Cannot mount old drive with LVM partition - help!
in [Linux Help]
|
Prev: Fatal server error: no screens found
Next: "disagrees about version of symbol struct_module" after addingSMP support
From: Ohmster on 4 Oct 2006 00:19 Ohmster <nowayin(a)hell.com> wrote in news:Xns9851F3F31A964MyBigKitty@ 81.174.50.80: > This is a real problem, I need to come up with some kind of linux disk > recovery tools to try and get that second partition restored. I did try > testdisk... > > http://www.cgsecurity.org/wiki/TestDisk This is interesting. I am still running testdisk on the drive and decided to try advanced. In there I can change the file type (Will not be written to the disk.) I choose linux, 83 instead of LVM 8e. The disk is scanning now, not sure of what it is doing but it is going at it. See here: --------------------------------------------------------------------- TestDisk 6.4, Data Recovery Utility, June 2006 Christophe GRENIER <grenier(a)cgsecurity.org> http://www.cgsecurity.org Disk /dev/hdb - 203 GB / 189 GiB - CHS 24792 255 63 Partition Start End Size in sectors 2 P Linux 13 0 1 24791 254 63 398074635 Search EXT2/EXT3 superblock 163210601/398074635 41% Ext2 superblock found at sector 49154 (block=6144, blocksize=4096) Stop --------------------------------------------------------------------- Well it is at 51% now, let's see what it does. If it won't write this change to disk, then what good is this I cannot tell you but it is going at it now. Well, here are the results. --------------------------------------------------------------------- TestDisk 6.4, Data Recovery Utility, June 2006 Christophe GRENIER <grenier(a)cgsecurity.org> http://www.cgsecurity.org Disk /dev/hdb - 203 GB / 189 GiB - CHS 24792 255 63 Partition Start End Size in sectors Linux 16 15 15 24537 126 52 393936896 superblock 0, blocksize=4096 [ Quit ] Return to Advanced menu --------------------------------------------------------------------- Exactly what good this is is beyond me. I still cannot get at my files, nor is this filesytem type change permenent or written to disk. ...sigh. -- ~Ohmster theohmster at comcast dot net Put "messageforohmster" in message body to pass my spam filter.
From: noi on 4 Oct 2006 03:06 On Wed, 04 Oct 2006 01:13:46 +0000, Ohmster wrote this: > "J.O. Aho" <user(a)example.net> wrote in > news:4oe6heFe14qbU1(a)individual.net: > >> deactivating the LVM won't in a magical way change the slice data >> >> >> //Aho > > Dam! :( I was hoping knoppix would have read the hdb2. Don't get hasty if you're unsure. If FC3 is really not a critical as in home system vs work system you can take your time and carefully recover your data. Before Webmin this was a simple change ie, $ vmchange -an # disables all lvm $ vmrename volgroup00 volgroup01 $ vmchange -ay Basically rename the volgroup00 (on hda) to volgroup01 or whatever so hdb would be volgroup00. Then change the volgroup name as often as necessary. Now it's unknown what you actually have but I think your hdb is still under LVM. Some LVM prints might help etc. $ vgscan $ pvdisplay $ pvscan $ fdisk -l on hda and hdb Found an article (snippet below) on recovering RAID and LVM volumes. It's not for the faint hearted. Plz read the recovering Lvm2 volume part of article (and displays) entirely. BTW /dev/md2 is raid drive so I'd think you'd substitute /dev/hdb. ----- http://www.linuxjournal.com/article/8874 Recovering and Renaming the LVM2 Volume The next hurdle is that the system now will have two sets of lvm2 disks with VolGroup00 in them. Typically, the vgchange -a -y command would allow LVM2 to recognize a new volume group. That won't work if devices containing identical volume group names are present, though. Issuing vgchange -a y will report that VolGroup00 is inconsistent, and the VolGroup00 on the RAID device will be invisible. To fix this, you need to rename the volume group that you are about to mount on the system by hand-editing its lvm configuration file. If you made a backup of the files in /etc on raidbox, you can edit a copy of the file /etc/lvm/backup/VolGroup00, so that it reads VolGroup01 or RestoreVG or whatever you want it to be named on the system you are going to restore under, making sure to edit the file itself to rename the volume group in the file. If you don't have a backup, you can re-create the equivalent of an LVM2 backup file by examining the LVM2 header on the disk and editing out the binary stuff. LVM2 typically keeps copies of the metadata configuration at the beginning of the disk, in the first 255 sectors following the partition table in sector 1 of the disk. See /etc/lvm/lvm.conf and man lvm.conf for more details. Because each disk sector is typically 512 bytes, reading this area will yield a 128KB file. LVM2 may have stored several different text representations of the LVM2 configuration stored on the partition itself in the first 128KB. Extract these to an ordinary file as follows, then edit the file: dd if=/dev/md2 bs=512 count=255 skip=1 of=/tmp/md2-raw-start vi /tmp/md2-raw-start You will see some binary gibberish, but look for the bits of plain text. LVM treats this metadata area as a ring buffer, so there may be multiple configuration entries on the disk. On my disk, the first entry had only the details for the physical volume and volume group, and the next entry had the logical volume information. Look for the block of text with the most recent timestamp, and edit out everything except the block of plain text that contains LVM declarations. This has the volume group declarations that include logical volumes information. Fix up physical device declarations if needed. If in doubt, look at the existing /etc/lvm/backup/VolGroup00 file to see what is there. On disk, the text entries are not as nicely formatted and are in a different order than in the normal backup file, but they will do. Save the trimmed configuration as VolGroup01. This file should then look like Listing 6.
From: noi on 4 Oct 2006 03:28 On Wed, 04 Oct 2006 07:06:34 +0000, noi wrote this: > On Wed, 04 Oct 2006 01:13:46 +0000, Ohmster wrote this: > >> "J.O. Aho" <user(a)example.net> wrote in >> news:4oe6heFe14qbU1(a)individual.net: >> >>> deactivating the LVM won't in a magical way change the slice data >>> >>> >>> //Aho >> >> Dam! :( > I was hoping knoppix would have read the hdb2. Don't get hasty if you're > unsure. If FC3 is really not a critical as in home system vs work system > you can take your time and carefully recover your data. > > Before Webmin this was a simple change ie, > Sorry I these should have been vgchange, vgrename > $ vgchange -an # disables all lvm > $ vgrename /dev/volgroup00 /dev/volgroup01 > $ vgchange -ay > > Basically rename the volgroup00 (on hda) to volgroup01 or whatever so hdb > would be volgroup00. Then change the volgroup name as often as necessary. > > Now it's unknown what you actually have but I think your hdb is still > under LVM. Some LVM prints might help etc. > > $ vgscan $ lvscan > $ pvdisplay > $ pvscan > $ fdisk -l on hda and hdb > > Found an article (snippet below) on recovering RAID and LVM volumes. It's > not for the faint hearted. Plz read the recovering Lvm2 volume part of > article (and displays) entirely. BTW /dev/md2 is raid drive so I'd think > you'd substitute /dev/hdb. > > ----- http://www.linuxjournal.com/article/8874 > > Recovering and Renaming the LVM2 Volume > > The next hurdle is that the system now will have two sets of lvm2 disks > with VolGroup00 in them. Typically, the vgchange -a -y command would allow > LVM2 to recognize a new volume group. That won't work if devices > containing identical volume group names are present, though. Issuing > vgchange -a y will report that VolGroup00 is inconsistent, and the > VolGroup00 on the RAID device will be invisible. To fix this, you need to > rename the volume group that you are about to mount on the system by > hand-editing its lvm configuration file. > > If you made a backup of the files in /etc on raidbox, you can edit a copy > of the file /etc/lvm/backup/VolGroup00, so that it reads VolGroup01 or > RestoreVG or whatever you want it to be named on the system you are going > to restore under, making sure to edit the file itself to rename the volume > group in the file. > > If you don't have a backup, you can re-create the equivalent of an LVM2 > backup file by examining the LVM2 header on the disk and editing out the > binary stuff. LVM2 typically keeps copies of the metadata configuration at > the beginning of the disk, in the first 255 sectors following the > partition table in sector 1 of the disk. See /etc/lvm/lvm.conf and man > lvm.conf for more details. Because each disk sector is typically 512 > bytes, reading this area will yield a 128KB file. LVM2 may have stored > several different text representations of the LVM2 configuration stored on > the partition itself in the first 128KB. Extract these to an ordinary file > as follows, then edit the file: > > dd if=/dev/md2 bs=512 count=255 skip=1 of=/tmp/md2-raw-start > > vi /tmp/md2-raw-start > > > You will see some binary gibberish, but look for the bits of plain text. > LVM treats this metadata area as a ring buffer, so there may be multiple > configuration entries on the disk. On my disk, the first entry had only > the details for the physical volume and volume group, and the next entry > had the logical volume information. Look for the block of text with the > most recent timestamp, and edit out everything except the block of plain > text that contains LVM declarations. This has the volume group > declarations that include logical volumes information. Fix up physical > device declarations if needed. If in doubt, look at the existing > /etc/lvm/backup/VolGroup00 file to see what is there. On disk, the text > entries are not as nicely formatted and are in a different order than in > the normal backup file, but they will do. Save the trimmed configuration > as VolGroup01. This file should then look like Listing 6.
From: Ohmster on 5 Oct 2006 21:53 noi <noi(a)siam.com> wrote in news:VoJUg.11235$6S3.5260 @newssvr25.news.prodigy.net: > Sorry I these should have been vgchange, vgrename Noi, I have saved the original post to a text file and have made the corrections. It looks like what you have here is the only way left to recover this disk and I really wish to thank you for this. During the week I have no time to think, let alone fix a Linux distro. I will get back to this on the weekend, time permitting. Thanks again buddy, will keep you updated. -- ~Ohmster theohmster at comcast dot net Put "messageforohmster" in message body to pass my spam filter.
From: Ohmster on 5 Oct 2006 23:49
noi <noi(a)siam.com> wrote in news:_3JUg.11229$6S3.4315(a)newssvr25.news.prodigy.net: > Found an article (snippet below) on recovering RAID and LVM volumes. > It's not for the faint hearted. Plz read the recovering Lvm2 volume > part of article (and displays) entirely. BTW /dev/md2 is raid drive > so I'd think you'd substitute /dev/hdb. Dude this might work! I did follow the instructions that you gave me and also referred to the original web page here: http://www.linuxjournal.com/article/8874 I created the backup file as described in the article, my VolGroup01 looks like this: --------------------------------------------------------------------- VolGroup01 { id = "Pu8j7l-2dEd-GhU7-tBAr-HDq7-r6OF-23O8Jo" seqno = 1 status = ["RESIZEABLE", "READ", "WRITE"] extent_size = 8192 max_lv = 0 max_pv = 0 physical_volumes { pv0 { id = "xE0F6K-q9r4-1K3o-iYuh-NlWc-9597-8WGobu" device = "/dev/hdb2" status = ["ALLOCATABLE"] pe_start = 384 pe_count = 48593 } } # Generated by LVM2: Sun Oct 1 16:33:20 2006 --------------------------------------------------------------------- Now that is exactly the same as the author dude's file as in listing 6 on his web page, here: --------------------------------------------------------------------- VolGroup01 { id = "xQZqTG-V4wn-DLeQ-bJ0J-GEHB-4teF-A4PPBv" seqno = 1 status = ["RESIZEABLE", "READ", "WRITE"] extent_size = 65536 max_lv = 0 max_pv = 0 physical_volumes { pv0 { id = "tRACEy-cstP-kk18-zQFZ-ErG5-QAIV-YqHItA" device = "/dev/md2" status = ["ALLOCATABLE"] pe_start = 384 pe_count = 2365 } } # Generated by LVM2: Sun Feb 5 22:57:19 2006 --------------------------------------------------------------------- Mine came out right, there is no difference other than the actual data. I cannot restore my volume group like he says in this part though: [root(a)recoverybox ~]# vgcfgrestore -f VolGroup01 VolGroup01 [root(a)recoverybox ~]# vgscan Reading all physical volumes. This may take a while... Found volume group "VolGroup01" using metadata type lvm2 Found volume group "VolGroup00" using metadata type lvm2 [root(a)recoverybox ~]# pvscan PV /dev/md2 VG VolGroup01 lvm2 [73.91 GB / 32.00 MB free] PV /dev/hda2 VG VolGroup00 lvm2 [18.91 GB / 32.00 MB free] Total: 2 [92.81 GB] / in use: 2 [92.81 GB] / in no VG: 0 [0 ] [root(a)recoverybox ~]# vgchange VolGroup01 -a y 1 logical volume(s) in volume group "VolGroup01" now active [root(a)recoverybox ~]# lvscan ACTIVE '/dev/VolGroup01/LogVol00' [73.88 GB] inherit ACTIVE '/dev/VolGroup00/LogVol00' [18.38 GB] inherit ACTIVE '/dev/VolGroup00/LogVol01' [512.00 MB] inherit Here is what happens when I try: [root(a)ohmster recoverybox]# vgcfgrestore -f VolGroup01 VolGroup01 Parse error at line 19: unexpected token Couldn't read volume group metadata. Restore failed. [root(a)ohmster recoverybox]# What the hell is the problem? I don't even have a line 19 in my VolGroup01 file. The comment line, the very last line, is line 17 and there ain't no more. How come this don't work? One thing that I am doing that the author dude did is that I am not doing this on another machine because I only have one linux machine right now. See, this part I did not do: "To recover, the first thing to do is to move the drive to another machine. You can do this pretty easily by putting the drive in a USB2 hard drive enclosure. It then will show up as a SCSI hard disk device, for example, /dev/sda, when you plug it in to your recovery computer. This reduces the risk of damaging the recovery machine while attempting to install the hardware from the original computer." You think that might be a problem? [root(a)ohmster recoverybox]# vgscan Reading all physical volumes. This may take a while... Found volume group "VolGroup01" using metadata type lvm2 Found volume group "VolGroup00" using metadata type lvm2 [root(a)ohmster recoverybox]# lvscan ACTIVE '/dev/VolGroup00/LogVol00' [184.22 GB] inherit ACTIVE '/dev/VolGroup00/LogVol01' [1.94 GB] inherit [root(a)ohmster recoverybox]# pvscan PV /dev/hdb2 VG VolGroup01 lvm2 [189.82 GB / 189.82 GB free] PV /dev/hda2 VG VolGroup00 lvm2 [186.19 GB / 32.00 MB free] Total: 2 [376.00 GB] / in use: 2 [376.00 GB] / in no VG: 0 [0 ] [root(a)ohmster recoverybox]# It looks like the system found both drives, although it is saying that hdb2 is empty, it is not, all of my data is in there. Oh man, I am so close now, somebody has to be able to help, what do you think, noi? So close but so far, this is major bumming me out. :( -- ~Ohmster theohmster at comcast dot net Put "messageforohmster" in message body to pass my spam filter. |