Odd messages during bootup from gdm

[Jim Cornette]

Tony Nelson wrote:
> At 11:51 PM -0400 5/4/06, Jim Cornette wrote:
>> Tony Nelson wrote:
>>
>>> SELinux must be active but not enforcing for it to relabel.
> 
>> During the development testing phase, selinux was in a state where
>> selinux could not even be in permissive mode for booting a kernel. I
>> relabeled the system with SELinux completely disabled and in runlevel 1
>> and was able to boot successfully after relabeling the system.
>> you could argue that sonce the system goes into relabelling once mode is
>> switched from disabled to enabled, either permissive or enforcing,
>> relabeling was successful only because of round two relabeling.
> 
> Did you relabel with "touch /.autorelabel ; reboot", or with fixfiles etc?

Since booting the system was impossible with SELinux in any mode, I used 
fixfiles relabel. Using touch /.autorelabel still would not allow for 
the system to boot. (Kernel panic)
Since Gene seems to had success using different methods, his system must 
be in that bad of a state.

> 
> 
>> If my understanding is correct. relabeling is file system related and
>> selinux does not need enabled in order to add content to the file
>> system. In order to honor the content within the labled file system,
>> selinux must be active.
> 
> My experience was that if SELinux is disabled it won't do anything,
> including relabel on boot.  I did "touch /.autorelabel" and rebooted with
> "selinux=0" on the linux command line, and nothing happened; I tried again
> with "enforcing=0" instead and the relabel happened.  I haven't tried
> restorecon / setfiles / fixfiles.

The behavior sounds rational since selinux is disabled, it should 
disable the presence of /.autorelabel

> 
>> If SELinux is active during relabeling, it could prevent file content to
>> be added to the filesystem. SELinux governs by the rules written to the
>> file system, if I'm on cue.
> 
> SELinux has two levels of, umm, "disablement".  In Permissive mode it is
> still active and will note any denials in the log without actually
> preventing the access, or it can be disabled, in which case it can't do
> anything.

You would think that permissive mode would only log failures and allow 
all actions without restriction. This was not the case with several 
testers during the testing phase. Even in permissive, some actions were 
denied and successful relabeling was hindered by denials of actions.

touch /.autorelabel followed by a reboot with enforcing=0 as a boot 
parameter is probably the best way to relabel the system successfully.

Jim

-- 
Plate voltage too low on demodulator tube