| 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: | genkernel | Assignee: | 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
Created attachment 314447 [details, diff]
patch to add real_root support
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?
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. (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. 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. :) (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 +*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 + 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!
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? 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? 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 :) 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? 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.. 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. 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. :) (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 |
