udev and existing /dev (devtmpfs)

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Þvices --action=change'

    right after

'udevadm trigger --typeÞvices --action­d'

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.

Re: udev and existing /dev (devtmpfs)

[William Hubbs]

[-- Attachment #1: Type: text/plain, Size: 757 bytes --]

On Tue, Jan 17, 2012 at 08:25:07PM +0100, Piotr Karbowski wrote:
> 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


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: udev and existing /dev (devtmpfs)

[Kay Sievers]

On Sat, Jan 21, 2012 at 23:44, William Hubbs <w.d.hubbs@gmail.com> wrote:
> On Tue, Jan 17, 2012 at 08:25:07PM +0100, Piotr Karbowski wrote:
>> 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 --typefivices --action=change'
>>
>>     right after
>>
>> 'udevadm trigger --typefivices --action≠d'
>
> 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 --typefivices --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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: udev and existing /dev (devtmpfs)

[Gabor Z. Papp]

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

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

Re: udev and existing /dev (devtmpfs)

[Kay Sievers]

On Mon, Jan 23, 2012 at 17:41, Gabor Z. Papp <gzp@papp.hu> wrote:
> * Kay Sievers <kay.sievers@vrfy.org>:
>
> | 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?

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 add.

Yes, that changed May 2010 with udev 154.

Kay

Re: udev and existing /dev (devtmpfs)

[Piotr Karbowski]

On 01/23/2012 06:00 PM, Kay Sievers wrote:
> On Mon, Jan 23, 2012 at 17:41, Gabor Z. Papp<gzp@papp.hu>  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.
>
> 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­d' should care about already-created 
nodes as well?

-- Piotr.

Re: udev and existing /dev (devtmpfs)

[Kay Sievers]

On Fri, Mar 2, 2012 at 01:46, Piotr Karbowski <piotr.karbowski@gmail.com> wrote:
> On 01/23/2012 06:00 PM, Kay Sievers wrote:
>>
>> On Mon, Jan 23, 2012 at 17:41, Gabor Z. Papp<gzp@papp.hu>  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.
>>
>> 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­d' 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