| by Arround The Web | No comments

GNU Guix: The 64-bit Hurd is Here!

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

(hurd-vm-configuration (type 'hurd64-qcow2))

into 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

(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: ssh root@localhost:10022).

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:

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

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:

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!

Related posts:

  1. GNU Guix: GNU Guix 1.5.0 released
  2. Simon Josefsson: Container Images for Debian with Guix
  3. GNU Guix: Privilege Escalation Vulnerability
  4. GNU Guix: Meet Guix at FOSDEM

Source: Planet GNU