KLV-Airedale-rc10 with Void Linux Kernel 6.1.8_1

[rockedge]

KLV-Airedale-rc10
Kennel Linux Void Airedale Release Candidate 10 782 MiB download size ↓
KLV-Airedale-rc10
SHA1-MD5.txt

Complete system update/upgrade and outfitted with a Void Linux kernel 6.1.8_1, Firefox v109.0

@fredx181 has repaired a bug in save2flash and modified swapper.sh to adapt for the /mnt/home device showing directly in Thunar and on the desktop. swapper.sh activates any swap partitions available to KLV-Airedale during system start.

From a suggestion by @wiak added in a modification to w_init that will display icons for /mnt/home partition in Thunar and on the desktop.

New and improved tuning of the /boot directory boot stanza's. improving the reliability of booting in QEMU, Ventoy and S2SG.

Improved and rebuilt initrd.qz including expanded support for SD cards.

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

@wiak has again done more work improving the boot system menus and further improvement to the initrd.gz boot mechanisms :

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

[geo_c]

I'll be running the downloaded iso soon. As usual I will try and drop the new system into my collected XXupper_changes. I will be upgrading from RC-6.

I just wanted to comment that I'm not sure where your files are hosted, but the server downloads a 840MB file in just a couple seconds. I didn't know that was even possible on a residential router like mine. That's been the case with all your isos.

[geo_c]

RC-10 appears to be working swell with the upper_changes I've been collecting since RC-3.

Amazing stuff! I think RC-10 runs faster. Updating the KLV system is a breeze.

My tbox system makes the process that much easier. Because I use absolute symlinks to link themes and icons into the upper_changes, it's necessary when copying upper_changes to a new drive to run the KLV-CONTROL-PANEL, hit the 3 unlink buttons followed by the link buttons, then all the themes and icons are readily available.

I'll be setting up KLU-jammy soon. I appreciate all the various approaches to puppies and dogs, but I really think what you guys are doing with the Kennel-Linux method solves a lot of inherent puppy issues. It's not a pup made from the packages of another distro, instead it's actually another distro, installed similar to a pup, with all those advantages, while being fully upgradable and multi-user. Which is the reason I jumped on KLV, I could see a lot of potential which is now beginning to really shine. KLV-airedale was kind of the pilot project, and it seems like different Kennel distros are going to congeal more quickly.

Great work!

[wiak]

KLV-airedale was kind of the pilot project, and it seems like different Kennel distros are going to congeal more quickly.

FirstRib build system was a reaction against inflexibility whilst I was trying to create a simple, hopefully somewhat flexible, 'makepup' frontend to woof-CE, back in late 2018 or thereabouts, that attempted to make each new build less simply of a clone of the previous one. I could see no point in simply rebuilding a clone of the same iso over and over again from the set in stone upstream 'recipe'! But in practice I discovered there was littlle I could do to change any such build aside from complex code chunk changes directly to woof-CE skeleton core, involving hacking multiple scripts - nothing that most forum users were likely to be able to do.

FirstRib started with my idea that all I needed for a build system was busybox (to provide simple shell script understanding 'brain') and a reliable package manager to download the building bricks. Thus in early 2019 when I discovered Void Linux had a standalone version (static build) of its package manager it was a 'Eureka moment' in my head. FirstRib thus began and I also then advocated for years, on the murga forum, my opinion that upstream Void Linux was in any case a better fit as a package provider to Puppy community itself than the for main part commercialised or huge repos of the likes of Debian, Ubuntu or Slackware. Yes Slackware is a bit different, but hardly unique having been around for so many decades. Using Void not quite so unique as compiling own repos, but that self-compiling mechanism is pretty much impractical when you want to have sufficient repo app choice anyway, but Void Linux does in fact, small though its non-commercial team of ordinary open source coders is, compile its own repos, and pretty good repos too as it happens...

Certainly, Debian offered a 'debootstrap' build system to produce a Debian core root filesystem, that could be added to thereafter (which is what later DebianDog adopted), and I subsequently included that Debian-provided debootstrap mechanism in FirstRib build script code too, in lieu of an actual simple package manager, to also allow FirstRib plugin type builds of Debian, Ubuntu, or Devuan root filesystems. But Void Linux with its standalone xbps package manager exemplifies FIrstRib and thus leads the way.

