Bug ID | 1231325 |
---|---|
Summary | dracut-pcr-signature races with udev for ESP symlinks |
Classification | openSUSE |
Product | openSUSE Tumbleweed |
Version | Current |
Hardware | Other |
OS | Other |
Status | NEW |
Severity | Normal |
Priority | P5 - None |
Component | Bootloader |
Assignee | screening-team-bugs@suse.de |
Reporter | arvidjaar@gmail.com |
QA Contact | qa-bugs@suse.de |
CC | aplanas@suse.com |
Target Milestone | --- |
Found By | --- |
Blocker | --- |
My FDE VM systematically fails to automatically unlock root the first time after host has been restarted. I compared PCR values and TPM log between bad and good cases and no changes are present - the values are identical. Then I remembered that not so long ago the same VM failed to boot, with log in https://bugzilla.suse.com/attachment.cgi?id=873748. Which shows [ 23.780502] localhost pcr-signature.sh[417]: mount: /tmp/pcr-signature: wrong fs type, bad option, bad superblock on /dev/disk/by-partuuid/4d904b6d-6495-4891-8481-fe0fbdacec21, missing codepage or helper program, or other error. ... [ 24.814025] localhost systemd[1]: systemd-cryptsetup@cr_root.service: Control process exited, code=exited, status=1/FAILURE and then I looked into dracut-pcr-oracle changelog which says commit ae07fc611de1884207614125533482477e9e2f8b Author: Alberto Planas <aplanas@suse.com> Date: Tue Apr 16 19:19:21 2024 +0200 Do not hard fail when error in mount which explains why my VM stopped to fail, but continued to require manual unlocking. pcr-signature.sh is using DEV="/dev/disk/by-partuuid/${ESP_UUID}" where ${ESP_UUID} is taken from EFI NVRAM, but it never actually checks that it exists or waits for this link to appear. Which pretty much explains my failures. pcr-signature.sh must really be split into two parts 1. systemd generator that determines device and adds Requires and After for this device to (root device) systemd-cryptsetup@.service. 2. The script that mounts this device. Actually, if we go generator route we could just as well create the proper mount unit for the LoaderDevice and simply add the proper dependencies. Because currently there is obvious race condition between multiple encrypted device, each attempting to mount and then unmount LoaderDevice. Having the proper mount unit will solve this as well. Hmm ... I expected that it would race with /boot/efi mount on Tumbleweed, but I was surprised that with systemd-boot ESP is not mounted in initrd. I am not sure why, but this may be potential source of problems with grub2 BLS module. Because we cannot mount the same FAT filesystem twice.