First Rib with Plug script.

[geo_c]

As per @rockedge's suggestion about trying a firstrib build, I would like to give it a try.

Perhaps you could point me to the tools.

And maybe brief instructions, or where to find them, maybe the tiny linux page? Of course I need to have the most stable up to date scripts, as I have no idea what I'm doing.

I'm not thinking I'll get an OS that rivals anything the experienced devs have assembled, but I will probably learn a lot just by making the attempt.

[rockedge]

@geo_c I will have to gather the links to the docs which are scattered around and I will set up some instructions to get a start on using the utility scripts which are on https://rockedge.org/kernels under Firstrib->FR-utilities

The PLUG files can be found under Firstrib->PLUGS
In the morning I can add in the instructions....which are pretty easy and straightforward to start off. Which us build the rootfs then how to add and extract a kernel and create the initrd.gz

The file is compressed and once decompressed should look like this:

Screenshot(23).jpg (36.01 KiB) Viewed 1686 times

[rockedge]

@geo_c Here we go!

These instructions are for Void Linux based systems. Void Linux is proving to be one of if not the most efficient Linux operating system currently available.
These are the steps here outlined:
1. build the rootfs
2. clean up rootfs then squash it it to 07rootfs.sfs
3. mount the uncompressed firstrib_rootfs using the utility mount_chroot.sh

Code: Select all

./mount_chroot.sh firstrib_rootfs

4.using xbps-install -y linux get a Void Linux kernel (later we can go over how to use a huge kernel instead.)
5. using the initrd build script create the initrd.img which is equal to initrd.gz and can be renamed to that.
6. using the extract kernel script build the vmlinuz

To start create a directory to build in. For this example I'll call it /prototype. After downloading Firstrib-utilites.tar.xz decompress the file and copy the files to the directory /prototype which then should look like this screenshot:

Screenshot(24).jpg (28.28 KiB) Viewed 1645 times

For the PLUG I'll choose f_00_Void_KLV_XFCE_no-kernel_WDLteam-RC5.plug which will be copied to /prototype

Screenshot(25).jpg (17.37 KiB) Viewed 1645 times

Now start a to build the rootfs in a terminal within /prototype:

Code: Select all

./build_firstrib_rootfs.sh void roll amd64 f_00_Void_KLV_XFCE_no-kernel_WDLteam-RC5.plug

Screenshot(26).jpg (18.38 KiB) Viewed 1645 times

Go get coffee.
Once finished there should be a directory /prototype/firstrib_rootfs

If you get here, we are ready to make the rootfs.sfs and prepare for building the initrd.gz and extracting the vmlinuz.

[rockedge]

@wiak might be interested in the progress made in using the scripts....

Once the build script is finished the directory should look like this:

Screenshot(28).jpg (18 KiB) Viewed 1644 times

and in the terminal:

Code: Select all

desktop build process finished

Assuming no errors have occurred above,
firstrib_rootfs flavour void roll amd64 is now ready.
If you wish, you can now use it via convenience script,
./mount_chrootXXX.sh and after such use, exit, and, IMPORTANT:
run ./umount_chrootXXX.sh to clean up temporary mounts.
Or, you can make it bootable via FirstRib's wiak initramfs by running:
./build_wiak_initrdXXX.sh <distroname> [OPTIONS], and then
frugal install it by copying the resultant initrdXX, vmlinuz,
and firstrib_rootfs.sfs (or firstrib_rootfs directory) into
/mnt/bootpartition/bootdir and configuring grub to boot it.
NOTE WELL: firstrib_rootfs needs renamed NN<anything> For example:
08rootfs or 08rootfs.sfs (if squashed using mksquashfs utility),
or for a pseudo-full-install only: rename uncompressed firstrib_rootfs
as upper_changes and mkdir -p NNdummy (e.g. 08dummy)
More details on booting at end of build_firstrib_initrd script.
Refer to FirstRib documentation if you wish to use optional plugins.

Refer to /initrd/mnt/dev_save/prototype/grub_config.txt for related booting information.

Now some cleanup can be done on /prototype/firstrib_rootfs!

And here decide if using perhaps the Puppy Linux type kernel is the way to go or go through more steps to add a Void Linux kernel.
Lets use the RT kernel from KLV-Airedale for this example!

[rockedge]

So now lets make the directory that will be the distro! I'll go with /protosys.
Copy /prototype/firstrib_rootfs to /protosys and add "07" to make 07firstrib_rootfs . Notice that this will remain not squashed or compressed for now.

