I don't know if it's a bug or a feature, but the filesystem-2.4.0-2.el5.centos rpm won't upgrade cleanly if /home is an NFS filesystem.
I sorta-kinda remember this when going from 5.1 to 5.2, but that memory is hazy.
On Wed, 1 Apr 2009, Paul Heinlein wrote:
I don't know if it's a bug or a feature, but the filesystem-2.4.0-2.el5.centos rpm won't upgrade cleanly if /home is an NFS filesystem.
I confirm this is present in 5.3 where /home is an NFS mount, and that I missed it in testing. A workaround is:
1. Boot into single user node. 2. run: /sbin/service network start 3. run: yum -y update filesystem
If your system emitted the warning, but did not 'bail', it is safe to retieve the rpm locally, and to run:
# rpm -Uvh filesystem*rpm --force
as there are no scripts in play:
[herrold@centos-5 ~]$ sudo rpm -q --scripts filesystem [herrold@centos-5 ~]$
The cause is the NFS root_squash being in effect when a NFS overmount is on a mountpoint, it seems. /home happens to express it
It seems Paul and I are the last two users of NFS mounted /home left.
-- Russ herrold
On Thu, 2 Apr 2009, R P Herrold wrote:
It seems Paul and I are the last two users of NFS mounted /home left.
Say it ain't so!
Paul Heinlein wrote:
On Thu, 2 Apr 2009, R P Herrold wrote:
It seems Paul and I are the last two users of NFS mounted /home left.
Say it ain't so!
It ain't so.
I've got 7 machines here with NFSed /home (and the same problem with the filesystem rpm).
Should I implement the workaround suggested by Russ for each machine, or will a fixed rpm come along eventually? (I'm not impatient!)
Hywel.
On Thu, 2 Apr 2009, Hywel Richards wrote:
It seems Paul and I are the last two users of NFS mounted /home left.
Say it ain't so!
It ain't so.
:-)
I've got 7 machines here with NFSed /home (and the same problem with the filesystem rpm).
Should I implement the workaround suggested by Russ for each machine, or will a fixed rpm come along eventually? (I'm not impatient!)
I just kicked everyone off, killed all apps with open file descriptors on /home, umounted /home, upgraded the rpm, then re-mounted /home. That worked just fine.
On Thu, 2 Apr 2009, Paul Heinlein wrote:
I just kicked everyone off, killed all apps with open file descriptors on /home, umounted /home, upgraded the rpm, then re-mounted /home. That worked just fine.
I confer 42 geek points on Paul -- hope that's enough to buy armor to protect him from the horde of angry users coming up the LTSP path with torches and pitchforks after him. ;)
-- Russ herrold
R P Herrold wrote:
On Thu, 2 Apr 2009, Paul Heinlein wrote:
I just kicked everyone off, killed all apps with open file descriptors on /home, umounted /home, upgraded the rpm, then re-mounted /home. That worked just fine.
I confer 42 geek points on Paul -- hope that's enough to buy armor to protect him from the horde of angry users coming up the LTSP path with torches and pitchforks after him. ;)
-- Russ herrold
I think those should be BOFH points instead. http://pages.cs.wisc.edu/~ballard/bofh/bofhserver.pl
On Thu, 2 Apr 2009, Les Mikesell wrote:
R P Herrold wrote:
On Thu, 2 Apr 2009, Paul Heinlein wrote:
I just kicked everyone off, killed all apps with open file descriptors on /home, umounted /home, upgraded the rpm, then re-mounted /home. That worked just fine.
I confer 42 geek points on Paul -- hope that's enough to buy armor to protect him from the horde of angry users coming up the LTSP path with torches and pitchforks after him. ;)
-- Russ herrold
I think those should be BOFH points instead. http://pages.cs.wisc.edu/~ballard/bofh/bofhserver.pl
A developer got me a BOFH ribbon at some conference, which I displayed proudly in my cube, but it got lost when we moved offices last summer. Now I just have my Mr. Potato Head "Darth Tater" stare menacingly at visitors. :-)
On Thu, 2 Apr 2009, Hywel Richards wrote:
I've got 7 machines here with NFSed /home (and the same problem with the filesystem rpm).
Should I implement the workaround suggested by Russ for each machine, or will a fixed rpm come along eventually? (I'm not impatient!)
Thank you for the confirmation, I have not had a chance to file in the centos tracker yet, and hope to get it filed tomorrow's business hours. Similarly I have not checked upstream's tracker yet. If needee, I'll file there as well, but I cannot imagine it will be deemed so critical as to pull a fast fix.
The fix will not be unilaterally placed in 'updates' by the CentOS team; we will note issue [ahh, I need to edit the online release notes -- good thing the wiki page reminds users to check back from time to time]
The takeaway is to use the process I outlined, and all should be fine. There are some more complex ways to do it by tracking down and clearing all processes reaching into /home and holding flies, but not worth the geek points being able to explain it confer.
-- Russ herrold
R P Herrold wrote:
Thank you for the confirmation, I have not had a chance to file in the centos tracker yet, and hope to get it filed tomorrow's business hours. Similarly I have not checked upstream's tracker yet. If needee, I'll file there as well, but I cannot imagine it will be deemed so critical as to pull a fast fix.
Found this on upstream bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=483071
-Liming
On Fri, 3 Apr 2009, Tsai Li Ming wrote:
Found this on upstream bugzilla: https://bugzilla.redhat.com/show_bug.cgi?id=483071
Good catch! Panu Matilainen posted what appears to be the answer, though I haven't tested it yet:
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
On Thursday 02 April 2009 21:40:59 R P Herrold wrote:
On Wed, 1 Apr 2009, Paul Heinlein wrote:
I don't know if it's a bug or a feature, but the filesystem-2.4.0-2.el5.centos rpm won't upgrade cleanly if /home is an NFS filesystem.
I confirm this is present in 5.3 where /home is an NFS mount, and that I missed it in testing. A workaround is:
- Boot into single user node.
- run: /sbin/service network start
- run: yum -y update filesystem
If your system emitted the warning, but did not 'bail', it is safe to retieve the rpm locally, and to run:
# rpm -Uvh filesystem*rpm --force
as there are no scripts in play:
[herrold@centos-5 ~]$ sudo rpm -q --scripts filesystem [herrold@centos-5 ~]$
The cause is the NFS root_squash being in effect when a NFS overmount is on a mountpoint, it seems. /home happens to express it
It seems Paul and I are the last two users of NFS mounted /home left.
I have /home exported and ran the upgrade from this laptop over the network, where that directory is mounted and displayed in a folderview under KDE4. I had no problems whatsoever. Is this the sort of situation you mean?
Anne
on 4-2-2009 2:00 PM Anne Wilson spake the following:
On Thursday 02 April 2009 21:40:59 R P Herrold wrote:
On Wed, 1 Apr 2009, Paul Heinlein wrote:
I don't know if it's a bug or a feature, but the filesystem-2.4.0-2.el5.centos rpm won't upgrade cleanly if /home is an NFS filesystem.
I confirm this is present in 5.3 where /home is an NFS mount, and that I missed it in testing. A workaround is:
- Boot into single user node.
- run: /sbin/service network start
- run: yum -y update filesystem
If your system emitted the warning, but did not 'bail', it is safe to retieve the rpm locally, and to run:
# rpm -Uvh filesystem*rpm --force
as there are no scripts in play:
[herrold@centos-5 ~]$ sudo rpm -q --scripts filesystem [herrold@centos-5 ~]$
The cause is the NFS root_squash being in effect when a NFS overmount is on a mountpoint, it seems. /home happens to express it
It seems Paul and I are the last two users of NFS mounted /home left.
I have /home exported and ran the upgrade from this laptop over the network, where that directory is mounted and displayed in a folderview under KDE4. I had no problems whatsoever. Is this the sort of situation you mean?
Anne
The way I read it was their /home was mounted on NFS, not just exported.
Scott Silva wrote:
on 4-2-2009 2:00 PM Anne Wilson spake the following:
On Thursday 02 April 2009 21:40:59 R P Herrold wrote:
On Wed, 1 Apr 2009, Paul Heinlein wrote:
I don't know if it's a bug or a feature, but the filesystem-2.4.0-2.el5.centos rpm won't upgrade cleanly if /home is an NFS filesystem.
I confirm this is present in 5.3 where /home is an NFS mount, and that I missed it in testing. A workaround is:
- Boot into single user node.
- run: /sbin/service network start
- run: yum -y update filesystem
If your system emitted the warning, but did not 'bail', it is safe to retieve the rpm locally, and to run:
# rpm -Uvh filesystem*rpm --force
as there are no scripts in play:
[herrold@centos-5 ~]$ sudo rpm -q --scripts filesystem [herrold@centos-5 ~]$
The cause is the NFS root_squash being in effect when a NFS overmount is on a mountpoint, it seems. /home happens to express it
It seems Paul and I are the last two users of NFS mounted /home left.
I have /home exported and ran the upgrade from this laptop over the network, where that directory is mounted and displayed in a folderview under KDE4. I had no problems whatsoever. Is this the sort of situation you mean?
Anne
The way I read it was their /home was mounted on NFS, not just exported.
I had a problem with /mnt or /media too with a mounted ISO. Had to umount the ISO before filesystem rpm can be updated. This happened when I yum update to RHEL 5.3 recently.
-Liming
Tsai Li Ming wrote:
Scott Silva wrote:
on 4-2-2009 2:00 PM Anne Wilson spake the following:
On Thursday 02 April 2009 21:40:59 R P Herrold wrote:
On Wed, 1 Apr 2009, Paul Heinlein wrote:
I don't know if it's a bug or a feature, but the filesystem-2.4.0-2.el5.centos rpm won't upgrade cleanly if /home is an NFS filesystem.
I confirm this is present in 5.3 where /home is an NFS mount, and that I missed it in testing. A workaround is:
- Boot into single user node.
- run: /sbin/service network start
- run: yum -y update filesystem
If your system emitted the warning, but did not 'bail', it is safe to retieve the rpm locally, and to run:
# rpm -Uvh filesystem*rpm --force
as there are no scripts in play:
[herrold@centos-5 ~]$ sudo rpm -q --scripts filesystem [herrold@centos-5 ~]$
The cause is the NFS root_squash being in effect when a NFS overmount is on a mountpoint, it seems. /home happens to express it
It seems Paul and I are the last two users of NFS mounted /home left.
I have /home exported and ran the upgrade from this laptop over the network, where that directory is mounted and displayed in a folderview under KDE4. I had no problems whatsoever. Is this the sort of situation you mean?
Anne
The way I read it was their /home was mounted on NFS, not just exported.
I had a problem with /mnt or /media too with a mounted ISO. Had to umount the ISO before filesystem rpm can be updated. This happened when I yum update to RHEL 5.3 recently.
My guess is a scriptlet is failing - quite possibly because an SELinux chcon command fails in those conditions. They probably need to change the chcon portion of the scriptlet to add a ||: after the command so it doesn't bomb out.
Someone should take a look at the spec file, add the ||: after the chcon (or whatever it might be) and if it allow the package to update, file a bug report upstream so it gets fixed in rhel svn.
On Thu, 2 Apr 2009, Michael A. Peters wrote:
My guess is a scriptlet is failing - quite possibly because an SELinux chcon command fails in those conditions. They probably need to change the chcon portion of the scriptlet to add a ||: after the command so it doesn't bomb out.
Guessing is fun and good exercise, but I addressed this matter in the initial post responding to Paul
as there are no scripts in play:
[herrold@centos-5 ~]$ sudo rpm -q --scripts filesystem [herrold@centos-5 ~]$
-- Russ herrold
R P Herrold wrote:
On Thu, 2 Apr 2009, Michael A. Peters wrote:
My guess is a scriptlet is failing - quite possibly because an SELinux chcon command fails in those conditions. They probably need to change the chcon portion of the scriptlet to add a ||: after the command so it doesn't bomb out.
Guessing is fun and good exercise, but I addressed this matter in the initial post responding to Paul
Yeah, looks like I missed the mark on that one big time.
On Thu, 2 Apr 2009, Anne Wilson wrote:
It seems Paul and I are the last two users of NFS mounted /home left.
I have /home exported and ran the upgrade from this laptop over the network, where that directory is mounted and displayed in a folderview under KDE4. I had no problems whatsoever. Is this the sort of situation you mean?
yup -- exports to another would not be affected by root_squash.
To some degree, the fact that upstream did not detect the issue, and I missed it in testing, was a wry observation that the 'old ways' of a common set of /home/ exported from a very reliably 'up' box through an office, is passing away.
The takeaway was that I need to 'test as I do, and do as I test'. My testing regime will have to include 'cloning' a test box, and simply 'moving into it' for an afternoon when doing 'updates' QA testing.
-- Russ herrold
On Friday 03 April 2009 05:11:15 R P Herrold wrote:
On Thu, 2 Apr 2009, Anne Wilson wrote:
It seems Paul and I are the last two users of NFS mounted /home left.
I have /home exported and ran the upgrade from this laptop over the network, where that directory is mounted and displayed in a folderview under KDE4. I had no problems whatsoever. Is this the sort of situation you mean?
yup -- exports to another would not be affected by root_squash.
To some degree, the fact that upstream did not detect the issue, and I missed it in testing, was a wry observation that the 'old ways' of a common set of /home/ exported from a very reliably 'up' box through an office, is passing away.
The takeaway was that I need to 'test as I do, and do as I test'. My testing regime will have to include 'cloning' a test box, and simply 'moving into it' for an afternoon when doing 'updates' QA testing.
I took it for granted that CentOS would be server, not client. Silly to assume anything, I guess.
Anne
Anne Wilson wrote:
On Friday 03 April 2009 05:11:15 R P Herrold wrote:
On Thu, 2 Apr 2009, Anne Wilson wrote:
It seems Paul and I are the last two users of NFS mounted /home left.
I have /home exported and ran the upgrade from this laptop over the network, where that directory is mounted and displayed in a folderview under KDE4. I had no problems whatsoever. Is this the sort of situation you mean?
yup -- exports to another would not be affected by root_squash.
To some degree, the fact that upstream did not detect the issue, and I missed it in testing, was a wry observation that the 'old ways' of a common set of /home/ exported from a very reliably 'up' box through an office, is passing away.
The takeaway was that I need to 'test as I do, and do as I test'. My testing regime will have to include 'cloning' a test box, and simply 'moving into it' for an afternoon when doing 'updates' QA testing.
I took it for granted that CentOS would be server, not client. Silly to assume anything, I guess.
I've found it somewhat useful in development/test scenarios to export /home via nfs and samba from a physical machine, then use one or more vmware guests with the testing framework that mount the shared /home with the developers using the vmware guest machine for their work. The guests often run on the same physical host as the home directories but are somewhat disposable and easy to replace. The samba share from the physical side is more efficient than doing it from a guest and gives windows users easy access.
On Fri, 3 Apr 2009, Anne Wilson wrote:
The takeaway was that I need to 'test as I do, and do as I test'. My testing regime will have to include 'cloning' a test box, and simply 'moving into it' for an afternoon when doing 'updates' QA testing.
I took it for granted that CentOS would be server, not client. Silly to assume anything, I guess.
* nod * we tend to forget our culture's history
I have used Linux as my desktop ( and CentOS as the lead one since the death of RHL ) that I can only stare in wonderment at people who do _not_ use it as their stable production environment, or those sell it but do not believe in it [1].
'Back in the day when dinosaurs roamed the earth,' Bank One, (now rolled up in JPMorgan Chase) ran X-tops at the C level on down, because it was the full featured (for the day) GUI window environment that 'just worked' [and no other credible alternative existed]; on a walk through I did at the NYSE trading floor two years ago, X based Motif windowed applications abounded at the trading posts; ditto at the CME for options traders. Not the sole platform any more of course, but clearly suitable for mission critical with major real money.
Note that I am not saying a ephemeral 'distro du jour' is suitable, but clearly, despite what some upstream might say, it 'just works' ;)
"The craft lives so long as it is remembered, but the children can only stare in wonderment at the Easter Island stone heads, unable to summon the spirits" -- NFS homes is part of that culture
-- Russ herrold
[1] http://www.infoworld.com/article/09/03/25/Red-Hat-CEO-questions-desktops-rel... Red Hat's CEO Jim Whitehurst pointed out several issues with running Linux on the desktop, including financial concerns the company has as a Linux vendor.
"First of all, I don't know how to make money on it," Whitehurst said. "Very few people are running a desktop that's mission-critical," so they do not want to pay the company for a desktop OS, he said.
Query: Isn't making money on a desktop, orthogonal to its suitability ... unless one is just in it for the money? sad that is the 'first of all' objection.
R P Herrold wrote:
On Wed, 1 Apr 2009, Paul Heinlein wrote:
I don't know if it's a bug or a feature, but the filesystem-2.4.0-2.el5.centos rpm won't upgrade cleanly if /home is an NFS filesystem.
I confirm this is present in 5.3 where /home is an NFS mount, and that I missed it in testing. A workaround is:
- Boot into single user node.
- run: /sbin/service network start
- run: yum -y update filesystem
If your system emitted the warning, but did not 'bail', it is safe to retieve the rpm locally, and to run:
# rpm -Uvh filesystem*rpm --force
I have te same problem, an NFS mounted home share with root_squash. Yum ignores the package, so I downloaded it and tried it with rpm:
[root@raaf ~]# rpm -Uvh --force filesystem-2.4.0-2.el5.centos.i386.rpm Preparing... ########################################### [100%] 1:filesystem ########################################### [100%] error: unpacking of archive failed on file /home: cpio: chown failed - Operation not permitted
But the package is still not installed (I don't know what you mean with 'bail' by the way). Is there another way to get this installed? Is there perhaps an option to ignore any errors and just install (apparently --force does not do that). Unmounting is not an option, too many users on the machine. So a reboot would be needed. As someone else mentioned, waiting a couple of weeks is also an option, if it get's fixed in the end.
Theo
On Thu, 2 Apr 2009, Olaf Mueller wrote:
Paul Heinlein wrote:
I don't know if it's a bug or a feature, but the filesystem-2.4.0-2.el5.centos rpm won't upgrade cleanly if /home is an NFS filesystem.
No problem here, /home is exported as nfs4 with sec=kerb5.
As noted later, the problem is not exporting, but mounting an export from another box at '/' and particularly (as it is a common use for NFS, /home
-- Russ herrold
-
Anne Wilson -
Hywel Richards -
Les Mikesell -
Michael A. Peters -
Olaf Mueller -
Paul Heinlein -
R P Herrold -
Scott Silva -
Theo Band -
Tsai Li Ming