Bug 784040 - Fedora16 installer not detecting an existing installation on system with multipath
Summary: Fedora16 installer not detecting an existing installation on system with mult...
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Fedora
Classification: Fedora
Component: device-mapper-multipath
Version: 16
Hardware: ppc64
OS: All
unspecified
urgent
Target Milestone: ---
Assignee: Ben Marzinski
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2012-01-23 16:21 UTC by IBM Bug Proxy
Modified: 2013-02-14 00:56 UTC (History)
19 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2013-02-14 00:56:04 UTC
Type: ---


Attachments (Terms of Use)
10-dm.rules file with extra debugging variables (6.99 KB, text/plain)
2012-01-23 19:10 UTC, IBM Bug Proxy
no flags Details
11-dm-lvm.rules file with extra debugging variables (1.59 KB, text/plain)
2012-01-24 20:44 UTC, IBM Bug Proxy
no flags Details


Links
System ID Private Priority Status Summary Last Updated
IBM Linux Technology Center 77584 0 None None None Never

Description IBM Bug Proxy 2012-01-23 16:21:59 UTC
During the " Examining Devices " phase of Fedora16 installer on a system with multipath, it will not detect an existing operating system even when one is present.

This was done using the following Fedora16 DVD installer
http://ppc.koji.fedoraproject.org/scratch/karsten/iso/RC3/ppc64/iso/Fedora-16-ppc64-DVD.iso

I am not able to do a "vnc" install with this media because it doesn't let me configure the IP address of my system.  Instead it skips that and launches the VNC session and gives an IP address that isn't valid for my network (172.16.254.252:1)

So instead I did a "serial" install (linux serial debug=1) and went through the text GUI menus.  However, with this install method I don't have an option for "Specialized Storage Devices".  I do have logs from a previous Fedora16 build where I was able to use the VNC installer (fc16 beta rc 6).  

== Comment: 2012.01.05 14:31:50 ==
Discovered a couple workarounds for the network config issue.  From the yaboot prompt use the
following kernel options

linux vnc debug=1 sshd=1 ip=<ip_address> netmask=<netmask_address>
gateway=<gateway_address> dns=<dns_address>

or 

linux vnc debug=1 sshd=1 asknetwork

== Comment: 2012.01.06 10:59:18 ==

