I had the very same problem, solved the same way with the addition of disabling line in /etc/vconsole.conf, because something was broken also there.

I think it is a critical bug, since it renders the system unusable, one cannot log in.

After trying solution of echo 'omit_dracutmodules+=" pcr-signature "' >  /etc/dracut.conf.d/disable-pcr-signature.conf
and dracut -f --regenerate-all using a Tumbleweed live CD I still had the issue.
Below are some relevant lines from the rdsosreport.txt
[    2.014938] osuse-king systemd[1]: Found device KINGSTON SFYRS1000G 2.
[    2.015012] osuse-king systemd[1]: Reloading finished in 117 ms.
[    2.018212] osuse-king systemd[1]: Started Show Plymouth Boot Screen.
[    2.018544] osuse-king systemd[1]: Finished Virtual Console Setup.
[    2.025879] osuse-king systemd[1]: Dispatch Password Requests to Console Directory Watch was skipped because of an unmet condition check (ConditionPathExists=!/run/plymouth/pid).
[    2.025948] osuse-king systemd[1]: Started Forward Password Requests to Plymouth Directory Watch.
[    2.025977] osuse-king systemd[1]: Reached target Path Units.
[    2.050180] osuse-king systemd[1]: Starting Cryptography Setup for cr_root...
[    2.054591] osuse-king pcr-signature.sh[680]: /usr/bin/pcr-signature.sh: line 18: mktemp: command not found
[    2.055305] osuse-king systemd[1]: systemd-cryptsetup@cr_root.service: Control process exited, code=exited, status=127/n/a
[    2.055443] osuse-king systemd[1]: systemd-cryptsetup@cr_root.service: Failed with result 'exit-code'.
[    2.055570] osuse-king systemd[1]: Failed to start Cryptography Setup for cr_root.
[    2.055600] osuse-king systemd[1]: Dependency failed for Local Encrypted Volumes.
[    2.055636] osuse-king systemd[1]: cryptsetup.target: Job cryptsetup.target/start failed with result 'dependency'.
[    2.055812] osuse-king systemd[1]: Reached target System Initialization.
[    2.055835] osuse-king systemd[1]: Reached target Basic System.

I had the same issue on fresh install of MicroOS. It seems that the initrd is missing the mktemp util. You can get around it by loging into the recovery shell and running: 

echo "#!/bin/sh" > /usr/bin/mktemp
echo "echo /tmp" >> /usr/bin/mktemp
chmod +x /usr/bin/mktemp
systemctl default

At that point you should be able to boot into the system. Unfortunately you have to do this on every boot until this is fixed

It seems it will be solved in the next release of dracut-pcr-signature:

https://github.com/aplanas/dracut-pcr-signature/issues/2

https://github.com/aplanas/dracut-pcr-signature/commit/f12ad63e3322c8b82f9c27f1dd21f9a84c458cec

It is actually not difficult to include the actual mktemp program into the initrd.

First, chroot into the system from a working liveUSB.

Don't forget to mount /boot and /boot/efi too, otherwise you will not change the boot configuration of the on-disk system but just the in-RAM copy of the liveUSB's boot configuration which is harmless but useless.

Once you have a working chroot, create a new config file in /etc/dracut.conf.d with the following contents...


install_items+=" /usr/bin/mktemp "


...then recreate the initrd with `sudo dracut -f --regenerate-all`.

In my case, my system was also affected by https://bugzilla.opensuse.org/show_bug.cgi?id=1222087 , so I had to address that too. But with both changes applied, the system boots fine again.

