All of lore.kernel.org
 help / color / mirror / Atom feed
* [linux-lvm] VG dissappeared without a trace?
@ 2002-01-06  3:33 IpSo
  2002-01-06 13:03 ` IpSo
  0 siblings, 1 reply; 15+ messages in thread
From: IpSo @ 2002-01-06  3:33 UTC (permalink / raw)
  To: linux-lvm

I was trying to extend my LVM partition to another disk, but being late and my
head not screwed on straight, things went terribly wrong.

I was using diskdrake (from Mandrake) and what I did was create a LVM partition
/dev/hdb6 and added it to my "quantum" VG which contained a single partition of
/dev/hda6. I was simply doing this as a test (my first time using LVM), so as
soon as it worked, I removed /dev/hdb6 from the "quantum" VG. I then proceeded
to create a larger partition /dev/hdc that I wanted to add to "quantum" for
good. I added it to the "quantum" VG and attemped to resize the "quantum" VG to
the full size of both /dev/hda6 (17gb) and /dev/hdc (12gb). Everything "seemed"
to go fine, so I exited from diskdrake and rebooted.

During the reboot, it said it couldn't mount /dev/quantum/1 as it was not a
proper block device. So I ran the following programs to try and collect as much
data as possible:

[root@ipso root]# pvscan -v
pvscan -- reading all physical volumes (this may take a while...)
pvscan -- walking through all physical volumes found
pvscan -- inactive PV "/dev/hda6"  is associated to an unknown VG (run vgscan)
pvscan -- inactive PV "/dev/hdb6"  is associated to an unknown VG (run vgscan)
pvscan -- total: 2 [19.01 GB] / in use: 2 [19.01 GB] / in no VG: 0 [0]

[root@ipso root]# vgscan -v
vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
vgscan -- reading all physical volumes (this may take a while...)
vgscan -- no volume groups found


vgcfgrestore -n quantum -l -f /etc/lvmconf/quantum.conf.1.old
--- Volume group ---
VG Name               quantum
VG Access             read/write
VG Status             NOT available/resizable
VG #                  0
MAX LV                256
Cur LV                1
Open LV               0
MAX LV Size           255.99 GB
Max PV                256
Cur PV                2
Act PV                2
VG Size               19 GB
PE Size               4 MB
Total PE              4865
Alloc PE / Size       4328 / 16.91 GB
Free  PE / Size       537 / 2.1 GB
VG UUID               54LQnu-1gQl-mNuO-KR7U-yypa-woKi-iu7PRF

[root@ipso lvmconf]# vgcfgrestore -n quantum -l -f /etc/lvmconf/quantum.conf
--- Volume group ---
VG Name               quantum
VG Access             read/write
VG Status             NOT available/resizable
VG #                  0
MAX LV                256
Cur LV                1
Open LV               0
MAX LV Size           255.99 GB
Max PV                256
Cur PV                3
Act PV                3
VG Size               30.88 GB
PE Size               4 MB
Total PE              7904
Alloc PE / Size       4328 / 16.91 GB
Free  PE / Size       3576 / 13.97 GB
VG UUID               54LQnu-1gQl-mNuO-KR7U-yypa-woKi-iu7PRF


[root@ipso lvmconf]# pvdata -a /dev/hda6

--- Physical volume ---
PV Name               /dev/hda6
VG Name               quantum
PV Size               16.91 GB / NOT usable 3.12 MB [LVM: 137 KB]
PV#                   1
PV Status             NOT available
Allocatable           yes (but full)
Cur LV                1
PE Size (KByte)       4096
Total PE              4328
Free PE               0
Allocated PE          4328
PV UUID               e42Ge3-mpoP-PNat-1xLg-TMjr-4hRU-Q2agG9

--- Volume group ---
VG Name
VG Access             read/write
VG Status             NOT available/resizable
VG #                  0
MAX LV                256
Cur LV                1
Open LV               0
MAX LV Size           255.99 GB
Max PV                256
Cur PV                2
Act PV                2
VG Size               19 GB
PE Size               4 MB
Total PE              4865
Alloc PE / Size       4328 / 16.91 GB
Free  PE / Size       537 / 2.1 GB
VG UUID               54LQnu-1gQl-mNuO-KR7U-yypa-woKi-iu7PRF

--- List of logical volumes ---

pvdata -- logical volume "/dev/quantum/1" at offset   0
pvdata -- logical volume struct at offset   1 is empty
pvdata -- logical volume struct at offset   2 is empty
pvdata -- logical volume struct at offset   3 is empty
pvdata -- logical volume struct at offset   4 is empty
pvdata -- logical volume struct at offset   5 is empty
pvdata -- logical volume struct at offset   6 is empty
pvdata -- logical volume struct at offset   7 is empty
pvdata -- logical volume struct at offset   8 is empty
pvdata -- logical volume struct at offset   9 is empty
pvdata -- logical volume struct at offset  10 is empty
...
pvdata -- logical volume struct at offset 254 is empty
pvdata -- logical volume struct at offset 255 is empty

--- List of physical extents ---

PE: 00000  LV: 001  LE: 00000
PE: 00001  LV: 001  LE: 00001
PE: 00002  LV: 001  LE: 00002
...
PE: 04326  LV: 001  LE: 04326
PE: 04327  LV: 001  LE: 04327
--- List of physical volume UUIDs ---

000: e42Ge3mpoPPNat1xLgTMjr4hRUQ2agG9
001: --- EMPTY ---



[root@ipso lvmconf]# pvdata -a /dev/hdb6


--- Physical volume ---
PV Name               /dev/hdb6
VG Name               quantum
PV Size               2.1 GB / NOT usable 1.75 MB [LVM: 123 KB]
PV#                   2
PV Status             NOT available
Allocatable           yes
Cur LV                0
PE Size (KByte)       4096
Total PE              537
Free PE               537
Allocated PE          0
PV UUID               PFyl3d-HSJD-adUL-vpzS-Sib3-jy78-tgR569

--- Volume group ---
VG Name
VG Access             read/write
VG Status             NOT available/resizable
VG #                  0
MAX LV                256
Cur LV                1
Open LV               0
MAX LV Size           255.99 GB
Max PV                256
Cur PV                3
Act PV                3
VG Size               30.88 GB
PE Size               4 MB
Total PE              7904
Alloc PE / Size       4328 / 16.91 GB
Free  PE / Size       3576 / 13.97 GB
VG UUID               54LQnu-1gQl-mNuO-KR7U-yypa-woKi-iu7PRF

--- List of logical volumes ---

pvdata -- logical volume "/dev/quantum/1" at offset   0
pvdata -- logical volume struct at offset   1 is empty
pvdata -- logical volume struct at offset   2 is empty
pvdata -- logical volume struct at offset   3 is empty
...
pvdata -- logical volume struct at offset 254 is empty
pvdata -- logical volume struct at offset 255 is empty

--- List of physical extents ---

PE: 00000  LV: ---  LE: -----
PE: 00001  LV: ---  LE: -----
PE: 00002  LV: ---  LE: -----
...
PE: 00535  LV: ---  LE: -----
PE: 00536  LV: ---  LE: -----
--- List of physical volume UUIDs ---

000: e42Ge3mpoPPNat1xLgTMjr4hRUQ2agG9
001: PFyl3dHSJDadULvpzSSib3jy78tgR569
002: TeWEsY1qLF4PPwfZAlljyT3KiE4CCajd


Unfortunately, I deleted the partition from the larger drive I was planning on
adding to the "quantum" VG, (/dev/hdc it didn't have any data on it yet). I
don't really care about /dev/hdb6 either, I would just like the data off of
/dev/hda6.

Partition table for: /dev/hda6
   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       507    255496+  82  Linux swap
/dev/hda2           508     39813  19810224    5  Extended
/dev/hda5           508      4633   2079472+  83  Linux
/dev/hda6          4634     39813  17730688+  8e  Linux LVM

Any ideas how I can get /dev/hda6 mountable again? Thanks.

IpSo

--------------------------------------------------------------------
Never worry about viruses in your Email again.
Get your FREE! virus scanned Email accounts at http://snappymail.ca

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] VG dissappeared without a trace?
  2002-01-06  3:33 [linux-lvm] VG dissappeared without a trace? IpSo
@ 2002-01-06 13:03 ` IpSo
  2002-01-06 16:22   ` Andreas Dilger
  0 siblings, 1 reply; 15+ messages in thread
From: IpSo @ 2002-01-06 13:03 UTC (permalink / raw)
  To: linux-lvm

A follow up to this, I downloaded uuid_fixer to see if it would help, here's
what I tried:

[root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6
Error: number of PVs passed in does not match number of PVs in /dev/hda6's VG
       1 PVs were passed in and 2 were expected.


[root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdb6
Error: number of PVs passed in does not match number of PVs in /dev/hdb6's VG
       2 PVs were passed in and 3 were expected.

Hrmm, so it must be looking for the partition I deleted on /dev/hdc. :( I
re-created the partition just to see:

[root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdb6 /dev/hdc1
Error: number of PVs passed in does not match number of PVs in /dev/hda6's VG
       3 PVs were passed in and 2 were expected.

Figures. I guess I don't have a backup of the vgcfg when /dev/hda6 was all alone
in the VG "quantum". Thats the last time it was working correctly. :(

Quoting IpSo <ipso@snappymail.ca>:

> I was trying to extend my LVM partition to another disk, but being late and
> my
> head not screwed on straight, things went terribly wrong.
> 
> I was using diskdrake (from Mandrake) and what I did was create a LVM
> partition
> /dev/hdb6 and added it to my "quantum" VG which contained a single partition
> of
> /dev/hda6. I was simply doing this as a test (my first time using LVM), so
> as
> soon as it worked, I removed /dev/hdb6 from the "quantum" VG. I then
> proceeded
> to create a larger partition /dev/hdc that I wanted to add to "quantum" for
> good. I added it to the "quantum" VG and attemped to resize the "quantum" VG
> to
> the full size of both /dev/hda6 (17gb) and /dev/hdc (12gb). Everything
> "seemed"
> to go fine, so I exited from diskdrake and rebooted.
> 
> During the reboot, it said it couldn't mount /dev/quantum/1 as it was not a
> proper block device. So I ran the following programs to try and collect as
> much
> data as possible:
> 
> [root@ipso root]# pvscan -v
> pvscan -- reading all physical volumes (this may take a while...)
> pvscan -- walking through all physical volumes found
> pvscan -- inactive PV "/dev/hda6"  is associated to an unknown VG (run
> vgscan)
> pvscan -- inactive PV "/dev/hdb6"  is associated to an unknown VG (run
> vgscan)
> pvscan -- total: 2 [19.01 GB] / in use: 2 [19.01 GB] / in no VG: 0 [0]
> 
> [root@ipso root]# vgscan -v
> vgscan -- removing "/etc/lvmtab" and "/etc/lvmtab.d"
> vgscan -- reading all physical volumes (this may take a while...)
> vgscan -- no volume groups found
> 
> 
> vgcfgrestore -n quantum -l -f /etc/lvmconf/quantum.conf.1.old
> --- Volume group ---
> VG Name               quantum
> VG Access             read/write
> VG Status             NOT available/resizable
> VG #                  0
> MAX LV                256
> Cur LV                1
> Open LV               0
> MAX LV Size           255.99 GB
> Max PV                256
> Cur PV                2
> Act PV                2
> VG Size               19 GB
> PE Size               4 MB
> Total PE              4865
> Alloc PE / Size       4328 / 16.91 GB
> Free  PE / Size       537 / 2.1 GB
> VG UUID               54LQnu-1gQl-mNuO-KR7U-yypa-woKi-iu7PRF
> 
> [root@ipso lvmconf]# vgcfgrestore -n quantum -l -f
> /etc/lvmconf/quantum.conf
> --- Volume group ---
> VG Name               quantum
> VG Access             read/write
> VG Status             NOT available/resizable
> VG #                  0
> MAX LV                256
> Cur LV                1
> Open LV               0
> MAX LV Size           255.99 GB
> Max PV                256
> Cur PV                3
> Act PV                3
> VG Size               30.88 GB
> PE Size               4 MB
> Total PE              7904
> Alloc PE / Size       4328 / 16.91 GB
> Free  PE / Size       3576 / 13.97 GB
> VG UUID               54LQnu-1gQl-mNuO-KR7U-yypa-woKi-iu7PRF
> 
> 
> [root@ipso lvmconf]# pvdata -a /dev/hda6
> 
> --- Physical volume ---
> PV Name               /dev/hda6
> VG Name               quantum
> PV Size               16.91 GB / NOT usable 3.12 MB [LVM: 137 KB]
> PV#                   1
> PV Status             NOT available
> Allocatable           yes (but full)
> Cur LV                1
> PE Size (KByte)       4096
> Total PE              4328
> Free PE               0
> Allocated PE          4328
> PV UUID               e42Ge3-mpoP-PNat-1xLg-TMjr-4hRU-Q2agG9
> 
> --- Volume group ---
> VG Name
> VG Access             read/write
> VG Status             NOT available/resizable
> VG #                  0
> MAX LV                256
> Cur LV                1
> Open LV               0
> MAX LV Size           255.99 GB
> Max PV                256
> Cur PV                2
> Act PV                2
> VG Size               19 GB
> PE Size               4 MB
> Total PE              4865
> Alloc PE / Size       4328 / 16.91 GB
> Free  PE / Size       537 / 2.1 GB
> VG UUID               54LQnu-1gQl-mNuO-KR7U-yypa-woKi-iu7PRF
> 
> --- List of logical volumes ---
> 
> pvdata -- logical volume "/dev/quantum/1" at offset   0
> pvdata -- logical volume struct at offset   1 is empty
> pvdata -- logical volume struct at offset   2 is empty
> pvdata -- logical volume struct at offset   3 is empty
> pvdata -- logical volume struct at offset   4 is empty
> pvdata -- logical volume struct at offset   5 is empty
> pvdata -- logical volume struct at offset   6 is empty
> pvdata -- logical volume struct at offset   7 is empty
> pvdata -- logical volume struct at offset   8 is empty
> pvdata -- logical volume struct at offset   9 is empty
> pvdata -- logical volume struct at offset  10 is empty
> ...
> pvdata -- logical volume struct at offset 254 is empty
> pvdata -- logical volume struct at offset 255 is empty
> 
> --- List of physical extents ---
> 
> PE: 00000  LV: 001  LE: 00000
> PE: 00001  LV: 001  LE: 00001
> PE: 00002  LV: 001  LE: 00002
> ...
> PE: 04326  LV: 001  LE: 04326
> PE: 04327  LV: 001  LE: 04327
> --- List of physical volume UUIDs ---
> 
> 000: e42Ge3mpoPPNat1xLgTMjr4hRUQ2agG9
> 001: --- EMPTY ---
> 
> 
> 
> [root@ipso lvmconf]# pvdata -a /dev/hdb6
> 
> 
> --- Physical volume ---
> PV Name               /dev/hdb6
> VG Name               quantum
> PV Size               2.1 GB / NOT usable 1.75 MB [LVM: 123 KB]
> PV#                   2
> PV Status             NOT available
> Allocatable           yes
> Cur LV                0
> PE Size (KByte)       4096
> Total PE              537
> Free PE               537
> Allocated PE          0
> PV UUID               PFyl3d-HSJD-adUL-vpzS-Sib3-jy78-tgR569
> 
> --- Volume group ---
> VG Name
> VG Access             read/write
> VG Status             NOT available/resizable
> VG #                  0
> MAX LV                256
> Cur LV                1
> Open LV               0
> MAX LV Size           255.99 GB
> Max PV                256
> Cur PV                3
> Act PV                3
> VG Size               30.88 GB
> PE Size               4 MB
> Total PE              7904
> Alloc PE / Size       4328 / 16.91 GB
> Free  PE / Size       3576 / 13.97 GB
> VG UUID               54LQnu-1gQl-mNuO-KR7U-yypa-woKi-iu7PRF
> 
> --- List of logical volumes ---
> 
> pvdata -- logical volume "/dev/quantum/1" at offset   0
> pvdata -- logical volume struct at offset   1 is empty
> pvdata -- logical volume struct at offset   2 is empty
> pvdata -- logical volume struct at offset   3 is empty
> ...
> pvdata -- logical volume struct at offset 254 is empty
> pvdata -- logical volume struct at offset 255 is empty
> 
> --- List of physical extents ---
> 
> PE: 00000  LV: ---  LE: -----
> PE: 00001  LV: ---  LE: -----
> PE: 00002  LV: ---  LE: -----
> ...
> PE: 00535  LV: ---  LE: -----
> PE: 00536  LV: ---  LE: -----
> --- List of physical volume UUIDs ---
> 
> 000: e42Ge3mpoPPNat1xLgTMjr4hRUQ2agG9
> 001: PFyl3dHSJDadULvpzSSib3jy78tgR569
> 002: TeWEsY1qLF4PPwfZAlljyT3KiE4CCajd
> 
> 
> Unfortunately, I deleted the partition from the larger drive I was planning
> on
> adding to the "quantum" VG, (/dev/hdc it didn't have any data on it yet). I
> don't really care about /dev/hdb6 either, I would just like the data off of
> /dev/hda6.
> 
> Partition table for: /dev/hda6
>    Device Boot    Start       End    Blocks   Id  System
> /dev/hda1   *         1       507    255496+  82  Linux swap
> /dev/hda2           508     39813  19810224    5  Extended
> /dev/hda5           508      4633   2079472+  83  Linux
> /dev/hda6          4634     39813  17730688+  8e  Linux LVM
> 
> Any ideas how I can get /dev/hda6 mountable again? Thanks.
> 
> IpSo
> 
> --------------------------------------------------------------------
> Never worry about viruses in your Email again.
> Get your FREE! virus scanned Email accounts at http://snappymail.ca
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 


IpSo

--------------------------------------------------------------------
Never worry about viruses in your Email again.
Get your FREE! virus scanned Email accounts at http://snappymail.ca

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] VG dissappeared without a trace?
  2002-01-06 13:03 ` IpSo
