Botched upgrade to Fedora43

Ask Fedora
,
1

I recently upgraded from F42 to F43 via the “Software” GUI app, and was left with a blank screen on boot. I think next time I’ll do it via command line, as I now understand the two methods are not identical.

When I started, it notified me that some Wine packages were incompatible and would need to be removed; I said sure and went for it. I had to walk away from my system during the update, which I thought would be fine. I assumed it would pause for input if anything was needed from me.

When I returned, the screen was black with a blinking _ at the top left. Rebooting took me to the same screen. Notably, I noticed that there is no F43 kernel listed on the GRUB menu, just F42 kernels and the rescue option.

I found similar issues on the forum and tried some things, namely the removal of the wine-dxvk i686 packages… maybe that step failed during the upgrade?

Somehow, I managed to get a graphical boot, and I’m currently typing this from the affected system. However:

  • uname -r returns 6.17.13-200.fc42.x86_64, and
  • ls /boot shows no f43 entries, despite the fact that
  • cat /etc/fedora-release returns Fedora release 43 (Forty Three)

So, my system thinks it is on Fedora 43, but the kernel is From Fedora 42. I also tried sudo dnf distro-sync --refresh --releasever=43, which returned this:

Problem: The operation would result in removing the following protected packages: NetworkManager, gnome-shell, grub2-tools-minimal, selinux-policy-targeted, setup, sudo, systemd, systemd-udev

What should my next move be?

  • Run the distro-sync command with –setopt=protected_packages=?
  • Act like I’m still on F42 and run sudo dnf system-upgrade download --releasever=43?
  • Something else?

System details in case that helps:

System Details Report

Report details

  • Date generated: 2026-01-06 16:25:18

Hardware Information:

  • Hardware Model: ASUS ROG STRIX B650-A GAMING WIFI
  • Memory: 32.0 GiB
  • Processor: AMD Ryzen™ 7 7800X3D × 16
  • Graphics: AMD Radeon™ Graphics
  • Graphics 1: AMD Ryzen™ 7 7800X3D
  • Disk Capacity: 1.0 TB

Software Information:

  • Firmware Version: 3057
  • OS Name: Fedora Linux 43 (Workstation Edition)
  • OS Build: (null)
  • OS Type: 64-bit
  • GNOME Version: 49
  • Windowing System: Wayland
  • Kernel Version: Linux 6.17.13-200.fc42.x86_64
2

The manual shows a few tips you can still check.

Black screen with blinking screen can bee issue with the gpu driver.

There is a change request which asks to change to dnf5 for the software app (packagekit) with F44. Then both apps use the same dnf5 database.

3

I would run that command with the additional --releasever=43 option.
Before doing that I would run df -h and verify that /boot is not full or nearly so. If /boot fills up it prevents a complete install of the newer kernel.

I also would remove all the wine packages since that was one of the things that you got a message about, and there has been quite some time with many different bug reports about not being able to upgrade from f42 to f43 when wine is installed. sudo dnf remove wine* --noautoremove should do that properly. If you need to use wine it can be reinstalled after the upgrade completes properly. There is a related common issue topic.

Note that the recommended method for upgrading versions is shown here.

The software manager hides any messages and may or may not do the upgrade properly. Users can end up in your situation with no clue as to what may have failed and caused the problem. The cli method using dnf provides messages and tells the user of problems before the upgrade is actually performed.

2 Likes
4

I did run distro-sync with this already. Are you suggesting I run it with both --releasever=43 and –setopt=protected_packages=? That’s what I was thinking to do next, but I’m not sure what the consequences will be if I let it remove protected packages like systemd.

Here is the relevant output of df -h:

/dev/sda2 974M 388M 519M 43% /boot
/dev/sda1 599M 20M 580M 4% /boot/efi

/boot is less than 50% full, so that doesn’t seem like an issue to me. But maybe it is?

