I am running CentOS 6.5 on top of Linux kernel 2.6.32-358.6.1.el6.x86_64
I got a warning from my vserver hoster that I need to upgrade to a Linux kernel > 3.15-rc5 because there is a security breach that would allow my server to be taken over.
I did a yumupgrade, but it wouldn't upgrade the kernel to a higher version than 2.6.32-358.6.1.el6.x86_64.
Currently I am confused about how to go on.
Could anybody tell me what is going on and how he would act in my position?
Thank you!
That kernel is a development kernel and will likely require you compile from source to install it. Upgrading from kernel 2.6 to 3.1n will likely break a bunch of packages also. The upgrade path for 3.1n in CentOS would be to upgrade to CentOS7 and then compile that kernel yourself.
CentOS backports security fixes and I certainly haven't heard anything about any security bug, and we manage like 150 centos servers. I would ask your host to specify what the security bug is and which patch applied in the 3.15-rc5 kernel fixes it. Who's the host?
I'm using CentOS 6.5 and have no problem using the ElRepo Long term kernel (currently 3.10.x).
See http://elrepo.org/tiki/kernel-lt
Upgrading was just a case of
yum --enablerepo=elrepo-kernel install kernel-lt
and rebooting.
Related
Using a virgin (but updated) version of Rocky Linux 8.5, I am trying to install VMware Workstation 16.2.1 (and others), but get compile errors during the first attempt to run, when vmmon and vmnet are being built.
All the proper, current headers from kernel-devel and kernel-headers are installed.
I tried upgrading to the 5.16.4 kernal at kernel.org, with all associated headers, and basically get the same errors.
"Unable to install all modules." i.e., vmmon and vmnet
Posts i have found with searching the net seem to indicate that there was a "back-port" of an upstream fix to Rocky that has affected the ability to build the loadable kernel modules necessary to run vmware - but i cannot confirm this is actually the problem that I am experiencing.
So i simply ask these questions: Can anyone (today) install VMware Workstation 16.2.1 (or any version), on a fresh install of Rocky Linux 8.5?
If so, would you please point me at your installation instructions, because I am unable to build "vmmon" and "vmnet" modules today (2022-01-04), that allow me to actually run virtual machines with vmware? (The kernel modules fail to compile and build.)
(and after 15 years of using stackoverflow i do not have the reputation to create a "rocky-linux" question tag...)
See https://unix.stackexchange.com/questions/689436/the-vmmon-and-vmnet-vmware-workstation-kernel-modules-fail-to-build-on-rocky-lin
mbubecek's instructions work for a variety of releases and should compile perfectly and run without issue, if you follow his instructions.
I have successfully used these methods at least a half dozen times with Rocky 8.5 and 8.6 with vmware workstation 16.1 up to version 16.2.1
NOTE: This error is NOT Rocky Linux specific. Also happens on some versions of RHEL 8 and CentOS 8.x I would also expect this "fix" to work on all of the other linux versions that are RHEL 8-derived.
I've been having difficulty with the same issue, and a colleague pointed me to check my kernel. This is our "official" resolution. See if the below works for you.
This is due to differences between the kernel and the source code for the VMWare modules, see here for more information. You can get the correct kernel modules, and build them by executing the following commands
wget https://github.com/mkubecek/vmware-host-modules/archive/workstation-16.1.0.tar.gz
tar -xf workstation-16.1.0.tar.gz
cd vmware-host-modules-workstation-16.1.0/
make
sudo make install
If you get the error,
crosspage.c:53:16: fatal error: linux/frame.h: No such file or directory
The error is described here. The solution is to remove (i.e. comment out) the offending include file in crosspage.c After doing the sudo make install, it is a very good idea to restart you host.
You may need to manually insert the modules into the kernel the first time after running make install'. The kernel modules (vmmon.ko and vmnet.ko) will be found at /lib/modules//misc. The following set of command will do this:
cd /lib/modules/$(uname -r)/misc
sudo insmod vmmon.ko
sudo insmod vmnet.ko
The modules should be load automatically after a restart/reboot.
If you update vmware to a different version (say 16.2.1) you may need to this again. Just change the versions in the above commands. If you hit the update button on the splash-screen and failed to notice the version you are updating to, you can run `vmware -v' at a command prompt to get the version you updated to.
After a recent kernel update for Centos 7.4, Paravirtualized DomUs under Xen stooped booting. They just crash on boot.
Apparently it seems a new restriction in RHEL 7 kernel. And there are some suggestions i found in different forums to switch to HVM or PVHM. Problem is that most of Paravirt DomUs are installed on plain disks (without partitions). But to convert them to HVM or PVHM they need Grub installed inside the VM which need partition table. So it is a full reinstallation :(
Centos guys say it is something RHEL need to fix. So is this a bug which can be fixed in near future ? or is that RHEL just dont want its kernel to run on Paravirt vms any more ?
Had the same issue, and as a hack workaround installed the CentOS Xen kernel before upgrading to 7.4. Had no issues booting with that kernel in place. If RedHat fixes their kernel it should be relatively simple to switch back to it.
We are currently provisioning a physical server as our automation server. We are making considerations as far as what our native operating system should be on this physical machine.
We are going to use a Linux OS as our operating system. From the Jenkins download page, I can see that Jenkins’ package distribution is available to Red Hat / Fedora / CentOS (which we will not be using), as well as Ubuntu / Debian. I also notice that a Generic Java package (WAR) distribution is available.
Am I correct in assuming that if we use a non-Ubuntu / non-Debian
operating system, we can still install Jenkins via the WAR
distribution without issue?
If we are not able to install via WAR without issue, are we relegated
to using Debian / Ubuntu if we’re going to install Jenkins on a Linux
machine (with the possibility of Red Hat / Fedora / CentOS ruled
out)?
It should probably be noted that we will likely install / upgrade on the Jenkins LTS release schedule.
Thanks for any guidance from anybody who may have experience installing / maintaining a Jenkins instance on a Linux machine!
I'm trying to replace centos 6.6 system with centos 7.2, but my kernel module for centos 6.6(kernel 2.6.32) dose not work on centos 7.2(kernel 3.10.0).
There is no source code and I am just a server engineer, not a programmer.
Could you please help me... is there any good solution?
For example, kernel module converter 2.6.32 => 3.10.0, or some hacks to force loading old kernel module...
You can, depending on the kernels.
You can also force load it. But if you force load it your system might crash, depending on how you do it.
I tried that with mint 17 and mint 18.
I need to install old kernel into Kali (Debian like) distro. I need to run program which requires older kernel.
I downloaded kernel but the installation gives me too many errors. I was reading similar topics and watch the videos, but so far I am not successful.
I do not have experience with kernels. Is there .deb package for kernels or any other easier way to do it?
Can I use such old kernel for this distribution?
Thank you
The 2.4.33 kernel is pretty old. According to Debian's packaging files installing that old a kernel doesn't seem to be doable in wheezy. Attempting to install and run an old kernel outside the packaging system is not going to to work. All the "modern" libraries and applications will be broken when running the 2.4 kernel, as will the program (you need more than just a kernel for your program). If it were me, I'd set up a virtualization environment like VirtualBox or something similar and pick an old distro like CentOS 3.9 or an older Debian release (sarge or later). If that's not an option, you could always try and port the program to a more recent kernel.