Re: [oi-dev] SIMD support

[Toomas Soome via oi-dev]

> On 15. Feb 2024, at 18:25, Marcel Telka  wrote:
> 
> On Thu, Feb 15, 2024 at 05:09:12PM +0100, Marcel Telka wrote:
>> On Thu, Feb 15, 2024 at 06:01:16PM +0200, Toomas Soome via oi-dev wrote:
>>> 
>>> 
>>>> On 15. Feb 2024, at 17:47, Marcel Telka  wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> There[1] is this comment:
>>>> 
>>>> # We cannot build sbcl on our build server because it lacks SIMD support.
>>>> 
>>>> 
>>>> How can I check a machine does have SIMD support?
>>>> 
>>>> 
>>>> Thank you.
>>>> 
>>> 
>>> $ isainfo -v
>>> 64-bit amd64 applications
>>>fsgsbase rdseed adx avx2 fma bmi2 bmi1 rdrand f16c vmx avx xsave 
>>>pclmulqdq aes movbe sse4.2 sse4.1 ssse3 amd_lzcnt popcnt tscp cx16 
>>>sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu 
>>> 32-bit i386 applications
>>>rdseed adx avx2 fma bmi2 bmi1 rdrand f16c vmx avx xsave pclmulqdq 
>>>aes movbe sse4.2 sse4.1 ssse3 amd_lzcnt popcnt tscp ahf cx16 sse3 
>>>sse2 sse fxsr mmx cmov sep cx8 tsc fpu 
>> 
>> There is no 'simd' in your output.  Does it mean you do not have simd
>> support?
> 
> The initial comment I was referring to is misleading.  It should say
> AVX2 instead of SIMD.
> 

Well, yes, AVX is part of SIMD (SSE), and yes, AVX2 is listed as well:)

rgds,
toomas

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] SIMD support

[Toomas Soome via oi-dev]

> On 15. Feb 2024, at 17:47, Marcel Telka  wrote:
> 
> Hi,
> 
> There[1] is this comment:
> 
> # We cannot build sbcl on our build server because it lacks SIMD support.
> 
> 
> How can I check a machine does have SIMD support?
> 
> 
> Thank you.
> 

$ isainfo -v
64-bit amd64 applications
fsgsbase rdseed adx avx2 fma bmi2 bmi1 rdrand f16c vmx avx xsave 
pclmulqdq aes movbe sse4.2 sse4.1 ssse3 amd_lzcnt popcnt tscp cx16 
sse3 sse2 sse fxsr mmx cmov amd_sysc cx8 tsc fpu 
32-bit i386 applications
rdseed adx avx2 fma bmi2 bmi1 rdrand f16c vmx avx xsave pclmulqdq 
aes movbe sse4.2 sse4.1 ssse3 amd_lzcnt popcnt tscp ahf cx16 sse3 
sse2 sse fxsr mmx cmov sep cx8 tsc fpu 

rgds,
toomas___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Emacs has a bad font

[Toomas Soome via oi-dev]

> On 8. Nov 2023, at 17:36, Gary Mills  wrote:
> 
> I recently did an OI upgrade, on one of my systems, from 20220928 to
> 20231107 (more than a year).  Everthing worked normally afterwards
> except for emacs.  It has a peculiar font, compared to MATE-terminal.
> The font appears to be too thin.  I'm using the same font size as
> before, 10 point.  What could the matter be?
> 

sounds like the original font got substituted. If you start emacs from command 
line, does it tell about fonts being replaced?

rgds,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Virtualbox crash

[Toomas Soome via oi-dev]

> On 15. Sep 2023, at 09:58, Stephan Althaus  
> wrote:
> 
> Hello Carsten!
> 
> 
> I have seen your new PR to VirtualBox.
> 
> I don't understand why it is a good idea to compile packges with GCC-12 
> instead of GCC-10.
> 
> Shoudn't we stay with GCC-10 not to break further more things with an 
> additional ABI incompatibility in the line GCC-7 - GCC-10 - GCC-12 ?
> 
> What will be the next standard-compiler (after GCCC-10) for illumos/OI, 
> GCC-12 or GCC-13 ?
> 
> 
> Would you be so kind and explain it in short, or maybe present a link for 
> further reading?
> 
> Thanks!
> 
> Stephan
> 


we are planning gcc 13 (C23 features), unfortunately oi does not provide it 
yet, does it?

rgds,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Virtualbox crash

[Toomas Soome via oi-dev]

> On 28. Aug 2023, at 13:32, Carsten Grzemba via oi-dev 
>  wrote:
> 
>> 
>>> #11 0x007b1eb5 in Medium::i_queryInfo (this=this@entry=0xe004c0, 
>>> fSetImageId=fSetImageId@entry=false, 
>>> fSetParentId=fSetParentId@entry=false, autoCaller=...)
>>> at 
>>> /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Main/src-server/MediumImpl.cpp:7176
>>> #12 0x007b2dc5 in Medium::refreshState (this=0xe004c0, 
>>> autoCaller=..., aState=0xe0b1a0)
>>> at 
>>> /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/src/VBox/Main/src-server/MediumImpl.cpp:2180
>>> #13 0x009acf71 in MediumWrap::RefreshState (this=0xe004c0, 
>>> aState=0xe0b1a0)
>>> at 
>>> /code/github/oi-userland/components/sysutils/virtualbox/build/amd64/out/solaris.amd64/debug/obj/VBoxAPIWrap/MediumWrap.cpp:1344


Those are bits you want to look into, as you get throw from:

Medium::i_queryInfo+0x2ae()

rgds,
toomas___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [developer] Heads-UP Openindiana/Hipster 2023.07 for SPARC

[Toomas Soome via oi-dev]

> On 18. Jul 2023, at 21:28, Klaus Ziegler  wrote:
> 
> Hi,
> 
> after about 6 months of work, I'm very pleased to announce:
> 
> OpenIndiana 2023.07 for SPARC
> 
> this release is by far the best one I've ever done, it includes
> quite some bugfixes but also real new SPARC code changes.
> Nearly all of them, except a few ones done by myself have been
> done by Toomas Soome. I'm just the one who has brought them
> together, because I think it would be a shame if all that stuff will
> never hit the road.
> 
> Thanks Toomas !
> 
> For more details, downloads and installation possiblilities,
> please have a look at:
> 
> https://dlc.openindiana.aurora-opencloud.org/SPARC/
> 
> Many Regards
> Klaus
> 

Oops:) This is very nice of you! 

Thanks,
Toomas


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] strange compiler error

[Toomas Soome via oi-dev]

> On 4. Nov 2022, at 22:47, Friedrich Kink  wrote:
> 
> hmm but I understand the manpage that -b is the linker switch and binary the 
> input format key word, which is valid see below. And even I use it like 
> '-Wl,-b,binary` it gives the same error. 
> 

how about -Wl,-b -Wl,binary ?

rgds,
toomas

> objdump -i
> BFD header file version (GNU Binutils) 2.39
> elf32-i386-sol2
>  (header little endian, data little endian)
>   i386
> elf32-iamcu
>  (header little endian, data little endian)
>   iamcu
> coff-i386
>  (header little endian, data little endian)
>   i386
> pei-i386
>  (header little endian, data little endian)
>   i386
> elf64-x86-64-sol2
>  (header little endian, data little endian)
>   i386
> pe-x86-64
>  (header little endian, data little endian)
>   i386
> pei-x86-64
>  (header little endian, data little endian)
>   i386
> elf64-little
>  (header little endian, data little endian)
>   i386
>   iamcu
> elf64-big
>  (header big endian, data big endian)
>   i386
>   iamcu
> elf32-little
>  (header little endian, data little endian)
>   i386
>   iamcu
> elf32-big
>  (header big endian, data big endian)
>   i386
>   iamcu
> srec
>  (header endianness unknown, data endianness unknown)
>   i386
>   iamcu
> symbolsrec
>  (header endianness unknown, data endianness unknown)
>   i386
>   iamcu
> verilog
>  (header endianness unknown, data endianness unknown)
>   i386
>   iamcu
> tekhex
>  (header endianness unknown, data endianness unknown)
>   i386
>   iamcu
> binary
>  (header endianness unknown, data endianness unknown)
>   i386
>   iamcu
> ihex
>  (header endianness unknown, data endianness unknown)
>   i386
>   iamcu
> plugin
>  (header little endian, data little endian)
> 
>  elf32-i386-sol2 elf32-iamcu coff-i386 pei-i386 elf64-x86-64-sol2
> i386 elf32-i386-sol2 --- coff-i386 pei-i386 elf64-x86-64-sol2
>iamcu --- elf32-iamcu -  -
> 
>  pe-x86-64 pei-x86-64 elf64-little elf64-big elf32-little elf32-big
> i386 pe-x86-64 pei-x86-64 elf64-little elf64-big elf32-little elf32-big
>iamcu - -- elf64-little elf64-big elf32-little elf32-big
> 
>  srec symbolsrec verilog tekhex binary ihex plugin
> i386 srec symbolsrec verilog tekhex binary ihex --
>iamcu srec symbolsrec verilog tekhex binary ihex --
> 
> 
> Am 04.11.2022 um 21:34 schrieb Toomas Soome:
>> You pass -b ( to linker) but not “binary”.
>> 
>> Sent from my iPhone
>> 
>>> On 4. Nov 2022, at 22:14, Friedrich Kink via oi-dev 
>>>   wrote:
>>> 
>>> Hi all,
>>> 
>>> I try to compile the newest asterisk version, but I get the following 
>>> linker error:
>>> 
>>> /usr/gcc/7/bin/gcc -g -nostartfiles -nodefaultlibs -nostdlib -r -Wl,-b 
>>> binary -o res_geolocation/pidf_lo_test.o res_geolocation/pidf_lo_test.xml
>>> ld: fatal: file binary: open failed: No such file or directory
>>> 
>>> /usr/gcc/7/bin/gcc -g -nostartfiles -nodefaultlibs -nostdlib -r 
>>> -Wl,--format=binary -o res_geolocation/pidf_lo_test.o 
>>> res_geolocation/pidf_lo_test.xml
>>> ld: fatal: unrecognized option '--format=binary'
>>> ld: fatal: use the -z help option for usage information
>>> 
>>> according to the man page (man ld) both variants are allowed, so I'd assume 
>>> that it works (s. below)
>>> 
>>> ..
>>> 
>>> 
>>>-b input-format
>>>--format=input-format
>>>ld may be configured to support more than one kind of object 
>>> file.
>>>If your ld is configured this way, you can use the -b option to
>>>specify the binary format for input object files that follow this
>>>option on the command line.  Even when ld is configured to 
>>> support
>>>alternative object formats, you don't usually need to specify 
>>> this,
>>>as ld should be configured to expect as a default input format 
>>> the
>>>most usual format on each machine.  input-format is a text 
>>> string,
>>>the name of a particular format supported by the BFD libraries.
>>>(You can list the available binary formats with objdump -i.)
>>> 
>>>You may want to use this option if you are linking files with an
>>>unusual binary format.  You can also use -b to switch formats
>>>explicitly (when linking object files of different formats), by
>>>including -b input-format before each group of object files in a
>>>particular format.
>>> 
>>>The default format is taken from the environment variable
>>>"GNUTARGET".
>>> 
>>>You can also define the input format from a script, using the
>>>command "TARGET";
>>> 
>>> Any idea what else could be wrong?
>>> 
>>> kind regards,
>>> 
>>>   Fritz
>>> 
>>> 
>>> ___
>>> oi-dev mailing list
>>> oi-dev@openindiana.org 
>>> 

Re: [oi-dev] strange compiler error

[Toomas Soome via oi-dev]

You pass -b ( to linker) but not “binary”.

Sent from my iPhone

> On 4. Nov 2022, at 22:14, Friedrich Kink via oi-dev  
> wrote:
> 
> Hi all,
> 
> I try to compile the newest asterisk version, but I get the following linker 
> error:
> 
> /usr/gcc/7/bin/gcc -g -nostartfiles -nodefaultlibs -nostdlib -r -Wl,-b binary 
> -o res_geolocation/pidf_lo_test.o res_geolocation/pidf_lo_test.xml
> ld: fatal: file binary: open failed: No such file or directory
> 
> /usr/gcc/7/bin/gcc -g -nostartfiles -nodefaultlibs -nostdlib -r 
> -Wl,--format=binary -o res_geolocation/pidf_lo_test.o 
> res_geolocation/pidf_lo_test.xml
> ld: fatal: unrecognized option '--format=binary'
> ld: fatal: use the -z help option for usage information
> 
> according to the man page (man ld) both variants are allowed, so I'd assume 
> that it works (s. below)
> 
> ..
> 
> 
>-b input-format
>--format=input-format
>ld may be configured to support more than one kind of object file.
>If your ld is configured this way, you can use the -b option to
>specify the binary format for input object files that follow this
>option on the command line.  Even when ld is configured to support
>alternative object formats, you don't usually need to specify this,
>as ld should be configured to expect as a default input format the
>most usual format on each machine.  input-format is a text string,
>the name of a particular format supported by the BFD libraries.
>(You can list the available binary formats with objdump -i.)
> 
>You may want to use this option if you are linking files with an
>unusual binary format.  You can also use -b to switch formats
>explicitly (when linking object files of different formats), by
>including -b input-format before each group of object files in a
>particular format.
> 
>The default format is taken from the environment variable
>"GNUTARGET".
> 
>You can also define the input format from a script, using the
>command "TARGET";
> 
> Any idea what else could be wrong?
> 
> kind regards,
> 
>   Fritz
> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] hipster 2021-10 failed to boot after pkg update

[Toomas Soome via oi-dev]

