Upgrade to Fedora 35 failed and Segmentation fault

I’ve tried to upgrade from 34 to 35 following the terminal instructions.
No error shown but I’m still logged into 34.
Furthermore if I try again the dnf system-upgrade I receive a segmentation fault.

Now I’m testing these suggestions.

In the meantime, is there a way to check the logs and understand why the upgrade failed?

I think dnf has its own log file at /var/log/dnf.log.

If things go bad, sometimes something like dnf distro-sync --releasever=35 can put things back in order again.

Edit: If the package database is corrupt, rpmdb --rebuilddb might help. In some extreme cases, it might be necessary to run rm -f /var/lib/rpm/* first.

Edit: The bugzilla report indicates that in some case restorecon -Rv /var/lib/rpm might be necessary before rpmdb --rebuilddb will work.

1 Like

I’m running the command. Consider that I’m still on Fedora 34 at this point. I’m going to confirm the download after the transaction summary… I don’t understand what failed before and what is the difference now but I will try

There were some known glitches in the rpm database format in Fedora Linux 33. They switched to a new format in Fedora Linux 34 (Changes/Sqlite Rpmdb - Fedora Project Wiki). If you’ve been upgrading across those versions, I think there is a chance that the database will need to be regenerated manually (by deleting the files under /var/lib/rpm and running rpmdb --rebuild). It is just a one-off sort of bug that hit a few people depending on what versions of the packages they transitioned through. Once you get it switched to the newer format successfully, everything should be good.

1 Like

Don’t remove anything from /var/lib/rpm or /usr/lib/sysimage/rpm. If you do, dnf and rpm forgets about all installed packages, and that would be bad.

1 Like

Yeah, sorry, I got that command wrong. The FAQ for RPM used to suggest that removing __db.* files from that directory could be helpful in some situations. But I think that information is out of date since Fedora Linux 33 changed the format.

The man page for rpmdb indicates that it can rebuild the database “from the installed package headers”. But I’m not sure where those package headers are archived.

I didn’t remove any files. I only did sudo rpm --rebuilddb but I don’t know if it was fundamental.
Apparently sudo dnf distro-sync --releasever=35 was the solution.

Off Topic
it tooks many hours to upgrade and I’m at the first reboot, I hope everything is actually ok and not slowed down or any other issue… This is an old laptop so I don’t know if keeping Fedora upgraded with new releases in the future, also because I have only 10 GB free space available in my / partition, it was originally a win7 laptop and win7 is still having the biggest partition.

giuliohome@localhost ~]$ ./space.sh 
│ 1 local device                                                  │
│ /root      │ 42.3G │ 30.3G │  9.8G │  71.7% │ ext4 │ /dev/sda7  │
Filesystem     1K-blocks     Used Available Use% Mounted on
/dev/sda7       44340520 31809308  10246412  76% /
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda7        43G   31G  9.8G  76% /
Sat Nov 19 06:56:09 PM CET 2022
[giuliohome@localhost ~]$ ./version_show.sh 
Linux version 6.0.8-100.fc35.x86_64 (mockbuild@bkernel01.iad2.fedoraproject.org) (gcc (GCC) 11.3.1 20220421 (Red Hat 11.3.1-3), GNU ld version 2.37-25.fc35) #1 SMP PREEMPT_DYNAMIC Fri Nov 11 15:25:15 UTC 2022
Fedora release 35 (Thirty Five)

They are stored in the database, and it contains most of the information found in the rpms, except the contents of the installed files.

1 Like

You can try running dnf autoremove to remove “recommended” (but not strictly “required”) packages from your system to slim it down a bit. To prevent “recommended” packages from getting pulled in in the future, you can add the line install_weak_deps=False to /etc/dnf/dnf.conf.

1 Like

That was a bug in the SELinux configuration, and as far as I remember it took about ten years to get fixed.

1 Like

Thanks, eventually I opted out with a no because I imagined that removing 124 packages for only 814 MB was not the case.
Aside from it, thank you all for your help again!

Transaction Summary
Remove  124 Packages

Freed space: 814 M
Is this ok [y/N]: N
Operation aborted.
1 Like