Re: [OpenIndiana-discuss] Which OI service cleans up hidden NFS files?

[Judah Richardson]

nfsfind script is as follows:

if [ ! -s /etc/dfs/sharetab ]; then exit ; fi

# Get all NFS filesystems exported with read-write permission.

DIRS=`/usr/bin/nawk '($3 != "nfs") { next }
($4 ~ /^rw$|^rw,|^rw=|,rw,|,rw=|,rw$/) { print $1; next }
($4 !~ /^ro$|^ro,|^ro=|,ro,|,ro=|,ro$/) { print $1 }'
/etc/dfs/sharetab`

for dir in $DIRS
do
find $dir -type f -name .nfs\* -mtime +7 -mount -exec rm -f {} \;
done

Here's what's in /etc/dfs/sharetab:

/znapzend/DellOptiPlex390MT/ROOT/openindiana-   nfs sec=sys,rw=@
192.168.0.107/32,root=@192.168.0.107/32
/znapzend/DellOptiPlex390MT/export/home/judah   -   nfs sec=sys,rw=@
192.168.0.107/32,root=@192.168.0.107/32
/znapzend/DellOptiPlex390MT -   nfs sec=sys,rw=@
192.168.0.107/32,root=@192.168.0.107/32
/rpool1 -   nfs sec=sys,rw=@192.168.0.107/32,root=@192.168.0.107/32
/znapzend   -   nfs sec=sys,rw=@
192.168.0.107/32,root=@192.168.0.107/32
/znapzend/DellOptiPlex390MT/export  -   nfs sec=sys,rw=@
192.168.0.107/32,root=@192.168.0.107/32
/znapzend/DellOptiPlex390MT/export/home -   nfs sec=sys,rw=@
192.168.0.107/32,root=@192.168.0.107/32
/znapzend/DellOptiPlex390MT/ROOT-   nfs sec=sys,rw=@
192.168.0.107/32,root=@192.168.0.107/32

Now, I only ever explicitly (i.e. manually executed a command to) NFS
shared rpool1. It looks like all the child filesystems (created afterwards)
got shared too.

Let's see what happens when I try to unshare the child datasets:

# zfs set sharenfs=off rpool1/znapzend

Now /etc/dfs/sharetab contains:

/rpool1 -   nfs sec=sys,rw=@192.168.0.107/32,root=@192.168.0.107/32

$ cd /rpool1 (where rpool1 is mounted) works, so I think that should fix
the problem, in theory. Unless anyone thinks it won't, in which case I urge
you to speak up :)

Thank you for the investigative direction idea and you and Alan both for
the quick replies.

On Tue, May 4, 2021 at 6:28 PM Joshua M. Clulow via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

> On Tue, 4 May 2021 at 16:25, Judah Richardson 
> wrote:
> > Extremely stupid question: is the fact that those mounted locations
> contain
> > ZFS snapshots resulting from znapzend's underlying use of zfs send &
> receive
> > and not actual physical directories possibly why find, cd, etc. can't
> reach
> > them?
> >
> > Shooting in the dark here; that's the only thing I can come up with.
>
> I think it would be easiest to take a look at the shell script and see
> what it gets out of sharetab and what it does with find.
>
> 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 mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Which OI service cleans up hidden NFS files?

[Joshua M. Clulow via openindiana-discuss]

On Tue, 4 May 2021 at 16:25, Judah Richardson  wrote:
> Extremely stupid question: is the fact that those mounted locations contain
> ZFS snapshots resulting from znapzend's underlying use of zfs send & receive
> and not actual physical directories possibly why find, cd, etc. can't reach
> them?
>
> Shooting in the dark here; that's the only thing I can come up with.

I think it would be easiest to take a look at the shell script and see
what it gets out of sharetab and what it does with find.

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] Which OI service cleans up hidden NFS files?

[Judah Richardson]

Extremely stupid question: is the fact that those mounted locations contain
ZFS snapshots resulting from znapzend's underlying use of zfs send & receive
and not actual physical directories possibly why find, cd, etc. can't reach
them?

Shooting in the dark here; that's the only thing I can come up with.

On Tue, May 4, 2021 at 6:15 PM Judah Richardson 
wrote:

>
>
> On Tue, May 4, 2021 at 5:53 PM Alan Coopersmith <
> alan.coopersm...@oracle.com> wrote:
>
>> On 5/4/21 3:38 PM, Judah Richardson wrote:
>> > I did some searching about the error message and found this Solaris
>> > documentation page
>> >  about
>> > removing hidden NFS files. It says that the above error is due to
>> something
>> > called nfsfind, but that nfsfind should be superseded by a service
>> called
>> > svc:/network/nfs/cleanup.
>>
>> It also says that the nfs cleanup service was added in Solaris 11.4,
>> which is
>> much newer than the pre-Solaris-11.0 base that OpenIndiana/illumos is
>> based on.
>>
> Good point. I'm often not sure how closely OI tracks Solaris in one thing
> or the other, which is why I ask questions.
>
>>
>> Don't you still have the nfsfind command in your root crontab?
>>
>>
>> https://github.com/illumos/illumos-gate/blob/9ecd05bdc59e4a1091c51ce68cce2028d5ba6fd1/usr/src/cmd/Adm/root#L30
>
> Yes I do.
>
> I think I found the problem, but I can't explain why it's happening. The
> directories in question are mounted:
>
> $ mount | grep znapzend
> /znapzend on rpool1/znapzend
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10008 on Fri Apr
> 30 21:59:04 2021
> /znapzend/DellOptiPlex390MT on rpool1/znapzend/DellOptiPlex390MT
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10034 on Sat May
> 1 10:00:03 2021
> /znapzend/DellOptiPlex390MT/ROOT on rpool1/znapzend/DellOptiPlex390MT/ROOT
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c1003a on Sat May
> 1 10:00:04 2021
> /znapzend/DellOptiPlex390MT/ROOT/openindiana on
> rpool1/znapzend/DellOptiPlex390MT/ROOT/openindiana
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c1003c on Sat May
> 1 10:03:00 2021
> /znapzend/DellOptiPlex390MT/export on
> rpool1/znapzend/DellOptiPlex390MT/export
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c1003d on Sat May
> 1 10:03:22 2021
> /znapzend/DellOptiPlex390MT/export/home on
> rpool1/znapzend/DellOptiPlex390MT/export/home
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10040 on Sat May
> 1 10:03:33 2021
> /znapzend/DellOptiPlex390MT/export/home/judah on
> rpool1/znapzend/DellOptiPlex390MT/export/home/judah
> read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10042 on Sat May
> 1 10:03:48 2021
>
> But I can't navigate to them, and so neither can the find $dir -type f
> -name .nfs command in the nfsfind script:
>
> $ cd /znapzend/DellOptiPlex390MT/ROOT/openindiana
> -bash: cd: /znapzend/DellOptiPlex390MT/ROOT/openindiana: No such file or
> directory
>
> # find /znapzend/DellOptiPlex390MT/ROOT/openindiana -type f -name .nfs
> find: ‘/znapzend/DellOptiPlex390MT/ROOT/openindiana’: No such file or
> directory
>
> I'm reasonably sure there's something obvious here I'm missing.
>
> Is it possible that znapzend makes destination filesystems unreachable to
> prevent them from being tampered with? What would I check for to see if
> this is the case?
>
>
>>
>> -alan-
>>
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Multiboot on PC

[Chris]

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

In message , Chris writes:

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


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

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


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

Thanks!

--Chris

John
groenv...@acm.org

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


--

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

