Re: [OmniOS-discuss] trouble compiling OmniOS

2013-02-22 Thread Theo Schlossnagle
You have two choices and both should work equally well: If you want to run latest stable (that happens to be r151004) you'll need to use the r151004 branch of omnios-build: git clone -b r151004 a...@src.omniti.com:~omnios/core/omnios-build If you want to dev stuff, it may be better to use

Re: [OmniOS-discuss] trouble compiling OmniOS

2013-02-22 Thread Eric Sproul
Hi Kent, We need to spruce up the build instructions; as you've noted, they are a little sparse in places. Generally when we (OmniTI) are building new illumos bits, we are doing so on bloody. The master branch of the build repo assumes you're on bloody, which is why it's indicating gcc47 instead

Re: [OmniOS-discuss] Preconfigured distributable OmniOS NAS with mirrorred USB sticks

2013-02-22 Thread Theo Schlossnagle
This sounds really nice. On Fri, Feb 22, 2013 at 3:09 PM, alka a...@hfg-gmuend.de wrote: about a ready to use mirrorred USB based NAS/SAN OmniOS is more and more my first choice for a NAS or SAN solution. With newer and faster USB sticks and disabled atime there is nearly no difference to a

Re: [OmniOS-discuss] [SPAM] Re: Preconfigured distributable OmniOS NAS with mirrorred USB sticks

2013-02-22 Thread Rob Logan
about a ready to use mirrorred USB based NAS/SAN cool... I did that too http://rob.com/lancair/2013.01/usb.jpg but for USB write leveling we might want research what files to link to /tmp (ramdisk) /var/adm/messages /var/adm/wtmpx Rob

Re: [OmniOS-discuss] [SPAM] Re: Preconfigured distributable OmniOS NAS with mirrorred USB sticks

2013-02-22 Thread alka
I avoided USB with Solaris for a long time due to performance and reliability problems. Modern USB sticks are fast and reliable especially when combined to a ZFS mirror Now I am more and more convinced, that booting a ZFS SAN is best done via mirrorred USB sticks. No other method is as

Re: [OmniOS-discuss] trouble compiling OmniOS

2013-02-22 Thread Kent Watsen
On 2/22/13 3:29 PM, Eric Sproul wrote: buildctl has rather bit-rotted-- we don't really use it much internally. Nevertheless, what buildctl expects for names is the package FMRI, e.g. "developer/build/autoconf", because it has scraped those from the PKG