Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

That error is when you want to boot Linux Mint? It’s a common Manjaro Error. You have to refresh the grub. You can do the command:
sudo update-grub

If that command don’t work, you can try with:
grub-mkconfig -o /boot/grub/grub.cfg

Linux Mint is booting fine. The problem is only when I boot with manjaro. I tried your solution previously with no successful.

Even some days ago, I installed manjaro alone in the hard disk and the error still continue.

I am using a grub2 installed by linux Mint.

If Linux Mint works fine, do sudo update-grub2 from Linux Mint to check if with that the errors it’s fix.

Yeah, that won’t load Manjaro correctly. Manjaro has some extra configuration to do microcode loading which breaks when a different GRUB setup is used.

Reinstall GRUB from within Manjaro; use a live CD or similar and chroot (or chroot from within Mint).

Ok, I just re-installed GRUB2 from manjaro live USB and you’re right some other stuffs had been added to grub.cfg but the probem still continues. Linux Mint still booting fine. Here the new menu entry for manjaro:

menuentry 'Manjaro Linux (Kernel: 4.4.13-1-MANJARO x64)' --class manjaro --class gnu-linux --class gnu --class os $menuentry_id_option 'gnulinux-4.4.13-1-MANJARO x64-advanced-22be06dd-0a19-4111-87e0-3ba674b4e667' { 

   savedefault        
   load_video        
   set gfxpayload=keep        
   insmod gzio        
   insmod part_msdos        
   insmod ext2        
   set root='hd0,msdos4'        
   if [ x$feature_platform_search_hint = xy ]; then          
      search --no-floppy --fs-uuid --set=root --hint-bios=hd0,msdos4 --hint-efi=hd0,msdos4 --hint-baremetal=ahci0,msdos4  22be06dd-0a19-4111-87e0-3ba674b4e667        
  else          
     search --no-floppy --fs-uuid --set=root 22be06dd-0a19-4111-87e0-3ba674b4e667        
fi        

echo    'Loading Linux 4.4.13-1-MANJARO x64 ...'        
linux    /boot/vmlinuz-4.4-x86_64 root=UUID=22be06dd-0a19-4111-87e0-3ba674b4e667 rw  quiet        
echo    'Loading initial ramdisk ...'        
initrd    /boot/intel-ucode.img /boot/initramfs-4.4-x86_64.img    
}

And the error:

1 Like

Some additional lines before error. Maybe someone with kernel knowledge can give me any idea.

microcode: Microcode Update Driver: v2.01 <tigran@aivazian.fsnet.co.uk>, Peter Oruba
registered taskstats version 1
Loading compiled-in X.509 certificates
zswap: loaded using pool lzo/zbud
   Magic number: 4:953:957
rtc_cmos 00:01: setting system clock to 2016-06-24 12:40:34 UTC (1466772034)
PM: Hibernation image not present or could not be loaded.
List of all partitions:
No filesystem could mount root, tried:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)

To me is quite strange the lines:

List of all partitions:
No filesystem could mount root, tried:

This lines don’t show partitions and filesystems. It’s like SSD hard disk is not recognized by kernel. Maybe some drivers are not uploaded.

This is an old problem and it’s been reported many times in the old forum. It seems Manjaro devs think that their GRUB is the best (and it may be!) and all other distros should change their GRUB that way.
For us poor humans that’s a real annoyance because no other GRUB seems to boot Manjaro correctly (I’ve tried with Fedora, Mint, OpenSUSE, Arch, Debian…) but no way, :frowning: KERNEL PANIC is always there to welcome us.
The obvious solution should be to always install GRUB from Manjaro and boot any other distro within it. Problem is, apart that it’s somewhat unpleasant to be forced to use a GRUB instead of another one, Manjaro GRUB has another annoying bug, which seems also not to be a priority for the devs. It takes ages to update: for me OS-Prober takes sometimes more than 20 minutes to find about 8 distros I share in my HD, while Fedora takes only less than a minute.
The solutions I found: either edit each time my grub menu (Fedora or LinuxMint GRUB). Just hit “e” (edit) before hitting Manjaro to boot and modify last line, from “initrd /intel-ucode.img” to “initrd /initramfs-4.6-x86_64.img” (or whatever else your kernel version is).
Or make a new permanent entry in your GRUB, from whithin Fedora or Mint, adding a few lines in the file /etc/grub.d/40_custom. Examples can be easily found by googling grub 40_custom

