Bug 1644876
| Summary: | Automatic unlock of LUKS device with clevis fails on boot | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Martin Welk <mwelk> |
| Component: | clevis | Assignee: | Nathaniel McCallum <npmccallum> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | medium | ||
| Version: | 29 | CC: | aannoaanno, arif, fmartine, npmccallum, pbrobinson, tmichett |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | clevis-11-2.fc29 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2018-11-18 03:55:36 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
These issues were already reported in upstream clevis: https://github.com/latchset/clevis/issues/73 https://github.com/latchset/clevis/issues/74 A pull-request was not proposed though, so I did it now: https://github.com/latchset/clevis/pull/81 I'll coordinate with Nathaniel to get these fixes into Fedora 29. I have this problem too, although I never configured Clevis to mess with the root disk. I have since uninstalled Clevis as it was just for a demo and the system still will not boot up ... complaining about: /var/log/messages: Nov 7 09:15:51 p50 dracut-initqueue[509]: Failed to start systemd-cryptsetup: Unit systemd-cryptsetup not found. Nov 7 09:16:59 p50 systemd[1]: systemd-cryptsetup@luks\x2d810cedba\x2d4eab\x2d42d6\x2da266\x2d9da16726319d.service: Failed with result 'exit-code'. /var/log/boot: [ 3.511920] dracut-initqueue[504]: Failed to start systemd-cryptsetup: Unit systemd-cryptsetup not found. It prompts me to unlock with the password like always, but freezes at reach target stage. The rescue boots up fine. As a work-around, I've found that when plugged into a network connection and the NIC is *live* the system will boot into FC29. At this point, Clevis/Tang are not installed on the system, however, it is still attempting to use Clevis to decrypt the LUKS volumes even though none of them are setup with Clevis and the /etc/crypttab doesn't have any of the volumes referenced which would have been LUKS with Clevis. --- Travis (In reply to Travis Michette from comment #2) > > As a work-around, I've found that when plugged into a network connection and > the NIC is *live* the system will boot into FC29. > This seems to be bug #1574413. > At this point, Clevis/Tang are not installed on the system, however, it is > still attempting to use Clevis to decrypt the LUKS volumes even though none > of them are setup with Clevis and the /etc/crypttab doesn't have any of the > volumes referenced which would have been LUKS with Clevis. > > --- Travis Did you re-generate your initramfs after uninstalling clevis? *** Bug 1634063 has been marked as a duplicate of this bug. *** clevis-11-2.fc29 has been submitted as an update to Fedora 29. https://bodhi.fedoraproject.org/updates/FEDORA-2018-cf82a4a9d9 (In reply to Javier Martinez Canillas from comment #3) > (In reply to Travis Michette from comment #2) > > > > As a work-around, I've found that when plugged into a network connection and > > the NIC is *live* the system will boot into FC29. > > > > This seems to be bug #1574413. > This is a very close description to the bug listed above. However, I never configured Clevis after it was installed. I mainly used it to build some documentation for a demo so I didn't need to fire up my VM. So I only used man pages and some of the features for the CLI to copy/paste output. At no point in time were Clevis or Tang even running on this laptop. I have my entire disk encrypted, and the system *did* prompt me for a password to unlock it. [root@p50 ~]# cat /etc/crypttab luks-810cedba-4eab-42d6-a266-9da16726319d UUID=810cedba-4eab-42d6-a266-9da16726319d none discard VM_Crypt UUID=f9ea1ae5-c917-45c7-aefe-936467371415 /root/VM_Keyfile luks VM_Crypt2 UUID=d6071dcd-63af-4b3a-89a7-a9728235030c /root/VM_Keyfile2 luks [root@p50 ~]# cat /etc/fstab # # /etc/fstab # Created by anaconda on Mon Mar 26 16:54:34 2018 # # Accessible filesystems, by reference, are maintained under '/dev/disk' # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info # /dev/mapper/fedora_p50-root / xfs defaults,x-systemd.device-timeout=0 0 0 UUID=a2dc36b0-eb8f-4261-9fa0-3e6d833c7c5a /boot ext4 defaults 1 2 /dev/mapper/fedora_p50-home /home xfs defaults,x-systemd.device-timeout=0 0 0 /dev/mapper/fedora_p50-swap swap swap defaults,x-systemd.device-timeout=0 0 0 /dev/mapper/VM_Crypt /VirtualMachines xfs noatime,nodiratime 0 0 /dev/mapper/VM_Crypt2 /VirtualMachines2 xfs noatime,nodiratime 0 0 /dev/nvme0n1p3 /VirtualMachines_Fast xfs noatime,nodiratime 0 0 > > At this point, Clevis/Tang are not installed on the system, however, it is > > still attempting to use Clevis to decrypt the LUKS volumes even though none > > of them are setup with Clevis and the /etc/crypttab doesn't have any of the > > volumes referenced which would have been LUKS with Clevis. > > > > --- Travis > > Did you re-generate your initramfs after uninstalling clevis? I did not regenerate initramfs after uninstalling clevis as I didn't generate the initramfs after installing Clevis. I saw no point in messing with the initramfs as I wasn't actually using Clevis. (In reply to Travis Michette from comment #6) > (In reply to Javier Martinez Canillas from comment #3) > > (In reply to Travis Michette from comment #2) > > > > > > As a work-around, I've found that when plugged into a network connection and > > > the NIC is *live* the system will boot into FC29. > > > > > > > This seems to be bug #1574413. > > > > This is a very close description to the bug listed above. However, I never > configured Clevis after it was installed. I mainly used it to build some > documentation for a demo so I didn't need to fire up my VM. So I only used > man pages and some of the features for the CLI to copy/paste output. At no > point in time were Clevis or Tang even running on this laptop. > > I have my entire disk encrypted, and the system *did* prompt me for a > password to unlock it. > > [root@p50 ~]# cat /etc/crypttab > luks-810cedba-4eab-42d6-a266-9da16726319d > UUID=810cedba-4eab-42d6-a266-9da16726319d none discard > VM_Crypt UUID=f9ea1ae5-c917-45c7-aefe-936467371415 /root/VM_Keyfile luks > VM_Crypt2 UUID=d6071dcd-63af-4b3a-89a7-a9728235030c /root/VM_Keyfile2 > luks > > [root@p50 ~]# cat /etc/fstab > > # > # /etc/fstab > # Created by anaconda on Mon Mar 26 16:54:34 2018 > # > # Accessible filesystems, by reference, are maintained under '/dev/disk' > # See man pages fstab(5), findfs(8), mount(8) and/or blkid(8) for more info > # > /dev/mapper/fedora_p50-root / xfs > defaults,x-systemd.device-timeout=0 0 0 > UUID=a2dc36b0-eb8f-4261-9fa0-3e6d833c7c5a /boot ext4 defaults > 1 2 > /dev/mapper/fedora_p50-home /home xfs > defaults,x-systemd.device-timeout=0 0 0 > /dev/mapper/fedora_p50-swap swap swap > defaults,x-systemd.device-timeout=0 0 0 > /dev/mapper/VM_Crypt /VirtualMachines xfs noatime,nodiratime > 0 0 > /dev/mapper/VM_Crypt2 /VirtualMachines2 xfs noatime,nodiratime > 0 0 > /dev/nvme0n1p3 /VirtualMachines_Fast xfs noatime,nodiratime 0 > 0 > > > > > > At this point, Clevis/Tang are not installed on the system, however, it is > > > still attempting to use Clevis to decrypt the LUKS volumes even though none > > > of them are setup with Clevis and the /etc/crypttab doesn't have any of the > > > volumes referenced which would have been LUKS with Clevis. > > > > > > --- Travis > > > > Did you re-generate your initramfs after uninstalling clevis? > > I did not regenerate initramfs after uninstalling clevis as I didn't > generate the initramfs after installing Clevis. I saw no point in messing > with the initramfs as I wasn't actually using Clevis. To note, the crypttab file and the fstab file are not waiting for network, and were never configured to, so not sure if the race condition would apply. clevis-11-2.fc29 has been pushed to the Fedora 29 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-2018-cf82a4a9d9 clevis-11-2.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: I had a running server with Fedora 28. I configured clevis to unlock an encrypted root disk via network, tested it. Afterwards, I ran an upgrade to Fedora 29. Automatic unlock of the disk didn't work anymore after the upgrade BTW, thank you for publishing F29 on my birthday, nice present. And, again, so far two flawless upgrades, one mostly flawless :) Version-Release number of selected component (if applicable): 29, "as of today" ;) How reproducible: Configure clevis to unlock a LUKS device Steps to Reproduce: 1. Reboot server, wait for the automatic unlock 2. Rebuild initial RAM disk using dracut -f Actual results: 1. Automatic unlock fails with an error that clevis-decrypt-http and cryptsetup were not found. 2. dracut -f complains dracut-install: ERROR: installing 'clevis-decrypt-http' Expected results: 1. System starts with automatic unlock of LUKS root disk 2. dracut runs without errors Additional info: I was able to fix it in /usr/lib/dracut/modules.d/60clevis/module-setup.sh: in the install shell function, add cryptsetup, remove clevis-decrypt-http. Here's the place: inst_hook initqueue/online 60 "$moddir/clevis-hook.sh" inst_hook initqueue/settled 60 "$moddir/clevis-hook.sh" inst_multiple /etc/services \ cryptsetup \ clevis-decrypt-tang \ clevis-decrypt-sss \ /usr/libexec/clevis-luks-askpass \ clevis-decrypt \ luksmeta \ clevis \ mktemp \ curl \ jose \ nc for cmd in clevis-decrypt-tpm2 \