SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
I'm getting weirdness from Hal on Slack 12.0 and I'm looking for a pointer.
There was recent Disk trouble, (Partition table, then e2fsck). I use runlevel 3
Symptoms: boots to displaying the line (/etc/rc.d/rc.hald)
"Starting Hal daemon /usr/sbin/hald --daemon=yes" (which is normal)
The disk goes for half a second, (cups is next)then noticably stops. Keyboard and boot are frozen. Reset required.
To make a long story boring, I added a few echo commands, decided it was Hal, & reinstalled it (upgradepkg --reinstall), then commented it out in /etc/rc.d/rc.M as none of this helped.
Once it boots, I can log in as root and run "/etc/rc.d/rc.hald start" and the process completes with no errors :-o. No errors show in the logs, but there is a load of binary in /var/log/messages at one point.
Any suggestions welcome. Hal is something I know little about, despite being a hardware guy.
Last edited by business_kid; 03-28-2008 at 05:07 AM.
Sounds like a dependency problem - something is loading before a module that it needs, but your normal boot loads that module and therefore lets you run HAL successfully.
Chances are that you're trying to do something before all filesystems (including things like /sys and /proc) are mounted, before SCSI/IDE drivers are loaded etc., trying to assign IP's before interfaces are even present etc.
That's why it just hangs when you run HAL - it's missing something critical - it might not be able to find the module because the /lib/modules folder isn't loaded yet (e.g. on a different drive, on a different controller, on a different filesystem), it might not be able to access /sys, /proc etc. properly, it might be missing drivers for entire buses that get loaded later (e.g. SCSI, PCMCIA etc.). But when you do a normal boot, it loads whatever is missing and you can run HAL successfully. Anything loading by manual modules in rc.modules? Tried loading on a huge kernel without any modules? Tried without any binary modules that might be tainting the kernel?
But to be honest none of that will really help you because the problem is most likely that you have a corrupt filesystem - "There was recent Disk trouble" and "there is a load of binary in /var/log/messages at one point" just scream file corruption to me. If one of your modules is corrupted, this will happen. Post logs but to be honest, I'd be reinstalling onto a blank disk if that were me.
I agree with you on corruption, but not a lot was corrupted. I've been here before, and it really wasn't bad enough to reinstall.
I'm lazy about reinstalling, and do not wish to update or to do anything drastic simply because one daemon misbehaves. Boot order has been static throughout, and I've not been messing. Hal comes fairly late in the boot sequence, long after filesystems are mounted. Hal only seems to depend on dbus, but it grabs all the hardware info. The output of lshal |less shows that.
So I can give up right away. I've a Via chipset with the following issues:
1. USB is dodgy - 2 ports give out unwanted log spam and this box finally helped to run down a years old issue in ehci-hcd. There is now a modprobe.conf option
option ehci_hcd ignore_oc=1 to jettison overcurrent change warnings
2. ACPI is dodgy, and best disabled.
3. The Via apic is notably broken and hands out the same 2 halfassed irqs to everything if it's let. So I have it disabled at boot.
4. The PS/2 port is blown away and the floppy is dodgy. It appeared to die recently, although it is back with us, Could have been a cable issue, but . . .
5 Aside from that, and the hard drive occasionally crashing it's firmware in crazy circumstances, we are reasonably reliable. See why I'm giving up :-)?
I also have this issue: 6. Life is short.
So rather than thinking, I'll gradually move it later in the boot process and see if I can find another startup it will work after, but not before. THAT will point a finger, and it saves thinking.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.