Title: Hurd Debian-Installer (draft)

Student: Jeremie Koenig <jk@jk.fr.eu.org>, jkoenig@{freenode,oftc}

Abstract: Debian GNU/Hurd is currently installed either using outdated CD images, or from an existing Debian GNU/Linux system using the 'crosshurd' package. The goal of this project is to modify debian-installer and the related packages to produce working Debian GNU/Hurd installation images.


I'm a 25 years old Computer Science student in Strasbourg (France), currently finishing my Licence (more or less equivalent to a bachelor's degree I think), after some years of interruption.

In particular I worked for some time as a developer on a Debian-based product (an "embedded" backup server with a web interface). This involved creating custom packages and modifying existing ones, automating the system's administration and installation, as well as some C, Perl, PHP and C# programming. Though the work in itself was fun and went rather smoothly, it was not manageable as a part-time job so I had to quit to resume my studies.

I have never been a regular Debian contributor, but I have used it for quite some time (see the list of bugs I reported) and am familiar with the developer tools. I have also done some debian-installer work in the past, namely helping with "oldworld" Macintosh support. I had to tweak the d-i image build scripts, package the miBoot bootloader and create the rsrce package (used to configure miBoot). Unfortunately, there were legal problems with miBoot and the Macintosh boot sector which the floppy used, so my work could not be completely integrated.

As for hurd I am less familiar with its guts, but I am enthusiastic about its overall design and I had tried it in the past. Preparing this application also involved some looking under the hood and tinkering with it, so I am confident that I would be able to acquire the necessary knowledge without too much of a hassle.

Project overview

I would work on a native debian-installer port for Hurd. Colin Watson and Samuel Thibault have already done some work in this direction, but much remains. Besides the installer itself, the project would involve at least ?BusyBox, GNU Mach and Hurd. Furthermore, I intend to coordinate with the kFreeBSD people and come up with generic solutions for non-Linux systems whenever possible.

Benefits to Debian

I believe that Debian, the universal operating system, benefits from non-Linux ports in general:

More specifically, a Hurd debian-installer would be an important step towards making hurd-i386 a viable Debian architecture (though, admittedly, lots of work would remain). Making debian-installer less tied to a particular kernel would benefit non-Linux Debian architectures in general. Deliverables

My work would primarily consist of changes to existing software. I would submit them as I go, as patches against Debian packages and upstream where appropriate. I would also keep track of them to submit to Google after GSoC is over.

Project details

Current status

Samuel Thibault has some packages and patches which can be used to build "monolithic" debian-installer images, which at some point he could boot into a shell. I have fixed a bug in ext2fs which prevents them from booting but as of 2010-04-06, another problem with the bootstrap process remains (namely, it hangs after the exec server is started by ext2fs.)


I have started working on "clean" patches for porting busybox. My first patches have been accepted upstream with some changes and the source from the upstream git repository builds on Hurd with a minimal config. However more applets will probably need to be ported as I progress with the rest of the installer.

In any case, some applets will need to be disabled in the Debian package on Hurd and kFreeBSD. This could be done either by using system-specific configuration files in the Debian package, or by disabling the relevant applets in the build system using KConfig dependencies.

GNU Mach

Mach will need to support using some of its multiboot modules as initial ramdisks. I have had an occasion to wander around the code for iopl and the "driver" part for this does not seem too hard.

The user interface might be fitted into the boot script language, for instance a $(use-as-initrd) statement on a module's command line would trigger its usage as a ramdisk device. GRUB could decompress the initrd before Mach uses it, so leaving some space on it and using it read-write would not be a problem.


The ext2fs translator only support filesystems with 4KB blocks right now. On the other hand, genext2fs uses a fixed block size of 1024. The problem could be attacked on either side, but the genext2fs route seems much more simple. Samuel Thibault has a patch which changes the hardwired #define from 1024 to 4096, and sets the superblock's "creator OS" field to a system-specific value. In the longer term, however, these would need to be turned into a command-line options.


Crosshurd currently does some magic in the "native-install" script to set up translators on a newly installed system. This magic would need to be moved into the hurd package's postinst script so that it happens during d-i installations.

I suspect udeb tuning and further changes might prove necessary as well. (for instance there are currently workarounds for the installer in the Debian package's libstore bootstrap code and I strongly suspect that they will need some changes or cleaning up).

Network configuration

Apparently, netcfg has had Hurd support for some time (r548, by David Whedon starts it, the more recent r62649 by Samuel Thibault adds some fixes). However, I'm not sure that DHCP is supported, which it also isn't in a straightforward way on an installed Hurd system, as I understand it.

So the situation would need to be reviewed and support for configuring DHCP both during the install and on the target system would need to be implemented.


As I understand it, Hurd only supports ext2 as its root filesystem (for which it needs support for passive translators), and more generally only has a subset of the filesystems which Linux understands. Furthermore, as mentioned above for genext2fs, it needs special options on filesystem creation. Partman would have to be modified to stay within these constraints on Hurd installations.

Bootloader installation

[TODO: review the situation, report the bug in os-detect]

Multilingual console

The Hurd console has some UTF-8 support and its VGA driver can use any 512 glyphs at once in a dynamic fashion. So while I don't expect it to handle bidi or large glyphs, I believe it could be used for a fair number of languages nontheless.

On the other hand, the VGA driver uses BDF fonts, so a udeb similar to bterm-unifont would have to be created. Also, the keyboard driver does not support any kind of keymaps so this would need to be implemented, and integrated with kdb-chooser and read from /etc/default/keyboard-configuration.

Installation media

Right now, only the "netboot" and "monolithic" image types have some hurd-specific configuration, and only "monolithic" can be built (due to missing udeb deps on "netboot", IIRC). [TODO: reword and complete: Once a basic installer is working, getting the same variety in the boot images as is available for Linux would be ...]

Graphical installer

Though it's somewhat sluggish, Xorg runs on Hurd, and porting the graphical installer would be great for languages not supported by the Hurd console. However I have not reviewd the situation in depth.

Project schedule



I expect to be able (and would be more than willing) to travel to Debconf 10. However I'm on a tight budget at the moment so I would need sponsoring for the travel and housing costs.

Other plans

I don't have any other other plans for this summer and I expect to be able to work on this project full-time for the complete duration of the GSoC program. My exams should be finished by May 21, so I don't expect them to be a problem either.

After GSoC

I'm quite fond of Debian, both as an operating system and as an organization, so I hope that a participation to GSoC would be the foot in the door of my continued involvement :-) In any case, I expect to be able to maintain the code I would have produced.