From 18d8eafdea2322dc80c37e826a75e4d62094fecc Mon Sep 17 00:00:00 2001 From: Mauricio Faria de Oliveira Date: Thu, 11 Aug 2022 16:10:14 -0300 Subject: [PATCH] templates/linux_xen: Properly order the multiple initrd files The linux_xen template orders the "early" initrd file(s) _first_ (i.e., before the "real" initrd files) and that seems reasonable, as microcode updates usually come first. However, this usually breaks Linux boot with initrd under Xen because Xen assumes the real initrd is the first multiboot[2] module after the kernel, passing its address over to Linux in Xen's start_info struct. So, if a microcode-only initrd (i.e., without init/userspace) is found by grub-mkconfig, it ends up considered as a normal initrd by the Linux kernel, which cannot do anything with it (as it has no other files) and panic()s unable to mount root if it depends on a initrd to do that (e.g., root=UUID=...). ... Well, since Xen doesn't actually use the provided microcode by default / unless the 'ucode=' option is enabled, this isn't used in the general case (and breaks). Additionally, if an user enables the 'ucode=' option, that either specifies which module is to be used for microcode, or scans all modules (regardless of being first) for that. Thus, for Xen: - it is *not required* to have microcode first, - but it is *required* to have real initrd first So, fix it by ordering the real initrd before early initrd(s). After: # touch /boot/xen /boot/microcode.cpio # grub-mkconfig 2>/dev/null | grep -P '^\t(multiboot|module)' multiboot /boot/xen ... module /boot/vmlinuz-5.4.0-122-generic ... module --nounzip /boot/initrd.img-5.4.0-122-generic module --nounzip /boot/microcode.cpio ... Corner case specific to Xen implementation details: It is actually _possible_ to have a microcode initrd first, but that requires a non-default option (so can't rely on it), and it turns out to be inconsistent with its counterpart (really shouldn't rely on it, as it may get confusing; below). 'ucode=1' does manually specify the first module is microcode _AND_ clears its bit in the module bitmap. The next module is now the 'new first', and gets passed to Linux as initrd. Good. 'ucode=scan' checks all modules for microcode, but does _NOT_ clear a bit if it finds one (reasonable, as it can find that prepended in a "real" initrd anyway, which needs to be used). The first module still gets passed to Linux as initrd. Bad. Fixes: e86f6aafb8de (grub-mkconfig/20_linux_xen: Support multiple early initrd images) Signed-off-by: Mauricio Faria de Oliveira Acked-by: Juergen Gross Reviewed-by: Daniel Kiper --- util/grub.d/20_linux_xen.in | 5 ++++- 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/util/grub.d/20_linux_xen.in b/util/grub.d/20_linux_xen.in index 50c62562b..626aed40c 100644 --- a/util/grub.d/20_linux_xen.in +++ b/util/grub.d/20_linux_xen.in @@ -307,7 +307,10 @@ for current_xen in ${reverse_sorted_xen_list}; do initrd= if test -n "${initrd_early}" || test -n "${initrd_real}"; then - initrd="${initrd_early} ${initrd_real}" + # Xen assumes the real initrd is the first module after the kernel. + # Additional (later) initrds can also be used for microcode update, + # with Xen option 'ucode= (non-default anyway). + initrd="${initrd_real} ${initrd_early}" initrd_display= for i in ${initrd}; do -- 2.47.2