Installing Debian to the network with NBD

As I've blogged about before, wheezy will be the first release since I've started maintaining NBD for Debian to feature NBD support in the installer. That is, you'll be able to install wheezy to the network, simply by adding "modules=partman-nbd" to the kernel command line:

While I'm happy and, in fact, a bit proud about that fact, there are still a few minor issues that make the whole process a bit less smooth than it could be:

• If you install your system to an NBD device but it's not a diskless system, then we'll still write a bootloader to disk. I think this is a bug; if we're not touching the hard disk for the rest of the installation, we should also not touch it during the final stages of the installation. Unfortunately that's not something that can easily be avoided in the current state of affairs.
• If you install your system to an NBD device and it is a diskless system, the installer will hang for about 30 seconds currently when it's trying to find a hard disk and can't. After that, you have to hit "continue without using a hard disk" to have it work. This isn't a major issue for people with patience, but it's a bit annoying.
• Additionally, when installing to a diskless system, you'll get a spurious error message at the end about the system not being able to install grub to local hard disk. This is the same issue as the first one, really, but it shows in a different way.
• There's a minor bug in partman-nbd where the NBD menu will lag behind reality until the next update. This isn't a major issue (all functionality is still there, the information to the user is just not alwyas up-to-date), and the fix might be somewhat complex, so I won't fix it before wheezy is out the door.
• If you install a desktop system onto an NBD device, then currently network-manager will also be installed, which will try restarting the network at boot time. This will cause the kernel to panic, as the system will suddenly lose all access to its root device when that happens.
• Most importantly, there is currently no way in Debian to configure a network bootloader from the installed system (other than copying and editing files manually). What this means is that while it'll be possible to install a Debian system to an NBD device with wheezy, it won't be possible to reboot into that newly-installed system without performing some manual steps.

In my plan to take over the world of network storage, I plan to work on that last point during the jessy release cycle, at least for x86 architectures; I envision a system which would mount /boot on NFS, and write pxelinux.cfg files, where the name of this config file would be configurable (so it can be configured to only boot the system on which the file was written, or to boot any system on the local network). If done well, it will also fix the point about installing the bootloader to local hard disk when doing a network installation, since we'll have a "install netbootloader" or some such option.

BSP postmortem

This post is a bit late, but still interesting:

Last weekend, I held a Bug Squashing Party at my company's offices in Mechlin, Belgium. This is the first time I've attended, let alone hosted, such an event; so I'm not that experienced in figuring out what I can and cannot do with other people's packages yet. As a result, our success rate was a bit lower than I'd hoped for. Still we closed two bugs, figured out that one more bug required just some binNMUs, that one should probably be tagged wheezy-ignore (as it was tagged squeeze-ignore too, and hasn't seen updates since then), and touched three more bugs.

Having said that, I did have a bit of a hidden agenda, in that I've been wanting to build a stronger Debian community in Belgium; we are ranked fairly highly on the Debian Developer per capita list, but us Belgian DDs never meet up, in contrast to DDs from three of the four countries that surround Belgium. In that, I did have some success, too; some local people showed up who'd never (directly) contributed to Debian before. While I'm not silly enough to think that just showing up to a BSP once makes you suddenly an active member of a community, it's still a good first step.

Unfortunately, however, I did not manage to get any other active Belgian DDs to show up. Apart from myself, only Dutch DD Joost Van Baal and DD Emeritus Joost Damad were present. If I can't find a way to improve on that, I'm not sure this BSPing will have a long life in Mechelen.

At any rate, though, I did have a lot of fun doing this. Surely that, if nothing else, counts as "success".

m68k: back from the dead

It's been a few years coming, but the day has finally arrived.

Contrary to some rumours which I've had to debunk over the years, the m68k port did not go into limbo because it was kicked out of the archive; instead, it did because recent versions of glibc require support for thread-local storage, a feature that wasn't available on m68k, and nobody with the required time, willingness, and skill set could be found to implement it.

This changed a few years back, when some people wrote the required support, because they were paid to do so in order to make recent Linux run on ColdFire processors again. Since ColdFire and m68k processors are sufficiently similar, that meant the technical problem was solved. However, by that time we'd fallen so far behind that essentially, we needed to rebootstrap the port all over again. Doing that is nontrivial, and most of the m68k porters team just didn't have the time or willingness anymore to work on this; and for a while, it seemed like the m68k port was well and truly dead.

But then, two things happened.

The first thing that happened was called "ARAnyM", short for "Atari Running on Any Machine". An atari emulator, it started supporting running Linux at some point, allowing us to work on the port while on the road, using a laptop—something not possible beforehand. While there were some bugs in the emulation of early versions of aranym, these were all fairly quickly fixed, and before long we could run Debian/m68k in the emulator. However, that was still the etch-m68k port on debian-ports.org, some time after Debian etch wasn't even supported anymore; this still required work.

The second "thing" that happened was called "Thorsten Glaser". A fresh DD and maintainer of the "mksh" shell, he wanted to make sure his shell would work on all Debian architectures, including the ones on debian-ports.org. When he found out that the m68k port was in a pretty bad shape, he did not, like many before him, shrug and move on; instead, he took it upon himself to start compiling things, just so he could compile his shell. How's that for dedication.

Anyway, fast-forward two years, and we're now, finally, at a point where I spent most of today getting buildd up and running on arrakis, one of our oldest buildd hosts. There were some issues while trying that, but it looks like everything is in working order now; and the first package to start building on the first functioning buildd host since a long time (the build of which is still ongoing at the time of this writing) is "babl".

Of course, with only one buildd, we'll have no hope whatsoever of ever catching up. But that can be remedied easily by using more than one buildd host...

Update: It built! Party!