Fedora 43 → 44 upgrade keeps failing and rolling back (noob, need guidance 🙏)

Ask Fedora
, , ,
1

I’m on Fedora Workstation 43 and trying to upgrade to 44 , but it keeps failing.
Same thing actually happened when I upgraded from 42 → 43 , so this is like a repeating issue for me.

What happens

  • dnf system-upgrade download --releasever=44 works fine
  • I run dnf5 offline reboot
  • system starts upgrading, installs a LOT of packages
  • near the end I see stuff like:
Non-critical error in %posttrans scriptlet
  • then:
Transaction failed: Rpm transaction failed.
  • system reboots → I’m still on Fedora 43

So basically → upgrade runs → fails → rolls back → nothing changes

What I already tried (from guides + help)

  • disabled all COPR repos
  • removed some conflicting packages (like wcurl )
  • cleaned cache
  • retried upgrade multiple times
  • checked logs (but I don’t fully understand them)
  • noticed a LOT of .i686 packages (probably from Wine)
  • planning to remove Wine completely since I don’t use it

System

  • Fedora 43 Workstation
  • GNOME
  • HP EliteBook 840 G5
  • had Wine + some COPR stuff earlier

Log (last part)

Here’s the end of the offline upgrade log:

>>> Running %posttrans scriptlet: selinux-policy-targeted
>>> Non-critical error in %posttrans scriptlet
>>> Running %posttrans scriptlet: kernel-core
>>> Non-critical error in %posttrans scriptlet
...
Transaction failed: Rpm transaction failed.

(I can post full log if needed)

My questions (noob level)

  1. What exactly is a scriptlet error and why would it break the whole upgrade?
  2. How do I find which specific package is causing the failure?
  3. Are .i686 / Wine packages actually a problem or not? (got mixed answers)
  4. Is my system just “dirty” from previous upgrades?
  5. Is there a way to fix this without reinstalling ? (I really don’t want to lose my app data/configs)

Important

I really want to avoid reinstall because I have important configs and setup I don’t want to redo.

Any help would seriously mean a lot :folded_hands:
I’m trying to learn but this is way above my level right now

(PS: I used AI to help structure this post because I didn’t know how to explain everything properly, but the issue and logs are real)

2

It is not very likely it really rolled back the update. The kernel version itself doesn’t really say which Fedora version you are running, as the Fedora 43 and Fedora 44 kernel are basically the same version. It looks like there were some isses with the kernel update, so the question is: did the regular updates update the kernel properly?

You can run some checks:

  • Run cat /etc/os-release to see which version that indicates
  • Run dnf check if there are any pending issues with the installed system
  • Run dnf repolist to show which version of the repositories are used

As for wine and the .i686 packages, it would be good idea to remove them if you won’t use wine anyway.

Some packages includes pieces of script code which are run during certain stages of the installation. Post transaction scriptlets are run after all the packages are basically installed. The post transaction scriptlet for kernel-core runs the configuration changes to make the new kernel bootable.

It would say it in the log for example

>>> Running %posttrans scriptlet: kernel-core
>>> Non-critical error in %posttrans scriptlet

which is the scriptlet for kernel-core running after the end of the install process.

Maybe or maybe not. It depends. In principle .i686 packages should not be a problem, but errors in creating the packages could cause problems.

Perhaps. That depends how much your system deviates from the factory default.

That also depends.

3

cat /etc/os-release
NAME=“Fedora Linux”
VERSION=“43 (Workstation Edition)”
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=43
VERSION_CODENAME=“”
PRETTY_NAME=“Fedora Linux 43 (Workstation Edition)”
ANSI_COLOR=“0;38;2;60;110;180”
LOGO=fedora-logo-icon
CPE_NAME=“cpe:/o:fedoraproject:fedora:43”
DEFAULT_HOSTNAME=“fedora”
HOME_URL=“https://fedoraproject.org/”
DOCUMENTATION_URL=“Making sure you're not a bot!
SUPPORT_URL=“https://ask.fedoraproject.org/”
BUG_REPORT_URL=“https://bugzilla.redhat.com/”
REDHAT_BUGZILLA_PRODUCT=“Fedora”
REDHAT_BUGZILLA_PRODUCT_VERSION=43
REDHAT_SUPPORT_PRODUCT=“Fedora”
REDHAT_SUPPORT_PRODUCT_VERSION=43
SUPPORT_END=2026-12-02
VARIANT=“Workstation Edition”
VARIANT_ID=workstation

4

dnf repolist
repo id repo name
brave-browser Brave Browser
fedora Fedora 43 - x86_64

5

That is missing the “updates” repository, so perhaps the system was not fully up-to-date before running the upgrade to version 44. Also I can’t explain how after running the updates to 44 it would still refer to version 43, so there must be something else going on, and I have no clue what that could be.

Maybe a clean install is the better option.

If someone has a better idea, pleas chime in.

