Greetings, new here.

I was previously attempt to clone my failing disk to a raid-1 array with aronis true image but failed because of the bad sectors near the end of the source disks. So i try to use dd from a livecd to do that.

as a noob to LVM, i didn't realized if there are disks with LVM volumes with exact same uuid, only one will shown in disk utility... in my case, the volumes on my source disk (/dev/sdc) was shown in disk utlility, under the category "Raid and other logicical volumes"(/dev/dm-0) which lead me to think that was referring to the raid array, my target.

Then I deleted volume on /dev/dm-0 and the dd'ed /dev/sdc to /dev/dm-0.... and you know, i'm doomed.

i now dd'ed the source disk to another single disk (/dev/sda), and managed to restore the LVM structure using meta data found on disk. But the partition tables seems messed up.

fdisk -l result as follows: (/dev/sda is the new cloned disk, sdb is the live usb disk)

Disk /dev/sda: 2000.4 GB, 2000398934016 bytes
255 heads, 63 sectors/track, 243201 cylinders, total 3907029168 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0006bb70

Device Boot Start End Blocks Id System
/dev/sda1 * 2048 1026047 512000 83 Linux
/dev/sda2 1026048 3906248703 1952611328 8e Linux LVM

Disk /dev/sdb: 7948 MB, 7948206080 bytes
245 heads, 62 sectors/track, 1021 cylinders, total 15523840 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: 0x20ac7dda

This doesn't look like a partition table
Probably you selected the wrong device.

Device Boot Start End Blocks Id System
/dev/sdb1 ? 3224498923 3657370039 216435558+ 7 HPFS/NTFS/exFAT
/dev/sdb2 ? 3272020941 930513678 976730017 16 Hidden FAT16
/dev/sdb3 ? 0 0 0 6f Unknown
/dev/sdb4 50200576 974536369 462167897 0 Empty

Partition table entries are not in disk order

Disk /dev/mapper/VolGroup-lv_home: 1940.3 GB, 1940318584832 bytes
255 heads, 63 sectors/track, 235896 cylinders, total 3789684736 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000


Disk /dev/mapper/VolGroup-lv_root: 53.7 GB, 53687091200 bytes
255 heads, 63 sectors/track, 6527 cylinders, total 104857600 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x0006bb70

Device Boot Start End Blocks Id System
/dev/mapper/VolGroup-lv_root1 * 2048 1026047 512000 83 Linux
/dev/mapper/VolGroup-lv_root2 1026048 3906248703 1952611328 8e Linux LVM

Disk /dev/mapper/VolGroup-lv_swap: 5435 MB, 5435817984 bytes
255 heads, 63 sectors/track, 660 cylinders, total 10616832 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disk identifier: 0x00000000

----

As you see, lv_root have 2 partition lv_root1 & lv_root2 which is the same as /dev/sda. and lv_home & lv_swap don't have valid partition tables. is there any chance i can fix this??

Thank you.

Welcome to LQ.

The tool I would pull first is testdisk. It is good at showing you where the partition breaks are. If you know what to do from there, you are fine. Otherwise, it looks grim.

It would be helpful if you laid out how the disks were assigned before things went wrong. I see what all the disks are at, but don't know how the puzzle goes together.

yes i have tried testdisk, but all the partitions it found are marked unrecoverable....
and photorec recovered a bunch of files with filenames of a alphanumeric string.

The original layout was fedora defualt installation layout....i don't remember exactly how its defined though.

all i know is the root "/" gose to lv_root
and then /home gose to lv_home
and swap gose to lv_swap

that's all i recalled.

sorry for the mess.

If you have a backup of /etc/fstab anywhere, then that's something to start with. Personally (and I'm putting a hand out to get slapped here) I would be surprised if it's seeing the usb disk as part of a raid or perhaps even lvm structure. I would have thought it would have to be internal for that.

dd is only useful for disk copying if you are dd'ing onto an identical disk. cp -a otherwise. With dd, he directories will point to track/cylinder for file start, and if the track/cylinder is different . . . you get info in, rubbish out. cp -a copies the data and writes fresh data locations. I would go through /dev/sda, & sdb, mounting every partition ro, e.g.

mount -o ro /dev/sda1 /mnt/tmp

and see what you can read. Consider also what you want/need, and what files you can do without. Also do web searches e.g. "linux deleted dm-0 raid 1" "linux recover lost raid-1". I'm no raid expert, and avoid lvm like the plague. Perhaps now you know why :-P.

1 members found this post helpful.

Thanks for the feedback, i'll try your approach.

Yeah, its definitely a bad move to have LVM on a raid array.

Looks like this is another example of convenience contradict with reliability in most case.

errrr wait, i can mount the partitions without valid partition tables??

i got:
root@Microknoppix:~# mount -o ro /dev/VolGroup/lv_root /tmp
mount: you must specify the filesystem type

OK.

Looking at them now, sda is your disk cloned with dd, right? If it is identical CHS to your old disk, dd may work - Otherwise it's nonsense, although you may get stuff off it with photorec. In the off chance it's identical, try the lines below.

sdb has a sdb1 & sdb2. Frankly, sdb3 & sdb4 look like garbage entries. sdb1 is NTFS, sdb2 is FAT16
(-->dos 6.0 & windows 3.11 iirc).

mount -t ntfs-3g /dev/sdb1 /somewhere
mount -t msdos /dev/sdb2 /somewhere (or mebbe -t vfat)

If this gets nowhere , there is ntfs and dos tools (check sbin & /usr/sbin). If testdisk won't do write up the partition table, I have _no_ ideas for you. Game over.

yep, sda is the disk i cloned. with the same size of my dying source disk. I'm not quite sure about the CHS though, just a 2TB disk.

sdb is the usb disk i stored the knoppix live dvd where i run the testdisk & photorec.

So that /dev/Mapper stuff is the data you're trying to get at?
Check the CHS of sda, & it's original. If they are different, you can let photorec loose on it. Once you have done that, clean it off, ans you probably need space. Throw in the old disk and try a cp -a to sda and you might get something. sdb is not of interest.

If you look to /etc/fstab, do you have there any translation of partitions, or is it somewhere else? If you have photorec data saved, cd to there & try this line on it
I would expect you to be able to find the partition (uuid probably) of each chunk that is in the LVM/raid array. Make a list of what's important/vital and save that stuff off. Then lose the lvm, the rest of the data, and reinstall. If it's commercially important, call experts.

If you get the uuids, add them to /etc/fstab, like this
You can then run 'mount -a' and it will try them :-D.

EDIT: If the kernel recognizes them, they are also in /dev/disk/by-uuid

2 members found this post helpful.

Thanks for the info again. will give it a try. orz