mikeslr wrote: Sun Dec 18, 2022 4:21 pm
While I would have preferred one based on debian/Ubuntu --in part because I'm more familiar with them, but MOSTLY because independent publishers always test for use under them--
Yes, I also rate ubuntu-based highest (debian lagging a bit IMO), simply because so many publishers produce ubuntu-based packages prior to any package releases for any other distro variant. An ubuntu firstrib-based distro can be built (indeed weedogit ubuntu creations already demonstrated that), but I've always steered clear of building from scratch any polished FirstRib_Ubuntu (aside from some mini-builds such as previous WDLGO_fossa) because the forum has had no need of another ubuntu derivative since DebianDog ubuntu builds covered that perfectly. However, if no new DD ubuntu builds are likely, and it seems fredx181 is no longer planning Ubuntu builds (?) then a KLU could be made pretty easily to follow the KLV design pattern. In fact, a KLU could easily adopt/modify extract from earlier DebianDog Ubuntu package/configs builld recipe as an alternative since these already provide a working recipe (albeit openbox/tint2) that could easily be tweaked to provide a build plugin for build_firstrib_rootfs (probably modded to use Xfce). Indeed, the FirstRIb build system also allows for debootstrap Debian/Ubuntu builds as part of its design (albeit not tested/maintained for a while so might need some url changes to make that kind of build work again). However, I continue to resist making that Ubuntu version since feel that is the domain of DebianDog forum offerings - afterall DD Debian builds are still being made and a KLD (Debian release) wouldn't offer any advantage to that.
In any case, my opinion remains that a Void Linux base is the best overall match for using in community-wide forum builds because like Puppy itself used to be, Void Linux is independent of the big mainstream distros and is packaged in a way that allows a lot of choice and diversity (including it avoiding systemd, which many on this forum seem to want to avoid...). KLV-Airedale turns out to be a very efficient XFCE-based distro - good distro to learn all the ins and outs of Xfce desktop environment using significantly less RAM resources than all other Xfce-based distros I have tried. Admittedly, once we all inevitably probably want to move to Wayland instead of X we may need to abandon Xfce (though maybe they will eventually produce a Wayland-compatible version - I hope so - I really like Xfce nowadays - it is fast and responsive enough on even ten year old machines of today).
mikeslr wrote: Sun Dec 18, 2022 4:21 pm
One thing I'll probably explore --if I can figure out how and what tools are needed-- are why not all of MikeWalsh's portables functioned. Some of his portables consist of an AppImage called and controlled by a bash script. Ignoring the script, I could start the application by clicking the AppImage, itself. So there most be something about the bash script which isn't working under KLV-Airedale.
Yes, I've used quite a few AppImages from upstream sources on KLV and all worked fine, so I expect all of MikeWalsh's variants could be made to work and if not all doing so will just be some script tweaks needed.
mikeslr wrote: Sun Dec 18, 2022 4:21 pm
The reason for my initial post wasn't that I couldn't figure out boot into KLV-Airedale: it was that if you have a great operating system I want to be able to tell others how to fully make use of it. Even --if as in my case-- it involves copying a stanza and editing it, that's much easier than first having to search thru many posts to find a 'template' to edit. And that isn't a complete answer. I recall reading a (rockedge's?) post somewhere which discussed having the Upper-Changes Folder as an SFS, then employing some code which would copy it into RAM so that (as I can using an a/y drv under AUFS) after booting from a USB-Key the key could be removed. And I have fogging recollection suggesting that there have been improvements to the 'No Changes' codes and/or that one of them isn't needed.
How difficult would it be to add a Section 'Boot Arguments and their meanings'?
I thought all boot arguments were pretty much covered in these two blog posts I referred to? But, yes, a single list of all boot arguments with attached meanings could be made in cheat sheet form as a useful addition. As far as using
(2-digit named) upper_changes, optionally compressed into sfs form - that's what we refer to as the session rollback mechanism outlined here: https://www.tinylinux.info/post/firstri ... -rollback/
But perhaps you are talking about something else rockedge has posted about. The numbered layer system employed is entirely flexible in terms of allowing easy organisation of which layer you want addons to appear - becomes just a matter of changing the NN value in the sfs layer, and particularly flexible since you don't even need to make the layer directory into an sfs - you can just use an uncompressed folder at any layer you wish. All sorts of layer 'tricks' can therefore be devised subject only to the imagination; one of these is the very useful pseudo-full-install mechanism, which both rockedge and I use quite a lot, particularly whilst extending/developing the system, which is described here: https://www.tinylinux.info/post/firstri ... all-howto/
I haven't thought about the 'remove-usb' after booting case per se, or whether rockedge has documented that variant somewhere, but yes that can be done. The previous r/w upper_changes directory can simply have a 2-digit number added to it (and optionally then made into a sfs) such that it would be used as top read-only layer on next boot, which can be made as RAM only via using kernel line option w_changes=RAM0, which means no external media then required after booting. However, off the top of my head, I do think you need to manually unmount the device that was used for booting prior to removing it. I considered getting the initrd to auto-unmount it, but sometimes we don't want to do that so I believe I left that up to the user - can be reconsidered and thought about further, but certainly the arrangement can be done either way.
EDIT: Remember enough flexibile option: aside from the initial boot stage, the majority of the initialisation code in FirstRib boot design is actually done by the simple text file of code called 'w_init'. Whilst not required, a copy of the provided w_init that is internal to initrd is also provided as an external easy-to-modify file, which is the one that takes precedence during boot (by default it is identical to the internal one so could be deleted and system would boot as per default design). Any user can thus tweak that external w_init to include a umount media (usb) command at the end (maybe...; better probably in the root filesystem itself - for example in rc.local). In fact I have long advocated users to contribute their own modified w_init variants since it is actually a boot plugin so different w_init variants can be contributed for special use purposes. So, I think the way to arrange it would be to run using a normal r/w upper_changes first time round, and put the umount usb command in rc.local, which will then be written to upper_changes, and then make upper_changes a top read-only layer by putting 2-digit number in its filename just prior to reboot with w_changes=RAM0. Yes that process could definitely be documented better!