Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

I overwrote some LVM2 metadata in much the same way as Recovering overwritten LVM metadata . That is, I attempted to install Debian 6.0.7 on a system with existing encrypted volumes and LVM2 volumes.

The structure of the disk was that a LUKS volume covered a 90% partition (sdc1) on the disk; an LVM2 physical volume used up the LUKS volume; and this physical volume had its own volume group and two logical volumes.

I used these commands to generate a hex dump:

cryptsetup luksOpen /dev/sdc1 sdc1_crypt
dd if=/dev/mapper/sdc1_crypt of=text count=100000
hexdump -C text | less

Part of the hex dump:

00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000200  4c 41 42 45 4c 4f 4e 45  01 00 00 00 00 00 00 00  |LABELONE........|
00000210  1a d0 74 52 20 00 00 00  4c 56 4d 32 20 30 30 31  |..tR ...LVM2 001|
00000220  39 4b 4d 34 48 30 37 43  6c 5a 6d 62 5a 46 32 43  |9KM4H07ClZmbZF2C|
00000230  78 6b 69 72 72 58 61 62  52 64 35 48 38 66 62 79  |xkirrXabRd5H8fby|
00000240  00 10 0e 8c d1 00 00 00  00 00 03 00 00 00 00 00  |................|
00000250  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000260  00 00 00 00 00 00 00 00  00 10 00 00 00 00 00 00  |................|
00000270  00 f0 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00000280  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
00000800  d2 6d b3 03 e3 88 08 0f  0f 60 17 31 60 2a a5 86  |.m.......`.1`*..|
00000810  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00000a00  f4 6c 87 31 71 aa 28 b8  44 9e 03 75 fc 58 9b b4  |.l.1q.(.D..u.X..|
00000a10  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00000c00  13 30 81 66 9a 7a 33 eb  dd e7 b6 93 c5 e6 42 f0  |.0.f.z3.......B.|
00000c10  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00000e00  c2 71 8f 11 f4 70 b4 e3  af e0 a0 d7 86 bd ad 5b  |.q...p.........[|
00000e10  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00001000  1b c7 35 60 20 4c 56 4d  32 20 78 5b 35 41 25 72  |..5` LVM2 x[5A%r|
00001010  30 4e 2a 3e 01 00 00 00  00 10 00 00 00 00 00 00  |0N*>............|
00001020  00 f0 02 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
00001030  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
***
00004c00  82 12 42 63 c4 c1 b3 2b  f5 f9 d1 17 06 60 64 c3  |..Bc...+.....`d.|
00004c10  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00004e00  4a eb 67 e4 80 7d e7 72  d3 b4 52 36 31 3d 36 01  |J.g..}.r..R61=6.|
00004e10  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00005000  dc da e7 8d 9b f1 37 8f  97 92 ee a4 8d 9a 42 1e  |......7.......B.|
00005010  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00005200  d2 2d 71 cb d1 31 27 c8  aa aa 03 60 a2 5f 8e 14  |.-q..1'....`._..|
00005210  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00005400  fe 7b fd cd 20 5b cd 99  9a bf 23 92 10 b5 f9 c2  |.{.. [....#.....|
00005410  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00005600  86 a2 ce 88 2f ba 9b 3b  ba 55 f4 d2 a5 a1 3e b7  |..../..;.U....>.|
00005610  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00005800  33 37 62 46 24 43 3b a1  6b 4d 65 8f 5a ca 1b 46  |37bF$C;.kMe.Z..F|
00005810  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00005a00  bd d5 b4 41 46 08 b9 b9  87 a2 53 ab ff 01 2a 1b  |...AF.....S...*.|
00005a10  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00005c00  2f a8 ae 97 6d 56 8a 71  9e 16 60 2c f3 68 c2 f4  |/...mV.q..`,.h..|
00005c10  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00005e00  d3 44 a7 ca bc 21 61 f4  58 c4 f2 78 9c 34 95 18  |.D...!a.X..x.4..|
00005e10  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00006000  5d df c9 11 56 ec 92 03  ac 02 4e 91 40 76 a6 b3  |]...V.....N.@v..|
00006010  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00006200  e2 19 26 d8 4e bc ae 44  a1 47 f9 bd 6d 0f 86 57  |..&.N..D.G..m..W|
00006210  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00006400  82 52 57 e2 35 e7 82 af  53 fb d4 04 93 89 48 aa  |.RW.5...S.....H.|
00006410  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00006600  49 86 60 90 1e a5 da d3  55 4c 26 31 80 fb a5 2d  |I.`.....UL&1...-|
00006610  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00006800  cf 2a ae 71 e8 5b ac 8e  dd 70 9e 05 2b bb c5 9c  |.*.q.[...p..+...|
00006810  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00006a00  43 e2 38 92 9a 1d c7 c4  fe bf df 13 7f bf 5b f9  |C.8...........[.|
00006a10  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00006c00  38 40 94 3c 21 3e ce 63  e8 c3 5d 1d 35 08 3e 7c  |8@..c..].5.>||
00006c10  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00006e00  71 52 d0 15 44 78 ad 13  fa c5 a0 ec 74 4c a7 5b  |qR..Dx......tL.[|
00006e10  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00007000  4f 2d b5 50 57 6b ac 02  23 82 28 05 f5 5e d1 f1  |O-.PWk..#.(..^..|
00007010  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|
*
00007200  37 43 9a f7 68 e7 94 59  13 10 66 e8 56 53 e3 cb  |7C..h..Y..f.VS..|
00007210  a8 2b 87 77 cb 73 bf 52  c6 36 92 ec ee 9f b7 e0  |.+.w.s.R.6......|

If the installation had overwritten the LUKS block with a new one that used the same passphrase, could I still see the recurring "+.w.s.R.6", or would that be improbable? If this isn't what happened, what did?

I think the installation had overwritten the PV metadata, which accounts for the readable LVM2 line at 0x1000. But searching the disk for keywords that existed on the disk prior to installation returned nothing.

share|improve this question
    
Why don't you simply give your grep keyword /dev/dm-2 a try instead of asking here what would happen then? –  Hauke Laging Apr 28 '13 at 8:19
    
@HaukeLaging: (Regarding your edit suggestion). Believe it is better to comment (and optionally ask OP to change question) then correcting misconceptions etc. Optionally include corrections and/or clarifications in answer. –  Sukminder Apr 28 '13 at 8:42
    
Have you lost the data in /etc/lvm/, too? –  Hauke Laging Apr 28 '13 at 8:43
    
@Sukminder And what do you think will happen if I ask on meta for comments about your attitude? You are aware of it that you get reputation points for edits and that even spelling edits are considered useful by most moderator-level users? –  Hauke Laging Apr 28 '13 at 8:47
    
@HaukeLaging: yes, I should have mentioned that I tried the grep. It wasn't finding anything for keywords I knew should be on the disk, so that's why I was wondering about the blocks being encrypted. Unfortunately /etc was managed by the LVM... Thanks for your answer below, I'll give it a try and let you know how it goes. –  jjj Apr 28 '13 at 11:20

1 Answer 1

up vote 2 down vote accepted

You can use gpart to search for file systems on /dev/dm-2. After that or even as an alternative you can create dm volumes without LVM using dmsetup directly. On my systems the first LV always starts at offset 384:

dmsetup create restore-lv --table "0 25165824 linear /dev/dm-2 384"

The size is not important (and usually wrong) for the test. Then you check whether there is a file system. For ext? with

dumpe2fs -h /dev/mapper/restore-lv

If that really was the position of the LV then dumpe2fs (or the respective program for your file system type) should tell you the size of the file system (which usually is the same size as the LV):

Block count:              53248
Block size:               1024

In this case the FS / LV size is 53248*1024=54525952 bytes (106496 sectors). So the correct dmsetup command would have been

dmsetup create restore-lv1 --table "0 106880 linear /dev/dm-2 384"

and the next one is at 106496+384=106880:

dmsetup create restore-lv --table "0 106880 linear /dev/dm-2 106880"

Of course, if your LVs were fragmented then this won't work. But if it works then you can check whether lvcreate recreated the LVs correctly later.

share|improve this answer
    
I tried dmsetup on a fake disk that I set up similarly, and it worked there, but not on the real disk. I added some details to the question above. Maybe its the encryption that's broken, not (just) the LVM2? –  jjj May 1 '13 at 10:17
    
@jjj Did you have to enter the LUKS password during the Debian install? How far did the Debian install go? Could it simply have overwritten your data? Was there a second level of encryption in the LVs? –  Hauke Laging May 1 '13 at 10:50
    
I think I did have to enter the LUKS password, although I also think that I told it to not write encryption changes to the disk. There was not a second level of encryption in the LVs. –  jjj May 1 '13 at 10:55
    
@jjj I have no idea what has happened. But if there is obviously no data left (grep failing) then it seems to make little sense to try to repair this. The only scenario I can imagine not to be hopeless would be that you have stored your data compressed (so that grep cannot find it because it is kind of "encrypted"). I don't even know how that could be done, probably with FUSE. –  Hauke Laging May 1 '13 at 11:24
    
Well, at least now I know I can give up, and I learned something about dmsetup. Neither of which would have happened without your answer. –  jjj May 3 '13 at 0:27

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.