Re: GPT header checksum mismatch

On Wednesday, 30 March 2022 at 11:23:38 -0500, Greg Balfour wrote:
> On Tue, Mar 29, 2022 at 11:47 AM Arthur Chance <freebsd@qeng-ho.org> wrote:
>> On 29/03/2022 15:45, Greg Balfour wrote:
>>> Running 12.3-RELEASE I had a UPS failure and my machine did a reboot
>>> without properly shutting down.  Now when it boots I see this
>>> message:
>>>
>>> gptboot: backup GPT header checksum mismatch
>>>
>>> Doing a "gpart show ada0" shows
>>>
>>> 34  976773101  ada0  GPT  (466G) [CORRUPT]
>>>
>>> The machine still boots fine.  I don't have a prior dump of the
>>> partition table saved.  How can I clean up these errors?
>>
>> Try gpart recover.
>
> So I did a recover and it appeared to work...
>
> # gpart recover ada0
> ada0 recovered
>
> And a gpart status on ada0 was no longer showing as corrupted.  But after
> rebooting I still get the header checksum mismatch error and a gpart
> status on ada0 will show again as corrupted.  Also seen on boot:
>
> Mar 30 08:21:01 desktop kernel: GEOM: ada0: the secondary GPT table is corrupt or invalid.
> Mar 30 08:21:01 desktop kernel: GEOM: ada0: using the primary only -- recovery suggested.
>
> This is repeatable.  A gpart recover appears to work but on reboot
> everything shows as corrupted again.

Interesting.  Could you enter a PR, please?  Start at
https://bugs.freebsd.org/bugzilla/enter_bug.cgi
We need at least the following information:

1. Output of 'grep ada /var/run/dmesg.boot'.  This will give details
   about the disk, and also the number of sectors, which you'll need
   below.  Take the number of sectors and subtract 32 for the next
   steps (noted as SECS-32).

2. After 'gpart recover', the files created by
     dd if=/dev/ada0 count=33 of=gpt-before.start
     dd if=/dev/ada0 iseek=SECS-32 of=gpt-before.end
   The second dd should transfer exactly 16384 bytes.

3. After reboot, the files created by
     dd if=/dev/ada0 count=33 of=gpt-after.start
     dd if=/dev/ada0 iseek=SECS-32 of=gpt-after.end
   The second dd should transfer exactly 16384 bytes.

Supply this information as attachments to the bug report.  I'd also
appreciate being informed, though I don't promise to be the one to
investigate the problem.

Greg
--
When replying to this message, please copy the original recipients.
If you don't, I may ignore the reply or reply to the original recipients.
For more information, see http://www.lemis.com/questions.html
Sent from my desktop computer.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA.php