Recovering a corrupted disk (not data) which is resisting being wiped

[tdeith]

I have an SSD whose partition table was corrupted while I was trying to move a dual-booted Windows into an EFI boot - I'm not positive on the how or why of the corruption. I am now booted into a live USB trying to recover the disk, which I have connected as an external via USB. My goal is ultimately to wipe the disk, including the partition table, and start this disk from scratch. I no longer care about partitions or their data.

However, I can't get anything to wipe more than 8GB of the 512GB on the disk, and there are a variety of oddities with this disk which I can't make heads or tails from, and must be related. My best guess at an overall theme to the oddities is that there is a corruption in the disk causing two specific partition headers (is that a thing?) to be read back-to-back in a loop, such that those two partitions will freeze anything trying to read the SSD's partition data.

Some interesting symptoms:

- fdisk -l, blkid, and df -h don't necessarily reach a consensus on what they're seeing regarding the drive. At the moment (now that I've ejected/inserted the drive a couple of times), blkid thinks the device is in /dev/sdd, df -h thinks the drive is in /dev/sdc, and fdisk doesn't see it. df -h is certainly right.

- None of my computers have successfully booted into BIOS (neither booting past BIOS nor entering the BIOS settings) with this drive attached. The BIOS's universally freeze while detecting hardware. This makes boot-based recovery tools (eg, DBAN) difficult so far. It is also not fixed by resets-via-CMOS-battery-ejecting.

- Once booted into Ubuntu, when the disk is inserted by USB, Nautilus sees the drive, can mount the original partitions on the drive, and can successfully read their contents. However, each partition is listed about a hundred times, each entry with a different UUID attached to the partition. (This makes sense to me if the partition table is gone and partitions are being repeated.)

- Using dd if=/dev/zero of=/dev/sdX bs=1M to try and overwrite the entire device resulted in only 8GB of 512GB being written before 'No space left on device' is returned. These 8GB correspond to the 8GB occupied by one of the two repeating partitions, no more, no less. I wish I could personally make inferences on this detail.

- GParted does not see the device, with the exception of one time: at that time, it saw 8GB of empty space, possibly written by dd above, and nothing else. Re-writing the partition table at that time had no effect.

- testdisk only sees 8GB of device, and doesn't find any partitions in scanning. (The cylindar/sector counts seem off too, but frankly I don't know enough to navigate testdisk confidently.)

I'm at a loss as to how else I can try to scrub whatever's corrupting this disk. My uneducated speculation is that there's some corruption in the disk causing seeking to go from the end to the start of the disk when looking for partitions, or something to that effect.

fdisk -l output:

[... /dev/ramX ...]

Disk /dev/loop0: 1.3 GiB, 1433468928 bytes, 2799744 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes


Disk /dev/sda: 14.9 GiB, 16018046976 bytes, 31285248 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x0e0e8e70

Device     Boot   Start     End Sectors  Size Id Type
/dev/sda1  *          0 2902111 2902112  1.4G  0 Empty
/dev/sda2       2888004 2892739    4736  2.3M ef EFI (FAT-12/16/32)

df -h output - note that /dev/sdc3 - /dev/sdc255 are repeats of the same two partitions.

Filesystem      Size  Used Avail Use% Mounted on
udev            7.8G  7.8G     0 100% /dev
tmpfs           1.6G   23M  1.6G   2% /run
/dev/sdb        1.4G  1.4G     0 100% /cdrom
/dev/loop0      1.4G  1.4G     0 100% /rofs
/cow            7.8G  262M  7.6G   4% /
tmpfs           7.8G  200K  7.8G   1% /dev/shm
tmpfs           5.0M  4.0K  5.0M   1% /run/lock
tmpfs           7.8G     0  7.8G   0% /sys/fs/cgroup
tmpfs           7.8G  192K  7.8G   1% /tmp
tmpfs           1.6G  108K  1.6G   1% /run/user/999
/dev/sdc12      7.6G  3.3G  3.9G  46% /media/ubuntu/29ca7c9f-c33a-4360-8ed6-54befae126a91
/dev/sdc16      7.6G  3.3G  3.9G  46% /media/ubuntu/29ca7c9f-c33a-4360-8ed6-54befae126a92
/dev/sdc10      7.6G  3.3G  3.9G  46% /media/ubuntu/29ca7c9f-c33a-4360-8ed6-54befae126a9
/dev/sdc22      7.6G  3.3G  3.9G  46% /media/ubuntu/29ca7c9f-c33a-4360-8ed6-54befae126a93
/dev/sdc24      7.6G  3.3G  3.9G  46% /media/ubuntu/29ca7c9f-c33a-4360-8ed6-54befae126a94
/dev/sdc26      7.6G  3.3G  3.9G  46% /media/ubuntu/29ca7c9f-c33a-4360-8ed6-54befae126a95
/dev/sdc6       7.6G  3.3G  3.9G  46% /media/ubuntu/29ca7c9f-c33a-4360-8ed6-54befae126a96
/dev/sdc13      257G  236G  8.2G  97% /media/ubuntu/7778b2a1-9bf2-4648-9fa6-6f2643d83e731
/dev/sdc11      257G  236G  8.2G  97% /media/ubuntu/7778b2a1-9bf2-4648-9fa6-6f2643d83e73
/dev/sdc15      257G  236G  8.2G  97% /media/ubuntu/7778b2a1-9bf2-4648-9fa6-6f2643d83e732
/dev/sdc21      257G  236G  8.2G  97% /media/ubuntu/7778b2a1-9bf2-4648-9fa6-6f2643d83e733
/dev/sdc8       7.6G  3.3G  3.9G  46% /media/ubuntu/29ca7c9f-c33a-4360-8ed6-54befae126a97

... etc etc for many repetitions ...

/dev/sdc192     7.6G  3.3G  3.9G  46% /media/ubuntu/29ca7c9f-c33a-4360-8ed6-54befae126a996
/dev/sdc198     7.6G  3.3G  3.9G  46% /media/ubuntu/29ca7c9f-c33a-4360-8ed6-54befae126a995
/dev/sdc200     7.6G  3.3G  3.9G  46% /media/ubuntu/29ca7c9f-c33a-4360-8ed6-54befae126a997
/dev/sdc197     257G  236G  8.2G  97% /media/ubuntu/7778b2a1-9bf2-4648-9fa6-6f2643d83e7395
/dev/sdc195     257G  236G  8.2G  97% /media/ubuntu/7778b2a1-9bf2-4648-9fa6-6f2643d83e7397
/dev/sdc199     257G  236G  8.2G  97% /media/ubuntu/7778b2a1-9bf2-4648-9fa6-6f2643d83e7396

blkid output - note that the device is actually at /dev/sdc, and is reported as being in /dev/sdd here. I have no idea why this would be the case. Also note that everything from /dev/sdd3 - /dev/sdd255 are repeats:

/dev/loop0: TYPE="squashfs"
/dev/sdd1: UUID="4598-B2D3" TYPE="vfat"
/dev/sdd2: LABEL="Lovelybunchadata" UUID="64B21538B2151062" TYPE="ntfs"
/dev/sdd5: UUID="7778b2a1-9bf2-4648-9fa6-6f2643d83e73" TYPE="ext4" PTTYPE="dos"
/dev/sdd6: UUID="29ca7c9f-c33a-4360-8ed6-54befae126a9" TYPE="ext4"
/dev/sdd7: UUID="7778b2a1-9bf2-4648-9fa6-6f2643d83e73" TYPE="ext4" PTTYPE="dos"
/dev/sdd8: UUID="29ca7c9f-c33a-4360-8ed6-54befae126a9" TYPE="ext4"
/dev/sdd9: UUID="7778b2a1-9bf2-4648-9fa6-6f2643d83e73" TYPE="ext4" PTTYPE="dos"

... UUIDs change, but nothing else...

/dev/sdd254: UUID="29ca7c9f-c33a-4360-8ed6-54befae126a9" TYPE="ext4"
/dev/sdd255: UUID="7778b2a1-9bf2-4648-9fa6-6f2643d83e73" TYPE="ext4" PTTYPE="dos"
/dev/sda1: LABEL="ESD-USB" UUID="12C5-D03F" TYPE="vfat"

Thank you to anyone who might be able to help.

[oldfred]

Lets try gdisk. If drive is sdd.
sudo gdisk -l /dev/sdd

Did you by any chance use drive as installer and use dd to copy ISO to that drive?

With logical partitions in MBR(msdos), it is a linked list from one partition to the next & last partition has no link. If links get messed up, then you get repeating loop of partitions.
sda60 error:Linked logical partition error
http://ubuntuforums.org/showthread.php?t=1880513
http://ubuntuforums.org/showthread.p...eds+partitions

[tdeith]

gdisk -l /dev/sdX output: (drive is now sdb - kernel panic caused reboot.)

ubuntu@ubuntu:~$ sudo gdisk -l /dev/sdb
GPT fdisk (gdisk) version 1.0.1

Partition table scan:
  MBR: not present
  BSD: not present
  APM: not present
  GPT: not present

Creating new GPT entries.
Disk /dev/sdb: 16313328 sectors, 7.8 GiB
Logical sector size: 512 bytes
Disk identifier (GUID): A1975D9B-7C21-4757-B170-548F69E0BF0C
Partition table holds up to 128 entries
First usable sector is 34, last usable sector is 16313294
Partitions will be aligned on 2048-sector boundaries
Total free space is 16313261 sectors (7.8 GiB)

Number  Start (sector)    End (sector)  Size       Code  Name

The drive has never been used as an installation drive, and it has also never had an install media dd'd into it.

The partition linking makes some sense. I'm investigating the links you provided. Thanks for the help so far!

[tdeith]

Another interesting tidbit is that sudo fdisk /dev/sdb does give access to the drive (note - a reboot means the drive has moved from /dev/sdc to sdb). The information it presents seems expected for the issue:

ubuntu@ubuntu:~$ sudo fdisk /dev/sdb

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0xd28a030e.

Command (m for help): p
Disk /dev/sdb: 7.8 GiB, 8352423936 bytes, 16313328 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xd28a030e

Command (m for help):

[tdeith]

Update:

Neither http://ubuntuforums.org/showthread.php?t=1880513
Nor https://ubuntuforums.org/showthread.php?t=1849060

are not quite the same issue as I'm having. The closest was ghost partitions showing up from bad MBR chaining, but in either thread, the OP had the drive show up in its entirety for fdisk, and looks as though dd could read/write from the disk in its entirety. The best I can get is a single partition's worth of drive space (not the partition itself, though) to show up in fdisk, or be read/writable by dd. Why it is that only one partition's worth of disk is showing in fdisk, but other partitions on the same disk appear under the device (using blkid or df), is still beyond me.

[oldfred]

You are looping with two UUIDs.

Go into fdisk's advanced mode and see if just a write fixes it.

You can possibly repair a MBR partition with fdisk:
sudo fdisk /dev/sda
x # enter expert mode
f # fix partition table
r # return
p # to print
v # to verify partition
if ok
w # write the changes to disk
q # quit

[tdeith]

No cigar:

ubuntu@ubuntu:~$ sudo fdisk /dev/sdb

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.

Device does not contain a recognized partition table.
Created a new DOS disklabel with disk identifier 0x28806548.

Command (m for help): x

Expert command (m for help): f
Nothing to do. Ordering is correct already.

Expert command (m for help): r

Command (m for help): p
Disk /dev/sdb: 7.8 GiB, 8352423936 bytes, 16313328 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x28806548


Command (m for help): v
Remaining 16313327 unallocated 512-byte sectors.

edit: Incidentally, after writing from fdisk, things are unchanged:

ubuntu@ubuntu:~$ sudo fdisk /dev/sdb

Welcome to fdisk (util-linux 2.27.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): p
Disk /dev/sdb: 7.8 GiB, 8352423936 bytes, 16313328 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xab54d47e

Command (m for help):

[oldfred]

It looks like you ran fdisk on sdb, but your issue was on sdc? Or did drive order change.

/dev/sdc3 - /dev/sdc255 are repeats

[tdeith]

The Drive order changed, yes. (Reboot due to kernel panic as I tried running Ubuntu's "disks" program to explore the drive.)

Sorry for that confusion.

[oldfred]

Did you do a w from fdisk to force it to update partition tables?