I'm in the process of rebuilding the Linux kernel for Cent OS 7 to select a different preemption level.
My steps follow:
sudo yum install rpm-build redhat-rpm-config asciidoc hmaccalc perl-ExtUtils-Embed pesign xmlto audit-libs-devel binutils-devel elfutils-devel elfutils-libelf-devel ncurses-devel newt-devel numactl-devel pciutils-devel python-devel zlib-devel gcc patchutils bison make gcc redhat-rpm-config
mkdir -p ~/rpmbuild/{BUILD,BUILDROOT,RPMS,SOURCES,SPECS,SRPMS}
echo '%_topdir %(echo $HOME)/rpmbuild' > ~/.rpmmacros
wget http://vault.centos.org/7.2.1511/updates/Source/SPackages/kernel-3.10.0-327.4.4.el7.src.rpm
rpm -i kernel-3.10.0-327.4.4.el7.src.rpm
cd ~/rpmbuild/SPECS
rpmbuild -bp --target=$(uname -m) kernel.spec
Kernel in BUILD configured and config file copied in SOURCES
rpmbuild -bb --with firmware --without kabichk --without debug --without debug-info --without doc --target=`uname -m` kernel.spec 2> build-err.log | tee build-out.log
rpmbuild -bb --with firmware --without kabichk --without debug --without debug-info --without doc --target=noarch kernel.spec 2> build-err.log | tee build-out.log
(--without kabichk is needed because the new preemption level somehow breaks the current ABI)
The problem is that the package kernel-firmware gets not generated.
Any idea of what is missing ?
There doesn't appear to be a kernel-firmware package in CentOS 7 at all. And a quick search through the kernel spec file confirms that kernel-firmware doesn't appear anywhere in it.
There is a linux-firmware package though.
That package is built by the linux-firmware specfile.
Related
I am trying to install some software that's required glib 2.14
so I installed it with this tutorial: How to upgrade glibc from version 2.12 to 2.14 on CentOS?
the problem is glib 2.14 path is /opt/glibc-2.14/lib/libc.so.6
so when I try to install software using rpm i still getting this error:
error: Failed dependencies:
libc.so.6(GLIBC_2.14)(64bit) is needed by xyz-4.6.6-1.x86_64
libc.so.6(GLIBC_2.15)(64bit) is needed by xyz-4.6.6-1.x86_64
libc.so.6(GLIBC_2.17)(64bit) is needed by xyz-4.6.6-1.x86_64
how can I add the custom path for rpm dependencies?
It would help a bit if you gave us the name of the package you are trying to install. You can't just provide a path, RPM checks if it's got any packages on record that provide these libraries, and there aren't any. Here are a couple methods you could use:
Use --nodeps
If you already know that you have everything that is required, using --nodeps is completely fine IMO.
Create virtual packages for the missing libraries (advanced)
You are missing the following libraries: libc.so.6(GLIBC_2.14)(64bit) libc.so.6(GLIBC_2.15)(64bit) libc.so.6(GLIBC_2.17)(64bit).
Here's an example .spec file to create a virtual package that claims to provide these libraries:
Name: libc-virtual-provides
Provides: libc.so.6(GLIBC_2.14)(64bit)
Provides: libc.so.6(GLIBC_2.15)(64bit)
Provides: libc.so.6(GLIBC_2.17)(64bit)
Version: 1.0
Release: 1
Summary: Virtual package providing libc 2.14, 2.15, 2.17
License: Public domain
%description
Virtual package providing libc 2.14, 2.15, 2.17
%prep
%files
%changelog
To create a virtual package from this SPEC file, first create some directories:
mkdir -p ~/rpmbuild/BUILD ~/rpmbuild/BUILDROOT ~/rpmbuild/RPMS ~/rpmbuild/SOURCES ~/rpmbuild/SPECS ~/rpmbuild/SRPMS
Then copy the SPEC file into ~/rpmbuild/SPECS, and build an RPM:
cp virtual-glibc-provides.spec ~/rpmbuild/SPECS
cd ~/rpmbuild/SPECS
rpmbuild -ba virtual-glibc-provides.spec
You'll get output like this:
Executing(%prep): /bin/sh -e /var/tmp/rpm-tmp.6Jni5u
+ umask 022
+ cd /home/.../rpmbuild/BUILD
+ exit 0
Processing files: glib2.14-virtual-provides-2.14-1.x86_64
Checking for unpackaged file(s): /usr/lib/rpm/check-files /home/.../rpmbuild/BUILDROOT/glib2.14-virtual-provides-2.14-1.x86_64
Wrote: /home/.../rpmbuild/SRPMS/glib2.14-virtual-provides-2.14-1.src.rpm
Wrote: /home/.../rpmbuild/RPMS/x86_64/glib2.14-virtual-provides-2.14-1.x86_64.rpm
Executing(%clean): /bin/sh -e /var/tmp/rpm-tmp.YNj8gP
+ umask 022
+ cd /home/.../rpmbuild/BUILD
+ /bin/rm -rf /home/.../rpmbuild/BUILDROOT/glib2.14-virtual-provides-2.14-1.x86_64
+ exit 0
And you'll have your RPM under /home/.../rpmbuild/RPMS/, which you can then install using rpm -ivh ....rpm. You should then be able to install the other package without any problems.
I'm trying to install a custom driver rpm that I custom built. I have a kickstart file bundled into a RHEL7.2 iso with a %post section. In the %post, I have a yum install of the driver rpm which seems to get installed, but I notice that depmod logs fatal errors when the driver rpm gets installed:
Installing : kmod-xnxx-1.0-1_test.x86_64
depmod: FATAL: could not load 3.10.0-327.el7.x86_64: No such file or directory
warning: %post(kmod-xnxx-1.0-1_test.x86_64) scriptlet failed, exit status 1
Non-fatal POSTIN scriptlet failure in rpm package kmod-xnxx-1.0-1_test.x86_64
Verifying : kmod-xnxx-1.0-1_test.x86_64
Installed :
kmod-xnxx-1.0-1_test.x86_64
Complete!
As the rpm gets installed, it runs a depmod -a and dracut to rebuild the ramdisk. I'm not sure why these errors a re occurring during the anaconda post install? I've confirmed that the same kernel "3.10.0-327.el7.x86_64" is being used during the post so I have no idea why the module doesn't get installed correctly without the "depmod" errors. I recall from the past that the running kernel during the anaconda install has differences with the kernel that actually gets installed. I'm not sure if this is attributed to the issue I'm having with the post. Any suggestions on how to overcome this would be great. Thanks!
Below is the spec file that I'm using to build the kernel driver rpm(kmod) against kernel 3.10.0-327.el7.x86_64:
%define build_kernel 3.10.0-327.el7.x86_64
%define current_kernel %(uname -r)
%define destdir /lib/modules/3.10.0-327.el7.x86_64/kernel/drivers/net/
Summary: driver
Name: kmod-xnxx
Version: 1.0
Release: 1_test
License: GPL
Group: Hardware driver
BuildArch: x86_64
BuildRoot: %{buildroot}
%description
Creating a xn4xx kernel module RPM
%prep
%install
mkdir -p %{buildroot}%{destdir}
if [ “%{build_kernel}” != “%{current_kernel}” ]; then
echo “This rpm is for %{build_kernel} kernel version. Ensure that you are using right module/kernel”
exit 1
fi
ls %{destdir} > /dev/null 2> /dev/null
if [ $? != 0 ]; then
echo “%{destdir} is not there. Unable to install the driver.”
exit 1
fi
install -m 644 %(pwd)/BUILD/xnxx.ko %{buildroot}%{destdir}xnxx.ko
%clean
rm -rf %{buildroot}
%post
/sbin/depmod -a %{current_kernel}
/sbin/dracut -v -f /boot/initramfs-%{current_kernel}.img %{current_kernel}
%files
%defattr(-,root,root)
%{destdir}xnxx.ko
%changelog
How to install Petite Chez Scheme on Ubuntu?
I run Ubuntu 15.10 and try to install pcsv8.4-a6le.tar.gz (non-threaded, 64 bit) for Linux.
After having unpacked this tar in /usr/locale, I enter the commands
sudo ./configure
sudo make install
from within the custom directory.
However, instead of a clean install, I get the following errors (which I hope someone can help me out with):
nlykkei#nlykkei-Studio-XPS-1640:/usr/local/csv8.4/custom$ sudo make install
if [ yes = no ]; then if [ ! -f ./scheme ]; then /bin/rm -f ./scheme; ln -s ../bin/a6le/scheme ./scheme; fi; fi
if [ ! -f ./petite ]; then /bin/rm -f ./petite; ln -s ./scheme ./petite; fi
/bin/rm -f ./scheme
echo "const char *S_date_stamp = \"`date +%m%d%Y%H%M%S`\";" > datestamp.c
gcc -m64 -rdynamic -o ./scheme datestamp.c ../boot/a6le/kernel.o ../boot/a6le/custom.o -lm -ldl -lncurses -lrt
/usr/bin/ld: cannot find -lncurses
collect2: error: ld returned 1 exit status
Mf-a6le:22: recipe for target 'scheme' failed
make[2]: *** [scheme] Error 1
Makefile:47: recipe for target 'buildpetite' failed
make[1]: *** [buildpetite] Error 2
Mf-install:64: recipe for target 'install' failed
make: *** [install] Error 2
On recent versions of Ubuntu (and future versions of Debian e.g. "Buster", and other Debian based distros), you can install Chez Scheme directly from the repo(s) by:
sudo apt install chezscheme
Previously you had to install it by compiling from source. Chez Scheme has been open source, for a few years now, and can be compiled from source, if it is not directly installable from the distribution's repo(s). Just download the source code compile and install. This will install not just the "petite" runtime version but also the full compiler. You can compile and install the software with:
./configure
sudo make install
Full build and install instructions are available here.
Pre-requisites for building are:
GNU Make
GCC
Header files and libraries for ncurses
Header files and libraries for X windows
On Ubuntu, install the libncurses5-dev package to get libncurses.so. (You can discover this by visiting http://packages.debian.org/file:libncurses.so (sadly, this doesn't seem to work for http://packages.ubuntu.com/file:libncurses.so).)
You may find other linkage errors if Chez requires other libraries to have development packages installed too. Use the same technique as above.
Go directly building from their Github.
ChezScheme
And then just do
./configure
sudo make install
Prerequisites according to Building are:
GNU Make
gcc
Header files and libraries for ncurses
Header files and libraries for X windows
And yes in case On Ubuntu, install the libncurses5-dev as Chris stated. Did just that and have no errors shown in clean install.
Chez Scheme has been open sourced since this question was asked. Since Bionic (18.04LTS) the full chezscheme is available as a repository.
First do
sudo apt update
then install the package:
sudo apt install chezscheme
This provides both the petite interpreter and the full scheme compiler.
There is also a PPA for trusty and xenial here:
https://launchpad.net/~jonathonf/+archive/ubuntu/lisp?field.series_filter=
Download the RPM package instead and use alien from terminal to produce a deb file:
fakeroot alien PetiteChezScheme-8.4-1.x86_64.rpm
You may need to install fakeroot, alien for this to work:
apt-get install fakeroot alien
Then you'll have a deb file. If you are on a desktop you can just double click the file and it will open Software Center and you can click install and it will fix your dependency problems.
Is it possible to write ip6tables rules to block ipv6 fragmented packets which are malformed.
This is basically for the ipv6 certification of our appliance box. We are running at: rhel 5.5 and kernel : 2.6.18-238.1.1.el5
The tests we are failing currently are:
1) Fragment Reassembly -- Fragment ID mismatch should give error 2) Fragment Reassembly -- Source Addresses Differ Between Fragments 3) Fragment Reassembly -- Destination Address Differ Between Fragments
Any other ideas to solve this is also welcome :)
We can solve this via tools like snort. Below are the steps to install, configure and run in RHEL 5.5
INSTALL PREREQUISITES
For the SNORT we need to install the following:
flex byacc bison pcre-devel libdnet-devel zlib-devel
We can download the above from:
ftp://ftp.univie.ac.at/systems/linux/dag/redhat/el5/en/x86_64/buildtools/RPMS/flex-2.5.35-0.8.el5.rfb.x86_64.rpm
ftp://fr2.rpmfind.net/linux/centos/5.10/os/x86_64/CentOS/byacc-1.9-29.2.2.x86_64.rpm
http://vault.centos.org/5.5/os/x86_64/CentOS/zlib-devel-1.2.3-3.x86_64.rpm
http://vault.centos.org/5.5/os/x86_64/CentOS/bison-2.3-2.1.x86_64.rpm
http://vault.centos.org/5.5/os/x86_64/CentOS/pcre-devel-6.6-2.el5_1.7.x86_64.rpm
ftp://ftp.univie.ac.at/systems/linux/dag/redhat/el5/en/x86_64/dag/RPMS/libdnet-1.11-1.2.el5.rf.x86_64.rpm
http://apt.sw.be/redhat/el5/en/x86_64/rpmforge/RPMS/libdnet-devel-1.11-1.2.el5.rf.x86_64.rpm
* Install the above said rpm in the below order:
rpm -ivh flex-2.5.35-0.8.el5.rfb.x86_64.rpm
rpm -ivh byacc-1.9-29.2.2.x86_64.rpm
rpm -ivh zlib-devel-1.2.3-3.x86_64.rpm
rpm -ivh bison-2.3-2.1.x86_64.rpm
rpm -ivh pcre-devel-6.6-2.el5_1.7.x86_64.rpm
rpm -ivh libdnet-1.11-1.2.el5.rf.x86_64.rpm
rpm -ivh libdnet-devel-1.11-1.2.el5.rf.x86_64.rpm
DOWNLOAD THE REQUIRED SNORT & ALLIED LIBRARIES
http://www.tcpdump.org/release/libpcap-1.5.3.tar.gz
http://sourceforge.net/projects/snort.mirror/files/Snort%202.9.5.6/snort-2.9.5.6.tar.gz/download
http://sourceforge.net/projects/snort.mirror/files/Snort%202.9.5.6/daq-2.0.1.tar.gz/download
[ NOTE: The following assumes the above 3 are downloaded to the /opt/CSCOlumos/SNORT ]
INSTALL LIBPCAP
cd /opt/CSCOlumos/SNORT
tar -xf libpcap-1.5.3.tar.gz
mv libpcap-1.5.3 /usr/local/src/
cd /usr/local/src/libpcap-1.5.3
./configure --prefix=/usr
make
make install
/sbin/ldconfig
INSTALL DAQ AND SNORT
cd /opt/CSCOlumos/SNORT
tar -xf daq-2.0.1.tar.gz
cd daq-2.0.1
./configure
cd os-daq-modules
make
cd ..
make
make install
cd /opt/CSCOlumos/SNORT
tar -xf snort-2.9.5.6.tar.gz
cd snort-2.9.5.6
./configure
make
make install
FIXING THE libdnet LIBRARY ISSUES
cp -rp /usr/lib/vmware-tools/lib32/libdnet.so.1 /usr/local/lib/
/sbin/ldconfig
updated
mkdir -p /var/log/snort/
touch /var/log/snort/alert
TEST THE SNORT
snort --version
,,_ -> Snort! <-
o" )~ Version 2.9.5.6 GRE (Build 208)
'''' By Martin Roesch & The Snort Team: http://www.snort.org/snort/snort-team
Copyright (C) 1998-2013 Sourcefire, Inc., et al.
Using libpcap version 1.5.3
Using PCRE version: 6.6 06-Feb-2006
Using ZLIB version: 1.2.3
CONFIGURING THE IPV6 FILTER AND RUNNING
vi /opt/test/SNORT/SNORT.conf
preprocessor frag3_global: max_frags 65536
preprocessor frag3_engine: policy linux
bind_to 2001::99ed:d7c6:86f0:8e0a
detect_anomalies
preprocessor frag3_engine: policy linux detect_anomalies
Now run as:
snort -c /opt/test/SNORT/SNORT.conf
NOTE: here the 2001::99ed:d7c6:86f0:8e0a is the eth0 (communication interface) ipv6 address.
Right now I'm trying to build Automake on my Mac, and so far everything has been going swimmingly. I built Autoconf and m4 without any issues out of the packages (as opposed to git pulls). And then I get to Automake, and that's where things fall apart:
checking whether autoconf is installed... yes
checking whether autoconf works... yes
checking whether autoconf is recent enough... no
configure: error: Autoconf 2.65 or better is required.
The issue persists if I build and install autoconf 2.68. Is there some sort of trick I'm missing on this one?
The make file is detecting an older version of Autoconf in your $PATH. Take a look at this post in Sebastien's blog, especially the part that tells you to add your new Autoconf bin dir to the $PATH before building Automake. If you want to follow "standard" OSX folder structure convention, install Autoconf in /usr/local.
Allow me to shamelessly copy Daniel Farrelly version of Sebastien's script.
export build=~/devtools # or wherever you'd like to build
mkdir -p $build
##
# Autoconf
# http://ftpmirror.gnu.org/autoconf
cd $build
curl -OL http://ftpmirror.gnu.org/autoconf/autoconf-2.69.tar.gz
tar xzf autoconf-2.69.tar.gz
cd autoconf-2.69
./configure --prefix=/usr/local
make
sudo make install
export PATH=/usr/local/bin
##
# Automake
# http://ftpmirror.gnu.org/automake
cd $build
curl -OL http://ftpmirror.gnu.org/automake/automake-1.13.2.tar.gz
tar xzf automake-1.13.2.tar.gz
cd automake-1.13.2
./configure --prefix=/usr/local
make
sudo make install