Re: [OpenIndiana-discuss] problem adding a mirror disk to rpool

[Reginald Beardsley via openindiana-discuss]

 Partition the disk so you have a partition that matches the size of your other 
disks in the pool. Then mount that partition.


 On Monday, January 2, 2023, 08:31:38 PM CST, Marc Lobelle 
 wrote:  
 
 Hello,

First, Best wished for 2023 to everybody !

I tried to add a second 480Gb disk to my rpool (different manufacturer 
and slightly larger)

Below is what I did, but apparently there is a problem and the case 
(adding a mirror disk) is not discussed in 
https://illumos.org/msg/ZFS-8000-4J/

Anybody has an idea on how to solve this issue ? I did not yet 
installgrub on the new disk because I fear it would make things worse.

Thanks

Marc

ml@spitfire:/home/ml# zpool status rpool
   pool: rpool
  state: ONLINE
   scan: scrub repaired 0 in 0 days 00:05:41 with 0 errors on Wed Dec 28 
16:43:12 2022
config:

     NAME    STATE READ WRITE CKSUM
     rpool   ONLINE   0 0 0
   c7d0s0    ONLINE   0 0 0

errors: No known data errors
ml@spitfire:/home/ml# format
Searching for disks...done


AVAILABLE DISK SELECTIONS:
    0. c5d0 
   /pci@0,0/pci-ide@1f,2/ide@0/cmdk@0,0
    1. c6d0 
   /pci@0,0/pci-ide@1f,2/ide@1/cmdk@0,0
    2. c7d0 
   /pci@0,0/pci-ide@1f,5/ide@0/cmdk@0,0
    3. c8d0 
   /pci@0,0/pci-ide@1f,5/ide@1/cmdk@0,0
Specify disk (enter its number): ^C
ml@spitfire:/home/ml# prtvtoc /dev/rdsk/c7d0s0
* /dev/rdsk/c7d0s0 partition map
*
* Dimensions:
* 512 bytes/sector
*  63 sectors/track
* 255 tracks/cylinder
*   16065 sectors/cylinder
*   58368 cylinders
*   58366 accessible cylinders
*   937681920 sectors
*   937649790 accessible sectors
*
* Flags:
*   1: unmountable
*  10: read-only
*
* Unallocated space:
* First   Sector  Last
* Sector   Count  Sector
* 0   16065   16064
*
*    First   Sector  Last
* Partition  Tag  Flags  Sector   Count  Sector  Mount Directory
    0  2    00    16065   937633725   937649789
    2  5    01    0   937649790   937649789
    8  1    01    0   16065   16064
ml@spitfire:/home/ml# prtvtoc /dev/rdsk/c7d0s0|fmthard -s - /dev/rdsk/c8d0s0
fmthard: Partition 2 specifies the full disk and is not equal
full size of disk.  The full disk capacity is 937665855 sectors.
fmthard:  New volume table of contents now in place.
ml@spitfire:/home/ml# zpool attach -f rpool c7d0s0 c8d0s0
Make sure to wait until resilver is done before rebooting.
ml@spitfire:/home/ml# zpool status rpool
   pool: rpool
  state: ONLINE
status: One or more devices is currently being resilvered.  The pool will
     continue to function, possibly in a degraded state.
action: Wait for the resilver to complete.
   scan: resilver in progress since Mon Jan  2 11:59:05 2023
     56,4G scanned at 2,56G/s, 909M issued at 41,3M/s, 56,4G total
     910M resilvered, 1,57% done, 0 days 00:22:55 to go
config:

     NAME    STATE READ WRITE CKSUM
     rpool   ONLINE   0 0 0
   mirror-0  ONLINE   0 0 0
     c7d0s0  ONLINE   0 0 0
     c8d0s0  ONLINE   0 0 0  (resilvering)

errors: No known data errors
ml@spitfire:/home/ml# zpool status rpool
   pool: rpool
  state: DEGRADED
status: One or more devices could not be used because the label is 
missing or
     invalid.  Sufficient replicas exist for the pool to continue
     functioning in a degraded state.
action: Replace the device using 'zpool replace'.
    see: http://illumos.org/msg/ZFS-8000-4J
   scan: resilvered 34,6G in 0 days 00:06:23 with 0 errors on Mon Jan  2 
12:05:28 2023
config:

     NAME    STATE READ WRITE CKSUM
     rpool   DEGRADED 0 0 0
   mirror-0  DEGRADED 0 0 0
     c7d0s0  ONLINE   0 0 0
     c8d0s0  UNAVAIL  0 57,4K 0  corrupted data

errors: No known data errors
ml@spitfire:/home/ml#


___
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] Any reasons tree /export/home/USERS shouldn't be moved to a different pool

[Reginald Beardsley via openindiana-discuss]

 Absolutely none. I have all of /export in epool.

The default configuration produced by the installer is intended to keep new 
users out of trouble.

It's a tad aggressive about that and can cause an experienced user some 
annoyance.

I allocate space for the root pool based on the expectation of a number of 
updates. I put the non-system files in epool so they are safe from issues with 
the root pool.

Have Fun!
Reg


 On Wednesday, January 12, 2022, 08:37:02 PM CST, hput via 
openindiana-discuss  wrote:  
 
 Are there any reasons the hierarchy /export/home/USERS should not be
moved to a different pool?  I can think of a few reasons why /root
should be on rpool.  But USER homes are kind of likely to, over time,
accumulate quite a lot of data might and eventually squeeze rpool.




___
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] CDE...

[Reginald Beardsley via openindiana-discuss]

 I figured out how it worked so I could run twm instead.

I can't think of a piece of software I hated more than Motif.


 On Sunday, December 19, 2021, 07:13:25 PM CST, Judah Richardson 
 wrote:  
 
 I remember using this on Sun workstations in college back when I was
learning Fortran. My favorite thing about the DE is I couldn't figure out
how it worked ;) (No, really.)

The more options the better :)

On Sun, Dec 19, 2021 at 12:43 PM Apostolos Syropoulos via
openindiana-discuss  wrote:

> Maybe some people are missing it.
>
> https://github.com/NsCDE/NsCDE
> --Apostolos Syropoulos
> Xanthi, Greece
>
>
>
> ___
> 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
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] Why are DOS executables being installed?

[Reginald Beardsley via openindiana-discuss]

I'm working on system image audit tools and found these in 2021.04.30:

/usr/lib/python3.5/distutils/command/wininst-9.0-amd64.exe: DOS executable 
(EXE)
/usr/lib/python3.5/distutils/command/wininst-9.0.exe:   DOS executable (EXE)
/usr/lib/python3.5/distutils/command/wininst-8.0.exe:   DOS executable (EXE)
/usr/lib/python3.5/distutils/command/wininst-14.0.exe:  DOS executable (EXE)
/usr/lib/python3.5/distutils/command/wininst-6.0.exe:   DOS executable (EXE)
/usr/lib/python3.5/distutils/command/wininst-10.0-amd64.exe:DOS executable 
(EXE)
/usr/lib/python3.5/distutils/command/wininst-10.0.exe:  DOS executable (EXE)
/usr/lib/python3.5/distutils/command/wininst-14.0-amd64.exe:DOS executable 
(EXE)
/usr/lib/python3.5/vendor-packages/pip/_vendor/distlib/t32.exe: DOS executable 
(EXE)
/usr/lib/python3.5/vendor-packages/pip/_vendor/distlib/t64.exe: DOS executable 
(EXE)
/usr/lib/python3.5/vendor-packages/pip/_vendor/distlib/w64.exe: DOS executable 
(EXE)
/usr/lib/python3.5/vendor-packages/pip/_vendor/distlib/w32.exe: DOS executable 
(EXE)
/usr/lib/python3.5/vendor-packages/setuptools/gui.exe:  DOS executable (EXE)
/usr/lib/python3.5/vendor-packages/setuptools/gui-32.exe:   DOS executable 
(EXE)
/usr/lib/python3.5/vendor-packages/setuptools/gui-64.exe:   DOS executable 
(EXE)
/usr/lib/python2.7/vendor-packages/setuptools/gui.exe:  DOS executable (EXE)
/usr/lib/python2.7/vendor-packages/setuptools/gui-64.exe:   DOS executable 
(EXE)
/usr/lib/python2.7/vendor-packages/setuptools/gui-32.exe:   DOS executable 
(EXE)
/usr/lib/python2.7/vendor-packages/pip/_vendor/distlib/t32.exe: DOS executable 
(EXE)
/usr/lib/python2.7/vendor-packages/pip/_vendor/distlib/t64.exe: DOS executable 
(EXE)
/usr/lib/python2.7/vendor-packages/pip/_vendor/distlib/w64.exe: DOS executable 
(EXE)
/usr/lib/python2.7/vendor-packages/pip/_vendor/distlib/w32.exe: DOS executable 
(EXE)
/usr/lib/python2.7/distutils/command/wininst-6.0.exe:   DOS executable (EXE)
/usr/lib/python2.7/distutils/command/wininst-8.0.exe:   DOS executable (EXE)
/usr/lib/python2.7/distutils/command/wininst-9.0-amd64.exe: DOS executable 
(EXE)
/usr/lib/python2.7/distutils/command/wininst-7.1.exe:   DOS executable (EXE)
/usr/lib/python2.7/distutils/command/wininst-9.0.exe:   DOS executable (EXE)
/usr/lib/python3.9/vendor-packages/pip/_vendor/distlib/t64.exe: DOS executable 
(EXE)
/usr/lib/python3.9/vendor-packages/pip/_vendor/distlib/t32.exe: DOS executable 
(EXE)
/usr/lib/python3.9/vendor-packages/pip/_vendor/distlib/w32.exe: DOS executable 
(EXE)
/usr/lib/python3.9/vendor-packages/pip/_vendor/distlib/w64.exe: DOS executable 
(EXE)
/usr/lib/python3.9/vendor-packages/setuptools/gui.exe:  DOS executable (EXE)
/usr/lib/python3.9/vendor-packages/setuptools/gui-32.exe:   DOS executable 
(EXE)
/usr/lib/python3.9/vendor-packages/setuptools/gui-64.exe:   DOS executable 
(EXE)
/var/smb/cvol/windows/system32/eventlog.dll:DOS executable (EXE)

Why are they there?

Reg

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

[OpenIndiana-discuss] Dangling symlinks in 2021.04.30?

[Reginald Beardsley via openindiana-discuss]

Are these dangling links or are they used to dynamically redirect things and 
missing another link?

/usr/share/lib/sgml/locale/ja_JP.UTF-8/entities:symbolic link to 
../C/entities
/usr/share/lib/sgml/locale/ja_JP.UTF-8/transpec/roff.cmap:  symbolic link 
to ../../C/transpec/roff.cmap
/usr/share/lib/sgml/locale/ja_JP.UTF-8/dtds/catalog:symbolic link to 
../../C/dtds/catalog
/usr/share/lib/sgml/locale/ja_JP.UTF-8/dtds/solbookv2/solbook.dtd:  
symbolic link to ../../../C/dtds/solbookv2/solbook.dtd
/usr/share/lib/sgml/locale/ja_JP.PCK/entities:  symbolic link to ../C/entities
/usr/share/lib/sgml/locale/ja_JP.PCK/transpec/roff.cmap:symbolic link 
to ../../C/transpec/roff.cmap
/usr/share/lib/sgml/locale/ja_JP.PCK/dtds/solbookv2/solbook.dtd:
symbolic link to ../../../C/dtds/solbookv2/solbook.dtd
/usr/share/lib/sgml/locale/ja_JP.PCK/dtds/catalog:  symbolic link to 
../../C/dtds/catalog
/usr/share/lib/sgml/locale/ja/dtds/catalog: symbolic link to 
../../C/dtds/catalog
/usr/share/lib/sgml/locale/ja/dtds/solbookv2/solbook.dtd:   symbolic link 
to ../../../C/dtds/solbookv2/solbook.dtd
/usr/share/lib/sgml/locale/ja/transpec/roff.cmap:   symbolic link to 
../../C/transpec/roff.cmap
/usr/share/lib/sgml/locale/ja/entities: symbolic link to ../C/entities

Reg

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

Re: [OpenIndiana-discuss] More 2021.04.30 strangeness

[Reginald Beardsley via openindiana-discuss]

 Here's the info:

root@hipster:~/wrk/audit# pkg info library/desktop/libgksu
 Name: library/desktop/libgksu
 Summary: Simple API for embedded_su, pfexec and sudo (optional)
 Category: System/Libraries
 State: Installed
 Publisher: openindiana.org
 Version: 2.0.12
 Branch: 2020.0.1.5
 Packaging Date: September 12, 2020 at 07:01:21 PM
Last Install Time: April 30, 2021 at 09:14:07 PM
 Size: 401.04 kB
 FMRI: 
pkg://openindiana.org/library/desktop/libgksu@2.0.12-2020.0.1.5:20200912T190121Z
 Source URL: http://people.debian.org/~kov/gksu/libgksu-2.0.12.tar.gz
 Project URL: http://www.nongnu.org/gksu/
root@hipster:~/wrk/audit# pkg info desktop/gksu
 Name: desktop/gksu
 Summary: Graphical frontend to su
 Category: Applications/System Utilities
 State: Installed
 Publisher: openindiana.org
 Version: 2.0.2
 Branch: 2020.0.1.5
 Packaging Date: March 30, 2020 at 11:46:52 AM
Last Install Time: April 30, 2021 at 09:14:07 PM
 Size: 184.58 kB
 FMRI: pkg://openindiana.org/desktop/gksu@2.0.2-2020.0.1.5:20200330T114652Z
 Source URL: http://people.debian.org/~kov/gksu/gksu-2.0.2.tar.gz
 Project URL: http://www.nongnu.org/gksu/

Reg
 On Monday, June 21, 2021, 04:19:11 PM CDT, Till Wegmueller 
 wrote:  
 
 Hi Everyone

Can you check that library/desktop/libgksu and desktop/gksu are installed?

Those are the most problematic candidates to be missing.

-Till

On 21.06.21 17:34, Gary Mills wrote:
> On Mon, Jun 21, 2021 at 08:17:57PM +0000, Reginald Beardsley via 
> openindiana-discuss wrote:
> 
>> At this point, the only means I can think of to find the source of
>> the message is to run ldd(1) across all the executables and grep out
>> anything that links libcaja-gksu.so.
> 
>      dump -Lv ... | grep NEEDED
> 
> works better than ldd.
> 
> 

___
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] More 2021.04.30 strangeness

[Reginald Beardsley via openindiana-discuss]

 
Usually you see enough of the first part of the string. However, I also looked 
for the open(2) of libgksu.so and neither caja nor mate-session nor any of 
their children open it.

Reg

 On Monday, June 21, 2021, 05:12:03 PM CDT, Udo Grabowski (IMK) 
 wrote:  
 
 On 21.06.21 22:17, Reginald Beardsley via openindiana-discuss wrote:
> FYI  I wrapped both caja and mate-session with "truss -f -o". Neither output 
> contains the "Initializing gksu extensions" string.  ...

Note that you usually don't see full strings in truss output,
those are printed usually as single character outputs. So
you cannot simply search for a string.



___
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] More 2021.04.30 strangeness

[Reginald Beardsley via openindiana-discuss]

 I do not find either of those. 

What is the full path for the files you cited?

 /usr/bin/gksu and /usr/bin/gksudo are present. It turns out that both of those 
are looking for libgksu2.so.0 which does not exist in my installation of 
2021.04.30. 

I did not get as many link libraries listed with "dump -Lv" as I did with ldd.

Nonetheless *something* is invoking libgksu.so to generate the "Initializing 
gksu extensions..." message in .xsession-errors.

At this point I think test installs are needed to verify that the F5 option 
install to an existing pool isn't expecting some things to have been done which 
I have not done. I tried reading the installer source and it was rather opaque 
because of the use of various modules/packages (whatever python calls them). 
Too much "magic".

Reg


 On Monday, June 21, 2021, 04:19:11 PM CDT, Till Wegmueller 
 wrote:  
 
 Hi Everyone

Can you check that library/desktop/libgksu and desktop/gksu are installed?

Those are the most problematic candidates to be missing.

-Till

On 21.06.21 17:34, Gary Mills wrote:
> On Mon, Jun 21, 2021 at 08:17:57PM +, Reginald Beardsley via 
> openindiana-discuss wrote:
> 
>> At this point, the only means I can think of to find the source of
>> the message is to run ldd(1) across all the executables and grep out
>> anything that links libcaja-gksu.so.
> 
>      dump -Lv ... | grep NEEDED
> 
> works better than ldd.
> 
> 

___
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] More 2021.04.30 strangeness

[Reginald Beardsley via openindiana-discuss]

