Guys,
I don't know if this is worth looking into from a TDE standpoint or if it is still relevant, but HAL and udev stopped the boot process on my Arch box today. Calvin had the issue that I believe he solved by removing an offending udev rule[1]. That raised the question to me whether there is some standardization that HAL will require across distros in order to support TDE or if there is some part of udev that is needed to support HAL?
Arch no longer provides HAL as a standard package. I believe what triggered the boot fail today was the loss of the 'udev-compat' package (unconfirmed). I'm still digging into this, but if HAL will be required for TDE, then should we look into either insuring that a generic HAL version that is compatible with upstream udev is available to the project?
I don't know how HAL + udev affect TDE or what the long term thoughts are on either, but I thought I would raise the issues to those smarter than I am in case there is a looming issue coming down the road.
What say the experts? Is there any issue with HAL + udev on TDE, or is it just a matter of the individual distro TDE builders to sort out? What worries me is Arch no longer packages HAL and the version we have in the user supported repository (done by 'l0ner' -- thank you!) is hal 0.5.14-7 with a *900K patch* file. If this is where all the distros are ultimately going, we may be better served by deciding how to handle it now rather than waiting until we run into build problems later...
Footnote [1]: (which we are still trying to determine exactly what he removed :)
On Tue, Feb 14, 2012 at 1:58 AM, David C. Rankin drankinatty@suddenlinkmail.com wrote:
Guys,
I don't know if this is worth looking into from a TDE standpoint or if it is still relevant, but HAL and udev stopped the boot process on my Arch box today. Calvin had the issue that I believe he solved by removing an offending udev rule[1]. That raised the question to me whether there is some standardization that HAL will require across distros in order to support TDE or if there is some part of udev that is needed to support HAL?
Calvin got it to work?
Arch no longer provides HAL as a standard package. I believe what triggered the boot fail today was the loss of the 'udev-compat' package (unconfirmed). I'm still digging into this, but if HAL will be required for TDE, then should we look into either insuring that a generic HAL version that is compatible with upstream udev is available to the project?
I don't know how HAL + udev affect TDE or what the long term thoughts are on either, but I thought I would raise the issues to those smarter than I am in case there is a looming issue coming down the road.
What say the experts? Is there any issue with HAL + udev on TDE, or is it just a matter of the individual distro TDE builders to sort out? What worries me is Arch no longer packages HAL and the version we have in the user supported repository (done by 'l0ner' -- thank you!) is hal 0.5.14-7 with a *900K patch* file. If this is where all the distros are ultimately going, we may be better served by deciding how to handle it now rather than waiting until we run into build problems later...
This may be an arch-only problem for a while. From what I understood arch uses last bleeding-edge version of udev, where other distros are using older version. Trinity team doesn't maintain hal, so it is something for the hal package maintainers to fix. Anyway I'm looking into it. Since I haven't updated my arch box yet, I recovered error that I was getting for some time, but never actually figured that it could cause problems in the future:
everything.log.2:Feb 1 05:15:16 localhost udevd[141]: RUN+="socket:..." support will be removed from a future udev release. Please remove it from: /etc/udev/rules.d/90-hal.rules:2 and use libudev to subscribe to events.
Footnote [1]: (which we are still trying to determine exactly what he removed :)
-- David C. Rankin, J.D.,P.E.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
On Tue, Feb 14, 2012 at 10:49 AM, Pawel Soltys sh4dou@gmail.com wrote:
On Tue, Feb 14, 2012 at 1:58 AM, David C. Rankin drankinatty@suddenlinkmail.com wrote:
Guys,
I don't know if this is worth looking into from a TDE standpoint or if it is still relevant, but HAL and udev stopped the boot process on my Arch box today. Calvin had the issue that I believe he solved by removing an offending udev rule[1]. That raised the question to me whether there is some standardization that HAL will require across distros in order to support TDE or if there is some part of udev that is needed to support HAL?
Calvin got it to work?
Arch no longer provides HAL as a standard package. I believe what triggered the boot fail today was the loss of the 'udev-compat' package (unconfirmed). I'm still digging into this, but if HAL will be required for TDE, then should we look into either insuring that a generic HAL version that is compatible with upstream udev is available to the project?
I don't know how HAL + udev affect TDE or what the long term thoughts are on either, but I thought I would raise the issues to those smarter than I am in case there is a looming issue coming down the road.
What say the experts? Is there any issue with HAL + udev on TDE, or is it just a matter of the individual distro TDE builders to sort out? What worries me is Arch no longer packages HAL and the version we have in the user supported repository (done by 'l0ner' -- thank you!) is hal 0.5.14-7 with a *900K patch* file. If this is where all the distros are ultimately going, we may be better served by deciding how to handle it now rather than waiting until we run into build problems later...
This may be an arch-only problem for a while. From what I understood arch uses last bleeding-edge version of udev, where other distros are using older version. Trinity team doesn't maintain hal, so it is something for the hal package maintainers to fix. Anyway I'm looking into it. Since I haven't updated my arch box yet, I recovered error that I was getting for some time, but never actually figured that it could cause problems in the future:
everything.log.2:Feb 1 05:15:16 localhost udevd[141]: RUN+="socket:..." support will be removed from a future udev release. Please remove it from: /etc/udev/rules.d/90-hal.rules:2 and use libudev to subscribe to events.
Footnote [1]: (which we are still trying to determine exactly what he removed :)
-- David C. Rankin, J.D.,P.E.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
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.
On 14 February 2012 07:32, Pawel Soltys sh4dou@gmail.com wrote:
On Tue, Feb 14, 2012 at 10:49 AM, Pawel Soltys sh4dou@gmail.com wrote:
On Tue, Feb 14, 2012 at 1:58 AM, David C. Rankin drankinatty@suddenlinkmail.com wrote:
Guys,
I don't know if this is worth looking into from a TDE standpoint or if it is still relevant, but HAL and udev stopped the boot process on my Arch box today. Calvin had the issue that I believe he solved by removing an offending udev rule[1]. That raised the question to me whether there is some standardization that HAL will require across distros in order to support TDE or if there is some part of udev that is needed to support HAL?
Calvin got it to work?
Arch no longer provides HAL as a standard package. I believe what triggered the boot fail today was the loss of the 'udev-compat' package (unconfirmed). I'm still digging into this, but if HAL will be required for TDE, then should we look into either insuring that a generic HAL version that is compatible with upstream udev is available to the project?
I don't know how HAL + udev affect TDE or what the long term thoughts are on either, but I thought I would raise the issues to those smarter than I am in case there is a looming issue coming down the road.
What say the experts? Is there any issue with HAL + udev on TDE, or is it just a matter of the individual distro TDE builders to sort out? What worries me is Arch no longer packages HAL and the version we have in the user supported repository (done by 'l0ner' -- thank you!) is hal 0.5.14-7 with a *900K patch* file. If this is where all the distros are ultimately going, we may be better served by deciding how to handle it now rather than waiting until we run into build problems later...
This may be an arch-only problem for a while. From what I understood arch uses last bleeding-edge version of udev, where other distros are using older version. Trinity team doesn't maintain hal, so it is something for the hal package maintainers to fix. Anyway I'm looking into it. Since I haven't updated my arch box yet, I recovered error that I was getting for some time, but never actually figured that it could cause problems in the future:
everything.log.2:Feb 1 05:15:16 localhost udevd[141]: RUN+="socket:..." support will be removed from a future udev release. Please remove it from: /etc/udev/rules.d/90-hal.rules:2 and use libudev to subscribe to events.
Footnote [1]: (which we are still trying to determine exactly what he removed :)
-- David C. Rankin, J.D.,P.E.
To unsubscribe, e-mail: trinity-devel-unsubscribe@lists.pearsoncomputing.net For additional commands, e-mail: trinity-devel-help@lists.pearsoncomputing.net Read list messages on the web archive: http://trinity-devel.pearsoncomputing.net/ Please remember not to top-post: http://trinity.pearsoncomputing.net/mailing_lists/#top-posting
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
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.
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.
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
On 02/14/2012 07:19 PM, Pawel Soltys 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
Your good! Thanks Pawel!
On 15 February 2012 11:20, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/14/2012 07:19 PM, Pawel Soltys 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
Your good! Thanks Pawel!
Is this a longterm fix?
On Wed, Feb 15, 2012 at 5:23 PM, Calvin Morrison mutantturkey@gmail.com wrote:
On 15 February 2012 11:20, David C. Rankin drankinatty@suddenlinkmail.com wrote:
On 02/14/2012 07:19 PM, Pawel Soltys 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
Your good! Thanks Pawel!
Is this a longterm fix?
Yes.
-
Calvin Morrison -
David C. Rankin -
Pawel Soltys