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:
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 group.
There've been lots of changes: have recent versions fixed this?
Assuming fixed by 2.00.29. Reopen if not.