FYI  I wrapped both caja and mate-session with "truss -f -o". Neither output 
contains the "Initializing gksu extensions" string.  I have created OI issue 
#13895 to provide a place for a subset of the  truss output between consecutive 
excve()s of caja.  Total output before I could kill the session was 56 MB.  The 
segment posted to the bug tracker starts at the first execve("/usr/bin/caja"... 
at line 239933 of the truss output.

The string written to .xsession-errors is contained in 
/usr/lib/amd64/caja/extensions-2.0/libcaja-gksu.so.

At this point, the only means I can think of to find the source of the message 
is to run ldd(1) across all the executables and grep out anything that links 
libcaja-gksu.so. 

Reg

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

Re: [OpenIndiana-discuss] More 2021.04.30 strangeness

[Reginald Beardsley via openindiana-discuss]

 The problems I was having appear to have been caused by caja restarting. The 
system stayed up with the mouse functional overnight. Before I disabled caja it 
would lock up the cursor in an hour or less.

I'll wrap caja with a script that runs "truss -f -o" to find out why it is 
failing and do the same with mate-session to find out where caja is being 
started. IIRC caja is also used to do MS style file indexing which I also do 
not want.

I definitely want to see this fixed. As I found the problem, I'm going to find 
the cause. I'm going to start with mate-session as I need to know a lot more 
about it to control what window managers run on which screen. Historically I 
did it via .xsession, but that was somewhat of a kludge to avoid figuring out 
the X initialization stuff in CDE.

I'm also going to look at the text-install log files and find out why this did 
not happen when I let the script create the pool. That will take longer as I'll 
need to do two installs on another system to capture comparable logs, though 
I'll try with just one reinstall using the F2 on the first screen on a Z400 
system. That *should* be close enough of a match to the Z840.

I was a bit confused by MATE at first, but then found out what and why. I was 
amused to see how much like Windows 8.x & 10 Gnome 3.x on Solaris 11 was. That 
immediately killed any idea I had of running Solaris 11. Ughh!

I engineered running dtwm and twm side by side under CDE without root access at 
work, so except for bit rot in the intervening 15+ years, I don't think I'll 
have too much trouble running MATE and twm. But there are always surprises.

The main reason I like twm is I can set a menu icon bar on the RHS of a 
portrait mode monitor and full size printed page xterms stacked on the LHS. A 
double click on an xterm name in the icon menu gets it to the top of the stack. 
This proved very useful doing research support work. I often had xterms that 
ran for many months while working on multiple projects. Having the entire 
command line history available avoided a lot of note taking and kept everything 
related in one place. I actually started that practice in 1989 using an NCD 15" 
X terminal. Having a full printed page of source code in view was a huge 
improvement over a VT100. At 1024 x 1024 monochrome, it was also a big 
improvement over a Sparcstation 1+ with a 16" Sony at 1152 x 900. I came back 
from vacation to find my X term had been given to a summer intern and I'd been 
given the Sparcstation. I demanded my X term back and threatened to epoxy it 
too my desk. I had been given a 386i and DECstation 2000 before I got the NCD. 
I didn't want any more keyboard layout changes. As my work required running on 
every system in service the NCD was much more convenient. One home filesystem 
and one xterm per system type.

Have Fun!
Reg


 On Sunday, June 20, 2021, 11:59:06 PM CDT, Tim Mooney via 
openindiana-discuss  wrote:  
 
 In regard to: Re: [OpenIndiana-discuss] More 2021.04.30 strangeness,...:

> This is the LiveImage text install to an existing pool so I could do
> both RAIDZ2 and RAIDZ1. So it *is* a bit different. I had to create dump
> and swap among other things.
>
> I found via top that caja was restarting 6 times per second, so I turned
> off execute permissions which stopped that. It *may* have been the cause
> of the other problems I was seeing. I should know in the morning. So
> far, so good.

If you're in the mood to do a little research, I would be at least a
little interested to know what was triggering the misbehavior with caja.
I know you don't plan to use it and I too rarely use the graphical file
manager, but if there's an edge case that you can reproduce, it might be
nice to identify it and get it fixed.

If you can figure out which component is restarting it, you can probably
truss that with -f and get an idea of what error caja is encountering
that's causing it to act that badly.

> I don't have PulseAudio running that I know of, but I also didn't, and
> have *never* started caja.

caja is one of many components of MATE.  When MATE forked from GNOME 2.x,
because of the direction GNOME 3.x was headed, the overall environment
was named "MATE" and virtually every component of the fork was renamed
to something else, to distinguish it from the GNOME 3.x component.  I'm
not sure how the names were chosen, but I think "caja" is most closely
descended from "nautilus".  Even after a couple of years of using MATE,
I still sometimes confuse the old GNOME 2.x names (like "evince" for the
document & PDF viewer) with what things are named under MATE ("atril" is
the MATE rebrand for evince).

Unlike the simple graphical desktop environments you prefer, the modern
desktop model (and this is true with KDE, MATE, GNOME 3.x, and other
desktops) often has components auto-started by other components.  Just by
virtue of lightdm launching "mate-session" for you, a lot of stuff gets
launched behind the scenes.  It may not have been 

Re: [OpenIndiana-discuss] More 2021.04.30 strangeness

[Reginald Beardsley via openindiana-discuss]

 Tim,

Thanks. I don't have the gl-helper stuff anywhere. I'd never seen that message 
before either.

This is the LiveImage text install to an existing pool so I could do both 
RAIDZ2 and RAIDZ1. So it *is* a bit different. I had to create dump and swap 
among other things.

I found via top that caja was restarting 6 times per second, so I turned off 
execute permissions which stopped that. It *may* have been the cause of the 
other problems I was seeing. I should know in the morning. So far, so good.

I don't have PulseAudio running that I know of, but I also didn't, and have 
*never* started caja. I didn't even know what it was until this afternoon. I'd 
seen the name, but simply ignored it. A search on the gksu extensions revealed 
that it was for caja and that was a filesystem browser.

I'm starting up via lightdm.

At this point I seem to be OK. I'm actually farther along than I expected given 
the complexity of the configuration I'm planning. Getting the L2ARC working as 
desired was a lot smoother than I expected. Moving filesystems will be a bit of 
a chore, but I can " zfs send" to the scratch pool using NFS and then put the 
files from Solaris 10 u8 and Hipster 2017.10 in sensible locations from there 
(if I can figure out what that is ;-)

I'm going to go back to a dual window manager configuration which will be 
"interesting" I'm sure. I'll run twm for the portrait mode software development 
stuff and MATE on the landscape mode screen for Firefox and similar.

Overall, I'm very pleased. Using RAIDZ1 for the scratch pool instead of RAIDZ2 
got me an extra 1.2 TB of space. As this is just for temporary files when doing 
data processing, the reduced redundancy is not an issue. Still a lot of work to 
do, but I'm rather excited as it should be a much nicer system once I work out 
all the kinks. Once it's done I simply need to find a vary large dataset to 
play with.

Have Fun!
Reg



On Sunday, June 20, 2021, 06:14:58 PM CDT, Tim Mooney via openindiana-discuss 
 wrote:


In regard to: [OpenIndiana-discuss] More 2021.04.30 strangeness, Reginald...:

> After the reboot .xsession-errors has this at the start:
>
> root@hipster:~# more .xs*ors
> mate-session-check-accelerated: Failed to run GL helper: Failed to execute 
> child process “/usr/
> lib/amd64/mate/mate-session-check-accelerated-gl-helper” (No such file or 
> directory)
> mate-session-check-accelerated: Failed to run GLES helper: Failed to execute 
> child process “/us
> r/lib/amd64/mate/mate-session-check-accelerated-gles-helper” (No such file or 
> directory)

I don't see those errors in my .xsession-errors, and I do not have that
binary installed

> (mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:40.297: Call to 
> screen_info_new is too
> frequent, skipping...
>
> (mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:40.308: Call to 
> screen_info_new is too
> frequent, skipping...
> Window manager warning: Log level 128: unsetenv() is not thread-safe and 
> should not be used after
> threads are created
>
> (mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:41.528: Call to 
> screen_info_new is too
> frequent, skipping...
>
> (mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:41.531: Call to 
> screen_info_new is too
> frequent, skipping...
>
> (mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:41.531: Call to 
> screen_info_new is too
> frequent, skipping...

I do see the same screen_info_new is too frequent warnings from
mate-settings-daemon, and the warning about unsetenv().

> Connection failure: Connection refused
> pa_context_connect() failed: Connection refused

I do not have these two messages. This is just a guess, but "pa_" is
probably PulseAudio. Do you have any "pulse" processes in your process
list?

> ** Message: 07:35:42.669: Initializing gksu extension...
> ** Message: 07:35:42.984: Initializing gksu extension...
> ** Message: 07:35:43.158: Initializing gksu extension...

I do have one message about initializing gksu, but not 3 in a row like
this.

Is MATE being started by lightdm, or are you starting it some other way?

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

___
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] More 2021.04.30 strangeness

[Reginald Beardsley via openindiana-discuss]

 I turned off execute permission for caja which stopped the initialization 
spew. It was trying to start caja 6 times a second :-(

I'll *never* use caja as it's a ridiculously clumsy way to navigate the file 
system. I've clearly got a lot of cruft removal to do.

I'll have to wait a while to find out if I still have a problem or if "unset 
autologout" and disabling caja resolved it.

A search using find in /etc & /root did not locate where autologout was set.

Reg


 On Sunday, June 20, 2021, 04:59:28 PM CDT, Reginald Beardsley via 
openindiana-discuss  wrote:  
 
 I've started to transition all my computing to 2021.04.30 on the Z840.  I 
created a pair of pools, one with primary-cache=all and one with 
primary-cache=metadata.  The first is 4.3 TB RAIDZ2 and the second 3.8 TB 
RAIDZ1.  It's a 4x 4 TB disk set with a 1 TB NVMe SSD for the L2ARC, split 980 
GB and 20 GB.  That all seems fine with the L2 persisting across a reboot.

I was getting logged out running as root so I did "unset autologout"  and hit 
return.  The mouse cursor then hid behind the mate-term and became inoperative. 
 I was forced to reboot via the soft power switch.

After the reboot .xsession-errors has this at the start:

root@hipster:~# more .xs*ors
mate-session-check-accelerated: Failed to run GL helper: Failed to execute 
child process “/usr/
lib/amd64/mate/mate-session-check-accelerated-gl-helper” (No such file or 
directory)
mate-session-check-accelerated: Failed to run GLES helper: Failed to execute 
child process “/us
r/lib/amd64/mate/mate-session-check-accelerated-gles-helper” (No such file or 
directory)

(mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:40.297: Call to 
screen_info_new is too
 frequent, skipping...

(mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:40.308: Call to 
screen_info_new is too
 frequent, skipping...
Window manager warning: Log level 128: unsetenv() is not thread-safe and should 
not be used after
 threads are created

(mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:41.528: Call to 
screen_info_new is too
 frequent, skipping...

(mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:41.531: Call to 
screen_info_new is too
 frequent, skipping...

(mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:41.531: Call to 
screen_info_new is too
 frequent, skipping...
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
** Message: 07:35:42.669: Initializing gksu extension...
** Message: 07:35:42.984: Initializing gksu extension...
** Message: 07:35:43.158: Initializing gksu extension...


it then repeats the gksu messages 5-6 times per second

Does anyone know what is going on?  I've never seen this before.  GPU is an 
nVidia K5000 using the 390.141 driver.

Thanks,
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

[OpenIndiana-discuss] More 2021.04.30 strangeness

[Reginald Beardsley via openindiana-discuss]

I've started to transition all my computing to 2021.04.30 on the Z840.  I 
created a pair of pools, one with primary-cache=all and one with 
primary-cache=metadata.  The first is 4.3 TB RAIDZ2 and the second 3.8 TB 
RAIDZ1.  It's a 4x 4 TB disk set with a 1 TB NVMe SSD for the L2ARC, split 980 
GB and 20 GB.  That all seems fine with the L2 persisting across a reboot.

I was getting logged out running as root so I did "unset autologout"  and hit 
return.  The mouse cursor then hid behind the mate-term and became inoperative. 
 I was forced to reboot via the soft power switch.

After the reboot .xsession-errors has this at the start:

root@hipster:~# more .xs*ors
mate-session-check-accelerated: Failed to run GL helper: Failed to execute 
child process “/usr/
lib/amd64/mate/mate-session-check-accelerated-gl-helper” (No such file or 
directory)
mate-session-check-accelerated: Failed to run GLES helper: Failed to execute 
child process “/us
r/lib/amd64/mate/mate-session-check-accelerated-gles-helper” (No such file or 
directory)

(mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:40.297: Call to 
screen_info_new is too
 frequent, skipping...

(mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:40.308: Call to 
screen_info_new is too
 frequent, skipping...
Window manager warning: Log level 128: unsetenv() is not thread-safe and should 
not be used after
 threads are created

(mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:41.528: Call to 
screen_info_new is too
 frequent, skipping...

(mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:41.531: Call to 
screen_info_new is too
 frequent, skipping...

(mate-settings-daemon:1419): MateDesktop-WARNING **: 07:35:41.531: Call to 
screen_info_new is too
 frequent, skipping...
Connection failure: Connection refused
pa_context_connect() failed: Connection refused
** Message: 07:35:42.669: Initializing gksu extension...
** Message: 07:35:42.984: Initializing gksu extension...
** Message: 07:35:43.158: Initializing gksu extension...


it then repeats the gksu messages 5-6 times per second

Does anyone know what is going on?  I've never seen this before.  GPU is an 
nVidia K5000 using the 390.141 driver.

Thanks,
Reg

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

Re: [OpenIndiana-discuss] [discuss] Re: NVMe SSD

[Reginald Beardsley via openindiana-discuss]

 I'm running 2021.04.31 on a 4 disk RAIDZ2 pool using 4 TB disks.

After considering work habits I decided to use the SSD for an L2ARC. I often 
run find(1) across large parts of the filesystem looking for files, so that 
should cache the directory information.

With a reconfigure boot OI found the SSD and fdisk(1m) followed by format(1m) 
let me set everything up properly.

I had to run fdisk to get the "geometry" to describe the disk to format. I've 
not yet configured the L2ARC. That's next. It is *way* too hot to be outside 
melting aluminum cans.

Have Fun!
Reg


 On Friday, June 18, 2021, 01:51:07 PM CDT, Tony Brian Albers  
wrote:  
 
 Reginald Beardsley via openindiana-discuss wrote:
> I just added a 1 TB WD SN750 NVMe SSD to my Z840 running Hipster 2021.04.31.  
> Now I need to set it up.
> 
> I have read the FreeBSD Master volumes by Lucas and Jude on the subject, but 
> the information is skimpy.  A search didn't turn up much that is relevant and 
> less still that is useful.  I want to serve executables,  libraries man 
> pages, etc from this.  Those are probably the only things I'd access 
> sufficiently often for it to provide any benefit.  I'm not running a database 
> instance.
> 
> Reading suggestions?
> 
> Have Fun!
> Reg
> 
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
> 

Depending on what other disks you have it might be best to just move the 
whole OS onto it. That would give you a general performance boost.
Since it's not mirrored(from what I can deduct from your post), it would 
probably be a good idea to keep important stuff(not easily 
reinstallable/recoverable) on mirrored drives. And as always, have a 
backup -one that actually can be used to recover from ;)

/tony

-- 
Tony Albers - Systems Architect - IT Development Royal Danish Library, 
Victor Albecks Vej 1, 8000 Aarhus C, Denmark
Tel: +45 2566 2383 - CVR/SE: 2898 8842 - EAN: 5798000792142
--
illumos: illumos-discuss
Permalink: 
https://illumos.topicbox.com/groups/discuss/Tda8a75e27684f82a-Mb77cb5b53eadc0231a3e9e73
Delivery options: https://illumos.topicbox.com/groups/discuss/subscription
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] NVMe SSD

[Reginald Beardsley via openindiana-discuss]

I just added a 1 TB WD SN750 NVMe SSD to my Z840 running Hipster 2021.04.31.  
Now I need to set it up.

I have read the FreeBSD Master volumes by Lucas and Jude on the subject, but 
the information is skimpy.  A search didn't turn up much that is relevant and 
less still that is useful.  I want to serve executables,  libraries man pages, 
etc from this.  Those are probably the only things I'd access sufficiently 
often for it to provide any benefit.  I'm not running a database instance.

Reading suggestions?

Have Fun!
Reg

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

Re: [OpenIndiana-discuss] [oi-dev] OI Foundation

[Reginald Beardsley via openindiana-discuss]

 
I just want a way to contribute money to support OI/Illumos. TANSTAFL

I was going to suggest one of the commercial Illumos based companies managing 
OI specific work with whatever money was provided and taking a cut to offset 
the cost of managing it.

All I want it a way to provide $200-$250 USD/yr with proper accountability. I 
got shouted down when I suggested the idea 8-10 years ago by people who thought 
it should be "free". I was *not* suggesting anyone be forced to pay, simply 
that there be a way for those who want to contribute money to do that.

I'm a retired research scientist with a very strong preference for SunOS. No 
server farm, other users to support or business revenue. Just me. I value good 
support and professional polish in release images. And willing and able to pay. 
In my case, time is more precious than money.

Reg

 On Wednesday, May 26, 2021, 05:01:38 PM CDT, Till Wegmueller 
 wrote:  
 
 Ok, Just a quick Info mail before everybody gets attached to things.

In the Maintainer call the founding of a Foundation/ or Rather 
Association has been discussed quite a bit. And it's in fact a process 
that was started once but not with a high priority. Thus far getting in 
Volunteers has been a higher priority rather than Organising cash or 
governance.

I get the benefits of a Foundation and a central spot to look at in 
Governance, but thus far we are one core developer (Andreas Wacknitz) 
and supporting maintainers. I love the initiative and Engagement that 
people bring here. And it's needed. But we don't need an official 
Signoff space yet. If people are willing to invest into development, we 
are not holding you guys back. But please be aware who you are and how 
much you have to do with the OI and in fact illumos brand and if another 
name is not more appropriate for an outside initiated initiative. ;)

Greetings
- Till

On 26.05.21 18:32, Gerard Arthus wrote:
> We can roll illumos into the foundation; we can keep the books ourselves,
> just have to pay a cpa to sign off on it if that is desired. I would do the
> tax preparation myself unless a large amount of money was involved. I would
> only do this if the finances were completely transparent and everything was
> posted on the Internet. The main point here should be to use donations
> strictly for development and not sucking administrative cost which is quite
> common in the nonprofit world.
> 
> Gerry
> Gerard Arthus
> 409 Lowell Avenue East
> Mishawaka, Indiana
> United States
> 46545
> Cell - 574-302-7731
> Home - 574-520-1337 <574-217-8726>
> 
> Instructor ITT-Tech - Mathematics, Electrical Engineering, and Computer
> Engineering.
> 
> garthus...@gmail.com
> Notary The State of Indiana #685426
> http://www.OpenEducation.org
> http://openeducation.org/moodle/  (For Course Portal) Log In as Guest
> http://www.linkedin.com/profile/edit?trk=tab_pro
> http://www.facebook.com/gerard.arthus
> https://archive.org/details/arthusgerardphilosophicalwritings (Philosophical
> Discussions)
> https://archive.org/details/arthusgerardpoems (Poems)
> https://archive.org/details/arthusgerardzoe?sort=titleSorter (Zoe Book)
> https://archive.org/details/@garthus1=collections (Gerard Arthus
> Collections Page)
> https://archive.org/details/arthusgerardhack
> 
> (Hacking The World)
> https://archive.org/details/arthusgerardmedical=about
> (Medical Records)
> https://archive.org/details/arthusgerardrec=collection
> (Musical Recordings)
> 
> https://archive.org/details/arthusgerardpackagingandinstructionmanuals
> (Packaging
> Collection)
> https://archive.org/details/@garthus1=uploads  (All Items Uploaded to
> Date)
> https://archive.org/details/What_Have_We_Wrought_ (Selected Poem)
> https://archive.org/details/A_World_Where_We_Consume_Our_Hearts_ (Selected
> Poem)
> https://archive.org/details/Here_There_Is_No_Lesson_To_Be_Learned_ (Selected
> Poem)
> https://archive.org/details/Deception_And_The_Self_Created_Terrorist_Threat_American_Complicity_In_World_W
> (Selected
> Poem)
> https://archive.org/details/Solitary_Horsemen_Reflections_On_Life_In_Cyberspace
> (Selected
> Poem)
> 
> 
> On Wed, May 26, 2021 at 5:21 PM Marc Lobelle 
> wrote:
> 
>> Yes, I too think it is a good idea and worth a try.
>>
>> Marc Lobelle
>>
>> Belgium
>>
>>
>> On 26/05/2021 20:40, Apostolos Syropoulos via openindiana-discuss wrote:
 We can get this going with at least 3-4 individuals; if there is
>> interest I
 can start putting something together.
>>> This is definitely a great idea.
>>> A.S.
>>> --
>>> Apostolos Syropoulos
>>> Xanthi, Greece
>>>
>>>
>>>
>>>
>>> ___
>>> openindiana-discuss mailing list
>>> openindiana-discuss@openindiana.org
>>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>>
>> --
>>
>>
>> Marc Lobelle
>> professeur émérite
>>
>> ICTEAM
>> UCLouvain / SST / ICTEAM / INGI
>>
>> Place Ste 

Re: [OpenIndiana-discuss] [oi-dev] OI Foundation

[Reginald Beardsley via openindiana-discuss]

 
Do we need an OI specific organization? Why could this not be handled by the 
existing Illumos Foundation? That was what I was going to propose. We're using 
the same base OS. So far as I know, OI just adds GUI support. So having the 
Illumos Foundation simply maintain a ledger entry for OI specific financial 
contributions and disburse them seems much lower cost.

Another foundation is immediately burdened by the cost of tax preparation among 
other things.

Reg

 On Wednesday, May 26, 2021, 12:33:31 PM CDT, Gerard Arthus 
 wrote:  
 
 Well I need one to two more people to place their name on the entity we 
create. It would be set up that there would be no compensation for members of 
the Board and that all revenues collected would go to Code development and 
maintenance. I and some others will provide the money for the filing fees and 
we can run it from one of my servers. As far as cleaning up the technical 
documentation...That can be dealt with after the foundation is established. I 
like the FREEBSD Model and could begin the process as soon as others agree.
Gerry
Gerard Arthus
409 Lowell Avenue East
Mishawaka, Indiana
United States
46545
Cell - 574-302-7731
Home - 574-520-1337

Instructor ITT-Tech - Mathematics, Electrical Engineering, and Computer 
Engineering.
garthus...@gmail.com
Notary The State of Indiana #685426
http://www.OpenEducation.org
http://openeducation.org/moodle/  (For Course Portal) Log In as Guest
http://www.linkedin.com/profile/edit?trk=tab_pro
http://www.facebook.com/gerard.arthus
https://archive.org/details/arthusgerardphilosophicalwritings (Philosophical 
Discussions)
https://archive.org/details/arthusgerardpoems (Poems)
https://archive.org/details/arthusgerardzoe?sort=titleSorter (Zoe Book)
https://archive.org/details/@garthus1=collections (Gerard Arthus 
Collections Page)
https://archive.org/details/arthusgerardhack (Hacking The World)
https://archive.org/details/arthusgerardmedical=about (Medical Records)
https://archive.org/details/arthusgerardrec=collection (Musical Recordings)
https://archive.org/details/arthusgerardpackagingandinstructionmanuals 
(Packaging Collection)
https://archive.org/details/@garthus1=uploads  (All Items Uploaded to Date)
https://archive.org/details/What_Have_We_Wrought_ (Selected Poem)
https://archive.org/details/A_World_Where_We_Consume_Our_Hearts_ (Selected Poem)
https://archive.org/details/Here_There_Is_No_Lesson_To_Be_Learned_ (Selected 
Poem)
https://archive.org/details/Deception_And_The_Self_Created_Terrorist_Threat_American_Complicity_In_World_W
 (Selected Poem)
https://archive.org/details/Solitary_Horsemen_Reflections_On_Life_In_Cyberspace 
(Selected Poem)


On Wed, May 26, 2021 at 1:13 PM Reginald Beardsley via oi-dev 
 wrote:

 Thanks for offering to do this. I've been pondering how to hire human 
resources to support OI, but somewhat reluctant to post about it as I tried 
8-10 years ago without success.

I am *very* interested in contributing money to such an organization on an 
annual basis at around $200/yr. In particular I think we need a tech writer to 
clean up the documentation, especially the wiki. Being able to hire developers 
would be a huge boon. But if we just cleaned up the ancient cruft in the wiki 
it would make life much easier.

My personal view is that without financial support from the user community OI 
is in serious jeopardy. That would distress me greatly. For me, contributing 
money is much less of a burden than trying to work on stuff myself.

Reg

 On Wednesday, May 26, 2021, 11:50:02 AM CDT, Gerard Arthus 
 wrote:  
 
 I have been using Solaris since 1999 and was always impressed with its 
stability. If there is interest in putting together a Foundation or 
organization for Open Indiana, I will take care of all of the legal aspects 
concerning its establishment; however there will have to be other interested 
people willing to place their names on the governing body of such an 
organization.  Anyone interested should contact me through this list or you can 
use my personal email. The tax deductible aspect is what can actually attract 
funding and this can be accomplished with a little work. I would much prefer an 
organization where the people running it are volunteers and all proceeds will 
go   to the maintenance of the OI codebase and related software applications.
We can get this going with at least 3-4 individuals; if there is interest I can 
start putting something together.
Best wishes,
Gerry
Gerard Arthus
409 Lowell Avenue East
Mishawaka, Indiana
United States
46545
Cell - 574-302-7731
Home - 574-520-1337

Instructor ITT-Tech - Mathematics, Electrical Engineering, and Computer 
Engineering.
garthus...@gmail.com
Notary The State of Indiana #685426
http://www.OpenEducation.org
http://openeducation.org/moodle/  (For Course Portal) Log In as Guest
http://www.linkedin.com/profile/edit?trk=tab_pro
http://www.facebook.com/gerard.arthus
https://archive.org/details/arthusgerardphilosophicalwritings 

Re: [OpenIndiana-discuss] [oi-dev] OI Foundation

[Reginald Beardsley via openindiana-discuss]

 Thanks for offering to do this. I've been pondering how to hire human 
resources to support OI, but somewhat reluctant to post about it as I tried 
8-10 years ago without success.

I am *very* interested in contributing money to such an organization on an 
annual basis at around $200/yr. In particular I think we need a tech writer to 
clean up the documentation, especially the wiki. Being able to hire developers 
would be a huge boon. But if we just cleaned up the ancient cruft in the wiki 
it would make life much easier.

My personal view is that without financial support from the user community OI 
is in serious jeopardy. That would distress me greatly. For me, contributing 
money is much less of a burden than trying to work on stuff myself.

Reg

 On Wednesday, May 26, 2021, 11:50:02 AM CDT, Gerard Arthus 
 wrote:  
 
 I have been using Solaris since 1999 and was always impressed with its 
stability. If there is interest in putting together a Foundation or 
organization for Open Indiana, I will take care of all of the legal aspects 
concerning its establishment; however there will have to be other interested 
people willing to place their names on the governing body of such an 
organization.  Anyone interested should contact me through this list or you can 
use my personal email. The tax deductible aspect is what can actually attract 
funding and this can be accomplished with a little work. I would much prefer an 
organization where the people running it are volunteers and all proceeds will 
go   to the maintenance of the OI codebase and related software applications.
We can get this going with at least 3-4 individuals; if there is interest I can 
start putting something together.
Best wishes,
Gerry
Gerard Arthus
409 Lowell Avenue East
Mishawaka, Indiana
United States
46545
Cell - 574-302-7731
Home - 574-520-1337

Instructor ITT-Tech - Mathematics, Electrical Engineering, and Computer 
Engineering.
garthus...@gmail.com
Notary The State of Indiana #685426
http://www.OpenEducation.org
http://openeducation.org/moodle/  (For Course Portal) Log In as Guest
http://www.linkedin.com/profile/edit?trk=tab_pro
http://www.facebook.com/gerard.arthus
https://archive.org/details/arthusgerardphilosophicalwritings (Philosophical 
Discussions)
https://archive.org/details/arthusgerardpoems (Poems)
https://archive.org/details/arthusgerardzoe?sort=titleSorter (Zoe Book)
https://archive.org/details/@garthus1=collections (Gerard Arthus 
Collections Page)
https://archive.org/details/arthusgerardhack (Hacking The World)
https://archive.org/details/arthusgerardmedical=about (Medical Records)
https://archive.org/details/arthusgerardrec=collection (Musical Recordings)
https://archive.org/details/arthusgerardpackagingandinstructionmanuals 
(Packaging Collection)
https://archive.org/details/@garthus1=uploads  (All Items Uploaded to Date)
https://archive.org/details/What_Have_We_Wrought_ (Selected Poem)
https://archive.org/details/A_World_Where_We_Consume_Our_Hearts_ (Selected Poem)
https://archive.org/details/Here_There_Is_No_Lesson_To_Be_Learned_ (Selected 
Poem)
https://archive.org/details/Deception_And_The_Self_Created_Terrorist_Threat_American_Complicity_In_World_W
 (Selected Poem)
https://archive.org/details/Solitary_Horsemen_Reflections_On_Life_In_Cyberspace 
(Selected Poem)
___
oi-dev mailing list
oi-...@openindiana.org
https://openindiana.org/mailman/listinfo/oi-dev
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] We need install images which work!

[Reginald Beardsley via openindiana-discuss]

 
I did just that. I hit "install" took the defaults, did a reboot and got 
"non-system disk or disk error". Z840 and 4 TB disk. I got that result with 
both 2020.10.31 and 2021.04.30. What I did is *exactly* what most new users 
would do. I just checked the other stuff to see if the image was consistent 
with the instructions.

My first step in building a new system is to do the most basic default install, 
see what it does and then go from there. 

Reg



On Tuesday, May 4, 2021, 02:59:38 PM CDT, Peter Tribble via openindiana-discuss 
 wrote:

[snip]

Assuming new users hit them. Most users simply take the obvious direct
route. If there's
a button that says "Install" they'll hit that and completely ignore
anything and everything
else that might be present.

Based on that simple workflow, the current OI gui installer (which I
haven't used for ages,
but still looks like the original OpenSolaris installer) is good enough.
It's pretty much on a par with
other distro installers (and I've run dozens of them this year already). It
could be a lot quicker,
it could be more responsive, but it's not noticeably worse in terms of
useability or functionality
or reliability than many of the current crop of Linux installers - worse
than some, better than some.
That's not necessarily a ringing endorsement, but the point is that for
most of the target audience
the sky isn't falling and I think it echos what someone (Judah?) said -
stick to the straight and
narrow and life will be easier.

-- 
-Peter Tribble
http://www.petertribble.co.uk/ - http://ptribble.blogspot.com/

___
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] We need install images which work!

[Reginald Beardsley via openindiana-discuss]

 
Thank you, that at least gives me a toe hold. There has been considerable churn 
in the source organization since I started using OI (151_a5) and several 
attempts to sort out what was where and what the overall structure was left me 
quite baffled.

The wiki has a lot of information which is very out of date.

Reg

 On Tuesday, May 4, 2021, 03:04:56 PM CDT, Joshua M. Clulow 
 wrote:  
 
 On Tue, 4 May 2021 at 12:44, Reginald Beardsley via
openindiana-discuss  wrote:
>  I'd be glad to fix them if I knew where the files that need to be modified 
>were located. Please enlighten me.

You have been saying for months that you want to help, if only people
would tell you where all the software is.  As people keep pointing
out, all of the software that goes into the distribution is built via
the userland repository:

    https://github.com/OpenIndiana/oi-userland

The only way you'll be able to help is by taking the time to
familiarise yourself with the make files and components and so on in
that repository.  It's a good place to look when you want to find
where a particular component comes from.  For example, I was looking
for the text installer, so I started on my OI system with:

  $ pkg search installer

The most relevant looking result is "OpenIndiana Text Installer",
package "system/install/text-install".  Maybe you don't know a good
keyword, but you know the name of a file like "text-install" and you
want to know which package contains it:

  $ pkg search text-install

This will tell you that the file "usr/bin/text-install" comes from
"system/install/text-install" as well.

Once you have a package name, it's pretty easy even just with grep to
find that the package comes from:

    
https://github.com/OpenIndiana/oi-userland/blob/oi/hipster/components/openindiana/slim_source/Makefile#L136

Looking further up in that Makefile, you can find that we get the
slim_source component from:

    GIT_REPO=https://github.com/OpenIndiana/slim_source.git

If you then clone _that_ repository, I am sure you will be able to
find what you're looking for.  If not, you'll be able to find where to
look next.

> I tried to find the source for the text-install screen that incorrectly 
> states an EFI whole disk will only use 2 TB. Python loads packages from a 
> library, but I wasn't able to find the source for the library.

A cursory search in the slim_source repository for the text "whole
disk" yields many plausible results:

    https://github.com/OpenIndiana/slim_source/search?q=%22whole+disk%22

Inspecting the live image is interesting, but never paints the whole
picture -- it is necessarily stripped (for size) of much of the
interesting information about where the software originated and how it
was built.  You will generally need to look at the source to
understand.

> The dearth of accurate documentation is a huge barrier.

I agree that there could always be more and better documentation!  But
if, as you keep saying, you want to help, you're going to have to show
some initiative in sifting through the build system and the files.
Things are a bit cryptic sometimes, but it's all in there; by reading
the source you will be able to find it.


Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] We need install images which work!