> On 28. May 2022, at 16:29, Klaus Elsbernd  wrote:
> 
> Urgent help needed :-(
> 
> a server (supermicro/xeon) has been installed and upgraded to 2021-10. It was 
> last updated on 2021:12:12. Today I updated the packages with
> 
> pkg update
> 
> Now the system failed to boot into multi-user/single-user mode with the 
> following services not started:
> 
> Enter user name tor system maintenance (control-d to bypass): root
> Enter root password (control-d to bypass): single-user privilege assigned to 
> root on /dev/conso1e.
> Entering System Maintenance Mode
> May 28 14:47:56 su: ' su root' succeeded for root on /dev/console
> The illumos Project illumos-b0d58672df May 2022 root@serv-1100:/root# svcs -x 
> svc:/system/metainit:default (SVM initialization)
> State: maintenance since Sat May 28 14:46:50 2022
> Reason: Completes a dependency cycle.
> See: http://i1lumos.org/msg/SMF-8000-HP
> See: metainit(lM)
> Impact: This service is not running.
> root@serv-1100:/root# beadm list
> BEActiveMountpointSpacePolicy Created
> openindiana-2020:06:11--62.03Mstatic 2020-06-11 16:53
> openindiana-2020:08:10  --11.97Mstatic 2020-08-10 16:44
> openindiana-2020:12:29  --46.41Mstatic 2020-12-29 13:54
> openindiana-2021:01:29  --22.00Mstatic 2021-01-29 12:37
> openindiana-2021:05:06  --11.88Mstatic 2021-05-06 19:01
> openindiana-2021:05:06-backup-l  --128Kstatic 2021-05-14 15:17
> openindiana-2021:06:05  --1.906static 2021-06-05 12:21
> openindiana-2021:06:05-1  --16.68Mstatic 2021-06-05 20:08
> openindiana-2021:12:12  --14.90Mstatic 2021-12-12 17:40
> 
> open!ndiana-2022:05:28NR/  43.356static 2022-05-28 11:01
> 
> The machine is booting OpenIndiana Hipster 2021.10 version illumos-b0d58672df 
> 64-bit. Some notable errors
> 
> acpinex: cpu@0, cpudrv0
> /fw/sb@0/socket@0/cpu@0 (cpudrv0) online
> pseudo-device: cld0
> cld0 is Zpseudo/cld@0
> sorry, variable 'ip_squeue_worker_wait' is not defined in the 'ip' module
> PCI Express-device: pci,3cB2@l. pcieb0
> 
> One message appeared on the console, indicating an error with a NVIDIA 
> module. But there is no NVIDIA graphic card installed:
> 
> /kernel/drv/amd64l/nvidia.modeset: undefined symbol 'nvidia_get_rm_ops'
> WARNING: mod_load: cannot load module 'nvidia.modeset'
> WARNING: nvidia_modeset: unable to resolve dependency, module 'nvidia' not 
> found
> 
> This is the second machine I lost. The only solution was then to boot the 
> previous boot environment 2021:12:12.
> 
> Any ideas?
> 
> Klaus
> 

If you do not have nvidia card, then this message is annoying, but harmless - 
because there is nocard, nvidia driver will not get loaded and module 
nvidia.modeset also does not load.

this other message may also be hint - "sorry, variable 'ip_squeue_worker_wait' 
is not defined in the 'ip’ module”. Do you have this variable set in 
/etc/system? you can try to boot -a and when it does prompt for /etc/system, 
enter /dev/null

rgds,
toomas


___
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

[Toomas Soome via oi-dev]

> On 26. Apr 2022, at 20:52, Gary Mills  wrote:
> 
> On Fri, Apr 15, 2022 at 07:16:02PM +0100, Peter Tribble wrote:
> 
>>   The common pattern in oi-userland (see eg
>>   components/sysutils/chezmoi/Makefile)
>>   is
>>   COMPONENT_BUILD_ENV += GOPATH="$(SOURCE_DIR)/gopath"
>>   COMPONENT_INSTALL_ENV += GOPATH="$(SOURCE_DIR)/gopath"
> 
> Thanks.  That got me much further in building a package.  However,
> in my first test, the daemon terminated with a segmentation fault.
> I'm building zrepl-0.5.0, which I assume is the current version.
> Here's part of the error message:
> 
>panic: runtime error: invalid memory address or nil pointer dereference
>[signal SIGSEGV: segmentation violation code=0x1 addr=0x20 pc=0xaea33e]
> 
> This was followed by a traceback, but I didn't see anything that
> revealed the origin of the error.


Old pool *may* contribute to trigger the issue, but such crash is program error.

rgds,
toomas


> 
> Could an old zpool be part of the problem?  This is part of the
> output:
> 
>$ zpool status dpool
>  pool: dpool
> state: ONLINE
>status: The pool is formatted using a legacy on-disk format.  The pool can
>   still be used, but some features are unavailable.
>action: Upgrade the pool using 'zpool upgrade'.  Once this is done, the
>   pool will no longer be accessible on software that does not support 
> feature
>   flags.
> 
> 
> -- 
> -Gary Mills-  -refurb--Winnipeg, Manitoba, Canada-
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [developer] recompile oi-userland > gcc-7

[Toomas Soome via oi-dev]

> On 28. Feb 2022, at 17:03, Klaus Ziegler  wrote:
> 
> Hi,
> 
> I'm currently trying to re-compile oi-userland with gcc-11 and where
> C++ usage in gcc-11 is too new, I'm taking gcc-10. However I found
> some packages which won't compile with either of 10/11 GCC releases:
> 
> print/cups-filters:
> ld: fatal: symbol 'postpipe' is multiply-defined:
> (file foomatic_rip-foomaticrip.o type=OBJT; file foomatic_rip-options.o 
> type=OBJT);
> ld: fatal: symbol 'printer_model' is multiply-defined:
> (file foomatic_rip-foomaticrip.o type=OBJT; file foomatic_rip-options.o 
> type=OBJT);
> ld: fatal: symbol 'cupsfilter' is multiply-defined:
> (file foomatic_rip-foomaticrip.o type=OBJT; file foomatic_rip-options.o 
> type=OBJT);
> ld: fatal: file processing errors. No output written to .libs/foomatic-rip
> collect2: error: ld returned 1 exit status
> 
> library/trousers - works using gcc-7 and gcc-9:
> ld: fatal: symbol 'tcsd_sa_chld' is multiply-defined:
> (file .libs/libtspi_la-tspi_context.o type=OBJT; file 
> .libs/libtspi_la-rpc_context.o type=OBJT);
> ld: fatal: symbol 'tcsd_sa_int' is multiply-defined:
> (file .libs/libtspi_la-tspi_context.o type=OBJT; file 
> .libs/libtspi_la-rpc_context.o type=OBJT);
> ld: fatal: symbol 'tcsd_sa_chld' is multiply-defined:
> (file .libs/libtspi_la-tspi_context.o type=OBJT; file 
> .libs/libtspi_la-tcs_api.o type=OBJT);
> ...
> 
> If those are compiled using gcc-7 all is fine, how could I fix these linking 
> errors,
> of course -z muldefs would be a solution - but is it okay to just add muldefs
> to involved Makefile(s) and or libtool?
> 
> Many Regards
> Klaus
> 

Multiply defined symbol means there are many object modules providing the same 
symbol. This often happens because variable is declared in header without 
‘extern’. gcc 10 did switch on that warning - it was off in previous versions. 
Many third party packages already have this fixed, so you may want to check for 
updates….

rgds,
toomas



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] is it possible to change caddr_t type

[Toomas Soome via oi-dev]

> On 29. Dec 2021, at 18:50, Vincent Torri  wrote:
> 
> Hello
> 
> I'm compiling the EFL for the Enlightenment developper, and I have a
> certain number of warnings about caddr_t and casts.
> 
> My question is: can I make caddr_t be void * instead of char * .
> 
> thank you
> 
> Vincent Torri
> 
> PS: tell me if i have to ask this question in illumos mailing list
> 

it does belong to illumos list, but I’m afraid, it would be quite impossible - 
unless you want to sweep through all the source to fix pointer arithmetics and 
such, and then test everything you did touch…. 

rgds,
toomas


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] libmapmalloc and libumem

[Toomas Soome via oi-dev]

> On 8. Aug 2021, at 11:46, s...@pandora.be  wrote:
> 
> 
> When I compiled OpenSmalltalk on OpenIndiana, initially it seemed to work but 
> there were sometimes malloc() errors, pointing to some form of memory 
> corruption.
> 
> The names of the OpenSmalltalk packages are cog-spur and stack-spur.
> 
> Those are also the names that the principal developer of OpenSmalltalk (Eliot 
> Miranda) also uses.
> 
> Both cog-spur and stack-spur were sometimes working fine for a while, then 
> crashing either without error message or with some malloc error.
> 
> I ran cog-spur and stack-spur under valgrind, a tool to debug malloc, but 
> valgrind did not find a problem.
> 
> Fortunately I discovered a while ago that OpenIndiana has multiple malloc() 
> libraries.
> 
> Since I link against libmapmalloc, a malloc() implementation that only uses 
> mmap() and not brk() or sbrk() , the situation is much better.
> 
> The packages are now much more stable and I have not seen a malloc() error 
> any longer although that these are hard to reproduce problems.
> 
> Perhaps I should be using libumem instead of libmapmalloc.
> 
> Has anyone recommendations on perhaps preference for libumem on OI instead of 
> libmapmalloc ?
> 
> David Stes

libumem does provide more tools to diagnose memory management issues.

rgds,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] help needed to test tem on nvidia system

[Toomas Soome via oi-dev]

Thanks!

We already got needed tests done, and now the console can handle CSI 38;2;R;G;B 
m and CSI 48;2;R;G;B m sequences.

Toomas

> On 28. Jun 2021, at 07:33, Tony Brian Albers  wrote:
> 
> Toomas Soome via oi-dev wrote:
>> 
>> 
>>>> On 23. Jun 2021, at 10:20, Stephan Althaus 
>>>>  wrote:
>>> 
>>> On 6/22/21 11:09 PM, Toomas Soome via oi-dev wrote:
>>>> 
>>>> hi!
>>>> 
>>>> as I do not have nvidia gfx myself, some help is needed to test 
>>>> https://code.illumos.org/c/illumos-gate/+/1550 
>>>> <https://code.illumos.org/c/illumos-gate/+/1550>.
>>>> 
>>>> thanks,
>>>> toomas
>>>> 
>>>> 
>>>> ___
>>>> oi-dev mailing list
>>>> oi-dev@openindiana.org <mailto:oi-dev@openindiana.org>
>>>> https://openindiana.org/mailman/listinfo/oi-dev 
>>>> <https://openindiana.org/mailman/listinfo/oi-dev>
>>> Hi Toomas!
>>> 
>>> Would it be as easy as exchange a binary, or do i have to build 
>>> illumos-gate with the PR-changes applied ?
>>> 
>>> Greetings,
>>> 
>>> Stephan
>>> 
>>> 
>>> 
>> 
>> I’ll provide binaries and instructions (we will create BE for test, so we 
>> wont disturb your current environment).
>> 
>> thanks,
>> toomas
>> 
>>> ___
>>> oi-dev mailing list
>>> oi-dev@openindiana.org
>>> https://openindiana.org/mailman/listinfo/oi-dev
>> 
>> 
>> 
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
>> 
> 
> I've got a NVS 510 and a quadro k2200 that I can test it with.
> 
> /tony
> 
> -- 
> Tony Albers - Systems Architect - Data Department, Royal Danish Library, 
> Victor Albecks Vej 1, 8000 Aarhus C, Denmark
> Tel: +45 2566 2383 - CVR/SE: 2898 8842 - EAN: 5798000792142

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] OI no longer automounts USB sticks

[Toomas Soome via oi-dev]

Quiesce is to support fast reboot, it does not interfere with device 
connectivity.

Sent from my iPhone

> On 27. Jun 2021, at 15:27, s...@telenet.be wrote:
> 
> 
> Although that OI 2020.04 and 2021.04 install both on this Dell Precision 3640 
> system,
> I have noticed:
> 
> reboot: Not all drivers have implemented quiesce(9E)
>Please see /var/adm/messages for drivers that haven't
>implemented quiesce(9E).
> 
> The driver that is indicated there is
> 
> Jun 27 14:18:24 wapper genunix: [ID 884581 kern.warning] WARNING: xhci has no 
> quiesce()
> 
> It would be interesting to compare to an older system which uses the ehci or 
> ohci USB driver.
> 
> 
> Maybe OpenIndiana running on a PC without the xHCI behaves differently.
> 
> David Stes
> 
> - Op 27 jun 2021 om 13:14 schreef Andreas Wacknitz a.wackn...@gmx.de:
> 
>>> Am 27.06.21 um 11:50 schrieb s...@pandora.be:
>>> - Op 27 jun 2021 om 10:55 schreef Andreas Wacknitz a.wackn...@gmx.de:
>>> 
 And I am only able to do limited
 manual tests, because I have lots of other things I want to do.
 I only use USB sticks very rarely and while I do change my mouse or
 keyboard from time to time, it hasn't been on my test scenarios in the 
 past.
 So problems like this will only be detected long after they have been
 introduced.
 
 I'd appreciate if we could find some volunteers for tests and would even
 more appreciate if you could find somebody starting to create automatic
 tests.
>>> 
>>> The best testing is desktop users of OpenIndiana.
>>> 
>>> I like the 2021.04 release of OI, this is a great piece of work, and this
>>> release works well on my PC
>>> (thanks for the work on it).
>>> 
>>> Regarding the USB automount, I can personally live with the workaround of 
>>> manual
>>> mount.
>>> Automount would be nice so if it gets fixed all the better.
>>> 
>>> David Stes
>>> 
>> While I understand your point of view you should be aware that if I
>> continue to update things without proper testing more and more things
>> will break.
>> At some point in time I will break things you rely on and then your
>> unhappiness will begin.
>> 
>> We are a very small community and if I cannot convince more people to
>> help out, OI will either become outdated in more and more areas
>> or it will be more and more buggy. And probably both.
>> 
>> I didn't find the problem earlier because of how I use OI. I don't use
>> many things that I have been working on in the past. I will probably
>> stop that,
>> because I am running out of time. If I have to care for everything I
>> will not be able to do anything in the end.
>> 
>> Regards
>> 
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] help needed to test tem on nvidia system

[Toomas Soome via oi-dev]

