Writing /dev/zero to a drive with DD still leaves data?
Linux - NewbieThis Linux forum is for members that are new to Linux.
Just starting out and have a question?
If it is not in the man pages or the how-to's this is the place!
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Writing /dev/zero to a drive with DD still leaves data?
I'm new to everything linux & everything HDD related, and, I've been messing around with a few commands. I wiped a disk with dd because I wanted to try it using:-
Code:
dd if=/dev/zero of=/dev/sdc
where SDC is a drive I didn't really care about, after awhile it gave me "Drive out of space", which, sounds like a good thing (Copied zeros until disk was full), however, around an hour later I was messing around with hdparm and the --read-sector command, I noticed that at the top of every sector it had the exact same start:-
The drive shouldn't of had anything written to it since the wipe (Not really touched it, unless my distro (Left side of my post, apparently my user-agent gave it away)/some software did it automatically), so, can I ask what the sector data means?
Contrary to the above, you actually did wipe out the MBR/partition table. Some of the tools might object as they can't find the disk signature - try a few and see.
The actual requirements for the hardware/microcode I have no knowledge of - but as stated above you wiped all the user accessible data.
Contrary to the above, you actually did wipe out the MBR/partition table. Some of the tools might object as they can't find the disk signature - try a few and see.
The actual requirements for the hardware/microcode I have no knowledge of - but as stated above you wiped all the user accessible data.
I was wondering that due to the last line of fdisk:-
Code:
Disk /dev/sdc doesn't contain a valid partition table
And, in fact, I assume that the sector headers (After reading wikipedia) are impossible to write to and are generated by the disk's controller? Also contain no personal information? Just parity (Which will result in 0x0) & sector information (Like location).
I was wondering that due to the last line of fdisk:-
Code:
Disk /dev/sdc doesn't contain a valid partition table
And, in fact, I assume that the sector headers (After reading wikipedia) are impossible to write to and are generated by the disk's controller? Also contain no personal information? Just parity (Which will result in 0x0) & sector information (Like location).
I'm not sure which page on Wikipedia you've been reading.
Your disk drive will contain an Intel partition table. The partition table is created and wrote to the hard disk, with a partition program like linux fdisk, cfdisk or sfdisk.
Something is very wrong. The sector headers are entirely internal to the drive. You can neither write nor read them. The output from "hdparm --read-sector" (I see that it does show exactly 512 bytes) should have been all-zeros.
Is this drive connected via USB? It might be that the USB<>SATA interface chip does not properly handle the low-level read commands from hdparm. What do you see when you run "dd if=/dev/sdc count=10 | hexdump" ?
I've seen weird things happen on a system where /dev/null got replaced by an ordinary file. Does "ls -l /dev/zero" show a character-special device with major and minor device numbers "1, 5"?
Something is very wrong. The sector headers are entirely internal to the drive. You can neither write nor read them. The output from "hdparm --read-sector" (I see that it does show exactly 512 bytes) should have been all-zeros.
Is this drive connected via USB? It might be that the USB<>SATA interface chip does not properly handle the low-level read commands from hdparm. What do you see when you run "dd if=/dev/sdc count=10 | hexdump" ?
I've seen weird things happen on a system where /dev/null got replaced by an ordinary file. Does "ls -l /dev/zero" show a character-special device with major and minor device numbers "1, 5"?
What do you see when you run "dd if=/dev/zero count=1 | hexdump" ?
Yes, it is connected via a USB socket, it's a 4GB flash drive (Yeah, I know, don't waste precious flash write data, etc, etc, don't defragment them, etc, etc, etc) that I happened to have laying around with no important data on it, considering you got it first try I assume that means it's a pretty common issue with flash drives.
Running DD & hexdump results in (had to re-zero the drive (with count=20, just to be sure it's greater than count=10), I had done other stuff with it since):-
Code:
automatic@automatic-G74Sx:~$ sudo dd if=/dev/sdc count=10 | hexdump
0000000 0000 0000 0000 0000 0000 0000 0000 0000
*
10+0 records in
10+0 records out
5120 bytes (5.1 kB) copied, 0.0070375 s, 728 kB/s
0001400
automatic@automatic-G74Sx:~$
And running the ls command does result in 1, 5, although, I presume where you said "System where /dev/null got replaced" you mean /dev/zero, if not, fill me in?
Only thing however is that the hexdump seems extremely small (512*10=5,120, quite a few bytes compared to what it returned), I'm not really sure as to why it's only one line.
hexdump suppresses consecutive identical lines and just shows an asterisk. Your output shows that the 5120 bytes were indeed all zeros. So, there is no problem with /dev/zero, and your drive has indeed been zeroed, but the drive is not properly handling the low-level read command from hdparm.
No, I did mean "/dev/null". It was an example of something that can go wrong, and there was an off chance that something similar might have happened to /dev/zero, though I would expect dire results for the rest of your system if that were indeed the case.
Incidentally, that non-zero data represents a string of ASCII characters:
hexdump suppresses consecutive identical lines and just shows an asterisk. Your output shows that the 5120 bytes were indeed all zeros. So, there is no problem with /dev/zero, and your drive has indeed been zeroed, but the drive is not properly handling the low-level read command from hdparm.
No, I did mean "/dev/null". It was an example of something that can go wrong, and there was an off chance that something similar might have happened to /dev/zero, though I would expect dire results for the rest of your system if that were indeed the case.
Incidentally, that non-zero data represents a string of ASCII characters:
So I suggest you've re-added some formatting somehow after wiping the disk
or wiping got interrupted unfinished
or you're looking somewhere different from what was wiped
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
