Sometimes you just want to prove yourself it might work. Just that.

While configuring two Solaris nodes to build a “sort of a cluster” (we called it “Moulinette”, the name should say all), I figured out how to avoid the unbearably slow Solaris 10 install: my imaginative solution is:

• create a ZFS mirrored pool on two identical disks on the “golden” node.
• Resilver the pool and install the bootblock
• break the mirror
• install the second hard-disk on the second node (and possibly a mirror for the third and so forth).

But when I booted the second system:

WARNING: pool 'rpool' could not be loaded as it was last accessed by
another system (host:  hostid: 830caa8d).

And the system start a loop of reboots.
Scratched my head a bit, then I turned to ZFS’ documentation:

“Disks are identified both by their path and by their device ID, if available. This method allows devices to be reconfigured on a system without having to update any ZFS state. If a disk is switched between controller 1 and controller 2, ZFS uses the device ID to detect that the disk has moved and should now be accessed using controller 2. The device ID is unique to the drive’s firmware. While unlikely, some firmware updates have been known to change device IDs. If this situation happens, ZFS can still access the device by path and update the stored device ID automatically. If you inadvertently change both the path and the ID of the device, then export and re-import the pool in order to use it.”

Ok. I should have known better. But this is easily solved:

ALT-A or whatever needed: just get the OpenBoot “ok” cursor and type.

boot disk -F failsafe

When Solaris booted, at the prompt type:

zpool import -f syspool

My pool is called syspool, yours could be something else of course.

Reboot the machine.

I found somebody else had the same insane idea and posted on ZFS-Discuss; a very knowledgeable guy answered providing some further detail: find it here