Re: [OpenIndiana-discuss] The Register today

[Chris]

On 2021-05-10 02:23, Toomas Soome via openindiana-discuss wrote:

On 10. May 2021, at 12:05, Volker A. Brandt  wrote:

Toomas Soome writes:

The immediate issue is https://www.illumos.org/issues/2757. In core, this
issue means that negative 32-bit numbers are not translated to negative
64-bit numbers. Currently used gcc 4.4.4 does implement such translation 
in

compiler, there is no such patch for more recent compilers (firstly, the
code path in more recent compilers has changed a lot, and secondly, such
translation should be done by OS). This effectively does block switch from
gcc 4.4.4. I actually am running gcc 7 built system, knowingly, keeping in
mind that I may be bitten by problems cause by this issue.


In other words, when that issue is fixed, the primary compiler could be
switched to gcc 7?



yes, assuming the needed cleanups are done;) but then again, this issue has 
been

open for ~10 years.





Secondly, there are SPARC optimizer issues in gcc 7 and gcc 9 (likely with
10 as well), crashing compiler while building specific parts of illumos
tree. One example:

[...]

Could this be worked around by selectively turning off -O2 until that
is fixed?


I have -O1 in my local patch, yes. But, the implication of this issue is, we 
do
not really know how much, or to what extent, we can count on gcc. I do 
realize
this does sound like FUD, but we do depend on external compiler and projects 
are

rather removing SPARC support...




I haven’t had time to open bugreport with gcc.


Fair enough.

[...]
As a side note, it is interesting to see SPARC related discussion in this 
list; there is no package repository for SPARC by OpenIndiana;)


Yes.  However, there are people working on new infrastructure for OI;
as soon as that is in place there will be a public repo for OI/SPARC.



Yes, I am aware of that too. From one hand it is nice, but from other hand, 
there

is a reason *why* I would vote for removing SPARC support.

And the reason is, I do think we should stop looking backward and start 
looking
forward. I’d rather spend my time on building support for things like arm64 
or
risc-v or some quantum computer or something what really matters for future 
of

this OS.
While I agree with you that OI _should_ look to, and target the future with 
its
development efforts. As that will ensure its future relevance. I'm a bit 
nostalgic,
and would hope that there is still a place for those that have the time, to 
post

their work in an OI supported (SPARC) repo.
-- long live SPARC!

--Chris


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


--

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

Re: [OpenIndiana-discuss] Multiboot on PC

[Chris]

On 2021-05-04 16:03, John D Groenveld wrote:

In message , Chris writes:

I would _think_ at this point in time pretty much any (recent version of)
OS would have little trouble installing their firmware into the ESP
making (U)EFI multi-boot pretty simple as compared to the trickery
involved in fooling/abusing the MBR to obtain multi-boot. Isn't it
so w/OI? I _also_ haven't tried (yet).


Yes.
OI has no trouble installing its loader into the EFI GPT partition.
If I installed multi-boot frequently, I might find it convenient if
OI did as Project Trident does and integrate Rod Smith's rEFInd into
its installation but I just don't multi-boot frequently.
https://www.rodsbooks.com/refind/>

+1 on that. I use it on a "hackintosh" laptop I created. Works a treat.
I also rarely use multi-boot. But thought I'd mention what I did because
it got brought up. ;-)


Regardless, when I have a spare moment, I'll try fix any handbook
sections that are confusing.

Thanks!

--Chris

John
groenv...@acm.org

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


--

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

Re: [OpenIndiana-discuss] Multiboot on PC

[Chris]

On 2021-05-04 12:59, James Madgwick wrote:

On Mon, 3 May 2021 20:16:28 +0300
Toomas Soome via openindiana-discuss
 wrote:

Only simple way is to use chainloader (point it to OS partition),
then you are not depending on file system reader implementation etc
etc.

rgds,
toomas


The OI handbook documents use of chainloader just above the text
installer section
(https://docs.openindiana.org/handbook/getting-started/#install-openindiana-using-the-text-installer).

I tested it out a while ago, so far as I can tell it should be
possible to install Linux, MS Windows, OI, BSDs on the same disk.

I only tested it with MBR partition type, not GPT and without (U)EFI.
The handbook says that multibooting is not possible with EFI. I'm not
sure about that, it's possible with other OSs, but as I've not tried it
with OI, I can't comment further.

I would _think_ at this point in time pretty much any (recent version of)
OS would have little trouble installing their firmware into the ESP
making (U)EFI multi-boot pretty simple as compared to the trickery
involved in fooling/abusing the MBR to obtain multi-boot. Isn't it
so w/OI? I _also_ haven't tried (yet).

--Chris


If it was desired to install MS Win + OI + Linux, I would use a
configuration where GRUB was installed to the MBR and used to boot MS
Win (which GRUB can do itself) and Linux, with GRUB's chainloader used
to load the illunos loader. This could be done the other way round with
the illumos loader loading GRUB. However starting from GRUB is more
convenient as all 3 OSs can be shown on the same selection screen.
illumos loader cannot boot MS Win, unless the Windows loader was
installed to a partition, which may not be possible and is certainly
less convenient than booting directly from GRUB.

Cheers,
James

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


--

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

Re: [OpenIndiana-discuss] VirtualBox 6.1.18 nested vms

[Chris]

On 2021-04-27 08:32, L. F. Elia via openindiana-discuss wrote:
From what I recall, nested virtualization might require BIOS changes (at 
least on DELL). Good luck!


lfe...@yahoo.com, Portsmouth VA, 23701
Solaris/LINUX/Windows administration CISSP/Security consulting

On Thursday, April 1, 2021, 07:16:20 AM EDT, russell
 wrote:

 Hi

For what I have read VirtualBox 6.1 introduced the capability to have
nested VMs.

I have created a VM to run VMware 6.7.0u3, however when I attempt to
start any VM inside ESX 6.7.0u3 I get the following message

Failed to power on virtual machine Lethe. This host does not support
"AMD RVI" hardware assisted MMU virtualization. Click here for more
details.

While I haven't examined the specs for your specific version of the AMD CPU.
You won't get the information you desire from the VM. What you're really 
after
is what the VM HOST provides. I think your best bet is to have a look at 
dmesg

specifically dmesg.boot. It's the messages generated during boot. In FreeBSD
parlance; dmesg -a would give it to you, as would; less /var/run/dmesg.boot 
--

Sorry, I don't have my OI box handy to give you the exact incantation for OI.
Another thing to have a peek at is within your BOIS. You will need to be sure
you have VM option(s) enabled in order to expose them to the host OS.

HTH

--Chris

<https://172.16.26.25/ui/#/host/vms/1/monitor/tasks/haTask-1-vim.VirtualMachine.powerOn-646279618>
-

Looking at the log for the VBox VM

00:00:00.812397 Ext Name:    AuthenticAMD
00:00:00.812398 Ext Supports: 0x8000-0x801e
00:00:00.812398 Family:  15      Extended: 10
     Effective: 25
00:00:00.812398 Model:   1      Extended: 2    
Effective: 33
00:00:00.812399 Stepping:    0
00:00:00.812399 Brand ID:    0x000
00:00:00.812399 Ext Features
00:00:00.812399   Mnemonic -
Description  = guest (host)
00:00:00.812400   FPU - x87 FPU on
Chip   = 1 (1)
00:00:00.812400   VME - *Virtual 8086 Mode Enhancements* = 1 (1)
00:00:00.812401   DE - Debugging
extensions   = 1 (1)
00:00:00.812401   PSE - Page Size
Extension   = 1 (1)
00:00:00.812402   TSC - Time Stamp
Counter    = 1 (1)
00:00:00.812403   MSR - K86 Model Specific
Registers  = 1 (1)
00:00:00.812403   PAE - Physical Address
Extension    = 1 (1)
00:00:00.812404   MCE - Machine Check
Exception   = 0 (1)
00:00:00.812404   CX8 - CMPXCHG8B
instruction = 1 (1)
00:00:00.812405   APIC - APIC
On-Chip = 1 (1)
00:00:00.812405   SEP -
SYSCALL/SYSRET    = 1 (1)
00:00:00.812406   MTRR - Memory Type Range
Registers  = 1 (1)
00:00:00.812406   PGE - PTE Global
Bit    = 1 (1)
00:00:00.812407   MCA - Machine Check
Architecture    = 1 (1)
00:00:00.812407   CMOV - Conditional Move
instructions    = 1 (1)
00:00:00.812408   PAT - Page Attribute
Table  = 1 (1)
00:00:00.812408   PSE-36 - 36-bit Page Size
Extension = 1 (1)
00:00:00.812409   NX -
No-Execute/Execute-Disable = 1 (1)
00:00:00.812409   AXMMX - AMD Extensions to MMX
instructions  = 1 (1)
00:00:00.812410   MMX - Intel MMX
Technology  = 1 (1)
00:00:00.812410   FXSR - FXSAVE and FXRSTOR
Instructions  = 1 (1)
00:00:00.812411   FFXSR - AMD fast FXSAVE and FXRSTOR
instructions    = 1 (1)
00:00:00.812411   Page1GB - 1 GB large
page   = 0 (1)
00:00:00.812412   RDTSCP - RDTSCP
instruction = 1 (1)
00:00:00.812413   LM - AMD64 Long
Mode    = 1 (1)
00:00:00.812413   3DNOWEXT - AMD Extensions to
3DNow  = 0 (0)
00:00:00.812414   3DNOW - AMD
3DNow   = 0 (0)
00:00:00.812415   LahfSahf - LAHF/SAHF support in 64-bit
mode = 1 (1)
00:00:00.812415   CmpLegacy - Core multi-processing legacy
mode   = 1 (1)
00:00:00.812416 *SVM - AMD Secure Virtual Machine extensions* = 1 (1)
00:00:00.812416   EXTAPIC - AMD Extended APIC
registers   = 0 (1)
00:00:00.812417   CR8L - AMD LOCK MOV CR0 means MOV
CR8   = 1 (1)
00:00:00.812417   ABM - AMD Advanced Bit
Manipulation = 1 (1)
00:00:00.812418   SSE4A - SSE4A
instructions  = 1 (1)
00:00:00.812418   MISALIGNSSE - AMD Misaligned SSE
mode   = 1 (1)
00:00:00.812419   3DNOWPRF - AMD PREFETCH and PREFETCHW
instructions  = 1 (1)
00:00:00.812419   OSVW - AMD OS Visible
Workaround  

Re: [OpenIndiana-discuss] The kiss of death

[Chris]

On 2021-04-24 16:02, Reginald Beardsley via openindiana-discuss wrote:
FWIW I saw the messages that Nelson posted at the start of this discussion 
on
systems that booted. However, they very likely had relic zfs labels. I've 
had
mysterious "corrupted pools" appear which I was only able to fix by using 
dd(1) to

wipe out the old label.
If it's anything like gpt, you're right. With gpt it's always best to perform 
a
gpart destroy prior to writing a new disk. If you don't delete the indices 
first

than a gpart destroy -F is often required. As memory serves; zfs also has the
destroy option. Which will clear the tables so you don't end up with 
"foreign"

un-referenced labels.

--Chris


I've come to the conclusion that zfs is saving information in places I don't 
know

about and which may or may not get cleared by "zpool labelclear".

Once I recover from the ordeal of this past week I'll go back and conduct 
some
experiments such as creating a slice, creating a pool and then modifying the 
slice

and creating a new pool to see if I can sort out what is happening.

I am very sorry that some of the developers took offense to my posts, but I 
am
very pleased that there is more engagement by the users in testing. "It is 
meet,

right and our bounden duty..."

Reg


 On Saturday, April 24, 2021, 05:16:59 PM CDT, Toomas Soome via
openindiana-discuss  wrote:




On 25. Apr 2021, at 00:53, Nelson H. F. Beebe  wrote:

Toomas Soome mailto:tso...@me.com>> responds today:


...
On 24. Apr 2021, at 23:56, Nelson H. F. Beebe  
wrote:


Thanks for the additional suggestions to get the CentOS-7 based
OpenIndiana to boot.  Here is what I get:

      boot: status
      disk device:
          disk0:  BIOS driver C (167772160 X 512)
            disk0s1: Solaris 2            79GB
              disk0s1a: root              79GB
              disk0s1i: root            8032KB


Why there are two root slices? it should not disturb us but still weird. 
anyhow, can you mail

me full partition table, format -> verify or partition -> print.ole disk

Since this is VM and no dual-boot, I recommend to only do whole disk 
setup (that is, GPT
automatically prepared). But for now, I wonder how your current slices 
are defined:)


...


I booted the failing VM from the CD-ROM, ran "ssh-keygen -A", edited
/etc/ssh/sshd_config to change PermitRootLogin from no to yes, then
ran "/usr/lib/ssh/sshd &".  That let me login remotely from a terminal
window from which I can do cut-and-paste, and I could then do

    # zpool import -R /mnt rpoot

    # format
    Searching for disks...done

    AVAILABLE DISK SELECTIONS:
          0. c4t0d0 
          /pci@0,0/pci1af4,1100@6/disk@0,0
    Specify disk (enter its number): 0

    electing c4t0d0
    [disk formatted]
    /dev/dsk/c4t0d0s0 is part of active ZFS pool rpool. Please see 
zpool(1M).


    FORMAT MENU:
        disk      - select a disk
        type      - select (define) a disk type
        partition  - select (define) a partition table
        current    - describe the current disk
        format    - format and analyze the disk
        fdisk      - run the fdisk program
        repair    - repair a defective sector
        label      - write label to the disk
        analyze    - surface analysis
        defect    - defect list management
        backup    - search for backup labels
        verify    - read and display labels
        save      - save new disk/partition definitions
        inquiry    - show vendor, product and revision
        volname    - set 8-character volume name
        !    - execute , then return
        quit
    format> verify
    Warning: Primary label on disk appears to be different from
    current label.

    Warning: Check the current partitioning and 'label' the disk or use the
        'backup' command.

    Primary label contents:

    Volume name = <        >
    ascii name  = 
    pcyl        = 10442
    ncyl        = 10440
    acyl        =    2
    bcyl        =    0
    nhead      =  255
    nsect      =  63
    Part      Tag    Flag    Cylinders        Size            Blocks
      0      root    wm      1 - 10439      79.97GB    (10439/0/0) 
167702535
      1 unassigned    wm      0                0        (0/0/0)            
0
      2    backup    wu      0 - 10439      79.97GB    (10440/0/0) 
167718600
      3 unassigned    wm      0                0        (0/0/0)            
0
      4 unassigned    wm      0                0        (0/0/0)            
0
      5 unassigned    wm      0                0        (0/0/0)            
0
      6 unassigned    wm      0                0        (0/0/0)            
0
      7 unassigned    wm      0                0        (0/0/0)            
0

      8      boot    wu      0 -    0        7.84MB    (1/0/0)        16065
      9 unassigned    wm      0                0        (0/0/0)            
0


*this* label does make se

Re: [OpenIndiana-discuss] zpool import not possible after slot change

[Chris]

On 2021-04-23 11:30, Andreas Wacknitz wrote:

Am 23.04.21 um 19:48 schrieb Reginald Beardsley via openindiana-discuss:
"the inner workings of an operating system so complicated that no one 
person actually understands all of it"


Bryan Cantrill in the Foreword to "Solaris Internals" , McDougall and 
Mauro, 2nd ed 2007


This is true of any production level OS whether Windows, Linux, BSD or 
Solaris derived. The FreeBSD kernel is 1.5 million lines of code. I don't 
even want to know what X and the window managers add. No person can 
remember that much even if they had time to read all of it. If they did 
read it all, it would be different by the time they finished. If that 
doesn't constitute "terminal complexity" I can find no other way to 
describe the situation.


Could I figure out what is going on with the USB naming?  Of course, that's 
how I made my living.  But it is time consuming and simply not worth the 
effort.  And might, for valid reasons, not be fixable.


My concern is the perception a new user has when they boot an OI release.  
It should be good.  In fact, it is already better than anything else I've 
tested recently.

I would be happy if we could fix all the issues. But that would need
more volunteers to help fixing bugs and enhancing the current situation.
For projects with lots of developers tests with exotic hardware or
configurations can be valuable.
But OI in fact has problems to keep even simple things up-to-date and it
gets worse every day.
Complaining about things in this situation is not helpful at all without
providing updates or patches that fix things.
We know that many things don't work or aren't perfect. But with a single
digit number of people submitting PR's to oi-userland you cannot expect
more.
I am trying to get more people involved for some time now. I am by far
more relaxed to merge PR's than former maintainers did because I don't
want to alienate the few volunteers who at least try to work on problems
and updates. Talking is easy but we need more actions.

The echo of my last offer to give interested people a helping hand to
get accustomed to our build system was exactly zero.

Let me take this opportunity to extend you a firm virtual hand shake with
a Thank You for that offer. I caught your initial offer, and was more
than pleased to see it. As I am near to accepting that offer. But I'm in
the middle of a build and image rollout for our hardware upgrade. This is
good news for me. As when I'm finished, and all the dust lands. I'll have
a surplus of hardware to re-purpose. It is my intent to use it for some
serious OI development. My background is BSD. So any help you would be
willing to provide to shorten the trajectory, would be GREATLY appreciated.

Thanks again. Be talking to you soon. ;-)

--Chris


For me we have the strange situation that even people who claim to be
maintainers for a software and claim to be OI users don't act even when
I tell them that their software is outdated in OI. This is something
that irritates me to the bone. Especially when the only reaction is
something like "Oh that is surprising. It should be quite easy to update
the package!"



When programs which appear on the Live Image Desktop crash or  icons for 
installation instructions referenced in the GUI install are missing and 
have been missing for multiple releases I think it quite reasonable to be 
concerned and to point out that the *user* community should be more 
involved in testing release candidates.


I have now attempted installs of S11.4, Debian 10.9, 2021.04-rc1, 2020.10, 
2017.10, Oracle Linux 8.3 and S10_u11.  Of these S11.4 and OL 8.3 succeeded 
in booting after the install.  S10_u11 just informed me that "The disc you 
inserted is not a Solaris CD/DVD".  This is after I selected option 4 from 
the Solaris 10 install menu so I could install to a ZFS pool,  had filled 
out all the fields and hit F2 to start the installation.


Is this a BIOS issue?  Or a driver issue?  I have no idea.  I suspect it's 
a bit of both as I do not have any documentation for the BIOS settings and 
this has Intel's ME, TPM and God only knows what else.  After a BIOS 
update, it won't even boot 2021.04-rc1 in single user mode.  It goes into 
maintenance on a login service failure booting from the DVD.  I can't even 
investigate why.


It runs Windows 10 and S11.4.  The latter is far too much like Windows 10 
to suit me.  MATE I can live with.  Unless I get lucky, this is going back 
on Monday and I'll get an older machine which is less likely to have driver 
issues.


Reg


If you have problems with so many OS's you should rethink your
requirements. I would already have changed to a smaller boot disk, eg. a
pair of 250GB or 500GB SSD's. There is enough space in the Z820 to add
them somewhere and if you don't have enough SATA connectors you could
easily add an HBA, eg. a simple LSI SAS HBA.

Andreas

__

Re: [OpenIndiana-discuss] RAIDZ2 root pool install fun :-(

[Chris]

On 2021-04-20 05:57, Bob Friesenhahn wrote:

On Tue, 20 Apr 2021, Reginald Beardsley via openindiana-discuss wrote:


NAME STATE READ WRITE CKSUM
rpool1 ONLINE 0 0 0
raidz2-0 ONLINE 0 0 0
c0t539A7B78030Fd0 ONLINE 0 0 0
c0t539A7B7002F3d0 ONLINE 0 0 0
c0t539A7B700306d0 ONLINE 0 0 0
c0t539A7B700305d0 ONLINE 0 0 0

errors: No known data errors

But I *really* don't like those long winded disk names.


You might learn to appreciate them given that part of the name is very 
likely

printed exactly on the side of your disk drive.  This can be very helpful.

Strictly from memory (mine -- which may well have a couple of incorrectly
flipped bits). A portion of the device name is created from the disks serial
number. So as Bob correctly points out; this makes it extremely simple to
identify the correct drive when not-so happy things occur in your data pool. 
:-)


--Chris


In fact all of the elements in the name appear to be helpful whereas the 
shorter

versions were not very helpful at all.

Bob


--

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

Re: [OpenIndiana-discuss] x86 boot loader

[Chris]

On 2021-04-19 19:01, Reginald Beardsley via openindiana-discuss wrote:
Is it actually written in forth?  I just learned of it today.  I'm a long 
time forth fan.

Me too! :-)

--Chris


Reg

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


--

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

Re: [OpenIndiana-discuss] How is this possible?

[Chris]

On 2021-04-16 11:38, Reginald Beardsley via openindiana-discuss wrote:
I have a pair of almost identical Z400s. (In total I have 4.) One has 4x 2 
GB
DIMMs (#3)  and the other has 2x 8 GB DIMMs (#4) .  Both have Quadro FX 1800 
cards
and trayless SATA bays.  Both are connected to the monitor through an 8 port 
KVM

switch.

Hipster 2020.10 was installed on system #3.  The monitor was recognized and
configured properly as 1600x1200 using the 340.108 driver.   If I move the 
disk to
#4 the nVIDIA driver didn't recognize the monitor or the resolution, set 
1024x768

and would not allow me to set it to 1600x1200.

I  moved the KVM switch port for #4  to #3 and rebooted 2020.10 on #3.  It 
behaves

as expected, recognizes the Samsung Monitor and the correct resolution.

After I installed the 2x 8 GB DIMMs S10 u8 kernel panicked on a null pointer
dereference, so I moved the 2020.10 disk to system #4 and ran it for several 
days
to see if fmd would log ECC errors on the DIMMs.  fmdump -eV reports the log 
file
is empty after 3 days.  I don't know what whether fmd in u8 logs ECC errors 
as
I've never seen any, though I have seen occasional ECC errors on system #2 
which

is running 2017.10

This morning  I put the S10 u8 disks back in the system, booted and started 
scrubs
at which point it immediately kernel panicked.  I rebooted in single user 
mode.
Both the root pool 3 way mirror and the RAIDZ1 export pool scrubs completed 
with

no errors.

The 3 disks forming the 2 pools were in a 6 DIMM slot Z400 (#1).  That MB 
appears

to have a failing SATA controller as it logged so many sector R/W errors it
rebooted.  I replaced the suspect disk with a new drive of the same make, 
model

and vintage.  The errors continued so I switched the  u8 disks to #4.  A
subsequent test of the drive that was reported bad showed no errors after a 
4 hr

scan using the BIOS test.

After verifying that 2020.10 worked properly in #3, I moved the disk back to 
#4.
This time it came up at 960x540!  I changed out the video with the card from 
#1

and again it came up in 960x540. I then moved the video card from #3 to #4.
Again, 960x540.  I reset the BIOS to factory defaults, changed the things 
(e.g

AHCI) I knew had to be changed.  Again.  Same behavior.

If I boot the 2020.10 Live Image on #3 it's 1600x1200.  On #4 it's 1024x768. 
 I

tried the video card in the other PCIe slot.  Same result.

I'm completely baffled.I've never seen anything like this.
Cables? IOW if it is working on one but not others. I'd hazard a guess that 
the

system isn't receiving the EDID from the monitor through the KVM. Some KVMs
can be a problem that way by not providing enough of the power to the 
connections.

Other times (often) (cheap) cables are missing the "sync" wire. In any case,
I'd first start by swapping the cable from the working machine to the port
on the "different" machine and see if that doesn't solve it -- it's the 
fastest
and easiest first step. OTOH If the machine that OI was setup on provides 
video
on a different port than the machine your swapping to. That too may be a 
factor.

In any case; w/o any log output. This is all I feel safe offering. ;-)

HTH

--Chris



Reg

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


--

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

Re: [OpenIndiana-discuss] Howto change NVidia driver version

[Chris]

On 2021-03-24 08:12, Stephan Althaus wrote:

On 03/20/21 08:21 AM, Andreas Wacknitz wrote:

Hi,

maybe it's time to put something on https://docs.openindiana.org
The sources of it are here: https://github.com/OpenIndiana/oi-docs
PR's are welcome and can be written by anybody capable of typing and has
some knowledge of markdown...

Regards,
Andreas


Hi!

Reading what is there at the moment,
i think the nvidia parts should be enhanced by a script that auto-selects 
the

correct driver for the installed hardware.

FreeBSD does it that way. Maybe some good hints might be found in their port.


I gave it a try to do it myself but i am not satisfied by now..

Stephan

--Chris



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


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How do I verify that fmd is actually able to detect and log ECC errors?

[Chris]

On 2021-03-16 12:15, Judah Richardson wrote:

AFAIK a scrub or ECC error shouldn't crash the kernel. Also, if the crash
is occurring on the error the error might not be logged. To me it sounds
like you might have a system board issue.

I felt compelled to chime on his last post, that it looked suspiciously
like it might be the PSU. Over time the diodes on the bridge(s) start
leaking AC. Which will start causing somewhat erratic behavior on OS/
applications. Resistance also increases on the circuits in the PSU.
Resulting in lower than required voltage.
If he is able to. Simply swapping out the PSU with one from one of his
other "working" Z400's would be a simple way to confirm.

Just thought I'd mention it. :-)

--Chris


Also FWIW you shouldn't have to scrub otherwise healthy pools more than
once per month.

On Tue, Mar 16, 2021, 14:08 Reginald Beardsley via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:


I suspect memory errors on my Sol 10 u8 system, but there are no memory
errors reported by "fmdump -eV".  All the errors and events are zfs 
related.


Initial symptom is starting a scrub on a freshly booted system will
complete properly, but the same operation after the system has been up for
a few days will cause a kernel panic. Immediately after a reboot a scrub
will complete normally.  This behavior suggests bit fade to me.

This has been very consistent  for the last few months.  The system is an
HP Z400 which is 10 years old and generally has run 24x7.  It was certified
by Sun for Solaris 10 which is why I bought it and uses unbuffered,
unregistered ECC DDR3 DIMMs.  Since my initial purchase I have bought three
more Z400s.

Recently the system became unstable to the point I have not been able to
complete a "zfs send -R" to a 12 TB WD USB drive.  My last attempt using a
Hipster LiveImage died after ~25 hours.

My Hipster 2017.10 system shows some events which appear to be ECC
related, but I'm not able to interpret them.  I've attached a file with the
last such event.  Not sure that will work, but worth trying.  This is from
my regular internet access host.  So  it is up 24x7 with few exceptions.

Except for the CPU and memory, the machines are almost identical.  The
Hipster machine is an older 4 DIMM slot machine with the same 3 way mirror
on s0 and 3 disk RAIDZ1 on s1.  The Sol 10 system is a 6 DIMM slot model
and has a 3 TB mirrored scratch pool in addition to the s0 & s1 root and
export pools.

It seems unlikely that I could simply swap the disks between the two, but
I can install Hipster on a single drive for rpool and attempt to copy the
scratch pool, spool, with that and simply run it for a while for testing.

I've read everything I can find about the Fault Manager, but it has
produced more questions than answers.

This is for Hipster 2017.10:

sun_x86%rhb {82} fmadm config
MODULE   VERSION STATUS  DESCRIPTION
cpumem-retire1.1 active  CPU/Memory Retire Agent
disk-lights  1.0 active  Disk Lights Agent
disk-transport   1.0 active  Disk Transport Agent
eft  1.16active  eft diagnosis engine
ext-event-transport  0.2 active  External FM event transport
fabric-xlate 1.0 active  Fabric Ereport Translater
fmd-self-diagnosis   1.0 active  Fault Manager Self-Diagnosis
io-retire2.0 active  I/O Retire Agent
sensor-transport 1.1 active  Sensor Transport Agent
ses-log-transport1.0 active  SES Log Transport Agent
software-diagnosis   0.1 active  Software Diagnosis engine
software-response0.1 active  Software Response Agent
sysevent-transport   1.0 active  SysEvent Transport Agent
syslog-msgs  1.1 active  Syslog Messaging Agent
zfs-diagnosis1.0 active  ZFS Diagnosis Engine
zfs-retire   1.0 active  ZFS Retire Agent


It's a little longer than for Sol 10 u8, but the cpumem-retire V 1.1
appears on both.

Suggestions?

Thanks,
Reg


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!

[Chris]

On 2021-03-04 19:01, cretin1997 wrote:

‐‐‐ Original Message ‐‐‐
On Friday, March 5, 2021 12:03 AM, Chris  wrote:


SquashFS is only small when it's compressed on media.



Who on earth use SquashFS without compression? lz4 is the most widely used
algorithm. Compressible is the selling point of it. Who on earth will ever 
think

about uncompressed SquashFS?

Huh? You've trimmed out all the context. Now none of this makes any sense.

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!

[Chris]

On 2021-03-04 09:03, Reginald Beardsley via openindiana-discuss wrote:
My God! I've been pushing the bounds of what I consider acceptable for a 
week! I

feel rather uncomfortable about making so much noise.

In all honesty, I enjoy your rants. They're largely on target. :-)

--Chris


However, from time to time I will resort to metaphorical swat on the head 
with a
big stick when I judge it to be tactically or strategically appropriate. It 
tends
to make people not like me, so I try not to do it too often, but sometimes I 
judge

it appropriate. Others often don't.

What is the alternative to a "rolling release"? I don't want to be running 
beta
software. I have a machine for testing beta software, but I want to have a 
stable

system for doing work.

If the only bootable medium available is the DVD, then getting anything must 
mean
the system is reading the DVD. It may well transition at some point to not 
being
able to read from the DVD, but it is how I got to the booloader. Otherwise 
it

emits a "No bootable device" message.

Reg


 On Thursday, March 4, 2021, 10:48:18 AM CST, cretin1997
 wrote:

 ‐‐‐ Original Message ‐‐‐
On Thursday, March 4, 2021 11:20 PM, Reginald Beardsley via 
openindiana-discuss

 wrote:

I posted a public plea to all the lists to contact me so I could test it. 
Never heard from anyone.




I confirm. You should push your thread a bit so people could see it easier.

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


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!

[Chris]

On 2021-03-04 08:45, cretin1997 via openindiana-discuss wrote:

‐‐‐ Original Message ‐‐‐
On Thursday, March 4, 2021 11:18 PM, Peter Tribble  
wrote:


Both OmniOS and Tribblix don't have this failure mode as they don't have 
the

split boot. We just get the bootloader to slurp the entire OS into memory.
It's
the sort of trick that isn't really practical for the GUI boot, though.



Uhm, SquashFS anyone? We are a desktop system so we should use a desktop
technology. Why don't change for the superior and proved solution? And as I 
saw

they even used SquashFS for cli only Linux without any problems. Or it's NIH
syndrome? Or just hate Linux? Or we must adhere to the tradition of 
OpenSolaris
and not allowed to change anything? Otherwise we will become less Solarish! 
Isn't

it?
It's not so much the space on media that's the problem, as the space in RAM 
that

poses the restrictions. SquashFS is only small when it's compressed on media.

--Chris


BTW, you didn't answered me about how to do full screen with Tribblix on
VirtualBox, Peter. Looking forward to you.



--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!

[Chris]

On 2021-03-03 08:50, Judah Richardson wrote:

On Tue, Mar 2, 2021 at 9:36 PM Chris  wrote:


On 2021-03-02 03:20, cretin1997 via openindiana-discuss wrote:
>
> Another weakness of FreeBSD is the init system of it that has to be
> mitigated by
> tools like daemontools.
No offense, but this is false.
> Some embrace the KISS principle praise it for it
> deterministic and simplicity. But when comparing with Solaris' SMF and
FMA,
> FreeBSD's RC init system is a joke. That's real. FreeBSD's RC init
system
> loses to
> SystemD, too, even though they don't want to admit it.
This is purely opinion (yours). :-)