[anaconda root@pfdioc03b tmp]# udevadm test --action=change  /devices/virtual/block/dm-8
run_command: calling: test
adm_test: version 173
parse_file: reading '/lib/udev/rules.d/10-dm.rules' as rules file
parse_file: reading '/lib/udev/rules.d/11-dm-lvm.rules' as rules file
parse_file: reading '/lib/udev/rules.d/13-dm-disk.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-libgphoto2.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-multipath.rules' as rules file
parse_file: reading '/lib/udev/rules.d/40-ppc.rules' as rules file
parse_file: reading '/lib/udev/rules.d/42-qemu-usb.rules' as rules file
parse_file: reading '/lib/udev/rules.d/50-firmware.rules' as rules file
parse_file: reading '/lib/udev/rules.d/50-udev-default.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-cdrom_id.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-floppy.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-net.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-pcmcia.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-alsa.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-input.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-serial.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-storage-tape.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-storage.rules' as rules file
parse_file: reading '/lib/udev/rules.d/60-persistent-v4l.rules' as rules file
parse_file: reading '/lib/udev/rules.d/61-accelerometer.rules' as rules file
parse_file: reading '/lib/udev/rules.d/64-md-raid.rules' as rules file
parse_file: reading '/lib/udev/rules.d/65-libsane.rules' as rules file
parse_file: reading '/lib/udev/rules.d/65-md-incremental.rules' as rules file
parse_file: reading '/lib/udev/rules.d/69-cd-sensors.rules' as rules file
parse_file: reading '/lib/udev/rules.d/70-anaconda.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-persistent-cd.rules' as rules file
parse_file: reading '/etc/udev/rules.d/70-persistent-net.rules' as rules file
parse_file: reading '/lib/udev/rules.d/70-uaccess.rules' as rules file
parse_file: reading '/lib/udev/rules.d/70-wacom.rules' as rules file
parse_file: reading '/lib/udev/rules.d/71-seat.rules' as rules file
parse_file: reading '/lib/udev/rules.d/73-seat-late.rules' as rules file
parse_file: reading '/lib/udev/rules.d/75-cd-aliases-generator.rules' as rules file
parse_file: reading '/lib/udev/rules.d/75-net-description.rules' as rules file
parse_file: reading '/lib/udev/rules.d/75-persistent-net-generator.rules' as rules file
parse_file: reading '/lib/udev/rules.d/75-probe_mtd.rules' as rules file
parse_file: reading '/lib/udev/rules.d/75-tty-description.rules' as rules file
parse_file: reading '/lib/udev/rules.d/77-mm-ericsson-mbm.rules' as rules file
parse_file: reading '/lib/udev/rules.d/77-mm-longcheer-port-types.rules' as rules file
parse_file: reading '/lib/udev/rules.d/77-mm-pcmcia-device-blacklist.rules' as rules file
parse_file: reading '/lib/udev/rules.d/77-mm-platform-serial-whitelist.rules' as rules file
parse_file: reading '/lib/udev/rules.d/77-mm-simtech-port-types.rules' as rules file
parse_file: reading '/lib/udev/rules.d/77-mm-usb-device-blacklist.rules' as rules file
parse_file: reading '/lib/udev/rules.d/77-mm-x22x-port-types.rules' as rules file
parse_file: reading '/lib/udev/rules.d/77-mm-zte-port-types.rules' as rules file
parse_file: reading '/lib/udev/rules.d/77-nm-olpc-mesh.rules' as rules file
parse_file: reading '/lib/udev/rules.d/78-sound-card.rules' as rules file
parse_file: reading '/lib/udev/rules.d/80-drivers.rules' as rules file
parse_file: reading '/lib/udev/rules.d/80-mm-candidate.rules' as rules file
parse_file: reading '/etc/udev/rules.d/91-drm-modeset.rules' as rules file
parse_file: reading '/lib/udev/rules.d/95-cd-devices.rules' as rules file
parse_file: reading '/lib/udev/rules.d/95-dm-notify.rules' as rules file
parse_file: reading '/lib/udev/rules.d/95-keyboard-force-release.rules' as rules file
parse_file: reading '/lib/udev/rules.d/95-keymap.rules' as rules file
parse_file: reading '/lib/udev/rules.d/95-udev-late.rules' as rules file
parse_file: reading '/run/udev/rules.d/99-live-mount.rules' as rules file
parse_file: reading '/lib/udev/rules.d/99-systemd.rules' as rules file
udev_rules_new: rules use 153168 bytes tokens (12764 * 12 bytes), 27993 bytes buffer
udev_rules_new: temporary index used 50120 bytes (2506 * 20 bytes)
udev_device_new_from_syspath: device 0x100235d0650 has devpath '/devices/virtual/block/dm-8'
udev_device_new_from_syspath: device 0x100235db410 has devpath '/devices/virtual/block/dm-8'
udev_device_read_db: device 0x100235db410 filled with db file data
udev_rules_apply_to_event: LINK 'mapper/mpathbp3' /lib/udev/rules.d/10-dm.rules:114
udev_rules_apply_to_event: RUN 'socket:/org/kernel/dm/multipath_event' /lib/udev/rules.d/40-multipath.rules:16
udev_rules_apply_to_event: GROUP 6 /lib/udev/rules.d/50-udev-default.rules:68
udev_event_execute_rules: no node name set, will use kernel supplied name 'dm-8'
udev_node_add: creating device node '/dev/dm-8', devnum=253:8, mode=0660, uid=0, gid=6
udev_node_mknod: preserve file '/dev/dm-8', because it has correct dev_t
udev_node_mknod: preserve permissions /dev/dm-8, 060660, uid=0, gid=6
node_symlink: preserve already existing symlink '/dev/block/253:8' to '../dm-8'
link_find_prioritized: found 'b253:8' claiming '/run/udev/links/mapper\x2fmpathbp3'
link_update: creating link '/dev/mapper/mpathbp3' to '/dev/dm-8'
node_symlink: preserve already existing symlink '/dev/mapper/mpathbp3' to '../dm-8'
udev_device_update_db: created db file '/run/udev/data/b253:8' for '/devices/virtual/block/dm-8'
This program is for debugging only, it does not run any program,
specified by a RUN key. It may show incorrect results, because
some values may be different, or not available at a simulation run.

UDEV_LOG=6
DEVPATH=/devices/virtual/block/dm-8
MAJOR=253
MINOR=8
DEVNAME=/dev/dm-8
DEVTYPE=disk
ACTION=change
SUBSYSTEM=block
DM_SBIN_PATH=/sbin
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES_VSN=2
DM_NAME=mpathbp3
DM_UUID=part3-mpath-35000c50017b69adf
DM_SUSPENDED=0
DEVLINKS=/dev/mapper/mpathbp3
MPATH_SBIN_PATH=/sbin
TAGS=:systemd:
run: 'socket:/org/kernel/dm/multipath_event'

