Partitioning schemes

[Mod: Split off from an 8 year old thread, https://forums.freebsd.org/threads/dd-command.45206/]

Is there a concise answer to this?

I also expect that it deletes the MBR?

I have the pata disk attached with a IDE to USB converter. Perhaps that is the reason?

EDIT: or perhaps /dev/da0 is not the way to address the whole disk, not as /dev/rsd0c in OpenBSD. But how then the way?
 
Last edited by a moderator:
Yes, /dev/da0 is the correct way to address the whole disk.

No, writing zeroes with dd to the beginning of the disk is not a good way to remove partition tables / slide headers / GPT labels. For several reasons, some of which are explained above: The kernel caches partition tables in memory, and overwriting the disk with dd does not always flush those caches. On an unformatted disk, slices may exist by default. And disks store two copies of the GPT label, the second one at the very end. And sometimes BIOSes have the nasty (good?) habit of updating "lost" copies of GPT labels from the second copy.

Concise answer: Use gpart not dd.
 
Thanks. In any case, I wanted to see that dd does what it is expected. I just
discovered that it does it and that fdisk do not show what is expected: after
filling with zeroes it shows a BSD first slice instead of an unused one.

The problem seems to be what fdisk shows. Not dd.
 
To begin with, fdisk is obsolete. I don't understand enough about BIOS booting to know any scenario where it would still be used, but perhaps there are legacy systems where it is still needed. As far as I know, on hardware that is less than 10-15 years old, you can (and shall) always use gpart.

And fdisk is intended to be used interactively, by a person who understands the difference between slice and partition. Not surprising that on a disk that has all zeroes on sector zero, fdisk tries to do something "reasonable", since the assumption is that the user will check the results before saving. I think of tools like fdisk a lot like a surgical knife: The user knows that you don't just stick it in and expect something good to happen. They are powerful, but can have very nasty side effects.
 
fdisk is very confusing in this regard. Look at this output:
Code:
# hd /dev/md1
00000000  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|
*
40000000
# fdisk /dev/md1
******* Working on device /dev/md1 *******
parameters extracted from in-core disklabel are:
cylinders=130 heads=255 sectors/track=63 (16065 blks/cyl)

parameters to be used for BIOS calculations are:
cylinders=130 heads=255 sectors/track=63 (16065 blks/cyl)

fdisk: invalid fdisk partition table found   ;  <--- but pay attention to this
Media sector size is 512
Warning: BIOS sector numbering starts with sector 1
Information from DOS bootblock is:
The data for partition 1 is:
sysid 165 (0xa5),(FreeBSD/NetBSD/386BSD)
    start 63, size 2088387 (1019 Meg), flag 80 (active)
    beg: cyl 0/ head 1/ sector 1;
    end: cyl 129/ 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>
#
md1 is a dummy device, all empty and yet fdisk shows you output as if there was a partition. It shows you how the partition could be.

MBR bootcode, i.e. code on LBA 0 in MBR disk scheme, does contain definition of 4 partitions. If you wipe this out (in my example dd if=/dev/zero of=/dev/md1 count=1) you'd lose definitions of the partitions. But that's it. This command would not erase slice metadata as those are stored deeper in the disk. With MBR scheme if you don't use enough of count to get to the slice metadata it will be still there.

It does make sense to use tools that are designed to work with the given task (such as gpart nowadays) but dd is for sure handy tool for this too. But you need to know what you're aiming for with dd.
 
And fdisk is intended to be used interactively, by a person who understands the difference between slice and partition.
And what about installing the filesystem directly, without slice partition or BSD label?
No need to use fdisk and/or disklabel!

And are these efi, uefi, gpt, etc. easier to understand?
 
You can create FS directly on raw device but you won't be able to boot off it.
I'd stay away from MBR layout in FreeBSD when you can use GPT scheme. It's easier, less messy and it has backup of its metadata. But even with MBR you don't need to use fdisk. You have gpart and bsdlabel for that.
 
And what about installing the filesystem directly, without slice partition or BSD label?
No need to use fdisk and/or disklabel!
Absolutely possible. Used to do it all the time. Stopped, because it confuses people and things. Today, both humans (sys admins) and firmware (like BIOSes) expect to see a GPT table on every disk. Examples include a human sys admin seeing a disk without a clear purpose (they just looked for the partition table), thinking that it must be unused, and therefore formatting a ReiserFS onto it. That happened so often, it turned into a running joke (about Hans Reiser killing both wives and disks). Also saw a BIOS that if it found the beginning of the disk to be corrupted (not a valid GPT partition table) would kindly overwrite it with whatever it found at the end of the disk ... even if the beginning of the disk was actually in use. So these days I put valid GPTs on every disk (except small USB sticks).

And are these efi, uefi, gpt, etc. easier to understand?
You are right, the whole area of how to boot and how to store partition information on disks is too complex. People need to be careful around it.
 
I'd stay away from MBR layout in FreeBSD when you can use GPT scheme. It's easier, less messy and it has backup of its metadata.
Do you mean the GPT scheme is easier, or gpart is easier to use than fdisk?
I wonder, because GPT includes a "protective MBR".
 
GPT is easier to use. You're just creating partitions, there are no slices that are being partitioned (MBR case under FreeBSD). gpart command is to be used instead of fdisk nowadays. You still have an option to legacy boot (I prefer this way) or you do the UEFI boot.

"protective MBR" feature of GPT scheme is just to protect itself from tools that don't understand the GPT scheme (i.e. old tools created before GPT existed). It's a dummy MBR with one partition defined. The only thing checked there is the boot signature, nothing else.

Side note: MBR is used both for describing MBR disk layout and bootcode on LBA0 of MBR scheme.
 
GPT is easier to use. You're just creating partitions, there are no slices that are being partitioned (MBR case under FreeBSD).
An what about putting a BSD disklabel without MBR in the raw disk?

But yes, I would put a trivial MBR and a trivial BSD disklabel to protect the disk from careless firmware, software and humans, as ralfphsz wrote. To put a GPT is too much for that purpose.
 
Note that the maximum size of a MBR partition (in BSD parlance a 'slice') is 2TB. Really, just stop using that antique partitioning scheme. GPT is so much easier.
 
Also saw a BIOS that if it found the beginning of the disk to be corrupted (not a valid GPT partition table) would kindly overwrite it with whatever it found at the end of the disk ... even if the beginning of the disk was actually in use. So these days I put valid GPTs on every disk (except small USB sticks).
I hope that stupid BIOS would respect a classical MBR.
 
I hope that stupid BIOS would respect a classical MBR.
BIOS isn't going to care. BIOS loads the first sector of the disk in memory and passes execution to it. That's it. That's all the BIOS has to do. Some UEFI implementation on the other hand will insist on EFI booting and cannot be configured to CSM boot.
 
Note that the maximum size of a MBR partition (in BSD parlance a 'slice') is 2TB. Really, just stop using that antique partitioning scheme. GPT is so much easier.
Is that also the case with BSD disklabels?
In any case, my biggest disks have "only" 500GB.
 
Is that also the case with BSD disklabels?
Code:
COMPATIBILITY
     Due to the use of an uint32_t to store the number of sectors, BSD labels
     are restricted to a maximum of 2^32-1 sectors.  This usually means 2TB of
     disk space.  Larger disks should be partitioned using another method such
     as gpart(8).
bsdlabel(8)
 
I was about to write what SirDice wrote -- BIOS really doesn't care.

Note though OP in 2014 asked about dd here. What he did was OK - it wiped about the MBR as expected. fdisk is showing confusing data, layout that is really not there (but shows numbers how that partition can be created).
 
BIOS isn't going to care. BIOS loads the first sector of the disk in memory and passes execution to it. That's it.
I was refering to the ocasional smart BIOS mentioned by ralphbsz that kindly overwrites the first sector with what it finds at the end of the disk.
 
Really, just stop using that antique partitioning scheme.
I still use antique hardware and antique OS. And move disks from one computer to other.

I hope, this EFI, UEFI or what the BIOS substitute is called be backward compatible and able to read MBR.
 
I hope, this new partitioning schemes are "backward compatible" and are able to read MBR.
A BIOS isn't going to care if it's GPT or MBR. As I said, the BIOS just reads sector 0 in memory and passes control to the code there. What happens next is going to depend on that code. Even really old hardware is able to read sector 0 and execute the code, BIOS only has to detect the drive and be able to read that first sector.

The PMBR of GPT has, besides a 'fake' MBR partition, code to find and execute the code that's in the freebsd-boot partition. But that's the PMBR code's job, not the BIOS. I have a whole bunch of old equipment and have been using GPT since it was added to FreeBSD, never had an issue with it.
 
Does UEFI also load and run this code, like BIOS?
In CSM mode, yes. EFI boot works a little different, that specifically searches for an efi partition (the ESP). Both MBR and GPT partitioning schemes are supported but I would highly recommend using GPT for EFI boot.
 
Systems without UEFI support are booting the (now) "legacy" way, i.e. find the lba0 on a bootable device and let the bootcode deal with the rest.
Newer BIOSes have new way of booting - UEFI boot, some of them provide legacy boot (or CSM as SirDice said). Now talking about FreeBSD you have these options:

1) Old BIOS - only legacy boot - support for both MBR and GPT scheme
2) New BIOS - EFI and/or legacy boot
MBR scheme - legacy boot possible
GPT scheme - both legacy and UEFI boot possible

In case of 2) and GPT you can set the disk so FreeBSD is capable of booting both legacy and UEFI. If you want to boot UEFI only pmbr doesn't need to have any bootcode, it can be all 0s (with one big partition defined in the partition definition). Only boot signature at the end of the sector is required (per UEFI standard). UEFI is looking for ESP and does all the booting from there.
 
Back
Top