2

I've been running CentOS 6.2 as a VM under Hyper-V on my Windows Server 2008 R2 system.

If I run "uname -r" it shows my current Linux version as "2.6.32-220.4.1.el6.x86_64"

A while ago, I did a software update and included in the update was a kernel update. When I rebooted the Linux VM, it came up with a kernel panic message and would not continue. I figured out that if I pressed the space bar during boot and selected the old (original) Linux kernel version, the system would boot fine.

I did some Googling and it I found a site that explains that the Linux Integration Services code needs to be recompiled for the kernel that you're running. Since I can't boot into that kernel, I'm not sure how that is even possible.

More Googling got the following site - http://support.microsoft.com/kb/2387594/de - which says I need to install Dynamic Kernel Module Support - DKMS (which I did) but when I follow further in the instructions it references a "dkms.conf" file which doesn't exist. Creating a blank one doesn't work either as attempting to run the "dkms add -m linuxic -v 3.2" command (I'm running Linux Integration Services 3.2) comes back with "Error! Bad conf file."

Any clues as to how to fix the issue so I can keep my Linux kernel up-to-date on CentOS 6 running the Linux Integration Services 3.2 drivers?

cpuguru
  • 411
  • 5
  • 14

4 Answers4

4

It turns out that the problem was with the CentosPlus kernels that were getting installed. The "CentOS-6-Plus" source was checked in "Add/Remove Software->System->Software Sources" and the "plus" kernels were getting installed with software updates.

Apparently there is some incompatibility between these Plus kernels (they contain "plus" in the kernel name - which you can see by typing "rpm -q kernel" in a terminal screen).

I unchecked "CentOS-6 Plus" as a software source and deleted the new plus versions of the kernel that had been installed via "yum remove " and then with the next software update, the non-plus version of the updated kernel was installed and the system booted without a kernel panic.

Hope this helps someone else in the same boat.

cpuguru
  • 411
  • 5
  • 14
2

You shouldn't need to build the LIS kernel modules against the running kernel, merely an installed one. The updated kernel headers should be enough to build the module for the new kernel.

I've never touched Hyper-V in my life (and, unless I'm very unlucky, that will never change), so I can't give you any specific instructions, but I would assume that the docs would show you how to specify how to build the module(s) against the headers you've installed.

womble
  • 95,029
  • 29
  • 173
  • 228
2

I had a similar problem, but with CentOS 6.5->6.6 and LIS 4.0 Here's what I did:

1) Boot into previous kernel version

2) Open the LIS folder [copy it to disk if on CD]

3) Open the /install.sh file for the NEW kernel version you installed, NOT the one you're running. In my case, was RHEL66.

4) Inside the file, where the rpm command is executed (in my case, it was twice), add "--force" without quotes to end of the rpm command.

5) Re-execute install.sh as root. This should install the RPM modules. Reboot the system, but booting into the new kernel this time. NOTE: I recommend snapshotting your VM BEFORE doing this. It worked for me, but it might not work for you.

aoetalks
  • 268
  • 4
  • 6
1

The Microsoft instructions are written for Linux Integration Components version 2.1 - when they were still delivering them in source format. So you were able to run a "make" and follow their various instructions.

The current versions 3.4 (or even 3.2) come in RPM format without source - so none of the files and folders they mention exist.

The underlying problem is (apparently) that the IC contain improved disk drivers for the Hyper-V simulated disks - and the new Kernel won't have them and thus doesn't know how to access the file system.

Andy Schmidt
  • 11
  • 1