Determining optimum modules required in KLV initrd

[wiak]

Continued from discussion with Phil_54 regarding KLV rc6.1 not booting from sdcard on his Chromebook. Thus far we have determined that the problem was caused by some missing Void Linux kernel modules required by his particular machine to be included in the initrd. We don't yet know what modules were causing the issue but now have the machine booting by using a large initrd.gz that contains a full set of kernel modules.

What follows in this post is my response to Phil_54's last post from here: viewtopic.php?p=78178#p78178
----------------------------------------------------------------------------------

PS your follow on post pointed to an initrd file you'd created, but it was the one you made for me the other week for bespoke beta25 initrd with rc6.1 improvements.

Fixed the Mega download link for the special KLV rc6 full modules set initrd.gz now thanks, but even better that you managed to build it yourself since now you have that skill for the future benefit of everyone on the forum!

https://mega.nz/file/7noQRYCZ#yvIHIbjAI ... 2t2UZufjxM
md5sum for this is 78b809ef1a2e9ad7f0515697f904d4f7

In case anyone else wants to learn how to rebuild the initrd.gz themselves, here is the link that provides the step by step howto: viewtopic.php?p=78143#p78143

[/b]I followed steps 1 to 6 exactly (you're a good teacher). Rebooted and here I am not that much later replying to you from RC6.1 on my sdcard/chrombook combo. Smooth, easy and pretty fast to boot considering initrd.gz size and my processor/memory constraints.
Thank you.
I guess you'll want to explore further what the differences are. If you need my support that's fine, but maybe in a separate thread, so all the other good folk reading this thread can get on with their questions and suggestions.

I'm delighted the resulting initrd.gz worked, which is also a bit of a miracle, but makes sense really. It is an important result since now we know there is nothing wrong with Void Linux kernel per se (for the case of your computer type) - just an issue with modules to include in the kernel and indeed we can now make some effort (over time - no hurry) to track down the culprits. So thanks for your willingness to help with that, since now you know how to modify the initrd.gz that will likely prove useful. And yes, best now in a special thread, under existing section KL-Dev_Work, for this bit of detective-like development work.

I believe the huge initrd.gz probably doesn't overload your machine because it doesn't all get kept in memory; once the switch_root to the main root_filesystem occurs (rather than the smallish initrd filesystem), most of the space the initrd was taking up in RAM is freed up (not all of it, but possibly ends similar to the small initrd - I'll have to check some Mem statistics to confirm that later since I could be wrong about that...). Will be a bit slower to boot I suppose though since so large to initially load into RAM.

Nothing new in my using a huge initrd like that, a utility I created in the past called weedogit, which was used to make frugal installed distros out of many distrowatch-listed mainstream distros in particular via same FirstRib initrd as used in KLV always put whole modules set inside the resulting initrd files and worked very well generally (though I don't know how many tests were ever made on low resourced systems). The same utility isn't dead, though it has been renamed 'firstribit' and eventually it will return as a published build system, but hopefully with slim-initrd-module capability; so that is another reason I'm interested in determining optimum module set for the initrd.

[wiak]

@Phil_54
Now that you have your machine booting with KLV rc6 using that full module set initrd.gz, it might help us determine what extra modules were required if you could post the modules_loaded.txt.tar file created using the following command:

Code: Select all

lsmod > modules_loaded.txt.tar

That's just a dummy tar extension so you can conveniently attach the resulting modules_loaded.txt.tar file up to this forum (it wouldn't accept .txt only).

The contents of that file will be complex, so probably difficult to work out what the extras needed were, but something to peruse, for a start, anyway...

[Phil_54]

@wiak
as requested file attached.
Boot time to working desktop was about 65 seconds. On beta25 it was under 50 seconds. On beta19, which I ran for a while, it was 40 seconds. Full distro like Peppermintos on separate partition, full install, just over 30 secs.
free -h shows 571Mb used with one tab open on portable chrome. That's not's bad.

[wiak]

@wiak
as requested file attached.
Boot time to working desktop was about 65 seconds. On beta25 it was under 50 seconds. On beta19, which I ran for a while, it was 40 seconds. Full distro like Peppermintos on separate partition, full install, just over 30 secs.
free -h shows 571Mb used with one tab open on portable chrome. That's not's bad.

Thanks Phil. I am just out of bed and had a quick look. One loaded module I do notice is chromeos_laptop.ko. That's not in the cut down modules initrd, but whether it is important for boot I don't know. I'll check further and later test with test cut down initrd variants. Will find the culprit eventually. Since beta25 Debian kernel/modules does boot with its cut down initrd that is another very good helper clue.
EDIT: No, chromeos_laptop.ko was not in beta25 initrd modules either, and since that booted fine, we can eliminate that one as the reason I'd say.

The difference between rc6.1 and beta25 should be quite easy to find by this method I think. I'm doing a diff between the rc6.1 and beta25 initrd kernel modules.dep files right now. Actually, more important is diff between rc6.1 special initrd I made and the beta25 one since I've already accounted for drivers/mmc in special rc6.1 initrd I made. Almost have the answer I think. Back soon once further test and will make new initrd for new boot test.

EDIT: I don't know the answer yet, but turns out, that for your chromebook it is indeed the Void rc6.1 kernel itself that has less built-ins than the Debian beta25 kernel. I'm therefore now comparing built-ins too, which should reveal the result once I get my brain working better... I suspect also that my old HP machine sdcard required different extra drivers than your chromebook for its sdcard, in which case we may be killing two birds with one stone here.
EDIT2: I see a major difference, but have an idea to test. Will take a while. Will get back to this later.

[wiak]

@Phil_54

So here is my attempt of a not-so-big, kind of midi initrd.gz that I hope will boot KLV rc6 on your computer, based on what I think was missing. Plus an alteration I wanted for other stuff I'm doing with KLV.

A lot of tricky detective work involved and I could be wrong so please test and let me know.

https://mega.nz/file/C7RhkYQK#hCcU3l2wI ... QC8PII7_5c

md5sum: b209f176c53f2275f39a06e94311ab4c initrd_rc6_midi_moduleset.gz

Again, disable old initrd.gz by renaming, and rename downloaded one to initrd.gz (assuming that is what is in your grub config) prior to booting.

EDIT: Updated since original upload, so same filename but different md5sum now.

[rockedge]

@wiak I am working on getting kernel 6.0.18_1 which is going fine it seems until I try to make the modules SFS. It is well over 500 mb uncompressed.

1. I unsquashed rc6.1 and made it into an upper_changes

2. mounted up

3. xbps installed linux6.0.18

4. exit

5. umount

6. ./FRmake_initrd.sh latest upper_changes

7. ./FRextract_kernel.sh upper_changes

which all seems to be okay but the resulting modules is 500+ mb. What am I doing wrong now??

[wiak]

@wiak I am working on getting kernel 6.0.18_1 which is going fine it seems until I try to make the modules SFS. It is well over 500 mb uncompressed.

1. I unsquashed rc6.1 and made it into an upper_changes

2. mounted up

3. xbps installed linux6.0.18

4. exit

5. umount

6. ./FRmake_initrd.sh latest upper_changes

7. ./FRextract_kernel.sh upper_changes

which all seems to be okay but the resulting modules is 500+ mb. What am I doing wrong now??

You have confused me...

What size is the initrd.gz that gets made? Should be around 20 to 30 MB max.

From your post seems it is 00modulesXXX.sfs that is 500+ MB. Is that the case?

If you are installing a second kernel, the FR scripts probably don't deal with that case (I can't remember). You should check in your pseudo upper_changes/usr/lib/modules and get rid of the earlier modules so FR scripts don't get confused probably. Your FRmake_initrd.sh commandline looks correct. I'll have to check back about FRextract; I haven't been using that so can't remember its usage. FRextract_kernel.sh --help maybe gives usage info?

EDIT: just had a very quick look at FRextract; your usage seems correct. From quick glance at the code I seem to have tried to make it use the newest kernel modules only, but sometimes that is tricky so best to manually remove the old one(s) from upper_changes I'd say prior to extracting the modules. You could always just extract the modules manually and build the sfs if FRextract making a mess of things. Main thing is is initrd.gz getting built okay.

[Phil_54]

@Phil_54

So here is my attempt of a not-so-big, kind of midi initrd.gz that I hope will boot KLV rc6 on your computer, based on what I think was missing. Plus an alteration I wanted for other stuff I'm doing with KLV.

A lot of tricky detective work involved and I could be wrong so please test and let me know.

https://mega.nz/file/C7RhkYQK#hCcU3l2wI ... QC8PII7_5c

@wiak
Booted fine, in just over 50 seconds. Good work. Thanks.
Does that mean future releases will include what I need or do I build my own initrd.gz ( with your guidance )?

Slightly related question.
I have re-downloaded klv beta19, to check its boot time (it is nearer 50 seconds not 40), but also laptop suspend action (I need this). Lid close, or terminal command or menu command for suspend, all work perfectly, and wakeup by lifting lid or touching touchpad restores session as normal. Beta 25 and the rc versions all suspend but wakeup by any method reboots the computer, or freezes the display and keyboard/mouse so reboot is necessary. Also battery drain is excessive from the suspend, but on beta19, from what I recall, was minimal. (12 hours <20%). Beta19 uses kernel 5.16.14-KLV

If this is module related or something else, I would be interested to know how to explore options and differences.
You are busy enough, I know, so ignore if unable to help.

[rockedge]

I compiled 5.16.14-KLV especially for KLV. There might be a a better 01firmware SFS that goes along with it. Let's try something easy....swap the 01firmware SFS from rc6.1 with the one in beta19. Just this file and reboot.

Do the functions work again?

[wiak]

@wiak
Booted fine, in just over 50 seconds. Good work. Thanks.
Does that mean future releases will include what I need or do I build my own initrd.gz ( with your guidance )?

Slightly related question.
I have re-downloaded klv beta19, to check its boot time (it is nearer 50 seconds not 40), but also laptop suspend action (I need this). Lid close, or terminal command or menu command for suspend, all work perfectly, and wakeup by lifting lid or touching touchpad restores session as normal. Beta 25 and the rc versions all suspend but wakeup by any method reboots the computer, or freezes the display and keyboard/mouse so reboot is necessary. Also battery drain is excessive from the suspend, but on beta19, from what I recall, was minimal. (12 hours <20%). Beta19 uses kernel 5.16.14-KLV

If this is module related or something else, I would be interested to know how to explore options and differences.
You are busy enough, I know, so ignore if unable to help.

@rockedge decides what kernel/modules he wants to release with KLV, but I'd certainly encourage him to use Void Linux with new FRmake_initrd scripts that I will soon be sending to him. If the Void Linux slimmed kernel is settled on and the initrd made with my scripts then you would not need to modify anything - your computer would just work.

I don't know anything about suspend and so on. That would likely be matters to do with whatever is built into the root filesystem I would think and not related to the initrd.

@rockedge: late here so I haven't time to post latest FRmake_init scripts but will do tomorrow. I don't mind what kernels you choose to use, but best to use the FRmake scripts to slim things down the way these kind of experiments determine. For example, original rc6.1 was missing various modules still, specially for older computers, such as pcmcia. Adding the missing ones does increase initrd size, but not substantially really - still under 30MB and provides far greater chance of boot success on multiple computers.

[rockedge]

@wiak I used a fresh KLV rootfs SFS decompressed that had no previous kernel at all. Did the very same procedure as in making the current 6.0.12_1 version. Ran it 3 times with a fresh setup each time. All the 00modules turned out to be around 540 mb when finished. The 6.0.12_1 version is around 128 mb.

So far can't get it to boot with 6.0.18_1 and the smaller 00modules from 6.0.12_1 in QEMU.

I would like to continue to use the Void Linux kernel. Try to make a fresh Void kernel.

[wiak]

I compiled 5.16.14-KLV especially for KLV. There might be a a better 01firmware SFS that goes along with it. Let's try something easy....swap the 01firmware SFS from rc6.1 with the one in beta19. Just this file and reboot.

Do the functions work again?

Something odd about forum post just now. I clicked on quote but only a little bit of your previous message is in the quote...

I'm not sure at all what you mean by the above. The matters I was sorting out with Phil_54 had nothing to do with firmware - was missing modules. Fred's crinit scripts also missed them. I fixed up FRmake_initrd scripts so all good now.
Certainly we could have different selection of kernels - huge kernels don't need specially constructed initrd.gz of course - they can be designed such that the skeleton initrd.gz can be used for booting. Having said that, I think the Void LInux kernel releases are likely to be the most stable/rock-solid for KLV.

I also don't know why you are having issues with modules sfs size. Maybe you could upload the root filesystem (without kernel modules) and I could try via mount_chroot and so on to install modules and see what the FRmake_init and FRextract scripts produce for me? I've been using FRmake_init scripts a lot of course recently and all worked without any issues. As I said, I haven't been using FRextract - it is a pretty simple script though - really just moves things out of the root filesystem and squashes up the modules; easy enough to do that bit manually really.

[wiak]

@wiak I used a fresh KLV rootfs SFS decompressed that had no previous kernel at all. Did the very same procedure as in making the current 6.0.12_1 version. Ran it 3 times with a fresh setup each time. All the 00modules turned out to be around 540 mb when finished. The 6.0.12_1 version is around 128 mb.

I'm busy doing work for partner's business tomorrow, but thereafter I'll take rc6 and try installing latest Void kernel and see what results I get. Odd if modules suddenly increased so much in size... One thing crossed my mind is that maybe Void now providing them as zstd compressed like Arch does. That being so, I'll have to modify FRextract script probably to make sure they are decompressed prior to extraction and recompressing; otherwise they would not compress very well. I can't remember if I had such facility already in FRextract - though problem might be something else anyway.

But why 6.0.18_1? That's an old kernel surely. Current official Void kernels are 6.1 series (current 6.1_4 I think).

[rockedge]

@wiak I tried to be conservative and just go up a small increment. Mostly to practice making one before making the 6.1 version.

I DID notice now that there was zstd being mentioned a lot as the script ran and was forced to install it on the F96 I am using to run the scripts because all of a sudden what was working a week ago now was failing. I installed zstd and the scripts ran smoothly.

But after 6 runs the results are the same, 00modules is around 540 mb when the 00modules for 6.0.12 is 128 mb

Plus the 01firmware is a problem to upgrade. Since it currently is a version from a Puppy Linux kernel 6.0.0. I think I would have to use the woof-CE kernel-kit to compile a huge kernel with the same version and use that fdrv SFS as the 01firmware SFS like it is now.

How do we generate a better 01firmware ?

[wiak]

Sorry @rockedge I've been over-doing it with qemu Plan 9 fs experiments (9p). I re-read your p9sts above and see what you are saying now. One of your posts was to Phil_54. I misunderstood - thought was about the huge module set! I have no idea why uncompressed modules becoming so large. Sounds over the top by Void if so.

[rockedge]

@wiak I am wondering if the Void modules are just not being processed and there is no size reduction happening.

[wiak]

Maybe best to get back to self building kernels then, via Puppy kits. Does that generate apprpriate firmware too? At least we now have good idea of boot required modules. Problem with self built kernels is getting config correct for the likes of sof. Better in the end might be to develop scripts to slim down official Void firmware and modules, but that will take a while.

[rockedge]

I am considering trying to use the 6.0.18 vmlinuz with the other 6.0.12 components to see if that'll boot the Frankenstein kernel.

Otherwise the whole process goes just as planned except the 00modules is 500+ mb

[wiak]

Check if modules in uncompressed download end with extension .ko, or if .ko.zst or .ko.xz or similar.

[rockedge]

@wiak they all seem to end with .ko

I could post an example if needed. The Void kernel performs really well in KLV and I have not been able to make a kernel that has the SOC support nailed down nor does poorercputemp work with the huge kernels I made...missing some module or firmware or missed kernel configuration.

Oh and also all of the latest kernel-kit runs have produced fdrv SFS's that are 60 bytes in size. with only one directory with licenses. Since making 5.16.14 NOT ONE kernel-kit run as produced a healthy fdrv which become our 01firmware.

Looking over the sizes the 6.0.12 00modules is 88 mb the 6.0.17 is 128 mb and 6.0.18 is 538 mb. All made with the same procedure.

[wiak]

@wiak
as requested file attached.
Boot time to working desktop was about 65 seconds. On beta25 it was under 50 seconds. On beta19, which I ran for a while, it was 40 seconds. Full distro like Peppermintos on separate partition, full install, just over 30 secs.
free -h shows 571Mb used with one tab open on portable chrome. That's not's bad.

Can't you just use the beta19 kernel swapped into rc6.1 frugal install? I.e. use vmlinux, 00modules, 01firmware from beta19 and fetch initrd-latest.gz and rename it to initrd.gz? I'm assuming beta 19 used huge kernel type so doesn't need modules put into the initrd.gz. So use that but with rc6.1 07KLV sfs and so on if that kernel better on your old chromebook?

[Phil_54]

@wiak Good point. Will try and report back.
Note I found a post from @Marv viewtopic.php?p=76050#p76050 where he says on the voidpup forum about suspend:

Code: Select all

One note on suspend. I use it a lot, probably 10x per day with the laptops, so it has to just work. I noted that after a LOT of suspend/use with the 6.1.0 or 6.0.8 kernels suspend would just stop working. What was happening -on this hardware anyway- was that the tpm_tis process was not shutting down correctly. What showed up in dmesg was:

CODE: SELECT ALL

[ 5631.852187] tpm_tis 00:06: PM: failed to suspend: error 28
Searching, this has been around for a decade or so with lots of kernel patching to do an end run on it. I'd never seen it before. I did try the usual fixes, tpm disabled in BIOS firmware, blacklisting etc. and they didn't do the trick. What worked for me was to rmmod tpm_tis prior to suspend and modprobe it post suspend in /etc/acpi/actions/suspend.sh. Not the first patch there :) I don't have enough time on S15Pup64 or LxPupSc64 to see if it shows up there with the newest kernels. One of those darn intermittants, but at least once it failed it stayed failed and showed something useful in dmesg.

