The 64-bit Hurd is Here! — 2026 — Blog — GNU Guix

The 64-bit Hurd is Here! — 2026 — Blog — GNU Guix
The 64-bit Hurd is Here!
Janneke Nieuwenhuizen, Yelninei — March 1, 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:
The
build daemon fails when invoking
guix authenticate
on the
Hurd
bug was fixed. This was our
most pressing problem as it meant that we could not keep our
substitutes up to date. It took 15 comments and 13 weeks to get it
resolved. Phew!
Installer support for
(cross)-installing the
Hurd
. Also adding developer
support for running the installer directly from the source tree;
Guix 1.5.0 lets you
install the Hurd on bare
metal
Fix
tests in the Shepherd
Update
hurd to 0.9.git20250420, gnumach to
1.8+git20250304
Add
support for a cross-built
gnumach
, allowing the removal
of an ugly workaround when cross-building for the Hurd.
Update
rumpkernel to
0-20250111
Support for
different childhurd
types
, a.k.a.
64-bit
childhurds in da
house
The syslogd used by default is now from the Shepherd
streamio,
gnumach
, and
the
Shepherd
, to make
the kernel log work.
Update
hurd to 0.9.git20251029, gnumach: to
1.8+git20250731
Now that the
go-team
branch has been merged,
gccgo now
works
(native only).
Fix
proc server for zombie
processes
which caused a
shepherd test to fail.
Fix all the dependencies of the
guix
package, again:
libgit2 tests
dbus, opensp, po4a
Resurrect
password hashing
Installer:
Fixes for the
Hurd
Installer:
More clearly mark the Hurd as
experimental
Installer:
Add Hurd x86_64 as an
option
. This took 15
comments, uncovering and fixing several bugs.
Add
support for
x86_64-gnu
, aka the 64-bit
Hurd
. The initial patch
set consisted of 31 patches. This patch
set
took
four
iterations and
208
messages
before its
final
58 patches
were merged to
`core-packages-team'. Janneke writes: "Lo and behold, the 64-bit
Hurd boots! Again, thanks to the help from the kind folks over at
libera #hurd and their excellent work. Do something like:"
./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...
Request for
merging "core-packages-team"
branch
: 247 commits, took
114
comments
weeks
and 24 iterations with
247 commits from 9
people
before presenting the initial merge.
The actual
merge
"core-packages-team"
85 more commits to a total of 332, by 17 people and 27 weeks
before actual merge. 173 packages with build fixes to relax
GCC 14's strictness, 109 package updates to fix build with GCC 14.
With this all in place we can
have ci build a 64-bit hurd
image
, and
Report
what packages still need to be
fixed
for that image to build.
For convenience we
added
i586-pc-gnu
and
x86_64-pc-gnu
cross
toolchains
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
Add
cross-compilation support for the
x86_64-pc-gnu
target, aka
64-bit
Hurd
and then
Add
support for
x86_64-gnu
, aka the 64-bit
Hurd
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
Update
the gcc cross compiler to
GCC 14
(one, simple commit), and
Fix all cross builds (initially
"just" 23
commits
).
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
Use
gcc-14, gcc-toolchain-14 on the 64-bit
Hurd
This, however does not support offloading. For that,
we would need
to
Update
gcc, gcc-toolchain, libgccjit to 14
, and
Make sure that all
packages in
commencement.scm
successfully build natively on
x86_64-hurd
, which took
only
some 35
commits
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:
(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:
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:
Freedom #0
: the
freedom to run the program as you wish, for any purpose.
Freedom from the System Administrator.
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:
Have
guix pull
from a non-local URL work on the Hurd,
Have
guix system reconfigure
work on the Hurd,
Figure out WiFi support with NetDDE (and add it to installer!),
Figure out WiFi support with RumpNET (and add it to installer!),
An
isolated build environment
(or better wait for, err, contribute to the
Guile build
daemon
?),
An installer running the Hurd, and,
Packages, packages, packages!
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:
Audio support
(this was
sponsored by
NLnet
, thanks!),
RumpNET
SMP
Journaling for
ext2
AArch64
RISC-V
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
).
Related topics:
GNU/Hurd
Unless otherwise stated, blog posts on this site are
copyrighted by their respective authors and published under the terms of
the
CC-BY-SA 4.0
license and those of the
GNU Free Documentation License
(version 1.3 or later, with no Invariant Sections, no
Front-Cover Texts, and no Back-Cover Texts).