Date: Mon, 22 Jun 2015 12:41:48 +1000 From: Paul Koch <paul.koch@akips.com> To: freebsd-stable@freebsd.org Subject: gptboot: unable to read backup GPT header - virtualbox guest with SAS controller Message-ID: <20150622124148.6aafd502@akips.com>
next in thread | raw e-mail | index | archive | help
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@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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150622124148.6aafd502>