Bug 905683

This workaround might work, until this is fixed:

# echo 'omit_dracutmodules+=" systemd "' > /etc/dracut.conf.d/luks-workaround.conf
# dracut -f

Thank your for your replay. This works. However the graphical output is send to nowhere. Any passwords must be entered blindly as there is no input prompt or any other graphical output while booting.

This issue still exists in dracut-024-25.git20130205.fc18.x86_64 which I have just installed.

working on it

The modification in comment 1 works very nicely when "rhgb quiet" is removed from the kernel command line.  dracut prompts for the passphrase if the key file is not found.

Patch sent to systemd mailing list:
http://lists.freedesktop.org/archives/systemd-devel/2013-April/010333.html

That patch has been committed, will we see this in Fedora 18?
It would be great!

systemd-201-2.fc18.6 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6

Package systemd-201-2.fc18.6:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing systemd-201-2.fc18.6'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-5452/systemd-201-2.fc18.6
then log in and leave karma (feedback).

Created attachment 745820 [details]
journalctl_systemd-201-2.fx18.6_20130509

Hi,

I've just tested systemd-201-2.fc18.6 but it still doesn't work. The journalctl is attached. It shows that some characters aren't translated right.

Looks like Harald's patch did not add support for the "rd.luks.key=<keypath>:<keydev>" syntax.

This bug is valid for f19 too. Please update to f19 so it won't be closed together with f18 life cycle.

Extra workaround, for f19:

# echo 'add_drivers+=" vfat"' >> /etc/dracut.conf.d/luks-workaround.conf
# dracut -f

