Wait, why do you have either of these installed? They should not be on a Fedora system. epel-release is an EPEL-only package, and I don’t know where redhat-release comes from.
I think your problem is not the upgrade itself, but that you have somehow enabled unrelated repositories. What is the output of sudo dnf repolist?
I don’t know where those came from. The first time I was aware of them was today while working thru this issue. Here’s the repolist:
SoftMaker_Office_Repository SoftMaker Office Repository
copr:copr.fedorainfracloud.org:bcotton:cherrytree Copr repo for cherrytree owned by bcotton
copr:copr.fedorainfracloud.org:phracek:PyCharm Copr repo for PyCharm owned by phracek
deadmozay-mindforger Copr repo for mindforger owned by deadmozay
docker-ce-stable Docker CE Stable - x86_64
fedora Fedora 33 - x86_64
fedora-cisco-openh264 Fedora 33 openh264 (From Cisco) - x86_64
fedora-modular Fedora Modular 33 - x86_64
google-chrome google-chrome
rpmfusion-free RPM Fusion for Fedora 33 - Free
rpmfusion-free-updates RPM Fusion for Fedora 33 - Free - Updates
rpmfusion-nonfree RPM Fusion for Fedora 33 - Nonfree
rpmfusion-nonfree-updates RPM Fusion for Fedora 33 - Nonfree - Updates
rpmsphere RPM Sphere - Basearch
rpmsphere-noarch RPM Sphere - Noarch
updates Fedora 33 - x86_64 - Updates
updates-modular Fedora Modular 33 - x86_64 - Updates
When I first saw the error message, I checked and didn’t see the epel repo. Did I miss it?
Thanks.
This copr appears to have not made a build since F29; you may want to remove mindforger.
These are all non-standard repos. I’m not sure why you have them installed, but they may be causing issues.
You may want to check which packages are installed from them with sudo dnf repository-packages --installed $REPOID list
The other thing, maybe you need also to rebuilt the grubenv incase it corupted. There an user here always failed to upgrade because of it.
sudo grub2-editenv /boot/grub2/grubenv create
Then try again to upgrade.
dnf repository-packages: error: the following arguments are required: SUBCOMMAND
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! 
Thanks much.
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.
.
Have you checked to see if there is anything useful in
/var/log/dnf.log
/var/log/dnf.librepo.log
Have you double checked available disk space?
du -h
Thanks
Thanks, grumpey,
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.
But anyway as mentioned from the other helpers you just have to DEACTIVATE everything what is not default!
You can activate them again after and see if they are available for the version you update for.
Here the default who comes with F34:
fedora Fedora 34 - x86_64
fedora-cisco-openh264 Fedora 34 openh264 (From Cisco) - x86_64
fedora-modular Fedora Modular 34 - x86_64
updates Fedora 34 - x86_64 - Updates
updates-modular Fedora Modular 34 - x86_64 - Updates
To disable use:
sudo dnf config-manager --set-disabled reponame
To enable use:
sudo dnf config-manager --set-enabled reponame
Disable everything that is not fedora*, then do the upgrade.
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.
JV,
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?
Just repeat sudo dnf system-upgrade download --releasever 34 till all your errors are gone … after you do the last command.
Everything what you removed you can try to reinstall after … as you not remove the config files in /etc , a reinstall should be smoth.
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.
fedora Fedora 33 - x86_64
fedora-cisco-openh264 Fedora 33 openh264 (From Cisco) - x86_64
fedora-modular Fedora Modular 33 - x86_64
google-chrome google-chrome
rpmfusion-free RPM Fusion for Fedora 33 - Free
rpmfusion-free-updates RPM Fusion for Fedora 33 - Free - Updates
rpmfusion-nonfree RPM Fusion for Fedora 33 - Nonfree
rpmfusion-nonfree-updates RPM Fusion for Fedora 33 - Nonfree - Updates
updates Fedora 33 - x86_64 - Updates
updates-modular Fedora Modular 33 - x86_64 - Updates
The easiest is the disable repo, remove packages, upgrade, enable repo, reinstall packages sequence, but how you proceed may be different depending upon your needs & wants.
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?
Thanks again.
You need to replace $REPOID by one of the repository names to check.
So I tried booting into an older (-1) kernel and when I initiated the upgrade routine, I got the message: “Error: upgrade is already scheduled”. Thoughts?
Yes.
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?