I’ve attached an image below (from booting into recovery), but my Fedora 36 installation, after rebooting from Gnome Software’s “Reboot & Install” button, resulted in the system being unable to boot.
1st failure seems to be “Failed to mount boot-efi.mount - /boot/efi”
I’m interested in any potential fixes anyone could help with. Installation is encrypted.
I do not know that this is a gnome-software (packagekit) failure but I have seen several similar failures that all seem to have occurred after an update with gnome-software.
You can try booting to run level 3 by selecting your kernel on the grub menu and pressing the e key to edit the entry. Then find the line beginning with ‘linux’ and edit it, removing rhgb quiet and adding init 3. Ctrl + X should continue the boot which should get you to a login screen where you can log in as your regular user. Once logged in this way try ‘startx’ and it should bring up the desktop.
If that fails then we need more info from the text screen you should see.
Thanks, Jeff. Just seeing your comment now. I’m trying the init 3 replacement now.
Update: It looks like following your suggesting is still ending up with a repeating error at boot and dropping to dracut-emergency.service shell.
Two warnings:
Warning: /dev/disk/by-uuid/{string} does not exist
Warning: crypto LUKS UUID {different string} not found
This produced a /run/initramfs/rdsosreport.txt file and suggests saving it somehow, but with the limited sh-5.1# terminal (no scp or ssh) I’ll need to figure that out.
It’s worth noting that I’m never prompted for my disk decryption password when trying to boot normally, it just fails to the emergency shell. Using a live USB and going through troubleshooting mode (via server netboot) does find and prompt for decryption password and successfully chroot into the disk, so I’m not sure what the best steps here are at this point.
Looking for password-related things reveals the following:
[ 1.933308] tower systemd[1]: Started plymouth-start.service - Show Plymouth Boot Screen.
[ 1.933425] tower audit[1]: SERVICE_START pid=1 uid=0 auid=4294967295 ses=4294967295 subj=kernel msg='unit=plymouth-start comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[ 1.934015] tower systemd[1]: systemd-ask-password-console.path - Dispatch Password Requests to Console Directory Watch was skipped because of a failed condition check (ConditionPathExists=!/run/plymouth/pid).
[ 1.934080] tower systemd[1]: Started systemd-ask-password-plymouth.path - Forward Password Requests to Plymouth Directory Watch.
[ 1.934111] tower systemd[1]: Reached target paths.target - Path Units.
Followed shortly by something I’d seen before:
[ 2.365281] tower kernel: nvme nvme0: failed to set APST feature (2)
[ 2.379244] tower kernel: nvme nvme1: failed to set APST feature (2)
Not sure if there’s a way to force the password ask, but maybe that would help.
That sounds like there is an issue with device id on those 2 devices.
You may want to check the disk uuid and the uuid of each partition on those 2 drives and find out if there is a conflict there.
While booted up try this command to see if there is any duplicated info shown.
$ lsblk --output MODEL,NAME,PARTTYPE,PARTUUID,SERIAL,MOUNTPOINT,TYPE,UUID,VENDOR,WWN -a
MODEL NAME PARTTYPE PARTUUID SERIAL MOUNTPOINT TYPE UUID VENDOR WWN
SanDi sda 191078 disk ATA 0x5001b448b842c616
├─sda1
│ c12a7328-f81f-11d2-ba4b-00a0c93ec93b f899df8e-0177-45ba-a145-8a342ab3f83b /boot/efi part EE19-DB5A 0x5001b448b842c616
├─sda2
│ 0fc63daf-8483-4772-8e79-3d69d8477de4 b9d9a34d-0f61-4939-ba7e-93d679b981cf /boot part bd615d70-0ff8-42b6-ab38-0a7429b9bb91 0x5001b448b842c616
└─sda3
e6d6d379-f507-44c2-a23c-238f2a3df928 65025311-1191-41d7-9de1-429990026ed4 part vpxzk7-tpzx-FEdH-wJzd-qZEQ-yEJ7-nuiPkc 0x5001b448b842c616
└─fedora-root
/ lvm 3468ef28-f391-4b94-811e-894daaa5b791