Alternative view: by date.

Time for a quick recap of the beginning of the Stretch release cycle as far as the Debian Installer is concerned:

  • It took nearly 3 months after the Jessie release, but linux finally managed to get into shape and fit for migration to testing, which unblocked the way for an debian-installer upload.
  • Trying to avoid last-minute fun, I’ve updated the britney freeze hints file to put into place a block-udeb on all packages.
  • Unfortunately, a recent change in systemd (implementation of Proposal v2: enable stateless persistant network interface names) found its way into testing a bit before that, so I’ve had my share of last-minute fun anyway! Indeed, that resulted in installer system and installed system having different views on interface naming. Thankfully I was approached by Michael Biebl right before my final tests (and debian-installer upload) so there was little head scratching involved. Commits were already in the master branch so a little plan was proposed in Fixing udev-udeb vs. net.ifnames for Stretch Alpha 1. This was implemented in two shots, given the extra round trip due to having dropped a binary package in the meanwhile and due to dak’s complaining about it.
  • After the usual round of build (see logs), and dak copy-installer to get installer files from unstable to testing, and urgent to get the source into testing as well (see request), I’ve asked Steve McIntyre to start building images through debian-cd. As expected, some troubles were run into, but they were swiftly fixed!
  • While Didier Raboud and Steve were performing some tests with the built images, I’ve prepared the announcement for dda@, and updated the usual pages in the debian-installer corner of the website: news entry, errata, and homepage.
  • Once the website was rebuilt to include these changes, I’ve sent the announce, and lifted all block-udeb.

(On a related note, I’ve started tweeting rather regularly about my actions, wins & fails, using the #DebianInstaller hashtag. I might try and aggregate my tweets as @CyrilBrulebois into more regular blog posts, time permitting.)

Executive summary: D-I Stretch Alpha 1 is released, time to stretch a bit!

Stretching cat

(Credit: rferran on openclipart)

Posted @ 22/07/2015 Tags: d-i

A bit of history: A while ago udeb-producing packages were getting frozen on a regular fashion, when a d-i release was about to be cut. While I wasn’t looking at the time, I can easily understand the reasons behind that: d-i is built upon many components, it takes some time to make sure it’s basically in shape for a release, and it’s very annoying when a regression sneaks in right before the installation images get built.

I took over d-i release maintenance in May 2012 and only a few uploads happened before the wheezy freeze. I was only discovering the job at the time, and I basically released whatever was in testing then. The freeze began right after that (end of June), so I started double checking things affecting d-i (in addition to or instead of the review performed by other release team members), and unblocking packages when changes seemed safe, or once they were tested.

A few uploads happened after the wheezy release and there’s already a Jessie Alpha 1 release. I was about to release Jessie Beta 1 after some fair bits of testing, a debian-installer upload, and the only remaining bits were: building installation images (hello Steve), and of course communication (mail announce and website update).

Unfortunately a new upstream release reached testing in the meanwhile, breaking the installer in several ways. I’ll give details below, of course not because I want to point finger at the maintainer, but to illustrate the ramifications that a single package’s migrating to testing can induce.

  • parted 3.2-1 was uploaded on 2014-07-30 and migrated on 2014-08-05.

  • parted 3.2-2 fixed a regression reported in Ubuntu only (LP#1352252) which I also hit with images built locally after that migration.

  • I then built some images locally using fixed parted packages but then discovered that auto-lvm was still broken, which I reported in #757417.

  • After some investigation Colin confirmed some behavioral changes in this new parted release, which imply the need for an update of several other partman-* components: #757661, #757662, #757663, #757664, #757665, #757666.

  • Thankfully fixes have been added for all of those, but more testing is needed before possibly urgenting those packages so that they get into testing as soon as possible.

Since I’d like to avoid such experience in the future, I’ll probably reintroduce the old method and freeze all udeb-producing packages during next d-i releases.

So you know why it might happen. Your next question might be: “What to do when your package is getting caught in that net?”. In that case, please get in touch with both debian-release@ and debian-boot@ asking for an unblock. I’ll then review your particular package, and either let it migrate to testing, or delay it until after the release.

Update: official announcement.

Posted @ 10/08/2014 Tags: d-i

What’s up? That was the sound of a new Debian Installer release, an early Alpha 1 for the Jessie release cycle.

As usual, see the Debian Installer section of the Debian website, in particular the errata page which lists important, known issues. Then give it a try, and report bugs!

Let’s see if we can keep the debian-boot@ bug count below 1400 for a while, even if we get many new installation reports. Last weeks have been busy:

Speaking of which, if you feel like helping with the triaging effort, there’s now a bug type called “installer bugs” on UDD’s Bugs Search page. ;)

Posted @ 19/03/2014 Tags: d-i

It’s a somewhat strange feeling to spend time fixing things that broke instead of implementing new things, but it’s not like I’m a creative guy anyway…

  • went down, but it’s now up again thanks to the relevant admins. The CGI part mentioned by Philipp was fun to debug: the CGI worked when called from a shell, but not from Apache (with an apparently strange DNS resolution error). I suggested attaching it with strace, and the result was even stranger: a connection to nscd’s socket was attempted but the DNS resolution through the network wasn’t. A closer look revealed the nsswitch.conf file was read, and its configuration was OK, so what? Looking at, one could see the usual syscalls for library loading: open, read, fstat, mmap… oh wait, mmap failed with ENOMEM (Cannot allocate memory). Tollef bumped the rlimits on the Apache side, and that was it.

  • Linux kernel ABI bump notifications: they were acting weird since kernel people resumed uploading -trunk- kernels to experimental. That was identified a while ago, but since I like tested bugfixes, I actually did wait for it to happen; fixed in r68876.

  • Of course, d-i’s git repository was updated to bump the ABI from 3.10-2-* to 3.10-3-* accordingly.

  • #722939 was reported against udev-udeb since depending on a deb library isn’t a good thing when you’re an udeb binary.

  • Trying to look into d-i build failures earlier this month, I thought I managed to reproduce the issue, but that was just my misunderstanding the way apt works. Long story short, *InRelease and *Packages files are checked before they’re put under lists/; modifying the contents isn’t expected: the modification time is used to set the If-Modified-Since header when trying to fetch a new version from the server, and it’s OK to get a 304 Not Modified in that case. As a side effect, that means the files can be hand-edited, for example because you need to work around the dependency bug mentioned above, and one will still get Hit lines for all those files. If something goes wrong, one can still rm the files and start over, but that looks like a large hammer. Let’s see if the issue can get reproduced (and debugged!) later on.

For those last two points, the long term plan is:

  • To check udeb installability automatically to catch such dependency issues as early as possible.

  • To keep many more logs, so that one can still read the whole output a few weeks after the fact, and so that one can compare some logs to try and spot difference in a semi-automated fashion.

Hopefully getting this done this week (famous last words, eh?).

Posted @ 17/09/2013 Tags: d-i

Look! A tiny TARDIS-powered release, as if we were a few years back, when Perl was hype! It’s called IPC::GimpFu and abstracts talking to Gimp’s script-fu server, making it possible to run a few commands/scripts without having to care too much about Gimp’s start-up time, and without having to deal manually with the script-fu server protocol.

At the moment, it was mainly tested against a local server, and without caring much about the reply (there’s the nasty #583778 anyway), and it needs some polishing to make reports from CPAN testers greener…

Source is at (git clone git://

More on the reasons why I needed this module and those Gimp filters in a later post.

Posted @ 29/06/2013 Tags: d-i

After a release cycle longer than between each beta (which is slightly sad, but I can’t spend all my time on Debian), here comes the first release candidate of the Debian Installer for Wheezy.

The Debian Installer 7.0 RC1 announce on the website has links to relevant bug reports in the Debian BTS, and the errata page lists things you probably want to know about (including gotchas with grub-install we’ve been having for a while, now diagnosed, and hopefully fixed for the next release candidate).

According to Arwen’s sleepy attitude, it’s officially time for a nap!

Sleepy Arwen

Posted @ 17/02/2013 Tags: d-i

#696699 was already a funny bug number, but #696969 is even better. d-i FTW!

Posted @ 30/12/2012 Tags: d-i

I’ve been working on some autotesting features for d-i over the past few weeks, and I’ve started lagging behind on my debian-boot@ reading accordingly, by several hundreds of mails. Today’s gift to myself: no more unread/unanswered mails in that mailbox!

Even if I’ve prepared things for a possible d-i wheezy rc1 release around Christmas, several things weren’t ready, most notably: grub-installer. Hopefully #696615 will be fixed soonish, probably by asking where to write when /target(/boot) isn’t on (hd0).


Speaking of grub-installer, if anyone can reproduce #681227, I’m all ears! Wouter has a workaround for it (only in sid for now), but I’d very much like to track down the root cause for that one. It is supposedly reproducible with wheezy beta 4 images and with weekly builds (they use components from testing), all of those are available from the debian-installer website.

Posted @ 25/12/2012 Tags: d-i

Problem #3: How to find out what’s going on with debconf?

Slightly longer version: As reported in #679327, the grub prompt during the installation process is entitled “Configuring man-db”, which isn’t exactly great. Given man-db is a known dpkg trigger, I suspected this would be the reason for the broken title, and here’s how I debugged it.

For starters, using d-i basically means asking a lot of questions, which is implemented using the debconf mechanism. One should note that two implementations are available:

  1. the historic implementation, in Perl: debconf
  2. the C reimplementation: cdebconf

d-i uses cdebconf udebs, but joy begins when packages get installed in /target: debconf is used there. We’ll see why that matters.

Recipe #3: Set DEBCONF_DEBUG=developer and read logs!

  1. Both implementations support the DEBCONF_DEBUG environment variable. The installer supports passing that as a kernel parameter; example from the syslinux prompt: select the “Graphical install” entry, press “Tab”, remove -- quiet and put DEBCONF_DEBUG=developer there instead.

  2. Let’s look at /var/log/syslog; there’s a tail -f on it in VT4, but one can run grep and friends on it in VT2 or VT3. There, one can see what happens at the debconf level (the debconf protocol is documented in debconf-devel(7)). Tiny excerpt (timestamps removed for clarity):

    frontend: --> GET preseed/early_command
    frontend: <-- 0
    frontend: --> GET debian-installer/framebuffer
    frontend: <-- 0 true
    debconf: --> GET debconf/language
    debconf: <-- 0 en
    debconf: --> SET debconf/language en
    debconf: Setting debconf/language to en
    debconf: <-- 0 value set
    debconf: --> GET debconf/priority
    debconf: <-- 0 high
    debconf: --> GET rescue/enable
    debconf: <-- 0 false
  3. The interesting point was titles, right? So let’s look at the last TITLE occurrences:

    debconf: --> SETTITLE debian-installer/main-menu-title
    debconf: --> SETTITLE debian-installer/grub-installer/title
    in-target: debconf (developer): ----> TITLE Configuration de man-db
    debconf: --> TITLE Configuration de man-db
    in-target: debconf (developer): <-- TITLE Configuration de man-db
    in-target: debconf (developer): ----> TITLE Configuration de man-db
    in-target: debconf (developer): ----> TITLE Configuration de grub-pc
    debconf: --> TITLE Configuration de grub-pc
    in-target: debconf (developer): <-- TITLE Configuration de grub-pc
    in-target: debconf (developer): ----> TITLE Configuration de grub-pc
    in-target: debconf (developer): ----> TITLE Configuration de man-db
    debconf: --> TITLE Configuration de man-db
    in-target: debconf (developer): <-- TITLE Configuration de man-db
    in-target: debconf (developer): ----> TITLE Configuration de man-db
    in-target: debconf (developer): ----> TITLE Configuration de grub-pc
    debconf: --> TITLE Configuration de grub-pc
    in-target: debconf (developer): <-- TITLE Configuration de grub-pc
    in-target: debconf (developer): ----> TITLE Configuration de grub-pc
    debconf: --> SETTITLE debian-installer/grub-installer/title

    Bad news: the last one is about grub, so the title should be correct, right?

  4. At this point, it might be the Gtk frontend behaving strangely. It’s shipped in cdebconf-gtk-udeb, built from the cdebconf source. Let’s look:

    • src/modules/frontend/gtk/ui.c has cdebconf_gtk_update_frontend_title(), which does what the function name suggests.
    • src/modules/frontend/gtk/di.c has cdebconf_gtk_di_run_dialog(), which calls the first function.
    • src/modules/frontend/gtk/progress.c has cdebconf_gtk_show_progress() (also calls the first function), which comes with the following comments:

       /** Show the progress widgets.
         * This will actually add the widgets to the corresponding containers.
         * The main title saved when starting the PROGRESS operation will be restored
         * from the value saved when START was called.  This is needed when GO is
         * called during a PROGRESS operation.

    Now that’s something! Even if the last entry is about grub, some previous value could be restored and could be the reason for the bad behaviour (that is easily confirmed by adding some debug_printf() calls on fe->title in cdebconf, thanks to an extra "debug.h" include). Maybe that’s what needs fixing!

  5. Now it’s time to take a step back. A d-i environment is nice, but testing things can easily become a burden. Taking a random wheezy or sid chroot, and installing/removing a tiny package shipping a manpage should be enough to run into the man-db trigger. Exporting DEBCONF_DEBUG=developer there too, let’s either install or remove x11-apps (the trigger does the same job, and the debconf trace is the same), here’s the output:

    Processing triggers for man-db ...
    debconf (developer): frontend started
    debconf (developer): frontend running, package name is man-db
    debconf (developer): starting /var/lib/dpkg/info/man-db.config configure /usr/share/man
    debconf (developer): <-- VERSION 2.0
    debconf (developer): --> 0 2.0
    debconf (developer): <-- INPUT medium man-db/install-setuid
    debconf (developer): --> 30 question skipped
    debconf (developer): <-- GO
    debconf (developer): --> 0 ok
    debconf (developer): starting /var/lib/dpkg/info/man-db.postinst triggered /usr/share/man
    debconf (developer): <-- VERSION 2.0
    debconf (developer): --> 0 2.0
    debconf (developer): <-- GET man-db/auto-update
    debconf (developer): --> 0 true

    Even if one didn’t know about the cdebconf/debconf thing, the frontend started bit in the d-i syslog would have been the key: it’s only found in debconf, in the frontend script. That one has several ways to determine the package being acted on, and it finally calls:

    debug developer => "frontend running, package name is $package";
    $frontend->default_title($package) if length $package;

    Tada, that’s likely to be the issue.

  6. Tweaking that frontend script, it’s easy to make sure that the code path for this use case is:

    elsif ($ARGV[0]=~m!^.*/(.*?)\.(?:postinst|postrm|prerm)$!) {

    Since $ARGV[1] is the action being passed to the maintainer script, one can intercept the triggered action, and avoid emitting a title update in this case; I’ve therefore reassigned #679327 to the debconf package, and proposed a patch implementing that, which Joey Hess seems to find reasonable.

In my message to the bug report I wrote I actually tested it in a d-i environment, and made sure the issue had gone away. How I did that will likely be described in the next d-i hacking recipe.

Posted @ 23/12/2012 Tags: d-i

Today’s recipe:

  • a day off
  • a long night of sleep
  • acid jazz music
  • some 24 episodes
  • coffee
  • trout and pasta
  • sleepy cats

Result: Debian Installer 7.0 Beta4 release!

Speaking of which, shameless plug: I'm giving a Debian Installer talk at mini-DebConf Paris this sunday.

(Update: slides & LaTeX source for this talk.)

Posted @ 22/11/2012 Tags: d-i