# 'gptboot: invalid backup gtp header' message at boot; no apparent ill effects



## OMGSnarf (Oct 12, 2012)

Hello,

I've just installed FreeBSD 9.0-RELEASE using GPT on /dev/ada0on my Dell Latitude c840.  After setting up GPT manually using the handbook as a guideline and rebooting, I get the following message prior to the BTX loader:


```
gptboot: invalid backup gpt header
```

The system boots properly, and I see no apparent ill effects.

[CMD="gpart show ada0"][/CMD]

```
=>       34  312581741  ada0  GPT  (149G)
         34       1024     1  freebsd-boot  (512k)
       1058    4194304     2  freebsd-ufs  (2.0G)
    4195362    8388608     3  freebsd-swap  (4.0G)
   12583970    8388608     4  freebsd-ufs  (4.0G)
   20972578    8388608     5  freebsd-ufs  (4.0G)
   29361186  283115520     6  freebsd-ufs  (135G)
  312476706     105069        - free -  (51M)
```

I looked at a previous thread (http://forums.freebsd.org/showthread.php?t=30231) except there the system would not boot, and it was marked as solved when the error message is still visible.  One of the earlier suggestions was to use dd to remove any possible remnants of an MBR or other GPT partition data.  I used DBAN to zero out the drive and did a fresh reinstall, and the invalid header message is still visible when booting.  Someone else in that thread had mentioned running the following:
`# gpart recover ada0`
and I get a message stating "ada0 recovering is not needed".


```
FreeBSD babylon 9.0-RELEASE-p3 FreeBSD 9.0-RELEASE-p3 #0: Tue Jun 12 01:47:53 UTC 2012
root@i386-builder.daemonology.net:/usr/obj/usr/src/sys/GENERIC  i386
```

dmesg output: http://pastebin.com/YheRNjLc

The only item that has been added to /boot/loader.conf is a line accepting the iwi0 firmware as specified in iwi(4).

Any suggestions?  This is a fresh setup, I've got nothing to lose, and I'm willing to try just about anything.  I'm relatively new with FreeBSD and the last time I used Linux was ages ago, but I'm willing to read man pages, documentation, and follow directions.

Thanks for your time.


----------



## wblock@ (Oct 12, 2012)

That message is what happens when the backup GPT table at the end of the disk has been overwritten.  Usually that's caused by something putting its own metadata there, typically gmirror(8) or glabel(8).  Have you used either?


----------



## OMGSnarf (Oct 12, 2012)

wblock@ said:
			
		

> That message is what happens when the backup GPT table at the end of the disk has been overwritten.  Usually that's caused by something putting its own metadata there, typically gmirror(8) or glabel(8).  Have you used either?


I'm not using gmirror, and I haven't used glabel that I'm aware of.  However, when I set up the partitions manually during installation with bsdinstall(8) I did opt to give all of the partitions labels - rootfs, swap, varfs, tmpfs, usrfs.  Would this have called glabel(8)?

I'm willing to blow everything away and try not giving items labels during installation and see if that makes a difference.


----------



## wblock@ (Oct 12, 2012)

The labels entered in bsdinstall should not be a problem, they'll either be GPT labels or filesystem labels.  It doesn't use them in /etc/fstab anyway.

A default install should not have this problem.  You say you created the partitions manually.  Was that through the shell or the bsdinstall partitioning screen?

The interesting thing is that gptboot, the boot loader, sees a problem, but gpart(8) does not.  I wonder if that's a BIOS off-by-one bug hiding the last block of the drive?


----------



## OMGSnarf (Oct 12, 2012)

wblock@ said:
			
		

> The labels entered in bsdinstall should not be a problem, they'll either be GPT labels or filesystem labels.  It doesn't use them in /etc/fstab anyway.
> 
> A default install should not have this problem.  You say you created the partitions manually.  Was that through the shell or the bsdinstall partitioning screen?
> 
> The interesting thing is that gptboot, the boot loader, sees a problem, but gpart(8) does not.  I wonder if that's a BIOS off-by-one bug hiding the last block of the drive?


The partitions were created through bsdinstall(8), as indicated in the handbook section 3.7.2.  I based the sizes off of Example 3-3.  Nothing was done through the shell.  

Out of curiosity I'll try reinstalling without using any labels, then by using guided partitioning and seeing what happens.  I'll provide details for both instances.

The BIOS is a bit lacking where drive geometry comes in, being it is an older Dell laptop.  If there's any additional information I can provide let me know and I'll have feedback within the next 6-8 hours


----------



## wblock@ (Oct 12, 2012)

If you reinstall, you may never know what caused this.  The labels entered in bsdinstall are not a problem.

Do you have the latest BIOS?


----------



## OMGSnarf (Oct 12, 2012)

wblock@ said:
			
		

> If you reinstall, you may never know what caused this.  The labels entered in bsdinstall are not a problem.
> 
> Do you have the latest BIOS?


I believe it has A13, which is the latest listed on the Latitude c840 support site.  I'll double-check once I get home, but I'm 99% certain this is what I'm using already.


----------



## OMGSnarf (Oct 13, 2012)

Confirmed - using the latest BIOS revision A13.  No geometry is shown for the drive in the BIOS aside from 'Primary Hard Drive: 137.4 GB'.  

Regarding reinstall - this is my second installation of FreeBSD 9.0-RELEASE to this system.  During my first installation I had this issue, which lead to my searching for and finding the thread in the OP.  I used DBANto wipe the drive based off of Morte's suggestion "To truly clear the old GPT data, you have to clear the back of the drive as well".  I was able to reproduce the issue using the same steps.

Any suggestions or anything that might help debug this issue, or provide additional data?  Thanks again for your time.


----------



## wblock@ (Oct 13, 2012)

The easy way to clear primary and backup GPT tables is
`# gpart destroy -F ada0`

But gpart(8) is saying there is nothing wrong.  So the problem is with gptboot, or the BIOS, or the combination.  The next thing to try would be 9-stable to see if there have been any changes.  If that doesn't work, it's worth entering a PR.


----------



## OMGSnarf (Oct 13, 2012)

wblock@ said:
			
		

> The easy way to clear primary and backup GPT tables is
> `# gpart destroy -F ada0`
> 
> But gpart(8) is saying there is nothing wrong.  So the problem is with gptboot, or the BIOS, or the combination.  The next thing to try would be 9-stable to see if there have been any changes.  If that doesn't work, it's worth entering a PR.


Thanks - I'm going to follow the instructions in the handbook on following stable and follow-up once I know more.


----------



## wblock@ (Oct 13, 2012)

Snapshots are available at https://pub.allbsd.org/FreeBSD-snapshots/.


----------



## OMGSnarf (Oct 13, 2012)

Wow, thanks - that should be quicker than syncing source with cvs and building everything   And I was just about to ask how that would affect the system partitioning without rebuilding it from scratch.


----------



## OMGSnarf (Oct 13, 2012)

Booted from the 9.0-RELEASE CD, dropped to a shell and ran
`# gpart destroy -F ada0`
Burned the RELENG_9 shapshot image from 20121006, booted from that disc, and created a fresh system using GPT and the same setup as described in the OP.  Upon reboot, I continue to get the same 'gptboot: Invalid GPT backup header' message.


```
FreeBSD babylon 9.1-PRERELEASE FreeBSD 9.1-PRERELEASE #0: Sat Oct  6 04:02:11 UTC 2012
root@build-i386-fbsd-2.allbsd.org:/usr/obj/i386.i386/usr/src/sys/GENERIC i386
```

The numbers from
`# gpart show ada0`
show the same as listed in OP.

The results of
`# gpart recover ada0`
still shows as

```
ada0 recovering is not needed
```

Unless you have any other suggestions, I'll enter a PR using the web interface since I don't have mail working yet on that system.

Thanks again!

Edit: Out of curiosity I tried using automatic partitioning using the snapshot and the issue still occurs.


----------