Re: [OpenIndiana-discuss] Which OI service cleans up hidden NFS files?

[Judah Richardson]

On Tue, May 4, 2021 at 5:53 PM Alan Coopersmith 
wrote:

> On 5/4/21 3:38 PM, Judah Richardson wrote:
> > I did some searching about the error message and found this Solaris
> > documentation page
> >  about
> > removing hidden NFS files. It says that the above error is due to
> something
> > called nfsfind, but that nfsfind should be superseded by a service called
> > svc:/network/nfs/cleanup.
>
> It also says that the nfs cleanup service was added in Solaris 11.4, which
> is
> much newer than the pre-Solaris-11.0 base that OpenIndiana/illumos is
> based on.
>
Good point. I'm often not sure how closely OI tracks Solaris in one thing
or the other, which is why I ask questions.

>
> Don't you still have the nfsfind command in your root crontab?
>
>
> https://github.com/illumos/illumos-gate/blob/9ecd05bdc59e4a1091c51ce68cce2028d5ba6fd1/usr/src/cmd/Adm/root#L30

Yes I do.

I think I found the problem, but I can't explain why it's happening. The
directories in question are mounted:

$ mount | grep znapzend
/znapzend on rpool1/znapzend
read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10008 on Fri Apr
30 21:59:04 2021
/znapzend/DellOptiPlex390MT on rpool1/znapzend/DellOptiPlex390MT
read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10034 on Sat May
1 10:00:03 2021
/znapzend/DellOptiPlex390MT/ROOT on rpool1/znapzend/DellOptiPlex390MT/ROOT
read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c1003a on Sat May
1 10:00:04 2021
/znapzend/DellOptiPlex390MT/ROOT/openindiana on
rpool1/znapzend/DellOptiPlex390MT/ROOT/openindiana
read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c1003c on Sat May
1 10:03:00 2021
/znapzend/DellOptiPlex390MT/export on
rpool1/znapzend/DellOptiPlex390MT/export
read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c1003d on Sat May
1 10:03:22 2021
/znapzend/DellOptiPlex390MT/export/home on
rpool1/znapzend/DellOptiPlex390MT/export/home
read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10040 on Sat May
1 10:03:33 2021
/znapzend/DellOptiPlex390MT/export/home/judah on
rpool1/znapzend/DellOptiPlex390MT/export/home/judah
read/write/setuid/devices/nonbmand/exec/xattr/atime/dev=4c10042 on Sat May
1 10:03:48 2021

But I can't navigate to them, and so neither can the find $dir -type f
-name .nfs command in the nfsfind script:

$ cd /znapzend/DellOptiPlex390MT/ROOT/openindiana
-bash: cd: /znapzend/DellOptiPlex390MT/ROOT/openindiana: No such file or
directory

# find /znapzend/DellOptiPlex390MT/ROOT/openindiana -type f -name .nfs
find: ‘/znapzend/DellOptiPlex390MT/ROOT/openindiana’: No such file or
directory

I'm reasonably sure there's something obvious here I'm missing.

Is it possible that znapzend makes destination filesystems unreachable to
prevent them from being tampered with? What would I check for to see if
this is the case?


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

Re: [OpenIndiana-discuss] Which OI service cleans up hidden NFS files?

[Judah Richardson]

On Tue, May 4, 2021 at 5:46 PM Joshua M. Clulow via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

> On Tue, 4 May 2021 at 15:39, Judah Richardson 
> wrote:
> > The other day my OI machine emailed (thank Peter Tribble, *et al*, who
> > helped me get that set up) me this error:
> >
> > find: cannot open /znapzend/DellOptiPlex390MT/ROOT/openindiana: No such
> > file or directory
> >
> > I did some searching about the error message and found this Solaris
> > documentation page
> >  about
> > removing hidden NFS files. It says that the above error is due to
> something
> > called nfsfind, but that nfsfind should be superseded by a service called
> > svc:/network/nfs/cleanup.
>
> We don't have a periodic execution mode for SMF like Oracle Solaris.
> The NFS cleanup task is run from the default root crontab:
>
>
> http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/Adm/root?r=fd324b96#30
>
> > How do I fix this error? Disabling the crontab job that throws it is an
> > option, but since the crontab job cleans up stale NFS files I don't think
> > that's a good idea. Would I share rpool1's child datasets via NFS
> > specifically fix it?
>
> I'm not sure exactly but it seems like nfsfind is a pretty basic shell
> script that may not have both its arms completely around the problem.
> It'd be good to get an illumos bug logged with the issue you've
> described, including the sequence of ZFS/NFS operations you've used to
> get the system into this state so that whatever the fix is can be
> tested well.
>
Thanks for the quick reply. I actually don't think it's an OI bug. More
details in a bit.

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

Re: [OpenIndiana-discuss] Multiboot on PC

[John D Groenveld]

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

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

Regardless, when I have a spare moment, I'll try fix any handbook
sections that are confusing.
John
groenv...@acm.org

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

Re: [OpenIndiana-discuss] Which OI service cleans up hidden NFS files?

[Alan Coopersmith]

On 5/4/21 3:38 PM, Judah Richardson wrote:

I did some searching about the error message and found this Solaris
documentation page
 about
removing hidden NFS files. It says that the above error is due to something
called nfsfind, but that nfsfind should be superseded by a service called
svc:/network/nfs/cleanup.


It also says that the nfs cleanup service was added in Solaris 11.4, which is
much newer than the pre-Solaris-11.0 base that OpenIndiana/illumos is based on.

Don't you still have the nfsfind command in your root crontab?

https://github.com/illumos/illumos-gate/blob/9ecd05bdc59e4a1091c51ce68cce2028d5ba6fd1/usr/src/cmd/Adm/root#L30

-alan-

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

Re: [OpenIndiana-discuss] Which OI service cleans up hidden NFS files?

[Joshua M. Clulow via openindiana-discuss]

On Tue, 4 May 2021 at 15:39, Judah Richardson  wrote:
> The other day my OI machine emailed (thank Peter Tribble, *et al*, who
> helped me get that set up) me this error:
>
> find: cannot open /znapzend/DellOptiPlex390MT/ROOT/openindiana: No such
> file or directory
>
> I did some searching about the error message and found this Solaris
> documentation page
>  about
> removing hidden NFS files. It says that the above error is due to something
> called nfsfind, but that nfsfind should be superseded by a service called
> svc:/network/nfs/cleanup.

We don't have a periodic execution mode for SMF like Oracle Solaris.
The NFS cleanup task is run from the default root crontab:


http://src.illumos.org/source/xref/illumos-gate/usr/src/cmd/Adm/root?r=fd324b96#30

> How do I fix this error? Disabling the crontab job that throws it is an
> option, but since the crontab job cleans up stale NFS files I don't think
> that's a good idea. Would I share rpool1's child datasets via NFS
> specifically fix it?

I'm not sure exactly but it seems like nfsfind is a pretty basic shell
script that may not have both its arms completely around the problem.
It'd be good to get an illumos bug logged with the issue you've
described, including the sequence of ZFS/NFS operations you've used to
get the system into this state so that whatever the fix is can be
tested well.

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] Which OI service cleans up hidden NFS files?

[Judah Richardson]

Hi All,

The other day my OI machine emailed (thank Peter Tribble, *et al*, who
helped me get that set up) me this error:

