Description of problem: touch /.autorelabel with luks filesystems leads to nasty problems at boot. Autorelabel complains that /run is read only - never completes and leaves the autorelabel for next boot. At same time systemd gets very confused and makes it very difficult to enter luks password - invokes plymouth even when rhgb is removed - issues multiple luks passwd requests and does not wait or accept text input for password. Version-Release number of selected component (if applicable): This may be systemd rather than selinux - or interaction between them when luks filesystems are present - tho readonly /run seems to be different issue. I cannot select more than one component in bugzilla - so I picked selinux ... :-) How reproducible:I have luks encrypted swap and /home Steps to Reproduce: 1.touch /.autorelabel 2.reboot with or without rhgb 3. Actual results: Expected results: Additional info: Booting the machine in this state is possible but very very difficult. systemd and luks seems to have a problem when things dont go as expected - in particular removing rhgb confuses systemd into a terrible state - it prints text prompts for luks password but never waits for an answer - it also attempts to ask plymouth to do graphical prompt for luks which you dont see without some carefully timed series of ESC key presses to flip it on and off ... and only in single user mode - perhaps systemd does more in multi user mode and gets more confused. Details: F15 installed on sandy bridge laptop with i915 intel graphics. The laptop has luks encyrpted swap and /home but not /. I did a "touch /.autorelabel" and rebooted - poo rained upon me in large amounts ... At some point the relabel ended and it booted but screen was hung at the white balloon. I wasn't watching the relabelling process so ... Hard reset - and reboot again. The machine now hangs during every boot - it hangs with the blue screen + balloon - and it no longer gives me the plymouth graphical luks password prompt. Hard reset - reboot removing rhgb and quiet - I see error: Unable to fix label of /run: read-only file system. in red text and it is clearly is trying to finish the relabeling and failing on /run. I see multiple text password prompts for luks password - but it doesn't stop - it keeps going - says something about 'forwarding to plymouth'. typing in the luks password into the text console has no effect. I repeated above but in single user with selinux=0 - now same as above - but if I type password and also toggle ESC enough times the balloon will eventually show password prompt. Toggling ESC again leads me back to text single user prompt. I can now exit single user and it comes up in multi user mode with graphical login. There is some magic timing to get the series of ESC toggles to get a luks password prompt otherwise the just machine hangs. (a) I dont think graphical prompts should be used in text boot. (b) systemd needs to wait for the password to be typed in. (c) what can I do to get the relabel to finish - every boot it keeps trying - the /.autorelable file is never removed. I can no longer boot except doing the above contortions in single user + ESC key flipping to get luks password in. Deleting the .autorelabel and turning off selinux gets me a working system - but I really want to relabel and turn selinux on. Subsequent to this - I installed kernel 3.0 from rawhide along with device-mapper and mdadm - and i have less issues with rhgb now .. but I have not tried to relabel again. ============= More Info: /usr/src/kernels/3.0-0.rc3.git5.1.fc16.x86_64/scripts/ver_linux If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux lap3.prv.sapience.com 3.0-0.rc3.git5.1.fc16.x86_64 #1 SMP Fri Jun 17 16:21:59 UTC 2011 x86_64 x86_64 x86_64 GNU/Linux Gnu C 4.6.0 Gnu make 3.82 binutils 2.21.51.0.6 util-linux 2.19.1 mount support module-init-tools 3.16 e2fsprogs 1.41.14 jfsutils 1.1.13 xfsprogs 3.1.4 pcmciautils 017 quota-tools 4.00-pre1. PPP 2.4.5 isdn4k-utils 3.13 Linux C Library 2.14 Dynamic linker (ldd) 2.14 Procps 3.2.8 Net-tools 1.60 Kbd 1.15.2 oprofile 0.9.6 Sh-utils 8.10 wireless-tools 29 Modules Loaded tcp_lp hidp fuse ebtable_nat ebtables ipt_MASQUERADE iptable_nat nf_nat xt_CHECKSUM iptable_mangle bridge stp llc sunrpc cpufreq_ondemand acpi_cpufreq freq_table mperf capi kernelcapi rfcomm bnep ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables nf_conntrack_ipv4 nf_defrag_ipv4 xt_state nf_conntrack xts gf128mul dm_crypt arc4 uvcvideo videodev media v4l2_compat_ioctl32 btusb bluetooth snd_hda_codec_conexant microcode joydev snd_hda_intel snd_hda_codec snd_hwdep snd_seq i2c_i801 snd_seq_device snd_pcm iwlagn xhci_hcd mac80211 cfg80211 snd_timer iTCO_wdt iTCO_vendor_support snd_page_alloc e1000e thinkpad_acpi rfkill snd soundcore virtio_net kvm_intel kvm sdhci_pci sdhci firewire_ohci mmc_core firewire_core crc_itu_t wmi i915 drm_kms_helper drm i2c_algo_bit i2c_core video ========================= Relevant Packages: libselinux.i686 2.0.99-4.fc15 @fedora libselinux.x86_64 2.0.99-4.fc15 @fedora libselinux-devel.x86_64 2.0.99-4.fc15 @fedora libselinux-python.x86_64 2.0.99-4.fc15 @fedora libselinux-utils.x86_64 2.0.99-4.fc15 @fedora selinux-policy.noarch 3.9.16-26.fc15 @updates selinux-policy-targeted.noarch 3.9.16-26.fc15 @updates systemd.x86_64 26-3.fc15 @updates systemd-sysv.x86_64 26-3.fc15 @updates systemd-units.x86_64 26-3.fc15 @updates wine-systemd.noarch 1.3.21-1.fc15 @updates =========================
Could you try to boot with enforcing=0 and without autorelabel flag. You will boot in permissive mode and then execute # fixfiles restore Also could you add output of # cat /proc/mounts |grep run
Since I now am running kernel 3.0 rc4 - and plymouth seems a little better behaved - I tried Dan's advice from selinix mailing list - rebooted with enforcing=0 (its in permissive mode at the moment still anyway by the way) with .autorelabel - and this time it seemed to go through ok - when I came back the screen was clear except for offer to ^D and go to emergency mode - so any messages had been cleared (i.e. about /run) - after going into emergency mode and exiting - the system came back up ok and the .autorelabel flag was cleared. Once machine was up - I setenforce 1 - however I have a sealert problem so I am not sure I am seeing alerts at the moment (https://bugzilla.redhat.com/show_bug.cgi?id=715373) I searched in /var/log/* (and lower) to find the relabeling log messages but found nothing - is it logged somewhere? Anyway - I am happy to run fixfiles restore a bit later today and will report back if you think that will be helpful. In the meantime : # egrep run /proc/mounts tmpfs /run tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,mode=755 0 0 tmpfs /var/run tmpfs rw,seclabel,nosuid,nodev,noexec,relatime,mode=755 0 0
I ran fixfiles restore ... other than the rows of ***'s I got one message: filespec_add: conflicting specifications for /usr/lib64/bind and /var/named/chroot/usr/lib64/bind, using system_u:object_r:named_conf_t:s0.
Side comment: /var is of course mounted rw at the moment - at some point during boot /var is read only - that seems to be what tickled autorelabel ... I assume this was a timing issue with systemd and the relabel at boot.
What is /usr/lib64/bind?
In my case it is an empty directory: # ls -ld /usr/lib64/bind/ 4 drwxr-xr-x. 2 root root 4096 May 27 05:16 /usr/lib64/bind// I have no idea what if anything it is used for. named is running fine in all the usual places - the following packages are installed: bind.x86_64 32:9.8.0-5.P2.fc15 @updates bind-chroot.x86_64 32:9.8.0-5.P2.fc15 @updates bind-libs.x86_64 32:9.8.0-5.P2.fc15 @updates bind-libs-lite.x86_64 32:9.8.0-5.P2.fc15 @updates bind-license.noarch 32:9.8.0-5.P2.fc15 @updates bind-utils.x86_64 32:9.8.0-5.P2.fc15 @updates
This package has changed ownership in the Fedora Package Database. Reassigning to the new owner of this component.
Is this still an issue or can this bug be closed?
I don't know - I gave up waiting sorry - I turned off selinux on the machine 6 months ago - was systemd fixed to properly handle the relabel?
You probably mean selinux-policy here and yes it has had numerous of enhancement and fixes with systemd
OK excellent - please close the bug - and if further issues arise I can always re-open ... thank you gene
Closing - as no current evidence its still a bug ... will re-open if problem re-surfaces.