15 Feb
2012
15 Feb
'12
1:19 a.m.
On Wed, Feb 15, 2012 at 1:07 AM, Pawel Soltys <sh4dou(a)gmail.com> wrote:
On Wed, Feb 15, 2012 at 12:54 AM, David C. Rankin
<drankinatty(a)suddenlinkmail.com> wrote:
For everyone interested: I was able to fix
the problem. For
explanations read my latest comment in aur:
https://aur.archlinux.org/packages.php?ID=51454
On 02/14/2012 11:04 AM, Calvin Morrison wrote:
Pawel,
You must be living right! After full updates yesterday, my box locked when it
reached hal in the DAEMONS list. Normal kernel and LTS both locked (linux
3.2.5-1, and linux-lts 3.0.20-1) It was bad enough I had to boot to single user
mode just to get to boot. On 'init 3' it hung on hal again, but switching to
tty2, I was surprised that hal was actually running:
[17:47 providence:/etc/udev/rules.d] # ps ax | grep hal
22701 ? Ssl 0:00 /usr/sbin/hald
22702 ? S 0:00 hald-runner
22732 ? S 0:01 /usr/lib/hal/hald-addon-acpi
init 5 from tty3 brought up kdm from 3.5.12.
I have absolutely nothing in rules.d:
[17:47 providence:/etc/udev/rules.d] # l /etc/udev/rules.d/
total 8
drwxr-xr-x 2 root root 4096 Feb 8 07:54 .
drwxr-xr-x 3 root root 4096 Feb 13 13:40 ..
I built and updated hal from AUR to 0.5.14-7, and I still have no
/etc/udev/rules.d/90-hal.rules:2. Should I? I have remotely downgraded udev to
180-1 to see if that helps. I'll know tomorrow when I get to the office.
--
David C. Rankin, J.D.,P.E.
Strange. This.Is.Really.Strange.
On my pc I still have the /etc/udev/rules.d/90-ral.rules file, nothing
freezes and everything is ok. Am I the only one unaffected?
Though reports from different people have reached my about this kind
of breakage in hal. Calvin was looking on how to enable the hal to
cummunicate with udev using directly libudev and not dbus like it was
done before (I assume, since I don't know anything about hal
structure). Anyway try reading this:
https://bbs.archlinux.org/viewtopic.php?id=135672
People stated that addink two symlinks in their system fixed the problem.
ln -s /usr/bin/udevadm /sbin/udevadm
ln -s /usr/bin/udevd /sbin/udevd
The problem may be:
-due to final deprecation of configuration of udev through rules.d and
now the apps should use libudev
-or due to movement of the binaries from /sbin to /usr/bin
I'll try to reproduce your problem on one of my arch
virtualmachines... and see what happens. Strangely
enough... for me everything works well and starts well after
> upgrade. I still get the previously stated errors, but I don't have
> hangups of any sort.
>
Even if HAL is still working - it will break in upcomping udev
versions unless we get rid of that rule, and add a patch to hal to
subscribe to the changes via libudev instead.
Calvin