KLV-Airedale-beta20.4 is Available.

[rockedge]

KLV-Airedale-beta20.4
Kennel Linux Void Airedale Beta 20.4 559 MB download size ->
KLV-Airedale-beta20.4
SHA1-MD5.txt

Only changes are a routine rolling system update and 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.

has the latest FirstRib skeleton initrd v6.0-rc1 supplying the initrd.gz
and is currently equipped with the kernel 5.16.14-KLV (no AUFS5 support).
00modules-5.16.14-KLV-b19.sfs has the file structure -> /usr/lib/modules

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.

• Beta20.2 has wiak's FirstRib skeleton initrd v6.0-rc1 and w_init_6.0-rc1

• the kernel's 00Module SFS file structure has been modified by moving /lib/modules to /usr/lib/modules

• included htop

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

• updated (latest 27/3/2022)save2flash to compliment initrd_v504-rc2.gz now initrd_v505-rc1.gz

• kernel 5.16.14-KLV (overlayfs built in and no aufs5) 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-beta4 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 think I'm working off 20.2. I should be able to drop the modules and initrd, etc into my frugal directory along with the upper_changes without having to modify menu.1st or worry about breaking currently installed packages, right?

~geo

[rockedge]

@geo_c should be alright right up to beta20.4 to use the same /upper_changes. Just run xbps-install -Suy in a terminal if there is any problems. beta20 - beta20.4 have just slight differences in tiling windows and including gxmessage.

[wiak]

@geo_c should be alright right up to beta20.4 to use the same /upper_changes. Just run xbps-install -Suy in a terminal if there is any problems. beta20 - beta20.4 have just slight differences in tiling windows and including gxmessage.

I'm not sure. xbps package database in the iso will be different since has gxmessage and save folder variant could overwrite that. I wouldn't guarantee using a previous save if new iso has different xbps records, but just have to try it I suppose. During beta tests, personally if I wanted to add something I'd need in future beta, I'd add it via a script I could re-run with xbps-install commands in the script and so on and any manual configs I then also did. I mean a very simple script usually - just a record of the commands I did, so just a simple command list that could be added to over time.

[rockedge]

I experimented with what happens when the KLV-airedale_rootfs.sfs is changed and the same upper_changes is used. This I will do for quickly trying out a new KLV build in a QEMU machine that already has everything set up and I can just use different ISO image files or simply switch the KLV-airedale_rootfs.sfs on a virtual HDD frugal installation Most of the time it works but there were cases of that it broke the operating system in a major way and other times where a few things didn't work correctly. Now every time I use a newer version I start with a fresh upper_changes and I'll pick one version to hang on to and customize and test configurations.

[geo_c]

@geo_c should be alright right up to beta20.4 to use the same /upper_changes.

I'm not sure. xbps package database in the iso will be different since has gxmessage and save folder variant could overwrite that. just a record of the commands I did, so just a simple command list that could be added to over time.

OKAY, I do have some questions.

First what I did:

I've been booting KLV-20 off of USB and building a system with 6 folders of upper_changes. I opened the iso, copied KLV-20.4 into a new directory along with all the upper_changes and ran grub, modified the menu.1st to one @rockedge suggested, and so I now have 2 installs that appear to be working fine from that USB stick, KLV-20 and KLV-20.4.

No problems with the updated KLV as far as I can tell.

So I decided to install it to a hard drive on a different computer than the one I've been running. I was fairly sure I used KLV on this different computer from USB in the past. But I've run into an issue.

Booting from both the USB stick and the hard drive of this different computer gives me an unusual error. The desktop loads and throws up message window that says, "Xfce Policy Agent" and tells me that my Power Manager can't load, Also the desktop background is reset, along with the drives being missing from all the file managers. I can still see the files in /home however, but the device is missing, along with any other drives I might have attached.

The last thing is trying to shutdown. The only shutdown option is logout. Shutdown and Reboot are not available. So I log out to the void login prompt and have to hard power off.

I've run this drill four or five times, changed some permissions on some of my externally linked folders to see if it helps. No luck. I can't boot this configured system on the other computer. I could try another computer, which is probably a good idea. The one I'm using boots a few OS's just fine from USB.

And importantly, this happens on both KLV-20 and KLV-20.4 from my USB stick.