I've run FreeBSD since 2018. rc.d is great when used with packages that
were developed for it. Otherwise, I've found it problematic.

I know many, many people who flocked from Linux to FreeBSD

I wish those people would show up in the FreeBSD forums or subreddits. The
nice thing about Linux is if you have a problem you can get 20 sets of eyes
on it in a single post. If you have a FreeBSD problem - especially 1
involving interaction with another OS - you might get 2 or 3 replies.

You'll find the mailing lists your best source for quick/multiple responses.
As well as from those Linux defectors.
I find the freebsd-current@, freebsd-stable@ && the freebsd-hackers@ the
best for overall support/information. Of course there's freebsd-ports@
and freebsd-ports-bugs@ if your interest/needs revolve around ports/packages.

HTH

--Chris


when SystemD as

the only option became final. Those whom couldn't bear to leave Linux, went
to Slackware.




--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Does OI compress the zpool by default?

[Chris]

On 2021-03-02 18:54, cretin1997 wrote:

‐‐‐ Original Message ‐‐‐
On Tuesday, March 2, 2021 11:15 PM, Chris  wrote:


On 2021-02-28 07:38, cretin1997 via openindiana-discuss wrote:

The reason is or should be, because of its potential cost. That is;
compression can consume a great deal more CPU cycles. So if the host has
limited resources, either outright or because of work load. Then 
compression

will not be an advantage, and may swamp the system. Further, in several
implementations several of the settings are somewhat dynamic, and can be
"tuned".
Compression being one of them.

Apologies in advance if this question has already been answered. I'm in the
process of getting caught up on my mail. :-)

--Chris

>

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX


Except this easy to easy to change from not compressed to compressed. 
Setting the
attribute alone not work. If you think have to do send/recv everything to 
get it
compressed is a pleasure task, especially you have to do this every time 
after you
installed a new system, I have nothing to say anymore. Why don't it just the 
thing
already set to be compressed from the beginning? It will save much time and 
space

for the user!

BTW, FreeBSD seemed to turn on lz4 compression by default. Nowadays with 
modern
hardware, it's sane to turn it on by default. Your arguments about an old 
system
should be dismissed completely. None of the Illumos is for old and weak 
system.

Illumos is a resource hog.
From a "server" perspective, I *completely* agree. OTOH a "server" OS that 
presents
itself as a live desktop with the option to install, attracts "desktop" 
users. So...
Further; ZFS compression isn't as simple as "throwing a switch"; there's a 
reasonable
amount of "tuning" that compression involved. On one hand, if you've not got 
that much
in your pool(s). _immidiate_ compression if of little value. ZFS send/reveive 
is

another matter, and so on...
Seems to me, the best solution might be setting a "default" level/algo, and 
provide

an option in the installer to enable it.

That's _my_ take on it. :-)

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] ALSA library/LibAsound for OpenIndiana?

[Chris]

On 2021-03-02 18:43, cretin1997 wrote:

‐‐‐ Original Message ‐‐‐
On Wednesday, March 3, 2021 12:34 AM, Chris  wrote:


All rubbish aside. It's not that nobody cares. In fact, if I could set an
hours
time aside. I could get the alsalib packaged for IO. So now that it's
available
and installed. You'll ask; why doesn't my application work? It uses Alsa 
and

I
installed alsalib. But it's still not working -- translation; I have to
familiarize
myself with your favorite applications and set aside an hours time for each
of them
and change/add to them the ability to use alsalib.

IOW it looks easy from the outside-in. But not so, from the inside-out. 
Make

no
mistake; your request has merit. It's just going to take someone, or 
several
people with the necessary time, to make the changes necessary to 
incorporate

Alsa.

HTH

--Chris



No. I'm not that stupid. I only need the library. I already have contact via 
email
with the software developer. Everything since then I will work with them, 
not you.
The only thing they require is all of the dependencies satisfied. They are 
pleased
to patch their software to run on a new platform but not to add new code 
just to

support a specific platform. Hope it helps.

Ahh. Well that's a *completely* different story. :-)
I'll see if I can't make some time to attack this for you.
Unless someone else beats me to it.

Thanks for the clarification!

--Chris

--

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

Re: [OpenIndiana-discuss] Hipster 2020.10 text installer ISO Wow!!!!

[Chris]

On 2021-03-02 03:20, cretin1997 via openindiana-discuss wrote:


Another weakness of FreeBSD is the init system of it that has to be 
mitigated by

tools like daemontools.

No offense, but this is false.

Some embrace the KISS principle praise it for it
deterministic and simplicity. But when comparing with Solaris' SMF and FMA,
FreeBSD's RC init system is a joke. That's real. FreeBSD's RC init system 
loses to

SystemD, too, even though they don't want to admit it.

This is purely opinion (yours). :-)
I know many, many people who flocked from Linux to FreeBSD when SystemD as
the only option became final. Those whom couldn't bear to leave Linux, went
to Slackware.

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Do you ever think about adopting APT+DPKG?

[Chris]

On 2021-03-02 09:56, Judah Richardson wrote:

On Tue, Mar 2, 2021 at 11:43 AM Chris  wrote:


On 2021-03-01 06:33, cretin1997 via openindiana-discuss wrote:
> We have the tech there. Well adapted for our needs. APT+DPKG based
Illumos
> distro
> is not unpopular. Some distros even use RPM.
>
> Most historic APT+DPKG based distros already dead, only DilOS is left
now.
> So we
> could have a look at DilOS, the way they patched and utilizing APT+DPKG
and
> we can
> even co-operate with them, if both side wanted.
>
> We already see too many problems of the IPS pkg. Could we switch to
another
> path?
>
> I know compatibility haunted us. But recently we broke it already. It's
no
> longer
> the holy grail we have to keep at all cost anymore.
>
> Could we patch our oi-userland to generate DEB packages alongside of IPS
> packages?
>
> The DilOS people has figured out how to build illumos-gate into DEB
packages
> already.
>
> This will not as hard as doing from scratch as we have many references.
There are many possible "package managers" available. Some have already
been
recobbled
to support Solaris derivatives. But IMHO the DEB package managers are not
as
efficient


I'd say this is largely an academic argument. I have 3 machines that use
apt + deb with no associated issues. Actually, # apt dist-upgrade on Debian
Buster, Ubuntu 20.10, and Raspberry Pi OS Buster runs MUCH faster than #
pkg update -v -r on OI Hipster with approximately the same underlying
hardware (Intel Core 2nd Gen, 16 GB RAM) for the OI, Debian, and Ubuntu
machines.

as many of the others, it's a real "cache thrasher".

I don't think this is an issue if you have a decent (e.g. Samsung 860 Evo
or better) SSD with good endurance specs.

Agreed. It's also not an issue with more RAM/cores && higher frequencies. ;-)

In the end, I don't really care _which_ package manager is chosen; as long
as there is only _one_ and that it's the simplest to use for the package 
*creators* :-)
Ultimately; that should ensure the most packages for the users, with the 
greatest

package integrity. No? :-)

--Chris


Many of the others are

more DB
centric. Which tends to make them much faster and less resource abusive.



--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Do you ever think about adopting APT+DPKG?

[Chris]

On 2021-03-01 06:33, cretin1997 via openindiana-discuss wrote:
We have the tech there. Well adapted for our needs. APT+DPKG based Illumos 
distro

is not unpopular. Some distros even use RPM.

Most historic APT+DPKG based distros already dead, only DilOS is left now. 
So we
could have a look at DilOS, the way they patched and utilizing APT+DPKG and 
we can

even co-operate with them, if both side wanted.

We already see too many problems of the IPS pkg. Could we switch to another 
path?


I know compatibility haunted us. But recently we broke it already. It's no 
longer

the holy grail we have to keep at all cost anymore.

Could we patch our oi-userland to generate DEB packages alongside of IPS 
packages?


The DilOS people has figured out how to build illumos-gate into DEB packages 
already.


This will not as hard as doing from scratch as we have many references.
There are many possible "package managers" available. Some have already been 
recobbled
to support Solaris derivatives. But IMHO the DEB package managers are not as 
efficient
as many of the others, it's a real "cache thrasher". Many of the others are 
more DB

centric. Which tends to make them much faster and less resource abusive.

--Chris





--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] ALSA library/LibAsound for OpenIndiana?

[Chris]

On 2021-03-01 06:11, cretin1997 via openindiana-discuss wrote:

‐‐‐ Original Message ‐‐‐
On Monday, March 1, 2021 8:58 PM, cretin1997 via openindiana-discuss
 wrote:


‐‐‐ Original Message ‐‐‐
On Thursday, February 25, 2021 9:14 AM, cretin1997 via openindiana-discuss 
openindiana-discuss@openindiana.org wrote:


> ‐‐‐ Original Message ‐‐‐
> On Wednesday, February 24, 2021 6:38 PM, cretin1997 via openindiana-discuss 
openindiana-discuss@openindiana.org wrote:
>
> > Could you consider port this very essential library from Linux to OI? I 
know ALSA is Linuxism. But Linuxism has spread into many applications. Now ALSA 
library is a hard requirement for sound support on Unix-like platforms of some 
applications. They are first developed on Linux and as ALSA library has been ported 
to many other Unix-like OSes as well, they just set ALSA library as a hard 
requirement. Of course a skillful developer could patch the code to use the platform 
specific facility. But I'm not one of them and ALSA library is the last piece to be 
able to build the software on OI. Please help.
> > ALSA library is available on all BSDs. The only Unix-like OS doesn't have 
ALSA library is OpenIndiana/Illumos.
> > Sent with ProtonMail Secure Email.
> > openindiana-discuss mailing list
> > openindiana-discuss@openindiana.org
> > https://openindiana.org/mailman/listinfo/openindiana-discuss
>
> No one interested?
> Currently I could build this with a small hack:
> https://github.com/cnjinhao/nana
> But no sound at all. Because of no ALSA library.
> Please note that ALSA library and ALSA itself is not the same.
> Porting ALSA library doesn't mean you need to pull in the whole Linux sound 
infrastructure.
> Please have a look at it.
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss

No one care about this?

It's just a small library, but it helps many applications.

Do you ever care about the productivity of your users? I think not. Please 
don't tell me port it myself. Because if I can, I already did it.


Or do you want me to ask for the mercy of pkgsrc? No, absolutely no. I saw 
there is a ALSA library port on pkgsrc. But the weakness of pkgsrc is it's 
not integrate with the system. I will ended up building everything as it 
dependencies even though I have no use for them! pkgsrc doesn't use system 
library. It always build it own. It's a huge waste of time and most of the 
time it failed to build one random dependency and render the whole thing 
failed, too.


Using OI as a workstation to do software development is impossible. Your OS 
is too useless. What's the use of it? A graphical server with a web browser 
so you could surf the web while working with your server via a graphical 
interface? This is too primitive to be even called a desktop. But if you 
say so, I will stop to expect anything more from OI.


Best regards.

openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss


Please don't blame everything on Linuxism. Linuxism is a reality we have to 
live
with. I know definitely someone will go and shout to my face about Linuxism, 
we

are a small team, port it yourself we welcome patches, blah blah... Some old
school die hard Unix veterans will come and shout to my face you youngster!, 
Unix

as an IDE!, blah blah... No. I don't care. By IDE I mean a real IDE, not a
discipline. I don't care about your discipline, to be clear.

Even if doing the development enjoying all of the modern tools on Linux and 
only
build the software to deploy on OI, it's still a lot of troubles. Getting 
the
library you use to build and work on OI is already a showstopper. Why do you 
even

dream of more software running on OI? It's unrealistic!

All rubbish aside. It's *not* that nobody cares. In fact, if I could set an 
hours
time aside. I could get the alsalib packaged for IO. So now that it's 
available
and installed. You'll ask; why doesn't my application work? It uses Alsa and 
I
installed alsalib. But it's still not working -- translation; I have to 
familiarize
myself with your favorite applications and set aside an hours time for each 
of them

and change/add to them the ability to use alsalib.

IOW it looks easy from the outside-in. But not so, from the inside-out. Make 
no

mistake; your request has merit. It's just going to take someone, or several
people with the necessary time, to make the changes necessary to incorporate 
Alsa.


HTH

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Does OI compress the zpool by default?

[Chris]

On 2021-02-28 07:38, cretin1997 via openindiana-discuss wrote:
zfs get compression and zfs get compressratio results seemed to tell that 
it's not

on by default. But, why?

The reason is or should be, because of its potential cost. That is;
compression can consume a great deal more CPU cycles. So if the host has
limited resources, either outright or because of work load. Then compression
will not be an advantage, and may swamp the system. Further, in several
implementations several of the settings are somewhat dynamic, and can be 
"tuned".

Compression being one of them.

Apologies in advance if this question has already been answered. I'm in the
process of getting caught up on my mail. :-)

--Chris




--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-02-07 01:48, Toomas Soome wrote:

On 7. Feb 2021, at 09:04, Chris  wrote:

On 2021-02-06 13:36, Chris wrote:

On 2021-02-06 00:56, Toomas Soome wrote:

On 6. Feb 2021, at 01:41, Chris  wrote:
On 2021-02-05 14:16, Chris wrote:

On 2021-02-05 13:46, Toomas Soome wrote:

On 5. Feb 2021, at 19:54, Chris  wrote:
On 2021-01-30 02:28, Toomas Soome wrote:

On 30. Jan 2021, at 10:39, Chris  wrote:
On 2021-01-30 00:03, Toomas Soome wrote:

On 30. Jan 2021, at 09:40, Chris  wrote:
On 2021-01-29 22:24, Toomas Soome via openindiana-discuss wrote:

On 30. Jan 2021, at 03:43, Chris  wrote:
On 2021-01-29 17:18, Andy Fiddaman wrote:

On Fri, 29 Jan 2021, Chris wrote:
; OK just dragged a Dell Optiplex 790 off the shelf
; with a 4 core 8 thread i5 CPU in it, and as much RAM
; as I could jam in it.
; BIOS:
; boot UEFI
; SATA ahci
; I've tried 2 different Nvidia cards, as well as the
; intermal video. The results are the same;
; 2.5 minutes to get to the OI banner/boot options.
; An additiona 3.5 to draw the OI banner/options screen.
; It takes ~0.5 seconds to draw each cell. To be clear;
; I'm not complaining here. Rather, I'm trying to
; pinpoint WTF is going wrong in hopes of overcoming
; the problem. I've attempted to put OI on 3 different
; computers now, and the results have all been
; underwhelming in the console dept.
;
; Any thoughts?
If you can press  really early in the boot process, 
you get the
first loader prompt (I forget exactly how it looks). At that 
point,
enter "-t" without the quotes and press return. That will keep 
in

VGA mode, which might well be faster/usable.

Huge thanks for the reply, Andy!
Yes, it made a difference. Drawing each cell only takes 0.25
seconds. :-P
So somewhat faster, anyway. It's funny. It starts out quite
fast. The speed I normally experience with other stuff. It
writes
Available consoles:
text VGA ...
ttya port 0x3f8
ttyb ... not present
ttyc ... not present
ttyd ... not present
null software device
spin software device
Right at this point is where it drops to about 1/2 or slower 
speed.

Then, cell by cell, it prints
console ttyb failed to initialize
console ttyc failed to initialize
console ttyd failed to initialize
This is the point where you have got hint about why this 
happens. The same defect
is with virtualbox, when you have configured host pipe for 
serial device.
The three lines above tell us that ttya was successfully 
initialized, so it must

have to do about ttya.
OK I neglected to note that this was including the advice by Andy 
to drop to
text mode, by interrupting loader, and entering -t at the prompt 
followed by
enter. It's clear that it was attempting serial mode -- note the 
port 0x3f8

Without interrupting loader, text and ttya return:
text VESA (800x600 - 1600x1200 depending on what I'm hooked up 
to)

