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"
GPT has a back-of-disk structure. Is the problem here that wiping GPT only at front, leaves emergency state at back which is detected, before the ZFS initialisation system can decide you don't want to use that?
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"
On 2021-Sep-16, at 16:27, Freddie Cash wrote: > > [message chopped and butchered, don't follow the quotes, it's just to show > some bits together from different messages] > > On Thu, Sep 16, 2021 at 3:54 PM Mark Millard via freebsd-current > wrote: > > > For reference, as things now are: > > > > > > # gpart show > > > => 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) > > > . . . > > > > So you just want to clean nda0p2 in order to reuse it? Do "zpool > > > labelclear -f /dev/nda0p2" > > > > >> > >> I did not extract and show everything that I'd tried but > >> there were examples of: > >> > >> # zpool labelclear -f /dev/nda0p2 > >> failed to clear label for /dev/nda0p2 > > The start of the problem looked like (console context, > so messages interlaced): > > # zpool create -O compress=lz4 -O atime=off -f -tzopt0 zpopt0 /dev/nvd0 > GEOM: nda0: the primary GPT table is corrupt or invalid. > GEOM: nda0: using the secondary instead -- recovery strongly advised. > cannot create 'zpopt0': no such pool or dataset > # Sep 16 12:19:31 CA72_4c8G_ZFS ZFS[]: vdev problem, zpool=zopt0 > path=/dev/nvd0 type=ereport.fs.zfs.vdev.open_failed > > The GPT table was okay just prior to the command. > So I recovered it. > > It looks like you're trying to use a disk partition for a ZFS pool (nda0p2), > but then you turn around and use the entire drive (nvd0) for the pool which > clobbers the GPT. I'd not noticed my lack of a "p2" suffix. Thanks. Explains how I got things messed up, with GPT and zfs conflicting. (Too many distractions at the time, I guess.) > You need to be consistent in using partitions for all commands. Yep: dumb typo that I'd not noticed. > You're also mixing up your disk device nodes for the different commands; > while they are just different names for the same thing, it's best to be > consistent. Once I had commands failing, I expectly tried alternatives that I thought should be equivalent in case they were not in some way. Not my normal procedure. > GEOM is built out of layers (or more precisely, "containers" as it specifies > a new start and end point on the disk), which is very powerful. But it's > also very easy to make a mess of things when you start accessing things > outside of the layers. :) And ZFS labelclear option is the nuclear option > that tends to remove everything ZFS-related, and everything GPT-related; > although I've never seen it used on a partition before, usually just the disk. > Best bet in this situation is to just zero out the entire disk (dd > if=/dev/zero of=/dev/nda0 bs=1M), and start over from scratch. Create a new > GPT. Create new partitions. Use the specific partition with the "zpool > create" command. I ended up writing something less than a full 480 GiByte of writes. It preserved /dev/nda0p1 . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
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"
[message chopped and butchered, don't follow the quotes, it's just to show some bits together from different messages] On Thu, Sep 16, 2021 at 3:54 PM Mark Millard via freebsd-current < freebsd-current@freebsd.org> wrote: > > > For reference, as things now are: > > > > > > # gpart show > > > => 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) > > > . . . > > > > So you just want to clean nda0p2 in order to reuse it? Do "zpool > labelclear -f /dev/nda0p2" > > > > >> > >> I did not extract and show everything that I'd tried but > >> there were examples of: > >> > >> # zpool labelclear -f /dev/nda0p2 > >> failed to clear label for /dev/nda0p2 > > The start of the problem looked like (console context, > so messages interlaced): > > # zpool create -O compress=lz4 -O atime=off -f -tzopt0 zpopt0 /dev/nvd0 > GEOM: nda0: the primary GPT table is corrupt or invalid. > GEOM: nda0: using the secondary instead -- recovery strongly advised. > cannot create 'zpopt0': no such pool or dataset > # Sep 16 12:19:31 CA72_4c8G_ZFS ZFS[]: vdev problem, zpool=zopt0 > path=/dev/nvd0 type=ereport.fs.zfs.vdev.open_failed > > The GPT table was okay just prior to the command. > So I recovered it. > It looks like you're trying to use a disk partition for a ZFS pool (nda0p2), but then you turn around and use the entire drive (nvd0) for the pool which clobbers the GPT. You need to be consistent in using partitions for all commands. You're also mixing up your disk device nodes for the different commands; while they are just different names for the same thing, it's best to be consistent. GEOM is built out of layers (or more precisely, "containers" as it specifies a new start and end point on the disk), which is very powerful. But it's also very easy to make a mess of things when you start accessing things outside of the layers. :) And ZFS labelclear option is the nuclear option that tends to remove everything ZFS-related, and everything GPT-related; although I've never seen it used on a partition before, usually just the disk. Best bet in this situation is to just zero out the entire disk (dd if=/dev/zero of=/dev/nda0 bs=1M), and start over from scratch. Create a new GPT. Create new partitions. Use the specific partition with the "zpool create" command. -- Freddie Cash fjwc...@gmail.com
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"
On 2021-Sep-16, at 15:16, Alan Somers wrote: > On Thu, Sep 16, 2021 at 4:02 PM Mark Millard wrote: > > > On 2021-Sep-16, at 13:39, Alan Somers wrote: > > > On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current > > wrote: > > What do I go about: > > > > 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: > > > > zopt0 FAULTED corrupted data > > nda0p2UNAVAIL corrupted data > > > > # zpool status -x > > all pools are healthy > > > > # zpool destroy zopt0 > > cannot open 'zopt0': no such pool > > END QUOTE > > > > (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.) > > > > For reference, as things now are: > > > > # gpart show > > => 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) > > . . . > > > > (That is not how it looked before I started.) > > > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > > arm64 aarch64 1300139 1300139 > > > > I have also tried under: > > > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > > arm64 aarch64 1400032 1400032 > > > > after reaching this state. It behaves the same. > > > > The text presented by: > > > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > > > does not deal with what is happening overall. > > > > So you just want to clean nda0p2 in order to reuse it? Do "zpool > > labelclear -f /dev/nda0p2" > > >> >> I did not extract and show everything that I'd tried but >> there were examples of: >> >> # zpool labelclear -f /dev/nda0p2 >> failed to clear label for /dev/nda0p2 >> >> from when I'd tried such. So far I've not >> identified anything with official commands >> to deal with the issue. >> > That is the correct command to run. However, the OpenZFS import in FreeBSD > 13.0 brought in a regression in that command. It wasn't a code bug really, > more like a UI bug. OpenZFS just had a less useful labelclear command than > FreeBSD did. The regression has now been fixed upstream. > https://github.com/openzfs/zfs/pull/12511 Cool. >> Ultimately I zeroed out areas of the media that >> happened to span the zfs related labels. After >> that things returned to normal. I'd still like >> to know a supported way of dealing with the >> issue. >> >> The page at the URL it listed just says: >> >> QUOTE >> The pool must be destroyed and recreated from an appropriate backup source >> END QUOTE > > It advised to to "destroy and recreate" the pool because you ran "zpool > import", so ZFS thought that you actually wanted to import the pool. The > error message is appropriate if that had been the case. The start of the problem looked like (console context, so messages interlaced): # zpool create -O compress=lz4 -O atime=off -f -tzopt0 zpopt0 /dev/nvd0 GEOM: nda0: the primary GPT table is corrupt or invalid. GEOM: nda0: using the secondary instead -- recovery strongly advised. cannot create 'zpopt0': no such pool or dataset # Sep 16 12:19:31 CA72_4c8G_ZFS ZFS[]: vdev problem, zpool=zopt0 path=/dev/nvd0 type=ereport.fs.zfs.vdev.open_failed The GPT table was okay just prior to the command. So I recovered it. The import was the only command that I tried that referenced what to do about what was being reported. (Not that it was useful for my context.) I discovered the zpool status via the import reporting what it did after doing the GPT recovery first. I've still no clue what was wrong with my labelclear before the repartitioning. But it appeared that the GPT tables and the zfs related labels were stomping on each other after the reparitioning. So, yes, I was trying to import when I first got the message in question. But I could not do as indated and it reported to do a type of activity that I could not do. That was confusing. >>
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"
On Thu, 16 Sep 2021 13:01:16 -0700 Mark Millard via freebsd-current wrote: > What do I go about: > > 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: > > zopt0 FAULTED corrupted data > nda0p2UNAVAIL corrupted data > > # zpool status -x > all pools are healthy > > # zpool destroy zopt0 > cannot open 'zopt0': no such pool > END QUOTE > > (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.) > > For reference, as things now are: > > # gpart show > => 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) > . . . > > (That is not how it looked before I started.) > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1300139 1300139 > > I have also tried under: > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400032 1400032 > > after reaching this state. It behaves the same. > > The text presented by: > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > does not deal with what is happening overall. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) IIRC, zpool (except zpool import) only works with already-imported pool(s). So IIUC, `zpool status` and `zpool destroy` for faulted pool(s) would only works properly if the pool(s) fault after graceful import. *I have root pools only (in different physical drives), so non-root pools can behave differently. -- Tomoaki AOKI
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"
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 ‘zpool import’ 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. > > zpool status reports 'everything ok’ because all the existing pools are ok. > zpool destroy can’t 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 > > > Joe McGuckin > ViaNet Communications > > j...@via.net > 650-207-0372 cell > 650-213-1302 office > 650-969-2124 fax > > > >> On Sep 16, 2021, at 1:01 PM, Mark Millard via freebsd-current >> wrote: >> >> What do I go about: >> >> 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: >> >>zopt0 FAULTED corrupted data >> nda0p2UNAVAIL corrupted data >> >> # zpool status -x >> all pools are healthy >> >> # zpool destroy zopt0 >> cannot open 'zopt0': no such pool >> END QUOTE >> >> (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.) >> >> For reference, as things now are: >> >> # gpart show >> => 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) >> . . . >> >> (That is not how it looked before I started.) >> >> # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 >> arm64 aarch64 1300139 1300139 >> >> I have also tried under: >> >> # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 >> arm64 aarch64 1400032 1400032 >> >> after reaching this state. It behaves the same. >> >> The text presented by: >> >> https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E >> >> does not deal with what is happening overall. >> > === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
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"
On Thu, Sep 16, 2021 at 4:02 PM Mark Millard wrote: > > > On 2021-Sep-16, at 13:39, Alan Somers wrote: > > > On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current < > freebsd-current@freebsd.org> wrote: > > What do I go about: > > > > 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: > > > > zopt0 FAULTED corrupted data > > nda0p2UNAVAIL corrupted data > > > > # zpool status -x > > all pools are healthy > > > > # zpool destroy zopt0 > > cannot open 'zopt0': no such pool > > END QUOTE > > > > (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.) > > > > For reference, as things now are: > > > > # gpart show > > => 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) > > . . . > > > > (That is not how it looked before I started.) > > > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1300139 1300139 > > > > I have also tried under: > > > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400032 1400032 > > > > after reaching this state. It behaves the same. > > > > The text presented by: > > > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > > > does not deal with what is happening overall. > > > > So you just want to clean nda0p2 in order to reuse it? Do "zpool > labelclear -f /dev/nda0p2" > > > > I did not extract and show everything that I'd tried but > there were examples of: > > # zpool labelclear -f /dev/nda0p2 > failed to clear label for /dev/nda0p2 > > from when I'd tried such. So far I've not > identified anything with official commands > to deal with the issue. > That is the correct command to run. However, the OpenZFS import in FreeBSD 13.0 brought in a regression in that command. It wasn't a code bug really, more like a UI bug. OpenZFS just had a less useful labelclear command than FreeBSD did. The regression has now been fixed upstream. https://github.com/openzfs/zfs/pull/12511 > > Ultimately I zeroed out areas of the media that > happened to span the zfs related labels. After > that things returned to normal. I'd still like > to know a supported way of dealing with the > issue. > > The page at the URL it listed just says: > > QUOTE > The pool must be destroyed and recreated from an appropriate backup source > END QUOTE > It advised to to "destroy and recreate" the pool because you ran "zpool import", so ZFS thought that you actually wanted to import the pool. The error message is appropriate if that had been the case. > > But the official destroy commands did not work: > Because "zpool destroy" only works for imported pools. The error message meant "destroy" in a more generic sense. > same sort of issue of reporting that nothing > appropriate was found to destroy and no way to > import the problematical pool. > > > Note: I use ZFS because of wanting to use bectl, not > for redundancy or such. So the configuration is very > simple. > > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > >
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"
On 2021-Sep-16, at 13:39, Alan Somers wrote: > On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current > wrote: > What do I go about: > > 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: > > zopt0 FAULTED corrupted data > nda0p2UNAVAIL corrupted data > > # zpool status -x > all pools are healthy > > # zpool destroy zopt0 > cannot open 'zopt0': no such pool > END QUOTE > > (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.) > > For reference, as things now are: > > # gpart show > => 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) > . . . > > (That is not how it looked before I started.) > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1300139 1300139 > > I have also tried under: > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400032 1400032 > > after reaching this state. It behaves the same. > > The text presented by: > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > does not deal with what is happening overall. > > So you just want to clean nda0p2 in order to reuse it? Do "zpool labelclear > -f /dev/nda0p2" > I did not extract and show everything that I'd tried but there were examples of: # zpool labelclear -f /dev/nda0p2 failed to clear label for /dev/nda0p2 from when I'd tried such. So far I've not identified anything with official commands to deal with the issue. Ultimately I zeroed out areas of the media that happened to span the zfs related labels. After that things returned to normal. I'd still like to know a supported way of dealing with the issue. The page at the URL it listed just says: QUOTE The pool must be destroyed and recreated from an appropriate backup source END QUOTE But the official destroy commands did not work: same sort of issue of reporting that nothing appropriate was found to destroy and no way to import the problematical pool. Note: I use ZFS because of wanting to use bectl, not for redundancy or such. So the configuration is very simple. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
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"
On 2021-Sep-16, at 13:01, Mark Millard wrote: > What do I go about: > > 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: > >zopt0 FAULTED corrupted data > nda0p2UNAVAIL corrupted data > > # zpool status -x > all pools are healthy > > # zpool destroy zopt0 > cannot open 'zopt0': no such pool > END QUOTE > > (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.) > > For reference, as things now are: > > # gpart show > => 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) > . . . > > (That is not how it looked before I started.) > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1300139 1300139 > > I have also tried under: > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400032 1400032 > > after reaching this state. It behaves the same. > > The text presented by: > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > does not deal with what is happening overall. > I finally seem to have stomped on enough to have gotten past the issue (last actions): # gpart add -tfreebsd-swap -s440g /dev/nda0 nda0p2 added # gpart add -tfreebsd-swap /dev/nda0 nda0p3 added 7384907776 bytes transferred in 5.326024 secs (1386570546 bytes/sec) # dd if=/dev/zero of=/dev/nda0p3 bs=4k conv=sync status=progress dd: /dev/nda0p3: end of device972 MiB) transferred 55.001s, 133 MB/s 1802957+0 records in 1802956+0 records out 7384907776 bytes transferred in 55.559644 secs (132918559 bytes/sec) # gpart delete -i3 /dev/nda0 nda0p3 deleted # gpart delete -i2 /dev/nda0 nda0p2 deleted # gpart add -tfreebsd-zfs -a1m /dev/nda0 nda0p2 added # zpool import no pools available to import # gpart show . . . => 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) # zpool create -O compress=lz4 -O atime=off -f -tzpopt0 zopt0 /dev/nda0p2 # zpool list NAME SIZE ALLOC FREE CKPOINT EXPANDSZ FRAGCAP DEDUPHEALTH ALTROOT zpopt0 444G 420K 444G- - 0% 0% 1.00xONLINE - zroot824G 105G 719G- - 1%12% 1.00xONLINE - I've no clue what made my original zpool labelclear -f attempt leave material behind before repartitioning. Still could have been operator error of some kind. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
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"
On Thu, Sep 16, 2021 at 2:04 PM Mark Millard via freebsd-current < freebsd-current@freebsd.org> wrote: > What do I go about: > > 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: > > zopt0 FAULTED corrupted data > nda0p2UNAVAIL corrupted data > > # zpool status -x > all pools are healthy > > # zpool destroy zopt0 > cannot open 'zopt0': no such pool > END QUOTE > > (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.) > > For reference, as things now are: > > # gpart show > => 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) > . . . > > (That is not how it looked before I started.) > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1300139 1300139 > > I have also tried under: > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400032 1400032 > > after reaching this state. It behaves the same. > > The text presented by: > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > does not deal with what is happening overall. > So you just want to clean nda0p2 in order to reuse it? Do "zpool labelclear -f /dev/nda0p2"
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"
I experienced the same yesterday. I grabbed an old disk that was previously part of a pool. Stuck it in the chassis and did ‘zpool import’ and got the same output you did. Since the other drives of the pool were missing, the pool could not be imported. zpool status reports 'everything ok’ because all the existing pools are ok. zpool destroy can’t destroy the pool becuase it has not been imported. I simply created a new pool specifying the drive address of the disk - zfs happily overwrote the old incomplete pool info. joe Joe McGuckin ViaNet Communications j...@via.net 650-207-0372 cell 650-213-1302 office 650-969-2124 fax > On Sep 16, 2021, at 1:01 PM, Mark Millard via freebsd-current > wrote: > > What do I go about: > > 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: > >zopt0 FAULTED corrupted data > nda0p2UNAVAIL corrupted data > > # zpool status -x > all pools are healthy > > # zpool destroy zopt0 > cannot open 'zopt0': no such pool > END QUOTE > > (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.) > > For reference, as things now are: > > # gpart show > => 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) > . . . > > (That is not how it looked before I started.) > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1300139 1300139 > > I have also tried under: > > # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 > arm64 aarch64 1400032 1400032 > > after reaching this state. It behaves the same. > > The text presented by: > > https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E > > does not deal with what is happening overall. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > >
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"
What do I go about: 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: zopt0 FAULTED corrupted data nda0p2UNAVAIL corrupted data # zpool status -x all pools are healthy # zpool destroy zopt0 cannot open 'zopt0': no such pool END QUOTE (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.) For reference, as things now are: # gpart show => 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) . . . (That is not how it looked before I started.) # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1300139 1300139 I have also tried under: # 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/arm64.aarch64/sys/GENERIC-NODBG-CA72 arm64 aarch64 1400032 1400032 after reaching this state. It behaves the same. The text presented by: https://openzfs.github.io/openzfs-docs/msg/ZFS-8000-5E does not deal with what is happening overall. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
