KLV-Airedale-beta23 with Puppy Linux (Debian) 5.19.11-kernel-kit

[rockedge]

KLV-Airedale-beta23
Kennel Linux Void Airedale Beta 23 635 MiB download size ->
KLV-Airedale-beta23
SHA1-MD5.txt

This is KLV-Airedale-beta21 with a Puppy Linux kernel-kit Debian version 5.19.11-kernel-kit (Debian) with SOC support bumping the version to beta23.

Using the woof-CE built kernel has increased the ISO size by around 100 MiB to 635 MiB

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

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.

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

• woof-CE built 5.19.11-kernel-kit Debian is used with SOC supported

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

[rockedge]

@wiak This should play nice with your machines and recording....hopefully.

I am still working on a smaller in overall size kernel that does the same thing and has no AUFS patches.

[fredx181]

@rockedge just a thought, without being disrespectful to your (or ozsouth, peebee or ...) ability of compiling a kernel, I wonder if it's perhaps better to leave this up to the *real* experts, e.g. from Void team or Debian team ? (yes it will add more to the size of the ISO, although with the Debian kernel setup that I shared earlier here: viewtopic.php?p=69615#p69615 not too much IMO).
Still thinking of a how-to for creating a Debian kernel setup for KLV, but I prefer to make it as a script that does the most automatically (as possible), will need some time, btw did you or @wiak test my earlier shared Debian kernel "package" ?

[Clarity]

Downloaded ISO file. In a QEMU VM, 33 seconds to desktop without any messages. AT KLV boot menu,allowed the topmost RAM0 option to be chosen ...unmodified.

Running in the VM: All things so far have no regressions or problems. Posting from it now. DMESG report nothing unusual and messages seen are repeats:

root# dmesg | grep error
[ 28.376293] I/O error, dev fd0, sector 0 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0
[ 28.376301] floppy: error 10 while reading block 0
root# dmesg | grep fail
[ 0.514379] acpi PNP0A03:00: fail to add MMCONFIG information, can't access extended PCI configuration space under this bridge.
[ 1.578381] exFAT-fs (sr0): failed to read boot sector
[ 1.578384] exFAT-fs (sr0): failed to recognize exfat type
[ 6.660851] qemu_fw_cfg: module verification failed: signature and/or required key missing - tainting kernel
root#

Booting Bare-metal taking the RAM0 Menu selection, this distro boots to desktop without any issues. It has the SAME annoying 'ever 1 sec popping' feedback thru the speakers as reported occurring with VoidPUP and VanillaDpup. Operationally, EVERYTHING works even as this continued annoyance is present. ANd, as reported, if I play music or multimedia which uses the speaker built into this monitor, the popping stops...an ONLY returns after the media completes. I have a feeling this is related to this old HP PC that is over a decade old along with something in the new kernels/distro. BUT, unlike VoidPUP, this distro uses the same audio manager as VanillaPUP; as such, I have not found a utility that would circumvent the continuous popping (in VoidPUP, it was a Retrovol setting that stopped it, but here ???)

I will try to see if the same problem exist on one of the 'newer-old' PCs I have.

Anyway, as reported, above, for the VM, here is the same report on the bare-metal test PC.

root# dmesg | egrep fail
[ 0.675052] ACPI Error: AE_ALREADY_EXISTS, CreateBufferField failure (20220331/dswload2-477)
[ 2.509664] sd 4:0:0:0: [sda] Asking for cache data failed
[ 3.010169] exFAT-fs (sda1): failed to read boot sector
[ 3.010172] exFAT-fs (sda1): failed to recognize exfat type
[ 4.361671] exFAT-fs (sda1): failed to read boot sector
[ 4.361673] exFAT-fs (sda1): failed to recognize exfat type
[ 5.701795] exFAT-fs (sda1): failed to read boot sector
[ 5.701845] exFAT-fs (sda1): failed to recognize exfat type
[ 7.689672] exFAT-fs (sda1): failed to read boot sector
[ 7.689675] exFAT-fs (sda1): failed to recognize exfat type
[ 8.823732] exFAT-fs (loop0): failed to read boot sector
[ 8.823734] exFAT-fs (loop0): failed to recognize exfat type
[ 38.483319] acpi_cpufreq: module verification failed: signature and/or required key missing - tainting kernel
root# dmesg | egrep error
[ 0.675057] ACPI Error: Aborting method \_SB.PCI0._OSC due to previous error (AE_ALREADY_EXISTS) (20220331/psparse-529)
root#