Copy the kernel components from KLV-Airedale-RT to /protosys

Screenshot(30).jpg (13.61 KiB) Viewed 1638 times

In the directory /protosys to get the boot stanzas run:

Code: Select all

./wd_grubconfig

Screenshot(31).jpg (53.92 KiB) Viewed 1636 times

[rockedge]

With a fresh coffee in hand try booting protosys

[dimkr]

@rockedge Is there short documentation for First Rib? How to build something with it, step by step.

And, is there any git repo or some other place where one can find a detailed changelog?

[rockedge]

@dimkr The scripts were on GitHub (or Gitlabs?) on wiak's account I think. Not sure what the status with that is

The best organized documentation is at @wiak's site -> https://www.tinylinux.info/

Most other documentation is scattered around like here ->viewforum.php?f=130
Lots of information on the oldforum -> https://oldforum.puppylinux.com/viewtopic.php?t=116070

Firstrib beginnings with Arch Linux which has a how-to guide-> https://oldforum.puppylinux.com/viewtop ... 6#p1028956

Some experimentation with 66MiB WeeDogLinux SliTaz flavour 32bit CD/usb bootable iso-> https://oldforum.puppylinux.com/viewtop ... 9#p1061329

Firstrib Forum has some -> https://firstrib.rockedge.org/

All in all there needs to be some far better organization of the relevant information pertaining to Firstrib and using the utility scripts.
The PLUG files are the customization portion that is under control of whom ever creates one and shares it.

The ones I provide are for example purposes and may themselves work or not work. More PLUG file are on https://rockedge.org/kernels to examine or try out.
There are JWM versions but I'll have to look around for the Spectrwm desktop version PLUG.

Sorry it's not better written and I don't know if there is any change.log per say (we know there should be one).....but perhaps in the near future.....

Another set of build instruction/discussion -> viewtopic.php?p=37772#p37772

[rockedge]

@geo_c One fix I had to make so protosys-A would boot to the XFCE4 desktop!

Open the uncompressed firstrib_rootfs and in /etc/sv open /etc/sv/agetty-tty1
in the agetty-tty1 directory create a blank file named down and retry the boot.

I added the /boot from KLV-Spectr-beta2, just modifying the distro name to /protosys-A and I made an ISO
Squash firstrib_rootfs:

Code: Select all

mksquashfs firstrib_rootfs 07protosys_rootfs.sfs  -b 1048576 -comp xz -Xdict-size 100% -noappend

Make ISO:

Code: Select all

mkisofs -b boot/isolinux/isolinux.bin -c boot/isolinux/boot.cat -D -l -R -v -V "KLV-Airedale" -no-emul-boot -boot-load-size 4 -boot-info-table -o "protosys-A.iso" protosys-A
isohybrid protosys-A.iso

I set up a VM in AQEMU and with the down command in agetty-tty1 the login conflict does not happen. This little line of code needs to be added to the PLUG file steps. Which worked well enough to boot the newly put together KLV type.

Screenshot(32).jpg (17.33 KiB) Viewed 1547 times

Will have to browse through the menus to see what is missing and what works......

[rockedge]

To be able to use a QEMU machine with an ISO I had to adjust some of the boot stanza's from ISO in the file /boot/grub/menu.lst to boot smoothly by defining /mnt/sr0 with: w_bootfrom=/mnt/sr0. Then creating the ISO image file.

Booting from a bare metal frugal installed set up on a Desktop HDD partition set up with Grub4Dos was really easy and straightforward.. So it was a matter of adding the boot stanzas to boot frugally and no hassles requiring the bootloader in an ISO.

So far after the fix adding a blank file named /etc/sv/agetty-tty1/down the distro protosys-A is up and running with the RT huge kernel in a QEMU VM.

Everything on the menus seems to start! And amazingly I have not run into any package really broken. total luck that it the build resulted in a what appears to be a fully functional, if not fully polished, quick distro.

SFS-Load is working! Tested with Textmaker2019-amd64.sfs

Screenshot(36).jpg (24.7 KiB) Viewed 1522 times

[wiak]

When I began creating FirstRib in 2019 I purposively did not want to involve any version control system like used by woof-CE.
Rather I wanted a simple build system involving one or two simple shell scripts that many on the forum could instantly use and understand without needing to learn how to use the likes of git to push, pull, commit, raise issues, or seek permission to merge any code ideas of their own.

FirstRib in fact consists of only two necessary/core parts:

