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

[rockedge]

KLV-Airedale-rc3
Kennel Linux Void Airedale Release Candidate 3 733 MiB download size ↓
KLV-Airedale-rc3
SHA1-MD5.txt

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

Posting from it right now.

Yes, best so far I'd say.

To save time in terms of testing I immediately made this frugal install of RC3 to an ntfs partition and using w_changes=RAM2 mode out-of-the-box into sparse created upper_changes.ucimg, made a test file and a save2flash - everything seems to be working correctly including audio sof supporting my tricky audio hardware fine it seems.

EDIT: Sound working fine confirmed. Made a wex screencast (always a good overall multimedia recording test) with audio and embedded webcam and all worked nicely once I adjusted my Audio mixer pulseaudio settings to my taste... very good.

[rockedge]

I forgot to assign the ownership before the rootf squash!

Please do in a terminal:

Code: Select all

chown -R spot:spot  /home/spot
chown -R weedog:weedog  /home/weedog

I will fix this and upload the replacement soon!

UPDATE: the replacement has been corrected and uploaded, and is ready for download.

[wiak]

I forgot to assign the ownership before the rootf squash!

Please do in a terminal:

Code: Select all

chown -R spot:spot  /home/spot
chown -R weedog:weedog  /home/weedog

I will fix this and upload the replacement soon!

UPDATE: the replacement has been corrected and uploaded, and is ready for download.

Thanks rockedge, I had to go out so didn't even get as far as noticing the permission issue! Re-downloading. I have switched off secure boot on my laptop at last - couldn't stand it any longer so can now boot KLV from my hard disk without needing special usb grub2 key... Still keeping Windows partition, but once my disk space gets too low (1 TB) that will go too...

[Sofiya]

wow!!! Now it loads fast, great!
works great. uploaded to folder KLV-airedale with upper_changes saved KLV-airedale-2 . so far everything is working great.

[geo_c]

Copied this underneath my several layers of upper_changes and man does it run fast now, boots fast also.

Now that KLV is so good, I have this one question that I never get around to asking about the default applications chooser. There are basically fields for four things, and then the rest of it is more of mime-type arrangment.

What's a good method to change say all of the file types that open with geany to another editor of choice?

I'm just using geany as an example, not necessarily to change it in particular. If it requires doing a search and replace in a certain file, which file is it?

[fredx181]

@wiak and @rockedge Nice job ! Good that it's running with the Void kernel now, about the Debian kernel I already had my concerns, e.g. problem getting the kernel sources (headers), as I mentioned earlier.

@geo_c

What's a good method to change say all of the file types that open with geany to another editor of choice?

Just right-click on a file and select "Open with" > "Open with other application", select your application and check "Use as default for this kind of file"

[fredx181]

@geo_c

What's a good method to change say all of the file types that open with geany to another editor of choice?

Just right-click on a file and select "Open with" > "Open with other application", select your application and check "Use as default for this kind of file"

EDIT: Above is for opening files from Thunar, for ROX it's different.

[rockedge]

........for ROX it's different.

in Rox it can be set with "Set Run Action" and or using "Customize" right clicking on Rox window

[geo_c]

........for ROX it's different.

in Rox it can be set with "Set Run Action" and or using "Customize" right clicking on Rox window

Yes, I could do that. But I'm still curious about changing default applications system wide, and not one filetype at a time. So in the Xfce default applications chooser, you can see that geany comes up for various filetypes. Seems that changing it with right-click in the file manager means doing it for every single one of those file types. So I'm wondering it there is a file to just search and replace those filetype association in a single shot:

[fredx181]

@geo_c I see what you mean, it's very Puppy specific way based on (I think) scripts in /usr/local/bin 'default....' e.g. defaultbrowser, not saying it's impossible, but won't be easy to implement in KLV...

[rockedge]

I'll look closer at a better solution. Perhaps a custom utility system but some experimenting will come first.

[Sofiya]

kernel - Void Linux version 6.0.12_1 - correct selected, my laptop just purrs
about the same as in Slacko64 8.2.1 with kernel 5.10.0
quiet idle

[mikeslr]

Hi Guys,

Please move this post to where ever you think appropriate.

Conclusion: It really would be helpful if there was one thread under KLV-Airedale which provides explanatory examples of the basic grub4dos' menu.lst and grub2config' grub.cfg to use with KLV-Airedale, together with other usable boot-arguments and their meanings.

Well, I finally got around to downloading the latest ISO and unpacking it into a folder. At which point I realized that adding it to grub2config's grub.cfg wasn't as easy as copying a listing for a Puppy and just changing the name of the folder in which vmlinuz and initrd are to be found.

I am fortunate. Having previously set up an earlier version of KLV-Airedale and also weedog'd manjaro and Pop_OS, somewhere in storage I likely have examples of 'boot-arguments'. But rather than searching thru a terabyte of files the first way I searched for guidance was to explore the listing under https://www.forum.puppylinux.com/viewforum.php?f=192. Nothing jumped out and bit me. So I ran https://rockedge.org/psearch/ with the argument 'KLV boot menu'. Lots of hits, none specifically useful.

