Date: Thu, 31 Mar 2022 11:36:22 +1100 From: Greg 'groggy' Lehey <grog@FreeBSD.org> To: Greg Balfour <greg.bal4@gmail.com> Cc: Arthur Chance <freebsd@qeng-ho.org>, freebsd-questions@freebsd.org Subject: Re: GPT header checksum mismatch Message-ID: <20220331003622.GK60301@eureka.lemis.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
--vkEkAx9hr54EJ73W Content-Type: text/plain; charset=us-ascii Content-Disposition: inline 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 --vkEkAx9hr54EJ73W Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iEYEARECAAYFAmJE94YACgkQIubykFB6QiNNFgCfR3tWSCfsoznbxhrL05Up6rfP xbMAn0NFZW9vbH2AOlnXqe1NXkgoz+my =fTC+ -----END PGP SIGNATURE----- --vkEkAx9hr54EJ73W--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20220331003622.GK60301>