Re: Looking for confirmation as I enter the acceptance stage.

On 27 Jul 2023 10:12 -0400, from [email protected] (blobfish):
> Ok I got a third drive to receive files. I was getting everything hooked up and 
> ready and I ran into a problem. Apparently the clone wasn't completely 
> successful? 
> 
> parted: //on cloned drive
> Error: Invalid argument during seek for read on /dev/sdc
> Retry/Ignore/Cancel? I                                                    
> Error: The backup GPT table is corrupt, but the primary appears OK, so that 
> will be used.
> OK/Cancel? OK                                                             
> Model: WD easystore 264D (scsi)
> Disk /dev/sdc: 8002GB
> Sector size (logical/physical): 512B/4096B
> Partition Table: unknown
> Disk Flags: 

Your ddrescue screenshot indicates that 8001 GB was copied, but your
pasted parted interaction indicates that some drive is 8002 GB. The
backup GPT is at the very end of the device. Thus, if the sizes don't
match exactly, the backup GPT won't be found. It's hard to follow
exactly based on the short /dev/sd* names (because those can change,
especially with reboots and hotplugging drives), but even if the new
drive is slightly smaller, that isn't necessarily a showstopper either
because you can set up a LVM group or a mdraid JBOD array of it and a
file elsewhere that makes up for the difference in size. (The
mechanics of how to do that is definitely off topic on this list,
however.)

If the drive sizes matched exactly, or if the target device was
larger, then I don't think your ddrescue execution would have run out
of space on the target.


> Your procedure for dumping and testing the luks header doesn't work on this 
> cloned drive.

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.

-- 
Michael Kjörling                     🔗 https://michael.kjorling.se
“Remember when, on the Internet, nobody cared that you were a dog?”