Current kernel-xen conflicts – and why!?

I’ve made a number of changes to the kernel-xen repo today – and it will probably break a lot of things for everyone except new installs – however the pain is worth it… Here’s why:

1) All RPM packages are now signed with a 4096 bit key. Now I’ve got mirror sites popping up its probably a good thing to sign them to ensure your safety and that they haven’t been altered.

2) There are now 4 mirrors and counting for packages. This means you’ll get faster downloads and upgrades in the future.

3) I don’t have to roll out a new kernel-xen package for every update to the mirrors!

The problem?

Well, versions of kernel-xen older than contain the file we use to set the mirrors and contains all the repo config. At the beginning, this didn’t matter – however as changes to mirrors happen, the only way to update each and every system with new mirrors is to roll a new kernel RPM! This is a bad thing.

To combat this, I’ve created a new package called kernel-xen-release. This contains the new GPG signature for the packages and also the repo config file /etc/yum.repos.d/kernel-xen.repo. This means changes to the mirrors can be done with a simple 10Kb update instead of the entire kernel.

Now, why it breaks:

You never want to UPGRADE a kernel RPM. Doing this would remove the running kernel from under your running system and replace it with the newer one. Generally, removing the running kernel is NASTY. However, this now causes an issue that if you have kernel-xen- installed, it will conflict with the new kernel-xen-release package!

At this stage, I can’t figure out a workaround that will cause this to go smoothly for upgrades, so the only real fix I can think of right now is to remove all kernels at or below and manually install and kernel-xen-release. You’ll also notice that kernel-xen-release requires yum-plugin-fastestmirror. This will make sure you get your updates from the fastest mirror around.

So in a nutshell, sorry for breaking your upgrade path! If I had thought ahead on how things would pan out, I would have split up the repo config from the kernel from day #1, but I didn’t see it being as popular as it has been and requiring mirrors from around the world!

How to fix this?

Thankfully, its quite easy:

# wget
# rpm -ivh --nodeps kernel-xen-

Edit /etc/grub.conf and set the default to, then reboot your system. Keep in mind you’ll have to add the kernel line for xen.gz and modify the existing KERNEL and INITRD lines to MODULE.

After rebooting, erase the old kernels (anything older than and install the new kernel-xen-release package:
# yum erase kernel-xen-
# yum install


Skip to comment form

    • kmthang on February 13, 2012 at 2:23 am
    • Reply


    Today, I installed the latest versio and booted to it. Now I’m very internet connection problem. I cannot ping to that server from my home pc machine. Yes, this was a new OS install (CentOS 6.2 x86_64 minimal iso). I installed it the exact same way as I did on my other server which is running and it doesn’t have network problems. I can ping fine and everything is normal.

    Do you have a solution for my situation?


    1. G’day!

      Nothing has changed in the actual kernel package. The only change between -3 and -4 is the /etc/yum.repos.d/kernel-xen.repo file. Keeping this in mind, I believe theres something else causing your issue here.

      See if you can ping from your Xen Dom0 machine, and also see if you can use wget to download the package. This should help you debugging a few more things…

    • kmthang on February 13, 2012 at 3:15 am
    • Reply

    This is the message I get.

    Screenshot below:

    I can ping fine when I boot to the normal kernel.

    • kmthang on February 13, 2012 at 3:21 am
    • Reply

    Something is off. When I do ifconfig (booted in xen kernel), I only see the lo, the eth0 is missing. But it isn’t missing when I boot to normal kernel. What do you suggest me to try?

    1. I doubt very much that this is a problem between kernels -3 and -4 – however the first thing I’d do is dmesg | grep eth0 to see what is detected at boot. Depending if you see anything or not depends on where you go from there. Also, just from habit, check you modified /etc/grub.conf correctly so you load the Xen hypervisor before the kernel…

      You should see something like:
      # dmesg | grep eth0
      eth0: RTL8168b/8111b at 0xffffc900059b4000, 50:e5:49:4d:4a:f6, XID 0c900800 IRQ 498
      r8169: eth0: link up
      r8169: eth0: link up

    • kmthang on February 13, 2012 at 3:49 pm
    • Reply

    I think eth0 detected.

    Screenshot below:

    1. I think udev might be playing tricks on your system. It seems that eth0 has been renamed to eth1 – which probably plays hell with all your startup scripts! I know udev is supposed to be helpful, but sometimes it causes interesting issues like this!

Leave a Reply

Your email address will not be published.