[Reginald Beardsley via openindiana-discuss]

 I'd be glad to fix them if I knew where the files that need to be modified 
were located. Please enlighten me.

I tried to find the source for the text-install screen that incorrectly states 
an EFI whole disk will only use 2 TB. Python loads packages from a library, but 
I wasn't able to find the source for the library.

What file controls what is on the Live Image Desktop? Where is the GUI install 
process operation documented? I've looked at the Live Image filesystem and 
could divine nothing about how the install worked.

The dearth of accurate documentation is a huge barrier.

Reg


 On Tuesday, May 4, 2021, 01:21:21 PM CDT, Bob Friesenhahn 
 wrote:  
 
 On Tue, 4 May 2021, Reginald Beardsley via openindiana-discuss wrote:
>
> All of these issues are also present in 2020.10.31 and possibly 
> older releases.  This is a huge deterrent to new users.  None of 
> them is a major task to fix.

Will you be submitting the fixes soon?

Bob
-- 
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,    http://www.simplesystems.org/users/bfriesen/public-key.txt

___
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] We have install images which work!

[Reginald Beardsley via openindiana-discuss]

 I was doing bare metal on an HP Z840. Does anyone know of any documentation on 
the VBox boot process? It's obviously not running the BIOS initial loader to 
read the first sector on the disk.

Reg




On Tuesday, May 4, 2021, 01:35:59 PM CDT, epektasis  wrote:



FWIW, I downloaded the 2021.04.30 gui install and installed it into Vbox
(6.1.22 on Artix Linux) with 4.25 Gb RAM allotted. It installed fine. True,
gparted did not work, but the graphical installer selected the entire
available partition, though it only used 7.3Gb. Rebooted fine (apparently the
boot loader was installed), except system/xvm/ipagent:default failed
repeatedly and was transitioned to maintenance; but the gui interface loaded
and I logged in. I believe I had that same error when I installed that
2021.04.05 test release; in that former case, pkg update cleared up that
problem and perhaps it will this time also. I did not find these matters to
be "major" problems; the newly installed system is running.

 e.




___
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

[OpenIndiana-discuss] We need install images which work!

[Reginald Beardsley via openindiana-discuss]

I'm going to try one more time.

---
The 2021.04.30  GUI Live Image has major problems.

gparted(1m) dumps core 

the documentation mentioned on the first GUI installer screen is missing

the release notes are missing

the GUI installer fails to install the boot loader

the text installer incorrectly states EFI installs are limited to 2 TB
-

All of these issues are also present in 2020.10.31 and possibly older releases. 
 This is a huge deterrent to new users.  None of them is a major task to fix.

Simply throwing something over the fence doesn't do anyone a service.  Spending 
an hour once  or twice a year to test a distribution image hardly seems a major 
burden.  

We simply need a review process such that broken installation images are not 
posted for general distribution.  While I only have one or two systems I can 
test,  I am quite happy to do it.  Even a single tester is better than none.  
But my testing is of no use if the issues are not addressed before the install 
images are released.

Without a reliable initial image from which to install, "pkg update" is of no 
use.  Without new users there will not be new maintainers/developers. 


Reg

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

Re: [OpenIndiana-discuss] Rolling release considered harmful

[Reginald Beardsley via openindiana-discuss]

 A response to a couple of Judah's posts.

I experiment with many operating systems including Plan 9 for which I got one 
of the first release floppies at Usenix '95 and chatted about it with Dennis 
for about 20-30 minutes.

My interest in OI is not curiosity. I want a stable, industrial strength OS and 
OI/Illumos has to date been my best option. I've used over a dozen non-Unix 
model OSes and close to 2 dozen Unix model OSes. Possibly more.

I do *not* want to be running alpha software for production use, even in the 
context of a single user, home environment. I'm quite happy to run alpha 
software for internet access, but not for my main system. For that I require 
the near bullet proof quality of traditional SunOS.

Over the years I've watched many names disappear from the OI mailing list. I do 
not know if they still are using OI or not. Many of those are of my generation 
and frame of mind. I have gotten personal emails from some supporting my 
comments, but many appear to be gone forever. They are a significant loss.

In short, if I am forced to run raw alphas I shall go elsewhere if I can find 
something with better QC and QA. After 30+ years using SunOS I should like to 
bring OI to the state that it has a stable, tested branch. I have no objection 
to alphas, but I don't consider alphas as the only option acceptable.

The hallmark of SunOS has always been robustness and reliability. If that is 
gone, there is nothing left of interest other than the corpse. And I prefer to 
avoid those.

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

Re: [OpenIndiana-discuss] Multiboot on PC

[Reginald Beardsley via openindiana-discuss]

 I have a laptop that boots XP, Linux and Solaris. That cost me about a dozen 
install attempts to make work. Then I never used it as I was able to avoid 
traveling.

Subsequently I've always simply swapped hard drives when I wanted to switch the 
OS. I did recently set up to dual boot Windows 7 and Debian 10 for lack of SATA 
caddies.

Reg


 On Monday, May 3, 2021, 11:07:38 AM CDT, Judah Richardson 
 wrote:  
 
 On Mon, May 3, 2021 at 11:01 AM John D Groenveld  wrote:

> In message  3ab...@mail.gmail.com>
> , "Francis.D" writes:
> >I had for a while OI in multiboot on the same hard disk. On a lenovo T410
> >Laptop using the same process on OpenBSD and it worked.
> >
> >I did not test on UEFI
>
> EFI makes multibooting easier, not that I recommend multibooting.
>
I generally recommend against it too, but I've found it's also not very
useful to question OPs' needs/wants ;)

>
> 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
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] Rolling release considered harmful

[Reginald Beardsley via openindiana-discuss]

I just finished running the graphic installer on 2020.10.31 and 2021.04.30 
ISOs.  It would be an understatement to say the results were not good.

1) The documentation mentioned on the first screen is missing as noted 
previously

2) The release notes button produces a "unable to display release notes" dialog.

I selected "whole disk install" and took all the defaults. After the install 
completed I rebooted using the GUI installer.

3) The system reported "Non-system disk or disk error" with both releases.

I am pleased to report that a default text install did properly configure the 
nVIDIA driver in 2021.04.30.  

I don't know when the GUI installer stopped installing the bootloader.  While I 
could check 2017.10  and 2015.10, there's really no point. Git should tell the 
tale for anyone interested.  My concern is not who broke it, but that it is 
being released broken.

The real issue is that releases are not being tested for even basic 
functionality.  We really should be testing for device driver issues, but first 
we need to get to first base.

Someone coming to OI from Linux would quite naturally choose the GUI installer. 
 I shall leave the reader to ponder their likely reaction to "Non-system disk 
or disk error".  I suspect most would simply abandon OI entirely.   Not because 
they couldn't make it work, but because the distribution image is so 
unprofessional as to be embarrassing.

OI *could* make most, if not all, of the Linux distros I've tested look bad.  
Sadly the current status is the opposite.  The worst Linux distro I've tested 
makes OI look bad.

So the overarching question is this:  What is the community going to do about 
it?

Reg

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

Re: [OpenIndiana-discuss] Multiboot on PC

[Reginald Beardsley via openindiana-discuss]

 Yes it is possible, however, it can be tricky preventing one installer from 
stepping on another OS. In particular Linux and Solaris partitions use the same 
number to denote partition type. The way around that is to use fdisk to change 
the partition type to DOS or similar, install and then fix the type after the 
install has completed.

In OI/Illumos "partition" refers to the DOS MBR partition table. To avoid 
confusion, OI/Illumos use the term "slice" to subdivide the Solaris portion of 
the MBR "partition".

Unfortunately, MBR limits the usable disk to 2 TB. In principle a GPT/UEFI 
label will allow booting multiple OSes. I do not know how well that actually 
would work at present. The general documentation is rather skimpy.

Reg


 On Monday, May 3, 2021, 09:18:25 AM CDT, Yassine Chaouche 
 wrote:  
 
 Hello OpenIndiana users,

Is it possible to install OpenIndiana alongside other
OSes on same PC with a single disk ? I don't know if
disk partitions exist in the Unix world or if is sees
the disks differently (I heard of slices instead of
partitions in some OSes)

Feedback appreciated.

-- Yassine.

___
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] Recommended way to migrate to a new release?

[Reginald Beardsley via openindiana-discuss]

 Alan is, of course, correct. You can't have *all* of them fixed in a code base 
as large as a modern OS. But you can fix the important stuff. And what a 
prospective user experiences when they boot the Live Image and attempt an 
install is critical.

When experienced people have major problems doing an install there is something 
seriously wrong. The only thing that kept me going for 50 hours was that I had 
never in 35 years lost a battle with a computer. And I was not going to 
concede. I came very close though to returning the Z840. But before I did that 
I was going to give it one more try and that uncovered the issue. The device 
configuration had not been saved and it did not have /reconfigure present when 
it began to reboot.

Most important of all is a concerted effort *by the user community* to test and 
review a release to ensure that glaring problems are fixed so that a 
prospective new user has a good experience and favorable impression. For a wide 
range of reasons testing a release candidate is not something the developers 
can meaningfully do. It *must* be the users.

Reg



On Sunday, May 2, 2021, 10:05:43 AM CDT, Judah Richardson 
 wrote:


FWIW I strongly agree with you and Alan's take on the "all bugs fixed"
concept.
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Recommended way to migrate to a new release?

[Reginald Beardsley via openindiana-discuss]

 
The Design and Implementation of the FreeBSD Operating System
McKusick, Neville-Neil & Watson
Addison-Wesley 2015 2nd ed

Chapter 10: The Zettabyte Filesystem

It's only 26 pages, but it's the only description of the internals of ZFS I've 
been able to find.

The FreeBSD Mastery books on ZFS by Lucas and Jude provide more information 
about the commands and the implications of various settings. 

McKusick said that finding information about ZFS outside of the source was 
difficult. Lucas and Jude was the only other material in print he knew of. I'm 
hoping he might decide to write a book about it with some of the developers of 
ZFS as coauthors.

Reg On Sunday, May 2, 2021, 04:14:12 PM CDT, John D Groenveld 
 wrote:  
 
 In message , Bob 
Friesenhahn writes:
>Perhaps you are talking about the FreeBSD Handbook rather than the 
>software implementation.  I am not encountering any issues with the OI 
>manual pages or the software.  The OI Wiki is another story 
>altogether.

The OI Handbook is making good progress towards the quality of
FreeBSD's Handbook.
PRs are easy and welcome.

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] Recommended way to migrate to a new release?

[Reginald Beardsley via openindiana-discuss]

 
Gparted(1m) on the Live Image worked at one time. Now it does not. But it's 
still there despite my raising an issue and the triviality of simply removing 
it from the Desktop. I don't recall if the "Getting Started" document 
referenced in the GUI installer was ever there. I'd have to boot disks going 
back to oi151_a5 to see. The wiki documentation with respect to updates from 
version to version is hopelessly out of date.

The OI installs are for the most part better than *BSD, *Linux and even Oracle 
Solaris. I maintain a system on which I can test OS installs on old HDDs. 
Periodically I'll get curious about the state of some OS distro and do an 
install, fool around for a while and then label the disk with what's installed 
and put in the rack I made to hold them all. I've got 2 dozen IDE drive in 
caddies. I don't have a count on SATA drives. I've not been able to find 
inexpensive and good quality caddies for those. So I keep those in anti-static 
bags in the shipping boxes. Less convenient to count.

If potential new users have the sort of problems Michelle and I encountered 
they are not likely to become members of the OI user community. The size of 
that community determines the size of the developer community. Only a small 
fraction of users have the time, skills and motivation to take on 
development/maintenance work.

My personal preference is for "all known bugs fixed" release points. If someone 
wants to track changes more often then the "pkg update" mechanism provides that.

Solaris was created to merge Sys V and BSD. So everyone else created OSF/1, 
though only DEC shipped it. At this point Sys V and BSD compatibility is moot. 
Sun was the last vendor standing, but not for much longer. Sys V only lives on 
in Solaris and Illumos so far as I know.

ZFS was at one time a compelling reason to stick with OI, but that's no longer 
the case. It's actually now better documented in FreeBSD.

Reg

 On Saturday, May 1, 2021, 06:45:55 PM CDT, Till Wegmueller 
 wrote:  
 
 Hi Reg

Hipster is a Rolling release model meaning updates land directly in the 
package repositories for each package.

ISO "Releases" are simply there to mark a point where we look back onto 
the last 6 months and can actually see how much has moved. And it's the 
point we want to make it as stable as possible so that new people can 
install it from the snapshot medias. Historically it was also a point, 
where we could snapshot the Repo so people could jump between 
publishers, but that has changed.

-Till

On 01.05.21 20:05, Reginald Beardsley via openindiana-discuss wrote:
>  
> So if I do a "pkg update" after each ISO release I should track the ISOs?
> 
> How do I ensure that I pick up new packages in an ISO? Do I specify a tag? It 
> seems unlikely that the package list would be immutable.
> 
> Reg
> 
>      On Saturday, May 1, 2021, 05:52:51 PM CDT, Alan Coopersmith 
> wrote:
>  
>  On 5/1/21 3:31 PM, Reginald Beardsley via openindiana-discuss wrote:
>> I tried a text-install of 2021.04.30  into an existing 2020.10.31 pool, but 
>> the user information didn't propagate to the new BE.  Is this a bug, install 
>> mistake or the wrong way to update?
> 
> The wrong way to update.  Install media is for fresh installs only.
> Updates are done via "pkg update".
> 

___
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] Recommended way to migrate to a new release?

[Reginald Beardsley via openindiana-discuss]

 
So if I do a "pkg update" after each ISO release I should track the ISOs?

How do I ensure that I pick up new packages in an ISO? Do I specify a tag? It 
seems unlikely that the package list would be immutable.

Reg

 On Saturday, May 1, 2021, 05:52:51 PM CDT, Alan Coopersmith 
 wrote:  
 
 On 5/1/21 3:31 PM, Reginald Beardsley via openindiana-discuss wrote:
> I tried a text-install of 2021.04.30  into an existing 2020.10.31 pool, but 
> the user information didn't propagate to the new BE.  Is this a bug, install 
> mistake or the wrong way to update?

The wrong way to update.  Install media is for fresh installs only.
Updates are done via "pkg update".

-- 
    -Alan Coopersmith-              alan.coopersm...@oracle.com
    Oracle Solaris Engineering - https://blogs.oracle.com/alanc
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] OpenIndiana Hipster 2021.04 is here

[Reginald Beardsley via openindiana-discuss]

 
Thanks!

 On Saturday, May 1, 2021, 05:25:16 PM CDT, Joshua M. Clulow 
 wrote:  
 
 On Sat, 1 May 2021 at 10:05, Reginald Beardsley via
openindiana-discuss  wrote:
> How about a pkg or explicit instructions (e.g. a shell script) for setting up 
> to be able to generate an ISO?

http://docs.openindiana.org/dev/distribution-constructor/

Cheers.

-- 
Joshua M. Clulow
http://blog.sysmgr.org
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] Recommended way to migrate to a new release?

[Reginald Beardsley via openindiana-discuss]

I tried a text-install of 2021.04.30  into an existing 2020.10.31 pool, but the 
user information didn't propagate to the new BE.  Is this a bug, install 
mistake or the wrong way to update?

All the stuff I found on the wiki was quite old.  Nothing discussed updates 
from one Hipster release to the next.   Particularly bothersome was the 
"uninstall a bunch of packages" part.  Everything I read appeared to apply to 
the situation 7-8 years ago.

I'd like to create a BE for each release so I can revert back if needed.  I'd 
also like to update from the ISO image in order to stay in sync with it.

A corollary question is does a "stable" branch exist?  From the wiki:

"Hipster is a rapid development branch where software versions are frequently 
updated. While every package is tested to ensure stability, caution is 
nevertheless warranted when deploying Hipster into mission critical production 
environments."

i gather that there are people running OI in a  production environment as 
opposed to my single user home environment.  How do you address the issue?

Reg

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

Re: [OpenIndiana-discuss] OpenIndiana Hipster 2021.04 is here

[Reginald Beardsley via openindiana-discuss]

 On Saturday, May 1, 2021, 09:16:45 AM CDT, Andreas Wacknitz 
 wrote:

[snip]

>I want to use this announcement to remind everybody that we are seeking
>for volunteers who help us to maintain OpenIndiana.

>Kind regards,
>Andreas

How about a pkg or explicit instructions (e.g. a shell script) for setting up 
to be able to generate an ISO?

Reg

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

Re: [OpenIndiana-discuss] Partitions for co-exist NAS drive

[Reginald Beardsley via openindiana-discuss]

 That's what it should do but the messages in the install program are quite 
confusing. 

It will actually let you do anything you want, but it is not easy to sort out 
how. In 34 years of doing admin work I have *never* had to spend more than a 
few hours to get a working system. The failure to reconfigure on the first boot 
took me 50 hours of effort to diagnose. And I really only succeeded because I 
did not give up.

I normally take several days sorting out exactly how I want a new system 
configured, but that is rather different from it not booting when it obviously 
should.

Reg


 On Saturday, May 1, 2021, 11:38:04 AM CDT, Michelle 
 wrote:  
 
 I just followed the text install on the 2021.04 GUi live image, and it
created a single Rpool for the whole disk.

I'm not sure where I'm going to go from here. Need to have a sit and
think.

Thank you very much for all your efforts on this. I really do
appreciate it.

Michelle.

On Sat, 2021-05-01 at 16:23 +, Reginald Beardsley via openindiana-
discuss wrote:
>  I just installed the 2021.04.30 text ISO on my Z400 test system. The
> disk had a pool in a single slice which I imported and destroyed. Had
> I not done that it would have named the pool rpool1. I left the disk
> label alone. This was from testing manually creating a single slice
> and installing into that using the F5 option which doesn't create
> dump and swap on the expectation they already exist.
> 
> The installer still has the usual spurious messages about only using
> 2 TB. I selected an EFI label and did the install.
> 
> That created a 256 MB s0 slice beginning in sector 256 with the rest
> of the disk in s1.
> 
> "zfs list" shows the pool has 4.39 TB available which is correct for
> having used the entire disk.
> 
> If you're going to run a 2 disk mirror with the 6 TB drives I'd
> install to a single pool using the text installer. Assuming it works
> properly. When the 8 TB drive returns, copy the data and then create
> a matching label and add the drive to the pool to create a mirror.
> 
> Unfortunately we are a tad shy on current documentation.
> 
> Reg
> 
>      On Saturday, May 1, 2021, 10:15:53 AM CDT, Michelle <
> miche...@msknight.com> wrote:  
>  
>  Actually, I was wrong. It was the 2021.04 text install USB that I
> was
> using. I was using the text install because it's just a file server.
> I
> don't need X.
> 
> Well, the situation I find myself in is as follows...
> 
> A pair of 6tb reds, one of which has data on that I can't get off
> until
> one of my 8tb has come back from RMA
> 
> So I thought I'd use the other 6tb to get this sorted, and by the
> time
> the other 6tb is ready to be put in, I would be able to install it
> and
> add it in.
> 
> Going via the GUI installer, I'm wondering whether I'll be able to do
> that.
> 
> This is why I was following your script, but when it came to step 4,
> the solaris partition was only 2tb max. However, I've just noted that
> I
> wasn't using the -e at the end of the format command, so after I've
> made dinner I'll read up on that switch in the hope that this is what
> will enable me to create the larger Solaris partition.
> 
> Michelle.
> 
> 
> On Sat, 2021-05-01 at 14:04 +, Reginald Beardsley via
> openindiana-
> discuss wrote:
> >  Michelle,
> > 
> > What disks are you trying to use? If they are different sizes the
> > recipe gets a bit more complex, but it's quite possible to get any
> > arrangement for which you have a sufficient number of disks. Having
> > spent 50 hours over 5 days battling the 2021.04.05 install I've had
> > *lots* of practice installing both 2021.04.05 and 2020.10.
> > 
> > Incidentally the failure of 2021.04.05 to run the nVIDIA driver is
> > because it installed the wrong driver for that system.
> > 
> > Reg
> > 
> > 
> > 
> > 
> > On Saturday, May 1, 2021, 08:16:07 AM CDT, Michelle <
> > miche...@msknight.com> wrote:
> > 
> > 
> > OK - I give in.
> > 
> > I've tried various combinations and I just can't get this into a
> > configuration where I can get things installed.
> > 
> > I need a step by step guide please, because I'm lost. I don't know
> > what
> > options to choose in the installer to not avoid it wanting to wipe
> > whatever combinations of partitions I've set.
> > 
> > Michelle.
> > 
> > 
> >  
> > ___
> > openindiana-discuss mailing list
> > openindiana-discuss@openindiana.org
> > https://openindiana.org/mailman/listinfo/openindiana-discuss
> 
> ___
&g

Re: [OpenIndiana-discuss] Partitions for co-exist NAS drive

[Reginald Beardsley via openindiana-discuss]

 I just installed the 2021.04.30 text ISO on my Z400 test system. The disk had 
a pool in a single slice which I imported and destroyed. Had I not done that it 
would have named the pool rpool1. I left the disk label alone. This was from 
testing manually creating a single slice and installing into that using the F5 
option which doesn't create dump and swap on the expectation they already exist.

The installer still has the usual spurious messages about only using 2 TB. I 
selected an EFI label and did the install.

That created a 256 MB s0 slice beginning in sector 256 with the rest of the 
disk in s1.

"zfs list" shows the pool has 4.39 TB available which is correct for having 
used the entire disk.

If you're going to run a 2 disk mirror with the 6 TB drives I'd install to a 
single pool using the text installer. Assuming it works properly. When the 8 TB 
drive returns, copy the data and then create a matching label and add the drive 
to the pool to create a mirror.

Unfortunately we are a tad shy on current documentation.

Reg

 On Saturday, May 1, 2021, 10:15:53 AM CDT, Michelle 
 wrote:  
 
 Actually, I was wrong. It was the 2021.04 text install USB that I was
using. I was using the text install because it's just a file server. I
don't need X.

Well, the situation I find myself in is as follows...

A pair of 6tb reds, one of which has data on that I can't get off until
one of my 8tb has come back from RMA

So I thought I'd use the other 6tb to get this sorted, and by the time
the other 6tb is ready to be put in, I would be able to install it and
add it in.

Going via the GUI installer, I'm wondering whether I'll be able to do
that.

This is why I was following your script, but when it came to step 4,
the solaris partition was only 2tb max. However, I've just noted that I
wasn't using the -e at the end of the format command, so after I've
made dinner I'll read up on that switch in the hope that this is what
will enable me to create the larger Solaris partition.

Michelle.


On Sat, 2021-05-01 at 14:04 +, Reginald Beardsley via openindiana-
discuss wrote:
>  Michelle,
> 
> What disks are you trying to use? If they are different sizes the
> recipe gets a bit more complex, but it's quite possible to get any
> arrangement for which you have a sufficient number of disks. Having
> spent 50 hours over 5 days battling the 2021.04.05 install I've had
> *lots* of practice installing both 2021.04.05 and 2020.10.
> 
> Incidentally the failure of 2021.04.05 to run the nVIDIA driver is
> because it installed the wrong driver for that system.
> 
> Reg
> 
> 
> 
> 
> On Saturday, May 1, 2021, 08:16:07 AM CDT, Michelle <
> miche...@msknight.com> wrote:
> 
> 
> OK - I give in.
> 
> I've tried various combinations and I just can't get this into a
> configuration where I can get things installed.
> 
> I need a step by step guide please, because I'm lost. I don't know
> what
> options to choose in the installer to not avoid it wanting to wipe
> whatever combinations of partitions I've set.
> 
> Michelle.
> 
> 
>  
> ___
> 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
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Partitions for co-exist NAS drive

[Reginald Beardsley via openindiana-discuss]

 
The text-install disk doesn't install X. I think the 2 text installers may not 
be the same, but have not verified that. They *should* be.

You can do all the stuff with format(1m) in single user mode. I use the GUI 
installer because I want the GUI and it is more convenient to have the MATE 
terminals.

I have an issue raised about the spurious 2 TB limit message. It's just that, a 
spurious message. It caused me a *lot* of confusion.

Reg

 On Saturday, May 1, 2021, 09:00:05 AM CDT, Michelle 
 wrote:  
 
 Thanks. I'll give that a go.

I'm using the text installer 2020.10 and on that, I can't create a
Solaris partition greater than 2tb.

I've got the GUI live image here somewhere.

Michelle.


