lvm volumes fail to mount when specified as /dev/vg-name/volume

I can reproduce this here with an fstab entry for "/dev/dario2/root". /var/log/udev attached, as requested by Scott.

Yup, this is because the /dev/vg/lv symlink is created by LVM and udev (and thus Upstart and mountall) know nothing about it.

I guess the proper fix for this will be to add something to lvm2's udev rules to seed this symlink in there as well.

Haven't figured out shell to split

    DM_NAME=ubuntu--vg-ubuntu--lv

into

 /dev/ubuntu-vg/ubuntu-lv

yet (which is how we think LVM does the -s, but we should check)

This does the trick in bash, but *not* in sh/dash:

DM_NAME=ubuntu--vg-ubuntu--lv
t=${DM_NAME//--/_}
vg=${t%-*}; vg=${vg/_/-}
lv=${t#*-}; lv=${lv/_/-}
echo "/dev/$vg/$lv"

This will do in Posix sh but uses sed:

echo /dev/$DM_NAME | sed -e 's/-/\//g' -e 's/\/\//-/g'

On Thu, 2009-09-17 at 15:50 +0000, Rick Spencer wrote:

> ** Changed in: lvm2 (Ubuntu Karmic)
> Importance: High => Critical
>
> ** Changed in: lvm2 (Ubuntu Karmic)
> Assignee: (unassigned) => Robbie Williamson (robbie.w)
>
Is Robbie going to personally fix this? :-)

And could you stop going around marking everything as OMG CRITICAL. It
really doesn't help.

This really doesn't affect many people, so:

 status medium

Scott
--
Scott James Remnant
<email address hidden>

Opening a mountall task to make it easier to track (since people tend to file bugs there first)

The fix will come from lvm2 though

This bug make my system unbootable. As this bug affects ALL people who uses lvm2, why mark the importance only medium?

Because not only do not ALL users use lvm2, but MOST users who use lvm2 do not use the /dev/vg/lv scheme and instead use /dev/mapper/vg-lv or UUID= (UUID= has always been the ubuntu-preferred method)

For the record we've always explicitly *not* preferred UUID= on LVM devices since the naming scheme is already stable.

On Fri, 2009-09-25 at 15:17 +0000, Colin Watson wrote:
> For the record we've always explicitly *not* preferred UUID= on LVM
> devices since the naming scheme is already stable.

And given that the UUID is apparently from the filesystem (at least in
the case of ext2/3/4), when you snapshot a device you get a UUID
conflict and can never really be sure which one gets mounted.

Sure, I suppose one could/should change the UUID of a filesystem once
it's snapshotted, but in reality, that doesn't happen.

In my case it was very difficult to detect what was preventing the system from starting. It would be very helpful if mountall could give more information about what is happening.

On Fri, 2009-09-25 at 16:44 +0000, Felipe Gil Castiñeira wrote:
> In my case it was very difficult to detect what was preventing the
> system from starting. It would be very helpful if mountall could give
> more information about what is happening.

I would second (and third!) that.

I have uploaded the fix for this to the archive, since we're in beta freeze this may take a while to appear so I have also uploaded it to the ubuntu-boot PPA. Please test.

This bug was fixed in the package devmapper - 2:1.02.27-4ubuntu7

---------------
devmapper (2:1.02.27-4ubuntu7) karmic; urgency=low

  * For LVM2 devices, create the /dev/VG/LV symlink figuring out the name
    by running "lvm lvdisplay" on the device. LP: #430542.

 -- Scott James Remnant <email address hidden> Sun, 27 Sep 2009 14:28:00 -0700

A similar fix might be needed to allow booting of a system with RAID devices identified by names of the form /dev/md_dX (instead of /dev/mdX). See bug #486361.

Regarding RAID devices, I noticed just now that the /dev/md_dX names don't even exist any more on my system. They were definitely there before I upgraded from Jaunty to Karmic over the weekend.

See the "DEVICE NAMES" section of mdadm(8) for evidence that device file names of the form /dev/md_dNN do (did? should?) in fact exist.

My guess is that this is a "devmapper" issue, and not a "mountall" problem, but this is just a guess on my part.