ttya ... not present
I'm attempting it again via Legacy where
text VESA 1600x1200
ttya ... not present
Choosing 5 (options), followed by 5 (verbose) has already taken 
20
minutes (it's still in progress). I think I'm just going to try 
to
install it and work on it further from the internal disk. In 
hopes

of getting at least a small speed increase from 0 to actual boot.
I greatly appreciate your insight on this, Toomas.
Ok, so this guess was not good one afterall. If you are doing CD 
(ISO) boot, you
will get loader started as first stage - that is, there is no way 
to enter
options; however, once you get out of menu and on O prompt, you 
can enter:

framebuffer off
on BIOS boot, this will switch to VGA text mode, on UEFI, it will 
switch terminal
draw from GOP Blt() to SimpleTextOutput protocol (gfx can not be 
switched off as

there is no VGA text mode in UEFI, there may not be even VGA).
If you are booting from USB stick, press space on very first 
spinner to get boot:
prompt, from there you can enter: -t as Andy was suggesting, it 
will start loader
in text mode, without switching to VBE framebuffer. Once the OS is 
installed, you
can create /boot/config with -t in it, this will achieve the same 
effect.

That much about workaround.
“normally”, if drawing in FB mode is slow, it will help to use 
lower resolution
and/or depth, but as you wrote, 800x600 was just as bad as 
1920x1200, it means

something else is going on there.
You can set mode as: framebuffer set XxY[xD], where D is for 
depth, defaults to
32, if not present. framebuffer list [depth] will list available 
modes. With BIOS
mode, you can also try something like 640x400 or 640x480, below 
that the terminal

will get too weird even with 6x12 font...
If depth 8 or 15/16 does not make it faster, it still means there 
is something
weird going on, and at this point, I’d suggest to check if there 
is firmware
update from vendor. (tbh, firmware update would be good as first 
check, the hw
vendors are known to produce a lot of bad things, especially if it 
comes to have

bios emulation with uefi csm.).
Sure. Good point. But already updated it. You've given me some 
things to poke

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-02-06 13:36, Chris wrote:

On 2021-02-06 00:56, Toomas Soome wrote:

On 6. Feb 2021, at 01:41, Chris  wrote:

On 2021-02-05 14:16, Chris wrote:

On 2021-02-05 13:46, Toomas Soome wrote:

On 5. Feb 2021, at 19:54, Chris  wrote:
On 2021-01-30 02:28, Toomas Soome wrote:

On 30. Jan 2021, at 10:39, Chris  wrote:
On 2021-01-30 00:03, Toomas Soome wrote:

On 30. Jan 2021, at 09:40, Chris  wrote:
On 2021-01-29 22:24, Toomas Soome via openindiana-discuss wrote:

On 30. Jan 2021, at 03:43, Chris  wrote:
On 2021-01-29 17:18, Andy Fiddaman wrote:

On Fri, 29 Jan 2021, Chris wrote:
; OK just dragged a Dell Optiplex 790 off the shelf
; with a 4 core 8 thread i5 CPU in it, and as much RAM
; as I could jam in it.
; BIOS:
; boot UEFI
; SATA ahci
; I've tried 2 different Nvidia cards, as well as the
; intermal video. The results are the same;
; 2.5 minutes to get to the OI banner/boot options.
; An additiona 3.5 to draw the OI banner/options screen.
; It takes ~0.5 seconds to draw each cell. To be clear;
; I'm not complaining here. Rather, I'm trying to
; pinpoint WTF is going wrong in hopes of overcoming
; the problem. I've attempted to put OI on 3 different
; computers now, and the results have all been
; underwhelming in the console dept.
;
; Any thoughts?
If you can press  really early in the boot process, you 
get the
first loader prompt (I forget exactly how it looks). At that 
point,
enter "-t" without the quotes and press return. That will keep 
in

VGA mode, which might well be faster/usable.

Huge thanks for the reply, Andy!
Yes, it made a difference. Drawing each cell only takes 0.25
seconds. :-P
So somewhat faster, anyway. It's funny. It starts out quite
fast. The speed I normally experience with other stuff. It
writes
Available consoles:
text VGA ...
ttya port 0x3f8
ttyb ... not present
ttyc ... not present
ttyd ... not present
null software device
spin software device
Right at this point is where it drops to about 1/2 or slower 
speed.

Then, cell by cell, it prints
console ttyb failed to initialize
console ttyc failed to initialize
console ttyd failed to initialize
This is the point where you have got hint about why this happens. 
The same defect
is with virtualbox, when you have configured host pipe for serial 
device.
The three lines above tell us that ttya was successfully 
initialized, so it must

have to do about ttya.
OK I neglected to note that this was including the advice by Andy 
to drop to
text mode, by interrupting loader, and entering -t at the prompt 
followed by
enter. It's clear that it was attempting serial mode -- note the 
port 0x3f8

Without interrupting loader, text and ttya return:
text VESA (800x600 - 1600x1200 depending on what I'm hooked up to)
ttya ... not present
I'm attempting it again via Legacy where
text VESA 1600x1200
ttya ... not present
Choosing 5 (options), followed by 5 (verbose) has already taken 20
minutes (it's still in progress). I think I'm just going to try to
install it and work on it further from the internal disk. In hopes
of getting at least a small speed increase from 0 to actual boot.
I greatly appreciate your insight on this, Toomas.
Ok, so this guess was not good one afterall. If you are doing CD 
(ISO) boot, you
will get loader started as first stage - that is, there is no way to 
enter
options; however, once you get out of menu and on O prompt, you can 
enter:

framebuffer off
on BIOS boot, this will switch to VGA text mode, on UEFI, it will 
switch terminal
draw from GOP Blt() to SimpleTextOutput protocol (gfx can not be 
switched off as

there is no VGA text mode in UEFI, there may not be even VGA).
If you are booting from USB stick, press space on very first spinner 
to get boot:
prompt, from there you can enter: -t as Andy was suggesting, it will 
start loader
in text mode, without switching to VBE framebuffer. Once the OS is 
installed, you
can create /boot/config with -t in it, this will achieve the same 
effect.

That much about workaround.
“normally”, if drawing in FB mode is slow, it will help to use lower 
resolution
and/or depth, but as you wrote, 800x600 was just as bad as 
1920x1200, it means

something else is going on there.
You can set mode as: framebuffer set XxY[xD], where D is for depth, 
defaults to
32, if not present. framebuffer list [depth] will list available 
modes. With BIOS
mode, you can also try something like 640x400 or 640x480, below that 
the terminal

will get too weird even with 6x12 font...
If depth 8 or 15/16 does not make it faster, it still means there is 
something
weird going on, and at this point, I’d suggest to check if there is 
firmware
update from vendor. (tbh, firmware update would be good as first 
check, the hw
vendors are known to produce a lot of bad things, especially if it 
comes to have

bios emulation with uefi csm.).
Sure. Good point. But already updated it. You've given me some things 
to poke at.

I'll give them a try, and see if anything interesting develops.
Thank you very much 

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-02-06 00:56, Toomas Soome wrote:

On 6. Feb 2021, at 01:41, Chris  wrote:

On 2021-02-05 14:16, Chris wrote:

On 2021-02-05 13:46, Toomas Soome wrote:

On 5. Feb 2021, at 19:54, Chris  wrote:
On 2021-01-30 02:28, Toomas Soome wrote:

On 30. Jan 2021, at 10:39, Chris  wrote:
On 2021-01-30 00:03, Toomas Soome wrote:

On 30. Jan 2021, at 09:40, Chris  wrote:
On 2021-01-29 22:24, Toomas Soome via openindiana-discuss wrote:

On 30. Jan 2021, at 03:43, Chris  wrote:
On 2021-01-29 17:18, Andy Fiddaman wrote:

On Fri, 29 Jan 2021, Chris wrote:
; OK just dragged a Dell Optiplex 790 off the shelf
; with a 4 core 8 thread i5 CPU in it, and as much RAM
; as I could jam in it.
; BIOS:
; boot UEFI
; SATA ahci
; I've tried 2 different Nvidia cards, as well as the
; intermal video. The results are the same;
; 2.5 minutes to get to the OI banner/boot options.
; An additiona 3.5 to draw the OI banner/options screen.
; It takes ~0.5 seconds to draw each cell. To be clear;
; I'm not complaining here. Rather, I'm trying to
; pinpoint WTF is going wrong in hopes of overcoming
; the problem. I've attempted to put OI on 3 different
; computers now, and the results have all been
; underwhelming in the console dept.
;
; Any thoughts?
If you can press  really early in the boot process, you 
get the
first loader prompt (I forget exactly how it looks). At that 
point,

enter "-t" without the quotes and press return. That will keep in
VGA mode, which might well be faster/usable.

Huge thanks for the reply, Andy!
Yes, it made a difference. Drawing each cell only takes 0.25
seconds. :-P
So somewhat faster, anyway. It's funny. It starts out quite
fast. The speed I normally experience with other stuff. It
writes
Available consoles:
text VGA ...
ttya port 0x3f8
ttyb ... not present
ttyc ... not present
ttyd ... not present
null software device
spin software device
Right at this point is where it drops to about 1/2 or slower 
speed.

Then, cell by cell, it prints
console ttyb failed to initialize
console ttyc failed to initialize
console ttyd failed to initialize
This is the point where you have got hint about why this happens. 
The same defect
is with virtualbox, when you have configured host pipe for serial 
device.
The three lines above tell us that ttya was successfully 
initialized, so it must

have to do about ttya.
OK I neglected to note that this was including the advice by Andy to 
drop to
text mode, by interrupting loader, and entering -t at the prompt 
followed by
enter. It's clear that it was attempting serial mode -- note the 
port 0x3f8

Without interrupting loader, text and ttya return:
text VESA (800x600 - 1600x1200 depending on what I'm hooked up to)
ttya ... not present
I'm attempting it again via Legacy where
text VESA 1600x1200
ttya ... not present
Choosing 5 (options), followed by 5 (verbose) has already taken 20
minutes (it's still in progress). I think I'm just going to try to
install it and work on it further from the internal disk. In hopes
of getting at least a small speed increase from 0 to actual boot.
I greatly appreciate your insight on this, Toomas.
Ok, so this guess was not good one afterall. If you are doing CD 
(ISO) boot, you
will get loader started as first stage - that is, there is no way to 
enter
options; however, once you get out of menu and on O prompt, you can 
enter:

framebuffer off
on BIOS boot, this will switch to VGA text mode, on UEFI, it will 
switch terminal
draw from GOP Blt() to SimpleTextOutput protocol (gfx can not be 
switched off as

there is no VGA text mode in UEFI, there may not be even VGA).
If you are booting from USB stick, press space on very first spinner 
to get boot:
prompt, from there you can enter: -t as Andy was suggesting, it will 
start loader
in text mode, without switching to VBE framebuffer. Once the OS is 
installed, you
can create /boot/config with -t in it, this will achieve the same 
effect.

That much about workaround.
“normally”, if drawing in FB mode is slow, it will help to use lower 
resolution
and/or depth, but as you wrote, 800x600 was just as bad as 1920x1200, 
it means

something else is going on there.
You can set mode as: framebuffer set XxY[xD], where D is for depth, 
defaults to
32, if not present. framebuffer list [depth] will list available 
modes. With BIOS
mode, you can also try something like 640x400 or 640x480, below that 
the terminal

will get too weird even with 6x12 font...
If depth 8 or 15/16 does not make it faster, it still means there is 
something
weird going on, and at this point, I’d suggest to check if there is 
firmware
update from vendor. (tbh, firmware update would be good as first 
check, the hw
vendors are known to produce a lot of bad things, especially if it 
comes to have

bios emulation with uefi csm.).
Sure. Good point. But already updated it. You've given me some things 
to poke at.

I'll give them a try, and see if anything interesting develops.
Thank you very much for taking the time, Toomas. Greatly a

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-02-05 15:44, Joshua M. Clulow via openindiana-discuss wrote:

On Fri, 5 Feb 2021 at 15:40, Chris  wrote:

> Thanks for taking the time to reply, Toomas! :-)
OK we have a winner! Thanks to some advice from Toomas:
adding: console=text to /boot/conf.d/console
which I later moved to /boot/loader.conf.local (console="text")
followed by commenting the console= line from /boot/default/loader.conf
I now have speed to boot menu that is close to the
OI-hipster-text-20191106.usb install I mentioned earlier in this thread.
While the screen still isn't as fast as the other some half dozen OSs
I use. It's not so slow I can't work with it. :-)
So a HUGE thanks go out to everyone here on the list, that chimed in
to help out -- THANK YOU! :-)


Does that mean loader is, on at least this machine, struggling with
writes to a serial port which isn't there, perhaps?  (More concretely:
why does that help?)

Yes. It's polling for all possible cons. It does so for the sake of
remote ACCESS/INSTALLS as well as local (video). There's also a
"headless" option.


Cheers.

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-02-05 14:16, Chris wrote:

On 2021-02-05 13:46, Toomas Soome wrote:

On 5. Feb 2021, at 19:54, Chris  wrote:

On 2021-01-30 02:28, Toomas Soome wrote:

On 30. Jan 2021, at 10:39, Chris  wrote:
On 2021-01-30 00:03, Toomas Soome wrote:

On 30. Jan 2021, at 09:40, Chris  wrote:
On 2021-01-29 22:24, Toomas Soome via openindiana-discuss wrote:

On 30. Jan 2021, at 03:43, Chris  wrote:
On 2021-01-29 17:18, Andy Fiddaman wrote:

On Fri, 29 Jan 2021, Chris wrote:
; OK just dragged a Dell Optiplex 790 off the shelf
; with a 4 core 8 thread i5 CPU in it, and as much RAM
; as I could jam in it.
; BIOS:
; boot UEFI
; SATA ahci
; I've tried 2 different Nvidia cards, as well as the
; intermal video. The results are the same;
; 2.5 minutes to get to the OI banner/boot options.
; An additiona 3.5 to draw the OI banner/options screen.
; It takes ~0.5 seconds to draw each cell. To be clear;
; I'm not complaining here. Rather, I'm trying to
; pinpoint WTF is going wrong in hopes of overcoming
; the problem. I've attempted to put OI on 3 different
; computers now, and the results have all been
; underwhelming in the console dept.
;
; Any thoughts?
If you can press  really early in the boot process, you get 
the

first loader prompt (I forget exactly how it looks). At that point,
enter "-t" without the quotes and press return. That will keep in
VGA mode, which might well be faster/usable.

Huge thanks for the reply, Andy!
Yes, it made a difference. Drawing each cell only takes 0.25
seconds. :-P
So somewhat faster, anyway. It's funny. It starts out quite
fast. The speed I normally experience with other stuff. It
writes
Available consoles:
text VGA ...
ttya port 0x3f8
ttyb ... not present
ttyc ... not present
ttyd ... not present
null software device
spin software device
Right at this point is where it drops to about 1/2 or slower speed.
Then, cell by cell, it prints
console ttyb failed to initialize
console ttyc failed to initialize
console ttyd failed to initialize
This is the point where you have got hint about why this happens. The 
same defect
is with virtualbox, when you have configured host pipe for serial 
device.
The three lines above tell us that ttya was successfully initialized, 
so it must

have to do about ttya.
OK I neglected to note that this was including the advice by Andy to 
drop to
text mode, by interrupting loader, and entering -t at the prompt 
followed by
enter. It's clear that it was attempting serial mode -- note the port 
0x3f8

Without interrupting loader, text and ttya return:
text VESA (800x600 - 1600x1200 depending on what I'm hooked up to)
ttya ... not present
I'm attempting it again via Legacy where
text VESA 1600x1200
ttya ... not present
Choosing 5 (options), followed by 5 (verbose) has already taken 20
minutes (it's still in progress). I think I'm just going to try to
install it and work on it further from the internal disk. In hopes
of getting at least a small speed increase from 0 to actual boot.
I greatly appreciate your insight on this, Toomas.
Ok, so this guess was not good one afterall. If you are doing CD (ISO) 
boot, you
will get loader started as first stage - that is, there is no way to 
enter
options; however, once you get out of menu and on O prompt, you can 
enter:

framebuffer off
on BIOS boot, this will switch to VGA text mode, on UEFI, it will 
switch terminal
draw from GOP Blt() to SimpleTextOutput protocol (gfx can not be 
switched off as

there is no VGA text mode in UEFI, there may not be even VGA).
If you are booting from USB stick, press space on very first spinner to 
get boot:
prompt, from there you can enter: -t as Andy was suggesting, it will 
start loader
in text mode, without switching to VBE framebuffer. Once the OS is 
installed, you
can create /boot/config with -t in it, this will achieve the same 
effect.

That much about workaround.
“normally”, if drawing in FB mode is slow, it will help to use lower 
resolution
and/or depth, but as you wrote, 800x600 was just as bad as 1920x1200, 
it means

something else is going on there.
You can set mode as: framebuffer set XxY[xD], where D is for depth, 
defaults to
32, if not present. framebuffer list [depth] will list available modes. 
With BIOS
mode, you can also try something like 640x400 or 640x480, below that 
the terminal

will get too weird even with 6x12 font...
If depth 8 or 15/16 does not make it faster, it still means there is 
something
weird going on, and at this point, I’d suggest to check if there is 
firmware
update from vendor. (tbh, firmware update would be good as first check, 
the hw
vendors are known to produce a lot of bad things, especially if it 
comes to have

bios emulation with uefi csm.).
Sure. Good point. But already updated it. You've given me some things to 
poke at.

I'll give them a try, and see if anything interesting develops.
Thank you very much for taking the time, Toomas. Greatly appreciated!

Well, I wrote that stuff;)

You seemed like a nice person. It's a p

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-02-05 13:46, Toomas Soome wrote:

On 5. Feb 2021, at 19:54, Chris  wrote:

On 2021-01-30 02:28, Toomas Soome wrote:

On 30. Jan 2021, at 10:39, Chris  wrote:
On 2021-01-30 00:03, Toomas Soome wrote:

On 30. Jan 2021, at 09:40, Chris  wrote:
On 2021-01-29 22:24, Toomas Soome via openindiana-discuss wrote:

On 30. Jan 2021, at 03:43, Chris  wrote:
On 2021-01-29 17:18, Andy Fiddaman wrote:

On Fri, 29 Jan 2021, Chris wrote:
; OK just dragged a Dell Optiplex 790 off the shelf
; with a 4 core 8 thread i5 CPU in it, and as much RAM
; as I could jam in it.
; BIOS:
; boot UEFI
; SATA ahci
; I've tried 2 different Nvidia cards, as well as the
; intermal video. The results are the same;
; 2.5 minutes to get to the OI banner/boot options.
; An additiona 3.5 to draw the OI banner/options screen.
; It takes ~0.5 seconds to draw each cell. To be clear;
; I'm not complaining here. Rather, I'm trying to
; pinpoint WTF is going wrong in hopes of overcoming
; the problem. I've attempted to put OI on 3 different
; computers now, and the results have all been
; underwhelming in the console dept.
;
; Any thoughts?
If you can press  really early in the boot process, you get 
the

first loader prompt (I forget exactly how it looks). At that point,
enter "-t" without the quotes and press return. That will keep in
VGA mode, which might well be faster/usable.

Huge thanks for the reply, Andy!
Yes, it made a difference. Drawing each cell only takes 0.25
seconds. :-P
So somewhat faster, anyway. It's funny. It starts out quite
fast. The speed I normally experience with other stuff. It
writes
Available consoles:
text VGA ...
ttya port 0x3f8
ttyb ... not present
ttyc ... not present
ttyd ... not present
null software device
spin software device
Right at this point is where it drops to about 1/2 or slower speed.
Then, cell by cell, it prints
console ttyb failed to initialize
console ttyc failed to initialize
console ttyd failed to initialize
This is the point where you have got hint about why this happens. The 
same defect
is with virtualbox, when you have configured host pipe for serial 
device.
The three lines above tell us that ttya was successfully initialized, 
so it must

have to do about ttya.
OK I neglected to note that this was including the advice by Andy to 
drop to
text mode, by interrupting loader, and entering -t at the prompt 
followed by
enter. It's clear that it was attempting serial mode -- note the port 
0x3f8

Without interrupting loader, text and ttya return:
text VESA (800x600 - 1600x1200 depending on what I'm hooked up to)
ttya ... not present
I'm attempting it again via Legacy where
text VESA 1600x1200
ttya ... not present
Choosing 5 (options), followed by 5 (verbose) has already taken 20
minutes (it's still in progress). I think I'm just going to try to
install it and work on it further from the internal disk. In hopes
of getting at least a small speed increase from 0 to actual boot.
I greatly appreciate your insight on this, Toomas.
Ok, so this guess was not good one afterall. If you are doing CD (ISO) 
boot, you
will get loader started as first stage - that is, there is no way to 
enter
options; however, once you get out of menu and on O prompt, you can 
enter:

framebuffer off
on BIOS boot, this will switch to VGA text mode, on UEFI, it will switch 
terminal
draw from GOP Blt() to SimpleTextOutput protocol (gfx can not be 
switched off as

there is no VGA text mode in UEFI, there may not be even VGA).
If you are booting from USB stick, press space on very first spinner to 
get boot:
prompt, from there you can enter: -t as Andy was suggesting, it will 
start loader
in text mode, without switching to VBE framebuffer. Once the OS is 
installed, you
can create /boot/config with -t in it, this will achieve the same 
effect.

That much about workaround.
“normally”, if drawing in FB mode is slow, it will help to use lower 
resolution
and/or depth, but as you wrote, 800x600 was just as bad as 1920x1200, it 
means

something else is going on there.
You can set mode as: framebuffer set XxY[xD], where D is for depth, 
defaults to
32, if not present. framebuffer list [depth] will list available modes. 
With BIOS
mode, you can also try something like 640x400 or 640x480, below that the 
terminal

will get too weird even with 6x12 font...
If depth 8 or 15/16 does not make it faster, it still means there is 
something
weird going on, and at this point, I’d suggest to check if there is 
firmware
update from vendor. (tbh, firmware update would be good as first check, 
the hw
vendors are known to produce a lot of bad things, especially if it comes 
to have

bios emulation with uefi csm.).
Sure. Good point. But already updated it. You've given me some things to 
poke at.

I'll give them a try, and see if anything interesting develops.
Thank you very much for taking the time, Toomas. Greatly appreciated!

Well, I wrote that stuff;)

You seemed like a nice person. It's a pity I have to hate you now

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-01-30 02:28, Toomas Soome wrote:

On 30. Jan 2021, at 10:39, Chris  wrote:

On 2021-01-30 00:03, Toomas Soome wrote:

On 30. Jan 2021, at 09:40, Chris  wrote:
On 2021-01-29 22:24, Toomas Soome via openindiana-discuss wrote:

On 30. Jan 2021, at 03:43, Chris  wrote:
On 2021-01-29 17:18, Andy Fiddaman wrote:

On Fri, 29 Jan 2021, Chris wrote:
; OK just dragged a Dell Optiplex 790 off the shelf
; with a 4 core 8 thread i5 CPU in it, and as much RAM
; as I could jam in it.
; BIOS:
; boot UEFI
; SATA ahci
; I've tried 2 different Nvidia cards, as well as the
; intermal video. The results are the same;
; 2.5 minutes to get to the OI banner/boot options.
; An additiona 3.5 to draw the OI banner/options screen.
; It takes ~0.5 seconds to draw each cell. To be clear;
; I'm not complaining here. Rather, I'm trying to
; pinpoint WTF is going wrong in hopes of overcoming
; the problem. I've attempted to put OI on 3 different
; computers now, and the results have all been
; underwhelming in the console dept.
;
; Any thoughts?
If you can press  really early in the boot process, you get 
the

first loader prompt (I forget exactly how it looks). At that point,
enter "-t" without the quotes and press return. That will keep in
VGA mode, which might well be faster/usable.

Huge thanks for the reply, Andy!
Yes, it made a difference. Drawing each cell only takes 0.25
seconds. :-P
So somewhat faster, anyway. It's funny. It starts out quite
fast. The speed I normally experience with other stuff. It
writes
Available consoles:
text VGA ...
ttya port 0x3f8
ttyb ... not present
ttyc ... not present
ttyd ... not present
null software device
spin software device
Right at this point is where it drops to about 1/2 or slower speed.
Then, cell by cell, it prints
console ttyb failed to initialize
console ttyc failed to initialize
console ttyd failed to initialize
This is the point where you have got hint about why this happens. The 
same defect
is with virtualbox, when you have configured host pipe for serial 
device.
The three lines above tell us that ttya was successfully initialized, so 
it must

have to do about ttya.
OK I neglected to note that this was including the advice by Andy to drop 
to
text mode, by interrupting loader, and entering -t at the prompt followed 
by
enter. It's clear that it was attempting serial mode -- note the port 
0x3f8

Without interrupting loader, text and ttya return:
text VESA (800x600 - 1600x1200 depending on what I'm hooked up to)
ttya ... not present
I'm attempting it again via Legacy where
text VESA 1600x1200
ttya ... not present
Choosing 5 (options), followed by 5 (verbose) has already taken 20
minutes (it's still in progress). I think I'm just going to try to
install it and work on it further from the internal disk. In hopes
of getting at least a small speed increase from 0 to actual boot.
I greatly appreciate your insight on this, Toomas.
Ok, so this guess was not good one afterall. If you are doing CD (ISO) 
boot, you

will get loader started as first stage - that is, there is no way to enter
options; however, once you get out of menu and on O prompt, you can enter:
framebuffer off
on BIOS boot, this will switch to VGA text mode, on UEFI, it will switch 
terminal
draw from GOP Blt() to SimpleTextOutput protocol (gfx can not be switched 
off as

there is no VGA text mode in UEFI, there may not be even VGA).
If you are booting from USB stick, press space on very first spinner to 
get boot:
prompt, from there you can enter: -t as Andy was suggesting, it will start 
loader
in text mode, without switching to VBE framebuffer. Once the OS is 
installed, you

can create /boot/config with -t in it, this will achieve the same effect.
That much about workaround.
“normally”, if drawing in FB mode is slow, it will help to use lower 
resolution
and/or depth, but as you wrote, 800x600 was just as bad as 1920x1200, it 
means

something else is going on there.
You can set mode as: framebuffer set XxY[xD], where D is for depth, 
defaults to
32, if not present. framebuffer list [depth] will list available modes. 
With BIOS
mode, you can also try something like 640x400 or 640x480, below that the 
terminal

will get too weird even with 6x12 font...
If depth 8 or 15/16 does not make it faster, it still means there is 
something
weird going on, and at this point, I’d suggest to check if there is 
firmware
update from vendor. (tbh, firmware update would be good as first check, 
the hw
vendors are known to produce a lot of bad things, especially if it comes 
to have

bios emulation with uefi csm.).
Sure. Good point. But already updated it. You've given me some things to 
poke at.

I'll give them a try, and see if anything interesting develops.
Thank you very much for taking the time, Toomas. Greatly appreciated!


Well, I wrote that stuff;)

You seemed like a nice person. It's a pity I have to hate you now for
doing that. ;-)

Seriously tho. After some 5 days now poking at this, and only getting

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-02-01 05:38, Tony Brian Albers wrote:

On 01/30/21 02:02 AM, Chris wrote:

OK just dragged a Dell Optiplex 790 off the shelf
with a 4 core 8 thread i5 CPU in it, and as much RAM
as I could jam in it.
BIOS:
boot UEFI
SATA ahci
I've tried 2 different Nvidia cards, as well as the
intermal video. The results are the same;
2.5 minutes to get to the OI banner/boot options.
An additiona 3.5 to draw the OI banner/options screen.
It takes ~0.5 seconds to draw each cell. To be clear;
I'm not complaining here. Rather, I'm trying to
pinpoint WTF is going wrong in hopes of overcoming
the problem. I've attempted to put OI on 3 different
computers now, and the results have all been
underwhelming in the console dept.

Any thoughts?

Thank you for all your time, and consideration.

--Chris



Maybe a stupid question, but are you booting from a USB-stick or a DVD?

Not a stupid question. :-)
I tried both. I also installed to SATA based platters.


I've tried on two machines recently, one is an i7/32GB RAM with a NVIDIA
K2200 card and the other an i3/8GB RAM just got the Intel card on the CPU.

Both booted to the banner/boot screen within maybe 10secs and the
options screen shows up maybe 30 secs after exiting the boot options screen.

Both machines booted from a cheap 8GB USB stick.

I used legacy boot, not UEFI.

I tried both UEFI && BIOS, 2 different Nvidia cards, and 2 different Intel
chipsets. As well as 2 AMDs with the 2 Nvidia cards. Results in all cases
were disappointing.


Both have SSD's as internal disks. One also has a SATA 3,5" 7200rpm
drive, but that doesn't seem to make a difference.

No difference for me either.

Thanks for taking the time to reply, Tony. :-)


/tony

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Does OI have a mouse daemon?

[Chris]

On 2021-02-04 18:14, Tim Mooney via openindiana-discuss wrote:

In regard to: [OpenIndiana-discuss] Does OI have a mouse daemon?, Chris...:


OK I've managed to get a reasonably speedy console
(long story for another thread).


For those of us that were watching that thread, I hope you do post your
results.  That's not something that should just go unresolved.

Absolutely. I will. :-)

--Chris


Tim


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

[OpenIndiana-discuss] Does OI have a mouse daemon?

[Chris]

OK I've managed to get a reasonably speedy console
(long story for another thread).
So now at the console (video, not serial/remote).
I see there's a mouse dev. But I can't seem to find any
indication of a moused.

Does one exist?

Thanks!

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] catching hell getting booted

[Chris]

On 2021-02-03 16:41, John D Groenveld wrote:
In message , 
Bob

 Friesenhahn writes:

Yes, dd works the same using Linux.  Just make sure to select the
correct device to write to or your system may be destroyed.


The handbook offers good advice for identifying the correct
device name:
http://docs.openindiana.org/handbook/getting-started/#creating-a-hipster-usb-drive>

