Bug 808750

Summary: Rpm should check for file conflicts within package itself
Product: [Fedora] Fedora Reporter: Zdenek Kabelac <zkabelac>
Component: rpmAssignee: Fedora Packaging Toolset Team <packaging-team>
Status: CLOSED RAWHIDE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: rawhideCC: ffesti, harald, jnovy, pmatilai
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-04-17 00:51:55 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
yum log
none
rpm --nodigest --nosignature -qa none

Description Zdenek Kabelac 2012-03-31 10:05:12 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:
/usr/lib/libfreebl3.chk
/usr/lib/libfreebl3.so
/usr/lib64/libfreebl3.chk
/usr/lib64/libfreebl3.so

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):
rpm.x86_64   4.9.90-0.git11505.7.fc18

How reproducible:


Steps to Reproduce:
1.
2.
3.
  
Actual results:


Expected results:


Additional info:
Comment 1 Panu Matilainen 2012-04-02 00:55:23 EDT
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.
Comment 2 Panu Matilainen 2012-04-02 01:58:06 EDT
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.
Comment 3 Zdenek Kabelac 2012-04-02 02:48:17 EDT
Created attachment 574410 [details]
yum log

Yum log from  rawhide upgrade on Mar. 31
Comment 4 Zdenek Kabelac 2012-04-02 02:50:56 EDT
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:

nss-mdns-0.10-10.fc17.x86_64
rpm-4.9.90-0.git11505.7.fc18.x86_64
error: rpmdbNextIterator: skipping h#   30143 Verify signature: BAD PARAMETERS (268 0x259da10 536 (nil) 0x25a9d60)
pinfo-0.6.10-4.fc17.x86_64
Comment 5 Zdenek Kabelac 2012-04-02 03:40:07 EDT
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.
Comment 6 Panu Matilainen 2012-04-02 03:51:58 EDT
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 ->
../../lib64/libfreebl3.chk
lrwxrwxrwx. 1 root root    25 Mar 19 12:24 /usr/lib64/libfreebl3.so ->
../../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
enabled).
Comment 7 Panu Matilainen 2012-04-02 04:06:31 EDT
Changing the summary to reflect the actual issue, bizarre as it seems...
Comment 8 Harald Hoyer 2012-04-02 05:00:38 EDT
(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:
https://fedoraproject.org/wiki/Upgrading_Fedora_using_yum#Fedora_16_-.3E_Fedora_17
Comment 9 Panu Matilainen 2012-04-02 06:09:42 EDT
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)
Comment 10 Harald Hoyer 2012-04-02 07:35:14 EDT
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.
Comment 11 Zdenek Kabelac 2012-04-02 08:20:27 EDT
(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.
Comment 12 Fedora Admin XMLRPC Client 2012-04-13 19:08:04 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 13 Fedora Admin XMLRPC Client 2012-04-13 19:11:30 EDT
This package has changed ownership in the Fedora Package Database.  Reassigning to the new owner of this component.
Comment 14 Panu Matilainen 2012-04-17 00:51:55 EDT
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.