I'll explore dmesg too, but if I can do what you say successfully all will be well.

EDIT: Well that was easy. Worked perfectly. Suspend works and recovers to desktop. Battery drain over 3 hours was 1%. I expect overnight ~10%. Good to go. I'm indebted to you and rockedge and other contributers for a fine distro.

[wiak]

@rockedge Regarding stripping individual modules using 'strip' command.

Void Linux does not strip modules and with good reason it seems. I imagine no distro strips modules?:

https://unix.stackexchange.com/question ... el-modules

Stripping all symbols removes the names of the symbols that the module calls. It's not going to work.

Stripping debugging symbols with strip --strip-debug *.ko (= strip -g *.ko) is safe. The kernel makefile does it for you if you run make INSTALL_MOD_STRIP=1 modules_install.

As and experiment I stripped the largest module (once in uncompressed .ko state in modules 6.1.4_1, which is latest kernel modules from Void Linux. It is a big module (uncompressed) being 18.7MiB in size.
After stripping with strip --strip-debug the size was actually slightly bigger! I have no idea why, but I also tried strip --strip-unneeded and the difference wasn't much at all so not worth the risk of modules not working as intended.

Firmware might be a different matter. Void doesn't seem to strip that either. (EDIT: Not sure about my statement there about firmware or how I came to that conclusion about Void and firmware - I do remember looking at it long ago, but don't remember what I determined about it. EDIT2: I think I remember now that it was libs that weren't stripped in Void, though checking now most seem to be after all. I think maybe libc can't though, and isn't in practice in Void, I don't know where I read about that.)