Some might smile at this: One benefit to this annoyance is that I now am forced to run a soothing background music which stops the annoyance while doing thing on its desktop Or running a repeating waterfall audio file.

This distro is Wonderful!!!
Merely a status report.

[wiak]

@rockedge just a thought, without being disrespectful to your (or ozsouth, peebee or ...) ability of compiling a kernel, I wonder if it's perhaps better to leave this up to the *real* experts, e.g. from Void team or Debian team ? (yes it will add more to the size of the ISO, although with the Debian kernel setup that I shared earlier here: viewtopic.php?p=69615#p69615 not too much IMO).
Still thinking of a how-to for creating a Debian kernel setup for KLV, but I prefer to make it as a script that does the most automatically (as possible), will need some time, btw did you or @wiak test my earlier shared Debian kernel "package" ?

I have tried it and it certainly works fine on my laptop (audio output and also the digital mics). Similarly, official Arch kernel works fine (audio output and record) on same laptop, on my latest FirstRib Arch64 build (i.e. it has good sof kernel/modules config).

I'm actually think it would be good to perfect both approaches: 1. using official kernel with modules inserted into the initrd to provide sufficient boot drivers, and 2. huge kernel where sufficient boot drivers are built into the kernel itself.

I like using official upstream kernel for same reason fred mentions - upstream kernel devs put in all the work and have time and numbers and experience to do so. Also allows upgrading kernel in line with upstream releases - but... really need that cr-initrd cutting down modules method scripted so can easily generate new initrd.

But I also like using huge kernel because it is so easy to swap kernels with that method so I don't think we should abandon that approach, but rather also have the alternative use upstream kernel with injected-into-initrd modules approach.

Going out just now, so haven't had time to test beta23 yet - I tested fred's cr-initrd kernel download on my previous beta22 install. Fred certainly has a good point about reliability in terms of cr-initrd creations likeliest to work on most machines whereas huge kernel creations might miss something. For the latter I think it is best to start with upstream kernel configs and then tweak these to create huge kernel and hence get upstream support for the most part rather than for kernel builder just to config what they think might be okay.

[Clarity]

The problem with the system's continuous popping thru the speakers reported, is local to one specific PC I use for test.

Just confirmed!

FYI

[rockedge]

@wiak I might have successfully added the audio module to the kernel 6.0.1-KLV. I have re-compiled this version with an improved kernel configuration.

I also agree fully on leaving the kernel setup as it is with being able to mix using huge kernels or a selection of other kernels.

Please try out beta24 (571 MiB)to see if the SOC support does work in this newly compiled 6.0.1-KLV

Will have to wait for a report if the touchscreen, touchpads are working as well!

[wiak]

@wiak I might have successfully added the audio module to the kernel 6.0.1-KLV. I have re-compiled this version with an improved kernel configuration.

I'm afraid you haven't.
I downloaded the iso and made frugal install, but before even booting it I look at the modules and noted the required ones were still missing. As I've said a few times, the modules you need would be found in directory:

/usr/lib/modules/6.0.1-KLV/kernels/sound/soc/sof/

but no 'sof' directory is to be found in your beta23 provided modules, so I was not surprised at all that my digital mics remain unworking with KLV-airedale when I did boot it up. You need these sof directory containing the required modules, not just the soc directory.
So sorry, you are not there yet. I suggest you compare with the modules provided in vupup - you will see the difference - it has the sof modules included, as does fredx181's cr-initrd created version - hence these work. Surely @dimkr could supply you with the kernel configs he used for vupup and you could then make whatever other changes you wish for KLV???! Presumably he is using Pupppy kernel kit for his build too, but, as he said, not using kernel configs provided at woof-CE (though why his one is not on woof-CE is mysterious to me - can it not be added there for others to benefit from it?).

[dimkr]

