[dm-devel] Blacklist broken?

Thu Jul 21 17:17:11 UTC 2011

I've received 0 responses since sending this.  So either people don't have a clue where to start to fix it, or they don't consider it their problem.  Some kind of response would be nice.  Bottom line is that being able to compile dm-multipath into initrd but without any way to enforce a blacklist is somewhat broken.  Since the majority of people do not boot from a multipath device, it would seem that the default option should be to not install dm-multipath into the initrd if the possibility exists of it grabbing a non-multipath boot disk and locking it up during pre-boot.

-brian

On 7/14/11 5:02 PM, "Brian Stamper" <brian.p.stamper at nasa.gov> wrote:

Ok, so I've isolated this.  It appears that dracut is loading dm_multipath into initram and has no blacklist configuration.  At some point initram should release disks, but it doesn't.  At least not in time for the system to attempt its routine fsck on /boot.  I didn't have this problem on a very similar machine that I upgraded last week that also runs multipath.  The one difference that comes to mind is that the most recent host was build on FC11 or even potentially FC9 and has been upgraded multiple times.  The host that went smoothly was built on FC13 a couple months ago and upgraded only once.

This is a fairly serious problem, and if I hadn't had so many issues with dracut in the last year I would have never solved it myself.  I'm not sure if the responsibility lies with the dracut team or with the dm-multipath team, but it should probably be fixed.  I was able to recompile the initrd with dracut -o dm_multipath and now my system boots cleanly.  But I don't really consider this a "fix" and I don't want to have to recompile my initrd everytime I get a kernel update across multiple systems.

-brian

On 7/14/11 4:06 PM, "Brian Stamper" <brian.p.stamper at nasa.gov> wrote:

I just upgrade an FC13 system to FC15, and now multipath is grabbing the system drive before the normal fsck can run, which is causing the machine to not boot.  I get the message: "Filesystem mounted or opened exclusively by another program? "  Now, I can simply control-d to continue, but why is multipath grabbing the drive?  I've blacklisted it every way I can, using devnode, using wwid, it simply ignores it and continues to create a path map for /dev/sda.

device-mapper-1.02.63-3.fc15.x86_64
device-mapper-multipath-0.4.9-15.fc15.x86_64
device-mapper-libs-1.02.63-3.fc15.x86_64

2.6.38.8-35.fc15.x86_64

mpath0 (36001ec90ee4ee600105ac65e04e84e61) dm-0 DELL,PERC 6/i
size=279G features='0' hwhandler='0' wp=rw
`-+- policy='round-robin 0' prio=1 status=active
  `- 2:2:0:0  sda 8:0   active ready running

[root at bonjovi ~]# blkid | grep boot
/dev/sda1: LABEL="/boot" UUID="8ed92bb6-0ddb-4fbc-907d-fdf12e5550a3" TYPE="ext3" SEC_TYPE="ext2"
/dev/mapper/mpath0p1: LABEL="/boot" UUID="8ed92bb6-0ddb-4fbc-907d-fdf12e5550a3" TYPE="ext3"

>From multipath.conf:

blacklist {
        wwid 36001ec90ee4ee600105ac65e04e84e61
        devnode "/dev/sda"
        devnode "/dev/sda1"
}
devnode_blacklist {
        wwid 36001ec90ee4ee600105ac65e04e84e61
        devnode "^(ram|raw|loop|fd|md|dm-|sr|scd|st)[0-9]*"
        devnode "^hd[a-z]"
        devnode "^cciss!c[0-9]d[0-9]*"
        devnode "sda"
        devnode "/dev/sda"
}

I've even tried blacklisting by /disk/by/uuid.  What does it take to get multipath to quit grabbing this disk?

-brian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/dm-devel/attachments/20110721/e6eabd45/attachment.htm>