The 64-bit Hurd is Here!

March 01, 2026

Fifteen months have passed since our last Guix/Hurd on a Thinkpad X60 post and a lot has happened with respect to the Hurd.

And most of you will have guessed, unless you skipped the title of this post, the rumored x86_64 support has landed in Guix!

Here is a not-so-short overview of our Hurd work over the past 1.5 years:

./pre-inst-env guix system image --image-type=hurd64-qcow2 \
  gnu/system/examples/bare-hurd64.tmpl

Pushed a `core-packages-team' with (this one) GCC 14 commit.  Let the
fun begin :)

We had a lot of fun...

Summarizing, building the Guix manifest for the 32-bit Hurd (i586-gnu) should work really well. Sadly, for the 64-bit Hurd (x86_64-gnu) is still a bit problematic as some tests in e.g., openssl, python, cmake, .... hang. This is still under investigation.

What Took You So Long?

We're so glad you asked! Usually, adding a new architecture should just take a couple of commits:

pretty neat, right? So, what's the story with the 64-bit Hurd? There are two problems: 64-bit Hurd support was added in GCC 14, while Guix was still at GCC 11. This means we "only" had to

The second step involves building for all architectures and fixing all breakage. Sometimes, fixing one architecture breaks another.

When Guix supported cross-building with GCC 14, and supported the 64-bit Hurd, we could create and boot a 64-bit childhurd. After that, we could start building 64-bit Hurd packages...but only after also

This, however does not support offloading. For that, we would need to:

This can simply be verified by building the hello package:

guix build --system=x86_64-gnu hello

However, GCC 14 is not a regular update: it is waaay more strict with respect to C code compilation. This means that, before actually switching, we had to fix 173 package builds and update another 109 packages to not break all of Guix. This took a total of 17 people and 35 weeks to complete.

You can understand that we are excited that the NLnet Foundation has been sponsoring this work!

Installing and Using the 64-bit Hurd

Easiest is to change your 32-bit childhurd definition into 64-bit, by adding

(type 'hurd64-qcow2)

to your hurd-vm-configuration. And if you don't have a hurd-vm-configuration yet?. Easy, in that case just add

(use-service-modules virtualization)
[..]
(hurd-vm-configuration
  (type 'hurd64-qcow2))

into your your hurd-vm-service-type definition[^0]. And if you don't have a hurd-vm-service-type yet? Easy, in that case just add

(use-service-modules virtualization)
[..]
(service hurd-vm-service-type
         (hurd-vm-configuration
           (type 'hurd64-qcow2)))

to your operating system definition. Reconfigure your system and you'd be able to:

This 64-bit Hurd is fully operational

(if you don't have a childhurd definition in your ~/.ssh/config you will have to use something like: ssh -p 10022 root@localhost[^1]).

And if you don't have a Guix operating system definition...The 64-bit Hurd is now an option in the installer:

Installer kernel page

and can be installed in a VM. Make sure to use --machine q35 with qemu.

To build a disk image for a virtual machine, do:

./pre-inst-env guix system image --image-type=hurd64-qcow2 \
    gnu/system/examples/bare-hurd64.tmpl

You may run it like so:

guix shell qemu -- qemu-system-x86_64 -m 2048 -M q35       \
  --enable-kvm                                             \
  --device e1000,netdev=net0                               \
  --netdev user,id=net0,hostfwd=tcp:127.0.0.1:10022-:2222  \
  --snapshot                                               \
  --hda /gnu/store/...-disk-image

(note that the 64-bit Hurd does not seem to show a login prompt)

and use it like:

ssh -p 10022 root@localhost
guix build -e '(@@ (gnu packages commencement) gnu-make-boot0)'

or even, if you build the image with at least --image-size=3G:

guix build hello

RumpNET Support

Upstream has added support for Intel i8254x Gigabit Ethernet using RumpNET.

Damien Zammit wrote:

This adds a working rump driver for /dev/wmX cards, which are Intel i8254x Gigabit Ethernet devices. (See man.netbsd.org for "wm(4)") This should be easily extended to support other NICs by contributing some makefile foo to netbsd/rump.

Example usage[^2]:

settrans -fgap /dev/rumpnet /hurd/rumpnet
settrans -fgap /dev/wm0 /hurd/devnode -M /dev/rumpnet wm0
settrans -fgap /servers/socket/2 /hurd/pfinet -i /dev/wm0
ifup /dev/wm0

With our updated hurd and rumpkernel packages, this should be available in Guix now too. Please let us know if you got it to work! (If you tried and didn't get it to work, we'd also like to know!)

Status

One of the most frequently asked questions is probably: Does X work on the Hurd yet? The canonical answer to that question is: Please read the GNU/Hurd FAQ.

A good summary of the current status was presented by Samuel Thibault in his GNU/Hurd progress at FOSDEM'26, in which he also makes compelling arguments for the Hurd, such as: Freedom from the system administrator and sharing the GNU heritage and values it's no coincidence that Guix also solves a part of that problem, allowing any user to install packages.

Debian GNU/Hurd has been a reality for some years now, reaching 75% of Debian packages being available for the Hurd.

As a comparison, in Guix only about 1.7% (32-bit) and 0.9% (64-bit) of packages are available for the Hurd. These percentages fluctuate a bit but continue to grow (both grew with a couple tenth percent point during the preparation of this blog post), and as always, might grow faster with your help.

So while Guix GNU/Hurd has an exciting future, please be aware that it lacks many packages and services, including Xorg.

If you would simply like to install the Hurd on bare metal running your favorite window manager (e.g.: i3, icewm, etc.) or lightweight desktop environment (Xfce) right now, then installing Debian GNU/Hurd is a good choice. Though we hope to catch up to them soon!

Last October, the 64-bit Hurd was reported to run on bare metal. Now that Guix 1.5.0's installer also lets you install the Hurd on bare metal, we'd be thrilled to year from you if you manage to replicate this!

What's Next?

In an earlier post we tried to answer the question “Why bother with the Hurd anyway?” An obvious question because it is all too easy to get discouraged, to downplay or underestimate the potential social impact of GNU and the Hurd.

Echoing Samuel Thibault's talk we would like to add: because it offers a better:

guix pull is known to work but only by pulling from a local branch doing something like:

mkdir -p src/guix
cd src/guix
git clone https://git.guix.gnu.org/guix.git master
cd master
git branch keyring origin/keyring
guix pull --url=$HOME/src/guix/master

kinda like we did it in the old days.

Other interesting task for Guix include:

We tried to make Hurd development as easy and as pleasant as we could. As you have seen, things start to work pretty nicely and there is still plenty of work to do in Guix. In a way this is “merely packaging” the amazing work of others. Some of the real work that needs to be done and which is being discussed and is in progress right now includes:

With the exception maybe of adding RumpNET NICs, these tasks look daunting, and indeed that’s a lot of work ahead. But the development environment is certainly an advantage. Take an example: surely anyone who’s hacked on device drivers or file systems before would have loved to be able to GDB into the code, restart it, add breakpoints and so on—that’s exactly the experience that the Hurd offers. As for Guix, it will make it easy to test changes to the micro-kernel and to the Hurd servers, and that too has the potential to speed up development and make it a very nice experience.

SMP support for the 64-bit Hurd

During the preparation of this blog post a patch set fixing SMP for the 64-bit Hurd, (well, gnumach actually) was presented by Damien Zammit. So most probably we'll have 64-bit multiprocessing real soon now! It seems however, that we will need new bootstrap binaries for that.

Join #guix and #hurd on libera.chat or the mailing lists and get involved!

Footnotes

[0]: Note: with an up-to-date guix this is no longer necessary!
Actually, as the 64-bit Hurd uses rumpdisk exclusively, and gnumach by default uses still it builtin IDE drivers, we also need to tell gnumach about that by adding the (kernel-arguments '("noide")).

(use-service-modules virtualization)
[..]
(hurd-vm-configuration
  (type 'hurd64-qcow2)
  (os (operating-system
        (inherit %hurd-vm-operating-system)
        (kernel-arguments '("noide")))))

We expect this to be the the default in the future.

[1]: You may have to override your childhurd's openssh-service definition, something like

(services
 (modify-services (operating-system-user-services %hurd-vm-operating-system)
   (openssh-service-type
    config =>
    (openssh-configuration
     (inherit config)
     (authorized-keys `(("root"
                         ,(local-file "/home/janneke/.ssh/janneke.pub"))))))))

but you can also take inspiration from the bare-hurd64.tmpl template.

[2]: Note that while is comes straight from a commit to the Hurd git repository, this is a Debian-specific recipe, Guix does not have ifup, and per this updated wiki page there's probably extra networking interface configuration needed too (in Debian you're intstructed to -- imperatively -- edit /etc/network/interfaces).