I downloaded the autoconf-2.69 from http://ftp.gnu.org/gnu/autoconf and I ran the "autoheader".
After that I copied "AC_CONFIG_HEADER(config.h)" to "configure.in" after the "AC_INIT" line. Ran "autoconf" than again ran "autoheader" and "./configure".
The "configure.h" is generated by it does not give me information about my Unix system.
Am I doing something wrong here?
How can I get information about my Unix system, "Are datalink socket structure are supported?", "Does socket address structure have len field or not?"
Edit: as requested output of uname -a
Linux ubuntu 3.13.0-35-generic #62-Ubuntu SMP Fri Aug 15 01:58:42 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
Related
uname -a tells the "kernel version" is 3.10.0
[root#iZbp16uggk8lf3x949ewxiZ ~]# cat /etc/redhat-release
CentOS Linux release 7.6.1810 (Core)
[root#iZbp16uggk8lf3x949ewxiZ ~]# uname -a
Linux iZbp16uggk8lf3x949ewxiZ 3.10.0-957.21.3.el7.x86_64 #1 SMP Tue Jun 18 16:35:19 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
LINUX_VERSION_CODE also says current kernel version is 3.10.0
[root#iZbp16uggk8lf3x949ewxiZ ~]# grep -rni "LINUX_VERSION_CODE" /usr/include/
/usr/include/linux/version.h:1:#define LINUX_VERSION_CODE 199168
But When I find a kernel function tcp_rtx_synack exist
[root#iZbp16uggk8lf3x949ewxiZ ~]# cat /proc/kallsyms | grep tcp_rtx_synack
ffffffff952a0700 t tcp_rtx_synack.part.26
ffffffff952a0730 T tcp_rtx_synack
ffffffff95721f90 r __ksymtab_tcp_rtx_synack
ffffffff95739e78 r __kcrctab_tcp_rtx_synack
ffffffff95765c36 r __kstrtab_tcp_rtx_synack
3.17 https://elixir.bootlin.com/linux/v3.17/A/ident/tcp_rtx_synack func tcp_rtx_synack exist
3.16 https://elixir.bootlin.com/linux/v3.17/A/ident/tcp_rtx_synack func tcp_rtx_synack not exist
Which means my centos kernel version is at least 3.17 not 3.10
I'm writting the eBPF which need more exact kernel version info because function and data struct are different from each kernel version.
I have buy two VMs on different Cloud provisioner and both VMs show like above.
CentOS, like RHEL, contains backports of various patches (features, fixes, etc.) to older kernel versions. So you can't rely on the kernel version to know which features or functions are available.
Instead, you can either probe for the available features from userspace (e.g., with bpftool feature probe) or use CO-RE to detect it with BTF.
I met a problem when I tried to use IVSHMEM.
Below is the configuration from my side:
vm xml configuration for IVSHMEM device:
<shmem name='ivshmem'>
<model type='ivshmem-plain'/>
<size unit='M'>2</size>
<address type='pci' domain='0x0000' bus='0x00' slot='0x10' function='0x0'/>
</shmem>
after the booting up and I found the qemu commandline ideedly have the device option:
ps aux | grep ivshmem
/usr/bin/qemu-system-x86_64
.......(ignore other options)
-object memory-backend-file,id=shmmem-shmem0,mem-path=/dev/shm/hostmem,size=4194304,share=yes -device ivshmem-plain,id=shmem0,memdev=shmmem-shmem0,bus=pcie.0,addr=0x10
lspci command not shown the device.
lshw command indeedly show the device:
*-memory UNCLAIMED
description: RAM memory
product: Inter-VM shared memory
vendor: Red Hat, Inc.
physical id: 10
bus info: pci#0000:00:10.0
version: 01
width: 64 bits
clock: 33MHz (30.3ns)
configuration: latency=0
resources: memory:fcc1c000-fcc1c0ff memory:fdc00000-fdffffff
My host os and gust vm os is ubuntu 20.04 and version is:
uname -a
5.8.0-43-generic #49~20.04.1-Ubuntu SMP Fri Feb 5 09:57:56 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux
Anything input on this one?
You first need to load the generic driver:
modprobe uio_pci_generic
Then you will see the PCI device.
Afterwards you can load your own kernel module by using
insmod uio_ivshmem.ko
Note that you probably need to build the module first.
Sharing below the output of my server info.
[root#HBAPIPUATAP13 mongodb-linux-x86_64-enterprise-rhel70-4.0.1]# uname -a
Linux HBAPIPUATAP13 3.10.0-862.14.4.el7.x86_64 #1 SMP Fri Sep 21 09:07:21 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
[root#HBAPIPUATAP13 mongodb-linux-x86_64-enterprise-rhel70-4.0.1]# cat /etc/redhat-release
Red Hat Enterprise Linux Server release 7.2 (Maipo)
The below packages need to be installed before starting mongod process.
yum install cyrus-sasl cyrus-sasl-gssapi cyrus-sasl-plain krb5-libs libcurl libpcap lm_sensors-libs net-snmp net-snmp-agent-libs openldap openssl rpm-libs tcp_wrappers-libs
Ref: https://docs.mongodb.com/manual/tutorial/install-mongodb-enterprise-on-red-hat/
I am using Ubuntu 16.0.4 LTS running linux kernel 4.4.0 series.
I made some changes to the i2c-ocores code and eeprom driver and built the whole kernel afresh. Then I installed the newly built kernel.
I used the following steps to build the kernel:
1. sudo apt-get source linux-image-$(uname -r)
2. Applied my changes to i2c-ocores and eeprom driver
3. sudo chmod a+x debian/scripts/*
4. sudo chmod a+x debian/scripts/misc/*
5. sudo fakeroot debian/rules clean
6. sudo fakeroot debian/rules editconfigs
a. Checked all the options for i2c driver
7. sudo fakeroot debian/rules binary-headers binary-generic skipabi=true skipmodule=true
8. Installed all the .deb packages created by the build.
After installing new kernel, I rebooted the machine and inserted i2c-ocores and eeprom drivers and they worked fine. But after like four or five reboots, my insertion for these drivers fails. I am using modprobe to insert the modules.
Like for i2c-ocores, I get the following errors:
Aug 18 11:08:14 manik kernel: [ 214.831678] i2c_ocores: disagrees about version of symbol i2c_new_device
Aug 18 11:08:14 manik kernel: [ 214.831682] i2c_ocores: Unknown symbol i2c_new_device (err -22)
Aug 18 11:08:14 manik kernel: [ 214.831700] i2c_ocores: disagrees about version of symbol i2c_del_adapter
Aug 18 11:08:14 manik kernel: [ 214.831701] i2c_ocores: Unknown symbol i2c_del_adapter (err -22)
Aug 18 11:08:14 manik kernel: [ 214.831708] i2c_ocores: disagrees about version of symbol i2c_add_adapter
Aug 18 11:08:14 manik kernel: [ 214.831709] i2c_ocores: Unknown symbol i2c_add_adapter (err -22)
does anyone have any idea what is happening here ? Am I doing something wrong ?
There really isn't enough information in the question to give a definite answer, but I believe I might know the problem.
You are rebuilding an Ubuntu kernel, but not changing the version number. As a result, you are, effectively, overwriting the kernel that came with the system. Somewhere in the process, it is possible that you are getting a mismatch between the kernel you are using and the modules you are trying to load (i.e. - you are getting the vanilla kernel and your custom modules or vice-versa). When that happens, the errors you are seeing might come up.
My best advice for you is to change the appended revision of the kernel to something that contains your name before building. At the very least, that will allow you to see which versions are involved by simply running uname -r.
A few asides:
People offered you to build just the modules. That won't work for two reasons. First, you are replacing existing modules, which means you run the risk that exactly what I think happened would happen. More to the point, however, you say you change the kernel's config. You cannot do that when you build just the modules out of tree.
You are running sudo fakeroot. sudo is a tool that makes your commands run as root. fakeroot is a command that fakes the root environment when the real one isn't available. It makes no sense to run both. As far as I can tell, your best bet is to build with fakeroot and install with sudo.
I was running MongoDB v2.0.4.
I installed v2.2.2 and restarted.
The mongod process is running fine. Client applications are connecting and functioning fine.
But the mongo shell bombs out.
$: ~ mongo localhost/da
MongoDB shell version: 2.2.2
connecting to: localhost/da
Illegal instruction
$: ~
My "install" process was to download & unpack the .tgz and simlink all the binaries in bin to /usr/local/bin.
Here's what I see in the log on start.
Thu Jan 3 16:14:54 Mongo DB : starting : pid = 7225 port = 27017 dbpath = /var/lib/mongodb/ master = 0 slave = 0 32-bit
** NOTE: when using MongoDB 32 bit, you are limited to about 2 gigabytes of data
** see http://blog.mongodb.org/post/137788967/32-bit-limitations for more
Thu Jan 3 16:14:54 db version v1.2.2, pdfile version 4.5
Thu Jan 3 16:14:54 git version: nogitversion
Thu Jan 3 16:14:54 sys info: Linux vernadsky 2.6.24-27-server #1 SMP Fri Mar 12 01:45:06 UTC 2010 i686 BOOST_LIB_VERSION=1_40
Thu Jan 3 16:14:54 waiting for connections on port 27017
This is running on a 32bit machine w/ 4GB memory and dual core PIII 1.4GHz processor.
Thinking this could be the 'floating point exception' mentioned on the MongoDB downloads page I tried the legacy-static build. The result is the same.
UPDATE
I think the limitations of running on an older 32 bit system make running v2.2.2 too unstable. The 2GB limit is easily exceeded (as evidenced by 'Got signal: 4' errors) when doing a repair operation or checking journal files on start up.
I've decided to revert to v1.2.2 using the Ubuntu package manager.
References:
https://jira.mongodb.org/browse/SERVER-5639
https://groups.google.com/d/topic/mongodb-user/gaAlONRvVSU/discussion
I had the same problem on Debian Squeeze 6.0.10 , an old 32-bit/i386 machine and with the 10gen distribution of the official mongodb instructions. On the instalation some problems with --configure of mongo-org-server and dependencies Trying to execute mongod "Illegal instruction" and
I had to purge the packages and install the 1.4.4 version through a simple apt-get install mongodb.