addendum I kind of get the impression that Void is not nearly as portable friendly as a straight puppy. Maybe due to the hardware configurations being stored in the upper_changes?

[geo_c]

Well, I'm just looking at this directory called /work, and realizing that inside it is a character device, and that I did also copy that folder to the new machine, and of course it's still present when I try booting with USB onto a different machine.

Is this character device causing my problem?

I think I tried booting once without the /work directory, but since I just booted into a clean KLV, and have a new /work directory, maybe I should add my upper_changes back in and see if that solves it.

NOPE, and the error message I'm getting is actually that the Plugin Power Manager isnt loading. No wonder I can't shut down.

ADDENDUM And actually, I managed to break the working KLV-20.4 system on my USB stick. Couldn't seem to get it back. Same error. But KLV-20 on the USB is still going strong.

I think I'll take @wiak's advice and start building an install script from scratch.

[fredx181]

@geo_c Did you copy the upper_changes (directory) from terminal using cp -a e.g. cp -a <source> <destination> (or with rsync) ?
If you've done it with a file-manager, the problems may be because of that (permissions and ownership not correct or/and skipping character devices).

[geo_c]

@geo_c Did you copy the upper_changes (directory) from terminal using cp -a e.g. cp -a <source> <destination> (or with rsync) ?
If you've done it with a file-manager, the problems may be because of that (permissions and ownership not correct or/and skipping character devices).

I've been using a file manager, mostly Xfe, sometimes mc. I'll try it with the cp command.

But still, when I would try and boot the original USB KLV that generated the upper changes that was working on the one computer that generated them, and then use that same USB install on a different computer, I still got the error.

[geo_c]

If you've done it with a file-manager, the problems may be because of that (permissions and ownership not correct or/and skipping character devices).

@fredx181 you're right, I used the cp command instead of the file manager and that restored my USB KLV-20.4.

So to recap, I have a working copy of KLV-20.0 on a USB stick, and I installed a copy of KLV-20.4 on the same USB stick, then copied all the KLV-20.0 upper_changes folders and the work folder to the KLV-20.4, and it booted with no error from the same computer that I built the original KLV-20.0 changes. I'm posting from it now.

The problem I believe I will still encounter is trying to boot either KLV-20.0 or KLV-20.4 with this USB stick on a different computer. But I will give that another whirl and see what happens.

[rockedge]

I have come across that "polkit" error so many times since the first FirstRib's came out of the forges. Also the greyed out reboot, shutdown buttons. Looking into it I found lots of information on why it happens which I right now will need to check a huge unorganized set of notes to remember exactly what it is.

On QEMU machines the polkit user agent load error pops up more often so when it happens again I'll track down the reason and the fix again.

[geo_c]

@rockedge btw, thanks for the stickywindows! That's an indispensable item now.

[geo_c]

@rockedge @fredx181

I'm having success now.

I used the cp command to copy the numbered upper changes folders to the hard drive of my "computer B" install, and this time it appears to be working!

I didn't get the polkit error, but my background was reset. However it looks like all my installed applications are running and the OS is functioning well.

Apparently, if copying the user system, the thing to do is only copy numbered upperchanges modules and not the top level upperchanges, and also do NOT copy the /work directory. This way it loads the modules and creates a new upper_changes and work directory that don't trip the policy agent error.

Thanks for the help. Looking forward to the day KLV goes "official."

[wiak]

Whilst working on the latest build script (lots to do and test for all the distro types involved) I build myself a FirstRib Arch for the first time in maybe a year. I had a few issues but going same as it used to now. However, one of the effects of KLV-Airedale is that its xfce configuration really highlights the weaknesses in my openbox/tint2 FR Arch Linux creation. But that's a good thing - I can now see a few things I want to improve so final FR Arch will benefit in the end from that. Only thing is, the resource advantage of Openbox/tint2 is only about one extra chromium browser tab less RAM used (assuming a heavy page opened such as gmail inbox) - i.e. around 150MB. The question then comes to my mind - it is worth it (certainly not on my newer laptop) - I really enjoy using xfce and furthermore, openbox is not itself wayland-compatible so its days are numbered. Xfce4 isn't wayland ready yet either as far as I know, but that is being worked on. Yes, there are openbox 'lookalikes' but last time I read up on them they were way behind current openbox capability. Oh well, I might complete openbox/tint2 Arch Linux plugin with just a few extra changes and leave it at that for now. I must try a xfce4 Arch build to see if end result is as efficient (for an Xfce4 based distro) as KLV-Airedale (which in my tests used half the RAM on first boot than any other Xfce4 based distros I tried).

