We recently experienced a power failure and simultaneous backup generator failure, severe enough to require safely shutting down all servers as their UPSs were draining.

Upon bringing one CentOS 7.4.1708 server back up (its first "reboot" in months, but it is up-to-date in terms of CentOS updates) I hit a brick wall preventing me from booting it with SELinux enabled. I have researched extensively but can't seem to find evidence that anyone else has experienced this, nor do I know what to try next. I'm hoping someone here can offer up some ideas.

Here's the timeline:

  1. Booted
  2. Boot failed due to several services not starting up:

    FAILED Failed to start Login Service.
    See 'systemctl status systemd-logind.service' for details.
    FAILED Failed to start Authorization Manager.
    See 'systemctl status polkit.service' for details.
    DEPEND Dependency failed for Dynamic System Tuning Daemon.
  3. Prompted by this I rebooted with selinux=0 in grub

  4. This works and gets the system running, but with SELinux enabled which is not viable for us as anything other than a temporary workaround

  5. Followed advice found online:

    sudo yum reinstall selinux-policy-targeted
  6. Rebooted

  7. Boot now failed due to:

    Failed to load SELinux policy, freezing
  8. Rebooted with selinux=0 in grub again

  9. Found more advice so performed:

    sudo yum reinstall selinux-policy-targeted
    sudo touch /.autorelabel

    and set permissive in /etc/selinux/config

  10. Rebooted

  11. Could see the following banner:

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

    but instead of actually performing the relabelling, the system immediately rebooted itself — too fast to see any other output

  12. Boot again failed with the original error.

    So ugh we're back here again. And I can see that /.autorelabel still exists, suggesting the relabel didn't happen. It's surprising to me that we're back to square one with the errors though.

    Also recall that SELinux is still in permissive mode, not enforcing.

The end result is that I'm stuck without being able to enable SELinux in either permissive or enforcing mode, which is not okay.

How should I proceed?

  • Get the journal entries from the previous failed boot. – Michael Hampton Dec 13 '17 at 17:36
  • Could you add some details about what type of filesystem it is, and what you've done to check the filesystem while SELinux is disabled? – axus Dec 13 '17 at 17:38
  • @axus: I haven't done anything like that - what would you suggest? – Lightness Races in Orbit Dec 13 '17 at 17:48
  • @MichaelHampton: How? I did scan through boot.log but couldn't find what I'd seen on screen. Perhaps I'll look closer. – Lightness Races in Orbit Dec 13 '17 at 17:49
  • You need to use journalctl to view the journal, unless you have a syslog daemon running and it also logged the journal to a text file. Try something like -b 2 or -b 3 or however many boots ago the failed boot was. – Michael Hampton Dec 13 '17 at 17:51

You should be able to relabel the filesystem with:

# restorecon -rv /

I'm not 100% sure if that works in Disabled mode, you may need to be in Permissive/Enforcing.

Can you boot with selinux enabled and init=/bin/sh?

  • You can't restorecon when SELinux is disabled; it has to be at least permissive. – Michael Hampton Dec 13 '17 at 17:36
  • This solution didn't work for me, but that was a baffling state of affairs that helped me deduce what was causing not only the root problem, but the problem with all of my would-be remedial steps. Thanks for your help! – Lightness Races in Orbit Dec 14 '17 at 14:51

tl;dr: Everything came down to an invalid value for SELINUXTYPE.

Make sure SELINUXTYPE has a valid value, then perform relabelling if needed (e.g. if you've booted with SELinux off during your diagnostics), reboot and crack open the champagne.

For some reason, and at some point in time, /etc/selinux/config had acquired the setting SELINUXTYPE=permissive.

This is not a valid option for that parameter, and it appears to make the value fall back on the value "default", based upon the reason listed for why Dbus, Login Service and Authorization Manager failed:

Failed to open "/etc/selinux/default/contexts/dbus_contexts": No such file or directory

This is troublesome because there is no selinux-policy-default package in CentOS 7 (on Debian, for example, it was deliberately removed in Jessie so I'd imagine the same is true here).

I suspect this is also why attempts to relabel the file system using restorecon (from single-user mode, and from a shell reached by init=/sbin/sh) resulted in baffling "No such file or directory" outputs, and getenforce would still show "Disabled" for no evident reason.

To switch to the selinux-policy-targeted stuff which is installed, I fixed the configuration to be SELINUXTYPE=targeted (as I believe it should have been all along), then again rebooted with enforcing=0 autorelabel=1.

The relabelling then took place. Following that, the system booted up as normal.

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.