[arch-dev-public] [signoff] udev 157-1, initscripts 2010.06-1, mkinitcpio 0.6.5-1

Dan McGee dpmcgee at gmail.com
Thu Jun 3 10:18:42 EDT 2010

On Thu, Jun 3, 2010 at 7:57 AM, Thomas Bächler <thomas at archlinux.org> wrote:
> You should upgrade and test these together (don't forget to regenerate
> initramfs when you're upgraded). The new udev should work without the
> new initscripts and mkinitcpio, but udev-based network device renaming
> will fail in that case.
> udev is an upstream update with mostly bugfixes, but some changes in
> behaviour. Most importantly, NAME= rules are being ignored now, you can
> not change the kernel's predefined device name anymore.
> initscripts changes:
> Dan McGee (1):
>      Include _netdev option in NETFS list when calling fsck
> Thomas Bächler (2):
>      Only mount /proc, /sys and /dev if they haven't been mounted
> already, use devtmpfs instead of tmpfs if supported by the kernel
>      Add --action=add to udevadm trigger
> mkinitcpio changes:
> Thomas Bächler (5):
>      Do not umount /proc and /sys before switch_root, but mount --move
> them into the real root
>      Mount tmpfs or (if supported) devtmpfs on /dev, move it into the
> real root before switch_root
>      udev hook: Add --action=add to udevadm trigger
>      udev hook: Add ata_id, path_id, scsi_id and usb_id to allow
> complete persistent storage rules
>      Release 0.6.5
> For the future, we now fully support devtmpfs. It is recommended (but
> not required (yet)) by upstream. Using devtmpfs gets rid of a small
> number of race conditions.
> I tested devtmpfs on a custom kernel, and with the exception of one
> short (and harmless) error message (mknod: /dev/rtc0: device exists), it
> works fine. Getting rid of that error message requires further
> consideration, as we can fix a bug with some custom kernel
> configurations at the same time if we do it right. For now, I will
> ignore this and please ask for testing and signoffs.

Signoff on the whole deal with stock arch kernel on x86_64, so no
devtmpfs in use currently. Everything seemed smooth and I didn't see
any unexpected errors scroll by.


More information about the arch-dev-public mailing list