On 10/28/22 22:53, Todd Zullinger wrote:
Hi, Richard W.M. Jones wrote:https://bugzilla.redhat.com/show_bug.cgi?id=2042147#c2 https://fedoraproject.org/wiki/Changes/RelocateRPMToUsr https://bugzilla.redhat.com/2042099 The RPM database is supposed to move from /var/lib/rpm to /usr/lib/sysimage/rpm. This was supposed to happen automatically when you upgraded the rpm package from an earlier version to 4.17.0-10.fc36 (Feb-Mar 2022). On several machines it is reported that the migration was only half- completed. The symptoms are that the RPM database is still in /var/lib/rpm (/usr contains symlinks to it). See typical output from failed & successful migrations at the end of the email. So _if_ you have rpm >= 4.17.0-10.fc36 installed: - Do you see the symptom of a failed migration? Or does it appear to be successful? (Or neither case??) - Did you: * Install F37 or Rawhide from scratch? * Upgrade using ordinary dnf update or similar? * Upgrade using dnf system-upgrade? * Some other install/upgrade method?I upgraded two systems from f35 to f36 in the past week via dnf system-upgrade. Neither of them completed the rpm migration. I _think_ the issue is due to the version-release in the %triggerun which should enable the rpmdb-migrate service. That is: %triggerun -- rpm < 4.17.0-7 # Handle rpmdb migrate service on erasure of old to avoid ordering issues if [ -x /usr/bin/systemctl ]; then systemctl --no-reload preset rpmdb-migrate ||: fi That was accurate when it was added in 0b9f813 (Migrate rpmdb to /usr/lib/sysimage/rpm (#2042099), 2022-01-26). However, when rpm was updated in f35 in e9927df (Rebase to rpm 4.17.1 (http://rpm.org/wiki/Releases/4.17.1), 2022-07-01), which never had the migration code, it prevented any up-to-date f35 system from triggering the migration. Anyone upgrading from f35 after rpm-4.17.1 was pushed to f35 won't have the rpmdb-migrate service enabled and the database will remain in /var/lib/rpm (with .migratedb) and symlinks in /usr/lib/sysimage/rpm. It seems that it's not so much a failed migration as a migration which is never attempted. :/
Likely in certain situations.What I don't understand is why all the trickery around enabling the service - why not just enable it unconditionally? It already has a condition:
ConditionPathExists=/var/lib/rpm/.migratedb and so won't run multiple times.In my case though it seems to be a product of a bad conditional. I'm running a continually updating rawhide VM and:
Jan 06 10:16:09 vmrawhide-rufous.cora.nwra.com systemd[1]: rpmdb-rebuild.service - RPM database rebuild was skipped because of a failed condition check (ConditionPathExists=/var/lib/rpm/.rebuilddb).
...Feb 06 19:35:14 vmrawhide-rufous.cora.nwra.com systemd[1]: rpmdb-rebuild.service - RPM database rebuild was skipped because of a failed condition check (ConditionPathExists=/var/lib/rpm/.rebuilddb). Feb 08 19:56:31 vmrawhide-rufous.cora.nwra.com systemd[1]: rpmdb-rebuild.service - RPM database rebuild was skipped because of a failed condition check (ConditionPathExists=/usr/lib/sysimage/rpm/.rebuilddb).
...Oct 16 09:47:01 vmrawhide-rufous.cora.nwra.com systemd[1]: rpmdb-rebuild.service - RPM database rebuild was skipped because of a failed condition check (ConditionPathExists=/usr/lib/sysimage/rpm/.rebuilddb). Oct 27 17:32:57 vmrawhide-rufous.cora.nwra.com systemd[1]: rpmdb-rebuild.service - RPM database rebuild was skipped because of an unmet condition check (ConditionPathExists=/usr/lib/sysimage/rpm/.rebuilddb).
# systemctl status rpmdb-rebuild.service ○ rpmdb-rebuild.service - RPM database rebuildLoaded: loaded (/usr/lib/systemd/system/rpmdb-rebuild.service; enabled; preset: enabled)
Active: inactive (dead)
Condition: start condition failed at Thu 2022-10-27 17:32:57 MDT; 1
day 15h ago
Oct 27 17:32:57 vmrawhide-rufous.cora.nwra.com systemd[1]: rpmdb-rebuild.service - RPM database rebuild was skipped because of an unmet condition check (ConditionPathExists=/usr/lib/sysimage/rpm/.rebuilddb).
# ls -la /usr/lib/sysimage/rpm/ total 8 drwxr-xr-x. 2 root root 4096 Oct 5 05:05 . drwxr-xr-x. 3 root root 4096 Aug 9 07:27 ..lrwxrwxrwx. 1 root root 34 Oct 5 20:32 .migratedb -> ../../../../var/lib/rpm/.migratedb lrwxrwxrwx. 1 root root 36 Oct 5 20:32 rpmdb.sqlite -> ../../../../var/lib/rpm/rpmdb.sqlite lrwxrwxrwx. 1 root root 40 Oct 5 20:32 rpmdb.sqlite-shm -> ../../../../var/lib/rpm/rpmdb.sqlite-shm lrwxrwxrwx. 1 root root 40 Oct 5 20:32 rpmdb.sqlite-wal -> ../../../../var/lib/rpm/rpmdb.sqlite-wal lrwxrwxrwx. 1 root root 33 Oct 5 20:32 .rpm.lock -> ../../../../var/lib/rpm/.rpm.lock
# ls -la /var/lib/rpm total 444064 drwxr-xr-x. 2 root root 4096 Feb 6 2022 . drwxr-xr-x. 68 root root 4096 Aug 9 07:27 .. -rw-r--r--. 1 root root 0 Oct 5 20:35 .migratedb -rw-r--r--. 1 root root 454676480 Oct 28 20:27 rpmdb.sqlite -rw-r--r--. 1 root root 32768 Oct 29 08:09 rpmdb.sqlite-shm -rw-r--r--. 1 root root 0 Oct 28 20:27 rpmdb.sqlite-wal -rw-r--r--. 1 root root 0 Feb 6 2022 .rpm.lock -- Orion Poplawski he/him/his - surely the least important thing about me IT Systems Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion@xxxxxxxx Boulder, CO 80301 https://www.nwra.com/
<<attachment: smime.p7s>>
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
