Bug 249666

Summary: Unable to update files
Product: Red Hat Enterprise Linux 5 Reporter: Need Real Name <lcharters>
Component: nssAssignee: Kai Engert (:kaie) (inactive account) <kengert>
Status: CLOSED NOTABUG QA Contact:
Severity: low Docs Contact:
Priority: low    
Version: 5.0CC: mattdm, ralph+rh-bugzilla
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-08-07 14:15:12 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Need Real Name 2007-07-26 10:41:33 UTC
Description of problem:

Both /usr/lib64/libfreebl3.so and /usr/lib64/libsoftokn3.so cannot be removed or
updated.

Version-Release number of selected component (if applicable):

nss-3.11.5-3.el5

How reproducible:

always

Steps to Reproduce:
1.attempt to upgrade nss
2.
3.
  
Actual results:

error: unpacking of archive failed on file /usr/lib/libfreebl3.so: cpio: rename
failed - Operation not permitted

Expected results:


Additional info: see http://bugs.centos.org/view.php?id=2225

Comment 1 Kai Engert (:kaie) (inactive account) 2007-08-03 16:20:48 UTC
What exact procedure did you use in your package upgrade attempt?
Please elaborate.

According to my testing on RHEL 5, the %pre, %post, %preun scripts used by the
package correctly allow upgrading to packages.

I do not understand why these scripts did not work for you. Did you use a manual
procedure, circumventing the package scripts? That's not supported.

(The only known failure is when DOWNgrading to the initial rhel-5 package, pre
rhel-5-zero-day, which did not yet have those atributes)

Note we plan to remove these attributes soon, see also bug 237350.


Comment 2 Need Real Name 2007-08-04 11:57:21 UTC
Tried to use yum update and rpm -Uvh

This upgrade issue was with the initial RHEL5 day one release nss package.

I'm not authorized to access bug #237350

Comment 3 Matthew Miller 2007-08-04 13:15:03 UTC
also see bug 230545.

Kai: as noted above, we can't see bug bug #237350. Please don't reference
restricted bugs without 1) unrestricting them or 2) at least, summarizing the
relevant part for us "outsiders".

Comment 4 Kai Engert (:kaie) (inactive account) 2007-08-06 12:37:04 UTC
Bug 237350 is complaining that we do have immutable files and that it is causing
some other problems, asking for a way to remove those attributes (which we want
to do).

However, I have not yet heard about issues when upgrading to newer package versions.


Comment 5 Kai Engert (:kaie) (inactive account) 2007-08-06 12:45:20 UTC
(In reply to comment #2)
> Tried to use yum update and rpm -Uvh
> 
> This upgrade issue was with the initial RHEL5 day one release nss package.
> 
> I'm not authorized to access bug #237350


I can only suspect what's going on. I have not heard about this problem with
RHEL versions.

Your scenario was:
- installed: original nss package, not using immutable files
- trying to install: new nss package which uses immutable files

The new package had %pre/%post/%preun scripts that do chattr +i
The new scripts have code to do chattr -i before removing the files.

However, in your scneario, when yum/rpm tried to erase the old files, it might
have been using a script from the old package, which did not yet deal with the
immutable attribute.

But on the other hand, if you had files without immutable installed, why would
there be a problem removing them?


I'm still not absolutely clear what happened.
If you'd like me to try and reproduce, please provide the exact package versions
that you had installed and tried to update to.



Comment 6 Kai Engert (:kaie) (inactive account) 2007-08-06 12:59:52 UTC
I tried, but I can not reproduce your problem.

I restored the original configuration of an install using the original package
versions:
  nss-3.11.5-1.el5

(I did so by using 
  chattr -i /usr/lib{,64}/libfreebl3.so  /usr/lib{,64}/libsoftokn3.so
  rpm -Uvh --oldpackage
)

Next I installed the package versions
  nss-3.11.5-3.el5

This worked fine, no errors.

Are you possibly jumping between initial and more recent package, without
cleaning up the immutable attribute?
That can not work, because the scripts in the original package version are
unable to deal with the immutable attribute.

Unless you can give more evidence, I'd like to resolve this bug as invalid,
because the standard "upgrade to later package" works correctly.

(Note that we do want to remove the immutables attributes soon, which will fix
problems like this one, when going back to older package versions)

Comment 7 Need Real Name 2007-08-06 17:59:28 UTC
I had to use the CentOS5 version of the nss-3.11.5-3.el5.centos.i386.rpm file to
replicate the error as I no longer have the original versions which produced the
anyplace;

$ rpm -qa 'nss*' | sort
nss-3.11.5-3.el5.centos
nss_db-2.2-35.1
nss_ldap-253-3
nss-tools-3.11.5-1.el5

$ sudo rpm -Uvh nss-3.11*.rpm --oldpackage
warning: nss-3.11.5-1.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing...                ########################################### [100%]
   1:nss                    ########################################### [100%]
error: unpacking of archive failed on file /usr/lib/libfreebl3.so: cpio: rename
failed - Operation not permitted

$ sudo chattr -i /usr/lib/libfreebl3.so  /usr/lib/libsoftokn3.so

$ sudo rpm -Uvh nss-3.11*.rpm --oldpackage
warning: nss-3.11.5-1.el5.i386.rpm: Header V3 DSA signature: NOKEY, key ID 37017186
Preparing...                ########################################### [100%]
   1:nss                    ########################################### [100%]

Updating to the latest version works fine after this, I suspect I still had the
older /usr/lib{,64}/libfreebl3.so  /usr/lib{,64}/libsoftokn3.so files inplace
from the RHEL5beta2.

You can find the nss rpm used to replicate the error here:

http://isoredirect.centos.org/centos/5/updates/


Comment 8 Kai Engert (:kaie) (inactive account) 2007-08-07 14:15:12 UTC
Yes, your observed behavior from comment 7 is expected, as I described in comment 6.

Resolving as NOTABUG.

I know, it's unfortunate that we had to use a workaround with such consequences,
but highest priority was fixing a collision between prelink and nss, and the
fastest fix was using the attributes.

We will get rid of the attributes, you'll eventually see it when a new nss
update package gets published.