Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 30 Mar 2022 17:10:00 -0700
From:      David Christensen <dpchrist@holgerdanske.com>
To:        questions@freebsd.org
Subject:   Re: GPT header checksum mismatch
Message-ID:  <30be493e-e631-25b5-69e8-041cf0068ff8@holgerdanske.com>
In-Reply-To: <CAOYYArJEJzmb1AUnQ=xo1jvagMpqLuwCiD-E014qLnZQwtu3og@mail.gmail.com>
References:  <CAOYYArJu-XvRGDOu_sDsUtrnxf90LwjUPivLUPAd=bL8Dyhp7w@mail.gmail.com> <a4c4fe01-8d14-2618-8334-6a1291182553@qeng-ho.org> <CAOYYArJEJzmb1AUnQ=xo1jvagMpqLuwCiD-E014qLnZQwtu3og@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help
On 3/30/22 09:23, 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


You see that message on the console?


>>> 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.


Perhaps the storage device has problems?  Or, something between the 
storage device and memory?


Are you seeing any storage or interface errors via dmesg(8)?


Does a smartctl(8) long test report any problems?


Does the storage device manufacturer provide a diagnostic tool?  If so, 
does it report any problems?


David



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?30be493e-e631-25b5-69e8-041cf0068ff8>