udev and existing /dev (devtmpfs)

[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'

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[William Hubbs]

Post by 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

[Kay Sievers]

Post by 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 sc=

ript

Post by Piotr Karbowski
'udevadm trigger --type=3Ddevices --action=3Dchange'
=C2=A0 =C2=A0 right after
'udevadm trigger --type=3Ddevices --action=3Dadd'

I had asked about this myself here (this is actually a gentoo bug rep=

ort

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=3Ddevices --action=3Dadd'
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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Gabor Z. Papp]

* Kay Sievers <***@vrfy.org>:

| I guess it's some Gentoo-specific bug. Almost everybody just does:
| 'udevadm trigger --type=devices --action=add'
| 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 ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Kay Sievers]

| =C2=A0 =C2=A0'udevadm trigger --type=3Ddevices --action=3Dadd'
| 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.

As I see from the man page, trigger's default action is change, not a=

dd.

Yes, that changed May 2010 with udev 154.

Kay
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug=
" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Piotr Karbowski]

Post by Kay Sievers
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.
o
Yes, 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 'action=add' should care about already-created
nodes as well?

-- Piotr.
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html

[Kay Sievers]

Post by Kay Sievers
It was always 'add' which was suggested. It was the default action,
but it was changed to 'change' because 'add' must not be used anywhe=

re

Post by Kay Sievers
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.
o
Yes, that changed May 2010 with udev 154.

I just upgraded to udev-181 and the issue still is there. I believe t=

he

/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 r=

unning.

Even if I umount devtmpfs on initramfs level and let udev mount it ag=

ain,

the changes will be still there. (I do mount --move to /newroot/dev).=

Maybe

the 'action=3Dadd' 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
--
To unsubscribe from this list: send the line "unsubscribe linux-hotplug=
" in
the body of a message to ***@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html