You can also use the puppified Debian sid kernel from https://github.com/puppylinux-woof-CE/w ... 3278986697 for comparison. Sid has changed to 6.0.2 recently.

[wiak]

You can also use the puppified Debian sid kernel from https://github.com/puppylinux-woof-CE/w ... 3278986697 for comparison. Sid has changed to 6.0.2 recently.

Yes that's probably another option but would be better overall if rockedge knew how to make his own that worked. I would think some close comparison should make that possible though.

[fredx181]

See here for a script to create a Debian kernel setup: viewtopic.php?p=69909#p69909
@rockedge Perhaps best to include kmod package (for the "full" depmod) in next release (instead of busybox depmod symlink)
With the busybox depmod, the -b option doesn't seem to work as it should, resulting in failure booting the kernel.

[Clarity]

Tested v24b

• NO popping thru the sound card. Thanks for the change(s) that addressed that annoyance on this old test platform. Thus, that problem introduction was release related for this PC

• Booted ISO file via SG2D with NO issues to desktop

• Very snappy, indeed

root# dmesg | egrep fail
[ 0.551472] ACPI Error: AE_ALREADY_EXISTS, CreateBufferField failure (20220331/dswload2-477)
[ 2.380037] sd 4:0:0:0: [sda] Asking for cache data failed
root# dmesg | egrep error
[ 0.551476] ACPI Error: Aborting method \_SB.PCI0._OSC due to previous error (AE_ALREADY_EXISTS) (20220331/psparse-529)
root# dmesg | egrep snd
[ 65.833503] snd_hda_codec_realtek hdaudioC0D0: autoconfig for ALC260: line_outs=1 (0x15/0x0/0x0/0x0/0x0) type:line
[ 65.833512] snd_hda_codec_realtek hdaudioC0D0: speaker_outs=1 (0x11/0x0/0x0/0x0/0x0)
[ 65.833515] snd_hda_codec_realtek hdaudioC0D0: hp_outs=1 (0x10/0x0/0x0/0x0/0x0)
[ 65.833518] snd_hda_codec_realtek hdaudioC0D0: mono: mono_out=0x0
[ 65.833520] snd_hda_codec_realtek hdaudioC0D0: inputs:
[ 65.833522] snd_hda_codec_realtek hdaudioC0D0: Mic=0x14
[ 65.833525] snd_hda_codec_realtek hdaudioC0D0: Line=0x13
[ 65.833527] snd_hda_codec_realtek hdaudioC0D0: Aux=0xf
root#

[Clarity]

Something is amiss OR I have NOT notice this before.

Seeking an explanation
KLV ISO file booting RAM0 in a VM shows up on the desktop one way while booting the same ISO file RAM0 from SG2D shows up differently. Never experienced this before. So, the distro MUST be making some choice for which I am curious why it is behaving this unusual way. What exactly is it trying to do?

Why???

Bare Metal booted desktop

Desktop via SG2D bare-metal_small.png (141.38 KiB) Viewed 1265 times

VM booted desktop

KLV-boot_small.jpg (42.63 KiB) Viewed 1265 times

[fredx181]

@Clarity May have to do with the same as discussed here: viewtopic.php?p=69040#p69040 and posts following up on that subject.
Default should be the "KLV-Airedale" background but depending on what XFCE sees as monitor type, it can change to the 'mouse' background.
You can help investigating this by going in the wallpaper settings (on your SG2D install) and select the default KLV background and after that attach here your '/root/.config/xfce4/xfconf/xfce-perchannel-xml/xfce4-desktop.xml' file (config file for background and more) so we can see what/how exactly.

[Clarity]

Thanks @Fred AND I will do so. But for the developers who do run QEMU here's my stanza
qemu-system-x86_64 -m 2048 -enable-kvm -smp 2 -device AC97 -boot d -cdrom KLV-Airedale-beta24.iso

Should see the same.

And for SG2D booting, RAM0 booted there, too.

[Clarity]

@fredx181 its attached.

[rockedge]

I found a difference between Clarity's XML file and the one I have booted in KLV-Airedale-beta24.
xfce4-desktop.xml line 58:
Clarity's version -> <property name="monitorVGA1" type="empty">

