Invalid GPT backup header
dweimer
dweimer at dweimer.net
Tue Jul 10 16:50:45 UTC 2012
On 2012-07-09 19:49, Warren Block wrote:
> On Mon, 9 Jul 2012, dweimer wrote:
>
>> I have had a few virtual machine installations come up with
>> "gptboot: invalid GPT backup header" error message while booting.
>> (some immediately on first boot after install) They still boot fine,
>> and run without problems, but I would like to find a way to fix the
>> problem. Does anyone know how you can write a new GPT backup header
>> to the partition table.
>
> See the gpart recover command covered in the RECOVERING section in
> gpart(8).
>
>> I have even gone to the extent of adding a second virtual disk,
>> using gpart to create a partition table and then add new partitions
>> and setup bootstrap then use cpio to copy data over and switched the
>> drive SCSI IDs within the virtual machines configuration to boot from
>> the second drive instead. Still same error message when booting off
>> the new drive. I did however leave out the size option when creating
>> the last UFS partition so it may have filled to the end and overwrote
>> the backup GPT table.
>
> gpart will not overwrite the backup GPT with a partition. Other
> stuff may not be GPT-aware.
> _______________________________________________
> freebsd-questions at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to
> "freebsd-questions-unsubscribe at freebsd.org"
I only used gpart, to create the partitions for the disk. Here is the
procedure that I followed except in this case I added labels to the UFS
slices just so it was clear what everything was used for. I followed
this by mounting each partition under /mnt/ and using "find . -mount
-print0 | cpio -0dump /mnt/" from the current mounted partitions. below
are the commands I removed the output from all but the gpart show
command, da0 is not the original installed drive, but the one I made
using this process last time, da1 was the installed drive, but of course
now has been rewritten with the new data.
fhproxy1-new# dd if=/dev/zero of=/dev/da1 bs=1024 count=1024
fhproxy1-new# gpart create -s GPT da1
fhproxy1-new# gpart show
fhproxy1-new# gpart add -s 128 -t freebsd-boot -l boot da1
fhproxy1-new# gpart add -a 2048 -t freebsd-swap -l swap -s 2G da1
fhproxy1-new# gpart add -t freebsd-ufs -l root -s 1G da1
fhproxy1-new# gpart add -t freebsd-ufs -l home -s 1G da1
fhproxy1-new# gpart add -t freebsd-ufs -l tmp -s 1G da1
fhproxy1-new# gpart add -t freebsd-ufs -l var -s 2G da1
fhproxy1-new# gpart add -t freebsd-ufs -l usr da1
fhproxy1-new# gpart show
=> 34 35651517 da0 GPT (17G)
34 128 1 freebsd-boot (64k)
162 2910 - free - (1.4M)
3072 4194304 2 freebsd-swap (2.0G)
4197376 2097152 3 freebsd-ufs (1.0G)
6294528 2097152 4 freebsd-ufs (1.0G)
8391680 2097152 5 freebsd-ufs (1.0G)
10488832 4194304 6 freebsd-ufs (2.0G)
14683136 20968415 7 freebsd-ufs (10G)
=> 34 35651517 da1 GPT (17G)
34 128 1 freebsd-boot (64k)
162 1886 - free - (943k)
2048 4194304 2 freebsd-swap (2.0G)
4196352 2097152 3 freebsd-ufs (1.0G)
6293504 2097152 4 freebsd-ufs (1.0G)
8390656 2097152 5 freebsd-ufs (1.0G)
10487808 4194304 6 freebsd-ufs (2.0G)
14682112 20969439 7 freebsd-ufs (10G)
fhproxy1-new# newfs -U /dev/gpt/root
fhproxy1-new# newfs -U /dev/gpt/home
fhproxy1-new# newfs -U /dev/gpt/tmp
fhproxy1-new# newfs -U /dev/gpt/var
fhproxy1-new# newfs -U /dev/gpt/usr
fhproxy1-new# gpart bootcode -b /boot/pmbr -p /boot/gptboot -i 1 da1
I will copy the data over and try a reboot again this afternoon and see
if maybe this time it works. gpart recover returns that no recovery is
needed on both da0 and da1.
--
Thanks,
Dean E. Weimer
http://www.dweimer.net/
More information about the freebsd-questions
mailing list