So the report notes issues with LUKS, do you use LUKS encryption? I used to use it up till about F31, and frankly only didn’t re-install it when I did a HDD re-configuration simultaneously re-installing Fedora Linux Silverblue. Anyway it worked through upgrades up to then with never an issue. What you could do is roll back to your previous, or select it in the Grub menu at boot time, then redo the upgrade perhaps something got muddled in the process first time.
So the report notes issues with LUKS, do you use LUKS encryption?
Yes, I use LUKS encryption, and until now with no problems.
What you could do is roll back to your previous, or select it in the Grub menu at boot time, then redo the upgrade perhaps something got muddled in the process first time.
I tried this with no luck, but thanks for your help.
EDIT: I mean Version: 34.20210516.0 is booting fine, but I can’t upgrade. I tried to rebase to Rawhide, but the same problem occurred.
I’m doing an upgrade from Version: 34.20210610.0 (2021-06-10T00:47:14Z) right now. I’ll let you know how it goes.
[Edit] 14 Minutes later reboots into Version: 34.20210618.0 no problem. Sorry, that really doesn’t help your situation though. Does it get past the LUKS decryption at boot, it seems to from the text file
So yes, past LUKS unlocking, good. If you use journalctl to look at your specific boot attempt at the first time it occurred. If you know how many, as in number of boots, previous, to find out which boot ID you can do journalctl --list-boots | grep 2021-05-18 will give a terse listing of all boots for today’s date. So if you know the date of the first boot failure you can now use it’s ID with journalctl -b=<bootID> to get the journal of the bad boot, if it booted to some level.
P.S. The ID is the -## on the left hand side of the table that lists the boots, so the first column