{
"$type": "site.standard.document",
"bskyPostRef": {
"cid": "bafyreibpmsnllbgzs3xrpi76gofwwel7sypw7d4vbzu34qkb3l2h4374iq",
"uri": "at://did:plc:iuoqosr26amzfcpxojzct3gx/app.bsky.feed.post/3mfyiohnkbhx2"
},
"path": "/blog/2026/the-64-bit-hurd//",
"publishedAt": "2026-03-01T10:09:02.149Z",
"site": "https://guix.gnu.org",
"tags": [
"Guix/Hurd on a Thinkpad X60",
"the Hurd",
"rumored x86_64 support",
"build daemon fails when invoking `guix authenticate` on the Hurd",
"(cross)-installing the Hurd",
"install the Hurd on bare metal",
"tests in the Shepherd",
"hurd to 0.9.git20250420, gnumach to 1.8+git20250304",
"support for a cross-built gnumach",
"rumpkernel to 0-20250111",
"different childhurd types",
"64-bit childhurds in da house",
"streamio, gnumach",
"the Shepherd",
"hurd to 0.9.git20251029, gnumach: to 1.8+git20250731",
"gccgo now works",
"proc server for zombie processes",
"libgit2 tests",
"dbus, opensp, po4a",
"password hashing",
"Fixes for the Hurd",
"More clearly mark the Hurd as experimental",
"Add Hurd x86_64 as an option",
"support for `x86_64-gnu`, aka the 64-bit Hurd",
"set",
"took",
"four",
"208 messages",
"final 58 patches",
"merging \"core-packages-team\" branch",
"114 comments",
"8 weeks",
"247 commits from 9 people",
"merge \"core-packages-team\"",
"have ci build a 64-bit hurd image",
"what packages still need to be fixed",
"added `i586-pc-gnu` and `x86_64-pc-gnu` cross toolchains",
"a couple of commits",
"cross-compilation support for the `x86_64-pc-gnu` target, aka 64-bit Hurd",
"added in GCC 14",
"the gcc cross compiler to GCC 14",
"\"just\" 23 commits",
"gcc-14, gcc-toolchain-14 on the 64-bit Hurd",
"we would need to",
"gcc, gcc-toolchain, libgccjit to 14",
"packages in `commencement.scm`",
"only some 35 commits",
"waaay more strict",
"total of 17 people and 35 weeks",
"NLnet Foundation",
"sponsoring this work",
"`childhurd` definition",
"sure to use `--machine q35`",
"added support for Intel i8254x Gigabit Ethernet",
"most frequently asked questions",
"GNU/Hurd FAQ",
"GNU/Hurd progress",
"FOSDEM'26",
"Debian GNU/Hurd",
"1.7% (32-bit)",
"0.9% (64-bit)",
"installing Debian GNU/Hurd",
"was reported to run",
"an earlier post",
"all too easy to get discouraged",
"Freedom #0",
"isolated build environment",
"Guile build daemon",
"Audio support",
"NLnet",
"RumpNET",
"SMP",
"Journaling for `ext2`",
"AArch64",
"RISC-V",
"a patch set fixing SMP for the 64-bit Hurd",
"will need new bootstrap binaries",
"`libera.chat`",
"mailing lists"
],
"textContent": "Fifteen months have passed since our last Guix/Hurd on a Thinkpad X60 post and a lot has happened with respect to the Hurd.\n\nAnd most of you will have guessed, unless you skipped the title of this post, the rumored x86_64 support has landed in Guix!\n\nHere is a not-so-short overview of our Hurd work over the past 1.5 years:\n\n * 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!\n\n * 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.\n\n * Fix tests in the Shepherd.\n\n * Update hurd to 0.9.git20250420, gnumach to 1.8+git20250304.\n\n * Add support for a cross-built gnumach, allowing the removal of an ugly workaround when cross-building for the Hurd.\n\n * Update rumpkernel to 0-20250111.\n\n * Support for different childhurd types, a.k.a. 64-bit childhurds in da house.\n\n * The syslogd used by default is now from the Shepherd streamio, gnumach, and the Shepherd, to make the kernel log work.\n\n * Update hurd to 0.9.git20251029, gnumach: to 1.8+git20250731.\n\n * Now that the `go-team` branch has been merged, gccgo now works (native only).\n\n * Fix proc server for zombie processes which caused a shepherd test to fail.\n\n * Fix all the dependencies of the `guix` package, again:\n\n * libgit2 tests,\n * dbus, opensp, po4a,\n * Resurrect password hashing.\n\n * Installer: Fixes for the Hurd.\n\n * Installer: More clearly mark the Hurd as experimental.\n\n * Installer: Add Hurd x86_64 as an option. This took 15 comments, surfacing and fixing several bugs.\n\n * Add support for `x86_64-gnu`, aka the 64-bit Hurd. The an initial patch set of 31 patches. This patch set 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:\"\n\n\n\n\n\n ./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 :)\n\nWe had a lot of fun...\n\n * Request for merging \"core-packages-team\" branch: 247 commits, took 114 comments 8 weeks and 24 iterations with 247 commits from 9 people before presenting the initial merge.\n\n * 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.\n\n * With this all in place we can have ci build a 64-bit hurd image, and\n\n * Report what packages still need to be fixed for that image to build.\n\n * For convenience we added `i586-pc-gnu` and `x86_64-pc-gnu` cross toolchains.\n\n\n\n\nSummarizing, 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.\n\n# What Took You So Long?\n\nWe're so glad you asked! Usually, adding a new architecture should just take a couple of commits:\n\n * Add cross-compilation support for the `x86_64-pc-gnu` target, aka 64-bit Hurd, and then\n * Add support for `x86_64-gnu`, aka the 64-bit Hurd.\n\n\n\npretty 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\n\n * Update the gcc cross compiler to GCC 14 (one, simple commit), and\n * Fix all cross builds (initially \"just\" 23 commits).\n\n\n\nThe second step involves building for all architectures and fixing all breakage. Sometimes, fixing one architecture breaks another.\n\nWhen 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\n\n * Use gcc-14, gcc-toolchain-14 on the 64-bit Hurd\n\n\n\nThis, however does not support offloading. For that, we would need to:\n\n * Update gcc, gcc-toolchain, libgccjit to 14, and\n\n * Make sure that all packages in `commencement.scm` successfully build natively on `x86_64-hurd`, which took only some 35 commits.\n\n\n\n\nThis can simply be verified by building the `hello` package:\n\n\n guix build --system=x86_64-gnu hello\n\nHowever, 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.\n\nYou can understand that we are excited that the NLnet Foundation has been sponsoring this work!\n\n# Installing and Using the 64-bit Hurd\n\nEasiest is to change your 32-bit childhurd definition into 64-bit, by adding\n\n\n (type 'hurd64-qcow2)\n\nto your `hurd-vm-configuration`. And if you don't have a `hurd-vm-configuration` yet?. Easy, in that case just add\n\n\n (hurd-vm-configuration (type 'hurd64-qcow2))\n\ninto your your `hurd-vm-service-type` definition! And if you don't have a `hurd-vm-service-type` yet?. Easy, in that case just add\n\n\n (service hurd-vm-service-type (hurd-vm-configuration (type 'hurd64-qcow2)))\n\nto your operating system definition. Reconfigure your system and you'd be able to:\n\n(if you don't have a `childhurd` definition in your `~/.ssh/config` you will have to use: `ssh root@localhost:10022`).\n\nAnd if you don't have a Guix operating system definition...The 64-bit Hurd is now an option in the installer:\n\nand can be installed in a VM. Make sure to use `--machine q35` with qemu.\n\nTo build a disk image for a virtual machine, do:\n\n\n ./pre-inst-env guix system image --image-type=hurd64-qcow2 \\ gnu/system/examples/bare-hurd64.tmpl\n\nYou may run it like so:\n\n\n 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\n\n(note that the 64-bit Hurd does not seem to show a login prompt)\n\nand use it like:\n\n\n ssh -p 10022 root@localhost guix build -e '(@@ (gnu packages commencement) gnu-make-boot0)'\n\nor even, if you build the image with at least --image-size=3G:\n\n\n guix build hello\n\n# RumpNET Support\n\nUpstream has added support for Intel i8254x Gigabit Ethernet using RumpNET.\n\nDamien Zammit wrote:\n\n> 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.\n\nExample usage:\n\n\n 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\n\nWith 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!)\n\n# Status\n\nOne 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.\n\nA good summary of current status was presented by Samuel Thibault in his GNU/Hurd progress at FOSDEM'26, in which he also makes a 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.\n\nDebian GNU/Hurd has been a reality for some years now, reaching 75% of Debian packages being available for the Hurd.\n\nAs 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.\n\nSo while Guix GNU/Hurd has an exciting future, please be aware that it lacks many packages and services, including Xorg.\n\nIf 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!\n\nLast 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!\n\n# What's Next?\n\nIn 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.\n\nEchoing Samuel Thibault's talk we would like to add: because it offers a better:\n\n * Freedom #0: the freedom to run the program as you wish, for any purpose.\n * Freedom from the System Administrator.\n\n\n\n`guix pull` is known to work but only by pulling from a local branch doing something like:\n\n\n 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\n\nkinda like we did it in the old days.\n\nOther interesting task for Guix include:\n\n * Have `guix pull` from a non-local URL work on the Hurd,\n * Have `guix system reconfigure` work on the Hurd,\n * Figure out WiFi support with NetDDE (and add it to installer!),\n * Figure out WiFi support with RumpNET (and add it to installer!),\n * An isolated build environment (or better wait for, err, contribute to the Guile build daemon?),\n * An installer running the Hurd, and,\n * Packages, packages, packages!\n\n\n\nWe 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:\n\n * Audio support (this was sponsored by NLnet, thanks!),\n * RumpNET,\n * SMP,\n * Journaling for `ext2`,\n * AArch64,\n * RISC-V.\n\n\n\nWith 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.\n\n#### SMP support for the 64-bit Hurd\n\nDuring 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.\n\nJoin `#guix` and `#hurd` on `libera.chat` or the mailing lists and get involved!",
"title": "The 64-bit Hurd is Here!",
"updatedAt": "2026-03-01T08:48:28.000Z"
}