Its almost certainly not even unsafe, it just means that due to the race we
needed random data in boot before we could have any.
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/open
One possibility:
One of the recent pre-stable updates came with an image format
update, which older pkg won't be able to read
Another possibility:
The same update is umask-sensitive, so if you have a restrictive
umask, /var/pkg will become unreadable (making it 0755 again should
wake things
That sounds like the pkg in the zone didn't get updated, and doesn't
speak the new image format (which the pkg in the GZ updated it to).
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/list
On Mon, Jun 25, 2012 at 10:37 PM, Gordon Ross wrote:
> UFS root should still work, also NFS root (convenient for ZFS debug work:)
>
As concepts within illumos, yes.
With the full OI distribution, doubtful.
-- Rich
___
OpenIndiana-discuss mailing list
On Wed, Jul 4, 2012 at 9:49 PM, Dan Swartzendruber wrote:
> I downloaded a PDF on the new zfs feature flag stuff. I'm not sure what
> 5000 means, but I'm not worried now. I don't think I'll upgrade the data
> pool yet though.
5000 is an arbitrarily high number, to provide separation between the
The version of gcc 4.4.4 in a5 was packaged incorrectly, and as
botched file permissions. Don't use it, use gcc-3.
Jon, any chance of getting this fixed before it bites more people?
(Also: is the package really 'gcc'? that's unfortunate, I thought it
was being kept to the side for the 151 builds?
When you've installed the system, you should be able to install the
driver into the root we created (mounted at /a, I believe),
You then should be able to run add_drv -R /a ...
I think the bootarchive will be automatically recreated when you
reboot, but you could run bootadm update-archive -vR /a t
Assertions are a necessary aid to debugging, do not disable them in a
default environment, be in the live CD or post-install environment.
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/lis
Is there any possibility that you've cloned a zone onto that data pool?
zfs list -o
name,org.opensolaris.libbe:parentbe,org.opensolaris.libbe:active,org.opensolaris.libbe:uuid
Would probably be useful output to see. It's telling you what it
claims to be, that you have a single zone with multipl
If you save the dump (savecore), extract it (savecore -vf vmdump.0 -d
.), and run mdb (mdb unix.0 vmcore.0)
What does:
f7f9a9c5::whatis
say? The stack looks reasonable enough that I'm wondering if you have
a module loaded someone's stripped that's actually at fault, rather
than it bei
Sorry, you have to run savecore twice.
Once:
# savecore
should write out the vmdump.0
The second
# savecore -vf vmdump.0
Will extract it.
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman
Ruled out what I was wondering. I'd file an illumos bug describing
the configuration, etc, and make the crashdump available somehow.
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinf
This looks a lot like: https://www.illumos.org/issues/3436 I have no
idea whether that fix is in OpenIndiana. One workaround is to stop
using ld -r.
I have no idea what your build process is doing though, because it
appears to believe it's building an archive library, but is using ld
-r, so is a
Did the system reboot, or turn itself off?
If it rebooted:
When it came back, did it say it panicked?
Anything in 'fmadm faulty'?
Does running 'savecore' produce a dump?
If it powered off:
I have for a while had a suspicion that we may sometimes shut
ourselves down based on thermal info,
I didn't think Milan was done updating JDS. I'd assume someone is
very confused. Especially since "Update to this other piece of
software" hardly resolves the bug in what _is_ shipping.
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@
On Sat, Dec 4, 2010 at 10:26 PM, Harry Putnam wrote:
> But is there not a pkg with a collection of the basic dev tools?
developer/gnu should be there, I think
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://open
On Dec 24, 2010 11:07 AM, "Anil" wrote:
>
> Cool, thanks. One more question for everyone?
>
> Is it safe to upgrade global zone from 2009.06 -> 134 -> 148, but
> upgrade the non-global zones from 2009.06 -> 148? (I am wondering if I
> can skip the intermediate upgrade to 134 for zones)
The global
> There does not appear to be a way to tell pkg
> "use exactly this version:timestamp".
I think the "pkg update" changes of Shawn's allow that, but I don't recall
when they landed.
Really I thought giving the full FMRI to"install" worked, though.
-- Rich
_
You shouldn't need to do anything, the functionality formally provided by
SUNWcry* (the encryption kit) was
folded in the base OS a couple of years ago.
Forcing an install would (I think) be a really bad idea.
-- Rich
___
OpenIndiana-discuss mailing lis
On Mon, Jan 31, 2011 at 12:51, Brett Dikeman wrote:
> On Fri, Jan 28, 2011 at 4:43 PM, Richard Lowe wrote:
>> You shouldn't need to do anything, the functionality formally provided by
>> SUNWcry* (the encryption kit) was
>> folded in the base OS a couple of years ago
> We should probably slim the LiveCD down a bit. Presumably if we built 151a
> consolidations,
> and used distro-const from 151a, we'd end up with a CD rather than a DVD.
I suspect the locale changes necessary for use with illumos may push
this around some.
I had wondered if the over-size was par
If this is the change reflected in the termio TAB* setting, this also
breaks emacs TRAMP unless a
workaround is applied.
It's very annoying.
If it _is_, 'stty tab0' restores the behaviour you're wanting (per terminal)
-- Rich
___
OpenIndiana-discuss ma
::cpuinfo and ::stacks would be good to see.
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
The rationale included the words "SPARC V9 ABI", if I recall
correctly. It's not changing.
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
If you're crashing, you want to add '-k' to the boot arguments as well
as -v, etc. to load the debugger, which should give you time to read
panic messages etc.
If with -k it stops at the debugger, the most useful thing is probably
to include the panic-related output from the debugger's $ /mnt
Up
That's part of the messages you get if the systems panics prior to the dump
device being configured.
Boot with -kv added to the kernel$ line in the grub configuration (hit 'e'
to edit.) And it should stop in the debugger and give you time to read the
message. The '$http://openindiana.org/mailman/
I think this got swallowed up by milek's work on making it an actual
interface, try:
zfs set sync=disabled (other values are "standard", and "always")
I suspect it may not have made it into the manual pages we currently have.
-- Rich
___
OpenIndian
pkg contents -Ho fmri -t depend
If the package isn't installed, you'll need to add '-r'
You can filter the type of dependency with '-a'
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/lis
The best thing to do is likely to file an illumos bug
(http://illumos.org/issues/illumos-gate) and possibly post to
develop...@lists.illumos.org. I'm not sure what the overlap of this
list, zfs-code, and developers@ is.
-- Rich
___
OpenIndiana-discuss
Illumos folded our ones into the same packages as the software.
I thought OI followed, but a small number could have been misplaced.
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo
On Wed, Sep 14, 2011 at 10:36, Peter Tribble wrote:
> So I thought I would try 151a on a test system I've had sitting around
> (it's a white-box pentium4 machine).
>
> Two issues I would like to sanity check before I submit bugs:
>
> 1. The network appears to be driven by iprb, and doesn't work. I
On Wed, Sep 14, 2011 at 16:05, Cyril Plisko wrote:
> cis:~$ pkg search zfs.1m
> INDEX ACTION VALUE PACKAGE
> basename file usr/share/man/man1m/zfs.1m pkg:/system/manual@0.5.11-0.148
> cis:~$ pkg info system/manual
> pkg: info: no packages matching the following patter
This might be #944 (https://www.illumos.org/issues/944), which has
symptoms that are remarkably annoying to track to their cause.
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/op
On Sun, Sep 25, 2011 at 03:36, Ian Collins wrote:
> On 09/25/11 07:06 PM, Richard Lowe wrote:
>>
>> This might be #944 (https://www.illumos.org/issues/944), which has
>> symptoms that are remarkably annoying to track to their cause.
>>
> It could be, but I wonder w
> Alas the patch didn't do the trick. It looks like the problem is with
> packages from the OI repro:
>
> Creating Plan |pkg: No matching version of SUNWadmap can be installed:
> pkg://openindiana.org/SUNWadmap@0.5.11,5.11-0.151:20110912T025048Z: This
> version is excluded by installed incorporati
Sun C 5.10 is Studio 12u1. It seems to explicitly want something prior to that.
I don't have answers to any other part, but installing 12u1 shouldn't
help you at all, based on the above.
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@
On Fri, Nov 18, 2011 at 11:43, Geoff Flarity wrote:
> Hi,
>
> Has the IO Throtting work that Joyent has done made it's way into
> Illumos/Open Indiana yet?
No.
> Is this on the horizon?
I'd like it, but there were a couple of performance concerns they were
trying to work out with the other ZFS
You need to have EPT, certainly.
Joshua and I did some work to make shadow paging work again on the
AMD, and got to the point where it did for he and I, but seemingly not
for anyone else :\ It'd be a good place to start for anyone wanting
to remove the EPT requirement though.
-- Rich
__
On Fri, Dec 9, 2011 at 07:32, Robar Philip wrote:
>
> I’m not a chat room user so I’m wondering, has anyone looked into how much of
> a performance hit (if any) illumos and OpenIndiana are going to take by
> switching from Sun’s compilers to GCC?
Yes.
-- Rich
_
That's a bug in spawn.h, already filed with illumos.
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
constype will _always_ display vgatext for that board regardless of a
correctly configured X. It's displaying the kernel driver attached to
the framebuffer which is driving the console, not the X driver.
The other response regarding explicit configuration, etc, is probably
the best way to figure
The most foolproof way is to pkrecv the packages into a local repository
first
-- Rich
___
OpenIndiana-discuss mailing list
OpenIndiana-discuss@openindiana.org
http://openindiana.org/mailman/listinfo/openindiana-discuss
the traditional reason to back publish or republish package/pkg has been to
fix bugs affecting upgrade, so this is intentional, though perhaps outdated.
Its not a bug anywhere, though it'd be nice if onu checked ahead of time
somehow to save trouble.
Workarounds.
- update pkg in the current BE.
This happens, pretty much always, because something on which the
package depends would also be upgraded and _really does_ require a new
BE.
Do an install -nv, look at what would be changed.
I highly doubt anyone is adding reboot-needed to random packages.
-- Rich
___
Vague recollection that the pool level is errors that weren't
recovered, so possibly two of them on the device were ditto'd
metadata? (I'm very unsure on both counts).
Otherwise, as Chris said, iostat is particularly difficult to trust.
No matter what the error (even if, indeed, the drive or tran
If you get a crash dump, can you provide it? Is this a machine with
an x2apic? If it is, have you disabled it?
(there's at least one known issue with complete, solid, system hangs
on machines with x2apics).
That said, if you were triggering the deadman regardless something is
clearly wrong that
Description fields are omitted when they would otherwise just duplicate the
summary.
--
-- Rich
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
Were there other messages prior to that one? This might be the bug that I
encountered and Toomas (Cc'd) gave me a fix for.
On Thu, Feb 9, 2017 at 9:07 AM Dirk Willems wrote:
> Hello OI,
>
> Today I want to switch over from my ubuntu desktop to OpenIndiana.
> But I experience some issue, I creat
This version of illumos has the bad version of the fix for 8362 in it,
which we backed out yesterday.
Boot an old BE, update illumos again (presuming OI has rebuilt), and you'll
probably be ok.
--
-- Rich
___
openindiana-discuss mailing list
openindian
This ksh93 having over-many broken builtins thing has bitten people
before, especially this one which can cause problems in autoconf.
Do we have a bug filed to remove them? We should.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana
The relevant result of an illumos 'make closedbins' is:
closed-bits/kernel/drv/lsimega.conf
closed-bits/kernel/drv/usbser_edge.conf
closed-bits/kernel/drv/amd64/lsimega
closed-bits/kernel/drv/amd64/mpt
closed-bits/kernel/drv/amd64/adpu320
closed-bits/kernel/drv/amd64/atiatom
closed-bits/kernel/drv
Ar Gwen, 5 Gorff 2019 am 03:27 Till Wegmüller
ysgrifennodd:
> What I am wondering is what those iconv .t files are.
Sorry, I missed this. I _think_ these are translation tables for a
keyboard driver. Possibly a very very very ancient keyboard driver.
I do not know why they're still packaged.
_
I think that might have been the case with the old closed iconv(1),
but we don't use that any longer.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss
I filed 11466 remove old closed iconv tables
(https://www.illumos.org/issues/11466)
if someone wanted to take a crack at this.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-d
The linker generates output of the same form as its input (32 or
64bit, x86 or sparc). Anything happening other than that is happening
through the compiler front end.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openi
History is recorded for the user only. If you don't use it you could purge
it.
Flushing the cache on success is fine too, anything it needs again will
just get redownloaded.
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https:
On Thu, Apr 22, 2021, 08:40 Reginald Beardsley via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:
> Do kernel modules load in a consistent order?
>
No
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://op
I don't know about python. eventlog.dll is weird smb compatibility.
Gordon (cc'd) can probably fill you in on that.
-- Rich
On Tue, Jun 22, 2021, 16:32 Reginald Beardsley via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:
> I'm working on system image audit tools and found th
A good thing to do is to get into mdb when it's hung, and see where we
are with the ::stacks command.
https://illumos.org/books/dev/debugging.html has other tips.
I would add if you set the 1 bit of `moddebug` when you're in kmdb (I
think moddebug/W 8001 is verbose and stop on _init, but I ten
The challenge of answering that is you often don't know the answer
until you see it
The ::stacks command will give you asummarized view of every kernel
thread's stack
the ::cpuinfo -v command will show you what the CPUs are doing now (or
were doing, before you got into kmdb).
Both or either might
60 matches
Mail list logo