Others, desiring to try out, but entirely new to KLV-Airedale, lacking even my, albeit, cumbersome resources will simply pass it bye.

[geo_c]

At which point I realized that adding it to grub2config's grub.cfg wasn't as easy as copying a listing for a Puppy and just changing the name of the folder in which vmlinuz and initrd are to be found.

@wiak provides a grub.cfg file in the iso. Did you try using some of those? I'm not familiar with grub2. I use grub4dos and change to find-the-UUID. The stanzas look like this:

Code: Select all

title Linux KLV-airedale20-2 (sda1/KLV-airedale20-2)
  find --set-root uuid () b768543e-4e76-201-8e25-d5689rf61hsd
  kernel /KLV-airedale20-2/vmlinuz w_bootfrom=UUID=b768543e-4e76-201-8e25-d5689rf61hsd=/KLV-airedale20-2 net.ifnames=0
  initrd /KLV-airedale20-2/initrd.gz
 

also notice the "w_bootfrom=" parameter

[rockedge]

@mikeslr Yes we are aware that the setup of boot stanza's for grub2config and Grub4Dos can be tricky. What you need is going to be a basic one most likely so all those extra parameters don't need to be used or set.

Also most importantly @wiak provides a script in the ISO called wd_grubconfig. Run this script from the frugal install directory in a terminal. It will create the grub2config compatible stanza's which then you can copy to your grub2 menu.

[wiak]

Conclusion: It really would be helpful if there was one thread under KLV-Airedale which provides explanatory examples of the basic grub4dos' menu.lst and grub2config' grub.cfg to use with KLV-Airedale, together with other usable boot-arguments and their meanings.

Please see "Booting KLV-Airedale and KLA" post now here: viewtopic.php?t=7596

When first visiting Mainline Puppy area or the forum in general, where do you find how to boot Puppy or the DebianDogs via grub? Funnily enough, because I rarely myself set up Puppy anymore I know the feeling of having to trawl the forum and psearch in my attempts to find the boot stanzas for Puppy. i.e. Imagine you are truly a new visitor to this forum and simply click on Mainline distros and the thread for one of them. I believe that generally just provides download link but not howto boot?

[Sofiya]

xfce updated from 4.16 to 4.18

[rockedge]

I've been wondering what will happen if the Void Linux kernel is getting updated? I don't think it will exactly work as intended.

For now I will recommend to put a HOLD on the Linux6.0 package so the update/upgrade will by-pass the kernel during the these operations. At least until we can see how it works and what actual effects will be.

The concern is adding bloat to the system with unused kernel particles from update activity that can't be dealt with by vkpurge

Holding packages

To prevent a package from being updated during a system update, use xbps-pkgdb:

Code: Select all

# xbps-pkgdb -m hold <package>

The hold can be removed with:

Code: Select all

# xbps-pkgdb -m unhold <package>

In this current KLV the command looks like this:

Code: Select all

xbps-pkgdb -m hold linux6.0

More info in the manual -> https://docs.voidlinux.org/xbps/advance ... g-packages

We will update the rootfs for the next generation of rc3 -> rc4

[Sofiya]

so it turns out my puppy is dying?
viewtopic.php?p=75882#p75882

[rockedge]

That's one of the advantages of KLV and KLA, we already are updated to glibc-2.36 and I am going to put out a rc4 that has all of the latest major updates completed.

[Sofiya]

That's one of the advantages of KLV and KLA, we already are updated to glibc-2.36 and I am going to put out a rc4 that has all of the latest major updates completed.

mm .... we are cool then

[mikeslr]

As my boot-loader IS grub2, I adopted the following I think from the one I used to boot weedog'd Pop_OS.

menuentry 'KLV-Airedale AUTO-SAVE'{
search --no-floppy --set=root --fs-uuid 39ff...d
linux /KLV/vmlinuz w_bootfrom=UUID=39ff...d=/KLV
initrd /KLV/initrd.gz
}

menuentry 'KLV-Airedale RAM-MODE NO CHANGES '{
search --no-floppy --set=root --fs-uuid 39ff...d
linux /KLV/vmlinuz w_bootfrom=UUID=39ff...d=/KLV w_changes=RAM0
initrd /KLV/initrd.gz
}

menuentry 'KLV-Airedale NO-NEW-CHANGES'{
search --no-floppy --set=root --fs-uuid 39ff...d
linux /KLV/vmlinuz w_bootfrom=UUID=39ff...d=/KLV w_changes=RAM2
initrd /KLV/initrd.gz
}

AFAIK, the arguments for grub4dos are almost always identical, only involving a change of the word 'linux' to 'kernel'.

I've only booted using "NO CHANGES" so that I could explore without fear of screwing things up. As I mentioned elsewhere one of the things I want to explore is to what extent, if any, the capabilities when employing AUFS are lost when employing Overlays.

Wiak and Rockedge has created a really great operating system. 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-- I'm really impressed how many of the AppImages and MikeWalsh's portables functioned OOTB under a 'Void-based' system. I didn't test all of the 246 I've accumulated. Just a sampling from each category of tool, e.g. graphic editors, video editors. Something functioned under all categories. Some specific applications, such as Olive, which worked under other OSes, didn't. But either or both Openshot or KDEnlive, and Shotcut did.