2 Likes

Thank you! Thank you! Thank you!
I would have never guessed it was a GRUB issue but I should have when the default OS switched to MemTest.
Clear simple steps, easy to follow, THANK YOU!

merl

Hey, just to add some additional info in case anyone else runs into this issue:

I experienced the same issue on three recent installs using the 16.06.1-x86_64 community release of Cinnamon. In my scenario it turned out to be the “HOOKS” value in /etc/mkinitcpio.conf. After booting from the live usb to troubleshoot and chrooting to my installed OS I checked the /etc/mkinitcpio.conf file and found that the value was set to:

HOOKS=“plymouth”

I changed it to:

HOOKS=“base udev autodetect modconf block resume filesystems keyboard keymap fsck usr shutdown”

I then re-ran “mkinitcpio -p linux44” to rebuild the boot image. My systems were able to boot up without issue after modifying mkinitcpio.conf.

When I ran mkinitcpio -p linux44 before modifying the config file I received the message:

“WARNING: No modules were added to the image. This is probably not what you want.”

which is what prompted me to finally check the /etc/mkinitcpio.conf file.

Hope this helps others struggling with the same issue.

All the best!

3 Likes

The fix for the problem above is to do a sudo mkinitcpio -P, the default /etc/mkinitcpio.conf should be just fine. I don’t know why you only have plymouth hook in that file but it’s definitely not like that by default.

Same issue on 16.08pre6

Just chiming in - I hope this works for me as well. Though on one system it probably won’t. Almost all my laptop systems are triple boot and I have been running into this with Manjaro.
On one laptop I have a dual drive set up so it is a duel drive quint boot at this time with WinXP (for old graphics apps), Bodhi (3.1 at this time - waiting for the 4.0 release), Manjaro - all on a regular disk drive and on an SSD I have Mageia and a stripped WinXP. I am a bit of a distro hopper and have a first string line up of Linux distros and rotate others. This is where Manjaro give me a bit of a headache as it is a first string distro but run into this boot issue because I rotate other distros. This system is a bit more static - that is I put on this one the distros that meet specific needs and will stay for a while.

I got the same problem (kernel panic like yours, caused by the same mkinitcpio.conf with only HOOKS=" plymouth") with my Deepin and KDE installs from (August 1st and 2nd).
I will move my posts fron the Deepin thread to here.

One significant but resolvable problem! I got kernel panic on first boot of the installed system because of Plymouth-Grub issue. Like here: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0)
Then I chrooted (FYI for btrfs subvolume install the first mount command is mount -o subvol=@ -t btrfs /dev/sda1 /mnt) and took a look at mkinitcpio.conf. There only the plymouth hook was there, so I changed it to HOOKS="base udev block filesystems plymouth". Then ran mkinitcpio -P, edited /etc/default/grub to have not only quiet but quiet splash, ran update-grub and was able to boot the installed system having your stylish plymouth.
Please, make these settings default!:slight_smile:
PS: I installed with the CLI installer.

2 Likes

Thank you, @eugen-b ! This is strange.
When you look at the mkinitcpio.conf in manjaro-tools-iso-profiles you see that everything is there. So I wonder what happened on the way to your install.
Either this is a bug in the tools, or it has to do with btrfs… We’ll have to investigate this!

Hello, Bernhard!
I finally got the chance to check that the same issue (kernel panic after install) is occuring on my KDE install from the 02.08.2016


due to exactly the same reason: /etc/mkinitcpio.conf contains only HOOKS=" plymouth" and /etc/default/grub does not contain splash.
I will see if I can repair it exactly like my Deepin install. (Which is running ok on my little “Frankenstein” computer.)

But do you think this is specific to a desktop environment? Will it not just happen with any ISO using plymouth? How about xfce with the same kernel version?

Good point! It is not a Deepin edition problem as it happened with KDE as well. I’m moving my posts and your replies to a general hardware topic. (The whole report is meant for other users anyway who would encounter a similar issue.)
Update: Moved the posts to this thread here.

Maybe it’s the installer forgot to use that mkinitcpio.conf? What did you install with, Calamares or Thus?

Forum kindly sponsored by Bytemark