udev and existing /dev (devtmpfs)
Hi,
After starting udev on the /dev which is devtmpfs the udev does not 'take over' already created nodes unless I add in the udev's init script
'udevadm trigger --typeÞvices --action=change'
right after
'udevadm trigger --typeÞvices --actiond'
If there is no action=change, the /dev device mapper nodes looks like (all are nodes, different permissions):
brw-rw---- 1 root disk 253, 0 Jan 17 19:51 /dev/dm-0 brw-rw---- 1 root disk 253, 1 Jan 17 19:51 /dev/dm-1 brw-rw---- 1 root disk 253, 2 Jan 17 19:51 /dev/dm-2 brw-rw---- 1 root disk 253, 3 Jan 17 19:51 /dev/dm-3 brw-rw---- 1 root disk 253, 4 Jan 17 19:51 /dev/dm-4 brw-rw---- 1 root disk 253, 5 Jan 17 19:51 /dev/dm-5 crw------- 1 root root 10, 236 Jan 17 19:51 /dev/mapper/control brw------- 1 root root 253, 0 Jan 17 19:51 /dev/mapper/enc_root brw------- 1 root root 253, 5 Jan 17 19:51 /dev/mapper/vg-dropzone brw------- 1 root root 253, 4 Jan 17 19:51 /dev/mapper/vg-home brw------- 1 root root 253, 3 Jan 17 19:51 /dev/mapper/vg-rootfs brw------- 1 root root 253, 1 Jan 17 19:51 /dev/mapper/vg-swap brw------- 1 root root 253, 2 Jan 17 19:51 /dev/mapper/vg-tmp
but after action=change it does look like:
brw-rw---- 1 root disk 253, 0 Jan 17 19:50 /dev/dm-0 brw-rw---- 1 root disk 253, 1 Jan 17 19:50 /dev/dm-1 brw-rw---- 1 root disk 253, 2 Jan 17 19:50 /dev/dm-2 brw-rw---- 1 root disk 253, 3 Jan 17 19:50 /dev/dm-3 brw-rw---- 1 root disk 253, 4 Jan 17 19:50 /dev/dm-4 brw-rw---- 1 root disk 253, 5 Jan 17 19:50 /dev/dm-5
crw------- 1 root root 10, 236 Jan 17 19:50 /dev/mapper/control
lrwxrwxrwx 1 root root 7 Jan 17 19:50 /dev/mapper/enc_root -> ../dm-0
lrwxrwxrwx 1 root root 7 Jan 17 19:50 /dev/mapper/vg-dropzone ->
../dm-5
lrwxrwxrwx 1 root root 7 Jan 17 19:50 /dev/mapper/vg-home -> ../dm-4
lrwxrwxrwx 1 root root 7 Jan 17 19:50 /dev/mapper/vg-rootfs ->
../dm-3
lrwxrwxrwx 1 root root 7 Jan 17 19:50 /dev/mapper/vg-swap -> ../dm-1
lrwxrwxrwx 1 root root 7 Jan 17 19:50 /dev/mapper/vg-tmp -> ../dm-2
The /dev/mapper/* become symlinks to /dev/dm-* (following udev rules).
The question is: in such scenario, where udev use already-created /dev (whatever it is devtmpfs or maybe mdev-created), should we add the action=change to the init script? If no, then what should we do to udevize /dev?
Distro gentoo, udev-171, I have such issue on every box I use.
-- Piotr.
Quoted 10 lines · Piotr Karbowski
Hi,
After starting udev on the /dev which is devtmpfs the udev does not 'take over' already created nodes unless I add in the udev's init script
'udevadm trigger --type=devices --action=change'
right after
'udevadm trigger --type=devices --action=add'
I had asked about this myself here (this is actually a gentoo bug report and Piotr has now brought it to this list). I also researched the systemd services and found that our inig script is using the correct startup sequence to bring up udev. In other words, Piotr is using a workaround which isn't the correct fix.
Can anyone point the right direction for getting this fixed?
William
Quoted 10 lines · William Hubbs
Quoted 8 lines · Piotr Karbowski
After starting udev on the /dev which is devtmpfs the udev does not 'take over' already created nodes unless I add in the udev's init script
'udevadm trigger --type�vices --action=change'
right after
'udevadm trigger --type�vices --action�d'
Quoted 7 lines
I had asked about this myself here (this is actually a gentoo bug report and Piotr has now brought it to this list). I also researched the systemd services and found that our inig script is using the correct startup sequence to bring up udev. In other words, Piotr is using a workaround which isn't the correct fix.
Can anyone point the right direction for getting this fixed?
I guess it's some Gentoo-specific bug. Almost everybody just does:
'udevadm trigger --type�vices --action�d'
once at bootup and nothing else.
Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
* Kay Sievers <[email protected]>:
| I guess it's some Gentoo-specific bug. Almost everybody just does: | 'udevadm trigger --type�vices --action�d' | once at bootup and nothing else.
udevadm trigger && udevadm settle
isn't anymore the suggested command after udevd --daemon?
As I see from the man page, trigger's default action is change, not add. --
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 8 lines · Gabor Z. Papp
* Kay Sievers <[email protected]>:
| I guess it's some Gentoo-specific bug. Almost everybody just does: | Â Â 'udevadm trigger --typeÞvices --actiond' | once at bootup and nothing else.udevadm trigger && udevadm settle
isn't anymore the suggested command after udevd --daemon?
It was always 'add' which was suggested. It was the default action, but it was changed to 'change' because 'add' must not be used anywhere else than once after bootup.
Triggering 'change' has some valid use cases, not many though, and most of them are workarounds for broken things.
Settle is only needed to block until broken subsystems catch up with reality during bootup, and with reality how hotplug systems work today. It is not pulled-in for systems which do not run broken or legacy tools.
Quoted 1 line
As I see from the man page, trigger's default action is change, not add.
Yes, that changed May 2010 with udev 154.
Kay
Quoted 9 lines · Kay Sievers
On Mon, Jan 23, 2012 at 17:41, Gabor Z. Papp<[email protected]> wrote:
It was always 'add' which was suggested. It was the default action, but it was changed to 'change' because 'add' must not be used anywhere else than once after bootup.
Triggering 'change' has some valid use cases, not many though, and most of them are workarounds for broken things.
Quoted 7 lines
Settle is only needed to block until broken subsystems catch up with reality during bootup, and with reality how hotplug systems work today. It is not pulled-in for systems which do not run broken or legacy tools.
oYes, that changed May 2010 with udev 154.
I just upgraded to udev-181 and the issue still is there. I believe the /dev/mapper/ nodes are created by kernel's devtmpfs but the /dev/dm-* are created by cryptsetup and lvm running in initramfs where is no udev running. Even if I umount devtmpfs on initramfs level and let udev mount it again, the changes will be still there. (I do mount --move to /newroot/dev). Maybe the 'actiond' should care about already-created nodes as well?
-- Piotr.
Quoted 20 lines · Piotr Karbowski
Quoted 10 lines · Kay Sievers
On Mon, Jan 23, 2012 at 17:41, Gabor Z. Papp<[email protected]> Â wrote:
It was always 'add' which was suggested. It was the default action, but it was changed to 'change' because 'add' must not be used anywhere else than once after bootup.
Triggering 'change' has some valid use cases, not many though, and most of them are workarounds for broken things.
Quoted 7 lines
Settle is only needed to block until broken subsystems catch up with reality during bootup, and with reality how hotplug systems work today. It is not pulled-in for systems which do not run broken or legacy tools.
oYes, that changed May 2010 with udev 154.
Quoted 6 lines
I just upgraded to udev-181 and the issue still is there. I believe the
/dev/mapper/nodes are created by kernel's devtmpfs but the/dev/dm-*are created by cryptsetup and lvm running in initramfs where is no udev running. Even if I umount devtmpfs on initramfs level and let udev mount it again, the changes will be still there. (I do mount --move to /newroot/dev). Maybe the 'actiond' should care about already-created nodes as well?
/dev/mapper/* is never created by the kernel.
/dev/dm-* is always created by the kernel.
You can mount and unmount devtmpfs as many times as you want, it will always have the same content. If some tool, or you, change the content, it will stay at the state it was changed to, regardless how and when you mount it.
Kay