After a while I was able to track down the problem.
During boot process service filesystem/local gets enabled long before
iscsi/initiator. Start method of filesystem/local will mount ufs, swap and all
stuff from /etc/vftab.
Some recent patch added a "zfs mount -a" to the filesystem/local start me
> Again: you may encounter this case only if...
> ... you're running some recent kernel patch level (in our case 142909-17)
> ... *and* you have placed zpools on both iscsi and non-iscsi devices.
Witnessed same behavior with osol_134 but it seems to be fixed in 147 atleast.
No idea about Solaris
Moazam,
Thanks for the update. I hope this is Roy's issue too.
I can see that format would freak out over ext3, but it
shouldn't core dump.
Cindy
On 11/02/10 17:00, Moazam Raja wrote:
Fixed!
It turns out the problem was that we pulled these two disks from a
Linux box and they were formatted
Sorry i'm not able to provide more insight but I thought some of the
concepts in this article might help you, as well as Mike's replication
script, also available on this page:
http://blog.laspina.ca/ubiquitous/provisioning_disaster_recovery_with_zfs
You also might want to look at InfraGeeks auto-
So I'm going to try to outline the problem as thoroughly as possible and
hopefully someone can help.
I have a b134 box that has a zpool on it which I created a block device on and
set to export via iscsi. That block device was imported onto FreeNAS (ZFS v6,
V0.7.1 5771) and setup as a simple st
