Bug#593375: udev: Doesnt create lvm symlinks

[Marco d'Itri]

clone 593375 -1
retitle -1 LVM needs to be updated for modern udev releases
reassign -1 lvm2
severity 593375 critical
thanks

Please let me know your plans about this, I need to upload a new udev
package with a fix.

The udev package will need a Breaks directive and lvm needs to change
the init script and rules as described here.
Or else I will have to revert the change, but I'd rather not have to.

On Aug 19, Peter Rajnoha <prajnoha at redhat.com> wrote:

> On 08/18/2010 10:54 AM +0100, Marco d'Itri wrote:
> > After I started not deleting the initramfs database as you asked,
> > I received multiple bug reports like this one.
> > Version of LVM in Debian is 2.02.66-2, please advise.
> > 
> >> After upgrade from 160 to 161, udev doesnt create lvm volumes symlinks any more.
> >> Here is the related part of the boot log:
> >> Tue Aug 17 09:05:00 2010:   The link /dev/vg00/root_lv should had been created
> >> by udev but it was not found. Falling back to direct link creation.
> 
> OK, here's what happens:
> 
> 1. the LV with root fs is activated in initrd and udev database is filled.
> 
> 2. root fs is mounted
> 
> 3. /etc/init.d/udev script is running (keeping the udev db from initrd), calling:
>       /sbin/udevadm trigger --action=add
> 
>    Since udev db now contains records about devices including dm devices and since
>    the version of the rules used in Debian does not contain everything that's needed
>    for proper support of synthesized events, the ADD event generated by udev script's
>    trigger will be ignored instead of being detected and used.
> 
>    (symlinks for dm devices are created only after the CHANGE event, unless there's
>     a support for synthesized ADD events which we added later)
> 
>    But ignoring events in udev rules means removing any existing symlinks! This will
>    remove any existing /dev/<vgname>/<lvname> symlinks.
> 
>    The missing parts are these:
> 
>        IMPORT{db}="DM_UDEV_PRIMARY_SOURCE_FLAG"
> 
>    and
> 
>        ACTION=="add", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", GOTO="dm_disable"
> 
>        (instead of ACTION=="add", ENV{STARTUP}!="1", NAME="", GOTO="dm_end")
> 
>    These changes are all in new upstream release of lvm2/libdevmapper though.
>    (Anyway, the NAME="" shouldn't be used anymore - it's deprecated as well now)
> 
> 
>    This problem did not occur/was not revealed before the change in udev init
>    script (keeping the udev db) because of the obscure situation actually:
> 
>      - the /dev was populated in initrd
> 
>      - the udev database was cleared though
> 
>      - /dev/<vgname>/<lvname> symlinks remained because when running initial
>        udevadm trigger --action=add in udev init script, there was no udev database.
>        We ignored the ADD event, but since there was no udev database record, udevd
>        didn't know about symlinks already created and so it kept any existing ones.
>        That's the reason why "vgscan --mknodes" did not warn about anything before
>        the change...
>     
> 3. /etc/init.d/lvm2 script is running, calling:
> 
>       /sbin/vgscan --ignorelockingfailure --mknodes
> 
>    The "--mknodes" shouldn't be used actually when we use udev with lvm2/libdevmapper.
>    Since we have udev support enabled, we expect that the symlinks are created by udev
>    itself. If we detect that they're missing, we issue a warning message and fallback
>    to direct link creation.
> 
>    Maybe:
> 
>        "udevadm trigger --action=change --attr-match=dm/name
> 
>    or
> 
>        "udevadm trigger --actoin=change --sysname-match=dm-*
> 
>    is more appropriate here instead (I assume that would also be a nice way how to support
>    even non-udev initrds if someone makes his own...).
> 
> 
> So, basically, the main source of the problem was the "--mknodes" parameter in that lvm2
> init hook - that udevadm trigger --action=change should be used instead.
> 
> But also, I really recommend using latest upstream release with the rules that should handle
> those synthesized events properly (even the udev's initial udevadm trigger --action=ADD).
> We relied on udev init script to set the ENV{STARTUP}="1" before calling the trigger, but
> this solution was deprecated (as we discussed it more with upstream udev). So we came with
> this DM_UDEV_PRIMARY_SOURCE_FLAG checking and keeping the udev database from initrd then
> (which is a more correct solution anyway).
> 
> Maybe this should be forwarded to Debian's lvm2 maintainer to make appropriate
> changes/updates.
> 
> If there's any other problem, please, let me know...
> 
> Peter
> 

-- 
ciao,
Marco
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.alioth.debian.org/pipermail/pkg-lvm-maintainers/attachments/20100819/ebe4a630/attachment-0001.pgp>