Bug 197548 - auto-mounting of external disks fails with device-mapper mappings
Summary: auto-mounting of external disks fails with device-mapper mappings
Alias: None
Product: Fedora
Classification: Fedora
Component: device-mapper-multipath
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Alasdair Kergon
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2006-07-03 23:22 UTC by Alexandre Oliva
Modified: 2007-11-30 22:11 UTC (History)
8 users (show)

Clone Of:
Last Closed: 2006-09-07 22:56:20 UTC

Attachments (Terms of Use)
Output of multipath -v4, as requested (4.53 KB, text/plain)
2006-07-17 17:35 UTC, Alexandre Oliva
no flags Details

Description Alexandre Oliva 2006-07-03 23:22:46 UTC
Description of problem:
The new device-mapper-based device naming seems to have broken gnome's ability
to mount external hard disks, direct use of partitions in such external disks
for raid devices and possibly more.  In the case of mdadm, I can work around the
inability to reference /dev/sda* by referencing /dev/mapper/someuglyname*, but
that's not quite as intuitive and will probably break lots of existing scripts.

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

How reproducible:
Every time

Steps to Reproduce:
1.Plug in external USB disk while logged into gnome

Actual results:
The external disk won't be mounted automatically.

Expected results:
It should be.

Additional info:

Comment 1 Harald Hoyer 2006-07-04 06:45:47 UTC
and why is this a bug of udev and not the gnome automounting system?

Comment 2 Alexandre Oliva 2006-07-04 14:35:14 UTC
Because the KDE automounting system is broken as well and there's other fallout
from the change in (presumably) udev that introduced all of this dm-based magic.
 Even if it's not a bug in udev per se, it was the change in (presumably) udev
that caused all of it, so at the very least you need one tracking bug like this
to dupe others into and/or clone into other fallouts.

Comment 3 Harald Hoyer 2006-07-05 07:51:58 UTC
There was no change in udev, besides of switching to udev in the first place.

Could you please explain
"the inability to reference /dev/sda* by referencing /dev/mapper/someuglyname*"
a little bit more. I'm not sure, if I understand the problem completly.

Comment 4 Alexandre Oliva 2006-07-10 03:49:36 UTC
# mount /dev/sdc1 /media/DV5000
mount: /dev/sdc1 already mounted or /media/DV5000 busy
# mount /dev/mapper/20010b92000d5b665p1 /media/DV5000

/dev/sdc1 is no longer available.  I can't mount it, and I can't add it as a
raid member.  I have to use the ugly /dev/mapper name.  I'm not even sure that
unmounting the external disk is enough to be able to disconnect it safely,
without leaving dangling device-mapper devices around.

Comment 5 Harald Hoyer 2006-07-10 09:18:51 UTC
1. /dev/sdc1 is available as a device node?
2. /proc/mounts does not show sdc1 already mounted?

Comment 6 Alexandre Oliva 2006-07-10 16:24:42 UTC
Yes, it is available, and it is in use only by device-mapper.

Comment 7 Harald Hoyer 2006-07-12 06:56:34 UTC
so why is this a problem/bug of udev?

Comment 8 Alexandre Oliva 2006-07-12 19:26:38 UTC
I don't know, it was just my best guess.  I thought it was udev that had the
rules that caused the newly-available disks to be turned into device-mapper
devices.  If not, please reassign this to the appropriate package.

Comment 9 Alexandre Oliva 2006-07-15 09:09:25 UTC
As it turns out, it is device-mapper-multipath that decides that any external
disk gets multipath dm devices created for it, rendering their original /dev
devices busy and unavailable for the raid subsystem.

Comment 10 Alasdair Kergon 2006-07-15 12:37:05 UTC
You don't say which version of device-mapper-multipath package you used!  If
it's prior to 0.4.7-2.0 then please update it and retest.

Comment 11 Alexandre Oliva 2006-07-15 15:19:11 UTC
Latest test was with 0.4.7-3.1.

FWIW, one way to avoid the problem is to get at least one of the disk partitions
to become busy before device-mapper-multipath's magic strikes, e.g., by having
raidautorun by initrd's /init script to activate one of the raid members present
in the external disk.  In this case, the external disk has another partition
mounted successfully at log in.  Booting without the disk plugged in, and then
plugging it in after udev is already running, however, restores the broken

See bug 197547 for more information on other problems this magic is causing.

Comment 12 Ben Marzinski 2006-07-17 15:07:43 UTC
What's in your /etc/multipath.conf file?

It should have the following lines at the top:

# Blacklist all devices by default. Remove this to enable multipathing
# on the default devices. 
devnode_blacklist {
        devnode "*"

This is the file that is installed by the rpm unless there already is an
/etc/multipath.conf file on the machine. With these lines in my configuration
file, I don't see any multipathed devices.

If you have these lines in you file, and they aren't commented out, and you are
getting multipathed devices anyway. Could you please plug in external device,
run multipath -F to remove all the multipath mappings, and then run multipath
-v4 and put the output in this bugzilla.

Comment 13 Alexandre Oliva 2006-07-17 17:35:21 UTC
Created attachment 132560 [details]
Output of multipath -v4, as requested

# grep -v ^# /etc/multipath.conf 

devnode_blacklist {
	devnode "*"

defaults {
	user_friendly_names yes

I've attached the output of multipath -v4 after multipath -F.  Thanks for
looking into this.

Comment 14 Ben Marzinski 2006-07-17 20:18:31 UTC

Well, it seems like I was the one looking at outdated code.  Change the config
file from

devnode_blacklist {
	devnode "*"


blacklist {
	devnode "*"

And your problems should go away. I'll get a new package built that fixes the
default config file.

Comment 15 Ben Marzinski 2006-07-17 23:50:18 UTC
There's a new build 0.4.7-4.0 that has a better default config file. 
Unfortunately, like I mentioned earlier, the new config file only gets installed
if there isn't a config file already there, so you have to uninstall the old rpm,
or simply delete /etc/multipath.conf before you upgrade.

Comment 16 Alexandre Oliva 2006-07-28 20:56:10 UTC
Wouldn't it be better if the new config file got installed only if the config
file in place hadn't been changed?  I'm pretty sure there's a simple way to
accomplish this with rpm, I'm just not sure what it is.

Anyhow, the original problem is fixed, feel free to CLOSE/RAWHIDE.

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