KLV-Airedale-rc5 with Void Linux Kernel is Available!

[rockedge]

KLV-Airedale-rc5
Kennel Linux Void Airedale Release Candidate 5 755 MiB download size ↓
KLV-Airedale-rc5
SHA1-MD5.txt

Routine system update/upgrade. And wallpapers from @Sofiya are included, replacing some of the stock xfce4 backgrounds.

@wiak has done work improving the boot system menus :

The iso config file boot/grub/menu.lst is used to boot from cdrom using that internal to iso provided menu.lst (i.e. he currently uses grub4dos for that purpose).
The iso config file boot/grub/loopback.cfg is used (per usual) to provide the boot menu for SG2D
The iso config file boot/grub/grub.cfg is used by Ventoy (but included no Ventoy-compatible entries until my alterations below)

I have made some modifications to all of the above (though have left previous entries in place for later experimentation and possible modification or deletion).
In particular I have provided the ability when booting via SG2D or Ventoy of using the FR modes:

a. RAM0 for session changes in RAM only (i.e. no save persistence)
b. RAM2 save on demand mode back to upper_changes folder (or ucimg savefile) in same directory iso is stored (or in subdirectory if symlink manually made to iso).
c. RAM2 save on demand mode back to upper_changes folder in, Clarity suggested, partition with LABEL 'Persistence' and directory 'Sessions'
d. Direct save (not in RAM) back to upper_changes folder (or ucimg savefile) in same directory iso is stored (or in subdirectory if symlink manually made to iso).
e. Direct save (not in RAM) back to upper_changes folder in, Clarity suggested, partition with LABEL 'Persistence' and directory 'Sessions'

No editing of the presented SG2D or Ventoy boot menus will be required to achieve these most useful FR initrd modes. User just needs to put the KLV iso in BOOTISOS (or wherever it is put usually) and boot...

starting of the pulseaudio system for any user that is logged in has been fixed and improved. Thanks wiak, Sofiya and fredx181 for the exact steps.

Upgraded to a new version of @fredx181 's save2flash, and set LANG=en_US.UTF-8 in /etc/environment as default localization.

Thanks to @Sofiya for the poorercputemp and Display Control packages that also have been added to desktop.

• Grub4Dos is now included in the System menu. Making KLV-Airedale capable of setting up a boot-able device using GParted and Grub4Dos.

• CUPS starting as a service has been added and is working thanks to @rcrsn51 spotting missing components!

This is constructed from KLV-Airedale-beta27->rc1->rc2->rc3->rc4->rc4.1 and is equipped with a Void Linux kernel version 6.0.12_1 SMP PREEMPT_DYNAMIC constructed with @wiak 's scripts that will extract the Void Linux kernel for KLV. Also has had a system wide upgrade. Uses an initrd.gz based on the FirstRib skeleton initrd.gz constructed by the kernel/module creation script. Firmware SFS is from a woof-CE kernel-kit built huge 6.0.0-1 kernel.

KLV-Airedale-rc5 is just as at home on FAT32, NTFS prtitions as it is running from ext2/3/4 formatted partitions.

Also included is wiak's generate a set of boot stanzas script. fredx181's mksplash has a menu entry and the remaster script is installed.

With the addition of a xfce4 desktop tiling configuration. A tip from wiak for configuring Tiling windows done with the Super (Windows) key and an up, down, left, right, home, pgup, pgdown or end key.

gxmessage in the default rootfs.

save2flash has been expanded to handle persistence on FAT32 and NTFS partitions.
The mksplash GUI utility to create splash notification banners.

The latest initrd.gz brings vFat and NTFS formatted partition support to KLV, allowing persistence on NTFS/vFat systems as well as the usual /ext2/ext3/ext4/swap support.

• included htop, Grub4Dos, CUPS

• created a symlink /root/spot with the target /home/spot

• Auto login cleaned up.

• includes also the logout logic provided by fredx181 gives true mulit-user support.

• replaced loop.cfg to the most recent modifications.

• Debian kernel 6.0.0-3-KLV SMP PREEMPT DYNAMIC is used.

• added gtkhash

Plus the other important improvements contributed by the KLV team.

Added @fredx181's save2flash utility that can be used when KLV is started in RAM2 mode to perform session saves on demand for persistence.
This is similar to PUPMODE13 in Puppy Linux.

fredx181's swap partition enable script includes the latest revisions and also added are the packages

