Bug 171770

+++ This bug was initially created as a clone of Bug #105932 +++

I have a problem using LVM on a loopback file.
It seems to me that this issue has been reported once on RH9 but was 
disregarded bescause support for this OS is no longer done by RedHat.

Here are the steps to reproduce:

# dd if=/dev/zero of=/tmp/toto bs=1024k count=512
# losetup /dev/loop1 /tmp/toto
# vgscan
# pvcreate /dev/loop1
# vgcreate testvg /dev/loop1
# lvcreate -n testlv -L 128M testvg
# mkfs.ext3 /dev/testvg/testlv
# mount /dev/testvg/testlv /mnt/test
mount: you must specify the filesystem type
# mount -t ext2 /dev/testvg/testlv /mnt/test
mount: wrong fs type, bad option, bad superblock on /dev/testvg/testlv,
       or too many mounted file systems

Thanks for your help


From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4a) Gecko/20030425

Description of problem:
Using LVM on a loopback device does not work with the redhat kernels. 
Everything seems to work right up to the point where I would mount an (ext2)
filesystem built on a logical volume in a volume group that was created using a
loopback device for the physical volume.

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

How reproducible:
Always

Steps to Reproduce:
1. [root@klmontg tmp]# dd if=/dev/zero of=fake_disk.img bs=1M count=500
500+0 records in
500+0 records out

2. [root@klmontg tmp]# losetup /dev/loop0 fake_disk.img

3. [root@klmontg tmp]# pvcreate /dev/loop0 pvcreate -- physical volume
"/dev/loop0" successfully created

4. [root@klmontg tmp]# vgcreate /dev/vgtest /dev/loop0
vgcreate -- INFO: using default physical extent size 4 MB vgcreate -- INFO:
maximum logical volume size is 255.99 Gigabyte vgcreate -- doing automatic
backup of volume group "vgtest" vgcreate -- volume group "vgtest" successfully
created and activated
 
5. [root@klmontg tmp]# lvcreate --name lv_one --size 200M /dev/vgtest lvcreate
-- doing automatic backup of "vgtest" lvcreate -- logical volume
"/dev/vgtest/lv_one" successfully created
 
6. [root@klmontg tmp]# mke2fs /dev/vgtest/lv_one
mke2fs 1.32 (09-Nov-2002)
Filesystem label=
OS type: Linux
Block size=1024 (log=0)
Fragment size=1024 (log=0)
51200 inodes, 204800 blocks
10240 blocks (5.00%) reserved for the super user
First data block=1
25 block groups
8192 blocks per group, 8192 fragments per group
2048 inodes per group
Superblock backups stored on blocks:
        8193, 24577, 40961, 57345, 73729
 
Writing inode tables: done
Writing superblocks and filesystem accounting information: done
 
This filesystem will be automatically checked every 26 mounts or 180 days,
whichever comes first.  Use tune2fs -c or -i to override.

6. [root@klmontg tmp]# e2fsck /dev/vgtest/lv_one e2fsck 1.32 (09-Nov-2002)
Couldn't find ext2 superblock, trying backup blocks...
e2fsck: Bad magic number in super-block while trying to open /dev/vgtest/lv_one
 
The superblock could not be read or does not describe a correct ext2 
filesystem.
 If the device is valid and it really contains an ext2 filesystem (and not swap
or ufs or something else), then the superblock is corrupt, and you might try
running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 
7. [root@klmontg tmp]# e2fsck -b 8193 /dev/vgtest/lv_one
e2fsck 1.32 (09-Nov-2002)
e2fsck: Bad magic number in super-block while trying to open /dev/vgtest/lv_one
 
The superblock could not be read or does not describe a correct ext2 
filesystem.
 If the device is valid and it really contains an ext2 filesystem (and not swap
or ufs or something else), then the superblock is corrupt, and you might try
running e2fsck with an alternate superblock:
    e2fsck -b 8193 <device>
 
8. [root@klmontg tmp]# mount /dev/vgtest/lv_one /mnt
mount: you must specify the filesystem type

9. [root@klmontg tmp]# mount -t ext2 /dev/vgtest/lv_one /mnt
mount: wrong fs type, bad option, bad superblock on /dev/vgtest/lv_one,
       or too many mounted file systems


Actual Results:  Results are listed with the steps.

Expected Results:  The filesystem appears to have been built correctly with
mke2fs, but after that everything else doesn't work.  I would expect for the
e2fsck to work, and for the filesystem on my LV to successfully mount and be 
usable.

Additional info:

I've tried doing this on RedHat 8.0 and 9 with both the 2.4.18 kernels and the
2.4.20 kernels, including the latest kernel errata 2.4.20-20.9.

The following steps work when using a vanilla kernel of the 2.4.20 or greater
series (I haven't tried kernels earlier than this from kernel.org)

-- Additional comment from riel on 2004-07-15 07:36 EST --
I'm sorry, but support for Red Hat Linux 9 is no longer done by Red
Hat, since the product is EOL.

Please ask the Fedora Legacy people, at http://www.fedoralegacy.org/