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

Hi all, I have an error after installing XFCE Manjaro 16.06.1.

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

I have a laptop Lenovo Z570 (2011) without UEFI support and a SSD hard drive. I installed Linux Mint 18 and works well. I installed the kernel 4.1 and 3.18 form live USB using mhwd-kernel and the error still continues.
Here some additional info about my system:

[manjaro@manjaro ~]$ sudo fdisk -l /dev/sda
Disk /dev/sda: 111.8 GiB, 120034123776 bytes, 234441648 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xb1063e30

Device     Boot     Start       End   Sectors  Size Id Type
/dev/sda1            2048   3999743   3997696  1.9G 82 Linux swap / Solaris
/dev/sda2  *      3999744  62593023  58593280   28G 83 Linux
/dev/sda3       117254142 234440703 117186562 55.9G  5 Extended
/dev/sda4        62593024 117252095  54659072 26.1G 83 Linux
/dev/sda5       117254144 234440703 117186560 55.9G 83 Linux

The sda2 for Mint and sd4 for Manjaro.

[manjaro@manjaro ~]$ lsblk -f /dev/sda
NAME   FSTYPE LABEL UUID                                 MOUNTPOINT
├─sda1 swap         fd77b164-8890-4832-966d-5c4926b312fa [SWAP]
├─sda2 ext4         73082fb7-2771-4009-8e1a-2fc5cda26996
├─sda4 ext4         22be06dd-0a19-4111-87e0-3ba674b4e667
└─sda5 ext4         b7daebb8-b9ed-4967-b9dd-ae0dd8e929d9

The grub2 menu entry for manjaro:

menuentry 'Manjaro Linux (16.06.1) (on /dev/sda4)' --class 
gnu-linux --class gnu --class os $menuentry_id_option 
'osprober-gnulinux-simple-22be06dd-0a19-4111-87e0-3ba674b4e667' {
    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  
      search --no-floppy --fs-uuid --set=root 22be06dd-0a19-4111-87e0-3ba674b4e667
    linux /boot/vmlinuz-4.4-x86_64 root=UUID=22be06dd-0a19-4111-87e0-3ba674b4e667 rw quiet
    initrd /boot/intel-ucode.img /boot/initramfs-4.4-x86_64.img


1 Like

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' { 

   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        
     search --no-floppy --fs-uuid --set=root 22be06dd-0a19-4111-87e0-3ba674b4e667        

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 <>, 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


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!


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:


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!


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.


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.

Forum kindly sponsored by