I’ve been following that bug and recently saw that it was fixed (https://bugzilla.redhat.com/show_bug.cgi?id=2401666), so I felt good about hitting the upgrade button. I guess I misunderstood. I did remove all wine packages, so hopefully that won’t be a barrier with whatever I try next.

Honestly, I wish the graphical method was simply not available in this broken state given the risk. It makes sense to provide an upgrade path for average users without CLI confidence, but not if it has a 50/50 chance of borking their system. This is going to hurt trust among average users fleeing Windows 11, among other things. (This complaint is not directed at you, I’m just taking the opportunity to rant.)

5

I originated that bug.
The fix appears to still be in updates-testing so it should soon be moved to the updates repo.

I agree that packagekit is broken when updating versions so that really needs to be fixed. The fact it still uses dnf4 when dnf5 has been the fedora mainstay for the last 3 releases (nearly 2 years at this point) is off-putting at best.

Any gui that hides what is going on is something that I personally dislike and is why I still rely on the cli interface for management.

I understand that most have no experience with the cli – and I blame that on both windows and apple in that they deliberately make it difficult for users to use any interface except the gui with point & click. A user cannot have complete control of their system if they depend solely upon the interface someone else creates for them. If the developer of the interface does not provide full access the user is limited to the access the developer does provide, which in many cases is lacking in function.

1 Like
6

Ah, well, I guess I jumped the gun then. :upside_down_face:

Do you think running the following command would be a smart next step?

sudo dnf distro-sync --refresh --releasever=43 –setopt=protected_packages=

7

That should be appropriate. The protected packages it says it will remove seem to be the ones from f42 that will be replaced by the versions from f43 so should not harm.

Running the command with dnf allows you to review what is being done so you can verify that it is replacing those packages and not removing them. Having the list of ‘protected packages’ that it claims will be removed can be used to check each package and actually verify that it is a version update and not actually a removal.

BTW, as of today the noted fix for that bug appears to already be in the updates repo.

8

Well, I went ahead and ran sudo dnf distro-sync --refresh --releasever=43 --setopt protected_packages= which removed a huge number of f42 packages (2400+) and updated a few f43 ones. I restarted the system and it booted after awhile, but I’m still at the same place as my first post. The system thinks it’s Fedora 43, but the F42 kernel is active and there doesn’t seem to be anything marked F43 when I run ls /boot.

It seems like there is no F43 kernel on this system. Maybe it got removed when I was trying to get into the graphical interface, or maybe it never got done with the original upgrade.

How should I proceed? Is there a way to install the appropriate kernel and add it to GRUB / make it the default?

9

The kernels in version 42 and 43 are usually the same, but sometimes the 42 version can be newer than the 43 version, and in that case you keep the version 42 kernel until you get an updated 43 kernel.

Do a sudo dnf check to see if there are any problems with the current installation. It may be that the update was completely successful.

2 Likes
10

You should be able to run sudo dnf upgrade kernel\* --refresh and have it install the latest kernel in the updates repo (6.17.12-300.fc43 right now, though 6.18.3 is in updates-testing). It appears that f42 was updated to the 6.17.13 kernel but f43 was not – probably because 6.18.3 was in the works.

If you want to try the one currently in testing try sudo dnf upgrade kernel\* --enablerepo updates-testing. I am actually using the 6.18 kernel right now.

It seems strange that it did not install the f43 kernel with the distro-sync.
Please check exactly which kernels are installed with dnf list --installed kernel

11

Probably something botched the upgrade. Possibly the wine error, though for me that error was seen in the download stage when using dnf system-upgrade and dnf would not continue.

12

Can this problem be caused by a 1GB large /boot partiiton? This was the standard in F42 but in F43 it is now 2GB.

13

Current installed kernel is uname -r returns 6.17.13-200.fc42.x86_64, and so the upgrade won’t upgrade it.

There is not problem to run the 6.17.13 kernel from Fedora 42, so if that is the only issue, there is no issue.

1 Like
14

At work we moved from SGI IRIX64 to macOS for workflows that used Photoshop and Illustrator. At the time, Apple had an excellent command-line document for developers that was also very useful for new Linux users. After Apple stopped maintaining their command-line document, https://LinuxCommand.org became our goto document. Users did need to sort out differences between GNU (Linux) and BSD (macOS) tools with the help of man pages.

1 Like
15

That returns the following:

libbluray-0:1.3.4-11.fc43.x86_64
 duplicate with "libbluray-0:1.3.4-9.fc42.x86_64"
libbluray-0:1.3.4-9.fc42.x86_64
 duplicate with "libbluray-0:1.3.4-11.fc43.x86_64"
Check discovered 2 problem(s) in 2 package(s)

Should I just dnf remove the two fc42 packages? I tried dnf autoremove, but neither was in the removal list. Autoremove listed 41 other packages, all fc43.

As @vekruse mentioned later, this results in “Nothing to do.”

This one is strange to me. Here’s the output:

kernel.x86_64 6.17.12-200.fc42 <unknown>
kernel.x86_64 6.17.12-300.fc43 <unknown>
kernel.x86_64 6.17.13-200.fc42 <unknown>

The first line is highlighted in green, the other two are blue. I don’t know what that means.

Will this be updated automatically in the future when a new stable kernel is released for F43, or will I have to manually upgrade it at that point? I’d really like to ensure my system is “back to normal,” to the extent that is possible.

This system takes a lot longer to boot now, with significant hangs on a black screen before text scrolls and GDM loads. This is not necessarily an issue for me in use, but makes me suspicious that something is still broken.

16

Yes, but it is safer to reinstall. Execute thus: sudo dnf reinstall libbluray

That will normally suppress the fc42 package but ensure also that the fc43 one is properly
installed.

1 Like
17

This is a real issue and this should be fixed.

It is possible that the duplicate can be fixed by the following command

sudo dnf4 remove --duplicates

So far, this functionality seems to be missing in dnf5.

18

The kernel apparently began to be upgraded

This says the f43 kernel meta package was installed, but apparently upgrading the entire kernel group of packages for f43 may have been interrupted so the f42 kernel is still the default. The files needed to allow grub to boot from the f43 kernel apparently did not get properly installed.

If you wish to use the f43 kernel then you probably need to reinstall the kernel packages. The easiest way to do that would be to remove all the fc43 kernel packages the repeat the upgrade. sudo dnf remove kernel*fc43* would remove those packages, then sudo dnf upgrade kernel\* should reinstall the f43 kernel packages and would probably make it the default.

You also could choose to wait until the 6.18 kernel that is still in testing is released then do an upgrade and have that kernel.

$ sudo dnf list --available kernel --enablerepo updates-testing
Updating and loading repositories:
Repositories loaded.
Available packages
kernel.x86_64 6.18.3-200.fc43 updates-testing
19

Thanks to both of you for these suggestions, sudo dnf check comes back clean now.

The first command seemed to work; it removed the f43 kernel and dependent packages, 53 in total. The second command, however, just says “Nothing to do.” Should I have used sudo dnf upgrade kernel\*fc43* or something like that instead?

I tried dnf distro-sync --refresh --releasever=43 just to see what it would do but aborted. It does look like this will reinstall the f43 kernel:

Installing:
 kernel                                   x86_64     6.17.12-300.fc43                           updates                 0.0   B
 kernel-core                              x86_64     6.17.12-300.fc43                           updates                96.9 MiB
 kernel-modules                           x86_64     6.17.12-300.fc43                           updates                95.6 MiB
 kernel-modules-extra                     x86_64     6.17.12-300.fc43                           updates                 4.2 MiB
Installing dependencies:
 kernel-modules-core                      x86_64     6.17.12-300.fc43                           updates                68.3 MiB

However, I don’t know what to think about the other 48 dependent packages that just got removed. Also, the kernel package shown above is 0.0 bytes. That seems wrong to me. Before I commit to trying this command, should I try something else?

20

The kernel package is a metadata package that defines the needed packages for a running system – thus the zero byte size.

The second command (distro-sync) would properly install the kernel for f43.

You should have kept the list of packages being removed, though that info will also be available using dnf history list then identifying the transaction that removed the kernel. Using dnf history info XXX where the XXX is the transaction number of interest will provide the details of the packages managed by that transaction – (installed, upgraded, removed, etc.) and makes it easy to identify and reinstall if the package removed is actually needed.

One example where removal of packages is unnecessary and may be harmful is that if you have a locally compiled kernel driver module (such as nvidia) installed, it seems that removing a kernel version also removes packages that are related such as akmods, akmod-nvidia, etc. Those packages are actually still needed even when a single kernel version is removed, yet dnf offers to remove them.

Usually I either verify that the transaction actually needs to remove the extra packages, or I use the --noautoremove option to prevent unnecessary removal of packages that may be needed elsewhere.

1 Like