How to disable HAL and still use X in Slackware64-13 ?
 

I did what is recommended in CHANGES_AND_TXT:
I already had an /etc/X11/org.conf file because I use a NVIDIA driver for my graphical card.

So I edited it, appended following lines at the end:
But then if I do not start hald, X fail to start and I have these messages in /var/log/Xorg.0.log:
Do I miss something, maybe in X configuration, to "tell" the X server not to rely upon HAL ?

PS this a "how-to" question, I do not expect answers like "why don't you use HAL?" -- there is already (at least) one thread about that anyway.

If you check /etc/rc.d/hald messagebus and mysql, I would guess that the files will be empty. These are the symptoms that I saw and I had to do a full re-install to fix the problem. I think that it is a wider problem but I couldn't find a way to fix it.

samac

Thanks Samac, but /etc/rc.d/hald, /etc/rc.d/messagebus and /etc/rc.d/mysql scripts are present in my installation and work, AFAIK. I can stop or start hal (and dbus and mysql) without any issue.

Can you show us your full /var/log/Xorg.0.log file and your /etc/X11/xorg.conf file? Because, honestly, those options should be all you need to disable Xorg from using HAL.

Adam

Yes.

xorg.conf:
Xorg.0.log:

I think its because the nvidia-generated xorg.conf does not contain enough to start the x-server. You will have to run xorgsetup to generate a complete xorg.conf file. Then, re-installing the nvidia driver will prompt you to allow the installer to add the nvidia related options to xorg.conf. The last step will be to manually edit xorg.conf for your mouse and screen resolution - especially if you have a wide screen.

I ran xorgsetup with no more success. X stops as soon as I try to use an input device, with the same messages in Xorg.0.log.

Thanks anyway - also because running xorgsetup I found out that I could use "thinkpad60" as "XkbModel" which is more accurate than "pc105" for my Lenovo Thinkpad T61's keyboard.

I have exactly the same issue as Didier here. X displays ok initially (Windowmaker from startx), but the instant you move the mouse or press a key it dies just as Didier's has. But only when hald isn't running.

You have

In two different sections. I doubt that this would be the source of the problem, but it's worth removing them from one of the two sections to find out. Either section is fine as those options should work in either ServerLayout or ServerFlags.

Adam

Thanks for the suggestion, however these lines are not duplicated in my last xorg.conf (output of xorgsetup) and I get the same results.

I've just figured it out. Insipration out of the blue.

You also need to stop messagebus. If you run messagebus without hal then it goes BOOM!

Thanks Gazl, same here.

I thought I would still need dbus though to have a few KDE apps working -- even if I use Fluxbox as WM -- but notwithstanding a few warnings at konqueror start up kontact as well as konqueror still seem to work.

To be more accurate, these KDE apps somehow launch dbus when they need it.

I saw that with "top" command: as soon as I launch kontact or konqueror as user didier, I see dbus-launch and dbus-daemon which appear in top's window.

But in that case X don't crash.

Good to know, though I would like to know why.

Yes, its annoying. I don't like HAL that much but I can see the value in dbus and as you say, things like kde rely on it quite a bit, so having to turn it off is a pain. I found a /etc/dbus-1/system.d/hal.conf file and thought that by removing that it might allow dbus to still run while allowing X without HAL, but it didn't make any difference.

I guess the Xorg code just isn't checking return values properly on their messagebus calls and subsequently bombing out. :(


The reason I was trying to run X without HAL is that I've found that when using the Virtual Consoles after exiting an Xserver screen, key-presses are going astray making it unusable until I restart X again. Interestingly, while X is still running (even if only showing a XDM), or when X is restarted, the key-presses work correctly in the VC. It's only after you exit X that the problem happens. Also, the same thing occurs on OpenBSD 4.6, so it's not linux specific, but something is upsetting keyboard handling somewhere. I wanted to see whether turning off HAL made any difference - It doesn't! This is using a Chicony HID wireless keyboard and mouse. I've not tried plugging in a cabled PS2 keyboard yet, but that's my next step. I suspect the problem may go away when I do that, but we'll see.