@ 2002-01-06 16:22   ` Andreas Dilger
  2002-01-06 17:29     ` IpSo
  0 siblings, 1 reply; 15+ messages in thread
From: Andreas Dilger @ 2002-01-06 16:22 UTC (permalink / raw)
  To: linux-lvm

On Jan 06, 2002  11:06 -0800, IpSo wrote:
> A follow up to this, I downloaded uuid_fixer to see if it would help, here's
> what I tried:
> 
> [root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6
> Error: number of PVs passed in does not match number of PVs in /dev/hda6's VG
>        1 PVs were passed in and 2 were expected.
> 
> 
> [root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdb6
> Error: number of PVs passed in does not match number of PVs in /dev/hdb6's VG
>        2 PVs were passed in and 3 were expected.
> 
> Hrmm, so it must be looking for the partition I deleted on /dev/hdc. :( I
> re-created the partition just to see:
> 
> [root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdb6 /dev/hdc1
> Error: number of PVs passed in does not match number of PVs in /dev/hda6's VG
>        3 PVs were passed in and 2 were expected.

Try hda6 and hdc, since this is what you had in the VG before you shut down.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] VG dissappeared without a trace?
  2002-01-06 16:22   ` Andreas Dilger
@ 2002-01-06 17:29     ` IpSo
  2002-01-08 20:27       ` [linux-lvm] A way to bypass LVM and extract the raw data off? IpSo
  0 siblings, 1 reply; 15+ messages in thread
From: IpSo @ 2002-01-06 17:29 UTC (permalink / raw)
  To: linux-lvm

[root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdc
/dev/hdc - pv_read(): PV identifier invalid

[root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdc1
Error: number of PVs passed in does not match number of PVs in /dev/hdc1's VG
       2 PVs were passed in and 3 were expected.

It seems whichever combination I use, it either wants 2 or 3 PVs. 

Quoting Andreas Dilger <adilger@turbolabs.com>:

> On Jan 06, 2002  11:06 -0800, IpSo wrote:
> > A follow up to this, I downloaded uuid_fixer to see if it would help,
> here's
> > what I tried:
> > 
> > [root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6
> > Error: number of PVs passed in does not match number of PVs in /dev/hda6's
> VG
> >        1 PVs were passed in and 2 were expected.
> > 
> > 
> > [root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdb6
> > Error: number of PVs passed in does not match number of PVs in /dev/hdb6's
> VG
> >        2 PVs were passed in and 3 were expected.
> > 
> > Hrmm, so it must be looking for the partition I deleted on /dev/hdc. :( I
> > re-created the partition just to see:
> > 
> > [root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdb6 /dev/hdc1
> > Error: number of PVs passed in does not match number of PVs in /dev/hda6's
> VG
> >        3 PVs were passed in and 2 were expected.
> 
> Try hda6 and hdc, since this is what you had in the VG before you shut
> down.
> 
> Cheers, Andreas
> --
> Andreas Dilger
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 


IpSo

--------------------------------------------------------------------
Never worry about viruses in your Email again.
Get your FREE! virus scanned Email accounts at http://snappymail.ca

^ permalink raw reply	[flat|nested] 15+ messages in thread
* [linux-lvm] A way to bypass LVM and extract the raw data off?
  2002-01-06 17:29     ` IpSo
@ 2002-01-08 20:27       ` IpSo
  2002-01-08 20:35         ` Petro
  2002-01-08 21:05         ` Andreas Dilger
  0 siblings, 2 replies; 15+ messages in thread
From: IpSo @ 2002-01-08 20:27 UTC (permalink / raw)
  To: linux-lvm

Well, it doesn't look like there is a way I can recover my LVM volume groups and
whatnot. (See below) But I know theres a fully intact ReiserFS of 17315mb on
/dev/hda6. "gpart" scanned my disk and came up with this: 

Possible extended partition at offset(249mb)
   Possible partition(Linux LVM physical volume), size(17315mb), offset(2280mb)
      type: 142(0x8E)(Linux LVM physical volume)
      size: 17315mb #s(35461377) s(4670127-40131503)
      chs:  (1023/15/63)-(1023/15/63)d (4633/1/1)-(39812/15/63)r
      hex:  00 0F FF FF 8E 0F FF FF AF 42 47 00 01 19 1D 02

End scan.

Is there some way to "dd" the data off onto another partition and access it
there? Because I know the filesystem was only on a single PV, and a single LV,
and the problems occured when trying to extend that LV, but I never got to the
point of extending the filesystem itself with reiser_resize. You would think I
could somehow using the offsets given above create a new partition to copy the
data to, run a reiserfsck and rebuild the file system so I can access the data?
Has anyone tryed something along these lines before?


Quoting IpSo <ipso@snappymail.ca>:

> [root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdc
> /dev/hdc - pv_read(): PV identifier invalid
> 
> [root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdc1
> Error: number of PVs passed in does not match number of PVs in /dev/hdc1's
> VG
>        2 PVs were passed in and 3 were expected.
> 
> It seems whichever combination I use, it either wants 2 or 3 PVs. 
> 
> Quoting Andreas Dilger <adilger@turbolabs.com>:
> 
> > On Jan 06, 2002  11:06 -0800, IpSo wrote:
> > > A follow up to this, I downloaded uuid_fixer to see if it would help,
> > here's
> > > what I tried:
> > > 
> > > [root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6
> > > Error: number of PVs passed in does not match number of PVs in
> /dev/hda6's
> > VG
> > >        1 PVs were passed in and 2 were expected.
> > > 
> > > 
> > > [root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdb6
> > > Error: number of PVs passed in does not match number of PVs in
> /dev/hdb6's
> > VG
> > >        2 PVs were passed in and 3 were expected.
> > > 
> > > Hrmm, so it must be looking for the partition I deleted on /dev/hdc. :(
> I
> > > re-created the partition just to see:
> > > 
> > > [root@ipso uuid_fixer]# ./uuid_fixer /dev/hda6 /dev/hdb6 /dev/hdc1
> > > Error: number of PVs passed in does not match number of PVs in
> /dev/hda6's
> > VG
> > >        3 PVs were passed in and 2 were expected.
> > 
> > Try hda6 and hdc, since this is what you had in the VG before you shut
> > down.
> > 
> > Cheers, Andreas
> > --
> > Andreas Dilger
> > http://sourceforge.net/projects/ext2resize/
> > http://www-mddsp.enel.ucalgary.ca/People/adilger/
> > 
> > 
> > _______________________________________________
> > linux-lvm mailing list
> > linux-lvm@sistina.com
> > http://lists.sistina.com/mailman/listinfo/linux-lvm
> > read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> > 
> 
> 
> IpSo
> 
> --------------------------------------------------------------------
> Never worry about viruses in your Email again.
> Get your FREE! virus scanned Email accounts at http://snappymail.ca
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 


IpSo

--------------------------------------------------------------------
Never worry about viruses in your Email again.
Get your FREE! virus scanned Email accounts at http://snappymail.ca

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] A way to bypass LVM and extract the raw data off?
  2002-01-08 20:27       ` [linux-lvm] A way to bypass LVM and extract the raw data off? IpSo
@ 2002-01-08 20:35         ` Petro
  2002-01-08 21:03           ` IpSo
  2002-01-08 21:05         ` Andreas Dilger
  1 sibling, 1 reply; 15+ messages in thread
From: Petro @ 2002-01-08 20:35 UTC (permalink / raw)
  To: linux-lvm

On Tue, Jan 08, 2002 at 06:26:36PM -0800, IpSo wrote:
> Well, it doesn't look like there is a way I can recover my LVM volume groups and
> whatnot. (See below) But I know theres a fully intact ReiserFS of 17315mb on
> /dev/hda6. "gpart" scanned my disk and came up with this: 

    Does the OS recognize /dev/hda6 as a partition? 

> Is there some way to "dd" the data off onto another partition and access it
> there? Because I know the filesystem was only on a single PV, and a single LV,
> and the problems occured when trying to extend that LV, but I never got to the
> point of extending the filesystem itself with reiser_resize. You would think I
> could somehow using the offsets given above create a new partition to copy the
> data to, run a reiserfsck and rebuild the file system so I can access the data?
> Has anyone tryed something along these lines before?

    If you have the HD space, you could try dd if=/dev/hda6
    of=/some/file

    Then mount -o loop /some/file /mnt/point -t reiserfs. 

    I don't think this would do any more damage. 

-- 
Share and Enjoy. 

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] A way to bypass LVM and extract the raw data off?
  2002-01-08 20:35         ` Petro
@ 2002-01-08 21:03           ` IpSo
  2002-01-09 13:41             ` Andreas Dilger
  0 siblings, 1 reply; 15+ messages in thread
From: IpSo @ 2002-01-08 21:03 UTC (permalink / raw)
  To: linux-lvm

Quoting Petro <petro@auctionwatch.com>:

> On Tue, Jan 08, 2002 at 06:26:36PM -0800, IpSo wrote:
> > Well, it doesn't look like there is a way I can recover my LVM volume
> groups and
> > whatnot. (See below) But I know theres a fully intact ReiserFS of 17315mb
> on
> > /dev/hda6. "gpart" scanned my disk and came up with this: 
> 
>     Does the OS recognize /dev/hda6 as a partition? 


Yup! I'm confident everything as far as the reiser filesystem is fine, just LVM
is very confused. 

   Device Boot    Start       End    Blocks   Id  System
/dev/hda1   *         1       507    255496+  82  Linux swap
/dev/hda2           508     39813  19810224    5  Extended
/dev/hda5           508      4633   2079472+  83  Linux
/dev/hda6          4634     39813  17730688+  8e  Linux LVM

 

> 
> > Is there some way to "dd" the data off onto another partition and access
> it
> > there? Because I know the filesystem was only on a single PV, and a single
> LV,
> > and the problems occured when trying to extend that LV, but I never got to
> the
> > point of extending the filesystem itself with reiser_resize. You would
> think I
> > could somehow using the offsets given above create a new partition to copy
> the
> > data to, run a reiserfsck and rebuild the file system so I can access the
> data?
> > Has anyone tryed something along these lines before?
> 
>     If you have the HD space, you could try dd if=/dev/hda6
>     of=/some/file
> 
>     Then mount -o loop /some/file /mnt/point -t reiserfs. 
> 
>     I don't think this would do any more damage. 
> 
I'll give it a shot I guess, won't this loopback file contain the extra LVM
information and cause problems when trying to mount it though? Does the LVM
information take up the first 2mb or something that I could set the offset as,
so it doesn't carry over to the loopback file?

> -- 
> Share and Enjoy. 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 


IpSo

--------------------------------------------------------------------
Never worry about viruses in your Email again.
Get your FREE! virus scanned Email accounts at http://snappymail.ca

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] A way to bypass LVM and extract the raw data off?
  2002-01-08 20:27       ` [linux-lvm] A way to bypass LVM and extract the raw data off? IpSo
  2002-01-08 20:35         ` Petro
@ 2002-01-08 21:05         ` Andreas Dilger
  2002-01-09  9:02           ` IpSo
  1 sibling, 1 reply; 15+ messages in thread
From: Andreas Dilger @ 2002-01-08 21:05 UTC (permalink / raw)
  To: IpSo; +Cc: linux-lvm

On Jan 08, 2002  18:26 -0800, IpSo wrote:
> Well, it doesn't look like there is a way I can recover my LVM volume groups
> and whatnot. (See below) But I know theres a fully intact ReiserFS of 17315mb
> on /dev/hda6. "gpart" scanned my disk and came up with this: 
> 
> Possible extended partition at offset(249mb)
>    Possible partition(Linux LVM physical volume), size(17315mb), offset(2280mb)
>       type: 142(0x8E)(Linux LVM physical volume)
>       size: 17315mb #s(35461377) s(4670127-40131503)
>       chs:  (1023/15/63)-(1023/15/63)d (4633/1/1)-(39812/15/63)r
>       hex:  00 0F FF FF 8E 0F FF FF AF 42 47 00 01 19 1D 02
> 
> End scan.
> 
> Is there some way to "dd" the data off onto another partition and access it
> there? Because I know the filesystem was only on a single PV, and a single
> LV, and the problems occured when trying to extend that LV, but I never got
> to the point of extending the filesystem itself with reiser_resize. You
> would think I could somehow using the offsets given above create a new
> partition to copy the data to, run a reiserfsck and rebuild the file system
> so I can access the data? Has anyone tryed something along these lines before?

dd if=/dev/hda bs=512 skip=4670127 count=35461377 of=<somewhere>

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] A way to bypass LVM and extract the raw data off?
  2002-01-08 21:05         ` Andreas Dilger
@ 2002-01-09  9:02           ` IpSo
  2002-01-09 10:30             ` Holger Grothe
  0 siblings, 1 reply; 15+ messages in thread
From: IpSo @ 2002-01-09  9:02 UTC (permalink / raw)
  To: linux-lvm

Well, I gave this a shot and everything seemed promising until I mounted the
loop back file.

dd if=/dev/hda bs=512 skip=4670127 count=35461377 of=/big/backup_hda6.bin

-rw-r--r--    1 root     root     17105949184 Jan  8 22:05 backup_hda6.bin

File size seems about right. 

[root@ipso big]# mount -o loop ./backup_hda6.bin /test -t reiserfs
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       or too many mounted file systems

Understandable...

[root@ipso big]# reiserfsck --rebuild-sb ./backup_hda6.bin
reiserfsck, 2001 - reiserfsprogs 3.x.0j
Will check SB and rebuild if it is needed
Will put log info to 'stderr'
Do you want to run this program?[N/Yes] (note need to type Yes):Yes
reiserfs_open: neither new nor old reiserfs format found on ./backup_hda6.bin

what is version of ReiserFS you use[1-4]
        (1)   3.6.x
        (2) >=3.5.9
        (3) < 3.5.9 converted to new format
        (4) < 3.5.9
        (X)   exit
1
Super block of format 3.6 found on the 0x3 in block 16
Block count 4432672
Blocksize 4096
Free blocks 0
Busy blocks (skipped 16, bitmaps - 136, journal blocks - 8193
1 super blocks, 4424326 data blocks
Root block 0
Journal block (first) 18
Journal dev 0
Journal orig size 8192
Filesystem state ERROR
Tree height 0
Hash function used to sort names: not set
Objectid map size 0, max 972
Version 2
Is this ok ? [N/Yes]: Yes

Do not forget to run reiserfsck --rebuild-tree

Seems like it found a backup super block, bitmaps, etc... Though "Filesystem
state ERROR" doesn't look so good, but no errors so, lets try a rebuild.

[root@ipso big]# reiserfsck --rebuild-tree ./backup_hda6.bin
reiserfsck, 2001 - reiserfsprogs 3.x.0j

This is an experimental version of reiserfsck, MAKE A BACKUP FIRST!
Don't run this program unless something is broken.
Some types of random FS damage can be recovered
from by this program, which basically throws away the internal nodes
of the tree and then reconstructs them.  This program is for use only
by the desperate, and is of only beta quality.  Email
reiserfs@devlinux.com with bug reports.
Will rebuild the filesystem tree
Will put log info to 'stderr'
Do you want to run this program?[N/Yes] (note need to type Yes):Yes
reiserfs_open: bitmap 0 was marked free
reiserfs_open: first bitmap looks corrupted
reiserfs_open: bitmap 1 was marked free
reiserfs_open: bitmap 2 was marked free
reiserfs_open: bitmap 4 was marked free
reiserfs_open: bitmap 5 was marked free
reiserfs_open: bitmap 6 was marked free
reiserfs_open: bitmap 9 was marked free
reiserfs_open: bitmap 12 was marked free
reiserfs_open: bitmap 13 was marked free
reiserfs_open: bitmap 18 was marked free
reiserfs_open: bitmap 22 was marked free
reiserfs_open: bitmap 25 was marked free
reiserfs_open: bitmap 26 was marked free
reiserfs_open: bitmap 29 was marked free
reiserfs_open: bitmap 30 was marked free
reiserfs_open: bitmap 41 was marked free
reiserfs_open: bitmap 42 was marked free
reiserfs_open: bitmap 44 was marked free
reiserfs_open: bitmap 46 was marked free
reiserfs_open: bitmap 49 was marked free
reiserfs_open: bitmap 55 was marked free
reiserfs_open: bitmap 56 was marked free
reiserfs_open: bitmap 59 was marked free
reiserfs_open: bitmap 62 was marked free
reiserfs_open: bitmap 63 was marked free
reiserfs_open: bitmap 64 was marked free
reiserfs_open: bitmap 65 was marked free
reiserfs_open: bitmap 67 was marked free
reiserfs_open: bitmap 70 was marked free
reiserfs_open: bitmap 71 was marked free
reiserfs_open: bitmap 75 was marked free
reiserfs_open: bitmap 76 was marked free
reiserfs_open: bitmap 77 was marked free
reiserfs_open: bitmap 80 was marked free
reiserfs_open: bitmap 81 was marked free
reiserfs_open: bitmap 82 was marked free
reiserfs_open: bitmap 83 was marked free
reiserfs_open: bitmap 85 was marked free
reiserfs_open: bitmap 86 was marked free
reiserfs_open: bitmap 87 was marked free
reiserfs_open: bitmap 88 was marked free
reiserfs_open: bitmap 93 was marked free
reiserfs_open: bitmap 96 was marked free
reiserfs_open: bitmap 97 was marked free
reiserfs_open: bitmap 98 was marked free
reiserfs_open: bitmap 100 was marked free
reiserfs_open: bitmap 101 was marked free
reiserfs_open: bitmap 102 was marked free
reiserfs_open: bitmap 103 was marked free
reiserfs_open: bitmap 109 was marked free
reiserfs_open: bitmap 110 was marked free
reiserfs_open: bitmap 111 was marked free
reiserfs_open: bitmap 113 was marked free
reiserfs_open: bitmap 115 was marked free
reiserfs_open: bitmap 116 was marked free
reiserfs_open: bitmap 117 was marked free
reiserfs_open: bitmap 118 was marked free
reiserfs_open: bitmap 119 was marked free
reiserfs_open: bitmap 120 was marked free
reiserfs_open: bitmap 121 was marked free
reiserfs_open: bitmap 129 was marked free
reiserfs_open: bitmap 132 was marked free
Analyzing journal..nothing to replay (no transactions match to latest mount id)
Rebuilding..
Loading on-disk bitmap .. Fetching on-disk bitmap..fetch_bitmap: on-disk bitmap
is not padded p
roperly
done
2036947 bits set - done
Skipping 74 blocks (super block, journal, bitmaps) 2036873 blocks will be read

Pass 0 (2036873 (of 4432672) blocks will be read):
0%....20%....40%....60%....80%....100%                         left 0, 795 /sec
Looking for allocable blocks .. ok
        Read blocks (but not data blocks) 2036873
                Leaves among those 1
                Blocks pointed by indirect items 96
                        - once 96
                Objectids found 50
        allocable 4424229 blocks

Pass1:
0%....20%....40%....60%....80%....100%                           left 0, 0 /sec
        1 leaves read
                1 inserted
Tree is built. Checking it - done
Syncing..done
Pass 3 (semantic):
dir 1 2 has wrong sd_size 48, has to be 80
        Files found: 0
        Directories found: 2
Pass 3a (looking for lost files):
Looking for lost directories:
Looking for lost files:0 /sec
        Objects without names 46
        Files linked to /lost+found 46
Pass 4 - done           left 2, 0 /sec
        Deleted unreachable items 1
Syncing..done
Done
[root@ipso big]# mount -o loop ./backup_hda6.bin /test -t reiserfs

Mounts fine now...

[root@ipso big]# df
Filesystem           1k-blocks      Used Available Use% Mounted on
/dev/hda5              2079404   1895672    183732  92% /
/dev/big/1            18742720  17781164    961556  95% /big
none                    192356         0    192356   0% /dev/shm
/big/backup_hda6.bin  17730140     33228  17696912   1% /test

Uhh, what happened to all the data? And theres no lost+found directory either.
There _should_ be perfectly good data on /dev/hda6, just LVM won't let me access
it. Do any LVM commands modify the data itself? Should this have worked?

Thanks.   


Quoting Andreas Dilger <adilger@turbolabs.com>:

> On Jan 08, 2002  18:26 -0800, IpSo wrote:
> > Well, it doesn't look like there is a way I can recover my LVM volume
> groups
> > and whatnot. (See below) But I know theres a fully intact ReiserFS of
> 17315mb
> > on /dev/hda6. "gpart" scanned my disk and came up with this: 
> > 
> > Possible extended partition at offset(249mb)
> >    Possible partition(Linux LVM physical volume), size(17315mb),
> offset(2280mb)
> >       type: 142(0x8E)(Linux LVM physical volume)
> >       size: 17315mb #s(35461377) s(4670127-40131503)
> >       chs:  (1023/15/63)-(1023/15/63)d (4633/1/1)-(39812/15/63)r
> >       hex:  00 0F FF FF 8E 0F FF FF AF 42 47 00 01 19 1D 02
> > 
> > End scan.
> > 
> > Is there some way to "dd" the data off onto another partition and access
> it
> > there? Because I know the filesystem was only on a single PV, and a
> single
> > LV, and the problems occured when trying to extend that LV, but I never
> got
> > to the point of extending the filesystem itself with reiser_resize. You
> > would think I could somehow using the offsets given above create a new
> > partition to copy the data to, run a reiserfsck and rebuild the file
> system
> > so I can access the data? Has anyone tryed something along these lines
> before?
> 
> dd if=/dev/hda bs=512 skip=4670127 count=35461377 of=<somewhere>
> 
> Cheers, Andreas
> --
> Andreas Dilger
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 


IpSo

--------------------------------------------------------------------
Never worry about viruses in your Email again.
Get your FREE! virus scanned Email accounts at http://snappymail.ca

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] A way to bypass LVM and extract the raw data off?
  2002-01-09  9:02           ` IpSo
@ 2002-01-09 10:30             ` Holger Grothe
  2002-01-09 12:04               ` IpSo
  0 siblings, 1 reply; 15+ messages in thread
From: Holger Grothe @ 2002-01-09 10:30 UTC (permalink / raw)
  To: linux-lvm

On Wed, Jan 09, 2002 at 07:01:37AM -0800, IpSo wrote:
> Well, I gave this a shot and everything seemed promising until I mounted the
> loop back file.
> 
> dd if=/dev/hda bs=512 skip=4670127 count=35461377 of=/big/backup_hda6.bin
                             ^^^^^^^
> 
> -rw-r--r--    1 root     root     17105949184 Jan  8 22:05 backup_hda6.bin
> 
> File size seems about right. 
> 
> [root@ipso big]# mount -o loop ./backup_hda6.bin /test -t reiserfs
> mount: wrong fs type, bad option, bad superblock on /dev/loop0,
>        or too many mounted file systems
> 
> Understandable...
> 
> [root@ipso big]# reiserfsck --rebuild-sb ./backup_hda6.bin

IMHO the wrong way. To my experience the mount error message indicates
a "bad filesystem structure", which means you skipped a wrong number of 
blocks when using dd.

> Uhh, what happened to all the data? And theres no lost+found directory either.

Due to the "bad filesystem structure" the filesystem is _more_ or less
initialised by the reiserfsck command. reiserfs has no lost+found directory.

> > > Possible extended partition at offset(249mb)
> > >    Possible partition(Linux LVM physical volume), size(17315mb),
> > offset(2280mb)
> > >       type: 142(0x8E)(Linux LVM physical volume)
> > >       size: 17315mb #s(35461377) s(4670127-40131503)
                                         ^^^^^^^
If I'am right this means sectors #4670127 to #40131503 (35461377 sectors)
are used for the volume. Therfore the dd command should skip only the
first 4670126 sectors:
  dd if=/dev/hda bs=512 skip=4670126 count=35461377 of=/big/backup_hda6.bin
                             ^^^^^^^
Please try.

Holger
-- 
Holger Grothe  (Email: grothe@mathematik.tu-darmstadt.de)
Fachbereich Mathematik, TU Darmstadt

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] A way to bypass LVM and extract the raw data off?
  2002-01-09 10:30             ` Holger Grothe
@ 2002-01-09 12:04               ` IpSo
  0 siblings, 0 replies; 15+ messages in thread
