Bug 437209 - system-config-lvm throws a 'AttributeError: 'NoneType' object has no attribute 'add_extent_block'' traceback when run with multipath.
system-config-lvm throws a 'AttributeError: 'NoneType' object has no attribut...
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: system-config-lvm (Show other bugs)
4.6
x86_64 Linux
high Severity high
: rc
: ---
Assigned To: Jim Parsons
Corey Marthaler
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-03-12 17:48 EDT by Stuart R. Kirk
Modified: 2010-10-22 19:12 EDT (History)
8 users (show)

See Also:
Fixed In Version: RHBA-2008-0654
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-07-24 15:06:36 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Traceback thrown when s-c-lvm is started. (3.22 KB, text/plain)
2008-03-12 17:52 EDT, Stuart R. Kirk
no flags Details
A verbose lvs (3.83 KB, text/plain)
2008-03-12 17:55 EDT, Stuart R. Kirk
no flags Details
fdisk -l and pvscan (10.29 KB, text/plain)
2008-03-12 18:01 EDT, Stuart R. Kirk
no flags Details
s-c-lvm output using modified lvm_model.py on a system that is working. (101.17 KB, text/plain)
2008-03-27 11:02 EDT, Stuart R. Kirk
no flags Details
Output from multipath -ll on working machine. (7.93 KB, text/plain)
2008-03-27 14:00 EDT, Stuart R. Kirk
no flags Details
Output from multipath -ll on non-working machine. (2.98 KB, text/plain)
2008-03-27 14:01 EDT, Stuart R. Kirk
no flags Details

  None (edit)
Description Stuart R. Kirk 2008-03-12 17:48:05 EDT
Description of problem:

When running s-c-lvm, it throws a traceback (attached) upon scan and fails to start.

Version-Release number of selected component (if applicable):

RHEL 4.5 AS x86_64
device-mapper-multipath 0.4.5-27.el4_6.3
system-config-lvm 1.0.23-1.0.  

How reproducible:
Unknown.

Steps to Reproduce:
1. Install RHEL 4.5 AS x86_64
2. Install device-mapper-multipath and system-config-lvm
3. Configure LVM to make use of /dev/mpath entries as PVs.
4. up2date -uf to RHEL 4.6 AS x86_64
5. Run s-c-lvm
  
Actual results:


Expected results:


Additional info:
Comment 1 Stuart R. Kirk 2008-03-12 17:52:48 EDT
Created attachment 297849 [details]
Traceback thrown when s-c-lvm is started.

Traceback thrown when s-c-lvm is started.
Comment 2 Stuart R. Kirk 2008-03-12 17:55:58 EDT
Created attachment 297850 [details]
A verbose lvs

Per jparsons, I was asked to run a scan with a more verbose lvs output so that
he could see what was going on.  This is the output of the command: lvs
--nosuffix --noheadings --units b --separator \; -o
lv_name,vg_name,stripes,stripesize,lv_attr,lv_uuid,devices,origin,snap_percent,seg_start,seg_size,vg_extent_size,lv_size,mirror_log
--all
Comment 3 Stuart R. Kirk 2008-03-12 18:01:53 EDT
Created attachment 297851 [details]
fdisk -l and pvscan

Again, per jparsons I have recorded a copy of fdisk -l and pvscan so that the
disk configuration can be ascertained.
Comment 4 Stuart R. Kirk 2008-03-27 11:02:08 EDT
Created attachment 299337 [details]
s-c-lvm output using modified lvm_model.py on a system that is working.
Comment 5 Stuart R. Kirk 2008-03-27 14:00:30 EDT
Created attachment 299369 [details]
Output from multipath -ll on working machine.
Comment 6 Stuart R. Kirk 2008-03-27 14:01:14 EDT
Created attachment 299371 [details]
Output from multipath -ll on non-working machine.
Comment 8 Bryn M. Reeves 2008-04-17 11:53:26 EDT
Can you attach an lvmdump from the two systems so I can try to reproduce with
the same metadata you're using?

Just run the command "lvmdump" and attach the tarball it drops into /root.
Comment 18 Jim Parsons 2008-06-03 10:51:17 EDT
I have worked very dilligently to reproduce this problem. I procurred dual-I/O
qlogic fiber cards and installed them in a test cluster we have available in
Westford. Then, I set up multiple fiber paths to storage and ran s-c-lvm on the
node. I cannot get this to fail.

That said, however, a traceback should never occur and I have modified the code
so that if the error described here does happen, an exception is caught and an
explanatory dialogue window is displayed. 

Ready to build this stopgap solution today.
Comment 19 Dave Wysochanski 2008-06-03 11:12:44 EDT
What is in /etc/lvm/lvm.conf?  In particular, the filter line should filter out
the /dev/sd* devices and you should be setting preferred_path to
/dev/mapper/mpath*, not /dev/mpath/... devices.  Something like this (assumes
all /dev/sd* devices are underlying paths of dm-mp):
    # Show multipath names if there are any
    preferred_names = [ "/dev/mapper" ]

    # Filter out underlying /dev/sd* devices (these are underlying dm-mp paths)
    filter = [ "r|/dev/sd.*|", "a/.*/" ]


I saw the below step #3 in the description and it made me wonder if a
misconfiguration exposed this problem.

Steps to Reproduce:
1. Install RHEL 4.5 AS x86_64
2. Install device-mapper-multipath and system-config-lvm
===>3. Configure LVM to make use of /dev/mpath entries as PVs.
Comment 25 Jim Parsons 2008-06-11 10:54:37 EDT
testing and completing it now. will build today
Comment 28 Jim Parsons 2008-06-25 13:11:12 EDT
Yes - This problem was originally evident in a cluster. I set up a similar MP
configuration on one of our test clusters many weeks ago, and could not
reproduce. I have tinkered on this during the entire 4.7 dev cycle with no luck,
BUT: Tracebacks should not happen, so I thought it was at least worthwhile
adding and exception handler for this condition, instead of just marking the bug
CANT_REPRODUCE. 

Using this application on a cluster with multiple paths to shared storage is a
common occurence. No other user has reported this condition, so I feel confident
this must be a peculiarity in the way the reporters cluster storage is set up.
All I can do is remain vigilent for a similar report in the future and trap this
condition so that the application doesn't quit.
Comment 33 errata-xmlrpc 2008-07-24 15:06:36 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2008-0654.html

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