The FR initrd originally didn't exist (first FR root filesystems were just used in chroot on other distros), so I purposively designed the build script for the FR initrd with the same modular plugin philosophy of build_firstrib_rootfs script itself, with the idea that it should be made able to boot most any root filesystem using a flexible arrangement of sfs compressed and/or normal directories as addon overlay layers, and I chose to use overlayfs rather than aufs on purpose, back then, unlike most all other small distros of the time, since I saw that as the future since kernel team had adopted its layer mechanism officially.

Most of my own efforts and available time have had to therefore shift to concentrate on the development of that core LEGO-like FR initrd component. Fortunately for everyone who likes FR-based systems, rockedge (Erik) saw and understood the potential of the FirstRib simple mainly two-script build design: The one single script plus plugin to build the root filesystem and one script, plus convenient to modify external w_init plugin, to build the initrd; that and 'busybox + package manager + plugin' concept. He stuck with it when no-one else particularly even noticed, and the rest is history.

Whilst I've not, unfortunately, had much time to since build much in the way of FR distros myself (WDL_Arch being one exception), rockedge has continued from that early 2019 start, to keep the Void Linux build flag flying and leading the way.

Yes, KLV-Airedale builds are indeed the core FirstRib builds that test out all the related ideas that other FIrstRib distros can then also use thereafter. The old weedogit 'turn most any distro into a frugal install' build system itself exemplified the power of the generic FR initrd design approach, and to some extent demonstrated its universal simplicity of approach.

The most important characteristic of the build system is that it is pretty much simple enough that anyone on this forum could build their own unique distro using it, whatever the upstream repo used, and whatever desktop manager wanted, and whatever... that is why we use the words 'simple' and 'flexible' for it. No git code guru experience required, desired, or necessary. Results speak for themselves.

Mind you I'm often attacked personally for advocating for FirstRIb. Odd if I didn't advocate for what I designed and believe in I'd say... Some seem to see it as some kind of competitive war, but that had nothing to do with its creation or its advance. Actually nothing is asked for in return (not even users!) aside from simple credit when credit is due.

[geo_c]

KLV-airedale was kind of the pilot project, and it seems like different Kennel distros are going to congeal more quickly.

FirstRib build system was a reaction against inflexibility whilst I was trying to create a simple, hopefully somewhat flexible, 'makepup' frontend to woof-CE, back in late 2018 or thereabouts, that attempted to make each new build less simply of a clone of the previous one
....
FirstRib thus began and I also then advocated for years, on the murga forum, my opinion that upstream Void Linux was in any case a better fit as a package provider to Puppy community itself than the for main part commercialised or huge repos of the likes of Debian, Ubuntu or Slackware. Yes Slackware is a bit different, but hardly unique having been around for so many decades. Using Void not quite so unique as compiling own repos, but that self-compiling mechanism is pretty much impractical when you want to have sufficient repo app choice anyway, but Void Linux does in fact, small though its non-commercial team of ordinary open source coders is, compile its own repos, and pretty good repos too as it happens...
....
But Void Linux with its standalone xbps package manager exemplifies FIrstRib and thus leads the way.
......
Most of my own efforts and available time have had to therefore shift to concentrate on the development of that core LEGO-like FR initrd component. Fortunately for everyone who likes FR-based systems, rockedge (Erik) saw and understood the potential of the FirstRib simple mainly two-script build design: .... He stuck with it when no-one else particularly even noticed, and the rest is history.
....
Yes, KLV-Airedale builds are indeed the core FirstRib builds that test out all the related ideas that other FIrstRib distros can then also use thereafter.
....
.... Actually nothing is asked for in return (not even users!) aside from simple credit when credit is due.

Void is a good fit. It'll be interesting to see how KLU develops. There are more application packages available in Ubuntu (Frescobaldi for instance). But with that comes the idea that Ubuntu is more of a mainstream philosophy and therefore perhaps not as modular and trim as Void.

Having a 'mainstream' psuedo-full install that maintains updates, but also runs snappy in the tradition of modular puppy utilities, while also providing the modern look of Xfce (though some would consider Xfce primitive, lightweight and dated, not me of course), is a whole lot of brownie points in my opinion. KLV fits that niche.