find: cannot open /znapzend/DellOptiPlex390MT/ROOT/openindiana: No such
file or directory
find: cannot open /znapzend/DellOptiPlex390MT/export/home/judah: No such
file or directory
find: cannot open /znapzend/DellOptiPlex390MT/export: No such file or
directory
find: cannot open /znapzend/DellOptiPlex390MT/export/home: No such file or
directory
find: cannot open /znapzend/DellOptiPlex390MT/ROOT: No such file or
directory

The following are details about the filesystems and their mountpoints,
because I'm not sure if those are contributing factors or not:

   - /znapzend is the mountpoint for rpool1/znapzend/, a ZFS fiesystem I
   created as a destination for znapzend
   - rpool1 itself is mounted at /rpool1. It is shared via NFS (but the
   child dataset rpool1/znapzend is not)

I did some searching about the error message and found this Solaris
documentation page
 about
removing hidden NFS files. It says that the above error is due to something
called nfsfind, but that nfsfind should be superseded by a service called
svc:/network/nfs/cleanup.

However, such a service does not exist on my machine:

judah@DellOptiPlex390MT 2021-05-04 17:30:11:/$ svcs | grep cleanup
judah@DellOptiPlex390MT 2021-05-04 17:31:02:/$

How do I fix this error? Disabling the crontab job that throws it is an
option, but since the crontab job cleans up stale NFS files I don't think
that's a good idea. Would I share rpool1's child datasets via NFS
specifically fix it?

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

Re: [OpenIndiana-discuss] Multiboot on PC

[Chris]

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

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

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

rgds,
toomas


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

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

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

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

--Chris


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

Cheers,
James

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


--

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

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

[Judah Richardson]

On Tue, May 4, 2021 at 5:16 PM Reginald Beardsley via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

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

1) Try a disk under 2 TB
2) Set the BIOS to legacy boot after installation

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
>
___
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] OI-hipster-gui-20210430.iso progress report on 3 virtualization system

[Toomas Soome via openindiana-discuss]

> On 5. May 2021, at 00:41, Nelson H. F. Beebe  wrote:
> 
> I've now made installation attempts with the
> OI-hipster-gui-20210430.iso image on these three virtualization
> systems:
> 
>   * CentoS 7.9virt-manager/QEMU
>   * Ubuntu 20.04  virt-manager/QEMU
>   * Ubuntu 20.04  VirtualBox
> 
> Each VM is given 4GB DRAM, 4 CPUs, and 80GB disk; the latter is not
> partitioned, so ZFS uses the entire disk.  The disk image file is
> newly created, and so should have nothing but zero blocks.
> 
> On all three, the GUI installer worked as expected, and I selected a
> time zone (America/Denver), created one ordinary user account, and
> supplied a root password.  Installation completed normally, and the
> systems rebooted.
> 
> On the CentOS-based VM, the one on which I reported boot problems
> before, after the system rebooted, I logged in, used the network GUI
> tool to change to static IPv4 addressing, made one ZFS snapshot, ran
> "sync" (twice) then "poweroff", then took a virt-manager snapshot.  On
> the next reboot, I again got a similar problem to what I reported
> previously.
> 
>   ZFS: i/o error - all block copies unavailable
>   ZFS: failed to read pool rpool directory object


Instead of poweroff, if you run reboot, pause autoboot and then switch VM off, 
is it still broken?

Other option is to create mirror on rpool, if the system will come up, run 
zpool scrub and see if it will find anything.

rgds,
toomas


> 
> On the Ubuntu virt-manager VM, reboots are problem free, and the VM is
> fully configured with a large number of installed packages, and is
> working nicely as part of our test farm.
> 
> The Ubuntu VirtualBox VM built normally. and rebooted normally, so I
> took a ZFS snapshot, rebooted, and started to install packages: it
> seems normal so far.
> 
> I'm not going to spend time trying to resurrect the VM on CentOS 7,
> but I'm still willing to try building on that system additional VMs
> from newer ISO releases for OpenIndiana Hipster.
> 
> One might be inclined to consider the CentOS-based VM as an example of
> failure, or bugs, inside the host O/S, or inside QEMU, or perhaps even
> the physical workstation (a 2015-vintage HP Z440 with 128GB DRAM, and
> several TB of disk storage, both EXT4 and ZFS).  However, that machine
> runs 80 to 100 simultaneous VMs with other O/Ses, and has been rock
> solid in its almost six years of service.  That would tend to
> exonerate the hardware, and virt-manager/QEMU, suggesting that
> something inside OpenIndiana is causing the problem.  However, the
> success of two other VMs from the same ISO image indicates that
> OpenIndiana is solid.
> 
> My workstation is essentially one-of-a-kind, so there is no way for me
> to see whether an apparently identical box from the same vendor would
> also experience failure of an OpenIndiana VM.
> 
> 
> ---
> - Nelson H. F. BeebeTel: +1 801 581 5254  
> -
> - University of UtahFAX: +1 801 581 4148  
> -
> - Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  
> -
> - 155 S 1400 E RM 233   be...@acm.org  be...@computer.org 
> -
> - Salt Lake City, UT 84112-0090, USAURL: 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] 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

[OpenIndiana-discuss] OI-hipster-gui-20210430.iso progress report on 3 virtualization system

[Nelson H. F. Beebe]

I've now made installation attempts with the
OI-hipster-gui-20210430.iso image on these three virtualization
systems:

* CentoS 7.9virt-manager/QEMU
* Ubuntu 20.04  virt-manager/QEMU
* Ubuntu 20.04  VirtualBox

Each VM is given 4GB DRAM, 4 CPUs, and 80GB disk; the latter is not
partitioned, so ZFS uses the entire disk.  The disk image file is
newly created, and so should have nothing but zero blocks.

On all three, the GUI installer worked as expected, and I selected a
time zone (America/Denver), created one ordinary user account, and
supplied a root password.  Installation completed normally, and the
systems rebooted.

On the CentOS-based VM, the one on which I reported boot problems
before, after the system rebooted, I logged in, used the network GUI
tool to change to static IPv4 addressing, made one ZFS snapshot, ran
"sync" (twice) then "poweroff", then took a virt-manager snapshot.  On
the next reboot, I again got a similar problem to what I reported
previously.

ZFS: i/o error - all block copies unavailable
ZFS: failed to read pool rpool directory object

On the Ubuntu virt-manager VM, reboots are problem free, and the VM is
fully configured with a large number of installed packages, and is
working nicely as part of our test farm.

The Ubuntu VirtualBox VM built normally. and rebooted normally, so I
took a ZFS snapshot, rebooted, and started to install packages: it
seems normal so far.

I'm not going to spend time trying to resurrect the VM on CentOS 7,
but I'm still willing to try building on that system additional VMs
from newer ISO releases for OpenIndiana Hipster.

One might be inclined to consider the CentOS-based VM as an example of
failure, or bugs, inside the host O/S, or inside QEMU, or perhaps even
the physical workstation (a 2015-vintage HP Z440 with 128GB DRAM, and
several TB of disk storage, both EXT4 and ZFS).  However, that machine
runs 80 to 100 simultaneous VMs with other O/Ses, and has been rock
solid in its almost six years of service.  That would tend to
exonerate the hardware, and virt-manager/QEMU, suggesting that
something inside OpenIndiana is causing the problem.  However, the
success of two other VMs from the same ISO image indicates that
OpenIndiana is solid.

My workstation is essentially one-of-a-kind, so there is no way for me
to see whether an apparently identical box from the same vendor would
also experience failure of an OpenIndiana VM.


---
- Nelson H. F. BeebeTel: +1 801 581 5254  -
- University of UtahFAX: +1 801 581 4148  -
- Department of Mathematics, 110 LCBInternet e-mail: be...@math.utah.edu  -
- 155 S 1400 E RM 233   be...@acm.org  be...@computer.org -
- Salt Lake City, UT 84112-0090, USAURL: http://www.math.utah.edu/~beebe/ -
---

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

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

[Joshua M. Clulow via openindiana-discuss]

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] Multiboot on PC

[James Madgwick]

On Mon, 3 May 2021 20:16:28 +0300
Toomas Soome via openindiana-discuss
 wrote:
> Only simple way is to use chainloader (point it to OS partition),
> then you are not depending on file system reader implementation etc
> etc.
> 
> rgds,
> toomas

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

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

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

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

Cheers,
James

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

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

[Peter Tribble via openindiana-discuss]

On Tue, May 4, 2021 at 3:53 PM Reginald Beardsley via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

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

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

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!

[Toomas Soome via openindiana-discuss]

> On 4. May 2021, at 22:09, Reginald Beardsley via openindiana-discuss 
>  wrote:
> 
> 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
> 
> 


First sector (MBR) is not read with UEFI boot. I see no reason, why it should 
not read first sector with BIOS boot:)

rgds,
toomas


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

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

[epektasis]

On Tue, May 04, 2021 at 02:52:01PM +, Reginald Beardsley via 
openindiana-discuss wrote:
> 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
> 

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

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

[Bob Friesenhahn]

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

Re: [OpenIndiana-discuss] Updates in OI

[Judah Richardson]

On Tue, May 4, 2021 at 12:05 PM Lou Picciano 
wrote:

>
>
> > On May 4, 2021, at 12:57 PM, Judah Richardson 
> wrote:
> >
> > On Tue, May 4, 2021 at 8:51 AM Toomas Soome via openindiana-discuss <
> > openindiana-discuss@openindiana.org> wrote:
> >
> >>
> >>> On 4. May 2021, at 16:27, Dave Miner  wrote:
> >>>
> >>> 
> >>>
> >>> On 5/4/2021 8:59 AM, Yassine Chaouche wrote:
>  Le 5/4/21 à 1:43 PM, Stephan Althaus a écrit :
> >
> > Hello!
> >
> > We have "Boot environments"
> >
> > On every "pkg update" you get a new BE that will be used on next
> >> reboot.
> 
>  This is just
> 
> >>> ...
>  Is this done by issuing a ZFS snapshot of the whole root partition ?
> or
>  is it more granular ?
> 
>  If this is done via snapshots, this means writing to an evergrowing
> >> file
>  on disk until the snapshot is removed. So the longer you keep a
> >> snapshot,
>  the bigger the file gets.
> 
> >>>
> >>> Yes, boot environments in the OpenSolaris-derived OS's are implemented
> >> using ZFS snapshots/clones of the root datasets.  Combined with IPS's
> >> optimizations to only update objects that have changed between package
> >> versions, you may find that boot environments for an update may not be
> >> nearly as large as the initial installation; it all depends on how much
> has
> >> changed.  Reclaiming space is as simple as deleting older boot
> environments
> >> when they're no longer needed.  It's not at all unusual for a system to
> >> have a dozen or more boot environments; some of the more masochistic
> among
> >> us used to have systems with 100 or more.
> >>>
> >>> Dave
> >>>
> >>
> >> With old grub, the number is limited to 50 - 60 becsuse of memory setup.
> >> With loader, I did demo with 600, but since loader is using sliding
> window,
> >> the number of BE’s is not limited there.
> >>
> > Is there ever a situation in which the disk can run out of space due to
> too
> > many BEs? And if so, how does one go about automatically pruning
> > old/unwanted BEs?
>
> I’m sure your root pool could eventually be strained to ‘max’ by installed
> BEs (though I imagine you’d be well-aware of this approaching limit as the
> new update(?) BE is being built.)
>
My experience with such things is they tend to happen sooner than expected,
especially with CoW filesystems. I've had Raspberry Pi OS choke because apt
cache had filled up the microSD card and I've also had a Btrfs pool become
unwriteable due to too many rsync snapshots and snapshot subvolumes. I'm
always concerned by space consuming things that increase without some
predefined bound ;)

>
> As to automation: I myself don’t automate deletions (of older BEs), but
> make it a matter of ‘good hygiene’ to clean up oldest ones, including their
> snapshots, when it’s clear these are BEs I’d never need to return to.
>
Fair. I prefer automation so that the process doesn't become subject to my
fallible memory or other human error.

>
> On that point, I’d say there have only been perhaps one or two instances -
> in 10+ years - in which I’ve really felt a need to revert to a BE, and only
> then to the most-recent one.
>
I've only ever reverted to a BE once before, on Project Trident back when
it was still based on FreeBSD, so I can relate.

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

[Judah Richardson]

On Tue, May 4, 2021 at 9:53 AM Reginald Beardsley via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

> I'm going to try one more time.
>
>
> ---
> The 2021.04.30  GUI Live Image has major problems.
>
> gparted(1m) dumps core
>
If you need to use gparted, use it on distribution on which it works. For
me that's my Ubuntu, Raspberry Pi OS, or Debian installations. This is what
I've meant by not having the mindset of 1 OS having to do everything.

>
> 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
>
I do believe I've complained about this before, too. But I was able to work
around them and documented the workaround for others.

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

This requires either having a dedicated test machine or disassembling an
existing running machine to install a blank disk to test. Then possibly
keeping that machine offline while any discovered bugs are addressed. For
even someone like me with 10 bare metal machines on hand, that's a tall
order as I don't have the budget for a bare metal testbed, and I have
enough trouble keeping up with the issues of my existing hardware and
distribution installations as is.

>
>
> We simply need a review process such that broken installation images are
> not posted for general distribution.

I take a different view of this. I prefer devs and the community be
transparent about what works and what doesn't as opposed to pretending
something works when it doesn't. Which is why I've been pretty
straightforward with my "rolling release" comments in previous emails as
well as my gparted one above.


>   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.
>
I, personally, cannot be of assistance there.

>
> 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.
>
True. But as I said in a previous email, OSes are tools, and some tools
fall out of use/favor with the general population for a variety of reasons.
The aim is not to preserve tools as sacred artifacts, it's to preserve the
ability to do something (e.g. drill a hole, run a service) regardless of
which tool or distribution is used for that purpose.

>
>
> 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] Updates in OI

[Lou Picciano]

> On May 4, 2021, at 12:57 PM, Judah Richardson  
> wrote:
> 
> On Tue, May 4, 2021 at 8:51 AM Toomas Soome via openindiana-discuss <
> openindiana-discuss@openindiana.org> wrote:
> 
>> 
>>> On 4. May 2021, at 16:27, Dave Miner  wrote:
>>> 
>>> 
>>> 
>>> On 5/4/2021 8:59 AM, Yassine Chaouche wrote:
 Le 5/4/21 à 1:43 PM, Stephan Althaus a écrit :
> 
> Hello!
> 
> We have "Boot environments"
> 
> On every "pkg update" you get a new BE that will be used on next
>> reboot.
 
 This is just
 
>>> ...
 Is this done by issuing a ZFS snapshot of the whole root partition ? or
 is it more granular ?
 
 If this is done via snapshots, this means writing to an evergrowing
>> file
 on disk until the snapshot is removed. So the longer you keep a
>> snapshot,
 the bigger the file gets.
 
