On 10/22/2009 05:01 PM, Thomas Bächler wrote:
> Peter Rajnoha schrieb:
>> ..ok, finally we kept the "last_rule" in the lvm/dm upstream. This is the
>> safe way. Maybe later we can think of a solution where we will rely on
>> the
>> others so they will check the variables we set for them (if that's
>> possible at all). But it would be too dangerous now, I have to admit.
>>
>> You can check the rules we have in the upstream - if you have any
>> comments
>> or hints, just feel free to write me back...
>
> I am going to replace our own device-mapper rules with upstream rules (I
> think when we made our own rules, dm didn't have any, or I overlooked
> them).
>
Well, official udev support is quite new (I think first rules were
added sometime in August together with udev synchronisation interface
in libdevmapper that could be used to synchronise udev actions with the
code using libdevmapper itself, so there's no race between the udev creating
the nodes and devmapper fallback - today only dmsetup and LVM uses this).
Maybe some important notes and problems we already know about and track:
- these rules change the layout in /dev a little:
- the nodes are created in /dev directly with the name of dm-X
(this is internal kernel name that is not the same as actual DM name)
- the symlinks are created in /dev/mapper
(these ones use DM name -- like the old layout, but they're symlinks now,
that's the only difference)
- consenquences of using symlinks instead of nodes in /dev/mapper:
- mount utility follows those symlinks and writes mtab with dm-X name, not
the actual DM name (so, for example, when someone uses "df" now, he will
see those dm-X names instead of actual nice DM names)
- there's a known problem with GRUB2 that can't deal with symlinks in
/dev/mapper (it's grub-probe utility that fails iirc, GRUB1 is OK though..)
- calling "udevadm trigger" itself - this one generates ADD udev events by default
and we suppress the node creation on ADD. However, if the node already exists and
you call udevadm trigger, you will loose the nodes and you will end up with dangling
symlinks in /dev/mapper. This is because of how udev works.. This either needs to be
fixed somehow in udev directly (I've written Kay about this specific situation already,
but actually don't know about a solution right now :) ) or, the temporary solution is
just to call "udevadm trigger --action=change" if you want those nodes and symlinks
back.
OK, thanks... If you spot any other problems, please let me know. We have to catch all
these initial bugs.
Peter
_______________________________________________
dm-crypt mailing list
dm-crypt@xxxxxxxx
http://www.saout.de/mailman/listinfo/dm-crypt
