RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 883416 - Need a way to easily fallback to non-udev operation in libdevmapper/lvm2
Summary: Need a way to easily fallback to non-udev operation in libdevmapper/lvm2
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: lvm2
Version: 6.4
Hardware: x86_64
OS: Linux
urgent
urgent
Target Milestone: rc
: ---
Assignee: Peter Rajnoha
QA Contact: Cluster QE
URL:
Whiteboard:
Depends On:
Blocks: 880040
TreeView+ depends on / blocked
 
Reported: 2012-12-04 14:53 UTC by Peter Rajnoha
Modified: 2018-12-02 15:50 UTC (History)
19 users (show)

Fixed In Version: lvm2-2.02.98-4.el6
Doc Type: Enhancement
Doc Text:
Feature: Recognize DM_DISABLE_UDEV environment variable while using LVM2 tools, dmsetup and libdevmapper to fallback to non-udev operation fully. Setting this variable acts as a shortcut for using --noudevsync, --noudevrules and --verifyudev option in dmsetup and setting devices/obtain_device_list_from_udev=0, activation/udev_sync=0 (or --noudevsync LVM2 command line option), activation/udev_rules=0 and activation/verify_udev_operations=1 option in LVM2. Changes also apply for any libdevmapper users. Reason: Setting the DM_DISABLE_UDEV environment variable provides a more convenient way of disabling udev support in libdevmapper, dmsetup and LVM2 tools globally without a need to modify any existing configuration settings. This is mostly useful if the system environment does not use udev. Result (if any): Refer to dmsetup manual page and LVM2 manual pages as well as the comments in lvm.conf itself and descriptions of the options mentioned above.
Clone Of: 880040
Environment:
Last Closed: 2013-02-21 08:15:08 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2013:0501 0 normal SHIPPED_LIVE lvm2 bug fix and enhancement update 2013-02-20 21:30:45 UTC

Description Peter Rajnoha 2012-12-04 14:53:02 UTC
Add the DM_DISABLE_UDEV env var instead of setting various options directly.  The DM_DISABLE_UDEV env var gets top priority over all existing settings.

Comment 2 Peter Rajnoha 2012-12-04 15:22:30 UTC
To QA:

To test this, use the DM_DISABLE_UDEV=1 environment variable and then try to create/remove dm/lvm devices. This should have the same effect as setting/using:

For dmsetup:
  --noudevsync in dmsetup
  --noudevrules
  --verifyudev


For LVM2:
  devices/obtain_device_list_from_udev=0
  activation/udev_sync=0 (or --noudevsync lvm2 cmd line option)
  activation/udev_rules=0
  activation/verify_udev_operations=1


You can check that udev is bypassed by:

 - checking the /dev/mapper dir - the nodes should be created here instead of symlinks
 - /dev/<vg_name>/<lv_name> should be a symlink to /dev/mapper instead of 
/dev/dm-X
 - also checking the udev database, for example:

   udevadm info --query=all --name=/dev/mapper/vg-lvol0

P: /devices/virtual/block/dm-0
N: dm-0
S: disk/by-id/dm-name-vg-lvol0
S: disk/by-id/dm-uuid-LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ
E: DEVLINKS=/dev/disk/by-id/dm-name-vg-lvol0 /dev/disk/by-id/dm-uuid-LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ
E: DEVNAME=/dev/dm-0
E: DEVPATH=/devices/virtual/block/dm-0
E: DEVTYPE=disk
E: DM_LV_NAME=lvol0
E: DM_NAME=vg-lvol0
E: DM_SUSPENDED=0
E: DM_UDEV_DISABLE_DM_RULES_FLAG=1
E: DM_UDEV_DISABLE_SUBSYSTEM_RULES_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES_VSN=2
E: DM_UUID=LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ
E: DM_VG_NAME=vg
E: MAJOR=253
E: MINOR=0
E: SUBSYSTEM=block

So no symlink "S:" record for /dev/mapper/vg-lvol0 and /dev/vg/lvol0. And also there are DM_UDEV_DISABLE_{DM, SUBSYSTEM}_FLAG=1 variables set.


Compared to udev records *without DM_DISABLE_UDEV*:

P: /devices/virtual/block/dm-0
N: dm-0
S: disk/by-id/dm-name-vg-lvol0
S: disk/by-id/dm-uuid-LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ
S: mapper/vg-lvol0
S: vg/lvol0
E: DEVLINKS=/dev/disk/by-id/dm-name-vg-lvol0 /dev/disk/by-id/dm-uuid-LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ /dev/mapper/vg-lvol0 /dev/vg/lvol0
E: DEVNAME=/dev/dm-0
E: DEVPATH=/devices/virtual/block/dm-0
E: DEVTYPE=disk
E: DM_LV_NAME=lvol0
E: DM_NAME=vg-lvol0
E: DM_SUSPENDED=0
E: DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
E: DM_UDEV_PRIMARY_SOURCE_FLAG=1
E: DM_UDEV_RULES_VSN=2
E: DM_UUID=LVM-lLYHEhwf9yDVwsA2KAIj2BGE2Tmrfa59gGQny4UDP2xCa6vl275fepLDPCG8LQLJ
E: DM_VG_NAME=vg
E: MAJOR=253
E: MINOR=0
E: SUBSYSTEM=block

The S:mapper/vg-lvol0 and S:vg/lvol0 is there and DM_UDEV_DISABLE_LIBRARY_FALLBACK=1 is set and no DM_UDEV_DISABLE_*_FLAG set.

Comment 3 Peter Rajnoha 2012-12-04 15:25:36 UTC
Also, if you use DM_DISABLE_UDEV=1 and at the same time udevd daemon is running, you should get these warning messages:

$ export DM_DISABLE_UDEV=1
$ lvchange -ay vg
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, LVM will manage logical volume symlinks in device directory.
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, LVM will obtain device list by scanning device directory.
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, device-mapper library will manage device nodes in device directory.

Comment 4 Nenad Peric 2012-12-04 15:34:13 UTC
Adding QA ACK based on Comment #2

Comment 6 Nenad Peric 2012-12-11 15:18:07 UTC
Verified by setting DM_DISABLE_UDEV and by changing the lvm.conf
The behavior is the same, save for the lack of warnings:

  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, LVM will manage logical volume symlinks in device directory.
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, LVM will obtain device list by scanning device directory.
  Udev is running and DM_DISABLE_UDEV environment variable is set. Bypassing udev, device-mapper library will manage device nodes in device directory.


Just a note of warning:
Even though it is possible, it is highly _not recommended_ mixing the udev and non-udev devices in a VG. 
This can cause issues later when manipulating those different LVs, especially after deleting the VG which had LVs created in such a combined way (left over orphaned/dangling nodes in /dev and /dev/mapper).

Comment 7 errata-xmlrpc 2013-02-21 08:15:08 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-0501.html


Note You need to log in before you can comment on or make changes to this bug.