From nobody Thu Sep 16 22:19:40 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id A1B2717DB6B8 for ; Thu, 16 Sep 2021 22:19:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic310-22.consmr.mail.gq1.yahoo.com (sonic310-22.consmr.mail.gq1.yahoo.com [98.137.69.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4H9WjQ2S2sz4S7f for ; Thu, 16 Sep 2021 22:19:54 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631830787; bh=QLjQ3wo2Jv8PNHiFe4UzACOM9iebWtYmkXLoTf++2rM=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=TzS+Czm6JXDmXCkTdWw24UC7M2DhM6XuZncs1IEqN/mFrYnf6mIXJnoQYEy5EHmYv3RYnDL+QMKXNaR5xn0vgmRDHtGLbZtLzopZuLT3FdW1ceoCr7apaCXXQLAGdJUKKY0qTCWdcH0Fx6WpByS26OpIbfhmzu+SFSAMoq9MhdMXxeEigllpKL68jZACyLUJ7erfa7AhQUU23IgU3dSQTXQETuUVAfB9unO+uERJJozrpP5jiyQDK6xOxa/37kvOZZKMpemlzpjrwhOOlKgK/i3AdXA81jyNVeS3ZuaDdcbevTIXyZRTYkXqn0+RzSDQaQl7lqQA404+II37auU6Hg== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1631830787; bh=iWhw+TJ4U5QcupmTYF29r3QY82O4A5qtIbg5RI9bhQi=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UP3gob6BzGxREk73G5da2iBOf5dEunXLAMU5jwjiX57hLPuHzD5nQOSWRBycB8yG/EPp/3fp5TcusKQIYQfM5BisMqtlCfqnDwcksf/EBL2GDKQAL5IAO17Mlm1p2xp5ky9HIuykzKM0rBbYPZehkYkqjX19Yep6Kpaz3+CdiLNfRTsLa/y4i/UfHnLKpXyPcjVOFSYG2eOfmgCweUhHpc1vn7EpfxQHa+XS9P758Q4ns0NNe7ljmJHTGxAQGUVO7XuQH4ICXRefQ/XO1tykRDG1BABoaHqhrFLtMT3l98ovPDnZdowHl4oQbG6F4LP8Zq0vQktKPCD5wJ8JBB7URg== X-YMail-OSG: NrfMS2kVM1nm5kpDEG0r9dgelLi2_z4IZ5RiIDGOdcxFvcMSRE8xHAvuRZPDhIe GMM9xPOgifR0QMCCdBRZDpRHOCRCFQ6iRxHi73rVvymNasb8nGpfjFYfd_sMP0px1NRrUZkQRaLn peH9zjV6OzjPVqui14iiXZueJ.8V2hT5p06h9VS8KkdrFHbFOecoyTI.Tq1S805_0vaelIHVAm38 3G1Wz.oHV4GnerD_b.KRhaOEHkRIOywgBnoHdNBycqaUH6xOV5Jikz0U0sWnsLf47TNy2EBL3W30 nCR9EES5B6b5ZzKifeK.Dzn7iaTMkKS_5B6C_42Wl4JXs.Pm7XER4c44hd3vzK_Vxv5LGPfJywT5 hXsB.I0CIyM_7hWHBzSAQlgNRfAI6dWb4mufF395Q8zggT9J1jwzFA54F9uFwG1gh1Lw88w9iaI2 TQVrQ0DVbZu8Aex2GLSrNhgSWpkr7bPo3RNn21wmb_RurQKiZYs.I403cA31FnDr241SgCqxAHx. Lu4NZSVxaJ3bxEAjKzi1rrrqAS0CW1TH7xalGhD2FJ1G9Yk8hoHYnXUFrbuake2kNT_HFU5BamC5 8FLkJbYUk2OYDeCERVK7bwADZaFnbaUbZksVlYi_8wtmMYzXMhp8LFo0M0WGYhkWYQMbVe1r3ekQ pBvSByen.oVFLzxv4yQvEd5hbLiq9D8EmheF1rZeQ4EBkdydRwaKnCH1Q737Sgx2x9GHR_eyyA3U h2g992phXota74rY_6Wx9CRfrr7pP3qSJu6R3pYJM6tmshG.XDuH4hlfjvYIGXlYS9iGx7aeqe5Z bntqU0zYBTF8VUaKO7qGoJoNbvbg_i649q2_Vo.VYq8GoOstmYLBOSmiIbc.wRcjMY5VPCPp4fK9 mrTy0RBXA9AK31JNBaqC3A5wd22aOngmPnByPT6XGucDSDhCFSJItyrpOgpa5zxip3saPB1owLar GHcJHeXquUGndhd.UUtW8.lRZs8iRlme_lwYgxE7EXdiBNaJsf2_lWKj3lhg9GXwHkim1D_m7zNB q_BJJe4TbdyWDBnayy1mogCskxUmg_sTOo3L0zfY2kQdDHaVnLRTFBREJGz_E53a6Lou7NxP4gVr ERDKQEwTqOPgQ1Mbmze9XkrgcdMDlVYxYXY3sWHgbO0tyG3EOGDczi21RpkOxO2kIbXpNY30DkyJ 1rcm.FMlAsOv0Jb.zoqE8au37lExPLCmv1fgsjdPgn_E715yQOct9KRq1tVeJQv9zMMlKxRMJ2jF IhITtDDyl8jg.hnzYmrB1oHBuPQNv12w7tOgx62.BJFIP.HWCzdzCSDOk2EioUe82O9wXD3SZ89e daGenQJ0WqeuHye65HhRuX.gy_abIPpjXsuKclZpKfwb2eJ_nmncgrGGjNFWOiDjAdHUeacBR1hg FaekzuPTnPeHC54bi7zjh7FgM706.U2PiKYaQLm9fezp4.Jq8p6a3z32j7_RlxbmYMMSJe3aAfo5 QGutW9ETvVO5_bBwVGo1ZPisOG8NGrK4wK8ZL0N4z2Wo6vZAwlzKTF5sGuTFTO.DXK9sS9hieqxV 0PP3syH6xAfWSR0gbjg0YtIoCQNP9gEI33ZFvKFbgy8RBsCGSDx.3Y_if_c_Eh0aLV39jMl5NswT EqwH5Zh7VQKpZqV1BHlt_oWz_OXyhw8qxq9uR6VLZ9lhY75bsgdfliufPGiHMEydMb3AnfyhVrAT MxjFPHMfddl2yuRaC0OxOIHk.D5Pij4l0QdR1ugIwylRpkJrsQgmhP0Jub9Nf83NcoGetw4h60Ky xal4yVC5M8SKTzvpRupEeMU9YVGpFne7S255kzxYhYqO3MM9kz3JCV.YAehfir.EuvD7hbPP2X4s zHSTE0wz7eVOT5495Yr6Vgv9Dl4IrhkVMo_zJ2Jcn2Me6qLhUkIgLlyAQC59DQtKrhq2haHXI2NK OylVJadcsEXhmJCzOiZ01PV88wWjlkXB8s1RII0aiC8Gpwfef0fbBIbnXLWs8cg5tO21hBJRQrpL duJk3lJVxOpn2KZD0NprTpULcA8GuDoBDXmo15mkPBGcUbGXuX9Zk5FaJQot_Z375FJg3H_4HfFR IWDMIIdpZTnY5vClIMoXrt_MkS8iB7kJHqZJWxJ6Z71et.a1DC3B2B5Srh6OIsDK7kMtp3Agpw.g kSfAqcvHr99wCiRBIUd8v5FikJKNsG_UPEMHPkcAsU9IvSdC3EpT1wGoU0mdavqEij9VVyxSgtQ6 5U8oahwiJQvszY5msrpxeXVZBB8AOTdlyUanDe7f.SbCd9ymCM2kX5qFgrrmBcfGZnm93_mwenti Vm8kXEEqk X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.gq1.yahoo.com with HTTP; Thu, 16 Sep 2021 22:19:47 +0000 Received: by kubenode517.mail-prod1.omega.ne1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 576ca0b717829a889d66ee8a668801ea; Thu, 16 Sep 2021 22:19:42 +0000 (UTC) Content-Type: text/plain; charset=utf-8 List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: zpool import: "The pool cannot be imported due to damaged devices or data" but zpool status -x: "all pools are healthy" and zpool destroy: "no such pool" In-Reply-To: <88799C4C-2371-42C1-A41C-392969A1C1E0@via.net> Date: Thu, 16 Sep 2021 15:19:40 -0700 Cc: freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: <6B748E71-0E70-4FFA-9AB5-639465E91275@yahoo.com> References: <88799C4C-2371-42C1-A41C-392969A1C1E0@via.net> To: joe mcguckin X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4H9WjQ2S2sz4S7f X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-current X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Sep-16, at 13:26, joe mcguckin wrote: > I experienced the same yesterday. I grabbed an old disk that was = previously part of a pool. Stuck it in the chassis and did =E2=80=98zpool = import=E2=80=99 and got the same output you did. Mine was a single-disk pool. I use zfs just in order to use bectl, not for redundancy or other such. So my configuration is very simple. > Since the other drives of the pool were missing, the pool could not be = imported. >=20 > zpool status reports 'everything ok=E2=80=99 because all the existing = pools are ok. zpool destroy can=E2=80=99t destroy the pool becuase it = has not been imported. Yea, but the material at the URL it listed just says: QUOTE The pool must be destroyed and recreated from an appropriate backup = source END QUOTE so it says to do something that in my context could not be done via the normal zfs-related commands as far as I can tell. > I simply created a new pool specifying the drive address of the disk - = zfs happily overwrote the old incomplete pool info. Ultimately, I zeroed out an area of the media that had the zfs related labels and after that things operated normally and I could recreate the pool in the partition, send/recieve to it the backup, and use the restored state. I did not find a way to use the zpool/zfs related commands to deal with fixing the messed-up status. (I did not report everything that I'd tried.) > joe >=20 >=20 > Joe McGuckin > ViaNet Communications >=20 > joe@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax >=20 >=20 >=20 >> On Sep 16, 2021, at 1:01 PM, Mark Millard via freebsd-current = wrote: >>=20 >> What do I go about: >>=20 >> QUOTE >> # zpool import >> pool: zopt0 >> id: 18166787938870325966 >> state: FAULTED >> status: One or more devices contains corrupted data. >> action: The pool cannot be imported due to damaged devices or data. >> see: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E >> config: >>=20 >> zopt0 FAULTED corrupted data >> nda0p2 UNAVAIL corrupted data >>=20 >> # zpool status -x >> all pools are healthy >>=20 >> # zpool destroy zopt0 >> cannot open 'zopt0': no such pool >> END QUOTE >>=20 >> (I had attempted to clean out the old zfs context on >> the media and delete/replace the 2 freebsd swap >> partitions and 1 freebsd-zfs partition, leaving the >> efi partition in place. Clearly I did not do everything >> require [or something is very wrong]. zopt0 had been >> a root-on-ZFS context and would be again. I have a >> backup of the context to send/receive once the pool >> in the partition is established.) >>=20 >> For reference, as things now are: >>=20 >> # gpart show >> =3D> 40 937703008 nda0 GPT (447G) >> 40 532480 1 efi (260M) >> 532520 2008 - free - (1.0M) >> 534528 937166848 2 freebsd-zfs (447G) >> 937701376 1672 - free - (836K) >> . . . >>=20 >> (That is not how it looked before I started.) >>=20 >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 13.0-RELEASE-p4 FreeBSD 13.0-RELEASE-p4 #4 = releng/13.0-n244760-940681634ee1-dirty: Mon Aug 30 11:35:45 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/13_0R-CA72-nodbg-clang/usr/13_0R-src/ar= m64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 >>=20 >> I have also tried under: >>=20 >> # uname -apKU >> FreeBSD CA72_4c8G_ZFS 14.0-CURRENT FreeBSD 14.0-CURRENT #12 = main-n249019-0637070b5bca-dirty: Tue Aug 31 02:24:20 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA72-nodbg-clang/usr/main-src/arm6= 4.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 >>=20 >> after reaching this state. It behaves the same. >>=20 >> The text presented by: >>=20 >> https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E >>=20 >> does not deal with what is happening overall. >>=20 >=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)