7

In addition to @vgaetera 's comment here the link to the quick-doc which gives you a bit more explanations, to get the guidance you asked for :wink:

Could it be that you installed a pre-release once (beta version) and updated to the stable version?

As you see above, the second link is distro-sync which does the following:

Using distro-sync to resolve dependency issues

The system upgrade tool uses dnf distro-sync by default. If your system is partly upgraded or you see some package dependency issues, try running another distro-sync manually to see if this fixes the problem. This will attempt to make your installed packages the same version in your currently enabled repositories, even if it must downgrade some packages:

sudo dnf distro-sync

Beside of checking the log files as proposed from others, have also a look if you have enough space where the kernel gets stored (/boot).

lsblk -f  #if sizes get close to 95% (FSUSE%) this can interrupt your upgrade too.

And also the /boot partition got an upgrade in size the last few versions. From 1GB to 2GB. If yours still is1GB or smaller, take in consideration to resize the partition before finishing your upgrade. But please not forget to update your impotent data in case something goes wrong.

8

ENVIRONMENT
Fedora 43 → 44 upgrade (KDE Plasma, Wayland)
Filesystem: btrfs with subvolume layout — subvol=/root, subvol=/home on nvme
Boot disk: third disk in system (hd2 in GRUB), UEFI
nvidia driver + CUDA stack via RPM Fusion nonfree
dnf5 version: 5.x (shipped with F43)
SYMPTOM

After a successful sudo dnf system-upgrade download --releasever=44 --allowerasing and running sudo dnf5 offline reboot, the system reboots but returns to Fedora 43 every time with no error, no progress screen, and no indication anything went wrong. The upgrade simply does not run.

ROOT CAUSE

The dnf5-offline-transaction.service and dnf-system-upgrade.service units both have ConditionPathExists=/system-update. On systems where root is a btrfs subvolume (subvol=/root), the /system-update symlink is created inside the subvolume. When systemd evaluates the condition early in the boot sequence, it is running against the top-level btrfs volume (subvolid=5), where the symlink does not exist. Both services are skipped, system-update-cleanup.service removes the symlink, and the system boots normally.

Confirmed in journal:

dnf-system-upgrade.service skipped, unmet condition check ConditionPathExists=/system-update
dnf5-offline-transaction.service skipped, unmet condition check ConditionPathExists=/system-update
rm[1136]: removed ‘/system-update’
WHAT DID NOT WORK
Manually creating the symlink at the top-level btrfs volume via sudo mount -o subvol=/ /dev/nvme0n1p3 /mnt && sudo ln -s /var/lib/dnf/system-upgrade /mnt/system-update and enabling the service with sudo systemctl enable dnf-system-upgrade.service — the system still booted past the upgrade environment each time. The symlink timing issue with btrfs subvolumes appears to be deeper than a simple path fix can resolve with dnf5’s current implementation.
WHAT WORKED — CONFIRMED FIX
Drop to a non-graphical multi-user target, then use dnf-3 (dnf4) explicitly instead of dnf5 for both the download and reboot steps. dnf-3’s offline upgrade implementation handles the btrfs subvolume layout correctly where dnf5’s does not.

1. Drop to non-graphical target (eliminates KDE/Plasma/Wayland from the equation

and ensures a clean environment for the upgrade trigger)

sudo systemctl isolate multi-user.target

2. Re-download packages using dnf-3 explicitly

sudo dnf-3 system-upgrade download --releasever=44 --allowerasing

3. Reboot into the offline upgrade using dnf-3

sudo dnf-3 system-upgrade reboot

The upgrade ran successfully on the next boot. Fedora 44 with KDE Plasma 6.6, kernel 6.19, and nvidia driver 580.x all came up cleanly.

ADDITIONAL BLOCKER ENCOUNTERED

RPM Fusion release packages (rpmfusion-free-release-43, rpmfusion-nonfree-release-43) also block the transaction because they are version-pinned. The F44 replacements require system-release(44) which doesn’t exist pre-upgrade, so dnf install rejects them. Pre-stage them with:

sudo rpm -Uvh --nodeps
https://mirrors.rpmfusion.org/free/fedora/rpmfusion-free-release-44.noarch.rpm
https://mirrors.rpmfusion.org/nonfree/fedora/rpmfusion-nonfree-release-44.noarch.rpm
SUGGESTED FIX FOR DNF5

dnf5 offline reboot should detect btrfs subvolume root layouts and write the /system-update symlink to the top-level btrfs volume, not only inside the subvolume. Alternatively the condition check timing in the systemd units needs to be reviewed relative to btrfs subvolume mount ordering. At minimum, a warning when the symlink cannot be confirmed visible outside the subvolume would prevent silent failure.

9

I broke the first post of this that I saw into it’s own topic since it didn’t seem to be the same issue, please continue this discussion there

Thanks and welcome to :fedora: