On Sat, Dec 7, 2013 at 10:06 AM, Tobias Oetiker t...@oetiker.ch wrote:
Following the latest instructions from your webpage, we tried this:
pkg list incorporation/jeos/omnios-userland /dev/null 21 || pkg install
incorporation/jeos/omnios-userland@11,5.11-0.151006
now, if we run
# pkg
Hi Eric,
Today Eric Sproul wrote:
On Sat, Dec 7, 2013 at 10:06 AM, Tobias Oetiker t...@oetiker.ch wrote:
Following the latest instructions from your webpage, we tried this:
pkg list incorporation/jeos/omnios-userland /dev/null 21 || pkg
install
On Mon, Dec 9, 2013 at 10:51 AM, Tobias Oetiker t...@oetiker.ch wrote:
we have installed some packages from our own repository
pkg.oetiker.ch and these packages themselfe have dependencies on
ms.omniti.com stuff.
namely the following:
$ pkg uninstall -nv libgcrypt
Creating Planpkg
This may be AMD64 specific. I haven't checked in depth, but the following
missing libraries (from miniroot.gz) prevent a successful pxe installation.
Most of them are related to zfs either in creating the filesystem or in the
implicit execution of share at the end of creating rootfs. In most cases
Chris Nehren writes:
Today Eric Sproul wrote:
pkg search -H -o pkg.fmri -l 'depend:incorporate:*@*-0.151006' |
sort | uniq
[...]
This gives me:
# pkg search -H -o pkg.fmri -l 'depend:incorporate:*@*-0.151006' | sort | uniq
pkg: Search performance is degraded.
Run 'pkg rebuild-index' to
On Mon, Dec 09, 2013 at 12:08:59 -0500, Eric Sproul wrote:
On Mon, Dec 9, 2013 at 11:51 AM, Volker A. Brandt v...@bb-c.de wrote:
So the library/uuid pkg is my problem here? That's... interesting.
Is deinstalling and not using ms.omniti.com any more the only option?
The packages in
My storage server (currently running omnios stable 151006) with an LSI
9201-16i SAS controller misbehaved this morning :(.
It started out with some complaints about a target:
Dec 9 05:18:23 storage kernel: scsi: [ID 365881 kern.info]
/pci@0,0/pci8086,3c0
a@3,2/pci1000,30c0@0 (mpt_sas0):
On Mon, Dec 9, 2013 at 4:45 PM, Paul B. Henson hen...@acm.org wrote:
I vaguely recall seeing some mpt_sas improvements flyby over the past 6-8
months, once the first update for 151008 comes out I guess I will go ahead
and upgrade to that, maybe next time things go wiggy it won't take out the
From: Garrett D'Amore [mailto:garr...@damore.org]
Sent: Monday, December 09, 2013 3:10 PM
This *looks* like its SAS drives, but can you confirm that you're using
SAS
disks and not SATA drives in an expander or converter?
I intended to mention in the original message that this was a WD red
Huh, I had recently updated all my servers' IPMI firmware as well as BIOS
recently, and didn't notice this new feature.
It's kind of interesting that they're trying to charge for it (at least
that's the assumption with an activation key). It's useful, but outside
of the fix corrupted BIOS (which
On Mon, Dec 09, 2013 at 05:23:07PM -0800, Garrett D'Amore wrote:
That's right... direct connection *with nothing else on the bus* should be
fine.
Cool. Hopefully that mpt_sas commit I'm currently lacking will keep the
controller from going wiggy next time. It cost a bit more for the 16
port HBA
On Mon, Dec 09, 2013 at 10:34:50PM -0500, wuffers wrote:
Huh, I had recently updated all my servers' IPMI firmware as well as BIOS
recently, and didn't notice this new feature.
The other new feature is a power usage/statistics screen which is kinda
cool, but only works if your power supply has
On Mon, Dec 9, 2013 at 4:45 PM, Paul B. Henson hen...@acm.org wrote:
One question; in this case, when it completely died, it ended up printing
out the wwn of the drive in question so it was easy to find. However, I'm
not quite sure how to map target 17 to an actual disk if all I had were
the
13 matches
Mail list logo
