Bug 344407 – sys-kernel/genkernel: Incorrect root device node after boot from LUKS root using genkernel-powered initramfs

• Product: Gentoo Linux
• Status: RESOLVED FIXED

[Description Wolfram 2010-11-06 17:58:22 UTC]

I've encrypted my / with LUKS, then added LUKS="yes" into /etc/genkernel.conf and crypt_root=/dev/sda1 into kernel line in /boot/grub/menu.lst 

So, now I have system that boots from encrypted root and everything looks good excepting one small issue: I haven't /dev/mapper/root device on my encrypted root, so fsck initscript fails at startup. I've found only one symlink (possibly created by udev) that refers to actual encrypted device /dev/root -> dm-0, so now I using "ln -s /dev/root /dev/mapper/root" in fsck script as workaround, but it's ugly solution. I think that udev (or something else) should create device node (or, at least, symlink) at proper place .


Reproducible: Always

[Comment 1 Sebastian Pipping 2010-11-18 23:18:40 UTC]

Please paste the complete grub boot entry.

If it doesn't use "real_root=": please try that.
If it doesn't include "dolvm": please try that.

[Comment 2 Wolfram 2010-11-21 07:37:31 UTC]

Here is exact grub menu entry:

title Gentoo 2.6.34-r12
root (hd0,0)
kernel /boot/kernel-genkernel-x86_64-2.6.34-gentoo-r12 root=/dev/ram0 crypt_root=/dev/sda2 real_root=/dev/mapper/root
initrd /boot/initramfs-genkernel-x86_64-2.6.34-gentoo-r12


Adding/removing real_root parameter don't changes anything, such as dolvm. Just by the way, I don't use lvm.

[Comment 3 Sebastian Pipping 2010-11-21 15:16:58 UTC]

Thanks for that info.

I'm wondering why cryptsetup is not creating /dev/mapper/root.
The call

  crypt_filter "cryptsetup ${cryptsetup_options} luksOpen ${LUKS_DEVICE} ${LUKS_NAME}"

in /usr/share/genkernel/defaults/initrd.scripts makes me expect its creation.

What does "ls -al /dev/mapper/" show for you?  Anything besides control?
If that doesn't reveal anything, I'm out of ideas for now.

[Comment 4 Wolfram 2010-11-21 18:41:27 UTC]

initramfs script works correctly, but it creates symlink in ramfs, so when / remounts from actual root, new fs doesn't contain required link.

% mount
rootfs on / type rootfs (rw) <--- ramfs root
/dev/mapper/root on / type ext4 (rw,noatime,commit=0) <-- actual root, but /dev/mapper/root is located on ramfs root


% ls -ls /dev/mapper 
total 0
0 crw-rw---- 1 root root  10, 59 Nov 21 13:34 control
...
0 lrwxrwxrwx 1 root root       9 Nov 21 13:34 root -> /dev/root
0 brw-rw---- 1 root disk 253,  1 Nov 21 13:34 swap
0 brw-rw---- 1 root disk 253,  2 Nov 21 13:34 tmp
...

Note: the 
> root -> /dev/root
symlink was created from fsck script

[Comment 5 Sebastian Pipping 2011-01-20 18:32:37 UTC]

*** Bug 352047 has been marked as a duplicate of this bug. ***

[Comment 6 Sebastian Pipping 2011-01-20 18:36:21 UTC]

To my current understanding this is what happens:
- /dev/mapper/root is created
- on switch_root (of busybox) it disappears
- udev is not re-creating it

As udev does not seem to mount on top of an existing /dev, we have to et udev to create it.  Any ideas on how to best make that happen?

[Comment 7 Sebastian Pipping 2011-02-07 20:10:28 UTC]

The recent commits have a good chance of fixing this already.
Could you give gennkernel-99999 (five nines) a spin and report back?

In case I do not hear anything from you I may close this bug in two weeks.

[Comment 8 Sebastian Pipping 2011-02-10 17:22:09 UTC]

Confirmed off the bug, closing.

Patch included in genkernel 3.4.13.