By the way, with kernel 6.1.4_1, Void Linux releases the modules as individually compressed with zstd, so there extension becomes .ko.zst. That's not the best for our purposes of final compression, but FRextract already accounts for that when making the modules_datestamp directory via extraction out of root filesystem. i.e. it uncompresses each individual module during extraction. Yes, the final uncompressed modules directory is very large (over 500MB) but once you compress that into a sfs file using the likes of:

Code: Select all

mksquashfs modules2023_01_14_193911/ 00modules_6.1.4_1.sfs -comp xz -b 512k

the resulting sfs file is around 88.7MiB, which is very similar to KLV rc6 00modulesXXX.sfs (which was for kernel release 6.0.12_1).

I will report back in a moment if I had any issue booting with 6.1.4_1 kernel/modules using same firmware as was in KLV rc6.

[wiak]

...
the resulting sfs file is around 88.7MiB, which is very similar to KLV rc6 00modulesXXX.sfs (which was for kernel release 6.0.12_1).

I will report back in a moment if I had any issue booting with 6.1.4_1 kernel/modules using same firmware as was in KLV rc6.

Did the following using KLV rc6.1 release and replaced its kernel with Void latest per below description:

As I said, I fetched the new kernel after first unsquashing 07KLV rootfilesystem sfs and using utilities mount_chroot and umount_chroot followed by xbps-install -Sy linux inside that chroot. Then used FRextract and FRmake_initrd utilities on the resulting squashfs-root (of 07KLV rootfilesystem sfs).

