I’ve been using Fedora 44 Workstation for a month or so and enjoying it; no issues at all until today. I’m not exactly a power Linux user (yet, anyway), but I also run a Mint laptop and an Arch desktop, with no issues.
I can’t get a full hardware list at present because I can’t boot, but:
Asus NUC13
Intel Core i5 with integrated graphics
Nothing out of the ordinary
Today’s full upgrade included a minor update to kernel 7.1.4, among a number of other upgrades, but nothing unusual that noticed. The upgrade (dnf upgrade) ran with no issues and reported complete.
When I rebooted I got a grub menu (which I typically don’t) with three kernel versions; the latest, the previous 7.1.4 release, and the last 7.1.3 release. No matter which I choose, it boots into emergency mode, advises me on commands to use to move forward, then tells me the console can’t be opened because the root account is locked (an SE Linux thing, I believe) leaving no option but to power down. Perhaps I should have explicitly enabled the root account when I installed, but it’s too late now.
I can always reinstall Fedora, but I’d prefer to understand what went wrong and find a way to fix it. Any recommendations welcome.
Boot with the parameter systemd.unit=emergency.target, then change your root password, and you’ll then get a sensible root shell. If the root filesystem is read-only you can remount it as rw, assuming it’s not entirely hosed.
From there you can look to see what the actual issue is preventing the current, and previous kernels from booting. It’s often a knackered disk but until you view the journal, we’ll never know.
It is likely you got a problem with one of your file systems, which may fail to mount. If you can boot a live system you may be able to check the file systems for any problems.
Reinstall rarely needed unless the system drive has to be replaced. If you have a Live USB installer, you can use that to:
check the “health” of the system drive,
make sure the system drive has free space,
install inxi, run inxi -ezxx and post the output here (as web-discoverable pre-formatted text) so we understand your hardware, and
attempt to view the journal by mounting the root partition of your system drive and using journalctl --no-hostname --directory <mount location>/var/log/journal/<ID>
I have 3 partitions - boot, root, and home - on my system drive. From a live usb boot, all three mounted with no difficulties. After unmounting, all three passed fsck. I’m not exactly sure what I’m looking for in the system log, but I note that timestamp 7-24 20:03:16 is where dracut runs to build initramfs for the new kernel (7.1.4-204). The forum won’t let me upload a text file with the output, is there any way to get it to the group for a look? Failing that, clues on what to look for would be welcome.
‘Journactl’ has filter options to eliminate irrelevant entries. Try adding -p 3 to start. See https://docs.fedoraproject.org/en-US/quick-docs/viewing-logs/ for more options. You haven’t mentioned the filesystem used for Fedora — if it is btrfs you need to use btrfs-check. You should check free space on the partitions using the appropriate tools. For btrfs, use `btrfs filesystem usage ’.
You were right, Villy, it was one of my file systems; three of them, actually.
For some reason, something doesn’t like the nfs mounts of shared folders on my NAS that I had in fstab. I eventually found in the system log that it shifted to emergency mode just after the failed mounts. I would not have thought a failed nfs mount would cause that, but commenting those lines out in fstab fixed the boot problem. I tried it twice just to be sure.
There is nothing unusual about the nfs mount lines in fstab, and they’ve worked fine through a number of kernel updates, up until this last one. It doesn’t seem to be the kernel itself, since I tried booting from all three kernels on my system: 7.1.4-204, 7.1.4-200, and 7.1.3-200.
The three commented lines worked before the last upgrade. I tried it again with “vers=4” removed, but no change. I’m back in business with my Fedora system, but I’m stumped as to why the nfs mounts would be failing. Any ideas?
Ok, I’m blind… The nfs mounts in my fstab file were missing something obvious; added ‘nfs’ in the file system type field for each mount, and all is well.
I am absolutely certain that I did not remove them from the original file; in fact, I did not touch fstab before the series of failed boots following the upgrade yesterday. Is it possible that the kernel update process modified it?
That may remain a mystery, but the problem is fully resolved. Many thanks, everyone, for your input.
You can add the option “nofail” to the options. If the entry fail to mount, the boot will just continue instead of going into emergency mode.
From man fstab
nofail
do not report errors for this device if it does not exist.
Second, you can create a root password like sudo passwd root. Then when you next time are stuck in emergency mode, you can enter the root password and start the shell.