I get the fedora logo and spinning arrow. Then a bunch of text scrolls by on the left (too fast to read) and the screen goes black. Waited ~10 minutes; no change.
This is not normal. You may have a hardware problem. You may also have new issues left from previous boot failures. The journalctl output should help identify the problem. Some vendors provide hardware tests, and the Fedora Live Workstation USB has memtest86+.
How robust is your network connection? If you are having problems downloading packages you may need to use dnf update --downloadonly before running dnf update.
Doubt it’s a hardware problem. This is a dual boot machine with a fast, reliable Internet connection. Never had any problems on the Windows side. Never had any problems on the Fedora side until upgrading from F36 to F40. So far this year, I have done 4 clean installs of F40. About 50% of the time, updates are problematic: dnf crashes, apps stop working after update and have to be reinstalled, etc. I’ve been using Linux since BSD first came out, worked with numerous distros, and never experienced such an unstable release.
Installs are the most intense activity in the lifetime of most storage devices, so you are most likely to encounter failures after an install. Multiple installs are very likely to push an older device into failure, and btrfs detects data corruption problems that other filesystems ignore. Use Gnome Disks to check the “Health” of the system drive and run the internal tests. Some vendors provide bootable images for drive tests.
The F40 filesystems need repairs before you can mount /boot/efi/, and possibly other partitions. This often happens (with any linux distros) after an unsafe shutdown.
You can try mounting the partitions on the system disk from the command-line in the Live Installer to see what errors are reported. You can then try to make the partitions mountable
FUBAR. Waste of time to attempt to recover this installation…
Reviewing my notes, every single system corruption experienced is the result on running dnf. Outside of this consistent fault, Fedora is excellent and remains my favorite distro; hands down.
Ubuntu is out due to snaps. Debian is dubious due to slow app updates. Mint has some strengths, but has never been a favorite.
With trepidation, I’ll go with F40 again. However, I will look into disk image backups and will use yum (not dnf) for updates.
I have a Pull request in Pagure to update this documentation as it is hard to follow. Although no luck in hearing from the team on it.
There is no yum, dnf is the update tool in Fedora. If you are still having issues I can guide you through these steps to unlock the root if you have a Live USB available. From there we can also inspect the update on the machine.
IME, much faster and more reliable to simply perform a clean install, than to attempt a repair. Never keep data on the system drive, so it’s not much of an issue to start clean. Already done.
Fedora fan since F28. However, starting with F39 and F40, have had chronic problems with dnf crashing, sometimes resulting in corruption.
When you do, I will suggest you to assign a password to root. sudo passwd root. Thus if the boot hangs again, you can enter the root password and then run the journalctl to find out what went wrong. That you seem to have problems with dnf updates, is not normal.
In the picture from message 5, instead of having root locked, you can now enter the root password, and then do further analysis. You can’t fix things if you don’t know what the real problem is.
Dnf works well for many users, but also for many users, dnf is responsible for the majority of storage operations, so if the storage device is failing, dnf may appear to be unreliable.
Although SMART indicated no problems (other than a large number of error log entries), replaced the system SSD. Still observed intermittent issues with DNF.
However, ran MemTest86 and hundreds of memory errors were reported. Replaced system memory and, so far, no issues with DNF. Also, app crashes have virtually disappeared.
Never had memory failures before, but now it will be one of the first things I test…
This does not 100% verify the source of memory failure. There are a lot of contacts on the memory (240+) and even one that corrodes or otherwise becomes interrupted (even intermittent) can cause errors in memory.
My first action would be to remove the dimms and clean all the contacts with an eraser then reseat them and test again. Also using air to blow out any potential dust/lint from the socket while the dimm is removed.
Contacts seem the most common failure with memory, though the chips do sometimes fail.
Interesting.