From: IpSo @ 2002-01-09 12:04 UTC (permalink / raw)
  To: linux-lvm

Quoting Holger Grothe <grothe@mathematik.tu-darmstadt.de>:

> 
> IMHO the wrong way. To my experience the mount error message indicates
> a "bad filesystem structure", which means you skipped a wrong number of 
> blocks when using dd.
> 
> > Uhh, what happened to all the data? And theres no lost+found directory
> either.
> 
> Due to the "bad filesystem structure" the filesystem is _more_ or less
> initialised by the reiserfsck command. reiserfs has no lost+found
> directory.
> 
> > > > Possible extended partition at offset(249mb)
> > > >    Possible partition(Linux LVM physical volume), size(17315mb),
> > > offset(2280mb)
> > > >       type: 142(0x8E)(Linux LVM physical volume)
> > > >       size: 17315mb #s(35461377) s(4670127-40131503)
>                                          ^^^^^^^
> If I'am right this means sectors #4670127 to #40131503 (35461377 sectors)
> are used for the volume. Therfore the dd command should skip only the
> first 4670126 sectors:
>   dd if=/dev/hda bs=512 skip=4670126 count=35461377 of=/big/backup_hda6.bin
>                              ^^^^^^^
> Please try.


Hrmm, No luck. You figure having to reiserfsck with --rebuild isn't going to
help eh? That partition information above is what gpart "guessed", so its likely
this is wrong? Is there a more reliable way to get the offsets by chance? 

