Solved gptboot: unable to read backup GPT header

Hello.

This was already asked in a other topic (but was not the main subject) so I re-created a new thread.

At booting, as first message:
Code:
gptboot: error 1 lba 11439007
gptboot: unable to read backup GPT header.
...
This appends only with VirtualBox if a SCSI disk is used for installation.
The error message does not appear if a IDE disk is used.

With VMWare, those error message does not appear, even for SCSI disks.

How can I fix this (or hide that message)?

PS: After a short moment, boot continue and all is ok.

Thanks.

Fre;D
 
The message means that the backup GPT table at the end of the drive was missing or corrupt. That can be caused by multiple things. The simplest one is that the backup table was overwritten. That takes some doing, but people happily disable the safety all the time, so it's possible. If there was an off-by-one bug in the VirtualBox SCSI disk code, that could do it.

The first thing to do is figure out whether it is caused by the process of setting up a disk or by a bug. That could be tested in VirtualBox. Take a known-good disk image and use it for a SCSI disk, then boot from that disk. If you still see that error, it might be a bug in VirtualBox. If the error does not appear, it likely has something to do with the way you set up disks.
 
The first thing to do is figure out whether it is caused by the process of setting up a disk or by a bug. That could be tested in VirtualBox. Take a known-good disk image and use it for a SCSI disk, then boot from that disk. If you still see that error, it might be a bug in VirtualBox. If the error does not appear, it likely has something to do with the way you set up disks.

=>

fbsdcscsivb2.png


=>

fbsdcscsivb.png
 
If you change only the controller type in VirtualBox, and use the same VDI file, is the error still shown?
 
If you change only the controller type in VirtualBox, and use the same VDI file, is the error still shown?
As explained in first post, the error appear only if SCSI controller is used.
With IDE controller (default with VirtualBox but much slower than SCSI) => no error message.
 
Last edited by a moderator:
What I'm trying to determine is whether you are just changing the controller, or recreating the VM and reinstalling.
 
What I'm trying to determine is whether you are just changing the controller, or recreating the VM and reinstalling.
Ha, FreeBSD was installed on a fresh new VBox player, with only SCSI controller (1 cdrom + 1 disk) (not changing to SCSI after installed on IDE).
 
Last edited by a moderator:
Right, then we still don't know. If a drive image works on one, but that same image shows the error on the other, that would be suggestive of a bug. If you install it on each, it could be just a problem with the installation code.
 
Right, then we still don't know. If a drive image works on one, but that same image shows the error on the other, that would be suggestive of a bug. If you install it on each, it could be just a problem with the installation code.
Sorry, but I do not understand (English is not my native language).
What want you say with "Right, then we still don't know. If a drive image works on one, but that same image shows the error on the other, that would be suggestive of a bug.".

=> "If a drive image works on one, but that same image shows the error on the other,"
=> what "one" and what "other" ?

Here a crazy proposition: Why don't (you or somebody else) try to install your favorite FreeBSD distro on VirtualBox, with SCSI controllers and see what appends ?
PS: I have try with FreeBSD official iso, GhostBSD, PC-BSD, msfBSD => all same problem.
 
I didn't yet test installing from scratch but using VirtualBox 5.0.0 for OS X I was able to swap the virtual disk in my FreeBSD 10 amd64 VM from the SATA controller to an SCSI controller without any ill effects to GPT partition table or the backup header.
 
I didn't yet test installing from scratch but using VirtualBox 5.0.0 for OS X I was able to swap the virtual disk in my FreeBSD 10 amd64 VM from the SATA controller to an SCSI controller without any ill effects to GPT partition table or the backup header.
Do you mean that it is possible to switch from a system installed with a SATA controller to SCSI controller without problems ?
I never try this but, in my opinion, it would be normal that, in this case, a error message appear...
 
Do you mean that it is possible to switch from a system installed with a SATA controller to SCSI controller without problems ?
I never try this but, in my opinion, it would be normal that, in this case, a error message appear...