[geo_c]

My KLV-airedale directory looks like this:

You can see I've been saving upper_changes incrementally since RC3. Adopting the more recent iso files has always been a simple matter of updating the system through OctoXbps, then renaming upper_changes to the latest number and description, then copying in the latest iso system files. This has worked well, and so far no snags.

At this point I'm thinking about squashing 20upper_changes-29upper_changes into one read-only sfs. That would be my base system. I prefer that approach to using KLV-remaster, as it would still be possible to copy new iso system files underneath. Admittedly there's a good bit of wasted storage space with a collection of upper_changes squashed on top of fully updated system. But I think I'm willing to go that direction.

Am I missing a better tool or way of doing it?

[rockedge]

Added in @fredx181 's save2flash v1.6 that has a bug fix.
More information here -> https://forum.puppylinux.com/viewtopic. ... 880#p74880

Modified and repackaged the ISO which has been uploaded.

[fredx181]

Added in @fredx181 's save2flash v1.6 that has a bug fix.
More information here -> https://forum.puppylinux.com/viewtopic. ... 880#p74880

Modified and repackaged the ISO which has been uploaded.

All good now with the suggested changes and fixes from me and @wiak on the newest rc10, thanks Erik !

[rockedge]

@geo_c there is a rough script that will merge multiple upper_changes into one. It is experimental was originally designed to create upper_changes SFS for persistence in RAM0 mode.
There is a save.sh and a merge_changes.sh which I will track down and post. They are experimental so back up first.

The merge script might be something to build up from and will need some modification to work. Or try:
convert the XXupper_changes that will be merged to a XXchanges.sfs.
then in a directory with the XXchanges.sfs files run the merge script. It should produce a single merged SFS. Which you could again un-squash if desired.

[Sofiya]

I don't know who did it, but the disk icons on the left sidebar in Thunar are just the bomb. Thank you very much!
completely reinstalled on new KLV-Airedale-rc10

[Clarity]

I just concluded testing of an vRC10. Then thought to check only to find out that I was testing the wrong RC10.

Should the numbering for minor fixes be distinguished from the prior version number so as not to get confused. (which is easy for me )

[Sofiya]

I just concluded testing of an vRC10. Then thought to check only to find out that I was testing the wrong RC10.

Should the numbering for minor fixes be distinguished from the prior version number so as not to get confused. (which is easy for me )

[Phil_54]

@rockedge @wiak
rc10 working nicely. Save file now remembers muted sound as well as desktop shortcuts. Thank you.
I have a wish.
As you've developed KVL_Airedale I have noticed boot times to working desktop increasing. The best I had was beta16 with 35 seconds and over time this has now increased to 60 seconds. Acceptable as this is now more sophisticated, but are there any tricks to get down to nearer 35 seconds boot time? Maybe using unsquashed files? I don't often use apps other than browser, so not really bothered about slower opening of any app, just initial boot time. Should I put it on SSD and use grub2, instead of current sdcard and grub4dos?

[rockedge]

@Phil_54 I have noticed on two of my machines the boot is around 45-60 seconds and on the other 4 it's around 35-40 seconds. I think it's the added complexity in the initrd.gz to deal with the quite different drives and partitions, and finding the file system. And the dealings in the initrd.gz for the Ventoy and ISO booting in those types of installations.

We'll definitely look into it. I'll run a test replacing the kernel to a Puppy Linux huge kernel and @wiak 's skeleton initrd version to run comparison tests

[wiak]

No, initrd is fast. Takes just a few seconds waiting on slow devices to mount. Longer delays nothing to do with initrd complexity. Yes, compression type of layers makes some difference - time needed by slower cpu to decompress and lower RAM would impact on that. Otherwise different graphics card X driver can result in weird boot delays or other changes in root filesystem resulting in boot delays caused by seek algorithms waiting to timeout when something not being found for underlying system. So certainly can be firmware modules or different kernel issue. Some such combinations work better therefore on some machines than another. With some combinations I can get boot delays if Intel Xorg server installed so I install that and boot becomes fast. Sometimes it's the opposite needed.

