Kernel Panic - unable to find root filesystem

Proinsias · Last edited by Proinsias on Thu Jul 20, 2017 9:30 pm; edited 1 time in total

Before heading off for a week I unplugged my desktop, removed the hard drives & gave it a little clean.

Just got back today, put it back together and got a kernel panic on booting. Unable to find root filesystem....I think vfs and (0,0) were mentioned at the end of the panic.

I stuck in a systemrescuecd, on optical disc, and used it to boot the existing gentoo install. I am typing from my gentoo install but with the sysrecue kernel.

Install is UEFI with grub2. I tried to regenerate the grub config with grub-mkconfig -o /boot/grub/grub.cfg from the gentoo/sysrescue environment and rebooted to the same panic. Back where I started.

My /etc/fstab uses /dev/sd* for root/boot/home etc:

Any help is appreciated, wondering if it is possible to fix this from within my current sysrecue/gentoo environment or if I will need to boot into full sysrecuecd and chroot into my gentoo.

Would using UUID's in /etc/fstab have avoided this?

genterminl · Posted: Thu Jul 13, 2017 8:09 pm Post subject:

Yes, I believe that panic with the vfs and (0,0) means that grub found the kernel, but the kernel can't find the root file system to mount. I went through a similar issue (on a BIOS system with legacy grub, not UEFI) when I moved my hard drive to a different PC. It took a few rounds booting to sysrescuecd and chrooting into Gentoo to get the right kernel parameters for all the new hardware. I use UUIDs in /etc/fstab, so changing drive order wouldn't have mattered for me.

I'm not sure how you could boot with the sysrescuecd kernel and your gentoo install, but I think whether you can fix your issue from there depends on exactly what is wrong. If you are not changing any hardware, I would expect that /dev/sdX drive order would not change, but using UUIDs is probably safer anyway. However, I think that will help only if the /dev/sdX drive order did somehow change. It's easy enough to try, and I don't think it will make anything worse. One thing you might try is 'lsblk -f' both in pure sysrescuecd boot and in your current state. Any differences might point you in the right direction. You should also say whether or not you use an initrd, since it might be something there causing the problem. In that case, I do think you would have to chroot into your Gentoo system to fix it.

Section_8 · l33t Joined: 22 May 2004 Posts: 627

Could it be that when you plugged your HDs back into your mobo, you swapped the sata ports, so what was sda is now sdb? Using UUID= or LABEL= in /etc/fstab prevents those kind of headaches.

Proinsias · Posted: Thu Jul 13, 2017 8:56 pm Post subject:

90% I did not swap the sata ports and /dev/sda is still what I expect it to be, removed the other drives leaving only my ssd with gentoo and it persists.

genterminl · Posted: Thu Jul 13, 2017 9:24 pm Post subject:

You could confirm which kernel it is using by "uname -a". I thought that option used the sysrescuecd's grub, but really found the kernal and system on the hard drive. Either way, the issue is still to find what's different between the two, as one works and the other doesn't. Before actually triggering the boot, (both from the hard drive and from the CD) see if you can see the actual kernel command line being used. The difference may show what you need to change in your own grub configuration.

Proinsias · Posted: Thu Jul 13, 2017 9:32 pm Post subject:

confirmed by uname -rav before I started the thread:

Jaglover · Posted: Thu Jul 13, 2017 10:05 pm Post subject:

You get (0,0) error with UEFI when root=<your_root_device> is not passed to the kernel. Also you get (0,0) error with both UEFI and BIOS systems when kernel is unable to access the drive due to missing controller driver.
And indeed, fstab has nothing to do with this because fstab happens to reside in root partition which is not mounted yet at this stage of boot.
_________________
My Gentoo installation notes.
Please learn how to denote units correctly!