freebsd stable - Jun 2015 - gptboot: unable to read backup GPT header - virtualbox guest with SAS controller

Hi,

We get the following error after installing 10.1-p12 in a VirtualBox guest
when setup with an emulated LSI / SAS controller and a 50G fixed sized
virtual disk:

 gptboot: error 1 lba 104857599
 gptboot: unable to read backup GPT header

Can't seem to find anyone who has this same issue.

The problem does not exist if we configure the guest with a SATA controller
and same size virtual disk.


Setup:
- 10.1-RELEASE-p12 host
- VirtualBox 4.3.28
- 10.1-RELEASE-p12 guest


Guest info after boot...

# uname -a
FreeBSD shed65.akips.com 10.1-RELEASE-p12 FreeBSD 10.1-RELEASE-p12 #0 r284334:
Sat Jun 13 05:45:13 UTC 2015 root at
shed21.akips.com:/usr/obj/usr/src/sys/GENERIC
amd64


# diskinfo -v da0
da0
        512             # sectorsize
        53687091200     # mediasize in bytes (50G)
        104857600       # mediasize in sectors
        0               # stripesize
        0               # stripeoffset
        6527            # Cylinders according to firmware.
        255             # Heads according to firmware.
        63              # Sectors according to firmware.
                        # Disk ident.


# gpart show
=>       34  104857533  da0  GPT  (50G)
         34       2014       - free -  (1.0M)
       2048       1024    1  freebsd-boot  (512K)
       3072    8388608    2  freebsd-swap  (4.0G)
    8391680       1024       - free -  (512K)
    8392704   10485760    3  freebsd-ufs  [bootme]  (5.0G)
   18878464   10485760    4  freebsd-ufs  (5.0G)
   29364224   75491328    5  freebsd-zfs  (36G)
  104855552       2015       - free -  (1.0M)

 
# gpart status
 Name  Status  Components
da0p1      OK  da0
da0p2      OK  da0
da0p3      OK  da0
da0p4      OK  da0
da0p5      OK  da0


The primary and backup GPT headers differ, which is expected we think.

Primary GPT header

# dd if=/dev/da0 bs=512 skip=1 count=1 2>/dev/null | hexdump
0000000 4645 2049 4150 5452 0000 0001 005c 0000
0000010 b85b a5f5 0000 0000 0001 0000 0000 0000
0000020 ffff 063f 0000 0000 0022 0000 0000 0000
0000030 ffde 063f 0000 0000 16e7 cafe 18d1 11e5
0000040 f697 0008 9b27 bd6a 0002 0000 0000 0000
0000050 0080 0000 0080 0000 8856 ebca 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*

Backup GPT header

# dd if=/dev/da0 bs=512 skip=104857599 count=1 2>/dev/null | hexdump
0000000 4645 2049 4150 5452 0000 0001 005c 0000
0000010 98b1 45c8 0000 0000 ffff 063f 0000 0000
0000020 0001 0000 0000 0000 0022 0000 0000 0000
0000030 ffde 063f 0000 0000 16e7 cafe 18d1 11e5
0000040 f697 0008 9b27 bd6a ffdf 063f 0000 0000
0000050 0080 0000 0080 0000 8856 ebca 0000 0000
0000060 0000 0000 0000 0000 0000 0000 0000 0000
*


MD5 of the primary and backup partition tables identical.

# dd if=/dev/da0 bs=512 skip=2 count=32 2>/dev/null | md5
8c4510e1854f3371c3241e8a4374dc2c

# dd if=/dev/da0 bs=512 skip=104857567 count=32 2>/dev/null | md5
8c4510e1854f3371c3241e8a4374dc2c


The guest boots fine, but we always get the gptboot error.

Is this just a problem with the virtualbox SAS controller emulation where
gptboot can't retrieve the backup table ?

Appears to fail in sys/boot/i386/common/drv.c in drvread().


We have another problem to do with the same setup to do with setting
bootonce flag not being updated in the backup partition table, but I'll
describe that in a separate email.

	Paul.
-- 
Paul Koch | Founder, CEO
AKIPS Network Monitor | akips.com
Brisbane, Australia

On Mon, 22 Jun 2015, Paul Koch wrote:
> We get the following error after installing 10.1-p12 in a VirtualBox guest
> when setup with an emulated LSI / SAS controller and a 50G fixed sized
> virtual disk:
>
> gptboot: error 1 lba 104857599
> gptboot: unable to read backup GPT header
>
> Can't seem to find anyone who has this same issue.
>
> The problem does not exist if we configure the guest with a SATA controller
> and same size virtual disk.
...
> The guest boots fine, but we always get the gptboot error.
>
> Is this just a problem with the virtualbox SAS controller emulation where
> gptboot can't retrieve the backup table ?
That would be my first guess: an off-by-one error preventing the last 
block from being read.  It's not clear which emulated controller was 
being used for the diskinfo output posted earlier.  If it really was an 
off-by-one bug, the block count would differ depending on the 
controller.

However, some controllers keep metadata on the drive, and report a 
reduced capacity, and that would have almost the same effect.  Seems 
like there would be a complaint by the controller firmware about the 
contents of the metadata block, but maybe not by an emulated controller. 
If controller metadata is the problem, installing FreeBSD using the 
emulated controller in place should make sure the backup GPT is in the 
correct position, rather than switching to the SCSI controller after 
installing with, say, SATA.