Re: [qubes-devel] systemd crypttab fix
On Tue, Apr 04, 2017 at 08:47:55AM +0200, Marek Marczykowski-Górecki wrote:
> [...]
> Answering your question -
> /usr/lib/dracut/modules.d/90crypt/module-setup.sh
That's super helpful, thanks, and gets me almost all of the way there
without having to touch systemd.
If I edit the dom0 /etc/crypttab file to change "none" to "/secret.key"
for the three partitions (/, /home and swap) and run "sudo dracut --force",
the initramfs /etc/crypttab will be generated with the keyfile specified
for / and swap, but not for /home.
It looks like the "filter for the devices we need" part of module-setup.sh
is discarding /home, which prevents the system from booting without
a passphrase. If I comment out the test "$_hdev -ef $_dev" it will
include all three partitions in the initrd /etc/crypttab and the
system boots fine.
--- module-setup.sh.orig2017-04-04 18:06:12.24689 -0400
+++ module-setup.sh 2017-04-04 18:06:17.49181 -0400
@@ -75,7 +75,7 @@
for _hdev in "${!host_fs_types[@]}"; do
[[ ${host_fs_types[$_hdev]} == "crypto_LUKS" ]] || continue
-if [[ $_hdev -ef $_dev ]] || [[ /dev/block/$_hdev -ef $_dev
]]; then
+if true || [[ $_hdev -ef $_dev ]] || [[ /dev/block/$_hdev -ef
$_dev ]]; then
echo "$_mapper $_dev $_rest"
break
fi
--
Trammell
--
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 qubes-devel+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-devel@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-devel/20170404220838.GS27162%40chishio.swcp.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-devel] systemd crypttab fix
On 04/04/2017 03:13 AM, Trammell Hudson wrote: On Mon, Apr 03, 2017 at 11:21:14PM +, 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. 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.
Re: [qubes-devel] systemd crypttab fix
On Mon, Apr 03, 2017 at 11:21:14PM +, 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. 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? -- Trammell -- 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 qubes-devel+unsubscr...@googlegroups.com. To post to this group, send email to qubes-devel@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-devel/20170404001338.GG30182%40chishio.swcp.com. For more options, visit https://groups.google.com/d/optout.
