Date: Fri, 10 Jul 2009 12:03:18 -0700 From: Jeff Kletsky <jeff+freebsd@wagsky.com> To: freebsd-geom@freebsd.org Subject: Re: 7.x and 8.0 gpt and gpart GPT PMBR prevents Intel boot Message-ID: <4A579076.5070008@wagsky.com> In-Reply-To: <4A578E3F.8050305@wagsky.com> References: <h34lml$6fv$1@ger.gmane.org> <4A578E3F.8050305@wagsky.com>
next in thread | previous in thread | raw e-mail | index | archive | help
It appears to me that the PMBR being used both by gpt and gpart is causing boot problems with current Intel hardware. There appear to be two issues that can cause difficulties: * The "start" of the PMBR is 0xffffff * The PMBR is not marked "bootable" by gpt or gpart In particular, it has been confirmed that it is not possible to format a GPT drive that will boot on an Intel D945GCLF2 with current BIOS (and may be the causes for the observed "freezes" at boot). Both these issues have been previously documented: <http://www.freebsd.org/cgi/query-pr.cgi?pr=115406>; <http://www.freebsd.org/cgi/query-pr.cgi?pr=133493>; These two PMBR excerpts illustrate the changes required: This is the "stock" PMBR generated by gpart for a 500 GB SATA drive. It does *not* allow the BIOS to boot.(FreeBSD 7.2-RELEASE-p2) 000001b0: 9090 9090 9090 9090 0000 0000 0000 00ff ................ 000001c0: ffff eeff ffff 0100 0000 2e60 383a 0000 ...........`8:.. 000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U. This is a hand-modified version of the PMBR installed on the same drive that does permit the BIOS to boot. 000001b0: 9090 9090 9090 9090 0000 0000 0000 8001 ................ 000001c0: 0100 eeff ffff 0100 0000 2e60 383a 0000 ...........`8:.. 000001d0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001e0: 0000 0000 0000 0000 0000 0000 0000 0000 ................ 000001f0: 0000 0000 0000 0000 0000 0000 0000 55aa ..............U. Note that the "bootable" flag has been set (0x80) and the start of the partition has been set to the beginning of the disk (0x010100). Without the 0x80 flag also set, the D945GCLF2 BIOS does not identify any bootable drives. The Intel specification for EFI boot <http://www.intel.com/technology/efi/efiagree.htm>; <http://download.intel.com/technology/efi/docs/EFI_110.zip>; does indicate (pp 374-375) that 0xffffff is to be used when the start of the partition can't be represented using CHS notation. However, this PMBR refers to the entire disk, arguably to prevent legacy systems from overwriting it (Protective Master Boot Record), but apparently also "reputable" BIOS manufacturers are producing current systems that key off the information as well. The PR indicates patches for the CHS issue for gpt. For gpart, the code is in /usr/src/sys/geom/part/g_part_gpt.c and, I believe, should be modified to read le16enc(table->mbr + DOSMAGICOFFSET, DOSMAGIC); table->mbr[DOSPARTOFF + 1] = 0x01; /* shd */ table->mbr[DOSPARTOFF + 2] = 0x01; /* ssect */ table->mbr[DOSPARTOFF + 3] = 0x00; /* scyl */ table->mbr[DOSPARTOFF + 4] = 0xee; /* typ */ table->mbr[DOSPARTOFF + 5] = 0xff; /* ehd */ table->mbr[DOSPARTOFF + 6] = 0xff; /* esect */ table->mbr[DOSPARTOFF + 7] = 0xff; /* ecyl */ le32enc(table->mbr + DOSPARTOFF + 8, 1); /* start */ le32enc(table->mbr + DOSPARTOFF + 12, MIN(last, 0xffffffffLL)); which will make it consistent with MBR content for the first partition on Windows machines (protecting GPT drives from inadvertent modification on non-GPT-aware platforms), as well as the patch suggested in PR 115406. (Code still unmodified in HEAD v1.16) As to marking the partition bootable, there is a question of where the most appropriate place might be and if a flag to override should be made available. In my opinion, it should be so marked when a GPT boot segment is added to the drive as well as when either drive-level or partition-level boot code is written, with a command-line option to not change the "bootable" flag in the PMBR for these conditions. In my opinion, these issues should be considered for inclusion in the 8.0-RELEASE -- at the very least, the 0xffffff issue, as it cannot easily be resolved from the command line. Thanks, Jeff
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4A579076.5070008>