IPv6 at home?

The Internet has been alive with doom saying since the IPv4 global address pool was parcelled out.  Now I do not subscribe to the view that the Internet is going to end imminently, but I do feel that if the technical people out there do not start playing with IPv6 soon then what hope is there for the masses?

In the UK getting native IPv6 is not a trivial task, only one ISP I can find seems to offer it and of course it is not the one I am with.  So what options do I have?  Well there are a number of different types of IPv4 tunnelling techniques such as 6to4 but these seem to require the ability to handle the transition on your NAT router, not an option here.  The other is a proper 6in4 tunnel to a tunnel broker but this needs an end-point.

As I have a local server that makes a sensible anchor for such a tunnel.  Talking round with those in the know I settled on getting a tunnel from Hurricane Electric (HE), a company which gives out tunnels to individuals for free and seems to have local presence for their tunnel hosts.  HE even supply you with tools to cope with your endpoint having a dynamic address, handy.  So with an HE tunnel configuration in hand I set about making my backup server into my IPv6 gateway.

First I had to ensure that protocol 41 (the tunnelling protocol) was being forwarded to the appropriate host.  This is a little tricky as this required me to talk to the configurator for my wireless router.  With that passed on to my server I was able to start configuring the tunnel.

Following the instructions on my HE tunnel broker page, a simple cut-n-paste into /etc/network/interfaces added the new tunnel network device, a quick ifup and my server started using IPv6.  Interestingly my apt-cacher-ng immediately switched backhaul of its incoming IPv4 requests to IPv6 no configuration needed.

Enabling IPv6 for the rest of the network was surprisingly easy.  I had to install and configure radv with my assigned prefix.  It also passed out information on the HE DNS servers, prioritising IPv6 in DNS lookup results.  No changes were required for any of the client systems; well other than enabling firewalls.  Win.

Overall IPv6 is still not simple as it is hard to obtain native IPv6 support, but if you can get it onto your network the client side is working very well indeed.

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.

Union File Systems (again)

During the early part of the Maverick cycle we once again revisited out Union Mount solution.  At that time VFS union-mounts was the hit of the day, set to finally to produce something which might get into the kernel.  Since then the complexity of changing every filesystem to support whiteouts, its invasiveness, and its affects on Posix semantics have lead to it falling by the wayside.  In its place has sprung overlayfs.

overlayfs is a small patch set which is a hybrid of the VFS union-mount approach and that of aufs/unionfs in that it also provides a filesystem.  This greatly reduces the complexity of the patch set, reducing its invasiveness and thus increasing its chances of ever being merged.  So much so simpler is it that your author is actually able to understand and debug it.  Win.

We have been tickling overlayfs for most of the Natty cycle, but with Natty in the can I have had had some time to catch up with its development and help out a little, both with testing and bug fixing.  Culminating today in my being able to inject a kernel containing overlayfs support into an Ubuntu LiveCD and boot it, then update it to the latest Natty, all without error.

overlayfs may shortly be in a mergable state, nirvana for all union mount lovers.  Only time and testing will tell.

Ubuntu Kernel Crack of the Day

We have been producing the mainline kernel crack of the day[1] for some time now.  But this targets the upstream kernel, and while great for testing and bug isolation it does not provide us with any pre-upload testing on the Ubuntu kernel delta.

Enter the pre-proposed kernel PPA[2].  We are now uploading the unreleased tips of the ubuntu kernel trees to this PPA.  These builds will contain any bug fixes marked Fix Committed and should provide a vehicle for advanced testing of these before they hit the archive.  For Maverick we will be uploading these automatically as the tree changes, roughly daily.  This should help us avoid the ThinkPad debackle we experienced late in Lucid.

I would encourage you to add this PPA to your sources and help us test this kernel before we unleash it on the world.

[1] https://wiki.ubuntu.com/KernelTeam/MainlineBuilds
[2] https://edge.launchpad.net/~kernel-ppa/+archive/pre-proposed/

Union Filesystem Plans

At UDS we return to the subject of those drivers we are carrying which are specific to Ubuntu, why they are not yet upstream and what we can do about it.  Union Filesystems are a key technology in producing the live CD environment used to allow both non-destructive testing and the graphical installer.  This technology has long been a contentious subject as the patch sets have been extensive and intrusive to the VFS.  Worse there have been a number of camps all disagreeing as to the most sensible solution.

For a number of series we have carried the AUFS/AUFS2 patch kit as an Ubuntu add on.  This has been a solid performer in this space and served our purposes well.  About a year ago now talk began upstream on what approach would be acceptable to upstream.  This has resulted in a proposed for an integrated VFS based solution for union filesystems called union-mounts.  Patches have been circulating for the best part of a year and we skirted with them for the Lucid cycle, at that time they were feature incomplete preventing full testing.

Recently updated patches have been circulated which should be feature complete, and we are planning to provide kernels enabled for union-mount for testing in a PPA.  Should testing there prove good we will consider switching to this solution for our live CDs.  Watch this space as they say.

Maverick UDS: the hangover

What a mad week.  Finally UDS is over and at least some of us are back home, dispite the efforts of a certain Icelandic volcano and of Eurostar.  For me this has been one of the most valuable I have attended.  I suspect in large part this is due to my being more experienced in the 'one hour to rule the world' mentality.  The rather fetching five minute warning popups were pretty handy to focus the mind on getting the pertinent actions into the gobby seance.

Last cycle I was Kernel Release Manager, this meant that I had responsibility for all of the core kernel blueprints and meant I was tied to the kernel track almost exclusively.  With that responsibility passing to Leann I found myself free to rove to other tracks and stick my nose in.  I attended a number of X/graphics related discussions.  It was great to meet those behind the IRC nicks which I deal with so very often.

More on what we are going to be playing with once the hangover dissipates, in the meantime some Guitar Hero me thinks.

Lucid Kernel Final Configuration

Now that release is fast approaching it was thought appropriate to advertise the final kernel configurations for all of the main distro and ports kernel flavours.  The purpose is to expose the main configuration changes to scrutiny and to provide pointers to the full configurations where those are of interest.

For Lucid we have aimed primarily on stabilisation and supportability. As such we do not expect there to be any radical configuration changes in these kernels.  There has been a drive to commonise and standardise options between architectures and flavours where at all possible to help standardise the experience.  There has also been a drive to pull out to modules some sub-systems which are commonly replaced by users, such as HID, and also pulling out the majority of the PATA and SATA drivers as it is most common to only require a single one of these.  We have also enabled KMS for all graphics hardware where it is supported.

To aid in this comparison we have generated a delta report between Karmic and Lucid which shows all items which have changed and how the value has changed.  This report can be found at the URL below:

  https://wiki.ubuntu.com/KernelTeam/Configs/KarmicToLucid

To facilitate series to series comparison we include pointers to both the full Karmic and Lucid configurations for each flavour, all of which can be found at the URL below:

  http://kernel.ubuntu.com/~kernel-ppa/configs/

Enjoy!