On Sat, 2021-05-01 at 13:50 +, Reginald Beardsley via openindiana-
discuss wrote:
>  What release are you trying to install? I last did this using
> 2021.04.05, but I can easily verify the behavior with 2020.10.
> 
> I *strongly* recommend that you put all the disks you plan to use in
> the machine and run the text-installer from the Live Desktop. Select
> F2 on the first screen. When you get to the disk list, select all the
> disks. Make sure you don't have a USB stick plugged in. I wiped out
> mine by accident. Selecting multiple disks triggers the appearance of
> options to create a mirror, RAIDZ1 or RAIDZ2 depending on whether you
> have 2, 3 or 4 disks. Just make sure you select an EFI label, not MBR
> 
> Let it wipe out the partitions and create the 250 MB slice and the
> rest of disk slice. That *is* the best practice today. The mirrored
> root pool slice is a bodge for releases which can't boot from RAIDZ.
> 
> If for some reason you want to do something different this is the
> step by step recipe. It will give you exactly whatever you set up
> with format(1m). Because the F5 option is expecting to be used on an
> existing bootable pool it doesn't create dump and swap, so you have
> to do that by hand. The absence of /reconfigure was what beat me up
> for a week before I figured it out quite by accident.
> 
> All this is done in a terminal window after doing "sudo /bin/su" as
> jack.
> 
> > format -e
> # select disk
> > fdisk
> # create Solaris partition for entire drive and commit to disk
> > partition
> # create the desired slices 
> > label
> # write an EFI label
> > quit
> > verify
> > quit
> 
> You should now have a Sun EFI label with 9 slices. 8 is set by
> format(1m) and can't be changed. The other two should be the ones you
> created. You will need to do this for each disk and then check using
> prtvtoc(1m) that they all match. The disks don't need to match, but
> the slice sizes should.
> 
> I should note that format(1m) will not allow deleting a slice by
> setting the start and end to 0 easily. I have managed to do it, but
> I'm not sure what the correct incantation is. It gives "0 is out of
> range" messages most of the time.
> 
> In the first text installer screen chose F5, in the 2nd screen select
> the slice you want to use. Continue with the install. When It
> completes reboot to single user.
> 
> zfs create -V  rpool/dump rpool
> zfs create -V  rpool/swap rpool
> dumpadm -d /dev/zvol/dsk/rpool/dump
> swap -a /dev/zvol/dsk/rpool/swap
> touch /reconfigure
> init 6
> 
> Reg    On Saturday, May 1, 2021, 08:16:07 AM CDT, Michelle <
> miche...@msknight.com> wrote:  
>  
>  OK - I give in.
> 
> I've tried various combinations and I just can't get this into a
> configuration where I can get things installed.
> 
> I need a step by step guide please, because I'm lost. I don't know
> what
> options to choose in the installer to not avoid it wanting to wipe
> whatever combinations of partitions I've set.
> 
> Michelle.
> 
> 
> On Sat, 2021-05-01 at 15:42 +0300, Toomas Soome via openindiana-
> discuss 
> wrote:
> > > On 1. May 2021, at 15:30, Michelle  wrote:
> > > 
> > > That's where I'm becoming unstuck.
> > > 
> > > A Solaris 2 partition will only see the first 2Tb.
> > > 
> > > There hangs my first problem.
> > > 
> > > If I try and create any other partition it gives me the warning
> > > about
> > > the 2TB limit and if I then try and create the EFI partition, it
> > > won't
> > > co-exist with anything and wants to wipe the whole disk again.
> > > 
> > > Michelle.
> > 
> > MBR and GPT can not co-exist. On this disk, you need GPT and this
> > means, MBR partitions will be removed.
> > 
> > Rgds,
> > Toomas
> > 
> > > > On Sat, 2021-05-01 at 12:21 +, Reginald Beardsley via
> > > > openindiana-
> 

Re: [OpenIndiana-discuss] Partitions for co-exist NAS drive

[Reginald Beardsley via openindiana-discuss]

 Michelle,

What disks are you trying to use? If they are different sizes the recipe gets a 
bit more complex, but it's quite possible to get any arrangement for which you 
have a sufficient number of disks. Having spent 50 hours over 5 days battling 
the 2021.04.05 install I've had *lots* of practice installing both 2021.04.05 
and 2020.10.

Incidentally the failure of 2021.04.05 to run the nVIDIA driver is because it 
installed the wrong driver for that system.

Reg




On Saturday, May 1, 2021, 08:16:07 AM CDT, Michelle  
wrote:


OK - I give in.

I've tried various combinations and I just can't get this into a
configuration where I can get things installed.

I need a step by step guide please, because I'm lost. I don't know what
options to choose in the installer to not avoid it wanting to wipe
whatever combinations of partitions I've set.

Michelle.


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

Re: [OpenIndiana-discuss] Partitions for co-exist NAS drive

[Reginald Beardsley via openindiana-discuss]

 What release are you trying to install? I last did this using 2021.04.05, but 
I can easily verify the behavior with 2020.10.

I *strongly* recommend that you put all the disks you plan to use in the 
machine and run the text-installer from the Live Desktop. Select F2 on the 
first screen. When you get to the disk list, select all the disks. Make sure 
you don't have a USB stick plugged in. I wiped out mine by accident. Selecting 
multiple disks triggers the appearance of options to create a mirror, RAIDZ1 or 
RAIDZ2 depending on whether you have 2, 3 or 4 disks. Just make sure you select 
an EFI label, not MBR

Let it wipe out the partitions and create the 250 MB slice and the rest of disk 
slice. That *is* the best practice today. The mirrored root pool slice is a 
bodge for releases which can't boot from RAIDZ.

If for some reason you want to do something different this is the step by step 
recipe. It will give you exactly whatever you set up with format(1m). Because 
the F5 option is expecting to be used on an existing bootable pool it doesn't 
create dump and swap, so you have to do that by hand. The absence of 
/reconfigure was what beat me up for a week before I figured it out quite by 
accident.

All this is done in a terminal window after doing "sudo /bin/su" as jack.

> format -e
# select disk
> fdisk
# create Solaris partition for entire drive and commit to disk
> partition
# create the desired slices 
> label
# write an EFI label
> quit
> verify
> quit

You should now have a Sun EFI label with 9 slices. 8 is set by format(1m) and 
can't be changed. The other two should be the ones you created. You will need 
to do this for each disk and then check using prtvtoc(1m) that they all match. 
The disks don't need to match, but the slice sizes should.

I should note that format(1m) will not allow deleting a slice by setting the 
start and end to 0 easily. I have managed to do it, but I'm not sure what the 
correct incantation is. It gives "0 is out of range" messages most of the time.

In the first text installer screen chose F5, in the 2nd screen select the slice 
you want to use. Continue with the install. When It completes reboot to single 
user.

zfs create -V  rpool/dump rpool
zfs create -V  rpool/swap rpool
dumpadm -d /dev/zvol/dsk/rpool/dump
swap -a /dev/zvol/dsk/rpool/swap
touch /reconfigure
init 6

Reg On Saturday, May 1, 2021, 08:16:07 AM CDT, Michelle 
 wrote:  
 
 OK - I give in.

I've tried various combinations and I just can't get this into a
configuration where I can get things installed.

I need a step by step guide please, because I'm lost. I don't know what
options to choose in the installer to not avoid it wanting to wipe
whatever combinations of partitions I've set.

Michelle.


On Sat, 2021-05-01 at 15:42 +0300, Toomas Soome via openindiana-discuss 
wrote:
> > On 1. May 2021, at 15:30, Michelle  wrote:
> > 
> > That's where I'm becoming unstuck.
> > 
> > A Solaris 2 partition will only see the first 2Tb.
> > 
> > There hangs my first problem.
> > 
> > If I try and create any other partition it gives me the warning
> > about
> > the 2TB limit and if I then try and create the EFI partition, it
> > won't
> > co-exist with anything and wants to wipe the whole disk again.
> > 
> > Michelle.
> 
> MBR and GPT can not co-exist. On this disk, you need GPT and this
> means, MBR partitions will be removed.
> 
> Rgds,
> Toomas
> 
> > 
> > > On Sat, 2021-05-01 at 12:21 +, Reginald Beardsley via
> > > openindiana-
> > > discuss wrote:
> > > 
> > > I just went through several iterations of this, and like you the
> > > last
> > > time I had done it was long ago. The following is based on
> > > 2021.04.05.
> > > 
> > > Large disks require an EFI or GPT label. The gparted program
> > > creates
> > > 128 slices which is a bit much. format(1m) will also write an EFI
> > > label which is usable with large disks.
> > > 
> > > > format -e
> > > # select disk
> > > > fdisk
> > > # create Solaris partition for entire drive and commit to disk
> > > > partition
> > > # create the desired slices and write an EFI label
> > > > quit
> > > > verify
> > > > quit
> > > 
> > > You should now have a Sun EFI label with 9 slices. 8 is set by
> > > format(1m) and can't be changed. The other two should be the ones
> > > you
> > > created.
> > > 
> > > In the first text installer screen chose F5, in the 2nd screen
> > > select
> > > the slice you want to use. Continue with the install. When It
> > > completes reboot to single user.
> &g

Re: [OpenIndiana-discuss] Partitions for co-exist NAS drive

[Reginald Beardsley via openindiana-discuss]

 Toomas,

Thanks for the explanation. That certainly sounds like a good idea. It provides 
lots of flexibility.

It would nice if the text-installer allowed specifying the BE name when 
creating a fresh pool or defaulted to the release, e.g. 2021.04, instead of 
openindiana. The latter is not very informative.

I don't recommend the 100 GB root pool approach now that we can boot from RAIDZ 
unless some HW issue prevents using a RAIDZ root pool. If one installs updates 
using F5 you will run out of room fairly quickly unless you delete older BEs. 
Ten years ago I did it to avoid using a USB stick to boot an NL40 running a 4x 
2 TB disk RAIDZ2 configuration. It was also the only option with Solaris 10 u8 
that provided redundancy for the root pool and RAIDZ for the rest of the disk. 
It has served me well, but is no longer needed in most cases.

Reg




On Saturday, May 1, 2021, 07:40:37 AM CDT, Toomas Soome  wrote:

This is EFI System partition, that is partition, created with FAT file system, 
where UEFI firmware can load and start applications such as os boot loaders and 
firmware updates.

The 250MB is too large for illumos loader alone, but is allocated to allow 
storing of other applications too.

In fact, 250MB is picked to keep in mind 4k sector size disks, and is actually 
buggy value - it should be abort 260MB instead. The fix is still on my desk;)

Rgds,
Toomas

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

Re: [OpenIndiana-discuss] Partitions for co-exist NAS drive

[Reginald Beardsley via openindiana-discuss]

 
I just went through several iterations of this, and like you the last time I 
had done it was long ago. The following is based on 2021.04.05.

Large disks require an EFI or GPT label. The gparted program creates 128 slices 
which is a bit much. format(1m) will also write an EFI label which is usable 
with large disks.

> format -e
# select disk
> fdisk
# create Solaris partition for entire drive and commit to disk
> partition
# create the desired slices and write an EFI label
> quit
> verify
> quit

You should now have a Sun EFI label with 9 slices. 8 is set by format(1m) and 
can't be changed. The other two should be the ones you created.

In the first text installer screen chose F5, in the 2nd screen select the slice 
you want to use. Continue with the install. When It completes reboot to single 
user.

zfs create -V  rpool/dump rpool
zfs create -V  rpool/swap rpool
dumpadm -d /dev/zvol/dsk/rpool/dump
swap -a /dev/zvol/dsk/rpool/swap
touch /reconfigure
init 6

You should now come up with rpool in the 100 GB slice.

That said, we can boot from RAIDZ now. The text-install on the Desktop live 
image will let you create a mirror, RAIDZ1 or RAIDZ2 and will take care of all 
the label stuff. Despite the statement that it will only use 2 TB, it in fact 
uses the entire disk.

It creates a 250 MB s0 slice and the rest of the disk in s1. The 250 MB slice 
is labeled "System", but I've not seen any explanation of it. I've also created 
RAIDZ2 pools by hand and used F5 to install into them. F5 appears to be 
intended to install into a new BE in an existing pool, hence the need to set up 
dump and swap by hand.

Ultimately I decided I didn't care about 1 GB of unused space in 16 TB of 
space. So I just went with the text-install created RAIDZ2 pool. The 
reconfigure on the first boot after the install is critical to getting 
2021.04.05 up properly.

Reg
 On Saturday, May 1, 2021, 02:57:23 AM CDT, Michelle 
 wrote:  
 
 OK - I appear to be well out of touch.

I booted the installer and went into prompt.

Used format (only 1 x 6TB drive in the machine at this point) to create
a new Solaris 2 partition table and then fdisk'd an all free hog to
partition 1, giving partition 0 100gig. 

I noticed that it must have gone on for 40 odd partitions, and also
there was none of the usual backup and reserved partitions for 2, 8 and
9 as I saw before.

On installation of OI, I selected the drive and got the warning...
"you have chosen a gpt labelled disk. installing onto a gpt labelled
disk will cause the loss of all existing data"

Out of interest I continued through and got the options for whole disk
or partition (MBR) ... the second of which gave me a 2Tb Solaris 2
partition in the list.

I did try F5 to change partition, but it just took me straight back to
the installation menu at the start again.

Things have obviously moved on and I haven't kept pace.

I now have to work out how to do this on a gpt drive.

If anyone has any notes, I'd be grateful.

Michelle.


On Sat, 2021-05-01 at 08:31 +0100, Michelle wrote:
> Well, I looked over my notes and the last time I did this was in
> 2014.
> 
> My preference has always been to run OI on its own drive and have the
> main ZFS tank as a "whole drive" basis. However, thanks to the QNAP,
> that's changed.
> 
> In 2014 I did a test. I took two 40gig drives and did the partitions
> as
> an all free hog on partition 0 ... I was simply testing the ability
> to
> configure rpool on two drives and have both active, so if one failed
> the other would keep running the OS.
> 
> My immediate thought is to have 100gig for the OS on partition 0 and
> the rest on partition 1. Also, turn on auto expand for the tank pool
> and off for the rpool.
> 
> That's my gut feel.
> 
> Anyone got any advice to offer please, before I commit finger to
> keyboard?
> 
> Michelle.
> 
> 
> ___
> 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
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Does anyone have an example of service manifest XML file for znapzend?

[Reginald Beardsley via openindiana-discuss]

 
You might try looking at the Solaris 11.1 documentation. I downloaded all of it 
to my iPad today, but have not read it yet.

I found the smf facility rather opaque when I started looking at the files in 
/lib/svc.

Not a good answer, but it's all I know at present. Similarly, I want to do 
something dead simple, but have not yet found proper documentation.

Reg

 On Friday, April 30, 2021, 09:16:18 PM CDT, Judah Richardson 
 wrote:  
 
 Just wondering the above. There are no XML files I can use as an example in
/var/svc/manifest and the /usr/share/lib/xml/dtd/service_bundle.dtd.1 file
is rather obtuse.

Literally all I want to do is ensure znapzend starts at boot. Nothing
fancy.

Any help would be appreciated.

Judah
___
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] OI on USB flash drive

[Reginald Beardsley via openindiana-discuss]

 

While I don't have prior experience booting from flash drives, I agree with 
Till's recommendation to try a USB hard drive.

Have you tried installing to a regular disk drive and booting from that? If you 
can I recommend doing that and skipping the flash drive boot. The RAIDZ 
bootloader seems to work though I don't have the 10 years of experience I have 
with using 2 slices to provide a mirrored rpool and a RAIDZ export pool.

Reg
 On Friday, April 30, 2021, 05:22:03 PM CDT, Till Wegmueller 
 wrote:  
 
 Hi Michelle

I don't know how happy you are going to get with a QNAP Hardware as base 
for OI. QNAP is very exotic Hardware. It may be USB what they are using 
in princiapl, but unless you are sure the Controllers are actually the 
Controllers they are saying they are and the Storage is not a SD card in 
Hiding, you are going to have a bad time. ZFS does not assume the 
Storage to be uncorruptable, and thus far every SD-Card I found was so 
terrible, that one meeting with ZFS showed just how much dataloss these 
cards have.

QNAP and Synology usually use RAMDISK based approaches which run fully 
in RAM and only use the Storage to boot.

SmartOS does the same, so this could work.

In my career and with friends I have seen many OS installation to USB 
drives and SD-cards go horribly wrong. Those storage Options usually 
don't survive for long and then the whole OS is gone. I've seen it with 
FreeNAS(FreeBSD), Linux and illumos based Oses. I use Disks or SSD's as 
Storage for the Pools. The Cable can be USB. But it needs to be a Disk 
and not a flashdrive to at least Guarantee some use.

My Hardware recommendations for Cheap Home Servers for NAS on a budget 
include HP Microservers Gen8 (Gen10 works too, but they spew warnings on 
boot) SuperMicro Mini-ITX Boards. HP Workstations, or Workstations and 
Gaming and Office Rigs in general and of course Dan McDonalds HDC3.0 [0]

-Till

[0] https://kebe.com/blog/?tag=HDC

On 30.04.21 17:19, Michelle wrote:
> Good suggestions, but sadly didn't work.
> 
> Using option 2 single user also fails with the same errors.
> 
> I've also tried the USB interface in various booting modes,
> unfortunately none of which work.
> 
> I took a look at the variables in the boot options, just for the sake
> of it, and couldn't find anything obvious that would help
> 
> Michelle.
> 
> On Fri, 2021-04-30 at 20:00 +0000, Reginald Beardsley via openindiana-
> discuss wrote:
>>  Try selecting the "reconfigure" option when you first boot the
>> installed image.
>>
>> It is *supposed* to reconfigure, but I spent 50 hrs before I found
>> out how to get 2021.04.05 to boot after the install. I thought the
>> issue was the particular nVIDIA driver, but that was not the case.
>>
>> I also got a fresh install of 2021.04.05 to boot properly by coming
>> up single user, "touch /reconfigure; init 6".
>>
>> Good luck,
>> Reg
>>
>>
>>      On Friday, April 30, 2021, 02:50:50 PM CDT, Michelle <
>> miche...@msknight.com> wrote:
>>  
>>  OK, this is where things are going to get a bit awkward.
>>
>> Scenario – QNAP NAS TS-251 decided to install their own Malware
>> Remover
>> which tells me it’s removed files, but doesn’t tell me which ones
>> it’s
>> removed, and I can’t kill the remover itself. If I Ssh in and remove
>> it, it simply re-installs itself. I'm not a fan of malware removers
>> that don't tell you what files they've removed.
>>
>> So… the decision to rip it apart and install my own operating system.
>> After all, it’s on an American Megatrends bios.
>>
>> The 2gig of RAM was replaced with 8, and the storage is a half gig
>> USB
>> flash module. So the flash module has to be replaced also.
>>
>> I thus have a USB header unit and I’ve also tried to install Hipster
>> to
>> a flash drive connected via a USB harness, and also to a USB key
>> directly.
>>
>> On install, I get an error…
>>
>> openindiana drm: WARNING: [drm:pci_dev_create:93] ddi_prop_get_int()
>> failed
>>
>> … which repeats three or four times during the installation.
>>
>> After installation is finished, the installation OS goes down, but
>> says…
>>
>> openindiana genunix:WARNING: xhci has no quiesce()
>> reboot: not all drivers have implemented quiesce(9E)
>> Please see veradm/messages for drivers that haven’t implemented
>> quiesce(9E)
>> Failed to process boot arguments from Boot Environment.
>> Falling back to regular reboot
>>
>> Then on reboot, the boot comes up but gives…
>>
>> WARNING: pci@0,0pci8086,f35@14/storage@3/disk@0,0 (sd0):
>> Commend failed to complete… Device is gone
>> Wa

Re: [OpenIndiana-discuss] OI on USB flash drive

[Reginald Beardsley via openindiana-discuss]

 The install completed normally. On the first boot attempt I selected every 
boot option *except* graphical console. It stalled part way with SCSI time 
outs. I inadvertently dropped the power while messing with other stuff.

In the 2nd boot attempt I selected *all* the boot options in 2021.04.05. This 
time it came up to single user mode. I logged in as root and took a quick look 
at the pool and when I hit ^d it came up and started lightdm.

It did *not* install the nVIDIA driver, but is otherwise fully functional. 
Running "nvidia-xconfig" hosed lightdm and I've not been able to restart that. 
Deleting /etc/xorg.conf and doing an "init 6" fixed it and I came up with 
lightdm running and 1600x1200 resolution in landscape mode.

I don't know if this helps or not. There is clearly something strange going on. 
I just tried a reboot using the same options as the first time after the 
install. It came up all the way when I hit ^d at the single user prompt.


Reg




On Friday, April 30, 2021, 04:21:19 PM CDT, Reginald Beardsley via 
openindiana-discuss  wrote:


I've started an install of 2021.04.05 to a 32 GB flash drive on a Z400. I'll 
see if that provides any information. I used the text installer from the GUI 
desktop, so it will be slow.