rockedge's version -> <property name="monitorVGA-1" type="empty">

[Clarity]

Yeah, something is creating 2 different behaviors for RAM0,

Here's the VM version

KLV Boot Menu

boot-KLV.jpg (15.93 KiB) Viewed 1186 times

KLV VM desktop

KLV-boot_TINY.jpg (17.12 KiB) Viewed 1178 times

[fredx181]

Thanks @Clarity

@rockedge :

I found a difference between Clarity's XML file and the one I have booted in KLV-Airedale-beta24.
xfce4-desktop.xml line 58:
Clarity's version -> <property name="monitorVGA1" type="empty">

rockedge's version -> <property name="monitorVGA-1" type="empty">

So I guess that in this case of "monitorVGA-1" the wrong (mouse) background shows for you too ?
EDIT: Btw, on Clarity's xml file I see "monitorVGA1" on line 50.

[fredx181]

@rockedge I've modified the xfce4-desktop.xml that @Clarity shared here: viewtopic.php?p=70003#p70003 so that it shows the correct wallpaper (KLV-erie_dusk.jpg) if detected "monitorVGA1".
If you include this in the rootfs, hopefully all options are covered, if not, it's anyway a step forward in the process

xfce4-desktop.xml

(4.41 KiB) Downloaded 38 times

[geo_c]

What's the most sound method to consolidate my upper_changes folders? I have ten numbered upper_changes now, and the system is highly refined.

I've used nicOSutilities in the past to create .sfs files. I'm not sure that's the way to go though.

And I'm curious how upper_changes works when removing and deleting things. Does the most recent upper changes white out things present in the lower layers, so that the system is unnecessarily large? For instance if I downloaded files into /root in earlier changes, and then delete them in later changes, are they actually deleted in the lower changes folders. And if so, would creating an .sfs module clean that up?

Since I'm working with themes and icons, and have a good amount of applications installed, my upper_changes are sitting at 3GB currently. Seems like a good time to restructure if necessary. Not a big deal, but eventually we get to 99, and that's as high as it goes, right?

~geo

[geo_c]

I've installed KLV on three laptops now, and I'm getting the hang of it. I'm thinking my earlier problems with the USB boot may have to do with the executable permissions of initrd being changed in the file copying process. That also seems to be what affected the polkit errors I was getting.

The incremental upper_changes layers are really nice for creating a base system and migrating without being encumbered by moving the latest work done on the source computer. When migrating it's extremely easy to roll back to the most recent clean system.

I've been running my linked theme pack and it's rather a cool addition. I have 115 gtk3/4 themes linked to /root/.themes, a total of 105 xfwm window manager themes sitting in /usr/share/themes and 24 sets of icons linked to /root/.icons.

I believe I'm running beta 20 or beta 21 though. I'm so deep in this current system that I'm kind of banking on being able to boot a newer version into my currently stored upper_changes.

I'm pretty well done assembling the theme pack, which I'm planning on calling tbox. The tbox could be unpacked anywhere, but probably best on the home directory. The question is the install method. It's easy enough for an experienced user to simply drag and drop to link the elements they want, but I plan to include a few scripts.

I'd like it not be rude, so rather than cluttering up the file system with a bunch of links that would need to be removed to uninstall, I'm considering the following approach:

1) rename the system's native /root/.themes directory to /root/.themes-KLV
2) create a new directory named /root/.themes-tbox
3) create a symlink to /root/.themes-tbox named /root/.themes
4) symlink all the system themes in /root/.themes-KLV to /root/.themes-tbox
5) symlink all the themes in the unzipped themes archive to /root/.themes-tbox

All the themes, both previously existing on the system, and the new ones residing wherever the user unzips the tbox archive will be symlinked to /root/.themes-tbox

/root/.themes will be a symlink pointing to /root/.themes-tbox

This way all that is necessary to put the system back to its original state is remove the symlink /root/.themes, the directory /root/.themes-tbox, and then rename the /root/.themes-KLV directory back to /root/.themes. No traces left behind.

~geo

[Phil_54]

