I was looking at using this for my arch zfs-on-root setups, but I've instead just been hacking on /etc/grub.d/10_linux and /lib/initcpio/hooks/zfs to get the boot menu setup I want with grub. I like the simplicity of it this way with less dependencies (especially otherwise needing to use AUR for the zfsbootmenu build or use the pre-built binary blob).
One concern I had with zfsbootmenu was I couldn't figure out how to load microcode. With kexec, zfsbootmenu can only load one image and late loading microcode may be "dangerous" [1]. I don't know practically if that is a real security issue or not. I tried cat'ing my images together as below, but it still didn't work for me:
There shouldn't be any issues catting the real initramfs with microcode into another file. I do that, as does another ZBM developer. What do you see when you try it?
I started ZBM years ago by hacking on the same grub script, then progressed to what it is now!
When I booted normally with the concatenated image (ensuring removing the original microcode img from the grub.cfg initrd command), I booted and I confirmed the microcode loaded with (dmesg | grep microcode).
Then switching to ZBM, while it did boot with the concatenated image, I didn't see microcode loaded in dmesg.
One concern I had with zfsbootmenu was I couldn't figure out how to load microcode. With kexec, zfsbootmenu can only load one image and late loading microcode may be "dangerous" [1]. I don't know practically if that is a real security issue or not. I tried cat'ing my images together as below, but it still didn't work for me:
[1] https://docs.kernel.org/arch/x86/microcode.html#why-is-late-...