My 8 port KVM switch died so most of my systems were down. The replacement, a 4 
port dual monitor KVM switch came today. Then I discovered that I also need 
Display Port to VGA adapters :-(

When I set up my NL40 it was not possible to boot from a RAIDZ, so the popular 
wisdom was to use a USB flash drive for the root pool. I didn't like that so I 
created a 100 GB rpool slice in s0 and the rest of the disk in s1.

After installing into the rpool, I created a 4 way mirror and a 4 disk RAIDZ2 
array.

I recently rebuilt it using a single RAIDZ2 array to verify we could now boot 
from RAIDZ. It worked fine.


I'll post once the install finishes and I've had time to mess with it a bit. I 
assume you've checked that the BIOS will allow USB boot.

IIRC the Z400 would not boot from the USB Live Image. So I don't hold out a lot 
of hope, but it's not much effort for me to give it a try.

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

Re: [OpenIndiana-discuss] OI on USB flash drive

[Reginald Beardsley via openindiana-discuss]

 I've started an install of 2021.04.05 to a 32 GB flash drive on a Z400. I'll 
see if that provides any information. I used the text installer from the GUI 
desktop, so it will be slow.

My 8 port KVM switch died so most of my systems were down. The replacement, a 4 
port dual monitor KVM switch came today. Then I discovered that I also need 
Display Port to VGA adapters :-(

When I set up my NL40 it was not possible to boot from a RAIDZ, so the popular 
wisdom was to use a USB flash drive for the root pool. I didn't like that so I 
created a 100 GB rpool slice in s0 and the rest of the disk in s1.

After installing into the rpool, I created a 4 way mirror and a 4 disk RAIDZ2 
array.

I recently rebuilt it using a single RAIDZ2 array to verify we could now boot 
from RAIDZ. It worked fine.


I'll post once the install finishes and I've had time to mess with it a bit. I 
assume you've checked that the BIOS will allow USB boot.

IIRC the Z400 would not boot from the USB Live Image. So I don't hold out a lot 
of hope, but it's not much effort for me to give it a try.

Reg

 On Friday, April 30, 2021, 03:20:15 PM CDT, Michelle 
 wrote:  
 
 Good suggestions, but sadly didn't work.

Using option 2 single user also fails with the same errors.

I've also tried the USB interface in various booting modes,
unfortunately none of which work.

I took a look at the variables in the boot options, just for the sake
of it, and couldn't find anything obvious that would help

Michelle.

On Fri, 2021-04-30 at 20:00 +, Reginald Beardsley via openindiana-
discuss wrote:
>  Try selecting the "reconfigure" option when you first boot the
> installed image. 
> 
> It is *supposed* to reconfigure, but I spent 50 hrs before I found
> out how to get 2021.04.05 to boot after the install. I thought the
> issue was the particular nVIDIA driver, but that was not the case.
> 
> I also got a fresh install of 2021.04.05 to boot properly by coming
> up single user, "touch /reconfigure; init 6".
> 
> Good luck,
> Reg
> 
> 
>      On Friday, April 30, 2021, 02:50:50 PM CDT, Michelle <
> miche...@msknight.com> wrote:  
>  
>  OK, this is where things are going to get a bit awkward.
> 
> Scenario – QNAP NAS TS-251 decided to install their own Malware
> Remover
> which tells me it’s removed files, but doesn’t tell me which ones
> it’s
> removed, and I can’t kill the remover itself. If I Ssh in and remove
> it, it simply re-installs itself. I'm not a fan of malware removers
> that don't tell you what files they've removed.
> 
> So… the decision to rip it apart and install my own operating system.
> After all, it’s on an American Megatrends bios.
> 
> The 2gig of RAM was replaced with 8, and the storage is a half gig
> USB
> flash module. So the flash module has to be replaced also.
> 
> I thus have a USB header unit and I’ve also tried to install Hipster
> to
> a flash drive connected via a USB harness, and also to a USB key
> directly.
> 
> On install, I get an error…
> 
> openindiana drm: WARNING: [drm:pci_dev_create:93] ddi_prop_get_int()
> failed
> 
> … which repeats three or four times during the installation.
> 
> After installation is finished, the installation OS goes down, but
> says…
> 
> openindiana genunix:WARNING: xhci has no quiesce()
> reboot: not all drivers have implemented quiesce(9E)
> Please see veradm/messages for drivers that haven’t implemented
> quiesce(9E)
> Failed to process boot arguments from Boot Environment.
> Falling back to regular reboot
> 
> Then on reboot, the boot comes up but gives…
> 
> WARNING: pci@0,0pci8086,f35@14/storage@3/disk@0,0 (sd0):
> Commend failed to complete… Device is gone
> Warning: Pool “rpool” has encountered an uncorrectable I/O failure
> and
> has been suspended; “zpool clear” will be required before the poor
> can
> be written to.
> Warning: pci@0,0/pci8086/f35@14/storage@3 (scsa2usb0): Reinserted
> device is accessible again.
> Warning: Pool “rpool” has encountered an incorrectable I/O failure
> and
> has been suspended; “zpool clear” will be required before the poor
> can
> be written to.
> 
> ...that last repeats three times and the unit sits there.
> 
> I did try searching for devices with no drivers, but the only thing
> that came up were the two processor cores. 
> 
> I did try creating a Solaris 2 partition and installing to a
> partition
> instead of the EFI whole disk option, but that failed on fdisk and
> didn’t even install the files. I had to destroy the partition table
> in
> order to get back to getting the installation to work.
> 
> Also, in the installer, when I tried to go to a partition
> installation
> and pressed F5 to change the partition type,

Re: [OpenIndiana-discuss] OI on USB flash drive

[Reginald Beardsley via openindiana-discuss]

 Try selecting the "reconfigure" option when you first boot the installed 
image. 

It is *supposed* to reconfigure, but I spent 50 hrs before I found out how to 
get 2021.04.05 to boot after the install. I thought the issue was the 
particular nVIDIA driver, but that was not the case.

I also got a fresh install of 2021.04.05 to boot properly by coming up single 
user, "touch /reconfigure; init 6".

Good luck,
Reg


 On Friday, April 30, 2021, 02:50:50 PM CDT, Michelle 
 wrote:  
 
 OK, this is where things are going to get a bit awkward.

Scenario – QNAP NAS TS-251 decided to install their own Malware Remover
which tells me it’s removed files, but doesn’t tell me which ones it’s
removed, and I can’t kill the remover itself. If I Ssh in and remove
it, it simply re-installs itself. I'm not a fan of malware removers
that don't tell you what files they've removed.

So… the decision to rip it apart and install my own operating system.
After all, it’s on an American Megatrends bios.

The 2gig of RAM was replaced with 8, and the storage is a half gig USB
flash module. So the flash module has to be replaced also.

I thus have a USB header unit and I’ve also tried to install Hipster to
a flash drive connected via a USB harness, and also to a USB key
directly.

On install, I get an error…

openindiana drm: WARNING: [drm:pci_dev_create:93] ddi_prop_get_int()
failed

… which repeats three or four times during the installation.

After installation is finished, the installation OS goes down, but
says…

openindiana genunix:WARNING: xhci has no quiesce()
reboot: not all drivers have implemented quiesce(9E)
Please see veradm/messages for drivers that haven’t implemented
quiesce(9E)
Failed to process boot arguments from Boot Environment.
Falling back to regular reboot

Then on reboot, the boot comes up but gives…

WARNING: pci@0,0pci8086,f35@14/storage@3/disk@0,0 (sd0):
Commend failed to complete… Device is gone
Warning: Pool “rpool” has encountered an uncorrectable I/O failure and
has been suspended; “zpool clear” will be required before the poor can
be written to.
Warning: pci@0,0/pci8086/f35@14/storage@3 (scsa2usb0): Reinserted
device is accessible again.
Warning: Pool “rpool” has encountered an incorrectable I/O failure and
has been suspended; “zpool clear” will be required before the poor can
be written to.

...that last repeats three times and the unit sits there.

I did try searching for devices with no drivers, but the only thing
that came up were the two processor cores. 

I did try creating a Solaris 2 partition and installing to a partition
instead of the EFI whole disk option, but that failed on fdisk and
didn’t even install the files. I had to destroy the partition table in
order to get back to getting the installation to work.

Also, in the installer, when I tried to go to a partition installation
and pressed F5 to change the partition type, it would go back to the
installation menu again, so I’m presuming that it just doesn’t like the
USB as a target.

I’ve got an ugly feeling that I’ve got no way of getting around this. 
Yes, I know I can put the SATA drives in and make a slice for rpool,
but where’s the fun in that?


___
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

[OpenIndiana-discuss] X startup/shutdown questions

[Reginald Beardsley via openindiana-discuss]

What service starts the MATE environment?  I've been unable to locate what 
starts that.  And generally unable to determine how exactly what any service 
does is specified.

I'd expected "init 2" in single user mode to take me to multi-user console 
mode, but it did not.  However, I was able to disable lightdm, come up to a 
multiuser console, login and start X and twm using startx(1) and the .xinitrc 
file on the command line.  However, when I exited twm it did not return to the 
login console.  What controls that?  Do I need something in .xinitrc?  I never 
did it that way but I remember it could be done.

I haven't messed with this in 15+ years.  I'm happy to say it appears that 
significant progress has been made.  The implementation of CDE was rather 
painful as was Motif.  So much so that I've been disinclined to even look at it 
for a long time.  Kudos to those who fixed it.

Firefox under twm did generate a GDK resource unavailable error in a short 
test, but that's mild compared to what I recall seeing if I started Netscape 
outside of the dtwm environment.  It almost certainly had to be dumping core 
for me to labor through starting separate window managers on each screen.

Reg

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

Re: [OpenIndiana-discuss] VBox on top of Hipster and twm?

[Reginald Beardsley via openindiana-discuss]

 

Thank you! That's great news. The reason I ran dtwm and twm side by side was 
Netscape wouldn't run properly on twm. Too many hooks into Motif.

I'd like to shift all my Internet access to a VM with the base system running 
OI on RAIDZ2.

Reg On Tuesday, April 27, 2021, 12:50:16 AM CDT, Stephan Althaus 
 wrote:  
 
 On 04/27/21 12:19 AM, Reginald Beardsley via openindiana-discuss wrote:
> I'd like to run Hipster in a VBox VM for web access with twm as the window 
> manager for the host.
>
> Is this likely to be possible, i.e. how much window manager stuff does VBox 
> require?  If not I can revert to using 2 window managers,  but I'd rather not 
> if I can avoid the added complexity and limitations.  You can't move windows 
> between screens if you are running 2 window managers.
>
> Reg
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss

Hi!

The window manager should have no effect on the X-application itself. i 
just tested VBox with twm by switching the window manager whilst working 
in the Mate-Desktop-Environment

pkill marco && twm

It works.

Stephan



___
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] TeX Live 2021 available for OpenIndiana

[Reginald Beardsley via openindiana-discuss]

 
I should also like to thank you. I use groff and TeX. Groff for short memoranda 
and TeX for almost everything else.

Reading the old Bell Labs papers I fell in love with the style they used for 
technical papers.

Have Fun!
Reg

 On Monday, April 26, 2021, 07:33:29 PM CDT, Jason Martin 
 wrote:  
 
 Thank you, for your time and effort.

I still prefer Tex to GUI stuff.



___
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

[OpenIndiana-discuss] VBox on top of Hipster and twm?

[Reginald Beardsley via openindiana-discuss]

I'd like to run Hipster in a VBox VM for web access with twm as the window 
manager for the host.  

Is this likely to be possible, i.e. how much window manager stuff does VBox 
require?  If not I can revert to using 2 window managers,  but I'd rather not 
if I can avoid the added complexity and limitations.  You can't move windows 
between screens if you are running 2 window managers.

Reg

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

Re: [OpenIndiana-discuss] OI-hipster-gui-20210405.iso and OVirt/QEMU status report

[Reginald Beardsley via openindiana-discuss]

 Nelson,

Thank you for testing this.

I elected to install 2020.10 to use as a base for learning how to update the 
system without reinstalling if that is possible.

I *think* the network menu bar icon is supposed to start /usr/lib/nwam-manager. 
I get a dialog popup using 2020.10 that asks for authorization to run that as 
root. 

However, I've had mixed results using it. At one point the Z840 was not 
connecting. Refresh seemed to do nothing, so I created a copy of the Automatic 
profile. That seemed to run when selected, but then Automatic ran.

I just tried using it to create a static IP address for the Z840. That set it 
to "NoNet" which "ifconfig -a" confirms. 

I only recently started using DHCP at all and have no useful experience with 
nwam. If I try to examine the "User" profile I created I can't see any 
information at all. 

I was after some fiddle able to get it to connect. I can ping my router and do 
an nslookup of google.com, but Firefox can't do the DNS lookup. Nslookup uses 
my router as a DNS proxy.

Not much help I'm afraid. Perhaps someone who knows more about nwam will post.

Reg


 On Monday, April 26, 2021, 12:21:44 PM CDT, Nelson H. F. Beebe 
 wrote:  
 
 This report follows earlier ones under the subject "The kiss of death"
that supplied installation reports for virt-manager/QEMU on CentOS 7
and Ubuntu 20.04, and VirtualBox on another Ubuntu 20.04 system.  This
one is fairly positive, so I felt it deserved a new subject line.

Today, I successfully installed OpenIndiana Hipster from

    http://dlc.openindiana.org/isos/hipster/test/OI-hipster-gui-20210405.iso

on OVirt/QEMU running on CentOS Linux release 7.6.1810 (Core).

As I noted in an earlier report, this virtualization system has the
advantage of live VM migration, at a cost of considerably more complex
VM creation and management.  However, once a VM has been successfully
installed, the platform has been rock solid, and we routinely use the
VM migration feature to move VMs off one server to another, run system
updates on the first, reboot, and move back its VMs, without the VMs
even noticing their two moves.

I took both OVirt snapshots and ZFS snapshots during the installation
steps, with multiple reboots, and have now successfully copied over
/var/opt, /opt/csw, and $prefix/texlive/2021 trees from other systems.

No boot problems have been observed this time.

However, there are a few other problems with OpenIndiana Hipster on
OVirt:

(1) Ovirt offers three console types: QXL (default), VGA, and CIRRUS.

    With QXL, the GUI desktop is too high to fit on the screen. Moving
    the mouse near the bottom edge slides up the display to make the
    bottom task bar visible.  Moving the mouse near the top edge makes
    the top menu bar only partly visible.  However, in neither case
    can the mouse select icons.  

    I shut down the system, changed to VGA, and found the same
    behavior as with QXL.

    I again shut down the system, changed to CIRRUS, rebooted, logged
    in, and now the screen is fully visible, but the mouse cannot
    select actions from the menu bar or tool bar.  Curiously, moving
    the mouse over a toolbar item, such as the network icon, produces
    a yellow popup window that describes the button.  One just cannot
    select it.

    With all three video types, there are generally two mouse cursors
    on the screen, but with CIRRUS, they remain within 5mm of each
    other.

    Those mouse problems make the desktop almost unusable.  With the
    mouse in the central region of the screen, I can get a popup menu
    from which I can start a terminal.  However, the Applications /
    Places / System / Network / ... menu bar items are unusable.

    Unlike VirtManager and VirtualBox, which have menu buttons to send
    Ctl-Alt-Fn and Ctl-Alt-DELete input to the VM, the OVirt button
    can only send Ctl-Alt-DELete, so there is no way to select
    alternate consoles that are supported by most operating systems.

    With another VM installed on virt-manager/QEMU on Ubuntu 20.04,
    there were no such icon selection problems, and I was able to
    reconfigure that system for static IPv4 addressing.

    If someone knows what program is started by clicking on the
    network menubar icon, please report it; I've never had much
    success with manual changes to files in the /etc/ tree on Solaris
    family systems to switch between DHCP-assigned and static IP
    addresses.

(2) During the installation, I selected Denver, CO, USA, from the
    world map, and it definitely showed that choice in the text bar
    under the map.  However, when the system rebooted, the timezone
    was still UTC, the clock was off by hours, and /etc/localtime did
    not exist.  The OVirt control panel shows the clock should be a
    hardware clock set to "(GMT-00:00) GMT Standard Time".  I fixed
    that problem by

    # ln -s /usr/share/lib/zoneinfo/America/Denver /etc/localtime
    # ntpdate time1.google.com

Re: [OpenIndiana-discuss] Initial install of 2020.10 on Z840 for production use

[Reginald Beardsley via openindiana-discuss]

 ROFL! I just noticed I didn't speciy a count. It had written 5.5 TB at over 
200 MB/s and would have continued until I filled all 6.7 TB of space.

I assume *nothing* about computers. I assert that the difference between a 
senior and junior person is the junior person makes assumptions that the senior 
person has learned not to make. No computer is like any other unless great 
effort has gone into making certain that they are.

I'm not familiar with the Solaris tunable parameters as I've never needed to 
look at them. The degradation of interactive response is still a big concern. 
However, it may not be possible to fix that in the Unix fork-exec model.

Long ago I set up a MicroVAX II so it would run batch jobs without adverse 
impact on interactive users. We ran it for months at 100% CPU utilization, but 
when an interactive user logged in it behaved as if the machine was idle. It 
took a lot of reading the Great Grey Wall of VMS manuals to figure out how to 
do that, but it was well worth it. Prior to that other grad students would 
start jobs that made the machine unusable for interactive use for days. The 
rough limit on our batch jobs was 70-100 hrs of CPU time. Because interactive 
use requires so few resources other than memory, the effect of reserving memory 
for interactive users had not discernable effect on batch throughput. 
WS_EXTENT, WS_QUOTA, etc were my best friends. I reserved enough space for a 
login that the editor did not get swapped to disk. Without very complex 
bookkeeping that is not possible without using a transient process space model 
instead of fork-exec.

For many years controlling resident memory was the feature I thought Unix 
needed most, but I eventually realized how difficult that would be to 
implement. I *think* it could be done at session level, but I haven't 
considered the problem in a *very* long time. And Unix is not the same as it 
was when I did.

Reg


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

Re: [OpenIndiana-discuss] Initial install of 2020.10 on Z840 for production use

[Reginald Beardsley via openindiana-discuss]

 rhb@Z840:~$ fmdump -eVp
TIME CLASS
Apr 25 2021 04:49:11.489928901 ereport.io.pci.fabric
nvlist version: 0
 class = ereport.io.pci.fabric
 ena = 0x3c55f1898004c01
 detector = dev:pci@0,0/pci8086,6f02@1
 bdf = 0x8
 device_id = 0x6f02
 vendor_id = 0x8086
 rev_id = 0x1
 dev_type = 0x40
 pcie_off = 0x90
 pcix_off = 0x0
 aer_off = 0x148
 ecc_ver = 0x0
 pci_status = 0x10
 pci_command = 0x47
 pci_bdg_sec_status = 0x0
 pci_bdg_ctrl = 0x3
 pcie_status = 0x0
 pcie_command = 0x27
 pcie_dev_cap = 0x8001
 pcie_adv_ctl = 0xa0
 pcie_ue_status = 0x0
 pcie_ue_mask = 0x18
 pcie_ue_sev = 0x62030
 pcie_ue_hdr0 = 0x0
 pcie_ue_hdr1 = 0x0
 pcie_ue_hdr2 = 0x0
 pcie_ue_hdr3 = 0x0
 pcie_ce_status = 0x0
 pcie_ce_mask = 0x0
 pcie_rp_status = 0x0
 pcie_rp_control = 0x0
 pcie_adv_rp_status = 0x0
 pcie_adv_rp_command = 0x7
 pcie_adv_rp_ce_src_id = 0x0
 pcie_adv_rp_ue_src_id = 0x0
 remainder = 0x0
 severity = 0x1
 __ttl = 0x1
 __tod = 0x60853b17 0x1d33b8c5

Apr 25 2021 04:49:14.680709384 ereport.io.pci.fabric
nvlist version: 0
 class = ereport.io.pci.fabric
 ena = 0x3d1420fbc305801
 detector = dev:pci@0,0/pci8086,8d10@1c
 bdf = 0xe0
 device_id = 0x8d10
 vendor_id = 0x8086
 rev_id = 0xd5
 dev_type = 0x40
 pcie_off = 0x40
 pcix_off = 0x0
 aer_off = 0x0
 ecc_ver = 0x0
 pci_status = 0x10
 pci_command = 0x47
 pci_bdg_sec_status = 0x0
 pci_bdg_ctrl = 0x3
 pcie_status = 0x10
 pcie_command = 0x7
 pcie_dev_cap = 0x8000
 pcie_rp_status = 0x0
 pcie_rp_control = 0x0
 remainder = 0x0
 severity = 0x1
 __ttl = 0x1
 __tod = 0x60853b1a 0x2892cd08

Apr 25 2021 04:49:14.717352076 ereport.io.pci.fabric
nvlist version: 0
 class = ereport.io.pci.fabric
 ena = 0x3d16501b4705801
 detector = dev:pci@0,0/pci8086,8d10@1c
 bdf = 0xe0
 device_id = 0x8d10
 vendor_id = 0x8086
 rev_id = 0xd5
 dev_type = 0x40
 pcie_off = 0x40
 pcix_off = 0x0
 aer_off = 0x0
 ecc_ver = 0x0
 pci_status = 0x10
 pci_command = 0x47
 pci_bdg_sec_status = 0x0
 pci_bdg_ctrl = 0x3
 pcie_status = 0x10
 pcie_command = 0x7
 pcie_dev_cap = 0x8000
 pcie_rp_status = 0x0
 pcie_rp_control = 0x0
 remainder = 0x0
 severity = 0x1
 __ttl = 0x1
 __tod = 0x60853b1a 0x2ac1ec8c

Apr 25 2021 06:08:40.003509148 ereport.io.pci.fabric
nvlist version: 0
 class = ereport.io.pci.fabric
 ena = 0x1962d818141
 detector = dev:pci@0,0/pci8086,6f02@1
 bdf = 0x8
 device_id = 0x6f02
 vendor_id = 0x8086
 rev_id = 0x1
 dev_type = 0x40
 pcie_off = 0x90
 pcix_off = 0x0
 aer_off = 0x148
 ecc_ver = 0x0
 pci_status = 0x10
 pci_command = 0x47
 pci_bdg_sec_status = 0x0
 pci_bdg_ctrl = 0x3
 pcie_status = 0x0
 pcie_command = 0x27
 pcie_dev_cap = 0x8001
 pcie_adv_ctl = 0xa0
 pcie_ue_status = 0x0
 pcie_ue_mask = 0x18
 pcie_ue_sev = 0x62030
 pcie_ue_hdr0 = 0x0
 pcie_ue_hdr1 = 0x0
 pcie_ue_hdr2 = 0x0
 pcie_ue_hdr3 = 0x0
 pcie_ce_status = 0x0
 pcie_ce_mask = 0x0
 pcie_rp_status = 0x0
 pcie_rp_control = 0x0
 pcie_adv_rp_status = 0x0
 pcie_adv_rp_command = 0x7
 pcie_adv_rp_ce_src_id = 0x0
 pcie_adv_rp_ue_src_id = 0x0
 remainder = 0x0
 severity = 0x1
 __ttl = 0x1
 __tod = 0x60854db8 0x358b9c

Apr 25 2021 06:09:41.850910327 ereport.io.pci.fabric
nvlist version: 0
 class = ereport.io.pci.fabric
 ena = 0x27c93c883000c01
 detector = dev:pci@0,0/pci8086,8d10@1c
 bdf = 0xe0
 device_id = 0x8d10
 vendor_id = 0x8086
 rev_id = 0xd5
 dev_type = 0x40
 pcie_off = 0x40
 pcix_off = 0x0
 aer_off = 0x0
 ecc_ver = 0x0
 pci_status = 0x10
 pci_command = 0x47
 pci_bdg_sec_status = 0x0
 pci_bdg_ctrl = 0x3
 pcie_status = 0x10
 pcie_command = 0x7
 pcie_dev_cap = 0x8000
 pcie_rp_status = 0x0
 pcie_rp_control = 0x0
 remainder = 0x0
 severity = 0x1
 __ttl = 0x1
 __tod = 0x60854df5 0x32b7dc77

Apr 25 2021 06:09:41.887552857 ereport.io.pci.fabric
nvlist version: 0
 class = ereport.io.pci.fabric
 ena = 0x27cb6ba74800c01
 detector = dev:pci@0,0/pci8086,8d10@1c
 bdf = 0xe0
 device_id = 0x8d10
 vendor_id = 0x8086
 rev_id = 0xd5
 dev_type = 0x40
 pcie_off = 0x40
 pcix_off = 0x0
 aer_off = 0x0
 ecc_ver = 0x0
 pci_status = 0x10
 pci_command = 0x47
 pci_bdg_sec_status = 0x0
 pci_bdg_ctrl = 0x3
 pcie_status = 0x10
 pcie_command = 0x7
 pcie_dev_cap = 0x8000
 pcie_rp_status = 0x0
 pcie_rp_control = 0x0
 remainder = 0x0
 severity = 0x1
 __ttl = 0x1
 __tod = 0x60854df5 0x34e6fb59

rhb@Z840:~$ 



 On Sunday, April 25, 2021, 04:27:12 PM CDT, Joshua M. Clulow 
 wrote:  
 
 On Sun, 25 Apr 2021 at 13:46, Reginald Beardsley via
openindiana-discuss  wrote:
> I've done a fresh install using the text installer on a 14 core E5-2680 V4 
> system with 72 GB of ECC DRAM and a 4x 4 TB 7200 rpm RAIDZ2 array.  With 
> reconfigure set on the post install boot it all came up fine.

It's possible that the installer is not creating the /reconfigure file
in the image that is being unpacked?  It would be worth checking to
make sure.  The first boot in a new machine after the install is
complete should always be a reconfigure reboot, even though that means
less and less these days.

> The prior install of 2021.04-rc1 gave ~220 MB/s for reads and writes an

Re: [OpenIndiana-discuss] Initial install of 2020.10 on Z840 for production use

[Reginald Beardsley via openindiana-discuss]

 Here's some info. The dd of /dev/zero is still running after almost 6 hours 
which is mind boggling, because before the 2020.10 install 2021.01-rc1 did it 
in ~1:11. I want to let it finish before I take it down and pull the 8 GB DIMM. 
It's quite singular. I've never seen anything like this before. But that's true 
of the whole experience with this machine.

I'll verify by booting a Z400, but I'm fairly certain that the text installer 
is not creating the /reconfigure file as it should. I've not had a failure 
since I specified the reconfigure option at first boot.

I've done all the experiments I can stand with the Z840. I just want it up and 
in production or on its way back to the seller. I have no desire to fight the 
"missing driver" battle.

Most likely the 8 GB DIMM is the cause of the glacial behavior.

Reg


rhb@Z840:~$ prtconf -D
System Configuration: Hewlett-Packard i86pc
Memory size: 73645 Megabytes
System Peripherals (Software Nodes):

i86pc (driver name: rootnex)
 scsi_vhci, instance #0 (driver name: scsi_vhci)
 disk, instance #1 (driver name: sd)
 disk, instance #2 (driver name: sd)
 disk, instance #3 (driver name: sd)
 disk, instance #4 (driver name: sd)
 pci, instance #0 (driver name: npe)
 pci103c,2129
 pci8086,6f02, instance #0 (driver name: pcieb)
 pci103c,158b, instance #0 (driver name: mpt_sas)
 iport, instance #1 (driver name: mpt_sas)
 iport, instance #2 (driver name: mpt_sas)
 iport, instance #3 (driver name: mpt_sas)
 iport, instance #4 (driver name: mpt_sas)
 iport, instance #5 (driver name: mpt_sas)
 pci8086,6f03 (driver name: pcieb)
 pci8086,6f04 (driver name: pcieb)
 pci8086,6f08, instance #3 (driver name: pcieb)
 display, instance #0 (driver name: nvidia)
 pci10de,965, instance #1 (driver name: audiohd)
 pci8086,6f28
 pci8086,6f29
 pci8086,6f2a
 pci8086,0
 pci103c,2129
 pci103c,2129, instance #0 (driver name: ahci)
 pci103c,2129, instance #0 (driver name: xhci)
 mouse, instance #0 (driver name: hid)
 keyboard, instance #1 (driver name: hid)
 hub, instance #2 (driver name: hubd)
 pci103c,2129
 pci103c,2129
 pci103c,2129, instance #0 (driver name: e1000g)
 pci103c,2129, instance #0 (driver name: ehci)
 hub, instance #0 (driver name: hubd)
 pci103c,2129, instance #0 (driver name: audiohd)
 pci8086,8d10, instance #4 (driver name: pcieb)
 pci103c,2129, instance #0 (driver name: igb)
 pci8086,8d16 (driver name: pcieb)
 pci8086,8d18 (driver name: pcieb)
 pci103c,2129, instance #1 (driver name: ehci)
 hub, instance #1 (driver name: hubd)
 isa, instance #0 (driver name: isa)
 asy, instance #0 (driver name: asy)
 i8042, instance #0 (driver name: i8042)
 mouse, instance #0 (driver name: mouse8042)
 keyboard, instance #0 (driver name: kb8042)
 tpm, instance #0 (driver name: tpm)
 pit_beep, instance #0 (driver name: pit_beep)
 pci103c,2129, instance #1 (driver name: ahci)
 cdrom, instance #0 (driver name: sd)
 pci103c,2129
 ioapics
 ioapic, instance #0
 pci, instance #1 (driver name: npe)
 pci8086,6f81
 pci8086,6f36
 pci8086,6f37
 pci8086,6f76
 pci8086,6fe0
 pci8086,6fe1
 pci8086,6fe2
 pci8086,6fe3
 pci8086,6fe4
 pci8086,6fe5
 pci8086,6fe6
 pci8086,6fe7
 pci8086,6fe8
 pci8086,6fe9
 pci8086,6fea
 pci8086,6feb
 pci8086,6fec
 pci8086,6fed
 pci8086,6ff8
 pci8086,6ff9
 pci8086,6ffa
 pci8086,6ffb
 pci8086,6fe0
 pci8086,6fe0
 pci8086,6fe0
 pci8086,6f1d
 pci8086,6f34
 pci8086,6f1e
 pci8086,6f7d
 pci8086,6f1f
 pci8086,6fa0
 pci8086,6f30
 pci8086,6f60
 pci8086,6f38
 pci8086,6fa8
 pci8086,6f71
 pci8086,6faa
 pci8086,6fab
 pci8086,6fae
 pci8086,6faf
 pci8086,6fb0
 pci8086,6fb1
 pci8086,6fb2
 pci8086,6fb3
 pci8086,6fbc
 pci8086,6fbd
 pci8086,6fbe
 pci8086,6fbf
 pci8086,6f68
 pci8086,6f79
 pci8086,6f6a
 pci8086,6f6b
 pci8086,6f6e
 pci8086,6f6f
 pci8086,6fd0
 pci8086,6fd1
 pci8086,6fd2
 pci8086,6fd3
 pci8086,6fb8
 pci8086,6fb9
 pci8086,6fba
 pci8086,6fbb
 pci8086,6f98
 pci8086,6f99
 pci8086,6f9a
 pci8086,6fc0
 pci8086,6f9c
 pci8086,6f88
 pci8086,6f8a
 fw, instance #0 (driver name: acpinex)
 sb, instance #1 (driver name: acpinex)
 socket, instance #2 (driver name: acpinex)
 cpu, instance #0 (driver name: cpudrv)
 cpu, instance #1 (driver name: cpudrv)
 cpu, instance #2 (driver name: cpudrv)
 cpu, instance #3 (driver name: cpudrv)
 cpu, instance #4 (driver name: cpudrv)
 cpu, instance #5 (driver name: cpudrv)
 cpu, instance #6 (driver name: cpudrv)
 cpu, instance #7 (driver name: cpudrv)
 cpu, instance #8 (driver name: cpudrv)
 cpu, instance #9 (driver name: cpudrv)
 cpu, instance #10 (driver name: cpudrv)
 cpu, instance #11 (driver name: cpudrv)
 cpu, instance #12 (driver name: cpudrv)
 cpu, instance #13 (driver name: cpudrv)
 cpu, instance #14 (driver name: cpudrv)
 cpu, instance #15 (driver name: cpudrv)
 cpu, instance #16 (driver name: cpudrv)
 cpu, instance #17 (driver name: cpudrv)
 cpu, instance #18 (driver name: cpudrv)
 cpu, instance #19 (driver name: cpudrv)
 cpu, instance #20 (driver name: cpudrv)
 cpu, instance #21 (driver name: cpudrv)
 cpu, instance #22 (driver name: cpudrv)
 cpu, 

[OpenIndiana-discuss] Initial install of 2020.10 on Z840 for production use

[Reginald Beardsley via openindiana-discuss]

I've done a fresh install using the text installer on a 14 core E5-2680 V4 
system with 72 GB of ECC DRAM and a 4x 4 TB 7200 rpm RAIDZ2 array.  With 
reconfigure set on the post install boot it all came up fine.

The prior install of 2021.04-rc1 gave ~220 MB/s for reads and writes and 87 
MB/s for a file copy on a 3 disk RAIDZ1 for a 1 TB file size.  A dev/zero write 
is running very much slower than 2021.04-rc1.  On that it took a little over an 
hour.  This write has been running for almost 4 hrs.

With a dd write of 1 TB of  /dev/zero to a file running, the GUI response is 
appallingly slow.  Minutes to bring up Firefox. 18 seconds to open a MATE 
terminal.  Unblanking the screen took almost 1 minute to bring up the 
screensaver login.

Top shows the ARC consuming 52 GB and about 10 GB free with the CPU 95% idle.  
This seems to me very strange for the response I'm getting.

Relative to my Z400s or my NL40 this thing is a complete dog. It's about what 
an 11/780 which is badly thrashing would do.   I assume that there are system  
parameters which need to be modified.  Reducing the size of the ARC seems the 
most probable first step.  For my prior testing I only had 8 GB of DRAM on a 
single DIMM.  I installed 4x of the fastest new Micron 16 GB DIMMs as specified 
by the Crucial website plus the 8 GB DIMM it came with.

"mdump -e" shows no events except for 3x pci.fabric events per boot which I 
assume are related to missing device drivers.

After the write completes, I am going to remove the 8 GB DIMM.

Reg

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

Re: [OpenIndiana-discuss] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 
I have been using labelclear which is a huge improvement. In the past I had to 
write a script to do it using dd. So far I've been unable to find a good 
diagram showing the various disk labels, boot blocks, etc. The best 
documentation I've found to date is the ZFS chapter in McKusick et al. I've not 
yet ordered the "IT Mastery" ZFS books but shall.

IIRC I had done an install into an existing pool created by hand. When 
Groenveld commented about the ability to create a RAIDZ2 pool in the text 
installer I tried using that. However, whereas I had created a single s0 slice, 
the text installer created a 250 MB s0 slice with the rest of the disk in s1. I 
think that the error message was the result of a label in the now much smaller 
and unused s0 slice.

This is somewhat speculative given the staggering number of installs I've done 
trying to collect information about what prevented 2021.04-rc1 from booting to 
the desktop.

Maddeningly, format(1m) will sometimes let me modify the label to go back to a 
single s0 slice and sometimes it won't. I've been unable to discern a pattern, 
so that will have to wait until I have time to run it under dbx.

Reg
 On Sunday, April 25, 2021, 07:04:23 AM CDT, Volker A. Brandt 
 wrote:  
 
 Hi Reg!


>  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.

Recent-ish illumos ZFS versions (and presumably OpenZFS, too) have

  zpool labelclear 


Regards -- Volker
-- 

Volker A. Brandt        Consulting and Support for Solaris-based Systems
Brandt & Brandt Computer GmbH                  WWW: http://www.bb-c.de/
Am Wiesenpfad 6, 53340 Meckenheim, GERMANY            Email: v...@bb-c.de
Handelsregister: Amtsgericht Bonn, HRB 10513              Schuhgröße: 46
Geschäftsführer: Rainer J.H. Brandt und Volker A. Brandt

"When logic and proportion have fallen sloppy dead"
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 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.

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 sense. That warning above, what is it about, what does 
partition -> print tell?

rgds,
toomas


> 
> I have to leave soon for the weekend, so likely cannot respond before Monday.
> 
> ---
> - Nelson H. F. Beebe               

Re: [OpenIndiana-discuss] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 I should like to say that from my perspective as the person who started this 
thread I consider your results 100% successful.

My goal was to increase the involvement of the user community in the process of 
creating a new release. It is a tremendous amount of work and many of us such 
as myself have been far too passive.

My profound thanks for your efforts.
Reg


 On Friday, April 23, 2021, 08:06:23 PM CDT, Nelson H. F. Beebe 
 wrote:  
 
 This progress report is 2/3 positive.  

I reported yesterday of my problems with frozen mouse cursor in the
GUI install from

    http://dlc.openindiana.org/isos/hipster/test/OI-hipster-gui-20210405.iso

on CentOS 7.9.2009 with virt-manager 1.5.0 and qemu-system-x86_64
2.0.0.

Later that day, I repeated that experiment on Ubuntu 20.04, which has
virt-manager 2.2.1 and qemu-system-x86_64 4.2.1, considerably newer
than the versions available on CentOS 7.9.2009, but found that the
installation would not proceed because of missing audio and console
drivers.  After my posting, I turned to other unrelated projects, had
a night's sleep, and woke up with an idea for OpenIndiana.

The virt-manager console for configuring a virtual machine has only
one driver for each of mouse and keyboard, but it has THREE for the
video controller: QXL (default), VGA, and Virtio.  It has been rare to
have to use other than the default video type, so I normally don't
even think about changing the default.

For OpenIndiana on Ubuntu 20.04, I shutdown the stuck installer,
powered off the VM, changed to VGA, rebooted, and found that the
installer would then not produce a GUI display, but only a bare
console.

I powered off again, changed to Virtio, and this time, the installer
worked and the installation completed!

It then asked me to reboot, which I did, and it came up normally.  I
immediately shut it down, took a virt-manager snapshot, brought it up,
ran "pkg install build-essential", powered off, took another snapshot,
powered on, installed more packages and user accounts, powered off,
took yet another snapshot, powered on, and I now have a working system
on which I'm attempting to build TeX Live 2021 (see my reports for
other systems at

    http://www.math.utah.edu/pub/texlive-utah/

).