But summary is that I am sure initrd complexity is not significant - that kind of selection logic just takes milliseconds. Mount delays are to do with drivers. The FR initrd doesn't itself impose any large fixed delays - the drivers and underlying system capabilites, resources, and hardware needs determine such delays. Difficult to get root filesystem very general purpose for all hardware. But yes, if booting at all, personally I would try to determine if xorg server is causing boot delays or some module clash needing blacklist on some computers, or if just tens of seconds slower maybe kernel or RAM related. Really nothing to do with initrd though as long as enough boot modules/firmware provided. No easy solution, but lower compression, or none, can help a lot, unless just RAM issue.

[geo_c]

I just installed KLV-airedale on another USB hard drive. This time since it's a 2TB hard drive with about 600GB of music/video data on it, and the drive allocation format is gpt, I went ahead and used the fossapup frugal grub2 bootloader. Worked like a charm, but to boot on my machines, I'll have to set my bioses to UEFI, then back again to boot their hard drives. Not a problem, and then if I take this USB drive to someone's elses computer, who undoubtedly is booting EFI, maybe it'll just work.

At any rate it reminded of one of @wiak's recent posts about not being afraid to try something new. I have always used legacy boot. But grub2 wasn't hard at all using the stanzas I found in RC-10's boot script.

[stemsee]

yesterday I downloaded the iso and frugally installed on my acer chromebook. I was surprised when it booted to desktop, as the previous version did not! This kernel is better configured. Wifi and webcam work, touchscreen, sound and bluetooth do not but im sure thats a missing firmware issue.

After a reboot wifi auto connected and the apps i was using opened up, firefox, at the last webpage before shutdown, like a state restorer.....very slick ... potentially embarrassing!

Its full featured and quite polished. I like the remaster gui its very intuitive and accessible to customise the final contents of your remaster.

I loaded one of my sfs apps but could not run it as the system could not find the executable. I mounted the sfs and copied contents to the filesystem and then it ran fine. So i decided to report the issue here.

Its a keeper!

cheers stemsee

[rockedge]

@stemsee The SFS-Load on the fly is rather experimental in KLV and overlayfs. What is the problematic SFS package?

It's good news that it now boots on a Chromebook and I believe you are correct about the missing firmware. We have a bit larger 01firmware SFS that might now have the missing firmware drivers. I could make it available if you would like to test it out by swapping this 01firmware in and replace the current 01firmware SFS

Could you try a test? Put the failing SFS in the KLV system frugal directory and rename the SFS by adding a 2 digit number in front like this example:

Code: Select all

50my_tester.sfs

Then reboot. The system will load any SFS or uncompressed directory as long as there is a 2 digit number as prefix to the name.
30Dummy_test or 30Dummy_test.sfs during the boot cycle. Does the system now "see" the executable?

It is possible to run KLV entirely as uncompressed directories. There can be 0 - 99 SFS and or un-squashed SFS directories.

[Clarity]

Hi @stemsee

Any thoughts on SNApP in KLV?

[fredx181]

After a reboot wifi auto connected and the apps i was using opened up, firefox, at the last webpage before shutdown, like a state restorer.....very slick ... potentially embarrassing!

FYI: That's happening when checkbox 'Save session for future logins' is checked at the logout gui, uncheck if you don't want (to prevent potentially embarrassment )

Screenshot.jpg (49.99 KiB) Viewed 4380 times

[stemsee]

@rockedge Ahh! So this is overlayfs in action! yes I will test out a few of my sfs apps.

@clarity indeed S.N.ApPy was the problematic sfs, in fact i didn't try another at that time, I was just to fascinated playing with the pristine desktop. I guess klv has a gtk3 yad installed as the gtk2 theming didn't work. So, it was good that snappy still ran quite respectably! I'm still working on 4.8.0 .... long way to go!

@fredx181 ah ha....checkbox safety helmet....got it!!

[stemsee]

A few hours later ...
Adding my sfs to the boot directory and renaming with two prefixed numbers resulted in booting and a working app.....however, after much ado, I discovered a problem which is a show stopper! or at least a boot to desktop stopper. After many reboots i think that either the size of sfs, or maybe the naming, or prefix numbering, causes the system to hang, requiring hard reset. This happened with a music.sfs (133mb), a kodi 18 sfs (29mb), a firmware sfs (100+mb). But with smaller sfs modules, under 10mb, it was ok. At first i thought it was the device character in /work/work/#3 ... but afer many eliminatory reboots, i ruled that out.

