# mounting an lvm image

## mathfeel

I had a faulty hard drive with a few bad sectors. So I use dd with conv=noerror,sync to back up the image of the whole drive, the use testdisk to fix the partition table. Here is the result:

```
# fdisk -l sda.img 

Disk sda.img: 200.0 GB, 200049647616 bytes

255 heads, 63 sectors/track, 24321 cylinders, total 390721968 sectors

Units = sectors of 1 * 512 = 512 bytes

Sector size (logical/physical): 512 bytes / 512 bytes

I/O size (minimum/optimal): 512 bytes / 512 bytes

Disk identifier: 0x00000000

  Device Boot      Start         End      Blocks   Id  System

sda.img1   *      224910     2345489     1060290   83  Linux

sda.img2         2345490   390716864   194185687+  8e  Linux LVM
```

Question is how do I now make a block device for each of the two partitions? and mount them or activate the volume group in the second partition?

Thanks.

----------

## NeddySeagoon

mathfeel,

ddrescue does a much beter job of reading data from dead or dying drives.  You may want to make to make a new image with ddrescue to be sure you get back everything you can reasonably recover. be sure to try the the problem disk upside down, on edge on end etc.  The idea is to try to get gravity to help align the bits for just one last read.

To mount sda.img1, you can use mount -o,ro,loop,offset=230307840 /path/to/image /mnt/someplace

You need loopback support from your kernel, ro is read only. Its a very bad idea to mount the filesystem read write if it may contain missing blocks and other errors.offset is just the number of bytes from the start of the image file, thats 224910x1024 bytes as each block is 1024 bytes.

To play with LVM on an image is a little harder. You need losetup to attach sda.img2 to a loop device, then you can run 

```
vgchange -ay
```

 to start LVM.

Read 

```
man losetup
```

for the detail.

Once you can see /dev/mapper and friends, you can try to use mount -o ro in the normal way.  Read only is important.

----------

## mathfeel

 *NeddySeagoon wrote:*   

> mathfeel,
> 
> ddrescue does a much beter job of reading data from dead or dying drives.  You may want to make to make a new image with ddrescue to be sure you get back everything you can reasonably recover. be sure to try the the problem disk upside down, on edge on end etc.  The idea is to try to get gravity to help align the bits for just one last read.
> 
> 

 

Thanks for the tip. I will indeed try that later if the current image doesn't work. From dd's output, the bad sectors are only at near the beginning of the drive, which is the / partition.

 *Quote:*   

> To mount sda.img1, you can use mount -o,ro,loop,offset=230307840 /path/to/image /mnt/someplace
> 
> You need loopback support from your kernel, ro is read only. Its a very bad idea to mount the filesystem read write if it may contain missing blocks and other errors.offset is just the number of bytes from the start of the image file, thats 224910x1024 bytes as each block is 1024 bytes.
> 
> To play with LVM on an image is a little harder. You need losetup to attach sda.img2 to a loop device, then you can run 
> ...

 

I was also thinking about losetup, but was not sure how to do it, if there is an offset.

----------

## NeddySeagoon

mathfeel,

You can copy the LVM partition out of the image with dd.  You need either the seek= or skip= parameter, I forget which ... and space for the copy of course.

----------

## khayyam

 *NeddySeagoon wrote:*   

> [...] be sure to try the the problem disk upside down, on edge on end etc. The idea is to try to get gravity to help align the bits for just one last read.

 

The mad scientist in me is hoping this is more than 'peanut butter vs bubble gum' :) ... but I can't help but ask why this might have any effect, the earths gravity is not magnetic, sure there is magnatism, but the magnetic effect of the grid of electric cables and what-have-you, solar-raditation, weather, etc, etc, would have a far greater (or at least mesurable) presence and its not 'directed' (downward) but in fields (more like the aurora borealis than gravitational effect). So, not to poo-poo the theory, or anyone, but where does this idea come from?

best ... khay

----------

## mathfeel

 *NeddySeagoon wrote:*   

> To mount sda.img1, you can use mount -o,ro,loop,offset=230307840 /path/to/image /mnt/someplace 
> 
> You need loopback support from your kernel, ro is read only. Its a very bad idea to mount the filesystem read write if it may contain missing blocks and other errors.offset is just the number of bytes from the start of the image file, thats 224910x1024 bytes as each block is 1024 bytes. 
> 
> .

 

filesystem n00b here: How did you infer the block size of 1024 bytes? from the information in the fdisk output above or else? When computing offset etc, is mbr taken into account?

