Fedora 36 Beta Install Error

,

I recently tried upgrading from F35 to F36 Beta, and now my computer won’t boot into the graphical desktop. To perform the upgrade, I ran the following before graphically starting the upgrade in Gnome Software:

gsettings set org.gnome.software shot-upgrade-prerelease true

Upon boot, I’m presented with a white screen and a message that says:

“Oh no! Something has gone wrong. A problem has occurred and the system can’t recover. Please contact a system administrator.”

After booting into the system using the “multiuser” target, I tried running a dnf upgrade, but virtually every attempt to interact with dnf returns the following message:

Traceback (most recent call last):
File “/usr/bin/dnf”, line 57, in
from dnf.cli import main
File “/usr/lib/python3.10/site-packages/dnf/init.py”, line 30, in
import dnf.base
File “/usr/lib/python3.10/site-packages/dnf/base.py”, line 29, in
import libdnf.transaction
File “/usr/lib64/python3.10/site-packages/libdnf/init.py”, line 12, in
from . import conf
File “/usr/lib64/python3.10/site-packages/libdnf/conf.py”, line 13, in
from . import _conf
ImportError: libzck.so.1: cannot open shared object file: No such file or directory

Please help me recover from this.

1 Like

They way it is done is
sudo dnf system-upgrade download --releasever 36 and when that completes use sudo dnf system-upgrade reboot .
It is always a good idea to do sudo dnf upgrade --refresh before doing the above 2 steps.

1 Like

Did the upgrade go through correctly? Another user ran into this error here, and it looks like their upgrade was interrupted. You’ll need to reinstall the package to get dnf working again:

Dnf is completely broken: ImportError: /lib64/libzck.so.1: cannot read file data: Is a directory Ask in English f35 dnf 7d - giannissc: /lib64/libzck.so.1: cannot read file data: Is a directory That is indeed very odd as libzck.so should definitely…

The “oh no!..” error is usually caused by some extensions that have not yet been updated to work with the latest Gnome version. When this happens, Gnome disables all your extensions, so hopefully you should be able to login when you try again—if it is an extension related error. You should be able to look at the journal logs to see what’s causing it:

They’ve already run the upgrade using Gnome-software here, so these steps will not help now that dnf is not working.

1 Like

While it’s true that the system-upgrade tool works via the terminal, I should still be able to upgrade graphically using Gnome Software as that’s also a valid upgrade option. There are a lot of casual users will will surely be using the graphical method in the near future once Fedora 36 officially drops.

In any case, my question is regarding how to recover from the state I’m in, not what I should have done.

No, the upgrade doesn’t appear to have gone through correctly. I stepped away from my computer as it was processing the update, and when I returned my computer was displaying the prompt for my drive encryption password.

Before doing anything yesterday, I ran the usual dnf upgrade --refresh command that I usually would when I’ve got a moment to update my system; there were honestly a bunch of things that got installed, including a new kernel release. Unfortunately I didn’t reboot my system after the update before trying to update graphically to Fedora 36. Whether the problem was caused by a kernel issue, or a disparity between the PackageKit cache and the DNF cache is hard to say, but I clearly didn’t follow best practices when I attempted to upgrade my system.

The issue was ultimately caused by a broken symlink at /lib64/libzck.so.1. It was trying to link to a new libzck.so.1.2.1 file that didn’t exist on my system yet. I tried forcing that symlink to point to the old shared object file and running dnf upgrade --refresh again, but that just broke things further.

Unfortunately I ended up doing a clean install of my system. I apologize for abandoning everything in the middle of your help with troubleshooting, but I really needed to log into work this morning. Thank you for all of your help and input.

2 Likes

What I have often seen is that mixing the gnome-software tools with dnf can cause breakage since they use different metadata caches and package storage areas. The failure to reboot after doing the dnf update that included a kernel update also may have contributed.

I never mix the 2 update methods, and always religiously stick to using dnf for all software install and update processes. Gnome-software and dnf are both intended for the same purpose, but use different methods and can conflict in the results.

1 Like