9th Aug 2012

-------------------------------------------------------------------------------

PROBLEM DESCRIPTION:

- Install Win 7 64bit on UEFI system using GPT, which creates 100MB FAT32 EFI
  system partition, 128MB MS recovery partition and requested size NTFS Windows
  install partition.

- Boot Win 7 and use disk manager utility to create a raw partition for FreeBSD
  after the Win 7 install partition. Use Win 7 command line diskpart tool to set
  partition to GUID type of freebsd-zfs. Confirm Win 7 still boots (it does).

- Boot FreeBSD 9.1 installer CD and use live filesystem to run gpart to change
  the GPT partition type for the FreeBSD partition to freebsd-zfs i.e. should be
  a NOP.

- Reboot system and Win 7 EFI bootloader will no longer boot Win 7 (it's not
  clear what happens as no diagnostics are output, but I think the Win 7 EFI
  bootloader runs and bails immediately).

-------------------------------------------------------------------------------

PROBLEM ANALYSIS:

gpt_pre_gpart.dmp is a dd of the first 34 blocks from the disk when Win 7 was
the only tool to have touched the GPT and was booting Win 7 fine.

gpt_post_gpart.dmp is a dd of the first 34 blocks from the disk immediately
after the following command was run from the FreeBSD 9.1 installer CD's live
filesystem "gpart modify -i 5 -t freebsd-zfs raid/r0". The partition type of
r0p5 was already set to freebsd-zfs (I used Win 7's diskpart tool to manually set
it).

A reboot immediately after running the gpart command shows that Win 7 EFI loader
no longer boots Win 7.

View one of the binary files in Vim as hex:

vim -b gpt_pre_gpart.dmp

Then run :%!xxd in Vim as a command to switch to hex view.



To binary edit in Vim:

vim -b mbr.dmp
Run :%!xxd as Vim command to switch to hex view
Edit hex
Run :%!xxd -r as Vim command to switch back to binary view
Run :wq to write the changed binary back out to the file



Use Vim to compare what changed between the two:

xxd gpt_pre_gpart.dmp > gpt_pre_gpart.txt
xxd gpt_post_gpart.dmp > gpt_post_gpart.txt
vim -d gpt_pre_gpart.txt gpt_post_gpart.txt



After consulting the MBR and GUID_Partition_Table articles on wikipedia:

LBA 0 i.e. the "protective" MBR spans the first 512 bytes, which is up to 0x200. The
Vim diff output shows the only bytes which changed are between 0x1b0 and 0x1d0
which are in LBA 0 i.e. the "protective" MBR.

The MBR partition table begins at 0x1be. The 0x00 -> 0x80 change at 0x1be has
set the bootable/active flag for the first (and only) partition in the MBR
partition table.

The remaining 3 bytes which changed are part of the 4 byte "Number of sectors in
partition" field of the partition table entry. gpart has updated the value from
0xffffffff (as written by Win 7) to 0xff577074.



If I dump just the MBR (dd if=/dev/raid/r0 of=/tmp/mbr.dmp count=1), binary edit
with Vim and change the 0x80 back to 0x00 at offset 0x1be, write the updated MBR
back to the disk and reboot, Win 7 boots up fine again.

-------------------------------------------------------------------------------

QUESTIONS:

- Should gpart be writing 0x80 (active) in the protective MBR entry?

  - Why is Windows EFI bootloader so sensitive to 0x80 in pmbr?

- Should gpart be silently rewriting the protective MBR entry at all when only
  asked to make changes to the GPT?

-------------------------------------------------------------------------------

MACHINE DETAILS:

HP Compaq 8200 Elite i5-2400 Microtower running latest UEFI BIOS version 2.21
Disks are 2 x 1TB in RAID-1 using onboard Intel software-assisted RAID.