From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8991213FFD for ; Fri, 28 Jul 2023 15:23:45 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.com; s=s31663417; t=1690557823; x=1691162623; i=blobfish@gmx.com; bh=CkthIGfyl2K9TopLl/TKfs9egZ2O/1SqJ5Mx/bd3hBA=; h=X-UI-Sender-Class:From:To:Subject:Date:In-Reply-To:References; b=HZRsa5fi22RsnIsl45NBF8vOFZ0YGc9Yz5uRzJKI843ocO2mVBjjqoH1yyh3ppSdTOyRVAd WC7BLQGKRQdifd8jy+1kjCRz4w+kT+rS8Eqdp5D/3ZYKKgCjBiLIQn/pyAM59/Clx4H77wCo2 RrZO+2VsGXdfIVHh8gj79RX6N2RMANvjudcIDamvbbZXTQHeCT/stI/orQVmWKnWV6hEucejI 7dHHVLaXSLN6rStxcMw6uM//rSHDj7fyJcKof4SmeIASSaQMoG6umYPVrr9D1ht29PsHgrv7z mnnKxh3e4GKi6fvTukVdD9B2VtRJelUVrjQ4e5qK+Tvp8ul1IViQ== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from laptop.localnet ([146.70.57.18]) by mail.gmx.net (mrgmx104 [212.227.17.174]) with ESMTPSA (Nemesis) id 1McYCb-1pt5EY0tmH-00cxwP for ; Fri, 28 Jul 2023 17:23:43 +0200 From: blobfish To: cryptsetup@lists.linux.dev Subject: Re: Looking for confirmation as I enter the acceptance stage. Date: Fri, 28 Jul 2023 11:23:40 -0400 Message-ID: <13313734.uLZWGnKmhe@laptop> In-Reply-To: References: <2159917.irdbgypaU6@laptop> <3554948.iIbC2pHGDl@laptop> Precedence: bulk X-Mailing-List: cryptsetup@lists.linux.dev List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-Provags-ID: V03:K1:kish80djVJmXrs0cETZRRCKzx55s37Fd6PUr3aThajJth1zVx/W yx3jkQ95HLwPnruzcKyWT53eBXgKVGKI/NZ2pOdYrDvCvs1ED3I63VjZcqa2GEUGbKrxkS1 adcnQl8Hz7Qdqst1oUIjAlLZMe0T4tINx0wXaN4qIAOZD3kB3JXN0/FUqDvmg81ai2iKSZ1 h+/GbJ+Dxi1fyvpmWEYng== X-Spam-Flag: NO UI-OutboundReport: notjunk:1;M01:P0:11a3G+Erkp8=;WPqVwYUatCEs7DgveqFimISAJLO rmBnPgW2nHH6MaGvUsaAU/z7S0eNkTnKiBL1sXstuchKcyuc2JT+pap0eZNltbCzFISAYLf52 VS9RbE7ewj506AVle2AxGCfT2/1mdQznjxAWr95MUp3kk9UcWrBfK8RaInHEC25la6YOZ32vt qPIrEYO4g8ktMw1n+xGfH5WUYhicrbIMaq2iefRbr8hS7FAIACvi3iPci2xsT/D+1IVueUa+6 oB48en8QeeOgnPwW0fdN1SE/CtGn76BMLQffDTFo69hSB/j08j7pqaoPSQ1pt4bANlYtWJfpE USvvezIKVct4KIAPO5zzux7VZhPZMV7oMUghu8tawuqn8ACCB9XHcZnYuWkSat/NHLITGts5k NjO3XX8/blRfgU3JsAY5bZU0JrT2illPosTu/CrCkMxW03pP9CgjohpqrE4wWYvsvu5mWk1e+ PdPSH/Pfm1qqhfm/AeZa6bh+xtCnyN0yedSkR0jlUvaRGs2OZj6ZBWXtH7nmGsT4ezQrc2fGm 0hPNudmBh7mItB5Wzxl+cHoGFxTRWSpEn6hOu+dGbrBGzsq1sI/gQdfJGI+VtSfMUvUK4H1r/ PoiMp5tuWdXR8ye6CTEAFR7uj4R4gl037xzeXz/E4yfEmUXtJz3FEsUDj0l62gl14XcLDNckX DCJFNIhYnzfVLsFpBhzDYC4i4scjGNHeMa58GCzKTiCT7SCZ1VEAOcA9rOm5CSGFfNW+d35m3 f+YZUJoI/qpPum7KD8yqDuzdUPfGnto6fq9NjXAOimhAeJJEdZboOC6fi0SF9aYkvuZqx6I93 HXfIgwG78oLbz4SDxn9vhkNF1RboxAqdkxWt1g+eru6a4pPMeIlBz9x6Nx3i94g2jLW1bIh/o tbVb9ofFW+oy5UuddIxqY/rBIu0B1WIAyX38VU5LKS4hs1pFMKIHAm59dJKsQE0r6yT5r6biC 6jSR9lcqU7PeEuHH/iC07a0RRqQ= On Friday, July 28, 2023 9:17:43 AM EDT Michael Kj=F6rling 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=3DX > bs=3DY; the offset was X*Y bytes. >=20 > 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/` for that > offset N to set up a loopback device which offsets I/O through to > /dev/ (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 pa= rted=20 complaining about the gpt table and that it (parted) didn't list any=20 partitions. Also I wasn't expecting the offset to be different. As I was fi= guring=20 out the offset for the clone, I did notice some EFI information which I am= =20 pretty sure was not on the original. I didn't spend a lot of time with that= =20 cloned drive prior to ddrescue, I might have missed the EFI partition and=20 maybe ddrescue started after it and that could explain the incomplete copy? Anyway, I have made it through and have successfully mounted my filesystem!= =20 =46irst 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= =20 for what I am doing?