Lessons learned from a failed Fedora upgrade

Previously on “Rob revives MacBook with Linux and new hardware”

In my last blog post, I shared my experience reviving my old 2012 MacBook Pro. That mini passion project started with installing the Linux operating system called Pop!_OS and then doing some hardware upgrades that breathed new life into the 11-year-old laptop. After installing a new 512 GB solid-state drive, 16 GB of RAM, and a new battery, I chose to install the Linux distro called Fedora since I had been dabbling with Pop!_OS for about three weeks, and the whole point of messing around with this particular laptop is to play with various Linux operating systems. I chose the most current stable version (Fedora 37) which seemed like a safe bet. That Saturday afternoon, I set up my typical applications and configured settings to my liking. 

Upgrading to Fedora 38 Beta

After reading a blog post saying Fedora 38 Beta was already quite polished and stable, I started considering upgrading to Fedora 38 Beta. But since I had already configured some applications and settings the way I like them, I was a bit hesitant to do another fresh install. I posted about it on Mastodon and got a reply suggesting that it’s not too hard to upgrade to the beta release in place from the command line. I hoped that upgrading directly from Fedora 37 to Fedora 38 Beta would retain all the settings and applications that were in place. After a little research, I found this Linux Capable post that provides steps for a Fedora 37 to Fedora 38 upgrade.

Executing the command

So I replied to my new friend on Mastodon, “Would that be a command such as: sudo dnf system-upgrade download –releasever=38?”

Caution: I do not recommend following my impulsive lead if your computer is vital to your workflow. Always back up your important files before attempting upgrades.

Throwing caution to the wind I thought to myself, “Let’s do it!” After all, the worst that could happen on this experimental laptop was that I would have to do a fresh install and start over with downloading a few apps. Minutes later I initiated the process with the sudo command, and my screen displayed a flurry of terminal activity that looked promising.

Transaction test failure

My optimism subsided fast after seeing that the transaction test failed and I received these errors:

file /usr/lib64/gstreamer-1.0/libgstamrnb.so conflicts between attempted installs of gstreamer1-plugins-ugly-1:1.22.0-1.fc38.x86_64 and gstreamer1-plugins-ugly-free-1.22.1-2.fc38.x86_64

file /usr/lib64/gstreamer-1.0/libgstamrwbdec.so conflicts between attempted installs of gstreamer1-plugins-ugly-1:1.22.0-1.fc38.x86_64 and gstreamer1-plugins-ugly-free-1.22.1-2.fc38.x86_64

At this point, I was considering bailing on this direct upgrade method because those letters and numbers all strung together didn’t mean anything to me. This was the first time I have attempted a major operating system version upgrade via the command line, and my command line repertoire is limited to simple things like changing directories (cd) and listing files (ls) in said directories. (i.e. limited).

Duplicate files from different repos

After some research, I found a post with a similar albeit not identical issue someone encountered during the upgrade process. This Fast Gadgets video helped me identify the issue with duplicate files from different repos causing a transaction error. I was able to deduce that I had copies of gstreamer files installed in the Fedora and RPM repositories (which is not allowed). To solve the issue, I removed the RPM versions of the files and left the Fedora versions, which allowed me to pass the transaction test. I was feeling superhuman from this problem-solving feat!

Plan B: A fresh install of Fedora 38 Beta

I was relieved to have solved the files-in-duplicate-repos problem and advanced to the next phase of the Fedora 38 upgrade, but my celebration was cut short when the installation got hung at 49%. Pressing ESC didn’t help and it appeared my only recourse was to abandon the upgrade and restart the computer. Even restarting the computer failed. 🤬 My computer was in version upgrade limbo and would not boot up. I don’t recall the error screen message, but it was clear that I needed to start all over again with a fresh install. 

This time I skipped Fedora 37 completely and simply installed Fedora 38 Beta from my Ventoy thumb drive. For all the troubleshooting effort I spent, I could have installed and configured my typical applications ten times over. I was ready to have a functional Fedora computer again so I returned to the method with which my confidence was high. A straight-up flash drive install of Fedora 38 Beta.

11:43 pm – Ending the day with a win—Fedora 38 Beta is fully installed and I’m now a pro at enabling the Broadcom wireless driver. I’ll finish setting up my apps tomorrow. Thanks for following this journey!

Reporting my first Fedora bug (sort of)!

Wanting to be a good open source citizen, the following Monday I set out to learn how to file a bug with the Fedora community. After creating an account on https://bugzilla.redhat.com, I performed a few searches for bugs that resembled what I had encountered. Feeling a bit timid about it, I reached out to fellow Red Hatter Ben Cotton, Fedora Program Manager, to ask him if I should proceed with filing a bug. In my email, I described the issue with the file conflicts and that I tried a couple of keyword searches in Bugzilla, but the search page just churned without yielding any results. “This is my first time attempting a bug report or even looking at Bugzilla, so I’m not sure if I’m doing this correctly. So far, I have not reported anything as I’m just now dipping my toe into the Fedora community.” 

First Fedora bug!

Call me impulsive or, more positively, motivated, but a couple of hours later, before Ben was able to respond, I went ahead and filed the ticket.

He closed the ticket immediately. HA! “Alas, I must close it! The package in question (gstreamer1-plugins-ugly) comes from the RPM Fusion repositories, not Fedora.” A swing and a miss! 

Ben gave me the info I needed to file the bug in the correct place, https://bugzilla.rpmfusion.org. I replied, “Thanks, Ben! This is extremely helpful info! Now that the mystery of reporting a bug is eliminated, the next time I encounter something it will be less intimidating.”

Second Fedora bug!

When I circled back around to file the bug in the RMP Fusion bug tracker, my experience was indeed less intimidating. I started to file the ticket as shown below and was immediately presented with possible duplicates before clicking Submit Bug. Look at bug 6605 at the bottom of the list.

Existing bug 6605

This appeared to be the same issue I encountered, and a fix had already been deployed.

Someone had filed a ticket for the same issue, and the resolution was pushed to Fedora 38 the same night I was attempting to upgrade from 37 to 38! What are the odds!? Had I attempted this upgrade after 9:30 PM that evening, I might have avoided this error altogether. But what fun would there have been in that? I would have missed out on all the troubleshooting and learning new things. Like how to work around a failed transaction test in the terminal or how to file a bug.

Lessons learned from a failed Fedora upgrade

Being new to Linux, it’s easy for me to assume the issues I encountered were self-inflicted user errors. But as Benjamin Hollan commented on Mastodon, “Still might be worth reporting; I think they mean for the upgrade to be more seamless than that. Worst that can happen is that they don’t see it as an issue.” It did not occur to me in the moment that documenting the obstacles I encountered could benefit the broader community.

By being aware of challenges as they happen with the mindset of documenting them for the benefit of the community, the experience shifts from being frustrating to fruitful. Taking pictures and screenshots and copying and pasting error messages provide breadcrumbs to trace one’s steps that recreate errors others may be experiencing. All of that data can be used to resolve bugs and make the process smoother for the next person.

Through this experience, I learned how to identify and solve technical problems previously thought to be beyond my grasp, became more comfortable using the command line effectively, identified useful online resources to reference in the future, and learned how to file a bug with the appropriate component (ie. RPM rather than Fedora).

It's not just about getting the latest software on an old machine; it's about the journey of problem-solving and learning. In this instance, I learned more from a failure than I would have from a success.

Upgrading from Fedora 37 to Fedora 38 Beta was not without its challenges, but through the troubleshooting experience, I gained valuable skills and knowledge. I encourage anyone interested in Linux and problem-solving to dive in and start tinkering. You never know what you might learn along the way.