[OpenIndiana-discuss] Illumos bug #1778 and oi_151a9

[Bob Friesenhahn]

On an OI oi_151a9 system with 16 cores (32 CPUs according to mpstat), 
I am running into Illumos bug #1778 
(https://www.illumos.org/issues/1778) while the system is still 
running.  This is after replacing a failed SAS drive, as well as 
problems with a USB-based pool based on a pair of USB drives.  There 
are no drives physically present which are not part of an already 
imported pool.

One of the USB drives was repeatedly considered "administratively 
removed" after being accessed for a little while (probably a hardware 
problem).  It would resume working for a short time after the USB 
cable was re-plugged.  It seems that cfgadm and zfs did not agree on 
the status of the drive.  I am assuming that this confusion is what is 
causing the problem and perhaps something has been left dangling.

The system is still up and running but now I get this when trying do a 
simple 'zpool import' with no additional pools attached to the system:

% pfexec zpool import
Assertion failed: rn->rn_nozpool == B_FALSE, file 
../common/libzfs_import.c, line 1080, function zpool_open_func
zsh: IOT instruction  pfexec zpool import

Due to this issue, I am afraid to reboot the system for fear that it 
will fail to import its currently imported pools.

Looking at the bug report I see two remedies offered.  One is by 
Josef Sipek and involves re-generating /dev/rdsk and /dev/dsk device 
entries from scratch.  Most involve disabling CPUs (presumably via 
BIOS).

Other than immediately updating the system to 'hipster', what is the 
consensus of opinion for how to solve this problem?  Is the system at 
risk of failing to reboot, or will the boot archive save the day?

Bob
-- 
Bob Friesenhahn
bfriesen at simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/