• mime-add-1.0_0.noarch.xbps

• edit-sfs-1.0_0.noarch.xbps

KLV-Airedale-beta25 is able to load squash SFS packages on the fly or during the boot sequence.
Squash files and ISO images can be opened from the file manager and the read the contents.

• can run with rootfs, 01fimware and 00module SFS files as uncompressed directories.

• Also able to load compressed and/or decompressed directories,
  once a 2 digit prefix is added to the file name.

• It is possible to mix using compressed squash files and uncompressed directories.

Also can be downloaded from https://rockedge.org/kernels in ISO->Kennel_Linux->Airedale

[wiak]

Just tried it quickly in Ventoy, but something wrong; only tried in Ventoy so don't know if it is general fault. Crashes on trying to find init or something at Kernel level. I'll try as normal frugal and report back.

EDIT: Normal frugal install worked fine as did SG2D. I don't know off top of my head why Ventoy didn't for me this time - going out right now but will check out Ventoy again later.

[wiak]

Well, Ventoy is also booting KLV rc5 fine! I must have done something wrong first time, but any tests of use on Ventoy would be helpful in case something meant it didn't work from pristine boot though I can't see anything different now - just works fine though I've still to test all the provided modes such as Persistence/Sessions save on demand.

[rockedge]

@wiak I don't have a Ventoy setup going yet. But I have it running as QEMU machine over VNC. I booted the ISO and partitioned the virtual HDD and formatted it with GParted rebooted into RAM mode (normal) and assigned it with a 8 core CPU. Runs really well.

My experimental KLV ISO edited and made from a QEMU VM KLV also works really well specifically on QEMU.

[wiak]

Okay, I know why my first Ventoy test didn't work.

I put the iso into directory Ventoy/BOOTISOS, but the internal-to-iso /boot/grub/grub.cfg line looks for it at /KLV-Airedale-rc5.iso and not /BOOTISOS/KLV-Airedale-rc5.iso. The simple KLV iso search routine is not for recursively searching for a given iso file name somewhere, but rather a recursive search through all system partitions for a particular iso file with given PATH.

It should be understood that Ventoy recursively searches so can find /KLV-AIredale-rc5.iso and/or /BOOTISOS/KLV-Airedale-rc5.iso to provide it in its menu, but KLV-AIredale initrd also has to search for its own iso separately. KLV-Airedale cares and knows nothing about Ventoy (and vice-versa really).

If you put the iso file straight into Ventoy / directory then all is fine, but if you want to treat it like SG2D does and put it, say, in a folder called BOOTISOS then with Ventoy user would need to press E and edit that grub.cfg line at boot-time to insert the /BOOTISOS extra piece.

But KLV also contains code to accept a symlink to the actual iso, so an alternative, currently, for those like Clarity who want to put the iso itself into /BOOTISOS on the Ventoy usb is to simply also make a permanent symlink to the iso in that Ventoy / folder . The symlink has to have exact same name and extension .iso (i.e. same as actual iso name) even though it is actually just a symlink to the actual iso. That is, from terminal opened in Ventoy /BOOTISOS:

ln -s /BOOTISOS/KLV-Airedale-rc5.iso KLV-Airedale-rc5.iso

or above can easily be done using ROX filer.

All will work then without needing boot-time edit.

Later, I'll consider putting that BOOTISOS possibility as a 'special' search case inside the initrd itself so even that location would then work, if using Ventoy, without user intervention. To be considered further. Easy to make the symlink for now anyway, or easiest is that Ventoy KLV booting works without any user intervention if the iso is instead simply stored at Ventoy / instead of in any subdirectory of it.

Like I said, any kind of booting from iso was not part of the original code design so the additions for that necessarily complicated the code already. Hence my reluctance to cater more than now done for any iso booting methods. Bare metal boot from iso could probably also be improved with a few additional RAM2 and also LABEL-based boots, but overall I think it is better for qemu to use a disk image with normal frugal install on it anyway.

[wiak]

@wiak I don't have a Ventoy setup going yet. But I have it running as QEMU machine over VNC. I booted the ISO and partitioned the virtual HDD and formatted it with GParted rebooted into RAM mode (normal) and assigned it with a 8 core CPU. Runs really well.

My experimental KLV ISO edited and made from a QEMU VM KLV also works really well specifically on QEMU.