1. A root filesystem, which for most flexibility can be optionally built with the help of a single shell script called 'build_firstrib_rootfs' or, pretty much any (but not all) existing pre-built root filesystems such as those provided in repos by Void Linux, Ubuntu, or Arch, or special ones originally designed for inclusion in docker containers for example.

and

2. The FirstRib initrd, which is provided pre-built as a skeleton FR initrd (that doesn't contain any embedded driver modules, which can be used directly with a Puppy-style huge kernel/modules combination, or have any required boot modules added to it as part of the build process), or can be built from scratch using another simple shell script currently called build_wiak_initrd.

In practice, if build_firstrib_rootfs is used to create the distro's main root filesystem, that by itself only builds a very basic root filesystem (with a choice of one using no package manager or one from either Void Linux, Arch Linux, Devuan, Debian, or Ubuntu). Most of the resulting distro design is actually then determined by a simple text plugin for use by that script, which is created by the user who wants to make a new distro. For example, that simple plugin may use the chosen repo package manager to install Wayland, or X, or JWM, or XFCE, or Gnome, or pipewire, and contain any configuration code wanted and so on - whatever the distro designer wants to include, dependent on what the upstream repo and their own scripting and knowledge can provide (but... the upstream repo can provide most everything in practice, so no great experience/knowledge is necessarily required).

Similarly, the FR initrd, includes the ability to utilise a user-provided plugin, which has the filename 'w_init', which is simply a text file containing shell script code that determines, for example, the structure and composition of the overlay structure and more. Since that w_init is external to the compressed initrd it can be easily edited at any time in a text editor (and used on next boot) and thus the facilities provided by the FR initrd system changed according to the user expertise and wishes. If no external w_init is provided, the internal to the initrd w_init will be used by default instead, but the external w_init takes preference if it is available. Users can thus provide their own customised w_init creations for others to use without needing any modification to the compressed FR initrd itself. In fact, I use a customised w_init to create my recently contributed KL_full2frugal system but still used the current stable FR compressed initrd along with that external w_init. Admittedly, modifying the behaviour of an initrd in any major way is not for beginners nor the faint of heart - the initrd/w_init combination is indeed the heart of the frugal install system functionality...

So, overall, it is a simple to use, simply implemented, build system that nevertheless has proved itself capable of building many shapes and forms and types of distro, to any level of sophistication, the user/builder wants.

I tend to store my own copies of FirstRib build scripts and the skeleton initrd on rockedge's kindly provided owncloud storage site. I do have some personal git sites of my own, as it happens, mainly to store the code for various business websites I maintain, but sometimes simply as alternative repos, to store some code in, rather than really for their version control facilities.

I don't myself in practice build many distros of my own. I started a few off, but I well-recognise that others are much better than I am at producing user-friendly fuller-featured desktops than I ever would be. Different people have different talents. Hence most FR-based distros aren't made by myself at all, which is great, because I prefer to step back and let others own the results of their own creations, which I can then use too... I continue to maintain the underlying build scripts (which are all MIT liberal licensed opensource), and both myself and others have added various useful build and system helper utilities (such as modify_initrd.sh and mount_chroot.sh), and adapted some from other forum distros, such as save2flash/snapmergepuppy and so on.

Nothing more to say about the matter really - I'll leave others to tell you whether the build system is easy to use or not. The existing KL distros, created on the whole by others, certainly shows that it works.

[geo_c]

Everything on the menus seems to start! And amazingly I have not run into any package really broken. total luck that it the build resulted in a what appears to be a fully functional, if not fully polished, quick distro.

At some point later in the week, I will begin by following your recipe.

Since I've been having amazing success mixing multi-track audio with KLV-Airedale-RT40, I'm getting really curious to see what kind of results I would get with KLV-Specterwm with a real time kernel. As of now I haven't tried installing Ardour on KLV-Spectrwm yet to see how well it plays with a tiling window manager. If the results are successful once I try that simple test, and figure out how to use firstrib, then I'm keen to set my sites on a realtime Spectrwm distro.

[rockedge]

@geo_c I went ahead and made an ISO of KLV-Spectr-RT that is using the same RT kernel set up in KLV-Airedale-RT.

I did only a few quick tests in a QEMU VM so can't guarantee anything but so far so good...

download information -> viewtopic.php?t=9287

Simple thing is if using a Puppy Linux huge kernel instead of extracting and then using a Void Linux kernel, one only needs to generate a firstrib_rootfs
To build using the huge kernels use the one build script + PLUG file and then one can use the firstrib_rootfs uncompressed or could squash it and add in the kernel components and add without any modifications, the skeleton initrd.gz + wd_init.

[Sofiya]

in FRmake_initrd.sh 2 links are invalid
we won't get the file "w_init" and "initrd-latest.gz"
I see " initrd-latest.gz " is in Firstrib-utilites.tar.xz , but " w_init " is not.

note:
And even if we put these files there, when we run " FRmake_initrd.sh " we will make " initrd-latest.gz and w_init " empty.

line 14:

Code: Select all

wget -c https://owncloud.rockedge.org/index.php/s/BQm758UXWSJ2O1k/download -O initrd-latest.gz

line 15:

Code: Select all

wget -c https://owncloud.rockedge.org/index.php/s/bolhoXwFylKi335/download -O w_init-latest

[rockedge]

@Sofiya I just ran it and it worked!

the command in a terminal (the syntax must include "latest") ->

Code: Select all

./FRmake_initrd.sh latest firstrib_rootfs

I change the file name of firstrib_rootfs to upper_changes and my command looks like ->

Code: Select all

FRmake_initrd.sh latest upper_changes

[Sofiya]

@Sofiya I just ran it and it worked!

the command in a terminal (the syntax must include "latest") ->

Code: Select all

./FRmake_initrd.sh latest firstrib_rootfs

I change the file name of firstrib_rootfs to upper_changes and my command looks like ->

Code: Select all

FRmake_initrd.sh latest upper_changes

hmm..... i run like this ./FRmake_initrd.sh latest . I'll try yours now .
Thank you

[wiak]

in FRmake_initrd.sh 2 links are invalid
we won't get the file "w_init" and "initrd-latest.gz"

Yes, I will need to fix this. Thanks.

Temporarily, a workaround is to put latest w_init and initrd.gz- (can't remember if it needs called initrd-latest.gz at that stage) into the build directory since any download fail (because download link for wget needs revised) shouldn't matter then (I think off the top of my head). That's generally the case for wget operations - if files already there, their download isn't needed.

I will fix it. I'm gradually putting some of these core files onto gitlab site where I'm less likely to mess up with link names for download - just wasn't planning much fix... until I'm settled in around Mar 2024, but yeah that's a while too long.

[wiak]

Alternatively, I just took a look at their storage on rockedge owncloud and the shared links now seem to be:

Code: Select all

initrd-latest.gz from: https://owncloud.rockedge.org/index.php/s/BQm758UXWSJ2O1k/download -O initrd-latest.gz

winit-latest from: https://owncloud.rockedge.org/index.php/s/bolhoXwFylKi335/download -O w_init-latest

Oh, that's what you seem too already have above. Should work. Some other issue? I haven't checked.

[Sofiya]

Alternatively, I just took a look at their storage on rockedge owncloud and the shared links now seem to be:

Code: Select all

initrd-latest.gz from: https://owncloud.rockedge.org/index.php/s/BQm758UXWSJ2O1k/download -O initrd-latest.gz

winit-latest from: https://owncloud.rockedge.org/index.php/s/bolhoXwFylKi335/download -O w_init-latest

Oh, that's what you seem too already have above. Should work. Some other issue? I haven't checked.

Everything is loading now
Thank you

[wiak]

I've been taking a look after this long absence at build_firstrib_rootfs script. I know we aren't using Ubuntu/Debian builds via that at the moment, so not an issue, but I do need to fix the Ubuntu/Devuan/Debian debootstrap fetch code - not sure what happened there, but I messed up last time I revised that. Okay still for Void builds and Arch builds I think, though I'll take a closer look at urls fetches for the bits and pieces.
Ok, is simple error I missed a couple of backslashes in grep regular expression code - probably had them when testing at commandline but copied wrongly into the actual script code... I must try a build of Ubuntu/Debian/Devuan sometime...
Also have Fedora build in there - interesting to try that again.

Re: fixes. As you have already long ago worked out, most fixes/maintenance that sometimes needs looked into regarding FirstRib scripts are just changes to url code. The other stuff is pretty simple shell script code that hardly changed over the past four years as you probably know... And the FRinitrd works, and likely keeps working as long as upstream Kernel team don't decide to ditch overlayfs for aufs...............
Good thing (I feel) is: I'm not in a hurry to change much. Stable feels good to me.

Having said that, despite not meaning to do any dev at the moment, out of curiousity I am right now taking a look at the Ubuntu/Debian/Devuan side of things to get that basically working again. A few things to check for that to occur.

[Sofiya]

on the second try everything went smoothly and I get KLA with kernel 6.4.7-arch1-1 with brand new initrd.gz and vmlinuz
The only thing is that the Arch core is larger and initrd.gz has also become larger.
Unless, of course, I don’t have jambs somewhere.

when loading the kernel, I get 3 default choices (1), the question is which option is better to choose?
and what should be cleaned after extracting the kernel?

I think KLV won't be a problem either
Thank you very much ! To all of you for your support

Sincerely, Sofiya

[Sofiya]

As the test showed, the system boots correctly

For the test: ISO (919 MIB )

https://mega.nz/file/LgcDhSYJ#bXfwdMDve ... 5GLWqSX6kk has been replaced

[rockedge]

@Sofiya excellent outcome! Nice.....

Here is another PLUG example that will produce a KLV very minimal build with no XORG or window manager.

A simple solid starting point to begin to make custom additions for a distro

Code: Select all

# f_00_Void_generic_NoX_WDL_team_no-kernel.plug
# version="1.2.0"; revision="-rc1"
# WeeDog Void outfitted with a basic commandline desktop and no kernel
# Creation date 24Sep2021; Revision date: 01Aug2023
# Copyright WeeDogLinux team; Licence MIT

# build this via terminal commands:
# export CONNECTION_TIMEOUT=-1
# ./build_firstrib_rootfs-XXX.sh void default amd64 f_00_Void_generic_NoX_WDLteam.plug
# Architecture i386 will probably successfully build too as an alternative to amd64

# login is user=root passwd=root

# All the parameters/commandlines can be appropriately changed:
# Simply comment in or comment out till you have what you desire
# or add new packages to the xbps-install lists.
# You can add as many valid commandlines as you want in here.
#
xbps-install -y base-minimal ncurses-base bash eudev
xbps-install -y file mc xauth
xbps-install -y shadow wpa_supplicant  # needed for most wifi
xbps-install -y ntfs-3g zstd

# set up passwd system
pwconv
grpconv
printf "root\nroot\n" | passwd >/dev/null 2>&1 # Quietly set default root passwd to "root"

# set root to use /bin/bash
usermod --shell /bin/bash root

# Install Network Manager
#
xbps-install -y NetworkManager network-manager-applet
ln -s /etc/sv/NetworkManager /etc/runit/runsvdir/default/NetworkManager

# Set locale to en_US.UTF-8 
sed -i 's/#en_US.UTF-8 UTF-8/en_US.UTF-8 UTF-8/' /etc/default/libc-locales
xbps-reconfigure -f glibc-locales

# enable dbus service
ln -s /etc/sv/dbus /etc/runit/runsvdir/default/dbus

# Set Bash as shell
xbps-alternatives --set bash

## --------------------------------------------------------------------------

# Optional packages
#
xbps-install -y squashfs-tools wget
xbps-install -y dosfstools mtools lynx



# --------------------------------------------------------------------------
## USER CONFIGS: Copy main configs to /etc/skel for all normal users later added
#
xbps-install -y sudo
cp -af /root/. /etc/skel
mkdir -p /etc/skel/.config /etc/skel/.cache /etc/skel/.local/share
echo Still some extra to do here re the likes of runit starting pulseaudio
echo among other user needed config bits and pieces,
echo so probably a few user-config issues noted as needing fixed here

# Give wheel group nopasswd sudo rights and create weedog as wheel group member
echo '%wheel ALL=(ALL) NOPASSWD: ALL' | (VISUAL="tee -a" visudo) # wheel group added to sudo no password required
useradd -m -G wheel -s /bin/bash weedog  # weedog in wheel group so has elevated sudo permissions
printf "weedog\nweedog\n" | passwd weedog >/dev/null 2>&1 # Quietly set default weedog passwd to "weedog"

# Give wheel group nopasswd sudo rights and create spot as wheel group member
echo '%wheel ALL=(ALL) NOPASSWD: ALL' | (VISUAL="tee -a" visudo) # wheel group added to sudo no password required
useradd -m -G wheel -s /bin/bash spot  #spot in wheel group so has elevated sudo permissions
printf "spot\nspot\n" | passwd spot >/dev/null 2>&1 # Quietly set default spot

echo "desktop build process finished"

[Sofiya]

@Sofiya excellent outcome! Nice.....

Yes, the result can be excellent, and I liked how the core works, but there is one BUT and I can’t understand what it is connected with.
On Shutdown does not work output to the console to select save do not save session from @fredx181
(:

[Sofiya]

during the investigation, it was found that the file 07KLA-OT2baseCE-2.7.sfs was nested from version 07KLA-OT2baseCE-2.6.sfs .although I don’t understand what is the difference between them?
link replaced with another ISO
https://mega.nz/file/LgcDhSYJ#bXfwdMDve ... 5GLWqSX6kk

[rockedge]

Yes, the result can be excellent, and I liked how the core works, but there is one BUT and I can’t understand what it is connected with.
On Shutdown does not work output to the console to select save do not save session from @fredx181 (:

I just fixed that same thing in KLV-Spectr. It was a simple fix but I'll have to look back at the posts where fredx181 helped straighten it out to be able to share how it went. It is somewhere in the KL-Dev or KLV-Spectr topics

[rockedge]

@Sofiya Here is where the posts are that begin to deal with the save2ram options query window missing -> viewtopic.php?p=93050#p93050

and the fix is here -> viewtopic.php?p=93113#p93113

[Sofiya]

@Sofiya Here is where the posts are that begin to deal with the save2ram options query window missing -> viewtopic.php?p=93050#p93050

and the fix is here -> viewtopic.php?p=93113#p93113

There are no such folders in KLA, everything is different there
We will use Upup core.
Most importantly, the process itself was interesting. And most importantly, educational.

[wiak]

I forget the details, but I somewhat recall when I was working on KLA-OT2base I wanted non-Arch-made scripts to be in /usr/local/bin rather than /usr/bin.

I thus arranged that for a while that snap-ex in that distro refers to /usr/local/bin/snapmergepuppy (rather than /usr/bin/snapmergepuppy).

I don't know if it still does in later KLA-OT2baseCE. I think I wasn't in the end using snap-ex at all, but maybe that wd_save2flash script somehow instead (you'd have to check). I think my choice was to have a yad pop-up at shutdown because personally I prefer that to a console pop-up. Just a matter of different taste on my part, but I have low taste sometimes I think...

Whist I think snap-ex may have that /usr/local/bin/snapmergepuppy reference, which means it wouldn't work since snapmergepuppy and save2flash ended up back in /usr/bin I cannot remember the sequence involved in system shutdown in that openbox/tint2 arrangement (which Sofiya may well have altered anyway). Is systemd involved? - again I can't remember.

Note that in the end I decided to just go with everyone else's flow and put snapmergepuppy and save2flash additions into /usr/bin. I decided maintenance of too different places to locate these would muck up future script maintenance... but since I was not I think using snap-ex, I forgot all about it changing that path back.

Don't know if anything I'm saying here is relevant to whatever the discussed issue is though...

[Sofiya]

I forget the details, but I somewhat recall when I was working on KLA-OT2base I wanted non-Arch-made scripts to be in /usr/local/bin rather than /usr/bin.

I thus arranged that for a while that snap-ex in that distro refers to /usr/local/bin/snapmergepuppy (rather than /usr/bin/snapmergepuppy).

I don't know if it still does in later KLA-OT2baseCE. I think I wasn't in the end using snap-ex at all, but maybe that wd_save2flash script somehow instead (you'd have to check). I think my choice was to have a yad pop-up at shutdown because personally I prefer that to a console pop-up. Just a matter of different taste on my part, but I have low taste sometimes I think...

Whist I think snap-ex may have that /usr/local/bin/snapmergepuppy reference, which means it wouldn't work since snapmergepuppy and save2flash ended up back in /usr/bin I cannot remember the sequence involved in system shutdown in that openbox/tint2 arrangement (which Sofiya may well have altered anyway). Is systemd involved? - again I can't remember.

Note that in the end I decided to just go with everyone else's flow and put snapmergepuppy and save2flash additions into /usr/bin. I decided maintenance of too different places to locate these would muck up future script maintenance... but since I was not I think using snap-ex, I forgot all about it changing that path back.

Don't know if anything I'm saying here is relevant to whatever the discussed issue is though...

we changed the way in snap-ex
when researching it was found that the latest package update breaks our output to the console to select save / not save.which is really sad.
It works exit but the window with selection elements is not visible.only at random you can switch.

I'm trying the KLA-OT2baseCE-2.6 version and if it doesn't update, everything works as it should. After the update, such an incident occurs
since we have KLA-OT2baseCE-2.7- with kernel 6.4.7-arch1-1 already with an updated package database, this incident happens immediately