I have an old physical server with an AMD Athlon64 CPU. It predates EFI. My upgrade to F34 hung just after verifying cmake upgrade and as it was about to start tigervnc upgrade. Since the kernels didn’t update and the F33 packages haven’t been purged I seem to be in an state that DNF won’t let me correct.
Attempting to setup a new system-upgrade errors that it would result in deleting the protected packages dnf, grub2-tools-minimal, systemd and systemd-udev.
Something like that happened to me once many years ago. At the time, there was a “dnf complete-transaction” (or something like that). Unfortunately, I don’t see that option anymore. However, it looks like there is a “dnf history redo last” command. I’ve never used it, so I cannot attest to how well or if it will work. I do remember having to run “package-cleanup --cleandupes” after I got dnf to complete the transaction when I ran into that problem.
P.S. Another option might be “dnf distro-sync --releasever=34”. If it won’t “sync” the packages forward to the new release, you might even be able to go backwards with that command by running “dnf distro-sync --releasever=33”. I think distro-sync works more at a package-by-package level and it might be able to straighten things out a little better than system-upgrade when you are in a mixed state.
Once I managed to not fat-finger the setopt param, I was able to remove the fc33 versions of the protected packages and dnf distro-sync --releasever=34 is installing the last ~855 packages that didn’t install yesterday, plus 9 that have been updated since.
I don’t miss the old days of installing a buch of floppies and compling everything you wanted or needed on the machine. However I only have to stray away from the most basic ops with dnf so rarely that I’m quite dangerous if left to my own devices.
Thanks for the pointers to save me from myself. Now I’m just waiting for this particular machine to keel over a final time, but that’s a different tale altogether.