Kernel Panic on zpool import

[Eniqmatic]

-F means "Recovery mode for a non-importable pool."
-n means "don't actually do it, just see if it might work"
https://www.freebsd.org/cgi/man.cgi?zpool(8)

OK, now I am confused!

I've ran the command "zpool import -fFn -R /mnt vol1" and now when I run a "zpool status" the volume is listed, and I can access the data from the CLI.

It's been up for a about 15 minutes now and not yet crashed? I can't see the data in the GUI yet but I believe that is a case of waiting for it to show up is it?

Question is why has this worked OK as the Fn shouldn't have done anything should it? Essentially what I've done is run "zpool import -f -R /mnt vol1" is it not? Or am I missing something (most likely) about that command that has done something extra?

What's my next steps however?

 

[Eniqmatic]

OK a little further on (kind of)

As mentioned above, I now have the pool imported and seems to be accessible through the CLI, just not the GUI (not figured out a way to make it show up yet).

However, although the GUI doesn't see the volumes, I had an idea to try and access the snapshots in the GUI as from what I can tell, it only seems to retrieve them when you click the button.

So I went to snapshots, and the system that had been running for a few hours, crashed upon trying to view the snapshots.

Could this indicate it's a snapshot corruption at all maybe?

 

[Robert Trevellyan]

I now have the pool imported and seems to be accessible through the CLI, just not the GUI (not figured out a way to make it show up yet).

That's because the GUI doesn't know about the import you did via the CLI.

Could this indicate it's a snapshot corruption at all maybe?

I don't think so.

I can access the data from the CLI ... What's my next steps however?

Backup the data (e.g. using zfs send/zfs receive or rsync), then destroy and recreate the pool.

 

[DrKK]

I agree.

All the signs here point to some kind of pool corruption. As RObert has said, this is almost always something we see happen due to a FreeNAS suffering a sudden power spike or power loss. For whatever that's worth---I know you said you don't think that's it, but, in our experience, these are the exact symptoms we see when people suddenly lose their FreeNAS to a violent/sudden power problem.

If the pool is mounted, copy what you can off of it. Then blow the pool away, as Robert says, then recreate from scratch. Does everything in smartctl -x check out OK for the drives?

 

[Eniqmatic]

I agree.

All the signs here point to some kind of pool corruption. As RObert has said, this is almost always something we see happen due to a FreeNAS suffering a sudden power spike or power loss. For whatever that's worth---I know you said you don't think that's it, but, in our experience, these are the exact symptoms we see when people suddenly lose their FreeNAS to a violent/sudden power problem.

If the pool is mounted, copy what you can off of it. Then blow the pool away, as Robert says, then recreate from scratch. Does everything in smartctl -x check out OK for the drives?

Thank you both for the replies and help.

I will probably end up restoring from the replicated data (is it safe to do this), it's just curiosity and a challenge getting the better of me really!

I'm doing a long smart test on one of the drives just now, I noticed an error message when the machine boots up that said something like "failed to copy the error log for ada0" then has the device name (a WD Red).

Small question, is there a way to change the mount/import behaviour of the pool on startup? For instance to change it to use the "-fF" switches?

 

[Eniqmatic]

Thrown in the towel and going to restore from backup!

Thanks again for all the help and suggestions!