Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.
Sign upQubes does not honour rd.luks boot parameters #1912
Comments
lorenzog
changed the title from
Qubes does not
to
Qubes does not honour rd.luks boot parameters
Apr 16, 2016
marmarek
added
bug
C: installer
C: other
P: minor
labels
Apr 16, 2016
marmarek
added this to the Release 3.2 milestone
Apr 16, 2016
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
lorenzog
Apr 17, 2016
@marmarek I can't really see the relationship with those issues. On a side note, what is Qubes' initramfs based on? I found this list about Fedora (https://fedoraproject.org/wiki/Dracut/Options#crypto_LUKS) but the parameters in there do not really match what's in the dracut command line used in the Qubes grub entry: for example, rd.luks.vg vs. rd_LUKS_VG etc.
lorenzog
commented
Apr 17, 2016
|
@marmarek I can't really see the relationship with those issues. On a side note, what is Qubes' initramfs based on? I found this list about Fedora (https://fedoraproject.org/wiki/Dracut/Options#crypto_LUKS) but the parameters in there do not really match what's in the dracut command line used in the Qubes grub entry: for example, rd.luks.vg vs. rd_LUKS_VG etc. |
This comment has been minimized.
Show comment
Hide comment
This comment has been minimized.
marmarek
Apr 17, 2016
Member
That wiki page seems to be incomplete and outdated (as noted at the
beginning). Better documentation is in manual page of dracut.cmdline.
Regarding relationship - this may be very similar to not accepting
password when first try was invalid - I guess later tries are not
accepted for the same reason.
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
|
That wiki page seems to be incomplete and outdated (as noted at the Regarding relationship - this may be very similar to not accepting Best Regards, |
lorenzog commentedApr 16, 2016
•
edited
Edited 1 time
-
lorenzog
edited Apr 16, 2016 (most recent)
Qubes OS version (e.g.,
R3.1): R3.1Affected TemplateVMs (e.g.,
fedora-23, if applicable): n/aExpected behavior:
The kernel boot parameters "rd.luks.uuid=" and "rd.lvm.lv=" are honoured: at boot I expect to be asked the password to unlock the Qubes LUKS crypto volume indicated by those parameters.
Actual behavior:
The kernel boot parameters are ignored (probably by the ram disk?). At boot I am asked the password to unlock another, pre-existing LUKS volume.
If I manage to drop into the initramfs debug shell I can manually unlock Qubes' crypto volume and mount it where indicated by the root parameter as defined in /proc/cmdline. This allows Qubes to continue booting but it leaves Qubes hanging and no login screen appears.
Steps to reproduce the behavior:
Create a Volume Group on a disk.
Add Physical Volumes to make up enough space.
Create a Logical Volume "foo" taking up some of the space, not all of it.
Encrypt the logical volume "foo" using luks (cryptsetup...).
Then install Qubes as a new logical volume "bar".
Reboot.
You are asked to unlock logical volume "foo" instead of "bar".
General notes:
Qubes is installed in a pre-existing Volume Group as Logical Volume named "00" alongside another Logical Volume name "lv1". Qubes installs correctly in LV "00" however at boot it cannot find the root as I am asked to unlock volume "lv1" instead. More details here:
http://superuser.com/questions/1066187/select-the-correct-lvm-volume-group-as-the-root-device
Related issues:
Relevant labels: