Score:0

Running `sudo dd` on partition `sda4` caused unallocated space on all partitions of my hard disk

in flag

I'm using Ubuntu 20.04, after running below command on only my root partition sda4, I checked gparted via live Ubuntu and it showed unallocated space for all partitions on my hard disk (not just for sda4).

Can anyone guide me what actually happened and how I can access the other partitions now?

sudo dd if=/dev/zero of=/dev/sda4

Update: I ran the command sudo gdisk -l /dev/sda and it displayed this:

GPT fdisk (gdisk) version 1.0.4

Caution: invalid main GPT header, but valid backup; regenerating main header
from backup!

Warning: Invalid CRC on main header data; loaded backup partition table.
Warning! Main and backup partition tables differ! Use the 'c' and 'e' options
on the recovery & transformation menu to examine the two tables.

Warning! Main partition table CRC mismatch! Loaded backup partition table
instead of main partition table!

Warning! One or more CRCs don't match. You should repair the disk!
Main header: ERROR
Backup header: OK
Main partition table: ERROR
Backup partition table: OK

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

Found invalid MBR and corrupt GPT. What do you want to do? (Using the
GPT MAY permit recovery of GPT data.)
 1 - Use current GPT
 2 - Create blank GPT```
in flag
What do you mean by "fix"? The computer would have done exactly as you told it to do: write a bunch of zeroes to `/dev/sda4`, overwriting anything that might have been there (because you specified a device, not a file)
ShirinJZ avatar
in flag
@matigo you're right but I told it to do the command on only one of my partitions (SDA4) not all the hard disk !!! Now all my HDD is unallocated; by fixing I meant how I can access the other partitions.
Artur Meinild avatar
vn flag
This is unexpected. So you say it wiped your entire HDD, and not only the partition `sda4`? I wouldn't have expected this either, but maybe someone who knows the inner workings of `dd` better can explain?
ShirinJZ avatar
in flag
Yes, so do I. :)
oldfred avatar
cn flag
Was drive MBR or gpt? Does this show anything? `sudo gdisk -l /dev/sda`
ShirinJZ avatar
in flag
@oldfred I wrote the result in my question dear :)
oldfred avatar
cn flag
If you use gdisk to restore primary partition table does that fix it? repair gpt: http://www.rodsbooks.com/gdisk/repairing.html More repair info use p, v & w to write the partition table. If not correct just use q to quit. : http://askubuntu.com/questions/386752/fixing-corrupt-backup-gpt-table/386802#386802
Score:0
us flag

first of all disconnect the drive after you have wiped it to prevent any write operations and damaging the disk even more

second: create a copy of the drive and perform recovery options on the copy

third: recover your partitions/files by following https://help.ubuntu.com/community/DataRecovery

dd will never wipe the partitions you didn't tell it to, but what could have happened is you pressed enter before writing 4 and then you have added 4 right after pressing enter. in terminal it could still show up as sda4 if you were faster than your OS response. this means you have zeroed the whole /dev/sda which seems is what you have experienced

ShirinJZ avatar
in flag
How can I disconnect it and make a copy while is disconnected? :)
Jan Myszkier avatar
us flag
easiest way is to run an operating system off a USB drive and `mount` the broken drive in read-only mode to copy it to another drive, for example external usb disk (I recommend usb 3.1 drive if you have that option available because copying to it will be way faster than any previous USB). if this is a desktop computer, you can connect another drive via SATA cable which will be even better way to make a copy.
mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.