Re: Looking for confirmation as I enter the acceptance stage.
blobfish <[email protected]> Fri, 28 Jul 2023 11:23:40 -0400
| Newsgroups | dev.linux.lists.cryptsetup |
|---|---|
| Message-ID | <13313734.uLZWGnKmhe@laptop> |
On Friday, July 28, 2023 9:17:43 AM EDT Michael Kjörling wrote: > Unfortunately, "doesn't work" isn't very helpful. The offsets I > mentioned previously were based on what you sent, which presumably was > based on the partition. If for some reason the partition table isn't > readable on the new drive, then at a minimum that means that those > exact offsets likely no longer apply. You will need to determine how > far into the device the initial "L" in "LUKS" in the LUKS header > appears; then skip that many bytes when reading such that that "LUKS" > is the very first four bytes that cryptsetup sees on the device (or in > the file) that you give it. That was the purpose of the dd skip=X > bs=Y; the offset was X*Y bytes. > > The general idea is that once you have a copy of the drive holding the > broken LUKS container, you can work with that copy and just make a new > copy from the untouched original if you make a mistake; then, given > the offset at which the header you did find begins in the copy you're > working with, use e.g. `losetup -o N -f /dev/<something>` for that > offset N to set up a loopback device which offsets I/O through to > /dev/<something> (see the man page for details); then give the > resulting /dev/loop* device to cryptsetup. From there, once cryptsetup > successfully unlocks the container (which it should be able to, based > on the experimentation with the smaller portion of the container), I > believe that you should be able to mount the Btrfs file system > normally through the symlink in /dev/mapper to whichever /dev/dm-* > that happens to become. Once the file system is mounted, it should all > hopefully be a perfectly normal file copy operation. Ok, sorry for the confusion. Working with the clone, I was thrown off by parted complaining about the gpt table and that it (parted) didn't list any partitions. Also I wasn't expecting the offset to be different. As I was figuring out the offset for the clone, I did notice some EFI information which I am pretty sure was not on the original. I didn't spend a lot of time with that cloned drive prior to ddrescue, I might have missed the EFI partition and maybe ddrescue started after it and that could explain the incomplete copy? Anyway, I have made it through and have successfully mounted my filesystem! First look through an looks good. just a little more hand holding, I promise: should I get btrfs involved before the copy? like: btrfs check btrfs check --repair as far as the copy I was just going to 'cp -avr'. Is there a better command for what I am doing?