SG2D searches for the isos and returns the PATH to them, but without also returning the partition that PATH is in! I frankly don't understand that limitation; had the partition also been returned by SG2D search routine then the additional support code needed in the FR initrd would have been tiny and uncomplicated (since no search then needed in FR initrd/init too).

Ventoy doesn't seem to return any useful variable I know to say where the iso is (just finds it itself and provides boot menu to it but FR initrd/init still then needs to find where the iso is... partition and path).

The end result, thus far, however, is that SG2D menu is terribly cluttered and slow and awkward to use (so why bother...?). SG2D seems to be overloaded with all the junk it is trained to find and display in its menus (yet fails to pass on the UUID or the LABEL for the partition found!!!! ). Ventoy just presents a menu to show the KLV and other isos of interest, but, alas, doesn't seem to pass on any FR initrd/init-needed useful partition/path information so FR initrd/init has to do all the search work itself anyway, but Ventoy menu is uncluttered and nice to use, so end result is preferrable to the mess menus of SG2D.

I do wonder, however, about the point of both of them personally since normal frugal installations are not difficult to do and don't need any extra complex initrd/init code (it is complex enough arranging all the special overlayfs-based flexibility thanks...).

Negatives aside, I do find Ventoy useful as a way to quickly pop in new iso release and do some basic checks (though more thorough checks need me to do a normal frugal install, which may be bare metal or via say qemu).

Biggest issue with Ventoy and SG2D is the fact that supporting them requires a lot of extra testing and sometimes code changes (and originally some quite complex code that took a lot of implementation time, though hopefully what is there is fine enough now); such support is likely to always be given lower priority to normal frugal installations that FR initrd/init was really designed for.

A bit negative, for me, is that even I struggle a bit to now remember/work-out how some parts of FR initrd/init code works now - it used to be easy but the extra SG2D/iso/Ventoy related code complicated the code logic quite a bit so gives me a headache reading it, whereas I preferred KISS approach even if that meant avoiding supporting some external optional boot techniques. Anyway, somewhat done now, for whatever it is worth.

As a system, I actually find SG2D simpler to understand than Ventoy - but SG2D really needs its menus simplified; perhaps it is trying too hard to do too much - we just want to see the isos available to boot not a dozen and more other junk we do not usually care about booting anyway! Ventoy got that bit right/better.

[rockedge]

@wiak I usually don't bother with either one. Only setup to test it. I never have tested KLV in SG2D myself and I do not have Ventoy setup anywhere. I find frugal installations on bare metal and virtual machines is the superior method. Booting from ISO with QEMU in either of the RAM modes works well as does booting from a virtual HDD. I also have pseudo full installs on QEMU VM HDD's and those work well.

I wouldn't change any of the initrd code to fix issues with Ventoy and SG2D systems. If that is important for a user then there are other distros that are better designed for these enviroments specifically. I really don't see any advantage in using these systems myself.

The fun is optimizing what exists now and getting the most out of it. Use as virtual machines has been fantastic with performance as fast as the host system and I can envision this as being an important ability as well as the many installation options on bare metal machines.

[wiak]

I wouldn't change any of the initrd code to fix issues with Ventoy and SG2D systems. If that is important for a user then there are other distros that are better designed for these enviroments specifically. I really don't see any advantage in using these systems myself.

Well the 'damage' is done in terms of added complexity really. Any further addition to that such as allowing BOOTISOS as special case is pretty much trivial extra code required inside the search function of FR initrd/init.

For more complex cases, I should mention per usual that FirstRib initrd has a special characteristic; its init script is actually split into two parts: an always internal to the initrd init script and a script 'sourced' by that init script called w_init, which is also stored inside the initrd but can also be stored outside it simply in the frugal install directory (or directory where iso is installed if booting from iso). The outside/external version of w_init (if it exists) gets used in preference to the inside initrd version (which by default is usually identical code, but external one can be altered to anything desired that works...).

In fact, whole of FirstRib design (both the build system and the initrd itself was designed to allow plugin additions). For initrd the boottime plugin would usually (but not necessary) be given a name starting with characters w_ to identify it as a wiak initrd boot-time plugin. Hence the name of w_init. It can be thought of as a user-modifiable plugin. Of course w_init itself can source further plugin sections of code; indeed that is the overall intention of the design to make it easy to change boot facilities and/or way of working.

