Let's recap.
What Happened:
(1) Your GhostBSD installation was on ZFS (OpenZFS 2.2.6).
(2) You mounted or imported the ZFS pool on Devuan Linux, using an older or different OpenZFS version (2.1.x).
(3) Linux OpenZFS misunderstood GhostBSD's ZFS metadata (probably because of newer features like vdev_zaps_v2) and corrupted the Meta-Object Set (MOS) and/or dataset trees.
- Result:
(1) Pool header (zpool status) looks fine: zroot ONLINE.
(2) Pool inside (zfs list, zfs mount, datasets): empty or wiped.
(3) No /ROOT/default filesystem, no datasets, no data.
In short:
(1) ZFS pool survived.
(2) ZFS filesystem hierarchy (datasets, snapshots, BE's) is gone.
(3) Your /boot/zfsloader is missing because there is no /boot directory anymore in the datasets.
Why this happens (even on FreeBSD / BSD)?
(1) ZFS trusts its metadata structures too much.
(2) When you open a pool with a wrong OpenZFS version (older or experimental), it assumes everything is fine, even if it does not fully understand new feature flags or metadata.
(3) ZFS does not warn, it will mount the pool and then silently destroy or misinterpret important internal structures.
(4) ZFS assumes "you know what you are doing" when moving pools between systems.
Super Stability Myth:
(1) ZFS is very stable inside one operating system with matching OpenZFS versions.
(2) Cross-platform operations (FreeBSD -> Linux, Linux -> Windows) are dangerous unless the OpenZFS versions exactly match.
(3) No filesystem in the world can survive incorrect software handling.
(4) BSD did nothing wrong here; it is OpenZFS design itself that has this weakness.
Next steps:
(1) Push for Devuan to upgrade its OpenZFS packages to at least version 2.2.6.
(2) Encourage the OpenZFS project to implement stronger safeguards when handling cross-version imports, so that users unfamiliar with ZFS internals do not accidentally destroy their data.