Later this morning, I returned to my campus office in order to meet
with a colleague who is a network and ZFS expert with long experience
in the Solaris family.  We tried to find a way to get past the boot
failure on CentOS 7.9.2009, which I reported yesterday said

    Loading unix...
    Loading /platform/i86pc/amd64/boot_archive...
    ZFS: i/o error - all block copies available
    ...
    No rootfs module provided, aborting

That happens early in the boot process, well before there is any
chance to try to revert to an earlier boot environment.  Despite Web
searching last night and today, and finding others have reported a
similar problem with ZFS on Solaris and FreeBSD, none of their
proposed fixes worked.  So, a new OpenIndiana on CentOS 7.9.2009
remains out of reach.

Finally, I tried the GUI installer on VirtualBox on a small memory
Ubuntu 20.04 system.  There, the installer worked flawlessly,
including a following "pkg install build-essential" and "pkg update"
and subsequent reboot.  No configuration changes whatever were needed.

So, I now have 2 working OpenIndiana Hipster 2020.10 systems out of 4
attempts, and I can now get on with actually putting these VMs to
doing useful work.

It might be useful to add a README file to the download site that
summarizes the lessons:

      VirtualBox:            20210405 unstaller works perfectly
    newer virt-manager/QEMU:    change video to Virtio from default QXL
    older virt-manager/QEMU:     probably unworkable

along with notes for other physical systems were people have gotten
successful installs, including instructions about what list members
have learned about the various NVIDIA driver choices.
 
Next week, when I'm back in my campus office, I may try to install
OpenIndiana with OVIRT/Qemu, our third virtualization platform: it is
newer than the virt-manager on CentOS 7, and offers the nice feature
of live VM migration across our multiple physical VM servers, but is
considerably more painful to manage and configure VMs for.

If OpenIndiana developers remember to post notices about new ISO
images added at

    http://dlc.openindiana.org/isos/hipster/test/

then I'm certainly willing to try new VM installations; our experience
this week should speed up their creation.



Some background and comments of support:

    Our use of SunOS, and later Solaris, began in 1987, and we were
    predominantly based on Sun hardware until Sun was bought by Oracle
    in 2010. After that, Oracle hardware pricing made their products
    unaffordable for our always meager academic budgets.  Since then,
    our backbone servers have been mostly Dell, IBM, and HP hardware
    running Red Hat, CentOS, Ubuntu, and ArchLinux, 

Re: [OpenIndiana-discuss] Successfull reboot of 2021.04-rc1 on Z840 w/ K5000 :-)

[Reginald Beardsley via openindiana-discuss]

 I never had a problem before the Z840. My first Z400 never changed until the 
MB died except for converting to a RAIDZ1 array and a bump from 3x 1 TB to 3x 2 
TB. I bought the other 3 about 5 years ago.

The installs I've done on my test Z400 have always gone smoothly, but the BIOS 
does some "magic" so you have to press F1 to continue the boot any time you 
change a disk. That's probably why I never saw it before. This BIOS doesn't do 
that. And I had loads of fun with it :-(

Sorting this cost me a lot, but at least it's a simple change to the install 
process to fix. I think the issue is the graphics card as everything looks fine 
in single user mode. It's when it attempts to start X that it crashed. The 
Solaris and Linux install tests showed how much superior Hipster is. I'm going 
to test rc1 on both the Z400 and Z840 to verify what change is needed in the 
installed image to prevent this happening.

It's very little effort for those who are set up to do test installs to provide 
test feedback to the developers. I'd like to see a regular program for doing 
that.

Courtesy of assistance from Andy Fiddaman on the illumos-dev list, I now have a 
disk with a 2020.10 based userland development environment. There's not a lot 
to it, so an oi-dev pkg should take care of making it easier for users to fix 
bugs they encounter. "pkg install oi-dev", locate the problem program and go to 
work.

Once I recover a bit from the drubbing the Z840 gave me, I'm going to fix the 
SEGVs in format(1m).

Have Fun!
Reg


 On Friday, April 23, 2021, 03:37:30 PM CDT, Judah Richardson 
 wrote:  
 
 

On Fri, Apr 23, 2021 at 2:43 PM Reginald Beardsley via openindiana-discuss 
 wrote:

It *appears* to be connected with selecting options 5, 6 & 7 before booting to 
multi-user.
I do believe this was in 1 of the very 1st replies I made to you when you 1st 
posted on this list ... it was either in the body or the link I posted. That 
has always been the key to getting an OI installation to boot for the 1st time 
on this end.
Glad you got it working; I just feel like you could have a lot sooner ;)
 

  I'll investigate further after it's been running a while.  I'm supposed have 
64 GB of DRAM arrive today.

I'm purely guessing, but I suspect that the "Reconfigure" option is what made 
it work.

This install was to a 3 disk RAIDZ1, so I have to redo the install for a 4 disk 
RAIDZ2.  I'll test my "Reconfigure" hypothesis when I do that.

There may be other wrinkles in the BIOS settings.  I cannot find BIOS 
documentation and this is my first encounter with a UEFI BIOS.  The behavior 
changed significantly when I updated the BIOS.  I'm hoping that applied a 
Spectre microcode patch.

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] Successfull reboot of 2021.04-rc1 on Z840 w/ K5000 :-)

[Reginald Beardsley via openindiana-discuss]

 
I'm not doing a "devfsadm -C -c disks" when I'm swapping USB drives around, but 
I did do that recently and baffled myself for a few minutes and made some disks 
disappear before I laughed and fixed it.

I have a Z400 just for swapping disks around and testing stuff. It's a great 
use for old drives.

I normally expect a new system configuration to take me 20-30 hours before I'm 
happy with it. After ~50 hours to get to the starting line I'm a bit beat. But 
at least I finally got there.

I've asserted that I never lost a battle with a computer and that includes 
being made an admin in grad school for a MicroVAX II in a BA123 worldbox with 
no training and no formal support except for the HW and *very* little prior 
computer experience.

I was feeling rather grim about the prospect of giving up and sending the Z840 
back.

Reg

 On Friday, April 23, 2021, 03:21:01 PM CDT, Stephan Althaus 
 wrote:  
 
 On 04/23/21 09:42 PM, Reginald Beardsley via openindiana-discuss wrote:
> It *appears* to be connected with selecting options 5, 6 & 7 before booting 
> to multi-user.  I'll investigate further after it's been running a while.  
> I'm supposed have 64 GB of DRAM arrive today.
>
> I'm purely guessing, but I suspect that the "Reconfigure" option is what made 
> it work.
>
> This install was to a 3 disk RAIDZ1, so I have to redo the install for a 4 
> disk RAIDZ2.  I'll test my "Reconfigure" hypothesis when I do that.
>
> There may be other wrinkles in the BIOS settings.  I cannot find BIOS 
> documentation and this is my first encounter with a UEFI BIOS.  The behavior 
> changed significantly when I updated the BIOS.  I'm hoping that applied a 
> Spectre microcode patch.
>
> Reg
>
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss

Hello!

2 hints:

To persistently enable the "reconfigure", create a file in the installed 
OI called @/boot/loader.conf.local@ and put @boot-args="-r"@ in there.
I have this because i like changing disks and whatever attached 
peripherals. As you will know a "devfsadm -C -c disk" will remove 
curently unused device names, so your inserted USB  device *may* get a 
C1... name after next boot...

You may like to persistently disable the graphical console, then create 
a file in the installed OI called @/boot/config@ and put @-t@ in there.
This is working for me in BIOS boot mode, BUT i don't know if this has 
an effect in UEFI boot mode..

Stephan


___
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

[OpenIndiana-discuss] Successfull reboot of 2021.04-rc1 on Z840 w/ K5000 :-)

[Reginald Beardsley via openindiana-discuss]

It *appears* to be connected with selecting options 5, 6 & 7 before booting to 
multi-user.  I'll investigate further after it's been running a while.  I'm 
supposed have 64 GB of DRAM arrive today.

I'm purely guessing, but I suspect that the "Reconfigure" option is what made 
it work.

This install was to a 3 disk RAIDZ1, so I have to redo the install for a 4 disk 
RAIDZ2.  I'll test my "Reconfigure" hypothesis when I do that.

There may be other wrinkles in the BIOS settings.  I cannot find BIOS 
documentation and this is my first encounter with a UEFI BIOS.  The behavior 
changed significantly when I updated the BIOS.  I'm hoping that applied a 
Spectre microcode patch.

Reg

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

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

[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.

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

On Thursday, April 22, 2021, 11:15:13 PM CDT, Joshua M. Clulow 
 wrote:


On Thu, 22 Apr 2021 at 19:10, Reginald Beardsley via
openindiana-discuss  wrote:
> I do *not* understand why there is any justification for renaming physical 
> interfaces between boots, but I had a demonstration today when a USB port was 
> renamed c1t0d0p0 which had previously been c11t0d0p0.
>
> I think we have reached terminal complexity. No one understands the system 
> any longer and so they randomly break things of which they are unaware.

Your consistent negative hyperbole in these threads is frankly
exhausting. We have, today, the best introspection and debugging
tools that have existed in the fifty year history of UNIX. The
software might not be doing what you want at this minute, in your
specific environment, but it absolutely can be understood and fixed.

If you want help with something, please try engaging constructively
and with some empathy for the people to whom you are sending mail.
Demonstrate that you've actually investigated your issue, rather than
opening and immediately closing with a fatalistic complaint about how
everything is broken and the project is doomed.

I don't know what happened with your USB disk having a new device
name, but I guarantee that were one to examine what the system was
doing, it would be possible to find out. In spite of the negativity,
many people have tried to help you in your endeavours in the last few
months.

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

Re: [OpenIndiana-discuss] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 Hmmm,

That suggests that I was perhaps too optimistic about using disks >2 TB despite 
having successfully installed 2020.10 on a single slice 5 TB disk.

I've got S11.4 installed and running again.

Reg

 On Friday, April 23, 2021, 01:26:37 AM CDT, Toomas Soome  
wrote:  
 
 


On 23. Apr 2021, at 01:57, Reginald Beardsley via openindiana-discuss 
 wrote:

What do those mean? I have seen them numerous times even though the system 
booted.



On Thursday, April 22, 2021, 05:46:30 PM CDT, Nelson H. F. Beebe 
 wrote:


 ZFS: i/o error - all block copies unavailable



I/O error means what it is telling us - we did encounter error while doing I/O, 
in this case, we were attempting to read disk. I/O error may come from BIOS 
INT13:
usr/src/boot/sys/boot/i386/libi386/biosdisk.c:
function bd_io() message template is:
printf("%s%d: Read %d sector(s) from %lld to %p “ … );
You should see disk name as disk0: etc.
or UEFI case in usr/src/boot/sys/boot/efi/libefi/efipart.c:
function efipart_readwrite() and the message template is:
printf("%s: rw=%d, blk=%ju size=%ju status=%lu\n” …)

With ZFS reader, we can also get I/O error because of failing checksum check. 
That is, we did issue read command to disk, we did not receive error from that 
read command, but the data checksum does not match.
Checksum error may happen in scenarios:
1. the data actually is corrupt (bitrot, partial write…)2. the disk read did 
not return error, but did read wrong data or does not actually return any data. 
This is often case when we meet 2TB barrier and BIOS INT13 implementation is 
buggy.
We can see this case with large disks, the setup used to be booting fine, but 
as the rpool has been filling up, at one point in time (after pkg update), the 
vital boot files (kernel or boot_archive) are written past 2TB “line”. Then 
next boot will attempt to read kernel or boot_archive and will get error.
3. BUG in loader ZFS reader code. If by some reason the zfs reader code will 
instruct disk layer to read wrong blocks, the disk IO is most likely OK, but 
the logical data is not. I can not exclude this cause, but it is very unlikely 
case.
When we do get IO error, and the pool has redundancy (mirror, raidz or zfs set 
copies=..), we attempt to read alternate copy of the file system block, if all 
reas fail, we get the second half of this message (all block copies).
Unfortunately, the current ZFS reader code does report generic EIO from its 
internal stack and therefore this error message is very generic one. I do plan 
to fix this with decryption code addition.


 ZFS: can't read MOS of pool rpool



This means, we got IO errors while we are opening pool for reading, we got pool 
label (there are 4 copies of pool label on disk), but we have error while 
attempting to read MOS (this is sort of like superblock in UFS), without MOS we 
can not continue reading this pool.
If this is virtualized system and the error does appear after reboot and the 
disk is not over 2TB one, one possible reason is VM managed failing to write 
down virtual disk blocks. This is the cache when VM manager is not implementing 
the cache flush for disks and, for example, is crashing. I have seen this 
myself with VMWare Fusion.
rgds,toomas
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

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

[Reginald Beardsley via openindiana-discuss]

 
I do *not* understand why there is any justification for renaming physical 
interfaces between boots, but I had a demonstration today when a USB port was 
renamed c1t0d0p0 which had previously been c11t0d0p0.

I think we have reached terminal complexity. No one understands the system any 
longer and so they randomly break things of which they are unaware.

Reg

 On Thursday, April 22, 2021, 08:54:14 PM CDT,  
wrote:  
 
 
On Thu, Apr 22, 2021, at 1:15 PM, Reginald Beardsley via openindiana-discuss 
wrote:
>  I ran into this a long time ago trying to set up a ZFS image on a USB 
> drive for a laptop. Ultimately I gave up as it had to be plugged into 
> the "correct" USB port and that seemed to change unpredictably.

I think this should be OK if you run "zpool export" before unplugging the USB 
disk.  I agree that this may be difficult/impossible for a boot image though 
since you can't export the rpool while the system is running ...

> On Thursday, April 22, 2021, 03:01:03 PM CDT, Stephan Althaus 
>  wrote:
> The issue is, that the zfs import routine should read the zfs labels on
> the disks instead on insist on some device path.
> And in these cases just see if some other disk (that is not part of a
> successfully imported 'online' pool) has the correct zfs label for the
> "missing" disk.

I agree that this seems to be a bug, which could be filed against illumos/zfs.  
But it may be dangerous to change without a ZFS expert confirming there is not 
some other case that would break without the current logic.  For example there 
might be complications for systems with multipath IO.  In my case it was a lot 
easier to fix via disk plugging rather than learning how to edit the kernel.

FWIW, deleting /etc/zfs/zpool.cache did not fix this, so the problem appears 
just by reading the paths on disk.

Hugh.


___
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] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 
What do those mean? I have seen them numerous times even though the system 
booted.



On Thursday, April 22, 2021, 05:46:30 PM CDT, Nelson H. F. Beebe 
 wrote:


 ZFS: i/o error - all block copies unavailable
 ZFS: can't read MOS of pool rpool
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 
I'll give that route a try if the current text install from the Desktop fails. 
I updated the BIOS and that stopped Solaris 11.4 from booting :-( What a mess.

So I figured worth a shot trying 2021.04-rc1 again.

Reg

 On Thursday, April 22, 2021, 04:49:31 PM CDT, Tim Mooney via 
openindiana-discuss  wrote:  
 
 In regard to: Re: [OpenIndiana-discuss] The kiss of death, Reginald...:

> The text-install ISO doesn't have a windowing system on it. I don't know
> if there is anything analogous to the Solaris 11.4 "solaris-desktop "
> pkg.

It's 'mate-install'.  And all it does is force the installation of the
desktop components, so the recommended steps are

     pfexec pkg install mate-install
     pfexec pkg uninstall mate-install

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

___
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] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 
The text-install ISO doesn't have a windowing system on it. I don't know if 
there is anything analogous to the Solaris 11.4 "solaris-desktop " pkg.

 On Thursday, April 22, 2021, 04:21:01 PM CDT, Nelson H. F. Beebe 
 wrote:  
 
 Following my report earlier today of problems installing the latest
OpenIndiana ISO GUI installer on CentOS 7.9.2009, I next downloaded

    http://dlc.openindiana.org/isos/hipster/test/OI-hipster-text-20210405.iso

and that led to a successful installation on CentOS 7.9.2009 with
virt-manager 1.5.0 and qemu-system-x86_64 2.0.0.

There was one nit: at the point that it asks for a domain name, it
cuts it off at 15 characters, which is way too small.  See

    https://www.ietf.org/rfc/rfc1035.txt
    https://en.wikipedia.org/wiki/Hostname
    
https://web.archive.org/web/20190518124533/https://devblogs.microsoft.com/oldnewthing/?p=7873

The limit for the domain name field should be 252 (allowing a one-byte
count, one-byte hostname, and dot for the unqualified hostname), so
the total fully-qualified domain name string is less than 256 bytes.

In my case, my required domain name is "vm.math.utah.edu", one longer
than the OpenIndiana installer permits.  Presumably I can fix this
trivially in files in the /etc tree after installation.

During installation, I assigned a static IPv4 address, and when the
system later rebooted, it gave me a text console, but no startx or
xstart or xinit to bring up a window system.

I can successfully login to the new VM via ssh from another system.
Presumably, I could continue to configure this system, and perhaps
later, add enough X11 packages to get a desktop.  However, I'm
delaying that for now.

Next, I ran the GUI installer from

      http://dlc.openindiana.org/isos/hipster/test/OI-hipster-gui-20210405.iso

on Ubuntu 20.04, which has virt-manager 2.2.1 and qemu-system-x86_64
4.2.1, considerably newer than available on CentOS 7.9.2009.

The GUI installation proceeded as expected, with no mouse problems
like I met on CentOS, but it quickly reached a panel complaining about
two missing device drivers, highlighting them in pink:

    Audio  Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family)
        High Definition Audio Controller        Misconfigured:[audiohd]

    Red Hat, Inc. Virtio console                    UNK Info

It will not proceed when I press the Install button, reporting in a
popup:

    Add Driver
    Driver not installed
    The driver package is empty
    Close

I have no idea what driver package is expected there, so there is
nothing to do but abort the installer.  

I don't have audio on any of my 500+ VMs, and given that the installer
desktop screen looks normal, it is puzzling why the GUI installer
thinks a console driver is missing.

I may be able to repeat these experiments next week on VirtualBox on
another system on campus; this week, I working from home.

---
- Nelson H. F. Beebe                    Tel: +1 801 581 5254                  -
- University of Utah                    FAX: +1 801 581 4148                  -
- Department of Mathematics, 110 LCB    Internet e-mail: be...@math.utah.edu  -
- 155 S 1400 E RM 233                      be...@acm.org  be...@computer.org -
- Salt Lake City, UT 84112-0090, USA    URL: http://www.math.utah.edu/~beebe/ -
---

___
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

[OpenIndiana-discuss] Z840 "fun". At least Solaris 11.4 works :-)