It will work assuming you have converted your disk to use labels, for example GPT labels. Without using labels your /etc/fstab will be using raw device names and attaching the disk to a different controller changes the device names and booting won't work.
 
It will work assuming you have converted your disk to use labels, for example GPT labels. Without using labels your /etc/fstab will be using raw device names and attaching the disk to a different controller changes the device names and booting won't work.
Ha, ok and perfect (did not know that switching is allowed).

Ok, I understand now the questions of wblock@. ;-)
=> I did not try yet to install on SATA controller and then switch to SCSI.
I am at work and will try this tonight to see if there is still error messages.

Thanks.
 
If switching controllers works then there probably isn't any problems in FreeBSD kernel. The question then becomes if the BIOS emulation in VirtualBox is broken somehow and returns a different number of LBA sectors at install time depending on which type of controller is selected. It also leaves open the possibility that FreeBSD boot(8) or loader(8) have a problem that only manifests itself when using SCSI controllers.
 
If switching controllers works then there probably isn't any problems in FreeBSD kernel. The question then becomes if the BIOS emulation in VirtualBox is broken somehow and returns a different number of LBA sectors at install time depending on which type of controller is selected. It also leaves open the possibility that FreeBSD boot(8) or loader(8) have a problem that only manifests itself when using SCSI controllers.
I suspect too a bug in VirtualBox. VMware does not have that problem. And because VirtualBox is open-source, I (we ?) must find the bug and correct it. ;-)
 
I tested a fresh install of FreeBSD 10.2-RELEASE amd64 on VirtualBox 5.0.0 for OS X using an SCSI controller in the VM settings and with GPT partitioning. No problems at all.
 
Some news from the front.

With VMware 6.0.5, on Linux Mint 17, Netbook Pentium M, tested with FreeBSD official, GhostBSD and msfBSD:

CDrom:
No error messages for all controllers.

Disk:
No error messages for all controllers.

------------------------------------------

With VirtualBox 4.3.10, on Linux Mint 17, Netbook Pentium M, tested with FreeBSD official, GhostBSD and msfBSD:

CDrom:
No error messages for all controllers.

Disk:
If system was originally installed with:

IDE controller:
- Booting with IDE controller => no error message.
- Booting with SATA controller => no error message.
- Booting with SCSI controller => GPT error message.
- Booting with SAS controller => GPT error message.

SATA controller:
- Booting with IDE controller => no error message.
- Booting with SATA controller => no error message.
- Booting with SCSI controller => GPT error message.
- Booting with SAS controller => GPT error message.

SCSI controller:
- Booting with IDE controller => no error message.
- Booting with SATA controller => no error message.
- Booting with SCSI controller => GPT error message.
- Booting with SAS controller => GPT error message.

SAS controller:
- Booting with IDE controller => no error message.
- Booting with SATA controller => no error message.
- Booting with SCSI controller => GPT error message.
- Booting with SAS controller => GPT error message.

Note that those error messages do not make the boot slower nor interrupt anything.
But they are only a few disturbing for first welcome message...

Thanks.
 
Interesting. That suggests either a bug in the VirtualBox SCSI/SAS device emulation, or possibly in how it interacts with FreeBSD.

Could you please post a notice in the freebsd-emulation mailing list, pointing them at this thread? Or even just at that last post.
 
Disk:
If system was originally installed with:

IDE controller:
- Booting with IDE controller => no error message.
- Booting with SATA controller => no error message.
- Booting with SCSI controller => GPT error message.
- Booting with SAS controller => GPT error message.

I repeated this part of the exercise using VirtualBox 5.0.0, fresh install of 10.2-RELEASE amd64 using the defaults in virtual machine settings except I chose 512 MBs of RAM. No GPT error messages on boot whatsoever. It's starting to look like the problem is specific to VirtualBox version 4.
 
I repeated this part of the exercise using VirtualBox 5.0.0, fresh install of 10.2-RELEASE amd64 using the defaults in virtual machine settings except I chose 512 MBs of RAM. No GPT error messages on boot whatsoever.
After upgrade to VirtualBox 5.0 => no more error messages => solved => thanks.
 
Back
Top