[EMAIL PROTECTED] pisze:
If I'll upgrade the pool under my new BE, then I'm not able to boot
my laptop using old BE, because it doesn't support new version of ZFS.
Am I right?
If the old BE doesn't support the new ZFS version, then indeed you can't
boot.
Hi,
Thanks a lot for the
Hi all! I'm a newbie of OpenSolaris world and I'm trying to understand how
resource allocation mechanism works. In particular I didn't understand what's
the difference between dynamic reconfiguration (DR) and dynamic resource pool
mechanism? Do they work only on SPARC architectures?
Thanks!
Hi Davide,
Dynamic Reconfiguration (DR) is a hardware+software feature of midrange
and high-end SPARC systems and so it is available on SPARC only.
With DR you can add or remove to a domain a physical board (4 CPUs with
memory) on E3800-E25Ks or even a single CPU (with memory) on a M-series
Thanks a lot!
--
This message posted from opensolaris.org
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
Perfect. Slight suggestion (I'm trying it out right now with an ON build for
a bugfix I've taken far too long to get taken care of) -- if DNS isn't going
to be used, could at least /etc/host entries be entered for certain
opensolaris servers (at least hg.opensolaris.org)? Since many projects
On Wed, Oct 22, 2008 at 12:36 PM, Richard L. Hamilton [EMAIL PROTECTED] wrote:
Perfect. Slight suggestion (I'm trying it out right now with an ON build for
a bugfix I've taken far too long to get taken care of) -- if DNS isn't going
to be used, could at least /etc/host entries be entered for
On Wed, Oct 22, 2008 at 1:06 PM, Martin Bochnig [EMAIL PROTECTED] wrote:
On Wed, Oct 22, 2008 at 12:36 PM, Richard L. Hamilton [EMAIL PROTECTED]
wrote:
Perfect. Slight suggestion (I'm trying it out right now with an ON build
for a bugfix I've taken far too long to get taken care of) -- if DNS
To checkout do:
ssh://[EMAIL PROTECTED]/hg/generic_distro_bulk
password is: OpenSolarisIsGreat
(both for pull and push access!)
Correction, I forgot to add hg clone to it after I did the
copypaste, the correct command is of course:
To checkout do:
hg clone ssh://[EMAIL
On Wed, Oct 22, 2008 at 12:36 PM, Richard L. Hamilton
[EMAIL PROTECTED] wrote:
Perfect. Slight suggestion (I'm trying it out
right now with an ON build for a bugfix I've taken
far too long to get taken care of) -- if DNS isn't
going to be used, could at least /etc/host entries
be entered
That looks approximately like what I was thinking of.
How generic is it? Can it build e.g. Indiana as well as your
It is _extremely_ generic.
However, it's not complete.
Right now all it does is fetching and building
on
sfw
fox-gate
conary
Next to be integrated are caiman, the
It does *not* create any actual distro yet. All my scripts to prepare
a root proto dir and generate an iso are still on different hdds, but
not inside the distro bulk gate yet, I lost some time with getting the
most recent svn snapshot of conary to work again.
On Tue, 2008-10-21 at 05:03 -0700, Richard L. Hamilton wrote:
As to whether one really wants to spend more money that ends up in
the hands of the Chinese military, that's another story...
Give us a break, we are discussing about TECHNOLOGY
MIPS is a great architecture, way to go!!!
On a SPARC's OBP prompt you could check that.
On x86 the only way to check at which freq. your bus'es and mem are
running is the BIOS.
But it won't tell you which modules are inside.
You have to open up your chassis, I would think.
You could boot into Windows and try SiSoft Sandra, although even
What does prtdiag(1M) give you in verbose mode?
On 10/22/08, Martin Bochnig [EMAIL PROTECTED] wrote:
On a SPARC's OBP prompt you could check that.
On x86 the only way to check at which freq. your bus'es and mem are
running is the BIOS.
But it won't tell you which modules are inside.
You
This sort of information *may* be encoded in the SMBIOS records.
Unfortunately, the quality and completeness of SMBIOS data varies quite
a bit from vendor to vendor.
You can dump the SMBIOS records for DIMMs (if present) with the
following command:
% smbios -t SMB_TYPE_MEMDEVICE
rob
Mike
Thanks, I will check this tonight when I get home.
This sort of information *may* be encoded in the
SMBIOS records.
Unfortunately, the quality and completeness of SMBIOS
data varies quite
a bit from vendor to vendor.
You can dump the SMBIOS records for DIMMs (if
present) with the
On Wed, Oct 22, 2008 at 5:33 PM, Rob Johnston [EMAIL PROTECTED] wrote:
This sort of information *may* be encoded in the SMBIOS records.
Unfortunately, the quality and completeness of SMBIOS data varies quite
a bit from vendor to vendor.
You can dump the SMBIOS records for DIMMs (if present)
On Mon, 20 Oct 2008 23:16:41 +0100
Calum Benson [EMAIL PROTECTED] wrote:
On 19 Oct 2008, at 13:11, Duncan Paterson wrote:
What are the chances that this will one day rival apt for selection,
frequency of updates and speed.
It will happen a lot quicker once we have repositories in
I'd much rather see a ports type implementation than an rpm
implementation - particularly if it includes the sources.
fpsm
On Mon, Oct 20, 2008 at 6:24 PM, Mike Meyer [EMAIL PROTECTED] wrote:
On Mon, 20 Oct 2008 23:16:41 +0100
Calum Benson [EMAIL PROTECTED] wrote:
On 19 Oct 2008, at 13:11,
The most likely implementation will probably be what the pkgbuild folks
are providing, which is very much like rpmbuild.
Fredrich Maney wrote:
I'd much rather see a ports type implementation than an rpm
implementation - particularly if it includes the sources.
fpsm
On Mon, Oct 20, 2008
I'd much rather see a ports type implementation than
an rpm
implementation - particularly if it includes the
sources.
fpsm
Sources available? Darn right - some of the licenses require that, too.
Build from source as the normal method of installation? That, I think is
too slow for most
Mike Meyer wrote:
On Wed, 22 Oct 2008 11:49:36 PDT Richard L. Hamilton [EMAIL PROTECTED]
wrote:
I'd much rather see a ports type implementation than
an rpm
implementation - particularly if it includes the
sources.
Sources available? Darn right - some of the licenses require that, too.
On Wed, Oct 22, 2008 at 11:28 PM, Shawn Walker [EMAIL PROTECTED] wrote:
I would venture to guess that a significant majority of users will never
need to or want to recompile or alter the software as you suggest.
They're going to want a stable, tested version of the software, and that
means a
On Wed, Oct 22, 2008 at 11:40 PM, Martin Bochnig [EMAIL PROTECTED] wrote:
On Wed, Oct 22, 2008 at 11:28 PM, Shawn Walker [EMAIL PROTECTED] wrote:
I would venture to guess that a significant majority of users will never
need to or want to recompile or alter the software as you suggest.
On Thu, Oct 23, 2008 at 12:25 AM, Mike Meyer [EMAIL PROTECTED] wrote:
On Thu, 23 Oct 2008 00:16:03 +0200
Martin Bochnig [EMAIL PROTECTED] wrote:
On Wed, Oct 22, 2008 at 11:40 PM, Martin Bochnig [EMAIL PROTECTED] wrote:
On Wed, Oct 22, 2008 at 11:28 PM, Shawn Walker [EMAIL PROTECTED] wrote:
# LD_PRELOAD=/tmp/y/a.out conary update --resove tuxpaint
usage: conary update [+][-]pkgname[=version][[flavor]]* changeset*
Update or install software on the system
options:
Update Options:
--exact-flavors Only match troves whose flavors match exactly
--from-file=FROM-FILE
The error msg came, because options need to go last into the cmd line:
# LD_PRELOAD=/tmp/y/a.out conary update tuxpaint --resolve
___
opensolaris-discuss mailing list
opensolaris-discuss@opensolaris.org
27 matches
Mail list logo