<dlehman> that's what we want
<dlehman> is one of the mpath's paths failed?
<hamzy> like disk error?
<dlehman> the device-mapper rules are setting a flag that means anaconda's rules, along with many other standard rules, should ignore these devices
<dlehman> the flag is DM_UDEV_DISABLE_DISK_RULES_FLAG
<dlehman> I'll just paste the udev rules that can set that flag
<dlehman> ENV{DM_UUID}=="mpath-?*", ENV{DM_ACTION}=="PATH_FAILED", GOTO="dm_disable"
<dlehman> ENV{DM_UUID}=="CRYPT-TEMP-?*", GOTO="dm_disable"
<dlehman> ENV{DM_UUID}!="?*", ENV{DM_NAME}=="temporary-cryptsetup-?*", GOTO="dm_disable"
<dlehman> ENV{DISK_RO}=="1", GOTO="dm_disable"
<dlehman> so, I don't know exactly how any of those work, but it looks like: a failed path in an mpath, a temporary cryptsetup device node, or a read-only disk
<hamzy> the SAS card is saying that the multipath path has failed?
<dlehman> DM_ACTION==PATH_FAILED sounds to me like one of the disks/paths became unavailable

== Comment  2012.01.16 15:16:54 ==
I formatted the two hard drives as pdisk and created a RAID 0 array.  I was then able to do an installation of Fedora16 onto the RAID 0 array without issues.  However, we're still hitting this bug when trying to do an install over the existing one.  The installer doesn't detect the existing installation and prompt the user. 

Also, the system that's displaying these issues is being replaced but I'm going to talk to our hardware coordinator to make sure we get the same type of SAS RAID configuration on the new system so we can continue this effort.

== Comment: #5 - 2012.01.23 10:34:22 ==
The installer is running in a multipath environment at the first screen.  I then ssh into the system to poke around.  I notice that, if I enable multipath, then I do not see any problems with udev.

[anaconda root@pfdioc03b ~]# cat << __EOF__ > /etc/multipath.conf
# multipath.conf written by anaconda