I have tried this beta23, but can't detect any difference to beta 20 ( I am basically web browsing and using a couple of apps). Would I see any difference with this debian kernel kit, as a normal user? I did notice boot time was a bit longer. What exactly does changing the kernel do? Sorry for simple basic questions.
Also, will printing become possible? Thanks.

[rockedge]

@Phil_54, There is very little difference between those 2 versions. Really only the kernel version and type changed and that is also very slight.

I am currently working on adding all the tools needed for printer and print management.

[rockedge]

@geo_c I thought of something that should be done and probably will improve boot speeds, Thunar file operations and quiet down those messages you've seen during the boot system start.

Inside all of the incremental numbered /XXupper_changes, the directory /mnt should be empty. So go back in all of the stacked XXupper_changes and delete the contents of /mnt or delete the entire directory. So that only /upper_changes has a /mnt directory with content.

This way no cycles are wasted resolving with the layers merging with duplicate entries for disks and partitions contained in the different layers of XXupper_changes

Also to be checked is /var/cache, those directories should also be empty in the XXupper_changes

[geo_c]

@geo_c I thought of something that should be done and probably will improve boot speeds, Thunar file operations and quiet down those messages you've seen during the boot system start.

Inside all of the incremental numbered /XXupper_changes, the directory /mnt should be empty. So go back in all of the stacked XXupper_changes and delete the contents of /mnt or delete the entire directory. So that only /upper_changes has a /mnt directory with content.

This way no cycles are wasted resolving with the layers merging with duplicate entries for disks and partitions contained in the different layers of XXupper_changes

Also to be checked is /var/cache, those directories should also be empty in the XXupper_changes

That makes sense. And I was asking about creating an sfs from the upper_changes, and last night I finally realized that the tool is included in KLV.

[geo_c]

Inside all of the incremental numbered /XXupper_changes, the directory /mnt should be empty. So go back in all of the stacked XXupper_changes and delete the contents of /mnt or delete the entire directory. So that only /upper_changes has a /mnt directory with content.
Also to be checked is /var/cache, those directories should also be empty in the XXupper_changes

I deleted /mnt in all the upper_changes, I forgot about /var/cache, but I ended up with buggy desktop behavior, so I put it all back with my backup copies, and everything is normal again. The desktop was not changing the text font color based on the background, though it would change with a change of gtk theme, and the font was noticeably fuzzy and degraded when black. Odd, I may have deleted something else, but I won't know unless I try again carefully.

[rockedge]

@geo_c We'll have to look at the overall effects and if there is any benefit to performing these deletion operations. I'll have to generate a series of XXupper_changes and start deleting carefully and see what is happening.

[williams2]

the font was noticeably fuzzy and degraded when black

Complaints of fuzzy fonts are usually about antialiasing.

Turn off antialiasing and also cleartype or equivalent.

antialias.jpg (15.8 KiB) Viewed 1189 times

[geo_c]

KLV is giving me an education in what I don't know about mounting.

I keep one line mounting scripts in /mnt that generally look like this

Code: Select all

mount /dev/sdb2 /mnt/sdb2

They are handy. Navigate to /mnt, click the script, open the folder, it's all there.

But, KLV has been displaying all my drives other than home in /run/media/root by their label.

so I poked around /dev to figure out what's going on. Void seems to number the device as expected, sdb1, mmcblk0p1, etc... but then it hides those from the /mnt directory and shows it by label mounted in /run/media/root.

Fine, so I adjusted my script to:

Code: Select all

mount /dev/disk/by-label/bigbox /mnt/run/media/root/bigbox

thinking that might do it, but at that point /mnt/run/media/root/bigbox doesn't exist yet.

so I created a folder in mnt called sdb2 and tried this approach:

Code: Select all

mount /dev/disk-by-label/bigbox /mnt/sdb2

and that successfully mounted it in /mnt/sdb2

But
'bigbox' disappeared from the desktop, and from thunar in 'devices,' and it appears as expected in /mnt/sdb2 until unmounted where it pops back up on the desktop and in thunar.

So I seem to be caught in a loop.

I guess the question is, what's the order to mount from command line and keep KLV seeing things consistently like it does from the desktop mounting mechanism?