Bug 54878 - filesystem update RPM fails to install cleanly
Summary: filesystem update RPM fails to install cleanly
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: filesystem   
(Show other bugs)
Version: 7.1
Hardware: i686 Linux
medium
medium
Target Milestone: ---
Assignee: Bill Nottingham
QA Contact: Aaron Brown
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-10-22 15:20 UTC by Neil Padgett
Modified: 2014-03-17 02:23 UTC (History)
2 users (show)

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


Attachments (Terms of Use)

Description Neil Padgett 2001-10-22 15:20:36 UTC
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 15:24:58 UTC
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 17:41:06 UTC
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 18:59:17 UTC
What package owns /usr/lib/X11/app-defaults (or the files under it?)

Comment 4 Need Real Name 2001-11-02 19:21:31 UTC
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 20:03:48 UTC
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 20:07:05 UTC
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 20:21:50 UTC
see also bug 54973

Comment 8 Bill Nottingham 2002-01-31 19:06:39 UTC
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.