Reason I'm saying that is that it has always with that system been possible to simply open up the external w_init file and alter a little bit of the code in there to, for example, change contents of a variable that was otherwise set by a grub kernel-line argument. A case in point would be if wanting RAM2 mode to save its persistence somewhere different than what grub kernel line argument specified. Indeed it is normal coding practice to often allow for two methods of setting script arguments: either directly on the command-line or via a configuration script that can overwrite what the commandline itself was set to use. Same thing was always able to be done via customised user-contributed w_init plugin, either by directly changing internal variable arguments (to, for example point save persistence location to somewhere different than grub kernel line config arguments made it) or by getting w_init to source a plugin stored beside it that does the same thing). I could later maybe add a w_ plugin specially for that since that wouldn't effect anything in the main FR initrd itself (other than the w_init copy there). What I don't like messing with is the FR initrd/init part, since its only real job is to find and mount the partition where the boot components are all held (including the optional external w_init); my pain with iso booting extras to cater for SG2D and Ventoy is the fact that involved major extra code complexity inside that efficient FR initrd/init part, so that is the the code I do not want to change further simply for the likes of iso booting mechanisms.

The w_init plugin was always able to load additional config overrides in the form of further plugins - that is what it is designed like it is for. I've actually over-written grub kernel line supplied variable arguments via w_init many times before for my own purposes so could easily put in special case for save persistence as an optional sitting alongside w_init extra small precedence-taking plugin (i.e. typical config overwrite code containing the likes of w_changes=wherever and so on overwriting what grub kernel line itself suggested for everything). The BOOTISOS need, however, actually does require a small alteration to the internal initrd/init script though - but it is a minor aleration thankfully.

EDIT: special BOOTISOS search case does indeed need internal initrd/init alteration (albeit simple one); external w_init too late in terms of not being able to mount the partition that external w_init is contained in! But still the case that external w_init (or plugin to it) could be used to load in alternative config to over-write kernel line arguments of course (such as w_changes=wherever) - that has always been a capability of it, which I've often done during my own development experiments as well as for more complicated alterations than simple config variable changes (for example, automatically including extra layers of addon sfs filesystems and/or uncompressed directories that are stored in special-purpose subdirectory signifying they are to be auto-included).

[Clarity]

I do wonder, however, about the point of both of them personally since normal frugal installations are not difficult to do and don't need any extra complex initrd/init code (it is complex enough arranging all the special overlayfs-based flexibility thanks...).

I know, as you too, that the benefit is that it accelerates, particular for many users, a simple means to identify, select, and boot many distros as well as almost ALL (except 1) forum distros....including KLV. No work if you have the SG2D USB/DVD for any PUP/DOG from download to desktop

Biggest issue with Ventoy and SG2D is the fact that supporting them requires a lot of extra testing and sometimes code changes (and originally some quite complex code that took a lot of implementation time, though hopefully what is there is fine enough now); such support is likely to always be given lower priority to normal frugal installations that FR initrd/init was really designed for.

The prime intent for Ubuntu for 6 years and PUPs since 2019, NO EFFORT is needed by development to boot our ISOs to desktop when listed by SG2D.

Ventoy, operates, as you have noticed a little differently in its GRUB2 code (like normal linux scripting) and EVERY PUP/DOG's ISO may not boot directly from the Ventoy list, whereas, every boots via SG2D.

For the last 18 months, after discovering the difficulty of Ventoy for forum distros, I have tested, used, and advised others who choose Ventoy to ADD SG2D's ISO to your list of all ISO AND to create a BOOTISOS folder to keep all ISO files within such that SG2D will discover on boot, list, and allow booting.

The 2 boot assistants, Ventoy & SG2D, are primarily crafted to merely create the environment such that the ISO files will boot with a 'feeling' of bare-metal. With SG2D, it has been around for so long that so many-most of the prime of the DistroWatch distro ISO files boot from it. In the case of Ventoy, it is only couple years old with an intent to LIST every ISO file it finds, including those in its BOOTISOS folder for user selection with some help under the covers for some of the ISO files. Yet, Ventoy's plan is to become a defacto standard (they have NOT said this, but in following them since their inception in appearance they are leaning that way) for EVERY ISO file, IMG (image) file, VM file, and anything else that need to be launched to boot a bare-metal PC.

I continue to advise EVERY forum distro users who uses Ventoy to keep all ISOs files in the BOOTISOS folder, as well as to have the SG2D ISO file on the boot partition as well. This way, if there's any problem booting to desktop directly via Ventoy Menu, they can still boot the Ventoy and select SG2D to list all of the forum PUPs or other distro that had Ventoy booting problems to see that SG2D will provide the environment allowing forum and other ISO files to boot to desktop.

In summary, SG2D is our gold standard for booting forum distros! ... as any forum distro boots to desktop. Ventoy has some convenience, but, their are only 2 forum distros, to date, that boot directly from the Ventoy menu without issues to desktop in testing, thus far: Namely Slacko v7 and one other IIRC,

I found my ability to jump directly from download to testing an advantage to me as it offers the simplest, easiest, and simplest way to:

• go from download to desktop

• NOT take ANY drive storage for any Frugal setup

• PUPs to operate fully with ALL subsystem behaving as expected

• Ability to have the forum distros create their persistence as they expect

• The PUPs find their persistence sessions behavior as all PUPs have done in PUP history.

Booting from ISO file booting IS A FRUGAL with little to NO user involvement.
In a nutshell, since 2019 PUPs and DOGs boot with no changes to their current INITs. Thus for developers, little to no change is required for the use of their distro no matter if a user wants to boot their ISO files directly to a frugal. This does NOT diminish any user's ability to choose if he wants to deconstruct the ISO files to set up disk storage for a frugal. This is the case whether we talk about ISObooter, Ventoy, or SG2D; they all list and allow launch of ISO files it lists onscreen to the user booting their PCS.

I, personally, have benefits from the removal managing storage to boot and maintain a PUP. In my case I have a Ventoy USB with SG2D ISO file and all of the PUPs/DOGs in the forum that I boot any when needed for productive use or tests. And I have been able to test KLV and others from the forum to a frugal operation in as little as 1 minute, max.
This includes the same behavior for all other forum distros when their download sites provide high-speed downloading.

I have multiple PCs connected via a common KVM that houses my USB. Once downloading any ISO file, I merely switch the KVM to the testing PC, boot the PC which is set to look for removal unit to boot. This was described in a forum post couple years ago.

I KNOW SEVERAL OF OUR MEMBERS do not want to view this booting ISO file(s) as an advantage but for those of us with this technology at our fingertips and is a part of our understanding, this is just too simple to ignore, for me and the benefit it offers people like me who value this time savings.

Our benefit across the forum, is that for most current forum offering, we can benefit our distros from ISObooter or from SG2D for sure...while an increasing number of newer WoofCE PUPs will be booting directly from Ventoy.

I hope this post is seen as an attempt to help; as it takes NOTHING away from forum distros ability to boot and do the things that they do in their operations.

LASTLY, currently no matter which of the forum ISO files chosen, they boot via the 3 known and tested boot helpers; namely ISObooter, SG2D, and Ventoy, the forum distro developers need do little to have their distros to boot to desktop via the ISO files provided from their own PUP/DOG Menus. Thus, no PUPDOG changes should be needed in order for success to occur...thus far.

P.S. I have known about the Ventoy boot issues and I DO understand why and what would be needed to adapt its KLV INIT. But for SG2D, KLV ISO booting WORKS!

This is long in tooth, but my hope the accuracy & concepts matches the reality.

[Clarity]

Additionally, I agree with @wiak that by comparison, Ventoy is simpler and faster to listing any distro versus SG2D which is different in how it achieves the listing of ALL bootable distros and ISOs on the system. Each is different, but, for me, I know SG2D will boot all PUPs the forum has produced since 2019,

As mentioned in above post, I suspect that beginning this year many more of forum distro will emerge capable of booting via Ventoy as it is faster to listing the ISO files. But, we lose nothing knowing and having the SG2D ISO file on a Ventoy USB to boot all forum ISO files, directly. Or we lose nothing by having a SG2D USB/DVD to boot all forum ISO files.

[Clarity]

The MOST IMPORTANT benefit to the developers of this forum community is that THEY DONT HAVE TO SUPPORT either of the boot helpers. The 'helpers', SG2D & Ventoy is done by others in the open-source community in their vision to help all across the Linux world and beyond who will boot their PCs with as little effort as necessary.

All we do is report any problems to them and the 'helpers' resolve or answer. They benefit and this forum does as well

Across this community, everyone benefits from the productivity gain without lifting a finger: Developers, Users, Newbies, programmers, etc.