A problem in dbus caused dbus not to start and hence hald refused to start as well. However, kdm started but since xorg-server-1.5 a not-running hald leads to X session that does not react on keyboard or mouse. Even a switch to VT is not possible. Reproducible: Always Steps to Reproduce: 1. Make dbus refusing to start 2. Reboot 3. Stick in xdm Actual Results: I had to login via ssh to fix the dbus problem which caused as a consequence the xdm problem. Expected Results: If xdm would have refused to start due to missing requirement hald/dbus, I could have fixed the problem on this machine via VT.
This only affects people who are using x11-base/xorg-server with the hal USE flag set. @maintainers: Please keep in mind that there are still people not using hal at all.
This is not a minor bug: any user with a fresh gentoo installation usually runs just `/etc/init.d/xdm start` and gets a totally non-working X environment. IMHO the severity should be raised. The fix is simple btw: just add a line 'need hald' inside the xdm init script. Then, if USE="-hal", the ebuild deletes that line via sed '/need hald/d' or something like that.
*** Bug 267427 has been marked as a duplicate of this bug. ***
This is something we cannot (and will not) fix. Xorg uses HAL if it's there. Even if you've built USE="hal", you can still have Xorg not use HAL at all. In short, USE="hal" only controls the build-time dependency on HAL, the run-time dependency being left to users to control. I'm sorry, but this is something we cannot fix unless we sacrifice options for our users, which (in this case) I believe would be very wrong. Thanks
The only dirty case for users is the following: One confirms the will to use hal by setting the use-flag, but actually doesn't use it at runtime. The question is, if the ebuild maintainer wants to respect this configuration of wills and therefore many users with "consistent" usage of use flags and runtime configuration end up in a input-locked xorg. In my opinion, it is better to enforce people that activate hal support by the use-flag to start hald by init. Those who are not interested in hal just shouldn't set the hal flag.
Sorry but I strongly disagree. The great majority of users have USE=hal (inherited from the desktop profile) and don't mess with xorg.conf to turn Auto{Add,Enable}Devices off. Therefore the most common scenario is to need hald started before xdm, and getting a non-working graphical environment right after installation is a major annoyance for new Gentoo users. Anyway, I think we should be able to design a better solution: the needed dependency can be detected at runtime (grepping xorg.conf, etc..., pulseaudio init script already does that). Are you interested in a patch?
Alright, I'm willing to reconsider. Patches are more than welcome. Thanks
Created attachment 195206 [details, diff] Patch for /etc/init.d/xdm By this patch the configuration file /etc/X11/xorg.conf is scanned whether hal usage is disabled by Option "AutoAddDevices" "false" Otherwise hald is added to need variable.
Created attachment 195207 [details, diff] A patch to apply the initscript patch when hal use-flag is set I have no experience in ebuild development. However, this patch does what it should. Possibly there is a cleaner way to patch the ebuild.
*** Bug 266906 has been marked as a duplicate of this bug. ***
I vote for not making xdm depend on hald. Documenting when hald is needed in the xorg configuration and upgrading guides is a good idea though. Also, the xorg-server ebuild could ewarn() if it detects that hald is not in any runlevel, and the xdm init script could print a warning message and have a 5 second delay (which can be switched off) if it starts while hald is stopped.
(In reply to comment #11) > I vote for not making xdm depend on hald. Documenting when hald is needed in > the xorg configuration and upgrading guides is a good idea though. You vote for not making xdm depending on hald, even if hal use-flag is given and xorg.conf tells us that hald is in fact used? > Also, the xorg-server ebuild could ewarn() if it detects that hald is not in > any runlevel, and the xdm init script could print a warning message and have a > 5 second delay (which can be switched off) if it starts while hald is stopped. The problem is not only that hald has to be added with rc-update when initially emerging xdm. For me it happened several times due to damaged conf file of dbus that hald refused to start and then I got a xdm not responding on input. So one has to use either a boot CD or ssh to fix the problem. I consider this as a major problem. Can anyone make a comment whether the patches above make sense to someone?
(In reply to comment #12) > I consider this as a major problem. Can anyone make a comment whether the > patches above make sense to someone? > It should work. However I don't like how the initd patch is applied by the ebuild. I'm thinking about it but I haven't come up with a both clean and simple solution yet.
(In reply to comment #12) > You vote for not making xdm depending on hald, even if hal use-flag is given > and xorg.conf tells us that hald is in fact used? Yes. I think scanning xorg.conf for Option "AutoAddDevices" "false" is not the way to do it. There are just too many possibilities you would have to consider (several ServerLayouts in one xorg.conf, different location of xorg.conf - be aware that xorg-server scans several directories for that file, and /etc/X11 is not the first in the list). What might be worth considering is a variable RC_XDM_DEPEND_HALD in /etc/conf.d/xdm which controls the dependency. But it should be carefully considered when to default this to true. Because restarting hald may trigger xdm restart too, terminating the user's current X session. > The problem is not only that hald has to be added with rc-update when initially > emerging xdm. For me it happened several times due to damaged conf file of dbus > that hald refused to start and then I got a xdm not responding on input. So one > has to use either a boot CD or ssh to fix the problem. Boot CD or ssh should not be necessary in any case. Magic SysRq and/or pressing 'I' at the correct time during startup should be sufficient.
(In reply to comment #14) > (In reply to comment #12) > > You vote for not making xdm depending on hald, even if hal use-flag is given > > and xorg.conf tells us that hald is in fact used? > > Yes. I think scanning xorg.conf for Option "AutoAddDevices" "false" is not the > way to do it. There are just too many possibilities you would have to consider > (several ServerLayouts in one xorg.conf, different location of xorg.conf - be > aware that xorg-server scans several directories for that file, and /etc/X11 is > not the first in the list). > > What might be worth considering is a variable RC_XDM_DEPEND_HALD in > /etc/conf.d/xdm which controls the dependency. But it should be carefully > considered when to default this to true. Because restarting hald may trigger > xdm restart too, terminating the user's current X session. > What I'm trying to design here is a solution for the average user that works out of the box in the majority of cases. However you made a couple of good points. Therefore I propose to introduce a variable (XDM_NEEDS_HALD - I believe the RC_ prefix is reserved for OpenRC usage) in conf.d/xdm, which may have the following values: *) "yes" => xdm forcefully needs hald. *) "no" => xdm never depends on hald, ignoring settings in xorg.conf. *) "auto" => the xdm init script tries to figure out the needed deps on its own, looking for xorg.conf in various places and parsing its contents. This should be the default. The hald restart is not an issue IMHO, because the ebuild already warns about that. > Boot CD or ssh should not be necessary in any case. Magic SysRq and/or pressing > 'I' at the correct time during startup should be sufficient. > Not user-friendly at all.
Even better, XDM_NEEDS_HALD defaults to "no" when USE="-hal", and to "auto" otherwise. This is the nice solution I was looking for :)
(In reply to comment #15) (In reply to comment #16) Sounds nice, care to send us a patch so we can try it out and iron bugs out? Thanks
(In reply to comment #17) > > Sounds nice, care to send us a patch so we can try it out and iron bugs out? > Sure! I'm working on it...
Should we grep for AutoAddDevices or AutoEnableDevices?
AutoAddDevices
Created attachment 195993 [details] xdm.initd-3
Created attachment 195994 [details] xdm.confd-2
Created attachment 195995 [details, diff] diff 1.0.8-r4 -> 1.0.8-r5
Created attachment 196038 [details] Fixing bug, restructured code There were 'command not found' errors due to misspelling of 'need'. Further, I restructured the code a little. I tested init.d and conf.d on my system and it seems to work.
Please send diffs, makes reviewing much easier for us. Thanks
Created attachment 196065 [details, diff] xdm initd patch Fixes the typos pointed out by Stefan. The other changes in the script are only trailing whitespaces/tabs cleanups and a typo fix.
Created attachment 196067 [details, diff] xdm confd patch
Created attachment 196091 [details, diff] More elaborate comments What do you think about this explanations? I tried to remove the TODO in the comment.
Indeed, both patches look good. Thanks for your work. The only thing I'm worried about is the grep line to find AutoAddDevices. But I guess it's much better than what we currently provide (ie, nothing). I'll try to test them and commit them in the next revbump of xorg-server. Thanks
I am curious why the patches of Davide Pesavento have not been taken into account for the recent versions of the xinit ebuilds (1.0.8-r7 and 1.0.8-r8 for example). Is there a specific reason we would possibly handle?
Simply because xinit is not very high on our priority list. You'll also notice we're several releases behind. I'm currently working on bringing xinit back to speed and I'll apply Davide's patches in due time. Thanks
I've committed attachment #196065 [details, diff] and attachment #196091 [details, diff] to xinit-9999 in the x11 overlay. Those will make their way into portage at some point. Please do _test_ them and report back if you have any issues, I'd greatly appreciate it. Thanks
Reopen. Needs to check for openrc/baselayout-2 with check in [ -n "${RC_UNAME}" ] I will do it when my net workie fine. It stays open untill i fix it in overlay as reminder for me
done
