Red Hat Bugzilla – Bug 808750
Rpm should check for file conflicts within package itself
Last modified: 2012-04-17 00:51:55 EDT
Description of problem:
Ok - today's update of rawhide wasn't the brightest idea of me - however how
rpm-4.9.90-0.git11505.7.fc18 could have made it to the updates - it's not working at all and now I'm quite curious how could I reinstall it in some user-friendly way?
Since all I get with rpm command is like:
error: rpmdbNextIterator: skipping h# 29390 Verify signature: BAD PARAMETERS (269 0x233a720 1 (nil) (nil))
error: rpmdbNextIterator: skipping h# 26832 Verify signature: BAD PARAMETERS (269 0x233a720 1 (nil) (nil))
error: rpmdbNextIterator: skipping h# 30426 Verify signature: BAD PARAMETERS (269 0x233a720 1 (nil) (nil))
error: rpmdbNextIterator: skipping h# 24541 Verify signature: BAD PARAMETERS (269 0x233a720 1 (nil) (nil))
After update files:
were just links point to /lib|/lib64 and effectively pointing recursively to itself.
This rendered my machine quite unusable - login didn't work many other tools failing as well - from single node I've manage to put back in some older file from some older backup - from the moment my system at least works, but rpm is still unusable.
So how can I recover some basic rpm functionality and upgrade to the last version available today: 4.9.90-0.git11505.10.fc18 ??
(I've tried to --rebuilddb - but this just created pretty empty /var/lib/rpm dir - and didn't really helped with:
error: rpm-build-libs-4.9.90-0.git11505.10.fc18.x86_64.rpm: Verify signature: BAD PARAMETERS (269 0x18d120c 1 (nil) (nil))
using options like --nodeps --nodigest seems to be no good enough.
Are there any test being made before issuing update of such important package?
Version-Release number of selected component (if applicable):
Steps to Reproduce:
When NSS is busted then yes, rpm will be very very ill no matter which version. Whether this is due to an rpm bug or something else like remains to be seen.
What did "today's rawhide update" include exactly? Please copy-paste/attach the relevant part of /var/log/yum.log.
FWIW, 'rpm --nosignature --nodigest' might be enough to allow reinstalling the broken nss packages. If not, using rpm2cpio (or as that might fail here too, /usr/lib/rpm/rpm2cpio.sh) to install the broken packages ought to allow getting it back to a functional state.
But more importantly, we need to understand what exactly happened here and how.
Symlinks being involved makes me wonder... rpm doesn't go inventing symlinks out of the blue, and rawhide nss doesn't have any symlinks, hasn't had for a while. Was "todays rawhide update" something like f16 -> rawhide upgrade, involving /usrmove and all? Please provide full details of the steps that lead to this situation.
Created attachment 574410 [details]
Yum log from rawhide upgrade on Mar. 31
Created attachment 574411 [details]
rpm --nodigest --nosignature -qa
list of packages
Without --nodigest --nosignature - I get just tons of:
error: rpmdbNextIterator: skipping h# 25333 Verify signature: BAD PARAMETERS (269 0xb29390 1 (nil) (nil))
Without only --nosignature:
I'm getting mixed listing:
error: rpmdbNextIterator: skipping h# 30143 Verify signature: BAD PARAMETERS (268 0x259da10 536 (nil) 0x25a9d60)
So to fix the system from this:
Download nss-softokn-3.13.3-2.fc18 packages - and replaces those from fc16 update via:
rpm --nodigest --nofiledigest --replacefiles -Uvh nss-softokn*rpm
This seems to fix rpm usability issue.
rpm needs to watch for linking between /lib and /usr/lib after usermove
since updated 'newer' package for fc16 got installed over fc18 version.
Thanks Panu with quick help to resolve this.
So... the issue is installing /usrmove affected package from f16 on a system
where /usrmove conversion has been done:
Mar 31 14:14:33 Updated: nss-softokn-freebl-3.13.3-2.1.fc16.x86_64
In the f16 versions, nss (and various other) packages have symlinks from
/usr/lib(64) to /lib(64):
[root@localhost ~]# ls -l /lib64/*freebl*
-rw-r--r--. 1 root root 478 Mar 10 23:04 /lib64/libfreebl3.chk
-rwxr-xr-x. 1 root root 390288 Mar 10 23:04 /lib64/libfreebl3.so
[root@localhost ~]# ls -l /usr/lib64/*freebl*
lrwxrwxrwx. 1 root root 26 Mar 19 12:24 /usr/lib64/libfreebl3.chk ->
lrwxrwxrwx. 1 root root 25 Mar 19 12:24 /usr/lib64/libfreebl3.so ->
-rw-r--r--. 1 root root 55154 Mar 10 23:04 /usr/lib64/libfreebl.a
...and when /lib(64) is symlinked to /usr/lib(64), the package ends up having a
file conflict with itself, which is a condition no existing rpm version checks
for. The condition is fairly bizarre but doesn't need /usrmove to occur, it
could just as well be a packaging bug, or an admin-created symlink on a system,
of which packagers could not be aware of.
I'll have a look at the rpm side of things, but cc'ing Harald for awareness of
the issue. This could be prevented by having the /usrmove affected packages in
F < 17 explicitly conflict with filesystem >= 3 but that'd require pushing out
a big pile of updates to stable releases in order to prevent what I'd expect to
be a rather rare (and discouraged) setup (running rawhide with f16 updates
Changing the summary to reflect the actual issue, bizarre as it seems...
(In reply to comment #5)
> since updated 'newer' package for fc16 got installed over fc18 version.
Well, this is a user error, because you should _not_ have been able to do this, if you have followed the instructions on:
Yes its a user error, but the warning about mixing packages from older versions could use more visibility perhaps, the issue is not limited to yum distro-upgrades. Prior to /usrmove, mixing up components from here and there hasn't been anywhere near this dangerous as long as dependencies are met and there's zero warning to the user that something could possibly go wrong in this case.
Unfortunately fixing rpm to notice the self-conflict is not the trivial one-liner it should be (due to rpm internals braindamage)
What the Fedora Project although really wants to prevent, is that F16 has a newer package than rawhide. This really sucks for updates. A lot of conflicts have been introduced by such constellations, preventing users from doing a clean update.
(In reply to comment #10)
> What the Fedora Project although really wants to prevent, is that F16 has a
> newer package than rawhide. This really sucks for updates. A lot of conflicts
> have been introduced by such constellations, preventing users from doing a
> clean update.
It's just half of the story - it's not only that package versions in updates are not correct - i.e. nothing prevents making newer package for older distro - but more problematic seems, the often many packages are getting updates only through update repo and rawhide packages are basicaly left unmaintained until package maintainer starts to care before branching is ahead - thus running without updates is quite problematic as well.
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
rpm >= 4.9.90-0.git11536.1.fc18 in rawhide now detects file conflicts on self. I'll consider backporting it to F17 where it would be needed as well, but as the required changes are not entirely trivial, lets give it a bit of rawhide soak-time first.