Bugzilla – Bug 1181044
RPM removes database in %posttrans when bootstrapping with DNF
Last modified: 2021-01-27 16:18:38 UTC
The rpm package post scriptlets do a bad migration rpmdb when bootstrapping with DNF package manager. Zypper and DNF behave slightly different when bootstrapping. Zypper initates the rpmdb in RPM's default location (/var/lib/rpm) and DNF initiates the rpmdb according to the host's `%_dbpath` macro value (/usr/lib/sysimage/rpm). So if one ever tries to bootstrap an openSUSE system using DNF the rpmdb is initated into the correct place from the very beginning to the desired location hence the `%posttrans` rpmdb migration is likely to be unneeded in this case. However the current result is that the rpmdb migration does wrong assumptions and completely erases the whole rpmdb by copying the empty values from `/var/lib/rpm` over the target location `/usr/lib/sysimage/rpm`. This can be easily experimented by installing some stuff into a differet root: $ dnf --installroot=/root/tmp install filesystem openSUSE-release $ rpm --root=/root/tmp -qa # lists all installed packages # Do the same adding rpm package $ dnf --installroot=/root/tmp install filesystem openSUSE-release rpm $ rpm --root=/root/tmp -qa # lists nothing I'd say that rpm scriptlets should be more robust to detect that rpmdb is already in place.
To my knowledge our libzypp developers changed the default location meanwhile, too. Not sure if that already in Factory or on the way to it.
rpm's posttrans scriptlet only does this if there is a database in /var/lib/rpm. So the bug seems to be somewhere else. Please investigate who created that database.
Ok I verified that a command like `dnf --installroot=/root/tmp install filesystem` before running the transaction it actually initiates an empty database at `/var/lib/rpm`. I went through some dnf code down to hawkey interface I believe the database it gets started in the scope of a call to the `load_system_repo` method [1]. [1] https://hawkey.readthedocs.io/en/latest/reference-py-sack.html#hawkey.Sack.load_system_repo I agree with Michael Schröder that this rpm database should not have been created if this is then ignored when running the transaction. To me it looks like some inner tool like libdnf or some other library under it ignores the host %_dbpath macro while running some config evaluation. Adding require info to hawkey maintainers.
We're not doing anything *specific* in DNF to create an rpmdb. When "dnf --installroot" is used, we attempt to probe for the "system repo" (hawkey/libsolv term) and skip it if it's not available yet[1]. The implementation[2] indicates it's all libsolv stuff here. Beyond that, it just calls librpm to execute the transaction, and at that point, librpm initializes the database first, then starts installing RPMs. [1]: https://github.com/rpm-software-management/dnf/commit/dfedde5d87216231bc7e29bd3d359f743200e05f [2]: https://github.com/rpm-software-management/libdnf/blob/e92a15a/libdnf/dnf-sack.cpp#L1693-L1755
Oh, that's right. Older libsolv versions did have /var/lib/rpm pretty much hardcoded. Sorry for missing that. Newer versions obey the rpm macro setting *if the macros are already loaded*. (I think that dnf loads them pretty early, right?) The next version of rpm will also no longer auto-create the database if it does not find it and just a read-only operation is done.
(In reply to Michael Schröder from comment #5) > Oh, that's right. Older libsolv versions did have /var/lib/rpm pretty much > hardcoded. Sorry for missing that. > > Newer versions obey the rpm macro setting *if the macros are already > loaded*. (I think that dnf loads them pretty early, right?) > Yep. We initialize librpm before starting any work, so all those settings are loaded up front. > The next version of rpm will also no longer auto-create the database if it > does not find it and just a read-only operation is done. Right, this should help resolve that problem.
I guess this will remain a problem with Leap 15.3 if we assume this will be fixed with RPM 4.16.1.2 in Tumbleweed? :(
It should work with the updated libsolv >= 0.7.17 in Leap 15.3.