I'm trying to install the v4l2loopback kernel module. Quick instructions are to clone that repo, then run `make` and `make install`. This should install /lib/modules/$(uname -r)/extra/v4l2loopback.ko.

Somewhere in the build process it's using the files in /usr/src/linux from the kernel-source package. I currently have version 4.19.65 of both kernel-source and kernel_sarpi3, so it seems like everything should work together just fine. But it doesn't. kernel-source has some files that were generated as part of building kernel_armv7 and those are being used during this kernel module's build process. The file is placed in /lib/modules/4.19.65-armv7 instead of /lib/modules/4.19.65-v7-arm. Trying to insmod it gives an error that it's an "invalid module format".

I think if I had a sarpi kernel-source package (with all the generated files from building the sarpi kernel), then everything would work fine.

What is different about the sarpi kernel vs. the one in Slackware ARM? Is there a way to replace the generated files in the kernel-source package with ones specific to the sarpi kernel?

There's probably a link to /usr/src/linux in your package source-tree or it is referred to in the build process. That's where the build process expects to find the Linux source. You need to tell it where the Linux source is located [if it's not in /usr/src/linux], would be my guess.

You can download the Raspberry Pi Linux Kernel source from https://github.com/raspberrypi/linux - this is the repository which SARPi uses. The generated files from building the kernel can be found in the installer images and packages available from http://sarpi.fatdog.nl/index.php?p=downloads - the SARPi downloads page.

Which files are you referring to that you want to replace in the kernel?

The differences between the kernel(s) that SARPi provides and the ones in Slackware ARM are quite fundamental. Slackware ARM kernels are built from the official Linux Foundation [kernel.org] source. SARPi kernels are built from the Raspberry Pi Foundation's GitHub [unofficial] Linux kernel source. There's one MAJOR difference right there! The SARPi kernel(s) obviously support the Raspberry Pi device. Slackware ARM kernels don't. MoZes builds his kernels the way that suits him and/or to support Slackware ARM and end-users. SARPi builds kernels entirely based on running Slackware ARM on the Raspberry Pi for the end-user. SARPi does not cater for any other device so everything available from the SARPi Project is bespoke in that respect. SARPi kernels are built on the Raspberry Pi device for which they are intended to run to ensure the highest level of compatibility is maintained, and that's not always 100% guaranteed. Slackware ARM kernels are the official kernel releases for the OS. SARPi kernels are not official and include a lot of hacked/patched shizzle that comes with the Raspberry Pi. Slackware ARM kernels are built by the Slackware developers in a professional manner and environment that are ultimately reliable. SARPi kernels are not.

If you have a '/lib/modules/4.19.65-armv7' directory on your system I'm interested in how that came about.

Correct, it's using /lib/modules/$(uname -r)/build, which is a symlink to /usr/src/linux, which has the contents of Slackware ARM's kernel-source package.

Basically the files that `make mrproper` would delete but `make clean` wouldn't. From /usr/src/linux/Makefile:

None of those files are available in your SARPi packages. Now if you had a SARPi-specific kernel-source package to replace the Slackware ARM kernel-source package and all of its generated bits...

My guess is something in MRPROPER_DIRS or MRPROPER_FILES. I tried replacing .config but that wasn't enough to get a working module.

You don't need to replace the Slackware ARM version for this, and I wouldn't recommend that because the OS is built with that Kernel, not the SARPi one.
For your use case, I think an additional SARPi source package would suffice - e.g. "kernel-source_sarpi" that can co-exist with the kernel-source Slackware package. The kernel-source.SlackBuild in the ARM source tree can be a reference for how to build such a package.

The package can unpack into /usr/src/linux-1.2.3_sarpi and the 'kernel-modules-sarpi3' package's 'install/doinst.sh' would look like this:
Since the doinst.sh is generated (I assume) during the kernel-modules-sarpi3 build script, it'll set those versioned symlinks correctly.
This seems the cleanest and proper way to achieve what you need.


As I was looking at this, I unpacked "kernel_sarpi3". In its 'install/doinst.sh' you have:
I'm not sure this guesswork is necessary, but I haven't read the instructions or ever installed it.
For the Slackware installer, the target root file system is known because it's mounted under /var/log/mount (IIRC - it's something like that), and you could make the doinst.sh script automatically determine it, since installpkg doesn't chroot the execution of doinst.sh scripts.

Post installation, when the OS is running, you could determine the root filesystem like this:
The doinst.sh can cater for both execution contexts easily.

You could also supply the root file system location on the Kernel command line by setting it from the boot loader, and reading it from /proc/cmdline. There's the 'root=' parameter set already, but this may not be the final root filesystem if you use LLVM or some other abstraction.

1 members found this post helpful.

@elyk

