Bug 594519 - filesystem upgrade fails with NFS mounts
Summary: filesystem upgrade fails with NFS mounts
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: rpm
Version: 5.6
Hardware: All
OS: Linux
low
medium
Target Milestone: rc
: ---
Assignee: Packaging Maintenance Team
QA Contact: BaseOS QE Security Team
URL:
Whiteboard:
Depends On: 483071
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-05-20 22:02 UTC by R P Herrold
Modified: 2013-03-07 14:56 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of: 483071
Environment:
Last Closed: 2013-03-07 14:56:02 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description R P Herrold 2010-05-20 22:02:13 UTC
+++ This bug was initially created as a clone of Bug #483071 +++

Description of problem:
Attempting to apply the filesystem update for RHEL5.3 will fail when /home and/or /usr/local are NFS mounted.

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

How reproducible:
always when NFS mounts exist

Steps to Reproduce:
1. # yum -y update filesystem


  Running Transaction
  Updating       : filesystem                                        [1/2] 
Error unpacking rpm package filesystem-2.4.0-2.i386
error: unpacking of archive failed on file /home: cpio: chown

Updated: filesystem.i386 0:2.4.0-2
Complete!

Actual results:


Expected results:
filesystem ignores the error for NFS mounted filesystems.

thanks!
 daryl

--- Additional comment from pknirsch@redhat.com on 2009-02-03 10:56:34 EST ---

Are those /usr/local and/or /home mounted read-only and/or without no_root_squash?

If they are that explains it as rpm will try and update the directory entries during an update of the filesystem component (see the chown error for /home where rpm tries to change the owner of /home).

This problem can be worked around by either unmounting both directories prior to an update or by exporting them with the no_root_squash during the time of the update.

Generally though this is something that needs to be fixed in rpm, so i'm reassigning this bug to the rpm component.

Thanks & regards, Phil

--- Additional comment from akrherz@iastate.edu on 2009-02-03 11:39:54 EST ---

Hi,

Thanks for the response and the work arounds are easy enough.  I still think there is a bug here somewhere :)

1. Eventhough the filesystem rpm install fails,
2. yum will still report an update success
3. yum then updates RHN noting that the filesystem rpm was installed, when
   it actually wasn't...

thanks!
  daryl

--- Additional comment from pknirsch@redhat.com on 2009-02-11 08:14:14 EST ---

*** Bug 484212 has been marked as a duplicate of this bug. ***

--- Additional comment from adam.winberg@smhi.se on 2009-02-11 08:23:05 EST ---

i would not say those workarounds are satisfactory in a large production environment with strict security policies. I think i will wait for an update of the rpm wich resolves this instead, hope to see it soon.

--- Additional comment from pmatilai@redhat.com on 2009-02-11 09:11:14 EST ---

To have rpm semi-reasonably deal with NFS-mounts on rpm "owned" paths, you need to tell rpm about them. This'll tell rpm to avoid touching /home and /usr/local:

# echo "%_netsharedpath /home:/usr/local" > /etc/rpm/macros.nfs

That yum reports success on clearly failed packages is a yum bug (recently been addressed at yum upstream to some extent at least)

--- Additional comment from akrherz@iastate.edu on 2009-02-11 12:21:16 EST ---

Thanks Panu!  I learn something everything day :)

Should this be refiled to the yum component then?

thanks!
  daryl

--- Additional comment from pknirsch@redhat.com on 2009-03-03 08:37:30 EST ---

*** Bug 488229 has been marked as a duplicate of this bug. ***

--- Additional comment from kyle@linuxdork.org on 2009-04-03 18:13:30 EDT ---

This bug will also occur if the immutable flag is set on the root (/) directory.

--- Additional comment from pmatilai@redhat.com on 2009-04-07 11:27:54 EDT ---

*** Bug 489718 has been marked as a duplicate of this bug. ***

--- Additional comment from herrold@owlriver.com on 2009-04-29 12:03:17 EDT ---

This problem continues in RawHide presently 

  Updating       : filesystem                                             2/583
Error unpacking rpm package filesystem-2.4.21-1.fc11.i586
error: unpacking of archive failed on file /home: cpio: chown

with a fstab thus:
#
nfs.first.lan:/home  /home  nfs  rsize=8192,wsize=8192,timeo=14,intr    0 0
xps400.first.lan:/var/ftp/pub/mirror /mnt/nfs/var/ftp/pub/mirror nfs \
   ro,rsize=8192,wsize=8192,timeo=14,intr     0 0