>>> 
>>> Yes, boot environments in the OpenSolaris-derived OS's are implemented
>> using ZFS snapshots/clones of the root datasets.  Combined with IPS's
>> optimizations to only update objects that have changed between package
>> versions, you may find that boot environments for an update may not be
>> nearly as large as the initial installation; it all depends on how much has
>> changed.  Reclaiming space is as simple as deleting older boot environments
>> when they're no longer needed.  It's not at all unusual for a system to
>> have a dozen or more boot environments; some of the more masochistic among
>> us used to have systems with 100 or more.
>>> 
>>> Dave
>>> 
>> 
>> With old grub, the number is limited to 50 - 60 becsuse of memory setup.
>> With loader, I did demo with 600, but since loader is using sliding window,
>> the number of BE’s is not limited there.
>> 
> Is there ever a situation in which the disk can run out of space due to too
> many BEs? And if so, how does one go about automatically pruning
> old/unwanted BEs?

I’m sure your root pool could eventually be strained to ‘max’ by installed BEs 
(though I imagine you’d be well-aware of this approaching limit as the new 
update(?) BE is being built.)

As to automation: I myself don’t automate deletions (of older BEs), but make it 
a matter of ‘good hygiene’ to clean up oldest ones, including their snapshots, 
when it’s clear these are BEs I’d never need to return to.

On that point, I’d say there have only been perhaps one or two instances - in 
10+ years - in which I’ve really felt a need to revert to a BE, and only then 
to the most-recent one.

>> 
>> Rgds,
>> Toomas
>> ___
>> openindiana-discuss mailing list
>> openindiana-discuss@openindiana.org
>> https://openindiana.org/mailman/listinfo/openindiana-discuss
>> 
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss


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

Re: [OpenIndiana-discuss] Updates in OI

[Judah Richardson]

On Tue, May 4, 2021 at 8:51 AM Toomas Soome via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

>
> > On 4. May 2021, at 16:27, Dave Miner  wrote:
> >
> > 
> >
> > On 5/4/2021 8:59 AM, Yassine Chaouche wrote:
> > > Le 5/4/21 à 1:43 PM, Stephan Althaus a écrit :
> > >>
> > >> Hello!
> > >>
> > >> We have "Boot environments"
> > >>
> > >> On every "pkg update" you get a new BE that will be used on next
> reboot.
> > >
> > > This is just
> > >
> > ...
> > > Is this done by issuing a ZFS snapshot of the whole root partition ? or
> > > is it more granular ?
> > >
> > > If this is done via snapshots, this means writing to an evergrowing
> file
> > > on disk until the snapshot is removed. So the longer you keep a
> snapshot,
> > > the bigger the file gets.
> > >
> >
> > Yes, boot environments in the OpenSolaris-derived OS's are implemented
> using ZFS snapshots/clones of the root datasets.  Combined with IPS's
> optimizations to only update objects that have changed between package
> versions, you may find that boot environments for an update may not be
> nearly as large as the initial installation; it all depends on how much has
> changed.  Reclaiming space is as simple as deleting older boot environments
> when they're no longer needed.  It's not at all unusual for a system to
> have a dozen or more boot environments; some of the more masochistic among
> us used to have systems with 100 or more.
> >
> > Dave
> >
>
> With old grub, the number is limited to 50 - 60 becsuse of memory setup.
> With loader, I did demo with 600, but since loader is using sliding window,
> the number of BE’s is not limited there.
>
Is there ever a situation in which the disk can run out of space due to too
many BEs? And if so, how does one go about automatically pruning
old/unwanted BEs?

>
> Rgds,
> Toomas
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Rolling release considered harmful

[Judah Richardson]

On Tue, May 4, 2021 at 8:35 AM Toomas Soome via openindiana-discuss <
openindiana-discuss@openindiana.org> wrote:

>
> > On 4. May 2021, at 16:01, Yassine Chaouche 
> wrote:
> >
> > Le 5/4/21 à 1:54 PM, Aurélien Larcher a écrit :
> >>> On Tue, May 4, 2021 at 2:40 PM Judah Richardson <
> judahrichard...@gmail.com> wrote:
> >>> On Tue, May 4, 2021, 07:25 Yassine Chaouche <
> a.chaou...@algerian-radio.dz> wrote:
>  Le 5/4/21 à 5:24 AM, Judah Richardson a écrit :
> > From a practical perspective, I don't think OI has the option you
> want. It's a rolling release distribution. I
>  So, just to be clear for outsiders like myself. I thought Hipster was
> the Rolling Release Branch. I assumed OI had another fixed release branche,
> but apparently there's not ?
> >>> Hipster is the only release mentioned on the blog in over 2 years and
> the only release listed on the download page. I had the same question when
> I 1st downloaded OI, but it was pretty obvious to me from the above that
> Hipster is the main effort, and so that's what I installed. Don't fight the
> paradigm, as I keep saying.
> >> Upgrades of Ubuntu LTS break more than OI on my server and without any
> possibility of rollback to a previous boot environment...
> > Upgrades != updates.
> >
>
> Hm, what is the difference?:)
>
The semantics vary by OS and ecosystem.

Personally: I use "update" to refer to any version number advance &
"upgrade" to refer to any SKU or service/subscription level advance. So,
e.g. I would consider going from Ubuntu 20.10 to 21.04 an update, and going
from Zabbix free to Zabbix paid an upgrade.

But in practice to avoid confusion in online discussions I use them to mean
what passing either update or upgrade to the package manager of the OS in
question does.

>
> Rgds,
> Toomas
> ___
> openindiana-discuss mailing list
> openindiana-discuss@openindiana.org
> https://openindiana.org/mailman/listinfo/openindiana-discuss
>
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Rolling release considered harmful

[Judah Richardson]

On Tue, May 4, 2021 at 7:56 AM Aurélien Larcher 
wrote:

> On Tue, May 4, 2021 at 2:40 PM Judah Richardson  >
> wrote:
>
> > On Tue, May 4, 2021, 07:25 Yassine Chaouche <
> a.chaou...@algerian-radio.dz>
> > wrote:
> >
> > > Le 5/4/21 à 5:24 AM, Judah Richardson a écrit :
> > > > From a practical perspective, I don't think OI has the option you
> want.
> > > > It's a rolling release distribution. I
> > > So, just to be clear for outsiders like myself. I thought Hipster
> > > was the Rolling Release Branch. I assumed OI had another fixed
> > > release branche, but apparently there's not ?
> > >
> > Hipster is the only release mentioned on the blog in over 2 years and the
> > only release listed on the download page. I had the same question when I
> > 1st downloaded OI, but it was pretty obvious to me from the above that
> > Hipster is the main effort, and so that's what I installed. Don't fight
> the
> > paradigm, as I keep saying.
> >
>
> Upgrades of Ubuntu LTS break more

Interesting. I run the 6 month cycle Ubuntu releases. I'm currently on
20.10 waiting for the update app to offer me 21.04. From my reading of the
problems users typically encounter, LTS is for folks who want security
patches only, with the understanding that they'll probably have to clean
install the next LTS release if you want it (because of the version gap
challenge I mentioned earlier.)

than OI

OK, so your experience with OI stuff not breaking between pkg upgrade
reboots is the same as mine :)

on my server and without any
> possibility of rollback to a previous boot environment...
>
I do believe Ubuntu has supported rollbacks for ZFS root installations
since 20.04 LTS.

>
> I think the idea of a "stable release" prepared for several years of
> production should be relaxed...
> Even on our last supercomputer we had to move to CentOS Stream

What has your experience with that been?

since CentOS
> has dropped support for a stable release...
>
>
>
> >
> >
> > > -- 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
> >
>
>
> --
> ---
> Praise the Caffeine embeddings
> ___
> 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] Rolling release considered harmful