FWIW (as it's not mentioned in the above link)
If you have FreeBSD installed. I have always use the following:
# my USB stick is located as /dev/da1
# OI image is OI-hipster-gui-20201031.usb in current dir (PWD)

% dd if=OI-hipster-gui-20201031.usb of=/dev/da1 bs=1m conv=sync

--Chris



John
groenv...@acm.org



--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-01-30 00:03, Toomas Soome wrote:

On 30. Jan 2021, at 09:40, Chris  wrote:

On 2021-01-29 22:24, Toomas Soome via openindiana-discuss wrote:

On 30. Jan 2021, at 03:43, Chris  wrote:
On 2021-01-29 17:18, Andy Fiddaman wrote:

On Fri, 29 Jan 2021, Chris wrote:
; OK just dragged a Dell Optiplex 790 off the shelf
; with a 4 core 8 thread i5 CPU in it, and as much RAM
; as I could jam in it.
; BIOS:
; boot UEFI
; SATA ahci
; I've tried 2 different Nvidia cards, as well as the
; intermal video. The results are the same;
; 2.5 minutes to get to the OI banner/boot options.
; An additiona 3.5 to draw the OI banner/options screen.
; It takes ~0.5 seconds to draw each cell. To be clear;
; I'm not complaining here. Rather, I'm trying to
; pinpoint WTF is going wrong in hopes of overcoming
; the problem. I've attempted to put OI on 3 different
; computers now, and the results have all been
; underwhelming in the console dept.
;
; Any thoughts?
If you can press  really early in the boot process, you get the
first loader prompt (I forget exactly how it looks). At that point,
enter "-t" without the quotes and press return. That will keep in
VGA mode, which might well be faster/usable.

Huge thanks for the reply, Andy!
Yes, it made a difference. Drawing each cell only takes 0.25
seconds. :-P
So somewhat faster, anyway. It's funny. It starts out quite
fast. The speed I normally experience with other stuff. It
writes
Available consoles:
text VGA ...
ttya port 0x3f8
ttyb ... not present
ttyc ... not present
ttyd ... not present
null software device
spin software device
Right at this point is where it drops to about 1/2 or slower speed.
Then, cell by cell, it prints
console ttyb failed to initialize
console ttyc failed to initialize
console ttyd failed to initialize
This is the point where you have got hint about why this happens. The same 
defect

is with virtualbox, when you have configured host pipe for serial device.
The three lines above tell us that ttya was successfully initialized, so 
it must

have to do about ttya.
OK I neglected to note that this was including the advice by Andy to drop 
to
text mode, by interrupting loader, and entering -t at the prompt followed 
by

enter. It's clear that it was attempting serial mode -- note the port 0x3f8
Without interrupting loader, text and ttya return:
 text VESA (800x600 - 1600x1200 depending on what I'm hooked up to)
 ttya ... not present

I'm attempting it again via Legacy where
text VESA 1600x1200
ttya ... not present
Choosing 5 (options), followed by 5 (verbose) has already taken 20
minutes (it's still in progress). I think I'm just going to try to
install it and work on it further from the internal disk. In hopes
of getting at least a small speed increase from 0 to actual boot.

I greatly appreciate your insight on this, Toomas.



Ok, so this guess was not good one afterall. If you are doing CD (ISO) boot, 
you

will get loader started as first stage - that is, there is no way to enter
options; however, once you get out of menu and on O prompt, you can enter:

framebuffer off

on BIOS boot, this will switch to VGA text mode, on UEFI, it will switch 
terminal
draw from GOP Blt() to SimpleTextOutput protocol (gfx can not be switched 
off as

there is no VGA text mode in UEFI, there may not be even VGA).

If you are booting from USB stick, press space on very first spinner to get 
boot:
prompt, from there you can enter: -t as Andy was suggesting, it will start 
loader
in text mode, without switching to VBE framebuffer. Once the OS is 
installed, you

can create /boot/config with -t in it, this will achieve the same effect.

That much about workaround.

“normally”, if drawing in FB mode is slow, it will help to use lower 
resolution
and/or depth, but as you wrote, 800x600 was just as bad as 1920x1200, it 
means

something else is going on there.

You can set mode as: framebuffer set XxY[xD], where D is for depth, defaults 
to
32, if not present. framebuffer list [depth] will list available modes. With 
BIOS
mode, you can also try something like 640x400 or 640x480, below that the 
terminal

will get too weird even with 6x12 font...

If depth 8 or 15/16 does not make it faster, it still means there is 
something

weird going on, and at this point, I’d suggest to check if there is firmware
update from vendor. (tbh, firmware update would be good as first check, the 
hw
vendors are known to produce a lot of bad things, especially if it comes to 
have

bios emulation with uefi csm.).
Sure. Good point. But already updated it. You've given me some things to poke 
at.

I'll give them a try, and see if anything interesting develops.
Thank you very much for taking the time, Toomas. Greatly appreciated!


rgds,
toomas


--Chris



If you comment out (I am assuming you have installed OS) the line:
console="text, ttya, ttyb, ttyc, ttyd”
from /boot/defaults/loader.conf, you will probably find the console is 
much better.

rgds,
toomas

--Chris

Then clears the

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-01-29 22:24, Toomas Soome via openindiana-discuss wrote:

On 30. Jan 2021, at 03:43, Chris  wrote:

On 2021-01-29 17:18, Andy Fiddaman wrote:

On Fri, 29 Jan 2021, Chris wrote:
; OK just dragged a Dell Optiplex 790 off the shelf
; with a 4 core 8 thread i5 CPU in it, and as much RAM
; as I could jam in it.
; BIOS:
; boot UEFI
; SATA ahci
; I've tried 2 different Nvidia cards, as well as the
; intermal video. The results are the same;
; 2.5 minutes to get to the OI banner/boot options.
; An additiona 3.5 to draw the OI banner/options screen.
; It takes ~0.5 seconds to draw each cell. To be clear;
; I'm not complaining here. Rather, I'm trying to
; pinpoint WTF is going wrong in hopes of overcoming
; the problem. I've attempted to put OI on 3 different
; computers now, and the results have all been
; underwhelming in the console dept.
;
; Any thoughts?
If you can press  really early in the boot process, you get the
first loader prompt (I forget exactly how it looks). At that point,
enter "-t" without the quotes and press return. That will keep in
VGA mode, which might well be faster/usable.

Huge thanks for the reply, Andy!
Yes, it made a difference. Drawing each cell only takes 0.25
seconds. :-P
So somewhat faster, anyway. It's funny. It starts out quite
fast. The speed I normally experience with other stuff. It
writes
Available consoles:
 text VGA ...
 ttya port 0x3f8
 ttyb ... not present
 ttyc ... not present
 ttyd ... not present
 null software device
 spin software device

Right at this point is where it drops to about 1/2 or slower speed.
Then, cell by cell, it prints

console ttyb failed to initialize
console ttyc failed to initialize
console ttyd failed to initialize




This is the point where you have got hint about why this happens. The same 
defect

is with virtualbox, when you have configured host pipe for serial device.

The three lines above tell us that ttya was successfully initialized, so it 
must

have to do about ttya.

OK I neglected to note that this was including the advice by Andy to drop to
text mode, by interrupting loader, and entering -t at the prompt followed by
enter. It's clear that it was attempting serial mode -- note the port 0x3f8
Without interrupting loader, text and ttya return:
  text VESA (800x600 - 1600x1200 depending on what I'm hooked up to)
  ttya ... not present

I'm attempting it again via Legacy where
text VESA 1600x1200
ttya ... not present
Choosing 5 (options), followed by 5 (verbose) has already taken 20
minutes (it's still in progress). I think I'm just going to try to
install it and work on it further from the internal disk. In hopes
of getting at least a small speed increase from 0 to actual boot.

I greatly appreciate your insight on this, Toomas.


If you comment out (I am assuming you have installed OS) the line:

console="text, ttya, ttyb, ttyc, ttyd”

from /boot/defaults/loader.conf, you will probably find the console is much 
better.


rgds,
toomas


--Chris



Then clears the screen to draw the OI banner, and boot options.
Which takes even longer.

Not sure where to look from here. But I really appreciate your
chiming in, Andy.

Thanks!

--Chris


Andy




--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-01-29 17:57, Gary Mills wrote:

On Fri, Jan 29, 2021 at 05:02:21PM -0800, Chris wrote:

OK just dragged a Dell Optiplex 790 off the shelf
with a 4 core 8 thread i5 CPU in it, and as much RAM
as I could jam in it.
BIOS:
boot UEFI


You can't do that.  You have to boot OI in BIOS mode.

The loader works in UEFI mode, but OI does not.  Usually you are
offered a choice at boot time.  Chose BIOS mode.

Alright. I went to the BIOS and changed it to Legacy boot.
Bounced the box. But the problem remains. The only perceivable
difference. Is that when it booted to the OI UEFI firmware,
it changed to the correct resolution: 1920x1200. But after it
left the firmware, it went to 800x600. With legacy boot, it was
800x600, and then the same path as before. :-(

Thank you again, Gary for taking the time to help/respond.

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-01-29 17:57, Gary Mills wrote:

On Fri, Jan 29, 2021 at 05:02:21PM -0800, Chris wrote:

OK just dragged a Dell Optiplex 790 off the shelf
with a 4 core 8 thread i5 CPU in it, and as much RAM
as I could jam in it.
BIOS:
boot UEFI


You can't do that.  You have to boot OI in BIOS mode.

The loader works in UEFI mode, but OI does not.  Usually you are
offered a choice at boot time.  Chose BIOS mode.

Thanks, Gary. I'll give that a shot.

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

On 2021-01-29 17:18, Andy Fiddaman wrote:

On Fri, 29 Jan 2021, Chris wrote:

; OK just dragged a Dell Optiplex 790 off the shelf
; with a 4 core 8 thread i5 CPU in it, and as much RAM
; as I could jam in it.
; BIOS:
; boot UEFI
; SATA ahci
; I've tried 2 different Nvidia cards, as well as the
; intermal video. The results are the same;
; 2.5 minutes to get to the OI banner/boot options.
; An additiona 3.5 to draw the OI banner/options screen.
; It takes ~0.5 seconds to draw each cell. To be clear;
; I'm not complaining here. Rather, I'm trying to
; pinpoint WTF is going wrong in hopes of overcoming
; the problem. I've attempted to put OI on 3 different
; computers now, and the results have all been
; underwhelming in the console dept.
;
; Any thoughts?

If you can press  really early in the boot process, you get the
first loader prompt (I forget exactly how it looks). At that point,
enter "-t" without the quotes and press return. That will keep in
VGA mode, which might well be faster/usable.

Huge thanks for the reply, Andy!
Yes, it made a difference. Drawing each cell only takes 0.25
seconds. :-P
So somewhat faster, anyway. It's funny. It starts out quite
fast. The speed I normally experience with other stuff. It
writes
Available consoles:
  text VGA ...
  ttya port 0x3f8
  ttyb ... not present
  ttyc ... not present
  ttyd ... not present
  null software device
  spin software device

Right at this point is where it drops to about 1/2 or slower speed.
Then, cell by cell, it prints

console ttyb failed to initialize
console ttyc failed to initialize
console ttyd failed to initialize

Then clears the screen to draw the OI banner, and boot options.
Which takes even longer.

Not sure where to look from here. But I really appreciate your
chiming in, Andy.

Thanks!

--Chris



Andy




--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

[OpenIndiana-discuss] ~6 minutes to OI banner/boot options in text install

[Chris]

OK just dragged a Dell Optiplex 790 off the shelf
with a 4 core 8 thread i5 CPU in it, and as much RAM
as I could jam in it.
BIOS:
boot UEFI
SATA ahci
I've tried 2 different Nvidia cards, as well as the
intermal video. The results are the same;
2.5 minutes to get to the OI banner/boot options.
An additiona 3.5 to draw the OI banner/options screen.
It takes ~0.5 seconds to draw each cell. To be clear;
I'm not complaining here. Rather, I'm trying to
pinpoint WTF is going wrong in hopes of overcoming
the problem. I've attempted to put OI on 3 different
computers now, and the results have all been
underwhelming in the console dept.

Any thoughts?

Thank you for all your time, and consideration.

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] What's HASWELL support like on OI?

[Chris]

On 2021-01-29 13:20, Stephan Althaus wrote:

On 01/29/21 17:29, Chris wrote:

On 2021-01-28 23:38, Udo Grabowski (IMK) wrote:

On 29.01.21 06:48, Chris wrote:

Maybe I'm spoiled, because the (Free)BSD console(s)
are great. I can CTRL+ALT+F(1-12) for a new session, and attack
several different tasks simultaneously.
Guess I'm going to have to build all that into OI.


Fire up services

online 2018 svc:/system/vtdaemon:default
online 2018 svc:/system/console-login:vt4
online 2018 svc:/system/console-login:vt6
online 2018 svc:/system/console-login:vt3
online 2018 svc:/system/console-login:vt5
online 2018 svc:/system/console-login:vt2

and you have what you want (note: Its alt only on the console, ctrl-alt in 
X)

alt-f 1 to 6 gives a new console, alt-f7 graphical desktop (if X is
running).

Thanks! I don't have any of that here. This sort of thing is
controlled by /etc/ttys on FreeBSD. I'm not sure what the equivalent
is on OI. Will have to look around and see what I can find.
Seems odd to me your listing above isn't initiated by default.

Thanks again! :-)

--Chris






Hello Chris!

On my system that was installed on Jan, 24
the services are _not_ enabled by default

$ svcs -a|grep -i vt
disabled   20:57:27 svc:/system/vtdaemon:default
disabled   20:57:27 svc:/system/console-login:vt2
..
disabled   20:57:27 svc:/system/console-login:vt6

So you have to enable them after installation:
svcadm enable svc:/system/vtdaemon:default

.. and Udo is right, i made a mistake, the keys to be pressed are

CTRL-ALT-F1 for the firstVT
CTRL-ALT-F2 for the 2nd VT
..

*Uups* - These VT won't be there on an UEFI System - just at this moment 
looking

at a black screen after pressing CRTL-ALT-F1

dmesg says:
console-kit-daemon[512]: [ID 702911 daemon.warning] WARNING: signal
"open_session_request" (from "OpenSessionRequest") exported but not found in
object class "CkSeat"

Be sure to use LEGACY boot option - if you have..

Thank you, Stephan!

Yep. sudo svcadm enable vtdaemon
followed by
for i in 2 3 4 5 6 ; do sudo svcadm enable console-login:vt$i; done;
gets it. :-)
Thanks again!



Greetings,

Stephan


--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] What's HASWELL support like on OI?

[Chris]

On 2021-01-29 08:45, John D Groenveld wrote:

In message <91ecf33c60c1c9dcca392709ecd01...@bsdos.info>, Chris writes:

Thanks! I don't have any of that here. This sort of thing is
controlled by /etc/ttys on FreeBSD. I'm not sure what the equivalent
is on OI. Will have to look around and see what I can find.


https://wiki.openindiana.org/pages/viewpage.action?pageId=30802326>

Thanks! :-)



Seems odd to me your listing above isn't initiated by default.


I rarely use virtual terminals on my *BSD and Linux machines
but I don't disable them.

BTW besides porting the enhancements of FreeBSD's ath(4) to ath(7D),
what's your intention for this OI machine?

First off. To make something I can develop (OI) on.
In a wider scope; cure what ails it (perceived). IOW I'd really like
to get on board with OI as my go-to OS. But it (currently) lacks man
power and resources. I'd like help overcome th(at|ose) obstical(s).
I'm looking to create an additional install against both Xfce &&
Cinnamon. But before that I see some things that I've become accustomed
to aren't working as I would expect. So I'll need to address them first.
fe; a directory listing of /usr/include takes some 20 seconds. All
screen draws stutter like the first black-and-white films. Something
appears to be broken. Other things may just be a lack of fully
understanding on my part -- like the multiple consoles.
In any event. I'd just like to "pitch in", and either fix or add
to OI. :-)

Thanks for your reply, John!


John
groenv...@acm.org

--Chris




--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] What's HASWELL support like on OI?

[Chris]

On 2021-01-28 23:38, Udo Grabowski (IMK) wrote:

On 29.01.21 06:48, Chris wrote:

Maybe I'm spoiled, because the (Free)BSD console(s)
are great. I can CTRL+ALT+F(1-12) for a new session, and attack
several different tasks simultaneously.
Guess I'm going to have to build all that into OI.


Fire up services

online 2018 svc:/system/vtdaemon:default
online 2018 svc:/system/console-login:vt4
online 2018 svc:/system/console-login:vt6
online 2018 svc:/system/console-login:vt3
online 2018 svc:/system/console-login:vt5
online 2018 svc:/system/console-login:vt2

and you have what you want (note: Its alt only on the console, ctrl-alt in 
X)

alt-f 1 to 6 gives a new console, alt-f7 graphical desktop (if X is
running).

Thanks! I don't have any of that here. This sort of thing is
controlled by /etc/ttys on FreeBSD. I'm not sure what the equivalent
is on OI. Will have to look around and see what I can find.
Seems odd to me your listing above isn't initiated by default.

Thanks again! :-)

--Chris





--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] What's HASWELL support like on OI?

[Chris]

On 2021-01-28 22:54, Stephan Althaus wrote:

On 01/29/21 07:48, Chris wrote:

On 2021-01-28 22:18, Toomas Soome via openindiana-discuss wrote:

On 29. Jan 2021, at 07:48, Chris  wrote:

On 2021-01-28 19:48, Gary Mills wrote:

On Thu, Jan 28, 2021 at 05:35:38PM -0800, Chris wrote:

I'm trying to find some combination of hardware that will
produce reasonable performance at the console.

By console, do you mean the raw console without a window manager?  If
that's the case, it's no wonder that you are finding it slow.  Most
people never see this, except during boot.  The raw console is known
to be quite slow.  It's never been a problem because the terminal
windows you get with a window manager are quite fast.  I have five
low-end systems with a variety of video cards all running OI here.
All I ever did was to do the initial install from the live USB image,
and do updates afterwards with the pkg command.

Well *that's* depressing. Hmm. I guess my first task is going to be
*fixing* that. Frustrating; as I do a great deal of my initial work
from the console. Maybe I'm spoiled, because the (Free)BSD console(s)
are great. I can CTRL+ALT+F(1-12) for a new session, and attack
several different tasks simultaneously.
Guess I'm going to have to build all that into OI. Looks like OI uses
wcons. I'll see if I can coerce syscons(4) to replace it. Unless
someone else has a better idea/option. :-)

Thanks for taking the time to reply, Gary. Greatly appreciated!

—Chris




You do not really want to start with replacing console with syscons, 
syscons
itself is already obsolete and freebsd got itself in situation with two 
competing

(and broken in parts) console implementations:)

For virtual consoles, you want to check VT(7I), I do not know why we do 
not enable

vt’s bt default:

tsoome@beastie:~$ svcs -a | grep vt
disabled   11:34:57 svc:/system/vtdaemon:default
disabled   11:34:57 svc:/system/console-login:vt2
disabled   11:34:57 svc:/system/console-login:vt3
disabled   11:34:57 svc:/system/console-login:vt4
disabled   11:34:57 svc:/system/console-login:vt5
disabled   11:34:57 svc:/system/console-login:vt6

IMO this is a bug. In any case, there is not need to start with replacing 
random
components with another kind of random components when there is perfectly 
good

option about making existing components better;)

I fully agree that needless "competition* should be avoided.
However for production, I exclusively use Nvidia adapters, as there is far 
too

much overhead attempting to use AMD/radeon/intel on FreeBSD. They work very
inconsistently between brands, and between console vs Graphics/X(org). Most 
all
of this is simply the churn adapting Linux graphics to FreeBSD. In fact 
after

~2yrs. I am still unable to CTRL+ALT+F1 from X with anything but an Nvidia
adapter. In part because using an Nvidia adapter I simply add kern.vty=sc
to loader.conf(5) and I'm done. X works && so do all the consoles. I can't
say the same for the other video adapters. They all require vt(4) which is 
as

yet still immature, and incomplete as compared to syscons(2) (sc). The font
handling is poor. Copy Paste at the console is inconsistent && largely
impossible. Character mode is almost unusable. Mode switching is also 
wonky.

As it is, it is almost exclusively limited to Graphics mode, Which is fine
if you live in X. But if you're already in X, you don't need it.
My experience(s).

Thank you for taking the time to point out vt(4) lives in OI, Toomas. :-)

--Chris


rgds,
toomas



Hello!

I am using an NVIDIA card with OI, LEGACY boot,
vt is enabled and in TEXT mode
which is about as fast as i was used to in former lx days, nothing to 
compain here..,

CTRL-1, CTRL-2 is working from X

Is it available by default on a fresh install?
Because I'm not enjoying your success.
I guess I'll have to see if I can simply enable it, and give it a go. :-)


Greetings,

Stephan

Thanks, Stephan! :-)

--Chris




--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] A dumb idea

[Chris Game]

On Thu, 28 Jan 2021, Chris wrote:


While coming from FreeBSD makes me a bit biased. I think it's a good thing
to think/talk about. But be warned; FreeBSD pkg(8) comes with it's own set of
complications. Not something OI would want to inherit. fe; if you build your
packages/applications from ports (source). You can NOT use package AT ALL.
Conversely; if you install your applications from pkg(8). You can NOT build
additional applications from ports/source. They are mutually incompatible.
Something to think about. :-)


Is anyone building from source these days? I thought of trying that
for a FreeBSD system last week and it shocked me how much time and
space was needed to build  Xorg just to start things off. I gave up
the idea when the system crashed due to lack of space - a 15GB
virtual partition was full, and the 'make' operation had already
taken 4 hrs or so.

Probably off topic, but showed me all is not well in the BSD world.

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

Re: [OpenIndiana-discuss] What's HASWELL support like on OI?

[Chris]

On 2021-01-28 22:18, Toomas Soome via openindiana-discuss wrote:

On 29. Jan 2021, at 07:48, Chris  wrote:

On 2021-01-28 19:48, Gary Mills wrote:

On Thu, Jan 28, 2021 at 05:35:38PM -0800, Chris wrote:

I'm trying to find some combination of hardware that will
produce reasonable performance at the console.

By console, do you mean the raw console without a window manager?  If
that's the case, it's no wonder that you are finding it slow.  Most
people never see this, except during boot.  The raw console is known
to be quite slow.  It's never been a problem because the terminal
windows you get with a window manager are quite fast.  I have five
low-end systems with a variety of video cards all running OI here.
All I ever did was to do the initial install from the live USB image,
and do updates afterwards with the pkg command.

Well *that's* depressing. Hmm. I guess my first task is going to be
*fixing* that. Frustrating; as I do a great deal of my initial work
from the console. Maybe I'm spoiled, because the (Free)BSD console(s)
are great. I can CTRL+ALT+F(1-12) for a new session, and attack
several different tasks simultaneously.
Guess I'm going to have to build all that into OI. Looks like OI uses
wcons. I'll see if I can coerce syscons(4) to replace it. Unless
someone else has a better idea/option. :-)

Thanks for taking the time to reply, Gary. Greatly appreciated!

—Chris




You do not really want to start with replacing console with syscons, syscons
itself is already obsolete and freebsd got itself in situation with two 
competing

(and broken in parts) console implementations:)

For virtual consoles, you want to check VT(7I), I do not know why we do not 
enable

vt’s bt default:

tsoome@beastie:~$ svcs -a | grep vt
disabled   11:34:57 svc:/system/vtdaemon:default
disabled   11:34:57 svc:/system/console-login:vt2
disabled   11:34:57 svc:/system/console-login:vt3
disabled   11:34:57 svc:/system/console-login:vt4
disabled   11:34:57 svc:/system/console-login:vt5
disabled   11:34:57 svc:/system/console-login:vt6

IMO this is a bug. In any case, there is not need to start with replacing 
random
components with another kind of random components when there is perfectly 
good

option about making existing components better;)

I fully agree that needless "competition* should be avoided.
However for production, I exclusively use Nvidia adapters, as there is far 
too

much overhead attempting to use AMD/radeon/intel on FreeBSD. They work very
inconsistently between brands, and between console vs Graphics/X(org). Most 
all

of this is simply the churn adapting Linux graphics to FreeBSD. In fact after
~2yrs. I am still unable to CTRL+ALT+F1 from X with anything but an Nvidia
adapter. In part because using an Nvidia adapter I simply add kern.vty=sc
to loader.conf(5) and I'm done. X works && so do all the consoles. I can't
say the same for the other video adapters. They all require vt(4) which is as
yet still immature, and incomplete as compared to syscons(2) (sc). The font
handling is poor. Copy Paste at the console is inconsistent && largely
impossible. Character mode is almost unusable. Mode switching is also wonky.
As it is, it is almost exclusively limited to Graphics mode, Which is fine
if you live in X. But if you're already in X, you don't need it.
My experience(s).

Thank you for taking the time to point out vt(4) lives in OI, Toomas. :-)

--Chris


rgds,
toomas


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] A dumb idea

[Chris]

On 2021-01-28 19:50, Hung Nguyen Gia via openindiana-discuss wrote:

What about just import the FreeBSD Ports system and like DragonflyBSD uses
transformations scripts (https://github.com/DragonFlyBSD/DeltaPorts) to 
transform
it into illumos-ports something like this 
(https://github.com/DragonFlyBSD/DPorts)
and enjoying the large amount of software we will never able to port by our 
own

with little effort?

Yes, FreeBSD and DragonflyBSD share more in common than FreeBSD and Illumos.

But people have done this for MacPorts anyway.

We can even patch the illumos-ports to output IPS packages instead of 
FreeBSD's pkg.


This doesn't mean to dump our current oi-userland. illumos-ports and 
oi-userland

could co-exist.

I know it sounds dumb but let's just give it a thought experiment and 
imagine.


BTW, the case between IPS pkg and FreeBSD pkg is where the copycat get it 
better

than the original.

Yes, FreeBSD pkg is a clone of IPS pkg, for FreeBSD.

But they didn't use Python and since their OS still has to installed on VPS 
with
little RAM so they can't make the ZFS assumption like us, so FreeBSD pkg 
doesn't

depend on ZFS, it works just fine with UFS.

IMHO, FreeBSD is simpler and has better performance than IPS pkg.

Yet it supports the almost the same features. It could operate on FreeBSD 
'jail',

too. Just like IPS pkg could operate on 'zones'.

IPS pkg is overly complicated and a resource hog with poor performance.

Unfortunately, we pretty much have to stick with it, for the sake of 
compatibility.

While coming from FreeBSD makes me a bit biased. I think it's a good thing
to think/talk about. But be warned; FreeBSD pkg(8) comes with it's own set of
complications. Not something OI would want to inherit. fe; if you build your
packages/applications from ports (source). You can NOT use package AT ALL.
Conversely; if you install your applications from pkg(8). You can NOT build
additional applications from ports/source. They are mutually incompatible.
Something to think about. :-)




--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] What's HASWELL support like on OI?

[Chris]

On 2021-01-28 19:48, Gary Mills wrote:

On Thu, Jan 28, 2021 at 05:35:38PM -0800, Chris wrote:

I'm trying to find some combination of hardware that will
produce reasonable performance at the console.


By console, do you mean the raw console without a window manager?  If
that's the case, it's no wonder that you are finding it slow.  Most
people never see this, except during boot.  The raw console is known
to be quite slow.  It's never been a problem because the terminal
windows you get with a window manager are quite fast.  I have five
low-end systems with a variety of video cards all running OI here.
All I ever did was to do the initial install from the live USB image,
and do updates afterwards with the pkg command.

Well *that's* depressing. Hmm. I guess my first task is going to be
*fixing* that. Frustrating; as I do a great deal of my initial work
from the console. Maybe I'm spoiled, because the (Free)BSD console(s)
are great. I can CTRL+ALT+F(1-12) for a new session, and attack
several different tasks simultaneously.
Guess I'm going to have to build all that into OI. Looks like OI uses
wcons. I'll see if I can coerce syscons(4) to replace it. Unless
someone else has a better idea/option. :-)

Thanks for taking the time to reply, Gary. Greatly appreciated!

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] What's HASWELL support like on OI?

[Chris]

On 2021-01-28 19:08, Hung Nguyen Gia wrote:

This is my CPU:

CPU:   Topology: Quad Core model: Intel Core i5-4460 bits: 64 type: MCP 
L2

cache: 6144 KiB

It has reasonable good performance with OI.

Graphic performance is also good. Possible to watch 4K on Palemoon and 1080p 
on Firefox.


The key point to good performance on OI is not CPU but RAM.

8G of RAM and a tweaked ZFS ARC Cache Size Max on /etc/system worked for me.

Everything is very fast and responsive. Until you touch operations with a 
spawning

a lot of process like pkgsrc it will show you the truly identity of it is,
Slowlaris.

I suggest add more RAM. Maybe 16G at least. But I think 32G is good.

Good luck at your effort.


Thanks!
I *really* appreciate your input. It gives me hope! :-)



--Chris



 On Fri, 29 Jan 2021 08:35:38 +0700 Chris  wrote 

 > I'm trying to find some combination of hardware that will
 > produce reasonable performance at the console. My last efforts
 > were in vain. I just ordered a motherboard that has intel
 > Haswell graphics support. The board also provides a pcie
 > x16 slot. Where I could put most any video card. My first
 > attempt with Intel video was a disappointment. So I tried
 > Nvidia. Which was also a disappointment. So I'm just
 > looking for something that doesn't take ~25 seconds to
 > return a full directory listing. But nothing created
 > in the within the last 5-7yrs that I have seems to fly.
 > Maybe I should be using a STBD, or RIVA TNT card? ;-)
 >
 > Thanks for your input! :-)
 >
 > --Chris
 >
 > --
 > ~10yrs a FreeBSD maintainer of ~160 ports
 > ~40yrs of UNIX
 >


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] A rant

[Chris]

On 2021-01-28 19:31, Hung Nguyen Gia via openindiana-discuss wrote:

Anyone here seems to be hated Linux too much. Does it because their bad past
experience with it or simply because Linux is success and we are loser and 
the

natural law of the loser hate the winner?

OK since this rant is personal. I'm going to chime in too.
Don't know what good it'll do anyone. ;-)

Personally; don't hate Linux. Linux is ok. I just feel more at home on the 
BSDs.


Someone used to said Linux is a cesspool because it's only a kernel and 
hacked

together to create a working system.

Today I cloned illumos-gate and I see the completely different.

I think Linux is more organized than Illumos.

Saying Linux is a hacked together work is hypocrite and indeed slapping back 
into

our own faces.

We are no different. Illumos is a hacked together work and was an product of 
an

desperate attempt to continue OpenSolaris.

We are a mess, too.

All a matter of perspective. If I were buried in code that was part of an
important part of the OS I am working on. Something that *should* have been
already done. I'd too feel it was a mess. Point being;
Am I frustrated with OI? Sure.
Do I feel OI is missing things? Yes.
Do I feel things should work better? Sure.
But in all honesty. I feel the same about FreeBSD which I run for both
myself, as well as my business. In fact my biggest "peev" is the massive
amounts of Linux code being made to run on a UNIX kernel. Not because
Linux is bad in any way. But because it's not written to be run on UNIX.
Altering it to do do, and adding shims to accommodate it. Results in an
inefficient OS. I understand that coding man hours are in short supply.
So it becomes a matter of not being able keep up with new hardware. Or
cave, and take what's already available, and make it work -- the "better
of two evils"; as it were.
Thing is; it's all subjective. Use whatever works/feels best for you. :-)
I have high standards, and expectations. I like OI. But I'm frustrated
with it. But I like it enough that I'm willing to make it bend to my will.
I like that I'm given the opportunity to do that -- I don't like something,
I "fix" it, submit it. Done! :-)


Indeed I found we are more like Linux than the BSDs.

The large part of our userland is GNU anyway.

Back to the rant: where actually things were put?

I have did many 'find . -name' commands to try to discover where things were 
put.

#!/bin/sh -
if [ $1 ]
then
for name in $(find . -type f)
do
  grep -F $name >>~/FOUND
done
else
   printf "\n\tWHAT do want to find?"
fi

