[arch-general] boot hangs on hal load after updates today.
All, Strange behavior on boot with both standard and LTS kernels. After updates today. Boot hangs on hal load when encountered in DAEMONS line of rc.conf. hal IS started, but boot hangs with both the normal kernel and LTS. This behavior is confirmed when starting hal manually. This occurs with both the old hal 0.5.14-6 and version 0.5.14-7 from aur. This stops the boot process dead in its tracks requiring a ctrl+alt+del to kill the hang. I had to boot to 'single' user mode to bring my box up enough to remove hal from the daemons line. Any ideas which package may be causing this? I know hal is on the way out, but it is needed currently for development of Trinity. -- David C. Rankin, J.D.,P.E.
On 13 February 2012 16:52, David C. Rankin <drankinatty@suddenlinkmail.com> wrote:
All,
Strange behavior on boot with both standard and LTS kernels. After updates today. Boot hangs on hal load when encountered in DAEMONS line of rc.conf. hal IS started, but boot hangs with both the normal kernel and LTS. This behavior is confirmed when starting hal manually. This occurs with both the old hal 0.5.14-6 and version 0.5.14-7 from aur.
This stops the boot process dead in its tracks requiring a ctrl+alt+del to kill the hang. I had to boot to 'single' user mode to bring my box up enough to remove hal from the daemons line. Any ideas which package may be causing this? I know hal is on the way out, but it is needed currently for development of Trinity.
-- David C. Rankin, J.D.,P.E.
I was having issues with this before as well. Do you have an exact error? Mine ended up being a udev rule written by hal that caused the breakage. Hopefully we can get it resolved. Calvin
On Mon, Feb 13, 2012 at 10:55 PM, Calvin Morrison <mutantturkey@gmail.com> wrote:
es with this before as well. Do you have an exact error? Mine ended up being a udev rule written by hal that caused the breakage. Hopefully we can get it resolved.
Does HAL still write the offending rule on updated systems? If so, could you paste it so we can see how big trouble to expect? HAL was already dead when I got involved with these things, so please forgive my ignorance. -t
On 02/13/2012 04:39 PM, Tom Gundersen wrote:
On Mon, Feb 13, 2012 at 10:55 PM, Calvin Morrison <mutantturkey@gmail.com> wrote:
es with this before as well. Do you have an exact error? Mine ended up being a udev rule written by hal that caused the breakage. Hopefully we can get it resolved.
Does HAL still write the offending rule on updated systems? If so, could you paste it so we can see how big trouble to expect?
HAL was already dead when I got involved with these things, so please forgive my ignorance.
-t
Tom, Calvin, Thanks. Calvin, which rule? I probably is udev. You think Soltys can find it in AUR version and get rid of it? -- David C. Rankin, J.D.,P.E.
On 02/13/2012 03:55 PM, Calvin Morrison wrote:
I was having issues with this before as well. Do you have an exact error? Mine ended up being a udev rule written by hal that caused the breakage. Hopefully we can get it resolved.
Calvin
Hah, I had to search for your reply -- was in the 'trinity' folder... I'll have to check when I get back to the office. I don't recall a specific rule being thrown out, but it may well have and I missed it. Thanks again. -- David C. Rankin, J.D.,P.E.
On 02/13/2012 04:55 PM, David C. Rankin wrote:
On 02/13/2012 04:39 PM, Tom Gundersen wrote:
On Mon, Feb 13, 2012 at 10:55 PM, Calvin Morrison <mutantturkey@gmail.com> wrote:
es with this before as well. Do you have an exact error? Mine ended up being a udev rule written by hal that caused the breakage. Hopefully we can get it resolved.
Does HAL still write the offending rule on updated systems? If so, could you paste it so we can see how big trouble to expect?
HAL was already dead when I got involved with these things, so please forgive my ignorance.
-t
Tom, Calvin,
Thanks. Calvin, which rule? I probably is udev. You think Soltys can find it in AUR version and get rid of it?
The boot hang was cause by the move of udev binaries from /sbin to /usr/bin. hal had hard-coded the /sbin location. Pawel updated the hal package in AUR and it solved the problem. If your system is using hal in any way, then update to hal 0.5.14-8: https://aur.archlinux.org/packages.php?ID=51454 -- David C. Rankin, J.D.,P.E.
participants (3)
-
Calvin Morrison
-
David C. Rankin
-
Tom Gundersen