LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   Slackware 12 won't mount lvm2 vols if shutdown with a snapshot vol. (http://www.linuxquestions.org/questions/slackware-14/slackware-12-wont-mount-lvm2-vols-if-shutdown-with-a-snapshot-vol-609234/)

akschu 12-26-2007 01:32 PM

Slackware 12 won't mount lvm2 vols if shutdown with a snapshot vol.
 
This is very easy to duplicate:

1. Install slackware 12.
2. Create a group:
Code:

# vgcreate grp_home /dev/sda7
3. Create a volume:
Code:

# lvcreate -L1500 -n vol_home grp_home
4. Make a filesystem:
Code:

# mke2fs -j /dev/grp_home/vol_home
5. mount the file system:
Code:

# mount /dev/grp_home/vol_home /home
6. Make a snapshot:
Code:

# lvcreate -L500 -s -n snp_home /dev/grp_home/vol_home
Ok, so far so good, I have my snapshot of /home. You can see that it's working just fine:

Code:

root@server01:/# lvdisplay
  --- Logical volume ---
  LV Name                /dev/grp_home/vol_home
  VG Name                grp_home
  LV UUID                6XsUIm-YEv0-IUob-t1v2-GY4R-HDQ9-ATNg0C
  LV Write Access        read/write
  LV snapshot status    source of
                        /dev/grp_home/snp_home [active]
  LV Status              available
  # open                1
  LV Size                1.46 GB
  Current LE            375
  Segments              1
  Allocation            inherit
  Read ahead sectors    0
  Block device          253:0

  --- Logical volume ---
  LV Name                /dev/grp_home/snp_home
  VG Name                grp_home
  LV UUID                axupXY-2BbR-ZAJn-V7DM-tHVI-eSpi-mSj19e
  LV Write Access        read/write
  LV snapshot status    active destination for /dev/grp_home/vol_home
  LV Status              available
  # open                0
  LV Size                1.46 GB
  Current LE            375
  COW-table size        500.00 MB
  COW-table LE          125
  Allocated to snapshot  0.00%
  Snapshot chunk size    8.00 KB
  Segments              1
  Allocation            inherit
  Read ahead sectors    0
  Block device          253:3

Now I change my fstab to mount /home at boot, then I kick it.

It doesn't create the /dev/grp_home devices and it reports the following errors:

Code:

device-mapper: table: 253:1: snapshot-origin: unknown target type
device-mapper: ioctl: error adding target to table
EXT3-fs: unable to read superblock

If I manually run vgscan again it will create the block devices, but the filesystem isn't there so I can't mount /home.

The second I delete the snapshot everything works fine:

Code:

# lvremove /dev/grp_home/snp_home
Logical volume "snp_home" successfully removed

Now it works:
Code:

root@server01:~# mount /home
root@server01:~#

Does anyone know why this happens? Almost certainly it's a bug in LVM2, however that is maintained by the Redhat crowd which means that there probably isn't a way to report the problem on another distro.

Any thoughts would be very helpful.

schu

evilDagmar 12-27-2007 06:39 AM

Report it upstream, anyway.

akschu 12-30-2007 01:46 AM

Ok, figured it out:

In slackware 12 there is a bug where the dm-snapshot kernel module is not loaded when LVM2 volumes are brought up. This causes any volume that has a snapshot to fail to mount with the error:

device-mapper: table: 253:1: snapshot-origin: unknown target type

This patch to /etc/rc.d/rc.S fixes the problem by getting the list of logical volumes and if any of them depend on a snapshot it loads the module.

Eric, if your around, please include the patch in the next slackware release as currently any volumes with a snapshot are not mounted on boot.

Thanks,
schu


--- rc.S.orig 2007-12-29 18:22:03.000000000 -0900
+++ rc.S 2007-12-29 15:23:06.000000000 -0900
@@ -49,6 +49,10 @@
# Try to load a device-mapper kernel module:
/sbin/modprobe -q dm-mod
fi
+ # if we have a snapshot then load the snapshot module:
+ if /sbin/lvdisplay --ignorelockingfailure | grep -q snapshot; then
+ /sbin/modprobe -q dm-snapshot
+ fi
# Scan for new volume groups:
/sbin/vgscan --mknodes --ignorelockingfailure 2> /dev/null
if [ $? = 0 ]; then

akschu 01-03-2008 01:02 AM

I found another bug in Slackware 12:

Code:

root@server01:/etc/udev/rules.d# lvremove -f /dev/grp_home/snp_home
  Logical volume "snp_home" successfully removed

root@server01:/etc/udev/rules.d# lvcreate -L1500 -s -p r -n snp_home /dev/grp_home/vol_home
  Logical volume "snp_home" created

root@server01:/etc/udev/rules.d# lvremove -f /dev/grp_home/snp_home
  Logical volume "snp_home" successfully removed

root@server01:/etc/udev/rules.d# lvcreate -L1500 -s -p r -n snp_home /dev/grp_home/vol_home
  LV grp_home/snp_home in use: not deactivating
  Couldn't deactivate new snapshot.

root@server01:/etc/udev/rules.d# lvremove -f /dev/grp_home/snp_home
  Logical volume "snp_home" successfully removed

root@server01:/etc/udev/rules.d# lvcreate -L1500 -s -p r -n snp_home /dev/grp_home/vol_home
  Logical volume "snp_home" created

As you can see sometimes it will create a snapshot and somtimes it won't. The problem is that udev is creating the device so when lvcreate goes to create it again, it thinks it's already in use. Because lvm2 manages it's own dev devices udev should be told not to muck with them:

Code:

--- 64-device-mapper.rules.orig 2008-01-02 14:02:02.000000000 -0900
+++ 64-device-mapper.rules      2008-01-02 14:41:10.000000000 -0900
@@ -2,6 +2,7 @@
 # becomes available; some table-types must be ignored

 KERNEL=="device-mapper",      NAME="mapper/control"
+KERNEL=="dm-[0-9]*",          OPTIONS+="ignore_device"

 KERNEL!="dm-*", GOTO="device_mapper_end"
 ACTION!="add|change", GOTO="device_mapper_end"

With this patch to /etc/udev/rules.d/64-device-mapper.rules it now works.

For those that don't want to patch, installing udev-116-i486-1 from -current also seems to fix the problem.

schu


All times are GMT -5. The time now is 01:20 AM.