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