Bug 126565 - 2.6.6-435 causes problems with LVM2
2.6.6-435 causes problems with LVM2
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Alasdair Kergon
Depends On:
  Show dependency treegraph
Reported: 2004-06-23 07:28 EDT by Heiko Jakob
Modified: 2007-11-30 17:10 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-12-03 11:04:31 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Heiko Jakob 2004-06-23 07:28:13 EDT
Description of problem:

2.6.6-435 reports a bad superblock for / when / is located in a LVM2
logical volume and a volumegroup ( not the one / is located in ) has a
raid5 physical volume.

Version-Release number of selected component (if applicable):
Fedora Core 2
kernel 2.6.5smp-358 & kernel-2.6.6smp-435

How reproducible:
This is 100% reproducable on my SMP system.

Steps to Reproduce:
1. Install FC2 on LVM2 using 2 Raid-1 PVs. (md0/md1) Volume00/LogVol00
2. upgrade to 2.6.6smp-435
3. create 2 other raid sets one with Raid1 one with Raid5. (md2/md3) 
4. mark them as physical volumes # pvcreate /dev/md2 ; pvcreate /dev/md3
5. Create a new volumegroup # vgcreate Volume01 /dev/md2 /dev/md3
6. Create some filesystems on this new Volumegroup
# lvcreate -n testLv -L 10G ; mkfs.ext3 /dev/Volume01/testLV
7. Reboot
8a. boot 2.6.6smp-435: System stops with: /dev/Volume00/LogVol00 has a
bad superblock.
8b. boot 2.6.5smp-358: System allerts: Physical volumes .... for
Volumegroup Volume01 not found. Disabling Volumegroup Volume01. Also
in /proc/mdstat the raid5 mddevice created under 2.6.6smp-435 seems
not not exist.

Actual results:
2.6.6smp-435 messes up all Volumegroups
2.6.5-358 messes up Volumegroups with RAID-5 PVs

Expected results:
Both 2.6.6smp-435 and 3.6.5smp-358 shouldn't have any problems with
LVM2 on mixed raid devices 

Additional info:
Comment 1 Heiko Jakob 2004-06-23 08:26:25 EDT
I did some further investigation on this problem and found out that:

2.6.5smp-358 has the same problem like 2.6.6smp-435 when not failing
to locate PVs for Volume01. That means, that this bug is two bugs and
it has only a few to do with raid5:

1.) the minor problem: Raid5 devices created under 2.6.6smp-435 won't
work under 2.6.5-358.  /proc/mdstat doesn't recognize them and the
start of the Volumegroups containing raid 5 devices will fail.

2.) the major problem: Having / in a logical volume and more than 1
Volumegroup exists on the system will result in a report of a bad
superblock on / during boot. It's not really a bad superblock, but
fsck reports it and the boot procedure stops by dropping you on the
password or Ctrl-D line to fix it. 
After removing the additional Volumegroup, everything get's ok.

I found this out by replacing the raid5 device with some raid1
devices. That resulted in: 2.6.5smp-358 finds the additional
Volumegroup and messes up during the boot process like 2.6.6-435

Regards Heiko Jakob 
Comment 2 Heiko Jakob 2004-06-24 02:17:35 EDT
This bug could be a duplicate of Bug #120292. I'm not sure, but
there's also a problem about LVM2 and badblocks at startup with newer
kernel versions. What i don't know is, has this guy more than 1 volume
Comment 3 Alasdair Kergon 2004-11-16 13:10:06 EST
There've been lots of changes: have recent versions fixed this?
Comment 4 Alasdair Kergon 2004-12-03 11:04:31 EST
Assuming fixed by 2.00.29.
Reopen if not.

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