Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!

Bug 419965

Summary: sys-kernel/genkernel-3.4.34 doesn't use real_root variable for LUKS setup
Product: Gentoo Hosted Projects Reporter: Marios Andreopoulos <opensource>
Component: genkernelAssignee: Gentoo Genkernel Maintainers <genkernel>
Status: RESOLVED CANTFIX    
Severity: minor CC: fabio.coatti, opensource
Priority: Normal Keywords: InVCS, PATCH
Version: unspecified   
Hardware: All   
OS: Linux   
Whiteboard:
Package list:
Runtime testing required: ---
Attachments: patch to add real_root support

Description Marios Andreopoulos 2012-06-06 17:32:56 UTC
genkernel's documentation as well genkernel's ebuild post installation message suggest that one can use the real_root variable to set the name for the unencrypted LUKS device.

This doesn't work and genkernel always sets the unencrypted root device as /dev/mapper/root.

I attached a patch for initrd.scripts which can take a real_root value in the format of /dev/mapper/aName and set accordingly the unencrypted root device.

Unfortunately I only use LUKS, so I couldn't test it with LVM, ZFS or any other special setup.



Reproducible: Always
Comment 1 Marios Andreopoulos 2012-06-06 17:34:25 UTC
Created attachment 314447 [details, diff]
patch to add real_root support
Comment 2 Sebastian Pipping gentoo-dev 2012-06-09 21:37:23 UTC
Hello!


I use

  crypt_root=UUID=..... real_root=/dev/gentoo/root

to boot from LVM inside a crypt container.  Wouldn't something like

  crypt_root=${partition} real_root=/dev/mapper/${container}

work for you?
Comment 3 Marios Andreopoulos 2012-06-09 22:26:32 UTC
No, it doesn't work. If you take a look at /usr/share/genkernel/defaults/initrd.scripts, line 763, you will see that for LUKS genkernel always sets the root device as /dev/mapper/root.

I do not use LVM but I guess in your case it sets the decrypted partition space as /dev/mapper/root and then sets the LVM on top of it as /dev/gentoo/root.

I am afraid though that adding this ability, will break setups like yours, which use LUKS and LVM at the same time.
Maybe we can check the real_root variable and if it starts with /dev/mapper to assign it to LUKS or else assign it to LVM?

