Description of problem: F13 with all updates & updates-testing enabled. Plymouth startup splash works ok, but reboot/shutdown splashes do not display. Version-Release number of selected component (if applicable): plymouth-theme-charge-0.8.2-3.fc13.i686 plymouth-plugin-label-0.8.2-3.fc13.i686 plymouth-plugin-two-step-0.8.2-3.fc13.i686 plymouth-gdm-hooks-0.8.2-3.fc13.i686 plymouth-scripts-0.8.2-3.fc13.i686 plymouth-utils-0.8.2-3.fc13.i686 plymouth-0.8.2-3.fc13.i686 plymouth-graphics-libs-0.8.2-3.fc13.i686 plymouth-core-libs-0.8.2-3.fc13.i686 plymouth-system-theme-0.8.2-3.fc13.i686 gdm-2.30.2-1.fc13.i686 kernel-PAE-2.6.34.7-56.fc13.i686 How reproducible: Every boot. Steps to Reproduce: 1. Install F13 on an Asus EeePC 1005P 2. Install all updates with updates-testing enabled. 3. Reboot. Actual results: Plymouth splash screen is only shown on startup, not reboot and shutdown as expected.
This seems to be related to selinux. After rebooting with selinux=disabled in /etc/sysconfig/selinux, the plymouth screens work perfectly on startup, reboot and shutdown. To test, I re-enabled selinux, waited for it to relabel the filesystem, then rebooted again and the shutdown/reboot screens didn't work. Disabling selinux again, and presto, everything was back to how it should be. Installed selinux packages: libselinux-2.0.94-2.fc13.i686 libselinux-python-2.0.94-2.fc13.i686 libselinux-utils-2.0.94-2.fc13.i686 selinux-policy-3.7.19-57.fc13.noarch selinux-policy-targeted-3.7.19-57.fc13.noarch
This may be helpful: Sep 22 23:40:14 eeepc kernel: type=1400 audit(1285162802.009:4): avc: denied { mmap_zero } for pid=457 comm="vbetool" scontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tcontext=system_u:system_r:vbetool_t:s0-s0:c0.c1023 tclass=memprotect Was caused by: The boolean mmap_low_allowed was set incorrectly. Description: Allow certain domains to map low memory in the kernel Allow access by executing: setsebool -P mmap_low_allowed 1
Steven you can put the machine into permissive mode and see if it shuts down with the splash screen. I would hope it is not the vbetool causing this. It could be a dontaudit rule. # semodule -DB # setenforce 0 # reboot Will turn off the dontaudit rules. # semodule -B turns them back on. Then look for bugs related to plymouth. One problem is that these bugs might not end up in a log file.
I ran 'setsebool -P mmap_low_allowed 1' however the issue still occured. I have put 'SELINUX=permissive' in /etc/sysconfig/selinux to debug. Will take the steps above to see what I can find.
Created attachment 448948 [details] output of 'grep avc: /var/log/messages' Ran the above commands - here is the output of 'grep avc: /var/log/messages' The reboot/shutdown screens work as expected in permissive mode (as you'd expect).
Created attachment 448950 [details] output of 'grep avc: /var/log/messages' with mmap_low_allowed 0 Rebooted a couple of times after setting mmap_low_allowed back to 0 (the default). This is the output of 'grep avc: /var/log/messages'.
Nothing there that would cause the error. Could you try to put the machine back into enforcing mode and then add # setenforce 1 # semanage permissive -a plymouthd_t # reboot Then see if the screen pops up. Also could you check in /var/log/audit/audit.log for avc messages.
Created attachment 448957 [details] output of 'grep ply /var/log/audit/audit.log' Ah ha. audit.log does contain references for plymouthd. Interpreting these is beyond me however :)
After running these two commands, the shutdown/reboot screens do not display: # setenforce 1 # semanage permissive -a plymouthd_t I tried 2-3 reboots, no shutdown/startup splash each time.
Sorry - typo. The above should read: I tried 2-3 reboots, no shutdown/*reboot* splash each time.
grep avc /var/log/audit/audit.log | audit2allow And attach the output.
Created attachment 448969 [details] Output of 'grep avc /var/log/audit/audit.log | audit2allow'
It looks like it could be shutdown causing the bug. # semanage permissive -a shutdown_t And see if it comes up.
Yay! After running 'semanage permissive -a shutdown_t', I now get both shutdown & reboot splash screens with enforcing mode set. This makes me wonder. Is it an selinux policy issue or a shutdown issue? :)
Ok did you find anything else in the logs about shutdown_t? grep shutdown_t /var/log/audit/audit.log grep shutdown_t /var/log/messages dmesg | grep shutdown_t
Created attachment 449081 [details] output of 'grep shutdown_t /var/log/audit/audit.log' Added output of 'grep shutdown_t /var/log/audit/audit.log'. There were no matches to the other two commands.
Make sure you turn off the dontaudit rules. # semodule -B Miroslav add allow shutdown_t initrc_var_run_t:file write; allow shutdown_t var_log_t:dir search; Steven you can add these rules for now by executing # grep shutdown_t /var/log/audit/audit.log | audit2allow -M myshutdown # semodule -i myshutdown.pp Then you can attempt to remove the permissive domain. # semanage permissive -d shutdown_t If it still works then those allow rules are what we needed to add.
Hi Daniel, I ran: # semodule -B # grep shutdown_t /var/log/audit/audit.log | audit2allow -M myshutdown # semodule -i myshutdown.pp # semanage permissive -d shutdown_t The shutdown / reboot splash screens still work as expected. Does this mean these rules will need to be added to the default selinux policy?
Yes
Fixed in selinux-policy-3.7.19-61.fc13
selinux-policy-3.7.19-62.fc13 has been submitted as an update for Fedora 13. https://admin.fedoraproject.org/updates/selinux-policy-3.7.19-62.fc13
I can verify that this is fixed in selinux-policy-3.7.19-62.fc13.
Please update karma
Already have. I was the first +1 :)
selinux-policy-3.7.19-62.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update selinux-policy'. You can provide feedback for this update here: https://admin.fedoraproject.org/updates/selinux-policy-3.7.19-62.fc13
selinux-policy-3.7.19-62.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.