(In reply to Hadrien Grasland from comment #5)a working liveUSB.
> Don't forget to mount /boot and /boot/efi too, otherwise you will not change
> the boot configuration of the on-disk system but just the in-RAM copy of the
> liveUSB's boot configuration which is harmless but useless.

Sorry, brain fart. This will obviously just write to a /boot directory in the root partition that is not read because the actual /boot is mounted on top of it. Just as useless, but differently useless.

*** Bug 1222759 has been marked as a duplicate of this bug. ***

@Kroll why did you change as P0? The release should be there:

https://build.opensuse.org/projects/openSUSE:Factory/packages/dracut-pcr-signature/files/dracut-pcr-signature.changes?expand=1

Maybe did you find another issue?

In a private conversation seems that there is not new issue, but I will monitor the bug.

I am also affected by this bug. What exactly do I have to do to mitigate it? The remarks here and in Bug 1222759 leave me in the dark, unfortunately …

dracut-pcr-signatures was updated in Tumbleweed 20240415 and fixed the problem for me - it had impacted me with kernel 6.8.4-rc1-default and 6.8.5-1-default.

For Rainer Klute

I had to create a new initrd, it wasn't updated when the new dracut-pcr-signatures was installed - in my case I did this manually, but it probably should have been done using sdbootutils. I choose manual as I only wanted to change 6.8.5, and wanted to leave the working 6.8.2 untouched. 


dracut --kver 6.8.5-1-default

mv initrd-6.8.5-1-default /boot/efi/opensuse-tumbleweed/6.8.5-1-default/

And then create a new entry to match the new initrd by copying the existing opensuse-tumbleweed-6.8.5-1-default-1.conf and changing the title and initrd lines, or edit the existing entry and just change the initrd line.

Thanks

(In reply to Rainer Klute from comment #10)
> I am also affected by this bug. What exactly do I have to do to mitigate it?
> The remarks here and in Bug 1222759 leave me in the dark, unfortunately …

As commented later the solution is to generate a new initrd that contains mktemp.

There are multiple solutions, but for now a zypper dup will do.

Another one is to do something like https://bugzilla.suse.com/show_bug.cgi?id=1222750#c5 suggest

(In reply to Alberto Planas Dominguez from comment #12)
> As commented later the solution is to generate a new initrd that contains
> mktemp.

I read all the messages but didn’t know how to do that on a system that doesn’t boot. Although I have >30 years of Linux experience, it was still new to me how to get a non-booting system up and running again.

Thanks to your hints, I eventually found my way, was able to decrypt and mount the missing partitions and get my system into a state where I was able to create an initrd. 


> There are multiple solutions, but for now a zypper dup will do.
> 
> Another one is to do something like
> https://bugzilla.suse.com/show_bug.cgi?id=1222750#c5 suggest

Updating the dracut-pcr-signature package was not enough as it did not rebuild the broken initrd files of my installed kernels (yes, they were all affected). I was reluctant to recreate the initrds manually because I am not familiar with initramfs, dracut, and friends. So I triggered this by reinstalling dracut – took some time but went smoothly.

(In reply to Rainer Klute from comment #13)
> (In reply to Alberto Planas Dominguez from comment #12)
> > As commented later the solution is to generate a new initrd that contains
> > mktemp.
> 
> I read all the messages but didn’t know how to do that on a system that
> doesn’t boot. 

Yes of course. The most used mechanism is to boot from USB, or manually mount the rootfs from the initrd and chroot inthere, and later do the zypper dup.

> Updating the dracut-pcr-signature package was not enough as it did not
> rebuild the broken initrd files of my installed kernels (yes, they were all
> affected). 

sdbootutil should do that when an update happens.

> I was reluctant to recreate the initrds manually because I am not
> familiar with initramfs, dracut, and friends. So I triggered this by
> reinstalling dracut – took some time but went smoothly.

That is a smart solution too.

(In reply to Alberto Planas Dominguez from comment #14)
> 
> > Updating the dracut-pcr-signature package was not enough as it did not
> > rebuild the broken initrd files of my installed kernels (yes, they were all
> > affected). 
> 
> sdbootutil should do that when an update happens.
> 

Yes, but the point is - updating dracut-pcr-signature *alone* will not fix this bug without either additional manual steps or coincidence (if some other package triggers initrd rebuild).

(In reply to Andrei Borzenkov from comment #15)
> (In reply to Alberto Planas Dominguez from comment #14)
> > 
> > > Updating the dracut-pcr-signature package was not enough as it did not
> > > rebuild the broken initrd files of my installed kernels (yes, they were all
> > > affected). 
> > 
> > sdbootutil should do that when an update happens.
> > 
> 
> Yes, but the point is - updating dracut-pcr-signature *alone* will not fix
> this bug without either additional manual steps or coincidence (if some
> other package triggers initrd rebuild).

Are you using btrfs with snapshots?  If so sdbootutil should be triggered by snapper once zypper ends the update in Tumbleweed (or at the end of a transaction in MicroOS)

Or maybe the package was installed with rpm?

(In reply to Alberto Planas Dominguez from comment #16)
> sdbootutil should be triggered by
> snapper once zypper ends the update in Tumbleweed

sdbootutil attempts to reuse existing initrd's.

> (or at the end of a
> transaction in MicroOS)
>

MicroOS was not affected as mktemp was installed by disk-encryption-tool which performs encryption on first boot. At least, those images that include this package were not affected (I have one).

(In reply to Andrei Borzenkov from comment #17)

> MicroOS was not affected as mktemp was installed by disk-encryption-tool
> which performs encryption on first boot. At least, those images that include
> this package were not affected (I have one).

Yes, any system with disk-encryption-tool is not affected.  My comment was about sdbootutil. Not generating the initrd seems a different issue.

To be honest this is such a critical bug rendering probably tens of thousands of systems (even much more) unusable, that there should be already a notice at the beginning of opensuse site providing solutions. 
I am aware of the fact that Tumbleweed is for advanced users, but arriving to a system where you do not even have a rescue console and have to play with boot stuff (which is not a frequent knowledge even amongst advanced users) is shocking. Being "closest to bleeding edge Linux" (from website) should not mean bleeding to death.

(In reply to Alberto Planas Dominguez from comment #18)
> My comment was
> about sdbootutil. Not generating the initrd seems a different issue.

I do not see any issue here. sdbootutil tires to reuse existing initrd's. it is by design. It avoids expensive dracut invocation on every snapshot creation. So, you cannot assume that - even with btrfs and snapshots - every "zypper dup" ends up triggering mkinitrd. If packages includes dracut modules, it probably should trigger initrd rebuild explicitly.

(In reply to Gabor Katona from comment #19)
> To be honest this is such a critical bug rendering probably tens of
> thousands of systems (even much more) unusable, that there should be already
> a notice at the beginning of opensuse site providing solutions.

sdbootutil is a tool that only makes sense to have when systemd-boot is used. Most of the installations have GRUB2, so this package should not be present.

I think that an old bug dragged it by accident (I am not sure).

This bug is for dracut-pcr-signature, that is installed by sdbootutil and only makes sense when FDE is active in a new mode that we are working on.  For now this mode is tested and deployed in the MicroOS and Tumbleweed (qcow2) images that were announced wrt FDE in user space (systemd)

We have openQA that tests those images, but as commented here those images has also disk-encryption-tool that already include mktemp in the initrd. So those tests didn't helped here.

Systems that have sdbootutil and dracut-pcr-signature are systems that are using sd-boot, or manually moved to FDE (as described https://en.opensuse.org/Systemd-fde).  We will have openQA tests for those systems once YaST can make such kind of installations.
 
> I am aware of the fact that Tumbleweed is for advanced users, but arriving
> to a system where you do not even have a rescue console and have to play
> with boot stuff (which is not a frequent knowledge even amongst advanced
> users) is shocking. Being "closest to bleeding edge Linux" (from website)
> should not mean bleeding to death.

I agree with the message and we are working on make it true.  But sdbootutil and  dracut-pcr-signature is still a technology under development, only tested in conjunction with others in the context of those MicroOS and Tumbleweed images that were announced.  The fact that this package is in more systems (that I guess are using systemd-boot), imply that was an user decision (that I appreciate a lot) and that there is some risk on using it.  Testing this new tech is helping a lot in improving it, but breakage is expected and knowledge is advisable.

In any case, once this move into the normal installation, more openQA tests will be made and enabled.

(In reply to Andrei Borzenkov from comment #20)

> If packages includes dracut
> modules, it probably should trigger initrd rebuild explicitly.

Yes, I think that this is the real issue.

(In reply to Alberto Planas Dominguez from comment #21)
> The fact that this package is in
> more systems (that I guess are using systemd-boot), imply that was an user
> decision (that I appreciate a lot) and that there is some risk on using it.

I don’t think is was necessarily a user decision. I for one encountered the term “dracut-pcr-signature” in relation with this bug for the very first time and never actively decided to install it.

May I assume that I can savely remove it? Or could a removal result in any unwanted and possibly harmful side-effects?

(In reply to Rainer Klute from comment #23)

> May I assume that I can savely remove it? Or could a removal result in any
> unwanted and possibly harmful side-effects?

Are you using sdbootutil and systemd-boot? If that is the case if you remove it it will be installed again. If you are using GRUB2 but sdbootutil is installed, you can remove sdbootutil and dracut-pcr-signature and will not be installed again.

(In reply to Alberto Planas Dominguez from comment #22)
> (In reply to Andrei Borzenkov from comment #20)
> 
> > If packages includes dracut
> > modules, it probably should trigger initrd rebuild explicitly.
> 
> Yes, I think that this is the real issue.

The posttrans has been added for the usual case. Sadly indeed there is a sdbootutil issue that will not trigger the initrd generation

(In reply to Alberto Planas Dominguez from comment #24)
> (In reply to Rainer Klute from comment #23)
> 
> > May I assume that I can savely remove it? Or could a removal result in any
> > unwanted and possibly harmful side-effects?
> 
> Are you using sdbootutil and systemd-boot? If that is the case if you remove
> it it will be installed again. If you are using GRUB2 but sdbootutil is
> installed, you can remove sdbootutil and dracut-pcr-signature and will not
> be installed again.

Alright, I checked the systems under my control and found a mixture of dracut-pcr-signature, sdbootutil, and systemd-boot being installed or not installed in various combinations. But since none of them were actually used – all systems boot via Grub2 – I removed all of these packages as far as they were installed. I’ll see what will happen on further updates. (Still wondering how they got there in the first place …)

(In reply to Rainer Klute from comment #26)

> But since none of them were actually used
> – all systems boot via Grub2 – I removed all of these packages as far as
> they were installed. 

Thanks a lot for checking.

I had a recommendation of adding a Conflict with GRUB2, so hopefully users will decide to remove sdbootutil and dracut-pcr-signature instead of the bootloader.

Eventually (soon) this conflict will be dropped, as those tool will work with the new grub2-bls once it reaches factory.

> I’ll see what will happen on further updates. (Still
> wondering how they got there in the first place …)

I am not sure, but IIRC sdbootutil had during a short period of time a wrong set of conditions (basically if you use btrfs and something else this package would be installed).

Should we close this bug?

After todays' `zypper dup`, which contained the snapshot 20240416 and a new kernel version, and removing my dracut config change I made (`omit_dracutmodules+=" pcr-signature "`), the system boots regulary. The new and fixed version of dracut-pcr-signature is already part of snapshot 20240415. For me, this issue can be closed.

Thanks all for the work. Closing.