Thanks, all, for the suggestions. I did remove mindforger since a) I stopped using it a while back and, 2) it last updated with F 30. The other repos supply various packages that are used from time to time and have been on the machine for a number of upgrade cycles w/o issue. Any errors identified doing distro-sync efforts were already addressed.
Based on the earlier discussions w/ JV, I had reinstalled systemd* since the log messages pointed to a failure to (I think I have this right) set a reboot point with the target file. (Again, why out of my element here!) The messages said the reboot “reset” had succeeded when, in fact, in hadn’t. There is no indication on reboot that the upgrading process has initiated. Very frustrated.
I did try the grubenv suggestion just now; no luck, unfortunately. The Fedora Magazine had an article recently (fedoramagazine.org/use-lvm-to-system-upgrade-a-fedora-linux-server-with-minimal-downtime/) regarding an alternative upgrade method. Has anyone tried that recently? Really, really, trying to avoid a fresh install!
PS: In the documentation, there’s a dead link to docs.fedoraproject.org/en-US/quick-docs/upgrading-fedora-online/Upgrading_from_EOL_Fedora_using_package_manager). I did find the info on fedoraproject.org/wiki/Upgrading_Fedora_using_package_manager)Anyone have experience using with when upgrading from F 33 or thereabouts? Thanks.
There’s nothing in any of the dnf* logs indicating any kind of error or advisory message. And there’s plenty of disk space. The problem is that the upgrade is not being initiated upon reboot after issuing the sudo dnf system-upgrade rebootcommand. The box reboots directly into the existing (F 33) installation.
I can’t believe I failed to consider the repolist.
I guess that since it had always worked in the past I figured that it should be OK, but I agree that at least temporarily you should disable all but the default repos. I would, however, leave the rpmfusion repos enabled since I have never seen an issue with upgrades using them, and they probably are needed for your video card drivers.
I also seem to remember that at times upgrades have failed due to installed packages from 3rd party repos even after the repo was disabled so that is something else to consider as well. That was usually caused by dependencies.
And that is exactly what has happened. Disabling the non-default repos throws up all kinds of errors/problems requiring either removal of various packages I use regularly or enabling --auto-erase which most likely has the same effect. So short of that, how does one avoid the problem list: I don’t see a way to do a “partial” upgrade, i.e., ignoring packages supplied by those various repos. So I may attempt to step through enabling repos to see if I can at least get past the problem list. (I didn’t take a shot of the list since I was working at the command line immediately after logging in.) And since I hadn’t had any issues in the past, I couldn’t see where disabling repos would have an effect…
That said, I don’t understand how the repos affect the existing installation’s trigger into the reboot/upgrade process when downloading the new packages (whether F 34 or 35) aren’t installed until the upgrade process begins. At least that’s how I’m interpreting what I’m reading. Am I confused??
Thanks to you and everyone else trying to help me. I do appreciate it.
Update: after reenabling the rpmfusion repos, still no boot into the upgrade process. And looking at the current boot log, I seen no reference to either a new kernel or a target file. Should I?
You will likely need to make a list of all packages that are causing problems, then uninstall them.
Once that is done the upgrade should work.
After the upgrade is complete the repos can be re-enabled and those packages reinstalled.
I would, however, suggest that you look and see if there are similar packages within the fedora tree that can do what you are doing with the out-of-tree packages. Finding something within the distro that does the same thing will eliminate these types of headaches going forward.
From your list, I use and have never had issues with the following when doing upgrades.
The upgrade process with DNF is just for the default repositories. The rest you have to do manually.
Copr repo’s come and go. If there is no maintainer they get removed. It would be too much to support all this repo’s too!
Okay, maybe I’m not being clear here. I’ve gone thru the disabling repos steps and re-run the system-update reboot scenario multiple times now. I’m NOT getting any error messages. What happens is the box goes into shutdown/reboot, the mb intro screen appears, grub (or whatever) goes thru the sequence of looking for drives, the computer boots into the most recent kernel (no dual-booting involved, fedora only) and brings me right to the terminal under F 33. No DE or other user-supplied graphics involved to this point.
As was discussed earlier, the process appears to be controlled by systemd, etc. I’m wondering if downgrading systemd* would address the issue? I also don’t see any calls to systemd in the first 100 or so lines of the boot journal - should I? My current kernel is 5.14.18-100.fc33.x86_64; anybody think booting into an older kernel and then initiating the upgrade sequence would make a difference?
You need to, with those extra repos disabled, redo the download step. Any errors that show up need to be resolved, until the download once again completes with no errors.
Doing the dnf --refresh upgrade with those repos disabled will help identify any dependency issues. The commands given above will help identify the packages installed from each of the repos in question so you have a list of those packages to remove and potentially reinstall.
It may also require that you do the sudo dnf system-upgrade clean all step to make sure each download has only the desired packages selected for download.
Remember that the reboot step automatically will boot from the latest kernel installed, so you should never try doing a system upgrade from an older kernel.
The problem that gives the “Error: upgrade is already scheduled” message is that the upgrade is already scheduled with the latest kernel and the older kernel sees that and will not override that setting. That is a safety feature that you should never attempt to override. To ensure that things work properly is the reason you do a full dnf --refresh upgrade before starting the download, then reboot if needed to ensure you are in the latest kernel when doing the download and upgrade.
I’ve spent most of the day going thru this cycle, all to no avail. The few package messages I got were resolved and I still get nothing to indicate a problem. At this point I’m out of patience…
That said, one thing that I have noticed is that dnf is not recording transactions. When I run a history, none of the actions I’ve done with dnf are listed; the commands do show up in my bash history, tho. Is it possible that the problem is with dnf? I’ve done multiple distro-syncs and, again, no messages. Thoughts?