I'm trying to build a simple kernel module and run it on the Raspberry Pi. I have downloaded kernel sources from official raspberry site, but they have slightly different kernel version then my raspbian on board.
Is it necessary to have fully identical version of kernel on source and target machine to run kernel module? I have this on my Raspberry Pi
$ uname -a
Linux raspberrypi 4.4.11+ #888 Mon May 23 20:02:58 BST 2016 armv6l GNU/Linux
And this about my module
$ modinfo ./threads.ko
filename: /lib/modules/4.4.11+/kernel/mymodules/./threads.ko
version: 0.0.1
description: Kernel threads example
author: xxxxxx
license: GPL
srcversion: C906582EC824D2D8DA76BFB
depends:
vermagic: 4.4.13+ mod_unload modversions ARMv6
As you see: "4.4.11+" vs "4.4.13+"...
Why am I asking? I have a error when insert module:
$ sudo insmod ./threads.ko
insmod: ERROR: could not insert module ./threads.ko: Invalid module format
And do not understand, it is valuable difference in last number of version of the kernel or there is another problem.
Is it necessary to have fully identical version of kernel on source and target machine to run kernel module?
Yes.
Related
I'm trying to compile the Elmer FEM software on Raspberry Pi OS (AFIK formerly known as Raspbian). Following these instructions:
sudo apt install cmake gfortran libopenblas-dev libqt4-dev libqwt-dev
inside the build directory cmake .. -DWITH_OpenMP:BOOLEAN=TRUE -DWITH_MPI:BOOLEAN=FALSE -DWITH_ELMERGUI:BOOLEAN=TRUE
make -j3
sudo make install
I managed to compile the software with no errors (... load of warnings though!). Now heading towards /usr/local/bin and running ./ElmerGUI the software icon appears for a minute or two and then disappears with no prompt or errors, showing just a Killed message in the terminal:
Given that there is no error messages I have no clue what is going wrong leading to the abrupt termination of the software. I would appreciate if you could help me know what is the problem and how I can resolve it.
My environment:
Hardware: Raspberry Pi 3 Model B Rev 1.2
Operating system: Linux raspberrypi 5.4.51-v7+ ... armv7l GNU/Linux
P.S. Following this comment on Discord, I did grep -r "Killed" . in the project folder, which returned no results. I'm almost certain the Killed message is from the OS itself.
I want to check the use of the pthread_mutex_lock function, so I execute the command man pthread_mutex_lock, the result appears No manual entry for pthread_mutex_lock.
I checked the information on the Internet and said that there was a No manual entry for pthread_mutex_lock prompt, need to install manpages-posix-dev.
So I'm ready to install manpages-posix-dev（I execute the command: apt-get install manpages-posix-dev）, but E: Unable to locate package manpages-posix-dev prompts me again. Why?I'm using the debian 10 system.
gyz#debian:~$ man pthread_mutex_lock
No manual entry for pthread_mutex_lock
gyz#debian:~$ sudo apt-get install manpages-posix-dev
Reading package lists... Done
Building dependency tree
Reading state information... Done
E: Unable to locate package manpages-posix-dev
gyz#debian:~$ lsb_release -a
No LSB modules are available.
Distributor ID: Debian
Description: Debian GNU/Linux 10 (buster)
Release: 10
Codename: buster
gyz#debian:~$ getconf LONG_BIT
64
gyz#debian:~$ cat /proc/version
Linux version 4.19.0-9-amd64 (debian-kernel#lists.debian.org) (gcc version 8.3.0 (Debian 8.3.0-6)) #1
SMP Debian 4.19.118-2+deb10u1 (2020-06-07)
(Even though the question is tagged Debian it appears in generic search results)
The answer for Fedora is that Fedora has removed posix manpages entirely; you need to download/install 'manually' (there's a make installer included in the archive) from https://www.kernel.org/pub/linux/docs/man-pages/man-pages-posix/
(Thanks to redditors)
I'm trying to run the ManualExamples of the latest Pin tool from Intel (3.7-97619) on Kali 32-bit (Linux kali32 4.19.0-kali4-686-pae #1 SMP Debian 4.19.28-2kali1 (2019-03-18) i686 GNU/Linux).
I could compile the examples found in source/tools/ManualExamples using make TARGET=ia32, but as soon as I run an example with the command ../../../pin -t obj-ia32/isampling.so -- /bin/ls from the ManualExamples as suggested in the documentation. Nonetheless, I face the following issue:
A: Source/pin/elfio/img_elf.cpp: ProcessSectionHeaders: 560: assertion failed: SEC_vaddr_i(sec) >= IMG_seg_text_vaddr_i(img) && SEC_vaddr_i(sec) < IMG_seg_data_vaddr_i(img)
################################################################################
## STACK TRACE
################################################################################
??? at isampling.so+0x24472
??? at isampling.so+0x90946
??? at isampling.so+0x98671
??? at isampling.so+0x14654d
??? at isampling.so+0x148b9d
??? at isampling.so+0x148c50
??? at isampling.so+0x6f243
??? at isampling.so+0x4bfab
_ZN14LEVEL_INJECTOR13UNIX_INJECTEE12StartProgramEb+0x10f at /root/pin/ia32/bin/pinbin+0x3354af
??? at isampling.so+0x48889
main+0x97 at isampling.so+0x90d7
_ZN14LEVEL_INJECTOR13UNIX_INJECTEE9StartToolEv+0x1d2 at /root/pin/ia32/bin/pinbin+0x333f12
_ZN14LEVEL_INJECTOR13UNIX_INJECTEE29RunMainThreadOnPinStackAttachEPS0_+0x3de at /root/pin/ia32/bin/pinbin+0x3374ee
Pin: pin-3.7-97619-0d0c92f4f
Copyright (c) 2003-2018, Intel Corporation. All rights reserved.
Aborted
So, I decided to run pin without any tool using the command pin -- /bin/ls and it works. Any idea why I get this error message ?
Many thanks
After some hours lost in the investigation of this issue with a colleague, we could not figure out the reason of this error. We tried on Kali and Debian that were up to date.
Later on, I decided to try on a old Ubuntu virtual machine with the kernel 4.15.0-47-generic and it worked! More precisely:
➜ ~ uname -a
Linux gpu 4.15.0-47-generic #50-Ubuntu SMP Wed Mar 13 10:44:52 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
➜ ~ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description: Ubuntu 18.04.1 LTS
Release: 18.04
Codename: bionic
I did not try on a newer version of Ubuntu, so I cannot state this is due to a new software component, such as a newer version of the kernel. My workaround is therefore to use an older version of the kernel, without having the certainty this is what caused the issue.
Any further investigation answer on this thread that would identify the issue better will be marked as the answer.
I currently try to build a Debian package for the armhf (ARMv7) architecture, but I want the build script to recognize the architecture itself. The problem is, that I can not find the architecture, that APT uses to retrieve the package from a repository.
In my case, APT uses armhf, when it retrieves packages.
When I run uname -m, I get armv7 as a result. A grep -rn armhf /etc does not show any appearance of armhf, relevant for APT to choose from.
So, where can I get (Debian 9 (Stretch) or Armbian next) a reliable source for that information from the system that is independent of the architecture (my script should run also on i686, amd64, armel & arm64)?
The answer is
dpkg --print-architecture
This gives you the architecture Debian is selecting for packages. I'm not sure what happens on multi-architecture systems (i686 and amd64), but this can be separated quite easily.
I'm going through a course on gdb. In the later lessons the course covers debugging on ARM architecture, so I'm presented a setup that allows me to emulate such situation.
My current setup comprises:
Windows 10: physical host
Ubuntu 12.04.5 LTS: guest os via Oracle Virtual Box on Windows 10
Linux debian-armel 2.6.32-5-versatile: guest os via qemu 2.8.0 on Ubuntu
The ARM Debian image comes from https://people.debian.org/~aurel32/qemu/armel/
The image is launched with
qemu-system-arm -M versatilepb -kernel vmlinuz-2.6.32-5-versatile -initrd initrd.img-2.6.32-5-versatile -hda debian_squeeze_armel_standard.qcow2 -append "root=/dev/sda1" -m 256 -redir tcp:2222::22
I modified the sources.list and apt.conf to allow apt to work, since the distro is quite outdated. I updated and upgraded and installed gcc and gdb.
The problem arises when trying to debug; I can load executables in gdb:
root#debian-armel:~/video-11/video-11# file ./main
./main: ELF 32-bit LSB executable, ARM, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.18, not stripped
but when I try to run it inside gdb, I receive this message and the execution hangs, until I'm able to kill the gdb process from another console:
------------[ cut here ]------------
WARNING: at /build/linux-2.6-fIxTVd/linux-2.6-2.6.32/debian/build/source_armel_none/kernel/sched.c:2628 wake_up_process+0x2c/0x48()
Modules linked in: loop sg smc91x sr_mod mii cdrom psmouse evdev ext3 jbd mbcache sd_mod crc_t10dif sym53c8xx scsi_transport_spi scsi_mod
[<c002b068>] (unwind_backtrace+0x0/0xdc) from [<c0046f88>] (warn_slowpath_common+0x4c/0x80)
[<c0046f88>] (warn_slowpath_common+0x4c/0x80) from [<c00446f0>] (wake_up_process+0x2c/0x48)
[<c00446f0>] (wake_up_process+0x2c/0x48) from [<c0026930>] (arch_ptrace+0x214/0x4bc)
[<c0026930>] (arch_ptrace+0x214/0x4bc) from [<c00508d8>] (sys_ptrace+0x9c/0x164)
[<c00508d8>] (sys_ptrace+0x9c/0x164) from [<c0024ec0>] (ret_fast_syscall+0x0/0x28)
---[ end trace 98ab50bc781b314f ]---
How can I resolve this issue?
Not my answer, but to enable the question to be marked as closed:
This is likely a bug in the guest kernel (though not certainly so), so
I would start by trying with a more recent kernel than 2.6.32, which
is now nearly 8 years old. – Peter Maydell Mar 3 '17 at 13:14