> On 23. Jun 2021, at 10:20, Stephan Althaus  
> wrote:
> 
> On 6/22/21 11:09 PM, Toomas Soome via oi-dev wrote:
>> 
>> hi!
>> 
>> as I do not have nvidia gfx myself, some help is needed to test 
>> https://code.illumos.org/c/illumos-gate/+/1550 
>> <https://code.illumos.org/c/illumos-gate/+/1550>. 
>> 
>> thanks,
>> toomas
>> 
>> 
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org <mailto:oi-dev@openindiana.org>
>> https://openindiana.org/mailman/listinfo/oi-dev 
>> <https://openindiana.org/mailman/listinfo/oi-dev>
> Hi Toomas!
> 
> Would it be as easy as exchange a binary, or do i have to build illumos-gate 
> with the PR-changes applied ?
> 
> Greetings,
> 
> Stephan
> 
> 
> 

I’ll provide binaries and instructions (we will create BE for test, so we wont 
disturb your current environment).

thanks,
toomas

> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] help needed to test tem on nvidia system

[Toomas Soome via oi-dev]

hi!

as I do not have nvidia gfx myself, some help is needed to test 
https://code.illumos.org/c/illumos-gate/+/1550 
. 

thanks,
toomas___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Nvidia warning at reboot

[Toomas Soome via oi-dev]

Or you may need to wrap it to

boot-args=“-B ...” 

Thats more likely:)

Sent from my iPhone

> On 13. Apr 2021, at 16:16, Toomas Soome via oi-dev  
> wrote:
> 
> echo disable-nvidia_modeset=true > /boot/conf.d/nvidia
> 
> Should get rid of it.
> 
> Sent from my iPhone
> 
>> On 13. Apr 2021, at 16:07, Gary Mills  wrote:
>> 
>> Yesterday, I did an OI update on my development server to get /bin/ksh
>> in a separate package.  The update was successful as was the
>> subsequent reboot.  During the reboot, I got these console messages:
>> 
>> /kernel/drv/amd64/nvidia_modeset: undefined symbol 'nvidia_get_rm_ops'
>> WARNING: mod_load: cannot load module 'nvidia_modeset'
>> WARNING: nvidia_modeset: unable to resolve dependency, module 'nvidia' not 
>> found
>> 
>> Are these warnings now normal?
>> 
>> The server does no have an nvidia video card.
>> 
>> 
>> -- 
>> -Gary Mills--refurb--Winnipeg, Manitoba, Canada-
>> 
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Nvidia warning at reboot

[Toomas Soome via oi-dev]

echo disable-nvidia_modeset=true > /boot/conf.d/nvidia

Should get rid of it.

Sent from my iPhone

> On 13. Apr 2021, at 16:07, Gary Mills  wrote:
> 
> Yesterday, I did an OI update on my development server to get /bin/ksh
> in a separate package.  The update was successful as was the
> subsequent reboot.  During the reboot, I got these console messages:
> 
>  /kernel/drv/amd64/nvidia_modeset: undefined symbol 'nvidia_get_rm_ops'
>  WARNING: mod_load: cannot load module 'nvidia_modeset'
>  WARNING: nvidia_modeset: unable to resolve dependency, module 'nvidia' not 
> found
> 
> Are these warnings now normal?
> 
> The server does no have an nvidia video card.
> 
> 
> -- 
> -Gary Mills--refurb--Winnipeg, Manitoba, Canada-
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] What is the equivalent for GNU ld's --export-dynamic?

[Toomas Soome via oi-dev]

> On 25. Mar 2021, at 06:27, cretin1997 via oi-dev  
> wrote:
> 
> 
> ‐‐‐ Original Message ‐‐‐
> On Thursday, March 25, 2021 1:43 AM, Bob Friesenhahn 
>  wrote:
> 
>> On Wed, 24 Mar 2021, cretin1997 via oi-dev wrote:
>> 
>>> I know the Solaris linker is what caused all of the trouble.
>>> FreeBASIC expects a GNU linker. This time is the same. The Solaris
>>> ld doesn't support --export-dynamic.
>> 
>> The Solaris linker has not caused a problem. It seems like the Linux
>> linker has caused the problem! :-)
>> 
>> I suggest trying without the option. If there is some problem later
>> with resolving symbols while actually running the program, then return
>> to the issue.
>> 
>> If one looks at the Linux dlopen(3) manual page, there is a
>> RTLD_GLOBAL option. Apparently this used to be the Linux default,
>> then but then RTLD_LOCAL became the default due to security concerns.
>> It is my experience that Illumos will still behave as described for
>> RTLD_GLOBAL:
>> 
>> "The symbols defined by this shared object will be made available for
>> symbol resolution of subsequently loaded shared objects."
>> 
>>> Put this shit aside, what I do is I just removed the problematic
>>> option. FreeBASIC does turn on it option for Linux. I don't know
>>> what it does, nor I wanted to know, I only wanted to know the
>>> equivalent option for the Solaris linker. If no such equivalent
>>> option available, does the shared library produced by FreeBASIC with
>>> --export-dynamic removed work? What is the side effect if without
>>> --export-dynamic? This is the only thing I wanted to know! The one
>>> most qualified to answer such question should be the FreeBASIC
>>> developers, but, as you already known... do it yourself and you
>>> could submit the code to us!
>> 
>> Since you are porting the code, you will soon learn if it works.
>> 
>> Trial and error is a valid approach.
>> 
>> Bob
>> 
>> --
>> 
>> Bob Friesenhahn
>> bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
>> GraphicsMagick Maintainer, http://www.GraphicsMagick.org/
>> Public Key, http://www.simplesystems.org/users/bfriesen/public-key.txt
>> 
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
> 
> No. The GNU linker is not a problem. It is widely used across platforms. It's 
> nothing wrong for the developers to insist it's the default. Even on platform 
> doesn't use the GNU linker by default like FreeBSD, it's easily installed 
> from ports/packages and it will just work. It is you, a weirded platform, 
> with it incompatible linker, that caused the problem. As I said many times 
> before and being hated because of this but I will not afraid said it again: 
> software developers will just skip your platforms and support other platforms 
> that they will have the least effort to support, that is platforms that 
> behave almost identical to their first class platform, usually be Linux.
> 
> Perhaps you didn't read my last email. OK, it's too long, I myself tired to 
> read it, too. I did try to remove --export-dynamic and after that I could 
> have the compiler to generate a shared library (.so file). And you are right, 
> trial and error is the only solution, because I have no one to mentor, no one 
> to ask for. But unfortunately, it seemed the produced shared library doesn't 
> work. The program linked with it will just sit there but do nothing, it 
> doesn't even seem to be launched, indicating that it failed to load the 
> shared library or the shared library simply doesn't work. Someone on the 
> internet said I should run truss on the binary, I did and I found after a 
> while the program just sit there idle. No outputs were even printed by this 
> program to the terminal. It just stuck and needs to be canceled with Ctrl+C.
> 

How did you test the library? are you sure it is fault  of linker and not the 
code? running the app and getting no output does only prove that there is a 
problem,   bit it does not identify the problem.

If that library is working on FreeBSD, it means the FreeBSD port is done 
correctly, it does *not* tell you anything about illumos port because building 
on FreeBSD does not tell anything about illumos.

rgds,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [OpenIndiana-discuss] Obstacle to GPT label boot?

[Toomas Soome via oi-dev]

> On 19. Mar 2021, at 21:06, Judah Richardson  wrote:
> 
> 
> 
> On Fri, Mar 19, 2021 at 1:14 PM Toomas Soome  > wrote:
> 
> 
>> On 19. Mar 2021, at 16:21, Judah Richardson > > wrote:
>> 
>> Thanks Toomas. A few questions about that:
>> Which OI version was originally installed? That would help me pinpoint where 
>> OI UEFI support landed
> 
> That is tricky:D because it was installed before I wrote UEFI support for 
> illumos:D (technically it is still not complete, but thats another story). 
> 
> I was thinking, what point in time to count for this landing - because we did 
> add it step by step, but I think this headsup should be the mark:
> 
> https://illumos.topicbox.com/groups/developer/T97536ca6fe4642cf-M727f3d9b380cd0b011197de1/headsup-or-something
>  
> 
> 
> So 2019.05 should have those bits already.
> OK. Welp, didn't work for me when I tried installing the latest Hipster in 
> 2020, but the target disk was a 128 GB SSD so not really an issue.


What was the problem?

rgds,
toomas


