Bug 216032 - Installing FC6 with LVM2 on 2nd parallel drive causes LVM of 1st drive with FC5 to be corrupted
Installing FC6 with LVM2 on 2nd parallel drive causes LVM of 1st drive with F...
Product: Fedora
Classification: Fedora
Component: lvm2 (Show other bugs)
i386 Linux
medium Severity urgent
: ---
: ---
Assigned To: Milan Broz
Corey Marthaler
: Reopened
Depends On:
  Show dependency treegraph
Reported: 2006-11-16 15:45 EST by Sven Oostenbrink
Modified: 2013-02-28 23:04 EST (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-12-06 09:31: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)
results of pvscan -vvvv, vgscan -vvvv, and head -n380 /dev/hda2, separated by a number of empty lines. (285.34 KB, text/plain)
2006-11-16 15:45 EST, Sven Oostenbrink
no flags Details

  None (edit)
Description Sven Oostenbrink 2006-11-16 15:45:28 EST
Description of problem:
I had a system with FC5 installed on a P-ATA drive using LVM2. Volune Group name
of this install is VolGroup00. This system worked correctly for some 6 months.
Then I decided to install FC6. I added a S-ATA drive, and installed FC6 from
DVD. During the install process I selected to use LVM, set the Volumne Group
name to be "svenfedoracore6". The first attempt to install hung during the
"copying installation package to drive" or something like that, so I attempted
to install again with the same parameters. This time, installation worked ok,
and I rebooted into FC6. No problem there. First of all, I was surprised that
FC5 would not show up in grub, but ok.. 

When I disconnected the FC6 drive, to boot in FC5 again, it crashed seconds
after grub with a message that VolGroup00 could not be read, ergo, the logical
volumes could not be read. Since swap, /, /home, basically everything except
/boot is in LVM, it could not mount swap, kernel panic.

Restarting in FC6, with the FC5 drive still attached, and using lvm tools, the
FC5 VG does no longer show up, except in lvmdiskscan. vgscan doesnt show
anything, pvscan neither..  I added results from both using the -vvvv option.. I
also added the first 400 lines of my /dev/hda2 so you can take a look at the
data directly.

Version-Release number of selected component (if applicable):
LVM version:     2.02.06 (2006-05-12)
Library version: 1.02.07 (2006-05-11)

How reproducible:
The way I figure it, have FC5 installed with LVM.. Then add a second drive,
install FC6 to that drive with LVM (give VG new name, or mayby not?), select
lots of packages.. if it hangs somewhere during formatting, or copying install
image or something like that, reboot.. reinstall, only dont select any extra
packages.. reboot after install, FC6 will work, drive with FC5 should have extra
(broken) records in the LVM header..

Steps to Reproduce:
1. Have drive with FC5 with LVM (VG is the default VolGroup00)
2. Add second drive
3. Install FC6 on that second drive with LVM as well.. Change VG name or leave
it default (just to be sure)
4. after install, FC5 drive should be damaged. The LVM will have extra records,
from which one seems damaged. no lvm tool will see the drive, except for

Actual results:
FC5 drive has extra seqno records.. 

Expected results:
FC5 drive should be untouched!

Additional info:
This FC5 drive contains _ALL_ my data, personal photos, videos, my
administration, work data, etc etc etc.. As far as I can see, the data is still
there, its just the LVM header that is damaged... If there is any way to
retrieve this data, please help me.. I will be _VERY_ much in trouble if I loose
it for ever..

thanks, and good luck

Sven Oostenbrink
Comment 1 Sven Oostenbrink 2006-11-16 15:45:28 EST
Created attachment 141413 [details]
results of pvscan -vvvv, vgscan -vvvv, and head -n380 /dev/hda2, separated by a number of empty lines.
Comment 2 Sven Oostenbrink 2006-11-16 20:12:56 EST
One comment about the file containing the data of head /dev/hda2 -n380: The
records showing are from AFTER I performed an vgcfgrestore -f
/etc/lvm/backup/VolGroup00 --uuid hljiEA-9iFJ-4zOT-6bK7-T4wM-zZ64-B20po4 VolGroup00

