Repairing an Unbootable System

ZFS is designed to be robust and stable despite errors. Even so, software
bugs or certain unexpected pathologies might cause the system to panic when
a pool is accessed. As part of the boot process, each pool must be opened,
which means that such failures will cause a system to enter into a panic-reboot
loop. In order to recover from this situation, ZFS must be informed not to
look for any pools on startup.

ZFS maintains an internal cache of available pools and their configurations
in /etc/zfs/zpool.cache. The location and contents of
this file are private and are subject to change. If the system becomes unbootable,
boot to the milestone none by using the -m milestone=none boot
option. Once the system is up, remount your root file system as writable and
then rename or move the /etc/zfs/zpool.cache file to
another location. These actions cause ZFS to forget that any pools exist on
the system, preventing it from trying to access the bad pool causing the problem.
You can then proceed to a normal system state by issuing the svcadm
milestone all command. You can use a similar process when booting
from an alternate root to perform repairs.

Once the system is up, you can attempt to import the pool by using the zpool import command. However, doing so will likely cause the same
error that occurred during boot, because the command uses the same mechanism
to access pools. If multiple pools exist on the system, do the following:

Rename or move the zpool.cache file to
another location as discussed above.

Determine which pool might have issues by using the fmdump
-eV command to display the pools with reported fatal errors.

Import the pools one-by-one, skipping the pools that are having
issues, as described in the fmdump output.