Some notes on RootOnZFS article in wiki

[Dag-Erling Smørgrav]

"James R. Van Artsdalen" <james-freebsd-current at jrv.org> writes:
> It definitely breaks things *when booting* to depend in any way on a
> partition table since there may not be one.  By the mid 90's nearly
> every OS was putting in at least dummy partition tables for the same
> reason GPT does - to lessen the risk of accidental clobbering of the
> disk - but that's just a convention.  I'm sure there are still a few
> customized VAR-things out there that don't bother with a partition table.

I can assure you that Windows does not put in a dummy partition table,
and will not boot if the partition is not active.

I can also assure you that the BIOS on my current laptop (ThinkPad T60)
*does* care about the partition table, because the BIOS boot menu has an
option to launch the rescue & recovery utility, which is located on a
DOS partition at the end of the disk (although the BIOS works fine if
the R&R partition is missing)

> A number of vendors have taken to putting "hidden" system partitions on
> the disk with various utilities that can be run via a hotkey press
> during POST.  These schemes have to use MBR-like code from the BIOS ROM
> to boot their system partition and that pseudo-MBR must read and
> interpret the partition table to find the system partition.  But during
> system boot itself the MBR sector is read and if the last word in that
> sector is 0xAA55 then the BIOS executes the MBR code blind as to what is
> on the disk.  It's the MBR code that's read from the disk that scans the
> partition table, if there is one.

I can't quite parse that.

The R&R partition on my T60 is not hidden in any way.

> There were attempts for a time to check for boot sector virii before
> booting but those were always so problematic that I never did that, and
> I don't the the other main BIOS teams did it either.

I've had machines that had a BIOS option to check if the boot sector had
been modified and warn the user before booting.  It worked just fine.

DES
-- 
Dag-Erling Smørgrav - des at des.no