> 
> 
>> What hardware is this on? If it's a prebuilt PC brand and model name would 
>> be great. If you built the PC yourself, I'd appreciate the brand and model 
>> of the motherboard
>> 
> 
> my host is a bit old already, it is Supermicro X10SAE with Intel(r) Xeon(r) 
> CPU E3-1246 v3 @ 3.50GHz. It is doing ok for my needs (illumos dev and build 
> host).
> Thanks for the info! 
> 
> rgds,
> toomas
> 
>> 
>> On Fri, Mar 19, 2021 at 1:18 AM Toomas Soome via openindiana-discuss 
>> > > wrote:
>> 
>> 
>> > On 19. Mar 2021, at 02:31, Reginald Beardsley via oi-dev 
>> > mailto:oi-dev@openindiana.org>> wrote:
>> > 
>> > Would someone please direct me to an explanation  of why we can't boot 
>> > from disk >2 TB in 2021?
>> 
>> 
>> root@beastie:/code/illumos-gate# format
>> Searching for disks...done
>> 
>> 
>> AVAILABLE DISK SELECTIONS:
>>0. c3t0d0 
>>   /pci@0,0/pci15d9,805@1f,2/disk@0,0
>>1. c3t1d0 
>>   /pci@0,0/pci15d9,805@1f,2/disk@1,0
>>2. c3t3d0 
>>   /pci@0,0/pci15d9,805@1f,2/disk@3,0
>>3. c3t4d0 
>>   /pci@0,0/pci15d9,805@1f,2/disk@4,0
>> Specify disk (enter its number): ^D
>> root@beastie:/code/illumos-gate# zpool status rpool
>>   pool: rpool
>>  state: ONLINE
>>   scan: resilvered 1,68T in 0 days 10:10:07 with 0 errors on Fri Oct 25 
>> 05:05:34 2019
>> config:
>> 
>> NAMESTATE READ WRITE CKSUM
>> rpool   ONLINE   0 0 0
>>   raidz1-0  ONLINE   0 0 0
>> c3t0d0  ONLINE   0 0 0
>> c3t1d0  ONLINE   0 0 0
>> c3t3d0  ONLINE   0 0 0
>> c3t4d0  ONLINE   0 0 0
>> 
>> errors: No known data errors
>> root@beastie:/code/illumos-gate# 
>> 
>> I can tell, this system does boot just fine with both UEFI and BIOS firmware.
>> 
>> rgds,
>> toomas
>> 
>> > 
>> > It's very hard for me to see a significant obstacle to reading an x86 MBR 
>> > that loads code that will then boot from GPT label disks.
>> > 
>> > I'm rebuilding my Sol 10 u8 system with my spare 2 TB disk.  I'd like to 
>> > replace the 3x  2 TB disk RAIDZ1 setup with  a 4-5x disk RAIDZ2 using 4 TB 
>> > disks using my s0 & s1 configuration.
>> > 
>> > I must assume that the Illumos market is dominated by customers who don't 
>> > care about having a few small SMI labeled boot disks in a farm of large 
>> > GPT labeled disks.  But for a 7 SATA port system, that's not very viable.
>> > 
>> > Linux, MS and BSD can do it, so we should be able to do it also.  It's 
>> > become enough of a personal nuisance that I'm willing to fix it if I get a 
>> > modest level of cooperation.
>> > 
>> > So please, point me at any known issues.  For workstations the s0 root 
>> > pool and s1 export pool works really well.
>> > 
>> > Reg
>> > 
>> > BTW After a DIMM shuffle, "format -e" and scrubs no longer dump core on 
>> > u8.  Now X goes off into la-la land :-(  Clearly I need new DIMMS.
>> > 
>> 
>> 
>> 
>> ___
>> openindiana-discuss mailing list
>> openindiana-disc...@openindiana.org 
>> 
>> https://openindiana.org/mailman/listinfo/openindiana-discuss 
>> 
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [OpenIndiana-discuss] Obstacle to GPT label boot?

[Toomas Soome via oi-dev]

> On 19. Mar 2021, at 16:21, Judah Richardson  wrote:
> 
> Thanks Toomas. A few questions about that:
> Which OI version was originally installed? That would help me pinpoint where 
> OI UEFI support landed

That is tricky:D because it was installed before I wrote UEFI support for 
illumos:D (technically it is still not complete, but thats another story). 

I was thinking, what point in time to count for this landing - because we did 
add it step by step, but I think this headsup should be the mark:

https://illumos.topicbox.com/groups/developer/T97536ca6fe4642cf-M727f3d9b380cd0b011197de1/headsup-or-something
 


So 2019.05 should have those bits already.


> What hardware is this on? If it's a prebuilt PC brand and model name would be 
> great. If you built the PC yourself, I'd appreciate the brand and model of 
> the motherboard
> 

my host is a bit old already, it is Supermicro X10SAE with Intel(r) Xeon(r) CPU 
E3-1246 v3 @ 3.50GHz. It is doing ok for my needs (illumos dev and build host).

rgds,
toomas

> 
> On Fri, Mar 19, 2021 at 1:18 AM Toomas Soome via openindiana-discuss 
>  > wrote:
> 
> 
> > On 19. Mar 2021, at 02:31, Reginald Beardsley via oi-dev 
> > mailto:oi-dev@openindiana.org>> wrote:
> > 
> > Would someone please direct me to an explanation  of why we can't boot from 
> > disk >2 TB in 2021?
> 
> 
> root@beastie:/code/illumos-gate# format
> Searching for disks...done
> 
> 
> AVAILABLE DISK SELECTIONS:
>0. c3t0d0 
>   /pci@0,0/pci15d9,805@1f,2/disk@0,0
>1. c3t1d0 
>   /pci@0,0/pci15d9,805@1f,2/disk@1,0
>2. c3t3d0 
>   /pci@0,0/pci15d9,805@1f,2/disk@3,0
>3. c3t4d0 
>   /pci@0,0/pci15d9,805@1f,2/disk@4,0
> Specify disk (enter its number): ^D
> root@beastie:/code/illumos-gate# zpool status rpool
>   pool: rpool
>  state: ONLINE
>   scan: resilvered 1,68T in 0 days 10:10:07 with 0 errors on Fri Oct 25 
> 05:05:34 2019
> config:
> 
> NAMESTATE READ WRITE CKSUM
> rpool   ONLINE   0 0 0
>   raidz1-0  ONLINE   0 0 0
> c3t0d0  ONLINE   0 0 0
> c3t1d0  ONLINE   0 0 0
> c3t3d0  ONLINE   0 0 0
> c3t4d0  ONLINE   0 0 0
> 
> errors: No known data errors
> root@beastie:/code/illumos-gate# 
> 
> I can tell, this system does boot just fine with both UEFI and BIOS firmware.
> 
> rgds,
> toomas
> 
> > 
> > It's very hard for me to see a significant obstacle to reading an x86 MBR 
> > that loads code that will then boot from GPT label disks.
> > 
> > I'm rebuilding my Sol 10 u8 system with my spare 2 TB disk.  I'd like to 
> > replace the 3x  2 TB disk RAIDZ1 setup with  a 4-5x disk RAIDZ2 using 4 TB 
> > disks using my s0 & s1 configuration.
> > 
> > I must assume that the Illumos market is dominated by customers who don't 
> > care about having a few small SMI labeled boot disks in a farm of large GPT 
> > labeled disks.  But for a 7 SATA port system, that's not very viable.
> > 
> > Linux, MS and BSD can do it, so we should be able to do it also.  It's 
> > become enough of a personal nuisance that I'm willing to fix it if I get a 
> > modest level of cooperation.
> > 
> > So please, point me at any known issues.  For workstations the s0 root pool 
> > and s1 export pool works really well.
> > 
> > Reg
> > 
> > BTW After a DIMM shuffle, "format -e" and scrubs no longer dump core on u8. 
> >  Now X goes off into la-la land :-(  Clearly I need new DIMMS.
> > 
> 
> 
> 
> ___
> openindiana-discuss mailing list
> openindiana-disc...@openindiana.org 
> 
> https://openindiana.org/mailman/listinfo/openindiana-discuss 
> 

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Obstacle to GPT label boot?

[Toomas Soome via oi-dev]

> On 19. Mar 2021, at 09:53, Marcel Telka  wrote:
> 
> On Fri, Mar 19, 2021 at 09:34:01AM +0200, Toomas Soome wrote:
> 
> [...snip...]
> 
> Thanks for all those commands and references!
> 
> 
>> To install on slice, you would need to select GPT partitioning and
>> *not* select whole disk setup. However, I have not used OI installer
>> for a long time, therefore I can not recall what exactly are on those
>> screens:D Also it is very likely, some improvements can be made there
>> (like for >2TB disks we should only offer GPT).
> 
> IIRC, this is not possible with Hipster 2020.10 installer.


hm. then it needs to be fixed.

> 
>> Yes, this BIOS does see all 4 disks, therefore I can boot from this
>> rpool. We have been able to do this since loader was integrated.. hm,
>> log is telling…
> 
> Then it must be just my stupid BIOS that does not allow me to boot from
> NVMe when I try legacy BIOS boot :-(.
> 

this is often the case, same with vmware fusion VM; also, if the device is 
having 4kn (4k logical/physical) sector size, then it is quite probable, the 
BIOS will not allow booting from it, and our pmbr.s code does not support 4kn 
either - without actual test system, I see no point:)

from practical point of view, NVMe boot is possible with UEFI.

rgds,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Obstacle to GPT label boot?

[Toomas Soome via oi-dev]

> On 19. Mar 2021, at 09:04, Marcel Telka  wrote:
> 
> On Fri, Mar 19, 2021 at 08:17:44AM +0200, Toomas Soome via oi-dev wrote:
>> root@beastie:/code/illumos-gate# zpool status rpool
>>  pool: rpool
>> state: ONLINE
>>  scan: resilvered 1,68T in 0 days 10:10:07 with 0 errors on Fri Oct 25 
>> 05:05:34 2019
>> config:
>> 
>>NAMESTATE READ WRITE CKSUM
>>rpool   ONLINE   0 0 0
>>  raidz1-0  ONLINE   0 0 0
>>c3t0d0  ONLINE   0 0 0
>>c3t1d0  ONLINE   0 0 0
>>c3t3d0  ONLINE   0 0 0
>>c3t4d0  ONLINE   0 0 0
>> 
>> errors: No known data errors
> 
> What is the slice layout at those disks?  Is it one small EFI boot slice
> (pcfs) + one big slice covering the rest of the disk and used for rpool?
> If I'm not mistaken this is the default layout created by the OI
> installer when installed on GPT/EFI disk (without MBR).
> 
> Is there a way to install OI on a GPT disk in a slice not covering the
> whole disk?
> 


Part  TagFlag First Sector  Size  Last Sector
  0 systemwm   256   256.00MB   524543
  1usrwm524544 3.64TB   7814020750
  2 unassignedwm 000
  3 unassignedwm 000
  4 unassignedwm 000
  5 unassignedwm 000
  6 unassignedwm 000
  8   reservedwm7814020751 8.00MB   7814037134

format> 

This is the default layout generated with zpool create -B rpool raidz c3t0d0 
c3t1d0 c3t3d0 c3t4d0

Technically *every* GPT partitioned disk does have MBR, but it is called 
protective MBR (PMBR).

This can be checked with fdisk, but here is alternate way:

root@beastie:/home/tsoome# mdb /dev/rdsk/c3t0d0
> ::load disk_label
> ::mbr
Format: loader (illumos)
Signature: 0xaa55 (valid)
UniqueMBRDiskSignature: 0
Loader STAGE1_STAGE2_LBA: 524544
Loader STAGE1_STAGE2_SIZE: 1
Loader STAGE1_STAGE2_UUID: 7f0a04f2-6a11-e6b8-b0ae-dc14a75a96fc

STAGE1 in VBR:
Format: loader (illumos)
Signature: 0xaa55 (valid)
UniqueMBRDiskSignature: 0
Loader STAGE1_STAGE2_LBA: 525568
Loader STAGE1_STAGE2_SIZE: 328
Loader STAGE1_STAGE2_UUID: 7f0a04f2-6a11-e6b8-b0ae-dc14a75a96fc

PART TYPE  ACTIVE  STARTCHSENDCHS  SECTOR NUMSECT  
0EFI_PMBR:0xee 0   1023/255/63 1023/255/63 1  4294967295
1UNUSED:0
2UNUSED:0
3UNUSED:0
> ::gpt
Signature: EFI PART (valid)
Revision: 1.0
HeaderSize: 512 bytes
HeaderCRC32: 0x375ff497 (should be 0x375ff497)
Reserved1: 0 (should be 0x0)
MyLBA: 1 (should be 1)
AlternateLBA: 7814037167
FirstUsableLBA: 34
LastUsableLBA: 7814037134
DiskGUID: c350e9d4-baee-63db-f81f-f702e840eb5f
PartitionEntryLBA: 2
NumberOfPartitionEntries: 9
SizeOfPartitionEntry: 0x80 bytes
PartitionEntryArrayCRC32: 0xf2fd883d (should be 0xf2fd883d)

PART TYPESTARTLBA  ENDLBAATTR NAME
0EFI_SYSTEM  256   5245430loader
1EFI_USR 52454478140207500zfs
2EFI_UNUSED 
3EFI_UNUSED 
4EFI_UNUSED 
5EFI_UNUSED 
6EFI_UNUSED 
7EFI_UNUSED 
8EFI_RESERVED781402075178140371340
> ::quit

root@beastie:/home/tsoome# 

To install on slice, you would need to select GPT partitioning and *not* select 
whole disk setup. However, I have not used OI installer for a long time, 
therefore I can not recall what exactly are on those screens:D Also it is very 
likely, some improvements can be made there (like for >2TB disks we should only 
offer GPT).


 

>> I can tell, this system does boot just fine with both UEFI and BIOS firmware.
> 
> Legacy BIOS?  Is your system really able to boot in legacy BIOS mode
> with the rpool as outlined above?
> 

Yes, this BIOS does see all 4 disks, therefore I can boot from this rpool. We 
have been able to do this since loader was integrated.. hm, log is telling…

Author: Toomas Soome 
Date:   Sun Oct 25 00:06:51 2015 +0300

5061 freebsd boot loader integration (loader project)
Reviewed by: Richard Lowe 
Reviewed by: Cody Mello 
Approved by: Robert Mustacchi 


5 years ago.. time flies...

rgds,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Obstacle to GPT label boot?

[Toomas Soome via oi-dev]

> On 19. Mar 2021, at 02:31, Reginald Beardsley via oi-dev 
>  wrote:
> 
> Would someone please direct me to an explanation  of why we can't boot from 
> disk >2 TB in 2021?


root@beastie:/code/illumos-gate# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
   0. c3t0d0 
  /pci@0,0/pci15d9,805@1f,2/disk@0,0
   1. c3t1d0 
  /pci@0,0/pci15d9,805@1f,2/disk@1,0
   2. c3t3d0 
  /pci@0,0/pci15d9,805@1f,2/disk@3,0
   3. c3t4d0 
  /pci@0,0/pci15d9,805@1f,2/disk@4,0
Specify disk (enter its number): ^D
root@beastie:/code/illumos-gate# zpool status rpool
  pool: rpool
 state: ONLINE
  scan: resilvered 1,68T in 0 days 10:10:07 with 0 errors on Fri Oct 25 
05:05:34 2019
config:

NAMESTATE READ WRITE CKSUM
rpool   ONLINE   0 0 0
  raidz1-0  ONLINE   0 0 0
c3t0d0  ONLINE   0 0 0
c3t1d0  ONLINE   0 0 0
c3t3d0  ONLINE   0 0 0
c3t4d0  ONLINE   0 0 0

errors: No known data errors
root@beastie:/code/illumos-gate# 

I can tell, this system does boot just fine with both UEFI and BIOS firmware.

rgds,
toomas

> 
> It's very hard for me to see a significant obstacle to reading an x86 MBR 
> that loads code that will then boot from GPT label disks.
> 
> I'm rebuilding my Sol 10 u8 system with my spare 2 TB disk.  I'd like to 
> replace the 3x  2 TB disk RAIDZ1 setup with  a 4-5x disk RAIDZ2 using 4 TB 
> disks using my s0 & s1 configuration.
> 
> I must assume that the Illumos market is dominated by customers who don't 
> care about having a few small SMI labeled boot disks in a farm of large GPT 
> labeled disks.  But for a 7 SATA port system, that's not very viable.
> 
> Linux, MS and BSD can do it, so we should be able to do it also.  It's become 
> enough of a personal nuisance that I'm willing to fix it if I get a modest 
> level of cooperation.
> 
> So please, point me at any known issues.  For workstations the s0 root pool 
> and s1 export pool works really well.
> 
> Reg
> 
> BTW After a DIMM shuffle, "format -e" and scrubs no longer dump core on u8.  
> Now X goes off into la-la land :-(  Clearly I need new DIMMS.
> 



___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [discuss] Obstacle to GPT label boot?

[Toomas Soome via oi-dev]

> On 19. Mar 2021, at 03:34, Reginald Beardsley via oi-dev 
>  wrote:
> 
> Judah has nailed the issue.
> 
> 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?". 
> 
> Reg
> 

Could you please mail screenshot about that situation in installer? 

rgds,
toomas


> 
> On Thursday, March 18, 2021, 08:18:59 PM CDT, Judah Richardson 
>  wrote:
> 
> 
> 
> 
> On Thu, Mar 18, 2021 at 8:11 PM Hans Rosenfeld 
> mailto:rosenf...@grumpf.hope-2000.org>> 
> wrote:
> On Fri, Mar 19, 2021 at 12:31:08AM +, Reginald Beardsley via 
> illumos-discuss wrote:
> > Would someone please direct me to an explanation  of why we can't boot
> > from disk >2 TB in 2021?
> 
> Have you tried? What problems did you run into?
> I do believe he was referring to OI specifically. AFAIK, OI itself (not the 
> live USB) has long had EFI boot issues, while other Illumos distributions 
> such as OmniOS don't.
> 
> Unless I'm mistaken, the issue has been repeatedly paved over in great detail 
> on the OI mailing list. 
> 
> illumos has had support for booting from disks > 2TB for a few years
> now, both in our ancient grub boot loader and of course also in the new
> loader that Toomas Soome ported from FreeBSD a few years ago.
> 
> 
> Hans
> 
> 
> -- 
> %SYSTEM-F-ANARCHISM, The operating system has been overthrown
> 
> --
> illumos: illumos-discuss
> Permalink: 
> https://illumos.topicbox.com/groups/discuss/T04ff6364a70ba334-M54025247a9158583db3bf331
>  
> 
> Delivery options: https://illumos.topicbox.com/groups/discuss/subscription 
> 
> illumos  / illumos-discuss / 
> seediscussions  +participants 
>  +delivery options 
> Permalink 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
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!!!!

[Toomas Soome via oi-dev]

> On 2. Mar 2021, at 13:08, cretin1997  wrote:
> 
> ‐‐‐ Original Message ‐‐‐
> On Tuesday, March 2, 2021 3:35 PM, Toomas Soome via openindiana-discuss 
>  wrote:
>> 
>> Yes, the code of format command is mess (I have been in it more than I would 
>> like to;), also we would need better tooling to handle disk partitioning, 
>> allowing easy scripting etc, something like freebsd gpart has been in my 
>> mind for a long time, but I haven't had time to think about it more…
>> 
>> rgds,
>> toomas
>> 
> 
> Too bad FreeBSD's gpart seemed to depend on FreeBSD's GEOM framework. Porting 
> it from FreeBSD seemed to not easy. Luckily, we have a snapshot of FreeBSD 
> before they switched to GEOM, DragonflyBSD. Do you think DragonflyBSD's gpt 
> tool is easier to port, sir?
> 
> https://man.dragonflybsd.org/?command=gpt=8

no, it is not about porting it, but the command line logic and functionality. 
we do have format, fdisk, prtvtoc, fmthard, all doing some subset of tasks and 
even if you can feed some input data, the customization would need awk/sed and 
fancy scripting:D  See /bin/usbgen for example;)

rgds,
toomas
___
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!!!!

[Toomas Soome via oi-dev]

> On 2. Mar 2021, at 02:45, Reginald Beardsley  wrote:
> 
> 
> It is with deep regret that I say this. 
> 
> I shall not be working on Illumos/OI. Below is the terminal output using the 
> Hipster 2020.10 GUI install disk. I've always been amused by the enthusiasm 
> for threads. I bought John Lakos' book when it came out and unlike most 
> actually read much of it. I even posted a page on my office door. Many months 
> after I'd taken it down the entire project ground to a complete halt while 
> they refactored the sysem to address the linker issue I'd highlighted on my 
> office door. I've also read many books on operating systems and all the 
> issues that must be handled 100% correctly to make multiple processes running 
> in the same address space work reliably. Can you state the "Dining 
> Philospher's" problem? I can. This stuff is hard. That's why protected memory 
> is so important to a robust system. Threads, like shared memory are valuable 
> tools, but are best used with discretion. And only when there is no suitable 
> alternative.
> 
> Rather well known, at least to my generation, is something called "Amdahl's 
> law". It's not particularly insightful. It just makes the observation that 
> pefectly optimizing something which does not take a lot of time has 
> neglegible benefit.
> 
> 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.
> 
> I have *never* written a program using pthreads or any other threading 
> library. I dealt with things like seismic imaging problems which ran on 
> 10,000 -20,000 cores or more for 8-10 days processing 10-30 TB of input and 
> generating similar output volumes. Fortunately these were trivially parallel 
> and could be broken up into separate jobs for each core. With that many 
> machines running, checkpointing and restarting was a critical issue. You 
> *were* going to lose a few machines during a run. So robust recovery was a 
> big deal. That much compute costs a lot of money and starting the whole thing 
> over simply not viable. If you did, you went out of business. The only upside 
> was because such users were running 50,000 cores 24x7 in a single location, 
> they got baseload electrical rates. Though it was not uncommon to have to 
> find additonal locations because the electrical power feed to that location 
> had been exceeded. In Houston, the AC costs as much or more than the 
> computers to run.
> 
> I've seen an inappropriate tool used far too many times for the sole reason 
> that some one wanted to put something on their resume. For many years I'd 
> never written an IP based client server application. I'd taught other people 
> how to do it, but I had not done it myself for the simple reason that it was 
> not an appropriate tool for my assigned tasks. I did eventually get to write 
> a UDP usage logger that tracked usage statistics for the package we were 
> fielding. That was fun. I generated graphics that showed where each business 
> affiliate was in the exploration cycle from what programs they were running.
> 
> Much too my surprise and some dismay, Mac OS X is the best supported 
> commercial Unix today. So I may well become a Mac user.
> 
> A not very happy,
> Reg
> 
> jack@openindiana:/jack$ sudo /bin/su
> root@openindiana:/jack# format -e
> Searching for disks...done
> 
> 
> AVAILABLE DISK SELECTIONS:
> 0. c4d0 
> /pci@0,0/pci-ide@1f,2/ide@0/cmdk@0,0
> Specify disk (enter its number): 0
> 

For some unknown reason, your disks are recognized as PATA (IDE) disks and not 
SATA/AHCI. That alone is bad because IDE is slow and cmdk driver is not the 
fastest one either. You should start with checking out if AHCI (SATA) is 
available.

That alone should not get to the crash but bad things happen.

> Error: can't open disk '/dev/rdsk/c4d0p0'.

Now this line is actual error - we do try to open whole disk device (*p0 is 
special device which does allow access to entire disk surface), but we fail. 
The bug there is obviously about this error - we failed to open the disk, we 
should not continue from this point, but we still do and the punishment is 
segmentation fault  because some needed data structures are not properly set.

It is not obvious why the disk open is failing there, the error code is not 
printed and you seem to have root rights. From this point, I’d run truss format 
and would seek out the failing open() to get the error code, perhaps it would 
explain.

Yes, the code of format command is mess (I have been in it more than I would 
like to;), also we would need better tooling to handle disk partitioning, 
allowing easy scripting etc, something *like* freebsd gpart has 

Re: [oi-dev] Hipster 2020.10 text installer ISO Wow!!!!

[Toomas Soome via oi-dev]

> On 2. Mar 2021, at 00:29, Reginald Beardsley via oi-dev 
>  wrote:
> 
> That was singularly unsuccessful.  It got confused by all the other pools and 
> apparently FreeBSD 12.2 created a "zroot" pool which was "corrupted" and 
> could not be destroyed in any fashion using zpool. I'll find out more when 
> "ZFS Essentials" , "Solaris Internals" 2nd ed and McKusic et al arrive.
> 

zpool destroy only does work with imported pools. If pool fails to import, 
zpool destroy is no help.


> So I did what admins have done since long before I started using Unix.  I 
> wiped the label with dd(1) and started over.  Boy was I ever starting over!
> 
> That resulted in "format -e" dumping core again.  And even after I created a 
> 4.5 TiB ntfs file system using a standalone gparted disk  it completely hosed 
> the geometry on the drive and put me back in the geometry definition dialog I 
> had not seen since I was running dual 141 MB disks on Emulex cards as LUN 0 & 
> 1 on the same SCSI target.  Sun very helpfully put that feature in the 
> generic 4.4.1a kernel for the 3/60.  That was very useful cutting down the 
> length of the SCSI bus.  With 4 shoeboxes it was fragile.  Just moving the 
> cables would make it fail.  So I consolidated the drives and eliminated 1 
> shoebox and cable.
> 
> In general format(1m) and the install programs cannot find the drive and get 
> correct geometry from it.  I don't recall the SCSI code page commands to feed 
> format(1m) to read the data.  But format(1m) needs some serious work.  It 
> should not dump core.
> 
> As John helpfully pointed out, the text installs on the 2 disks are *not* the 
> same.  And the text install ISO has the very helpful feature of using white 
> text on a light colored background so that people who have macular 
> degeneration get extra help in making their life more difficult than it 
> already is.
> 
> BTW The labeling is inconsistent some screens have "F2_continue" and some of 
> the later screens have "ESC-2_continue", though it's actually still F2.
> 
> Yes, sir.  A real quality product.  No effort expended to make it work 
> smoothly.
> 
> Reg
> 
> BTW I'll see if I can capture what format(1m) says when I tell it the disk 
> speed is 7200 rpm.  I don't recall, but it's pretty funny, I remember that.  
> Even 30 years ago the raw geometry stuff was actually obsolete, though still 
> often needed.  I'm not concerned that my drive is ruined, because it's not.  
> I've been here and fixed this before.  It's just tedious and a bit 
> disappointing to see "format -e" dump core again.  It will be pretty funny in 
> a rather sad sort of way if I have to install Linux or Windows to make 
> Hipster install.
> 

pstack core ?

that “quality product” is made by few people there. If you want it to get 
better, there is simple option - start sending out patches.

rgds,
toomas


___
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

[Toomas Soome via oi-dev]

> On 11. Jan 2021, at 18:23, Hung Nguyen Gia via oi-dev 
>  wrote:
> 
> I know how to install nano, sir.
> 
> To be fair, your OS is a resources hog. This small VM I'm setup only has 4 
> cores 4 GB of RAM.
> 
> Without limiting the ZFS Maximum ARC Cache in /etc/system, any attempts to 
> use pkg will fail.

This is not quite true, I have 2 VM’s with 4GB ram and one with 2GB, and I have 
never needed to touch max arc. But pkg is hog. can not be run with firefox, 
which is another hog. 

> To be able to use this VM comfortably, I have to assign 8 GB of swap and 
> limit arc cache size to 512 MB maximum.
> 
> I can't deal with vi at all. Not the modern VIM let alone your old vi.
> 
> Without nano, I can't do text editing.

Now that would be pity, would it?

rgds,
toomas

> 
> Yes, vi is historically part of any Unix. But at least, on FreeBSD, they have 
> a fallback, the ee editor, included by default.
> 
> It's basically what I'm asking for.
> 
> 
>  On Mon, 11 Jan 2021 15:27:51 +0700 Vincent Torri 
>  wrote 
> 
>> On Mon, Jan 11, 2021 at 9:00 AM Toomas Soome via oi-dev
>>  wrote:
>>> 
>>> 
>>> 
>>>> On 11. Jan 2021, at 09:39, Hung Nguyen Gia via oi-dev 
>>>>  wrote:
>>>> 
>>>> Maybe... I'm impolite. But what if I'm just visit here once for this 
>>>> purpose then?
>>>> 
>>>> I only care about the result. Maybe I'm posted on the wrong mailing list. 
>>>> Maybe OI-discuss more fit?
>>>> 
>>>> The only thing I want to see and to care is: the next version of OI, nano 
>>>> is included alongside of vi in the text and minimal version.
>>>> 
>>>> It's just simple as that. Why make thing complicated?
>>>> 
>>> 
>>> The problem is, you are asking to expand minimal version, by definition, 
>>> after such expansion, the minimal is not minimal any more. So, the decision 
>>> has to me made - should the definition of minimal be changed, or should 
>>> user who has decided to use minimal image, learn how to enter ‘pkg install 
>>> nano’.
>> 
>> hello
>> 
>> As a user, I don't want my system to be polluted by unwanted packages.
>> I prefer installing what I want. For example, for text or code editor,
>> I prefer another program than nano.
>> 
>> When searching for a package, i use
>> http://pkg.openindiana.org/hipster/en/index.shtml (in case it helps)
>> 
>> best regards
>> 
>> Vincent Torri
>> 
>>> If you are making decision to use minimal image, you should be aware that 
>>> such image is missing many things and is not intended to be used by someone 
>>> who does not know how to use the system.
>>> 
>>> PS: I see no problem to include nano with larger image.
>>> 
>>> my 2 cents.
>>> 
>>> rgds,
>>> toomas
>>> 
>>>>  On Sun, 10 Jan 2021 14:19:14 +0700 Tim Mooney via oi-dev 
>>>>  wrote 
>>>> 
>>>>> In regard to: Re: [oi-dev] Shipping the nano editor alongside with vi, 
>>>>> Hung...:
>>>>> 
>>>>>> Yes, it's just a single line. But why you give me a read-only file and
>>>>>> asked me to modified it?
>>>>>> 
>>>>>> It's much more simpler for developer with write access to do it, not me.
>>>>>> And it's within a second, just a single line.
>>>>> 
>>>>> I don't know if other languages and cultures have an equivalent, but there
>>>>> is a proverb[1] that applies here:
>>>>> 
>>>>>If you give a man a fish, you feed him for a day.
>>>>>If you teach a man to fish, you feed him for a lifetime.
>>>>> 
>>>>> Teaching someone (or helping them learn) how to do something is often
>>>>> more useful than just doing something (once) for them.
>>>>> 
>>>>> Aurélien is trying to help you to learn to fish.
>>>>> 
>>>>> Learning how to clone oi-userland, create a branch, make a very simple
>>>>> change like this, and submit a pull request (PR) is very useful knowledge
>>>>> to have for anyone that wants to contribute to OI.  There are certainly
>>>>> other ways to contribute, but since you're posting to the oi-dev list,
>>>>> it seems like you might be interested in the development process.  Knowing
>>>>> the workflow for submitting a change is potentially benef

Re: [oi-dev] Missing locale zh_CN.GB18030

[Toomas Soome via oi-dev]

> On 11. Jan 2021, at 16:47, Nona Hansel  wrote:
> 
> Hi,
> 
> I'm trying to update findutils.  Some test are skipping because I don't have 
> zh_CN.GB18030 locale on my system. How can I get it? 
> pfexec pkg info -r doesn't work for me in this case.
> Thank you in advance.
> Nona

I think, we only do have zh_CN.UTF-8 (pkg contents zh_cn).

rgds,
toomas___
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

[Toomas Soome via oi-dev]

> On 11. Jan 2021, at 09:39, Hung Nguyen Gia via oi-dev 
>  wrote:
> 
> Maybe... I'm impolite. But what if I'm just visit here once for this purpose 
> then?
> 
> I only care about the result. Maybe I'm posted on the wrong mailing list. 
> Maybe OI-discuss more fit?
> 
> The only thing I want to see and to care is: the next version of OI, nano is 
> included alongside of vi in the text and minimal version.
> 
> It's just simple as that. Why make thing complicated?
> 

The problem is, you are asking to expand minimal version, by definition, after 
such expansion, the minimal is not minimal any more. So, the decision has to me 
made - should the definition of minimal be changed, or should user who has 
decided to use minimal image, learn how to enter ‘pkg install nano’. If you are 
making decision to use minimal image, you should be aware that such image is 
missing many things and is not intended to be used by someone who does not know 
how to use the system.

PS: I see no problem to include nano with larger image.

my 2 cents.

rgds,
toomas

>  On Sun, 10 Jan 2021 14:19:14 +0700 Tim Mooney via oi-dev 
>  wrote 
> 
>> In regard to: Re: [oi-dev] Shipping the nano editor alongside with vi, 
>> Hung...: 
>> 
>>> Yes, it's just a single line. But why you give me a read-only file and 
>>> asked me to modified it? 
>>> 
>>> It's much more simpler for developer with write access to do it, not me. 
>>> And it's within a second, just a single line. 
>> 
>> I don't know if other languages and cultures have an equivalent, but there 
>> is a proverb[1] that applies here: 
>> 
>> If you give a man a fish, you feed him for a day. 
>> If you teach a man to fish, you feed him for a lifetime. 
>> 
>> Teaching someone (or helping them learn) how to do something is often 
>> more useful than just doing something (once) for them. 
>> 
>> Aurélien is trying to help you to learn to fish. 
>> 
>> Learning how to clone oi-userland, create a branch, make a very simple 
>> change like this, and submit a pull request (PR) is very useful knowledge 
>> to have for anyone that wants to contribute to OI.  There are certainly 
>> other ways to contribute, but since you're posting to the oi-dev list, 
>> it seems like you might be interested in the development process.  Knowing 
>> the workflow for submitting a change is potentially beneficial to you. 
>> 
>> Yes, he could do it in just a couple minutes.  But then you've missed an 
>> opportunity to learn something that might allow you to contribute to OI. 
>> 
>> [1] the origin of this proverb appears to be quite contested, but it 
>> seems like it might be Lao-Tzu. 
>> 
>> Tim 
>> 
>>>  On Sun, 10 Jan 2021 00:49:50 +0700 Aurélien Larcher 
>>>  wrote  
>>> 
 
 
 On Sat, Jan 9, 2021 at 9:09 AM Hung Nguyen Gia via oi-dev 
  wrote: 
 This should be done for none desktop OI flavors: OI text and OI minimal. 
 
 It will help novice user like me very much. Please consider it, 
 developers. I have trouble using the vi editor even though I have my 
 mobile phone with me as a backup showing the vi tutorial. And I think many 
 other novice users have the same trouble as me. 
 
 Doing as Fedora is a step too far: 
 https://www.phoronix.com/scan.php?page=news_item=Fedora-33-Nano-Is-The-Default
  
 
 I only asked for shipping nano alongside with vi. The link I put above 
 just to note that nano has pretty much become the default editor on the 
 Linux world and most of us come from Linux. It will be easier for us. 
 Thanks. 
 
 Hello, 
 basically one could add the nano package to: 
 
 https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/meta-packages/install-types/includes/minimal
  
 
 Kind regards, 
 
 Aurélien 
 
 
 
 ___ 
 oi-dev mailing list 
 oi-dev@openindiana.org 
 https://openindiana.org/mailman/listinfo/oi-dev 
 
 
 -- 
 --- 
 Praise the Caffeine embeddings 
 ___ 
 oi-dev mailing list 
 oi-dev@openindiana.org 
 https://openindiana.org/mailman/listinfo/oi-dev 
 
>>> 
>>> ___ 
>>> oi-dev mailing list 
>>> oi-dev@openindiana.org 
>>> https://openindiana.org/mailman/listinfo/oi-dev 
>>> 
>> 
>> -- 
>> Tim Mooney tim.moo...@ndsu.edu 
>> Enterprise Computing & Infrastructure / 
>> Division of Information Technology/701-231-1076 (Voice) 
>> North Dakota State University, Fargo, ND 
>> 58105-5164___ 
>> oi-dev mailing list 
>> oi-dev@openindiana.org 
>> https://openindiana.org/mailman/listinfo/oi-dev 
>> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] How many CPUs does OI support?

[Toomas Soome via oi-dev]

> On 8. Jan 2021, at 09: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?
> 
> Thank you for all your time, and consideration.
> 
> —Chris
> 


well, ncpu is signed int… ;)

