The TestDisk forum would be expected to host more posters explicitly experienced with of course TestDisk itself but also with recovering a LUKS-encrypted partition and may as such be a better idea than me/this forum. Which may not yet be all's there to it, but such would be determined from feedback the system gives without any such feedback I can't furthermore try to be useful. You'd then reboot and as advised try to "luksOpen" and mount that newly created partition. ![]() I'm as said not a TestDisk-aficionado and it's unclear to me why you'd use latter rather than former, but in any case the idea is to end up with a partition with the LUKS header at its start and large enough to cover the originally present one. php?t=8403, seems to say you can in MBR-mode after using a on the "Linux LUKS" partition change the end sector to that mentioned 121597 255 63 so as to expand the partition to the end of your disk or use a from to just add a new partition with that same starting sector, that end sector and with the proper LUKS type. That link I provided to the TestDisk forum. Those addresses are specified in so-called CHS format - Cylinder Head Sector - which as commented makes little sense it's an obsolete addressing scheme: even in an MBR-context it's been a backwards-compatibility thing only for some 20 years or so now and certainly it doesn't exist in a GPT-context.Īs such I was saying that rerunning the analysis in GPT-mode as you were advised on the TestDisk forum might give you more sensible numbers to work with than the above CHS-format numbers that you should feel free to try said rerunning, even if it'll probably work as well to just use the CHS-numbers for start and end that I gave 70604 13 2 resp. In your above posted results TestDisk shows the LUKS header/partition as P Linux LUKS 70604 13 2 70604 78 2 4096, i.e., as 4096 sectors (2M) from start address 70604 13 2 to end address 70604 78 2. In turn that unfortunately completely loses me "more sensible" is better (well, here.) Yes, if rerunning the analysis in GPT mode is in fact a thing you may be provided more sensible numbers to work with and you may try - but as per that forum link that I mentioned it seems you'd be able to simply add a partition yourself in any case.Ī note is that while I'm aware you'd not at this moment enormously appreciate such being pointed out: when one combines encryption with non-optimal technical prowess, best be damn sure to backup from now on.įirst you said I must be running the analysis in GPT mode, and now you're implying it may give more sensible numbers. I would at this point advise doing what I said earlier just create a partition with that mentioned start sector that extends to the end of the disk and see if you can then "luksOpen" and mount it. It seems you'd be presented the choice MBR/GPT right after selecting the disk itself: "EFI GPT partition map" rather than "Intel/PC partition".īut what I'm most definitively missing is the mention of that found 2M LUKS header. ![]() It would (sort of.) explain the also mentioned "ridiculous" CHS-addressing so, well, perhaps in fact. I.e., when I looked at your result I certainly let the fact that the thing seemed to find 10 partition records that it marked P, presumably "primary", imply that it was looking at things in GPT-mode MBR-mode can have up to 4 primary partitions only. Now, this is "dangerous" as I'm here getting out of my own comfort-zone - I don't use encryption other than for the technical sport of it and have although I've seen it be useful in practice always considered TestDisk a horrible tool with a god-awful interface - but I'm not so sure you should be listening to the reply you got there.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |