disko's --mode destroy,format,mount leaves the ZFS root pool imported so nixos-install can write into /mnt, but the installer script rebooted straight into the newly-installed system without exporting it. The pool stayed stamped with the live installer's hostid, which never matches the target's declared networking.hostId, so with boot.zfs.forceImportRoot = false (the deliberate, safer setting) the import gets refused on boot -- this is the stall waiting for ZFS import on baremetal-gui.
Fix: export the pool (zpool export -a, a no-op on non-ZFS hosts) right before reboot in scripts/installer/auto-install.sh, and add zfs to the script's nix-shell shebang so zpool is guaranteed on PATH even off a stock ISO.
Follow-up not addressed here: variables.nix still has placeholder disks (guiRootDisk1 = /dev/sda, guiRootDisk2 = /dev/sdb) that should be real /dev/disk/by-id/... paths before the next real install.
disko's --mode destroy,format,mount leaves the ZFS root pool imported so nixos-install can write into /mnt, but the installer script rebooted straight into the newly-installed system without exporting it. The pool stayed stamped with the live installer's hostid, which never matches the target's declared networking.hostId, so with boot.zfs.forceImportRoot = false (the deliberate, safer setting) the import gets refused on boot -- this is the stall waiting for ZFS import on baremetal-gui.
Fix: export the pool (zpool export -a, a no-op on non-ZFS hosts) right before reboot in scripts/installer/auto-install.sh, and add zfs to the script's nix-shell shebang so zpool is guaranteed on PATH even off a stock ISO.
Follow-up not addressed here: variables.nix still has placeholder disks (guiRootDisk1 = /dev/sda, guiRootDisk2 = /dev/sdb) that should be real /dev/disk/by-id/... paths before the next real install.
disko's --mode ...,mount leaves the pool imported (needed for
nixos-install to write into /mnt), and the script rebooted straight
into the newly-installed system without exporting it. That pool is
still stamped with the live installer's own hostid, which never
matches the target host's declared networking.hostId, and since
boot.zfs.forceImportRoot is false (the recommended setting, not a bug),
the first real boot refuses to force-import an unexported pool from a
different hostid -- which is exactly the ZFS-import stall baremetal-gui
was hitting after install. Exporting all pools right before reboot (a
no-op for non-ZFS hosts) clears the in-use state so import succeeds
regardless of hostid.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
disko's --mode destroy,format,mount leaves the ZFS root pool imported so nixos-install can write into /mnt, but the installer script rebooted straight into the newly-installed system without exporting it. The pool stayed stamped with the live installer's hostid, which never matches the target's declared networking.hostId, so with boot.zfs.forceImportRoot = false (the deliberate, safer setting) the import gets refused on boot -- this is the stall waiting for ZFS import on baremetal-gui.
Fix: export the pool (zpool export -a, a no-op on non-ZFS hosts) right before reboot in scripts/installer/auto-install.sh, and add zfs to the script's nix-shell shebang so zpool is guaranteed on PATH even off a stock ISO.
Follow-up not addressed here: variables.nix still has placeholder disks (guiRootDisk1 = /dev/sda, guiRootDisk2 = /dev/sdb) that should be real /dev/disk/by-id/... paths before the next real install.