Bug 216032
Summary: | Installing FC6 with LVM2 on 2nd parallel drive causes LVM of 1st drive with FC5 to be corrupted | ||||||
---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Sven Oostenbrink <sven> | ||||
Component: | lvm2 | Assignee: | Milan Broz <mbroz> | ||||
Status: | CLOSED NOTABUG | QA Contact: | Corey Marthaler <cmarthal> | ||||
Severity: | urgent | Docs Contact: | |||||
Priority: | medium | ||||||
Version: | 6 | CC: | agk, dwysocha, jbrassow, mbroz, prockai, pvrabec, sven | ||||
Target Milestone: | --- | Keywords: | Reopened | ||||
Target Release: | --- | ||||||
Hardware: | i386 | ||||||
OS: | Linux | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | 2006-12-06 14:31: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: | |||||||
Attachments: |
|
Description
Sven Oostenbrink
2006-11-16 20:45:28 UTC
Created attachment 141413 [details]
results of pvscan -vvvv, vgscan -vvvv, and head -n380 /dev/hda2, separated by a number of empty lines.
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 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. # Kickstart file automatically generated by anaconda. install cdrom 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 5pass=$1$VUhKFhsq$gc2m9dYmKvnjvXjfzhmwW1 # 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 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.. 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? 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... 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. 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.. |