As I've also previously mentioned, one of my interests is keeping the RAM needs of computing systems low. Regardless of how efficiently an operating system manages caching installed application via RAM-Cache, portables and AppImages do that better. At most only the small links to an external file occupy RAM when the application is not in use.

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.

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

[wiak]

I've been wondering what will happen if the Void Linux kernel is getting updated? I don't think it will exactly work as intended.

For now I will recommend to put a HOLD on the Linux6.0 package so the update/upgrade will by-pass the kernel during the these operations. At least until we can see how it works and what actual effects will be.

Yes, that one of the main problems, often not stated on Puppy forum, of using frugal installations - more steps involved in acheiving a successful upgrade of kernel or glibc.
Easy to upgrade a kernel if using a huge kernel, but not so easy since you need to build a huge kernel!!! Using an upstream official kernel, as KLV-airedale is currently doing, is a big advantage otherwise in that no patching is required and the kernel is well tested for use in the distribution; however, yes, you need to put a hold on whatever kernel version is included in releases. Certainly new releases with new kernels can always be easily made later via new plugin builds, with remade initrd+required_modules to support it, but each rebuild should include hold on whatever official kernel is used. That's what I have always done when building earlier WDL_Arch64 distros - put a hold on the kernel to prevent incompatibility arising between main root filesystem kernel and initrd-included-modules.

If we want eventually to avoid needing to hold kernels (though holding kernels for a while is not a bad thing anyway) we would need to device a mechanism that somehow automatically remakes the initrd immediately an official kernel is updated via the xbps package manager. That idea has been in my mind, but I haven't investigated the howto do it as yet. In practice full install distros do exactly that - the initramfs gets automatically updated, so tapping into that mechanism to remake the FirstRib initrd, or similar, would somehow have to be done. I can imagine off the top of my head a less than automatic way to achieve this - could manually update initrd from a running system (since existing initrd has already done its work and is held in RAM by the time switch_root to the main root filesystem. However, I also feel a small daemon could notice when kernel change occurs and automatically then rebuild appropriate initrd. Complex overall, and maybe not necessary really, but we will see. Glibc used to update without issue in WDL_Arch64, which is more of a real issue in the Puppy world, so I was delighted by that; whether same is the case with Void-based KLV I don't know, but imagine it might well be fine.

[wiak]

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

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.

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!

[dancytron]

What is the standard way to do run-as-spot or run-as-guest to run Chromium, VLC etc?

Is there a better place for easy questions like this than the cutting edge development thread?

[rockedge]

@dancytron here is fine to ask questions. You can use run-as-spot or run-as-weedog to start a program like VLC as the root user.
Or sudo -u spot vlc is possible as well.

Also KLV is a true multi-user system so it's possible to logout and login with user=spot and password=spot. Similar with user=weedog and password=weedog and just start VLC. Also just in case user=root and password=root

The passwords are all changeable.

[wiak]

What is the standard way to do run-as-spot or run-as-guest to run Chromium, VLC etc?

Is there a better place for easy questions like this than the cutting edge development thread?

This isn't really the dev thread, more the announcements thread for RC3 release I think, so I imagine it is fine to post questions about matters to do with using it. There is a KL_Dev_Work area for detailed dev discussions, which can include todo items or user proposals for discussion too. I've leave rockedge to answer your specific question though since I know nothing much about these run-as scripts and tend to start the likes of Chromium my own way at home. oops.. my post crossed with more relevant one from rockedge, whom in different timezone I thought might be asleep, but maybe just afternoon over there... (albeit Sunday there and Monday afternoon here now).

[Clarity]

Tested ISO file booting via SG2D and QEMU. QEMU was a KLV Menu's RAM0 boot while bare-metal (via SG2D) with the booting Menu's 2nd stanza change of

Code: Select all

linux /vmlinuz w_bootfrom=${iso_path} net.ifnames=0 w_changes=LABEL=Persistence=/Sessions w_changes1=RAM1 initrd /initrd.gz

On the desktop, now; and running well.

Thanks to all!

[wiak]

Tested ISO file booting via SG2D and QEMU. QEMU was a KLV Menu's RAM0 boot while bare-metal (via SG2D) with the booting Menu's 2nd stanza change of

Code: Select all

linux /vmlinuz w_bootfrom=${iso_path} net.ifnames=0 w_changes=LABEL=Persistence=/Sessions w_changes1=RAM1 initrd /initrd.gz

On the desktop, now; and running well.

Thanks to all!

Just a note that we don't really use RAM1 mode; it is there, but has limitations. Instead we use w_changes=RAM2, which is very similar to Pupmode13 and allows user option to save or not save sessions via save2flash and/or at shutdown. Without w_changes being specified, an upper_changes folder is created on the boot media and automatically used via direct read/writes during session. I haven't tried SG2D for a long time, but I'll give it a spin in the near future to see all is reasonably well.