On 04/04/2017 03:13 AM, Trammell Hudson wrote:
On Mon, Apr 03, 2017 at 11:21:14PM +0000, Rusty Bird wrote:
Did you try the "rd.luks.key=LUKSUUID=KEYFILE" workaround? IIRC, this
shouldn't trigger the buggy if branch.
I haven't tried that one, although I did build a patched version of
systemd v227 with the fix applied and found another problem --
it seem to only apply the keyfile to the root device and prompts for a
password for the other partitions.
So as a workaround I'm generating a /etc/cryptab that specifies
/secret.key for every paritition and inserting those two files into
the initrd at boot time. This works, although the rebuilding the cpio
is slow.
I did something like that on a centos7 install. I'm wondering what you
mean by "inserting those two files" - in my case the only I've done is
to create a .conf file in /etc/dracut.conf.d containing this single line:
install_items+=/etc/blah/key
The key path being of course the same as the one defined in
/etc/crypttab ; that way the key file gets included automatically each
time dracut creates a new initrd - usually at each kernel update.
Judging by your former posts (very interesting BTW !) I guess you
probably have a more custom setup an my solution may not apply but I
thought I'd post it anyway :)
Cheers
Ivan
What controls the generate of /etc/crypttab in the initrd during a
system upgrade? Would it be possible to have it create the correct
entries for all the partitions instead?
--
You received this message because you are subscribed to the Google Groups
"qubes-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/051ac59b-f169-3a92-69e3-37bb4a5742cd%40maa.bz.
For more options, visit https://groups.google.com/d/optout.
