Alternative view: by date.

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: debian

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…

  • buildd.debian.org 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 libnss_dns.so.2, 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: debian

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 http://git.mraw.org/ (git clone git://git.mraw.org/ipc-gimpfu).

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

Posted @ 29/06/2013 Tags: debian

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: debian

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

Posted @ 30/12/2012 Tags: debian

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).

Wanted!

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: debian

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)$!) {
            $package=$1;
    }
    

    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: debian

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: debian

While I’m not a big fan of clicky-clicky applications, I find it quite nice to be able to select some WEP/WPA settings in a GUI (as opposed to configuring wpa_supplicant manually) once in a while (new home, new couch by a friend’s, new phone), and be done with it forever.

Having mostly used Xfce over the years, I naturally came to trying out Wicd around 2006 (according to Wikipedia), and it looked like it did the job. It’s been on all my laptops since then, and things were quite fine… until the last laptop switch. For some (to be determined) reasons, that one comes up with a soft-blocked (rfkill) wireless LAN, which makes Wicd the biggest pain I have ever experienced as far as networking is concerned (see 4th bug report below).

So I finally decided to try out that network-manager thing people apparently love to hate.

A few bugs were filed in the process:

  • #692413: wicd-daemon: /etc/init.d/wicd stop doesn’t kill wpa_supplicant

  • #692414: network-manager: /etc/init.d/network-manager stop leaves wpa_supplicant behind

  • #692417: wicd-daemon: Continuously, ridiculously runs ifconfig/iwconfig

  • #692418: wicd-daemon: Fails to automatically (re)connect after rfkill unblock

I think nm-applet is the only Gtk3 application I have, meaning slightly bad visuals (no integration with the current Gtk2 theme for other applications), but besides that, everything is now running smoothly.

Bottom line: contrary to Wicd, NetworkManager just works!

I can’t tell for sure since I’m not using Gnome, but I’m not sure why somebody would want to use Wicd there as it’s clearly inferior on a technical level. Maybe something about the GUI/CLI? At least NetworkManager knows about netlink sockets, doesn’t waste resources through useless polling, and is able to figure out when connections need kicking. That one just does its job.

What triggered this Wicd→NetworkManager switch is a look at the linux source, which reminded me of some strange polling noticed while playing around with auditd, as mentioned in #692417; that and the “no network at boot-up unless one triggers several actions in a Wicd client” bit.

Posted @ 06/11/2012 Tags: debian

Problem #2: How to add a wireless module to a d-i image?

Slightly longer version: As reported in #686605, a whole wireless module family is missing from the linux kernel udebs, meaning they’re missing from the d-i images. Please note the hypothesis here is that the regular linux kernel images contain the relevant modules, only the udebs don’t.

Recipe #2: Craft a local udeb!

  1. The following assumes one is interested in adding a wireless module, but that can be adapted to other module families. The relevant udeb base name is nic-wireless-modules.
  2. When it comes to linux kernel modules, picking the right ones is important, so one has to consider the ABI. Right now, the current ABI in testing is 3.2.0-3-amd64. The complete udeb name is therefore nic-wireless-modules-3.2.0-3-amd64-di.
  3. If you’re running a kernel with the same ABI, all good, relevant modules should be available under /lib/modules/$(uname -r), which is what will be assumed below. Otherwise, one would have to download a proper linux-image-$ABI package, and extract it into a temporary directory to grab the wanted module(s).
  4. Determine the relevant module and its dependencies. As an example, I’ll pick a Realtek module: rtl8192cu.ko. If it’s loaded, one can use the following to detect its dependencies:

    $ lsmod|grep rtl8192cu
    rtl8192cu              78863  0
    rtlwifi                81350  1 rtl8192cu
    rtl8192c_common        52602  1 rtl8192cu
    mac80211              192768  4 iwlwifi,rtl8192c_common,rtlwifi,rtl8192cu
    cfg80211              137140  3 mac80211,iwlwifi,rtlwifi
    usbcore               128498  7 ehci_hcd,usbhid,uvcvideo,rtlwifi,rtl8192cu
    

    But it isn’t even needed to load the module to get those dependencies:

    $ /sbin/modinfo /lib/modules/3.2.0-3-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko|grep ^depends
    depends:        rtlwifi,mac80211,rtl8192c-common,usbcore
    

    Compared to what the d-i image contains, only rtlwifi and rtl8192c-common are missing.

  5. Fetch the udeb using http://packages.debian.org/ or browsing your favourite mirror if you know the paths by heart.

  6. Extract the udeb into a temporary data/ directory, along with its meta data:

    dpkg -x nic-wireless-modules-3.2.0-3-amd64-di_3.2.23-1_amd64.udeb data
    dpkg --control nic-wireless-modules-3.2.0-3-amd64-di_3.2.23-1_amd64.udeb data/DEBIAN
    
  7. Copy the 3 modules under the relevant subdirectory under data/.

  8. Update the version in data/DEBIAN/control, for example by adding the +local1 suffix.
  9. Build a new binary package, using fakeroot to avoid owner/group noise in the diff:

    fakeroot dpkg -b data nic-wireless-modules-3.2.0-3-amd64-di_3.2.23-1+local1_amd64.udeb
    
  10. Use debdiff to check the results:

    $ debdiff nic-wireless-modules-3.2.0-3-amd64-di_3.2.23-1*_amd64.udeb
    Files in second .deb but not in first
    -------------------------------------
    -rw-r--r--  root/root   /lib/modules/3.2.0-3-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192c-common.ko
    -rw-r--r--  root/root   /lib/modules/3.2.0-3-amd64/kernel/drivers/net/wireless/rtlwifi/rtl8192cu/rtl8192cu.ko
    -rw-r--r--  root/root   /lib/modules/3.2.0-3-amd64/kernel/drivers/net/wireless/rtlwifi/rtlwifi.ko
    
    Control files: lines which differ (wdiff format)
    ------------------------------------------------
    Version: [-3.2.23-1-] {+3.2.23-1+local1+}
    
  11. Put the resulting udeb under localudebs/ in your d-i build tree, and rebuild your image as usual. Almost-tada!

Why “almost”? Because a firmware is needed, so one can go back to the 7th step, extract the proper file (lib/firmware/rtlwifi/rtl8192cufw.bin) from the non-free firmware-realtek package, and add it under data/lib/firmware/realtek/. Rebuild the udeb, rebuild the d-i image. Then: tada!

Posted @ 01/10/2012 Tags: debian