#

and an export:

[herrold@nfs ~]$ cat /etc/exports
#
#       then: /usr/sbin/exportfs -ra
#
/home                   *.first.lan(rw)
#
[herrold@nfs ~]$

so the stock root_squash is (intentionally) in play at the remote NFS server

-- Russ Herrold

--- Additional comment from systems@reservoir.com on 2009-07-23 12:04:32 EDT ---

I'm getting this bug on a Cell blade (QS22) running the PPC version for RHEL 5.

$ sudo yum -y update
Loaded plugins: rhnplugin, security
CellSDK-Open-RHEL-cbea                                   | 1.1 kB     00:00     
CellSDK-Extras-RHEL-cbea                                 | 1.1 kB     00:00     
CellSDK-Devel-RHEL-cbea                                  | 1.1 kB     00:00     
Skipping security plugin, no data
Setting up Update Process
Resolving Dependencies
Skipping security plugin, no data
--> Running transaction check
---> Package filesystem.ppc 0:2.4.0-2 set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

================================================================================
 Package            Arch        Version         Repository                 Size
================================================================================
Updating:
 filesystem         ppc         2.4.0-2         rhel-ppc-server-5         116 k

Transaction Summary
================================================================================
Install      0 Package(s)         
Update       1 Package(s)         
Remove       0 Package(s)         

Total download size: 116 k
Downloading Packages:
filesystem-2.4.0-2.ppc.rpm                               | 116 kB     00:00     
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Updating       : filesystem                                        [1/2] 
Error unpacking rpm package filesystem-2.4.0-2.ppc
error: unpacking of archive failed on file /home: cpio: chown
There was an error communicating with RHN.
Package profile information could not be sent.
Error communicating with server. The message was:

Error Message:
    Unknown package arch found
Error Class Code: 45
Error Class Info: 
     Invalid architecture.

     The architecture of the package is not supported by Red Hat Network
Explanation: 
     An error has occurred while processing your request. If this problem
     persists please enter a bug report at bugzilla.redhat.com.
     If you choose to submit the bug report, please be sure to include
     details of what you were trying to do when this error occurred and
     details on how to reproduce this problem.


Updated: filesystem.ppc 0:2.4.0-2
Complete!

--- Additional comment from ffesti@redhat.com on 2009-09-23 06:01:14 EDT ---

Basically the error message give here is right. Solution is setting netsharedpath to keep rpm out of the mount points.

Of course it would be nicer if rpm could detect such situations before starting the transaction and error out. Adding such check to rpm is out of the scope of a RHEL update release and will be done upstream.

--- Additional comment from herrold@owlriver.com on 2010-05-20 18:00:25 EDT ---

This is Closed/Deferred in the parent but still not solved -- I see similarly #484212 #526368 but the issue is still present in RHEL 5 (.5 update)

-- Russ herrold

Comment 1 R P Herrold 2010-11-04 13:52:27 UTC
Any approach to solving this issue?

Comment 2 R P Herrold 2011-05-26 07:47:02 UTC
This is still observed under 5.6

Any approach to solving this issue?

Comment 3 Panu Matilainen 2011-05-26 09:31:47 UTC
Well, setting %_netsharedpaths works now, in practically all existing rpm versions.

Upstream recently started permitting chmod/chown failure in the case permissions on fs were already identical, which alleviates this issue in many common cases (depending on NFS-mount permissions of course). Backporting can be considered if/when rpm is next scheduled for an update.

Comment 4 Panu Matilainen 2013-03-07 14:56:02 UTC
This request was evaluated by Red Hat Engineering for inclusion in a Red Hat Enterprise Linux maintenance release.

Red Hat does not currently plan to provide this change in a Red Hat Enterprise Linux update release for currently deployed products.

With the goal of minimizing risk of change for deployed systems, and in response to customer and partner requirements, Red Hat takes a conservative approach when evaluating enhancements for inclusion in maintenance updates for currently deployed products. The primary objectives of update releases are to enable new hardware platform support and to resolve critical defects. 

This issue should be fixed in the next major Red Hat Enterprise Linux release, for existing ones the solution is to use %_netsharedpath to exclude nfs-mounts and the like.


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