Re: gptboot: unable to read backup GPT header - virtualbox guest with SAS controller
On Mon, 22 Jun 2015 08:28:10 -0600 (MDT)
Warren Block wrote:
> 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.
It does look like gptboot couldn't access the last sector on the virtual SAS
disk. We were playing with expanding the size of the virtual disk...
Shutting down the VM, expanding the disk size, rebooting, and no gptboot error.
Running the appropriate gpart/zpool commands to take up the expanded space,
then reboot, and the gptboot error is back again.
We've been having similar/same issues with a customer who is running on bare
hardware using a Cisco C240 M4 using the mrsas driver, but it also appears
to exhibit the problem we were having where the backup partition table does
not get updated when the gpart bootonce flag is set so we can boot from an
alternate partition. Adding 'gpart recover ${disk}' to our startup script
gets around the problem.
Paul.
--
Paul Koch | Founder, CEO
AKIPS Network Monitor | akips.com
Brisbane, Australia
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 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. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
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 r...@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 10241 freebsd-boot (512K) 307283886082 freebsd-swap (4.0G) 8391680 1024 - free - (512K) 8392704 104857603 freebsd-ufs [bootme] (5.0G) 18878464 104857604 freebsd-ufs (5.0G) 29364224 754913285 freebsd-zfs (36G) 10482 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 000 4645 2049 4150 5452 0001 005c 010 b85b a5f5 0001 020 063f 0022 030 ffde 063f 16e7 cafe 18d1 11e5 040 f697 0008 9b27 bd6a 0002 050 0080 0080 8856 ebca 060 * Backup GPT header # dd if=/dev/da0 bs=512 skip=104857599 count=1 2>/dev/null | hexdump 000 4645 2049 4150 5452 0001 005c 010 98b1 45c8 063f 020 0001 0022 030 ffde 063f 16e7 cafe 18d1 11e5 040 f697 0008 9b27 bd6a ffdf 063f 050 0080 0080 8856 ebca 060 * 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