It isn't an important feature really, but it is referenced by the documentation and I came upon it when trying to make my system backups bootable directly from a usb disk with as little hassle as possible, so I thought I should give it a try.
Comment 4 Sebastian Pipping gentoo-dev 2012-06-10 16:44:54 UTC
(In reply to comment #3)
> No, it doesn't work. If you take a look at
> /usr/share/genkernel/defaults/initrd.scripts, line 763, you will see that
> for LUKS genkernel always sets the root device as /dev/mapper/root.

Right.  I suppose that name would work you for you technically but you want to be free to have /dev/mapper/foobar in /etc/fstab, correct?

The approach your patch is taking is clear to me now.  The black magic factor is a bit high for my taste but I can add that patch if it makes things better for you.  From the way it works, it should do no harm to the LVM+cryptsetup case.
I would use

  .... LUKS_NAME="`echo "${REAL_ROOT}" | sed 's|.*/||'`"

though to meet POSIX and save the slash escaping.
Comment 5 Marios Andreopoulos 2012-06-11 10:47:13 UTC
Yes, this report is because one can't set the decrypted root device for LUKS to be at /dev/mapper/foobar although this functionality is, for example, documented here, under --luks explanation:
http://www.gentoo.org/doc/en/genkernel.xml

It isn't a feature I really need but I thought I should report it anyway and since it is within my ability, to try to write a fix too.

So, I don't know what to propose. If it isn't much work and doesn't break things, it would be nice to add it but it is a minor enhancement, so it should be at the bottom of your priorities list. :)
Comment 6 Sebastian Pipping gentoo-dev 2012-06-11 17:38:27 UTC
(In reply to comment #5)
> Yes, this report is because one can't set the decrypted root device for LUKS
> to be at /dev/mapper/foobar although this functionality is, for example,
> documented here, under --luks explanation:
> http://www.gentoo.org/doc/en/genkernel.xml

I see.


> It isn't a feature I really need but I thought I should report it anyway and
> since it is within my ability, to try to write a fix too.

Good attitude.


> So, I don't know what to propose. If it isn't much work and doesn't break
> things, it would be nice to add it but it is a minor enhancement, so it
> should be at the bottom of your priorities list. :)

Added to git:
http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=f95264added35c25fb557931116edd3cd0aec7ba
Comment 7 Sebastian Pipping gentoo-dev 2012-06-11 17:44:57 UTC
+*genkernel-3.4.36 (11 Jun 2012)
+
+  11 Jun 2012; Sebastian Pipping <sping@gentoo.org> +genkernel-3.4.36.ebuild:
+  Bump to 3.4.36
+
Comment 8 Marios Andreopoulos 2012-06-12 01:57:45 UTC
Just gave init.scripts from git a spin and works as advertised. :D

Also I tried with your line just in case. It works great of course too.
LUKS_NAME="`echo "${REAL_ROOT}" | sed 's|.*/||'`"


Thanks!
Comment 9 Fabio Coatti 2012-06-18 12:07:17 UTC
I have a setup that worked so far, but with last genkernel the boot sequence will not complete.

LVM+LUKS, boot parameters here:


kernel /kernel-genkernel-x86_64-3.4.3  console=tty1 fbcon=map:0 radeon.modeset=1 dolvm root_keydev=/dev/mmcblk0p1 root_key=key.gpg crypt_root=/dev/sda5 real_root=/dev/mapper/vg0-root

initrd /initramfs-genkernel-x86_64-3.4.3

This worked fine up to last genkernel. I've tried to understand what is not working, but i failed. Any suggestion?
Comment 10 Marios Andreopoulos 2012-06-18 13:02:05 UTC
I haven't any experience with LVM, so I can't suggest many things.

Just to make sure, do you have set your root device as /dev/mapper/vg0-root in your /etc/fstab?
Comment 11 Fabio Coatti 2012-06-25 18:05:07 UTC
yes, exactly the same in fstab and in boot parameter. It is a change between 35 and 36 that broke the boot process, as soon I get 5 minutes I will try to understand where.
For now, I've masked 3.4.36 on my laptop :)
Comment 12 Marios Andreopoulos 2012-06-27 17:10:16 UTC
With the change that was made to genkernel because of this bug report, your system now should setup /dev/mapper/vg0-root as the decrypted block device created by luks.
Before this patch, your unencrypted luks device would always be /dev/mapper/root.

Could it be that in your system, /dev/mapper/vg0-root is a device created by LVM after (or before) luks creates its own device?
Comment 13 Fabio Coatti 2012-07-02 11:52:30 UTC
uhm... likely:

calvin ~ # lvdisplay 
  --- Logical volume ---
  LV Path                /dev/vg0/root
  LV Name                root
  VG Name                vg0
[...]

calvin ~ # ls -la /dev/vg0
totale 0                                                                                                                                                                                                                                     
drwxr-xr-x  2 root root  100  2 lug 08.44 .                                                                                                                                                                                                  
drwxr-xr-x 20 root root 4420  2 lug 08.45 ..                                                                                                                                                                                                 
lrwxrwxrwx  1 root root   20  2 lug 08.44 home -> /dev/mapper/vg0-home                                                                                                                                                                       
lrwxrwxrwx  1 root root   20  2 lug 08.44 root -> /dev/mapper/vg0-root                                                                                                                                                                       
lrwxrwxrwx  1 root root   19  2 lug 08.44 var -> /dev/mapper/vg0-var                                                                                                                                                                         
calvin ~ # 


(all encrypted)

However, not sure about how to proceed to solve this tricky situation..
Comment 14 Sebastian Pipping gentoo-dev 2012-07-08 17:53:23 UTC
Due to the reported regressions I'm afraid we may have to revert this feature and adjust documentation, instead.  I'd be happy about any better ideas from you.
Comment 15 Marios Andreopoulos 2012-07-09 14:10:02 UTC
Yes, I understand. I can't think of any better solution at the moment and it is a minor feature, so it is better to remove it before more users hit the regression.

Thanks though for your effort to include it. :)
Comment 16 Sebastian Pipping gentoo-dev 2012-07-09 17:54:30 UTC
(In reply to comment #15)
> Yes, I understand. I can't think of any better solution at the moment and it
> is a minor feature, so it is better to remove it before more users hit the
> regression.
> 
> Thanks though for your effort to include it. :)

Thanks for your understanding!

Reverted:
http://git.overlays.gentoo.org/gitweb/?p=proj/genkernel.git;a=commitdiff;h=51dcb157423d660f652e44a795cfb9a51724ad1e