Some general tips for preparing your environment before attempting the compilation&installation of an out-of-tree kernel module:
- you'll need the exact kernel source tree that was used for compiling your running kernel, untouched and in the state it was after finishing the kernel compilation. Make sure at least the two important files: .config and Module.symvers are available.
- for your running kernel (uname -r) you should have (create it if it's not available!):
/lib/modules/kernel-version/build -> pointing to the kernel source tree that was used for compiling your running kernel /usr/src/linux-kernel-version
- I'd recommend to keep only the source tree for your running kernel available, some modules build scripts might not check what's the running kernel and get confused (low quality of the script) if other kernel source trees are available
- after the module compilation and installation, if the build script doesn't do it, it's recommended to run a "depmod kernel-version"

With respect to Slackware ARM and its officially provided kernel packages, you don't need most of them because they are not supporting the Raspberry Pi board. The only packages that are required, are:
- kernel-headers-kernel-version - header files used by the toolchain and residing in /usr/include/
- kernel-firmware-version - collection of firmware files, residing in /lib/firmware/ (this might be already available from your kernel provider)

If you use a Raspberry Pi board - up to Pi3B(+) and plan to patch modules or install out-of-tree modules, you might want to consider building and maintaining your own kernel, based on the official Raspberry source. If interested, follow the How-To from this post (don't mind the rest of the thread):
https://www.linuxquestions.org/quest...5/#post5959658

The resulting files which are generated from compiling the kernel source are; Image, System.map, and the DTBS. All of which are included in the SARPi shizzle. Or am I on the wrong frequency here?

The guesswork is some of Dave's Collective code in the doinst.sh and it's there because of "if it isn't broken don't fix it" reasons. Never had to question that method in ~7 years. If you think it's wrong then it can be revised but it works and very well.

[EDIT] Correction: it works well, except for those who stuff-up their Slackware ARM system and publicly question/blame SARPi for it.

I wouldn't go as far to say "works very well". On initial install it correctly found /dev/mmcblk0p2 as my root device (probably from its /dev/root or /tag/README check), but on a subsequent upgrade it decided on "mmcblk0p3". It chose the wrong partition, and it's also missing the "/dev/" part. If I had blindly replaced /boot/cmdline.txt with cmdline.txt.new (or didn't know what I was doing) then I would have had problems.

Then fix it. Seriously, I have no issues what-so-ever in installing Slackware ARM on the setups I have here, using SARPi images. I do not know what you're doing or have done to cause the problems which you are experiencing but you seem to be saying there's a fundamental problem with the SARPi installation procedure [or something else?]. If I was getting a few complaints back from people about the same thing then alarm bells would ring. However, it's not the case. There's just you and your 'wrong partition' problem and I have no clue how this happened. I'd like to know why the wrong partition was chosen but information which may lead to the answer is somewhat lacking.

"Works well for everybody except elyk" is what I should have wrote.

Find out what you have broken and why you have broken it. THEN get back to me and throw my work into question!

[EDIT] The config.txt.new file is there FOR A REASON! i.e. it will not blindly overwrite any existing config.txt settings and it's down to YOU [the admin] to decide what YOUR requirements are with regards to any new settings or changes in the config.txt.new file. You are not forced in any way to blindly replace this file, knowingly, unknowingly, or otherwise. You may blindly replace this file [if you so choose] but it will be nothing to do with SARPi when you do it. Although, I suspect any blame for blindly replacing said file will reside with SARPi.

I have never heard of 'cmdline.txt.new' overwriting existing settings. That's for YOU [i.e. the adnin] to decide what to do with. There really shouldn't be any problems overwriting any existing settings unless your cmdline.txt file is customised. - i.e. you have set your root partition as root=/dev/mmcblk0p2 [or some UUID value] and not /dev/mmcblk0p3. SARPi uses the latter and this is reflected in the installation tutorial. Any custom setups or configs are your own responsibility to deal with.

SARPi makes it easy to install Slackware ARM on the Raspberry Pi and after that there's no need what-so-ever for SARPi. I'm finding some people are relying on SARPi as a be-all-solution to save them time and effort updating/upgrading and that's not what SARPi is there for. Nor does it cater for all individual cases running Slackware ARM.

No need to take offense. I'm just pointing out that this code doesn't work if your root partition doesn't live at /dev/mmcblk0p3. I decided to skip creating a swap partition, that is all. It needs a solution something like what drmozes describes.

This gives me /dev/root (I believe this happens when there is no initrd) and /dev/root does not exist. findmnt gives me better results:

Just remember when I write "it works well" and you write "I wouldn't go as far to say 'works very well'." other people will read these statements and assume there's a general issue/fault/problem. Yes there is in your case, and your case alone. Not in general. But you didn't say "In my particular individual subjective-setup experience it's not working for me personally". You made a general statement that 'it doesn't work well'. This thread contains many pointers to suggest that the way SARPi works, or in what it does, is flawed or bugged or detrimental. That's the problem I have with what has been written.

As Mozes suggested, the code he offered might be a more suitable solution. He's not often known to be wrong. So, try it.

Slackware gives you the freedom to setup your system any damned way you please. Plus you can get really funky with it and Slackware doesn't care - it just works. BUT you have to always consider such configurations when installing new software. Ergo, because your root=/dev/mmcblk0p2 then you should be aware for future reference that this is not what's included in the SARPi installation guide and you should make provisions to accomodate this particular setup you have into any further updates or upgrades or package installations which may encroach on your existing system configuration(s).

Installing any Slackware package without considering how it might modify current personal setup/settings is another form of blindy overwriting your cmdline.txt file.

Anyway, I just got fired from SARPi so I've handed in my blick and I'm out of here. Ciao.

Sorry to see you go , we'll keep a light on for you.

I was looking for the same tool as 'rdev' in busybox, but it seemed to involve multiple commands and trawling /dev.
I didn't know of findmnt - thanks!