-
Notifications
You must be signed in to change notification settings - Fork 199
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Hard power cycle of centos 7 ostree image typically causes boot to fail with error: failed to load selinux policy #1963
Comments
Hmm, this sounds like it might be related to the staging API. In v2018.5, it was still pretty new, and looking through the git logs, the only way we supported staged deployments was via |
We've not explicitly set that, so probably no. A text search in our repository shows an object file with #AutomaticUpdatePolicy=none. ie commented out. |
I've been doing a few more tests - power on the PC, wait for the login screen to at least appear and then hard power off after that. Looking at the selinux folder by mounting the disk on another PC - the files have already been cleared before boot starts, so this suggests to me a process is regularly running which is doing something to these files? Is that possible? |
Hmm, I'd check the journal for any hints. A misconfigured systemd-tmpfiles dropin perhaps? I'm not aware offhand of anything that would nuke SELinux files like this. |
I'll take a look. |
Finding it a bit difficult to debug, but best guess so far is that selinux is rebuilding the policy after first boot. If this process is interrupted, eg power off, the policy in /etc/selinux/targeted/active are empty which essentially bricks the PC (selinux unable to load policy at next boot). Still need to confirm this is actually what is happening, but I do get the same behaviour if I run semodule -B and then immediately hard power off. In any case, I really think semodule shouldn't be this sensitive and should be more atomic (eg build the policy in a temp/secondary location) and then switch when complete. |
The source of the problem was a script running setsebool on startup. As above, this causes the selinux policy files to be rebuilt and if the PC is power cycled during that process, it typically will fail to boot. This happens on non ostree PCs. I will close this ticket and raise an issue with selinux on this - I think it would be better if it is was more resiliant to this. |
Hmm, is it a service actually shipped with SELinux though? Likely the script is using |
No, setsebool was in the ExecStartPre section for a custom service (setsebool -P httpd_can_network_connect on), and yes it had a -P. I think this should be in the rpm, however this doesn't work as selinux isn't running when composing ostree. Any idea waht the 'correct' way of setting this from inside an rpm spec? |
Hmm, you mean disabled completely or in permissive mode? rpm-ostree today does need SELinux on (even if permissive) on the compose side. |
I'm pretty convinced |
Custom Centos 7 atomic install.
Expected vs actual behavior
We should be able to power cycle the PC.
Steps to reproduce it
Further notes
Soft reboot works OK. Power cycling often fails as above, but not always.
From a freshly installed ostree deployment I can soft reboot several times and then hard powercycle and the boot will subseqently often fail in the same way.
I have tried running semodule -B in a freshly installed deployment, soft powercycle and then hard powercycle. This often leads to the same failure
By connecting the disk from a PC that has failed to boot to another PC, many of the selinux files in the deployed etc/selinux/targeted/active folder are seen to be different to the deployed usr/etc/selinux/targeted/active/ - in fact they seem to be empty!
eg sample from diff across the two folders:
In addition, if I copy from usr/etc/selinux to etc/linux and then reconnect to the PC, the PC boots successfully, however subsequent hard powercycles often lead to the same failure.
Something seems to vaping each file in the selinux folder.
The text was updated successfully, but these errors were encountered: