Once upon a time I did set up a script (something like “yum –assumeno update” but to just filter out package names) on my Fedora machines to automatically send me an report about the updates that need to be applied nightly and since Fedora is an development distribution the emails should be daily (or at least weekly), but for some reason last couple weeks have been rather quiet…
So digging in the internet a little and what do I found out – Fedora 31 EOL was 24 of November 2020… Another thing that happened on the midst of chaos that the year has been so far… So I have to upgrade several PC’s to the next release… I know Fedora 32 is not the latest version to upgrade to, but I like the stability of being 1 release behind the latest version as it has most likely been fixed from the bugs that sometimes creep into the latest releases. Also I don’t run the latest and greatest hardware so I don’t have the need for the latest kernel drivers so I usually don’t need the bleeding edge software...
It has been a while since I had to dist upgrade my fedora machines (I usually do it one or twice a year as the EOL time nears, but seems that in the midst of all the chaos that is year 2020 I forgot to do another upgrade cycle until it already was past EOL for some time. Oh well – time to plan one night for downloading a lot of updates… I usually don’t have any issues with upgrades as the process for doing it is pretty much the same as it was 10 years ago. Yes it has gotten simpler and easier in years as the yum/dnf framework has evolved and I think the last mishap of dist upgrade going wrong was with Fedora 19 and that upgrade was long time ago. I just love the simplicity of the process in the midst of things. Windows people would say to that that the system is slow and cluttered and you should re-install windows regularly to keep the clutter and legacy software away, but this is Linux – you don't get all sorts of extra dll’s and who knows what… Yes in time some software is obsoleted and replaced with new, but still… One of the laptops I use regularly has been upgrades since Fedora 7 and now its running 32 and most likely will go to run even newer versions…
Enough of rambling – the procedure I used to upgrade from F31 to F32 or to do a dist upgrade on my machines is this:
“dnf clean all”
“dnf –releasever=32 update”
“dnf –releasever=32 –downloadonly –skip-broken upgrade“
This can be done remotely over ssh or from graphical environment and it just cleans out the F31 repository data and downloads the F32 meta-data and packages (I have slow internet so it took a while). I usually don’t have million repositories enabled so I don’t have a lot of package conflicts that need resolving. But now I recommend to switch to the terminal to do the actual upgrade so “Ctrl+Alt+F2” (yes I have done the upgrade over ssh and from the graphical environment, but I have had mishaps where you have 3000 packages upgraded and just when it is time to start uninstalling the previous version packages some script gives an error and the upgrade crashes and you are a left with 7000 installed packages just because some dependency is missing in the graphical environment).
“dnf –releasever=32 --skip-broken upgrade”
And usually that’s all that is needed to do dist upgrade. Well not this time – this time I was left with packages that have an F32 version available but for some reason would not upgrade and the message was cryptic:
WARNING Modular dependency problems:
Problem 1: conflicting requests
- nothing provides module(platform:f31) needed by module gimp:2.10:3120191106095052:f636be4b-0.x86_64
Problem 2: conflicting requests
- nothing provides module(platform:f31) needed by module libgit2:0.27:3120190407181414:f636be4b-0.x86_64
So it seems that Gimp and libgit2 need something that was in F31 and is no more in F32… Great… Google was also not particularly helpful as there were bug reports about this message but no real answer. After digging some more I found out that dnf has some new features where packages can have some sort of modules that they require in “/etc/dnf/modules.d/” and well after upgrade the version they were searching was not there any more… Again after some searching that the removal of package was not enough to remove and the only way would be to manually edit each offending module to add “state=disabled” to the file.
Well… As I don’t have anything that is this module specific I found an easier way:
“dnf module reset '*'”
No more annoying modules :D
And when I now run “dnf upgrade” I end up with
Upgraded:
apache-commons-codec-1.13-2.fc32.noarch apache-commons-io-1:2.6-8.fc32.noarch apache-commons-lang3-3.11-1.fc32.noarch apache-commons-logging-1.2-20.fc32.noarch apache-commons-net-3.6-8.fc32.noarch hawtjni-runtime-1.17-2.fc32.noarch jansi-1.18-3.fc32.noarch jansi-native-1.8-2.fc32.x86_64 jsch-0.1.54-11.fc32.noarch jzlib-1.1.3-12.fc32.noarch slf4j-1.7.30-2.fc32.noarch xalan-j2-2.7.2-2.fc32.noarch xerces-j2-2.12.0-4.fc32.noarch xml-commons-apis-1.4.01-29.fc32.noarch xml-commons-resolver-1.2-29.fc32.noarch
So… I don’t know why those modules are good for but I don’t need them and resetting them let me to finally upgrade the system…
Until next time I guess...