[Yassine Chaouche]

Le 5/4/21 à 4:52 PM, Yassine Chaouche a écrit :


I am beginning to appreciate a little more how containers fix this 
compatibility issue.
The only thing I need to figure out is how to get the most out of 
containers
optimisation-wise, i.e still getting a way to share common libraries 
between
same-generation apps. Otherwise, I see software distribution going 
full circle



+---+
++Every software uses its own library+>>+
   snap, docker, virtual ^ 
+---+  v
   environements, appImage, 
^   v 
Introducing shared libraries
   whole VMs. 
^   v
+--+---+ 
+--v-+
  |This particular software needs lib L |    
|  Let's have common code in shared  |
  |version 2 but your system relies on |    |  
libraries, this should make apps  |
  |lib L version 1. |    |  smaller in size 
and easier to |
+--^---+    | 
maintain. |

^ +--+-+
^   v
+<<<+
  Can't have 
multiple versions
   of same 
lib



-- Yassine.



Oops, formatting failed, let's try again.


  
+---+


 ++Every software uses its 
own library+>>+


   snap, docker, virtual ^    
+---+  v


   environements, appImage,  
^   v   
Introducing shared libraries


   whole VMs.    
^   v


  +--+---+    
+--v-+


  |This particular software needs lib L  |    
|  Let's have common code in shared  |


  |version 2 but your system relies on   |    
|  libraries, this should make apps  |


  |lib L version 1.  |    
|  smaller in size and easier to |


  +--^---+    
|  maintain. |


 ^    
+--+-+


 
^   v


 
+<<<+


  Can't have 
multiple versions


   of same lib



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

Re: [OpenIndiana-discuss] Rolling release considered harmful

[Yassine Chaouche]

Le 5/4/21 à 3:37 PM, Toomas Soome via openindiana-discuss a écrit :



Well you can *update* packages and remain in same OS version. Or,
you can *upgrade* to next OS version, for example from Ubuntu 16
to Ubuntu 17. In that case yes, breaks happen, and most users
prefer to simply reinstall instead of upgrading, which they
consider cleaner.


Well, with upgrade you get new OS version [...] because you have technical 
changes which are either not compatible with current apps or introduce some 
major (new) technologies into the system.

But when our interfaces remain stable and we do not break the apps and we do 
not have marketing department… we can just update. But then again, things are 
never that simple;)


I am beginning to appreciate a little more how containers fix this 
compatibility issue.
The only thing I need to figure out is how to get the most out of 
containers
optimisation-wise, i.e still getting a way to share common libraries 
between
same-generation apps. Otherwise, I see software distribution going full 
circle



+---+
++Every software uses its own library+>>+
   snap, docker, virtual ^ 
+---+  v
   environements, appImage, 
^   v 
Introducing shared libraries

   whole VMs. ^   v
+--+---+ 
+--v-+
  |This particular software needs lib L |    |  
Let's have common code in shared  |
  |version 2 but your system relies on |    |  
libraries, this should make apps  |
  |lib L version 1. |    |  smaller in size and 
easier to |
+--^---+    | 
maintain. |

^ +--+-+
^   v
+<<<+
  Can't have 
multiple versions

   of same lib


-- Yassine.

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

Re: [OpenIndiana-discuss] Rolling release considered harmful

[John D Groenveld]

In message 
, =?UTF-8?Q?Aur=C3=A9lien_Larcher?= writes:
>Upgrades of Ubuntu LTS break more than OI on my server and without any
>possibility of rollback to a previous boot environment...

The Project Trident devs are making progress to integrate BEs into
Void Linux.
https://project-trident.org/>

Definitely worth checking out. Void runs in bhyve(5) or VirtualBox.

John
groenv...@acm.org

___
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

[Toomas Soome via openindiana-discuss]

> On 4. May 2021, at 16:55, Yassine Chaouche  
> wrote:
> 
> Le 5/4/21 à 2:34 PM, Toomas Soome via openindiana-discuss a écrit :
>> Upgrades of Ubuntu LTS break more than OI on my server and without any 
>> possibility of rollback to a previous boot environment...
>>> Upgrades != updates. 
>> Hm, what is the difference?:) Rgds, Toomas
> 
> Well you can *update* packages and remain in same OS version. Or,
> you can *upgrade* to next OS version, for example from Ubuntu 16
> to Ubuntu 17. In that case yes, breaks happen, and most users
> prefer to simply reinstall instead of upgrading, which they
> consider cleaner.
> 

Well, with upgrade you get new OS version, which may have been created because 
of marketing reasons (we have so many new features since year X, so lets call 
ot new version), or because you have technical changes which are either not 
compatible with current apps or introduce some major (new) technologies into 
the system.

But when our interfaces remain stable and we do not break the apps and we do 
not have marketing department… we can just update. But then again, things are 
never that simple;)

rgds,
toomas


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

Re: [OpenIndiana-discuss] Rolling release considered harmful

[Aurélien Larcher]

On Tue, May 4, 2021 at 3:56 PM Yassine Chaouche <
a.chaou...@algerian-radio.dz> wrote:

> Le 5/4/21 à 2:34 PM, Toomas Soome via openindiana-discuss a écrit :
> > Upgrades of Ubuntu LTS break more than OI on my server and without any
> > possibility of rollback to a previous boot environment...
> >> Upgrades != updates.
> > Hm, what is the difference?:) Rgds, Toomas
>
> Well you can *update* packages and remain in same OS version. Or,
> you can *upgrade* to next OS version, for example from Ubuntu 16
> to Ubuntu 17. In that case yes, breaks happen, and most users
> prefer to simply reinstall instead of upgrading, which they
> consider cleaner.
>

Yes and sometimes it does not feel like it is 2021 ;)

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


-- 
---
Praise the Caffeine embeddings
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Rolling release considered harmful

[Yassine Chaouche]

Le 5/4/21 à 2:34 PM, Toomas Soome via openindiana-discuss a écrit :
Upgrades of Ubuntu LTS break more than OI on my server and without any 
possibility of rollback to a previous boot environment...
Upgrades != updates. 

Hm, what is the difference?:) Rgds, Toomas


Well you can *update* packages and remain in same OS version. Or,
you can *upgrade* to next OS version, for example from Ubuntu 16
to Ubuntu 17. In that case yes, breaks happen, and most users
prefer to simply reinstall instead of upgrading, which they
consider cleaner.

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

Re: [OpenIndiana-discuss] Updates in OI

[Toomas Soome via openindiana-discuss]

> On 4. May 2021, at 16:27, Dave Miner  wrote:
> 
> 
> 
> On 5/4/2021 8:59 AM, Yassine Chaouche wrote:
> > Le 5/4/21 à 1:43 PM, Stephan Althaus a écrit :
> >>
> >> Hello!
> >>
> >> We have "Boot environments"
> >>
> >> On every "pkg update" you get a new BE that will be used on next reboot.
> >
> > This is just
> >
> ...
> > Is this done by issuing a ZFS snapshot of the whole root partition ? or
> > is it more granular ?
> >
> > If this is done via snapshots, this means writing to an evergrowing file
> > on disk until the snapshot is removed. So the longer you keep a snapshot,
> > the bigger the file gets.
> >
> 
> Yes, boot environments in the OpenSolaris-derived OS's are implemented using 
> ZFS snapshots/clones of the root datasets.  Combined with IPS's optimizations 
> to only update objects that have changed between package versions, you may 
> find that boot environments for an update may not be nearly as large as the 
> initial installation; it all depends on how much has changed.  Reclaiming 
> space is as simple as deleting older boot environments when they're no longer 
> needed.  It's not at all unusual for a system to have a dozen or more boot 
> environments; some of the more masochistic among us used to have systems with 
> 100 or more.
> 
> Dave
> 

