Hi,
I'm using 2008.11, then updated to snv_106.
When I try to share a zvol via iscsi, I get this error
iscsitgt service need to be enabled by a privileged user
I have these iscsi-related packages installed
system SUNWiscsidmrSun iSCSI Data Mover (Root)
system SUNWis
Robert Milkowski wrote:
> Hello Shawn,
>
> Thursday, February 5, 2009, 4:36:55 PM, you wrote:
>
> SW> Robert Milkowski wrote:
>>> Hi,
>>>
>>>
>>> mi...@milek-desktop:~# uname -a
>>> SunOS milek-desktop 5.11 snv_106 i86pc i386 i86pc Solaris
>>> mi...@milek-desktop:~# id -u
>>> 0
>>> mi...@milek-de
Hello Shawn,
Thursday, February 5, 2009, 4:36:55 PM, you wrote:
SW> Robert Milkowski wrote:
>> Hi,
>>
>>
>> mi...@milek-desktop:~# uname -a
>> SunOS milek-desktop 5.11 snv_106 i86pc i386 i86pc Solaris
>> mi...@milek-desktop:~# id -u
>> 0
>> mi...@milek-desktop:~# pwd
>> /export/home/milek
>> mi
Mark Fenwick wrote:
>
> I have a system with two disk's. I have installed a late build of
> Nevada on one disk and OpenSolaris 2008.11 on the other. What I would
> really like is to move both of these OS's installed in a single ZFS
> pool, then I can use both disks in the same pool. I can import t
I have a system with two disk's. I have installed a late build of Nevada on one
disk and OpenSolaris 2008.11 on the other. What I would really like is to move
both of these OS's installed in a single ZFS pool, then I can use both disks in
the same pool. I can import the OpenSolaris ZFS pool in
An additional set of changes we need for SPARC graphics support
that I've discussed in the hallway with Dave, but am writing down
before we forget:
- Fix for http://defect.opensolaris.org/bz/show_bug.cgi?id=6369
- Copy /var/svc/manifest/application/x11/x11-server.xml from an
x86 machine into
I just ran into this or a similar bug on 2008.11:
http://bugs.opensolaris.org/bugdatabase/view_bug.do?bug_id=6453407
In my situation, the zfs filesystem was not the root filesystem, but the
end result was the same. The workaround of copying /dev/null onto one
or more files, then using the rm c
On 5 Feb 2009, at 14:44, Brian Ruthven - Sun UK wrote:
>
> 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 50
During the tests I was doing with dduvall, I prstat'ed pkg, and it was
failing with 420M of memory. My system has 2Gb of RAM and was setup with
the default half RAM swap space (i.e. 1Gb of swap). The default is good
for large memory systems, but bad for small memory systems. I hope in
the futur
Robert Milkowski wrote:
> Hi,
>
>
> mi...@milek-desktop:~# uname -a
> SunOS milek-desktop 5.11 snv_106 i86pc i386 i86pc Solaris
> mi...@milek-desktop:~# id -u
> 0
> mi...@milek-desktop:~# pwd
> /export/home/milek
> mi...@milek-desktop:~# pkg search audiohd
> INDEX ACTIONVALUE
On Thu, 2009-02-05 at 07:32 -0800, Michael Schuster wrote:
> this seems to be closely related to what I saw recently (see the thread
> "strange behaviour of atheros driver(?)" on network-discuss, but don't go
> there expecting much, all there is is a suggestion of Jim Carlson's which I
> haven't
Hi,
mi...@milek-desktop:~# uname -a
SunOS milek-desktop 5.11 snv_106 i86pc i386 i86pc Solaris
mi...@milek-desktop:~# id -u
0
mi...@milek-desktop:~# pwd
/export/home/milek
mi...@milek-desktop:~# pkg search audiohd
INDEX ACTIONVALUE PACKAGE
driver_name driveraudiohd
Christian Thalinger wrote:
> Hi!
>
> This gets really annoying. Without any reason the ath0 link goes down
> and, obviously, NWAM disconnects:
>
> Feb 5 13:47:35 macbook mac: [ID 486395 kern.info] NOTICE: ath0 link down
> Feb 5 13:47:35 macbook mac: [ID 744254 kern.info] NOTICE: ath0 link up
>
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
http://src.opensolaris.org/source/xref/onnv/o
On Thu, Feb 5, 2009 at 3:22 PM, Aubrey Li wrote:
> Hi list,
>
> After upgrading my system to B106, Cap-Eye-Install doesn't work
> properly on my side.
> The following command sleep and never return.
> "$ Install -G kernel.own -k i86pc -o obj"
>
> In case I encountered a hardware issue, I tried my
Hi!
This gets really annoying. Without any reason the ath0 link goes down
and, obviously, NWAM disconnects:
Feb 5 13:47:35 macbook mac: [ID 486395 kern.info] NOTICE: ath0 link down
Feb 5 13:47:35 macbook mac: [ID 744254 kern.info] NOTICE: ath0 link up
Feb 5 13:47:36 macbook mac: [ID 486395 ke
> Ché Kristo wrote:
> > RFE filed:
> http://defect.opensolaris.org/bz/show_bug.cgi?id=6241
> >
> > I can't imagine it'll pop up for 2009.04, unless
> Sun have some secret internal project happening.
> >
> No hidden projects here ;-) However, the FUSE folks
> are working on
> providing this fun
Hello Antonello,
I tried as you suggested but it ain't work at least on my laptop. The same
result.
But as I wrote before doubling swap size to 1G solved it.
Thx,
Zsolt
--
This message posted from opensolaris.org
___
indiana-discuss mailing list
indi
On 4 Feb 2009, at 21:05, Michael Schuster wrote:
> On 02/04/09 12:56, Chris Ridd wrote:
>> On 4 Feb 2009, at 19:33, Sean Sprague wrote:
>>> Chris,
>>>
> You could also try setting the deadman timer with "set
> snooping=1" in /etc/system and rebooting.
I'll give that a go, thanks S
Hello
thx
after adding additional 512M for swap the update finished successfully.
I got the feeling that 1G RAM means 512M swap is not so perfect in every case.
Br,Zsolt
--
This message posted from opensolaris.org
___
indiana-discuss mailing list
india
20 matches
Mail list logo