Undoing wipefs --all --force /dev/sda? /dev/sda

Question

OS: Debian Bullseye, uname -a:

Linux backup-server 5.10.0-5-amd64 #1 SMP Debian 5.10.24-1 (2021-03-19) x86_64 GNU/Linux

I am looking for a way of undoing this wipefs command:

wipefs --all --force /dev/sda? /dev/sda

while the former structure was:

fdisk -l /dev/sda

Disk /dev/sda: 223.57 GiB, 240057409536 bytes, 468862128 sectors
Disk model: CT240BX200SSD1  
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: 8D5A08BF-0976-4CDB-AEA2-8A0EAD44575E

Device       Start       End   Sectors   Size Type
/dev/sda1     2048   1050623   1048576   512M EFI System
/dev/sda2  1050624 468860927 467810304 223.1G Linux filesystem

and the output of that wipefs command (is still sitting on my terminal):

/dev/sda1: 8 bytes were erased at offset 0x00000052 (vfat): 46 41 54 33 32 20 20 20
/dev/sda1: 1 byte was erased at offset 0x00000000 (vfat): eb
/dev/sda1: 2 bytes were erased at offset 0x000001fe (vfat): 55 aa
/dev/sda2: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef
/dev/sda: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 8 bytes were erased at offset 0x37e4895e00 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa

I might have found an article hosted on https://sysbits.org/, namely: https://sysbits.org/undoing-wipefs/

I will quote the wipe and undo parts from there, I want to know if it's sound and I can safely execute it on my server, which I did not yet reboot, and since then trying to figure out a work-around from this hell of a typo:

wipe part

wipefs -a /dev/sda

/dev/sda: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 8 bytes were erased at offset 0x3b9e655e00 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa

undo part

echo -en '\x45\x46\x49\x20\x50\x41\x52\x54' | dd of=/dev/sda bs=1 conv=notrunc seek=$((0x00000200))
echo -en '\x45\x46\x49\x20\x50\x41\x52\x54' | dd of=/dev/sda bs=1 conv=notrunc seek=$((0x3b9e655e00))
echo -en '\x55\xaa' | dd of=/dev/sda bs=1 conv=notrunc seek=$((0x000001fe))

partprobe /dev/sda

Possibly alternative solution

Just now, I ran the testdisk on that SSD drive, and it found many partitions, but only these two match the original:

TestDisk 7.1, Data Recovery Utility, July 2019
Christophe GRENIER <[email protected]>
https://www.cgsecurity.org

Disk /dev/sda - 240 GB / 223 GiB - CHS 29185 255 63

     Partition                  Start        End    Size in sectors

 1 P EFI System                  2048    1050623    1048576 [EFI System Partition] [NO NAME]
 2 P Linux filesys. data      1050624  468860927  467810304

Can I / Should I just hit Write (Write partition structure to disk)? If not, why not?

Upvoted for almost giving me a heart attack by just reading the title — pipe, Apr 12 '21 at 12:54
Aside - It is time to consider the next options. **Had this not worked** how much would you have lost? How would you have recovered? What could you do now to make this same error less-bad. Make future-you grateful to present-you for thinking ahead. — Criggie, Apr 13 '21 at 03:26
Thank you, thank you, thank you. I had an off-site backup but this saved me a trip to recover my data. — 0xACE, Jan 14 '23 at 18:04

score 15 · Accepted Answer · edited Apr 11 '21 at 13:52

You're lucky that wipefs actually prints out the parts it wipes.

These,

wipefs -a /dev/sda
/dev/sda: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 8 bytes were erased at offset 0x3b9e655e00 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa

echo -en '\x45\x46\x49\x20\x50\x41\x52\x54' | dd of=/dev/sda bs=1 conv=notrunc seek=$((0x00000200))
echo -en '\x45\x46\x49\x20\x50\x41\x52\x54' | dd of=/dev/sda bs=1 conv=notrunc seek=$((0x3b9e655e00))
echo -en '\x55\xaa' | dd of=/dev/sda bs=1 conv=notrunc seek=$((0x000001fe))

do look sensible to me in general.

But note that the offsets there are different from the ones in your case! You'll need to use the values you got from wipefs.

Based on the offset values (0x3b9e655e00 vs 0x37e4895e00), they had a slightly larger disk than you did (~256 GB vs ~240 GB). Using their values would mean that the backup GPT at the end of disk would be left broken. That shouldn't matter much, in that any partitioning tool should be able to rewrite it as long as the first copy is intact.

But if it was the other way around, and the wrong offset you used happened to be within the size of your disk, you'd end up overwriting some random part of the drive. Not good.

Also, the magic numbers for the filesystems of course need to be in the right places.

I tested wiping and undoing it with a VFAT image, and wrote this off the top of my head before reading your version too closely:

printf "$(printf '\\x%s' 46 41 54 31 36 20 20 20)" |
  dd bs=1 conv=notrunc seek=$(printf "%d" 0x00000036) of=test.vfat

that's for the single wipefs output line (repeat for others):

test.vfat: 8 bytes were erased at offset 0x00000036 (vfat): 46 41 54 31 36 20 20 20

The nested printf at the start allows to copypaste the output from wipefs, without having to manually change 46 41 54 31... to \x46\x41\x54\x31....

Again, you do need to take care to enter the correct values in the correct offsets!

It probably wouldn't be too bad to automate that further, but what with the risk involved, I'm not too keen to post such a script publicly without significant testing.

If you can, take a copy of the disk contents before messing with it.

For convenience, the nested `printf` can also be `printf '46 41 ...' | xxd -p -r` if you have `xxd(1)` installed. — wchargin, Apr 12 '21 at 22:50

score 7 · Answer 2 · answered Apr 11 '21 at 15:26

In my question with a headline of Undoing wipefs, I chose to re-create partitions using the testdisk, it's probably best for you to avoid it as it took a measurable amount of time (not just hitting Write), before I did so, I must have carefully inspected both partitions - testdisk allowed me to read their structure, I went ahead and read a few directories - seemed Ok.

What I did not think of were the underlying file systems, because it of course did not boot now.

From a live Linux Mint I took a picture of GParted:

I will repeat that the full output of wipefs command was:

/dev/sda1: 8 bytes were erased at offset 0x00000052 (vfat): 46 41 54 33 32 20 20 20
/dev/sda1: 1 byte was erased at offset 0x00000000 (vfat): eb
/dev/sda1: 2 bytes were erased at offset 0x000001fe (vfat): 55 aa
/dev/sda2: 2 bytes were erased at offset 0x00000438 (ext4): 53 ef
/dev/sda: 8 bytes were erased at offset 0x00000200 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 8 bytes were erased at offset 0x37e4895e00 (gpt): 45 46 49 20 50 41 52 54
/dev/sda: 2 bytes were erased at offset 0x000001fe (PMBR): 55 aa

To undo what has been erased, I did:

First, my Ext4 partition:

echo -en '\x53\xef' | dd of=/dev/sda2 bs=1 conv=notrunc seek=$((0x00000438))
partprobe /dev/sda2

Now, mountable and can read all of the files.

Second, my EFI partition:

echo -en '\x46\x41\x54\x33\x32\x20\x20\x20' | dd of=/dev/sda1 bs=1 conv=notrunc seek=$((0x00000052))
echo -en '\xeb' | dd of=/dev/sda1 bs=1 conv=notrunc seek=$((0x00000000))
echo -en '\x55\xaa' | dd of=/dev/sda1 bs=1 conv=notrunc seek=$((0x000001fe))
partprobe /dev/sda1

I rebooted, and SSH'ed into my server without any problem now.

score 3 · Answer 3 · answered Apr 11 '21 at 12:39

Can I / Should I just hit Write (Write partition structure to disk)?

Only and only if all the partitions are listed.

Partition table recovery

If all partitions are listed and only in this case, confirm at Write with Enter, y and OK.

Now, the partitions are registered in the partition table.

Undoing wipefs --all --force /dev/sda? /dev/sda

Possibly alternative solution

3 Answers3