[Reginald Beardsley via openindiana-discuss]

I decided that I'd had all of battling OI I could stand for now.

I tried installing Debian 10.9, but it would not boot from a 4 TB disk.  I 
guessed that when I saw the "install GRUB" dialog.  But, you don't know until 
you try.

I installed Solaris 11.4 to a single disk and did a "pkg install 
solaris-desktop".  Much to my relief, that came up using nVIDIA driver 384.111. 
 Not keen on the Gnome 3 desktop, but "pkg search mate" didn't find anything.  
But is does give me a working OS to test the HW.  The Z840 is a 5-6 year old 
off lease system from ebay.  I've had good experiences with my 4x Z400s, but 
there's always the chance of faulty HW.

The BIOS on the Z840 will allow me to select which disk to boot, so I'm going 
to try installing that driver with Hipster 2020.10 and 2021.04-rc1 on other 
disks.

It really bothers me that the Live Image for 2021.04-rc1 works, but the 
installed image crashes.  Even more considering the amount of time I've 
committed to diagnosis.

Reg

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

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

[Reginald Beardsley via openindiana-discuss]

 I ran into this a long time ago trying to set up a ZFS image on a USB drive 
for a laptop. Ultimately I gave up as it had to be plugged into the "correct" 
USB port and that seemed to change unpredictably.

Reg




On Thursday, April 22, 2021, 03:01:03 PM CDT, Stephan Althaus 
 wrote:

Hello!

Thanks for your spending your time!

Yes, i am able to import the pool 'tank' when i leave out the disks of
'bkp1t'.

The issue is, that the zfs import routine should read the zfs labels on
the disks instead on insist on some device path.
And in these cases just see if some other disk (that is not part of a
successfully imported 'online' pool) has the correct zfs label for the
"missing" disk.


No?

Stephan


___
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

[OpenIndiana-discuss] Panics but no dumps ???

[Reginald Beardsley via openindiana-discuss]

Because of a message about VTOCs and needing an EFI label I relabeled the 
disks, created a RAIDZ2 pool and installed to an existing pool.  I then booted 
single user, setup dump and swap.  It crashed but no dump.  Not even a panic 
message in messages.  A 2nd crash did write a panic message and "dumping to 
/dev/zvol/dsk/rpool/dump" and "dump succeeded".

But no files in /var/crash.  "savecore -v /dev/zvol/dsk/rpool/dump" generated 
"is not a directory".  No core file in /var/crash.

I've collected several core files, so I'm getting weirded out by non-repeatable 
behavior.

I'm currently installing to a single disk using the text installer.  If that 
crashes I'm going to try Debian 10.

Sigh...
Reg

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

Re: [OpenIndiana-discuss] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 
I don't understand "adapter". I'm using a Display Port on the K5000 feeding an 
HP DP to DVI adapter to the DVI port of the 1600x1200 Princeton monitor. So I 
don't think VGA enters into this at the moment. It might once I get a new KVM 
switch as the one I've been using died and wouldn't pass the USB signals, just 
the video.

The Z840 boot order BIOS menu allows UEFI or legacy boots of all devices. I've 
not seen any mention of graphics adapters in the BIOS screens, but it's a large 
and complex BIOS so I may have missed it.

Reg

 On Thursday, April 22, 2021, 08:35:25 AM CDT, Toomas Soome  
wrote:  
 
 VESA only can work when adapter does have VESA/VGA bios. With UEFI, there is 
no requirement to have it. 

Sent from my iPhone

> On 22. Apr 2021, at 16:26, Reginald Beardsley via openindiana-discuss 
>  wrote:
> 
> 
> VESA *does* work with a UEFI boot. I had 2020.10 booting from a 4x 4 TB 
> RAIDZ2 pool using the VESA driver before I tried to boot 2021.04_rc1.
> 
> 
> 
> On Thursday, April 22, 2021, 08:07:18 AM CDT, Gary Mills 
>  wrote:
> 
> 
> This is a known broken configuration of OI. It cannot work. The VESA
> driver is a fall-back driver in Xorg. It only runs if the other
> drivers all fail. Unfortunately, the VESA driver does not work with
> a UEFI boot. As long as the nvidia driver succeeds, it will be
> selected by Xorg, and VESA will never be used. The Xorg log will
> contain this information.
> 
> ___
> 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

[OpenIndiana-discuss] Some internals questions

[Reginald Beardsley via openindiana-discuss]

Do kernel modules load in a consistent order?

Where is the code that creates the symlinks in /var/run, when is it supposed to 
run and what determines the timing?  

On the first boot of 2021.04_rc1 after install,  the X server can't find 
libglk.so.  I stopped in single user mode and rewrote the symlinks to point to 
the correct library.  It did get farther, but still crashed.

How does one stop at milestone:all without starting X?  Is disabling lightdm 
sufficient?

I have 1st and 2nd ed of "Solaris Internals", but as those are dated, I would 
like to confirm the kernel module load order without having to do multiple 
boots and saving modinfo output.

There is an extensive set of log files from the Live Image boot, the single 
user boot post install, the post install crash etc  in #13706 logs.tar

Reg

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

Re: [OpenIndiana-discuss] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 
VESA *does* work with a UEFI boot. I had 2020.10 booting from a 4x 4 TB RAIDZ2 
pool using the VESA driver before I tried to boot 2021.04_rc1.



On Thursday, April 22, 2021, 08:07:18 AM CDT, Gary Mills 
 wrote:


This is a known broken configuration of OI. It cannot work. The VESA
driver is a fall-back driver in Xorg. It only runs if the other
drivers all fail. Unfortunately, the VESA driver does not work with
a UEFI boot. As long as the nvidia driver succeeds, it will be
selected by Xorg, and VESA will never be used. The Xorg log will
contain this information.
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 There are very few developers. As a consequence responsibility for testing 
must fall on the regular user community. It should in any case for the simple 
reason that installation on physical hardware is more of an issue than on a VM 
and no one can support very many physical machines. I have a single Z400 set up 
to allow testing OS installs to old disks using a trayless SATA socket.

The point of starting this thread is to formalize a review process by the user 
community of a release candidate before the release is formalized. The list of 
systems on which a release has been tested should be in the release notes along 
with the name of the person who did the testing.

I got started on testing when what I thought would be a routine install of 
2020.10 to a 5 TB disk found that gparted dumped core. So I started looking for 
other issues.

This is why my extensive testing of the ISO images John linked which I have 
been referring to as 2021.04_rc1.

The only way this can work is to post release candidates which are tested by 
the user community, issues logged and when those issues have been fixed another 
RC is created and the testing repeated. When all the issues found have been 
verified as fixed it becomes an official release with a list of the systems 
used in testing in the release notes. Semiannual releases which break things 
that were working is not conducive to the survival of OI. Gparted works on the 
2017.10 ISO, but dumps core on 2020.10. That can not be allowed to happen. 
Better no release than one that has obvious major flaws.

Reg



On Wednesday, April 21, 2021, 10:14:00 PM CDT, Nelson H. F. Beebe 
 wrote:


John D Groenveld  asks today

>> Can you install from the latest installation media on that PC?
>> http://dlc.openindiana.org/isos/hipster/test/>

There are a lot of recent discussions on this list about installation
problems on particular hardware systems, but not a much mention of
routine test installations on virtualization hypervisors, like bhyve,
Parallels, OVirt/QEMU, virt-manager/QEMU, VirtualBox, VMware ESX, and
Xen.

At my site, we have a test farm with hundreds of VMs, primarily on
OVirt and virt-manager, with one small system capable of supporting
just one or two simultaneous VMs on VirtualBox.

I have had at least 8 instances of various releases of OpenIndiana and
Hipster, plus more VMS with the relatives OmniOS, OmniTribblix,
Sun/Oracle Solaris, Tribblix, Unleashed, and XstreamOS, mostly on the
QEMU-based hypervisors.

Several classes of installer bugs have afflicted some of the VMs that
we run, or have tried to install:

(a) uncontrollable streaming garbage input on the console device,
 making correct typein almost impossible;

(b) black screen-of-death on the console at boot time;

(c) random patterns of green and red lines on the console (hiding all
 text);

(d) failure of the mouse to track the screen cursor, sometimes showing
 two cursors, one of which cannot reach certain portions of the
 screen;

(e) installer screens with critical buttons lying off the visible
 console screen, and no resizing possible;

(f) boot wait times that are too short to get to the BIOS setup before
 booting starts (on OVirt, it can take 20 to 30 seconds after a
 power-on before the console is visible, by which time a lot of
 early output is lost).

Are openindiana developers on this list willing to post a list of VMs
on which candidate ISO images have been tested before end users try to
install them on physical machines?

It seems to me that such testing should be normal these days, given
the extreme low cost of virtualization --- I personally run more than
80 VMs simultaneously on each of my home and campus office
workstations.

I will make an effort over the next few days to try some of the latest
ISO images from the Web site above on some of our virtualization
platforms.

---
- Nelson H. F. Beebe Tel: +1 801 581 5254 -
- University of Utah FAX: +1 801 581 4148 -
- Department of Mathematics, 110 LCB Internet e-mail: be...@math.utah.edu -
- 155 S 1400 E RM 233 be...@acm.org be...@computer.org -
- Salt Lake City, UT 84112-0090, USA URL: http://www.math.utah.edu/~beebe/ -
---

___
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] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 

I've been referring to this as 2021.04_rc1 for 2 weeks. We need to formalize 
what most others do and have a release candidate process where people test the 
images before a formal release. 

Expecting the people building them to do it is simply not reasonable. They are 
already quite busy and cannot possibly support the number of hardware platforms 
needed even if they could afford it. It's simply too much work.

I maintain, and will continue to maintain, systems whose sole purpose is 
testing such things.

Reg
 On Wednesday, April 21, 2021, 06:40:15 PM CDT, John D Groenveld 
 wrote:  
 
 In message 
, Jacob Ritorto writes:
>and I do have one shitty pc (HP Z400) I can add to the fray.  Please let me
>know how I can be useful.

Can you install from the latest installation media on that PC?
http://dlc.openindiana.org/isos/hipster/test/>

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] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 That is in contradiction to what Allan said, but I'll write an xorg.conf file 
by hand tomorrow. 8-9 hours of this is all I can stand. If I try to run longer, 
I make things worse rather than better.

I am doing a UEFI boot as it is a 4x 4 TB RAIDZ2 pool. The UEFI vs SMI boot 
would make a lot of sense. However, it still leaves the problem of 2020.10 
crashing before reaching the desktop.

I want to resolve this. If it's not fixed, OI is dead. That would make me 
*very* unhappy. 

I was quite stunned by the number of symlinks and *not* happy. I've done battle 
with profligate use of symlinks as bandaids too many times.

Reg



 On Wednesday, April 21, 2021, 07:09:00 PM CDT, Gary Mills 
 wrote:  
 
 On Wed, Apr 21, 2021 at 11:29:55PM +, Reginald Beardsley via 
openindiana-discuss wrote:

> I'm trying to bring up OI on Oracle Solaris 11 certified hardware.
> 2020.10 crashes booting the Desktop Live Image.  The 2021.04_rc1
> Live Image works fine, but the installed image crashes on reboot.

I've seen this behavior before: you can boot from the install media
and even do an install with no problems, but the installed image fails
to boot fully.  It's caused by the VESA video driver, which will only
run correctly with a BIOS boot, not with a UEFI boot.  The installer
itself can be booted either way.


-- 
-Gary Mills-        -refurb-        -Winnipeg, Manitoba, Canada-
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] The kiss of death

[Reginald Beardsley via openindiana-discuss]

 That is what I've been fighting with for 3 days.
 On Wednesday, April 21, 2021, 06:40:15 PM CDT, John D Groenveld 
 wrote:  
 
 In message 
, Jacob Ritorto writes:
>and I do have one shitty pc (HP Z400) I can add to the fray.  Please let me
>know how I can be useful.

Can you install from the latest installation media on that PC?
http://dlc.openindiana.org/isos/hipster/test/>

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

[OpenIndiana-discuss] The kiss of death

[Reginald Beardsley via openindiana-discuss]

I'm extremely concerned about the situation I've encountered.

I'm trying to bring up OI on Oracle Solaris 11 certified hardware.  2020.10 
crashes booting the Desktop Live Image.  The 2021.04_rc1 Live Image works fine, 
but the installed image crashes on reboot.

This is disastrous for the future of OI.  If it is not fixed, OI is dead.  I 
feel confident that I can determine the source of my problem and fix it.  
However, I only have a few hardware platforms to test releases on.  Fixing my 
problem doesn't make OI reliable on other systems. If we do not achieve 
reliable operation on many platforms it's "game over".

We need to have multiple people test a release candidate on as many pieces of 
hardware as possible.  We can't do everything, but we can do better.  Release 
decisions need to be based on a sign off from multiple people testing a release 
candidate, not on a schedule.

Reg

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

Re: [OpenIndiana-discuss] 2021.04_rc1 on Z840 crashes after install

[Reginald Beardsley via openindiana-discuss]

 Thanks. I just finished logging all the directories, symlinks, files and file 
md5sums for the Live Image using find and have started another text install. 
When that completes I'll repeat the process on the installed image before I 
reboot. Then I'll do it again in single user mode on the reboot.

I very much doubt this is a serious flaw, but it is highly annoying. It would 
be a huge deterrent to a new user which I find of considerable concern. 

Do you have any suggestions about why 2020.10 would not boot to the Desktop and 
2021.04_rc1 would?

Reg


 On Wednesday, April 21, 2021, 05:00:59 PM CDT, Alan Coopersmith 
 wrote:  
 
 On 4/21/21 2:31 PM, Reginald Beardsley wrote:
> The Xorg server is loading both the nvidia driver and the vesa driver. Is 
> that 
> likely to cause a crash? I don't understand what is causing it to load the 
> vesa 
> driver as it doesn't seem to find an xorg.conf file and uses a builtin.

When there is no xorg.conf, it's normal for Xorg to load multiple drivers 
(usually including vesa) as part of the probe routines, and then once it's
found a driver to use, to unload the rest.  This shouldn't cause a crash.

-- 
    -Alan Coopersmith-              alan.coopersm...@oracle.com
    Oracle Solaris Engineering - https://blogs.oracle.com/alanc
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] 2021.04_rc1 on Z840 crashes after install

[Reginald Beardsley via openindiana-discuss]

 Thanks. That actually makes some sense, though I do get nervous when I see 
lots of symlinks. 

I had an FMA fault and fmd is offline. fmdump -v -u  did not find it, but I 
was able to determine that notify-params was disabled. However even after I 
enabled it, fmd is still offline and nothing seemed to change that. 

I'm about to do a brute force comparison of the Desktop Live Image and the 
installed image.

I've been working on this non-stop for almost 9 hours now, so my brain is 
pretty fried at this point.

The Xorg server is loading both the nvidia driver and the vesa driver. Is that 
likely to cause a crash? I don't understand what is causing it to load the vesa 
driver as it doesn't seem to find an xorg.conf file and uses a builtin.

Reg


 On Wednesday, April 21, 2021, 02:59:30 PM CDT, Alan Coopersmith 
 wrote:  
 
 On 4/21/21 12:51 PM, Reginald Beardsley via openindiana-discuss wrote:
>  A bit more information.
> 
> There are symlinks in /usr/lib/xorg that point to symlinks in /var/run which 
> point back to /usr/X11 on the Desktop Live Image. The /var/run links are not 
> present on the installed system.

They are created at boot when the system detects what graphics devices are
in use, via the ogl-select SMF service - make sure it is enabled & running.

-- 
    -Alan Coopersmith-              alan.coopersm...@oracle.com
    Oracle Solaris Engineering - https://blogs.oracle.com/alanc
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] 2021.04_rc1 on Z840 crashes after install

[Reginald Beardsley via openindiana-discuss]

 A bit more information.

There are symlinks in /usr/lib/xorg that point to symlinks in /var/run which 
point back to /usr/X11 on the Desktop Live Image. The /var/run links are not 
present on the installed system.

4294943905 1 lrwxrwxrwx 1 root root 11 Apr 5 17:33 
/usr/X11/lib/modules/extensions/NVIDIA/amd64/libglx.so -> libglx.so.1
2401942 14614 -r-xr-xr-x 1 root bin 14964128 Apr 5 17:30 
/usr/X11/lib/modules/extensions/NVIDIA/amd64/libglx.so.1
4294943906 1 lrwxrwxrwx 1 root root 11 Apr 5 17:33 
/usr/X11/lib/modules/extensions/NVIDIA/libglx.so -> libglx.so.1
2397215 9453 -r-xr-xr-x 1 root bin 9679808 Apr 5 17:30 
/usr/X11/lib/modules/extensions/NVIDIA/libglx.so.1
32254 520 -r-xr-xr-x 1 root bin 532224 Apr 5 17:32 
/usr/lib/mesa/modules/extensions/amd64/libglx.so
4294948253 1 lrwxrwxrwx 1 root root 55 Apr 5 17:33 
/usr/lib/xorg/modules/extensions/amd64/libglx.so -> 
../../../../../../var/run/opengl/server/amd64/libglx.so
4294948254 1 lrwxrwxrwx 1 root root 46 Apr 5 17:33 
/usr/lib/xorg/modules/extensions/libglx.so -> 
../../../../../var/run/opengl/server/libglx.so
2017402090 4 lrwxrwxrwx 1 root root 54 Apr 21 03:08 
/var/run/opengl/server/amd64/libglx.so -> 
/usr/X11/lib/modules/extensions/NVIDIA/amd64/libglx.so
2017402118 4 lrwxrwxrwx 1 root root 48 Apr 21 03:08 
/var/run/opengl/server/libglx.so -> 
/usr/X11/lib/modules/extensions/NVIDIA/libglx.so


There are 35526 symlinks in total in the Desktop Live Image. What could go 
wrong? I plan to write a script to search for dangling links after my brain 
recovers.

I fixed the links /usr/lib/xorg, but the system still panics when I try to 
transition to milestone:all and bring up X.

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

[OpenIndiana-discuss] 2021.04_rc1 on Z840 crashes after install

[Reginald Beardsley via openindiana-discuss]

The Desktop Live Image boots properly from the GUI iso, however on reboot it 
crashes.

I collected log files along the way

single_user_from_DVD
all_before_install
post_install_before_reboot
single_user_after_reboot
single_user_after_crash

log files posted to #13706.  An initial look at the Xorg.0.log suggests that 
the crash is being caused by not unloading the vesa module as that gets 
unloaded on the Live Image Desktop boot when it is running the 390 driver 
properly.

I'm going to try creating an xorg.conf file by hand after lunch.

I've got vmcore.0, but it's too big to upload.  I don't know mdb well enough to 
know what to do.  But if someone will provide instructions I'll collect what 
data I can.

Reg

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

