On Wed, Feb 15, 2012 at 12:54 AM, David C. Rankin <drankinatty@...> 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.