defaults {
        user_friendly_names yes
}
blacklist {
        devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
        devnode "^hd[a-z]"
        devnode "^dcssblk[0-9]*"
        device {
                vendor "DGC"
                product "LUNZ"
        }
        device {
                vendor "IBM"
                product "S/390.*"
        }
        # don't count normal SATA devices as multipaths
        device {
                vendor  "ATA"
        }
        # don't count 3ware devices as multipaths
        device {
                vendor  "3ware"
        }
        device {
                vendor  "AMCC"
        }
        # nor highpoint devices
        device {
                vendor  "HPT"
        }
}
multipaths {
}
__EOF__
[anaconda root@pfdioc03b ~]# multipath
create: mpatha (1IBM     IPR-0   1B87E0C4CEFF65C4) undef IBM,IPR-0   1B87E0C4
size=260G features='1 queue_if_no_path' hwhandler='1 alua' wp=undef
|-+- policy='round-robin 0' prio=50 status=undef
| `- 1:255:0:0 sdb 8:16 undef ready running
`-+- policy='round-robin 0' prio=10 status=undef
  `- 0:255:0:0 sda 8:0  undef ready running
[anaconda root@pfdioc03b ~]# dmsetup status -v | egrep "(Name|State)"
Name:              mpathap2
State:             ACTIVE
Name:              mpathap1
State:             ACTIVE
Name:              mpatha
State:             ACTIVE
Name:              live-rw
State:             ACTIVE
Name:              mpathap3
State:             ACTIVE
[anaconda root@pfdioc03b ~]# for ((i = 0; i <= 4; i = i + 1)) do echo "=== dm-$i ==="; udevadm test --action=change  /devices/virtual/block/dm-$i 2>&1 | grep DM_UDEV; done
=== dm-0 ===
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES_VSN=2
=== dm-1 ===
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES_VSN=2
=== dm-2 ===
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES_VSN=2
=== dm-3 ===
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES_VSN=2
=== dm-4 ===
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES_VSN=2


I then navigate the installer to select the multipath device and where it should detect the previously installed system.  However, it is now at the hostname screen.

[anaconda root@pfdioc03b ~]# dmsetup status -v | egrep "(Name|State)"
Name:              mpathap2
State:             ACTIVE
Name:              mpathap1
State:             ACTIVE
Name:              mpatha
State:             ACTIVE
Name:              live-rw
State:             ACTIVE
Name:              mpathap3
State:             ACTIVE
[anaconda root@pfdioc03b ~]# for ((i = 0; i <= 4; i = i + 1)) do echo "=== dm-$i ==="; udevadm test --action=change  /devices/virtual/block/dm-$i 2>&1 | grep DM_UDEV; done
=== dm-0 ===
DM_UDEV_DISABLE_LIBRARY_FALLBACK_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES_VSN=2
=== dm-1 ===
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES_VSN=2
=== dm-2 ===
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES_VSN=2
=== dm-3 ===
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES_VSN=2
=== dm-4 ===
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_PRIMARY_SOURCE_FLAG=1
DM_UDEV_RULES_VSN=2

Notice that udev now has the DM_UDEV_DISABLE_DISK_RULES_FLAG flag set?

Comment 1 IBM Bug Proxy 2012-01-23 19:10:35 UTC
------- Comment From hamzy.com 2012-01-23 14:10 EDT-------
[anaconda root@pfdioc03b ~]# vi /lib/udev/rules.d/10-dm.rules
[anaconda root@pfdioc03b ~]# cp /lib/udev/rules.d/10-dm.rules /etc/udev/rules.d/
[anaconda root@pfdioc03b ~]# udevadm control --reload-rules
[anaconda root@pfdioc03b ~]# multipath -F
[anaconda root@pfdioc03b ~]# ls -l /sys/devices/virtual/block
total 0
drwxr-xr-x. 8 root root 0 Jan 23 16:32 dm-0
drwxr-xr-x. 8 root root 0 Jan 23 16:32 loop0
drwxr-xr-x. 8 root root 0 Jan 23 16:32 loop1
drwxr-xr-x. 8 root root 0 Jan 23 16:32 loop2
drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop3
drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop4
drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop5
drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop6
drwxr-xr-x. 7 root root 0 Jan 23 16:32 loop7

Okay, I modified /lib/udev/rules.d/10-dm.rules to the above attached file.  I then pressed the back button in the installer to the first screen.  After unloading the multipath device and reloading udev rules, I went through the selection screens until the point where the existing OS should be detected (but hostname screen is shown).

DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1

As you can see above, I am not creating a debug environment variable for one of the dm_disable conditions.  It looks like it was imported from somewhere via:

IMPORT{db}="DM_UDEV_DISABLE_DISK_RULES_FLAG"

Comment 2 IBM Bug Proxy 2012-01-23 19:10:48 UTC
Created attachment 557033 [details]
10-dm.rules file with extra debugging variables


------- Comment (attachment only) From hamzy.com 2012-01-23 14:04 EDT-------

Comment 3 IBM Bug Proxy 2012-01-23 19:30:32 UTC
------- Comment From hamzy.com 2012-01-23 14:26 EDT-------
I also check to see if /lib/udev/rules.d/11-dm-lvm.rule was setting the flag, but it does not look that way.

[anaconda root@pfdioc03b ~]# for ((i = 0; i <= 4; i = i + 1)) do echo "=== dm-$i ==="; udevadm test
--action=change  /devices/virtual/block/dm-$i 2>&1 | grep DM_UDEV; done
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_YZMAH_START=1
DM_UDEV_YZMAH_START1=1
DM_UDEV_YZMAH_START2=1
DM_UDEV_YZMAH_LVM_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_YZMAH_START=1
DM_UDEV_YZMAH_START1=1
DM_UDEV_YZMAH_START2=1
DM_UDEV_YZMAH_LVM_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_YZMAH_START=1
DM_UDEV_YZMAH_START1=1
DM_UDEV_YZMAH_START2=1
DM_UDEV_YZMAH_LVM_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_YZMAH_START=1
DM_UDEV_YZMAH_START1=1
DM_UDEV_YZMAH_START2=1
DM_UDEV_YZMAH_LVM_DONE=1
DM_UDEV_HAMZY_START=1
DM_UDEV_HAMZY_START2=1
DM_UDEV_HAMZY_START3=1
DM_UDEV_HAMZY_START4=1
DM_UDEV_HAMZY_START5=1
DM_UDEV_HAMZY_START6=1
DM_UDEV_DISABLE_DISK_RULES_FLAG=1
DM_UDEV_HAMZY_DONE=1
DM_UDEV_YZMAH_START=1
DM_UDEV_YZMAH_START1=1
DM_UDEV_YZMAH_START2=1
DM_UDEV_YZMAH_LVM_DONE=1

Comment 4 Mark Hamzy 2012-01-24 20:39:15 UTC
Hey Harald,

Can you take a look at this defect? I don't know DM_UDEV_DISABLE_DISK_RULES_FLAG is being set.  It seems that the line:

IMPORT{db}="DM_UDEV_DISABLE_DISK_RULES_FLAG"

Is pulling this flag from an internal database.  What code is setting that flag inside udev?

Comment 5 IBM Bug Proxy 2012-01-24 20:44:34 UTC
Created attachment 557310 [details]
11-dm-lvm.rules file with extra debugging variables


------- Comment (attachment only) From hamzy.com 2012-01-24 15:41 EDT-------

Comment 6 Harald Hoyer 2012-01-25 08:42:54 UTC
(In reply to comment #4)
> Hey Harald,
> 
> Can you take a look at this defect? I don't know
> DM_UDEV_DISABLE_DISK_RULES_FLAG is being set.  It seems that the line:
> 
> IMPORT{db}="DM_UDEV_DISABLE_DISK_RULES_FLAG"
> 
> Is pulling this flag from an internal database.  What code is setting that flag
> inside udev?

you have to ask the device-mapper/lvm guys. It's their flag, which they store in the udev DB

Comment 7 Harald Hoyer 2012-01-25 09:11:09 UTC
basically, I think, it's because, if they have already seen the dm device and it's disabled, they set the flag in "/lib/udev/rules.d/10-dm.rules"

Just read 10-dm.rules (and watch for "dm_disable") and ask the device-mapper team for details.

Comment 8 IBM Bug Proxy 2012-01-25 15:30:51 UTC
------- Comment From hamzy.com 2012-01-25 10:29 EDT-------
As I've stated previously in the defect, I've included 10-dm.rules in this defect with a debugging version and none of the dm_disable gotos are being executed.

Comment 9 Mark Hamzy 2012-01-26 15:57:08 UTC
Hey Doug,

Could you take a look at this defect for me.  I am trying to understand how this flag is being set in udev.  How does the device-mapper/lvm2 code store this flag in the udev database?  I am not seeing it set by the udev rules.  Do you have some special API to tell udev to set flags?

Comment 10 Mark Hamzy 2012-01-26 16:07:18 UTC
Also, Harald, have I written 10-dm.rules correctly to debug this problem?

Comment 11 Doug Ledford 2012-01-26 17:40:14 UTC
I'm not the right person to answer your questions.  I handle the MD raid stuff, not the LVM/Multipath stuff.

However, I would suggest looking in 40-multipath.rules as those are going to be relevant to these multipath devices.  And I know they want to reference a multipath configuration file on the system during normal operation, I don't know if they are managing to pull that configuration off the hard disk during an upgrade however.

Comment 12 Mark Hamzy 2012-02-02 19:40:33 UTC
Hi Kay,

Can you help me debugging this problem?  Have I written 10-dm.rules correctly to debug this problem?

Comment 13 Phil Knirsch 2012-02-03 14:47:28 UTC
I suspect Ben Marzinski knows a lot more about the multipath part here as he's maintaining the device-mapper-multipath component.

Anything you can see here going wrong, Ben?

Thanks & regards, Phil

Comment 14 Ben Marzinski 2012-02-07 17:47:04 UTC
Multipathd set that flag in order to keep blkid from running whenever the device is reloaded. If all paths are down and multipath is queueing IO, this will keep the the device stuck open.  Unfortunately this is causing problems with reinstalls.  The issue is that if udev doesn't run blkid on every udev change event, the data is removed from the udev database.  It's possible to fix this in
10-dm.rules, but not without causing other issues.  Since devices that are set to
queue forever when all paths are down can get stuck open on any IO that happens to them after all paths have failed, we decided that solving this one case wasn't worth the other complications it created, so the patch that sets that flag will get removed in RHEL and fedora. I'm re-assigning this bug to device-mapper-multipath, unless anyone has any objections.

Comment 15 Fedora End Of Life 2013-01-16 22:24:14 UTC
This message is a reminder that Fedora 16 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 16. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '16'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 16's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 16 is end of life. If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora, you are encouraged to click on 
"Clone This Bug" and open it against that version of Fedora.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping

Comment 16 Fedora End Of Life 2013-02-14 00:56:09 UTC
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.


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