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.


You are receiving this mail because: