Paul Koch
2015-Jun-22 02:41 UTC
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
Warren Block
2015-Jun-22 14:28 UTC
gptboot: unable to read backup GPT header - virtualbox guest with SAS controller
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.