This added another seqno (7) to the list
Comment 3 Milan Broz 2006-12-04 10:32:45 EST
Could you please post here which type of disk layout you selected during
installation ? -> paste here anaconda kickstart file (to the %packages line -
after FC6 installation (in /root/anaconda-ks.cfg).

Metadata shows that your fc5 volume was removed on Nov 9 - so you probably
selected default installation and then volume was correctly removed during
installation process.
Comment 4 Sven Oostenbrink 2006-12-04 17:50:28 EST
# Kickstart file automatically generated by anaconda.

lang en_US.UTF-8
keyboard us
xconfig --driver "nv" --resolution 800x600 --depth 24 --startxonboot
network --device eth0 --bootproto dhcp
network --device eth1 --onboot no --bootproto dhcp
rootpw --iscrypted $1$EixNwW.2$l/0mcsLMhla4LlHAaeU8Z.
firewall --enabled --port=22:tcp
authconfig --enableshadow --enablemd5
selinux --enforcing
timezone --utc America/Mexico_City
bootloader --location=partition --driveorder=hda,sda --append="rhgb quiet" --md
# The following is the partition information you requested
# Note that any partitions you deleted are not expressed
# here so unless you clear all partitions first, this is
# not guaranteed to work
#clearpart --linux --drives=sda
#part /boot --fstype ext3 --size=100 --ondisk=sda
#part pv.8 --size=0 --grow --ondisk=sda
#part pv.2 --noformat --onpart hda2
#volgroup svenfedoracore6 --noformat --pesize=32768 pv.8
#logvol / --fstype ext3 --name=root --vgname=svenfedoracore6 --size=44992
#logvol swap --fstype swap --name=swap --vgname=svenfedoracore6 --size=2976
#logvol /home --fstype ext3 --name=home --vgname=svenfedoracore6 --size=30400
Comment 5 Sven Oostenbrink 2006-12-04 17:57:47 EST
I just posted the kickstart file, but I doubt it will be of much help.. This
file is from the _second_ install, the first install hung / crashed on
formatting.. nothing happened for 15 minutes, which is not normal, so I resetted
the computer.

The second install went just fine.

I just have been able to fix the corrupted LVM header. I needed to re-create the
PV with the correct UUID, and after that, using the last correct record from the
LVM header and vgcfgrestore, I could repair that part of the damage. The LVM is
ok now, but ALL filesystems are damaged.. I am about to start recovery with
multiple programs to see what I can recover

As a VERY IMPORTANT hint: By default, PLEASE, dont call the VG's VolGroup00..
Call them VolGroup9gK3lz948fK or something.. something random, so that
installing on a second parrallel disk with the same volume group name wont
damage the other PV..
Comment 6 Petr Rockai 2006-12-05 11:15:52 EST
As for the hint, i have just tested that anaconda creates VolGroup01 by 
default in case VolGroup00 does exist on accessible devices when installing. 
So that is definitely not the problem you have observed. Since it sees 
VolGroup00, there's no easy way to run over it using anaconda, you can add PVs 
and LVs to the group but that is unlikely to break in the manner you describe. 
Especially, nothing should run over the filesystems, no matter what you do to 
the metadata. Are you absolutely sure you didn't wipe the drive in your first 
install attempt?
Comment 7 Petr Rockai 2006-12-05 11:18:21 EST
For the record, i have finished going through your scenario (without the hang 
in the middle) and no apparent damage happened. I have selected hda for fc5 
and hdb for fc6, let the automatic partitioner do all the rest. Fc5 is in a 
perfectly bootable shape after the procedure. It would help if you could 
supply more details on how to reproduce or try reproducing yourself...
Comment 8 Milan Broz 2006-12-06 04:18:30 EST
It seems that wrong option was selected during the first install.
This is not definitely bug in lvm. Please if you hit this again with correct
installer settings report bug for anaconda installer.
Comment 9 Sven Oostenbrink 2006-12-19 19:10:42 EST
As a reply on comment #6: No, I am 100% positive I did not wipe the drive in any
way during the first install attempt, and wile the drive is NOT wiped, there IS
damage to the metadata.. At least, a less /dev/hda1 shows me what appear to be a
number of normal LVM records, created by FC5, then a record created by FC6, and
then what looks like half an LVM record, or something like that.. 

Though I have been able to repair the LVM volumes, I still have not had the time
to repair the drive, Im a bit too busy with work. Once I have started recovery,
I hope I can tell you a bit more about the state of the drive. AFAIK, the data
should pretty much still be there..

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