On Sun, 12 Oct 2025 23:13:56 -0700
Samuel Sieb <[email protected]> wrote:
> On 10/12/25 10:08 PM, Franta Hanzlík via users wrote:
> > 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.
>
> That seems like what it should be.
>
> > 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
>
> Those are old, except for the "-shm" file, so that's really weird.
>
> > 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'
> Try moving /var/lib/rpm somewhere else, make the symlink, and see what
> you get.
>
> If you check the upgrade log, is there anything there that would be
> relevant.
>
> After making the symlink, you could try the upgrade again. I expect
> there will a very large number of complaints about missing files, but
> the end result should be ok.
> --
Samuel, thanks for the review.
I finally solved it by taking the RPM DB (from /usr/lib/sysimage/rpm/)
from another F42 machine with a similar package set that was updated
that day, and replacing the bad one on the upgraded machine.
Then was followed by several (few) rounds of "rpm -Va",
"rpm -e [--justdb] ${Package_w_missing_files}", and then additional
installing/reinstalling a few packages - and result seems be good.
Another thing is why the problem (that the RPM DB from F40 remained on
the upgraded F42 system) occurred. Before the system-upgrade I made a
copy of the root (where the /usr and /var directories were) of F40
(cp -ax / /$Some-Free-Partition).
From that it was clear that the real directory /var/lib/rpm (and not
a rel. symlink to /usr/lib/sysimage/rpm) already existed on the old F40
system, and in parallel the RPM DB was in /usr/lib/sysimage/rpm/.
It is probably impossible to find out why the real /var/lib/rpm
directory remained on the machine. In the past, dnf system-upgrade
F38 -> F40 would have been done on it and even earlier F35 -> F38
(I know that it should not be more than over two versions ;).
No errors was visible in the /var/log/dnf.log and /var/log/dnf.rpm.log
logs, it is strange and it raises the possibility that the RPM DB
"returned" to the state in F40 sometime AFTER the system-upgrade.
One possibility is that I unintentionally caused it myself - after
rebooting the upgraded system I wanted to list the presence of some
packages with the command "rpm -qa|grep $something", and this command
took a suspiciously long time, 30-60 sec with about 4000 packages on
a fairly fast machine. I thought that the RPM DB was too bloated and
fragmented, and executed "rpm --rebuilddb" - and that, on the contrary,
ran very quickly, within a few seconds. This could be where the problem
could have occurred.
But I don't want to speculate, the incident is resolved, the lesson
for me is probably that I should check the status of /var/lib/rpm and
/usr/lib/sysimage/rpm before the next system-upgrade...
--
Thanks, 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
