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
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
