Bug 210721 - Rerooting to an imported ZFS pool triggers panic
Summary: Rerooting to an imported ZFS pool triggers panic
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: kern (show other bugs)
Version: CURRENT
Hardware: Any Any
: --- Affects Some People
Assignee: Andriy Gapon
URL:
Keywords:
: 220916 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-06-30 09:25 UTC by Jan Bramkamp
Modified: 2017-09-19 14:22 UTC (History)
3 users (show)

See Also:


Attachments
system console output (2.23 KB, text/plain)
2016-06-30 09:25 UTC, Jan Bramkamp
no flags Details
proposed patch (763 bytes, patch)
2017-06-13 16:04 UTC, Andriy Gapon
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Jan Bramkamp 2016-06-30 09:25:56 UTC
Created attachment 171971 [details]
system console output

Rerooting to a ZFS dataseft triggers a kernel panic unless the ZFS pool containing the new root filesystem is exported before rerooting.

Steps to reproduce the problem:

 * Install FreeBSD 11.0-ALPHA5 with ZFS on root.
 * Install FreeBSD 10.0-ALPHA5 again on the same computer in a differen ZFS pool.
 * Boot into the first installation.
 * Set the vfs.root.mountfrom kernel env var to zfs:$SECOND_POOL_ROOT
 * Reroot with `reboot -r`.
 * Watch the kernel panic.

uname -a output:
FreeBSD sol.local 11.0-ALPHA5 FreeBSD 11.0-ALPHA5 #0 r302293: Thu Jun 30 08:21:36 UTC 2016     root@sol.local:/usr/obj/usr/src/sys/GENERIC  amd64

I attached the kernel panic backtrace.

The exporting the second pool before running `reroot -r` prevents the panic during rerooting.

My test setup is slightly more complicated because the second pool resides on GELI encrypted partitions, but it shouldn't influence the outcome.
Comment 1 Jan Bramkamp 2016-06-30 09:34:23 UTC
Rerooting in place without changing vfs.root.mountfrom triggers a panic as well.
Comment 2 Joakim Asplund 2017-03-31 21:32:17 UTC
I ran across this too when trying out stuff.
In the end it doesn't affect my use case of rerooting from one pool to another, but I was stumped and wondered why the simplest use case of just rerooting in place didn't work.
Comment 3 Andriy Gapon freebsd_committer 2017-03-31 21:40:50 UTC
(In reply to Joakim Asplund from comment #2)
Essentially, it's because the code that handles a zfs root filesystem mindlessly tries to import its pool and that's a problem if the pool is already imported.
It should be very easy to fix this bug by just adding a check for that condition.
Comment 4 Andriy Gapon freebsd_committer 2017-06-13 16:04:52 UTC
Created attachment 183449 [details]
proposed patch

Could you please try this patch?
Comment 5 Andriy Gapon freebsd_committer 2017-07-22 08:17:17 UTC
*** Bug 220916 has been marked as a duplicate of this bug. ***
Comment 6 David NewHamlet 2017-07-22 08:28:28 UTC
In my case(https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220916), rerooting to an dataset which is part of an exported zpool still trigger panic. 

The key point to reproducing is the zpool has been imported for some reasons.

This pool has been exported befor kenv vfs.root.mountfrom=zfs:tank/dataset && reboot -r.
Comment 7 David NewHamlet 2017-07-22 08:36:43 UTC
Moreover, I reroot from a md_root to a zfs pool in local device so I can export the pool befor reroot.
Comment 8 Andriy Gapon freebsd_committer 2017-07-22 08:38:35 UTC
It's still the same underlying issue.
Comment 9 Andriy Gapon freebsd_committer 2017-07-22 13:12:19 UTC
(In reply to David NewHamlet from comment #6)
I see now that my patch is incomplete, I'll update it to handle your case as well.
Thank you for the report!
Comment 10 Andriy Gapon freebsd_committer 2017-07-24 16:05:04 UTC
(In reply to David NewHamlet from comment #6)
For what it's worth, I can not reproduce the problem if I export the target pool before reboot -r.  I am not sure why you have the problem that you have and how patch from bug #220916 could change anything.  zpool export does all of spa_unload + spa_deactivate + spa_remove.
Comment 11 David NewHamlet 2017-07-25 00:53:37 UTC
(In reply to Andriy Gapon from comment #10)
Thanks for your investigation. Now I also can not reproduce the problem if I export the target pool before reboot -r(after half of the day in git reverting and compiling). Sorry for the misguiding.
Comment 12 commit-hook freebsd_committer 2017-07-25 13:17:56 UTC
A commit references this bug:

Author: avg
Date: Tue Jul 25 13:17:06 UTC 2017
New revision: 321471
URL: https://svnweb.freebsd.org/changeset/base/321471

Log:
  spa_import_rootpool should be able to handle an imported root pool

  That is required to support reboot -r with a new root filesystem being
  on an already imported pool.

  PR:		210721
  Reported by:	Jan Bramkamp <crest_maintainer@rlwinm.de>
  MFC after:	2 weeks

Changes:
  head/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c
Comment 13 Jan Bramkamp 2017-07-25 13:19:29 UTC
(In reply to commit-hook from comment #12)

Is there any chance to get this into the upcoming 11.1 release?
Comment 14 commit-hook freebsd_committer 2017-09-19 08:43:27 UTC
A commit references this bug:

Author: avg
Date: Tue Sep 19 08:43:16 UTC 2017
New revision: 323746
URL: https://svnweb.freebsd.org/changeset/base/323746

Log:
  MFC r321471: spa_import_rootpool should be able to handle an imported root pool

  That is required to support reboot -r with a new root filesystem being
  on an already imported pool.

  PR:		210721

Changes:
_U  stable/11/
  stable/11/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c
Comment 15 commit-hook freebsd_committer 2017-09-19 08:44:31 UTC
A commit references this bug:

Author: avg
Date: Tue Sep 19 08:43:46 UTC 2017
New revision: 323747
URL: https://svnweb.freebsd.org/changeset/base/323747

Log:
  MFC r321471: spa_import_rootpool should be able to handle an imported root pool

  That is required to support reboot -r with a new root filesystem being
  on an already imported pool.

  PR:		210721

Changes:
_U  stable/10/
  stable/10/sys/cddl/contrib/opensolaris/uts/common/fs/zfs/spa.c
Comment 16 Jan Bramkamp 2017-09-19 13:40:33 UTC
Is there a chance to get this into the next batch of 11.1 erratas?
Comment 17 Andriy Gapon freebsd_committer 2017-09-19 14:22:03 UTC
(In reply to Jan Bramkamp from comment #16)
I am not planning to work on an erratum myself.  Maybe another developer or someone from re@ would could be interested..