Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 184228 - /sbin/fixfiles depends on files in /usr
/sbin/fixfiles depends on files in /usr
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: policycoreutils (Show other bugs)
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
: Reopened
Depends On:
Blocks: 176344
  Show dependency treegraph
Reported: 2006-03-07 10:23 EST by Bastien Nocera
Modified: 2007-11-30 17:07 EST (History)
2 users (show)

See Also:
Fixed In Version: RHBA-2007-0227
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-05-01 18:45:40 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0227 normal SHIPPED_LIVE policycoreutils bug fix update 2007-04-27 17:37:00 EDT

  None (edit)
Description Bastien Nocera 2006-03-07 10:23:42 EST

/sbin/fixfiles (which might be called by /etc/rc.sysinit) depends on
/usr/sbin/setfiles which might not be available if /usr isn't mounted.
Comment 1 Daniel Walsh 2006-03-10 09:39:43 EST
It should be moved to /usr/sbin, although I don't think it is ever used without
/usr being mounted.
Comment 2 Frank Hirtz 2006-03-10 10:18:40 EST
If SELinux needs to be relabled per the check in rc.sysinit, then this will be
called. If the client has /usr non-locally mounted, it won't be present should
this happen, causing a problem.
Comment 3 Daniel Walsh 2006-03-10 16:46:23 EST
Then the check needs to mound /usr, since relabeling without /usr is probably a
waste of time.
Comment 4 Frank Hirtz 2006-03-10 16:55:58 EST
I don't believe that it's realistic to have /usr mounted in sysinit, especially
for a network mounted /usr as there're a good number of needed services which
haven't happened yet.

In the more general sense, we have a longer term request in to clean up /usr
dependencies in initscripts.
Comment 6 Daniel Walsh 2006-04-11 14:42:45 EDT
fixfiles is only called in /etc/rc.sysinit after /usr is mounted.
Comment 7 Frank Hirtz 2006-04-17 17:06:06 EDT
It would appear that is only the case if /usr is local though It looks like
rc.sysinit explicitly mounts local filesystems, checks quotas and then checks to
see if a relabel is needed. If /usr is a non-local share, it's not mounted yet
and since /sbin/fixfiles calls /usr/sbin/setfiles, it breaks. Am I misreading
what's going on here? 
Comment 8 Daniel Walsh 2006-04-19 06:47:26 EDT
Ok a non local /usr would be a problem.

Comment 12 RHEL Product and Program Management 2006-08-18 12:33:33 EDT
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
Comment 13 Eric Hagberg 2006-08-31 12:20:34 EDT
I'd also like to point out that relabelling everything except /usr isn't
necessarily a waste of time - especially if /usr is a readonly share (not even
writable by root. Relabelling everything else in the local filesystem is
probably a good thing and you don't even have to do anything special to avoid
attempting to relabel stuff in /usr, which can't be done anyway and would likely
generate a lot of errors if it was attempted.
Comment 15 Daniel Walsh 2007-01-29 10:25:11 EST
Fixed in 1.18.1-4.10
Comment 19 Red Hat Bugzilla 2007-05-01 18:45:41 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.


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