[OpenIndiana-discuss] HP Z840/K5000 fun :-(

[Reginald Beardsley via openindiana-discuss]

2020.10 will only  run the Desktop in 1024x768 using VESA.  An install will 
boot in 1024x768, but I've been unable to sort out how to get the 390 driver to 
install in place of the 340 driver.  I was able to do the reverse with 
2021.04_rc1, but either I forgot a step or something is different.

2021.04_rc1 boots the Live Image  Desktop at 1600x1200 which is full monitor 
resoultion.  However, the installed image crashes when it tries to start X.  
I've not been able to glean much data yet.

However, running from the Live Image I have mounted the RAIDZ2 root pool and 
will post log files to issue #13706.   /var/adm/messages and 
/var/log/Xorg.0.log are obvious candidates.  What other data would be useful?  
I had not enabled dump files as it crashed on the reboot after the install and 
the 2021.04_rc1 installed sysem doesn't do that by default.  I think it should 
as it would be easy for a new user to overlook the need to do that.

If anyone would like, I'll boot single user, enable dumps and provide whatever 
information someone can tell me how to get.

Having mounted and examined the ISOs and poked around the in-core filesystem, 
it's not at all clear to me how the installed image and the Live Image are 
related.

I have ISOs for S11.4 and S10 u11 and am happy to install those if someone 
thinks it will provide information.  But the 2021.04_rc1 Live Image Desktop 
looks great.  Just what it should.  As I had the opposite experiences with 
2020.10 and 2021.04_rc1 on the Desktop live Image boots on the Z400 and Z840 it 
seems likely to be either a BIOS setting or HW.

Reg


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

[OpenIndiana-discuss] WTF?

[Reginald Beardsley via openindiana-discuss]

The nvidia-340 driver caused a kernel panic on my Z840 with a Quadro K5000 when 
I ran nvidia-xconfig.

So I booted single user, attempted to uninstall it, but pkg wouldn't let me 
until I also uninstalled xorg-video.

But when I tried to install nvidia-390 I generated a series of  "requires 
Reject:"  messages which has been running across the console for 20 minutes 
listing the same pkgs over and over.  I tried Ctrl-C and Ctrl-D but nothing 
stops it.  It appears to be in an infinite loop.

Eventually I just dropped the power and redo the install but with snapshots and 
BEs so I can back up.

nvidia-460, nvidia-390 and nvidia-340 all support the Quadro K5000, so I'm 
rather baffled at the behavior.  It's particularly frustrating because I had a 
similar issue with 2021.04_rc1 on a Z400 with a Quadro FX 1800 and was able to 
switch from nvidia-390 to nvidia-340 without significant trouble.  And I 
installed 2020.10 and set it up to build userland a few days ago with the 
nVIDIA driver installed.

FWIW I agree about the need for identifying the disk. But it seems to me that 
"zpool status" is where the device info belongs.  I just wrote a script to map 
physical device names from messages to logical device names.

Reg

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

[OpenIndiana-discuss] x86 boot loader

[Reginald Beardsley via openindiana-discuss]

Is it actually written in forth?  I just learned of it today.  I'm a long time 
forth fan.

Reg

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

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

[Reginald Beardsley via openindiana-discuss]

 
With the information in the link John posted I was able to get Hipster 2020.10 
to install into a RAIDZ2 pool using almost all of the 4 TB disks via the text 
installer on the GUI Live Image. There's a 250 MB "SYSTEM" slice on each disk, 
but that's about $0.01 USD today. 

I still need to deal with installing the correct nVIDIA driver and there is 
something strange going on with the USB keyboard and mouse. Even when I plugged 
them in directly without the KVM switch one or the other would become 
non-responsive.

But for the first 6-7 hours with a new system I'm *very* pleased to have gotten 
so far.

rhb@2020-10-txt:~$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool1 16.1G 6.81T 215K /rpool1
rpool1/ROOT 6.10G 6.81T 140K legacy
rpool1/ROOT/openindiana 6.10G 6.81T 5.61G /
rpool1/ROOT/openindiana/var 494M 6.81T 488M /var
rpool1/dump 3.96G 6.81T 3.96G -
rpool1/export 3.03M 6.81T 140K /export
rpool1/export/home 2.89M 6.81T 140K /export/home
rpool1/export/home/rhb 2.76M 6.81T 2.76M /export/home/rhb
rpool1/swap 6.01G 6.82T 81.4K -
rhb@2020-10-txt:~$ zpool status
 pool: rpool1
 state: ONLINE
 scan: none requested
config:

 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.

Have Fun!
Reg  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

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

[Reginald Beardsley via openindiana-discuss]

 FYI

I created the pool manually before installing into an existing pool as well as 
the dump and swap volumes afterwards. I was not aware of the other options in 
the text installer. I'll try those on the Z840.

rhb@NL40:~$ zfs list
NAME USED AVAIL REFER MOUNTPOINT
rpool 11.5G 3.40T 180K /rpool
rpool/ROOT 1.56G 3.40T 140K legacy
rpool/ROOT/2020-10-net 1.56G 3.40T 1.21G /
rpool/ROOT/2020-10-net/var 317M 3.40T 315M /var
rpool/dump 4.00G 3.40T 4.00G -
rpool/export 424K 3.40T 140K /export
rpool/export/home 285K 3.40T 140K /export/home
rpool/export/home/rhb 145K 3.40T 145K /export/home/rhb
rpool/swap 5.95G 3.40T 81.4K -
rhb@NL40:~$ zpool status
 pool: rpool
 state: ONLINE
 scan: none requested
config:

 NAME STATE READ WRITE CKSUM
 rpool ONLINE 0 0 0
 raidz2-0 ONLINE 0 0 0
 c4t0d0s0 ONLINE 0 0 0
 c4t1d0s0 ONLINE 0 0 0
 c4t2d0s0 ONLINE 0 0 0
 c4t3d0s0 ONLINE 0 0 0

errors: No known data errors
rhb@NL40:~$ 


What's the deal with these device names? How do I get something more reasonable 
to type in? These are all 4 TB EFI labeled disks on the Z840 using format(1m).


/dev/dsk/c0t539A7B7002F3d0s0
/dev/dsk/c0t539A7B700305d0s0
/dev/dsk/c0t539A7B700306d0s0
/dev/dsk/c0t539A7B78030Fd0s0

Reg



On Monday, April 19, 2021, 05:47:36 PM CDT, John D Groenveld 
 wrote:


In message <34bf7cc2-5a0c-5c5e-b9ed-9f188e961...@gmail.com>, Till Wegmueller wr
ites:
>Try Raidz1, Raidz2 as root had some problems when I tried last. Although
>that was 1-2 years ago. So it might work now. But I have not yet seen
>any installation with RAIDZ2 as root it's quite rare.

RAIDZ[1-3] seem to work fine, but as Toomas Soome has repeatedly
warned here, all the vdevs should be accessible from the boot loader.
Escape to the loader prompt from the boot menu and run lsdev.
I have submitted a PR for the Handbook.
http://docs.openindiana.org/handbook/getting-started/#install-openindiana-to-existing-zfs-pool>

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] RAIDZ2 root pool install fun :-(

[Reginald Beardsley via openindiana-discuss]

 The text-install on the NL40 went quite well. I repartitioned the disks, 
created a new RAIDZ2 pool, installed into an existing pool and then created 
dump and swap.

 I'm currently installing S11.4, but I don't think it will let me have a RAIDZ2 
root pool. I created one, but I think it is getting stomped on. That's an 
argument for using my s0 & s1 arrangement. 

We'll see. New systems usually take me several days to work out how to get what 
I want.

Reg

 On Monday, April 19, 2021, 05:00:37 PM CDT, Till Wegmueller 
 wrote:  
 
 Hi Reg

Try Raidz1, Raidz2 as root had some problems when I tried last. Although 
that was 1-2 years ago. So it might work now. But I have not yet seen 
any installation with RAIDZ2 as root it's quite rare.

-Till

On 19.04.21 18:23, Reginald Beardsley via openindiana-discuss wrote:
> I did an install of 2020.10 from a text USB stick on an HP NL40 with a 4x 2 
> TB RAIDZ2 root pool this morning without any issues.
> 
> My Z840 showed up and things have not gone well.  After a bit of BIOS fubar I 
> was able to create a RAIDZ2 pool, but the pseudo device names were very long.
> 
> /dev/dsk/c0t539A7B7002F3d0s0
> /dev/dsk/c0t539A7B700305d0s0
> /dev/dsk/c0t539A7B700306d0s0
> /dev/dsk/c0t539A7B78030Fd0s0
> 
> When the system arrived it had Windows 10 installed.  I booted that and it 
> was OK, so I pulled the disk and installed 4x 4 TB Toshiba X300 disks.
> 
> On boot the Live Image Desktop came up, but I could only see 2 of the 4 
> disks.  Fiddling with the BIOS eventually got it to see all 4 drives, though 
> at one point format(1m) could not see any disks until I reset the BIOS to 
> factory defaults.
> 
> Now the Desktop won't come up.  If I run the text-installer on the GUI ISO in 
> single user mode  it crashes. Bug #13734.
> 
> The USB text-install ran and installed, but the system doesn't boot.  I've 
> not yet done an installboot to all the disks.  That's next.  If that doesn't 
> work I'll try S11.4.
> 
> The Z840 BIOS is *very* different from the Z400.  But I've successfully 
> installed 2020.10  in a single 5 TB  pool using the GUI DVD and the 
> text-install script on a Z400.
> 
> 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
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

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

[Reginald Beardsley via openindiana-discuss]

I did an install of 2020.10 from a text USB stick on an HP NL40 with a 4x 2 TB 
RAIDZ2 root pool this morning without any issues.

My Z840 showed up and things have not gone well.  After a bit of BIOS fubar I 
was able to create a RAIDZ2 pool, but the pseudo device names were very long.

/dev/dsk/c0t539A7B7002F3d0s0
/dev/dsk/c0t539A7B700305d0s0
/dev/dsk/c0t539A7B700306d0s0
/dev/dsk/c0t539A7B78030Fd0s0

When the system arrived it had Windows 10 installed.  I booted that and it was 
OK, so I pulled the disk and installed 4x 4 TB Toshiba X300 disks.

On boot the Live Image Desktop came up, but I could only see 2 of the 4 disks.  
Fiddling with the BIOS eventually got it to see all 4 drives, though at one 
point format(1m) could not see any disks until I reset the BIOS to factory 
defaults. 

Now the Desktop won't come up.  If I run the text-installer on the GUI ISO in 
single user mode  it crashes. Bug #13734.

The USB text-install ran and installed, but the system doesn't boot.  I've not 
yet done an installboot to all the disks.  That's next.  If that doesn't work 
I'll try S11.4.

The Z840 BIOS is *very* different from the Z400.  But I've successfully 
installed 2020.10  in a single 5 TB  pool using the GUI DVD and the 
text-install script on a Z400.

Reg

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

[OpenIndiana-discuss] Installing to a RAIDZ2 root pool How-To

[Reginald Beardsley via openindiana-discuss]

It is my understanding that we can now boot from a RAIDZ pool.   Are there any 
known limitations? I  looked at the wiki and I didn't see any instructions 
related to booting from a RAIDZ pool or installing into a RAIDZ pool.

It looks pretty straight forward, but there are some details that are not 
obvious.  In particular the need to create the pool and use the text-install 
script to install into an existing pool.  That will not create rpool/swap and 
rpool/dump so the user must run dumpadm and swap to set up dump and swap space.

As I am going to be doing this shortly with a RAIDZ2 rpool I thought I should 
write up the process for the wiki if there is not a How-To already that I 
missed.

Reg

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

Re: [OpenIndiana-discuss] New system planning comments

[Reginald Beardsley via openindiana-discuss]

 My use cases for VMs are running CAD and EDA software on Win 7 and Debian and 
Firefox on Hipster so a local display is essential.

I have no application for a server other than to do backups. 

Reg

 On Sunday, April 18, 2021, 07:46:22 AM CDT, Carl Brewer 
 wrote:  
 
 On 18/04/2021 9:44 pm, Andreas Wacknitz wrote:
> 

> Running VMs in VirtualBox makes only sense under certain requirements,
> like eg. local display. OI has out-of-the-box better virtualization
> methods: KVM and BHyve. For both you can create corresponding zones. If
> possible, BHyve is the recommended new virtualisation method.

VBox "just works" and is easy to manage. That's my certain requirement :)

Carl


___
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

[OpenIndiana-discuss] Scientific packages for OI

[Reginald Beardsley via openindiana-discuss]

Robert's suggestion of Anaconda got me to thinking about maintaining some IPS 
packages for OI.  

I typically build from source and have an  /app tree with symlinks from bin, 
lib, etc to the actual files so I can flip from one release to another with a 
couple of commands.  I've used the scheme for 10 years or so and it has worked 
very well.

That said, it should not be a significant effort for me to create IPS packages 
beyond learning  how to create a package.

Things of which I am aware and have an interest:

GLPK  (Gnu Linear Programming Kit)
gnuplot
R
Octave
Anaconda
Seismic Unix

R and Octave have a huge number of dependencies on BLAS and other math 
libraries.  In addition, the last time I tried, Octave would not build because 
the configuration files were borked.  But it shouldn't be that hard to write a 
shell script to build it.

There are, of course, many scientific packages.  Far more than I care to build, 
but I'm open to suggestions for additions to the list above.

Have Fun!
Reg

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

Re: [OpenIndiana-discuss] New system planning comments

[Reginald Beardsley via openindiana-discuss]

 I'm not familiar with that as I have never learned python, but I should be 
able to create a package for it. I have numerous friends who do use python.

I'd *really* like to get Octave to compile, but they have borked autotools so 
badly it is hopeless unless I write a new Makefile. In the meantime I use 
Debian for Octave.

Thanks for pointing it out.

Have Fun!
Reg


 On Saturday, April 17, 2021, 03:37:42 PM CDT, private mail openbabel 
 wrote:  
 
 Dear all,

Planning ahead. It would be nice to compile Anaconda for science
sometime in the future.

Regards,


Robert

https://www.ch.cam.ac.uk/computing/software/anaconda-scientific-python-distribution



On 17/04/2021 18:24, Reginald Beardsley via openindiana-discuss wrote:
> I'm about to set up  an HP Z840 with 1x 14 core E5-2690 V4,  a 4x 4 TB RAIDZ2 
> array and 4x 16 GB ECC DIMMs.
>
> The dbx implementation in the Oracle/Sun/Forte compiler suite is the only 
> debugger I've encountered which will evaluate F77 intrinsics on the command 
> line.  This is immensely valuable to a scientific programmer.  Without that 
> one must use temporary variables when debugging.  While the optimization 
> process will remove the overhead, it makes the code quite long winded and 
> ugly.
>
> I currently have Studio 12.1 on Hipster 2017.10 and have not seen any issues, 
> though more serious work has been done on my S10 u8 system.  I tend to prefer 
> mixed F77 and C89 for reasons of portability and the vast number of high 
> quality scientific libraries available.
>
> It seems to me that 14 cores and 64 GB of DRAM should be sufficient to run 
> S11.4 in a VM if I *really* need the latest Studio version. The Z840 will 
> take 12 more DIMMs so I can easily expand memory and add a 2nd 14 core 
> E5-2690 V4 if needed. 
>
> This inclines me to use Hipster as the base OS and use VirtualBox to run 
> S11.4, Win 7, Debian and an OI build system in VMs when needed with a fall 
> back of a Z400 and swappable disks if MMU limitations constrain performance 
> too much.
>
> Ten years ago a VM was not viable for building OI, but 14 cores and 64 GB of 
> DRAM seems to me likely to handle it.  Is an OI VM running on top of OI 
> viable for building and testing?  In particular, how good is VBox for that?  
> it's become very Windows host oriented.  I'm also aware the Solaris USB 
> support is not very good.  I'll have Win 7 and Debian available  running 
> native on a Z400 if USB proves an issue for working with microcontrollers 
> which is my primary use case for both of those.
>
> Thanks.
>
> Have Fun!
> 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
  
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

[OpenIndiana-discuss] New system planning comments

[Reginald Beardsley via openindiana-discuss]

I'm about to set up  an HP Z840 with 1x 14 core E5-2690 V4,  a 4x 4 TB RAIDZ2 
array and 4x 16 GB ECC DIMMs.

The dbx implementation in the Oracle/Sun/Forte compiler suite is the only 
debugger I've encountered which will evaluate F77 intrinsics on the command 
line.  This is immensely valuable to a scientific programmer.  Without that one 
must use temporary variables when debugging.  While the optimization process 
will remove the overhead, it makes the code quite long winded and ugly.

I currently have Studio 12.1 on Hipster 2017.10 and have not seen any issues, 
though more serious work has been done on my S10 u8 system.  I tend to prefer 
mixed F77 and C89 for reasons of portability and the vast number of high 
quality scientific libraries available.

It seems to me that 14 cores and 64 GB of DRAM should be sufficient to run 
S11.4 in a VM if I *really* need the latest Studio version. The Z840 will take 
12 more DIMMs so I can easily expand memory and add a 2nd 14 core E5-2690 V4 if 
needed. 

This inclines me to use Hipster as the base OS and use VirtualBox to run S11.4, 
Win 7, Debian and an OI build system in VMs when needed with a fall back of a 
Z400 and swappable disks if MMU limitations constrain performance too much.

Ten years ago a VM was not viable for building OI, but 14 cores and 64 GB of 
DRAM seems to me likely to handle it.  Is an OI VM running on top of OI viable 
for building and testing?  In particular, how good is VBox for that?  it's 
become very Windows host oriented.  I'm also aware the Solaris USB support is 
not very good.  I'll have Win 7 and Debian available  running native on a Z400 
if USB proves an issue for working with microcontrollers which is my primary 
use case for both of those.

Thanks.

Have Fun!
Reg

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

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

[Reginald Beardsley via openindiana-discuss]

 To summarize:

I swapped PSUs and graphics cards including putting the card from #3 in #4

I booted from the 2020.10 hard disk and Live Image

I swapped the KVM cables and ports

I tried the other PCIe slot that will take the graphics card. 

I put a scope on the 5 V and 12 V rails.

After all that agony I finally tracked it down. A couple of junk DVI-VGA 
adapters! Somehow in my search for the cause of the kernel panics I failed to 
notice that the display resolution was wrong when I was running 2020.10 in #4

After all this I'm exhausted. But I've never lost a battle with a piece of 
computer HW and was not about to start. I'd like to shoot these, but that would 
require more trouble than they are worth. So I am going to crush them with a 20 
ton hydraulic press. If there were someone I disliked enough, I'd give them 
away.

The moral of this sad tale is, "Don't put untested parts in your spares bin!" I 
bought these to have some spares on hand, but did not test them when i received 
them. They were still in the bags. I damaged my old one for #4 while shifting 
HW.

Unfortunately, I still have the kernel panics to deal with :-( 

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

[OpenIndiana-discuss] How is this possible?

[Reginald Beardsley via openindiana-discuss]

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.

Reg

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

Re: [OpenIndiana-discuss] Where do ECC errors get logged?

[Reginald Beardsley via openindiana-discuss]

 
OK guys, I think I know where to look now. Thanks!

With a recipe from Andy Fiddaman I was able to build format(1m). It took rather 
a long time to get things set up, so I decided to pull the trigger on a 
replacement for my aging Z400s.

I just bought an HP Z840 on ebay with a 14 core E5-2690 V4. It only has 8 GB of 
DRAM, but it was $800 + tax so I should be able to kick it up to 64 or 128 GB 
at reasonable cost to use as an Illumos/OI dev system.

I must admit that "wc *.[ch]" in the format directory gave me pause when I saw 
how many lines it totaled for the simple reason of being a lot to read. But 
it's a lot cleaner than the 125 KLOC FORTRAN codes I've dealt with and those 
simply aren't possible to read before going to work. The client wouldn't stand 
for the delay. And you've not seen ugly until you've seen the typical research 
scientist written program.

I think I'll likely start by stripping out all the comments and reading those 
for orientation. But I'm quite excited at being able to fix things that annoy 
me. And the only thing that annoys me more than a core dump is a kernel panic. 
However, I'll pass on fixing the latter as things are just too complex now. 
There are lots of other things on my bucket list. Like building radios and 
making stuff on my lathes and mill. When I was younger I was hot to do kernel 
work, but it takes a lot of time and effort to come up to speed.

The OS as a whole is beyond any one person's grasp. I doubt that John von 
Neumann could grasp it all, even with his celebrated photographic memory. "A 
Tale of Two Cities" is small potatoes relative to 2 million lines of source 
code.

If anyone knows of a reliable source of 4x 16 GB DIMMS for a Z840, please drop 
me a line off list.

Have Fun!
Reg

 On Monday, April 12, 2021, 04:19:16 PM CDT, Bob Friesenhahn 
 wrote:  
 
 On Mon, 12 Apr 2021, Bob Friesenhahn wrote:
>
> Read the manual pages regarding 'fmadm', 'fmdump', and 'fmstat'.  In 
> particular, I believe that 'fmstat' will output the data that you are looking 
> for. When I had memory ECC errors that is how I was able to see them.

Darn it!  I meant to type 'fmdump'.

Bob
-- 
Bob Friesenhahn
bfrie...@simple.dallas.tx.us, http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/
Public Key,    http://www.simplesystems.org/users/bfriesen/public-key.txt

___
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] [discuss] [developer] Illumos/OI development system installation

[Reginald Beardsley via openindiana-discuss]

 Kent,

Thank you for a very informative reply.

My interest is a desktop. Were there seismic work I'd be interested in a 
server. Actually, a lot of them. But that world is dominated now by Linux and 
with almost no revenue in the seismic industry, that won't change. Because most 
scientists can't write portable code, moving a single executable to another 
platform is a 6 figure undertaking. In the 90's Landmark claimed they were 
porting SeisWorks, a $100k/seat product, to NT. I laughed. It never happened, 
but they did manage to move it from SunOS to Linux and that killed a several 
billion dollar segment of Sun's customer base. Once SeisWorks ran on Linux and 
x86 hardware, the industry bought IBM systems for 10% of the cost of an Ultra 
60. Eventually Sun brought out the Ultra 20 and Ultra 40, but by then it was 
too late. It was no longer locked to SunOS on SPARC.

My desire is for a simple method for fixing stray errors I encounter as I use 
OI. I've got lots of old disk drives, so I can set up a OmniOS system, swap 
disks and boot it when I run into an issue with the non-GUI programs and ssh 
into the system to work on it. And quite frankly, I don't like working on GUI 
programs anyway. So I have no inclination to fix those.

Thank you for suggesting a satisfactory alternative.

Have Fun!
Reg

 On Saturday, April 10, 2021, 05:35:11 PM CDT, Kent Watsen 
 wrote:  
 
 [removing “developer" and "oi-dev” lists]
Hi Reg,
Regarding compiling, my understanding it that these two docs on the omnios.org 
are NOT holdovers from the legacy OmniOS wiki (i.e., they’re accessed from the 
“site map” located at the top-left of every page on the omnios.org site:
Building illumos-gate on OmniOS: - https://omnios.org/dev/gate.html
Building OmniOS: - https://omnios.org/dev/build_instructions.html
I haven’t built OmniOS in about a decade (when I patched the kernel to run KVM 
on AMD), but I did build Illumos-gate per the instructions above a few days 
ago.  Notably, the instructions were flawless and the build completed 
successfully on first try.  Hats off to the devs for that!  :)
Regarding time to build on various platforms, below is the nightly-build output 
email that was sent to root@localhost when I built Illumos-gate on a machine 
with 16 cores (32 threads) and 64 GB of memory.  That said, the ZFS filesystem 
was on a cheap M.2 disk that I’ve since discovered is rather slow.  I now have 
a faster ZFS pool, but it’s currently occupied running burn-in tests for me to 
do a build now.
Since `format` is in the Illumos base, I recommend you take Dan’s suggestion on 
OmniOS and Illumos-gate.  I’m unsure if OmniOS can run in an OI zone, but it 
could definitely run in a VM if needed.  In either case, the compiled binary 
can be copied to your OI system (assuming same arch) and patches sent upstream.
Regarding no response, I wanted to but, like many here, I suspect (and doubly 
so since you didn’t get a responses before), I use OmniOS (not OI) and I have 
no interest in GUIs on my servers, unless you count `tmux` as a GUI, as I’m 
completely addicted to it...I even run it fullscreen on my Mac OS desktops ;).
Below is the nighty-build email mentioned above.
K.


 Nightly distributed build started:   Mon Apr  5 10:57:54 EDT 2021      
                                        Nightly distributed build 
completed: Mon Apr  5 11:21:24 EDT 2021                                     
       

 Total build time 

real    0:23:30

 Build environment 

/usr/bin/uname
SunOS san2 5.11 omnios-r151036-de483383c0 i86pc i386 i86pc
                                                                                
                             [106/1860]
/opt/onbld/bin/i386/dmake
dmake: illumos make
number of concurrent jobs = 34

cw version 5.0
primary: /opt/gcc-7/bin/gcc
gcc (OmniOS 151036/7.5.0-il-1) 7.5.0
Copyright (C) 2017 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

shadow: /opt/gcc-4.4.4/bin/gcc
gcc (GCC) 4.4.4
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

shadow: 
/build/illumos-gate/usr/src/tools/proto/root_i386-nd/opt/onbld/bin/i386/smatch
0.6.1-rc1-il-5

/usr/jdk/openjdk11.0/bin/javac
openjdk full version "11.0.10+9-omnios-151036"

/usr/bin/openssl
OpenSSL 1.1.1j  16 Feb 2021
    API_COMPAT=0x1000L

/usr/bin/as
as: Sun Compiler Common 12 SunOS_i386 snv_121 08/03/2009

/usr/ccs/bin/ld
ld: Software Generation Utilities - Solaris Link Editors: 5.11-1.1763 (illumos)

Build project:  user.root
Build taskid:   76

 Nightly argument issues 

 Build version 
master-0-g867228adfb

 Make clobber ERRORS  

 Make tools clobber ERRORS 

 Bootstrap build errors 

 Tools build 

Re: [OpenIndiana-discuss] Illumos/OI development system installation

[Reginald Beardsley via openindiana-discuss]

 Please post to the wiki a console log from a fresh install of 2020.10 that 
performs all the steps you outlined below, recompiles format(1m) so it can be 
run under a debugger, commits it to a local repository and then rebuilds it 
from the repository and installs it.

Give me that and I'll fix as many of the SEGVs as I can find. And at this point 
I know how to trigger several. I also know on general principle how to locate 
code that has the potential to cause a SEGV and preemptively guard the 
operation and produce an user intelligible message on stderr.

I started using OI_151_a5. A lot has changed since then. There is a huge amount 
of no longer correct stuff out there waiting for the unwary. Fixing a SEGV is a 
few hours work. Sorting out how the the build system and repositories have 
changed is several days work.

I'm asking for an explicit recipe. I've got all the reference books I need. If 
what I want to do actually is simple, then it should not take very long to do 
it and post the console log.

If you want help, help me.

My own software is in a system such that "make -DEBUG=[123]" compiles the 
software for testing. 1 is plain debug, 2 is gprof and 3 is efence. This runs 
across several system architectures. In an industrial setting I have done 
fancier build systems that supported simultaneous compilation and test suite 
execution across SunOS, HP-UX, CLIX, IRIX, Ultrix and AIX in the same directory 
from the same source files.

Extract  
Make  
Test  component>
Checkin  

It was built on SCCS and required one Extract and one Checkin. It required a 
Make and Test for each system platform. We used multiple xterms and rlogins so 
we just switched from one to the next to run the Make and Test steps. The 
entire system had a Build  operation that beat the NFS server so hard 
that I could only do a Build on one system at a time. I'd start a Build at work 
and then log in around 9 pm via a dumb terminal and modem to check the log 
file. If it was OK I started a Build on the next system. The terminal sat on 
top of a 3 drawer lateral file. I told the client that I didn't charge unless I 
had to sit down. Build ran a very large regression test suite.

Reg




On Saturday, April 10, 2021, 02:29:27 PM CDT, Aurélien Larcher 
 wrote:


On Sat, Apr 10, 2021 at 7:27 PM Reginald Beardsley via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

>
> Which does what? Does that retrieve the source code? If so, where does it
> put it? What are the prerequisites? Neither pkg(1) nor pkg(5) offer any
> explanation.
>

I am not sure what you are trying to achieve but building and installing
illumos-gate on OI can be as simple as:
- cloning oi-userland,
- committing your changes locally or changing the branch to build in
oi-userland/components/openindiana/illumos-gate/Makefile and incrementing
the branch version,
- running gmake publish in components/openindiana/illumos-gate to build and
publish to the local repository located in oi-userland/i386/repo
- running pkg update -g oi-userland/i386/repo to a new BE,
- reboot.


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

Re: [OpenIndiana-discuss] Illumos/OI development system installation

[Reginald Beardsley via openindiana-discuss]

 
Which does what? Does that retrieve the source code? If so, where does it put 
it? What are the prerequisites? Neither pkg(1) nor pkg(5) offer any explanation.

Reg

 On Saturday, April 10, 2021, 11:48:13 AM CDT, Tomasz Kłoczko 
 wrote:  
 
 On Sat, 10 Apr 2021 at 15:34, Reginald Beardsley via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

> I should like to suggest that providing a turnkey development
> installation that would permit someone like me to compile format(1m)  and
> fix the SEGV faults would go a long way towards increasing the number of
> people supporting OI and Illumos.
>

Sorry but you don't need special installer for single command like
"pkg change-facet devel=true"

kloczek
-- 
Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH
___
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