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 none milestone by using
the -m milestone=none boot option. Once the system is up, remount your root
file system as writable and then remove /etc/zfs/zpool.cache. 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 more than one pool is on the system and
you want to import a specific pool without accessing any other pools, you
must re-initialize the devices in the damaged pool, at which point you can
safely import the good pool.