Gecko/20110616 Thunderbird/3.1.11
s2.utilities,comp.os.os2.beta
UTC)
comp.os.os2.misc:3428 comp.os.os2.utilities:215 comp.os.os2.beta:177
From: Jonathan de Boyne Pollard
I came across an EDD proposal the other day, for adding a new flag to
the EFI (so-called "GUID") partition table. The proposal hypothesized a
master boot record that understood EFI partition tables. It would
enable machines with PC/AT style firmwares to bootstrap operating
systems on discs partitioned with an EFI partition table. (The MBR
bootstrap code provided by people until now has always assumed an MBR
partition table, and failed when one either is not present or is merely
a so-called "protective MBR".) The hypothesized boostrap code would
scan the EFI partition table for the first entry with this attribute
set, and load and run its volume boot record just as if it were a
primary MBR partition.
The proposal didn't mention anyone having written such a bootstrap. So
I have. (-:
If you have my latest DASDPART utility, then you can install it. I've
updated the NEWMBR command in DASDPART, and added a PARTATTRIB command.
The NEWMBR command used to unconditionally write an
MBR-partitioning-aware bootstrap. It now detects the presence of an EFI
partition table, and if one is found writes an EFI-partitioning-aware
bootstrap instead. The PARTATTRIB command is a new command, which was
needed anyway, that allows one to change the attributes of a partition.
It can manage the standard EFI partition attributes defined in the EFI
specification, as well as this new proposed attribute. The INSPECT
command now prints out the attributes of a partition, too.
The new attribute goes by the label "HasVBR" in DASDPART, denoting a
partition that ... well ... has a VBR (volume boot record). I've made
PARTATTRIB and INSPECT map this attribute onto the "active" ("startable"
in IBM's terminology) flag if they find themselves facing MBR partition
tables, so setting the "HasVBR" flag has effectively the same semantics
for both MBR and EFI partition tables. The MBR-partitioning-aware
bootstrap code looks for the "HasVBR" (i.e. startable) flag on the four
boot partitions in the MBR partition table, and the
EFI-partitioning-aware bootstrap looks for the "HasVBR" (i.e. the
proposed EDD extension) flag on all of the partitions in the EFI
partition table. In both cases, the bootstrap simply loads and runs the
VBR as if it were being loaded from a primary partition. (So beware of
"hybrid MBR" configurations where the partitions were actually formatted
as secondary partitions within a container.)
Effectively, therefore, the procedures from the user point of view are
the same across both MBR and EFI partitioned discs. One installs the
MBR boostrap with NEWMBR, one looks at the partition table with INSPECT,
one changes attributes and applies the "HasVBR" flag with PARTATTRIB to
specify which partition's VBR is booted; and the commands do the
necessary machinations to map things appropriately and pick the right
bootstrap code according to what partition table scheme is actually in
use. One's system boots by the firmware loading the MBR bootstrap, the
bootstrap scanning the (appropriate) partition table for a "startable"
partition, and loading and running its VBR.
Of course, OS/2 doesn't understand the EFI partition table, so you'll
have to employ a "hybrid MBR" scheme if you want to try this with OS/2.
If, as I have, you have OS/2 in a secondary partition (from the MBR
point of view) within a container, marking that as the startable
"HasVBR" partition will not work. You'll have to put either IBM's or my
Boot Manager in between. They'll do the necessary fixups for
bootstrapping an operating system from a secondary partition (more on
which later). I have my Boot Manager (naturally!) installed in my EFI
System Partition, and I've marked the ESP with the "HasVBR" attribute.
If you have OS/2 in (from the MBR point of view) a primary partition,
however, you should be able to mark it as "HasVBR" (from the EFI point
of view) and it will be bootstrapped directly (as long as your two
partition tables are in step with each other).
The more interesting case is perhaps Windows NT 6.1, which can
understand an EFI partition table but cannot be bootstrapped from an EFI
partitioned disc on machines without EFI firmwares. My MBR bootstrap
provides the final link in the chain that should enable this. One needs
to somehow persuade Windows NT to install the non-EFI version of
Microsoft's Boot Manager. (Getting it to install on an EFI partitioned
disc requires fooling the installer into believing that the machine has
EFI firmware. But this has the consequence of Windows NT being
installed with the EFI version of Microsoft's Boot Manager.) Once one
has persuaded it, however, one should need only to simply mark the
partition as startable with PARTATTRIB x y +HasVBR and install my
bootstrap with NEWMBR x. The firmware will load and run the bootstrap;
the bootstrap will find the startable partition in the EFI partition
table and load and run its VBR; and the VBR will load and run
Microsoft's Boot Manager.
The PARTATTRIB command can also manipulate an "OnBMMenu" attribute for
partition table entries. This is the "bootable" (again, in IBM's
terminology) flag that, as the name mildly suggests, controls whether a
partition table entry is listed by IBM's and my Boot Managers. It sets
the "bootable" flag in both places that it exists in the MBR
partitioning scheme, and so should work for both IBM's old (FDISK) and
new (LVM) Boot Managers. I haven't been brave enough to unilaterally
co-opt an EFI (global) partition table entry attribute for this,
although I'm tempted to, so this flag only works for MBR partitioned
discs for now. But you can now add and remove MBR partitions to and
from the Boot Manager menus with the PARTATTRIB x y +OnBMMenu and
PARTATTRIB x y -OnBMMenu commands in DASDPART.
For completeness, I should note that I haven't implemented the whole of
the EDD proposal. The part that I don't implement involves passing an
extended data structure to the VBR, purportedly (according to the
proposal at any rate) to enable it to work with "startable" partitions
that lie above the 2TiB line. This is all well and good, except for two
things.
The first thing is that it's based upon an erroneous assumption. By
historical accident, the DS:SI register pair pointed to the selected
(primary) partition table entry when the MBR boostrap code written by
MS-DOS handed over to the selected VBR. So the EDD proposal has
extended this with new fields plonked onto the end of that structure.
Unfortunately for the proposal, what it has assumed as the de facto
standard is not standard at all. Microsoft switched to using DS:BP as
the roving pointer into the partition table as of Windows NT 6.0 in
2007. The supposed standard is merely an accidental byproduct of the
way that MBR code that was installed by MS-DOS and some early versions
of Windows NT operated, doesn't (the killer fact for a "de facto"
standard) match the way that things operate now and have operated for
the past several years, and the proposed extension has an entirely false
foundation.
The second thing is that no-one's existing VBR bootstrap actually
expects this anyway. Despite denials encouraged by Microsoft, the
actual VBR bootstrap code of most operating systems, including Windows
NT up to and including version 6, looks at the "hidden sectors" field of
the embedded BPB within the VBR and uses *that*, not whatever DS:SI
points to, as the way to determine the start offset of the boot volume.
This is why we need things like my and IBM's Boot Manager to fix things
up for secondary partitions (whose on-disc BPBs don't contain the right
values in the "hidden sectors" field).
--- Internet Rex 2.31
* Origin: virginmedia.com (1:261/20.999)
|