Is there any significance with the numeric prefix?

[rockedge]

Is there any significance with the numeric prefix?

There is! The order of the layer in ascending order. So 00modules, 01firmware, 07KLV-airedale_rootfs should be the 1 - 2 - 3 order. We keep 00-10 reserved for system SFS or directories. I usually start the extra SFS's with 11Some.sfs, 12Some_other.sfs and so on. When saving upper_changes to 30upper_changes it becomes read only and a new upper_changes is created. Since there can be 99 layers there is room to space out the layers numerically.

@geo_c I believe has a collection of XXupper_changes that create the ability to rollback in reverse sequential order. I usually start in the 30's to number and order the layers. upper_changes is the top read-write layer.

[geo_c]

Is there any significance with the numeric prefix?

@geo_c I believe has a collection of XXupper_changes that create the ability to rollback in reverse sequential order. I usually start in the 30's to number and order the layers. upper_changes is the top read-write layer.

I started in the 20's this time around beginning with RC-3, and you can see by numbered changes names that I converted to RC-6 and then to RC-10.

To drop in the new RC system files, I run an xbps system update, shutdown, reboot into another pup and rename the current upper_changes to [latest number]upper_changesRC[current]to[new], move or delete the current system .sfs files, copy in the new ones, usually delete the work directory, and reboot.

I also drop a flag file in the directory to tell me which RC files are present.

edit: Now here's a question. If I rolled back to a previous, say 25upper_changes, system before the RC-6 and current RC-10 files were implemented without replacing the system files with the RC-3 iso files, would I run into trouble? Not that I want to do that, but I'm curious.

[dancytron]

edit: Now here's a question. If I rolled back to a previous, say 25upper_changes, system before the RC-6 and current RC-10 files were implemented without replacing the system files with the RC-3 iso files, would I run into trouble? Not that I want to do that, but I'm curious.

The package database in the (now older) top most layer might not match what's in the newest 07-xxx.sfs file, so I think you'd need revert to the matching older one.

[geo_c]

The package database in the (now older) top most layer might not match what's in the newest 07-xxx.sfs file, so I think you'd need revert to the matching older one.

Yes, you reminded me why I named the upper_changes to reflect where the shifts occured. Though I'm not planning to roll back, it might be an option if I want to do a simpler, smaller remaster at some point.

I would need to reverse the RC system update process, revert to earlier numbered upper_changes and load the latest system files back in, then do the remaster.

[stemsee]

Also, wine would not function after installing with the package manager. Bluez also lacked the bluetoothd daemon, and how to start the service! systemctl not present, service start not present .... whats the method here?

Code: Select all

bluetoothd &

?

[wiak]

Also, wine would not function after installing with the package manager. Bluez also lacked the bluetoothd daemon, and how to start the service! systemctl not present, service start not present .... whats the method here?

Code: Select all

bluetoothd &

?

I don't know anything about how well supported Wine is on Void Linux though I do notice its package was updated yesterday: https://github.com/void-linux/void-pack ... e/template
Whether it needs multilib package I don't know either.

Void Linux doesn't use systemd, but rather runit which is similarly easy to configure and use: https://docs.voidlinux.org/config/services/index.html

I think rockedge has commented before that he hasn't added all bluetooth components yet, but planned to get that working soonish.

[geo_c]

Well, I have a bunch of installs of RC-10 going, and on my ssd hard drive machines the boot time comes in right around 30 seconds from the moment I hit the grub entry to the time the desktop is stable. That's pretty good I think.

Wondering if any of you are still getting the intermitent Rox panel when booting. I still get it about half the time I boot. I can't figure out why it comes and goes.

I was doing some experimenting deleting and adding files into upper_changes from another install, and I figured out that you can get double copies of files showing up that way. I think maybe I deleted a character device, like a whiteout, then when I copied a file with the same name into it, I wound up with doubles of the same files once booted. Of course I restored to a saved good copy of upper_changes.