Tuesday, 21 June 2011

Oh no 3.0

After 39 2.6.x releases Linus Torvalds has chosen to revisit the upstream kernel version.  The plan is to release what would have been 2.6.40 instead as version 3.0:
"I decided to just bite the bullet, and call the next version 3.0. It
will get released close enough to the 20-year mark, which is excuse
enough for me, although honestly, the real reason is just that I can
no longe rcomfortably count as high as 40."
When 3.0-rc1 was released the Kernel Team had to decide what version to use for it in Ubuntu.  We typically upload every -rcN release within a couple of days of its release so the pressure was on.  We could simply call it 3.0.0 knowing that all the current scripting would cope, or as 3.0 better matching its official name knowing this would not be plain sailing.  This was not a decision we could delay as in Debian versioning 3.0 < 3.0.0 so we were likely to be committed for Oneiric if we uploaded using 3.0.0.  It is also not clear from upstream discussion what version number the final release will carry, as 3.0 clearly will cause breakage on older userspace.

After much discussion we decided we bite the bullet and upload a 3.0 kernel.  At least we get a chance  to identify problematic applications, while still keeping our options open to move to a 3.0.0 kernel for release should that be prudent.  As expected this was not smooth sailing, not least for the kernel packaging which needed much love to even correctly build this version.  Plus we had to hack the meta packages to allow that to be reversioned later too.

Once successfully uploaded the problem applications started to crawl out of the woodwork:
  • depmod -- the depmod incantion to create the module dependancies identifies the kernel version in its command line but was assuming that a version contained three digits, this lead it to miss the version entirely and rebuild the wrong dependancies;
  • libc6 -- both the runtime and the installation control scripts manipulate the kernel version number, in both cases assuming the version was three digits, enormous fun getting the pending updates installed;
  • ps/top -- when starting the kernel version was checked, and miss decoded triggering a rather nasty sounding version warning whenever they are started;
  • nfs-utils -- when attempting to read and identify the kernel version the nfs-utils would trigger a SIGSEGV and die, triggering boot failures on machines with NFS roots; and
  • lm-sensors-3 -- this package is only compatible with 2.6.5 and above, failed version detection lead to this test failing and sensors being unconfigured.
Those are the ones we have found so far, I am sure there will be more.  If you do find one please file a bug against the failing package but tag it kernel-3.0 then we can find them.

3 comments:

  1. Why waste valuable dev time?
    You know it will only be a matter of a couple of months and 3.0.1 will be out.
    So just call it 3.0.0 and be done with it.
    Your wasting time and resources that could better be directed elsewhere.

    ReplyDelete
  2. For what is worth, this is also the choice that the Fedora kernel maintainers have made:
    http://koji.fedoraproject.org/koji/buildinfo?buildID=248428

    Hopefully, with two of the major Linux distributors working on it, the issues due to this new versioning scheme should be resolved pretty quickly. :)

    ReplyDelete
  3. parted broke too - it wound up reverting to old-style partition handling and breaking horribly. (Fixed upstream, patch backported into Debian and Ubuntu.)

    ReplyDelete