I just updated to the latest bits - 6.10.5 kernel - on F40 on my AMD 7950X system, AMD 6800 GPU. Updates were stuck installing at 63% for an extended period. I hard rebooted.
The machine is a multi-boot install. It will not boot under any recent version of Fedora on disk (6.10.4 is the latest good version; also tried 6.10.3) - just shows a black screen after the Fedora splash screen shows for a few seconds (with the revolving circle).
Debian 12 boots but I get a black screen with a movable mouse pointer - no desktop environment. The system isn’t dead but I can’t do anything with it (didn’t try remote).
Windows 11 boots but when I attempt to login it bluescreens. This seems to be timing-related, probably starting processes before I’ve logged in, one of which crashes the system.
There was a lot of firmware with the latest update. It looks like one of them has killed my system. Will attempt to install from scratch tomorrow, although it looks like everything needs to be reinstalled, maybe even new hardware?!
Seems the issue is GPU-related. I managed to get this screen full of output whilst booting:
A hard (power cycle) reboot during any write process (the update was writing) can easily lead to drive corruption and this appears to be what happened. It is impossible to conjecture where on the drive that may have happened.
Since you said the update was at 63% I must assume you were using the software app to perform the update. Dnf would have shown exactly which package was being updated since it itemizes one by one the packages as the update proceeds.
Recovery may require a reinstall, but I would first try booting to live media then using chroot to attempt a recovery of fedora.
For future reference, the greatest value to a user is patience when doing anything that involves writing to a drive. Which is more costly – a relatively short time waiting for an update to complete or the hassle and time involved in a reinstall and reconfigure of the entire system.?
The image you shared seems to indicate that whatever the cause was occurred before the data at the top of the screen.
The firmware update should have finished and system rebooted before the Fedora update began. It is possible there is a bug in the firmware update, so you should check for other reports on vendor forums.
It is also possible (especially if others aren’t having problems with the firmware updates) that you have a hardware failure. Can you boot using a Live Installer USB? Try using the grub2 editor to a remove the rhgb quiet and add 3 to the end of the kernel command line to see the boot messages and boot into a terminal.
My guess is it was the boot-stage update that occurs after restarting, when it was initiated from the graphical software manager (?).
There have been a noticeable number (3-4) of similar posts in a very short time of stuck system updates that render systems unbootable. Some mentioned hardware failures as well, including PCI bus errors. There might be something fishy going on with one of the recent linux-firmware updates, crippling some systems.
Yes, very good, but the update was stuck at 63% for around 10 minutes before I rebooted. It had obviously stopped or crashed. Updating has never taken that long previously.
The update was done via Discover which is what I’ve used since switching from Debian a couple of years ago.
It is always recommended that major version upgrades be done with dnf from a console. This ensures the user can see exactly what is happening and when without the potential for the DE or the gui app hiding the progress or status of each package as it is being updated.
I do not use (and never have used) one of the gui package managers to perform updates (even for routine minor updates). I prefer to see the details of what is being done and keep track of the progress.
I have seen updates take considerably more than 10 minutes. It totally depends upon what is being done and whether the system is totally idle before starting the upgrade (hopefully so) or if there are apps running in the background. Time required also can be affected by running in the gui or from the cli. Available memory and drive space is also a factor. What your system did the last update does not guarantee the same results with this update.
I still say that patience is a virtue when updating an OS, and think it should never be considered hung unless it has taken far more than an hour.
Some updates may require selinux or other time-consuming processing. Probably the only thing I miss about spinning disks is that the sound of disk activity was a sign of life.
I always remove the rhgb quiet from the kernel command line so I can monitor the progress of a reboot. When a system seems to stuck, check that CapsLock or NumLock lights still respond. Pressing Escape early in the boot process should show messages. If the GUI environment has issues you may still be able to get a text console with Ctrl-Alt F3. From long experience with systems that only had Nvidia graphics, one of the first things I do is enable ssh remote logins and install cockpit so I can manage the system remotely when the display fails. It is best to practice thse things while you system is working.
I woudln’t have said this qualifies as a “major version upgrade”. It was a typical regular update of the kind that happens all the time with Fedora (on a daily basis if you wish - I tend to update weekly). I have several machines running Fedora, admittedly different types and processor families. This was the only time that an ordinary update not only didn’t work but left the machine in an unbootable state (the only other time I had similar outcomes was when I was trying to get Nvidia drivers working on a laptop).
I’m not sure how dnf would have helped - the new bits were downloaded and were being installed during the multi-boot phase. Maybe it would, I don’t know.
I did that - it was one of the clues I had that the system was unresponsive at best.
I did that too, plus all the F-keys and any others that I thought might help. I only gave up when it was clear that there was nothing going on, and nothing I was doing elicited any signs of life.
I installed a new version of Fedora 40 from scratch using a live ISO on a USB stick.
So far, so good, although I spent several hours troubleshooting hardware - which seems to be fine. I didn’t have to resort to swapping out the GPU which was the next thing to try, but things did go better (particularly Windows) with the 7950X’s onboard GPU.
Windows 11 has stopped bluescreening on boot, and Debian 12 has regained the desktop. It seems as though it was a firmware change that appears to have taken out the GPU. Not sure how to explain the Windows & Debian (& Ubuntu) behavior otherwise.
Late breaking news: it may well transpire that the culprit was actually none other than Microsoft. The machine is multi-boot, one OS of which is Windows 11. I received the now infamous and undeniably helpful message “Something has gone seriously wrong” after I timed out and rebooted when my Fedora update stopped.
I have entirely re-installed Fedora 40 and Debian 12 and turfed Ubuntu off the system (typing this on the Fedora install). However, my previously all-inclusive grub config is no longer as diverse as it once once. If there are any grub gurus who can weigh in, can you force the OS prober to go through installed systems and update a grub config with what it finds? Alternatively, can I safely manually modify my grub config to pick up the installations that are no longer present in the config but exist in the system? I’m assuming that disk GUIDs are particular to each Linux (and maybe Windows) installation, and not unique across the machine (GUIDs are unique, but will grub or the Linux I’m booting recognize disk GUIDs from other installations not picked up from a probe?) I re-installed Fedora 40 on a fresh M.2 drive, then Debian 12 (ditto). Fedora didn’t pick up the Debian that no longer existed, and Debian hasn’t recognized Fedora. Not sure if any of this is due to the recent GRUB security issue that was “fixed” by Microsoft. It probably is since it’s related to version numbers that may or may not be being updated.
I have “messed around” with GRUB config in the past but as this is my main dev desktop machine, I don’t want to do anything experimental. I can boot into different OSs from the BIOS if necessary.
If it was Microsoft who was the culprit then I owe a big apology to the Fedora installation process!
