The system is CentOS 6.3.
I've compile a new kernel and the resulting rpm installed on a target machine.
When booting from the kernel I've receive the error in a title of the question.
I've extracted corresponding initramfs and compared output of:
modprobe --dump-modversions /path/to/scsi_wait_scan.ko
with entries in corresponding /boot/symvers-*. All symbols checksums fit, including of module_layout.
Is there a way to extract symvers from kernel itself?
I've found the problem.
Short answer
The problem was that I installed kernel rpm (B) over already installed kernel rpm (A),
without removing it first.
Detaild answer
scsi_mod.ko was owned only by (A). While installing (B), scsi_mod.ko was in /lib/modules/.
When intramfs was created in (B)'s postinstall script. depmod decided that scsi_wait_scan.ko depends on scsi_mod.ko, while both build against different configurations.
Later when booting the machine, kernel started run initramfs. This in turn modprob'ed scsi_wait_scan.ko. modprobe tried loaded as a consiquence scsi_mod.ko, which is not appropriate to the current kernel, thus resulting to error I saw.
Related
1. What I am trying to achieve:
Build a custom kernel so I can install and run Anbox-git from AUR on my Arch laptop. Custom kernel is needed for the package to work.
2. What I did to achieve it:
Download Arch Linux kernel v5.8.5-arch1 from here
I followed the guidelines on tradional compilation Arch wiki to create the custom kernel
Via make nconfig I applied the changes mentioned in the Anbox Arch wiki page.
Via make nconfig I changed EFIVAR_FS option from "M" to "*" to resolve an error from earlier attemps.
Via make nconfig under Location: -> Device Drivers-> Multiple devices driver support (RAID and LVM) (MD [=y])-> Device mapper support (BLK_DEV_DM [=y]) I added a few more options (*) because on earlier builds mkinitpcio gave errors for missing modules for DM_CRYPT, and some more DM_ modules which I cannot easily reproduce (will do if necessary for the answer, but I hope it'll be irrelevant).
After creating the config this way I did:
sudo make modules_install
sudo cp -v arch/x86_64/boot/bzImage /boot/vmlinuz-linux58ac
sudo cp /etc/mkinitcpio.d/linux.preset /etc/mkinitcpio.d/linux58ac.preset
Adapted the preset file per Arch wiki instructions
sudo mkinitcpio -p linux58ac
Important: The mkinitpcio runs fine, but keeps giving me a warning:
WARNING: No modules were added to the image. This is probably not what
you want.
sudo grub-mkconfig -o /boot/grub/grub.cfg
3. Expected result:
I am able to reboot, select the new kernel from grub menu, get the usual LVM password prompt, and launch into it without problems.
4. Result I get:
I can reboot and select new kernel from grub but when I select it I get a
Warning: /lib/modules/5.8.5-arch1/modules.devname not found, ignoring.
Starting version 246.4-1-arch
ERROR device 'dev/mapper/vg0-root' not found. Skipping fsck.
mount /new_root: special device /dev/mapper/vg0-root does not exist.
You are being dropped into an emergy shell.
I checked and the /lib/modules/5.8.5-arch1/modules.devnamedoes indeed exist. But I think the actual problem is that mkinitcpio doesn't load the correct modules into the custom kernel, causing it to become unbootable.
Any help appreciated!
I have an out-of-tree Linux kernel module that I need to compile. When I execute "make" in the kernel module directory I am getting:
"fatal error: stdarg.h: No such file or directory"
Before starting the build I installed the header file based on my Linux distribution.
$sudo apt-get install kernel-headers-$(uname -r)
How can I solve this compilation error? (my distribution is Ubuntu 16.04 with linux-headers-4.15.0-42-generic)
I ran a search of stdarg.h with the "locate" command to see if I can sport the file on the system.
I got:
/usr/include/c++/5/tr1/stdarg.h
/usr/lib/gcc/i686-linux-gnu/5/include/cross-stdarg.h
/usr/lib/gcc/i686-linux-gnu/5/include/stdarg.h
...
It tells me there is at least one stdarg.h provided by the compiler.
I tried to include the path "/usr/lib/gcc/i686-linux-gnu/5/include" in the kernel module Makefile so stdarg.h can be picked up. It did not work (while building, another reference to stdarg.h in the official kernel header was not being resolved).
I finally created a symlink directly under:
/usr/src/linux-headers-4.15.0-42-generic/include
$sudo ln -s /usr/lib/gcc/i686-linux-gnu/5/include/stdarg.h stdarg.h
This was just enough to solve the compilation issue.
I am wondering if the kernel headers should come with an implementation of stdarg.h by default (that is the first time I encounter this issue). I have also read that the compiler provide one implementation and most of the time it is better to use the compiler version.
Updated note: if the above solution still does not solve the problem:
Before running make again, do a make clean. Do a ls -la in the folder and look for a ".cache.mk" file. If this is still there, remove it and run "make" again. It should solve the problem.
I had the same issue with CentOS 9, and the other answers didn't work for me. Apparently the problem is that in more recent kernels, it shouldn't be <stdarg.h> but <linux/stdarg.h>. With virtualbox guest additions 6.1.34, it correctly checks for kernel with a version of 5.15.0 or more. But my kernel is the 5.14.xx, meaning the include for stdarg.h is wrong.
Solving the issue
Dependencies
Install all the dependencies for the guest edition
gcc make perl kernel-devel kernel-headers bzip2 dkms
Installation
Run the Guest Addition installation like you would normally. It will fail by saying it is unable to compile the kernel modules. That's expected. It will copy all the file we need to the VM disk.
Editing
We now need to edit the erroneous files.
/opt/VBoxGuestAdditions-6.1.34/src/vboxguest-6.1.34/vboxguest/include/iprt/stdarg.h
/opt/VBoxGuestAdditions-6.1.34/src/vboxguest-6.1.34/vboxsf/include/iprt/stdarg.h
On line 48 (may change for different versions), it check for a version of Linux and select the correct header depending on the version. We need to replace if RTLNX_VER_MIN(5,15,0) with if RTLNX_VER_MIN(5,14,0) in both files.
Compile the kernel modules
We can now compile the kernel modules, and the error should be gone.
sudo rcvboxadd quicksetup all
I personally got an error the first time, but then I recompiled without changing anything and it worked.
Remember that it's just a workaround, it may not work with different versions.
If you using Arch Linux with zen-kernel:
sudo CPATH=/usr/src/linux-zen/include/linux vmware-modconfig --console --install-all
I had the same problem with VirtualBox 6.1.0 running archlinux with kernel 6.1.9.
I downloaded VirtualBoxGuestAdditions_7.2.0.iso file from https://download.virtualbox.org/virtualbox/7.0.2/ link(you may select more appropriate to your VirtualBox version) and assigned as an optical drive to virtualbox machine. After start of the system running blkid command on terminal showed the name of CD rom device which was /dev/sr0. then I created iso folder on
/mnt folder
mkdir /mnt/iso
and mounted cd drive to that folder
mount -o loop /dev/sr0 /mnt/iso
after I cd'ed to /mnt/iso
cd /mnt/iso
and manually run VirtualBoxGuestAdditions.run script
sh ./VirtualBoxGuestAdditions.run
which successfully compiled and istalled required virtualbox guest modules.
Now everytime I update kernel version I redo the same procedure. And it work fine.
It also remove old 6.1.0 guest additons folder.
Currently I'm experimenting with the Cell/BE CPU under Linux. What I'm trying to do is running simulations in the near future, e.g. about the weather or black holes.
Problem is, Linux only discovers the main CPU of the Cell (the PPE), all other SPUs (7 should be available to Linux) are "sleeping". They just don't work out of the box.
What works is the PPE and it's recognized as a two-threaded CPU with one core by the OS. Also, the SPEs are shown at every boot (with small penguins showing a red "PPE" in them), but afterwards are shown nowhere.
Is it possible to "free" these specialised cores for use by the Linux OS? If so, how?
As noone seems to be interested or can answer this question I'll provide the details myself.
In fact there exists a workaround:
First, create an entry point for the SPUFS:
# sudo mkdir /spu
Create a mount point for the filesystem so you won’t have to manually mount after a reboot. Add this line to /etc/fstab
spufs /spu spufs defaults 0 0
Now reboot and test to make sure the SPUFS is mounted (in a terminal):
spu-top
You should see the 7 SPEs running with 0% load average.
Now Google for the following package to get the runtime library and headers you need for SPE development:
libspe2-2.3.0.135.tar.gz
You should find it on the first hit. Just unpack, build, and install it:
./configure
make
sudo make install
You can ignore the build warnings (or fix them if you have obsessive compulsive disorder).
You can use pkg-config to find the location of the runtime and headers though they are in /usr/local if I recall.
You of course need the gcc-spe compiler and the rest of the PPU and SPU toolchains but those you can install with apt-get as they are in the repos.
Source: comment by Exillis via redribbongnulinux.000webhostapp.com
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 want to make some modifications in the kvm module in my Linux kernel. For this, I did the following:
Obtained the Kernel sources:
apt-get source linux-image-source-$(uname-r)
Modified a function in the file emulate.c - changed some variables and added a printk statement.
Built the kernel:
fakeroot debian/rules clean
fakeroot debian/rules binary-headers binary generic
Installed the packages produced as a result of building:
sudo dpkg -i linux*(version)*.deb
Rebooted the system.
Executed QEMU with kvm enabled.
However the changes I made, didn't seem to reflect when I try to test them in QEMU. Neither did the printk statement execute when I checked with dmesg.
Can anyone please point out which part I am getting wrong?
Installing a new kernel wont necessarily make it boot into it, you may need to change the default in your boot loader. (e.g. grub)
You can check whether the kernel you just compiled and installed is the same as what you booted with using:
cat /proc/version
If this is not as expected, then you need to tweak your Grub config and/or reboot and manually choose the correct kernel.
Having established the correct kernel, you may need to change the level of which messages are reported by the kernel (via dmesg)
This is controlled by a kernel proc file. You can see what the current values are by printing this file:
cat /proc/sys/kernel/printk
Example output:
4 4 1 7
The first argument - messages with severity < 4 (i.e. 0, 1 2 or 3) will be recorded.
The second argument - messages with no specified severity default to 4 and thus not seen by the system in the above example.
So the following will change the log so that all kernel messages are seen:
echo 8 > /proc/sys/kernel/printk
See (for example) http://www.makelinux.net/books/lkd2/ch18lev1sec3 for further information.