exit

The location, and organization of the source hierarchy (see hier(7)) doesn't
bother me. Because it's akin to the FreeBSD layout. So I'm right at home. 
OTOH

anyone from a different system/layout would feel lost and frustrated.
The Makefiles are all parents at the tops of the trees. So seeking the info
your looking for in them, or immediately under them will usually show you the
path to take. Often it's as easy as make -C /path/to/driver/program.


I want to find the source code of pcfs, aka msdosfs.

The source files with pcfs as part of their names scattered across the 
source

tree, the same for ufs.

Which one is the true one to look for?

 I really hope we could be as 'a mess' as Linux, where things were put 
organized

into linux/fs: https://github.com/torvalds/linux/tree/master/fs

Oh no, headers scattered everywhere. Which headers really needed and what 
they are

actually for?

See above. :-)


It might took ages to find the answer.

Yet the hypocrites still accused Linux of putting everything into 
/usr/include.

Yes, you, too, the BSDs.

See above. :-)

In the end. I *do* understand your frustration. I guess it comes down to;
is it worth it to fix what you feel is broken. Or say "screw it", and move 
on. :-)


--Chris




--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

[OpenIndiana-discuss] What's HASWELL support like on OI?

[Chris]

I'm trying to find some combination of hardware that will
produce reasonable performance at the console. My last efforts
were in vain. I just ordered a motherboard that has intel
Haswell graphics support. The board also provides a pcie
x16 slot. Where I could put most any video card. My first
attempt with Intel video was a disappointment. So I tried
Nvidia. Which was also a disappointment. So I'm just
looking for something that doesn't take ~25 seconds to
return a full directory listing. But nothing created
in the within the last 5-7yrs that I have seems to fly.
Maybe I should be using a STBD, or RIVA TNT card? ;-)

Thanks for your input! :-)

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How to expand the live usb to use all of the space on the device? v2

[Chris]

On 2021-01-25 17:25, Hung Nguyen Gia via openindiana-discuss wrote:

Well. My guess seemed to be true again.

Here is the output of Linux's fdisk:

fdisk -l /dev/sdc

GPT PMBR size mismatch (4008112 != 30031871) will be corrected by write.
The backup GPT table is not on the end of the device. This problem will be
corrected by write.
Disk /dev/sdc: 14.3 GiB, 15376318464 bytes, 30031872 sectors
Disk model: Cruzer Force
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: E34D276B-2790-236C-E97C-E1EFEEAEAD80

Device   Start End Sectors  Size Type
/dev/sdc1  256   69887   69632   34M EFI System
/dev/sdc269888   7193520481M Solaris boot
/dev/sdc371936 3991694 3919759  1.9G Solaris root
/dev/sdc9  3991696 4008079   163848M Solaris reserved 1

You just dd-ed your iso image into /dev/sdc3 (don't know which Solaris name 
it is,

to be fair!)

No way to expand or extend or modify this scheme! Since there is no writable 
file

system to be expand or extend or modify at all!

Perhaps Linux's Gparted could do something with the partition table and 
possibly

creating new partition.

But who care? The point is having an read/write area for OI on the usb 
stick. And

it seemed unfeasible now.
OK I'm on one of my FreeBSD boxes. Assuming you're looking at creating a 
modified
IO hipster GUI install (OI-hipster-gui-20201031.usb) and you want to expand 
one of

the partitions. Which one? Here's what I've done so far:
mdconfig -a -t vnode -f OI-hipster-gui-20201031.usb -u 0

Now that I have the whole image loaded as a memory disk image (md(4)). Let's 
see

what we have to work with:
# gpart show md0
=> 34  4008046  md0  GPT  (1.9G)
   34  222   - free -  (111K)
  256696321  efi  (34M)
69888 20482  !6a82cb45-1dd2-11b2-99a6-080020736631  (1.0M)
71936  39197593  !6a85cf4d-1dd2-11b2-99a6-080020736631  (1.9G)
  39916951   - free -  (512B)
  3991696163849  !6a945a3b-1dd2-11b2-99a6-080020736631  (8.0M)

# gpart show -l md0
=> 34  4008046  md0  GPT  (1.9G)
   34  222   - free -  (111K)
  256696321  (null)  (34M)
69888 20482  (null)  (1.0M)
71936  39197593  (null)  (1.9G)
  39916951   - free -  (512B)
  3991696163849  (null)  (8.0M)

So. Which partition/slice do you want to grow, and how big?
Note: gpart show -l (-l means show LABEL if one exists). The column
with numbers refer to INDEXES. Which you can name to work with.


I'll cobble up an image for you. I just need your desired specs. :-)





 On Tue, 26 Jan 2021 08:18:16 +0700 Hung Nguyen Gia via 
openindiana-discuss

 wrote 

 > v1 is failed because no one could give a solution.
 >
 > 
https://openindiana.org/pipermail/openindiana-discuss/2021-January/023341.html

 >
 > So I start v2.
 >
 > As I said here:
https://openindiana.org/pipermail/openindiana-discuss/2021-January/023555.html
 >
 > I only left with fdisk. And my guess was right, it's not work.
 >
 > The ONLY thing it showed me is a EFI partition with Length is 250, no 
other

partitions to expand, no actual partition that contain the distro's data.
 >
 > The Solaris fdisk is extremely limited compared to Linux fdisk or even 
FreeBSD,

to be fair!
 >
 > I don't know your partitioning scheme on your live usb.
 >
 > Please explain and give me DETAIL answer, not kind of DIY answers I 
previously

received on v1.
 >
 > If my guess is not wrong, then:
 >
 > You just have an EFI partition in order to boot.
 >
 > Then you just dd-ed your iso image into the unallocated space and let 
your boot

loader mount it during boot.
 >
 > This is the reason why fdisk only shows just one EFI partition and 
nothing

else. Does it true?
 >
 > I saw no UFS partition, no writable file systems at all to be fair. On 
Linux,

Gparted only display a bunch of black and very small partitions:
https://imgur.com/FmcrVMF.png
 >
 > If there was an UFS file system, Linux could mount it automatically, auto 
mount
is turned on on all Linux nowadays, albeit just read-only for UFS. But, I 
saw

nothing.
 >

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How to expand the live usb to use all of the space on the device? v2

[Chris]

On 2021-01-25 17:18, Hung Nguyen Gia via openindiana-discuss wrote:

v1 is failed because no one could give a solution.

https://openindiana.org/pipermail/openindiana-discuss/2021-January/023341.html

So I start v2.

As I said here:
https://openindiana.org/pipermail/openindiana-discuss/2021-January/023555.html

I only left with fdisk. And my guess was right, it's not work.

The ONLY thing it showed me is a EFI partition with Length is 250, no other
partitions to expand, no actual partition that contain the distro's data.

The Solaris fdisk is extremely limited compared to Linux fdisk or even 
FreeBSD, to be fair!


I don't know your partitioning scheme on your live usb.

Please explain and give me DETAIL answer, not kind of DIY answers I 
previously

received on v1.

If my guess is not wrong, then:

You just have an EFI partition in order to boot.

Then you just dd-ed your iso image into the unallocated space and let your 
boot

loader mount it during boot.

This is the reason why fdisk only shows just one EFI partition and nothing 
else.

Does it true?

I saw no UFS partition, no writable file systems at all to be fair. On 
Linux,

Gparted only display a bunch of black and very small partitions:
https://imgur.com/FmcrVMF.png

If there was an UFS file system, Linux could mount it automatically, auto 
mount is

turned on on all Linux nowadays, albeit just read-only for UFS. But, I saw
nothing.
Well. I'm pretty sure the gpartd on the live OI disk can see (OI) UFS 
partition.
The thing is. The partitions that are available for the LIVE install are 
memory

disks; that is; (compressed) images on the (.usb|.iso) and are unpacked into
memory. So that no disks are touched until *install* is chosen. I know for 
sure
how FreeBSD does it. I do it all the time. But I'll need to have a look at 
the

OI live installs. I'll take a look, and see if I can give you a recipe to
accomplish what you want/need. :-)



--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How to add a new package to distibution construction?

[Chris]

On 2021-01-25 16:22, Hung Nguyen Gia via openindiana-discuss wrote:

Thanks. BTW, do you know how to do this?

https://openindiana.org/pipermail/openindiana-discuss/2021-January/023341.html

The DIY guys seemed never did the same thing but just like to teach other 
what to do.


On a booted live usb system of OI.

The format command doesn't show the usb stick as disk.

rmformat only does with formatting, but not partitioning: 
https://illumos.org/man/1/rmformat


It seemed only fdisk left. I will try if fdisk works or not.

I hate this kind of DIY answers very much.

Better give me the details, which commands to use, which man pages to look 
at...


I always give them very detailed information but they can only give these 
sh8t.
I *dearly* wish gpart(8) (FreeBSD) was available to OI (has grow && shrink). 
Once I
get my graphics card output sorted. I'm going to see about converting it to 
OI.
Till then (given a GUI) you could probably use gpartd to accomplish your 
task(s).


HTH

--Chris


 On Mon, 25 Jan 2021 19:38:37 +0700 Aurélien Larcher
 wrote 

 >
 >
 > On Mon, Jan 25, 2021 at 1:56 AM Hung Nguyen Gia via openindiana-discuss
 wrote:
 > So no one know how to do it?
 >
 > You should add the package FMRI in the distribution constructor manifest 
like I

should in the thread about nano.
 > Add it to one of the manifests included in slim_cd.
 > However sunpro is not available anymore from our repo for legal reasons, 
it was

obsoleted some weeks ago.
 >
 > Also I just remembered that you ask why we do not have cc,c++,cxx etc.. 
in

/usr/bin... I forgot to reply...
 > A lot of software assumes that if /usr/bin/cc is found then it is 
Sunstudio and
sets it as default without checking that it is actually another compiler 
e.g. GCC.
 > We had to refrain from providing the symlinks in /usr/bin to work around 
such

ill-defined behaviour...
 >
 >
 >
 >
 >
 >  On Sun, 24 Jan 2021 23:11:17 +0700 Hung Nguyen Gia via 
openindiana-discuss

 wrote 
 >
 >   > e.g: I wanted to add the sunpro package into slim_cd_x86.xml
 >   >
 >   > How could I do it?
 >   >
 >   > I found this xml doesn't contain any list of packages to be used at 
all.

 >   >
 >   > Please help. Thanks.
 >   >
 >
 >
 > --
 > ---
 > Praise the Caffeine embeddings
 >


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How to get a usable console on OI?

[Chris]

On 2021-01-25 15:36, Joshua M. Clulow wrote:

On Mon, 25 Jan 2021 at 11:52, Chris  wrote:

On 2021-01-24 23:10, Joshua M. Clulow via openindiana-discuss wrote:
> # dtrace -x stackframes=100 -n '
> profile-997 /arg0/ { @[stack()] = count(); }
> tick-60s { exit(0); }' -o out.kern_stacks
>
OK I simply created an sh script (DTTRACE) with the contents above and
fired it off as; sudo ./DTRACE &
followed by; ls -Cla /usr/include
which created: out.kern_stacks (attached).

> That will capture the stack of what's running in the kernel (if the
> kernel is running at the time) on each CPU, 997 times per second, for
> 60 seconds.  While that's running, kick off the "time ls" again.  Take
> the "out.kern_stacks"  file and pass it through the flame graph
> generator; e.g., something like:
>
> $ ./stackcollapse.pl out.kern_stacks | ./flamegraph.pl > output.svg
The results of the above are attached as: out_kern_stacks.svg
I has somehow expected a longer spike on the graph, as the output of
ls -Cla /usr/include took the same ~20 seconds to finish writing to the
screen as before.


That's great!  Thank you.

