# Booting from GPT EFI vs BIOS



## rtwingfield (Jan 14, 2012)

I have read quite a lot of disturbing discusions regarding the tendency of GPT not making nice with the BIOS firmware interface, present in all older IBM PC-compatible personal computers.  Additional reading has revealed that GPT forms a part of the Extensible Firmware Interface (EFI) standard which is Intel's proposed replacement for the PC BIOS.

Various contributors including Rod Smith's article, Booting from GPT, is a very well written piece, but his comments and suggestions regarding FreeBSD are with regard to v7.2.  (There are some differences between v7+ and v8.2)

I have whipped this horse for at least four man-weeks and I simply cannot pursuade FreeBSD v8.2 configured with gpart(8), etc. to create a bootable disk partitation.  My latest attempt results with these messages and repeated in dmesg when booting from the IDE drive:

```
# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 amrd0p1
GEOM: gpt/gpboot: partition 1 does not end on a track boundary.
GEOM: gptid/13282f1e-3aa7-11e1-82ac-000c764e7bd5: partition 1 does not end on a track boundary.
bootcode written to amrd0p1
```

Note that amrd0p1 naming convention is the result of the kernel utilizing the module (device amr) supporting the AMI MegaRAID controller interfaced to the SCSI subsystem.  This is a card-based RAID controller and is configured for RAID1.

Regardless, the mirror(s) are partitioned for /(root), /var, /tmp, /usr and all can be mounted and apparently are very accessable.  The mysterious thing is that at one time, I had a configuration that would boot from the SCSI mirror; I even physically removed the IDE drive from the platform.  I thought I had a good understanding of what to do, so I decided to redo the configuration to increase the swap file size to 6GB.  (This is a fresh install.)  Unfortunately, after the partition reconfiguration, I cannot boot the system from the GPT boot partition.

I'm at a total impass.  How significant is the message, gpt/gpboot: partition 1 not ending on a track boundary?   . . .and if this is (part of) the problem, then how would one fix it?


----------



## tingo (Jan 14, 2012)

What happens if you try just a single drive, connected to a regular sata controller?


----------



## rtwingfield (Jan 14, 2012)

Re. my comment from my original post, 





> My latest attempt results with these messages and repeated in dmesg when booting from the IDE drive


 I can boot from the IDE drive.  (The box is about 10yrs. old . . .no SATA).

The hard-card RAID controller is (or should be) like a pipe.  It manages the RAID1 mirror.
I really think this is a problem between the GPT and BIOS.


----------



## wblock@ (Jan 14, 2012)

Please show the output of
`% gpart show amrd0`

The "track boundary" warning is odd.  Few things should care about tracks any more.


----------



## rtwingfield (Jan 14, 2012)

I see the same similar message if I boot not from but with a USB flash drive installed (i.e., plugged-in).  Doesn't seem to cause any problems; I can mount it as a MSDOS file-type on /dev/da0 and read and write to it; howevever, da0 will not appeare in /dev unless the flash drive is installed before booting.  I've never tried to boot from a flash drive.

I've loaded both g_part_gpt and g_part_mbr into the kernel.  Could there be a conflict there?

(_edit note_). . .and whatever I've done tweaking with gpart bootcode, the "track boundary" message is gone.

Here's the gpart show, _et al_.  (And as always, all suggestions are greatly appreciated!)

```
# gpart show -l |less
=>      63  20028897  ad2  MBR  (9.6G)
        63  20028897    1  (null)  [active]  (9.6G)

=>       34  287274941  amrd0  GPT  (137G)
         34        256      1  gpboot  [bootme]  (128K)
        290       1758         - free -  (879K)
       2048    4194304      2  gprootfs  (2.0G)
    4196352   12582912      3  gpswap  (6.0G)
   16779264  209715200      4  gpvarfs  (100G)
  226494464    4194304      5  gptmpfs  (2.0G)
  230688768   56586207      6  gpusrfs  (27G)

=>       0  20028897  ad2s1  BSD  (9.6G)
         0    837632      1  (null)  (409M)
    837632   5346036      2  (null)  (2.5G)
   6183668   1361920      4  (null)  (665M)
   7545588    733184      5  (null)  (358M)
   8278772  11750125      6  (null)  (5.6G)

=>      63  15925140  da0  MBR  (7.6G)
        63        17       - free -  (8.5K)
        80  15925168    1  (null)  [active]  (7.6G)

# ls -l gpt
total 0
crw-r-----  1 root  operator    0, 108 Jan 14 18:40 gpboot
crw-r-----  1 root  operator    0, 111 Jan 14 18:40 gprootfs
crw-r-----  1 root  operator    0, 113 Jan 14 18:40 gpswap
crw-r-----  1 root  operator    0, 119 Jan 14 18:40 gptmpfs
crw-r-----  1 root  operator    0, 122 Jan 14 18:40 gpusrfs
crw-r-----  1 root  operator    0, 116 Jan 14 18:40 gpvarfs

# ls -l ufsid
total 0
crw-r-----  1 root  operator    0, 110 Jan 14 18:40 4f0ac06d8507d405
crw-r-----  1 root  operator    0, 115 Jan 14 18:40 4f0ac07a894e70a4
crw-r-----  1 root  operator    0, 118 Jan 14 18:40 4f0ac083f08c0604
crw-r-----  1 root  operator    0, 121 Jan 14 18:40 4f0ac08a64067203
```


----------



## Nukama (Jan 16, 2012)

Are you trying to write bootcode to amrd0*p1*?
Is amrd0p1 a "freebsd-boot" type partition?
Have you tried to write it to amrd0 and not amrd0*p1*?
`# [man]gpart[/man] bootcode -b /boot/pmbr -p /boot/gptboot -i 1 amrd0`

Try to read the manpage of gpart, it would reveal some other point:

```
bootme	 When set, the gptboot stage 1 boot loader will try to boot
		 the system from this partition.  Multiple partitions might be
		 marked with the bootme attribute.  In such scenario the
		 gptboot will try all bootme partitions one by one, until the
		 next boot stage is successfully entered.
```

So apparently amrd0p1 shouldn't set to bootme, because it holds the gptboot loader. 
Try to set your root partition with bootme and remove it for the freebsd-boot partition.


----------

