I'm building the wireless driver from https://www.kernel.org/pub/linux/kernel/projects/backports/stable/v3.10.4/backports-3.10.4-1.tar.bz2 and I get this error message.
I have build-essential and the generic headers installed.. not sure where to go from here. Any help would be appreciated!
ipw2200.c:8259:4: error: implicit declaration of function ‘__list_for_each’ [-Werror=implicit-function-declaration]
__list_for_each(p, &priv->ibss_mac_hash[index]) {
I changed the actual code in that line __list_for_each to list_for_each in 3.13.x which is referred by my linux/list.h
The kernel you are running (or the one you have includes for) is missing __list_for_each macro (AFAICT, last found in 3.10's linux/list.h, missing in 3.11 kernel).
Install 3.10 kernel (and associated headers) from repositories, reboot into it, and reconfigure.
Related
I try to control a Sony Alpha using Python/gphoto2 on a Raspberry PI. I've tried a number of python bindings (python-gphoto2, gphoto2-cffi, ...) but they all fail at the instruction to create a camera object (eg. my_cam = gphoto.Camera()) with the error:
"Could not claim interface 0 (Device or resource busy). Make sure no other program (gvfs-gphoto2-volume-monitor) or kernel module (such as sdc2xx, stv680, spca50x) is using the device and you have read/write access to the device."
We tried to kill background programs, make sure the kernel modules are not running, install the latest versions of the libraries and python packages, ... but could not get rid of the error. Furthermore C code using libgphoto2 works fine so it's not likely that the resource is really busy. We suspect the problem is missing USB libs in the python packages, and have tried to install libusb-dev, ... but it doesn't help.
Any suggestions what else we should try? Thanks.
You mentioned trying python-gphoto2. I'm the author of that package. Assuming you have installed it successfully then I'd try the list-cameras.py example program. It should list any cameras recognised by libgphoto2 that are connected and switched on.
If C programs are working but Python ones aren't you could check that they're using the same versions of libgphoto2. Try ldd on the C program's executable and on one of the python-gphoto2 compiled modules, e.g. /usr/local/lib/python3.5/dist-packages/gphoto2/_camera.cpython-35m-arm-linux-gnueabihf.so.
While working on SNMP, I am not able to execute snmpwalk or snmpset. Then I checked snmpd -H.
I see an error as:
dlopen(/lib/libvcpeLiTapMediationTable.so) failed: /lib/libvcpeLiTapMediationTable.so: undefined symbol: memdup
dlopen(/lib/libvcpeLiTapStreamTable.so) failed: /lib/libvcpeLiTapStreamTable.so: undefined symbol: memdup
I think that my library might not be opening dynamically due to this.
When I load my packages in CentOS as rpms, I have no errors.
But for the same code, when I load my packages in Ubuntu as debian packages, I see this error.
Queries:
Is there any problem with SNMP installation (since it works on CentOS but not on Ubuntu)? Or is something missing in my debian packages?
Please explain the impact of this error on my operations.
Any relevant answers will be helpful as I am new to this.
Thank you.
Your libvcpeLiTapMediationTable.so depends on function memdup(). This is defined on your CentOS and wherever it was built, in either Net-SNMP or one of the libraries it or libvcpeLiTapMediationTable.so links to at run time, but is not defined on your Ubuntu. Consequently, it can't be loaded at won't work.
Net-SNMP defined memdup() in snmplib/tools.c, but this was renamed to netsnmp_memdup() to avoid conflicts with other libraries that might define their own version according to change history. Perhaps you are using two different versions of Net-SNMP between your two distros, one with and one without that change.
I have imx6-quad and Debian Jessie installed on it. Here is the full info about (uname -a):
Linux linaro-alip 4.1.15-g5599520 #1 SMP PREEMPT Sun Jan 8 13:03:20 IST 2017 armv7l GNU/Linux
I'm trying to run tunslip application for CC1350 Launchpad, but there is no kernel module "tun" in my OS. When I run command modprobe tun, I given an error:
modprobe: FATAL: Module tun not found.
At this point, I don't know how to install tun module to my Debian. I even don't know where to start. Is it possible to add tun module to running operation system or should I compile whole kernel from scratch? If I can add kernel module, how could I add to running OS?
Any help is too precious for me.
So, to sum up the discussion in the comments in case someone else will come here with the same problem:
Unfortunately, the precompiled kernel image provided by Variscite here doesn't come with tun support at all. Neither in modules nor compiled into the kernel.
If you want tun support, you will have to compile the kernel in your own. Sources can be found here on github.
Previous Answer:
Since I'm not allowed to comment yet, please take this less as an answer but more as a suggestion where to look for a solution.
What does the following command give you?
cat /boot/config-4.1.15-g5599520 | grep CONFIG_TUN
It should say CONFIG_TUN=m. If it doesn't, it may be that your kernel already supports tun devices.
Have you tried searching for tunmodules in /lib/modules? If not, run
find /lib/modules/ -name '*tun.ko*'
and let us know what it gives you.
as you are building your kernel. there are a couple of methods one is to compile the module separately and to install it on the existing image. The other is to create the tun module along with the kernel and the sdcard image creation will take care of your module.
TO build tun module. use menuconfig from the kernel folder. search for something matching to CONFIG_TUN if its is a module change its value to m. Rebuild and create the sdcard again. This is the easy way.
You can also craete the module separately and then bring the module to your filesystem but that can be more error prone.
I am working on implementing a temp patch (non-persistent) on my system as described here (while waiting for the official distro kernel):
https://bugzilla.redhat.com/show_bug.cgi?id=1384344#c13
I have tested a dirty copy on write script for the intent of testing the resolution of this bug on my system but note that I am getting a semantic error and that this bug is still active on my system:
SuperUser Shell ~/> # stap -g -p 4 fix.stp
semantic error: while resolving probe point: identifier 'syscall' at fix.stp:5:7
source: probe syscall.ptrace { // includes compat ptrace as well
^
semantic error: no match
Pass 2: analysis failed. [man error::pass2]
SuperUser Shell ~/>
With color (if that's your thing):
Reading this article:
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/5/html/SystemTap_Beginners_Guide/errors.html
I see a brief explanation:
semantic error: no match for probe point, while resolving probe point foo
The events / handler function foo could not be resolved
altogether, for a variety of reasons. This error occurs when the
script contains the event kernel.function("blah"), and blah does not
exist. In some cases, the error could also mean the script contains an
invalid kernel file name or source line number.
Questions:
This is essentially stating that the syscall kernel function is not recognized, correct?
Has anyone successfully implemented this temp fix on CentOS 7.x yet?
Thanks for any help
PS: Sorry if this seems somewhat script kiddy-ish (I don't fully understand this hot fix yet).
Yes, I have successfully implemented this temporary mitigation on CentOS 7.
As described in one of the comments on that bugzilla entry, you need to install the both systemtap and the debuginfo for the kernel in order for this mitigation to work.
The commands given are:
yum install systemtap yum-utils
debuginfo-install kernel-$(uname -r)
Based on what you posted, presumably you already have systemtap, but the error you're getting suggests you need the debuginfo packages. The second command above should install the right stuff; you could also get the RPMs by hand from http://debuginfo.centos.org/ (this is what I ended up doing)
By the way, this mitigation using systemtap is not a real fix, it just makes one of the proof of concept programs fail. It is worth doing, but no substitute for a real patched kernel.
I don't understand why Red Hat and CentOS haven't pushed out patched kernel packages yet, Ubuntu and others had their updates out days ago. What's the holdup?
I am trying to install Xen on Centos6.5 based on this tutorial (http://wiki.centos.org/HowTos/Xen/Xen4QuickStart), however after installing xen and running the script to edit the grub.conf, i am not able to boot into the new kernel.
I get an error stating -
invalid magic number: 9090
Error 13: Invalid or unsupported executable format
Can someone help me please?
Current suspicion: http://wiki.centos.org/HowTos/Xen/Xen4QuickStart definitely not a 10 minute install for all platforms???
History: there is a Centos Bug on this: centos.org/print_bug_page.php?bug_id=6503
I repeated a similar process:
(1) Install Centos 6.6 (Centos kernel: 2.6.32-504.el6.x86_84) from DVD1, DVD2 with Install using only the CENTOS Repo
(2) Installed Xen (Xen4CentOS kernel:3.10.56-11.el6.centos.alt.X86_64) Issuing the following commands from the centos command line (as root, warnings from readers accepted as correct from a security standpoint) To abate the security concern, no network connection existed as an offline repo would have been used but was not actually needed for the Centos minimal install.
yum install centos-release-xen
yum install xen
/usr/bin/grub-bootxen.sh
from the Xen/Centos reference: http://wiki.centos.org/HowTos/Xen/Xen4QuickStart
I noticed that the /boot/grub/grub.conf file was non-existent and tried to reboot without it. The reference above suggests it should be there, so I am proposing that your grub.conf file was missing or incorrect because my results were similar:
'invalid magic number: 9090
Error 13: Invalid or unsupported executable format
Press any key to continue...'
So as of now I can reproduce the problem. I will be updating this as I discover what will solve it for my solution, post it with hope it fixes it for yours or others who share similar issues.
I noticed something odd, I was using a Combo USB hub and tried to reboot using the other kernel (2.6) and there were considerable failures which were squawking on the startup screen and it would not permit me to start. When I removed it I could not boot into the 3.10, but only into 2.6.
Ok, a quick find on grub.conf revealed a similar version to that shown on the reference link above in /etc. So I copied the grub.conf from /etc to /boot/grub and rebooted. But I too see similar results. The USB hub is off the system and will not be reattached, so there is something else here that needs review. I'm digging into the grub.conf file at this time...
(update) I see that there is a grub.conf file under /boot/efi/EFI/redhat. Oddly in the Centos 'bug archives' there appears to be a related resolved bug for Centos 7: bugs.centos.org/view.php?id=7242 (cannot post this as a link as my reputation is less than 10, my apologies)
Also, as this relates to magic number here are results for my type of files and magic numbers, but I have done this with vi and have some assumptions here about what I saw, so I am retrying this with the help of the other stackoverflow article which uses file-devel package LibMagic... here are the intermittent results.
File.x86_64 Magic number (if two bytes, just use first 2)
vmlinuz-2.6.32.504.el6.x86_64 /0x8c/0x8e/0x8e/0x8e
vmlinuz-3.10.56-11.el6.centos.alt.x86_64 /0x8c/0x8e/0x8e/0x8e
Note: A search of '9090' on centos.org using the provided search engine for words on the site yielded no response on 12/22/14: #wiki.centos.org/Search
There is no mention of installation problems with SELinux, even though I have set:
SELINUX=disabled
in the /etc/sysconfig/selinux file and
yum uninstall xen
yum install xen
/usr/bin/grub-bootxen.sh
No results, and no new grub file in any of the three locations listed above. /etc /boot or /boot/efi/EFI/redhat.
Comparison of the grub.conf files with other sources, show that it is reasonable. Same for the grub-bootxen.sh file based on what I could decipher from bash.
Changing the timeout in grub.conf (all I found) to 15 and removing the hiddenmenu command by #hiddenmenu, did not eliminate the '9090' error. Using: wiki.xen.org/wiki/RHEL6_Xen4_Tutorial which shows the 'kernel' modifier instead of the 'module' and changing the 'module' in front of the .img file to initrd, did not change the results.
OK. Reload.
1) reinstall minmum Centos
2) disable SE Linux
3) reboot
4) correct ifcfg-eth0 (remove NM and allow boot on startup) and service network restart
5) yum import centos-release-xen (accept import of GPG key)
6) yum install xen
7) investigate what occurs with "grub-install hd0" which produces '9090' error!
Ok, I would have to say that the question was not well defined. It is now well defined and can be posed as a question. I will convert this info and my trials to a reasonable question to see if anyone can assist with pointers...