policycoreutils-1.18.1-4.7 /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.
It should be moved to /usr/sbin, although I don't think it is ever used without /usr being mounted.
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.
Then the check needs to mound /usr, since relabeling without /usr is probably a waste of time.
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.
fixfiles is only called in /etc/rc.sysinit after /usr is mounted.
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?
Ok a non local /usr would be a problem. Dan
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 release.
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.
Fixed in 1.18.1-4.10
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. http://rhn.redhat.com/errata/RHBA-2007-0227.html