rgds,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] loader problems on upgrade

[Toomas Soome via oi-dev]

> On 29. May 2020, at 16:09, Carsten Grzemba via oi-dev 
>  wrote:
> 
> I upgraded my system  on Supermicro X10SLM from quite older OI (2017) to 
> current and faces some problems here.
> Got a system panic on first boot an then on loader
> - loader shows a lot of old BE's which not exist anymore for a long time in 
> the rpool

Loader does get the BE list from rpool/boot/menu.lst file, you can remove the 
file and when you use beadm, it will re-populate it.


> - if I walk through the BE list I can't select a BE in the subsequent 
> choices, it selects from the first choice, forunatly select with 'beadm' on 
> loader CLI works!

hitting ghost entries?

> - most most annoying thing: can't see the serial console anymore if the 
> system boots, on the old version it worked with ttyb

set console=ttyb
boot -k

rgds,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] lenovo?

[Toomas Soome via oi-dev]

hi!

does anyone use lenovo PowerEdge R640 Server for solaris or illumos?

thanks,
toomas___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] IPS package

[Toomas Soome via oi-dev]

> On 11. May 2020, at 16:30, G B via oi-dev  wrote:
> 
> I started over and got farther, but now it has a conflict:

You can not change attributes of shared directories (groups are different).

