Repairing an Unbootable System
ZFS is designed to be robust and stable despite errors. Even so, software bugs or certain unexpected problems 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. 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. After 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 unhealthy 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.
After 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 in the preceding text. -
Determine which pool might have problems 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 problems, as described in the
fmdump
output.