Oops, I did it again...

For (at least) the third time, I managed to register for debconf before registration was actually open. Oops.

I found out that unfortunately, it's not quite certain yet that there will actually be a debcamp this year—and if there is going to be a debcamp, it won't be a full week. Pity. At any rate, I'll be there the whole time, whatever the duration of debcamp.

Since Vaumarcus is closer to Mechelen than Edinburgh (by about 250km), this is going to be the closest debconf for me, ever. And if I could go to Banja Luka by car, I can certainly go to Vaumarcus by car.

Anyone care to join me?

Single-stepping init systems

The Linux init systems are a bit in flux at the moment. That is, they're in flux in Debian; outside Debian, most other distributions have stepped away from sysvinit and towards something else (systemd, openrc, or upstart). I've not been a proponent of any switch, though I understand the reasoning, and it probably makes sense for us to switch at some point. But yesterday, the fact that this customer's system was running sysvinit and not systemd or upstart saved me quite a bit.

There's a server. It has one quadcore processor. For reasons that I won't go into here, the customer wants an extra quadcore processor to be added to the system.

After having done so, I power on the system... only to see it power itself off at some point during boot. I did notice some kernel messages fly by just moments before the system would power itself off, but it was impossible for me to read them. So what did I do?

• Boot the system with init=/bin/bash,
• After having booted the system, go to /etc/rcS.d and manually run each and every one of the scripts there in turn. When the system powers off, I know what the problem is.
• Disable the init script that causes the problem, and boot the system normally.

That last bit is, obviously, a bit of an ugly workaround; the better way to fix this issue would have been to debug what the actual issue was, and implement a proper fix. However, I didn't have time for that (the fact that there was need for a second quadcore chip explains how much this system is in use), and the workaround was acceptable for the customer. It is not the first time that this ability to single-step the init system has saved me. The fact that sysvinit is so simplistic is what makes this possible, and I consider that one of its most important features.

Recently, I came into contact with a distribution that uses systemd as its init system (in casu, Arch Linux). I had made a mistake in configuration; I had installed and enabled a graphical login system, but had no xterm or similar available, and had done something else wrong through which I couldn't get a regular shell on the console anymore, either. To fix this, I tried doing something like the above (running with init=/bin/bash and single-stepping the init system), but found that doing so with systemd is nigh impossible. In the end, I knew what exactly the problem was and could disable automatically starting the login manager through removing a symlink, but it brought home the issue that debugging a similar issue when running systemd rather than sysvinit might be a lot harder to do.

We'll see what the future brings.

Whee

Today, I played at TC Cantincrode in Mortsel, Belgium, in the first round. This is the first year I'm playing tennis competitively, so I was expecting to lose by a pretty wide margin. Now while I didn't win, the margin wasn't as wide as I'd expected; 6/4 - 6/3 isn't too bad for the non-ranked beginner that I am. For comparison: I lost my previous match with 6/2 - 6/0, and I was not unhappy about that.

Part of this was due to my opponent (by his own admission) not playing his best; but still, I'm quite happy about my result here.

My next match probably won't be as good. Oh well.

Not switching to 3.0 (quilt) just yet

I had a look at the 3.0 source formats just now. I've never been very fond of that, mainly because of the fact that it wants to store individual patches for no particularly good reason¹. However, recently I found out about the --single-debian-patch option to dpkg-source, which makes the 3.0 (quilt) format behave somewhat more like the non-native 1.0 format, which is good.

Unfortunately, "somewhat more" does not mean "entirely". For some weird reason, after converting the source to a 3.0 source package and running "dpkg-buildpackage", I find that suddenly my source tree is devoid of the patches that I'd applied to it.

I'm sure there's another option hidden somewhere to make it not do that either, but I was quickly annoyed about it enough that I didn't care anymore. I just removed the debian/source directory entirely again, instead.

Maybe I'll look into this again at some future point, but it's pretty unlikely.

¹I have all my packages stored in git with a proper Vcs-Git: header; if people really want to look at individual patches, they can just use debcheckout, kthxbye.