rgds,
toomas


> 
> root@pluto:/# pkgsend generate racket | pkgfmt > racket.p5m.1
> root@pluto:/# pkgmogrify racket.p5m.1 racket_manifest | pkgfmt > racket.p5m.2
> root@pluto:/# pkgdepend generate -md racket racket.p5m.2 |pkgfmt > 
> racket.p5m.3
> root@pluto:/# pkgdepend resolve -m racket.p5m.3
> root@pluto:/# pkglint racket.p5m.3.res 
> Lint engine setup...
> Starting lint run...
> WARNING pkglint.action005.1   obsolete dependency check skipped: unable 
> to find dependency pkg:/SUNWcs@0.5.11-2020.0.1.19662 for pkg:/racket@7.7,5.11
> WARNING pkglint.action005.1   obsolete dependency check skipped: unable 
> to find dependency pkg:/system/library/math@0.5.11-2020.0.1.19662 for 
> pkg:/racket@7.7,5.11
> WARNING pkglint.action005.1   obsolete dependency check skipped: unable 
> to find dependency pkg:/system/library@0.5.11-2020.0.1.19662 for 
> pkg:/racket@7.7,5.11
> root@pluto:/# pkgrepo create myrepo
> root@pluto:/# pkgrepo -s myrepo set publisher/prefix=site
> root@pluto:/# pkgsend -s myrepo publish -d racket racket.p5m.3.res 
> pkg://site/racket@7.7,5.11:20200511T131012Z
> PUBLISHED
> root@pluto:/# pkgrepo info -s myrepo
> PUBLISHER PACKAGES STATUS   UPDATED
> site  1online   2020-05-11T13:13:21.398732Z
> root@pluto:/# 
> root@pluto:/# pkg set-publisher -p myrepo
> pkg set-publisher:
>   Updated publisher(s): site
> root@pluto:/# pkg publisher
> PUBLISHER   TYPE STATUS P LOCATION
> openindiana.org  origin   online F 
> http://pkg.openindiana.org/hipster/
> hipster-encumbered  origin   online F 
> http://pkg.openindiana.org/hipster-encumbered/
> siteorigin   online F file:///myrepo/
> root@pluto:/# pkg install racket@7.7
> Creating Plan (Checking for conflicting actions): -
> pkg install: The requested change to the system attempts to install multiple 
> actions
> for dir 'opt' with conflicting attributes:
> 
> 1 package delivers 'dir group=bin mode=0755 owner=root path=opt':
> pkg://site/racket@7.7,5.11:20200511T131012Z
> 1 package delivers 'dir group=sys mode=0755 owner=root path=opt':
> 
> pkg://openindiana.org/SUNWcs@0.5.11,5.11-2020.0.1.19662:20200503T194230Z
> 
> 
> These packages cannot be installed together. Any non-conflicting subset
> of the above packages can be installed.
> 
> 
> 
> Changed the manifest:
> 
> root@pluto:/# cat racket_manifest 
> set name=pkg.fmri value=racket@7.7
> set name=pkg.description value="Racket programming language"
> set name=pkg.summary value="Racket is a general-purpose programming language 
> as well as the world’s first ecosystem for language-oriented programming."
> set name=variant.opensolaris.zone value=global value=nonglobal
> set name=variant.arch value=i386
> root@pluto:/# 
> 
> 
> On Monday, May 11, 2020, 7:53:38 AM CDT, G B  wrote:
> 
> 
> My guess is the manifest.  Do I need more than just this?
> 
> set name=pkg.fmri value=racket@7.7,5.11-0
> set name=pkg.description value="Racket programming language"
> set name=pkg.summary value="Racket is a general-purpose programming language 
> as well as the world’s first ecosystem for language-oriented programming."
> set name=variant.arch value=$(ARCH)
> 
> 
> 
> On Monday, May 11, 2020, 7:50:26 AM CDT, G B  wrote:
> 
> 
> root@pluto:/# pkg install -v racket@7.7,5.11-0
> 
> pkg install: The following pattern(s) only matched packages that are not 
> available
> for the current image's architecture, zone type, and/or other variant:
> racket@7.7,5.11-0
> 
> 
> 
> On Monday, May 11, 2020, 7:43:49 AM CDT, Volker A. Brandt  
> wrote:
> 
> 
> G B via oi-dev writes:
> > root@pluto :/# pkg install racket
> >
> > pkg install: The following pattern(s) only matched packages that are not
> > available
> > for the current image's architecture, zone type, and/or other variant:
> >racket
> 
> It's always a good idea to do a verbose run, and give the specific 
> version of the package you want to install.  In your case:
> 
>   # pkg install -v racket@7.7 ,5.11-0
> 
> This should give you more detailed error messages.  Maybe we can then
> figure out what the problem is.
> 
> 
> Regards -- Volker
> --
> 
> Volker A. BrandtConsulting and Support for Solaris-based Systems
> Brandt & Brandt Computer GmbH  WWW: http://www.bb-c.de/ 
> 
> Am Wiesenpfad 6, 53340 Meckenheim, GERMANYEmail: v...@bb-c.de 
> 
> Handelsregister: Amtsgericht Bonn, HRB 10513  Schuhgröße: 46
> Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt
> 
> "When logic and proportion have fallen sloppy dead"
> 

Re: [oi-dev] IPS package

[Toomas Soome via oi-dev]

did you pkgrepo refresh?

rgds,
toomas

> On 11. May 2020, at 15:00, G B via oi-dev  wrote:
> 
> I attempted to create an IPS package of Racket, the programming language, and 
> everything seemed to have worked correctly.  But when I tried to install it 
> from my local repository it fails.
> 
> root@pluto:/# pkg install racket
> 
> pkg install: The following pattern(s) only matched packages that are not 
> available
> for the current image's architecture, zone type, and/or other variant:
> racket
> 
> These are the steps I used:
> # pkgsend generate racket | pkgfmt > racket.p5m.1
> # cat racket_manifest
> set name=pkg.fmri value=racket@7.7,5.11-0
> set name=pkg.description value="Racket programming language"
> set name=pkg.summary value="Racket is a general-purpose programming language 
> as well as the world’s first ecosystem for language-oriented programming."
> set name=variant.arch value=$(ARCH)
> # pkgmogrify racket.p5m.1 racket_manifest | pkgfmt > racket.p5m.2
> # pkgdepend generate -md racket racket.p5m.2 | pkgfmt > racket.p5m.3
> # pkgdepend resolve -m racket.p5m.3
> # pkglint racket.p5m.3.re
> # pkgrepo create local-repository
> # pkgrepo -s local-repository set publisher/prefix=localpublisher
> # pkgsend -s local-repository publish -d racket racket.p5m.3.res
> # pkg set-publisher -p local-repository
> # pkg install racket
> Then I get the error shown above.  This is on OpenIndiana 2020504.  The 
> working directory is racket and the tree is /racket/opt/racket-7.7
> 
> Thanks.
> 
>  
> 
> 
> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] illumos-gcc (gcc 4.4.4-il)

[Toomas Soome via oi-dev]

> On 11. May 2020, at 11:04, Aurélien Larcher  
> wrote:
> 
> Sorry for the delay, yes it is because it does not build with recent gcc.
> I did not have time to fix it and since it worked as it was I left it with 
> gcc-49.
> 


Ye, and gcc49 is building with itself:D but it seems we can build it with 7, 
just need to wait before I can be sure:)

thanks,
toomas


> On Monday, May 11, 2020, Toomas Soome via oi-dev  <mailto:oi-dev@openindiana.org>> wrote:
> >
> >
> >> On 11. May 2020, at 10:36, Toomas Soome via oi-dev  >> <mailto:oi-dev@openindiana.org>> wrote:
> >>
> >> Hi!
> >>
> >> The current illumos-gcc build is depending on gcc-49, is there some hard 
> >> requirement for it, or is it just leftover?
> >>
> >
> > ok, this is because 4.4.4 does not build with gcc7.
> >
> > rgds,
> > toomas
> >
> >
> > ___
> > oi-dev mailing list
> > oi-dev@openindiana.org <mailto:oi-dev@openindiana.org>
> > https://openindiana.org/mailman/listinfo/oi-dev 
> > <https://openindiana.org/mailman/listinfo/oi-dev>
> >
> 
> -- 
> ---
> Praise the Caffeine embeddings
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] illumos-gcc (gcc 4.4.4-il)

[Toomas Soome via oi-dev]

> On 11. May 2020, at 10:36, Toomas Soome via oi-dev  
> wrote:
> 
> Hi!
> 
> The current illumos-gcc build is depending on gcc-49, is there some hard 
> requirement for it, or is it just leftover? 
> 

ok, this is because 4.4.4 does not build with gcc7.

rgds,
toomas


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] illumos-gcc (gcc 4.4.4-il)

[Toomas Soome via oi-dev]

Hi!

The current illumos-gcc build is depending on gcc-49, is there some hard 
requirement for it, or is it just leftover? 

rgds,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Bootloader as of today damaged?

[Toomas Soome via oi-dev]

> On 28 Sep 2019, at 12:45, Toomas Soome  wrote:
> 
> 
> 
>> On 28 Sep 2019, at 12:11, Andreas Wacknitz  wrote:
>> 
>> Hi all,
>> 
>> I have updated one of my build servers today and it stopped working after 
>> reboot.
>> I get a black screen (before the bootloader prompt typically is shown). So, 
>> my conclusion is that
>> the bootloader is damaged. I have re-installed OI with Michal's latest text 
>> image and after pkg update
>> the boot fails again.
>> Has anybody else experienced the same?
>> 
>> Regards,
>> Andreas
> 
> poke me on irc and we can do some diag…
> 
> rgds,
> toomas
> 


hi!

As it did turn out, it is not about bootloader being damaged, but installboot 
doing slightly wrong (updating VBR/PBR while stage2 was not updated). I’ll try 
to get the fix integrated asap, but for now, the workaround is:

after you run pkg update, force update of boot program with: 
beadm mount NEWBE /mnt
bootadm install-bootloader -f -R /mnt

Or wait with update till the repo has loader package more recent than 

Packaging Date: 28 September 2019 at 01:31:17 
  Size: 2.26 MB
  FMRI: 
pkg://openindiana.org/system/boot/loader@1.1,5.11-2019.0.0.19070:20190928T013117Z

