Trying to upgrade from Fedora 33 to F34 and the upgrade does not start after reboot or even after a shutdown and fresh start. I’ve repeated the process more than four times, including clearing the system-upgrade and dnf caches. I get no error messages and can’t find anything in the logs (assuming I’m even looking in the right places). I’ve used the dnf method on this same machine in the past. The machine continues to boot into F33 w/o issues. (I’ve thought about going directly to F35, which is not recommended.) Any suggestions for going forward? What I’ve found in my research seem to be compatibility issues but, again, I see nothing that suggests that, especially since the transaction tests don’t flag anything. Any suggestions for going forward? Thanks!
You should follow the recommended upgrade steps. sudo dnf upgrade --refresh sudo dnf system-upgrade download --releasever 34 sudo dnf system-upgrade reboot
If either the ‘upgrade’ or the ‘system-upgrade download’ steps fail you need to resolve those issues before you continue. In some cases it may be necessary to add in sudo dnf distro-sync between the upgrade and the download steps.
It is also sometimes necessary to disable 3rd party repos (and possibly uninstall packages that were installed from the 3rd party repos) since those may cause conflicts or other errors.
Those 3 commands are all that is needed to do a full system upgrade to a newer version and should be run in the order listed. The --releasever gives the version number you are upgrading to.
In your title it seems you expect the reboot to trigger the upgrade, but that is not the way it has ever been done.
The full instructions are here
Thanks for your replay. I did follow the steps, each of which completed sucessfully, so that’s not the issue. I don’t understand your last comment: the Fedora docs specifically say that the reboot triggers the upgrade, as in
Trigger the upgrade process. This will reboot your machine (immediately!, without a countdown or confirmation, so close other programs and save your work) into the upgrade process running in a console terminal:
* *sudo dnf system-upgrade reboot* *
Once the upgrade process completes, your system will reboot a second time into the updated release version of Fedora.
So, yes, the reboot has always triggered the upgrade. As for using distro-sync before the upgrade, please explain. Thanks.
I read your comment as saying that you rebooted and expected they upgrade to start. In fact, what you now imply is that you do the sudo dnf system-upgrade reboot step and the reboot starts. There is a difference in how the reboot is initiated so I may have misunderstood.
Can you tell us exactly what happens during that reboot? It should shutdown and restart and display a screen that indicates the progress of the upgrade. Is that not happening? Is something else happening?
The only detail you have provided is Trying to upgrade from Fedora 33 to F34 and the upgrade does not start after reboot or even after a shutdown and fresh start. There is no hint of what is actually happening or how the reboot was initiated and we cannot guess. The shutdown and fresh start will never start the upgrade as I previously noted so we really need a lot more detail.
I just did a test system upgrade on a VM and after doing the sudo dnf system-upgrade reboot step it shuts down and reboots into this screen
There are no messages. The machine shuts down (rebooting) and reboots directly into F33. No indication at all that an update is taking place. (That’s why I described it as I did. The shutdown & reboot happen as described in the documentation; it just doesn’t go into the upgrade “step”, if you wil.) And as I’ve searched around for answers, I can find no info in any logs or the dnf history list of either the downloads or the dnf transaction. It’s as if, and I’m truly not trying to be sarcastic or flippant here, nothing I did happened.
I’ve read that the process is supposed to reboot into a “safe” mode of sorts and trigger systemmd(?) into “launching” the upgrade. But I didn’t follow how that was/is supposed to work. My limited understanding is that it is supposed to reboot into the “existing” kernel and then there’s a hand-off of sorts into the upgrade process. (FWIW, I’ve done this a number of times (maybe as far back as F23 or so) in the past on this machine and not run into this situation.)
I just saw the screenshot you posted and I don’t even get to that point.
I agree, btw, that the full shutdown and “fresh start” should not have worked and I didn’t expect it to; I was just trying to eliminate the possibility.
Ok, so then something weird seems to be occurring, and this explanation makes it easier to understand.
Try the other step I indicated. sudo dnf --refresh distro-sync which will download fresh repo metadata then verify that everything installed matches what it should be according to what is on the repos.
Follow that with a clean out of the upgrade packages and a new download. It is possible that something has gotten corrupted in the initial download and so cleaning it out and doing a new download should fix that. sudo dnf system-upgrade clean all (the path to the system-upgrade cache is not the same as the standard upgrade cache) sudo dnf system-upgrade download --releasever 34
I have seen times where this step may seem to hang but when you actually look at what is displayed it might be asking for permission to install new keys.
Once the download completes with no errors at all then redo the sudo dnf system-upgrade reboot and see if there is any difference now.
That helps! The disto-sync (which I had earlier tried w/o the --refresh option) returned an error message that libqxt (whatever that is) does not belong to a distupgrade repository. (Strange that the transaction test didn’t pop this up!) So I added --skip-broken and it still pops up Error: Problem: problem with installed package libqxt-0.6.2-16.x86_64
libqxt-0.6.2-16.x86_64 does not belong to a distupgrade repository*
nothing provides libc.so.6(GLIBC_2.33)(64bit) needed by libqxt-0.6.2-16.x86_64*
Pkgs.org has the package and it appears that it, as well as libqxt, are QT packages. However, it also appears that libqxt is no longer being maintained. (libqxt / libqxt / wiki / Home — Bitbucket) So I’m wondering if I remove libqxt if that’ll break KDE or one of the QT packages. (I’m thinking it won’t since the wiki page was last updated in 2015, but I don’t know.) But if that’s the problem, then I may have no choice. Thoughts?
Well, unfortunately, this didn’t solve the problem. After doing the distro-sync (per your text above) and cleaning the cache. I did a fresh download and initiated the upgrade. The “redirect” (my word) didn’t take and the unit still boots directly into F33. The only difference now is that the distro-sync transaction is listed in the dnf history and that’s the last transaction listed.
Having now walked thru some 5000+ lines of boot/kernel/system log entries, I may have found at least one factor. Here are the last 10 lines or so of the journalctl -b lines from the session during which I initiated the system-update reboot:
Jan 19 08:23:55 hallie.claritynet systemd: Started Show Plymouth Reboot
Jan 19 08:23:55 hallie.claritynet audit: SERVICE_START pid=1 uid=0
auid=4294967295 ses=4294967295 subj=system_u:system_r:init_t:s0
msg=‘unit=plymouth-reboot comm=“systemd” exe=“/usr/lib/systemd/systemd”
hostname=? addr=? terminal=? res=success’
Jan 19 08:23:55 hallie.claritynet systemd: Requested transaction contradicts
existing jobs: Transaction for rtkit-daemon.service/start is destructive
(systemd-reboot.service has ‘start’ job queued, but ‘stop’ is included in
There are add’l entries similar to the last line regarding the “requested transaction”. Notice the contradictory “stop” description. (I could attach the entire 418 lines that I captured which began with:
Jan 19 08:23:54 hallie.claritynet python3: Rebooting to perform upgrade.
Jan 19 08:23:54 hallie.claritynet systemd-logind: System is rebooting.
So it’s getting the upgrade and reboot 'signals" (my word), goes thru shutting down the various services, etc., and then runs into the contradictory messages quoted above.
I’m way out of my lane here so I haven’t a clue where this takes me.
This may be the cause. The daemon prevents a lot of (certain type) changes to the system so the quick fix that may work is to do this. sudo systemctl stop rtkit-daemon.service before you do the sudo dnf system-upgrade reboot step
If that service is actually stopping the sytem upgrade then it also may be necessary to do it as sudo systemctl disable --now rtkit-daemon.service to prevent it restarting with the reboot. The first suggestion is temporary until the next boot, the second is permanent and would need to be reset after the update is complete if you actually want that daemon running.
Thanks. I tried it going with just the “stop” command and then again after disabling it. Still not working. I’m not seeing the same “error” messages as before, not surprisingly, Now the closing messages (with the time & hostname stripped off for (hopefully) increased readability) are:
The entries would be more meaningful (and readable) if you were to directly copy and paste them into your post using the </> Preformatted text tags above without any form of editing.
We then can look at the format we normally see on our own systems to analyze the meaning. It also helps if you include a reasonable number of entries surrounding the part you feel is interesting since that way we get a feel for the context as well.
It does puzzle me that it seems to properly start the reboot then shuts down and reboots again outside the upgrade process. The audit part may give a clue, in that it is possible for selinux to interfere in some way.
What happens if you edit /etc/selinux/config and change the line that reads SELINUX=enforcing to SELINUX=permissive or SELINUX=disabled then try the upgrade reboot step again.
I was grasping at straws with the comment about audit and selinux but other than removing the lines mentioning audit which were selinux related I see little difference. Maybe someone else has a suggestion?
There is one other thing I could suggest, and that is totally up to to your discretion. Fedora only officially supports upgrade to the n+1 version which is what you are trying with going to version 34. However, many users, myself included, have upgraded to the n+2 version in a single step and seen no errors.
The failure seems to be that systemd is not properly completing the reboot step and immediately reboots to the installed OS. It is possible that an attempt to repair systemd will fix that. You may try sudo dnf reinstall systemd* and find that then the upgrade will complete normally.
It is also possible that even after that, the upgrade to fedora 34 may fail and that you should consider cleaning out the cache as done earlier then doing a download for upgrading directly to version 35.
I cannot think of anything else to suggest, so hopefully these steps may work and if not someone else may have a better idea by now.
Thanks. I’ve been reluctant to skip over a version but I’ve been thinking about that possibility. Hadn’t considered reinstalling the systemd packages - that seems like a reasonable approach. I don’t want to do a fresh install if I can avoid it; been there, done that, and the dnf approach has worked for me up to now.
I’ll see if anyone else comes up with another approach and I’ll keep you posted. I do want to thank you for all the help. If nothing else, I’ve learned some things!
My situation is a bit different than yours. I have a fedora 32 machine that has been collecting dust for almost 2 years, and I started it up today. Upgrading from 32 to 35 is taking a lot of time (with >3 GB download for each version), and with each version update I am running the distro-sync as well as the upgrade --refresh and I am finding that the full system upgrade does not always pull the latest packages as it is supposed to. These steps are necessary.
I edited the title of this thread to properly reflect the situation where the system-upgrade reboot step does not start the upgrade.
I’m downloading the F35 packages now: it’s about 7GB (8090 packages … but who’s counting?). I’ve luckily got a pretty good pipe so the dl isn’t too long. Ran into one burp initiating the download:
Problem: package epel-release-7-11.noarch requires redhat-release >= 7, but
none of the providers can be installed
generic-release-common-33-0.1.noarch does not belong to a distupgrade
problem with installed package epel-release-7-11.noarch
That didn’t show up before with the F34 attempt, so I’ve removed it and the download is thus far going smoothly. I’m hoping this works: my “fear” is that the F33 installation will hose it up. I did do the systemd* reinstall, as you suggested. My fingers are crossed. I’m about to initiate the reboot and will keep you apprised.
Thanks for editing the title: trying to describe the issue initially was something of a challenge. And, again, I do appreciate all the time and effort you provided working with me!
If everything works as it should, I’ll be back in a few hours…
FWIW: the download just finished. 11 minutes. Here we go…
Well, skipping over F34 didn’t work, either. At this point I’m thinking about options:
Stick w/ F33 until I get a new box and then do a clean install, or
Do a fresh install of either 34 or 35, or
Ask if there’s a way to bypass the shutdown/reboot problem by appending one or more commands in grub2 at boot time.
I have F35 running on another machine which works well but is more minimal in terms of installed programs. I guess I could create a package list and create a mirror box before doing a fresh install on this one… Why can’t anything with computers be simple?!? I’m sure the sun’s over the yardarm somewhere…