Bug 54878 - filesystem update RPM fails to install cleanly
filesystem update RPM fails to install cleanly
Status: CLOSED NOTABUG
Product: Red Hat Linux
Classification: Retired
Component: filesystem (Show other bugs)
7.1
i686 Linux
medium Severity medium
: ---
: ---
Assigned To: Bill Nottingham
Aaron Brown
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2001-10-22 11:20 EDT by Neil Padgett
Modified: 2014-03-16 22:23 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2001-12-03 15:21:55 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Neil Padgett 2001-10-22 11:20:36 EDT
From Bugzilla Helper:
User-Agent: Mozilla/4.77 [en] (X11; U; Linux 2.4.9-6 i686)

Description of problem:
When attempting to install the updated filesystem RPM
(filesystem-2.1.0-2.1.noarch.rpm) currently available via RHN on a system
where /home is a remote filesystem mounted via NFS, the RPM fails to
install cleanly.

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


How reproducible:
Always

Steps to Reproduce:
1. Configure a Red Hat Linux 7.1 system where /home is a remote filesystem
mounted via NFS.
2. As root, attempt to apply the RPM filesystem-2.1.0-2.1.noarch.rpm .

Actual Results:  The error produced is:
error: unpacking of archive failed on file /home: cpio: chown failed -
Operation not permitted



Expected Results:  The RPM should apply cleanly. If necessary, steps to
umount the filesystem, make necessary changes, and then remote it again,
should be taken.

A manual work around is to manually umount such filesystems before
installing the RPM.

Additional info:

The permissions on /home are:
drwxr-xr-x   

Owner and group are root.

The RPM was applied already using the above work around.
Comment 1 Bill Nottingham 2001-10-22 11:24:58 EDT
This is not something that can really be fixed in the context of this particular
RPM; checking all filesystems and trying to figure out which to umount is way
too much hackage for a %pre/%post. You might try setting your netsharedpath in RPM.
Comment 2 Need Real Name 2001-11-02 12:41:06 EST
I received a similar error, however, this was on /usr/lib/X11

unpacking of archive failed on file /usr/lib/X11: cpio: unlink failed - Is a directory

We don't have X installed on this box, just Xfree86-libs

ls -ld /usr/lib/X11
drwxr-xr-x    3 root     root         4096 Oct 17 13:12 /usr/lib/X11/

ls-l /usr/lib/X11
drwxr-xr-x    2 root     root         4096 Oct 17 13:12 app-defaults

Comment 3 Bill Nottingham 2001-11-02 13:59:17 EST
What package owns /usr/lib/X11/app-defaults (or the files under it?)
Comment 4 Need Real Name 2001-11-02 14:21:31 EST
Its a third party rpm, legato networker. Specifically, lgtoclnt-6.1-1

If its their problem and not yours, what do we need to tell legato to do?
Comment 5 Frank Ch. Eigler 2001-12-03 15:03:48 EST
This problem is especially nasty in that, if one takes one proposed workaround
and applies the filesystem rpm update with "--justdb", a subsequent boot with
a modern kernel can hang (failing root pivot).  The "/initrd" new top level
directory is now essential.
Comment 6 Bill Nottingham 2001-12-03 15:07:05 EST
As for legato, tell them to not package something under /usr/lib/X11; have them
package it with it as the standard /usr/X11R6/lib/X11

Does the netsharedpath setting not work?
Comment 7 Frank Ch. Eigler 2001-12-03 15:21:50 EST
see also bug 54973
Comment 8 Bill Nottingham 2002-01-31 14:06:39 EST
This is not a Red Hat issue, and requiring the /initrd directory to be present
is not a bug.

Note You need to log in before you can comment on or make changes to this bug.