Steve's Blog

Xen repo update and new gizmos

I’ve been doing a little work on the development and repo hosting side of things. We now have 5 mirrors around the globe mirroring these packages. Sadly, they don’t always update at the same time - so today I’ve implemented a script to check each mirror hourly and either add or remove it from the mirror pool as they change into or out of sync.

This brings me to the next change. I’ve updated the kernel-xen-release package to revision 3 now. This uses the mirrorlist directive by default to take advantage of the script mentioned above to automatically exclude out of sync mirrors… This is a much more flexible system and will cause less errors as updates are pushed out to mirrors.

The third change is that I have now also build Xen for a 32 bit (i386) environment. I am still working on a kernel for this - so work is not yet complete - however the core hypervisor and associated tools as well as an updated bridge-utils package is also available for use on 32 bit systems. Once I get a successful kernel build, I’ll be making it available via the 32 bit repo.

The fourth and final change today is the addition of the $basearch tag in all mirrors. This will allow compatibility with all systems I’d expect to see Xen packages for without having to change too may things manually.

The update to kernel-xen-release-6-3 should be pain free using yum -y update kernel-xen-release and you’ll need to do this to be able to continue using the repo going forward.

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 2.6.32.55-4 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-2.6.32.55-3 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 2.6.32.55-3 and manually install 2.6.32.55-4 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:

1
2
# wget http://www.crc.id.au/repo/x86_64/kernel-xen-2.6.32.55-4.x86_64.rpm
# rpm -ivh --nodeps kernel-xen-2.6.32.55-4.x86_64.rpm

Edit /etc/grub.conf and set the default to 2.6.32.55-4, 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 2.6.32.55-4) and install the new kernel-xen-release package:

1
2
# yum erase kernel-xen-2.6.32.55-3
# yum install http://www.crc.id.au/repo/x86_64/kernel-xen-release-6-2.x86_64.rpm

EL6 Xen Dom0 kernel gets mirrors!

In a bid to provider better service to people using my repo for Xen Dom0 kernels for EL6, I’ve put in place two mirror sites which yum will be able to use.

I recommend to everyone using my repo to install the yum-plugin-fastestmirror plugin for yum and to also redownload /etc/yum.repos.d/kernel-xen.repo from here

If you are able to offer a stable mirror for this repository in another country, please email me!

Xen Dom0 kernel update & new -devel packages

Rebuild based on 2.6.32.55 kernel version. Changelogs are as follows:

1
2
3
4
5
6
7
* Tue Feb 07 2012 Steven Haigh <netwiz@crc.id.au>
- Re-enable all but the digitv USB DVB modules.
  Sadly, digitv still fails to build.
- Minor tweak of the kernel-xen-devel package.

* Wed Feb 01 2012 Steven Haigh <netwiz@crc.id.au>
- Attempt to create kernel-xen-devel package able to build modules from.

There has been success in building the drbd kernel module against this kernel-xen-devel package - so hopefully others should be buildable without too many issues as well.

I’ve also included a new bridge-utils package that removes the errors associated with the stock EL6 bridge-utils when doing brctl show.

Xen kernel testers required

Ok, so I’ve had quite a few requests to get a kernel-xen-devel package happening so people can build third party kernel modules against my Xen Dom0 kernel.

Now I think that I’ve got this sorted out - but before I inflict it on the world I’d like to get a few testers to check if it works at all. It seems the most common request is to build the drbd module from somewhere (not quite sure where).

As such, I’m hunting for at least one or two people that can install my kernel RPMs + the kernel-xen-devel package and see if they succeed in building third party modules, then let me know if it works or not.

Email me if you’re able to help!