[Bug 295313] RB_REROOT fails with already-imported ZFS pool (regression from 15.0)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=295313

            Bug ID: 295313
           Summary: RB_REROOT fails with already-imported ZFS pool
                    (regression from 15.0)
           Product: Base System
           Version: 15.1-STABLE
          Hardware: amd64
                OS: Any
            Status: New
          Severity: Affects Only Me
          Priority: ---
         Component: kern
          Assignee: bugs@FreeBSD.org
          Reporter: shantanna@hotmail.com

## Summary
`reboot(RB_REROOT)` panics the kernel when the target ZFS pool is
already imported at the time of the call. This is a regression from
FreeBSD 15.0, where the same flow worked correctly. Affects bare-metal
and VM deployments equally.

## Environment
- FreeBSD 15.1-STABLE (stable/15-n283579-49937a6face3), GENERIC, amd64
- GELI-encrypted ZFS root (AES-XTS-256)
- Boot chain: initramfs → GELI attach remotely → zpool import → reroot

## Steps to reproduce
1. Boot any minimal FreeBSD environment (initramfs, rescue, mfsBSD)
2. Import a ZFS pool without mounting:
   `zpool import -f -N zroot`
3. Mount the root dataset temporarily:
   `mount -t zfs zroot/ROOT/default /mnt`
4. Set kernel environment:
   `kenv vfs.root.mountfrom="zfs:zroot/ROOT/default"`
5. Execute: `reboot(RB_REROOT)`
6. Kernel panics

## Expected
Kernel unmounts the current root, mounts `zroot/ROOT/default` at `/`,
starts init from the new root. Clean reroot without full reboot.
GELI devices survive (GEOM classes persist across reroot).

## Actual
Kernel panics in `vfs_mountroot()`. The ZFS root dataset is already
mounted at `/mnt` (step 3). ZFS returns EBUSY because the dataset
cannot be mounted at two locations simultaneously.

## What we tested
| Pool state before reroot | Result |
|--------------------------|--------|
| Imported, dataset mounted at /mnt | Panic (EBUSY) |
| Imported, dataset unmounted | Panic |
| Exported entirely | Panic (kernel cannot re-import without GELI re-attach) |

All variants panic. The pool state does not matter.

## Workaround
Execute `chroot /mnt /sbin/init` from PID 1 instead of reroot.
Works reliably but has side effects (nullfs deadlocks between
datasets, `mount` shows `/mnt/` paths).

## Suggested fix
During `RB_REROOT`, `vfs_mountroot()` should handle already-imported
ZFS pools by either:
a) unmounting the dataset from its current location before mounting
   at `/`, or
b) moving the existing mount point

## Related
- FreeBSD commit 4453ec5 (Dec 2025): `reboot -r` behavior change
- OpenZFS issue #18542 (same bug, ZFS-side perspective)

-- 
You are receiving this mail because:
You are the assignee for the bug.