----------

## NeddySeagoon

khayyam,

The easy one first.  Disk drives use air bearings. That is, there is no metal to metal contact between the fixed part of the drive and the rotating part except when the drive spins up.

At its operational speed, the bearing surfaces are separated by a cushion of air, which is very good for both friction aind wear.

There are other forces at work too. The platters are a spinning mass. Unless the spin axis of the drive is parallel to the rotational axis of the Earth, which is very unlikely unless the drive is located at the poles, the rotation of the Earth about its axis causes the platters to attempt to rotate (precess) at right angles to the spin axis and the force applied by Earths rotation.  We can neglect the precession due to the Earchs orbit around the sun as that is tiny compared to precession induced by both gravity and Earths rotational rate.

All this means that there is a force acting on the drive bearings that you are not aware of.  If you have scrap drive, you can feel the gyroscopic effect when you spin it up then move it about any axis except the spin axis. A toy gyroscope or spinning top may help you understand whats happening. 

Most drive failures are due to bearing failures of one sort or another. Here, wear is a form of failure too. Keep in mid that there is some bearing surface contact, even if its very brief during spin up and spin down.  The idea of operating the drive in various orientations is to get both gravity and the gyroscopic forces to attempt to have the air bearings align slightly differently, so a slightly different part of the magnetic surface of the drive is read.

This is where ddrescue helps. It gets the easy to read data first by doing a binary seach of the target area. When there are only problem regions of the drive left, it keeps attempting reads by sneaking up on the faulty sectors by reading secors in decending order, by stepping the head onto the track from the inside and the outside etc.  The whole idea it to use the mechanical tolerances of the drive as an aid to data recovery.

----------

## NeddySeagoon

mathfeel,

khayyams question needed the appliance of science. The response to yours depends on some heuristics.

Block 224910 is a very odd start address but it can be right. Old versions of fdisk use sector 63 and new versions use block 2048, or 2Mb. Neither of which maps onto block 224910.

Than makes me suspect you have another partition in that disk image that is not in the partition table - before the first partition. 224910 is about 115Mb from the start of the drive.

We know your image is

```
 Disk sda.img: 200.0 GB, 200049647616 bytes 
```

and we know that the last partition ends at 390716864 somethings, which should also be very close to the end of the disk.

These somethings are sectors (512b) blocks (1024b) or cylinders (512x63x255b just over 8Mb)

With some trial and error 390716864x512=200047034368, which is very close to the end of your drive.

Its less then one cylinder.

In my previous post, I used 1024, not 512 as the block size, so all my numbers are out by a factor of two.  Sorry about that.

History lesson: Cylinders, Heads and Sectors were used to address all drives in the days before logical block addessing.

A sector is the smallest unit of addressable storage on a disk.  Drives were made with many different numbers of sectors per track but the BIOS code can cope with a maximum of 63.

A head is moved in and out over the disk surface to read all the tracks on that surface. The BIOS can support a maximim of 255 heads.

A vertial single track slice of a disk (the stack of heads) is called a Cylinder. The original BIOS can support at most 1024 cylinders.

By convention, the first partition starts at head 1, sector 0 track 0. In days of oldthat was a variable number of sectors from the start of the drive.  By convention, all drives report 63 sectors per track and 255 heads as thats the biggest numbers the BIOS supports, hence the first partition starts at sector 63. The space after the MBR and the start of the first partition is apparently wasted.  Its ceartianly outside any filesystem. However, almost every bootloader uses at least some of it.  Grubs sage1.5 goes there.

These CHS limits started the race between HDD manufactures making bigger drives and BIOS vendors comming up with different ways to read them when drives reached 528Mb. Thats another history lesson. Read The Linux Documentation Projects Large Drive HOWTO ... its all there.

----------

## khayyam

NeddySeagoon ...

Thanks for your very detailed reply ... so its centrifugal force rather than gravitational. A vacuum would be the ideal spot for such tasks due to the reduced friction, just in case you have one knocking arround, hehe. The essencial problem being centrafugal (the disk loosing its fixed 'center') I can see how changing its axis would move the 'weight' on the bearing to a different co-ordinate and how this might allow reads that prior co-ordinates might miss. Its an interesting idea ... so thanks again for the clarification.

best ... khay

----------

## NeddySeagoon

khayyam,

Its a combination of the changed gravity vector and the precessive force. See gyroscopic precession

----------

