In message <[EMAIL PROTECTED]>, [EMAIL PROTECTED] writes: >/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. Ian To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-questions" in the body of the message