A few months ago I was doing a standard update of a Fedora 40 machine which then hung and, long story short, I had to reinstall. I moaned about it here (naturally) and was chided that I should have used dnf for “proper” updating. I used Discover as I usually do (interestingly, maybe, I always used apt on Debian, but typically let Discover do the job on Fedora).
So now I’m about to plunge into upgrading Fedora 40 to 41 on the first of 5 machines. Discover is giving me a seductive come-on with its green-bannered (an Incredible Hulk reference?!?) invitation to slip into something more modern. I’ve used dnf and Discover to upgrade (39 → 40, e.g.) in the past, both successfully. But now, after the previous negative experience, I’m wondering if there’s a “right” way to upgrade to the next version? I noticed there have been quite a few problem reports with dnf5 and other issues with this latest major version upgrade and I’m feeling a little apprehensive.
The recommended method on the website is to upgrade with gnome-software. But I don’t recommend it because I had many problems. Especially flatpaks are getting damaged and repos are malfunctioning. My advice is to upgrade from the terminal.
The procedure linked by the OP is the recommended way while on f40 for upgrading to f41. Hopefully by the time f42 is released dnf5 will have matured enough to avoid the several issues that have been noted by others in using dnf5 on f40.
Either way is “right”, but updating with dnf is not for users who have rarely used command-line tools. For users comfortable with command-line tools, dnf upgrades make problems more visible and can be needed to recover a broken system – others may be be better served by a reinstall. The downside for the larger linux community is that a reinstall may reduce the likelihood that the underlying problem can be understood. There are some things that can be done to capture potentially useful information prior to updating, such as an inventory of installed packages and notes on configuration customizations (typically in /etc/). Prior to a reinstall, a backup of the /var/log directory may preserve details that explain what went wrong.
Thanks. Personally I’m very comfortable with CLI (been at thlis before GUIs were a thing! Not that I’m a dnf guru, mind you), but I do usually let Discover handle updates on Fedora just because they’re so frequent, and I get lazy if stuff just works, which for the most part it does.
I do keep logs of what I’ve installed, copies of configs that I’ve changed, and backups generally.
Sorry, but that doesn’t make much sense. As written, it doesn’t upgrade to 41, and in effect sudo dnf upgrade --refresh would be enough to update the current 40 system. Also note that “update” and “upgrade” do exactly the same thing.
When using dnf5 for the very first time, some important status information is extracted from the previous dnf status and after that never again. Therefore, don’t use dnf5 until you will be committed to not use dnf4 any more.
Great idea to do it like that. I “system-upgrade” using dnf twice a year it’s algae superior to Gnome Software which doesn’t provide useful feedback from the upgrade process
Any thoughts on the unmatched checksums? I tried running the command immediately again with a wider terminal session but the information wasn’t repeated.
Corrupt data returned from the source (whatever that was - which I did not see).
Dnf apparently tried switching to the opencolo repo, failed to connect, then switched to another which was successful.
I’ve upgraded hundreds of VM’s from one fedora version to another, including 40->41. The easiest method I have found, which does upgrade 3rd party packages from repos like rpmfusion and remi, is using the following commands.
Make sure all packages on your current Fedora version are up to date sudo dnf --refresh upgrade
Make sure all configuration is up to date sudo rpmconf -a, go through each configuration file to determine if those changes are relevant to your system.
Make sure nothing requiring a reboot was updated. sudo dnf needs-rebooting -r, if a reboot is required, then go ahead and do that now. If not, continue to next step.
Run the following command sudo dnf --releasever={version to upgrade to} distro-sync. Look at the list of packages that will be upgraded, downgraded, etc and that you don’t see anything alarming. If there were no gotchas and all dependencies were resolved, then go ahead and press Y, and continue with the upgrade.
Wait, when it’s finished, reboot. Log back in and again take care of any needed configuration updates sudo rpmconf -a.
For me the right way was to use Discover. I use Fedora Kinoite and was pleasantly surprised it all went so smooth. This was my first system update/upgrade which worked so well. I have used, on other distro’s other upgrade scripts but always ended up in a black screen at reboot.
Discover has worked for me also during previous version upgrades, but it appears that, to hard-core Fedoraistas at any rate, that the more controllable and queryable dnf route is preferred, just in case something does go wrong, it seems to me.
This update incorporates a new major version increment for dnf so it appears some circumspection is not out of order, lest one is left in the “Black Screen of, if not exactly Death, then at least Upgrade Embarrassment” situation.
Yes, true, doing it in a terminal will give you more insight of the process, but to honest, I am not so interested in that. For me the computer just has to work. For me it woud be rpm-ostree instead of dnf because of the immutable version I use.
Plus, it is very easy to rollback to a previous version. What helps with that is to pin a working version before doing the update. That way you are sure this working version is still there, no matter how many reboots have happened during the upgrade.
Should something still go wrong, an install of the new version takes little time and you are up and running very fast.
So there are several ways of doing the upgrade. For me, this time Discover did the job very well, so I will probably do that again the next time.
If you find one like that, let us know. PC’s break, so having ways to deal with a broken system should be thought out in advance.
You have a strategy to deal with failed updates, but what about hardware failiures?
The large enterprise I worked for over 35 years did evolve to point they purchased enterprise grade systems in large volumes (minimum order 1000 units) with optional components (like network cards) chosen for reliability and give each user and work unit space in the corporate cloud for data. Stuff would still break, in which case IT would swap in a replacement drive with the standard base image. If it worked, they gave it back to the user. If it didn’t, and wasn’t too old, it was sent to the vendor for replacement.
One downside was that there was no way to provide students or visitors with identical hardware.
I can imagine that in a (large) company the IT department has strategies as you explained, but I am a private person with 2 laptops of which one is only used to install and check out other distro’s, the other is my main machine which is running Fedora Kinoite.
I have enough knowledge of a Linux system to install it, set it up the way I want to, meaning installing user programs and doing regular updates.
When I face a problem I search for it here on Fedora web pages and if I can’t find it here I search the wider internet for it. If I can’t fix it I write about it here on the Discussion pages hoping for a good answer. What I see in the answers people get here is astonishing. With that I mean, there are several people here in the forum who know directly which file(s) to check, what to change to make it work again. Where do they get all that info from? It is way out of my league.
When I do have a problem which I can’t fix I just re-install. I used manual partitioning so I keep my home folder, just install Kinoite, update it and install the flatpacks and also the Nvidia driver from RPM-Fusion. Within an hour it is all done: problem solved. Not in the most elegant way but hey, it works.
Hardware failure? The laptop I have now is still under warranty and if something should break after the warranty period I do have the technical manual so I can see how to reach a certain component which will be replaced by a new one I guess. Never had that though.
Is this a good way to fix a problem? No idea, but I guess it will work and if not I open my wallet and either go back to the shop where I bought it to see how much it will cost me to have it fixed or I buy a new one.
From experience.
Either by paying attention to what is posted here (and on other forums) about problems and the solution OR by personal experience and experimentation.
Often testing is used to confirm the solutions.
Your approach is literally the best way I am aware of.
Most problems have solutions (unless it is actually defective hardware that needs replaced).