I like Arch Linux based distros though - excellent repos and pretty efficient resource-usage-wise seems to me. And I like the way they so reliably handle rolling releases - I've never had any issue over the years I've used it (and on a critical business machine).

[wiak]

Well I hesitated to bother with FR Arch, but I like Arch so much and this distro, despite being far from as neat as KLV-Airedale (yet) proved very stable and useful previously so I'm doing a bit work on it whilst testing latest build_firstrib_rootfs script. I have for example implemented Super key tiling (for same effect as done for xfce4). I'm also planning to try save2flash out of KLV-Airedale in it and may make a smallish version using KLV-Airedale huge kernel and so on. We will see.

[fredx181]

... but my background was reset

I think that has to do with the monitor type, on my laptop the default KLV-airedale wallpaper (as intended by rockedge) doesn't show (instead it's the the xfce wallpaper).
It's configured in '/root/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml' as 'monitor0' and 'screen0' , this setting apparently doesn't work for all monitor types.

Note sure if there may be a solution for this small problem.

[rockedge]

@wiak I borrowed some of the methods and configurations from the Arch PLUG to improve KLV-Airedale's PLUG in the initial stages of creating KLV's. I have a version of the FR_Arch64 built with the last set of build scripts and PLUG file that made the distro. Many of the advances gained in Void Linux are a result of reading the Arch Wiki and other Arch examples on sites like Stackexchange. Much of what works in Arch Linux also applies to Void Linux.

The only reason the openbox+Tint2 desktop isn't as polished is because like the jwm+Rox desktop, there is so much manual configuration and installing utilities to manage them, where as xfce4 has many configuration options that are easy as calling up a GUI based tool to set the parameters that are components of xfce4.

@fredx181 I agree that is what is causing the wallpaper to switch back to the xfce4 default background. I see it happen mostly on QEMU / VirtualBox machines and also certain physical machines.
I am glad you've diagnosed it to an exact cause, good work Fred.

[wiak]

I didn't get the polkit error, but my background was reset. However it looks like all my installed applications are running and the OS is functioning well.

Apparently, if copying the user system, the thing to do is only copy numbered upperchanges modules and not the top level upperchanges, and also do NOT copy the /work directory. This way it loads the modules and creates a new upper_changes and work directory that don't trip the policy agent error.

