Figured it was time to make the jump over, and did some quick reading that a two version upgrade was an officially supported route. Decided to do it through the terminal, where I ran dnf upgrade --refresh, all fine. Then ran dnf system-upgrade download --releasever=41, all fine there. Compared the checksums, all seemed good (but I can’t rule out if I missed something indicating an unsatisfied dependency). Ran sudo dnf system-upgrade reboot to start the process. Went smoothly over the first hour, got to 90% where it hanged for another hour. At this point it’s 1am and I decided if its borked, I’ll deal with it in the morning and if it isn’t, it’ll be sorted when I wake up.
I have now woken up and found it still hanging at 90%. Brilliant. I had no option but to shut the PC off. On rebooting, I have three kernels available - one showing F41, two for F39. The F41 kernel (understandably) immediately kernel panics because of a missing initramfs. The two other F39 kernels get stuck in a bootloop, never making it to the login screen. Emergency mode… has no internet access for some reason (likely because the system upgrade wiped part of those relevant files out) and only lists the loopback as the working interface with ifconfig so I’m unable to get any new packages or downloads through emergency mode.
Any suggestions or is this a case or “it’s FUBAR, go reinstall?” - I’m going to go get a new USB to prepare for a fresh reinstall but if there are any logs I can provide please tell me what they are and I’ll see what I can do - this was my first time upgrading the system from one to the next and it’s a bit of a shame its ended up like this.
I’ve since got my live media boot - it doesn’t seem to recognise the fact that theres a fedora install already existent to repair, and a quick look at the disks seems to reveal that the boot drives just don’t exist:
(for quick reference, dev/sda1 and sda2 are a NTFS Hard drive that I use between both the windows partition and linux, where linux is installed on dev/nvme0, the 0n1p1 being EFI. dev/nvme1 is a second SSD split between extra linux filesystem space and windows install)
I can still mount the fedora data partitions and read them, which is atleast a plus that the data exists. What would be the best way to recover from here?
Check that the small partitions aren’t full – you can do that with Gnome Disks in the Live System. You can use journalctl in a terminal to check the entries for the failed install. Mount the partition with /var with Gnome Disks and look for the latest files in <mount_point>/var/log/journal/*/*.journal. In a terminal run:
cd <directory with .journal files>
journalctl --file=<file from time of the issue>
This seems to indicate that your fedora install is on /dev/nvme0n1.
Thus it seems the easiest recovery would be to boot from the live media, mount and chroot into the installed system, then run dnf distro-sync to complete the recovery.
boot to the live system and configure internet connection
open a terminal
su since everything from here on requires root privileges.
mount /dev/nvme0n1p3 /mnt
now to mount the additional necessary directories from the booted system for F in sys proc run dev sys/firmware/efi/efivars ; do mount -o bind $F /mnt/root/$F ; done
chroot to the mounted file system chroot /mnt/root
mount the additional file systems mount -a
now do the recovery with dnf distro-sync --releasever=41
This should finish whatever failed to complete previously.
When the upgrade has completed successfully then exit the chroot and reboot.
