12 thoughts on “Fedora Upgrade Issue”

1. No, but I’ve become a real believer in running my Ubuntu Linux O/S under VirtualBox. Before every update I take a snapshot of the running system that I can instantly roll-back to with a mouse click if there is ever an upgrade issue.

2. Hmm, looks like you have an alpha version of qemu and your update utility is detecting a conflict with a stable version. I’d know how to approach this in the Debian side of the planet, but don’t know how to do things in the Red Hat world. The magic bullet to start with in Debian land is:

   sudo apt-get install -f

   Sort of a Swiss army knife to fix conflicts. Is there anything similar in dnf or yum? Are you using qemu to run a Win10 box? Is it running in an alpha or stable version? I’ve not used qemu much, as my Win10 VM is in Virtualbox. If it’s possible without doing damage (and after backing up), you might do a full uninstall and reinstall of qemu. This is just a guess, but I suspect the python and other angst may be caused by another installation (possibly qemu) requiring these conflicting packages. Python these days is poured over everything like ketchup (yuck). It almost makes one appreciate snap packages.

   1. Almost. 🙂

3. A couple of links that might help, or maybe you’ve already seen?

   https://docs.fedoraproject.org/en-US/quick-docs/upgrading/
   https://docs.fedoraproject.org/en-US/quick-docs/dnf-system-upgrade/

4. Rand, you must really, really hate Windows to be putting up with all this.

   1. Indeed I do, and with good cause. 🙂

   2. To be honest I’m not particularly fond of Fedora for the issues Rand often encounters during upgrades. It has been called “forever beta” for a reason. If I were in need of a RedHat edition, I’d probably break down and pay for one but not before first checking with the key application programs I’d want to run under it to understand which of the various RHEL versions I should buy that they support. I’ve used RHEL before and with great success but it has been a long long time. But I once used RH 7.2 (that’s the original Red Hat Linux with the 2.4 kernel, not Red Hat Enterprise Linux) to drive a satellite router that at one point in time had over 240 days of continuous runtime thanks to being connected to a UPS. So it isn’t Linux per se that is the issue. That being said I’ve had good luck (knock on wood) with Ubuntu Linux using their LTS (Long Term Support) editions. I’m currently using Ubunut 22.04 LTS and have been for nearly two years now. Granted my work machine is Win10 based (by Corporate Edict) but I’ve been running Ubuntu under Oracle’s free VirtualBox VM ever since I got here and without issue. It’s a great way to work for those of us familiar with Unix/Linux but need to stick with the corporate communication and email software. The original Ubuntu OS (18.04 LTS) I started with is still installed in the VM and can be booted with a mouse click as can older snapshots I’ve taken of 22.04 LTS along the way.

      1. Agreed with the relative robust nature of Ubuntu LTS releases. I’ve had an occasional issue with an upgrade eliminating support for an old program I use a lot (GLE Graphics Layout Engine), but another upgrade corrected that issue. About 5 or 6 years ago, updates could be a bit flaky, but now they are rock solid. Upgrades are always amazingly smooth, although I admit to a bit of nervousness when they happen. I’ve got an ancient Dell running Focal Fossa (20.04) that acts as a server for home network backups. I’ve got two more slightly less ancient desktops running Jammy Jellyfish (22.04), along with a couple of dual boot laptops. Both laptops cannot “upgrade” to Win11, so I might wipe the Win partitions in 2025. I like to boot into Win about once a week to get MS upgrades (ugghhh).

         1. Being able to roll back to a snapshot eliminated a lot of the shakes around an update downgrade for me. Doubly so because I rely on my Linux environment to get serious work done. I wouldn’t risk updates at all without this capability. About the worst I’ve encountered is when an Ubuntu update requires a subsequent upgrade to the Guest Host VM tools from Oracle on the Windows side in order to boot. So far I’ve only suffered through that transition once and only because I wanted to go there.

5. OK, the problem is that I’m trying to upgrade to 35 when in fact I’m running 36. And the weird thing is that ‘uname -r’ says it’s 34, while /etc/fedora-release says it’s 36.

   Just to keep things confusing, don’t get confused by the output of the uname command vs the contents of the /etc/fedora-release file.

   Yes uname -r does give the version of the kernel you are using, but you cannot read anything into those last digits. The kernel numbering scheme doesn’t have anything to do with the OS revision per se. So likely uname is telling you something like it does on my computer:

   $ uname -r
   5.19.0-38-generic
   I don’t know if Fedora intentionally aligns it’s os releases with this or not, but the uname output is saying you are running the 5.19.0 kernel (build #38 or in your case #34) or whatever the output is in your case.

   Likewise:
   $ cat /etc/fedora-release # will say something like:
   Fedora Linux release x.y.z (fubar)

   These numbers do NOT have to line up with the kernel numbers. In my Ubuntu release it certainly doesn’t.

   $ cat /etc/os-release
   PRETTY_NAME=”Ubuntu 22.04.2 LTS”
   NAME=”Ubuntu”
   VERSION_ID=”22.04″
   VERSION=”22.04.2 LTS (Jammy Jellyfish)”
   VERSION_CODENAME=jammy
   ID=ubuntu
   ID_LIKE=debian
   HOME_URL=”https://www.ubuntu.com/”
   SUPPORT_URL=”https://help.ubuntu.com/”
   BUG_REPORT_URL=”https://bugs.launchpad.net/ubuntu/”
   PRIVACY_POLICY_URL=”https://www.ubuntu.com/legal/terms-and-policies/privacy-policy”
   UBUNTU_CODENAME=jammy

   So I hope that clears up some of the confusion. OS Numbers and Kernel Numbers are NOT THE SAME.

   1. I know it’s running a 34 kernel, because I see it when I boot.

      1. https://www.kernel.org/releases.html
         Above is a chart of Linux kernels and actual/projected release dates along with an explanation of distribution kernels and their identifiers. Hope this helps.

Comments are closed.