I've already posted the issue in a mailing list thread: https://lists.fedoraproject.org/archives/list/test@lists.fedoraproject.org/thread/FBSF7UUMIG4WH7FYZT4QWYIOK7R4MNM3/ There hasn't been an answer thus far, so I'm filing it as a bug, which it most likely is. Description of problem: On every single systemd unit operation (e.g. systemctl restart cups or the like), the console is spammed by password requests for unlocking my encrypted root volume. The root volume is of course unlocked already, or else the system wouldn't have booted. Also, systemctl status shows "starting", because it's convinced that somehow the already mounted root volume still has to be unlocked. Attempts to give it the password using systemd-tty-ask-password-agent end up with a failure of the auto-generated systemd unit, because re-opening of already active LUKS volumes yields "Device or resource busy". Additionally, dracut fails to recognize that it needs the crypt module in the initial ramdisk and the crypt module must be added manually (add_dracutmodules+="crypt"). Otherwise it won't unlock the root volume and boot. I suspect there could be a causal relation between this glitch and the stuff above. More details are in the mailing list post linked above. Version-Release number of selected component (if applicable): 4.11.0-2.fc26.x86_64 Fedora 26 with rpmfusion and updates, but without updates-testing. How reproducible: Always. Steps to Reproduce: 1. Install Fedora 26 with a Btrfs on LVM on LUKS on LVM layout, as described here: https://bugzilla.redhat.com/show_bug.cgi?id=1297188#c2 2. Add add_dracutmodules+="crypt" to /etc/dracut.conf, so that it boots at all. 3. On a running system, try to restart any service (e.g. cups). Actual results: systemctl status keeps showing "starting" and thinks that the mounted LUKS root volume is in fact not ready. You get a useless password prompt on every single systemctl operation that touches units. When you use systemd-tty-ask-password-agent and input the password, the attempt to reopen the LUKS volume (of course) fails, so does the auto-generated sytemd unit and systemctl status shows "degraded" Expected results: No such glitches. When I have a root LUKS partition handled by dracut, systemd should know that it doesn't have to be activated once more. Also, when dracut generates initramdisks, it should automatically add the crypt module, because it can just inspect the root filesystem and find out that it's actually on LUKS. This worked in Fedora 23 and 24 and stopped working after a jump to 26.
Created attachment 1284711 [details] /etc/default/grub
Created attachment 1284712 [details] /etc/crypttab
This message is a reminder that Fedora 26 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 26. 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 '26'. 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 26 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.
Fedora 26 changed to end-of-life (EOL) status on 2018-05-29. Fedora 26 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.