or /boot/gptzfsboot more recent than (use installboot -i /boot/gptzfsboot):
Extended version string: 1.1-2019.09.20.1

I’ll update installboot soon to make such error impossible in future.

sorry about the mess,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Bootloader as of today damaged?

[Toomas Soome via oi-dev]

> On 28 Sep 2019, at 12:11, Andreas Wacknitz  wrote:
> 
> Hi all,
> 
> I have updated one of my build servers today and it stopped working after 
> reboot.
> I get a black screen (before the bootloader prompt typically is shown). So, 
> my conclusion is that
> the bootloader is damaged. I have re-installed OI with Michal's latest text 
> image and after pkg update
> the boot fails again.
> Has anybody else experienced the same?
> 
> Regards,
> Andreas

poke me on irc and we can do some diag…

rgds,
toomas

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] How to create an ISO correctly?

[Toomas Soome via oi-dev]

> On 27 Aug 2019, at 00:46, Gary Mills  wrote:
> 
> Another progress report and some questions: I have now replaced all
> v9os packages with oi-userland packages.  There are no v9os packages
> left.  My T2000 has only oi-userland packages, ones that I have built.
> It boots correctly.  The publisher name is oi-userland, not the usual
> userland or openindiana.org .  That difference raises my first
> question.
> 
> I've read the information on distribution-constructor:
> 
>http://docs.openindiana.org/dev/distribution-constructor/
> 
> as well as the man page for distro_const .  Neither of them answered
> my questions completely.
> 
> Will distro_const change the publisher in the ISO file, both for the
> packages and the `pkg publisher' command?  How do I do this?

Those are set in DC xml manifest file, see

pkg_repo_default_authority
post_install_repo_default_authority

> 
> If not, can the publisher be changed on the host system?  Does the
> publisher in `pkg publisher' have to match the one in the file
> repository?
> 
> I see that the XML file used by distro_const specifies `entire' as the
> package that includes all the packages to install to the ISO file.
> My system has no package `entire'.  How do I create and populate it?
> Will it include some packages that do not exist?  Will this be a
> problem?
> 
> Finally, how do I create a USB image from the CD image?
> 


it is generated from iso with help of /usr/share/distro_const/create_usb, which 
in turn is using /bin/usbgen, but at this time, it is all about x86. So the 
SPARC updates have to be implemented still. The code is in 
https://github.com/OpenIndiana/slim_source 
.

rgds,
toomas

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] [developer] suspend/resume in Illumos

[Toomas Soome via oi-dev]

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.

Sent from my iPhone

> On 11 Jun 2019, at 22:58, Garrett D'Amore  wrote:
> 
> My gut instinct is that this isn’t that interesting – most everyone is 
> running illumos in either VMs, or in datacenter applications where 
> suspend/resume has little if any applicability.
>  
> While the work itself is probably interesting, and it may enable new 
> applications for illumos, the concern I’d have would be detraction from other 
> more pressing work, without any clear use cases for it.
>  
> That said, if someone (you?) wanted to spend cycles on this for personal 
> satisfaction, I hardly see any reason to discourage it, and I’m fairly 
> certain if the risks of the new code being introduced are small (or well 
> managed by sufficient testing for example), I can’t see any other reason we 
> would reject a suitably formed RTI.
>  
> Sent from Mail for Windows 10
>  
> From: ran...@sibernet.com
> Sent: Tuesday, June 11, 2019 11:10 AM
> To: oi-dev@openindiana.org; develo...@lists.illumos.org
> Subject: [developer] suspend/resume in Illumos
>  
>  
>  
> I have a question for developers here:
>  
> How important is suspend/resume for OI/Illumos (including S4)?
>  
>  
> One of the incomplete projects left behind was S4 (lack of need, and a
> hard to identify bug stifled it's integration).  It is non-trivial, and
> needs updated s/r core code (added configuration and significant
> restructuring, as well as likely assistance from developers knowlegable in
> other Illumos internals), but if this is an uninteresting feature, it is
> likey not worth the effort (recent bugs suggest that few if anyone use
> it); however, it wouldn't be too hard to resurect (though would still take
> several months of work).
>  
>  
>Cheers!
>  
>  Randy
>  
> --
> illumos: illumos-developer
> Permalink: 
> https://illumos.topicbox.com/groups/developer/Tb3e65f5ac470e30c-M221586bbcf19e81e63ecf58f
> Delivery options: https://illumos.topicbox.com/groups/developer/subscription
>  
> illumos / illumos-developer / see discussions + participants + delivery 
> options Permalink
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Importing data from wiki to oi-docs

[Toomas Soome via oi-dev]

LGTM:)

rgds,
toomas

> On 14 May 2019, at 10:55, Alexander Pyhalov via oi-dev 
>  wrote:
> 
> Hi.
> 
> I've been looking at updating 'Building oi-userland' oi-docs page. 
> 
> And found the following isue - we have long top-level menu, which is hard to 
> extend (it is splitted in two lines when extended). 
> Updated mkdocs have third-level menus, which helps with issue.
> 
> So I've created two PRs - https://github.com/OpenIndiana/oi-docs/pull/105 and 
> https://github.com/OpenIndiana/oi-userland/pull/5006 .
> 
> The first one updates oi-docs layout (and brings in information from wiki 
> pate 'Building oi-userland' to corresponding oi-docs page). The second - 
> updates our mkdocs in OI.
> 
> Result can be seen here: http://buildzone.oi-build.r61.net/oi-docs/ .
> 
> As you can see, theme seems to be changed a bit. 
> 
> Looking at your comments. 
> If I receive no negative feedback, I'll push changes tomorrow
> 
> Best regards, 
> Alexander Pyhalov, 
> system administrator of Southern Federal University IT department
> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] SMF service enabled by default in global zone

[Toomas Soome via oi-dev]

You need SMF profile. Google will help, also see /etc/svc/profile.

Sent from my iPhone

> On 7 May 2019, at 23:27, Till Wegmüller  wrote:
> 
> Hi
> 
> The only way I know in the IPS framework is to use variants and two
> seperate xml files for zone.global and zone.nonglobal environment
> 
> Greetings
> Till
> 
>> On 07.05.19 22:12, Michal Nowak wrote:
>> Hi,
>> 
>> I want to modify a SMF service so it's enabled by default once it's
>> installed in global zone. In non-global zone the service must be
>> disabled by default and may be enabled by admin manually (e.g. by
>> setting SMF prop value).
>> 
>> How do I do that in SMF? Is there an example of such a service already?
>> 
>> I figured out that '' does the
>> enablement, but how to limit this to global zone?
>> 
>> Thanks,
>> Michal
>> 
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev


___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] HEADS UP: loader FB console

[Toomas Soome via oi-dev]

Hi!

With "10028 loader: implement framebuffer console “, the loader does attempt to 
use framebuffer console as default. We still do not provide FB console for 
kernel/userland, but stay tuned:)


The change does provide some notable features:

framebuffer command to set/get/list the modes, and switch FB off.  It can be 
used in /boot/loader.rc.local (or remove .local) to set gfx mode.

loadfont command for manual loading of console fonts (provided in /boot/fonts). 
Default built in font is 8x16, default loaded font depends on gfx mode.

set screen-font= to switch font based on size

set tem.fg_color=
set tem.bg_color=
set tem.inverse=
set tem.inverse-screen=

