I have some trouble getting this particular kernel patch to compile correctly with my Ubuntu Linux kernel.
The patch in question comes from a piece of software called SCST it a iSCSI target for Linux. The patch loads fine when I run patch -p1 < put_page_callback-2.6.32.patch but when I got to compile I get about an hour in or so and then make fails and returns these errors.
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:63: error: redefinition of '__kcrctab_net_get_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:14: note: previous definition of '__kcrctab_net_get_page_callback' was here
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:63: error: redefinition of '__kstrtab_net_get_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:14: note: previous definition of '__kstrtab_net_get_page_callback' was here
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:63: error: redefinition of '__ksymtab_net_get_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:14: note: previous definition of '__ksymtab_net_get_page_callback' was here
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:66: error: redefinition of '__kcrctab_net_put_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:17: note: previous definition of '__kcrctab_net_put_page_callback' was here
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:66: error: redefinition of '__kstrtab_net_put_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:17: note: previous definition of '__kstrtab_net_put_page_callback' was here
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:66: error: redefinition of '__ksymtab_net_put_page_callback'
/root/d1/development/kernel/lucid/source/net/ipv4/tcp_zero_copy.c:17: note: previous definition of '__ksymtab_net_put_page_callback' was here
and I have absolutley no idea what is going on. I am not a kernel dev by any means, I am just trying to get this patch and another one which works fine scst_exec_req_fifo-2.6.32.patch. So I can make this iSCSI target run at full speed.
Any idea what I can do?
** UPDATE **
I am following the insructions from https://help.ubuntu.com/community/Kernel/Compile. More specificly a link on that page that goes to http://blog.avirtualhome.com/2010/05/05/how-to-compile-a-ubuntu-lucid-kernel/.
I have already done a few compiles using these instructions, my problems were either I forgot to apply the patches or the patch did not take, but up until now they always completed. Something with this new patch messed something up.
As far as why the iSCSI target is messing with the network parts, it apperantly has something to do with the network performance. When I compile the target software without the patch it whines about the performance wont be good. The website for the target is http://scst.sourceforge.net/index.html
You should follow the standard kernel compilation method after getting yourself an appropriate kernel version from kernel.org
Here are the steps in order
Extract kernel to a folder
Apply patch
sudo make menuconfig, save default .config file
sudo make
sudo make modules_install
sudo make install
cd /boot
sudo mkinitramfs -o initrd.img-(your version here) (your version again)
sudo update-grub
You should now see the new kernel in your boot options and it should (hopefully) boot.
Related
I want to use the writeprotect mode of the userfaultfd feature, but it is implemented only from Linux 5.11.
I have ubuntu 20 with kernel 5.4 so I installed version 5.11 of Linux from sources, but when I reboot on the installed version, and try to use the writeprotect mode in a c user program the macros (e.g., UFFDIO_WRITEPROTECT) still appear not to be defined. And I verified that userfaultfd is not a module (doing lsmod).
In the other hand, if I make a modification for example in the scheduler just for a test (let's say in kernel/sched/core.c:context_switch) the modification are taken into account because this is in-core, but modifications for user space are not, I'm confused.
The userfaultfd.c file is in the fs/ directory of the kernel.
So please is it something that I'm missing in the compilation process (make menuconfig, make, make modules_install, make) ?
I was wrongly interpreting the error I had.
The modifications are indeed taken into account when I boot on the newly compiled kernel.
But while searching an understanding of what happens when booting on a compiled kernel, I got this:
When booting on a kernel compiled from sources, the libraries in /usr/include are not modified on the disk
If you want to overwrite them by the one modified, you should do this:
make deb-pkg //from the kernel sources directory
cd ..
sudo dpkg -i *.deb
This will install the new kernel and overwrite the headers
I have some older utilities that are only sometimes needed and it came time to use a particular one and I found it didn't work. I know that some of the other utilities in the same package were working, but rather than worry about why this one was unique, I figured it just needed a recompile on the most recent Fedora and so I ran make.
I then learned that it couldn't find cc1. So the first thing I did was: dnf update gcc
This upgraded some 11 packages but didn't cure the cc1 problem, so I did which gcc to find where that is, then made a soft link to the cc1 program in the same directory. The compile then proceeded until a / the final linking, which should be:
gcc -o run${BINTYPE} run.o hashc.o
'run' here is the utility name. But the compile returns:
gcc: fatal error: ‘-fuse-linker-plugin’, but liblto_plugin.so not found
compilation terminated.
I then did a web search and found a few stack-overflow entries, such as this one, (and a handful of non-stack-overflow pages, too) but none matched or provided a working solution.
I then found where liblto_plugin.so actually is:
/usr/lib64/bfd-plugins/liblto_plugin.so
...and checked LD_LIBRARY_PATH - the location wasn't in there, so I added it as the first entry (/usr/lib64/bfd-plugins/). That didn't work - same error.
And, I also tried going to where this distribution of Fedora seems to want to find it - which is /usr/libexec/gcc/x86_64-redhat-linux/ - and then making a soft link there, too, but that didn't work either.
OK, this should be simple, but I'm stumped!
It might be worth noting that from what I understand, this plugin is about optimizing dynamic linking at runtime, and that's simply not involved for this utility. All this program does is validate an environment before running to ensure it doesn't even try to launch unless certain conditions are met, so static linking should work fine. So maybe a workaround is to simply provide a flag that says skip the plug-ins? I'd rather "fix it correctly," but I'll settle for it doing what I need to do right now.
UPDATE
As suggested by Knud Larsen in comments, I did a re-installation of gcc and nothing changed. And, it appears the ‘-fuse-linker-plugin’ isn't even rquired these days, Great! But, there's no flag calling for its use, so it seems to be automatic; how do I turn this thing off?!
I also meet this question when install something with cargo.
note: cc: fatal error: '-fuse-linker-plugin', but liblto_plugin.so not found
compilation terminated.
Finally, I found the reason. I created the hard link cc of gcc by mistake. It should have been a soft link. It will be fine after changing it.
I'm trying to install Qemu in Ubuntu 18.04 but I guess there is a problem with the Makefile.
./configure runs fine, but when i try to 'make' it, it exits with an error:
contrib/elf2dmp/download.c:9:10: fatal error: curl/curl.h: Arquivo ou diretório inexistente
#include <curl/curl.h>
^~~~~~~~~~~~~
compilation terminated.
/home/usr/Programas/qemu-4.1.0-rc1/rules.mak:69: recipe for target 'contrib/elf2dmp/download.o' failed
I would gladly accept some help to solve this, since I cannot figure it out. Thanks!
The compiler is looking for a system header file (provided by the libcurl library) which isn't present on your system. For Ubuntu 18.04 this should be in the libcurl4-gnutls-dev package, so if you install that and then do a 'make clean' and then repeat configure and make it ought to build OK.
In theory configure should have noticed that you don't have the curl library dev package installed and just disabled the parts of QEMU that require it. I suspect this is an upstream bug. I haven't been able to reproduce your setup, but I have a good guess about what the problem is, and I think this patch to QEMU should fix it:
https://patchew.org/QEMU/20190719100955.17180-1-peter.maydell#linaro.org/ -- so if you could test that that would be helpful.
NB: If your /etc/apt/sources.list has the correct deb-src lines in it, then you can use "apt build-dep qemu" to install all the -dev packages that would be needed to build the official Ubuntu QEMU. This might help you to avoid surprises in future where it turns out that the QEMU you've compiled yourself is missing some optional functionality because a -dev package wasn't present at compile time.
I know that on the internet I can find same information about "adding one driver to linux kernel" but I can not get it working.
I need to compile an ADV7800driver. It is based on adv7180 driver code.
I put my driver file (adv7800.c) into /linux_source_folder/drivers/media/platform/mxc/capture folder. I also add
adv7800_converter-objs := adv7800.o
obj-$(CONFIG_MXC_ADV7800_CONVERTER)+=adv7800_converter.o
in makefile in the same folder and add information in Kconfigfile.
Then I go back to /linux_source_folder and do sudo make menuconfig and set adv7800 as a module and save config. Then sudo make defconfig, then sudo make -j4 modules (now waiting about 2 hours) and then sudo make modules install.
As a result I can see every module which I configure in menuconfig but I can not see my own module (only .c file exists).
How can I do this correctly and how can I build only this one module without building others (to same much time) ?
I do not remember exactly what happens in terms of instructions executed, but the idea of defconfig is to set a default configuration for a given architecture/platform.
If, as you said, you run sudo make defconfig after you configure your module to be compiled, most likely you loose your configuration. The defconfig should be executed first (once) and then you customize the configuration.
Regarding the compilation of a single module, I point you to an old answer
How to "make" existing Linux kernel module driver after modifying the driver source code.
One note: you should not use sudo to compile
I am trying to build my software using cygwin-x86(32 bit version) on Windows-7.
Cygwin-x64(64 bit) works perfectly fine on the same machine. I want to build 32-bit executable.
Whenever I try cygwin-x86, I get the following errors:
[main] make 7780 child_info_fork::abort:
C:\cygwin\bin\cygiconv-2.dll: Loaded to different address:
parent(0x440000) != child(0x5F0000) make: fork: Resource temporarily
unavailable
I have checked this thread Cygwin Error
I have already tried everything mentioned in there, but I still continue to face the same issue.
Whenever i try /usr/bin/rebaseall -v or cd /usr/bin && ./rebaseall -v as mentioned in the step 7 of the accepted answer in the above mentioned thread, I get this error:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygvtv_stubs-0.dll: skipped
because wrong machine type.
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll: skipped because wrong
machine type. Segmentation fault (core dumped)
I get this wrong machine type error for a lot of other .dll's as well.
As mentioned earlier I have cygwin-64 installed on my machine & working as expected. But while running rebaseall it is somehow looking for x86-64-pc-cygwin instead of 32 bit version.
The thread is obsolete.
run /usr/bin/rebase-trigger, close all cygwin processes and run again setup-x86.exe. Also without installing anything will execute a rebase for you.
You can also specify the option full.
Additional note:
The most likely cause of fork problems on 32 bit system are too many programs and libraries installed.
for example:
/usr/x86_64-pc-cygwin/sys-root/usr/bin/cygz.dll
belongs to cygwin64-zlib a cross library for building cygwin64 programs from cygwin32. Do you really need it ? If not, as I suspect, remove all cywgin64 packages .
The problem can also be triggered by an anti-virus program. (I saw it happening with Avast.) You can test if this is the cause by disabling it.
Could also be caused by this update
https://support.microsoft.com/en-us/help/4561616/windows-10-update-kb4561616
You can also kill each of the latest process of ash, dash or bash that was forked, setup.exe will simply skip this script and continue with the rest.
I had to kill about 10-20 of them, mostly in latex postinstall scripts.
For me, the solution was to remove the .new file extention of the libs from c:\cygwin64\bin\
I had the same problem using git. various dlls depending on the git command used where included in the error message stating that it was loaded to "different adress".
In fact a corporate antivirus or a loaded program had probably prevent un update during the rebase phase while installing a new program (git-svn in my case)
some required libraries where not installed but cleverly left in the target with the .new file extention.
I just had to remove the .new extention (and rename the original lib to .old) to solve the problem.
In my case the list of lib involved was:
cygcrypto-1.1.dll
cyggcc_s-seh-1.dll
cygintl-8.dll
cygwin1.dll