Kernel panic - VFS: Unable to mount root fs on unknown-block

FarkR · n00b Joined: 01 Oct 2015 Posts: 11

Let me start off by saying that I'm aware of the documentation for this error on the wiki.
But nothing on this page is of any use to me since as far as I can tell, my initramfs is configured correctly.

Please take note of the following output before making a diagnosis

Here is the output given by

eccerr0r · Posted: Mon Nov 05, 2018 3:47 am Post subject:

Would be helpful to know a bit more context around the panic -- did it load the initramfs? Did it mount and use the initramfs?

One thing that looks a tad bit suspicious is that your direct EFIbootmgr settings do not include a root filesystem... but I've not tried installing without grub2, so not sure what to extrapolate from this information.
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

FarkR · n00b Joined: 01 Oct 2015 Posts: 11

eccerr0r · Posted: Mon Nov 05, 2018 5:32 am Post subject:

A screenshot would be helpful. Or if it has some dialog during boot, then it could be initramfs that loaded up. In any case if your initramfs didn't load, you should check your kernel options for initramfs handling; if it did load, then you should be able to break into a shell to inspect your devices.

Did you build your drivers into the kernel or as modules?

What happened to your refind?
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

FarkR · n00b Joined: 01 Oct 2015 Posts: 11

eccerr0r · Posted: Mon Nov 05, 2018 3:29 pm Post subject:

Hmm...looks like your initramfs did not get loaded, or very unlikely that it got loaded (then again, when you select an EFI boot option it should start with loading the kernel and then immediately afterwards it should say that it's loading the initramfs image). Without a root= and the initramfs not helping locate a root, it would explain why it's conking out...

I vaguely recall an issue with initramfs and efi ... ugh... someone remind me what it was. There was some known problem with some EFI implementations and command line argument.

My current suggestion is to either build all your drivers into the kernel, and/or build your initramfs into your kernel (there's a kernel config option to embed the initramfs image.)

As for refind, interesting....sure you don't have hardware problems? a block device flaking out?

(Yes I'm trying hard not to suggest installing grub2...)
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

NeddySeagoon · Posted: Mon Nov 05, 2018 3:52 pm Post subject:

FarkR,

The interesting part of the image is

FarkR · n00b Joined: 01 Oct 2015 Posts: 11

NeddySeagoon · Posted: Tue Nov 06, 2018 9:23 pm Post subject:

FarkR,

Make the initrd first and put it somewhere the kernel build can pick it up.
Configure the kernel to include the file.

This will end badly if the initrd must contain kernel modules.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.

FarkR · n00b Joined: 01 Oct 2015 Posts: 11

FarkR · n00b Joined: 01 Oct 2015 Posts: 11

Okay, so ironically with grub2 the initramfs does appear to load, but now it can't load the root filesystem: https://i.imgur.com/MWIepTq.jpg (you can also see me screwing around with busybox, peek blkid)
The UUID is definitely right (especially since grub generated the grub.cfg in the first place), and my ext drivers are enabled in .config, so... I'd post proof but not if I don't have to, since I'd have to reboot for it.

NeddySeagoon · Posted: Wed Nov 07, 2018 7:24 pm Post subject:

FarkR,

If you use --no-ramdisk-modules, your kernel must be built with everything needed to drive your hardware and filesystems configured as <*>, or built in, as it will not be possible to load any kernel modules until. root is mounted.
You may find

eccerr0r · Posted: Wed Nov 07, 2018 8:59 pm Post subject:

Yeah, with grub2 it's now clear that your disk subsystem modules were not included in the initramfs, cannot be loaded by initramfs, or not built into the kernel.

For informational purposes only, if you're interested - it's confusing that the handoffs cause drivers to be invalidated:

EFI can only read the ESP (EFI System Partition) and other FAT-formatted disks.
EFI can only load EFI applications: a kernel with an EFI stub, window's loader, grub2, refind, etc. Some EFI can direct the Linux kernel EFI stub to load initramfs using EFI directives, and EFI boot menu implementations seem to have problems directing the kernel to load initramfs -- this may be the problem you're seeing. Typically it will always work from the EFI shell. Note that Windows does not use an initramfs and hence the menu bug was likely poorly tested by your manufacturer.

GRUB2 and refind have their own capability of reading ext2 partitions, but cannot write to them. They also have a driver to read the ESP and FAT partitions. They can load the initramfs without the kernel's help, using their own drivers.

At this point, once kernel is running with initramfs loaded, it's up to the kernel to do everything else. Grub2/rEFInd and EFI itself cannot further help the kernel find anything else. If the kernel doesn't have the drivers built in, it's up to the instructions and contents of the initramfs to load drivers and find your root disk.

Hope this clarifies what needs to be done at this point to get a booting system (and the value of using grub2/refind instead of just using EFI menu boot directly).
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?