Thanks.


dd if=/dev/hda bs=512 skip=4670126 count=35461377 of=/big/backup_hda6.bin

[root@ipso big]# mount -o loop ./backup_hda6.bin /test -t reiserfs
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       or too many mounted file systems

[root@ipso big]# reiserfsck ./backup_hda6.bin 
reiserfsck, 2001 - reiserfsprogs 3.x.0j
Will read-only check consistency of the partition
Will put log info to 'stderr'
Do you want to run this program?[N/Yes] (note need to type Yes):Yes
reiserfs_open: neither new nor old reiserfs format found on ./backup_hda6.bin
reiserfsck: --rebuild-sb may restore reiserfs super block
[root@ipso big]# reiserfsck --rebuild-sb ./backup_hda6.bin
reiserfsck, 2001 - reiserfsprogs 3.x.0j
Will check SB and rebuild if it is needed
Will put log info to 'stderr'
Do you want to run this program?[N/Yes] (note need to type Yes):Yes
reiserfs_open: neither new nor old reiserfs format found on ./backup_hda6.bin

what is version of ReiserFS you use[1-4]
        (1)   3.6.x
        (2) >=3.5.9
        (3) < 3.5.9 converted to new format
        (4) < 3.5.9
        (X)   exit
1
Super block of format 3.6 found on the 0x3 in block 16
Block count 4432672
Blocksize 4096
Free blocks 0
Busy blocks (skipped 16, bitmaps - 136, journal blocks - 8193
1 super blocks, 4424326 data blocks
Root block 0
Journal block (first) 18
Journal dev 0
Journal orig size 8192
Filesystem state ERROR
Tree height 0
Hash function used to sort names: not set
Objectid map size 0, max 972
Version 2
Is this ok ? [N/Yes]: Yes

Do not forget to run reiserfsck --rebuild-tree


[root@ipso big]# mount -o loop ./backup_hda6.bin /test -t reiserfs
mount: wrong fs type, bad option, bad superblock on /dev/loop0,
       or too many mounted file systems



> 
> Holger
> -- 
> Holger Grothe  (Email: grothe@mathematik.tu-darmstadt.de)
> Fachbereich Mathematik, TU Darmstadt
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 


IpSo

--------------------------------------------------------------------
Never worry about viruses in your Email again.
Get your FREE! virus scanned Email accounts at http://snappymail.ca

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] A way to bypass LVM and extract the raw data off?
  2002-01-08 21:03           ` IpSo
@ 2002-01-09 13:41             ` Andreas Dilger
  2002-01-09 15:44               ` IpSo
  0 siblings, 1 reply; 15+ messages in thread
From: Andreas Dilger @ 2002-01-09 13:41 UTC (permalink / raw)
  To: IpSo; +Cc: linux-lvm

On Jan 08, 2002  19:02 -0800, IpSo wrote:
> Yup! I'm confident everything as far as the reiser filesystem is fine,
> just LVM is very confused. 
> 
>    Device Boot    Start       End    Blocks   Id  System
> /dev/hda1   *         1       507    255496+  82  Linux swap
> /dev/hda2           508     39813  19810224    5  Extended
> /dev/hda5           508      4633   2079472+  83  Linux
> /dev/hda6          4634     39813  17730688+  8e  Linux LVM
> 
>  
> >     If you have the HD space, you could try dd if=/dev/hda6 of=/some/file
> > 
> >     Then mount -o loop /some/file /mnt/point -t reiserfs. 
> > 
> >     I don't think this would do any more damage. 
>
> I'll give it a shot I guess, won't this loopback file contain the extra LVM
> information and cause problems when trying to mount it though? Does the LVM
> information take up the first 2mb or something that I could set the offset as,
> so it doesn't carry over to the loopback file?

No, it uses a variable amount of space.

What you could do is try

od -Ad -a /dev/hda6 | grep "R   e   I   s   E   r   2   F   s"

and start your dd 65584 bytes before the address at the line this is
found on (it should align to an even block boundary).

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] A way to bypass LVM and extract the raw data off?
  2002-01-09 13:41             ` Andreas Dilger
