"dd" command

N

Niatross

I thought the dd command wiped out all data on a device.

I type the following command:

Code: 
dd if=/dev/zero of=/dev/da0 count=32

...and then I type fdisk da0 and receive the following information:

Code: 
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
     start 63, size 31294557 (15280 Meg), flag 80 (active)
          beg: cyl 0/ head 1/ sector 1;
          end: cyl 923/ head 254/ sector 63
The data for partition 2 is:
<UNUSED>
The data for partition 3 is:
<UNUSED>
The data for partition 4 is:
<UNUSED>

Why does it show an MBR partition in the partition 1 slot?

All 4 MBR partions should say "UNUSED" when I use the dd command to wipe the da0 device. Correct?
 
Niatross said:
I thought the dd command wiped out all data on a device.
Click to expand...

If told to, yes, it can.

I type the following command:

Code: 
dd if=/dev/zero of=/dev/da0 count=32
Click to expand...

That only erases the first 32 blocks. But think about the way that MBR slices and FreeBSD bsdlabel(8) information is stored on the disk.

The MBR slice table is at the start of the disk, describing up to four slices. Erasing the first block wipes that out, along with the bootcode.

FreeBSD partitions are defined inside the slices, not in the MBR. So no, dd(1) does not necessarily erase everything.

Stop using dd(1) for this. Instead, use gpart(8). It correctly removes many types of disk partitioning. Remember that on a disk with partitions inside a slice, those must be destroyed first:
gpart destroy -F da0s1

Then destroy the MBR:
gpart destroy -F da0

If you skip the first step and then create a new MBR, the FreeBSD partitions in the first slice will reappear because that data is still on the disk.
 
What's weird is that I have run the following dd coomand all the way across the device and it still doesn't remove the MBR partition 1:

Code: 
dd if=/dev/zero of=/dev/da0 bs=64k

I'm going to try the gpart commands you mentioned, but shouldn't the command (above) wipe out everything on a device (BSD and MBR partitions)?
 
When no count is given, dd(1) runs until the device is full. And yes, that should erase everything. GEOM will re-taste the partitioning after a write, but it can be forced:
true > /dev/da0 (and maybe also with da0s1)

If the MBR is still there, something else is going on. What version of FreeBSD is being used? Is some type of "boot block virus protection" enabled in the BIOS? Is da0 an external USB drive?
 
When I look at the output from fdisk, I note that the second line it prints says:
Code: 
parameters extracted from in-core disklabel are:
That seems to tell me that fdisk is displaying information that is cached by the kernel, and doesn't know that you just wiped out the partition table, etc unless you were to detach the drive from the system and reattach it (and the kernel would then re-read the partition information).
 
OK guys, this is what's going on...

I'm finding that fdisk da0 says that an MBR partition (partition 1) still resides on the device and gpart show says there are no partitions residing on the device.

Very interesting.

gpart displays the correct information and fdisk bombs.

I pulled this device out (which is a USB drive) and reinserted it but fdisk da0 still reports incorrect information. It still thinks there is an MBR (partiton 1) on it. I rebooted the system and fdisk da0 still reports false information that there is a MBR (partiton 1) on it.

I am using FreeBSD 9.0-RELEASE. I need to upgrade I know, but this is interesting. Any other ideas of how to get fdisk da0 to report correct information?

How come gpart show displays the device correctly?
 
Well, using an (external) USB drive is a totally different ballgame. Because you're not accessing it directly but through umass(4) (iirc) which basically means that a lot of operations respond differently.

In this case you might benefit from using camcontrol, but I somewhat doubt it. For example # camcontrol rescan all should force the system to re-examine your disk(s) after which fdisk it might pick up the correct data.

There's quite a bit more which you can do using camcontrol but do be careful with that critter
 
I tried camcontrol rescan all, but the same problem still persists.

Have any of you guys tried this scenario?

Insert a USB device, install FreeBSD on it. Try to delete all MBR and FreeBSD partitions with the dd or gpart commands and then run fdisk da0 and see if you still see an MBR partition (AKA: partition 1).
 
fdisk(8) apparently supplies a default MBR when it can't find one. To see what is really on the disk: dd if=/dev/da0 bs=512 count=1 | hd | less.

Again, please stop using fdisk(8)*. Also stop using MBR unless the computer has a broken BIOS that does not work with GPT.

*: There is one reason to use fdisk(8), and it involves creating 4K-aligned slices and only matters on 4K disks and SSDs where MBR/bsdlabel(8) partitioning is still needed.
 
wblock@ said:
fdisk(8) apparently supplies a default MBR when it can't find one. To see what is really on the disk: dd if=/dev/da0 bs=512 count=1 | hd | less.
Click to expand...

Thank you for the command (above). At least it tells you the following when there is no MBR partitions on a device:

Code: 
1+0 records in
1+0 records out
512 bytes transferred in 0.000822 secs (622820 bytes/sec)
00000000  00  00  00  00  00  00  00  00    00  00  00  00  00  00  00  00 |................|
*
00000200

PS: I'll start using GPT partitions with gpart. Thanks again for answering my questions.
 
You must log in or register to reply here.
Back
Top