Debian kernel for KLV-Airedale

[fredx181]

Update 2022-11-07, bug fix, filter out 'linux-image-....' .deb from 'experimental' branch, script replaced below

cr-debkernel.gz

Updated 2022-11-02 Remove fake .gz and make executable

(8.95 KiB) Downloaded 61 times

----------------------------------------------------------------------------------------
Update 2022-11-02, script replaced below, added ntfs3 to the kernel modules to be copied to the initrd, thanks @wiak see: https://forum.puppylinux.com/viewtopic. ... 211#p71211
Here's a script that will download, extract Debian latest "linux-image" .deb package (currently v6.0.0-1) and create a setup for KLV-Airedale, including initrd.gz and 00modules-... .sfs.
Remove fake .gz extension and make executable.
EDIT 2022-10-21, some improvements and important fix,
- check for if required 'ar' is installed (if not, install 'binutils'), for extracting .deb package
- better way to check if depmod is symlink to kmod (should not be symlinked to busybox) (the script should work on a "non usr-merged" system too now).
- changed the trap 'exitfn' cleanup function very important !! as there was a risk of deleting the whole directory (standing in) when interrupting the script at some point, fixed now.

Usage: Copy the script to some directory of choice (on a Linux filesystem), open a terminal there and type ./cr-debkernel
Takes a few minutes and the files can be found in workdir-<date> .
To swap the kernel in a KLV install with these created Debian kernel files, copy these to the KLV frugal install dir and overwrite initrd.gz and vmlinuz.

Required is the "full" depmod (not symlink to busybox), the script checks for that, if it gives the message "it seems that depmod is a symlink to busybox", then install 'kmod' : xbps-install kmod .

On top of script you can modify RT=no to RT=yes if the Debian realtime kernel is preferred.
Also modify INITCOMPR=gzip to INITCOMPR=xz for a much smaller initrd.gz (xz compressed).

[rockedge]

@fredx181 The script is excellent! It is exactly what we need. The KLV type kernels are a great practice in building kernels but for going forward for KLV-Airedale it would be advantageous to use these script built Debian kernels.

The configurations are solid and touchscreens work plus the MATOX graphic card has it's drivers loaded and my xfce4-screensaver stopped segmentation faulting the Xorg server.

I am about to run the script twice. Once for a real time kernel option. Then outfit beta24 with this newly acquired kernel.

So far both the kernel you shared and the artifact version created by woof-CE are working very well in KLV-Airedale

@wiak meanwhile in the background I'll keep comparing the configurations of kernel build options to eventually make a KLV custom kernel. But I think we can move with solid foundations forward using Fred's script and derive a kernel using it to supply KLV-Airedale with a solid performing kernel.

[fredx181]

Ok, sounds good, thanks for testing !

It would be great IMO to give the user choice of kernel to use by offering a few setups on your index site and perhaps give some info about it and how to swap the kernel

[wiak]

Ok, sounds good, thanks for testing !

It would be great IMO to give the user choice of kernel to use by offering a few setups on your index site and perhaps give some info about it and how to swap the kernel

Absolutely excellent Fred. Trying it now and all working well on my computer (audio output and record - sof stuff all fine).

Yes, choice of kernels would be good if could be arranged somehow.

One question @fredx181: works with previous firmware sfs, but I imagine firmware can sometimes break if compiled with different kernel - or is that not the case? Bound to be a need for newish firmware anyway so has to be taken into consideration?

[rockedge]

works with previous firmware sfs, but I imagine firmware can sometimes break if compiled with different kernel - or is that not the case?

I recently have run a KLV with a 6.0.1 kernel and 5.16.14 firmware sfs. I have just built 6.0.0 and 6.0.1 so I am using the firmware from 6.0.0 that the kernel-kit put together with the 6.0.0 Debian kernel and module sfs built by @fredx181's script.

So far it does seem that there is some leeway when it comes to the module SFS version that can be used. But I am very pleased with the performance and efficiency with this kernel

Right now KLV-Airedale-beta24 is running better than it ever has with this kernel. The PowerEdge R210 II is doing stuff I didn't know it could do

[wiak]

I'm also currently using this Debian kernel combination in my current under dev test builds of FR arch64. Going really well and without issues.

[fredx181]

Thanks, glad to hear that it works well.

One question @fredx181: works with previous firmware sfs, but I imagine firmware can sometimes break if compiled with different kernel - or is that not the case?

I don't know that, but seems that @rockedge has solution :

I have just built 6.0.0 and 6.0.1 so I am using the firmware from 6.0.0 that the kernel-kit put together with the 6.0.0 Debian kernel and module sfs built by @fredx181's script

If I understand well, you have to compile a kernel and it would be just for the firmware then ?
(one of the advantages of my script can be that it will save you the trouble of having to compile a kernel, but probably you are very fluent with that, I have little experience with kernel building)

[fredx181]

Replaced the script, has some improvements and important fix, download and info at first post

[bigpup]

What I understand about firmware.

The firmware is not dependent on the kernel.
Any firmware can be used with any kernel.
It has to be the firmware for the hardware, you are trying to operate.
Manufactures usually provide this firmware.
A firmware package, is a bunch of different firmware, for all the hardware, that most likely will be found, in the computer.
The package will be the firmware, that was available, when it was produced.
A new device comes out and the firmware for it, is made available.
It's firmware, will be in a newer firmware package.

The kernel will need to have the driver for the specific hardware.
That is kernel specific.
Most kernel builds have the needed driver in the kernel.
If needed driver is not in the kernel.
You have to compile it for, that specific kernel, and add it into the operating system, where it will be found and used.

So, usually the kernel provides the needed driver.
The operating system, usually has a firmware package, that provides the needed firmware.

Example:
A very new kernel is compiled with drivers for some very, very, new hardware.
To go along with providing support for this very, very, new hardware.
A firmware package, containing firmware for this very, very new hardware, is also needed to update the firmware, that is in the operating system.
All the older hardware, is already supported, by older drivers in the kernel, and firmware already in the operating system.
.

Screenshot.jpg (18.84 KiB) Viewed 1103 times

[dimkr]

The firmware is not dependent on the kernel.

That's true but only most of the time. Some drivers (including iwlwifi) need a specific version of the firmware. In some cases, the linux-firmware repo contains multiple firmware versions for the same hardware, because older kernels have an old driver that uses version x, while the newer driver in newer kernels uses version x+1 of the firmware.

kernel-kit trims the selection of firmware based on firmware actually requested by the drivers of the kernel you're building. Sometimes, the cut-down selection of firmware for a kernel built by kernel-kit omits firmware needed by kernels of a different version, or kernels of the same version but built with more drivers: if you mix mix and match kernels and firmware SFSs, it's very likely that some hardware won't work.

[fredx181]

Script cr-debkernel updated, see first post , added ntfs3 kernel module to be copied to the initrd.

[fredx181]

cr-debkernel updated, see first post
bug fix, now will filter out 'linux-image-....' .deb from 'experimental' branch