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 Ruthven - Solaris Network Sustaining - Sun UK wrote:
Can you try plumbing in the ::1 interface in the zone please? I
don't recall whether this can be done with ifconfig plumb or not
within an NGZ or whether it is a zonecfg re-configuration which is
needed.
it's very difficult to find the docs. I found this:
http://www.sun.com/bigadmin/sundocs/articles/trsoltechfaq.jsp
and i did:
zonecfg:catalogue2> add net
zonecfg:catalogue2:net> set address=::1/64
zonecfg:catalogue2:net> set physical=e1000g1
zonecfg:catalogue2:net> end
i'm not sure how it is correct?
in the zone, now:
lo0:1: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL>
mtu 8252 index 1
inet6 ::1/128
and the message "error: Failed to allocate internet-domain X11
display socket" never appears
Could you confirm this workaround, and the exact syntax? i'm not very
friendly with ipv6.
It's been a while since I've configured a zone, so I'm not the best
one to check with ;-)
On the other hand, you do end up with a ::1 address, so I guess it's
good enough.
I expected the message to go away once a ::1 addr was available.
Alternatively, try one of the workarounds in
http://bugs.opensolaris.org/view_bug.do?bug_id=6704823 and let me
know whether you can reproduce the problem. If not, remove the
workaround (unplumb the interface, etc...) and try again to confirm
the error re-appears.
none of these workarounds works in my case. But even if the error
message appears, you're able to login into the zone, so i think it's
the reason why other people doesn't complain about it.
OK, none of the documented workarounds are applicable, but adding the
interface with zonecfg is apparently good enough. It may need some
refining, but it does show that nevada NGZs are applicable to this bug.
The message shouldn't stop a shell login, but IIRC you should find
that you cannot SSH-tunnel X applications to a remote host, i.e. X
forwarding is broken.
When I originally logged the bug, I didn't check NGZ default config (I
didn't have the time to set one up and test as I was in the middle of
checking and integrating another bug fix.
I'll try and check this out (and update the bug), but I don't have a
lot of time at the moment.
Regards,
Brian
thanks for your help,
Thanks,
Brian
solarg wrote:
Brian Ruthven - Solaris Network Sustaining - Sun UK wrote:
That bug (or rather the bug it was closed as a duplicate of) is
technically S10-only because nevada (and hence opensolaris) plumbs
in an IPv6 interface by default.
Do you have the ::1 "interface" plumbed in and up? Something like
this:
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL>
mtu 8252 index 1
inet6 ::1/128
If not, then you can be exposed to this bug on OpenSolaris.
yes, i have it in the global zone:
lo0: flags=2002000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv6,VIRTUAL>
mtu 8252 index
1
inet6 ::1/128
but not in the non-global zone:
r...@ng-zone:~# ifconfig -a
lo0:8: flags=2001000849<UP,LOOPBACK,RUNNING,MULTICAST,IPv4,VIRTUAL>
mtu 8232 index 1
inet 127.0.0.1 netmask ff000000
e1000g1:8: flags=201000843<UP,BROADCAST,RUNNING,MULTICAST,IPv4,CoS>
mtu 1500 index 3
inet x.y.z.143 netmask ffffff00 broadcast x.y.z.255
r...@ng-zone:~#
gerard
--
Brian Ruthven Sun Microsystems UK
Solaris Revenue Product Engineering Tel: +44 (0)1252 422 312
Sparc House, Guillemont Park, Camberley, GU17 9QG
_______________________________________________
indiana-discuss mailing list
indiana-discuss@opensolaris.org
http://mail.opensolaris.org/mailman/listinfo/indiana-discuss