That continues to sound a bit odd to me.
If you can duplicate the error in another build perhaps, could you try renaming w_init and using the one I've attached (renamed to w_init). That's the previous ver505rc1 of the initrd.gz w_init (not much changing initrd.gz internal init script itself, but the ability to save to a file code are in w_init and the external copy in boot directory is used by default. If that still fix things, you could alternatively try using the whole previous initrd.gz (505rc1) to boot (and either leave the 505 external w_init in place or delete it (a copy is inside the initrd.gz itself, which is used if none external). To fetch that simple run the following command and once ready to reboot first rename it initrd.gz (obviously you should back up the original initrd.gz that was version 6.00rc1):

Code: Select all

wget -c http://owncloud.rockedge.org/index.php/s/ZhWzwU52raKxGyN/download -O initrd505.gz

I'm assuming your install is to a Linux filesystem. i.e. that you are not using a savefile on a fat32 or ntfs partition. I'm not saying the previous initrd.gz will fix the issue - but I can't duplicate the problem you have but it does look suspicious - I'm concerned just in case there is some kind of timing issue/race-condition effecting the overlayfs merge such that upper_changes not being merged correctly - unlikely, but would be important to know and ver 6.00 has only recently been released so not had much testing. Being the heart of the system the initrd can cause a lot of hard to find problems if any race conditions, and there is a lot involved: the kernel could sometimes cause issues because of some internal overlayfs code issues, media devices may sometimes not be settling in time, and similar matters such that booting may be fine on most systems but occasionally cause an issue on particular computers. I hope not, and simply old incompatible upper_changes directory was being used - otherwise, tricky to fix because race condition situation not generally apparent logically in the initrd/init code itself.

[wiak]

@geo_c
I think the new initrd is probably basically fine so using previous will probably make no difference to your issue (but you never know...).

Whilst I have not myself come across the issue you are having, that may simply because you are transferring installs in a way I don't normally do. Overlayfs may be a bit fussy when it comes to inodes and how it caches similar things such that when you move read-write upper_changes to other filesystems maybe that causes issues. As I say, I have no knowledge of that situation one way or the other.

However, I have found something that might be related (or maybe not...) so will post about that once I've had time to test out some ideas. Funny I haven't noticed any such effects before but again may be related to how I normally configure my system. I'll be back soon therefore with some other trick to try (though I'm not sure if what I'm going to try will have unforeseen side-effects too - only time would tell).

[geo_c]

... but my background was reset

I think that has to do with the monitor type, on my laptop the default KLV-airedale wallpaper (as intended by rockedge) doesn't show (instead it's the the xfce wallpaper).
It's configured in '/root/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml' as 'monitor0' and 'screen0' , this setting apparently doesn't work for all monitor types.

Note sure if there may be a solution for this small problem.

Is the Xfce default wallpaper the blue with a white mouse? Or is that KLV? Every boot I have done so far with KLV gives me the white mouse at first boot.

[rockedge]

@geo_c I have experienced the XFCE PolicyKit Agent error on some system starts especially in the alpha series. The error now occurs on certain setups most likely be related to having two different polkit agents at end stage of the boot cycle.

Also to consider : welp...there ya go, ya need dbus as a service with elogind installed to fix the issue

In most cases it is a flawed system start during the boot cycle and components are missing. Boot stanza miscues also have caused havoc. It could be your not getting a clean system boot.

This is the wallpaper that should be showing after system boot ->

Screenshot(6).jpg (45.16 KiB) Viewed 995 times

[geo_c]

@geo_c I have experienced the XFCE PolicyKit Agent error on some system starts especially in the alpha series. The error now occurs on certain setups most likely be related to having two different polkit agents at end stage of the boot cycle.

Also to consider : welp...there ya go, ya need dbus as a service with elogind installed to fix the issue

In most cases it is a flawed system start during the boot cycle and components are missing. Boot stanza miscues also have caused havoc. It could be your not getting a clean system boot.

Well, that makes sense. So breaking this down, in the case of my USB stick, it boots with no polkit errors on one machine, but not on another, so the setup on the stick has not changed, just the machine. But one thing I notice about this second machine is when I boot up Fossapup from a USB stick, it labels the USB stick as sda1 and the computer hard drive as sdb1, even though the bootloader finds sdb2 just fine. Not sure why that happens on this machine, which is an HP-Elite Pro from 2019 with an i5-8th gen.

But I should double check that to make sure I'm remembering correctly.

Using grub4dos from jackalpup wrote all the stanzas on this USB stick with UUID. And of course I edited KLV's stanza to the following:

Code: Select all

title Linux KLV-airedale20-0 (sdb2/KLV-airedale20-0)
  find --set-root uuid () 1b186e42-4f56-4cf3-bc41-863feab8ee43
   kernel /KLV-airedale20-0/vmlinuz w_bootfrom=UUID=1b186e42-4f56-4cf3-bc41-863feab8ee43=/KLV-airedale20-0 net.ifnames=0 
  initrd /KLV-airedale20-0/initrd.gz

title Linux KLV-airedale20-2 (sdb2/KLV-airedale20-2)
  find --set-root uuid () 1b186e42-4f56-4cf3-bc41-863feab8ee43
  kernel /KLV-airedale20-2/vmlinuz w_bootfrom=UUID=1b186e42-4f56-4cf3-bc41-863feab8ee43=/KLV-airedale20-2 net.ifnames=0 
  initrd /KLV-airedale20-2/initrd.gz

which represents two installs of KLV on the USBstick. The one labeled KLV-20-0 is beta20 and the one labeled 20-2 is beta20.4. I used this alternate stanza, the second line actually, because the 1st stanza you suggested much earlier didn't work and caused kernel panic. This one works and certainly boots both OS's on the machine from which is was built. Inserting this same stick in the other machine causes the polkit error.

So the polkit error occurs on the second machine even when no upper_changes have been copied or altered on this USB stick, all are original created with the 1st machine, but if I remove the top level upper_changes and the /work directory, it boots with all the numbered upper_changes functioning correctly. Or appearing to, possibly stuff is missing or mis-configured, but I haven't noticed so far.

I'm guessing here that what happens in the /work directory is system changes are stored or routed through the device to upper_changes, or something like that. The work file always seems to be a 0 byte file. I'm just stabbing in the dark to comprehend how it works.

[geo_c]

@rockedge I read the dbus elogind thread, and that may be the issue I suppose. I'd like to test it by booting the USB stick on the second machine, but I' m gonna stew on it for awhile, because I don't have enough hard drive space to put an install on the first machine, and I still want this stick in working order. Right now both versions on the stick are running fine to the best of my knowledge, at least no polkit error.

[geo_c]

This is the wallpaper that should be showing after system boot ->
Screenshot(6).jpg

That's not what I've ever gotten. Not since I booted beta14 and not on any machine.

Do your machines boot up with xorg or wayland? Because mine appear from the verbose boot to always be using xorg.

[wiak]

@geo_c please try both machines but with w_changes=RAM2 put at end of each grub kernel line and let me know if that makes difference to your various tests

Above not about wallpaper tho. I think I often/generally get white mouse too, well maybe above affects that too? I'm out on android phone right now so will report my main finding once home though that RAM2 mode is part of it

[geo_c]

@geo_c please try both machines but with w_changes=RAM2 put at end of each grub kernel line and let me know if that makes difference to your various tests

Just logging what I'm doing, I'll come back and edit this post as I go:

-Booted both KLV versions from USB on machine one, just to check them out. I do notice errors which have been there for awhile, first is modprobe: can't find KLV-sfs5.14.16 or something like that, it goes by fast. I don't know how to pause the machine, if there actually is a way. Then I get a runit messages, modprobe: dev/console can't open no such file or directory

Next I will add the suggested lines to the stanza...

-Booted both KLV versions from USB on machine one again using w_changes=RAM2 and both still working smoothly with the same boot messages. This time I noticed two kernel proc messages but didn't quite get the names. Didn't save the changes on shutdown.

Next I will boot the USB on machine two:

-I booted this USB stick on machine two, and now I must admit, and embarassingly, I'm not sure KLV ever booted on this machine off USB. It was late and I was bounding back and forth between machines copying upper_changes. It appears that my polkit errors on machine two were all from the hard drive install, which as I've previously said is now [SOLVED] thankfully. But, trying to boot KLV from USB on the second machine is not getting past grub, which is saying the file is not found. Not valid directory.

So I guess at this point I'm left with trying a bunch of different boot stanzas to get these USB installs to load the kernel before I can see if there are other errors.

I also suppose it would be okay to leave the two boot stanzas I have to still boot the USB on machine one, while adding more stanzas that might make this machine work.

as a note, this USB stick boots on machine two the following: Fossapup, Jackalpup, VanillapupD, and Fatdog. So this seems to be a definite stanza hurdle to overcome first, only with machine two, as machine one boots KLV with no problems with the above stanzas, and KLV boots off the hard drive of machine two with the above stanzas no problems.

Should I be looking at machine three? And widening the war? It would tell me if the stanzas are problematic for just this particular hardware or not.

[wiak]

I don't recognize any of the issues unfortunately. Never had a problem booting on any of my laptops, new or old, except for a special case I discovered this morning, which I'll document in a few hours once home. You can stall the boot in stages and thus see boot messages though. Just put the following at end of grub kernel line and boot will stop at prompt for each one. You just enter exit to continue boot onwards each time:

w_rdsh0 w_rdsh1 w_rdsh2 w_rdsh3 w_rdsh4 w_rdsh5

At least I think I have that correct. I have to check the arg names once I get home

[wiak]

Still testing before further report.

By the way, the 'modprobe' can't fine message you see on boot is irrelevant and effects nothing. It occurs because init tried to modprobe overlay, but rockedge has now included that in the kernel build itself so there no longer is a module for overlay; the mechanism was put into FirstRib initrd from the very beginning to allow the use of Puppy huge kernels, which only include aufs built in to the kernel, but only provide overlayfs as a module.

[wiak]

Test Reports:

1. Tried running KLV-Airedale with various implementations such as using uncompressed 08KLV... root filesystem and 08KLV sfs filesystem, with and without 10gtkdialog addon prior and after first use. Everything always booted fine, so actually I have nothing KLV-related to report...

However, I do have something I'll document regarding a different build altogether that had an interesting result worth documenting. Not saying I understand the details myself, but worth knowing about it I feel - though I'd have to make a rebuild to double-check same happened. Anyway, as I said, nothing to do with KLV-Airedale itself per se, so I cannot in any way duplicate or explain any issues geo_c has been having. All worked for me.

2. What I do wish to document is a strange result from a FirstRib Arch Linux build I have just made and been testing:

Scenario is that I build this and first boot with uncompressed directory 08firstrib_rootfs and no 10gtkdialog added.
It boots fine, though on second boot it does hesitate with warning message vesa: Refusing to run, Framebuffer or device present (this Xorg log detail). I've haven't checked further about that; after a little delay it goes on to boot into desktop anyway. But what is interesting is when I thereafter copy the 10gtkdialog...sfs into the bootfrom dir and reboot. The system has a kernel crash with the error message:

mount: mounting overlay_result on merged failed: Stale file handle

I then checked kernel docs on overlayfs and noted the following (extract only - the overlayfs kernel docs contain more details):

https://www.kernel.org/doc/Documentatio ... rlayfs.txt

Sharing and copying layers
--------------------------
...
Mounting an overlay using an upper layer path, where the upper layer path
was previously used by another mounted overlay in combination with a
different lower layer path, is allowed, unless the "inodes index" feature
or "metadata only copy up" feature is enabled.
...
It is quite a common practice to copy overlay layers to a different
directory tree on the same or different underlying filesystem, and even
to a different machine. With the "inodes index" feature, trying to mount
the copied layers will fail the verification of the lower root file handle.

Based on the above, but actually just guessing what to try, I modified the mount overlay code line (around line 409) in external w_init file in bootfrom directory on my FR Arch Linux install from:

Code: Select all

mount -t overlay -o lowerdir=${uc_ro}${middle}${lower}${modules00}${bottom},"${upper_work}" overlay_result merged

to

mount -t overlay -o index=off,metacopy=off,lowerdir=${uc_ro}${middle}${lower}${modules00}${bottom},"${upper_work}" overlay_result merged

rebooted, and it booted fine...

This behaviour was absolutely repeatable with that FR Arch Linux install. However, I then replaced the Arch Linux kernel and firmware/modules with that from KLV-Airedale, erased external upper_changes and work directories and repeated all of the above, but no issues occurred and I did not need the index=off,metacopy=off mount options for overlayfs at all...

I have no idea if these index=off,metacopy=off options have any negative side-effects (obviously better without them if no issues...) or why they were needed for this FirstRib Arch Linux installation, but there you have it; your guess is as good as mine. Obviously all means something per these kernel docs, though I don't understand the details sufficiently to explain why it was needed here but not in any KLV-Airedale combination tried. The information may come in useful some time though, hence my reporting the matter here.

I repeat, however, I could find nothing whatsoever wrong with KLV-Airedale itself in anything I tried with it. Booted fine always for me. I have not tried booting on different machines using usb stick, however, since took a lot of testing trying all of the above already. Also I thnk I am still using first beta20 release, so haven't tried latest at all as yet.

[wiak]

I just downloaded beta20.4

I haven't actually been testing latest releases very closely so can't say much about them.

However, I don't see where the wallpaper gets done. I just get the usual xfce4 white mouse.

Also, though not an error per se, I see that even with 10gtkdialogXXX.sfs addon, the 07KLV sfs contains an apparently newer 0.8.5 version of gtkdialog in /usr/local/bin and also a couple of versions of filemnt in there. The gtkdialog gets overlaid by the 10gtkdialog sfs of course; personally I'd not include duplicates like that unless for a particular reason?

I'm a bit short of time since busy also trying to complete and test latest build_firstrib_rootfs script - aside from above post comments it basically also builds FR Arch variant fine. Haven't tried the likes of Ubuntu yet - Void worked fine. My tests are all very short though, since takes to much time. The associated build_wiak_initrd seemed to work fine with Void builds - not with Arch since that needs a special initrd nowadays since its modules are zstd compressed.