With old grub, the number is limited to 50 - 60 becsuse of memory setup. With 
loader, I did demo with 600, but since loader is using sliding window, the 
number of BE’s is not limited there.

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

Re: [OpenIndiana-discuss] Rolling release considered harmful

[Toomas Soome via openindiana-discuss]

> On 4. May 2021, at 16:01, Yassine Chaouche  
> wrote:
> 
> Le 5/4/21 à 1:54 PM, Aurélien Larcher a écrit :
>>> On Tue, May 4, 2021 at 2:40 PM Judah Richardson  
>>> wrote:
>>> On Tue, May 4, 2021, 07:25 Yassine Chaouche  
>>> wrote:
 Le 5/4/21 à 5:24 AM, Judah Richardson a écrit :
> From a practical perspective, I don't think OI has the option you want. 
> It's a rolling release distribution. I 
 So, just to be clear for outsiders like myself. I thought Hipster was the 
 Rolling Release Branch. I assumed OI had another fixed release branche, 
 but apparently there's not ? 
>>> Hipster is the only release mentioned on the blog in over 2 years and the 
>>> only release listed on the download page. I had the same question when I 
>>> 1st downloaded OI, but it was pretty obvious to me from the above that 
>>> Hipster is the main effort, and so that's what I installed. Don't fight the 
>>> paradigm, as I keep saying. 
>> Upgrades of Ubuntu LTS break more than OI on my server and without any 
>> possibility of rollback to a previous boot environment...
> Upgrades != updates.
> 

Hm, what is the difference?:)

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

Re: [OpenIndiana-discuss] Updates in OI

[Dave Miner]

On 5/4/2021 8:59 AM, Yassine Chaouche wrote:
> Le 5/4/21 à 1:43 PM, Stephan Althaus a écrit :
>>
>> Hello!
>>
>> We have "Boot environments"
>>
>> On every "pkg update" you get a new BE that will be used on next reboot.
>
> This is just
>
...
> Is this done by issuing a ZFS snapshot of the whole root partition ? or
> is it more granular ?
>
> If this is done via snapshots, this means writing to an evergrowing file
> on disk until the snapshot is removed. So the longer you keep a snapshot,
> the bigger the file gets.
>

Yes, boot environments in the OpenSolaris-derived OS's are implemented 
using ZFS snapshots/clones of the root datasets.  Combined with IPS's 
optimizations to only update objects that have changed between package 
versions, you may find that boot environments for an update may not be 
nearly as large as the initial installation; it all depends on how much 
has changed.  Reclaiming space is as simple as deleting older boot 
environments when they're no longer needed.  It's not at all unusual for 
a system to have a dozen or more boot environments; some of the more 
masochistic among us used to have systems with 100 or more.


Dave



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

Re: [OpenIndiana-discuss] Updates in OI

[Yassine Chaouche]

Le 5/4/21 à 1:55 PM, Judah Richardson a écrit :


Missing an update increases your

  chances of breaking the system on next update.


Correct with all OSes. The bigger the gap between versions, the less
reliable/robust the update will be.


Not in my experience. I can go months without doing a single
update on my old desktop, then decide to do one. I never had
a problem. But then again we're talking about (small) updates
(package upgrades, same OS version), not (whole) upgrades (a
change in OS version).

-- Yassine.



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

Re: [OpenIndiana-discuss] Rolling release considered harmful

[Yassine Chaouche]

Le 5/4/21 à 1:54 PM, Aurélien Larcher a écrit :
On Tue, May 4, 2021 at 2:40 PM Judah Richardson 
 wrote:
On Tue, May 4, 2021, 07:25 Yassine Chaouche 
 wrote:

Le 5/4/21 à 5:24 AM, Judah Richardson a écrit :
From a practical perspective, I don't think OI has the option you 
want. It's a rolling release distribution. I 
So, just to be clear for outsiders like myself. I thought Hipster 
was the Rolling Release Branch. I assumed OI had another fixed 
release branche, but apparently there's not ? 
Hipster is the only release mentioned on the blog in over 2 years and 
the only release listed on the download page. I had the same question 
when I 1st downloaded OI, but it was pretty obvious to me from the 
above that Hipster is the main effort, and so that's what I 
installed. Don't fight the paradigm, as I keep saying. 
Upgrades of Ubuntu LTS break more than OI on my server and without any 
possibility of rollback to a previous boot environment...

Upgrades != updates.

-- Yassine

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

Re: [OpenIndiana-discuss] Updates in OI

[Yassine Chaouche]

Le 5/4/21 à 1:43 PM, Stephan Althaus a écrit :


Hello!

We have "Boot environments"

On every "pkg update" you get a new BE that will be used on next reboot.


This is just

XXKc''',,',dk0KKXN
XXK0kc..';::...,''..,oO0KKKXXX
XXXK000:..,;;,;;;,;:ccc,. .;ok0KKX
XXXK0Oc,;:c;. ...,;:::lc..',:k0KX
KK000d;cdc. ..'',;;;cxo:kOO00XX
XXXK0Oxdd.   ',;:;,,... .',,'..dkOO0O000KX
XXK0dccdkdlo'.'cclo:,c;;,,'... ..;kOOO00OKKK
XK0xl;.. ;kd::..,;:dx:'oxkkkdl...',c:'.;kOkOO0KK
O:...,lOOOo:.  ..',.,odxxxoc:;,;,.''. .:xOO0KK
. ..,:oxxdo;. ...,'.:oodxdol:,;:odcc:;,''oOOO000KK
..'',,'.:kk,;...;c',odool:coko;:;;;,..l0KK
.',:oxxkxc:lkOOdl. .ldxxxddxko:,,;c;,..oO000KK
cc;,kOl'.,;lkOOOk.. .,;okkooolcokx,,:cc:;'..lOOO000KKK
c:;''';codkkOl..:;,odxkkxdlldOO00Od,::'. ;kOKK
ccc:cldkOO:'.,loxkkkkoook00kll:,..ckO000KK
llloxO00OOkl,''coxOO000OxdxOK00K0dxdxkOOO0Odx0OO0K
xkO0KK00OkkOO00000ccdO0OddO0KK
XX00OOkxxc,:,',kKKK00KKXXKx... .;:;:0koOKK
XXKOo:;'..    .:',oOKKkodxOOl.. ;0OodO000x0KKK
kxoolc:,'..lkO00KKK0ko,.,xKKK000kddk0O0KKK
kxkOxol:,,,'...,kOOO00k,. .'..;d;,0KK0OloX
O0KKkddllc:;;;:okOkkO00K00x:,;'.;od;,O00K0K00OKXXX
KKXXOOOxooolllok000K00Oxl',xdc;:0K0OKKKXX0xOXX
000OdxooddxK0KKOc:OOkd:000ox0KKxkX

Is this done by issuing a ZFS snapshot of the whole root partition ? or
is it more granular ?

If this is done via snapshots, this means writing to an evergrowing file
on disk until the snapshot is removed. So the longer you keep a snapshot,
the bigger the file gets.

-- Yassine

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

Re: [OpenIndiana-discuss] Updates in OI

[Judah Richardson]

On Tue, May 4, 2021 at 7:36 AM Yassine Chaouche <
a.chaou...@algerian-radio.dz> wrote:

