Red Hat Bugzilla – Bug 126565
2.6.6-435 causes problems with LVM2
Last modified: 2007-11-30 17:10:45 EST
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
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
8a. boot 2.6.6smp-435: System stops with: /dev/Volume00/LogVol00 has a
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.
2.6.6smp-435 messes up all Volumegroups
2.6.5-358 messes up Volumegroups with RAID-5 PVs
Both 2.6.6smp-435 and 3.6.5smp-358 shouldn't have any problems with
LVM2 on mixed raid devices
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
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
There've been lots of changes: have recent versions fixed this?
Assuming fixed by 2.00.29.
Reopen if not.