I suspect the correct way is to request the app is built for and
qualified for OpenSolaris (which I guess it is not at present).
Brian
Jacob Ritorto wrote:
Yeah, did that and it does work, but is that really the correct way?
Trying to be all proper on this box..
dick hoogendijk wrote:
Is this Sun's EBS software? Which version of EBS is it? Looks like 7.5
(or 7.5.1) to me.
These link against libcommonssl which in turn links against libssl.0.9.7
You may be able to downgrade the client SUNWebsc package to 7.4,
although to check the server's version - I can't remember which
Marcus Heine wrote:
Hi,
I am currently playing around with diskless Solaris (iscsi, network
booted ramdisk, etc)
and found that dumpadm allows me to configure a USB stick or an iscsi
device as a dump
device no problem, like
dumpadm -c kernel -d /dev/dsk/...
but testing this with reboot
Marcus Heine wrote:
Brian,
Brian Ruthven - Sun UK wrote:
Marcus Heine wrote:
Hi,
I am currently playing around with diskless Solaris (iscsi, network
booted ramdisk, etc)
and found that dumpadm allows me to configure a USB stick or an
iscsi device as a dump
device no problem, like
Try disabling the grub splash screen stuff, and add -k to the kernel$
line.
Then boot and see if you are getting a panic.
If so, post the output of the panic here, or search sunsolve /
bugs.opensolaris.org to see if it's an existing bug.
Brian
Luca Morettoni wrote:
I have a friend that
Ordinarily, the csh family of shells (csh, tcsh, etc...) will read
~/.login and the Bourne shell family of shells (/bin/sh, ksh, bash,
etc...) will read ~/.profile.
These are only for a login shell (usually the first shell), and the
values are then inherited by all children. Windows opened
I can't see any bugs with that stacktrace either on bugs.opensolaris.org
or defect.opensolaris.org.
I'd suggest filing a new bug (including the stack trace) at
http://defect.opensolaris.org/
Brian
Malte Hahlbeck wrote:
Hi,
Songbird crashes after I made the upgrade:
core 'core' of 2122:
Add the -k flag to the kernel$ line in grub and when it panics you will
be given the kmdb prompt. From here, you can get the stack trace by
typing $c. All this should be done in text mode (no splash screen,
etc...). There are no core files or messages because the panic probably
happens way
I had a similar problem. I believe the tracker database is somewhere
under ${HOME}/.local
I was having many other issues too, so I ended up taking an rm -rf
sledgehammer to all GNOME-related config. Fixed the tracker problem for
me. :-)
Brian
dick hoogendijk wrote:
Tracker complains
What is the output from rpcinfo within the zone? What RPC services have
registered with rpcbind?
You may find things like keyserv and nlockmgr are running (which are
dependancies for nfs/client).
You may find that disabling it will break this zone's ability to be an
nfs client (not a
This was fixed in snv_114. Unfortunately, this is not yet available via
the dev repository, so for now, I'd go with the workaround of adding the
::1 address through zonecfg.
Regards,
Brian
Brian Ruthven - Solaris Network Sustaining - Sun UK wrote:
Replies inline
solarg wrote:
Brian
Sebastien Roy wrote:
Furthermore, just turning off one service that apparently isn't
directly linked to GDM should not block GDM from running... at least
NOT without some clear warning of what is happening or about to
happen.
This much isn't related to NWAM, but I agree that there's
I'm not sure I follow your question, but I think it is this:
You are currently running snv_107 and wish to update.
The latest available is snv_111, but you cannot update to it (due to
known bugs).
So, you want to update to a release which is not the current latest, but
snv_109.
I don't
Hi Harry,
The usual clue I look for is:
Mar 18 17:21:56 opensol genunix: [ID 672855 kern.notice] syncing file
systems...
Mar 18 17:21:57 opensol genunix: [ID 904073 kern.notice] done
Mar 18 17:22:50 opensol genunix: [ID 540533 kern.notice] ^MSunOS Release
5.11 Version snv_110 64-bit
Known issue I think. Try CR 6801598 Xorg 1.5 ignores kernel keyboard
layout setting, always uses us for size.
http://bugs.opensolaris.org/view_bug.do?bug_id=6801598
There's a workaround in there too.
Brian
Gilles Gravier wrote:
Hi!
So... I updated from osol 2008.11 b106 to b107... and now
Hi Chris,
If you are talking about the delay before the clock thread declaring the
system has hung, then yes, this is tunable. The variable is
snoop_interval and the units are expressed as microseconds. Default
value is 5000 (50 seconds). See
16 matches
Mail list logo