Booted fine with the new 6.1.4_1 based initrd.gz that I made using FRmake_initrd.sh (with its dependency FRmake_initrd_deps.sh), along with the new vmlinuz and 00modulesXXX.sfs for 6.1.4_1 of course. Still using same 01firmware sfs as rc6. FRextract, by the way, worked perfectly, extracted kernel and also the uncompressed modules directory ready for squashing. The vmlinuz-XXX needs renamed to simply vmlinuz of course per grub stanza used. Just took a few minutes to make all that.

Indeed I'm posting from it now.

Final iso size using this newer kernel should be pretty much the same as rc6 release (assuming little or no change to underlying 07KLVxxx.sfs rootfilesystem.

Of course you could make iso slightly smaller if 00modules was made a bit smaller, but even if 00modulesXXX.sfs was 0 bytes in size that would hardly make the iso much smaller really. The new initrd.gz (with extra modules so sdcard works and more besides just to be sure... came in at 29MiB, so a very slight increase only at the end of the day... and at least will now support more computers, which is best I feel.

More generally there is nothing wrong with using an older kernel and probably best for older computers per my discussion with Phil_54 (the huge-kernel plus modules used in beta19 apparently being optimum for his old Chromebook), but the extra modules being included in the initrd.gz for non-huge-kernel case is very important for some functionality such as sdcard boot capability (but only if user needing that). Can still use exactly the same 07KLV root filesystem no matter which kernel being used, so just as up-to-date KLV-Airedale - since same root filesystem... For those on newer computers good to keep in sync with upstream Void releases on new builds though; however matching firmware may be an issue unless we devise a strategy for slimming down official firmware release by Void - and 'maybe' stripping the binaries of that if that doesn't cause issues - but not strip modules since per my above post that seems to not be good. Actually I don't know if you can strip firmware - not sure what it is composed of - file command seems to say it is 'data' - seems it isn't 'binaries' per se: https://askubuntu.com/questions/1300404 ... re-exactly

EDIT: Been in it for a few hours now (played long hard game on lichess), and it is running very smoothly and efficiently on my, admittedly quite powerful, HP i7 business laptop. I even won the game on lichess though I think that was nothing to do with the new kernel.

[rockedge]

@wiak I don't understand why attempts are failing. It seemed like cut and dry. I would have had rc7 out with 6.1.4_1 already!

I also am ending up with a 00modules around 88 mb. But boots to a frozen desktop like the there is no firmware or modules.

I am going to start fresh this morning and get this done. I would really like to continue on using the Void kernels and get this process down to routine!!

First is the make initrd script then extract........

Oh and using aqemu as the GUI for QEMU I found out how to boot kernels using Multi-boot feature, This allows booting the distro with a entirely different kernel than the one in the distro itself. It's fantastic! Just working through the directory tree I have of all these kernels.

In AQEMU look under the Boot Kernel options! Now can test kernels in rc7 WITHOUT having to change the ISO itself!

My son plays chess well. I taught him the game when he was around 4.5-5 years old. Played blitz chess on line winning a lot. By the time he was 10 I couldn't beat him anymore. When he was 11 he announced he was going to play in the famous Hamburg Germany youth chess tournament. It's a big deal and spans about 4 or 5 weekends, He never played at this level before really. Ended up in the final game against a 17 year old after all 5 weekends of playing both Saturday and Sunday.

Literally blew me away. Now he's all grown up and a Computer engineer and I still can;t beat him. Maybe if we play with a football game on television and I catch him when he's really watching the game on TV and I can sneak a move by him. I guess I can teach the basic fundamentals of chess to youngsters well but after that I'm cannon fodder.

[rockedge]

@wiak Found the problem was the initrd.img was not being completed! I was ending up with a initrd-latest_decompressed.img and not the initrd.img

So I was using an incomplete initrd.img because I was ending up with initrd-latest_decompressed.img and renaming it. I ran the whole thing again just now and in 10 minutes I have a brand new initrd.gz that works!

Why this was happening yesterday is a mystery still. But today ran the kernel making on a F96_4-radky6-CE and all the componets are looking good and working with the 00modules at 88 mb

I'll push out the "real" rc7 today! I think we can automate this procedure in some way in the near future. For now I am really pleased with the performance and I updated the rootfs as well.

Strange is using the incomplete initrd it still booted, but no working inputs.

[wiak]

Strange is using the incomplete initrd it still booted, but no working inputs.

Oh well, don't know what could have happened. The initrd does end up with .img in its name, but can't remember the details, but I don't think there is an issue so let's not worry about it.

As for the (off-topic) chess... I last played competitive chess in around 1990 in an Open Tournament - biggest in East Africa, the Kenya Open. I managed to beat an International Master there, was narrowly beaten (as black) by another International Master from India, and resigned (mistakenly in under-crazy-attack panic, when turned out to be, on immediate analysis, an end game win for me sigh...) to an another IM who was captain of the (I think Ugandan) chess team. The Ugandan had won the Kenyan Open the previous year. Later that year I was sent a postcard from the Chess Olympiad (being held in Manila, Philippines) by that captain of team because he remembered the (extremely aggressive exciting game he had had with me at Kenyan Open). Aside from that I only played in two tournaments as a school boy though I captained my school team to become East Scotland champions. However, that was long ago and nowadays my rating is only at best around 1500 (back then was rated somewhere over 2000), so I'm pretty often beaten by not even particularly strong players.

[rockedge]

@wiak I have made KLV-Airedale-rc7.2 available and ready to download. I am have a really good runs with rc7.2 in both a QEMU machine and bare metal machines of various types. Overall with kernel 6.1.4 KLV is efficient and excellent in low resources at idle.

A lot of fun to use and is really handy in a QEMU VNC with full screen option enabled. From a remote machine on the LAN using Tigervnc-client I am connected and running in full screen mode and using Settings->Display switched resolution to the full 1920x1080 of the remote machines monitor. Works exceptionally fast with quick response.

I will experiment with a QEMU version ISO that has no kernel components except for the 00modules SFS. For running with QEMU's multi-boot option and testing out kernels from the collection without installing the kernel. Still though dealing with the 00modules and switching that out with others to test with does require repacking the ISO.

Seems that some mixing and matching is possible as far as the 00modules SFS and kernels close to it's generation,