Date: Thu, 24 Feb 2022 07:36:32 -0900 From: Rob Wing <rob.fx907@gmail.com> To: Alexander Motin <mav@freebsd.org> Cc: Larry Rosenman <ler@lerctr.org>, Freebsd current <freebsd-current@freebsd.org> Subject: Re: ZFS PANIC: HELP. Message-ID: <CAF3%2Bn_fYSHLxYGp0jUbFg8%2BPFkEJAp7QMCX2BWMk4ePrn0=1yA@mail.gmail.com> In-Reply-To: <e9b95fed-9a3c-623c-c046-f0a7fd609eb6@FreeBSD.org> References: <07c0c9c34b4a4133acab597c96867d27@lerctr.org> <95c7c326-e2f9-6e66-7b97-b9fb2671f4ad@FreeBSD.org> <1b6b2017ba69e6fda1ca237c3016ac61@lerctr.org> <a5f379a6-c2bd-f1e9-a281-bb657f3ccb75@FreeBSD.org> <6182c57bf1859482e72af78037c399e4@lerctr.org> <7abcbe88-446f-44b9-c3a7-0997d3430b57@FreeBSD.org> <2bc12c9ee3e6dd71b65079116ff2b845@lerctr.org> <5930f3d2b71c0932f903bb5b88a3c87d@lerctr.org> <e9b95fed-9a3c-623c-c046-f0a7fd609eb6@FreeBSD.org>
index | next in thread | previous in thread | raw e-mail
[-- Attachment #1 --] You might try setting `sysctl vfs.zfs.recover=1` and `sysctl vfs.zfs.spa.load_verify_metadata=0`. I had a similar error the other day (couple months ago). The best I did was being able to import the pool read only. I ended up restoring from backup. On Thu, Feb 24, 2022 at 7:30 AM Alexander Motin <mav@freebsd.org> wrote: > On 24.02.2022 10:57, Larry Rosenman wrote: > > On 02/23/2022 9:27 pm, Larry Rosenman wrote: > >> It crashes just after root mount (this is the boot pool and only pool > >> on the system), > >> seeL > >> https://www.lerctr.org/~ler/14-BOOT-Crash.png > > > > Where do I go from here? > > I see 2 ways: 1) Since it is only an assertion and 13 is working (so > far), you may just build 14 kernel without INVARIANTS option and later > recreate the pool when you have time. 2) You may treat it as metadata > corruption: import pool read-only and evacuate the data. If you have > recent enough snapshots you may be able to easily replicate the pool > with all the settings to some other disk. ZIL is not replicated, so > corruptions there should not be a problem. If there are no snapshots, > then either copy on file level, or you may be able to create snapshot > for replication in 13 (on 14 without INVARIANTS), importing pool > read-write. > > -- > Alexander Motin > > [-- Attachment #2 --] <div dir="ltr"><div>You might try setting `sysctl vfs.zfs.recover=1` and `sysctl vfs.zfs.spa.load_verify_metadata=0`.<br></div><div><br></div><div>I had a similar error the other day (couple months ago). The best I did was being able to import the pool read only. I ended up restoring from backup.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 24, 2022 at 7:30 AM Alexander Motin <<a href="mailto:mav@freebsd.org">mav@freebsd.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 24.02.2022 10:57, Larry Rosenman wrote:<br> > On 02/23/2022 9:27 pm, Larry Rosenman wrote:<br> >> It crashes just after root mount (this is the boot pool and only pool<br> >> on the system),<br> >> seeL<br> >> <a href="https://www.lerctr.org/~ler/14-BOOT-Crash.png" rel="noreferrer" target="_blank">https://www.lerctr.org/~ler/14-BOOT-Crash.png</a><br>; > <br> > Where do I go from here?<br> <br> I see 2 ways: 1) Since it is only an assertion and 13 is working (so <br> far), you may just build 14 kernel without INVARIANTS option and later <br> recreate the pool when you have time. 2) You may treat it as metadata <br> corruption: import pool read-only and evacuate the data. If you have <br> recent enough snapshots you may be able to easily replicate the pool <br> with all the settings to some other disk. ZIL is not replicated, so <br> corruptions there should not be a problem. If there are no snapshots, <br> then either copy on file level, or you may be able to create snapshot <br> for replication in 13 (on 14 without INVARIANTS), importing pool read-write.<br> <br> -- <br> Alexander Motin<br> <br> </blockquote></div>help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CAF3%2Bn_fYSHLxYGp0jUbFg8%2BPFkEJAp7QMCX2BWMk4ePrn0=1yA>