(In reply to prudy from comment #14)
> Extra workaround, for f19:
> 
> # echo 'add_drivers+=" vfat"' >> /etc/dracut.conf.d/luks-workaround.conf
> # dracut -f

Does it mean, I need following two lines in deacut's config files to be albe to use LUKS key from file?

omit_dracutmodules+=" systemd "
add_drivers+=" vfat"

Yes, two lines, the vfat is not added by default so thy cannot be read (well, unless you use different filesystem on the key storage).

FYI:
For my F19 build in /etc/dracut.conf in addition ot omitting 'systemd',
I needed to put:

add_dracutmodules+=' lvm crypt '

LVM - because my volumes are under LVM control, but I also had to add 'crypt'
or cryptsetup was not in the initramfs.

(In reply to Michal Schmidt from comment #12)
> Looks like Harald's patch did not add support for the
> "rd.luks.key=<keypath>:<keydev>" syntax.

So this is still unresolved? I was using keypath:keydev syntax on OpenRC and am now unable to to use the keydev part. USB stick is not automatically getting mounted either. This is on dracut-034.

This message is a reminder that Fedora 18 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 18. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '18'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 18's end of life.

Thank you for reporting this issue and we are sorry that we may not be 
able to fix it before Fedora 18 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior to Fedora 18's end of life.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Actually this seems to be solved. The thing is that it must be used differently with systemd. See some guide here:
http://forums.fedoraforum.org/showpost.php?p=1681988&postcount=43

Hi prudy,

thanks for the guide, but I don't see how I can get it to work.

My system looks like the following:
- unencrypted partition /boot
- encrypted lvm with systempatition
- unencrypted vfat partition on a usb key with a keyfile

Imho the fstab method won't work here as systemd is reading /etc/fstab and fstab is encrypted on my system. Have you any other idea, how I can tell systemd where the keyfile is? The old method - I'm currently using rd.luks.key=/keyfile.gpg:UUID=12345678-1234-1234-1234-123456789012 - doesn't work with systemd.

(In reply to Daniel L. from comment #21)
> Hi prudy,
> 
> thanks for the guide, but I don't see how I can get it to work.
> 
> My system looks like the following:
> - unencrypted partition /boot
> - encrypted lvm with systempatition
For this 'lvm' must be added to dracut modules as mentioned before.

> - unencrypted vfat partition on a usb key with a keyfile
> 
> Imho the fstab method won't work here as systemd is reading /etc/fstab and
> fstab is encrypted on my system. Have you any other idea, how I can tell
The fstab is taken from initramfs, this is not encrypted. Could it be?

> systemd where the keyfile is? The old method - I'm currently using
> rd.luks.key=/keyfile.gpg:UUID=12345678-1234-1234-1234-123456789012 - doesn't
> work with systemd.
Yes, this is not compatible as I mentioned, simply use luks.key= (only the key path here on your mounted UUID device), or via crypttab. Key device must be mounted using fstab or systemd *.mount file (I have not used this one).

I just noticed you use gpg-ed keyfile, I have not tried this as it would require a password I presume.

Sorry, but I still don't get it to work. The problem is that it doesn't mount the USB key (I was using fstab method). In my opinion this is not solved with your tips and still a bug, because the system stops booting and goes to the emergency mode if it doesn't find a keyfile. I would expect it to prompt for a password instead of stopping the boot process. AFAIK the guys above still use omit_dracutmodules+=" systemd " which works for me too...

Can you unpack the initramfs you use to see if the valid fstab is there (with the proper entry for the key device)? I presume you can mount it manually to using  fstab (well, creating the mount path, the systemd will do it automatically if it does not exist). You could increase the mount timeout there, example 5s was enough for me but your device might need bit more. What are the actual entries in cmdline/fstab/crypttab?
The 'omit_dracutmodules=' works but my point was to try with systemd.

Daniel, I have just checked the behaviour and you are right - asking for the password when key device is not found is not working. The guide I wrote is fine to ensure longer timeout for the key device mount. But if the key device is not inserted there will be no password request after this timeout.

Looking at the code of systemd I see the patch above adds the key option support (so you can give the key in command line). The implementation tries attaching the luks using given key file, if it fails it would fall back to the password dialogue.
However, when key device is not present, all this logic is not even started. The reason of this is not satisfied dependency of systemd internally generated option 'RequiresMountsFor'.

Before there is a systemd code fix, I described the workaround in here:
http://forums.fedoraforum.org/showpost.php?p=1696031&postcount=44

Created attachment 887979 [details]
proposd patch for the issue

Attaching the poposed patch for this problem.

(In reply to prudy from comment #28)
> Created attachment 887979 [details]
> proposd patch for the issue
> 
> Attaching the poposed patch for this problem.

One note - the key device must be specified in fstab with "auto,nofail"

A much more direct workaround, if the keyfile is stored locally. In other words, only if you want to "remove" encryption:

While the keyfile is specified in /etc/crypttab, it isn't copied into the initramfs by dracut. The option '--include' to dracut is only a temporary workaround; any additional initramfs rebuilds or kernel upgrades will remove the additional files instead. Instead to preserve changes across both kernel and (probably any) dracut upgrades, use:

/etc/dracut.conf.d/crypttab
    push include_src "/path/to/local/keyfile/as/per/etc/crypttab"
    push include_target "/path/to/local/keyfile/as/per/etc/crypttab"
    PARMS_TO_STORE+=" --include '/path/to/local/keyfile/as/per/etc/crypttab' '/path/to/local/keyfile/as/per/etc/crypttab'"

Note: for some strange reason dracut strips the SWAP luks partition from crypttab when generating the initramfs. Since a keyfile isn't specified, you might still receive a password prompt. Remove the luks swap partition from the kernel command line (/etc/boot/grub) and regenerate grub.cfg (grub2-mkconfig) to solve this.

===========

Anyway, the only real fix (as per comment 12) is to implement "rd.luks.key=<keypath>:<keydev>" syntax in cryptsetup-generate.c (systemd).

The real fix has been submitted to systemd already.

(In reply to prudy from comment #31)
> The real fix has been submitted to systemd already.

so, should this be reassigned to systemd?

Yes Harald, systemd.

(In reply to prudy from comment #28)
> Created attachment 887979 [details]
> proposd patch for the issue
> 
> Attaching the poposed patch for this problem.

Typo... 
+        { "WantssMountsFor",....

double "s"

Best to post this patch to the systemd-devel mailing list.

http://lists.freedesktop.org/mailman/listinfo/systemd-devel

Created attachment 919119 [details]
patch adding WantsMountsFor with typo fixed

Please do not compress small attachements.

Yes, this patch has a typo, please refer to comment #31 instead.

prudy, it's still not working with a gpged keyfile, is it? Can I provide any additional information? I think somebody should close this ticket as fixed. I'll open a new report for the gpged keyfile then.

I have not touched the gpg-ed keyfile problem.
I focused on solving the systemd not able to issue the passphrase request when device with a key file is not present. Proposed patch was sent to systemd mailing list, however it was not merged due to implementation change requests that I had no time for. But functionally it is fully working and tested. 
The patch in this ticket is also working but is a proof of concept only, the systemd mailing list patch is more accurate. 
Still a dracut workaround for this can be used as in Comment 27 above.

I don't think that specifying rd.luks.key= works as it should:

        linux16 /vmlinuz-3.17.4-301.fc21.x86_64 root=/dev/mapper/luks-f6e9b3ee-3cdd-484b-8bce-7e06b080a986 ro rd.luks.uuid=luks-f6e9b3ee-3cdd-484b-8bce-7e06b080a986 rhgb quiet LANG=en_US.UTF-8 rd.luks.crypttab=0 rd.luks.key=/key:UUID=04779efa-4c0e-42c3-b325-56c0d925b3e9

I'm always prompted for a password even though I specified the keyfile. Adding "rd.break" still prompts for a password, and then breaks. This looks like a dracut problem to me.

# rpm -q dracut systemd
dracut-038-30.git20140903.fc21.x86_64
systemd-216-12.fc21.x86_64

Hi Jan,
Please see my note in https://bugzilla.redhat.com/show_bug.cgi?id=905683#c20
abut incompatibility for rd.luks.key between dracut and systemd.
In short - if you use it for systemd it must contain only the full-path.

I have not tested yet with fedora 21, maybe there is something new.

It is still not fixed in Fedora 21.
Workaraoud is posted here:
http://forums.fedoraforum.org/showpost.php?p=1721369&postcount=45

Zbyszek, are you working on this one? If not, I'd like to give it a shot.

Go ahead. I totally forgot about it.

Nice to read this. I'm using the workaround of omitting systemd in dracut config, but that makes me face another bugs with initramfs without systemd like keyboard layout not working at boot or console font not setting up (it only setup during boot if plymouth is in text mode).

Jan Synacek I could test packages in fedora testing if you need.

(In reply to David Santamaría Rogado from comment #44)
> Nice to read this. I'm using the workaround of omitting systemd in dracut
> [...]
With my latest workaround you don't have to skip systemd, it is fully functional.
But yes, will be good to have this solved.

For the brave: you can test this dracut version:

https://jsynacek.fedorapeople.org/dracut/12.git20140402.fc20.wip/

Dracut already provides code that handles cryptsetup related stuff. My patch removes systemd-crypt-setup related code from dracut, thus leaving all the processing to dracut itself.

From my limited testing, dracut now correctly falls back to password prompt even though when the keyfile device is not present.

I'm using fedora 21.

This doesn't contradict with the purpose of using systemd with dracut? Can't be systemd make aware of rd.luks.key with the same behaviour?

(In reply to David Santamaría Rogado from comment #47)
> This doesn't contradict with the purpose of using systemd with dracut? Can't
> be systemd make aware of rd.luks.key with the same behaviour?

Dracut already has code to deal with encrypted root partition and the key files, there's probably no reason to do this directly in systemd. Once the root is mounted and switched to, systemd handles key files as well, just not on possibly unmounted partitions. If you already have your encrypted root mounted, you can put the keys there, so there's probably no reason to support such use case in systemd itself.

How long would the 'don't use systemd' approach wait for you to plug in the USB device?

In dracut 10s, or number of seconds defined by rd.luks.key.tout=

This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Hi Harald,

I'm still omitting systemd as I'm using a gpged keyfile. Since F22 this doesn't work anymore though. Have you changed anything in 041-10.fc22.1 affecting this? Even fallback mode doesn't work. It says "crypt: unknown target type".

It would be nice if you could drop any information ;) Thanks in advance.

I can confirm this completely fails all workarounds for Fedora 22 as well, and has basically become completely unusable, and this is very sad, especially after 2 years.

Jan Synacek told us in comment #48 that this probably won't be added to systemd as dracut can already handle this.

So, can anybody tell us if this will still be maintained in dracut?

If not, I will open a bug against systemd.

If it will still be maintained, getting some information and help with troubleshooting would be nice. I downgraded dracut, dracut-config-rescue and dracut-network, but it didn't help.

For the whole '/' encryption dracut will probably do, however having separate partitions it still must be supported in systemd.
The bugfix has been noticed to systemd mailing list but reasonably there are only 30 people watching this thread, so not many, and so low priority probably...

Beside my systemd workaround (no recompilation, only scripts, works for F22), you can also find quite nice grub level solution. With patches it allows full (including /boot) encryption and key from external device. It needs rpm recompilation but once installed it does not have to be modified every kernel update.

Thanks for your replay, but let me explain the problem again:

My partition layout isn't really anything specific. I have an unencrypted /boot partition and an encrypted LVM that contains /swap and /. My keyfile is GPGED and on a USB drive.

My grub.cfg looks like
linux   /vmlinuz-4.0.4-201.fc21.x86_64 root=/dev/mapper/VolGroup00-LogVol01 ro rd.md=0 rd.dm=0  rd.luks.uuid=luks-XXX...XXX rd.lvm.lv=VolGroup00/LogVol01 rd.lvm.lv=VolGroup00/LogVol00 rd.luks.key=/key.gpg:UUID=YYY...YYY vconsole.keymap=de LANG=de_DE.UTF-8

I added the following lines to dracut.conf:
add_dracutmodules+="crypt-gpg"
omit_dracutmodules+="systemd"
The first line adds the gpg module to dracut, so it can encrypt the gpged keyfile. The second line omits systemd.

Old F21 kernels build with this configuration still boot F22 systems.

Until F22 this configuration has been working and was still maintained in dracut, as said in comment #48. So, will this still be maintained in dracut or will this move over to systemd?

I'm aware that the subject of this bug is keyfiles in general and not gpged ones. I will open a new bug report if anyone tells me were this will be maintained ;)

Also thanks for your workaround. I know the thread on the forum. I'm aware that systemd doesn't accept 'rd' parameters etc. but I didn't get it to work with a gpged keyfile though.

Has anybody ever tried the patched version of dracut from comment 46?

(In reply to Jan Synacek from comment #57)
> Has anybody ever tried the patched version of dracut from comment 46?

Sorry, sadly not. I just tried downgrading dracut to that version, but it seems like the 4.X kernels need dracut 0.38 or newer. Can the patches be applied to current dracut version as well?

Yes, the patch can be applied. You can find it at https://github.com/jsynacek/dracut/tree/crypto-keys. Let me know if I should create a testing F21/F22 packages.

(In reply to Jan Synacek from comment #59)
> Yes, the patch can be applied. You can find it at
> https://github.com/jsynacek/dracut/tree/crypto-keys. Let me know if I should
> create a testing F21/F22 packages.

It would be great if you created the testing packages, because I'm not very familiar with this process.

Packages for Fedora 22 can be found at https://jsynacek.fedorapeople.org/dracut/11.fc22.1.luks/. Fedora 21 version is in the works.

F21: https://jsynacek.fedorapeople.org/dracut/40.git20150518.fc21.luks/

Thank you! In F21 it works flawlessly. As you said, dracut is handling the encryption stuff and I don't need to omit systemd.

In F22 it doesn't work though. It is doing the same thing as it is with the current stable version. It finds my keyfile, however it is falling back to passphrase mode. When I type in the correct passphrase, it says:

device-mapper: table: 253:0: crypt: unknown target type
device-mapper: ioctl: error adding target to table
dracut-initqueue[313]: device-mapper: reload ioctl on luks-ABC...XYZ failed: Invalid argument

I tried downgrading device-mapper to F21 version, added several modules to dracut, but it didn't help. Any other ideas? Shall I open a bug against device-mapper?

(In reply to Daniel L. from comment #63)

> device-mapper: table: 253:0: crypt: unknown target type

This looks like the dm-crypt.ko kernel module is missing in initramdisk.
(It will need also some crypto modules but the error message above would be different in that case.)

Well, the patch will probably not make it into any Fedora version anyway: https://github.com/haraldh/dracut/pull/72. I don't think it makes sense to file bugs when you are using a testing package.

Upstream isn't really fond of supporting such use case (http://lists.freedesktop.org/archives/systemd-devel/2015-April/031137.html), so there's nothing that I can really do right now.

@Daniel: were you looking for GPG support?  The upstream comment I'm reading says:

"I'd be willing to merge a patch that supports basic
rd.luks.key=<keypath>:<keydev>, even though I think it's usecase is
more security theater than really useful."

The systemd maintainer doesn't have to understand physical security if he's willing to merge the patch. ;)

(In reply to Bill McGonigle from comment #67)
> @Daniel: were you looking for GPG support?  The upstream comment I'm reading
> says:
> 
> "I'd be willing to merge a patch that supports basic
> rd.luks.key=<keypath>:<keydev>, even though I think it's usecase is
> more security theater than really useful."
> 
> The systemd maintainer doesn't have to understand physical security if he's
> willing to merge the patch. ;)

Hi Bill,

yes, GPG support is exactly what I'm looking for :)

@Bill: can you provide a link to the upstream discussion/the feature request?

@Daniel: I think I was just reading the second link in comment#66.

Hi,

just a short update to anyone who is still watching this:

I just applied the new kernel and systemd updates. My gpged keyfile is working again by adding crypt-gpg module to dracut and omitting systemd!

Package versions are: kernel.x86_64 4.1.3-201.fc22 and systemd.x86_64 219-20.fc22.

I'd like to note that omitting systemd from dracut is still necessary to use rd.luks.key in in Fedora 25.

Is systemd tracking this issue in any way besides that mail thread?

This BZ is marked as 'closed upstream' yet still apparently is an issue as of F25.

Is there a newer BZ for this, or does the 'closed upstream' tag mean 'nothing more is going to be done about this'?

Thanks

I imagined it meant it was upstream's responsibility to fix.

While it still appears to be systemd that needs to implement rd.luks.key for keyfiles, dracut has an open bug for this issue: https://github.com/dracutdevs/dracut/issues/147

The patches to systemd are not applied. But still individual the systemd unit/mount files can be used to achieve key on external device.

Hi all,

is there any working solution to unlock a system from file key (USB stick, for example)?

I tried everything mentioned here, but it did not work.

Any suggestions?

Thanks,

bye,

pg

(In reply to Piergiorgio Sartor from comment #76)
> Hi all,
> 
> is there any working solution to unlock a system from file key (USB stick,
> for example)?
> 
> I tried everything mentioned here, but it did not work.
> 
> Any suggestions?
> 
> Thanks,
> 
> bye,
> 
> pg

What exactly have you tried? Any error? Using a gpged keyfile definitely works. However you need a workaround and might need to play with the kernel parameters.

Check comment #1. Also add add_dracutmodules+="crypt-gpg" to the config as mentioned in comment #56.

Also see comment #56 for kernel parameters. Add the parameters to /etc/default/grub using GRUB_CMDLINE_LINUX="<parameters>" and rebuild grub running 'grub2-mkconfig -o /boot/grub2/grub.cfg'. rd.luks.key contains your gpged keyfile and the UUID of the device the file is located (for example USB stick). AFAIR you will also need rd.luks.uuid, which is the luks device you want to unlock.

(In reply to Piergiorgio Sartor from comment #76)
> Hi all,
> 
> is there any working solution to unlock a system from file key (USB stick,
> for example)?
> 
> I tried everything mentioned here, but it did not work.
> 
> Any suggestions?
> 
> Thanks,
> 
> bye,
> 
> pg

To date, I am omitting systemd from my initrd in order to use the dracut scripts for this, instead.

$ cat /etc/dracut.conf.d/crypt-keydev-fix.conf
omit_dracutmodules+="systemd systemd-initrd dracut-systemd"

Rebuild all initrds with the new configuration using with `sudo dracut --regenerate-all --force`

Then make sure your cmdline contains:
rd.luks.key=/${key_file}:UUID=${key_device_uuid}:UUID=${luks_device_uuid}

(In reply to Daniel Laczi from comment #77)
[...]
> What exactly have you tried? Any error? Using a gpged keyfile definitely

If I got it correctly, gpg-ed keyfile requires a
password, which I do not want.
I want to have an encrypted system, which can be unlock by password *or* by keyfile on USB stick (like a car / home key).

That's it, and that does not seem to work.

> works. However you need a workaround and might need to play with the kernel
> parameters.

Which leads to the second issue. There is no *clear* or *official* setup for that.
IMHO, once the rd.luks.key parameter is given, it should work, without playing with other things.

Anyway thanks,

bye,

pg

(In reply to Kyle Marek from comment #78)
[...]
> To date, I am omitting systemd from my initrd in order to use the dracut
> scripts for this, instead.

I think I tried this, but it did not work.

Furthermore, what are the consequences of omitting systemd from initrd?
I guess if systemd is not relevant to initrd, then why add it in the first place?

This is an other issue I've with this.
It is mentioned to omit systemd, but it is never clarified what are the drawbacks.

> $ cat /etc/dracut.conf.d/crypt-keydev-fix.conf
> omit_dracutmodules+="systemd systemd-initrd dracut-systemd"
> 
> Rebuild all initrds with the new configuration using with `sudo dracut
> --regenerate-all --force`
> 
> Then make sure your cmdline contains:
> rd.luks.key=/${key_file}:UUID=${key_device_uuid}:UUID=${luks_device_uuid}

I'll try again, maybe something was wrong in this syntax.

Thanks,

bye,

pg

(In reply to Piergiorgio Sartor from comment #76)
If you want to keep systemd during startup and create a number of files I updated the forum with some solution:
https://forums.fedoraforum.org/showpost.php?p=1797174&postcount=46

(In reply to Piergiorgio Sartor from comment #80)
> (In reply to Kyle Marek from comment #78)
> [...]
> > To date, I am omitting systemd from my initrd in order to use the dracut
> > scripts for this, instead.
> 
> I think I tried this, but it did not work.

Well, from your other comments, it sounds like you're trying to decrypt with a GPG-encrypted file. As you pointed out, this requires a password to decrypt, defeating the purpose. GPG-encrypting the key is *optional*. Remember that there is no real distinction between the contents of a key file and what you type on decryption prompt. You can, in fact, decrypt with a file containing nothing more than the exact password you would type if you were to decrypt without a key file.

Personally, to make a key file "revoke"-able, I use LUKS's multiple key slots to generate a random key, and put that in the key-file instead of what I have to memorize to type. This way, if I lose my key device, I don't have to memorize a new password in addition to changing the key I lost.

Steps to do this include:
# Mount file system being used to decrypt
sudo mount ${key_device} /mnt

# Write random 256 bytes to a key file
head /dev/urandom -c 256 | sudo tee /mnt/luks-${luks_device_uuid}.key > /dev/null

# Add key file as acceptable key *in addition* to your existing passphrase
# (will prompt for existing key)
sudo cryptsetup luksAddKey /dev/disk/by-uuid/${luks_device_uuid} /mnt/luks-${luks_device_uuid}.key

> Furthermore, what are the consequences of omitting systemd from initrd?
> I guess if systemd is not relevant to initrd, then why add it in the first
> place?
>
> This is an other issue I've with this.
> It is mentioned to omit systemd, but it is never clarified what are the
> drawbacks.

It isn't simply that systemd is irrelevant; systemd provides a lot of benefits, but is being used *instead of* the scripts that used to be used, in order to re-implement the features provided by those scripts (hence the current UPSTREAM status of the bug). systemd and the dracut scripts accomplish the same things, just in different ways.

The reason why systemd was brought into the initrd, as far as I understand, is because it allows for a better event-driven architecture which gives developers more flexibility in addition to speeding up the boot process and eliminating a lot of the CPU-usage of script interpretation. In addition, systemd's integration with other projects like udev brings the abilities of these projects to initrd services automatically.

An example of a drawback to not using systemd in the initrd is using the "old" dracut script for key file searches. The old script is 10 iterations of searching for your block device, separated by 1 second pauses. If it takes longer than 10 seconds for your block device to show up (which is unlikely), I believe you will be prompted for the password as a fallback (which works in your favor, I guess). systemd would probably wait for a trigger from block device creation instead of constantly surveying the available block devices, and support an arbitrary timeout.
 
> > $ cat /etc/dracut.conf.d/crypt-keydev-fix.conf
> > omit_dracutmodules+="systemd systemd-initrd dracut-systemd"
> > 
> > Rebuild all initrds with the new configuration using with `sudo dracut
> > --regenerate-all --force`
> > 
> > Then make sure your cmdline contains:
> > rd.luks.key=/${key_file}:UUID=${key_device_uuid}:UUID=${luks_device_uuid}
> 
> I'll try again, maybe something was wrong in this syntax.

Remember to reconsider what's actually in the key file. While there is support for decrypting keys encrypted with GPG, what you probably want is a plain key stored in a file.

> Thanks,
> 
> bye,
> 
> pg

(In reply to Kyle Marek from comment #82)
[...]
> Well, from your other comments, it sounds like you're trying to decrypt with
> a GPG-encrypted file. As you pointed out, this requires a password to
> decrypt, defeating the purpose. GPG-encrypting the key is *optional*.

No, I do not use gpg, I just put the plain keyfile into some storage.
For testing, this was even in the /boot partition, at a certain point.

[...]
> Personally, to make a key file "revoke"-able, I use LUKS's multiple key
> slots to generate a random key, and put that in the key-file instead of what
> I have to memorize to type. This way, if I lose my key device, I don't have
> to memorize a new password in addition to changing the key I lost.

The current requirement is to be able to boot, using full disk encryption (except /boot, of course), using an external USB device (key) *or* password from console.
The problem is that the console is far away, the disk has to be encrypted, merely for disposal purposes.

[...]
> It isn't simply that systemd is irrelevant; systemd provides a lot of
> benefits, but is being used *instead of* the scripts that used to be used,
> in order to re-implement the features provided by those scripts (hence the
> current UPSTREAM status of the bug). systemd and the dracut scripts
> accomplish the same things, just in different ways.

So, if I understand this correctly, there is no _standard_ solution, currently.
Either we sabotage the system by removing systemd from initrd or we cannot have the unlock key on some storage.

[...]
> Remember to reconsider what's actually in the key file. While there is
> support for decrypting keys encrypted with GPG, what you probably want is a
> plain key stored in a file.

That's exactly what I want, what I tested and it did not work...

bye,

pg

(In reply to prudy from comment #81)
> (In reply to Piergiorgio Sartor from comment #76)
> If you want to keep systemd during startup and create a number of files I
> updated the forum with some solution:
> https://forums.fedoraforum.org/showpost.php?p=1797174&postcount=46

Thanks for the link.

I had a look, but it seems to me a too custom solution.

I would prefer more off-the-shelf ones.

Anyway thanks again,

bye,

pg

(In reply to Piergiorgio Sartor from comment #83)
> (In reply to Kyle Marek from comment #82)
> [...]
> > Well, from your other comments, it sounds like you're trying to decrypt with
> > a GPG-encrypted file. As you pointed out, this requires a password to
> > decrypt, defeating the purpose. GPG-encrypting the key is *optional*.
> 
> No, I do not use gpg, I just put the plain keyfile into some storage.
> For testing, this was even in the /boot partition, at a certain point.

This is good.

> [...]
> > Personally, to make a key file "revoke"-able, I use LUKS's multiple key
> > slots to generate a random key, and put that in the key-file instead of what
> > I have to memorize to type. This way, if I lose my key device, I don't have
> > to memorize a new password in addition to changing the key I lost.
> 
> The current requirement is to be able to boot, using full disk encryption
> (except /boot, of course), using an external USB device (key) *or* password
> from console.
> The problem is that the console is far away, the disk has to be encrypted,
> merely for disposal purposes.

Similar situation here, except I have it working on five machines. However, they were all initially Fedora 25. The significance of this will be discussed later.

> [...]
> > It isn't simply that systemd is irrelevant; systemd provides a lot of
> > benefits, but is being used *instead of* the scripts that used to be used,
> > in order to re-implement the features provided by those scripts (hence the
> > current UPSTREAM status of the bug). systemd and the dracut scripts
> > accomplish the same things, just in different ways.
> 
> So, if I understand this correctly, there is no _standard_ solution,
> currently.
> Either we sabotage the system by removing systemd from initrd or we cannot
> have the unlock key on some storage.

Almost correct. There is no "standard" solution, as it is your initrd's responsibility/design choice.

You're not exactly sabotaging your initrd by removing systemd. They were initially designed to be agnostic of the init you use, by using *whatever means* necessary to mount your root partition, and exec PID 1 to /sbin/init (systemd in your case). Executing systemd from the initrd is just a convenience from an initrd developer point of view.

Remember that all of these things (the non-systemd scripts) needed to work before systemd existed. They should still work.

> [...]
> > Remember to reconsider what's actually in the key file. While there is
> > support for decrypting keys encrypted with GPG, what you probably want is a
> > plain key stored in a file.
> 
> That's exactly what I want, what I tested and it did not work...

In order to identify any missing steps, I started fresh in a VM in order to produce a list of every action taken in order to accomplish this, and then I tried my list of actions again on another clean VM.

While I was doing this, I discovered a potential issue. `dracut --force --regenerate-all` does not actually put the initrds in the right place in Fedora 26. I have filed a bug on this. See: https://bugzilla.redhat.com/show_bug.cgi?id=1509599

In addition, it was my own choice to format my flash drives with FAT32. By default, dracut generates "host-only" images, meaning they include only the modules necessary to boot *your* system on *your current* hardware. In my case, it seems to be forgetting the vfat module. While you can include specific missing modules, it might be easier and better for future hardware changes to generate a complete initrd.

Here is my complete process to go from a minimal Fedora 26 install to automatically decrypting with a key file, including a workaround for initrd regenration and initrd modules. I worked in shell variables and non-interactive commands for easy copy-paste:

1. Install Fedora 26 "Minimal install" from network installer disk <https://download.fedoraproject.org/pub/fedora/linux/releases/26/Everything/x86_64/iso/Fedora-Everything-netinst-x86_64-26-1.5.iso>, using automatic partitioning and enabling encryption (automatically installs onto LVM on LUKS, defaulting to prompting for decryption).

2. Install necessary packages:
   - dosfstools for mkfs.vfat

3. Plug in flash drive, monitor what block device it is (I watch output of dmesg -w). In my case it was /dev/vdb (a virtio device)
   $ key_device="/dev/vdb"

4. Determine your LUKS device UUID. In my case, my LUKS block device (not the decrypting one) is /dev/vda2:
   $ luks_device="/dev/vda2"
   $ luks_device_uuid="$(sudo blkid -o value -s UUID "$luks_device")"

5. Format and mount flash drive:
   $ sudo mkfs.vfat -F32 -I "$key_device"
   $ sudo mkdir /root/mnt # mounting here for root-only readability
   $ sudo mount "$key_device" /root/mnt

6. Determine your key device's UUID:
   $ key_device_uuid="$(sudo blkid -o value -s UUID "$key_device")"

7. Create key file:
   $ head /dev/urandom -c 256 | sudo tee /root/mnt/luks-${luks_device_uuid}.key > /dev/null

8. Configure LUKS to accept the key file as a key:
   $ sudo cryptsetup luksAddKey /dev/disk/by-uuid/${luks_device_uuid} /root/mnt/luks-${luks_device_uuid}.key

9.1. You can verify by trying to open your LUKS volume a second time:
     $ sudo cryptsetup open --type luks --readonly --key-file /root/mnt/luks-${luks_device_uuid}.key /dev/disk/by-uuid/${luks_device_uuid} tmp

     Note that the following message indicates success in using the key file: Cannot use device /dev/disk/by-uuid/3765552b-fddf-4b37-839c-942cc0059c12 which is in use (already mapped or mounted).

     Opening with an invalid keyfile (/dev/null, for example) results in no message, but a return value of 1 (`echo $?` to see return value).

10. Unmount flash drive
    $ sync
    $ sudo umount /root/mnt
    $ sudo rmdir /root/mnt

11. Configure dracut to omit systemd modules, due to systemd *not yet* implementing rd.luks.key:
    $ echo 'omit_dracutmodules+="systemd systemd-initrd dracut-systemd"' | sudo tee /etc/dracut.conf.d/crypt-keydev-fix.conf > /dev/null

12. Configure dracut to generate a complete generic initrd:
    $ echo 'hostonly="no"' | sudo tee /etc/dracut.conf.d/no-hostonly.conf > /dev/null

13. Regenerate all initrds using the new configuration:
    $ for kernel in /boot/vmlinuz-*; do kver="$(echo "$kernel" | sed -ne 's:^/boot/vmlinuz-\(.*\)$:\1:p')"; sudo dracut --force /boot/initramfs-"$kver".img "$kver"; done

14. Put the *output* of the following command onto your kernel cmdline:
    $ echo "rd.luks.key=/luks-${luks_device_uuid}.key:UUID=${key_device_uuid}:UUID=${luks_device_uuid}"

14.1. For GRUB2 cmdline configuration:
      In /etc/default/grub:
        GRUB_CMDLINE_LINUX="... paste here"
      Regenerate GRUB2 configuration
        $ for file in /etc/grub2.cfg /etc/grub2-efi.cfg; do test -L "$file" && sudo grub2-mkconfig -o "$file"; done

15. Reboot to test
   
> bye,
> 
> pg

We have a new problem. As for Fedora 28, removing systemd invokes warnings about systemd-initrd and other systemd modules in dracut. As much as I'd like to follow the simpler solution of not using systemd in initrd, I'm not sure how to proceed in Fedora 28 since the init process itself seems to be dependent on systemd. There seems to be no workaround other than Prudy's option. Can I reboot properly with the systemd-initrd errors reported? Or do I need to follow Prudy's answer?

Can I simply use the following?


omit_dracutmodules+=" systemd "
add_drivers+=" vfat lvm crypt "

(In reply to shamim.islam from comment #86)
> We have a new problem. As for Fedora 28, removing systemd invokes warnings
> about systemd-initrd and other systemd modules in dracut. As much as I'd
> like to follow the simpler solution of not using systemd in initrd, I'm not
> sure how to proceed in Fedora 28 since the init process itself seems to be
> dependent on systemd. There seems to be no workaround other than Prudy's
> option. Can I reboot properly with the systemd-initrd errors reported? Or do
> I need to follow Prudy's answer?
> 
> Can I simply use the following?
> 
> 
> omit_dracutmodules+=" systemd "
> add_drivers+=" vfat lvm crypt "

Nothing's new, here. Change to:

omit_dracutmodules+="systemd systemd-initrd dracut-systemd"
add_drivers+="vfat"

Was tested with success on a F28 VM.

(In reply to Kyle Marek from comment #87)
> (In reply to shamim.islam from comment #86)
> > We have a new problem. As for Fedora 28, removing systemd invokes warnings
> > about systemd-initrd and other systemd modules in dracut. As much as I'd
> > like to follow the simpler solution of not using systemd in initrd, I'm not
> > sure how to proceed in Fedora 28 since the init process itself seems to be
> > dependent on systemd. There seems to be no workaround other than Prudy's
> > option. Can I reboot properly with the systemd-initrd errors reported? Or do
> > I need to follow Prudy's answer?
> > 
> > Can I simply use the following?
> > 
> > 
> > omit_dracutmodules+=" systemd "
> > add_drivers+=" vfat lvm crypt "
> 
> Nothing's new, here. Change to:
> 
> omit_dracutmodules+="systemd systemd-initrd dracut-systemd"
> add_drivers+="vfat"
> 
> Was tested with success on a F28 VM.

Though, do use the spaces in the +=. I just noticed...

I came across this bug while attempting to use rd.luks.key with a rescue image (which had the systemd module installed).  Pointers in dracut.cmdline(7) man page led me here...

References above to the systemd source-code finally led me to systemd-cryptsetup-generator(8), which documents rd.luks.key with an external key-file as something like 

  rd.luks.key=<uuid>=<key-path>:<key-dev>

Their example:
  rd.luks.uuid=b40f1abf-2a53-400a-889a-2eccc27eaa40
  rd.luks.key=b40f1abf-2a53-400a-889a-2eccc27eaa40=/keyfile:LABEL=keydev

With the caveat:
 .. will attempt to mount file system residing
    on the block device with label "keydev". This syntax is for now
    only supported on a per-device basis, i.e. you have to specify LUKS
    device UUID.

This syntax works with the generic rescue image...and allows the systemd module to correctly handle a key-file on the targeted device.

Note however, that the rd.luks.key syntax differs from the one documented in dracut.cmdline(7) 

   rd.luks.key=<keypath>[:<keydev>[:<luksdev>]]
     - (which I tried and failed to get working with the rescue image)

Hope this helps anyone else who finds their way to this bug :)

I like do drop a quick note as well: it might be helpful to switch to YubiKey on clients