Description of problem: Boot fails and drops to emergency mode if the file specified for an encrypted volume cannot be read. This is a change in behavior from Fedora 29 (although booting the F29 kernel in F30 userspace works as expected). The relevant message appears to be: [ 6.343786] fpgm systemd-cryptsetup[654]: Failed to open key file. [ 6.343809] fpgm systemd-cryptsetup[654]: Failed to activate with key file '/boot/luks_keys': Invalid argument When I change the field to `-` in order to prompt for a password and then rebuild the initramfs, it boots as expected. I think this is fixed by upstream PR 11805 (https://github.com/systemd/systemd/pull/11805), which is included in version 242. Version-Release number of selected component (if applicable): systemd-241-8.git9ef65cb.fc30.x86_64 I'm not sure if the failure to open the file is new, or if it has never worked. I didn't see any related error messages on a successful boot with that key file still in place.
I finally discovered this over the weekend after much experimentation and gnashing of teeth. I could still boot on the Fedora 29 kernel, but all of the Fedora 30 kernels failed to boot with the systemd-cryptsetup error "Failed to activate with key file ... Invalid argument". I have two luks encrypted devices defined in /etc/crypttab, both were setup by gnome disks with plain-text passwords stored in /etc/luks-keys. The root filesystem containing /etc is encrypted on disk UUID=ea56bffa-c0f1-49df-a68c-c7370cf7d146, so I changed its password reference in crypttab to "none" and it now boots after prompting for that password. luks-ea56bffa-c0f1-49df-a68c-c7370cf7d146 UUID=ea56bffa-c0f1-49df-a68c-c7370cf7d146 none luks luks-8d4ee900-a98f-47a3-84f8-e13906caac91 UUID=8d4ee900-a98f-47a3-84f8-e13906caac91 /etc/luks-keys/luks-8d4ee900-a98f-47a3-84f8-e13906caac91 luks I don't know if it was necessary, but I also rebuilt the initramfs file, cd /boot dracut -f initramfs-5.0.11-300.fc30.x86_64.img 5.0.11-300.fc30.x86_64 and reinstalled grub2 efi, grub2-mkconfig -o /boot/efi/EFI/fedora/grub.cfg
I experienced this same issue. After an upgrade to Fedora 30 I was unable to boot using the Fedora 30 kernels. The Fedora 29 kernel would still boot. The steps outlined in Comment #1 fixed the issue for me.
Please set status==POST if there's an upstream patch (or even PR). This makes it easier to see stuff to backport in the sea of open tickets.
FEDORA-2020-f8e267d6d0 has been submitted as an update to Fedora 30. https://bodhi.fedoraproject.org/updates/FEDORA-2020-f8e267d6d0
systemd-241-14.git18dd3fb.fc30 has been pushed to the Fedora 30 testing repository. If problems still persist, please make note of it in this bug report. See https://fedoraproject.org/wiki/QA:Updates_Testing for instructions on how to install test updates. You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-f8e267d6d0
systemd-241-14.git18dd3fb.fc30 has been pushed to the Fedora 30 stable repository. If problems still persist, please make note of it in this bug report.