All things being considered, I looks like X.org is going through a bit of a rough patch at the moment. Lets hope it gets back on track sooner rather than later.

There are two dbus daemons. A system wide one and one for your current session, which is the one dbus-launch starts. I'm not sure if the session specific one will work without the system level one being up. I've not really looked into dbus all that much.

Sorry -- I misread the issue :|

I too have not found a way to still run X, with HAL dead.

Sasha

Maybe a totally different question: but why is HAL bad? It took me some getting-used-to, but eventually I found it the solution to many of my issues... This gets me curious, and curiosity can only be met with answers :-)

Ramurd, as stated in my first post here:
So please post your question elsewhere, here could be a good place.

edit:
moved my reply to Ramurd to here to keep this thread clean.

Thanks GazL.

About disabling HAL, unfortunately the problem is not solved in avoiding dbus usage, as CUPS needs dbus to work -- and I need CUPS to print.

Trying to print without it this morning (Paris time) I saw this in /var/log/syslog:
Any thought ?

I guess you could look at recompiling the xserver package and see if you can configure out HAL support at compile time and see if it avoids the problem. But it's getting a little on the involved side.

I hate to say it, but perhaps it's best to just reconsider letting HAL run. :(

I agree, fwiw : compiling HAL out of X is getting more involved, and the end may/probably doesn't justify the means.

Here's a thought (though again, more complex than may justify doing it):

We know that X/K/GDM quits/restarts repeatedly if HAL isn't running at the *DM login. BUT: we also seem to know that once we're logged in, HAL can be killed and stuff seems to work fine. SO:

A little bit of editing of the X or DE startup scripts could produce a situation whereby HAL gets stopped after login, but gets restarted before/during/after logout.

This would have HAL running outside of X, but when using X, it would not be running.

...just a thought :)
Sasha

I tried to compile xserver with --disable-config-hal option (just editing /source/x/x11/configure/xorg-server in the slackware64-13 tree) but got a compilation error. I will try to find out why this evening (Paris time).

Did you get any further with this Didier?

Yes, it works!

I didn't post earlier because at first I had compilation errors.

I suspected this being a side effect of installing all the packages needed to get a multilib Slackware as explained in this page written by Eric Hameleers aka Alien BOB. So I removed all new packages and installed back the "original" ones. But still the same errors.

To make sure it was not caused by some modification of my system before I complain to Pat something like "heh, one of your Slackbuilds don't work" I ended up doing this:
- install VirtualBox in Slackware64-13.0
- install Slackware64-13.0 in a virtual machine with VirtualBox
- mount the DVD as /mnt in the embedded Slackware-13.0 (not modified at all) and run directly /mnt/source/x/x11/x11.Slackbuild

It worked and I got all the packages!

Then as I need only xorg-server I ran following command:
/mnt/source/x1/X11/x11.Slackbuild xserver

It worked!

All I had to do now was edit the configure file, make the packages again and reinstall (in the "physical" machine, of course) the updated packages.

Now I am writing under X and without HAL (but with the dBus daemon running, so I can print with CUPS) and so far, everything seems to work.

To make a long story short, if your installation is cleaner than mine all you have to do is:
1) Copy somewhere the directory /source/x/x11 of the DVD (or a mirror) of the distribution and cd there
2) Edit the file configure/xorg-server (that is to say, source/x/x11/configure/xorg-server) to add following option:
4) Run following command:
5) Replace the "original" packages by the new ones:
6) Kill X, then stop the HAL daemon and prevent it from starting at next (re)boot:
Then you can start X again or reboot.

WARNINGS
1) Remember that if/when a new xorg-server is released by Pat (for instance following a security advisory) and you still don't want to use HAL, you will have to follow that procedure again.
2) This seems to work here but I didn't make methodical testing.

May be only xorg-server-1.6.3 needs to be modified for all this to work, I don't know.

Happy Slackin!

PS I still don't know why I got these compilation errors on my "real" system but that's another story.

EDIT. This seems to work with as well as without an xorg.conf file and (if HAL is launched) do not prevent auto-mounting of removable devices in XFCE and KDE; may be I could suggest Pat to add the "--disable-config-hal" option in the official xorg-server packages ? What do you think ?

