How to restore FreeBSD boot manager on GPT disk ?

[Ian Smith]

On Tue, 8 Nov 2016 07:46:00 -0700, Warren Block wrote:
 > On Tue, 8 Nov 2016, Ian Smith wrote:
 > > In freebsd-questions Digest, Vol 649, Issue 3, Message: 3
 > > On Tue, 8 Nov 2016 10:49:23 +0000 Manish Jain <bourne.identity at hotmail.com>
 > > wrote:
 > > 
 > > > One thing I have loved about FreeBSD over the years is the superbly
 > > > designed Boot Easy boot manager. If any other OS overwrites the MBR, it
 > > > is straightforward to restore with 'boot0cfg -B /dev/ada0'
 > > >
 > > > That command only works on MBR disks though, as far as I know. Is there
 > > > any equivalent command on a GPT disk ?
 > > 
 > > Sadly, no.  Noone has written a GPT equivalent of boot0cfg; perhaps it's
 > > too hard, or developers perceive no use for multi-booting; I don't know.
 > > 
 > > Often people will suggest using the GPL'd GRUB; I suppose that works ok
 > > with GPT disks these days.  You could research rather more complicated
 > > Boot Environments, about which I know nothing, but I don't think these
 > > enable a choice between e.g. BSD/s|Linux/s|Window/s systems as boot0cfg
 > > does.  [ Corrections to any misperceptions are welcome! ]
 > > 
 > > Jack L. offered:
 > >  gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 ada0
 > > 
 > > which restores the PMBR and GPT bootblocks to ada0p1, but that's not
 > > (yet?) able to provide or restore multi-boot options as such.
 > > 
 > > Are you forced to use GPT, because of UEFI-only motherboards?
 > 
 > If the machine is booting in BIOS from a GPT disk, it *should* work to put
 > boot0 on there, replacing the PMBR.  I think, anyway, have not tested it.

Hmm, I can't see how that might work.  From an admitedly quick browse 
through recent head usr/src/sys/ ..

   % less boot/i386/boot0/boot0.S boot/i386/pmbr/pmbr.s

.. it's one or the other; boot0.S only knows about MBR slices, and 
pmbr.s starts looking at (the next) LBA 1 for a GPT, or at the last LBA 
for a backup GPT if not found, thence for bootable GPT partition/s.

While boot0cfg will preserve the existing MBR table, that's only 64 
bytes of sector 0, the rest being code to select and load the next 
stage via BIOS.  boot0 especially is very tight and tricky asm code.

>From my quick scan just now, I don't think the pmbr.s code even looks at 
its MBR table.  I don't have a GPT system; maybe you could show results 
from (assuming a BIOS-booting) one, of:

   % boot0cfg -v $disk

and I know you'll just hate this :) but for the BIOS view, what says:

   % fdisk -s $disk

cheers, Ian