Hello again, folks to whom I am grateful for all the advice! I bring good news, that the drive has been recovered successfully, and the data promptly backed up (twice!).
For future reference if anybody else ever overwrites or deletes or otherwise mangles their partition table, here is the protocol that worked, hopefully in enough detail that it is manageable with only basic command line comfort:
- For safety, use dd to copy the broken drive (ādamageddriveā) to a backup (ādamageddrivecopyā)
a. start without any external drives (including damageddrive) plugged in
b. use lsblk to see currently mounted drives/partitions
c. plug in damageddrive
d. use lsblk to see where damageddrive is mounted (the new entry relative to before plugging damageddrive in), in my case it was /dev/sda, without any visible partitions underneath it
e. plug in damageddrivecopy
f. use lsblk to see where damageddrivecopy is mounted, in my case it was /dev/sdb
g. use dd to copy damageddrive to damagedrivecopy, the template of the command is sudo dd if=/dev/MOUNTPOINTOFDAMAGEDDRIVE of=/dev/MOUNTPOINTOFDAMAGEDDRIVECOPY, and the exact command in my case was sudo dd if=/dev/sda of=/dev/sdb
A comment on 1.g, the dd command has a variety of flags that can be set, at least for the Framework storage module whatever the default behavior is seems to have worked well. It is a somewhat slow process, in my setup (damageddrive plugged in to one of the Frameworkās slots, damageddrivebackup plugged in through USB-A 3.0 interface) it took about 2.5 hours. There are apparently ways of having it display progress in the terminal but I didnāt try any of those to minimize complexity. After this is done, running sudo fdisk -u -l will show that damageddrive and damageddrivecopy will have the same Disklabel types (in my case gpt, since my original sin was overwriting the original partition table with an empty gpt one) and Disk identifiers (which for gpt seems to be five fields of hex characters of varying lengths separated by hyphens). As per the comments of @truffaldino and @Matt_Hartley this is not a desirable situation in general, but for the moment for this procedure it is OK (and in fact seems unavoidable when making dd copies at least initially).
- Extract the partition table from a known good drive (āgooddriveā) using
sfdisk and save it somewhere. If this is not possible (not having a known good drive of the same type available) I have attached a copy of the file created by this step and used later, which may work for you, at least for the 250GB storage module. Modules (or maybe any drive) of different sizes may likely require an adjustment to the size= number in the file
a. I shut down everything, unplugged all the external drives, and booted up again fresh to minimize the possibility for confusion
b. you might want to check the version of sfdisk as for GPT partition tables there was a change of behavior in the semi-recent past (see comments here: command line - How to copy the partition layout of a whole disk using standard tools - Unix & Linux Stack Exchange); in my case I think it was moot since the driveās original/desired partition table was mbr (aka dos?) and anyway a current distribution as of 2023 is likely to have sufficiently updated tools)
c. plug in gooddrive and use lsblk to verify where it mounts (for me it was /dev/sda)
d. use sfdisk --dump \dev\sda > ~/gooddisk_partition_backup.dump to write a file to your home directory with the partition table information from gooddisk
e. Note that there is a line in the .dump file starting with ālabel-idā. You should delete this line (and save it as a different file, gooddisk_partition_backup_nolabelid.dump), because by doing so, the later step to write the partition table to the damaged driveās copy will automatically generate a new Disk identifier (this apparently is behavior of sfdisk, see same link as above), which is desirable.
Will comment here that I was somewhat suprised to see that the .dump file has a "device: " line that seems to list the mount location of the drive. I would have thought that this is not part of the partition table information since it is endowed by the OS on mount. In my case this was dev/sda, so I just made sure that there was not anything already mounted as /dev/sda in the next step when I wrote the partition information from this file to the damageddrivecopy.
At this point I again shut down the machine, unplugged all the external drives, and rebooted.
- Write the label-free partition table information from the .dump file to damageddrivecopy using
sfdisk
a. plug in damageddrivecopy and use lsblk to verify the mount location (in my case /dev/sda)
b. run sudo sfdisk /dev/sda < ~/gooddisk_partition_backup_nolabelid.dump
This is the moment of truth, if this simple strategy worked, it should relatively quickly mount damageddrivecopy and you should see all of the formerly missing files. That was an enormous relief. At this stage I plugged in a backup drive and drag-and-dropped all of the files to copy them over, and because this experience has made me paranoid did it again with a second backup drive. This was probably overkill.
For reference, there were some initially slightly scary messages printed to the terminal, which Iāll put here to reassure anyone if they see it:
GPT PMBR size mismatch (488397167 != 976773167) will be corrected by write.
The backup GPT table is not on the end of the device. This problem will be corrected by write.
Checking that no-one is using this disk right now ... OK
Disk /dev/sda: 465.76 GiB, 500107862016 bytes, 976773168 sectors
Disk model: SSD 870 EVO 500G
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 0EEFDD29-B3BC-41E4-B562-AFEAD635F6AD
Old situation:
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Script header accepted.
>>> Created a new DOS disklabel with disk identifier 0x05033b06.
/dev/sda1: Created a new partition 1 of type 'HPFS/NTFS/exFAT' and of size 232.9 GiB.
Partition #1 contains a exfat signature.
/dev/sda2: Done.
New situation:
Disklabel type: dos
Disk identifier: 0x05033b06
Device Boot Start End Sectors Size Id Type
/dev/sda1 7552 488397167 488389616 232.9G 7 HPFS/NTFS/exFAT
The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.
Also note that at this point because you had removed the label-id line from the .dump file, the Disk identifier of damageddrivecopy (which you can see with sudo fdisk -u -l) should be different from the label-id in the first .dump file that came straight from gooddrive. This means that you can do the next step to copy the recovered data back to damageddrive using dd and not have to worry about Device identifier conflicts later on if you use gooddisk with damageddrive (now a misnomer fortunately!) contemporaneously later.
- Copy the recovered data from damageddrivecopy to damageddrive using
dd
a. again abundance of caution, shut down the computer, removed all external drives, booted freshly
b. plug in damageddrivecopy, use lsblk to verify mount location, in my case /dev/sda
c. use sudo fdisk -u -l and make note of the End entry of /dev/sda1, call it XXX, which in my case was 488397167
c. plug in damageddrive, use lsblk to verify mount location, in my case /dev/sdb
d. use dd to copy only the relevant portion (this matters if the backup drive is larger than the damaged drive, which in my case it was) from damageddrivebackup to damageddrive, template of the command is dd if=/dev/MOUNTPOINTOFDAMAGEDDRIVEBACKUP of=/dev/MOUNTPOINTOFDAMAGEDDRIVE count=XXX+1, so in my case this was dd if=/dev/sda of=/dev/sdb count=488397168
This should put the repaired data from damageddrivebackup back on damageddrive, which share the same Disk identifier, but presumably you will never have both plugged in at the same time for long (and might eventually want to reformat the damageddrivebackup back to full capacity for other uses), so I did not do anything to remedy that.
Some general thoughts and lessons:
- not doing anything to potentially write to the damaged drive until establishing some success in fixing the backup copy was very important
- I did try using the Data Rescue menu item in gparted (which needed me to
sudo apt install gpart), which ran for a pretty long while, but ultimately failed as it reported not finding any partitions
- for the brief time after I
dd-ed the repaired backup to the damaged drive, the computer had two drives attached with the same Disk identifiers, and it seemed to do OK with that which I was relieved to see, but would not keep such a collision-guaranteed setup around long-term
- I wonder if there is a simple adjustment to this for recovering drives with more complicated partitiont tables than a single partition occupying the entire drive
Thank you again everyone for the advice and support!
Edit:
Cannot seem to upload the gooddisk_partition_backup_nolabelid.dump file as an attachment to the message, so here are the contents (although tabs vs spaces might be an issue going through the forum software, please look up the requirements in the sfdisk documentation if you are planning to use this directly:
label: dos
device: /dev/sda
unit: sectors
sector-size: 512
/dev/sda1 : start= 7552, size= 488389616, type=7
If youāre not comfortable with inspecting sectors of a block device to find where the partition starts using a dedicated tool will be better. Having backup allows for safe experiments.