Bug 239562 - boot sequence hangs at selinux relabel operation
boot sequence hangs at selinux relabel operation
Status: CLOSED DUPLICATE of bug 244636
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: policycoreutils (Show other bugs)
4.5
All Linux
medium Severity medium
: ---
: ---
Assigned To: Daniel Walsh
Ben Levenson
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2007-05-09 10:54 EDT by Richard Phipps
Modified: 2007-11-16 20:14 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-06-22 11:55:56 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Richard Phipps 2007-05-09 10:54:15 EDT
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
reboot

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 12:10:54 EDT
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 13:06:17 EDT
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 13:13:30 EDT
If you add back in the exit $? does it work?
Comment 4 Carsten Tumma 2007-05-24 03:03:27 EDT
(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?

Yes.
Comment 5 RHEL Product and Program Management 2007-05-24 10:04:31 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
release.
Comment 6 Daniel Walsh 2007-06-22 11:55:56 EDT

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

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