>/boot/boot0 has the FreeBSD bootloader.  The installer also offers
>to use the "standard" /boot/mbr.

>Roughly speaking.  /boot/boot2 is 15 sectors; I suppose the first
>(all zeros) is replaced with the disklabel, loosely speaking.

>One such as would be created by "disklabel -B".  (/boot/boot1 seems to
>have the fourth slice pre-defined.)  This differs from "B" only in the
>slice table, right?  The "disklabel" manpage implies that this is a DD.

Exactly. Thanks for filling in the details I missed. The other magic
thing about the bogus 50000-sector slice is that the kernel detects
this special case and then completely ignores the slice table and
makes the compatibility slice cover the whole disk (I'm not 100%
sure of the details here).

>It seems that a DD disk is one which is similar to a single slice
>starting at sector 0, regardless of what the slice table part of sector
>0 contains.  With FreeBSD-standard boot code and some BIOSes, one disk
>layout (ie, DD or sliced) will work better than the other.  (And for DD
>disks, some slice table contents might work better than others.  I've
>not read anything comparing your "B" and "C" or either with a slice
>table full of zeros or random bits.)

I think to avoid warnings or errors, you need either a valid slice
entry (even if it is a sysinstall-style slice that starts at sector
0 and contains the whole disk), or else the exact special bogus
slice table, since the kernel code just does a bcmp() to check for
the special bogus table.

As to the issue of BIOSes disliking DD modes, there have been a few
different reasons suggested. For traditional BIOSes that just look
for the 0x55 0xaa signature and if found then execute the MBR code,
all of the various DD and non-DD schemes should work fine. However,
some BIOSes perform additional tests that may fail on DD disks. For
example (I'm just guessing here), they might check that the slice
starts after the MBR, or that the slice starts and ends on a cylinder
boundary. It sounds a silly thing to do, but I guess maybe it allows
the BIOS to automatically figure out what geometry the OS is
expecting or something.

The fact that boot1 always contains the bogus slice table even when
boot1 is not used as an MBR has been linked to other BIOS problems
too - some BIOSes apparently go further and check if the first
sector of each slice looks like it has an extended partition table
even if the slice type is not that of an extended partition. In
-CURRENT, the default bogus slice table was changed slightly to
stop some BIOSes crashing with a divide-by-zero error when they
tried to parse the bogus slice entry in boot1.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message

Reply via email to