Samuel, thanks for response. I would also be very interested in how the problem could have occurred. More in context:
On Sun, 12 Oct 2025 15:22:23 -0700 Samuel Sieb <[email protected]> wrote: > On 10/12/25 3:00 PM, Franta Hanzlík via users wrote: > > Today I did a dnf system-upgrade of the server from Fedora 40 x86_64 > > to Fedora 42. The upgrade went seemingly well, the system booted and > > seems to be working, the kernel and other packages are probably from > > Fedora 42. > > What does the grub menu show? Looks good: kernel 6.16.10-200.fc42.x86_64 at first position, rest are F40 kernels. F42 kernel boots perfectly. > What is in /proc/version? # cat /proc/version Linux version 6.16.10-200.fc42.x86_64 (mockbuild@972f0dab0ea04e12a2a8e0d18dd0050d) (gcc (GCC) 15.2.1 20250808 (Red Hat 15.2.1-1), GNU ld version 2.44-6.fc42) #1 SMP PREEMPT_DYNAMIC Thu Oct 2 19:23:55 UTC 2025 > What is in /etc/fedora-release? # cat /etc/fedora-release Fedora release 42 (Adams) # cat /etc/os-release NAME="Fedora Linux" VERSION="42 (Server Edition)" RELEASE_TYPE=stable ID=fedora VERSION_ID=42 VERSION_CODENAME="" PLATFORM_ID="platform:f42" PRETTY_NAME="Fedora Linux 42 (Server Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:42" HOME_URL="https://fedoraproject.org/"; DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f42/"; SUPPORT_URL="https://ask.fedoraproject.org/"; BUG_REPORT_URL="https://bugzilla.redhat.com/"; REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=42 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=42 SUPPORT_END=2026-05-13 VARIANT="Server Edition" VARIANT_ID=server This machine also serve as personal computer and boot to level 5/ graphical.target, to MATE desktop - and there is F42 background, all works. 'dnf system-upgrade download --releasever=42' ended successfully, 'dnf system-upgrade reboot' performed an upgrade. /var/log/dnf.rpm.log[.1] shows tons lines as: ... dnf.rpm.log.1:2025-10-12T10:44:09+0200 SUBDEBUG Upgrade: qemu-ui-opengl-2:9.2.4-2.fc42.x86_64 dnf.rpm.log.1:2025-10-12T10:44:09+0200 SUBDEBUG Upgrade: php-process-8.4.13-1.fc42.x86_64 dnf.rpm.log.1:2025-10-12T10:44:09+0200 SUBDEBUG Upgrade: php-xml-8.4.13-1.fc42.x86_64 dnf.rpm.log.1:2025-10-12T10:44:09+0200 SUBDEBUG Installed: kernel-modules-core-6.16.10-200.fc42.x86_64 dnf.rpm.log.1:2025-10-12T10:44:12+0200 SUBDEBUG Installed: kernel-core-6.16.10-200.fc42.x86_64 dnf.rpm.log.1:2025-10-12T10:44:15+0200 SUBDEBUG Upgrade: ppp-2.5.1-5.fc42.x86_64 dnf.rpm.log.1:2025-10-12T10:44:15+0200 SUBDEBUG Upgrade: hiredis-1.2.0-6.fc42.x86_64 ... Another thing, I don't know if it might be of any significance: on another machine of mine, where a dnf upgrade was done a few months ago, /var/lib/rpm is a symlink to ../../usr/lib/sysimage/rpm. On this problematic one, /var/lib/rpm is a normal directory and contains: # ls -lia /var/lib/rpm total 609520 262152 drwxr-xr-x. 2 root root 4096 Nov 28 2023 . 262146 drwxr-xr-x. 117 root root 4096 Oct 12 23:21 .. 263688 -rw-r--r--. 1 root root 0 Jun 15 2024 .migratedb 262153 -rw-r--r--. 1 root root 624103424 Jul 25 2024 rpmdb.sqlite 262155 -rw-r--r--. 1 root root 32768 Oct 12 12:50 rpmdb.sqlite-shm 262154 -rw-r--r--. 1 root root 0 Jul 25 2024 rpmdb.sqlite-wal 264701 -rw-r--r--. 1 root root 0 Nov 28 2023 .rpm.lock Normal directory /usr/lib/sysimage/rpm/ exist too and contains: # ls -lia /usr/lib/sysimage/rpm/ total 306124 2621474 drwxr-xr-x. 2 root root 4096 Oct 12 12:50 . 2621660 drwxr-xr-x. 5 root root 4096 Oct 12 23:10 .. 2621641 -rw-r--r--. 1 root root 313425920 Oct 12 12:50 rpmdb.sqlite 2622120 -rw-r--r--. 1 root root 32768 Oct 12 23:22 rpmdb.sqlite-shm 2621650 -rw-r--r--. 1 root root 0 Oct 12 12:50 rpmdb.sqlite-wal but it seems no difference between with rpm queries with '--dbpath /usr/lib/sysimage/rpm' and '--dbpath /var/lib/rpm' > > But what's crazy and I can't explain it - the RPM database shows > > the original packages from Fedora 40 - there are none from Fedora 42. > > I couldn't find another and up-to-date RPM database anywhere on the > > disk. > > > > Can anyone advise the easiest way to reconstruct the RPM database? > > The RPM database is the only source. There's nothing to reconstruct it > from. Yes, I know, but you can do everything in Linux, right? ;) At least there are dnf/rpm upgrade logs that show which packages should be installed. What about taking the RPM DB from another machine and tweaking it accordingly? I don't want to reinstall the server, plus it's 50 km away, no KVM/iLO/ iDRAC. And everything seems to work... -- Franta Hanzlik -- _______________________________________________ users mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