> Dear OI community,
>
> I was never fond of Rolling Releases.

I generally don't use them either unless they're the only way to get
decently recent packages. The only other rolling release I use is the pkg
latest repo on FreeBSD RELEASE. Of course, because it's a RELEASE version
it's not a full-stack rolling release in the usual sense.

I tried a couple times,
> it always ended in an unrecoverable system and me switching
> back to a classic LTS linux distro (I'm a linux user myself).
>
> It generally boils down to these two essential problems :
>
>   1- Never miss an update.

My rule for all my OSes on this end is "update early, update often."
Everything I have is updated at least monthly (typically in lockstep with
Patch Tuesday). OI itself gets a pkg update and reboot at that time every
month unless there's a broken package that needs an extra update to be
fixed.

Missing an update increases your
>  chances of breaking the system on next update.
>
Correct with all OSes. The bigger the gap between versions, the less
reliable/robust the update will be.

>
>   2- You can't install a package if your system is out of date.
>
I avoid the question entirely by doing a package manager update for any
repo before I install anything from that repo. Always. For OI, most of my
packages come from pkgsrc and pkgin update does not update the BE or base
OS, so no reboot is required.

>  This means that if you chose to not update the system, for
>  example because of a known problematic package,

I find this very rare.

you won't
>  be able to install new software until that package is fixed.
>
Correct. I once couldn't update FreeBSD for a while because doing so would
have removed Firefox from my system.

 A workaround would be to pin that package to its current
>  version so that it doesn't get updated, and unpin it once
>  it gets fixed on next update (but see 1 about missing
>  updates)
>
> Out of curiosity, does this also apply to OI ?
>
See above. If you use pkgsrc (and for all practical reasons you will since
otherwise OI's package availability is extremely limited relative to other
distros) then you can update packages from it without having to worry about
the underlying OS.

>
> -- 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] Rolling release considered harmful

[Aurélien Larcher]

On Tue, May 4, 2021 at 2:40 PM Judah Richardson 
wrote:

> On Tue, May 4, 2021, 07:25 Yassine Chaouche 
> wrote:
>
> > Le 5/4/21 à 5:24 AM, Judah Richardson a écrit :
> > > From a practical perspective, I don't think OI has the option you want.
> > > It's a rolling release distribution. I
> > So, just to be clear for outsiders like myself. I thought Hipster
> > was the Rolling Release Branch. I assumed OI had another fixed
> > release branche, but apparently there's not ?
> >
> Hipster is the only release mentioned on the blog in over 2 years and the
> only release listed on the download page. I had the same question when I
> 1st downloaded OI, but it was pretty obvious to me from the above that
> Hipster is the main effort, and so that's what I installed. Don't fight the
> paradigm, as I keep saying.
>

Upgrades of Ubuntu LTS break more than OI on my server and without any
possibility of rollback to a previous boot environment...

I think the idea of a "stable release" prepared for several years of
production should be relaxed...
Even on our last supercomputer we had to move to CentOS Stream since CentOS
has dropped support for a stable release...



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


-- 
---
Praise the Caffeine embeddings
___
openindiana-discuss mailing list
openindiana-discuss@openindiana.org
https://openindiana.org/mailman/listinfo/openindiana-discuss

Re: [OpenIndiana-discuss] Updates in OI

[Stephan Althaus]

On 05/04/21 02:34 PM, Yassine Chaouche wrote:

Dear OI community,

I was never fond of Rolling Releases. I tried a couple times,
it always ended in an unrecoverable system and me switching
back to a classic LTS linux distro (I'm a linux user myself).

It generally boils down to these two essential problems :

 1- Never miss an update. Missing an update increases your
    chances of breaking the system on next update.

 2- You can't install a package if your system is out of date.
    This means that if you chose to not update the system, for
    example because of a known problematic package, you won't
    be able to install new software until that package is fixed.
    A workaround would be to pin that package to its current
    version so that it doesn't get updated, and unpin it once
    it gets fixed on next update (but see 1 about missing
    updates)

Out of curiosity, does this also apply to OI ?

-- Yassine

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


Hello!

We have "Boot environments"

On every "pkg update" you get a new BE that will be used on next reboot.

*if* there is something broken, you can easily choose the previous BE in 
the boot menu and you're back to the previous state of the operating 
system. That's really easy,


i currently have some BEs on my server:

$ beadm list
BE Active Mountpoint Space  Policy Created
openindiana-2021:03:11 -  -  24.41M static 2021-03-11 10:10
openindiana-2021:03:19 -  -  25.73M static 2021-03-19 08:57
openindiana-2021:03:26 -  -  21.64M static 2021-03-26 23:29
openindiana-2021:03:27 -  -  26.07M static 2021-03-29 11:52
openindiana-2021:04:11 -  -  25.88M static 2021-04-11 20:04
openindiana-2021:04:20 NR /  58.24G static 2021-04-20 11:21

.. and i could switch forth and back just as i like to :-)

NO problems with updates that raise some sort of concern!

Stephan



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

Re: [OpenIndiana-discuss] Rolling release considered harmful

[Judah Richardson]

On Tue, May 4, 2021, 07:25 Yassine Chaouche 
wrote:

> Le 5/4/21 à 5:24 AM, Judah Richardson a écrit :
> > From a practical perspective, I don't think OI has the option you want.
> > It's a rolling release distribution. I
> So, just to be clear for outsiders like myself. I thought Hipster
> was the Rolling Release Branch. I assumed OI had another fixed
> release branche, but apparently there's not ?
>
Hipster is the only release mentioned on the blog in over 2 years and the
only release listed on the download page. I had the same question when I
1st downloaded OI, but it was pretty obvious to me from the above that
Hipster is the main effort, and so that's what I installed. Don't fight the
paradigm, as I keep saying.


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

[OpenIndiana-discuss] Updates in OI

[Yassine Chaouche]

Dear OI community,

I was never fond of Rolling Releases. I tried a couple times,
it always ended in an unrecoverable system and me switching
back to a classic LTS linux distro (I'm a linux user myself).

It generally boils down to these two essential problems :

 1- Never miss an update. Missing an update increases your
    chances of breaking the system on next update.

 2- You can't install a package if your system is out of date.
    This means that if you chose to not update the system, for
    example because of a known problematic package, you won't
    be able to install new software until that package is fixed.
    A workaround would be to pin that package to its current
    version so that it doesn't get updated, and unpin it once
    it gets fixed on next update (but see 1 about missing
    updates)

Out of curiosity, does this also apply to OI ?

-- Yassine

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

Re: [OpenIndiana-discuss] Rolling release considered harmful

[Toomas Soome via openindiana-discuss]

> On 4. May 2021, at 15:24, Yassine Chaouche  
> wrote:
> 
> Le 5/4/21 à 5:24 AM, Judah Richardson a écrit :
>> From a practical perspective, I don't think OI has the option you want.
>> It's a rolling release distribution. I
> So, just to be clear for outsiders like myself. I thought Hipster
> was the Rolling Release Branch. I assumed OI had another fixed
> release branche, but apparently there's not ?
> 



We can have just as many branches as there are people who wish to maintain 
those branches.

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

Re: [OpenIndiana-discuss] Rolling release considered harmful

[Yassine Chaouche]

Le 5/4/21 à 5:24 AM, Judah Richardson a écrit :

From a practical perspective, I don't think OI has the option you want.
It's a rolling release distribution. I

So, just to be clear for outsiders like myself. I thought Hipster
was the Rolling Release Branch. I assumed OI had another fixed
release branche, but apparently there's not ?

-- Yassine

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