It booted into a Gnome session. At the last command, at deleting various fc37 packages X suddenly died. I rebooted to no X. Using a console I typed startx. It opened a KDE session. It seems that removing a fc37 package damaged Gnome. I found that the running programs: the kernel, gcc, evince etc. belong to fc39. However, dnf and rpm refer to fc37. The following files all refer to fc39:
/etc/fedora-release ; /etc/redhat-release ; /usr/lib/os-release ; /usr/lib/fedora-release
Where does dnf take the release number 37 and how can I re-configure it to 39?
Help will be much appreciated. Thanks!
I attach the results of the commands suggested by Vladislav:
xxx@localhost:~$ hostnamectl status
Static hostname: localhost.localdomain
Transient hostname: fedora
Icon name: computer-desktop
Chassis: desktop 🖥
Machine ID: 9103d... skipped
Boot ID: 7e280cb5... skipped
Operating System: Fedora Linux 39 (MATE-Compiz)
CPE OS Name: cpe:/o:fedoraproject:fedora:39
OS Support End: Tue 2024-11-12
OS Support Remaining: 7month 1d
Kernel: Linux 6.8.4-200.fc39.x86_64
Architecture: x86-64
Hardware Vendor: Dell Inc.
Hardware Model: Inspiron 3847
......
xxx@localhost:~$ dnf repolist
repo id repo name
Dropbox Dropbox Repository
adobe-linux-x86_64 Adobe Systems Incorporated
fedora Fedora 37 - x86_64
fedora-cisco-openh264 Fedora 37 openh264 (From Cisco) - x86_64
rpmfusion-free RPM Fusion for Fedora 37 - Free
rpmfusion-free-updates RPM Fusion for Fedora 37 - Free - Updates
rpmfusion-nonfree RPM Fusion for Fedora 37 - Nonfree
rpmfusion-nonfree-updates RPM Fusion for Fedora 37 - Nonfree - Updates
updates Fedora 37 - x86_64 - Updates
xxx@localhost:~$ dnf repoquery --extras
Adobe Systems Incorporated
Dropbox Repository
Fedora 37 - x86_64 - Updates
RPM Fusion for Fedora 37 - Free - Updates
RPM Fusion for Fedora 37 - Nonfree - Updates
astronomy-bookmarks-0:1-23.fc32.noarch
xxdiff-0:4.0.1-10.fc37.x86_64
xxdiff-debuginfo-0:4.0.1-10.fc37.x86_64
**Command suggested by Igor ** I try dnf distro-sync on a package cheese:
root@localhost:/home/xxx# dnf list --releasever=39 cheese
Last metadata expiration check: 0:15:13 ago on Wed 10 Apr 2024 07:38:56 PM EDT.
Installed Packages
cheese.x86_64 2:43~alpha-2.fc37 @fedora
Available Packages
cheese.x86_64 2:44.1-1.fc39 fedora
root@localhost:/home/xxx# cheese --version
Cheese 44.1
root@localhost:/home/gen# dnf distro-sync cheese
Last metadata expiration check: 1:12:23 ago on Wed 10 Apr 2024 06:44:49 PM EDT.
Dependencies resolved.
Nothing to do.
Complete!
root@localhost:/home/gen# dnf list cheese
Last metadata expiration check: 1:13:16 ago on Wed 10 Apr 2024 06:44:49 PM EDT.
Installed Packages
cheese.x86_64 2:43~alpha-2.fc37 @fedora
root@localhost:/home/gen# cheese --version
Cheese 44.1
It looks like the cheese exacutable installed belongs to fc39, but dnf thinks that it belongs to fc37.
Perhaps, when X died on the remove-retired-packages 37 command, the command was killed and something was corrupted in the package database. dnf distro-sync --releasever=39 cheese prompted a change of glibc and other libraries to fc39. I am wary at this time that it would crash the OS completely.
I tried the suggested command to a bizarre effect. # dnf distro-sync --refresh --releasever=39 cheese
It said that it replaced several fc37 packages by the fc39 ones. Indeed:
Then I ran # dnf distro-sync --refresh --releasever 39 --allowerasing
It has downloaded 3500 fc39 packages, ran transaction, cleanups etc. An finally it came to exactly the initial situation: dnf and rpm see no fc39 packages installed. They see only the fc37 packages. The versions of the executable programs: the running kernel, gcc etc belong to fc39.
I have not noticed any problem in /var/log/dnf.log (a piece is enclosed):
I ran the cheese replacement again, and after that dnf reported again that cheese, glibc and a few other libraties come from fc39. Somehow the change of everything restored the obsolete fc37 reference, but the change of one package produced the correct one.
One thing has been fixed as a result of this exercise - Gnome started working again. Still, no X window manager on reboots, though it seems that the level 5 is set.
dnf log is very verbose and adds this word DEBUG or DDEBUG to about half of all lines. I do not know what it means. Perhaps, it is a level of logging. It is not a new feature - I now see the same thing in the logs from 2019.
I noticed that rpm --rebuilddb produced an error, and a window message flashed saying something about selinux. I found a note about such a case https://discussion.fedoraproject.org/t/problem-with-rpm-rebuilddb-after-dnf-system-upgrade-from-f35-to-f36/78152
The installation manual recommends to relabel selinux by fixfiles -B onboot and reboot. I did that and without any other action, miraculously, rpm and dnf started seeing fc39 as the default release. They showed that about 15% of packages still came from fc37. I ran again:
# remove-retired-packages 37 # - removed a few
# dnf distro-sync
These commands seemed to be doing right things, installing fc39 and removing fc37. BUT after that dnf and rpm went again to the fc37 default, showing all the installed packages as coming from fc37, while they (at least many of them) come from fc39. I tried # rpm --rebuilddb - it did not show errors, but did not help either.
root@localhost:/home/gen# dnf distro-sync --refresh
Adobe Systems Incorporated 8.6 kB/s | 2.9 kB 00:00
Dropbox Repository 13 kB/s | 1.5 kB 00:00
Fedora 37 - x86_64 63 kB/s | 24 kB 00:00
Fedora 37 openh264 (From Cisco) - x86_64 12 kB/s | 989 B 00:00
Fedora 37 - x86_64 - Updates 201 kB/s | 23 kB 00:00
RPM Fusion for Fedora 37 - Free 10 kB/s | 3.6 kB 00:00
RPM Fusion for Fedora 37 - Free - Updates 26 kB/s | 3.3 kB 00:00
RPM Fusion for Fedora 37 - Nonfree 18 kB/s | 6.8 kB 00:00
RPM Fusion for Fedora 37 - Nonfree - Updates 16 kB/s | 6.3 kB 00:00
Error:
Problem: The operation would result in removing the following protected packages: dnf
(try to add '--skip-broken' to skip uninstallable packages)
I am not sure what it may do. dnf and rpm (the database in /etc/lib/sysimage/) think that all the packages belong to fc37. Would it remove all them? There is no need to remove dnf, since it comes from fc39. Another option: # dnf distro-sync --refresh --releasever=39
suggested to upgrade everything:
Transaction Summary
===================================
Install 168 Packages
Upgrade 3721 Packages
Remove 13 Packages
Total download size: 4.6 G
Is this ok [y/N]: n
Operation aborted.
Total download size: 4.6 G
Is this ok [y/N]: n
Operation aborted.
I have done it once (described above) but the database returned to the wrong state.
Again, all (or nearly all) the installed packages come from fc39. The database is confused.
Another observation described above: after “replacing” a particular package with: # dnf distro-sync --refresh --releasever=39 cheese
the database remembers that this package comes from fc39.
This looks like the rpm database has not been proper migrated.
/var/lib/rpm should be a symbolic link to ../../usr/lib/sysimage/rpm and the files in /usr/lib/sysimage/rpm should be real files and not symbolic links.
So, the database is duplicated - no symlinks. About the dates: I started the fc39 installation on Apr 6th. In /usr/lib/sysimage there are older versions:
The symlinks in the older databases’ directories all refer to the same files /var/lib/rpm/. In one directory (rpmold.4015460) the links were created before the fc39 upgrade. Others seem to be created during and after the change. What is the right place for the symlinks - in /usr/lib/sysimage/rpm or in /var/log/rpm ? The files rpmdb.sqlite in these two places are different. One in /var is bigger and older, but both were created after the upgrade.
Indeed, it looks like some installation scripts have failed to complete. I wonder it it can be fixed or it would be better to install fc39 as a new system. It has been a while since I did it the last time, configuring the software raid etc.
