[arch-dev-public] [signoff] udev-170-1
Hi guys, udev-170 is out only one day after 169. The only change is an additional bugfix needed for udev in mkinitcpio. Please test and signoff. Cheers, Tom The original notes still apply: ***** This is an upstream update together with the following changes: * we no longer disable error logging. This can be done manually if needed, but the lack of error messages makes finding errors harder. Besides, if the messages are truly unnecessary it should be reported upstream. * we no longer maintain our own custom cd symlinks. This change is just to get closer to upstream, and it does not lose significant functionality (also, the custom script is likely to bitrot). * we longer autoload oss emulation modules. This can be added to MODULES in rc.conf if needed, but is not needed by most people and causes problems for some, so don't do i by default. In the future we will not load any modules by default except for what is done upstream. This seemed the most obvious, so changed it first. * we no longer provide persistent net/cd autogeneration rules. This is deprecated upstream and should be done as explained on the arch wiki. I might leave this package in [testing] somewhat longer than strictly necessary to pick up on any obscure bugs (we were hit by some with the 168 release). Also note: with this release we need kernel 2.6.32 or later.
On 20 May 2011 09:36, Tom Gundersen <teg@jklm.no> wrote:
Hi guys,
udev-170 is out only one day after 169. The only change is an additional bugfix needed for udev in mkinitcpio.
Please test and signoff.
Signoff x86_64.
On Fri, May 20, 2011 at 2:36 AM, Tom Gundersen <teg@jklm.no> wrote:
Hi guys,
udev-170 is out only one day after 169. The only change is an additional bugfix needed for udev in mkinitcpio.
Please test and signoff.
Cheers,
Tom
The original notes still apply:
*****
This is an upstream update together with the following changes:
* we no longer disable error logging. This can be done manually if needed, but the lack of error messages makes finding errors harder. Besides, if the messages are truly unnecessary it should be reported upstream. * we no longer maintain our own custom cd symlinks. This change is just to get closer to upstream, and it does not lose significant functionality (also, the custom script is likely to bitrot). * we longer autoload oss emulation modules. This can be added to MODULES in rc.conf if needed, but is not needed by most people and causes problems for some, so don't do i by default. In the future we will not load any modules by default except for what is done upstream. This seemed the most obvious, so changed it first. * we no longer provide persistent net/cd autogeneration rules. This is deprecated upstream and should be done as explained on the arch wiki.
I might leave this package in [testing] somewhat longer than strictly necessary to pick up on any obscure bugs (we were hit by some with the 168 release).
Also note: with this release we need kernel 2.6.32 or later.
While the kernel is booting, I'm getting error messages like these: udevd: failed to execute '/sbin/mdadm' '/sbin/mdadm --incremental /dev/sdb2' : No such file or directory udevd: failed to execute '/sbin/mdadm' '/sbin/mdadm --detail --export /dev/md1' : No such file or directory and similar for the other hard disk and raid devices. From a quick check, they seem to come from the udev rules from the mdadm package. I don't know if it's the udev rules in mdadm that need to be updated to work with the new udev or if it's a problem with the new udev and/or kernel26 packages. Despites these error messages, the raid array has assembled itself correctly and everything seem to work fine. Later today, I'll try to downgrade udev and or the kernel to see if it helps. BTW, that's on x86_64. Eric
On Fri, May 20, 2011 at 8:44 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
While the kernel is booting, I'm getting error messages like these:
udevd: failed to execute '/sbin/mdadm' '/sbin/mdadm --incremental /dev/sdb2' : No such file or directory udevd: failed to execute '/sbin/mdadm' '/sbin/mdadm --detail --export /dev/md1' : No such file or directory
and similar for the other hard disk and raid devices. From a quick check, they seem to come from the udev rules from the mdadm package. I don't know if it's the udev rules in mdadm that need to be updated to work with the new udev or if it's a problem with the new udev and/or kernel26 packages.
Despites these error messages, the raid array has assembled itself correctly and everything seem to work fine.
Later today, I'll try to downgrade udev and or the kernel to see if it helps. BTW, that's on x86_64.
When you downgrade, could you manually change udev_log to "err" in /etc/udev/udev.conf? I enabled error printing again as of udev-170, so it could be that the error was always there, just never printed. Thanks for testing! Cheers, Tom
On Fri, May 20, 2011 at 4:41 PM, Tom Gundersen <teg@jklm.no> wrote:
On Fri, May 20, 2011 at 8:44 PM, Eric Bélanger <snowmaniscool@gmail.com> wrote:
While the kernel is booting, I'm getting error messages like these:
udevd: failed to execute '/sbin/mdadm' '/sbin/mdadm --incremental /dev/sdb2' : No such file or directory udevd: failed to execute '/sbin/mdadm' '/sbin/mdadm --detail --export /dev/md1' : No such file or directory
and similar for the other hard disk and raid devices. From a quick check, they seem to come from the udev rules from the mdadm package. I don't know if it's the udev rules in mdadm that need to be updated to work with the new udev or if it's a problem with the new udev and/or kernel26 packages.
Despites these error messages, the raid array has assembled itself correctly and everything seem to work fine.
Later today, I'll try to downgrade udev and or the kernel to see if it helps. BTW, that's on x86_64.
When you downgrade, could you manually change udev_log to "err" in /etc/udev/udev.conf? I enabled error printing again as of udev-170, so it could be that the error was always there, just never printed.
Thanks for testing!
Cheers,
Tom
I'm not able to reproduce that anymore. The error went away during my tests. Either it is a racing issue or it fixed itself with the numerous upgrade/downgrade of udev and kernel. Eric
participants (3)
-
Eric Bélanger
-
Evangelos Foutras
-
Tom Gundersen