Date: Thu, 31 Mar 2022 11:51:57 -0500 From: Greg Balfour <greg.bal4@gmail.com> To: "Greg 'groggy' Lehey" <grog@freebsd.org>, dpchrist@holgerdanske.com, grarpamp@gmail.com Cc: Arthur Chance <freebsd@qeng-ho.org>, freebsd-questions@freebsd.org Subject: Re: GPT header checksum mismatch Message-ID: <CAOYYAr%2BTaiyKWm=OTp6aV-qbqvdwoFbWcF_mNz3gV77OvjHg%2Bw@mail.gmail.com> In-Reply-To: <20220331003622.GK60301@eureka.lemis.com> References: <CAOYYArJu-XvRGDOu_sDsUtrnxf90LwjUPivLUPAd=bL8Dyhp7w@mail.gmail.com> <a4c4fe01-8d14-2618-8334-6a1291182553@qeng-ho.org> <CAOYYArJEJzmb1AUnQ=xo1jvagMpqLuwCiD-E014qLnZQwtu3og@mail.gmail.com> <20220331003622.GK60301@eureka.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, Mar 30, 2022 at 7:36 PM Greg 'groggy' Lehey <grog@freebsd.org> wrote: > 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 The link to the Wikipedia article in a previous response was very informative. While digging through it I realized what happened. When the PC lost power it also lost all BIOS settings due to a dead CMOS battery. When the system booted the SATA Operation setting was configured to the default of RAID On. When FreeBSD was originally installed on this machine the SATA Operation setting had been configured to AHCI. After changing it back to AHCI I was able to do a gpart recover which was now successful. It was a long time ago, but I think I had originally changed it to AHCI because of trying to install some Linux distribution. Thanks for the all the responses. I learned a bit.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAOYYAr%2BTaiyKWm=OTp6aV-qbqvdwoFbWcF_mNz3gV77OvjHg%2Bw>