Date: Fri, 26 Jun 2015 12:19:06 +1000 From: Paul Koch <paul.koch@akips.com> To: Warren Block <wblock@wonkity.com> Cc: freebsd-stable@freebsd.org Subject: Re: gptboot: unable to read backup GPT header - virtualbox guest with SAS controller Message-ID: <20150626121906.598684d1@akips.com> In-Reply-To: <alpine.BSF.2.20.1506220819300.34102@wonkity.com> References: <20150622124148.6aafd502@akips.com> <alpine.BSF.2.20.1506220819300.34102@wonkity.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Jun 2015 08:28:10 -0600 (MDT)
Warren Block <wblock@wonkity.com> 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20150626121906.598684d1>