On Sep 5, 2012, at 5:11, deb...@mikapflueger.de wrote:
> Hi Ron
> Are you absolutely sure the context for gdm3 is correct at the machine where
> it doesn't work? You wrote that you relabeled and rebooted and that would
> restore the (wrong) context. Unfortunately (I'm not sure if this is a bug -
> it is intended but I don't like it) reenabling selinux after having it
> disabled triggers an autorelabel. This is what happened for me: I had selinux
> disabled, changed the context for gdm3, rebooted with selinux=1
> security=selinux, the system did a relabeling on the boot, and I got a broken
> gdm3 right again. You then have to log into a VT (e.g. ctrl+alt+f1) and
> correct the label from the command line. Then you can reboot once again
> (which now will hopefully _not_ relabel) and after that it worked for me.
Yes, I'm sure the context is correct. I was initially fooled by the
context-change-on-relabel 'feature', but when gdm gets stuck on that, it
doesn't respawn. When I fixed the context and rebooted, gdm continually
respawned as it had done before, and the segfault and backtrack appeared in the
log. I think we're talking about a different bug now (probably in libextmod).
A better workaround, I found, is to restore libextmod.so to its correct place,
and add this to xorg.conf:
Section "Module"
SubSection "extmod"
Option "omit SELinux"
EndSubSection
EndSection
That, at least, retains the other ext mod functions.
.....Ron
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
