Hi,
time for my 6 months report on upgrade bugs. Fedora 43 Edition :D
As you may know, i run a bigger cluster of fedora VM servers and baremetal installations. Due to the headless nature, distro-sync is the prefered methode. Pls no discussions, the "normal" upgrade path is too dangerous in case of those issues and i know all your arguments from the last upgrade report ;)
This is just a report to give feedback to get new ideas how to handle stuff.
Upgrading those servers showed the following issues, some are caused by special circumstances, i mention them anyway.
1. several services do not start
Root cause:
the replacement of (Example) /usr/sbin/sshd with a symlink to ../bin/sshd did not work. NONE of those replacements worked.
Proxmox VM, no special kernels required, happend 1 out of 100 (we still have to update more servers, expect more numbers )
2. Systemd 258 does work or does not work with the same LTS kernel on different systems
Root cause: unkown - inconclusive informations
Symptoms:
- Units freezes of PID1 unit while!!!! upgrading the system is still in progress. - reverting to an even older kernel fixed it also.
XenServer, LTS Kernel 5.x . (no bugzillareport because of this special snowflake)
Does not happen on Proxmox VM with newer Kernel.
Workaround: using systemd 257 from Fedora 42 for now.
3. missing Housekeeping
collision between config files for user and groups of bin / daemon a.o.
Happens on all systems with more or less sys users.
bugzilla.redhat.com/show_bug.cgi?id=2479538
4. GDM failing to start gnome-session
Happend on different hw and gpus
Workaround: replace with lightdm
https://bugzilla.redhat.com/show_bug.cgi?id=2481856
5. PLYMOUTH Service failes to mount sysroot in initramfs
Happend once so far.
Special note: the initramfs did not change for a while now. I can only imagine that something recreated the initramfs without letting us admins know.
XenServer, LTS Kernel 5.x . (no bugzillareport because of this special snowflake)
Solution: disabling it in the kernelline
################### ### Absolut NOGO Bugs ### ###################
Does Fedora have a upfront notice about those breakages and is it a subscribable resource? The happy msg on this is: Fedora so commonly used, it got important to be more careful ;)
one way to handle this would be to introduce a new package or an "old" package that backs the breaking service up for a release cycle, like it's done with postgresql servers.
6. POSTGRESQL server update from V16 to V18
Never ever make more than 1 version jump with postgresql servers. the imgrationtool does not handle it at all:
F43vm # postgresql-upgrade --upgrade-ids postgresql - Upgrade data from system PostgreSQL version (PostgreSQL 17)
No support for 16 => you have to revert the database, export databases, upgrade server and reimport it.
I'm glad i new about that pgsql issue upfront and made sqldumps. All hail MYSQL livemigrationfeature ;)
7. DOVECOT 2.3.x to 2.4.3 switch
Dovecot changed the config format in 2.4.x and is not capable of migrating the old config correctly. The online tool is too dump for it. manual recreation was required.
If the testservers did not find this, a major production fail would have been the consequence.
best regards, Marius Schwarz
On 28/05/2026 00:24, Marius Schwarz wrote:
- POSTGRESQL server update from V16 to V18
Never ever make more than 1 version jump with postgresql servers. the imgrationtool does not handle it at all:
F43vm # postgresql-upgrade --upgrade-ids postgresql - Upgrade data from system PostgreSQL version (PostgreSQL 17)
No support for 16 => you have to revert the database, export databases, upgrade server and reimport it.
Actually postgres is fine with it, it's just the way that the packaging in Fedora works that stops you doing it because the postgresql-upgrade package is always one version behind.
You don't have to dump and reload though - you can uninstall the postgresql packages and install the postgresql17 ones and upgrade, then uninstall those and install the postgresql ones again and do a second upgrade.
Now that Fedora is packaging multiple versions there isn't really any need for the -upgrade packages, but it would require the versions packages to be parallel installable which they aren't at the moment.
Tom
On 28 May 2026, at 00:24, Marius Schwarz fedoradev@cloud-foo.de wrote:
- DOVECOT 2.3.x to 2.4.3 switch
Dovecot changed the config format in 2.4.x and is not capable of migrating the old config correctly. The online tool is too dump for it. manual recreation was required.
This broken my setup as well. Was painful to fix.
One config I tried had dovecot coredumping...
I did lose emails on my production system.
Barry
On Thu, May 28, 2026 at 1:24 AM Marius Schwarz fedoradev@cloud-foo.de wrote:
- POSTGRESQL server update from V16 to V18
Never ever make more than 1 version jump with postgresql servers. the imgrationtool does not handle it at all:
F43vm # postgresql-upgrade --upgrade-ids postgresql - Upgrade data from system PostgreSQL version (PostgreSQL 17)
No support for 16 => you have to revert the database, export databases, upgrade server and reimport it.
I'm glad i new about that pgsql issue upfront and made sqldumps. All hail MYSQL livemigrationfeature ;)
I agree, the postgres bump skipping version 17 wasn't great. But this issue was already discussed for quite a bit last year when Fedora 43 was released, and led to updated documentation: https://discussion.fedoraproject.org/t/cant-upgrade-postgres-after-f42-f43/1...
Fabio