Manjaro kernel panic in a multiboot non-Manjaro GRUB

General Linux Question
1

I installed Manjaro on a spare partition with three other Linux distros and Windows 7. After installation, all of them worked except Manjaro, which went into kernel panic.
Error message said: “Kernel panic - not syncing VFS: Unable to mount root fs on unknown block (0,0)”

BUT it successfully booted on the “fallback” option under Advanced Manjaro options.

Online digging found some mention of this being a known Manjaro issue, which was described as Manjaro developers wanting users to use their own GRUB. They described a fix thus:

Change the GRUB entry from “initrd /intel-ucode.img” to “initrd /initramfs-4.6-x86_64.img” (or whatever else your kernel version is).

I tried that fix and it did not work, but I may have done it wrong.

Here is the original GRUB entry

insmod part_gpt
insmod ext2
set root=‘hd0,gpt2’
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 898c3d71-b0f5-493c-98db-989bdd75078f
else
search --no-floppy --fs-uuid --set=root 898c3d71-b0f5-493c-98db-989bdd75078f
fi
linux /boot/vmlinuz-4.19-x86_64 root=UUID=898c3d71-b0f5-493c-98db-989bdd75078f rw quiet rd.udev.log-priority=3
initrd /boot/intel-ucode.img

Here is what I changed it to:

insmod part_gpt
insmod ext2
set root=‘hd0,gpt2’
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 898c3d71-b0f5-493c-98db-989bdd75078f
else
search --no-floppy --fs-uuid --set=root 898c3d71-b0f5-493c-98db-989bdd75078f
fi
linux /boot/vmlinuz-4.19-x86_64 root=UUID=898c3d71-b0f5-493c-98db-989bdd75078f rw quiet rd.udev.log-priority=3
initrd /boot/vmlinuz-4.19-x86_64.img

It couldn’t find the kernel.

Here is the GRUB entry that works:

insmod part_gpt
insmod ext2
set root=‘hd0,gpt2’
if [ x$feature_platform_search_hint = xy ]; then
search --no-floppy --fs-uuid --set=root --hint-bios=hd0,gpt2 --hint-efi=hd0,gpt2 --hint-baremetal=ahci0,gpt2 898c3d71-b0f5-493c-98db-989bdd75078f
else
search --no-floppy --fs-uuid --set=root 898c3d71-b0f5-493c-98db-989bdd75078f
fi
linux /boot/vmlinuz-4.19-x86_64 root=UUID=898c3d71-b0f5-493c-98db-989bdd75078f rw quiet rd.udev.log-priority=3
initrd /boot/initramfs-4.19-x86_64-fallback.img

I am using GRUB Customizer, my main OS is on sdb1, and this is on sda2.

1 Like
2

you just installed it?

3

It’s not unusual to experience such bugs with recent kernels. I remember not being able to boot into my Unstable Debian after a tiny kernel update. Booting to the old kernel solved it for me. Here, I recommend the same procedure. Try booting into a kernel that is confirmed to work on your machine. If it still does not work with initrd /boot/intel-ucode.img then apply the fix you have read online.

1 Like
4

If you’re installing into a MBR BIOS (rather than UEFI) environment, then this is a known issue.

Manjaro, and possibly Arch-based distros generally, treat Intel microcode updates differently to the majority of other distros.

The easiest way around it is to let Manjaro take control of GRUB - i.e. allow the Manjaro installer to write the bootloader to the MBR. Most other distros will work OK with the way GRUB is set up by the Manjaro installer, but Manjaro won’t work with GRUB in the way it is set up in other distros.

I have to say I find this peculiarity with Manjaro/Arch very frustrating. Why does Manjaro have to do things differently? I don’t know whether the same issue exists with UEFI.

3 Likes
5

Thanks a lot. Worked fine for me. Just changed from “intel-ucode.img” to “initramfs-5.3-x86_64.img” in Grub Customizer. :))))

1 Like