ting technical challenges. One is that
the zpool and zfs version numbering space is flat, so unless the new
on-disk (and in-stream) formats can be reverse-engineered, the
compatibility story will be unusual, to say the least.
--
James Carlson 4
t does "ifconfig -a" say about the state of the interfaces? You
will see "DHCP" on the IPv6 interface if DHCPv6 is running.
- If the interface is already running DHCPv6, then try:
dhcpinfo -i bge0 -v6 DNSAddresses
(Replace "bge0" with the
/etc/resolv.conf.new
mv /etc/resolv.conf.new /etc/resolv.conf
;;
esac
exit 0
The exact details will vary depending on how you want your network to
operate.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
t; will see what I can find.
No. If you're getting output from dhcpinfo, then DHCP is running. As I
noted before "ifconfig -a" will also show you that DHCP is running.
The problem appears to be the local plumbing, not the router.
--
James Carlson 42.703N 71.076W
> then press enter, and b
> what I can see is the picture which right bottom corner is "Powered by
> illumo"
You need to turn off graphical boot as well. Use "d" in GRUB to remove
the spashimage, foreground, and background lines, and then remove
&quo
darkblue wrote:
> 2011/11/21 James Carlson
>> You need to turn off graphical boot as well. Use "d" in GRUB to remove
>> the spashimage, foreground, and background lines, and then remove
>> "console=graphics" from the kernel$ line. That should allow you
On 11/23/2011 08:28 AM, Jeppe Toustrup wrote:
Hi
I am in the process of setting up IPv6 for some servers running
OpenIndiana. Each server/zone has it's own IPv6 address which is
configured statically in /etc/hostname6. such as:
addif dead:beef:1000::11/64 up
A default gateway has been se
On 11/24/11 16:45, Jeppe Toustrup wrote:
> On Thu, Nov 24, 2011 at 22:27, James Carlson wrote:
>> Read the ndpd.conf(4) man page. And set "ifdefault StatelessAddrConf off"
>> in /etc/inet/ndpd.conf.
>
> Ah, thank you for the pointer. I tried it out and It is in
sult doesn't fit in the data structure
available. Rather than return a wrong answer, it returns no answer.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Albert Chin wrote:
> On Sun, Nov 27, 2011 at 08:04:33AM -0500, James Carlson wrote:
>> On 11/27/11 02:03, Albert Chin wrote:
>>> On Sun, Nov 27, 2011 at 12:48:39AM -0600, Albert Chin wrote:
>>>> We're running oi_151a and using it to serve up file systems
t
intended to make it work primarily with things other than routing protocols.
http://hub.opensolaris.org/bin/view/Project+vrrp/
Maybe you can find some pointers related to that ...
--
James Carlson 42.703N 71.076W
___
OpenIndiana-dis
4L) has been supported for a long time. The former
(82579LM) is more recent:
https://www.illumos.org/issues/832
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana
, each of 100GB.
I don't know if this a limitation/bug in KVM or the Solaris kernel (this
was back at oi_147).
James
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Hans J. Albertsson wrote:
> Subject says it all.
>
> I suppose so, at least one shouldn't need to do anything beyond addig a
> line in /etc/driver_aliases, right?
The line for 8086,10a7 should already be there; it's served by "igb".
--
James
d call pppoeisp" or (to do
this with debugging enabled, and debug messages written to your
terminal) "pppd call pppoeisp debug updetach".
More information about the PPP level of configuration (as opposed to the
low-level PPPoE plumbing) is a
ast at the 100Mbps level on cheap commodity hardware. If you're
seeing something else, then I think you probably have other problems.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
127.1 5667" rather than
attempting to use "0" as an alias for the local system.
It's a bit of an old Solaris bug that allows address 0 to work as a
local address (even though it's not a valid address), and there's no
guarantee that it will work on any modern Solaris
fine and when it's slow; the difference may reveal something,
- installing a network interface card that uses a different driver
(e.g., if you have Intel, install Broadcom) and see if that interface
behaves differently.
Note that you'll probably need to know a fair bi
ilding as you've always done (without stub libraries), using all the
same dependencies as you've done before, and it'll keep working.
The stubs are just a build artifact. They're generated automatically
and aren't needed after the build is
quot; parameter.
That's what sets the actual disk area available for swap. It looks
like the existing volume was set to 500MB. Try "zfs list -o
name,volsize rpool/swap".
To change the swap size, I'd do this:
# swap -d /dev/zvol/dsk/rpool/swap
# zfs volsize=2G rp
seful
responses if you described what you were hoping to accomplish by
replacing that component.
For what it's worth, the ssh that comes with OpenIndiana is well
integrated with the existing OS features and performs decently. You may
end up replicating the hard work the Sun ssh team did gett
gn differences, particularly in the area of privilege
separation.
Meaningful source patches for this sort of thing are probably at least
as hard to manage as are the sources themselves -- meaning that I
believe you'd have no real benefit to keeping
necessary occurred, and the
issues were (and are) not trivial.
But, hey, it's your system. Install anything you want on it. Much luck.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openin
am considering putting a pre-crossbow S10,
> oi148, and/or S11 on the front line here to see if the problem goes away. I
> starting to scrape the bottom of the barrel for ideas.
Those symptoms seem to point in the direction of something much broader;
a system-wide issue with interrupts, perhaps.
resting item. The server that has had the 'resets'
> where performance returns to normal but then begins the march of death has a
> link state of 'unknown' on its two vnics.
That is interesting. Unfortunately, I'm not sure what it means.
At this point I think the prime s
horization to do so. I don't
think anything about that message should relate to a "freeze-up."
It could be a symptom, though, of other issues. If this system is
intended for use as a server, it's possible that you might not want to
be using NWAM a
uration.
That's an interesting observation. When running with one port, do you
unplumb the other? Or is "one port" just an application configuration
issue?
If you run "/sbin/route monitor" when the system is working fine and
leave it running until a problem happens, do y
'm guessing that what's really going on is that you have
either interfaces, IREs, or ARP entries flapping in the breeze due to
the odd configuration on this system. "route monitor" should reveal that.
But it could be almost anything else. Looking at kstats and/or
ca
Robin Axelsson wrote:
> On 2012-01-24 21:59, James Carlson wrote:
>> Well, unless you get into playing tricks with IP Filter. And if you do
>> that, then you're in a much deeper world of hurt, at least in terms of
>> performance.
> Here's what the virtualbox m
e). Both connections have now disappeared from 'ifconfig
> -a' (also the IPv6 part is gone as well), even after a reboot, so I
> consider them permanently unplumbed. It looks like this when issuing
> 'ifconfig -a':
>
> lo0: flags=2001000849 mtu
> 8232 index 1
&
k(3DLPI)), at least on OpenIndiana.
If portability to older Solaris systems is necessary, it should be
enumerating DLPI interfaces using libdevinfo.
Piggybacking on IP isn't right at all.
--
James Carlson 42.703N 71.076W
___
OpenI
On 01/27/12 07:51, Robin Axelsson wrote:
> On 2012-01-25 21:50, James Carlson wrote:
>> By default, the first IP layer object created on a given datalink layer
>> object has the same name as that datalink layer object -- even though
>> they're distinct ideas. The
way for the kernel to find it there. And if you could do it,
then you could break the security model, so the limitation is a good thing.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openin
eone is going to a
lot of effort to make things more complex in order to avoid problems.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
what went wrong. Unfortunately, I only
remember details about the "old" one ...
> Perhaps it already does so. If not it should at
> least unplumb one connection to prevent the interference issues the
> James Carlson was talking about, or at least give warning messages about
> it
Robin Axelsson wrote:
> On 2012-01-27 15:32, James Carlson wrote:
>> What NWAM is supposed to do is configure only one usable interface
>> (guided by user selection criteria) for the system. The fact that you
>> got multiple interfaces configured is indeed an anomaly, and o
Robin Axelsson wrote:
> On 2012-01-27 16:45, James Carlson wrote:
>> Robin Axelsson wrote:
>>> On 2012-01-27 15:32, James Carlson wrote:
>>>> What NWAM is supposed to do is configure only one usable interface
>>>> (guided by user selection criteria) f
an independent
> process from the network issue or if they are directly related in some way.
It's possible that they're related. It sounds to me like this is a
pretty good clue.
--
James Carlson 42.703N 71.076W
___
OpenIndi
ot;savecore" directory; usually /var/crash. Look for files there.
Running mdb on the files and using ::status and ::stack commands might
give a good enough signature that someone could identify the cause.
(I'm not a CIFS expert, but if you gather some basic l
minating the useful BE
creation process, why not fix the broken Chef/Puppet behavior?
Modifying the current configuration makes no sense here.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndia
oute. ICMP Router Discovery can also do that. RIP-2 and OSPF
can do the same job, but are much more flexible and can provide
arbitrary network and host routes as well. If you don't use any of
those, then you have to configure the default route manually, along with
some way to ma
pful. It should identify
the process that is removing the route, which will then help focus the
issue.
What about logs?
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
han an etherstub. A simnet is a simulated Ethernet interface.
As for the "STATE unknown" bit, I believe that's because etherstubs
don't have physical links and thus don't have physical link status.
It's probably harmless.
--
James Carlson 42.703N 71.076W
- that's
sort of the definition of bridging.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
tention.
I wouldn't be much surprised, with high-speed links, to see the
performance drop to less than what you get by putting all the traffic
over one link.
But if it's worth it to you to try, then by all means, change the driver
and publish the results. ;-}
--
te NFS exports for each of the underlying
datasets -- one for Video and one for Music in this case.
Automount, of course, is your friend. ;-}
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
d they all say that you
shouldn't run DHCPv6 on a prefix, then it will not be run. If you have
no IPv6 routers (a bit of a degenerate case in the standards), then
DHCPv6 is required to run, and the system will run it, but it's almost
completely useless.
See in.ndpd(1M), dhcpagent(1M), and i
n DHCP on a given network.
With IPv6, DHCPv6 is invoked by the actions of in.ndpd, because there's
a standard Router Advertisement based mechanism that tells a node
whether DHCPv6 is in use. For v6, it should have nothing to do with NWAM.
e NWAM.
But it has little to do with how DHCPv6 works.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
ough the "prtpicl -v"
output or in the syslog messages. A key clue is seeing "usb_mid"
attaching to the device when it's inserted. That means that no standard
class driver works on that device, and you're getting the "generic"
driver that
/messages, and the files are dumped in /var/crash.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
;beadm'. Because you just imported the
pool, I suspect that won't work, and you'll have to change the
fpool/ROOT/ mount point to something temporary, and then change
it back to "/" when done.
--
James Carlson 42.703N 71.076W
__
" mount to fail.
Where there errors when you mounted these file systems? Perhaps one
saying that the system was unable to mount fpool/ROOT/openindiana
because the "/mnt" directory was not empty?
--
James Carlson 42.703N 71.076W
__
ZFS attributes; they tell you everything you might want to know.
zfs get -o all all fpool/ROOT/opensolaris
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
is that it doesn't
> quite grok zfs yet. I find myself using "zfs list" quite a bit.
>
> In any event, the confluence of comments got me to the solution. Which is
> what matters.
None of that rings true to me, b
he LAN nic?
> Does mdns have a similar issue? I discovered this by running "bssh" and
> seeing the service both on my bge0 (WAN) and bge1 (LAN) nics.
These should be the same thing -- just block UDP port 5353 in the places
where you don't want Avahi/mDNS stuff to leak.
--
Ja
information produced by
the system -- syslog output, command output, error messages, network
configuration (netstat -ni, netstat -nr, ifconfig -a) -- would probably
be helpful in chasing down problems. Again, posting that information
somewhere would be a good idea.
--
James Carlson 4
hen you'll either need to disable DHCP on rge0
so that you don't get this bogus bit of configuration, or at least
disable the DHCP default route mechanism.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Mountpeaks wrote:
> (ok, you are right James, I probed that data at different times)
> To connect, I use DSL modem, that is connected to my laptop with cable. On
> any linux distro I use "pppoe-setup" to configure my connection and it always
> works. I never use GNOM
000g driver which means any
> system that use Intel based NICs. Some people say that it most likely is
> the nwam that is the culprit of this nuisance.
Sorry; no idea. I haven't seen that sort of behavior before.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
n making a configuration file be
executable, right?
I'd make it root:root and mode 0640. /usr/sbin/named normally runs as
UID root, GID root, but if it's different on your system, you might need
to adjust. You could check by doing something like this:
ps -o uid,gid,comm -p `pgrep
argy.org/~jesus/writes/the-desktop-and-server-oil-and-water
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
with -o invalid=bypass or -o
invalid=rename to fix it up.
Or it's possible that you just need to tell tar not to do national
character set conversions that it might already be doing. Set
"LANG=at.UTF-8" in your environment and try un
to create the file. If so, then that
could just be a configuration problem on your part -- e.g., attempting
to use a national language character set when the rest of your world is
set up for UTF8.
But maybe I'm wrong about that. Someone who knows the internals of tar
better should pr
ured that's breaking UDP traffic on
port 123. Try:
ntpdate -u us.pool.ntp.org
If that works, then you'll probably want to go looking at your firewall
configuration.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-d
Gary Gendel wrote:
> On 4/26/12 12:55 PM, James Carlson wrote:
>> If that works, then you'll probably want to go looking at your firewall
>> configuration.
>>
> Thanks for the -u option. That worked fine so now I have to figure out
> what's going on. Since t
nd make sure that each interface
really does work in individual link mode.
Once you're sure that both links do work when used individually, you're
down to LACP configuration problems, possibly on the switch itself.
--
James Carl
conf and
/etc/resolv.conf.
My bet would be that /etc/nsswitch.conf doesn't have the necessary
"hosts: dns" setting ... but other problems are possible.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mail
sually no
meaningful way to "force" a failing module to load. modload won't fix it.
If you're doing something else, then please explain in detail.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing
getting that mount in place at boot time may
be slightly tougher to do on a modern Open Indiana system, as zfs works
outside of the /etc/vfstab scheme.)
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndian
here.
I think the right answer, assuming that NFS isn't working for you, is to
look into what's wrong with the service. Start with "svcs -x" and "svcs
-l nfs/server".
--
James Carlson 42.703N 71.076W
___
OpenI
Tim Dunphy wrote:
> root@openindiana:~# svcs -x nfs/server
> svc:/network/nfs/server:default (NFS server)
> State: disabled since May 7, 2012 01:57:11 PM EDT
> Reason: Temporarily disabled by an administrator.
What happens if you do this?
svcadm enable nfs/server
--
J
o it anyway, then make
sure the directory in which those files exist is world-writable so that
user "nobody" can write to them. Opening up root access isn't too
different from making everything world-writable.
If "nobody" isn't to your taste, you can set up "roo
system.
I guess if the general consensus is to keep the (in my opinion
irrational) fear alive, distributing btrfs as a separate package from
the core system would be more than enough fig leaf.
--
James Carlson 42.703N 71.076W
___
Open
Hans J. Albertsson wrote:
> I was a bit surprised to see so much near-religious reactions
> James C is to be commended for his rational answer.
Thanks. ;-}
Really, it doesn't surprise me too much.
> I was merely trying to find out if
>
> A: BTRFS would be (easily) do
administrative request to shut down or restart should
probably copy over the configuration as if you said "refresh", because
it's almost certainly what you intend, but that's just not how it works.
--
James Carlson 42.703N 71.076W
_
nnot be mapped into local users by the NFS server. Overloading it to
mean something else is a Bad Idea.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
slow external one was a Bad Thing.
It's entirely possible that the USB drivers have improved greatly since
circa 2009, and that this is just "old news," but I'm gunshy now. I
don't think I'd even attempt to use USB for an external file system,
except possibly as a backup
ount up the CD/DVD image and copy it over to a ZFS file
system, then share the copied ZFS file system as you wish.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
depends on "foo.so", so it needs that.
"foo.so" depends on "foo.o", so, even though "foo.o" doesn't exist, it
goes on to build "foo.o" from the existing "foo.c", then looks for the
".o.so" rule, and finds it.
You can
you could use a cron job to find
them if you were concerned about it.
Have you tried a google search on ".nfs files"?
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
ginal poster's opinion that these files get
in the way and that they're annoying. They're nasty, but they're part
of the game. Stick with local file systems if you really can't stand
them. :-/
> The only thing to do with these files is to remove them af
ave the
right permissions. Directory entries are just that -- directory
entries. They have the name of the object and a pointer to where the
object resides. They're not the object itself.
> I believe an option to hide them would do no harm.
Fortunately,
s
are never "in use" in any meaningful way when a file is open. In the
case of unmounting a file system, though, you're revoking access to a
set of structures that are actively in use, and that requires a choice;
either the one removing loses (EBUSY) or the one using loses (ENOEN
multiple
platforms, you'll see things that are far more jarring than that. For
example, on HP/UX, memory-mapped files (e.g., shared libraries) are
locked good and hard. You can't write to them. You can't remove them.
You can't even rename them. They end up with a big yellow
" (Shame to burn a global /64 on a simple link to
the ISP, but, well, I don't see a better way with broadcast-type
interfaces.)
If they've given you a single /64 on a non-broadcast type interface
(such as a point-to-
haven't really kept up with it since 2006, so things may well have
changed.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Gary Gendel wrote:
> On 6/7/12 12:17 PM, James Carlson wrote:
>> Gary Gendel wrote:
>>> Moving from IPV4 to IPV4/IPV6 on my home network is like peeling an
>>> onion, so I'm taking it one step at a time. :(
>>>
>>> Currently I only see the old Sol
e data paths between zones. One
is by communicating between zones via shared (loopback-mounted) file
systems.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
James Carlson wrote:
> For what it's worth (and having worked on the code in the now-distant
> past), I certainly agree with you at a high level. What you're
> describing is an "obvious" generalization of the exclusive stack
> concept. It was "obvious&
3.63797880709171295166
With the numbers you quote above, you're not actually missing any storage.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/m
y bog things down. (I'd
expect that most such programs already use setrlimit(2) to do something
reasonable here ...)
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
chipset. (It did need updates on Linux, so the failure to attach
reported here is not surprising.) An alternative might be the 'em'
driver from Masayuki Murayama.
See:
https://www.illumos.org/issues/832
--
James Carlson 42.703N 71.076W
r factor in naming is what "everyone else does." If a driver has
a well-known name because it's used on Linux or BSD or some other
system, then that's usually a good choice so that people don't get too
confused.
--
James Carlson 42.703N 71.076W
>>> ether 2:8:20:1e:4:75< here?
>>
>> Also note that you need to run ifconfig with root permissions in the
>> zone in order for it to print the MAC address.
>
> That's why it said '
On 7/4/2012 6:37 PM, Glenn Holmer wrote:
> On 07/03/2012 07:27 AM, James Carlson wrote:
>> The 82579V should use the e1000g driver, but will need updates for the
>> new chipset. (It did need updates on Linux, so the failure to attach
>> reported here is not surprising.) An
ef0f6b0 _lwp_start (fecc7a40, 0, 0, 0, 0, 0)
Weird. That looks a whole lot like this bug:
http://wesunsolve.net/bugid/id/6646104
which was fixed long ago.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenInd
boots. The same is true
for ZFS; if there's a bug, it needs to be fixed, not papered over with
another "tool."
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
d has been somehow disabled or the upstream
router is not providing complete information.
--
James Carlson 42.703N 71.076W
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
Gary Gendel wrote:
> On 7/27/12 11:02 AM, James Carlson wrote:
>> Seeing /128 means that something in that fundamental mechanism has
>> broken down. Either in.ndpd has been somehow disabled or the upstream
>> router is not providing complete information.
>>
101 - 200 of 509 matches
Mail list logo
