A blog about doing things with computers

Blog | Archive | Twitter | Github | Rss

Upgrading the kernel on Debian 7.8

07 Oct 2015 | linux, extlinux, kernel, wheezy, debian, aws

I recently had a problem upgrading from the default kernel provided by the official Debian AMI (3.2.0-4) to something more recent in wheezy backports. The issue was quite simple but it stumped me pretty well! TL;DR extlinux-update is broken because it attempts to sort versions using: sort -nr instead of the version option:sort -Vr. In order to fix this you’ll need to replace these lines in /usr/sbin/extlinux-update

The long version..

To boot from a volume (e.g. /boot is a fairly standard location) extlinux needs to know where to look for images. The boot location and a load of other configuruation options are spread across many files. These are in /etc/default/extlinux and various config files in /boot/extlinux/ (assuming extlinux is configured to run on /boot). All these configuration files are generated by one shell script:


I assume within this script the label with the lowest value will be run first i.e. from linux.conf

label l0
        menu label Debian GNU/Linux, kernel 3.16.0-0.bpo.4-amd64

will take precendence over:

label l1
        menu label Debian GNU/Linux, kernel 3.2.0-4-amd64

This illustrates the precise problem. extlinux-update always makes sure 3.2.0-4-amd64 always comes out above 3.16.0-0.bpo.4-amd64. The reason for this is simple, it’s the following line in extlinux-update:

_VERSIONS="$(cd /boot && ls vmlinuz-* | grep -v .dpkg-tmp | sed -e 's|vmlinuz-||g' | sort -nr)"

sort -nr is a numerical ordering and numerically 3.2 > 3.16. Fortunately sort also has a version ordering so change it to:

_VERSIONS="$(cd /boot && ls vmlinuz-* | grep -v .dpkg-tmp | sed -e 's|vmlinuz-||g' | sort -Vr)"

There has been a bug open about this for a while. I believe it should be fixed in jessie, but haven’t had the chance to check yet.

In the meantime I’ve had to replace the sort with some rather hacky shell as part of provisioning new AMIs with the desired kernel version.

Older · View Archive (11)

Provisioning with Terraform Part 2

In my last post I covered the basics of provisioning a single EC2 instance with terraform. This time we’re going to go further and explore the provisioners and some other features. I’m doing some pretty funky things just to show the power of terraform. As you’ll see later there are other (better) ways.


Get up and running with Puppetlabs AWS

There’s an increasing number of ways to provision AWS infrastructure. I’ve already mentioned terraform which is my current frontrunner. There’s also also a couple of other options like the ansible cloud modules, Cloud Formation or writing your own custom stuff with an AWS sdk. In this post I’ll be looking at something I came across fairly recently: Puppetlabs-aws.