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 784648 - Occasionally a device is ignored when obtain_device_list_from_udev is set
Summary: Occasionally a device is ignored when obtain_device_list_from_udev is set
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: udev
Version: 6.2
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Harald Hoyer
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-25 16:49 UTC by Milan Broz
Modified: 2013-03-01 04:11 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
In previous version of udev, the udev_device_get_devnode() function of libudev returned NULL, if the function got called, before udevd processed the uevent for the device node. udev_device_get_devnode() now returns the kernel provided devnode in this case.
Clone Of:
Environment:
Last Closed: 2012-06-20 14:22:38 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)
Proposed patch (948 bytes, patch)
2012-01-26 15:38 UTC, Milan Broz
no flags Details | Diff


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2012:0906 0 normal SHIPPED_LIVE udev bug fix and enhancement update 2012-06-19 20:46:51 UTC

Description Milan Broz 2012-01-25 16:49:27 UTC
Description of problem:

Repeating test with lvm2 2.02.89 snapshot shows that sometimes udev returns NULL
for device path causing internal device scan to ignore some disk.

This scan can be disabled in lvm.conf by
obtain_device_list_from_udev = 0

but because rpm will not update lvm.conf if user modified it by hand and default is enabled, we can see serious regressions on RHEL6 after update.

So the best seems to be just switch default for lvm2 in RHEL6.3:

-- a/lib/config/defaults.h
+++ b/lib/config/defaults.h
@@ -29,7 +29,7 @@
 
 #define DEFAULT_DEV_DIR "/dev"
 #define DEFAULT_PROC_DIR "/proc"
-#define DEFAULT_OBTAIN_DEVICE_LIST_FROM_UDEV 1
+#define DEFAULT_OBTAIN_DEVICE_LIST_FROM_UDEV 0
 #define DEFAULT_SYSFS_SCAN 1
 #define DEFAULT_MD_COMPONENT_DETECTION 1
 #define DEFAULT_MD_CHUNK_ALIGNMENT 1

Version-Release number of selected component (if applicable):
Found on lvm2 testing snapshot lvm2-2.02.89-0.19.el6

Reproducer is quite problematic, on my cluster node for VG over 4 PVs this script:

while true; do  echo "**********"; lvcreate -L100M -n LV test ;  lvremove -f test/LV ; done

sometime produces
**********
  Couldn't find device with uuid 73fgBs-nCRJ-WNts-wju9-pVoS-cOVY-f1ZV65.
  Cannot change VG test while PVs are missing.
  Consider vgreduce --removemissing.
  One or more specified logical volume(s) not found.
**********

after analysis, we found path=NULL
...
6  0x08090a60 in _insert (path=0x0, rec=0, check_with_udev_db=0) at device/dev-cache.c:577
#7  0x0809123c in _insert_udev_dir (dev_scan=<value optimized out>) at device/dev-cache.c:513
#8  _insert_dirs (dev_scan=<value optimized out>) at device/dev-cache.c:543
#9  _full_scan (dev_scan=<value optimized out>) at device/dev-cache.c:626
#10 0x080914e6 in dev_iter_create (f=0x95e6600, dev_scan=0) at device/dev-cache.c:924
#11 0x08086f83 in lvmcache_label_scan (cmd=0x95cd8c0, full_scan=0) at cache/lvmcache.c:607
#12 0x080c5336 in _vg_read (cmd=0x95cd8c0, vgname=0xbfa9191b "test", vgid=0x0, warnings=1, consistent=0xbfa9009c, precommitted=0) at metadata/metadata.c:2925
#13 0x080c5a9c in vg_read_internal (cmd=0x95cd8c0, vgname=0xbfa9191b "test", vgid=0x0, warnings=1, consistent=0xbfa9009c) at metadata/metadata.c:3340
#14 0x080c5cad in _vg_lock_and_read (cmd=0x95cd8c0, vg_name=0xbfa9191b "test", vgid=0x0, flags=1048576) at metadata/metadata.c:3957
#15 vg_read (cmd=0x95cd8c0, vg_name=0xbfa9191b "test", vgid=0x0, flags=1048576) at metadata/metadata.c:4061
#16 0x080c6368 in vg_read_for_update (cmd=0x95cd8c0, vg_name=0xbfa9191b "test", vgid=0x0, flags=0) at metadata/metadata.c:4072
#17 0x08060dbc in lvcreate (cmd=0x95cd8c0, argc=1, argv=0xbfa904d4) at lvcreate.c:977
#18 0x08064b4f in lvm_run_command (cmd=0x95cd8c0, argc=1, argv=0xbfa904d4) at lvmcmdline.c:1073
#19 0x080676bf in lvm2_main (argc=5, argv=0xbfa904c4) at lvmcmdline.c:1439
#20 0x080810b8 in main (argc=5, argv=0xbfa904c4) at lvm.c:21

(I will report udev bug if we can reproduce it reliably but the best is just disable this option by default.)

Comment 1 Alasdair Kergon 2012-01-25 16:58:41 UTC
We are still in development.  The feature should be understood and fixed. not disabled.

Comment 2 Milan Broz 2012-01-25 17:03:51 UTC
Sure. Send a patch then ;-)

Comment 3 Milan Broz 2012-01-26 13:07:41 UTC
udev_device_get_devnode(device) seems to return NULL sometimes...

