[SOLVED] root= for initramfs + encrypted root partition

[calavicci]

I'm trying to install with an encrypted root partition. The kernel fails to load the (preliminary) root filesystem and panics, with something like

Code: Select all

VFS: Cannot open root device mapper/root or unknown-block(0,0): error -2 
Please append a correct "root=" boot option; here are the available partitions:
0800        78150744 sda  driver: sd
  0801           30720 sda1 7d516f3e-61a2-4a56-82f6-35cc2fffb661
  0802         3999744 sda2 8b1689aa-60ed-4105-a37f-90f3f366381e
  0803        73994240 sda3 54252171-c9ca-46f1-af389b473cd842db
  0804          124928 sda4 65aefdd9-98a4-4ac3-88b5-f8d95c8618c8
0b00         1048575 sr0  driver: sr
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,0) 

Specifics vary with kernel parameters.

I have no idea what to feed the kernel with root= to make this work. Let's go over some possibilities, suggested by various online sources, all of which I have tried and excluded:

• The actual root partition, /dev/sda3. Wrong: this is encrypted, so the kernel can't read it until after it's been decrypted.
• The virtual block device that holds the actual root filesystem, /dev/mapper/realroot. Wrong: this doesn't exist until /dev/sda3 has been decrypted.
• /dev/ram0, presumably autogenerated by the kernel expecting an initramfs or by the bootloader or something. Wrong: seems not to exist at all. (EDIT: this is right after all. See below.)
• /dev/mapper/root, also presumably autogenerated by the kernel expecting an initramfs or by the bootloader or something. Wrong: also seems not to exist at all.
• Anything generated by mdev. Wrong: doesn't exist until the initramfs is loaded and init gets going to invoke mdev in the first place.
• The (unencrypted) boot partition, /dev/sda4. Wrong: mountable, I guess, but doesn't contain anything even remotely like a root filesystem.

It should be the filesystem stored in initramfs.cpio, which I would assume that the bootloader and/or kernel is smart enough to know that it needs to load. Neither the bootloader nor the kernel is loading that filesystem as the root filesystem. There's no obvious way to specify what device that filesystem ends up being. There's no way to take a peek because I can't even just drop to /bin/sh (busybox) as a recovery shell until the kernel starts init.

Yes, CONFIG_DEVTMPFS is enabled. Yes, CONFIG_BLK_DEV_INITRD is enabled. Yes, all of the hardware drivers are in the kernel. No, they aren't modules; they're built-in. Yes, I have created an initramfs and packaged it nicely in a cpio archive, which sits with the kernel on the boot partition. Yes, the bootloader is loading the initramfs.

I am worried that I may not have enabled some device mapper or lvm bit in the kernel because only the physical partitions, and nothing from device mapper, are showing up in the kernel's list of suggestions for root=. I don't know what that option would be, though.

The problem also presumably might be in the way I am configuring the bootloader. It's not specific to any one bootloader, though, because LILO, GRUB Legacy, and GRUB2 all display the same behavior.

I am not using genkernel, mkinitrd, mkinitramfs, mkinitcpio, or any such tool.

[Hu]

I prefer to use the kernel build system's ability to embed an initramfs in the kernel, rather than rely on the bootloader to load it at boot time. Generally, if you use an initramfs, you do not need root= because the kernel should ignore it and trust that the initramfs will do the right thing. Based on reading Documentation/initrd.txt, you might need root=/dev/ram0 when using an external initrd. You said that /dev/ram0 does not exist. What did you see that led you to that conclusion?

It is normal that no LVM volumes are visible in the kernel's suggestion list, because you have not run any lvm commands to make the kernel aware of them.

[calavicci]

Thanks for your help!

I wouldn't really expect that I'd need root=, as you say, because the root fs should be in the initramfs, but I figure, who am I to argue with the kernel?

I say that /dev/ram0 does not exist because root=/dev/ram0 results in a complaint from the kernel that it does not exist.

Good to know that I'm seeing what I should regarding the device list.

[calavicci]

I say that /dev/ram0 does not exist because root=/dev/ram0 results in a complaint from the kernel that it does not exist.

Well, I say that, but I might be misinterpreting it. EXACTLY, it says

Code: Select all

VFS: Cannot open root device "ram0" or unknown-block(0,0): error -6

[Roman_Gruber]

So how is your setup

you write you use encryption but that is as good as the statement i eat a cookie (could be any cookie available in the supermarket).

you need to be more specific

how you made it / luks?
do you use lvm? yes / no?
what else needs to be known.

usually unencrypted boot partition ext 2, 512mb
initramfs with proper kernel, openrc, eudev and you should be able to boot and work from it.

[Goverp]

...
There's no way to take a peek because I can't even just drop to /bin/sh (busybox) as a recovery shell until the kernel starts init.
...

Therein lies your problem. At this stage, the kernel should be starting the init script in the initramfs. So if that was working correctly, and assuming your script is like most initramfs examples, it would start a busybox command-line if there was an error. And all this is before/instead of any root= processing.

My first guess would be that your cpio image isn't creating all the devices necessary for busybox to start a command line. In particular, it's easy to miss out the console and tty devices; AFAIR there are some sequencing issues to do with creating them and /proc and /dev that make it easy for busybox to try to type a message before there's a device to write to, causing an exception that tries to start a command line, which fails because there's no device to read from.

Compare your script with the various examples on the internet, and perhaps just try to get it to start command-line busybox; then you can see what devices there are, and which of your crypto/LVM/whatever commands are working.

If you get past that point, enabling trace within your script usually makes it clear where the remaining problems are.

[Hu]

Please post a listing of the contents of your initrd and the contents of its /init.

[calavicci]

Figured it out. I was right about some stuff and wrong about some stuff.

I was wrong about root=/dev/ram0; this is the right thing to pass to the kernel.

I was right about it not existing, and I was right about it being a forgotten CONFIG_SOMETHING for some virtual driver in the kernel: CONFIG_BLK_DEV_RAM was disabled.

Therefore, issue was that even though the initramfs was good, present, and properly fed to the bootloader, the kernel couldn't create /dev/ram0 to hold it. I was just focusing so much on the initramfs options and the root specification for the kernel that I wasn't thinking about CONFIG_BLK_DEV_RAM at all. My bad. Naively, I would have expected CONFIG_BLK_DEV_INITRD to have selected this automatically; just out of curiosity, can anyone explain why it doesn't?

"Encryption" was just for context. It couldn't have possibly have had anything to do with the problem because the system wasn't getting far enough to even try to deal with the encrypted partitions.

Marking as solved.