My experiences upgrading to Fedora 30
Having a certain number of machines here with Fedora, I started working on April, 30 with the migration of those to use Fedora’s latest version: Fedora 30.
Note: this is a re-post of a blog entry I wrote back on May, 1st: https://linuxkernel.home.blog/2019/05/01/fedora-30-installation/ with one update at the end made on Jun, 26.
First machine: a multi-monitor desktop
I started the migration on a machine with multiple monitors connected on it. Originally, when Fedora was installed on it, the GPU Kernel driver for the chipset (called DRM KMS – Kernel ModeSet) was not available yet at Fedora’s Kernel. So, Fedora installer (Anaconda) added a
nomodeset option to the Kernel parameters.
As there was KMS support was just arriving upstream, I built my own Kernel on that time and removed the
By the time I did the upgrade, maybe except for the rescue mode, all Kernels were using KMS.
I did the upgrade the same way I did in the past (as described here), e. g. by calling:
dnf system-upgrade --release 30 --allowerasing download dnf system-upgrade reboot
The system-upgrade had to remove
pgp-tools, with currently has a broken dependency, and
eclipse. The last one was due to the fact that, on Fedora 29, I was with modular support enabled, with made it depend on a Java modular set of packages.
After booting the Kernel, I had the first problem with the upgrade: Fedora now uses BootLoaderSpec – BLS by default, converting the old
grub.cfg file to the new BLS mode. Well, the conversion simply re-added the
nomodeset option to all Kernels, causing it to disable the extra monitors, as X11/Wayland would need to setup the video mode via the old way. On that time, I wasn’t aware of BLS, so I just ran this command:
cd /boot/efi/EFI/fedora/ && cp grub.cfg.rpmsave grub.cfg
In order to restore the working
Later, in order to avoid further problems on Kernel upgrades, I installed
grubby-deprecated, as recommended at https://fedoraproject.org/wiki/Changes/BootLoaderSpecByDefault#Upgrade.2Fcompatibility_impact, and manually edited
/etc/default/grub in order to comment out the line with
GRUB_ENABLE_BLSCFG. I probably could just fix the BLS setup instead, but I opted to be conservative here.
After that, I worked to re-install
eclipse. For that, I had to disable modular support, as eclipse depends on an
ant package version that was not there yet inside Fedora modular repositories by the time I did the upgrade.
In summary, my first install didn’t went smoothly.
Second machine: a laptop
At the second machine, I ran the same
dnf system-upgrade commands as did at the first machine. As this laptop had a Fedora 29 installed last month from scratch, I was expecting a better luck.
… it ended to be an even worse upgrade… machine crashed after boot!
Basically, systemd doesn’t want to mount a
rootfs image if it doesn’t contain a valid file at
/usr/lib/os-release. On Fedora 29, this is a soft link to another file inside
/usr/lib/os.release.d. The specific file name depends if you installed Fedora Workstation, Fedora Server, …
During the upgrade, the directory
/usr/lib/os.release.d got removed, causing the soft link to point to nowhere. Due to that, after boot, systemd crashes the machine with a “brilliant” message, saying that it was generating a
rdsosreport.txt, crowded of information that one would need to copy to some place else in order to analyze. Well, as it didn’t mount the rootfs, copying it would be tricky, without network nor the usual commands found at
So, instead, I just looked at the journal file, where it said that the failure was at
/lib/systemd/system/initrd-switch-root.service. That basically calls
systemctl, asking it to switch the
/sysroot (with is the root filesystem as listed at
systemctl checks if it recognizes
os-release. If not, instead of mounting it, producing a warning and hoping for the best, it simply crashes the system!
In order to fix it, I had to use vi to manually create a Fedora 30 release. Thankfully, I had already a valid
os-release from my first upgraded machine. So, I just manually typed it.
After that, the system booted smoothly.
Knowing that Fedora 30 install was not trivial, I decided to go one step back, learning from my past mistakes.
So, I decided to write a small “script” with the steps to be done for the upgrade. Instead of running it as a script, you may instead run it line by line (after the
set -e line). Here it is:
#/bin/bash #should run as root # If one runs it as a script, makes it abort on errors set -e dnf config-manager --set-disabled fedora-modular dnf config-manager --set-disabled updates-modular dnf config-manager --set-disabled updates-testing-modular dnf distro-sync dnf upgrade --refresh (cd /usr/lib/ && cp $(readlink -f os-release) /tmp/os-release && rm os-release && cp /tmp/os-release os-release) dnf system-upgrade --release 30 --allowerasing download dnf system-upgrade reboot
Please notice that the scripts will removes os-release and copies the one from the linked file. Please check if it went well, as if the logic fails, you may end crashing your machine at the next boot.
Also, please notice that it will disable Fedora modular support. Well, I don’t need anything there, so it works pretty fine for me.
Please notice that, after an upgrade, Fedora may re-enable Fedora modular. That happened to me on one machine with had Fedora 26. If you don't want to keep it enabled, you should do:
dnf config-manager --set-disabled fedora-modular dnf config-manager --set-disabled updates-modular dnf config-manager --set-disabled updates-testing-modular dnf distro-sync
I repeated the same procedure on several other machines, one being a Fedora Server, using the above scripts. On all, it went smoothly.