#6  0x080914c3 in _insert_udev_dir (dev_scan=<value optimized out>) at device/dev-cache.c:515
#7  _insert_dirs (dev_scan=<value optimized out>) at device/dev-cache.c:546
#8  _full_scan (dev_scan=<value optimized out>) at device/dev-cache.c:629
#9  0x08091526 in dev_iter_create (f=0x9074600, dev_scan=0) at device/dev-cache.c:927
#10 0x08086fa3 in lvmcache_label_scan (cmd=0x905b8c0, full_scan=0) at cache/lvmcache.c:607
#11 0x080c53a6 in _vg_read (cmd=0x905b8c0, vgname=0xbf837927 "test", vgid=0x0, warnings=1, consistent=0xbf835d9c, 
    precommitted=0) at metadata/metadata.c:2925
#12 0x080c5b0c in vg_read_internal (cmd=0x905b8c0, vgname=0xbf837927 "test", vgid=0x0, warnings=1, 
    consistent=0xbf835d9c) at metadata/metadata.c:3340
#13 0x080c5d1d in _vg_lock_and_read (cmd=0x905b8c0, vg_name=0xbf837927 "test", vgid=0x0, flags=1048576)
    at metadata/metadata.c:3957
#14 vg_read (cmd=0x905b8c0, vg_name=0xbf837927 "test", vgid=0x0, flags=1048576) at metadata/metadata.c:4061
#15 0x080c63d8 in vg_read_for_update (cmd=0x905b8c0, vg_name=0xbf837927 "test", vgid=0x0, flags=0)
    at metadata/metadata.c:4072
#16 0x08060dbc in lvcreate (cmd=0x905b8c0, argc=1, argv=0xbf8361d4) at lvcreate.c:977
#17 0x08064b4f in lvm_run_command (cmd=0x905b8c0, argc=1, argv=0xbf8361d4) at lvmcmdline.c:1073
#18 0x080676bf in lvm2_main (argc=5, argv=0xbf8361c4) at lvmcmdline.c:1439
#19 0x080810c8 in main (argc=5, argv=0xbf8361c4) at lvm.c:21
(gdb) frame 6
#6  0x080914c3 in _insert_udev_dir (dev_scan=<value optimized out>) at device/dev-cache.c:515
515                     if (!node_name) abort();
(gdb) list
510                     if (!device_entry) abort();
511                     device = udev_device_new_from_syspath(udev, udev_list_entry_get_name(device_entry));
512
513                     if (!device) abort();
514                     node_name = udev_device_get_devnode(device);
515                     if (!node_name) abort();
516                     r &= _insert(node_name, 0, 0);
517
518                     udev_list_entry_foreach(symlink_entry, udev_device_get_devlinks_list_entry(device)) {
519                             symlink_name = udev_list_entry_get_name(symlink_entry);
(gdb) p node_name
$1 = <value optimized out>
(gdb) p device
$2 = (struct udev_device *) 0x9097e68

Comment 4 Milan Broz 2012-01-26 13:35:31 UTC
libudev: udev_list_entry_add: 'DEVPATH=/devices/pci0000:00/0000:00:02.0/0000:05:00.3/0000:0a:01.0/host2/rport-2:0-0/target2:0:0/2:0:0:1/block/sdd' added
libudev: udev_device_new_from_syspath: device 0x908bec8 has devpath '/devices/pci0000:00/0000:00:02.0/0000:05:00.3/0000:0a:01.0/host2/rport-2:0-0/target2:0:0/2:0:0:1/block/sdd'
libudev: udev_list_entry_add: 'MAJOR=8' added
libudev: udev_list_entry_add: 'MINOR=48' added
libudev: udev_list_entry_add: 'DEVNAME=sdd' added
libudev: udev_list_entry_add: 'DEVNAME' is already in the list
libudev: udev_list_entry_add: 'DEVNAME' value replaced with 'sdd'
libudev: udev_list_entry_add: 'DEVTYPE=disk' added
libudev: udev_list_entry_add: 'DEVTYPE' is already in the list
libudev: udev_list_entry_add: 'DEVTYPE' value replaced with 'disk'
libudev: get_sys_link: resolved link to: 'block'
libudev: udev_list_entry_add: 'SUBSYSTEM=block' added
libudev: udev_device_read_db: no db file to read /dev/.udev/db/block:sdd: No such file or directory
Aborted (core dumped)
*

Comment 5 Milan Broz 2012-01-26 15:35:59 UTC
Backporting this commit seems to fixes it...

commit cdb1d7608a2e2ba708a890eeab6e5e99409a1953
Author: Kay Sievers <kay.sievers>
Date:   Fri Oct 22 13:50:55 2010 +0200

    libudev: return kernel provided devnode when asked before we handled any rules

Comment 6 Milan Broz 2012-01-26 15:38:52 UTC
Created attachment 557692 [details]
Proposed patch

Comment 7 Milan Broz 2012-01-26 15:42:03 UTC
Reassigning to udev.

Bug present in version udev-147-2.40.el6

When backported, we need lvm2 in RHEL6.3 require this build, otherwise some operations can be unreliable if udev based scan is switched on...

Comment 11 Harald Hoyer 2012-04-27 10:20:33 UTC
    Technical note added. If any revisions are required, please edit the "Technical Notes" field
    accordingly. All revisions will be proofread by the Engineering Content Services team.
    
    New Contents:
In previous version of udev, the udev_device_get_devnode() function of libudev returned NULL, if the function got called, before udevd processed the uevent for the device node. udev_device_get_devnode() now returns the kernel provided devnode in this case.

Comment 13 errata-xmlrpc 2012-06-20 14:22:38 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-2012-0906.html


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