Created attachment 634928 [details] Failed kernel boot log (with Xen) All, While performing a rare server reboot, I've discovered that I can no longer boot with Xen. Booting without Xen, same grub.cfg, same kernel, same initramfs works fine. When attempting to boot with Xen, I get: -------------->8---------------------- Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(1,0) CPU: 3 PID: 1 Comm: swapper/0 Not tainted 5.4.35 #10 Hardware name: Supermicro X9DRi-LN4+/X9DR3-LN4+/X9DRi-LN4+/X9DR3-LN4+, BIOS 3.2 03/04/2015 Call Trace: dump_stack+0x64/0x7c panic+0xff/0x2c6 mount_block_root+0x292/0x2b6 prepare_namespace+0x166/0x19c ? rest_init+0x95/0x95 kernel_init+0x5/0xeb ret_from_fork+0x35/0x40 Kernel Offset: disabled -------------------------------------- I suspect grub is loading the initramfs to a location that is not accessible to the kernel after Xen has taken control. I've removed 'dom0_mem' from the Xen command line without success. Thankfully, Grub provides no way for me to a) determine where it loads the initramfs to, nor b) force it to a different address. :-/ I'm sure there's a simple option I'm missing, but I'll be damned if I can find it. Any insight or suggestions would be appreciated.
Created attachment 634930 [details] Successful kernel boot (without Xen)
Created attachment 634932 [details] generated grub config file
Created attachment 634936 [details] Vanilla Linux v5.4.25 config file
I should also mention, I was going to downgrade to Xen 4.11 (what I was previously running), but those ebuilds are no longer in portage. :(
echo 'Loading initial ramdisk ...' module2 --nounzip /intel-uc.img /initramfs-genkernel-x86_64-5.4.35 Please try to remove intel-uc.img and regenerate grub.cfg. Only initramfs from genkernel should be there.
(In reply to Tomáš Mózes from comment #5) > echo 'Loading initial ramdisk ...' > module2 --nounzip /intel-uc.img /initramfs-genkernel-x86_64-5.4.35 > > Please try to remove intel-uc.img and regenerate grub.cfg. Only initramfs > from genkernel should be there. Well, I owe you a bottle of whiskey, sir. :-) That was exactly it! I'm so glad it wasn't a bug, although I would like to know what put that file there. Thanks!
Actually, it's not your fault. It happens since Grub started to include intel-uc.img as module. Now you have a running Xen, but you don't have the microcode applied. Here's the workaround that works for me: 1) have this in your /etc/default/grub GRUB_CMDLINE_XEN="... ucode=scan" GRUB_EARLY_INITRD_LINUX_STOCK="" 2) install sys-firmware/intel-microcode USE=initramfs 3) install genkernel 4) generate an initramfs with genkernel 5) concatenate the microcode with the initramfs from genkernel: cat intel-uc.img initramfs-${KV}-gentoo${KR}.img > initrd-${KV}-${kernel_type}${KR} rm -v initramfs-${KV}-gentoo${KR}.img 6) in /boot you'll have something like: config-5.4.35-gentoo initrd-5.4.35-gentoo kernel-5.4.35-gentoo 7) regen grub.cfg, now your xen grub entry looks like: multiboot2 /xen.gz placeholder ... ucode=scan ${xen_rm_opts} echo 'Loading Linux 5.4.35-gentoo ...' module2 /kernel-5.4.35-gentoo placeholder ro echo 'Loading initial ramdisk ...' module2 --nounzip /initrd-5.4.35-gentoo Thanks to GRUB_EARLY_INITRD_LINUX_STOCK="" intel-uc.img is not included in the initrd line, but we have everything packed together. You have your microcode applied and the help of initrams too.
