Bug 126565

Summary: 2.6.6-435 causes problems with LVM2
Product: [Fedora] Fedora Reporter: Heiko Jakob <buffalo>
Component: lvm2Assignee: Alasdair Kergon <agk>
Status: CLOSED RAWHIDE QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: 2CC: dkelson
Target Milestone: ---   
Target Release: ---   
Hardware: i386   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-12-03 16:04:31 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Heiko Jakob 2004-06-23 11:28:13 UTC 
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 12:26:25 UTC 
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 06:17:35 UTC 
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
group.
Comment 3 Alasdair Kergon 2004-11-16 18:10:06 UTC 
There've been lots of changes: have recent versions fixed this?
Comment 4 Alasdair Kergon 2004-12-03 16:04:31 UTC 
Assuming fixed by 2.00.29.
Reopen if not.