I am trying to "make" and load the "/drivers/md/raid0.ko" module into my linux kernel but I am getting this error.
# modprobe raid0 --force-vermagic
modprobe: ERROR: could not insert 'raid0': Exec format error
dmesg
[Dec 2 15:10] raid0: version magic '5.0.0 SMP mod_unload ' should be '5.0.0-36-generic SMP mod_unload '
My kernel version is
# uname -a
Linux ubuntu1 5.0.0-36-generic #39-Ubuntu SMP Tue Nov 12 09:46:06 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
and the code from which I am trying to load is taken from the link https://mirrors.edge.kernel.org/pub/linux/kernel/v5.x/linux-5.0.tar.xz
Hence the version in that is 5.0.0, without the EXTRAVERSION -36
I have tried a number of things but failed.
Setting the EXTRAVERSION using command make EXTRAVERSION=-1 modules_prepare, before building the module
Using the --force-vermagic while loading the kernel, but it fails.
Copying the Makefile firectly from /usr/lib/modules/$(uname -r)/build/Makefile before building the kernel.
I have used both make SUBDIRS=drivers/md modules and make M=drivers/md for building, but same result for both.
Need help!
force modprobe to ignore the magic str
use --force-vermagic optin
Every module contains a small string containing important information,
such as the kernel and compiler versions. If a module fails to load
and the kernel complains that the "version magic" doesn't match, you
can use this option to remove it. Naturally, this check is there for
your protection, so this using option is dangerous. This applies to
any modules inserted: both the module (or alias) on the command line
and any modules on which it
in this case modprob ignore magic str
Related
I am trying to build my custom kernel module. it is compling successfully but while inserting module it is giving me error
insmod: init_module 'helloworld.ko' failed (Exec format error)
And dmesg Log shows:
version magic '3.10.0+ mod_unload ARMv7 p2v8 ' should be '3.10.0 SMP preempt mod_unload ARMv7 p2v8 '
How can I add "SMP" & "preempt" in version magic ?
Check whether CONFIG_PREEMPT and CONFIG_SMP is enabled in the kernel config of the kernel which you are using to compile your kernel module. Enable it in your kernel and then recompile your module using this config.
I want to run swi-prolog program on the machine (actually a server) where there is no prolog installed.
The prolog code swipl_test.pl:
main :- write('Hello, world\n').
On the local machine 4.4.0-64-generic #85~14.04.1-Ubuntu SMP Mon Feb 20 12:10:54 UTC 2017 x86_64 x86_64 x86_64 GNU/Linux making the binary hello with SWI-Prolog version 7.2.3 for amd64:
swipl --goal=main --toplevel=halt --stand_alone=true --foreign=save -o hello1 -c swipl_test.pl
Moving hello on the remote machine 2.6.32-5-amd64 #1 SMP Wed Jun 17 16:09:06 UTC 2015 x86_64 GNU/Linux gives the following error:
error while loading shared libraries: libswipl.so.7.2: cannot open shared object file: No such file or directory
How I can prepare a self-contained binary from a prolog code?
I do not have sudo rights on the remote machine.
I had the same problem and i could solve it looking for the shared libraries necessary for the execution of my program. You can find these libraries by executing the ldd command. Once you have them, you can distribute them in the same directory as your executable and set the LD_LIBRARY_PATH variable so that the executable can find them.
This happens because, as clarified in the documentation, when using the option --stand_alone = true the executable becomes a copy of swipl with the saved state and, if SWI-Prolog is statically linked (by default in Linux/386) and the state does not use external packages, there will be no problems to run the program on another machine. Otherwise (our case) the shared objects must be made available so that the executable can find them. In Linux, these shared objects are found using ldd (in your case, the library libswipl.so.7.2). Therefore, you should look for this library (by default in /usr/lib) and copy it to the directory of your executable to distribute it with it. Then, in the machine where you are going to run the program, you must set the LD_LIBRARY_PATH variable so that the executable knows where to find those libraries that it needs to run, that is, the same directory where it is, or use chrpath(1) to change the address where the executable will search.
It is became available and possible to install swi prolog as:
pkg install swi-prolog
This will fix it
I am trying to boot a custom kernel on Xeon-phi instead of the default Linux kernel. At this link, I found a way to cross compile my kernel which compiles successfully using k1om-mpss-linux-gcc cross compiler. Is cross compiling enough ? I get the error
mykernel.img is not a k1om Linux bzImage
Edit:
So, I used /usr/linux-k1om-4.7/bin/x86_64-k1om-linux-gcc compiler to compile a simple helloworld.c program and the kernel source. I get two different types of results for objdump -f on the executables.
for helloworld.c:
hello: file format elf64-k1om
architecture: k1om, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000000000400400
for mykernel:
mykernel: file format elf32-i386
architecture: i386, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0010000c
I compiled using the same compiler, yet they show different architectures. What is the reason for this ?
The first thing to do is figure out what mykernel.img is. Try running file on it.
$ file /opt/mpss/3.4/sysroots/k1om-mpss-linux/boot/vmlinux-2.6.38.8+mpss3.4
/opt/mpss/3.4/sysroots/k1om-mpss-linux/boot/vmlinux-2.6.38.8+mpss3.4: ELF 64-bit LSB executable, version 1 (SYSV), statically linked, BuildID[sha1]=0xa4c16ee85c11aca4e78dc4ae46d3827fb74289c1, not stripped
$ objdump -f /opt/mpss/3.4/sysroots/k1om-mpss-linux/boot/vmlinux-2.6.38.8+mpss3.4
/opt/mpss/3.4/sysroots/k1om-mpss-linux/boot/vmlinux-2.6.38.8+mpss3.4: file format elf64-k1om
architecture: k1om, flags 0x00000112:
EXEC_P, HAS_SYMS, D_PAGED
start address 0x0000000001000000
The answer to your original question - no, unfortunately, it is not as simple as just cross-compiling. There were a number of changes made to the kernel that comes with the MPSS. I don't know all the changes but a big one that I do know is that they had to add support for the larger register set on the coprocessor in order to be able to save state on a context switch.
As to why the file format is elf32-i386 instead of elf32-k1om -
The web site you referenced referred to recompiling the kernel that came with the MPSS after possibly make a few changes in the files. You'll notice that they also copied over a configuration file for the installed version of the kernel. So they had all the files to remake the kernel exactly as it had been made.
I suspect that, in your case, either a) there was a configuration script of some sort in your source directory that picked up the architecture you were running on and caused confusion when the makefile ran or b) your makefile had no idea what k1om was. In either case, it fell back to what it believed to the the lowest common denominator i386. As I say, this is just a suspicion on my part but a careful reading of your makefiles should lead to the answer.
out of sheer curiosity I tried compiling a 2.6.0 kernel on my slackware machine.
root#darkstar:/home/linux-2.6.0# uname -a
Linux darkstar 2.6.37.6-smp #2 SMP Sat Apr 9 23:39:07 CDT 2011 i686 Intel(R) Core(TM)2 Duo CPU P8600 # 2.40GHz GenuineIntel GNU/Linux
When I try compiling I get :-
root#darkstar:/home/linux-2.6.0# make menuconfig
HOSTCC scripts/fixdep
scripts/fixdep.c: In function 'traps':
scripts/fixdep.c:359:2: warning: dereferencing type-punned pointer will break strict-aliasing rules
scripts/fixdep.c:361:4: warning: dereferencing type-punned pointer will break strict-aliasing rules
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/mconf.o
scripts/kconfig/mconf.c:91:21: error: static declaration of 'current_menu' follows non-static declaration
scripts/kconfig/lkc.h:63:21: note: previous declaration of 'current_menu' was here
make[1]: *** [scripts/kconfig/mconf.o] Error 1
make: *** [menuconfig] Error 2
Some hints on what im doing wrong? Thanks!
How are you doing this to start with?
Typically, you download the latest kernel from kernel.org, copy the tarball to /usr/src, then:
1. tar -zxvvf linux-2.6.xxxx.tar.gz
2. ln -nsf linux-2.6.xxxx linux # ie: Update the "/usr/src/linux" symbolic link to
# point to the new kernel source directory
3. make menuconfig # or make xconfig
4. make modules # Build the kernel modules
5. make modules_install # Install the previously built modules for the
# new kernel
6. make bzImage # Create the boot image
At this point, DO NOT run make install. Most guides say to do this, but this is WRONG! Instead, copy the newly created bzImage file to /boot (ie: find -name bzImage /usr/src/linux, then cp to /boot), then edit your LILO configuration file (edit /etc/lilo.conf, and when done, run lilo), then reboot your system (ie: init 6 or shutdown -r now), and try out the new kernel.
The whole point of skipping the make install step is because it overwrites/replaces your existing kernel. The steps I described above allow you to have the new kernel and your existing kernel both installed and runnable in parallel. If the new kernel is broken or your left out an important option, you can still fall back to your existing stable/working kernel without the need for a boot/recovery CD/DVD.
If I recall well i think you are missing the ncurses libraries. Those are needed to create the interface with menuconfig.
Try a to do a make xconfig from an X session and see if it works.
if that is the case then the ncurses libs are definitely missing.
check with:
ls /var/log/packages/ncurses*
to see if installed
I am trying to create binding for a C library using Cgo. I have package which uses Cgo to import the library and make some calls to it. It compiles and installs fine. But when trying to use that package from a Go program, I get the the error "unexpected R_X86_64_64 relocation for dynamic symbol" when linking.
Any ideas?
It appears in the assembly generation routines in the 6g compiler:
case 256 + R_X86_64_64:
if(targ->dynimpname != nil && !targ->dynexport)
diag("unexpected R_X86_64_64 relocation for dynamic symbol %s",
targ->name);
r->type = D_ADDR;
return;
The R_X86_64_64 is a type of a symbol in the library. For more information about relocation in the amd64 architecture consult page ~70 here.
Is it possible that you mix 386 compiled library with amd64 code?
The compiler should report the exact symbol which caused the problem. Can you try linking with a minimal library containing other symbols, and try to locate a minimal example where it fails?
Did you manage to use cgo with any library at all?
I agree with Elazar that it seems plausible that mixing of 32-bit and 64-bit code is involved.
Have you tried gccgo?
Works like a charm :
root#Ubuntu-1304-raring-64-minimal:/etc# uname -a
Linux Ubuntu-1304-raring-64-minimal 3.8.13.4 #2 SMP Mon Jul 8 23:59:05 CEST 2013 x86_64 x86_64 x86_64 GNU/Linux
do this sequence :
cd /usr/local
mkdir /var/go
apt-get install mercurial
hg clone https://code.google.com/p/go/
After that create a /etc/profile.d/go.sh with the follewing contents and make it executable:
export GOPATH=/var/go
export GOROOT=/usr/local/go
export GOBIN=$GOPATH/bin
export PATH=$PATH:$GOBIN
export GOROOT_FINAL=/var/go
export GOHOSTARCH=amd64
export GOARCH=amd64
export CGO_ENABLED=1
And then restart your shell. NO source xxx will be working properly - be warned! In a new shell do this :
cd /usr/local/go/src
./make.bash
do the thing, and then copy all the things from /usr/local/go to /var/go - or there's a way to merge both directories by symlink, whatever you prefer. After that comment GOROOT_FINAL in go.sh script above AND restart your shell again. And you're ok with latest working Go language!
root#Ubuntu-1304-raring-64-minimal:/usr/work/golang/go/src# go version
go version devel +35d5bae6aac8 Fri Oct 18 10:45:19 2013 +0400 linux/amd64
Note bene : Two shell restarts are required - found it myself in a hard way.