|Summary:||Rerooting to an imported ZFS pool triggers panic|
|Product:||Base System||Reporter:||Jan Bramkamp <crest_maintainer>|
|Component:||kern||Assignee:||Andriy Gapon <avg>|
|Severity:||Affects Some People||CC:||avg, joakimas, wheelcomplex|
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 firstname.lastname@example.org:/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 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 2017-06-13 16:04:52 UTC
Created attachment 183449 [details] proposed patch Could you please try this patch?
Comment 5 Andriy Gapon 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 2017-07-22 08:38:35 UTC
It's still the same underlying issue.
Comment 9 Andriy Gapon 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 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 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 <email@example.com> 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 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 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?