LinuxQuestions.org
Review your favorite Linux distribution.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM
User Name
Password
Slackware - ARM This forum is for the discussion of Slackware ARM.

Notices


Reply
  Search this Thread
Old 08-13-2019, 10:13 PM   #1
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 212

Rep: Reputation: 33
Installing out-of-tree kernel modules with SARPi


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?
 
Old 08-14-2019, 03:02 AM   #2
Exaga
Member
 
Registered: Nov 2012
Posts: 176

Rep: Reputation: 88
Quote:
Originally Posted by elyk View Post
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.

Last edited by Exaga; 08-14-2019 at 03:24 AM. Reason: because more coffee
 
Old 08-22-2019, 11:49 PM   #3
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 212

Original Poster
Rep: Reputation: 33
Quote:
Originally Posted by Exaga View Post
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.
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.

Quote:
Originally Posted by Exaga View Post
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?
Basically the files that `make mrproper` would delete but `make clean` wouldn't. From /usr/src/linux/Makefile:

Code:
###
# Cleaning is done on three levels.
# make clean     Delete most generated files
#                Leave enough to build external modules
# make mrproper  Delete the current configuration, and all generated files
# make distclean Remove editor backup files, patch leftover files and the like

# Directories & files removed with 'make clean'
CLEAN_DIRS  += $(MODVERDIR) include/ksym

# Directories & files removed with 'make mrproper'
MRPROPER_DIRS  += include/config usr/include include/generated          \
                  arch/*/include/generated .tmp_objdiff
MRPROPER_FILES += .config .config.old .version \
                  Module.symvers tags TAGS cscope* GPATH GTAGS GRTAGS GSYMS \
                  signing_key.pem signing_key.priv signing_key.x509     \
                  x509.genkey extra_certificates signing_key.x509.keyid \
                  signing_key.x509.signer vmlinux-gdb.py
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...

Quote:
Originally Posted by Exaga View Post
If you have a '/lib/modules/4.19.65-armv7' directory on your system I'm interested in how that came about.
My guess is something in MRPROPER_DIRS or MRPROPER_FILES. I tried replacing .config but that wasn't enough to get a working module.
 
Old 08-23-2019, 01:25 AM   #4
drmozes
Slackware Contributor
 
Registered: Apr 2008
Location: Surrey, England
Distribution: Slackware
Posts: 841

Rep: Reputation: 633Reputation: 633Reputation: 633Reputation: 633Reputation: 633Reputation: 633
Quote:
Originally Posted by elyk View Post
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...
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:
Code:
( cd lib/modules/4.19.66-v7-arm ; rm -rf build )
( cd lib/modules/4.19.66-v7-arm ; ln -sf /usr/src/linux-1.2.3_sarpi build )
( cd lib/modules/4.19.66-v7-arm ; rm -rf source )
( cd lib/modules/4.19.66-v7-arm ; ln -sf /usr/src/linux-1.2.3_sarpi source )
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:
Code:
# Start with a wild guess
rootdev='mmcblk0p3'
if [ -L dev/root ]; then
  rootdev=/dev/$(readlink dev/root)
...
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:
Code:
df --output=source / | egrep '^/'
/dev/sda2
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.

Last edited by drmozes; 08-23-2019 at 02:44 AM.
 
1 members found this post helpful.
Old 08-23-2019, 03:11 PM   #5
abga
Senior Member
 
Registered: Jul 2017
Location: EU
Distribution: Slackware
Posts: 1,025

Rep: Reputation: 536Reputation: 536Reputation: 536Reputation: 536Reputation: 536Reputation: 536
@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
 
Old 08-23-2019, 03:12 PM   #6
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 264

Rep: Reputation: 74
Quote:
Originally Posted by elyk View Post
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...
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?
 
Old Yesterday, 12:40 PM   #7
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 264

Rep: Reputation: 74
Quote:
Originally Posted by drmozes View Post
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:
Code:
df --output=source / | egrep '^/'
/dev/sda2
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.
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.

Last edited by Penthux; Yesterday at 01:57 PM. Reason: n00b-esque retaliation
 
Old Yesterday, 01:07 PM   #8
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 212

Original Poster
Rep: Reputation: 33
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.
 
Old Yesterday, 01:53 PM   #9
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 264

Rep: Reputation: 74
Quote:
Originally Posted by elyk View Post
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.

Last edited by Penthux; Yesterday at 03:37 PM. Reason: config.txt.new
 
Old Yesterday, 02:29 PM   #10
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 212

Original Poster
Rep: Reputation: 33
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.
 
Old Yesterday, 02:53 PM   #11
elyk
Member
 
Registered: Jun 2004
Distribution: Slackware
Posts: 212

Original Poster
Rep: Reputation: 33
Quote:
Originally Posted by drmozes View Post
Post installation, when the OS is running, you could determine the root filesystem like this:
Code:
df --output=source / | egrep '^/'
/dev/sda2
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:

Code:
# findmnt --target=/ --output=SOURCE --noheadings
/dev/mmcblk0p2
 
Old Yesterday, 04:25 PM   #12
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 264

Rep: Reputation: 74
Quote:
Originally Posted by elyk View Post
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.
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.
 
Old Yesterday, 04:52 PM   #13
Penthux
Member
 
Registered: Dec 2008
Location: Middlesbrough, UK
Distribution: Slackware
Posts: 264

Rep: Reputation: 74
Quote:
Originally Posted by elyk View Post
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:

Code:
# findmnt --target=/ --output=SOURCE --noheadings
/dev/mmcblk0p2
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.
 
Old Yesterday, 07:10 PM   #14
glorsplitz
Member
 
Registered: Dec 2002
Distribution: slackware!
Posts: 754

Rep: Reputation: 162Reputation: 162
Quote:
Originally Posted by Penthux View Post
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.
 
  


Reply


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
[SOLVED] SARPi out of space in /boot elyk Slackware - ARM 7 08-14-2019 01:16 AM
[SOLVED] Slackware 14.2 Install mkinitrd ERROR: No /lib/modules/4.4.14-smp kernel modules tree found for kernel " 4.4.14-smp" laxware Slackware 4 01-04-2019 12:40 PM
SARPi website new URL - sarpi.co.uk Exaga Slackware - ARM 4 01-28-2018 06:36 PM
SARPi installer and packages using kernel 4.9.61 Exaga Slackware - ARM 1 11-19-2017 02:10 AM

LinuxQuestions.org > Forums > Linux Forums > Linux - Distributions > Slackware > Slackware - ARM

All times are GMT -5. The time now is 08:40 AM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Facebook: linuxquestions Google+: linuxquestions
Open Source Consulting | Domain Registration