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}"
 


             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: link
Be 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).