Bug 239562

Summary: boot sequence hangs at selinux relabel operation
Product: Red Hat Enterprise Linux 4 Reporter: Richard Phipps <rphipps+bugzredhat>
Component: policycoreutilsAssignee: Daniel Walsh <dwalsh>
Status: CLOSED DUPLICATE QA Contact: Ben Levenson <benl>
Severity: medium Docs Contact:
Priority: medium    
Version: 4.5CC: redhat.com
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2007-06-22 15:55:56 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:

Description Richard Phipps 2007-05-09 14:54:15 UTC
Description of problem:
Boot sequence appears to hang during SELinux relabel operation.

Version-Release number of selected component (if applicable):
Red Hat Enterprise Linux AS release 4 (Nahant Update 5)

How reproducible:
touch /.autorelabel

Actual results:
Boot sequence stops here:

         *** Warning -- SELinux relabel is required. ***
         *** Disabling security enforcement.         ***
         *** Relabeling could take a very long time, ***
         *** depending on file system size.          ***

Expected results:
Boot sequence continues after relabel is complete.

Additional info:
Apparent cause is: fixfiles command was broken in policycoreutils-1.18.1-4.12
The file /etc/rc.sysinit contains this:
 /sbin/fixfiles -F relabel > /dev/null 2>&1

Behavior of fixfiles per man page says -F skips prompting for removal of /tmp
files. However, fixfiles from policycoreutils-1.18.1-4.12 prompts regardless
if -F switch is used. This probably causes the apparent boot hang, as rc.sysinit
is waiting at: /sbin/fixfiles -F relabel > /dev/null 2>&1

The fixfiles -F switch worked as expected in policycoreutils-1.18.1-4.9

Comment 1 Carsten Tumma 2007-05-22 16:10:54 UTC
By adding the fallback to use /sbin/restorecon if /usr/sbin/setfiles is not
available, the "exit $?" statement has been removed from the end of the
restore() function within /sbin/fixfiles. This causes fixfiles to continue
execution after it actually finished relabeling.

Comment 2 Daniel Walsh 2007-05-23 17:06:17 UTC
We have not seen this in house although the exit $? is definitely removed.

Does this only happen with a separate /usr partiition?

Comment 3 Daniel Walsh 2007-05-23 17:13:30 UTC
If you add back in the exit $? does it work?

Comment 4 Carsten Tumma 2007-05-24 07:03:27 UTC
(In reply to comment #2)
> We have not seen this in house although the exit $? is definitely removed.
> Does this only happen with a separate /usr partiition?

No, this happens always, regardless whether /usr is on a local partition or
mounted remotely later during the boot process. In any case fixfiles continues
execution prompts the user after the file security contexts have been restored
using either setfiles or restorecon.

(In reply to comment #3)
> If you add back in the exit $? does it work?


Comment 5 RHEL Program Management 2007-05-24 14:04:31 UTC
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 6 Daniel Walsh 2007-06-22 15:55:56 UTC

*** This bug has been marked as a duplicate of 244636 ***