I have VMs that are installed with selinux disabled via my custom kickstart file. However, when I reboot the VMs for the first time, they want to go through the relabeling process. I see these message appear on the console of the VMs when they are booting:

*** Warning -- SELinux targeted policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.

This takes a minute or so and then the box reboots, and sometimes I see this message again with another reboot before the box finally comes up. It only appears to happen on the first boot. How can I prevent this relabeling process from ever occurring?

disable selinux?

As I mentioned in my original post, selinux *is* disabled. But for some reason, my system (CentOS 6.4) wants to do this relabeling the first time the system is rebooted. This does not happen during FirstBoot, but during the first reboot.

Try this command:
Reboot afterwards and see if it goes away.

I had already tried that and the relabeling is still performed during the first reboot of the system. Technically what I really want is something like .noautorelabel--I want to turn off the relabeling, not trigger it. The relabeling does not occur the first time the VM is booted after it's been installed. It occurs the first time the system is rebooted, even though selinux is disabled. Since it is disabled, you'd think I wouldn't have to do anything to disable the automatic relabeling process--it should be off by default if selinux is disabled. Perhaps I don't fully understand what this relabeling is supposed to accomplish.

Ironically, if I try to perform a relabel manually, it complains that selunix isn't enabled:

Have you tried adding "selinux=0" as a kernel parameter passed in by the boot loader?

This has no effect. Here's a snippet of my console output during the reboot:

At this point it sits here for a while, and then proceeds with this:
and the system then restarts. I have occasionally seen it go through this relabeling process on the next reboot as well before finally finishing the boot. Seems very odd that this would be happening with SElinux is disabled.

let it do it's job
and rerun the labling
it has to after you make a change

every time you turn it off( setenforce=0) and back on ( reboot) it HAS TO run a check

so let it do it's job.

then ONLY turn off SE when it is 100% NEEDED ( almost never is needed ) and expect the TIME needed to run the check

set SE to "permissive" READ AND FIX -- FIX--- the errors
from "selinuxtroubleshooter"
then set it to ENFORCING and leave it there

Examination of /etc/rc.d/rc.sysinit suggests that the existence of a non-empty file /selinux/enforce might cause that. Why that would be the case is not apparent. That file gets written with either a "0" or "1" to control actions during the forced reboots that are sometimes needed for an autorelabel. Whatever empties it is not apparent.

If you never want to use SELinux, you could simply uninstall selinux-policy (which will also take out selinux-policy-targeted and policycoreutils-gui).

We have a custom minimal CentOS and we don't want SElinux installed at all. The kickstart document describes the command "selinux --disabled" as "Disables SELinux completely on the system", but this is apparently not the case. I've even tried to explicitly exclude the module "selinux-policy" in the kickstart file but it gets installed anyway.

1 members found this post helpful.

If the installation calls for "selinux-policy-targeted" or "policycoreutils-gui", then the base policy will be installed to satisfy dependencies.

While I can't tell what exactly happens when you set selinux --disable, SELinux was obviously installed on your system, perhaps as a dependency of another package. /root/install.log tells you what packages were installed, though it doesn't say why. Perhaps /root/install.log.syslog is more enlightening.
Now that you have SELinux, you can use /etc/selinux/config to persistently disable it.

I am not sure how to completely remove SELinux once it is installed. You may want to start with removing packages like selinux-policy or libselinux-utils.

I've modified my kickstart file to explicitly exclude selinux from the main set of packages:

%packages --nobase
@core
-selinux-policy-targeted
-selinux-policy

and also include the directives

selinux --disabled
bootloader --location=mbr --append="console=tty0 console=ttyS0,115200 selinux=0"

When my VM comes up sestatus confirms that selinux is disabled:

# sestatus
SELinux status: disabled
# cat /selinux/enforce
0

and the selinux policy modules are definitely not installed (they do not appear in install.log). The system log also confirms it is disabled:

# grep -i selinux /var/log/messages
Jan 29 07:43:31 pws-01 kernel: SELinux: Disabled at boot.

However, the first time I reboot the VM I get this on the console:

*** Warning -- SELinux targeted policy relabel is required.
*** Relabeling could take a very long time, depending on file
*** system size and speed of hard drives.
usage: /sbin/setfiles [-dnpqvW] [-o filename] [-r alt_root_path ] spec_file pathname...
usage: /sbin/setfiles -c policyfile spec_file
usage: /sbin/setfiles -s [-dnpqvW] [-o filename ] spec_file
Unmounting file systems
Automatic reboot in progress.
Restarting system.
machine restart

and the machine reboots. Fortunately with all of these efforts at disabling SELinux, the system reboot happens immediately. Previously when I hit this the relabeling process took a couple of minutes. At least that's no longer the case and I just have to deal with the extra reboot, which ultimately adds very little time now that the relabeling no longer runs.

I still think there is something screwy here. Why is it even attempting a relabel when clearly SElinux is not active. But, beyond modifying /etc/rc.d/rc.sysinit to disable the relabeling logic, it seems that I've done all I can do so I'll leave it that.

The filesystem probably still has the SELinux labels on the files. You can try removing them, but make a backup first because it might break other things.

http://stephane.lesimple.fr/blog/200...ux-labels.html

These systems are VMs created by an automated kickstart script, so I can play with them as needed. I'll add the setfattr command to the kickstart post install script to see if that does the trick. You'd think that the CentOS installer would not apply SELinux labels to the files during the install if the kickstart script indicates that SELinux is disabled, but clearly the labels *are* being set...