Re: [oi-dev] Memory use with Firefox
On Thu, 11 Jan 2024 at 09:09, Alan Coopersmith wrote: > On 1/11/24 03:17, Matthew R. Trower wrote: > > What's up with your Xorg, though? 2.5GB? Your display server is nearly as > > fat > > as your Firefox :O > > Xorg maps VRAM from your video card, so you need to use pmap on the process > to see how much is heap allocation (regular ram) vs. memory mappings. Would the device mapping for video RAM show up as RSS though? I'd obviously expect it to be in SIZE. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Memory use with Firefox
On Thu, 4 Jan 2024 at 08:54, Gary Mills wrote: > Why are there so many firefox processes? I was expecting one process > per tab. Clearly there are many more. Why do some of the processes > have so many threads? How much memory does firefox want? Firefox increasingly uses multiple processes as a measure of isolation between different fault and security domains; if there is a vulnerability or a bug in some code, it need not impact all the other tabs necessarily. You can ask Firefox for more information about the processes it has started by entering "about:processes" and "about:memory" into the URL bar. I believe the process ID is in parentheses on each line in the list that represents a process. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] rebuilding system/xvm/xvmstore ?
On Thu, 19 Oct 2023 at 11:58, Alan Coopersmith wrote: > The source code was in the xvm gate, used for Sun's Xen port for OpenSolaris. > I don't know if anyone kept a copy of that gate around - I don't see it on > https://hg.openindiana.org/ . > > The package was created by converting the SVR4 package created from that gate > to IPS using the old distro-import tool: > https://github.com/oracle/solaris-ips/blob/40deb36077c33ef6717ef5ddaf3b895e8b2ec1fd/src/util/distro-import/133/i386/system%3Axvm%3Axvmstore > > I suspect it should just be obsoleted/removed now if you're not running the > Xen hypervisor from xVM, along with any other system/xvm/* packages. I would definitely be inclined to remove and obsolete it. There's never enough time to get everything done, but the Xen bits in illumos are ancient and on the path to eventual removal via IPD 23: https://github.com/illumos/ipd/blob/master/ipd/0023/README.md Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] libstdc++.so version
On Wed, 14 Sept 2022 at 09:29, Andreas Wacknitz wrote: > > # pkg contents -r system/library/g++-4-runtime | grep libstdc++ > > usr/lib/amd64/libstdc++.so > > usr/lib/amd64/libstdc++.so.6 > > usr/lib/amd64/libstdc++.so.6.0.20 > > usr/lib/libstdc++.so > > usr/lib/libstdc++.so.6 > > usr/lib/libstdc++.so.6.0.20 > > # > > > Yes, I sometimes forget about this old version. I want to get rid of it > but alas rustup is using this version. Rustup does not use the dynamic libstdc++, it uses these: /usr/lib/64/libssp.so.0 /usr/lib/64/libgcc_s.so.1 As far as I know, libgcc_s.so.1 and libssp.so.0 are generally backwards compatible, so it seems like it would be fine to ship a mediated symlink for those paths into /usr/gcc/7/lib/amd64 or whatever. The only reason we use the "system/library/g++-4-runtime" package at all for Rustup is that libssp.so.0 is shipped in that package by mistake, rather than in "gcc-4-runtime", even though it's not really a C++ thing. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] problems publishing rust
On Sun, 19 Jun 2022 at 03:31, Gary Mills wrote: > On Sat, Jun 18, 2022 at 03:49:33PM +0200, Friedrich Kink via oi-dev wrote: > > I try to prepare new rustc package with current version 1.61.0. So far > > building and installing is already working. But publishing respectively make > > REQUIRED_PACKAGES immediately bails out with the following error message: > [...] > > truss shows that make REQUIRED_PACKAGE really tries to open the file > > /usr/share/src/myoi-userland/components/developer/rust/RESOLVE_DEPS= Any > > idea what goes wrong here? To simplify things I just used sample manifest > > p5m file to exclude home made errors. > > First of all, I'm pleased that somebody else is working on rust: I > thought I was the only one. > > I anticipated that the upgrade would be difficult, but it's essential > to upgrade any packages that still use clang-90 . Rust is one of > these. Consequently, I did the upgrade by stages. The first stage > was to build and publish the original rust package with no change. > I found I had to make one change: COMPONENT_PRE_CONFIGURE_ACTION > had to copy files, instead of creating symlinks or hard links. Then, > build and publish were successful > > Subsequent stages were to upgrade clang, to upgrade python, and to > convert the Makefile to the new style. I'm still stuck in the second > stage. You clearly have gotten further. I found many things that did > not work, but nothing successful. The original rust version (1.44.1) > is too old to build with clang-13. I chose 1.60.0, since it had a > bootstrap archive available from Joyent. I also found that this > version will not build with the clang compilers. I had to revert to > gcc for these. Still, my builds terminated with this error: > > libLLVM-14-rust-1.60.0-stable.so is missing > > I don't know how to get past that error. I would be inclined to try this strategy: - use rustup to get a bootstrap compiler, as the Rust project builds official illumos binaries see: https://rustup.rs for instructions - use GCC, not Clang - use the Rust-provided static LLVM, not the shared LLVM provided by OI this should be fine as of the resolution to: 14250 ld should resolve discarded COMDAT symbols against their mates https://www.illumos.org/issues/14250 Let me know if this doesn't work, because there is likely some bug that we can fix upstream, etc. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Error building a zrepl package for OI
On Fri, 15 Apr 2022 at 13:23, Gary Mills wrote: > On Fri, Apr 15, 2022 at 07:16:02PM +0100, Peter Tribble wrote: > > > >The environment variable GOPATH is set to the root of the zrepl source. > >Any other value will work. If unset, then ~/go, but that's not always > >ideal. > > Thanks. I assumed it had to exist. It's the opposite: it had to > not exist, because that's where go will download packages. > > >The common pattern in oi-userland (see eg > >components/sysutils/chezmoi/Makefile) > > That is my model. Obviously a good choice. > > >is > >COMPONENT_BUILD_ENV += GOPATH="$(SOURCE_DIR)/gopath" > >COMPONENT_INSTALL_ENV += GOPATH="$(SOURCE_DIR)/gopath" > > Yes, that worked for me. You may wish to investigate setting GOCACHE to somewhere contained as well, which is a somewhat newer feature. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What changed between glib versions?
On Thu, 31 Mar 2022 at 18:19, Gary Mills wrote: > On Thu, Mar 31, 2022 at 04:48:04PM -0500, Gary Mills wrote: > > Ah, that behavior makes it much more difficult to diagnose the > > problem. Intermittent operation is not something I even considered. > > Could there be a critical timing someplace? I don't know how you > > would even answer that question. > > The only thing I can think of that occurs at a random time is signals. > Linux signal handling is quite different from illumos signal handling. > Both OSes can lose repeated signals. > > The other pecularity, although not entirely random, is that hal writes > UTF strings to a pipe, and reads them back from the same pipe. Pipes > also are quite different between Linux and illumos. In particular, > illumos pipes use streams, and require a context switch before the > packet can move along the pipe. A few things: - though we support STREAMS-compatible pipes, we use a more direct fast path by default; see use of FIFOFAST - nobody can support pipes without context switching, pipe reads and writes requiring interaction with the kernel, and often lead to another process, so there are usually at least three contexts involved Even through all of this, though, there will likely always be at least minute differences in timing between the platforms. If the code is correct, this will not matter. The only way to solve this problem will be to debug exactly what's going wrong, whether it's in glib or HAL or somewhere inbetween. Some previous mail to the list that includes some debugging I started on in June: https://openindiana.org/pipermail/oi-dev/2021-June/032756.html https://openindiana.org/pipermail/oi-dev/2021-June/032768.html Some combination of DTrace, truss, and mdb, is likely to help -- along with source inspection. You could conceivably even add or enable more debug logging to HAL or to glib or to both and rebuild. I don't have an OI workstation myself, which is why I haven't spent more time on this. If you decide to dig in, though, either myself or someone in #illumos IRC or on the illumos mailing list will likely be able to help with pointers once you have questions. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] update of ca-certificates ?
On Thu, 14 Oct 2021 at 10:26, s...@pandora.be wrote: > # cd /etc/certs/CA > # rm DST_Root_CA_X3.pem > # svcadm restart ca-certificates > > at the OS level - without changing anything in Squeak. I had to do this recently as well for another application. > So should there be an update of the ca-certificates package in OpenIndiana ? Yes, I believe there needs to be an update. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] questions about updating security/pinentry
On Sun, 26 Sept 2021 at 20:01, Tim Mooney via oi-dev wrote: > Finally, the security/pinentry uses symlinks to default /usr/bin/pinentry > to the pinentry-gtk2 backend. Is there a convenient method with IPS to > make that selectable by the sysadmin installing the system? Something > similar to how the system-default version of python or perl can be > changed. I think for this part you probably want to look at IPS Mediators: https://man.omnios.org/man5/pkg.5#MEDIATIORS Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] dmidecode package
On Mon, 28 Jun 2021 at 10:06, s...@pandora.be wrote: > In order to fix DDU (Device Detection Utility) for the Dell Precision > workstation, > and possibly for other computers with UEFI, perhaps dmidecode could be > packaged. > > http://savannah.nongnu.org/projects/dmidecode/ > > This dmidecode utility compiles without problems and it works for me. > > It supports UEFI and their support for UEFI seems to work on OpenIndiana. > > Once dmidecode is packaged, the DDU probe script could use dmidecode, > instead of dmi_info. > > I'm not familiar enough with DDU nor dmidecode to see whether this is a good > idea, > but it could work I guess. We actually have a library for dealing with SMBIOS in the OS today: https://github.com/illumos/illumos-gate/tree/master/usr/src/lib/libsmbios https://github.com/illumos/illumos-gate/blob/master/usr/src/uts/common/sys/smbios.h It's used by a core OS command, smbios(1M), to interrogate the SMBIOS tables for display. The same code is also used by various core OS libraries and the kernel as required. It definitely works on UEFI machines; e.g., on an Intel NUC to which I have access: $ smbios -t 2 IDSIZE TYPE 2 115 SMB_TYPE_BASEBOARD (type 2) (base board) Manufacturer: Intel Corporation Product: NUC6i7KYB Version: H90766-405 Serial Number: [REDACTED] Asset Tag: Location Tag: Default string Chassis: 3 Flags: 0x9 SMB_BBFL_MOTHERBOARD (board is a motherboard) SMB_BBFL_REPLACABLE (board is field-replacable) Board Type: 0xa (motherboard) The source for the "dmi_info" command that comes with DDU seems to be here: https://github.com/OpenIndiana/ddu/blob/oi/hipster/utils/dmi_info/dmi.c It looks like it would be relatively easy to port it to use libsmbios from the OS. You would include and link with -lsmbios and you should be able to get going. Note that there is not currently a strong stability guarantee around the libsmbios ABI, but if you pass a specific version (e.g., SMB_VERSION_34) instead of just the latest version token (i.e., SMB_VERSION, as we do in the gate) then things will probably be OK. In practice, we try pretty hard to keep existing binaries working -- and we may be able to make stronger guarantees and provide manual pages and so on if there are consumers outside the gate. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Sun, 27 Jun 2021 at 21:30, Tony Brian Albers wrote: > I was trying to use a KVM switch the other day, and I suppose this issue > is why I had to force a shutdown(power btn) of OI every time I had > switched to another machine and back again. Mouse and keyboard were > unresponsive but powered up. > > Potentially this is a lot worse than automounting of usb devices not > working IMO. At a cursory glance, it appears to be the same problem. I plugged a keyboard in to the machine while doing the same tracing as before, and I see these sysevents: EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/device@1 EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/device@1/keyboard@0 EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/device@1/input@1 I believe, if these were correctly received through the glib GIOChannel, these would end up calling into devinfo_usb_add() which would look at the driver, find that it was "hid", and then call devinfo_usb_input_add() to notify HAL consumers that there are new input devices. If someone fixes the glib channel issue, I would imagine keyboard and mouse hotplug under X11 would also start working again. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, 25 Jun 2021 at 18:52, Gary Mills wrote:
> On Fri, Jun 25, 2021 at 12:24:52PM -0700, Joshua M. Clulow via oi-dev wrote:
> > It seems like it would be good to figure out, on the systems that _do_
> > work, what exactly is performing the mount. Then we can work
> > backwards to why that is no longer happening.
>
> Good idea. I have a system running an older BE where the automount
> does work. I did exactly what you suggested.
> # dtrace -w -n '
> > syscall::*mount*:entry {
> > raise(SIGSTOP);
> > system("pargs %d; ptree %d; prun %d", pid, pid, pid);
> > }'
> dtrace: description '
> syscall::*mount*:entry ' matched 2 probes
> dtrace: allowing destructive actions
> CPU IDFUNCTION:NAME
> 10 8968umount2:entry 3951:
> /usr/lib/hal/hald-addon-storage
> argv[0]: /usr/lib/hal/hald-addon-storage
> 1994 /usr/lib/hal/hald --daemon=yes
> 1995 hald-runner
> 3951 /usr/lib/hal/hald-addon-storage
>
> 11 8532 mount:entry 3955: mount -o nosuid
> /dev/dsk/c4t0d0p0:1 /media/STORE N GO
> argv[0]: pcfs_mount
> argv[1]: -o
> argv[2]: nosuid
> argv[3]: /dev/dsk/c4t0d0p0:1
> argv[4]: /media/STORE N GO
> 1994 /usr/lib/hal/hald --daemon=yes
> 1995 hald-runner
> 3954 /usr/lib/hal/hal-storage-mount
> 3955 mount -o nosuid /dev/dsk/c4t0d0p0:1 /media/STORE N GO
>
> 2 8532 mount:entry 3951:
> /usr/lib/hal/hald-addon-storage
> argv[0]: /usr/lib/hal/hald-addon-storage
> 1994 /usr/lib/hal/hald --daemon=yes
> 1995 hald-runner
> 3951 /usr/lib/hal/hald-addon-storage
Thanks for that!
OK, so I have looked into this a little bit. It seems like there is a
bug in the HAL code we ship, or in the glib that OI is now using, or
somewhere inbetween.
With DTrace, I am able to see (in the "hald --daemon=yes" process at
the top of the HAL process tree) that it receives the appropriate
sysevents from the kernel when a USB disk is plugged in or removed.
We get as far as the sysevent_dev_handler() routine:
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L157-L191
In particular, on my system, I see three write(2) calls that look like this:
EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2
EC_devfs ESC_devfs_devi_add /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
EC_dev_add disk /pci@0,0/pci8086,2064@14/storage@2/disk@0,0
/dev/rdsk/c4t0d0 0
This seems about right. These writes are into a self-pipe (i.e., both
ends of the pipe are held open within this single hald process) that
is established in the sysevent_init() routine, and stored in the
"sysevent_pipe_fds" global where I was able to confirm with pfiles
that the pipe is still open.
Where things appear to fall down is once we get into the glib area.
The strings that are written into one end of the pipe by the sysevent
consumer, as described above, are meant to then be read through a glib
GIOChannel object in sysevent_iochannel_data():
https://github.com/illumos/illumos-gate/blob/master/usr/src/cmd/hal/hald/solaris/sysevent.c#L244-L272
Though we do enter sysevent_iochannel_data() on schedule for each
sysevent, it seems like the call to g_io_channel_read_line() always
returns a value of 3 on my system -- which seems like an EOF? Because
the value is not G_IO_STATUS_NORMAL, we don't even try to call
sscanf() to parse the lines we wrote above. This means we never call
into sysevent_dev_add() and thus we never pass the hotplug event on to
the rest of HAL.
I have run out of steam on this for now, but I hope this is enough for
someone to keep digging. In particular, it seems like it is worth
investigating whether glib has been updated in OI at some point
between when this was last working and now. Perhaps there is a build
issue or a bug there. It doesn't seem like there has been a lot of
change in the HAL daemon itself (which is in the gate, as linked
above).
One imagines this may also have an impact on the X11 keyboard/mouse
situation as those changes are presumably communicated via sysevents
to HAL, and HAL is similarly dropping the ball there.
Cheers.
--
Joshua M. Clulow
http://blog.sysmgr.org
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI no longer automounts USB sticks
On Fri, 25 Jun 2021 at 11:45, s...@pandora.be wrote:
> I can reproduce the problem;
>
> When I plugin a USB key on my OI 2021.04 latest update system it does not
> automount the volume;
>
> cdrecord -scanbus shows the USB key controller.target.disk 5.0.0 so from
> there it is also possible to deduce
>
> root@wapper:~# mount -F pcfs /dev/dsk/c5t0d0p1 /mnt
>
> that works
>
> This is USB 2 key in a USB 3.2 port for me
>
> root@wapper:~# modinfo | grep xhci
> 103 f7cef000 e8f0 251 1 xhci (USB xHCI Driver)
>
> There are also 2 USB 2 ports on my computer but that doesn't help for
> automount either.
>
> David Stes
>
> - Op 25 jun 2021 om 17:30 schreef gary mills gary_mi...@fastmail.fm:
>
> > On Sun, Jun 06, 2021 at 09:49:58PM +0200, Andreas Wacknitz wrote:
> >>
> >> service/hal is delivered by illumos-gate
> >
> > Well, hal seemed to be a good lead, but turned out to be another dead
> > end.
> >
> > Curiously, there seem to be many versions of the hal package in OI.
> > The range is enormous. I wonder why there are so many? The ones in
> > my recent BEs are service/hal@0.5.11-2020.0.1.20171 and
> > service/hal@0.5.11-2020.0.1.20514 .
> >
> > At the moment, I've run out of leads. All that I know is that a BE
> > dated 2021-05-15 has this problem but a BE dated 2020-11-27 does not
> > have it.
> >
> > Of course, if you don't use USB sticks, and don't disconnect your USB
> > mouse or keyboard, you will never experience the problem.
It seems like it would be good to figure out, on the systems that _do_
work, what exactly is performing the mount. Then we can work
backwards to why that is no longer happening.
I would probably do something like...
$ pfexec dtrace -w -n '
syscall::*mount*:entry {
raise(SIGSTOP);
system("pargs %d; ptree %d; prun %d", pid, pid, pid);
}'
dtrace: description 'syscall::*mount*:entry ' matched 2 probes
dtrace: allowing destructive actions
CPU IDFUNCTION:NAME
3 6941 mount:entry 3938: mount blah /a
argv[0]: tmpfs_mount
argv[1]: blah
argv[2]: /a
977/usr/lib/ssh/sshd
3916 /usr/lib/ssh/sshd -R
3918 /usr/lib/ssh/sshd -R
3919 -bash
3938 mount blah /a
And then plug in a device, to see what triggers the mount.
Cheers.
--
Joshua M. Clulow
http://blog.sysmgr.org
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] OI Foundation
On Wed, 26 May 2021 at 13:26, Reginald Beardsley via oi-dev wrote: > Do we need an OI specific organization? Why could this not be handled by the > existing Illumos Foundation? That was what I was going to propose. We're > using the same base OS. So far as I know, OI just adds GUI support. So having > the Illumos Foundation simply maintain a ledger entry for OI specific > financial contributions and disburse them seems much lower cost. > > Another foundation is immediately burdened by the cost of tax preparation > among other things. There is no illumos foundation today. We're just a self-organising project team. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] HP Microserver Gen8 HP Dynamic Smart Array B120i RAID Controller support
On Sat, 24 Apr 2021 at 09:35, Klaus Elsbernd wrote: > I own an HP Microserver Gen8 and want to run OI onto it. The > Installation went smooth, but I can't get the Raid Controller running. > > I had read, that omnios (?) has driver (packages) for this controller. > > Because Freenas, TrueNAS and Proxmox could access the the drives (and > access the zpools onto it), I wonder, why OI can't handle it. > > Any suggestions? Did I missed a package to install? Are you able to switch the controller from RAID mode to AHCI mode? Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [discuss] Obstacle to GPT label boot?
On Thu, 18 Mar 2021 at 18:34, Reginald Beardsley via oi-dev wrote: > Hipster 2020.10 will not install with a GPT/EFI label. Clearly stated 2 TB > limit in the installer. I was quite shocked. And annoyingly noisy about it :-( > > I am happy to fix things which cause me problems if I get some help in the > form of where to go look. Telling me to "use a search engine" is tantamount > to saying. "We don't like your kind." Google delights in generating a million > completely useless "hits". > > If there is a piece of Illumos code for booting from >2 TB disks that needs > to be ported over to OI, I'll do it if I can get answers to basic questions. > Complex stuff such as, "What are the source files?" Where is the canonical > repository?". You should take another look at the mail I sent you in February about where to find the installer source, and how to contribute: https://openindiana.org/pipermail/openindiana-discuss/2021-February/023944.html Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Firefox build - Link problems
On Tue, 9 Mar 2021 at 00:35, Carsten Grzemba via oi-dev wrote: > I attempt to build newer Firefox for OI, but my results alwas run in core > dumps early on start or later on exit. One of them is demonstrated here. > Our current userland toolchain use gcc7, but with gcc7 I get an strange > memory allocation error of g++, so I switched to gcc10. Here cores 'js' in > libicu. libicu is build with gcc7: > > here is shown libstdc++ of gcc7 and gcc10 is loaded: > $ pldd core > core 'core' of 2496:./js > /lib/amd64/libpthread.so.1 > /lib/amd64/libsocket.so.1 > /usr/lib/amd64/libffi.so.6.0.4 > /usr/lib/amd64/libicui18n.so.66.1 > /usr/lib/amd64/libicuuc.so.66.1 > /usr/lib/amd64/libicudata.so.66.1 > /usr/lib/mps/amd64/libplds4.so > /usr/lib/mps/amd64/libplc4.so > /usr/lib/mps/amd64/libnspr4.so > /lib/amd64/libdl.so.1 > /lib/amd64/librt.so.1 > /usr/lib/amd64/libz.so.1.2.11 > /lib/amd64/libm.so.2 > /lib/amd64/libnsl.so.1 > /usr/gcc/10/lib/amd64/libstdc++.so.6.0.28 > /usr/gcc/10/lib/amd64/libgcc_s.so.1 > /lib/amd64/libc.so.1 > /usr/gcc/7/lib/amd64/libstdc++.so.6.0.24 > /usr/gcc/7/lib/amd64/libgcc_s.so.1 > > if I modify the rpath to load the gcc7 libs: > $ elfedit -e 'dyn:value -s RPATH > "$ORIGIN:/usr/lib/mps/amd64:/usr/gcc/7/lib/amd64"' js > the 'js' binary runs without core and an 'pldd' shows the libs of gcc7 only > are loaded. What was the RPATH/RUNPATH value before you modified it? It might help to use "ldd -v" on the actual binary (rather than the core) to see more details about why the runtime link editor decided to load each copy of libstdc++... -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
On Tue, 2 Mar 2021 at 07:37, Reginald Beardsley via oi-dev wrote: > There clearly is a need for a "zfs unlabel " option to remove label > cruft. I ran into the problem with a 3 TB disk 7-8 years ago. On that > occasion I was a bit more thoughtful and searched for the pool label and did > a more surgical elimination. That was actually because the problem was the > duplicate label at the end of the disk. I believe you want "zpool labelclear", as per: https://illumos.org/man/1M/zpool -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
On Mon, 1 Mar 2021 at 16:45, Reginald Beardsley via oi-dev wrote: > That a seldom used admin utility would be rewritten as a threaded application > says that those responsible for this idiocy were solely interested in adding > "threaded programming" to their resumes. I neither know nor care if the > programmer was at fault or the manager who permitted it was at fault. In any > case it is so stupid as to begger belief. Sadly I have seen many people do > something similar. If you take a look, format doesn't create any threads directly -- not that it would be a problem if it did! > root@openindiana:/jack# pstack core > core 'core' of 3749: format -e > - thread# 1 / lwp# 1 - > 080658cb init_globals (8095bd8, 0, 8047d18, 806837c, 0, fefc3bb9) + 51f > 08068385 c_disk (fef70548, fef70548, 3, 2, 4, 806d608) + 3c8 > 08065bc1 main (8047d6c, fef685c8, 8047da8, 8057e47, 2, 8047dd4) + 2b4 > 08057e47 _start_crt (2, 8047dd4, fefd0c6f, 0, 0, 0) + 96 > 08057d1a _start (2, 8047eb4, 8047ebb, 0, 8047ebe, 8047ed2) + 1a > - thread# 2 / lwp# 2 - > feeed05e __door_return (0, 0, 0, 0, feb90240, fef5b000) + 2e > feed287c door_create_func (0) + 4a > feee7551 _thrp_setup (feb90240) + 81 > feee7800 _lwp_start (feb90240, 0, 0, 0, 0, 0) > - thread# 3 / lwp# 3 - > feee7859 __lwp_park (8097828, 8097838, 0, 0, 0, 0) + 19 > feee1607 cond_wait_queue (8097828, 8097838, 0) + 5f > feee1d82 __cond_wait (8097828, 8097838) + b1 > feee1e1c cond_wait (8097828, 8097838) + 2e > fe8a4986 subscriber_event_handler (8095ce0) + 9d > feee7551 _thrp_setup (feb90a40) + 81 > feee7800 _lwp_start (feb90a40, 0, 0, 0, 0, 0) > root@openindiana:/jack# Those other threads, beyond the main thread from format that is crashing, are almost certainly from libsysevent on behalf of the disk management library. They are an implementation detail of the door calls it uses to subscribe to events about devices coming and going in the system. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!
On Mon, 1 Mar 2021 at 16:06, cretin1997 via openindiana-discuss wrote: > Could you try other Illumos to see if it's OI specific? I suggest you to try > OmniOS. If it's a generic problem for Illumos then the OI people can't do > anything, so don't blame them. It would be best to avoid the notion of "blame" altogether. If whatever problem you happen to be experiencing is generic to all distributions based on illumos, either folks from OpenIndiana or anywhere else are welcome to report bugs and to contribute fixes. At the end of the day it's all just software, the software won't fix itself, and we're all in this together. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] brand10 support broken in OI
On Thu, 4 Feb 2021 at 13:14, Klaus Ziegler - owner of sunfreeware.de wrote: > thanks very much for letting us know, is anybody picking up this very > small fix for illumos-gate? it would be really much appreciated. Anybody can submit a fix for review if it has been tested. Small fixes like this are probably a good place to get started with contribution. We have a guide to contribution that should help: https://illumos.org/docs/contributing/ If you need assistance, there are folks on the mailing list and in IRC that can help! Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Shipping the nano editor alongside with vi
On Mon, 11 Jan 2021 at 12:36, Gary Mills wrote: > On Mon, Jan 11, 2021 at 09:54:23AM -0800, Chris wrote: > > While vim(1) is my "goto" editor, and vi(1) really isn't difficult. My > > frustration > > comes in the fact that each OS implements a different version, with > > different > > keyboard macros. Which quickly made ee(1) my goto when I was working in a > > "constrained" env (like dropping to single-user), and just needed to make > > some > > simple edit(s). BTW I'm the maintainer for ee(1) on FreeBSD. ;-) > > Shall I start editor wars? I use ex, which is almost always there, > until I can install emacs. Then I'm much happier. Even though ex is > just a command-line version of vi, I've never learned vi. As per our manual: The ed utility is the standard text editor. How could it be otherwise! Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] What's wrong with Pale Moon?
On Sat, 9 Jan 2021 at 04:19, Volker A. Brandt wrote: > Hung Nguyen Gia via oi-dev writes: > > I know their branding issue. But we could easily overcome it by not build > > with their official branding, our browser will be named New Moon and > > everything is fine. Please let me know more about your decision. Thanks. > There was a long discussion on this mailing list in December 2019. > Please check the list archives for details. > > Basically, the Pale Moon developers insist that one use private copies > of a large number of libraries. If the system version of these libs are > used instead, the Pale Moon devs consider that a license violation. It may be a violation of the right-to-use licence for the "Pale Moon" trademark, but that is as far as I know not a restriction that you can really have with MPLv2.0 code. If you ship the browser without the trademarked materials such as the name and logo, I don't believe you have violated the copyright licence they advertise on their code -- even if it's not the way they would prefer you to ship the software. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] How many CPUs does OI support?
On Thu, 7 Jan 2021 at 23:53, Chris wrote: > I'm looking to help building packages. Both current, as > well as newer versions. I have a large server farm. But > primarily BSD based. As such I'm looking into a new build > box, based on an Opteron or Xeon. So before I take the > plunge. I was hoping to add as many CPU/cores as possible. > Which begs the question: haw many CPUs does OI support? I don't think you'll be able to buy a machine with more CPUs than we support in illumos. I've personally used older HP machines with 4 CPU sockets and thus a lot of cores, and modern AMD systems which have a still surprising number of cores in one or two packages. In the unlikely event that you hit a problem based on core count, I am sure it will just be a bug that can be fixed. Cheers. -- Joshua M. Clulow http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] suspend/resume in Illumos
On Tue, 11 Jun 2019 at 14:29, wrote: > On Tue, 11 Jun 2019, Toomas Soome via illumos-developer wrote: > > I’d say, anything to encourage people to try, use and join to develop > > [illumos] is very welcome. Better laptop support will definitely be > > bonus. > >Betting better graphics support would be higher on the list (yea, the > other 'dropped' project). I think there are a fair few people who would appreciate some serious elbow grease being applied to the graphics bits! Cheers. -- Joshua M. Clulow Engineer @ Joyent http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] fmemopen not found for compiling samba-4.10.0
On Thu, 21 Mar 2019 at 07:04, Alan Coopersmith
wrote:
> On 3/21/19 2:29 AM, Joerg Schilling wrote:
> > Till Wegmüller wrote:
> >> fmemopen Seems to be only from the newest iteration of the Posix
> >> Standard. We do not support that yet.
> > It is part of the standard since > 10 years. This standard is so old that we
> > have been in risk of being kicked out of IEEE because there is no new major
> > revision of the standard since 10 years.
> And it took 10 years before any OS certified compliance to that new version
> of the standard, with Solaris 11.4 being the only OS to ever do so.
>
> Realistically, GNU libc defines the set of libc API's that software expects
> today much more than POSIX does.
Indeed!
I've opened an illumos bug about this specific function:
https://www.illumos.org/issues/10578
Cheers.
--
Joshua M. Clulow
Engineer @ Joyent
http://blog.sysmgr.org
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] "Fixed Enlightenment" or "Beware of epoll"
On 11 April 2017 at 23:57, Vincent Torri <vincent.to...@gmail.com> wrote: > I can provide a fix in the build system of the EFL for the next > release, but indeed, it would be better to hide the linux emulation > layer. I can do that today I'd still like to understand the precise nature of the issue with epoll before we just paper over the problem. It might be something we can fix. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] "Fixed Enlightenment" or "Beware of epoll"
On 11 April 2017 at 22:32, Aurélien Larcher <aurelien.larc...@gmail.com> wrote: > Hi, > yesterday I figured out why EFL stopped working suddenly several (too many) > months ago: was added and one source started using silently > epoll in the main loop. > > But epoll in illumos does not implement the same behaviour as in Linux: > https://us-east.manta.joyent.com/smartosman/public/man5/epoll.5.html > and in this particular case EFL relies on a peculiarity of Linux epoll: on > illumos this produces a deadlock. Upon which particular peculiar behaviour does it depend? What is the precise nature of the deadlock? If there's real software that requires things we're not implementing, we may well need to fix the emulation layer. After all, it forms the foundation of epoll support in the LX brand as well. As an aside, the more canonical location for SmartOS manual pages is, e.g., https://smartos.org/man/5/epoll Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org https://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
improvements. Yes, it _is_ a significant undertaking. That nobody has enough time or resources to step up and commit to being responsible for the whole thing, with or without help from folks like yourself, is really the reason that it's unmaintained. I'm not trying to make out like SPARC is some kind of evil, just that there won't likely ever be enough users and engineers to feed and water it. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] Resignation
On 12 September 2014 17:28, Peter j...@zeus.net.au wrote: That's rich, a project with no stable release baseline to measure binary compatibility against won't accept patches unless ... Actually, our stated goal of FCS quality all the time means that we intend to treat _every commit_ in the gate as a stable release. Things are only integrated when they work, and once they're integrated, documented, and people are able to use them, we intend to keep supporting them compatibly. Accidents happen; negligence cannot. We may not be perfect, but we _strive_ to be, and to fix bugs (or revert integrated changes) as quickly as is possible so that the software remains unbroken. The logical solution is to maintain a stable kernel release version at OI, then use that as a baseline for patches and submit patches upstream to Illumos from OI rather than from individual developers. Working on your own distribution-specific fork of illumos-gate is a reasonable idea -- it's the model we use for SmartOS at Joyent. If your intent is to avoid work creeping up on you, I would recommend that you merge changes into your fork early, and often. At Joyent, we merge into the SmartOS fork, illumos-joyent, on most business days. I can't recall a time when we experienced serious difficulty from changes we received through these syncs. We also try to minimise our diff from upstream periodically by submitting chunks of our work for integration into illumos-gate. That will put your patches on an equal footing as those with commercial interests. No, the _only_ thing that will put your patches on equal footing with the commercial interests is to do the software engineering required to produce quality, tested changes. There are not different sets of rules for different contributors -- the same attention to quality, testing, sensible architecture, etc, is expected from all contributors. I'd ignore the FUD about legacy platforms, projects that support multiple architectures are more stable for it. I whole-heartedly agree that operating systems that run on more than one architecture are less likely to see particular classes of bugs that are hidden by some architecture-specific implementation detail; e.g. byte ordering, different core system hardware drivers, etc. Unfortunately, if there are no _active_ OS engineers using and working on a particular architecture, it will absolutely rot over time; eventually becoming an obstruction to important changes where those changes require architecture-specific work. With regard to sparc, there are a number of current chip manufacturers, Aeroflex, Fujitsu, Oracle, FeiTeng. How hard would it be to support sparc v8? What about ARM64? Robert Mustacchi, myself, and a few others, have been investigating (and in Robert's case, working on) an ARM port of the OS. It's a lot of work -- work which is entirely uninteresting to our employer, so it's a spare time project. I would love to see it completed, and hopefully we will get there in time. It's clear that Illumos isn't the right place for me to contribute directly, but the whole community will benefit if I and others like me can contribute via OI. Why is that? If you want to procure and operate SPARC hardware, to fix build issues as they arise, and to write SPARC-specific code for changes that require it, why not do it in illumos? If you (and others like you) do not step up to maintain the SPARC bits, then they truly are dead weight and need to be removed. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] [developer] initial illumos-userland
On 13 November 2011 09:29, Piotr Jasiukajtis est...@gmail.com wrote: $ hg clone ssh://ano...@hg.illumos.org/illumos-userland remote: The following repository is not allowed: remote: illumos-userland remote: remote: Contact in...@lists.illumos.org if you believe it should be available for anonymous access. abort: no suitable response from remote hg! Should be working now. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
Re: [oi-dev] 1567 oi-build generated files should use Illumos copyright header
On 4 October 2011 09:59, Guido Berhoerster g...@openindiana.org wrote: Looks good. Illumos needs to fix https://www.illumos.org/license/CDDL Yes, we do. See: https://www.illumos.org/issues/1170 I'll try and chase this up. Cheers. -- Joshua M. Clulow UNIX Admin/Developer http://blog.sysmgr.org ___ oi-dev mailing list oi-dev@openindiana.org http://openindiana.org/mailman/listinfo/oi-dev
