public inbox for lvm2-cvs@sourceware.org help / color / mirror / Atom feed
From: prajnoha@sourceware.org To: lvm-devel@redhat.com, lvm2-cvs@sourceware.org Subject: LVM2 ./WHATS_NEW_DM udev/10-dm.rules.in Date: Thu, 12 Aug 2010 13:41:00 -0000 [thread overview] Message-ID: <20100812134120.6324.qmail@sourceware.org> (raw) CVSROOT: /cvs/lvm2 Module name: LVM2 Changes by: prajnoha@sourceware.org 2010-08-12 13:41:19 Modified files: . : WHATS_NEW_DM udev : 10-dm.rules.in Log message: Fix udev rules to support udev database content generated by older rules. This can happen with older rules (without support for synthesized events) that are still part of initrd while using new udev rules in the system itself. The consequence was that new udev rules incorrectly assumed that not having DM_UDEV_PRIMARY_SOURCE_FLAG set always means the uevent is synthesized and inappropriate (device is still not properly activated) and so it should be ignored. However, initrd is not updated automatically while updating the libdevmapper/udev rules in the system and so we end up with the rules not detecting and setting crucial parts in the initrd environment and the rules in the system that rely on the information that should have been stored in udev db (which is incorrect in this configuration, of course). The overall consequence is that the update of libdevmapper/lvm2 without regenerating the initrd could end up with a boot failure! Ignoring the event means removing any existing symlinks in /dev! To fix this, increase udev rules version to make a difference. So from now on, mark rules without proper support for synthesized events as DM_UDEV_RULES_VSN="1" and 2 (or higher) if that support is included. Patches: http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/WHATS_NEW_DM.diff?cvsroot=lvm2&r1=1.406&r2=1.407 http://sourceware.org/cgi-bin/cvsweb.cgi/LVM2/udev/10-dm.rules.in.diff?cvsroot=lvm2&r1=1.11&r2=1.12 --- LVM2/WHATS_NEW_DM 2010/08/12 13:07:08 1.406 +++ LVM2/WHATS_NEW_DM 2010/08/12 13:41:18 1.407 @@ -1,5 +1,6 @@ Version 1.02.54 - ================================ + Fix udev rules to support udev database content generated by older rules. Reinstate detection of inappropriate uevent with DISK_RO set and suppress it. Fix segfault in regex matcher with characters of ordinal value > 127. Use built-in rule for device aliases: block/ < dm- < disk/ < mapper/ < other. --- LVM2/udev/10-dm.rules.in 2010/08/12 13:07:08 1.11 +++ LVM2/udev/10-dm.rules.in 2010/08/12 13:41:19 1.12 @@ -66,6 +66,7 @@ IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG5" IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG6" IMPORT{db}="DM_SUBSYSTEM_UDEV_FLAG7" +IMPORT{db}="DM_UDEV_RULES_VSN" LABEL="dm_flags_done" # Normally, we operate on "change" events. But when coldplugging, there's an @@ -80,7 +81,7 @@ # before (e.g. in initrd). If udev is used in initrd, we require the udev init # script to not remove the existing udev database so we can reuse the information # stored at the time of device activation in the initrd. -ACTION=="add", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", GOTO="dm_disable" +ACTION=="add", ENV{DM_UDEV_RULES_VSN}!="1", ENV{DM_UDEV_PRIMARY_SOURCE_FLAG}!="1", GOTO="dm_disable" # "dm" sysfs subdirectory is available in newer versions of DM # only (kernels >= 2.6.29). We have to check for its existence @@ -106,7 +107,9 @@ # fact (e.g. fallback to rules that behave correctly even without # these rules installed). It also provides versioning for any # possible future changes. -ENV{DM_UDEV_RULES_VSN}="1" +# VSN 1 - original rules +# VSN 2 - add support for synthesized events +ENV{DM_UDEV_RULES_VSN}="2" ENV{DM_UDEV_DISABLE_DM_RULES_FLAG}!="1", ENV{DM_NAME}=="?*", SYMLINK+="(DM_DIR)/$env{DM_NAME}"
next reply other threads:[~2010-08-12 13:41 UTC|newest] Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top 2010-08-12 13:41 prajnoha [this message] -- strict thread matches above, loose matches on Subject: below -- 2011-01-28 11:41 prajnoha 2010-08-12 13:07 prajnoha 2010-06-23 17:00 prajnoha 2009-12-07 12:03 prajnoha
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20100812134120.6324.qmail@sourceware.org \ --to=prajnoha@sourceware.org \ --cc=lvm-devel@redhat.com \ --cc=lvm2-cvs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).