Excellent stuff! :)

I can't see Pat wanting to go with '--disable-hal' in the stock packages. Though there does seem to be a fair number of us who'd rather not have any hal in our X system, hal is becoming the expected norm. Perhaps he'd be open to having a non-hal alternate package in 'extra' though to save people the effort of recompiling it themselves?

The fact the Xserver as shipped was blowing up when dbus was running but hal wasn't, is clearly a bug. It ought to fallback to non-hal mode gracefully in that situation, but at least now we have a proven workaround. Hopefully recompiling won't be necessary in future versions.

Anyway, good job and thanks for posting the results.

Thanks from me too, for the effort & time put into this.

I agree, it'd be nice to have the option of a NON-Hal Xorg in Slackware /Extra but I would understand if Pat is not open to the idea; it does kinda cause a fork in the road so to speak, in terms of him maintaining two versions of the same package, just because a few of us don't like HAL. Also, at times like bug reporting, it may be looked upon as a 'taint' by which, if we report a bug yet are running non-HAL-Xorg, we may be told to re-test for the bug with the official Xorg (in the same sense of bug reporting on tainted kernels)

Anyhow, nice work!
Once I have my install finalized, I'll be rebuilding X as was described here. :cool:

Sasha

Most things doesn't seem to change if one --disable-config-hal in xorg-server: one can still use HAL and if the HAL daemon is launched auto-mounting of removable devices works.

Only caveat AFAIK: in this case any X setting should be made through an /etc/X11/xorg.conf, not an fdi file in /etc/hal as stated in CHANGES_AND_HINTS.TXT

Would someone be eager to look at this issue more thoroughly please do it ;)

Not really a caveat though in this case; I think that's how things _should_ be: X stuff gets configured in xorg.conf. Makes perfect sense (to me anyway)

What we need is another word; if "caveat" = "beware", and beware being the forboding, ominous sort of word that it is, we need a word meaning "be aware"...

Cheers :)
Sasha

Sasha, I meant caveat as in caveat emptor.

Please forgive my bad English anyway; sixty years old and still trying to learn it :scratch:

Hopefully with the help of WordNet, available at Slackbuilds.org it will be easier.

Hi Didier;

Forgive me: your English is great, there's no problem there :)

I was just being silly -- figuring we could use a different latin word for "be aware", instead of 'caveat' for "beware".

Note the difference:

"Beware of Dog" # implies scary dog that will attack you.

"Be aware of Dog" # less scary -- means "fyi: there's a dog around here (and don't run him over)".

Sorry for the confusion!
Sasha

cave canem ;)

Don't be sorry, I always welcome your remarks.

Cheers,

Thank you ;)
Sasha

bad link fixed
 

Some news: "X server crashing when HAL daemon is not started but dBus daemon is" was a bug in xorg-server, already fixed in version 1.6.3.901. Rémi Cardona gave me this information (I posted the issue on the xorg mailing list), CC Patrick Volkerding.

See http://cgit.freedesktop.org/xorg/xse...dfaead48e86440

So hopefully my workaround won't be necessary any more when xorg-server will be upgraded in Slackware-13.0 (or in the next release, this is up to Pat).

BTW, Rémi told me too that AutoAddDevices is enough to disable HAL support at run-time.

I get "bad object ID" from that link Didier, but thanks for the update. I always suspected it was a actual bug, but it's nice to know its a bug that's already been fixed upstream.

Sorry for the bad link in previous post, it's now fixed.

After recompiling X to remove its dependency on HAL, is it OK to remove the HAL package entirely? I've removed executable perms on rc.hald, so the daemon doesn't start on boot, which leads me to believe that it would be safe to remove the HAL package. Just want to be sure..

Well, IMHO chmod -x /etc/rc.d/rc.hald is good enough to get rid of it -- That's what I did, at least ;)

Unless you be really short of disk space, I wouldn't recommend you to remove it, as you still could find another application which rely on it. For instance when I launch amarok wit no HAL daemon running I get some weird messages like this one:
At least, keep the package somewhere, ready to be re installed.

OK, thanks!