I expected a bit more as well, but I think I can see what's happening.
It looks like the "nvidia" driver is closed source and built in a way
that doesn't correctly maintain the frame pointer so DTrace is not
able to walk up the stack past that point.  On a machine that isn't
using the nvidia driver, it looks more like...

  gfx_private`bitmap_cons_display()
  gfx_private`do_gfx_ioctl+0x272
  gfx_private`gfxp_fb_ioctl+0x63
  vgatext`vgatext_ioctl+0xc0
  genunix`cdev_ioctl+0x2b
  genunix`ldi_ioctl+0x89
  tem`tems_display_layered+0x37
  tem`tems_safe_display+0x2d
  tem`tem_safe_pix_cls_range+0x152
  tem`tem_safe_pix_cls+0x4d
  tem`tem_safe_clear_chars+0xb0
  tem`tem_safe_scroll+0xdc
  tem`tem_safe_lf+0xbd
  tem`tem_safe_control+0x18d
  tem`tem_safe_parse+0x53
  tem`tem_safe_input_byte+0x109
  tem`tem_safe_terminal_emulate+0x84
  tem`tem_write+0x73
  wc`wcuwsrv+0xc7
  genunix`runservice+0x49
  genunix`queue_service+0x41

It looks like one would only get to bitmap_cons_display() by making a
VIS_CONSDISPLAY ioctl(), perhaps via tems_display_layered().  This
routine ends up copying memory around, basically.  That it's doing it
100% of the time on one CPU seems like the obvious bottleneck here.
It'd be good to know, perhaps, at what _rate_ calls to
bitmap_cons_display() are being made.  You could try something like:

dtrace -q -n '
bitmap_cons_display:return { @ = count(); }
tick-1s { printf("%Y ", walltimestamp); printa("%@d", @);
printf("\n"); trunc(@); }'

I ran that on my system, and then did "echo a >/dev/wscons"
simultaneously and was able to count 91 firings...

2021 Jan 25 15:28:46
2021 Jan 25 15:28:47
2021 Jan 25 15:28:48 91
2021 Jan 25 15:28:49
...

Another thing that would be interesting to know is: if you disable the
nvidia driver completely, is performance better?  Because you're not
currently using X11, I don't believe you technically need it.  I think
you could try, at the boot loader, hitting escape to get to the "ok"
prompt and then...

set disable-nvidia=true
boot

Hmm according to loader.conf nvidia_load="NO" should have accomplished
the same. But did not.



It should hopefully then give you a WARNING about the "nvidia" module
being disabled at boot.  Hopefully performance is at least different,
if not better, if you do that.

However...
 set disable-nvidia=true
 boot
DID disable loading of the Nvidia driver. Sadly, there was no perceptible
change in screen draws. :-(

I'll give a shot at your above suggestion, and report back.

Thank you very much for all your advice, Joshua! :-)

OH one last thing; isn't there a so-called "graphics" mode one can
initiate for the console, via the cards graphics driver (nvidia)?



Cheers.

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How to get a usable console on OI?

[Chris]

On 2021-01-25 15:16, v...@bb-c.de wrote:

Chris writes:

On 2021-01-25 00:42, v...@bb-c.de wrote:

[...]

> @Chris: Do try to set console resolution to 8 bit and see if it improves
> things for you.  You need to create the directory /boot/conf.d if it
> doesn't already exist, and add the following
>
>   loader_resolution=1280x1024x8
>   boot_resolution=1280x1024x8
Thanks for your reply, Volker!
I dumped the above 2 lines to /boot/loader.conf (actually 1920x1200)
but they were ignored.


Not sure if they would work there.  The tried and true way is to create
/boot/conf.d and put those lines into /boot/conf.d/loader-args (that's
the name I use).

For completeness, I also have /boot/conf.d/boot-args which contains

  boot-args=-v

Ahh. OK. I accomplish the same in loader.conf via:
boot_verbose="YES"
So I'm guessing the syntax you provided is probably not loder.conf(5)
compatible. :-)
I'll move it to /boot/conf.d/loader-args then.

Thanks for taking the time to respond, Volker.

--Chris



Cheers -- Volker


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How to get a usable console on OI?

[Chris]

On 2021-01-24 22:40, Stephan Althaus wrote:

On 01/25/21 02:27, Chris wrote:

I have a recent install where I simply login at the
console -- no X related stuff. Just the screen.
Things just seem broken, For example, a simple ls /dev
takes a full 3 to 4 seconds to fill the screen, and each
page full is an additional 3 to 4 seconds. This is on a 3
core AMD CPU @3Ghz && 8Gb RAM on a x16 pcie Nvidia card.
This seems horribly unreasonable. Simple shell scripts
that output to the screen take as long or longer to write
to the screen. It's like the old days logging into a BBS,
or an anonymous ftp site on an 8086 or 80286.

Thanks for any clues! :-)


Hello!

Yeah i saw this on my 4K screen too :-/


You may try to

#sudo pkg install pkg:/driver/graphics/nvidia

Good call. But I've already got this. In fact, I think it comes
by default as a kernel module.
One thing on the nvidia (graphics) module; It's apparently not
compatible with fastboot:
OIDEV genunix: [ID 884581 kern.warning] WARNING: nvidia has no quiesce()



this includes the NVIDIA Kernel Mode Setting Driver for UNIX platforms
mybe this affects the console, too.

It may be required to install some X pkgs,
and If you don't want an X login be sure to disable lightdm service

#sudo svcadm disable lightdm

Not (currently) using X(org) related things. So the services associated
with X are disabled. :-)



Thanks, Stephan!

--Chris


Greetings,

Stephan





--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How to get a usable console on OI?

[Chris]

On 2021-01-25 00:42, v...@bb-c.de wrote:

Joshua M. Clulow via openindiana-discuss writes:

On Sun, 24 Jan 2021 at 21:13, Chris  wrote:
> On 2021-01-24 18:53, Chris wrote:
> > On 2021-01-24 17:48, Joshua M. Clulow via openindiana-discuss wrote:
> >> On Sun, 24 Jan 2021 at 17:27, Chris  wrote:
> > All the reports I've seen thus far, indicate 800x600.
> > You're suggestion confirms it:
> > ts_p_dimension = {
> > ts_p_dimension.width = 0t800
> > ts_p_dimension.height = 0t600
> > }
> > ts_pdepth = 0t32

Based on that, I don't imagine trying to drop the resolution is really
going to help.


I can only relate my experience from OmniOS which also uses the BSD
loader.  Going from the default (24 bit color) to 8 bit via loader
configuration parameters improved console speed dramatically.

There were some palette bugs in 8 bit mode which Toomas Soome has all
fixed now.

@Chris: Do try to set console resolution to 8 bit and see if it improves
things for you.  You need to create the directory /boot/conf.d if it
doesn't already exist, and add the following

  loader_resolution=1280x1024x8
  boot_resolution=1280x1024x8

Thanks for your reply, Volker!
I dumped the above 2 lines to /boot/loader.conf (actually 1920x1200)
but they were ignored.

  tem.fg_color="green"

to a file (the name is your choice).  Adapt the resolution to your box.
Of course the last line may not be to your taste ;-)

Thanks for the info. I didn't realize (some of) loader had been imported
from recent(ish) BSD.




Regards -- Volker


--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How to get a usable console on OI?

[Chris]

On 2021-01-25 12:09, Chris wrote:

On 2021-01-25 11:52, Chris wrote:

On 2021-01-24 23:10, Joshua M. Clulow via openindiana-discuss wrote:

On Sun, 24 Jan 2021 at 21:13, Chris  wrote:

On 2021-01-24 18:53, Chris wrote:
> On 2021-01-24 17:48, Joshua M. Clulow via openindiana-discuss wrote:
>> On Sun, 24 Jan 2021 at 17:27, Chris  wrote:
> All the reports I've seen thus far, indicate 800x600.
> You're suggestion confirms it:
> ts_p_dimension = {
> ts_p_dimension.width = 0t800
> ts_p_dimension.height = 0t600
> }
> ts_pdepth = 0t32


Based on that, I don't imagine trying to drop the resolution is really
going to help.


> I'm booting via BIOS. While the CPU may be involved. I would have
> imagined that the cycles would be on the GPU. Which should be more than
> adequate to run high frame rates.


With the current framebuffer console code we have, I believe we
basically map a region of the video RAM into the host physical address
space.  The terminal emulator in the kernel which runs on the CPU just
copies pixels (bytes, really) from the region in memory where we store
the font into the right place in the mapped region to make it all show
up on the screen.  I don't believe the GPU is really being used for
anything, at least directly.

Does this system support UEFI booting as well?  It may help to get the
entire contents of the "tems" object to get us more detail about
exactly how the console is set up; e.g.,

# mdb -ke 'tems::print -d'

Attached as mdb-ke




> Thank you *very* much for taking the time to reply!


You are most welcome!


> I'll dump some mpstat data to file, and see what (if anything) pops up,
> and report what it contains.


I have taken a look at your mpstat output, and it does indeed seem
like between ~09:02:23PM and ~09:02:44PM (a period of around 20
seconds) one CPU was spending 100% of its time executing kernel code
(the "sys" column).  This matches up with the ~20 seconds of sys time
(the 23.223s) in the output of "time ls" you also posted.

As it seems this is pretty reproducible, the next thing I would do is
figure out what we're doing in the kernel for that 20 seconds.  You'll
want to use DTrace to capture kernel stacks; e.g.,

# dtrace -x stackframes=100 -n '
profile-997 /arg0/ { @[stack()] = count(); }
tick-60s { exit(0); }' -o out.kern_stacks


OK I simply created an sh script (DTTRACE) with the contents above and
fired it off as; sudo ./DTRACE &
followed by; ls -Cla /usr/include
which created: out.kern_stacks (attached).


That will capture the stack of what's running in the kernel (if the
kernel is running at the time) on each CPU, 997 times per second, for
60 seconds.  While that's running, kick off the "time ls" again.  Take
the "out.kern_stacks"  file and pass it through the flame graph
generator; e.g., something like:

$ ./stackcollapse.pl out.kern_stacks | ./flamegraph.pl > output.svg

The results of the above are attached as: out_kern_stacks.svg
I has somehow expected a longer spike on the graph, as the output of
ls -Cla /usr/include took the same ~20 seconds to finish writing to the
screen as before.

OK the list stripped the flamegraph file attached. So I'm attaching it as:
out_kern_stacks_svg.txt
in hopes it makes it through.

Nope. The list ate that one too.
let's try:
https://sunos.info/out_kern_stacks_svg instead. :-)


HTH

Thanks again! :-)

--Chris


Thank you very much all your helpful advice!

--Chris


You can open "output.svg" in a web browser and inspect the aggregated
view of all the stacks.  It'll probably be small enough to attach to
an e-mail here.

Note, the perl scripts above, and more detailed instructions, are all
up on GitHub:

https://github.com/brendangregg/FlameGraph#dtrace


Cheers.




--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How to get a usable console on OI?

[Chris]

On 2021-01-25 11:52, Chris wrote:

On 2021-01-24 23:10, Joshua M. Clulow via openindiana-discuss wrote:

On Sun, 24 Jan 2021 at 21:13, Chris  wrote:

On 2021-01-24 18:53, Chris wrote:
> On 2021-01-24 17:48, Joshua M. Clulow via openindiana-discuss wrote:
>> On Sun, 24 Jan 2021 at 17:27, Chris  wrote:
> All the reports I've seen thus far, indicate 800x600.
> You're suggestion confirms it:
> ts_p_dimension = {
> ts_p_dimension.width = 0t800
> ts_p_dimension.height = 0t600
> }
> ts_pdepth = 0t32


Based on that, I don't imagine trying to drop the resolution is really
going to help.


> I'm booting via BIOS. While the CPU may be involved. I would have
> imagined that the cycles would be on the GPU. Which should be more than
> adequate to run high frame rates.


With the current framebuffer console code we have, I believe we
basically map a region of the video RAM into the host physical address
space.  The terminal emulator in the kernel which runs on the CPU just
copies pixels (bytes, really) from the region in memory where we store
the font into the right place in the mapped region to make it all show
up on the screen.  I don't believe the GPU is really being used for
anything, at least directly.

Does this system support UEFI booting as well?  It may help to get the
entire contents of the "tems" object to get us more detail about
exactly how the console is set up; e.g.,

# mdb -ke 'tems::print -d'

Attached as mdb-ke




> Thank you *very* much for taking the time to reply!


You are most welcome!


> I'll dump some mpstat data to file, and see what (if anything) pops up,
> and report what it contains.


I have taken a look at your mpstat output, and it does indeed seem
like between ~09:02:23PM and ~09:02:44PM (a period of around 20
seconds) one CPU was spending 100% of its time executing kernel code
(the "sys" column).  This matches up with the ~20 seconds of sys time
(the 23.223s) in the output of "time ls" you also posted.

As it seems this is pretty reproducible, the next thing I would do is
figure out what we're doing in the kernel for that 20 seconds.  You'll
want to use DTrace to capture kernel stacks; e.g.,

# dtrace -x stackframes=100 -n '
profile-997 /arg0/ { @[stack()] = count(); }
tick-60s { exit(0); }' -o out.kern_stacks


OK I simply created an sh script (DTTRACE) with the contents above and
fired it off as; sudo ./DTRACE &
followed by; ls -Cla /usr/include
which created: out.kern_stacks (attached).


That will capture the stack of what's running in the kernel (if the
kernel is running at the time) on each CPU, 997 times per second, for
60 seconds.  While that's running, kick off the "time ls" again.  Take
the "out.kern_stacks"  file and pass it through the flame graph
generator; e.g., something like:

$ ./stackcollapse.pl out.kern_stacks | ./flamegraph.pl > output.svg

The results of the above are attached as: out_kern_stacks.svg
I has somehow expected a longer spike on the graph, as the output of
ls -Cla /usr/include took the same ~20 seconds to finish writing to the
screen as before.

OK the list stripped the flamegraph file attached. So I'm attaching it as:
out_kern_stacks_svg.txt
in hopes it makes it through.

HTH

Thanks again! :-)

--Chris


Thank you very much all your helpful advice!

--Chris


You can open "output.svg" in a web browser and inspect the aggregated
view of all the stacks.  It'll probably be small enough to attach to
an e-mail here.

Note, the perl scripts above, and more detailed instructions, are all
up on GitHub:

https://github.com/brendangregg/FlameGraph#dtrace


Cheers.




--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] How to get a usable console on OI?

[Chris]

On 2021-01-24 19:54, Reginald Beardsley via openindiana-discuss wrote:
I just took Hipster, I think 2017.10, but here's "uname -a", to single user 
mode.


SunOS Hipster 5.11 illumos-2727bb055f i86pc i386 i86pc

"ls /dev" was blisteringly quick. "/usr/bin/time ls /dev" reported 0.1 
seconds.

On
% uname -a
SunOS OIDEV 5.11 illumos-f85f43ed9f i86pc i386 i86pc
% time ls -Cla /usr/include
0.013u 23.223s 0:23.23 100.0%

--Chris


System is a quad core HP Z400 at 2.9 GHz with I think 8 GB of DRAM. Monitor 
is
1600x1200. I'm afraid I am old and *very* tired of the continual churn of 
system
commands, so I shall not provide any more data unless someone provides 
explicit
syntax. Why sysinfo(1m) was eliminated is beyond me. The traditional mantra 
was

ease of discovery. It is now apparently complexity to make the creators look
"special".

The recent volume of traffic has been driving me nuts. When "What shell to 
use?"
appeared I really began to despair. I shudder to think how many trees have 
been
killed and electrons tortured on that topic. I have very low tolerance for 
people

who don't do their homework and want others to do it for them.

I increasingly long for 4.1.1 when things still made sense. Now we have a 
half

finished transition to God only knows what. I rather fear to the graveyard.

The vision of Unix I know has been replaced by an agglomeration of poorly 
thought
out and even more poorly implemented "features". I fully appreciate why we 
are in
this situation, but it breaks my heart. There was a day when I had xterms 
open on
6 different systems, AIX, SunOS, IRIX, CLIX, Ultrix and HP-UX and I could 
move
easily among them and maintained a vast array of FOSS on all of them. And 
there
were many days when the list of systems was quite different. But all of 
those are

long gone.

Grumble,
Reg


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How to get a usable console on OI?

[Chris]

On 2021-01-24 18:53, Chris wrote:

On 2021-01-24 17:48, Joshua M. Clulow via openindiana-discuss wrote:

On Sun, 24 Jan 2021 at 17:27, Chris  wrote:

I have a recent install where I simply login at the
console -- no X related stuff. Just the screen.
Things just seem broken, For example, a simple ls /dev
takes a full 3 to 4 seconds to fill the screen, and each
page full is an additional 3 to 4 seconds. This is on a 3
core AMD CPU @3Ghz && 8Gb RAM on a x16 pcie Nvidia card.
This seems horribly unreasonable. Simple shell scripts
that output to the screen take as long or longer to write
to the screen. It's like the old days logging into a BBS,
or an anonymous ftp site on an 8086 or 80286.

Thanks for any clues! :-)


Do you happen to know what resolution and colour depth are in use on
the console on this machine?  As far as I recall, the current
framebuffer console code doesn't use any acceleration features, it
just writes each frame to a flat bitmap effectively.  The higher the
resolution, or the higher the colour depth, the more CPU cycles will
be spent on copying data into the display.

I believe you can tell by running something like this:

# mdb -ke 'tems::print -d ts_p_dimension ts_pdepth'
ts_p_dimension = {
ts_p_dimension.width = 0t1280
ts_p_dimension.height = 0t768
}
ts_pdepth = 0t32

All the reports I've seen thus far, indicate 800x600.
You're suggestion confirms it:
ts_p_dimension = {
ts_p_dimension.width = 0t800
ts_p_dimension.height = 0t600
}
ts_pdepth = 0t32



From these numbers we can determine the rough size of the framebuffer

data region; e.g.,

1280 * 768 * 32 / 8 / 1024 / 1024 = 3.75 MB

If you had a larger display, say 1920x1080, that could result in

It's running on a 1900x1200

around twice as many pixels.  All things being equal, it would
probably take twice as long to draw an update.  I believe the
framebuffer modes available to you depend at least in part on what
your UEFI firmware makes available, but I'm not sure off-hand how to
enumerate them or choose between them.  Someone else may recall, or we
can look at the boot loader docs and code to find out.

With that in mind, it might help to know whether, on your system, the
CPU is the bottleneck.  Your system has a lot of cores, but is at
least one of them 100% busy (presumably mostly in the kernel) while
the display is updating?  You could run "mpstat -T d 1" redirected
into a file in the background to get overall CPU measurements with
timestamps.  Then, run something that takes 20 seconds to display and
look at the output to see if a core is busy during that time.

Alright. Here's the output from mpstat (see attached).
Any thoughts on the output?

Thanks!

--Chris



I'm booting via BIOS. While the CPU may be involved. I would have
imagined that the cycles would be on the GPU. Which should be more than
adequate to run high frame rates.


If there's a CPU that's relatively busy, I would next use DTrace to
profile the kernel.  You can get a flamegraph of the same 20 seconds
of busy work:

https://github.com/brendangregg/FlameGraph#dtrace

Profiling data like that should let us know where the kernel is
spending its time, and may give pointers for optimisations or fixes we
could make.

Thank you *very* much for taking the time to reply!
I'll dump some mpstat data to file, and see what (if anything) pops up,
and report what it contains.

Thanks again.

--Chris


Cheers.


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIXSunOS OIDEV 5.11 illumos-f85f43ed9f i86pc i386 i86pc
% mpstat -T d 1 >>./MPSTAT &
% ls -Cla /usr/include/
% kill -HUP 4496

January 24, 2021 at 09:02:09 PM PST
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0   24   01  2146  140  2530810210   4   0  96
  1   28   0076   23   720510250   1   0  99
  2   25   0055   17   550400250   0   0  99
January 24, 2021 at 09:02:10 PM PST
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  0   26   08  2156  136  1840   3610   2960   2   0  98
  10   06   134   34  1060   2000 00   0   0 100
  20   04   225   15   733   1500 10  17   0  83
January 24, 2021 at 09:02:11 PM PST
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  00   00  2217  134  2910   65   470   2740   3   0  97
  10   00   198   27  2520   48   530 00   1   0  99
  20   00   186   69  1910   39   450 20   1   0  99
January 24, 2021 at 09:02:12 PM PST
CPU minf mjf xcal  intr ithr  csw icsw migr smtx  srw syscl  usr sys  wt idl
  00   00  2161  131  1900   4930   2740   3   0  97
  10   00   143   29  1290   3100 3  

Re: [OpenIndiana-discuss] How to get a usable console on OI?

[Chris]

On 2021-01-24 17:48, Joshua M. Clulow via openindiana-discuss wrote:

On Sun, 24 Jan 2021 at 17:27, Chris  wrote:

I have a recent install where I simply login at the
console -- no X related stuff. Just the screen.
Things just seem broken, For example, a simple ls /dev
takes a full 3 to 4 seconds to fill the screen, and each
page full is an additional 3 to 4 seconds. This is on a 3
core AMD CPU @3Ghz && 8Gb RAM on a x16 pcie Nvidia card.
This seems horribly unreasonable. Simple shell scripts
that output to the screen take as long or longer to write
to the screen. It's like the old days logging into a BBS,
or an anonymous ftp site on an 8086 or 80286.

Thanks for any clues! :-)


Do you happen to know what resolution and colour depth are in use on
the console on this machine?  As far as I recall, the current
framebuffer console code doesn't use any acceleration features, it
just writes each frame to a flat bitmap effectively.  The higher the
resolution, or the higher the colour depth, the more CPU cycles will
be spent on copying data into the display.

I believe you can tell by running something like this:

# mdb -ke 'tems::print -d ts_p_dimension ts_pdepth'
ts_p_dimension = {
ts_p_dimension.width = 0t1280
ts_p_dimension.height = 0t768
}
ts_pdepth = 0t32

All the reports I've seen thus far, indicate 800x600.
You're suggestion confirms it:
ts_p_dimension = {
ts_p_dimension.width = 0t800
ts_p_dimension.height = 0t600
}
ts_pdepth = 0t32



From these numbers we can determine the rough size of the framebuffer

data region; e.g.,

1280 * 768 * 32 / 8 / 1024 / 1024 = 3.75 MB

If you had a larger display, say 1920x1080, that could result in

It's running on a 1900x1200

around twice as many pixels.  All things being equal, it would
probably take twice as long to draw an update.  I believe the
framebuffer modes available to you depend at least in part on what
your UEFI firmware makes available, but I'm not sure off-hand how to
enumerate them or choose between them.  Someone else may recall, or we
can look at the boot loader docs and code to find out.

With that in mind, it might help to know whether, on your system, the
CPU is the bottleneck.  Your system has a lot of cores, but is at
least one of them 100% busy (presumably mostly in the kernel) while
the display is updating?  You could run "mpstat -T d 1" redirected
into a file in the background to get overall CPU measurements with
timestamps.  Then, run something that takes 20 seconds to display and
look at the output to see if a core is busy during that time.


I'm booting via BIOS. While the CPU may be involved. I would have
imagined that the cycles would be on the GPU. Which should be more than
adequate to run high frame rates.


If there's a CPU that's relatively busy, I would next use DTrace to
profile the kernel.  You can get a flamegraph of the same 20 seconds
of busy work:

https://github.com/brendangregg/FlameGraph#dtrace

Profiling data like that should let us know where the kernel is
spending its time, and may give pointers for optimisations or fixes we
could make.

Thank you *very* much for taking the time to reply!
I'll dump some mpstat data to file, and see what (if anything) pops up,
and report what it contains.

Thanks again.

--Chris


Cheers.


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

[OpenIndiana-discuss] How to get a usable console on OI?

[Chris]

I have a recent install where I simply login at the
console -- no X related stuff. Just the screen.
Things just seem broken, For example, a simple ls /dev
takes a full 3 to 4 seconds to fill the screen, and each
page full is an additional 3 to 4 seconds. This is on a 3
core AMD CPU @3Ghz && 8Gb RAM on a x16 pcie Nvidia card.
This seems horribly unreasonable. Simple shell scripts
that output to the screen take as long or longer to write
to the screen. It's like the old days logging into a BBS,
or an anonymous ftp site on an 8086 or 80286.

Thanks for any clues! :-)

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Illumos UFS vs FreeBSD UFS?

[Chris]

On 2021-01-22 23:17, Chris wrote:

On 2021-01-22 22:58, Hung Nguyen Gia via openindiana-discuss wrote:

Are they compatible? Could I use UFS for data exchange purpose?

UFS is available on all BSDs, including one doesn't support ZFS. So it's a 
better

portable FS than ZFS.

But I'm a bit pessimistic, because each BSD's UFS is different to the 
other. e.g:
FreeBSD's UFS2 doesn't mountable under DragonflyBSD, which only supports 
UFS1.
FWIW Dragonfly was forked to show off the hammer filesystem he created. As 
such,

not much interest in keeping ffs in sync.
Truth is; ffs was created by BSD. Anyway. I'm betting the differences, if 
any, are
minimal. It would be trivial to experiment on a couple USB sticks if you 
don't have

a couple spare platters.

Good question. Glad you brought it up.


So I don't expect much.

BTW, our UFS is UFS2 or UFS1 or something else?

_technically_ it's ffs v ffs2. Hope that helps. :-)

Hmm... well the man pages are not forthcoming on this.
Well, as I remember the early days, it was initially called
ffs -- Fast File System. The updates garnered the title ffs2.
I'll need to dig into my archives.

--Chris




Please let me know. Thanks.



--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Illumos UFS vs FreeBSD UFS?

[Chris]

On 2021-01-22 22:58, Hung Nguyen Gia via openindiana-discuss wrote:

Are they compatible? Could I use UFS for data exchange purpose?

UFS is available on all BSDs, including one doesn't support ZFS. So it's a 
better

portable FS than ZFS.

But I'm a bit pessimistic, because each BSD's UFS is different to the other. 
e.g:
FreeBSD's UFS2 doesn't mountable under DragonflyBSD, which only supports 
UFS1.
FWIW Dragonfly was forked to show off the hammer filesystem he created. As 
such,

not much interest in keeping ffs in sync.
Truth is; ffs was created by BSD. Anyway. I'm betting the differences, if 
any, are
minimal. It would be trivial to experiment on a couple USB sticks if you 
don't have

a couple spare platters.

Good question. Glad you brought it up.


So I don't expect much.

BTW, our UFS is UFS2 or UFS1 or something else?

_technically_ it's ffs v ffs2. Hope that helps. :-)



Please let me know. Thanks.


--Chris
--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] How to speedup screen writes?

[Chris]

On 2021-01-22 17:42, Hung Nguyen Gia wrote:
You said you used the text install so I assume it's non-graphical 
installation?


Then better use ssh and work on your comfortable workstation with a handy 
terminal

emulator like XFCE4 Terminal.

If it's graphical, I'm out of idea. I don't use NVIDIA.

Thanks for the reply!
Well yes. I'm at the console ATM. But I notice it's pretty well the same
when I was testing with the GUI installer. So I'm guessing I'm not getting
graphics mode. But rather, the framebuffer.
I'll see if I can figure it all out after I finish getting all the packages
I need installed, and update the BE.

Thanks again! :-)

--Chris





 On Sat, 23 Jan 2021 08:34:13 +0700 Chris  wrote 

 > I'm on Nvidia graphics.
 > But it looks like my console is running an 800x600 VESA
 > framebuffer. As a result. The screen draws are REAL slow.
 > How to best improve that on OI? I change to modsetting
 > on FreeBSD. But I don't think that's available on OI?
 >
 > Thanks!
 >
 > --Chris
 >
 > --
 > ~10yrs a FreeBSD maintainer of ~160 ports
 > ~40yrs of UNIX
 >
 > ___
 > openindiana-discuss mailing list
 > openindiana-discuss@openindiana.org
 > https://openindiana.org/mailman/listinfo/openindiana-discuss
 >


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

[OpenIndiana-discuss] How to speedup screen writes?

[Chris]

I'm on Nvidia graphics.
But it looks like my console is running an 800x600 VESA
framebuffer. As a result. The screen draws are REAL slow.
How to best improve that on OI? I change to modsetting
on FreeBSD. But I don't think that's available on OI?

Thanks!

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Is there a *BSD to OI/Solaris cheatsheet?

[Chris]

On 2021-01-22 11:21, Richard L. Hamilton wrote:

modinfo, modload (but you should usually use add_drv to install a loadable
driver/module, instead), modunload (but you should usually use rem_drv 
instead).
RTFM on all of 'em, because the options and behavior are likely to be 
different.


A google for
 freebsd solaris admin cheat sheet
will find some things, but a number of them are not impressive.

https://github.com/jpdasma/unix-cheat-sheet
and
https://networking.ringofsaturn.com/Unix/unixguide.php

look non-horrible to me, although I would take them all with a big grain of 
salt.

A huge thank you for all of that. Exactly what I was hoping for.
If I can get _close_ to what I'm looking for I can sort the fine details.
I never imagined there would be an exact equiv. I was just trying to build
up my memory muscle for Solaris/OI commands.
I usually create aliases for the frequently used commands with my chosen
options.

Thanks again, Richard. Your input should get me up to speed in no time. :-)

--Chris




On Jan 22, 2021, at 14:09, Chris  wrote:

OK while I've run all the various NIXs availabe for as long
as I can remember. My $work has been primarily tied to
FreeBSD. So in an effort to get up-to-speed. I was hoping I
could find a sort of cheatsheet for ppl coming from the BSDs.
Things like
kldstat == ? on OI
kldload
etc...

man intro was of little use.

Thanks!

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] When will AMD XIII CPUs be supported

[Chris]

On 2021-01-22 11:14, Gary Mills wrote:

On Fri, Jan 22, 2021 at 01:14:05AM -0800, Chris wrote:


OK here's a nice picture (screenshot) I was able to capture that
pretty well sums it up.

Driver is NOT the problem.
I think the only way I'm going to be able to install OI on this, is
by plugging my sata drive into a USB adapter, and install it there.
Then after installation. Plug the drive back into the sata port on
the MB. I thought OI had better sata support. It clearly understands
the controller.

Well. They say a Picture paints a thousand words:
https://bsdos.info/OI/Screenshot-2021-01-22-00-12-55.png


Your picture shows that it's using the nv_sata driver for the disk
controller, not the ahci driver.  Are you able to configure the disk
controllers into AHCI mode?  Doing that might fix your problem.  Most
systems use the ahci driver now.  Here's how mine looks in OI:

$ prtconf -D
...
pci1b21,1062, instance #0 (driver name: ahci)
disk, instance #2 (driver name: sd)
disk, instance #5 (driver name: sd)
disk, instance #3 (driver name: sd)
disk, instance #4 (driver name: sd)

As you can see, it uses two drivers, one for the controller and one
for the disks.  Here's how my disks look in OI:

# format
...
   0. c5t0d0 sec 56>

  /pci@0,0/pci1022,1453@1,3/pci1b21,1062@0,1/disk@0,0
   1. c5t1d0 sec 56>

  /pci@0,0/pci1022,1453@1,3/pci1b21,1062@0,1/disk@1,0
   2. c5t2d0 
  /pci@0,0/pci1022,1453@1,3/pci1b21,1062@0,1/disk@2,0
   3. c5t3d0 
  /pci@0,0/pci1022,1453@1,3/pci1b21,1062@0,1/disk@3,0
Specify disk (enter its number): ^D


Thanks for your input, Gary.
I don't have a specific setting for ahci. As a rule, when available,
I choose that. But it's simply not available.

Here's the output for mine

~
11:35am Fri, 22
OIDEV# prtconf -D

System Configuration:  MSI  i86pc
Memory size: 8192 Megabytes
System Peripherals (Software Nodes):

i86pc (driver name: rootnex)
scsi_vhci, instance #0 (driver name: scsi_vhci)
pci, instance #0 (driver name: npe)
pci1462,7309
isa, instance #0 (driver name: isa)
motherboard
pit_beep, instance #0 (driver name: pit_beep)
pci1462,7309
pci1462,7309
pci1462,7309, instance #0 (driver name: ohci)
hub, instance #0 (driver name: hubd)
device, instance #0 (driver name: usb_mid)
keyboard, instance #0 (driver name: hid)
mouse, instance #1 (driver name: hid)
pci1462,7309, instance #0 (driver name: ehci)
pci10de,3f3, instance #0 (driver name: pci_pci)
pci888,10ec
pci1462,7309, instance #0 (driver name: nge)
pci1462,7309, instance #0 (driver name: nv_sata)
disk, instance #2 (driver name: sd)
pci1462,7309, instance #1 (driver name: nv_sata)
pci10de,3e8, instance #0 (driver name: pcieb)
display, instance #0 (driver name: nvidia)
pci10de,3e9 (driver name: pcieb)
pci10de,3e9 (driver name: pcieb)
pci1022,1200
pci1022,1201
pci1022,1202
pci1022,1203
pci1022,1204
fw, instance #0 (driver name: acpinex)
cpu, instance #0 (driver name: cpudrv)
cpu, instance #1 (driver name: cpudrv)
cpu, instance #2 (driver name: cpudrv)
sb, instance #1 (driver name: acpinex)
used-resources
agpgart, instance #0 (driver name: agpgart)
options, instance #0 (driver name: options)
pseudo, instance #0 (driver name: pseudo)
xsvc, instance #0 (driver name: xsvc)
iscsi, instance #0 (driver name: iscsi)

~
11:37am Fri, 22
OIDEV# format

   0. c6t1d0 
  /pci@0,0/pci1462,7309@8/disk@1,0
Specify disk (enter its number): 0
selecting c6t1d0
[disk formatted]
/dev/dsk/c6t1d0s1 is part of active ZFS pool rpool. Please see zpool(1M).

Sorry for the long output to prtconf -D. But wasn't sure if it
wouldn't be interesting.

Thanks again for your input, Gary! :-)

--Chris
--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

[OpenIndiana-discuss] Is there a *BSD to OI/Solaris cheatsheet?

[Chris]

OK while I've run all the various NIXs availabe for as long
as I can remember. My $work has been primarily tied to
FreeBSD. So in an effort to get up-to-speed. I was hoping I
could find a sort of cheatsheet for ppl coming from the BSDs.
Things like
kldstat == ? on OI
kldload
etc...

man intro was of little use.

Thanks!

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] When will AMD XIII CPUs be supported

[Chris]

On 2021-01-22 09:21, Chris wrote:

On 2021-01-22 07:34, Chris wrote:

On 2021-01-22 01:29, v...@bb-c.de wrote:

Hi Chris!


Hang in there!  I'm sure we'll get it to work eventually.


Driver is NOT the problem.
I think the only way I'm going to be able to install OI on this, is
by plugging my sata drive into a USB adapter, and install it there.
Then after installation. Plug the drive back into the sata port on
the MB. I thought OI had better sata support. It clearly understands
the controller.

Well. They say a Picture paints a thousand words:
https://bsdos.info/OI/Screenshot-2021-01-22-00-12-55.png


I don't think it's a matter of lacking "better SATA support".  Several
Sun servers had the nv_sata chip on board (we have an X2200M2 here), and

I'm actually looking at a Sun Ultra27 as we speak. Anyone here have one?


Solaris and thus illumos-based systems have supported that for a long
time.  It must be some interaction between the installer and your
system.

Do test an OmniOS USB installer, just to see if it can find the disks.

Just as a point of fact;
The Windows, *BSD, Linux, Darwin and (hack)intosh installers all find this
drive. OI can't see it unless it's been installed onto it from another
MB. Then I can plug the drive in, and it boots as tho it had just installed
itself from the install media on this MB. Alto it's clear the BIOS pointed
OI to the drive past POST. But still...

So I find this problem *highly* interesting.

OK I took OmniOS for a spin. Same problem; disk not found. It's clear, the
luminos disk probe routine is broken. I'd love to dig deeper. But can't (as 
yet)

get OI on a disk on this MB. So that's that. I've spent 16hrs on this -- FAR
more than anyone in their right mind would. ;-)
So. Lacking any more options. I'm going to simply use my USB to SATA adapter
and install OI to disk. When completed, I'll simply plug the disk back into
the SATA port on the MB and use OI.

OK the install worked as anticipated over USB-->SATA.
I used the text install. As this will be my initial devbox until I decide
what hardware I want for my real devbox. So I want to pick and choose what
gets installed.

--Chris


I'll keep everyone posted.

Thanks for all the feedback! :-)

--Chris



Regards -- Volker

Thank you very much for taking the time to reply.

--Chris


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] When will AMD XIII CPUs be supported

[Chris]

On 2021-01-22 07:34, Chris wrote:

On 2021-01-22 01:29, v...@bb-c.de wrote:

Hi Chris!


Hang in there!  I'm sure we'll get it to work eventually.


Driver is NOT the problem.
I think the only way I'm going to be able to install OI on this, is
by plugging my sata drive into a USB adapter, and install it there.
Then after installation. Plug the drive back into the sata port on
the MB. I thought OI had better sata support. It clearly understands
the controller.

Well. They say a Picture paints a thousand words:
https://bsdos.info/OI/Screenshot-2021-01-22-00-12-55.png


I don't think it's a matter of lacking "better SATA support".  Several
Sun servers had the nv_sata chip on board (we have an X2200M2 here), and

I'm actually looking at a Sun Ultra27 as we speak. Anyone here have one?


Solaris and thus illumos-based systems have supported that for a long
time.  It must be some interaction between the installer and your
system.

Do test an OmniOS USB installer, just to see if it can find the disks.

Just as a point of fact;
The Windows, *BSD, Linux, Darwin and (hack)intosh installers all find this
drive. OI can't see it unless it's been installed onto it from another
MB. Then I can plug the drive in, and it boots as tho it had just installed
itself from the install media on this MB. Alto it's clear the BIOS pointed
OI to the drive past POST. But still...

So I find this problem *highly* interesting.

OK I took OmniOS for a spin. Same problem; disk not found. It's clear, the
luminos disk probe routine is broken. I'd love to dig deeper. But can't (as 
yet)

get OI on a disk on this MB. So that's that. I've spent 16hrs on this -- FAR
more than anyone in their right mind would. ;-)
So. Lacking any more options. I'm going to simply use my USB to SATA adapter
and install OI to disk. When completed, I'll simply plug the disk back into
the SATA port on the MB and use OI.

I'll keep everyone posted.

Thanks for all the feedback! :-)

--Chris



Regards -- Volker

Thank you very much for taking the time to reply.

--Chris


--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] When will AMD XIII CPUs be supported

[Chris]

On 2021-01-22 01:29, v...@bb-c.de wrote:

Hi Chris!


Hang in there!  I'm sure we'll get it to work eventually.


Driver is NOT the problem.
I think the only way I'm going to be able to install OI on this, is
by plugging my sata drive into a USB adapter, and install it there.
Then after installation. Plug the drive back into the sata port on
the MB. I thought OI had better sata support. It clearly understands
the controller.

Well. They say a Picture paints a thousand words:
https://bsdos.info/OI/Screenshot-2021-01-22-00-12-55.png


I don't think it's a matter of lacking "better SATA support".  Several
Sun servers had the nv_sata chip on board (we have an X2200M2 here), and

I'm actually looking at a Sun Ultra27 as we speak. Anyone here have one?


Solaris and thus illumos-based systems have supported that for a long
time.  It must be some interaction between the installer and your
system.

Do test an OmniOS USB installer, just to see if it can find the disks.

Just as a point of fact;
The Windows, *BSD, Linux, Darwin and (hack)intosh installers all find this
drive. OI can't see it unless it's been installed onto it from another
MB. Then I can plug the drive in, and it boots as tho it had just installed
itself from the install media on this MB. Alto it's clear the BIOS pointed
OI to the drive past POST. But still...

So I find this problem *highly* interesting.



Regards -- Volker

Thank you very much for taking the time to reply.

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] When will AMD XIII CPUs be supported

[Chris]

On 2021-01-21 18:31, Gary Mills wrote:

On Thu, Jan 21, 2021 at 04:10:40PM -0800, Chris wrote:

Thank you *very* much for the reply.
It's an AMD Athlon II X3 @3Ghz w/*Gb RAM
It's on an AM2+ board -- I know. But still...
Anyway.


I used to have one of those.


The failures I indicated here turned out to be a bad PSU.


I've had PSU failures too.


I've since replaced it, and I get to the color Welcome screen.


I assume that's in the loader, after it's booted the copy of OI
that's on the DVD or USB image.


But, a couple things; the (onboard) Nivdia Gigabit port (nge0)
causes OI all kinds of grief -- loop message regarding ipsec, followed
by dhcpd error(s). Finding that, I simply unplugged it, and shoved
an Atheros WiFi card in it.


I've had bad luck with nge devices too, but never that bad.


Restarted the install, and got No disk
drives found. Well, the BIOS finds and confirms it's in good shape.
Will allow me to boot from it. But not OI. Oh it's sata (II). Anyway;
I replace the drive, and boot the OI install. Same problem -- No
drive found.


That sounds like a missing driver for your disk controller.  It will
be included with the full OI kernel, but perhaps not with the loader.
Selecting AHCI mode in the BIOS for the disk controller may fix the
problem.  I notice when I run:

$ prtconf -D

on my system, it shows ahci as the disk controller driver.


OK here's a nice picture (screenshot) I was able to capture that
pretty well sums it up.

Driver is NOT the problem.
I think the only way I'm going to be able to install OI on this, is
by plugging my sata drive into a USB adapter, and install it there.
Then after installation. Plug the drive back into the sata port on
the MB. I thought OI had better sata support. It clearly understands
the controller.

Well. They say a Picture paints a thousand words:
https://bsdos.info/OI/Screenshot-2021-01-22-00-12-55.png

Any hints || suggestions GREATLY appreciated.

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] When will AMD XIII CPUs be supported

[Chris]

On 2021-01-21 13:58, Gary Mills wrote:

On Thu, Jan 21, 2021 at 12:56:51PM -0800, Chris wrote:

Or, why does the 20201031 usb image text install crash
on my AMD XIII @3Ghz && 8GB RAM?


What is AMD XIII?  I have three AMD Ryzen systems.  None of them behave
that way.  This is the one I use most often:

$ psrinfo -vp
The physical processor has 8 cores and 16 virtual processors (0-15)
  ...
x86 (AuthenticAMD 800F82 family 23 model 8 step 2 clock 3200 MHz)
  AMD Ryzen 7 2700 Eight-Core Processor


The install is slow as a dog in graphics or text modes.


That may not be a problem.  After all, you only install once.


It either bootloops just after
zfs0 /pseudo/zfs@0

or it dumps core at the first language choice screen.
Any thoughts/suggestions?


That certainly could be a problem.  Did you capture the core file
or record the traceback?

Couldn't do it. It dumprd abruptly, and immediately rebooted.

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] When will AMD XIII CPUs be supported

[Chris]

On 2021-01-21 16:10, Chris wrote:

On 2021-01-21 13:58, Gary Mills wrote:

On Thu, Jan 21, 2021 at 12:56:51PM -0800, Chris wrote:

Or, why does the 20201031 usb image text install crash
on my AMD XIII @3Ghz && 8GB RAM?


What is AMD XIII?  I have three AMD Ryzen systems.  None of them behave
that way.  This is the one I use most often:

$ psrinfo -vp
The physical processor has 8 cores and 16 virtual processors (0-15)
  ...
x86 (AuthenticAMD 800F82 family 23 model 8 step 2 clock 3200 MHz)
  AMD Ryzen 7 2700 Eight-Core Processor


The install is slow as a dog in graphics or text modes.


That may not be a problem.  After all, you only install once.


It either bootloops just after
zfs0 /pseudo/zfs@0

or it dumps core at the first language choice screen.
Any thoughts/suggestions?


That certainly could be a problem.  Did you capture the core file
or record the traceback?

Thank you *very* much for the reply.
It's an AMD Athlon II X3 @3Ghz w/8Gb RAM
It's on an AM2+ board -- I know. But still...
Anyway. The failures I indicated here turned out to be a bad PSU.
I've since replaced it, and I get to the color Welcome screen.
But, a couple things; the (onboard) Nivdia Gigabit port (nge0)
causes OI all kinds of grief -- loop message regarding ipsec, followed
by dhcpd error(s). Finding that, I simply unplugged it, and shoved
an Atheros WiFi card in it. Restarted the install, and got No disk
drives found. Well, the BIOS finds and confirms it's in good shape.
Will allow me to boot from it. But not OI. Oh it's sata (II). Anyway;
I replace the drive, and boot the OI install. Same problem -- No
drive found.
Sigh...
I'm not here to complain; well maybe a little ;-)
But really. I'd just like to discover *why* the OI install is so
unhappy. Any thoughts || suggestions? It's an Nvidia chipset
(NVIDIA GeForce 6150SE & nForce 430 chipset)
That's about all I think I could add.

Thanks again for taking the time to respond, Gary!

--Chris

Well I found a drive that had OI (illuminos-dde7ba523f) installed
on an old AMD 2 core sempron and plugged it in. It booted it, and
apparently re-configured itself to the (current) hardware.
I just wish I could perform an OI *install* to this. It's clear
that the hardware is supported. I even tried the text || gui install
images that installed what's now running on it. Confusing.

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] When will AMD XIII CPUs be supported

[Chris]

On 2021-01-21 13:58, Gary Mills wrote:

On Thu, Jan 21, 2021 at 12:56:51PM -0800, Chris wrote:

Or, why does the 20201031 usb image text install crash
on my AMD XIII @3Ghz && 8GB RAM?


What is AMD XIII?  I have three AMD Ryzen systems.  None of them behave
that way.  This is the one I use most often:

$ psrinfo -vp
The physical processor has 8 cores and 16 virtual processors (0-15)
  ...
x86 (AuthenticAMD 800F82 family 23 model 8 step 2 clock 3200 MHz)
  AMD Ryzen 7 2700 Eight-Core Processor


The install is slow as a dog in graphics or text modes.


That may not be a problem.  After all, you only install once.


It either bootloops just after
zfs0 /pseudo/zfs@0

or it dumps core at the first language choice screen.
Any thoughts/suggestions?


That certainly could be a problem.  Did you capture the core file
or record the traceback?

Thank you *very* much for the reply.
It's an AMD Athlon II X3 @3Ghz w/*Gb RAM
It's on an AM2+ board -- I know. But still...
Anyway. The failures I indicated here turned out to be a bad PSU.
I've since replaced it, and I get to the color Welcome screen.
But, a couple things; the (onboard) Nivdia Gigabit port (nge0)
causes OI all kinds of grief -- loop message regarding ipsec, followed
by dhcpd error(s). Finding that, I simply unplugged it, and shoved
an Atheros WiFi card in it. Restarted the install, and got No disk
drives found. Well, the BIOS finds and confirms it's in good shape.
Will allow me to boot from it. But not OI. Oh it's sata (II). Anyway;
I replace the drive, and boot the OI install. Same problem -- No
drive found.
Sigh...
I'm not here to complain; well maybe a little ;-)
But really. I'd just like to discover *why* the OI install is so
unhappy. Any thoughts || suggestions? It's an Nvidia chipset
(NVIDIA GeForce 6150SE & nForce 430 chipset)
That's about all I think I could add.

Thanks again for taking the time to respond, Gary!

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

[OpenIndiana-discuss] When will AMD XIII CPUs be supported

[Chris]

Or, why does the 20201031 usb image text install crash
on my AMD XIII @3Ghz && 8GB RAM?
The install is slow as a dog in graphics or text modes.
It either bootloops just after
zfs0 /pseudo/zfs@0

or it dumps core at the first language choice screen.
Any thoughts/suggestions?

Thanks!

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] Is the Atheros AR9462 WiFi card supported?

[Chris]

On 2021-01-20 18:23, John D Groenveld wrote:

In message , Chris writes:

Ive got an Atheros AR9462 WiFi card in my fresh OI install.
Is it supported? If not, is there a driver similar I can hack
on?


No and maybe:
http://pkg.openindiana.org/hipster/manifest/0/driver%2Fnetwork%2Fath%400.5.11%2C5.11-2020.0.1.20243%3A20210120T012047Z>

You'll want to read the illumos DDI/DDK docs:
https://illumos.org/books/wdd/partintro-1.html#partintro-1>

Thanks! Let's see if I can parlay any of my FreeBSD experience into
an OI success. :-)



Happy hacking,
John
groenv...@acm.org


--Chris
--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

[OpenIndiana-discuss] Is the Atheros AR9462 WiFi card supported?

[Chris]

Ive got an Atheros AR9462 WiFi card in my fresh OI install.
Is it supported? If not, is there a driver similar I can hack
on?

Thanks!

--Chris

--
~10yrs a FreeBSD maintainer of ~160 ports
~40yrs of UNIX

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 14:04, Aurélien Larcher wrote:

On Wed, Jan 20, 2021 at 11:00 PM Chris  wrote:


On 2021-01-20 13:32, Aurélien Larcher wrote:
> On Wed, Jan 20, 2021 at 10:19 PM Chris  wrote:
>
>> On 2021-01-20 12:47, Tim Mooney via openindiana-discuss wrote:
>> > In regard to: Re: [OpenIndiana-discuss] distribution constructor for
>> > making...:
>> >
>> >> On 2021-01-20 04:09, Tim Mooney via openindiana-discuss wrote:
>> >>> In regard to: Re: [OpenIndiana-discuss] distribution constructor for
>> >>> making...:
>> >>>
>> >>>> I would love to have XFCE.
>> >>>>
>> >>>> But as I know, the OI devs will not package other DEs. They stay
>> royal to
>> >>>> MATE.
>> >>>>
>> >>>> You can't found any other DE's packages on the repo.
>> >>>
>> >>> You might want to review the mailing list archives for this mailing
>> list
>> >>> to get a clearer understanding of why that is.  It's been discussed
>> >>> before.
>> >>>
>> >>> If you or Chris or someone else builds an entire desktop environment
>> >>> like Cinnamon and publishes a repo that is kept up to date, I would
>> >>> definitely give it a try, at least in a VM.  If someone does this
and
>> >>> keeps it up to date for a long time and continues to contribute to
OI,
>> >>> I would probably use that as my main desktop environment.
>> >>>
>> >>> Just building it once, without a commitment to keeping it updated,
>> isn't
>> >>> good for anyone, though.
>> >> TBH The only reason OI isn't my "daily driver" is the DE available.
If I
>> >> had XFCE (what I currently use), or better, Cinnamon. I'd have a hard
>> time
>> >> not using OI. Overall I like it better. But I'm (currently) pretty
well
>> >> committed to FreeBSD as maintainer of some 160 ports, and I create
>> >> installs for all my servers && clients. I've been on BSD since Bill
Joy
>> >> forked 386BSD, and hacked on various NIX' before that. But if I could
>> >> cobble up an OI I could justify as a "daily driver", and something I
>> could
>> >> recommend to my clients. I'd make the switch.
>> >> Which brings me to why I initiated this thread. Since I need
commitment
>> >> to justfy *my* commitment. I thought I'd send out a "feeler" to see
if
>> >> there was any interest. Appears I'm not the only one. So I'm going to
>> >> "take the plunge". I'll start gathering all the information I need to
>> get
>> >> all the dots in a line, so I can start production. Any pointers to
help
>> >> shorten the trajectory would be *greatly* appreciated. As well as
>> keeping
>> >> the wiki working. ;-)
>> >
>> > I'm indifferent to Xfce, but when you start working on Cinnamon and
deps,
>> > that's something that I would be happy to collaborate on and test.
>> That's my *ideal* target. I really like working in Cinnamon, and want to
>> transform my current workspace from XFCE to Cinnamon. So I'll definitely
>> include you in the loop when I start on it. :-)
>> >  oi-dev and the irc channels are your best source for help on porting,
>> > and I've gotten good feedback in PRs where I've asked questions or
been
>> > stuck part way through updating or porting a package.
>> >
>> > Also, rather than the wiki, I would highly recommend
>> >
>> >   http://docs.openindiana.org/
>> >
>> > and then "HandBook->Building with oi-userland".  That's been migrated
>> from
>> > the old wiki page and updated and had some corrections and a few
>> > clarifications added.  There may still be improvements that could be
>> made,
>> > so the
>> > first few times through the process, please pay special attention
>> > to places where that document misses information or appears incorrect.
>> If
>> > you mention the issues on oi-dev, I'll get PRs submitted (or you can,
>> > if you fork the docs too) to try improve things.
>> In all honesty; OI could *really* use some DOC love --
>> consolidation/updating.
>
> I had a devil of a time discovering where the "truth" was located. It's
>> currently
>> fragmented, and out-of-date -- mind you, I'm not shaking my finger at
>> anyone
>> here.
>> Just sharing my current struggle in this reg

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 13:45, Aurélien Larcher wrote:

On Wed, Jan 20, 2021 at 10:39 PM Chris  wrote:


On 2021-01-20 13:03, Andreas Wacknitz wrote:
> Am 20.01.21 um 21:47 schrieb Tim Mooney via openindiana-discuss:
>> In regard to: Re: [OpenIndiana-discuss] distribution constructor for
>> making...:
>>
>>> On 2021-01-20 04:09, Tim Mooney via openindiana-discuss wrote:
>>>> In regard to: Re: [OpenIndiana-discuss] distribution constructor for
>>>> making...:
>>>>
>>>>> I would love to have XFCE.
>>>>>
>>>>> But as I know, the OI devs will not package other DEs. They stay
>>>>> royal to MATE.
>>>>>
>>>>> You can't found any other DE's packages on the repo.
>>>>
>>>> You might want to review the mailing list archives for this mailing
>>>> list
>>>> to get a clearer understanding of why that is.  It's been discussed
>>>> before.
>>>>
>>>> If you or Chris or someone else builds an entire desktop environment
>>>> like Cinnamon and publishes a repo that is kept up to date, I would
>>>> definitely give it a try, at least in a VM.  If someone does this and
>>>> keeps it up to date for a long time and continues to contribute to OI,
>>>> I would probably use that as my main desktop environment.
>>>>
>>>> Just building it once, without a commitment to keeping it updated,
>>>> isn't
>>>> good for anyone, though.
>>> TBH The only reason OI isn't my "daily driver" is the DE available. If
I
>>> had XFCE (what I currently use), or better, Cinnamon. I'd have a hard
>>> time
>>> not using OI. Overall I like it better. But I'm (currently) pretty well
>>> committed to FreeBSD as maintainer of some 160 ports, and I create
>>> installs for all my servers && clients. I've been on BSD since Bill Joy
>>> forked 386BSD, and hacked on various NIX' before that. But if I could
>>> cobble up an OI I could justify as a "daily driver", and something I
>>> could
>>> recommend to my clients. I'd make the switch.
>>> Which brings me to why I initiated this thread. Since I need commitment
>>> to justfy *my* commitment. I thought I'd send out a "feeler" to see if
>>> there was any interest. Appears I'm not the only one. So I'm going to
>>> "take the plunge". I'll start gathering all the information I need to
>>> get
>>> all the dots in a line, so I can start production. Any pointers to help
>>> shorten the trajectory would be *greatly* appreciated. As well as
>>> keeping
>>> the wiki working. ;-)
>>
>> I'm indifferent to Xfce, but when you start working on Cinnamon and
deps,
>> that's something that I would be happy to collaborate on and test.
>> oi-dev
>> and the irc channels are your best source for help on porting,
I find IRC stressful while I'm working, and somewhat hard to keep up on
(the threads). FreeBSD has a discord channel
(https://discord.com/channels/) -- IRC but also Web && app based. I find
that pretty darn easy to keep up with, and the (web based) UI really
lends itself to getting things done. Oh, and it's free. Works on yer
so-called smart/handheld devices too. :-)



We actually have a Discord channel for OI devs already,

Awesome. :-)

but IRC has been
the primary entry point for newcomers.



>> and I've
>> gotten good feedback in PRs where I've asked questions or been stuck
>> part way through updating or porting a package.
>>
>> Also, rather than the wiki, I would highly recommend
>>
>> http://docs.openindiana.org/
>>
>> and then "HandBook->Building with oi-userland".  That's been migrated
>> from
>> the old wiki page and updated and had some corrections and a few
>> clarifications added.  There may still be improvements that could be
>> made, so the first few times through the process, please pay special
>> attention
>> to places where that document misses information or appears
>> incorrect.  If
>> you mention the issues on oi-dev, I'll get PRs submitted (or you can,
>> if you fork the docs too) to try improve things.
>>
>> Tim
> I will happily merge enhancements to oi-docs.
> And one more thing: We share the Sun Solaris ancestry with Oracle
> Solaris. Some things have diverted during the last decade but the
> solaris-userland
> repository is a first-class source of information and inspiration.
That's a good point, and I considered it. But I was unsure as to the
extent of any divergence.
>
> Andreas
>

--Chris

--

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 13:03, Andreas Wacknitz wrote:

Am 20.01.21 um 21:47 schrieb Tim Mooney via openindiana-discuss:

In regard to: Re: [OpenIndiana-discuss] distribution constructor for
making...:


On 2021-01-20 04:09, Tim Mooney via openindiana-discuss wrote:

In regard to: Re: [OpenIndiana-discuss] distribution constructor for
making...:


I would love to have XFCE.

But as I know, the OI devs will not package other DEs. They stay
royal to MATE.

You can't found any other DE's packages on the repo.


You might want to review the mailing list archives for this mailing
list
to get a clearer understanding of why that is.  It's been discussed
before.

If you or Chris or someone else builds an entire desktop environment
like Cinnamon and publishes a repo that is kept up to date, I would
definitely give it a try, at least in a VM.  If someone does this and
keeps it up to date for a long time and continues to contribute to OI,
I would probably use that as my main desktop environment.

Just building it once, without a commitment to keeping it updated,
isn't
good for anyone, though.

TBH The only reason OI isn't my "daily driver" is the DE available. If I
had XFCE (what I currently use), or better, Cinnamon. I'd have a hard
time
not using OI. Overall I like it better. But I'm (currently) pretty well
committed to FreeBSD as maintainer of some 160 ports, and I create
installs for all my servers && clients. I've been on BSD since Bill Joy
forked 386BSD, and hacked on various NIX' before that. But if I could
cobble up an OI I could justify as a "daily driver", and something I
could
recommend to my clients. I'd make the switch.
Which brings me to why I initiated this thread. Since I need commitment
to justfy *my* commitment. I thought I'd send out a "feeler" to see if
there was any interest. Appears I'm not the only one. So I'm going to
"take the plunge". I'll start gathering all the information I need to
get
all the dots in a line, so I can start production. Any pointers to help
shorten the trajectory would be *greatly* appreciated. As well as
keeping
the wiki working. ;-)


I'm indifferent to Xfce, but when you start working on Cinnamon and deps,
that's something that I would be happy to collaborate on and test. 
oi-dev
and the irc channels are your best source for help on porting,

I find IRC stressful while I'm working, and somewhat hard to keep up on
(the threads). FreeBSD has a discord channel
(https://discord.com/channels/) -- IRC but also Web && app based. I find
that pretty darn easy to keep up with, and the (web based) UI really
lends itself to getting things done. Oh, and it's free. Works on yer
so-called smart/handheld devices too. :-)

and I've gotten good feedback in PRs where I've asked questions or
been stuck part way through updating or porting a package.

Also, rather than the wiki, I would highly recommend

http://docs.openindiana.org/

and then "HandBook->Building with oi-userland".  That's been migrated
from
the old wiki page and updated and had some corrections and a few
clarifications added.  There may still be improvements that could be
made, so the first few times through the process, please pay special
attention
to places where that document misses information or appears
incorrect.  If
you mention the issues on oi-dev, I'll get PRs submitted (or you can,
if you fork the docs too) to try improve things.

Tim

I will happily merge enhancements to oi-docs.
And one more thing: We share the Sun Solaris ancestry with Oracle
Solaris. Some things have diverted during the last decade but the
solaris-userland
repository is a first-class source of information and inspiration.

That's a good point, and I considered it. But I was unsure as to the
extent of any divergence.


Andreas


--Chris

--

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 13:32, Aurélien Larcher wrote:

On Wed, Jan 20, 2021 at 10:19 PM Chris  wrote:


On 2021-01-20 12:47, Tim Mooney via openindiana-discuss wrote:
> In regard to: Re: [OpenIndiana-discuss] distribution constructor for
> making...:
>
>> On 2021-01-20 04:09, Tim Mooney via openindiana-discuss wrote:
>>> In regard to: Re: [OpenIndiana-discuss] distribution constructor for
>>> making...:
>>>
>>>> I would love to have XFCE.
>>>>
>>>> But as I know, the OI devs will not package other DEs. They stay
royal to
>>>> MATE.
>>>>
>>>> You can't found any other DE's packages on the repo.
>>>
>>> You might want to review the mailing list archives for this mailing
list
>>> to get a clearer understanding of why that is.  It's been discussed
>>> before.
>>>
>>> If you or Chris or someone else builds an entire desktop environment
>>> like Cinnamon and publishes a repo that is kept up to date, I would
>>> definitely give it a try, at least in a VM.  If someone does this and
>>> keeps it up to date for a long time and continues to contribute to OI,
>>> I would probably use that as my main desktop environment.
>>>
>>> Just building it once, without a commitment to keeping it updated,
isn't
>>> good for anyone, though.
>> TBH The only reason OI isn't my "daily driver" is the DE available. If I
>> had XFCE (what I currently use), or better, Cinnamon. I'd have a hard
time
>> not using OI. Overall I like it better. But I'm (currently) pretty well
>> committed to FreeBSD as maintainer of some 160 ports, and I create
>> installs for all my servers && clients. I've been on BSD since Bill Joy
>> forked 386BSD, and hacked on various NIX' before that. But if I could
>> cobble up an OI I could justify as a "daily driver", and something I
could
>> recommend to my clients. I'd make the switch.
>> Which brings me to why I initiated this thread. Since I need commitment
>> to justfy *my* commitment. I thought I'd send out a "feeler" to see if
>> there was any interest. Appears I'm not the only one. So I'm going to
>> "take the plunge". I'll start gathering all the information I need to
get
>> all the dots in a line, so I can start production. Any pointers to help
>> shorten the trajectory would be *greatly* appreciated. As well as
keeping
>> the wiki working. ;-)
>
> I'm indifferent to Xfce, but when you start working on Cinnamon and deps,
> that's something that I would be happy to collaborate on and test.
That's my *ideal* target. I really like working in Cinnamon, and want to
transform my current workspace from XFCE to Cinnamon. So I'll definitely
include you in the loop when I start on it. :-)
>  oi-dev and the irc channels are your best source for help on porting,
> and I've gotten good feedback in PRs where I've asked questions or been
> stuck part way through updating or porting a package.
>
> Also, rather than the wiki, I would highly recommend
>
>   http://docs.openindiana.org/
>
> and then "HandBook->Building with oi-userland".  That's been migrated
from
> the old wiki page and updated and had some corrections and a few
> clarifications added.  There may still be improvements that could be
made,
> so the
> first few times through the process, please pay special attention
> to places where that document misses information or appears incorrect.
If
> you mention the issues on oi-dev, I'll get PRs submitted (or you can,
> if you fork the docs too) to try improve things.
In all honesty; OI could *really* use some DOC love --
consolidation/updating.


I had a devil of a time discovering where the "truth" was located. It's

currently
fragmented, and out-of-date -- mind you, I'm not shaking my finger at
anyone
here.
Just sharing my current struggle in this regard. If it were to get
consolidated.


I think many more might feel inclined to get onboard w/OI.




Trouble is that we called for contributions to migrate and enrich the new
documentation but it never gained momentum.

I'd *love* to contribute to the DOCs. But early; while I've still got that
"fresh" look at getting started on IO (development). I think it would lend
itself to conveying the message to the unseasoned as well as the seasoned
(OI) developers.
Now. If I could only find the documentation on how to write/contribute OI
DOCs, so I can start documenting... ;-)

I started writing a maintainer's guide on the Wiki before the migration but
have absolutely zero time to dedicate to its migration to the new doc
system.

Alexander did move some pages to:

https://github.com/OpenIndiana/oi-userland/tree/oi/hipster/doc

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 13:19, Aurélien Larcher wrote:

On Wed, Jan 20, 2021 at 9:47 PM Tim Mooney via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:


In regard to: Re: [OpenIndiana-discuss] distribution constructor for
making...:

> On 2021-01-20 04:09, Tim Mooney via openindiana-discuss wrote:
>> In regard to: Re: [OpenIndiana-discuss] distribution constructor for
>> making...:
>>
>>> I would love to have XFCE.
>>>
>>> But as I know, the OI devs will not package other DEs. They stay royal
to
>>> MATE.
>>>
>>> You can't found any other DE's packages on the repo.
>>
>> You might want to review the mailing list archives for this mailing list
>> to get a clearer understanding of why that is.  It's been discussed
>> before.
>>
>> If you or Chris or someone else builds an entire desktop environment
>> like Cinnamon and publishes a repo that is kept up to date, I would
>> definitely give it a try, at least in a VM.  If someone does this and
>> keeps it up to date for a long time and continues to contribute to OI,
>> I would probably use that as my main desktop environment.
>>
>> Just building it once, without a commitment to keeping it updated, isn't
>> good for anyone, though.
> TBH The only reason OI isn't my "daily driver" is the DE available. If I
> had XFCE (what I currently use), or better, Cinnamon. I'd have a hard
time
> not using OI. Overall I like it better. But I'm (currently) pretty well
> committed to FreeBSD as maintainer of some 160 ports, and I create
> installs for all my servers && clients. I've been on BSD since Bill Joy
> forked 386BSD, and hacked on various NIX' before that. But if I could
> cobble up an OI I could justify as a "daily driver", and something I
could
> recommend to my clients. I'd make the switch.
> Which brings me to why I initiated this thread. Since I need commitment
> to justfy *my* commitment. I thought I'd send out a "feeler" to see if
> there was any interest. Appears I'm not the only one. So I'm going to
> "take the plunge". I'll start gathering all the information I need to get
> all the dots in a line, so I can start production. Any pointers to help
> shorten the trajectory would be *greatly* appreciated. As well as keeping
> the wiki working. ;-)

I'm indifferent to Xfce, but when you start working on Cinnamon and deps,
that's something that I would be happy to collaborate on and test.



Something to keep in mind is that if you focus on another desktop then you
may leave behind features like the Time Slider that we have spent a
ridiculous amount of time porting from Gnome 2 to MATE and then
resynchronizing at each MATE iteration.

Speaking for myself here;
The only real difference here, is gtk2 v gtk3. Granted, gtk3 *sucks* but
trans(lation|ition) isn't terribly bad. I guess my only concern here would
be Python. Any python2 involved with Time Slider? I just got done converting
some 30 (FBSD) ports from py2 to py3. Accept for the py-gtk(2) stuff, I 
didn't
find it terribly difficult. But some of the py-gtk2 stuff required my 
building

shims.
Thanks for pointing that out, Aurélien.





oi-dev
and the irc channels are your best source for help on porting, and I've
gotten good feedback in PRs where I've asked questions or been stuck
part way through updating or porting a package.

Also, rather than the wiki, I would highly recommend

http://docs.openindiana.org/

and then "HandBook->Building with oi-userland".  That's been migrated from
the old wiki page and updated and had some corrections and a few
clarifications added.  There may still be improvements that could be made,
so the first few times through the process, please pay special attention
to places where that document misses information or appears incorrect.  If
you mention the issues on oi-dev, I'll get PRs submitted (or you can,
if you fork the docs too) to try improve things.

Tim
--
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


--Chris

--

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 13:03, Andreas Wacknitz wrote:

Am 20.01.21 um 21:47 schrieb Tim Mooney via openindiana-discuss:

In regard to: Re: [OpenIndiana-discuss] distribution constructor for
making...:


On 2021-01-20 04:09, Tim Mooney via openindiana-discuss wrote:

In regard to: Re: [OpenIndiana-discuss] distribution constructor for
making...:


I would love to have XFCE.

But as I know, the OI devs will not package other DEs. They stay
royal to MATE.

You can't found any other DE's packages on the repo.


You might want to review the mailing list archives for this mailing
list
to get a clearer understanding of why that is.  It's been discussed
before.

If you or Chris or someone else builds an entire desktop environment
like Cinnamon and publishes a repo that is kept up to date, I would
definitely give it a try, at least in a VM.  If someone does this and
keeps it up to date for a long time and continues to contribute to OI,
I would probably use that as my main desktop environment.

Just building it once, without a commitment to keeping it updated,
isn't
good for anyone, though.

TBH The only reason OI isn't my "daily driver" is the DE available. If I
had XFCE (what I currently use), or better, Cinnamon. I'd have a hard
time
not using OI. Overall I like it better. But I'm (currently) pretty well
committed to FreeBSD as maintainer of some 160 ports, and I create
installs for all my servers && clients. I've been on BSD since Bill Joy
forked 386BSD, and hacked on various NIX' before that. But if I could
cobble up an OI I could justify as a "daily driver", and something I
could
recommend to my clients. I'd make the switch.
Which brings me to why I initiated this thread. Since I need commitment
to justfy *my* commitment. I thought I'd send out a "feeler" to see if
there was any interest. Appears I'm not the only one. So I'm going to
"take the plunge". I'll start gathering all the information I need to
get
all the dots in a line, so I can start production. Any pointers to help
shorten the trajectory would be *greatly* appreciated. As well as
keeping
the wiki working. ;-)


I'm indifferent to Xfce, but when you start working on Cinnamon and deps,
that's something that I would be happy to collaborate on and test. 
oi-dev
and the irc channels are your best source for help on porting,

I find IRC stressful while I'm working, and somewhat hard to keep up on
(the threads). FreeBSD has a discord channel
(https://discord.com/channels/) -- IRC but also Web && app based. I find
that pretty darn easy to keep up with, and the (web based) UI really
lends itself to getting things done. Oh, and it's free. Works on yer
so-called smart/handheld devices too. :-)

and I've
gotten good feedback in PRs where I've asked questions or been stuck
part way through updating or porting a package.

Also, rather than the wiki, I would highly recommend

http://docs.openindiana.org/

and then "HandBook->Building with oi-userland".  That's been migrated
from
the old wiki page and updated and had some corrections and a few
clarifications added.  There may still be improvements that could be
made, so the first few times through the process, please pay special
attention
to places where that document misses information or appears
incorrect.  If
you mention the issues on oi-dev, I'll get PRs submitted (or you can,
if you fork the docs too) to try improve things.

Tim

I will happily merge enhancements to oi-docs.
And one more thing: We share the Sun Solaris ancestry with Oracle
Solaris. Some things have diverted during the last decade but the
solaris-userland
repository is a first-class source of information and inspiration.

That's a good point, and I considered it. But I was unsure as to the
extent of any divergence.


Andreas


--Chris

--

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 12:47, Tim Mooney via openindiana-discuss wrote:
In regard to: Re: [OpenIndiana-discuss] distribution constructor for 
making...:



On 2021-01-20 04:09, Tim Mooney via openindiana-discuss wrote:
In regard to: Re: [OpenIndiana-discuss] distribution constructor for 
making...:



I would love to have XFCE.

But as I know, the OI devs will not package other DEs. They stay royal to 
MATE.


You can't found any other DE's packages on the repo.


You might want to review the mailing list archives for this mailing list
to get a clearer understanding of why that is.  It's been discussed
before.

If you or Chris or someone else builds an entire desktop environment
like Cinnamon and publishes a repo that is kept up to date, I would
definitely give it a try, at least in a VM.  If someone does this and
keeps it up to date for a long time and continues to contribute to OI,
I would probably use that as my main desktop environment.

Just building it once, without a commitment to keeping it updated, isn't
good for anyone, though.

TBH The only reason OI isn't my "daily driver" is the DE available. If I
had XFCE (what I currently use), or better, Cinnamon. I'd have a hard time
not using OI. Overall I like it better. But I'm (currently) pretty well
committed to FreeBSD as maintainer of some 160 ports, and I create
installs for all my servers && clients. I've been on BSD since Bill Joy
forked 386BSD, and hacked on various NIX' before that. But if I could
cobble up an OI I could justify as a "daily driver", and something I could
recommend to my clients. I'd make the switch.
Which brings me to why I initiated this thread. Since I need commitment
to justfy *my* commitment. I thought I'd send out a "feeler" to see if
there was any interest. Appears I'm not the only one. So I'm going to
"take the plunge". I'll start gathering all the information I need to get
all the dots in a line, so I can start production. Any pointers to help
shorten the trajectory would be *greatly* appreciated. As well as keeping
the wiki working. ;-)


I'm indifferent to Xfce, but when you start working on Cinnamon and deps,
that's something that I would be happy to collaborate on and test.

That's my *ideal* target. I really like working in Cinnamon, and want to
transform my current workspace from XFCE to Cinnamon. So I'll definitely
include you in the loop when I start on it. :-)

 oi-dev and the irc channels are your best source for help on porting,
and I've gotten good feedback in PRs where I've asked questions or been
stuck part way through updating or porting a package.

Also, rather than the wiki, I would highly recommend

http://docs.openindiana.org/

and then "HandBook->Building with oi-userland".  That's been migrated from
the old wiki page and updated and had some corrections and a few
clarifications added.  There may still be improvements that could be made, 
so the

first few times through the process, please pay special attention
to places where that document misses information or appears incorrect.  If
you mention the issues on oi-dev, I'll get PRs submitted (or you can,
if you fork the docs too) to try improve things.
In all honesty; OI could *really* use some DOC love -- 
consolidation/updating.
I had a devil of a time discovering where the "truth" was located. It's 
currently
fragmented, and out-of-date -- mind you, I'm not shaking my finger at anyone 
here.
Just sharing my current struggle in this regard. If it were to get 
consolidated

I think many more might feel inclined to get onboard w/OI.
I'm currently using: https://github.com/OpenIndiana/oi-userland as my source 
of
truth. Having been a (ports/package) maintainer on FreeBSD for some 10yrs. 
I'm
finding it enough to read the shell framework to get up to speed. My only 
*personal*
nit; is that it's largely bash(1) based. Maybe it's because I'm more used to 
sh(1).
But I find bash to be a bit of a pig, by comparison. But I can get used to it 
-- or

just rewrite all of it in sh(1). ;-)

Tim, thank you *very* much for all the pointers, and support! :-)
We'll be talking Cinnamon, real soon now. ;-)

--Chris


Tim


--

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

Re: [OpenIndiana-discuss] Shell to use?

[Chris]

On 2021-01-20 09:33, Bob Friesenhahn wrote:

On Wed, 20 Jan 2021, Chris wrote:


Please do a little investigation before you post and don't let your plain 
hatred

for someone to ruin your investigation.

I didn't asked to add any Linux shell at all. Please keep that in mind.
I might suggest you try the default (Free)BSD shell; t/csh. While FreeSBD 
calls it
csh, the differences really only appear in their name. I do the following 
on


To clarify, the personal login shell that a user choses has nothing to do 
with the
shell which is normally used when building software. So changing the login 
shell

will not change the software build performance.

The tcsh shell is great for interactive use but few scripts are written 
using its

syntax any more.

For purposes of Autoconf (popular 'configure' scripts), the shell to may be
specified by the CONFIG_SHELL environment variable or configure command 
argument.

For example:

  CONFIG_SHELL=/usr/bin/ksh ./configure 

  ./configure CONFIG_SHELL=/usr/bin/ksh ...

Changing the SHELL environment variable itself may also cause a change to
execution since it influences the default shell that the system uses which
invoking a command (e.g. using system()) which uses the shell.

I *totally* agree. I guessed when it was mentioned that "looking for..."
took forever. That it would be (gnu|auto)conf. Which spawn all kinds of 
queries:

cc -V && awk '{print $...
While /bin/sh seems to be the one I most encounter, complex bash scripts are 
the
other, and mostly because the scripts/source originated from a Linux 
developer.
Whom is most acquainted with bash, as it's their default shell. So the 
question

*really* becomes; why the difference on OI?

I'm going to be doing a great deal of building today. So hope to gain some 
insight

during the process.

--Chris


Bob


--

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

Re: [OpenIndiana-discuss] Shell to use?

[Chris]

On 2021-01-20 08:37, Bob Friesenhahn wrote:

On Wed, 20 Jan 2021, Hung Nguyen Gia via openindiana-discuss wrote:

Regardless of it's good behavior or not, this does give Linux a huge 
advantage over us.

The different is significant.
If we want to continue to keep our Solaris heritage and continue to 
ridicule Linux, then OK, it's fine.


I did not see anyone here "ridiculing" Linux.  Different decisions were made 
based
on the target market.  Solaris made decisions with a priority on robustness 
and

Linux made decisions with a priority to run on cheap hardware.

I use Linux on tiny hardware where there is tremendous memory over-commit 
(as much
as 120x) and it is a wonder that apps run at all (sometimes they run 
exceedingly

slowly).  It is nice that this is possible to do.

It is possible to disable over-commit in Linux but then even many desktop 
systems

would not succeed with initializing at all.

Memory allocation via mmap() is useful but there is a decision point as to 
whether
to allocate backing storage in the swap space or not. By default allocated 
pages
are zero and actual memory is not used until something writes data to the 
page (at
which point in time there is a "page fault" and the kernel allocates a real 
memory
page and initializes it with zeroed bytes).  Likewise memory which is 
"duplicated"
by fork() and its COW principle is not used until it has been modified.  So 
Linux
(by default) is very optimistic and assumes that the app will not actually 
use the

memory it requested, or might not ever modify memory inherited by the forked
process.

If one is running a large database server or critical large apps then 
relying on

over-commit is not helpful since once the system even slightly runs out of
resources, either an app, or the whole system needs to die.

IBM's AIX was the earliest system I recall where over-commit was common and
processes were scored based on memory usage.  When the system ran short of 
memory

it would usually kill the largest process.

Linux has followed this same strategy and computes an OOM score for each 
process.
When the system runs out of "already" allocated memory, then a process has 
to die,
or the system needs to panic and reboot, or new activities must be 
disallowed.
Another difference with Linux, at least as compared to FreeBSD; is that Linux 
favors
disk backing. IOW they'd rather keep RAM free. Whereas the BSDs would rather 
use RAM.
Granted, ZFS brings COW which helps. But when given a choice, why not choose 
RAM over

disk? It's *much* faster.

--Chris


Bob


--

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

Re: [OpenIndiana-discuss] Shell to use?

[Chris]

On 2021-01-20 04:57, Hung Nguyen Gia via openindiana-discuss wrote:
I will took me hours to write a very long mail to answer each of your 
points.


So I will give you a short summary: I have tried it on both physical machine 
and
virtual machine, my graphics performance is good on the physical machine, I 
could
watch 4K video without much tearing. I would say it's slow in any 
circumstances.

Not only the output printing is slow. I really measured the time it took to
complete the jobs to do comparison.

Hater gonna hate. I know you hate me. So I don't mind.

The fact is both Linux and OI are using bash as their default login shell 
for user, though.


Please do a little investigation before you post and don't let your plain 
hatred

for someone to ruin your investigation.

I didn't asked to add any Linux shell at all. Please keep that in mind.
I might suggest you try the default (Free)BSD shell; t/csh. While FreeSBD 
calls it
csh, the differences really only appear in their name. I do the following on 
all

my fresh OI installs;
usermod -s /usr/bin/tcsh 
The same thing can be accomplished with root, only the command is
rolemod -s /usr/bin/tcsh root
The downside is that OI doesn't create a dot file for (t)csh. So if you want 
to
tweak your PS1 && environment. You'll want to snag one off a BSD, or use one 
you
already have somewhere. Also, I'm *not* suggesting you didn't already know 
how to

do this. Just sayin' what *I* did. :-)
If it makes a difference. You're done. :-) If not. hmm...
I'm going to be doing a lot of building today. So I'll get a better chance to 
see
if I experience what you're talking about. If I do, and find a solution. I'll 
post it.


--Chris out...


 On Wed, 20 Jan 2021 01:40:13 +0700 Araragi Hokuto 


wrote 

 > From my experience, the shell's performance hardly makes large
 > difference, because the shell itself is *not* that different (that is,
 > if there's a difference in the first place: most *nix I've ever seen
 > ships with the same set of shells).
 >
 > Given that you are stating the output printing is slow, I would like to
 > confirm your display setting first:
 >
 > 1) Are you running OI inside a vm, or are you running it on real
 > hardwares? If later, can you provide the specs of hardware in use?
 >
 > 2) What interface are you using, video console, terminal emulator under
 > X, or something else (through ssh, etc)?
 >
 >  a) If using video console, are you using VGA text console, or BIOS
 > graphical console, or UEFI console? All three of them have significant
 > performance difference on my hardware.
 >
 >  b) If using X, what video driver are you using? Look into your Xorg
 > log if you are not sure.
 >
 >  c) If its something else, priovide more infomation so we can look
 > into it.
 >
 > I would at least confirm the problem really lies inside shell before
 > asking maintainers to update it, and I would *NEVER* send out a mail
 > with something like "OI is too slow for me so GO GET LINUX'S SHELL AT
 > ONCE". Don't blame Google translator for it; we can tell the difference
 > bewteen poor translation and true disrespect, and disrespectful mail
 > calls for disrespectful replies.
 >
 > On 1/20/21 12:46 AM, Hung Nguyen Gia via openindiana-discuss wrote:
 > > What is profiled?
 > >
 > > I don't think it's gmake at all.
 > >
 > > How could you explain the slowness when it 'Checking for...' something?
 > >
 > > This stage is plain configure script, gmake is not yet invoked.
 > >
 > >
 > >
 > >
 > >  On Tue, 19 Jan 2021 23:38:21 +0700 Aurélien Larcher
 wrote 
 > >
 > >   > On Tue, Jan 19, 2021 at 5:20 PM Hung Nguyen Gia via 
openindiana-discuss <

 > >   > openindiana-discuss@openindiana.org> wrote:
 > >   >
 > >   > > Everything on OI is too slow, so I decided to go another route.
 > >   > >
 > >   > > I tried with bash as default shell on FreeBSD and the result is 
the same.

 > >   > >
 > >   > > Also tried on Debian 10 with export SH=/bin/bash, it's pretty 
much as fast

 > >   > > as on FreeBSD if not to say faster.
 > >   > >
 > >   > > Bash maybe not the problem.
 > >   > >
 > >   >
 > >   > Have you profiled gnu make?
 > >   >
 > >   > >
 > >   > >
 > >   > >
 > >   > >
 > >   > >  On Tue, 19 Jan 2021 12:38:28 +0700 edward 


 > >   > > wrote 
 > >   > >
 > >   > >  >
 > >   > >  > On 1/18/21 8:27 PM, Hung Nguyen Gia via openindiana-discuss 
wrote:
 > >   > >  > > The output printed on the screen 'Checking for...' is line 
by line,
 > >   > > very slow. Meanwhile, the same thing on FreeBSD is blazing fast 
that I

 > >   > > can't even see what's going on at all.
 > >   > >  >
 > >   > >  > suggest to try the same type of shell freebsd uses?
 > >   > >  >
 > >   >
 > >   >
 > >   > --
 > >   > ---
 > >   > Praise the Caffeine embeddings


--

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 04:10, Stephan Althaus wrote:

Hello!

Please keep in mind, that almost every Linux distro has much more manpower 
to

maintain those many packages and DEs.

If you volunteer to maintain an other DE for OI  i doubt that this would be 
a

problem for our OI first-level maintainers.

Maybe a good starting point for XFCE would be Joyent's pkgsrc packages
https://pkgsrc.joyent.com/install-on-illumos/
https://pkgsrc.joyent.com/packages/SmartOS/2020Q4/x86_64/All/

you can get binary packages there i you want to try things out first.
There have to be patches reay to compile for illumos distros
so the first step would be starting to translate the pkgsrc package to a
OI-userland component, starting from the first missing dependancy of 
xfce4...


Have fun!

Thank you *very* much for the links/pointers, Stephan!
That should help. The hardest part of "maintaining" are the initial steps.
Keeping them going isn't *nearly* as much time/effort. Looks like you've
saved me a little up-front.

Thanks. :-)

--Chris

On an aside; why is most everyone on this list so inclined to "top post"?
It really buggers up the mailing list archives -- breaks all the threads.
Everyone looks like their talking to *themselves*. :-)


Greetings,
Stephan


On 01/20/21 12:51, Hung Nguyen Gia via openindiana-discuss wrote:

I would love to have XFCE.

But as I know, the OI devs will not package other DEs. They stay royal to 
MATE.


You can't found any other DE's packages on the repo.

There are packages for many window manager, though.

You have to do pretty much anything yourself, with your own repo publisher.

BTW, at least I know XFCE is possible on Illumos. Tribblix's default 
desktop is XFCE.


I don't have much hope about Cinnamon. But if you can bring it up, I would 
love to have it, too.





 On Wed, 20 Jan 2021 13:55:13 +0700 Chris  wrote 

  > Well I was finally able to get OI on one of my spares.
  > I wanted to do so, so that I could start adding/upgrading
  > some OI packages. As I began looking at the process I
  > stumbled on distribution-constructor and thought; why
  > not build up some additional desktop installs. I had
  > intended to build both the Xfce4 and Cinnamon desktop
  > packages anyway. So why not ask to see if the any
  > OI users/developers/caretakers would be interested in
  > providing xfce4 or cinnamon desktop ISO and USB images.
  > Would something like this be of any interest?
  > If so. I'll start building all the necessary bits straight
  > away.
  >
  > Thanks for your feedback.
  >
  > --Chris

--

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 04:09, Tim Mooney via openindiana-discuss wrote:
In regard to: Re: [OpenIndiana-discuss] distribution constructor for 
making...:



I would love to have XFCE.

But as I know, the OI devs will not package other DEs. They stay royal to 
MATE.


You can't found any other DE's packages on the repo.


You might want to review the mailing list archives for this mailing list
to get a clearer understanding of why that is.  It's been discussed
before.

If you or Chris or someone else builds an entire desktop environment
like Cinnamon and publishes a repo that is kept up to date, I would
definitely give it a try, at least in a VM.  If someone does this and
keeps it up to date for a long time and continues to contribute to OI,
I would probably use that as my main desktop environment.

Just building it once, without a commitment to keeping it updated, isn't
good for anyone, though.

TBH The only reason OI isn't my "daily driver" is the DE available. If I
had XFCE (what I currently use), or better, Cinnamon. I'd have a hard time
not using OI. Overall I like it better. But I'm (currently) pretty well
committed to FreeBSD as maintainer of some 160 ports, and I create
installs for all my servers && clients. I've been on BSD since Bill Joy
forked 386BSD, and hacked on various NIX' before that. But if I could
cobble up an OI I could justify as a "daily driver", and something I could
recommend to my clients. I'd make the switch.
Which brings me to why I initiated this thread. Since I need commitment
to justfy *my* commitment. I thought I'd send out a "feeler" to see if
there was any interest. Appears I'm not the only one. So I'm going to
"take the plunge". I'll start gathering all the information I need to get
all the dots in a line, so I can start production. Any pointers to help
shorten the trajectory would be *greatly* appreciated. As well as keeping
the wiki working. ;-)

Thanks for the feedback!

--Chris
P.S. To be clear. I don't want to create an OI "fork". I intend to keep
this inline w/OI. IOW It *is* OI, but with a different, or more DE choice(s).



Tim


There are packages for many window manager, though.

You have to do pretty much anything yourself, with your own repo publisher.

BTW, at least I know XFCE is possible on Illumos. Tribblix's default 
desktop is XFCE.


I don't have much hope about Cinnamon. But if you can bring it up, I would 
love to have it, too.





 On Wed, 20 Jan 2021 13:55:13 +0700 Chris  wrote 

> Well I was finally able to get OI on one of my spares.
> I wanted to do so, so that I could start adding/upgrading
> some OI packages. As I began looking at the process I
> stumbled on distribution-constructor and thought; why
> not build up some additional desktop installs. I had
> intended to build both the Xfce4 and Cinnamon desktop
> packages anyway. So why not ask to see if the any
> OI users/developers/caretakers would be interested in
> providing xfce4 or cinnamon desktop ISO and USB images.
> Would something like this be of any interest?
> If so. I'll start building all the necessary bits straight
> away.
>
> Thanks for your feedback.
>
> --Chris
> --
>


--

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 04:01, Aurélien Larcher wrote:

On Wednesday, January 20, 2021, Hung Nguyen Gia via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

I would love to have XFCE.

But as I know, the OI devs will not package other DEs. They stay royal to

MATE.


You can't found any other DE's packages on the repo.

There are packages for many window manager, though.

You have to do pretty much anything yourself, with your own repo

publisher.


BTW, at least I know XFCE is possible on Illumos. Tribblix's default

desktop is XFCE.


I don't have much hope about Cinnamon. But if you can bring it up, I

would love to have it, too.

Hello,
it is not really about being loyal to MATE but commiting to maintain the
packages.

When swithing to gcc 10 I had to patch a few dozen packages that I do not
use or maintain but the original maintainer had no time or interest to fix
it.

We want to avoid situations were large pieces of software are added then
left to rot.

This is unfortunately the case for some important packahes due to recent
circumstances that have reduced our number of maintainers drastically.

There is not strong opinion against packages in general, just a question of
commitment to maintain them.

Right. It's the same on FreeBSD for which I've been a maintainer for some
10yrs, and rightly so. It's additional overhead to manage source/packages.
Even when they go un(used|maintained). So a commitment should/needs to be
established.



XFCE would be nice indeed, I packaged it back in OpenSolaris days :)

I'll get started today. :-)

--Chris


Cheers,

Aurélien





 On Wed, 20 Jan 2021 13:55:13 +0700 Chris  wrote




 > Well I was finally able to get OI on one of my spares.
 > I wanted to do so, so that I could start adding/upgrading
 > some OI packages. As I began looking at the process I
 > stumbled on distribution-constructor and thought; why
 > not build up some additional desktop installs. I had
 > intended to build both the Xfce4 and Cinnamon desktop
 > packages anyway. So why not ask to see if the any
 > OI users/developers/caretakers would be interested in
 > providing xfce4 or cinnamon desktop ISO and USB images.
 > Would something like this be of any interest?
 > If so. I'll start building all the necessary bits straight
 > away.
 >
 > Thanks for your feedback.
 >
 > --Chris


--

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 03:55, Hung Nguyen Gia wrote:

 On Wed, 20 Jan 2021 14:46:30 +0700 Chris  wrote 

 > On 2021-01-19 22:58, Judah Richardson wrote:
 > > On Wed, Jan 20, 2021 at 12:55 AM Chris  wrote:
 > >
 > >> Well I was finally able to get OI on one of my spares.
 > >> I wanted to do so, so that I could start adding/upgrading
 > >> some OI packages. As I began looking at the process I
 > >> stumbled on distribution-constructor and thought; why
 > >> not build up some additional desktop installs. I had
 > >> intended to build both the Xfce4 and Cinnamon desktop
 > >> packages anyway. So why not ask to see if the any
 > >> OI users/developers/caretakers would be interested in
 > >> providing xfce4 or cinnamon desktop ISO and USB images.
 > >> Would something like this be of any interest?
 > >> If so. I'll start building all the necessary bits straight
 > >> away.
 > >>
 > >> Thanks for your feedback.
 > >>
 > > Hi Chris,
 > >
 > > I'd be most interested in OI KDE spins.
 > Thanks for your feedback, Judah.
 > I'd probably be up for that. But as I haven't touched KDE in at
 > least a year. I may be slower than you'd wish. Still, I'll
 > make a go of it. :-)
 > I'll likely have an Xfce4 before that. As I'm already well familiar
 > building it.
 >
 > Thanks again!
 > >
If you could please have a look at the Trinity DE, too. It's KDE3 indeed.

https://www.trinitydesktop.org/

It advertised that it support Linux, FreeBSD and DilOS.

DilOS is just another Illumos distro and I confirm that there are tde's 
packages on DilOS.


The sad thing is I can't really get them to install because of umet 
dependencies.

Thanks for the pointer! That should really give me a "leg up" on development.
As many of the depends will already be sorted. I'll only need to sort the
differences between OI and theirs.

--Chris
--

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 03:51, Hung Nguyen Gia wrote:

 On Wed, 20 Jan 2021 13:55:13 +0700 Chris  wrote 

 > Well I was finally able to get OI on one of my spares.
 > I wanted to do so, so that I could start adding/upgrading
 > some OI packages. As I began looking at the process I
 > stumbled on distribution-constructor and thought; why
 > not build up some additional desktop installs. I had
 > intended to build both the Xfce4 and Cinnamon desktop
 > packages anyway. So why not ask to see if the any
 > OI users/developers/caretakers would be interested in
 > providing xfce4 or cinnamon desktop ISO and USB images.
 > Would something like this be of any interest?
 > If so. I'll start building all the necessary bits straight
 > away.
I would love to have XFCE.

But as I know, the OI devs will not package other DEs. They stay royal to 
MATE.


You can't found any other DE's packages on the repo.

There are packages for many window manager, though.

You have to do pretty much anything yourself, with your own repo publisher.

BTW, at least I know XFCE is possible on Illumos. Tribblix's default desktop 
is XFCE.


I don't have much hope about Cinnamon. But if you can bring it up, I would 
love to

have it, too.
Yes. Cinnamon will be more of a challenge. But I rather like it. So I wanted 
to
give it a go. I'm big on Xfce because it seems smaller and more convenient to 
use.
IDK about packaging other DEs. But I'm going to produce them. So maybe if 
they

are popular. They become part of the fold. Who knows. :-)

Thanks for the feedback!

--Chris

 >


--

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-20 00:28, Stephan Althaus wrote:

On 01/20/21 08:46, Chris wrote:

On 2021-01-19 22:58, Judah Richardson wrote:

On Wed, Jan 20, 2021 at 12:55 AM Chris  wrote:


Well I was finally able to get OI on one of my spares.
I wanted to do so, so that I could start adding/upgrading
some OI packages. As I began looking at the process I
stumbled on distribution-constructor and thought; why
not build up some additional desktop installs. I had
intended to build both the Xfce4 and Cinnamon desktop
packages anyway. So why not ask to see if the any
OI users/developers/caretakers would be interested in
providing xfce4 or cinnamon desktop ISO and USB images.
Would something like this be of any interest?
If so. I'll start building all the necessary bits straight
away.

Thanks for your feedback.


Hi Chris,

I'd be most interested in OI KDE spins.

Thanks for your feedback, Judah.
I'd probably be up for that. But as I haven't touched KDE in at
least a year. I may be slower than you'd wish. Still, I'll
make a go of it. :-)
I'll likely have an Xfce4 before that. As I'm already well familiar
building it.

Hello Chris!

Hello, Stephan!
Thanks for the pointer. I remember there having been one. But I didn't
run across it in all my recent reading on the OI web site.

Thank you! :-)

--Chris


Just in the rare case you did't know it yet,
there's joyent pkgsrc where a hole lot of packages are patched to build on 
Illumos

derivates.
At least worth to have look at in case of 'problems'.

https://pkgsrc.joyent.com/

Greetings,
Stephan




Thanks again!


Judah


 --Chris


--
~40yrs of UNIX and counting

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

Re: [OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

On 2021-01-19 22:58, Judah Richardson wrote:

On Wed, Jan 20, 2021 at 12:55 AM Chris  wrote:


Well I was finally able to get OI on one of my spares.
I wanted to do so, so that I could start adding/upgrading
some OI packages. As I began looking at the process I
stumbled on distribution-constructor and thought; why
not build up some additional desktop installs. I had
intended to build both the Xfce4 and Cinnamon desktop
packages anyway. So why not ask to see if the any
OI users/developers/caretakers would be interested in
providing xfce4 or cinnamon desktop ISO and USB images.
Would something like this be of any interest?
If so. I'll start building all the necessary bits straight
away.

Thanks for your feedback.


Hi Chris,

I'd be most interested in OI KDE spins.

Thanks for your feedback, Judah.
I'd probably be up for that. But as I haven't touched KDE in at
least a year. I may be slower than you'd wish. Still, I'll
make a go of it. :-)
I'll likely have an Xfce4 before that. As I'm already well familiar
building it.

Thanks again!


Judah


 --Chris

--



--

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

[OpenIndiana-discuss] distribution constructor for making OI spins?

[Chris]

Well I was finally able to get OI on one of my spares.
I wanted to do so, so that I could start adding/upgrading
some OI packages. As I began looking at the process I
stumbled on distribution-constructor and thought; why
not build up some additional desktop installs. I had
intended to build both the Xfce4 and Cinnamon desktop
packages anyway. So why not ask to see if the any
OI users/developers/caretakers would be interested in
providing xfce4 or cinnamon desktop ISO and USB images.
Would something like this be of any interest?
If so. I'll start building all the necessary bits straight
away.

Thanks for your feedback.

--Chris
--

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

Re: [OpenIndiana-discuss] what command is used to start MATE?

[Chris]

On 2021-01-19 22:06, Tim Mooney via openindiana-discuss wrote:

In regard to: Re: [OpenIndiana-discuss] what command is used to start...:


IMHO it is *not* the role of an OS to determine the security policy.


While it should be possible for an admin to set security policy,
the OS should have good, secure defaults.  That's all this is.

Yes. Accidental foot shooting should me minimized. :-)


Tim

--Chris

--

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

[OpenIndiana-discuss] wiki has been dead all day

[Chris]

Like the subject says. :-)

Just thought I'd mention it. As I've been directed there
by my searched for information. But the wiki times out with
a 503.

Thanks! :-)


--

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