@ 2002-01-09 15:44               ` IpSo
  2002-01-09 16:26                 ` Andreas Dilger
  0 siblings, 1 reply; 15+ messages in thread
From: IpSo @ 2002-01-09 15:44 UTC (permalink / raw)
  To: Andreas Dilger; +Cc: linux-lvm

Quoting Andreas Dilger <adilger@turbolabs.com>:

> On Jan 08, 2002  19:02 -0800, IpSo wrote:
> > Yup! I'm confident everything as far as the reiser filesystem is fine,
> > just LVM is very confused. 
> > 
> >    Device Boot    Start       End    Blocks   Id  System
> > /dev/hda1   *         1       507    255496+  82  Linux swap
> > /dev/hda2           508     39813  19810224    5  Extended
> > /dev/hda5           508      4633   2079472+  83  Linux
> > /dev/hda6          4634     39813  17730688+  8e  Linux LVM
> > 
> >  
> > >     If you have the HD space, you could try dd if=/dev/hda6
> of=/some/file
> > > 
> > >     Then mount -o loop /some/file /mnt/point -t reiserfs. 
> > > 
> > >     I don't think this would do any more damage. 
> >
> > I'll give it a shot I guess, won't this loopback file contain the extra
> LVM
> > information and cause problems when trying to mount it though? Does the
> LVM
> > information take up the first 2mb or something that I could set the offset
> as,
> > so it doesn't carry over to the loopback file?
> 
> No, it uses a variable amount of space.
> 
> What you could do is try
> 
> od -Ad -a /dev/hda6 | grep "R   e   I   s   E   r   2   F   s"
> 
> and start your dd 65584 bytes before the address at the line this is
> found on (it should align to an even block boundary).

At the "line", I tried the command and I got about 1000+ lines that seem to
match. I assume I just try from the first line minus 65584 (3276800) like you 
said? 

[root@ipso big]# od -Ad -a /dev/hda6 | grep "R   e   I   s   E   r   2   F   s"
3342384  bs nul soh nul   R   e   I   s   E   r   2   F   s nul nul nul
3383344 eot nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
3424304 eot nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
3498032 stx nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
3547184 eot nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
3616816 ack nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
3706928  nl nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
3825712  nl nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
3842096 dc4 nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
3932208 dc4 nul soh nul   R   e   I   s   E   r   2   F   s nul nul nul
3944496 dc4 nul soh nul   R   e   I   s   E   r   2   F   s nul nul nul
3956784 dc4 nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
4001840 dc4 nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
...



dd if=/dev/hda6 bs=512 skip=3276800 of=/big/backup_hda6.bin

-rw-r--r--    1 root     root     16478502912 Jan  9 12:50 backup_hda6.bin

Still won't mount the file. :( Even after a --rebuild-sb.

I also tried: (/dev/hda)

dd if=/dev/hda bs=512 skip=3276800 of=/big/backup_hda6.bin

-rw-r--r--    1 root     root     18870119424 Jan  9 13:41 backup_hda6.bin

Still no go. 

> 
> Cheers, Andreas
> --
> Andreas Dilger
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
> 


IpSo

--------------------------------------------------------------------
Never worry about viruses in your Email again.
Get your FREE! virus scanned Email accounts at http://snappymail.ca

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] A way to bypass LVM and extract the raw data off?
  2002-01-09 15:44               ` IpSo
@ 2002-01-09 16:26                 ` Andreas Dilger
  2002-01-09 17:26                   ` IpSo
  0 siblings, 1 reply; 15+ messages in thread
From: Andreas Dilger @ 2002-01-09 16:26 UTC (permalink / raw)
  To: IpSo; +Cc: linux-lvm

On Jan 09, 2002  13:43 -0800, IpSo wrote:
> Quoting Andreas Dilger <adilger@turbolabs.com>:
> > On Jan 08, 2002  19:02 -0800, IpSo wrote:
> > > Yup! I'm confident everything as far as the reiser filesystem is fine,
> > > just LVM is very confused. 
> > > 
> > >    Device Boot    Start       End    Blocks   Id  System
> > > /dev/hda1   *         1       507    255496+  82  Linux swap
> > > /dev/hda2           508     39813  19810224    5  Extended
> > > /dev/hda5           508      4633   2079472+  83  Linux
> > > /dev/hda6          4634     39813  17730688+  8e  Linux LVM
> > > 
> > > Does the LVM information take up the first 2mb or something that I
> > > could set the offset as, so it doesn't carry over to the loopback file?
> > 
> > No, it uses a variable amount of space.
> > 
> > What you could do is try
> > 
> > od -Ad -a /dev/hda6 | grep "R   e   I   s   E   r   2   F   s"
> > 
> > and start your dd 65584 bytes before the address at the line this is
> > found on (it should align to an even block boundary).
> 
> At the "line", I tried the command and I got about 1000+ lines that seem to
> match. I assume I just try from the first line minus 65584 (3276800) like you 
> said? 
> 
> [root@ipso big]# od -Ad -a /dev/hda6 | grep "R   e   I   s   E   r   2   F   s"
> 3342384  bs nul soh nul   R   e   I   s   E   r   2   F   s nul nul nul
> 3383344 eot nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> 3424304 eot nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> 3498032 stx nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> 3547184 eot nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> 3616816 ack nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> 3706928  nl nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> 3825712  nl nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> 3842096 dc4 nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> 3932208 dc4 nul soh nul   R   e   I   s   E   r   2   F   s nul nul nul
> 3944496 dc4 nul soh nul   R   e   I   s   E   r   2   F   s nul nul nul
> 3956784 dc4 nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> 4001840 dc4 nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> ...
> 
> dd if=/dev/hda6 bs=512 skip=3276800 of=/big/backup_hda6.bin
> 
> -rw-r--r--    1 root     root     16478502912 Jan  9 12:50 backup_hda6.bin

Well, since "od" outputs a _byte_ offset, and "dd" is skipping _sectors_,
you need to use:

dd if=/dev/hda6 bs=512 skip=6400 of=/big/backup_hda6.bin

Granted, all of these superblock copies might be in the journal, so it
is hard to tell (with ext2/ext3 there are backup superblocks, but they
have numbers assigned to them, so you can still find the proper start
of the filesystem.

> I also tried: (/dev/hda)
> dd if=/dev/hda bs=512 skip=3276800 of=/big/backup_hda6.bin

Well, this doesn't make sense, since the offset is relative to the start
of /dev/hda6.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

^ permalink raw reply	[flat|nested] 15+ messages in thread
* Re: [linux-lvm] A way to bypass LVM and extract the raw data off?
  2002-01-09 16:26                 ` Andreas Dilger
@ 2002-01-09 17:26                   ` IpSo
  0 siblings, 0 replies; 15+ messages in thread
From: IpSo @ 2002-01-09 17:26 UTC (permalink / raw)
  To: linux-lvm

Andreas,

  dd if=/dev/hda6 bs=512 skip=6400 of=/big/backup_hda6.bin


That did the trick. It mounted no problem whatsoever! Thank you very much. Your
help has been greatly appreciated. 

Thanks also to, Holger Grothe and Petro. 

Quoting Andreas Dilger <adilger@turbolabs.com>:

> On Jan 09, 2002  13:43 -0800, IpSo wrote:
> > Quoting Andreas Dilger <adilger@turbolabs.com>:
> > > On Jan 08, 2002  19:02 -0800, IpSo wrote:
> > > > Yup! I'm confident everything as far as the reiser filesystem is
> fine,
> > > > just LVM is very confused. 
> > > > 
> > > >    Device Boot    Start       End    Blocks   Id  System
> > > > /dev/hda1   *         1       507    255496+  82  Linux swap
> > > > /dev/hda2           508     39813  19810224    5  Extended
> > > > /dev/hda5           508      4633   2079472+  83  Linux
> > > > /dev/hda6          4634     39813  17730688+  8e  Linux LVM
> > > > 
> > > > Does the LVM information take up the first 2mb or something that I
> > > > could set the offset as, so it doesn't carry over to the loopback
> file?
> > > 
> > > No, it uses a variable amount of space.
> > > 
> > > What you could do is try
> > > 
> > > od -Ad -a /dev/hda6 | grep "R   e   I   s   E   r   2   F   s"
> > > 
> > > and start your dd 65584 bytes before the address at the line this is
> > > found on (it should align to an even block boundary).
> > 
> > At the "line", I tried the command and I got about 1000+ lines that seem
> to
> > match. I assume I just try from the first line minus 65584 (3276800) like
> you 
> > said? 
> > 
> > [root@ipso big]# od -Ad -a /dev/hda6 | grep "R   e   I   s   E   r   2   F 
>  s"
> > 3342384  bs nul soh nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 3383344 eot nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 3424304 eot nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 3498032 stx nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 3547184 eot nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 3616816 ack nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 3706928  nl nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 3825712  nl nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 3842096 dc4 nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 3932208 dc4 nul soh nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 3944496 dc4 nul soh nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 3956784 dc4 nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> > 4001840 dc4 nul stx nul   R   e   I   s   E   r   2   F   s nul nul nul
> > ...
> > 
> > dd if=/dev/hda6 bs=512 skip=3276800 of=/big/backup_hda6.bin
> > 
> > -rw-r--r--    1 root     root     16478502912 Jan  9 12:50
> backup_hda6.bin
> 
> Well, since "od" outputs a _byte_ offset, and "dd" is skipping _sectors_,
> you need to use:
> 
> dd if=/dev/hda6 bs=512 skip=6400 of=/big/backup_hda6.bin
> 
> Granted, all of these superblock copies might be in the journal, so it
> is hard to tell (with ext2/ext3 there are backup superblocks, but they
> have numbers assigned to them, so you can still find the proper start
> of the filesystem.
> 
> > I also tried: (/dev/hda)
> > dd if=/dev/hda bs=512 skip=3276800 of=/big/backup_hda6.bin
> 
> Well, this doesn't make sense, since the offset is relative to the start
> of /dev/hda6.
> 
> Cheers, Andreas
> --
> Andreas Dilger
> http://sourceforge.net/projects/ext2resize/
> http://www-mddsp.enel.ucalgary.ca/People/adilger/
> 
> 
> _______________________________________________
> linux-lvm mailing list
> linux-lvm@sistina.com
> http://lists.sistina.com/mailman/listinfo/linux-lvm
> read the LVM HOW-TO at http://www.sistina.com/lvm/Pages/howto.html
> 


IpSo

--------------------------------------------------------------------
Never worry about viruses in your Email again.
Get your FREE! virus scanned Email accounts at http://snappymail.ca

^ permalink raw reply	[flat|nested] 15+ messages in thread
end of thread, other threads:[~2002-01-09 17:26 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-01-06  3:33 [linux-lvm] VG dissappeared without a trace? IpSo
2002-01-06 13:03 ` IpSo
2002-01-06 16:22   ` Andreas Dilger
2002-01-06 17:29     ` IpSo
2002-01-08 20:27       ` [linux-lvm] A way to bypass LVM and extract the raw data off? IpSo
2002-01-08 20:35         ` Petro
2002-01-08 21:03           ` IpSo
2002-01-09 13:41             ` Andreas Dilger
2002-01-09 15:44               ` IpSo
2002-01-09 16:26                 ` Andreas Dilger
2002-01-09 17:26                   ` IpSo
2002-01-08 21:05         ` Andreas Dilger
2002-01-09  9:02           ` IpSo
2002-01-09 10:30             ` Holger Grothe
2002-01-09 12:04               ` IpSo

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.