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

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:

Code:
gptboot: invalid backup gpt header

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

[CMD="gpart show ada0"][/CMD]
Code:
=>       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".

Code:
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.
 
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?
 
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. :)
 
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?
 
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 :)
 
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?
 
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.
 
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.
 
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.
 
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.
 
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.
 
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.

Code:
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
Code:
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.
 
Back
Top