On Wed, Feb 15, 2012 at 1:07 AM, Pawel Soltys sh4dou@gmail.com wrote:
On Wed, Feb 15, 2012 at 12:54 AM, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/14/2012 11:04 AM, Calvin Morrison wrote:
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
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.
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