we do support standard ansi colors by name or values 0-7, variables can be set 
in loader.conf or /boot/conf.d/* (without set command, just name=value).

thanks,
toomas
___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] new set of demo iso/usb

[Toomas Soome via oi-dev]

hi!

As lewellyn did complain about loader screen performance, I did a small update 
to boost it and did generate new iso/usb images on 
http://148.52.235.80.sta.estpak.ee 

The iso can be booted directly from usb stick (altho the OI boot scripts will 
fail you there;)

it would be nice to get some feedback about loader screen performance (also 
note the framebuffer command in loader and tem* and screen* variables from the 
output of show command).

thanks,
toomas___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] required header-idnkit for illumps-gate obsolete

[Toomas Soome via oi-dev]

> On 11 Dec 2018, at 15:17, Udo Grabowski (IMK)  wrote:
> 
> Hi,
> regarding the message from Dan on library/libidn/header-idnkit:
> This package is currently obsolete on oi-Hipster (as of 2018-10).


but is ok in 
http://pkg.openindiana.org/hipster/info/0/library%2Fidnkit%2Fheader-idnkit%405.11%2C5.11-2018.0.0.0%3A20181113T172737Z
 


rgds,
toomas

> 
> On Dec 10, 2018, at 7:51 PM, Dan McDonald  wrote:
> >
> > Hello!
> >
> >The integration of illumos 9997 which brings in iconv into illumos-gate 
> >>constitutes a flag day for people who build illumos-gate, or children which 
> >>have this fix in place.  /usr/include/idn/{api,version}.h MUST be in place 
> >on >your build system.
> >
> >On both OmniOS and OpenIndiana, these are part of the 
> >library/libidn/header-idnkit package.
> >
> >For SmartOS, make sure your copy of illumos-extra is up to date as of today.
> >
> >Other distros please follow-up here with your instruction(s).
> >
> >If you do not have these headers, you will get a lot of build noise in your 
> >>failure, lead off by:
> >
> >../common//ace_utf8.c:35:21: error: idn/api.h: No such file or directory
> >../common//ace_utf8.c:36:25: error: idn/version.h: No such file or directory
> >
> >Thanks,
> >Dan
> >
> -- 
> Dr.Udo Grabowski   Inst.f.Meteorology & Climate Research IMK-ASF-SAT
> http://www.imk-asf.kit.edu/english/sat.php
> KIT - Karlsruhe Institute of Technology   http://www.kit.edu
> Postfach 3640,76021 Karlsruhe,Germany T:(+49)721 608-26026 F:-926026
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] GCC 7.3.0-il-1

[Toomas Soome via oi-dev]

Aurélien,

Huge thanks, all this development to clean up gcc 6, gcc 7 and now the on-going 
cleanup with gcc 8, it all would not have been possible without the compilers 
and You did the huge work with all those compilers. It would not have been 
possible without the work from Rich and Andy and all others doing reviews, 
testing etc but it still took that one person to actually start porting the 
4.4.4 patches and actually build the compiler and make it available!

Thanks again,
Toomas

> On 31 Oct 2018, at 23:59, Aurélien Larcher  wrote:
> 
> Hello,
> about 2.5 years ago I started playing with more recent versions of GCC: the 
> intent was to support illumos by providing a testing environment for new 
> compilers.
> I added GCC 5.x in Aug 2016, GCC 6.x in Jan 2017, GCC 7.x in April 2017, then 
> GCC 8.x in Jan 2018.
> 
> With the help of Rich Lowe illumos patches were rebased to allow building 
> illumos and userland wih the same compiler: GCC 5/6 in Feb 2017 , GCC 7 in 
> April 2017, GCC 8 in Jan 2018.
> Dates are a good way to measure that many things that happened since the 
> first stages.
> 
> Thanks to Toomas who relentlessly fixed illumos-gate with gcc-7 we are now 
> able to build it (I have been running for almost a year cherry-picking his 
> patches on the go).
> 
> Rich finally pushed GCC 7.3.0-il-1 as the new candidate for the default 
> illumos compiler:
> 
> https://github.com/illumos/gcc/releases 
> 
> 
> This is a great achievement, congratulations to Toomas, Rich, and everybody 
> involved.
> A shadow compilaton with gcc-7 was added recently to illumos-gate to identify 
> possible issues introduced by RTIs.
> 
> Our gcc-7 paclage will be updated soon with the il-1 patchset (same patchset 
> except one patch has been improved by John Levon): gcc 7.3.0-OI-2 will become 
> gcc 7.3.0-il-1.
> 
> We still provide testing build based on gcc-8 for userland, and gcc-7 for 
> illumos-gate:
> 
> https://pkg.openindiana.org/gcc-next/ 
> 
> While illumos-gate does not build yet with gcc-8 the patchset has been around 
> for a while: looking forward to the next GCC 8.x.0-il.
> 
> Kind regards,
> 
> Aurélien
> 
> -- 
> ---
> Praise the Caffeine embeddings
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Slow Loader on Samsung 950 Pro

[Toomas Soome via oi-dev]

> On 24 Sep 2018, at 21:20, Till Wegmüller  wrote:
> 
> Hi Toomas
> 
> The system was installed two weeks ago and updated about one week ago.
> What I noticed when booting is:
> The first spinner already akes a couple of seconds to load loader wheras
> on the iso it takes at most one second.

So, in your case the disk (not cd) io is to be investigated. 

> What takes most time is Display of available memory after displaying the
> seem bios drives.
> 

That is the biosdisk init and zfs probe, yes.

> Loading things like the string class is fast as expected.
> Loading menu config and boot_archive from disk is what takes most time.
> 
> Your dev version of loader gets as far as printing the system bios
> drives on white background and then stop

That probably means it stops while probing for zfs pools. So we need to 
investigate, why... but for that we need to insert some debug printouts.

> Loader on Hipster takes some time to print the bios memory then it
> continious.
> 
> Loader from your dev link also sees a fd device which current stable
> loader does not. I have no Floppy disk device in that computer.
> Does this help?
> 

A bit,  but we definitely need to investigate it further.  Anyhow, I only can 
check email this week, I left my laptop home on purpose:)

Rgds,
Toomas
> 
>> On 09/24/18 02:55 PM, Toomas Soome via oi-dev wrote:
>> Forgot to note, you should also be able to boot usb/iso, press esc from 
>> menu. Then use beadm list zfs:rpool and beadm activate zfs:rpool and then 
>> enter boot
>> 
>> Sent from my iPhone
>> 
>>> On 24 Sep 2018, at 15:40, Toomas Soome via oi-dev  
>>> wrote:
>>> 
>>> Installed or pkg update is also done?
>>> 
>>> I am on the trip this week and can not help with code, but from 
>>> http://148.52.235.80.sta.estpak.ee you can find iso/usb image, and from it 
>>> you can copy the dev version of loader binary. You can copy it with new 
>>> name and if you press the space just when the first spinner, you can enter 
>>> the new name.
>>> 
>>> Basically I’d like to establish if the error is actually fixed...
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 24 Sep 2018, at 15:18, Till Wegmüller  wrote:
>>>> 
>>>> Hi Setup is most recent Hipster installed two weeks ago.
>>>> 
>>>> Greetings
>>>> Till
>>>>> On 9/24/18 1:44 PM, Toomas Soome via oi-dev wrote:
>>>>> What version, or how old is the setup? The older ones had some cases 
>>>>> where the read past disk end and with some systems this can cause 
>>>>> slowdown as described.
>>>>> 
>>>>> Rgds,
>>>>> Toomas
>>>>> 
>>>>> Sent from my iPhone
>>>>> 
>>>>>> On 24 Sep 2018, at 13:03, Till Wegmüller  wrote:
>>>>>> 
>>>>>> Hello
>>>>>> 
>>>>>> Has anybody tested loader on an NVME Disk? I have two Samsung 950 Pro in
>>>>>> a mirror Zpool Configuration. They are nicely fast but not during boot.
>>>>>> To be more precise loader requires more than 20minutes to get to the
>>>>>> point at which it has loaded the kernel and Ramdisk into memory. From
>>>>>> there the Kernel requires about 10-20 seconds to boot to graphical 
>>>>>> desktop.
>>>>>> 
>>>>>> I would like to start debugging that issue. Where can I start?
>>>>>> 
>>>>>> Thanks and Greetings
>>>>>> Till
>>>>>> 
>>>>>> ___
>>>>>> oi-dev mailing list
>>>>>> oi-dev@openindiana.org
>>>>>> https://openindiana.org/mailman/listinfo/oi-dev
>>>>> 
>>>>> ___
>>>>> oi-dev mailing list
>>>>> oi-dev@openindiana.org
>>>>> https://openindiana.org/mailman/listinfo/oi-dev
>>>>> 
>>>> 
>>>> ___
>>>> oi-dev mailing list
>>>> oi-dev@openindiana.org
>>>> https://openindiana.org/mailman/listinfo/oi-dev
>>> 
>>> ___
>>> oi-dev mailing list
>>> oi-dev@openindiana.org
>>> https://openindiana.org/mailman/listinfo/oi-dev
>> 
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
>> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Slow Loader on Samsung 950 Pro

[Toomas Soome via oi-dev]

Forgot to note, you should also be able to boot usb/iso, press esc from menu. 
Then use beadm list zfs:rpool and beadm activate zfs:rpool and then enter boot

Sent from my iPhone

> On 24 Sep 2018, at 15:40, Toomas Soome via oi-dev  
> wrote:
> 
> Installed or pkg update is also done?
> 
> I am on the trip this week and can not help with code, but from 
> http://148.52.235.80.sta.estpak.ee you can find iso/usb image, and from it 
> you can copy the dev version of loader binary. You can copy it with new name 
> and if you press the space just when the first spinner, you can enter the new 
> name.
> 
> Basically I’d like to establish if the error is actually fixed...
> 
> Sent from my iPhone
> 
>> On 24 Sep 2018, at 15:18, Till Wegmüller  wrote:
>> 
>> Hi Setup is most recent Hipster installed two weeks ago.
>> 
>> Greetings
>> Till
>>> On 9/24/18 1:44 PM, Toomas Soome via oi-dev wrote:
>>> What version, or how old is the setup? The older ones had some cases where 
>>> the read past disk end and with some systems this can cause slowdown as 
>>> described.
>>> 
>>> Rgds,
>>> Toomas
>>> 
>>> Sent from my iPhone
>>> 
>>>> On 24 Sep 2018, at 13:03, Till Wegmüller  wrote:
>>>> 
>>>> Hello
>>>> 
>>>> Has anybody tested loader on an NVME Disk? I have two Samsung 950 Pro in
>>>> a mirror Zpool Configuration. They are nicely fast but not during boot.
>>>> To be more precise loader requires more than 20minutes to get to the
>>>> point at which it has loaded the kernel and Ramdisk into memory. From
>>>> there the Kernel requires about 10-20 seconds to boot to graphical desktop.
>>>> 
>>>> I would like to start debugging that issue. Where can I start?
>>>> 
>>>> Thanks and Greetings
>>>> Till
>>>> 
>>>> ___
>>>> oi-dev mailing list
>>>> oi-dev@openindiana.org
>>>> https://openindiana.org/mailman/listinfo/oi-dev
>>> 
>>> ___
>>> oi-dev mailing list
>>> oi-dev@openindiana.org
>>> https://openindiana.org/mailman/listinfo/oi-dev
>>> 
>> 
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Slow Loader on Samsung 950 Pro

[Toomas Soome via oi-dev]

Installed or pkg update is also done?

I am on the trip this week and can not help with code, but from 
http://148.52.235.80.sta.estpak.ee you can find iso/usb image, and from it you 
can copy the dev version of loader binary. You can copy it with new name and if 
you press the space just when the first spinner, you can enter the new name.

Basically I’d like to establish if the error is actually fixed...

Sent from my iPhone

> On 24 Sep 2018, at 15:18, Till Wegmüller  wrote:
> 
> Hi Setup is most recent Hipster installed two weeks ago.
> 
> Greetings
> Till
>> On 9/24/18 1:44 PM, Toomas Soome via oi-dev wrote:
>> What version, or how old is the setup? The older ones had some cases where 
>> the read past disk end and with some systems this can cause slowdown as 
>> described.
>> 
>> Rgds,
>> Toomas
>> 
>> Sent from my iPhone
>> 
>>> On 24 Sep 2018, at 13:03, Till Wegmüller  wrote:
>>> 
>>> Hello
>>> 
>>> Has anybody tested loader on an NVME Disk? I have two Samsung 950 Pro in
>>> a mirror Zpool Configuration. They are nicely fast but not during boot.
>>> To be more precise loader requires more than 20minutes to get to the
>>> point at which it has loaded the kernel and Ramdisk into memory. From
>>> there the Kernel requires about 10-20 seconds to boot to graphical desktop.
>>> 
>>> I would like to start debugging that issue. Where can I start?
>>> 
>>> Thanks and Greetings
>>> Till
>>> 
>>> ___
>>> oi-dev mailing list
>>> oi-dev@openindiana.org
>>> https://openindiana.org/mailman/listinfo/oi-dev
>> 
>> ___
>> oi-dev mailing list
>> oi-dev@openindiana.org
>> https://openindiana.org/mailman/listinfo/oi-dev
>> 
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Slow Loader on Samsung 950 Pro

[Toomas Soome via oi-dev]

What version, or how old is the setup? The older ones had some cases where the 
read past disk end and with some systems this can cause slowdown as described.

Rgds,
Toomas

Sent from my iPhone

> On 24 Sep 2018, at 13:03, Till Wegmüller  wrote:
> 
> Hello
> 
> Has anybody tested loader on an NVME Disk? I have two Samsung 950 Pro in
> a mirror Zpool Configuration. They are nicely fast but not during boot.
> To be more precise loader requires more than 20minutes to get to the
> point at which it has loaded the kernel and Ramdisk into memory. From
> there the Kernel requires about 10-20 seconds to boot to graphical desktop.
> 
> I would like to start debugging that issue. Where can I start?
> 
> Thanks and Greetings
> Till
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Sendmail logging to wrong facility

[Toomas Soome via oi-dev]

> On 18 Sep 2018, at 22:24, Gary Mills  wrote:
> 
> On Tue, Sep 18, 2018 at 09:57:40PM +0300, Toomas Soome via oi-dev wrote:
>> 
>>   var/log/daemon.6:Aug  1 12:48:19 beastie sendmail[1189]: [ID 702911
>>   [7]daemon.info] starting daemon (8.14.4+Sun): SMTP+queueing@00:15:00
> 
>>   apparently the daemon part is logging using daemon facility.
> 
> Yes, that's the problem.  How do I determine what's causing it?
> It's likely not sendmail itself.
> 

daemon() call? I guess dtrace would help.

rgds,
toomas

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Sendmail logging to wrong facility

[Toomas Soome via oi-dev]

> On 18 Sep 2018, at 20:37, Gary Mills  wrote:
> 
> On Tue, Sep 18, 2018 at 06:03:48PM +0100, Jonathan Adams wrote:
>>   add this to your syslog.conf:
>>   mail.info;daemon.info�  �  �  �  �  � ifdef(`LOGHOST',
>>   /var/log/syslog, @loghost)
> 
> So, you had the same problem.  Good.  It exists.  Thanks for that
> information.
> 
>>   I found it out by adding every possible log format to the file until I
>>   could work out what had changed.
> 
> I don't like your workaround, however:
> 
> $ grep sendmail /var/adm/messages | wc -l
>  56
> $ grep daemon.info /var/adm/messages | wc -l
>   11624
> 
> I'm mainly trying to work out what had changed.
> 
> My original question was:
> 
>How do I determine the caller?  I need to examine the startup of the
>MTA, as that's where the openlog() calls occur.
> 
> 
> -- 
> -Gary Mills-  -refurb--Winnipeg, Manitoba, Canada-
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev 
> 
var/log/daemon.6:Aug  1 12:48:19 beastie sendmail[1189]: [ID 702911 
daemon.info] starting daemon (8.14.4+Sun): SMTP+queueing@00:15:00

apparently the daemon part is logging using daemon facility.

rgds,
toomas

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] latest loader branch + ACPI patches

[Toomas Soome via oi-dev]

> On 18 Aug 2018, at 21:38, Aurélien Larcher  wrote:
> 
> 
> 
> On Sat, Aug 18, 2018 at 4:45 PM, Toomas Soome  <mailto:tso...@me.com>> wrote:
> 
> 
>> On 18 Aug 2018, at 15:20, Aurélien Larcher > <mailto:aurelien.larc...@gmail.com>> wrote:
>> 
>> 
>> 
>> On Sat, Aug 18, 2018 at 8:45 AM, Toomas Soome via oi-dev 
>> mailto:oi-dev@openindiana.org>> wrote:
>> hi!
>> 
>> I have built the latest state + ACPI patches from Robert, the images are 
>> available at: http://148.52.235.80.sta.estpak.ee 
>> <http://148.52.235.80.sta.estpak.ee/>
>> 
>> Hi Toomas,
>> thanks for doing this :)
>> Should we mirror the images on dlc-int ?
>> 
>> Also I have published your gcc7 branch + ACPI patches to 
>> pkg.openindiana.org/gcc-next <http://pkg.openindiana.org/gcc-next>
>> That's what I am using right now on my workstation.
>> 
>> I could add your loader patches if you want.
>> 
> 
> 
> Hm, I do not mind. The loader branch also has gcc7 (of course).
> 
> Currently in the gcc-next zone illumos-gate builds with gcc-6 (non-debug 
> only).
> Would it make sense to move to gcc-7 already? (e.g. to catch any regression)
>  

I have been running gcc-7 built gate for very long time - thats because gcc 7 
is doing a bit better job on identifying issues and less false positives.

rgds,
toomas

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] latest loader branch + ACPI patches

[Toomas Soome via oi-dev]

> On 18 Aug 2018, at 15:20, Aurélien Larcher  wrote:
> 
> 
> 
> On Sat, Aug 18, 2018 at 8:45 AM, Toomas Soome via oi-dev 
> mailto:oi-dev@openindiana.org>> wrote:
> hi!
> 
> I have built the latest state + ACPI patches from Robert, the images are 
> available at: http://148.52.235.80.sta.estpak.ee 
> <http://148.52.235.80.sta.estpak.ee/>
> 
> Hi Toomas,
> thanks for doing this :)
> Should we mirror the images on dlc-int ?
> 
> Also I have published your gcc7 branch + ACPI patches to 
> pkg.openindiana.org/gcc-next <http://pkg.openindiana.org/gcc-next>
> That's what I am using right now on my workstation.
> 
> I could add your loader patches if you want.
> 


Hm, I do not mind. The loader branch also has gcc7 (of course).

rgds,
toomas

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

[oi-dev] latest loader branch + ACPI patches

[Toomas Soome via oi-dev]

hi!

I have built the latest state + ACPI patches from Robert, the images are 
available at: http://148.52.235.80.sta.estpak.ee 


rgds,
toomas___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev

Re: [oi-dev] Please Zip compress the USB downloads from OI

[Toomas Soome via oi-dev]

I do have the isoboot boot code and some companion work ported over, so we can 
get hybrid iso files, but note, unfortunately it is not 100% universally 
supported. There are bios implementations choking on hybrid images... thats 
according to reports from FreeBSD. 

Sent from my iPhone

> On 10 Aug 2018, at 22:23, Till Wegmüller  wrote:
> 
> Hi
> 
> The Image itself is compressed. However not the USB part but the LOFI
> File representing /usr on the Live system.
> 
> What you compressed was the Sparse part of the image. I.e the Allocated
> but not used USB Image Parts.
> 
> As soon as we have the combined image that will be solved.
> 
> What will help however Especially for people in the US is to pick a
> local mirror. AFAIK the main Server is in the UK not US.
> 
> 
> Greetings
> Till
> 
>> On 10.08.2018 19:22, Bob Friesenhahn wrote:
>>> On Fri, 10 Aug 2018, John Howard wrote:
>>> 
>>> Yesterday I downloaded the minimal USB.  I am in USA, not Europe or Asia,
>>> so I did not choose an alternative mirror for the download.  Average
>>> speed
>>> was modem circa 1990 around 56 Kb/s.  It took almost 3 hours.  Okay, if
>>> that is how it is now.
>>> 
>>> The problem is, out of curiousity, I compressed the downloaded minimal
>>> USB
>>> file 25% using Zip.
>>> Similar savings result for the 2 GiB Live USB down to 1.6 GiB.
>> 
>> If the image is to be compressed, then it is likely that there is a
>> popular compression algorithm (e.g. xz or 7zip) which is more effective
>> than gzip.
>> 
>> Bob
> 
> ___
> oi-dev mailing list
> oi-dev@openindiana.org
> https://openindiana.org/mailman/listinfo/oi-dev

___
oi-dev mailing list
oi-dev@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev