joyofsource.com

The 64-bit Hurd is Here!

2026-03-01T10:00:00Z

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 8 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:

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

We're finally incooperated!

2025-08-28T12:00:00Z

Our reasonable-sourcery cooperative's website is live!

GNU Mes 0.27.1 released

2025-08-19T10:00:00Z

Mes 0.27.1 is a bug-fix release. It represents 53 commits by four people over one year. This release resurrects supports development builds with gcc-14 and adds support for using NYACC versions 0.99.0 through 2.02.2.

Enjoy!

ABOUT

GNU Mes is a Scheme interpreter and C compiler for bootstrapping the GNU System. It has helped to decimate the number and size of binary seeds that were used in the bootstrap of GNU Guix 1.0. Recently, version 0.24.2 has realized the first Full Source Bootstrap for Guix. The final goal is to help create a full source bootstrap as part of the bootstrappable builds effort for any UNIX-like operating system.

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. Mes can now be bootstrapped from M2-Planet and Mescc-Tools.

Mes + MesCC + Mes C Library can build a bootstrappable TinyCC that is self-hosting. Using this bootstrappable-tcc and the Mes C library we can build an ancient version of the GNU tools triplet: glibc-2.2.5, binutils-2.20.1, gcc-2.95.3. This is enough to bootstrap Guix for i686-linux, x86_64-linux, armhf-linux and aarch64-linux.

Mes was inspired by The Maxwell Equations of Software: LISP-1.5 -- John McCarthy page 13, Guix's source/binary packaging transparency and Jeremiah Orians's stage0, a ~500-byte self-hosting hex assembler.

DOWNLOAD

git clone git://git.savannah.gnu.org/mes.git

Here is the GNU Mes home page:
gnu.org/s/mes/

For a summary of changes and contributors, see:
git.sv.gnu.org/gitweb/?p=mes.git;a=shortlog;h=v0.27.1 or run this command from a git-cloned mes directory:

git shortlog v0.27..v0.27.1

Here are the compressed sources and a GPG detached signature:

mes-0.27.1.tar.gz
mes-0.27.1.tar.gz.sig

Use a mirror for higher download bandwidth:

mes-0.27.1.tar.gz
mes-0.27.1.tar.gz.sig

Here are the SHA1 and SHA256 checksums:

d1bb88ae1c83269599ddfc975f5d3268fb7f5596  mes-0.27.1.tar.gz
183a40ea47ea49f8a1e3bd1b9d12e676374d64d63bc79e7bc1ae7d673dfdf25d  mes-0.27.1.tar.gz

Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this:

gpg --verify mes-0.27.1.tar.gz.sig

The signature should match the fingerprint of the following key:

pub   rsa4096 2018-04-08 [SC]  
      1A85 8392 E331 EAFD B8C2  7FFB F3C1 A0D9 C1D6 5273  
uid   Janneke Nieuwenhuizen <janneke@gnu.org>

If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command.

gpg --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

As a last resort to find the key, you can try the official GNU keyring:

wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg  
gpg --keyring gnu-keyring.gpg --verify mes-0.27.1.tar.gz.sig

Alternatively, Mes can be installed using GNU Guix:

guix pull  
guix install mes

NEWS

Changes in 0.27.1 since 0.27

Core
- The pmatch-car/pmatch-cdr hack was removed.
Build
- Development build with gcc-14 is now supported.
- Using M2-Planet 1.12.0 is now supported.
- On x86-linux, using M2-Planet 1.13.0 is now supported.
- A benchmark suite was added.
- The "simple.make" build was resurrected.
- Scripts with bashisms now use bash in shebang.
Mes
- 1 New module stub: (system foreign).
- 1 New function: string-every.
- 3 New symbols: W_OK, X_OK, F_OK.
MesCC
- Using the "-Dinline=" kludge is no longer necessary.
- Building bootstrappable-tcc using 1.00.02 <= NYACC <= 2.02.2 now works.
- kernel-stat was fixed for x86_64-linux.
- Four new prototypes: strcspn, strncat, strpbrk, strspn.
Noteworthy bug fixes
- A bug was fixed in "match" to support NYACC 2.01.0.

See also bootstrappable.org.
Join bug-mes@gnu.org and #bootstrappable on irc.libera.chat for discussions.

Thanks to everyone who contributed to this release:

 2	Andrius Štikonas  
15	Ekaitz Zarraga  
35	Janneke Nieuwenhuizen  
 1	Samuel Lidén Borell

Janneke -- on behalf of the Mes developers

Guix/Hurd on a Thinkpad X60

2024-11-24T18:00:00Z

A lot has happened with respect to the Hurd since our Childhurds and GNU/Hurd Substitutes post. As long as two years ago some of you have been asking for a progress update and although there have been rumours on a new blog post for over a year, we were kind of waiting for the rumoured x86_64 support.

With all the exciting progress on the Hurd coming available after the recent (last?) merger of core-updates we thought it better not to wait any longer. So here is a short overview of our Hurd work over the past years:

Update Hurd to 3ff7053, gnumach 1.8+git20220827, and fix build failures,
A native compilation fix for gcc-boot0,
Initial rumpdisk support, more on this below, which needed to wait for:
A libc specific to Hurd, updating gnumach to 1.8+git20221224 and hurd to 0.9.git20230216,
Some 40 native package build fixes for the Hurd so that all development dependencies of the guix package are now available,
A hack to use Git source in commencement to update and fix cross build and native build for the Hurd,
Support for buiding guix natively on the Hurd by splitting the build into more steps for 32-bit hosts
Even nicer offloading support for Childhurds by introducing Smart Hurdloading so that now both the Bordeaux and Berlin build farms build packages for i586-gnu,
Locale fixes for wrong glibc-utf8-locales package used on GNU/Hurd,
More locale fixes to use glibc-utf8-locales/hurd in %standard-patch-inputs,
And even more locale fixes for using the right locales on GNU/Hurd,
A new glibc 2.38 allowing us to do (define-public glibc/hurd glibc)—i.e., once again use the same glibc for Linux and Hurd alike, and: Better Hurd support!,
Creation of hurd-team branch with build fixes, updating gnumach to 1.8+git20230410 and hurd to 0.9.git20231217,
A constructive meeting with sixteen people during the Guix Days just before FOSDEM '24 with notes that contain some nice ideas,
Another new glibc 2.39; even better Hurd support, opening the door to x86_64 support,
Yet another restoring of i586-gnu (32-bit GNU/Hurd) support,
The installer just learnt about the Hurd! More on this below, and finally,
Another set of updates: gnumach (1.8+git20240714), mig (1.8+git20231217), hurd (0.9.git20240714), netdde (c0ef248d), rumpkernel (f1ffd640), and initial support for x86_64-gnu, aka the 64bit Hurd.

NetDDE and Rumpdisk support

Back in 2020, Ricardo Wurmus added the NetDDE package that provides Linux 2.6 network drivers. At the time we didn't get to integrate and use it though and meanwhile it bitrotted.

After we resurrected the NetDDE build, and with kind help of the Hurd developers we finally managed to support NetDDE for the Hurd.. This allows the usage of the Intel 82573L Gigabit Ethernet Controller of the Thinkpad X60 (and many other network cards, possibly even WIFI). Instead of using the builtin kernel driver in GNU Mach, it would be running as a userland driver.

What sparked this development was upstream's NetBSD rumpdisk support that would allow using modern hard disks such as SSDs, again running as a userland driver. Hard disk support builtin in GNU Mach was once considered to be a nice hack but it only supported disks up to 128 GiB…

First, we needed to fix the cross build on Guix.

After the initial attempt at rumpdisk support for the Hurd it took (v2) some (v3) work (v4) to finally arrive at rumpdisk support for the Hurd, really, *really* (v5)

Sadly when actually using them, booting hangs:

start: pci.arbiter:

What did not really help is that upstream's rumpkernel archive was ridiculously large. We managed to work with upstream to remove unused bits from the archive. Upstream created a new archive that instead of 1.8 GiB (!) now “only” weighs 670 MiB.

Anyway, after a lot of building, rebuilding, and debugging and some more with kind help from upstream we finally got Rumpdisk and NetDDE to run in a Childhurd.

Initial Guix/Hurd on the Thinkpad X60

Now that the last (!) core-updates merge has finally happened (thanks everyone!), the recipe of installing Guix/Hurd has been much simpfilied. It goes something along these lines.

Install Guix/Linux on your X60,
Reserve a partition and format it for the Hurd:
```
mke2fs -o hurd -L hurd /dev/sdaX
```

In your config.scm, add some code to add GRUB menuentries for booting the Hurd, and mount the Hurd partition under /hurd:

(use-modules (srfi srfi-26)
          (ice-9 match)
          (ice-9 rdelim)
          (ice-9 regex)
          (gnu build file-systems))

(define %hurd-menuentry-regex
"menuentry \"(GNU with the Hurd[^{\"]*)\".*multiboot ([^ \n]*) +([^\n]*)")
(define (text->hurd-menuentry text)
(let* ((m (string-match %hurd-menuentry-regex text))
      (label (match:substring m 1))
      (kernel (match:substring m 2))
      (arguments (match:substring m 3))
      (arguments (string-split arguments #\space))
      (root (find (cute string-prefix? "root=" <>) arguments))
      (device-spec (match (string-split root #\=)
                     (("root" device) device)))
      (device (hurd-device-name->device-name device-spec))
      (modules (list-matches "module ([^\n]*)" text))
      (modules (map (cute match:substring <> 1) modules))
      (modules (map (cute string-split <> #\space) modules)))
 (menu-entry
  (label label)
  (device device)
  (multiboot-kernel kernel)
  (multiboot-arguments arguments)
  (multiboot-modules modules))))

(define %hurd-menuentries-regex
"menuentry \"(GNU with the Hurd[^{\"]*)\" \\{([^}]|[^\n]\\})*\n\\}")
(define (grub.cfg->hurd-menuentries grub.cfg)
(let* ((entries (list-matches %hurd-menuentries-regex grub.cfg))
      (entries (map (cute match:substring <> 0) entries)))
 (map text->hurd-menuentry entries)))

(define (hurd-menuentries)
(let ((grub.cfg (with-input-from-file "/hurd/boot/grub/grub.cfg"
                 read-string)))
 (grub.cfg->hurd-menuentries grub.cfg)))

...
(operating-system
...
(bootloader (bootloader-configuration
            (bootloader grub-bootloader)
            (targets '("/dev/sda"))
            (menu-entries (hurd-menuentries))))
(file-systems (cons* (file-system
                      (device (file-system-label "guix"))
                      (mount-point "/")
                      (type "ext4"))
                    (file-system
                      (device (file-system-label "hurd"))
                      (mount-point "/hurd")
                      (type "ext2"))
                    %base-file-systems))
...)

Create a config.scm for your Hurd system. You can get inspiration from bare-hurd.tmpl and inherit from %hurd-default-operating-system. Use grub-minimal-bootloader and add a static-networking-service-type. Something like:

(use-modules (srfi srfi-1) (ice-9 match))
(use-modules (gnu) (gnu system hurd))

(operating-system
(inherit %hurd-default-operating-system)
(bootloader (bootloader-configuration
            (bootloader grub-minimal-bootloader)
            (targets '("/dev/sda"))))
(kernel-arguments '("noide"))
...
(services
 (cons*
   (service static-networking-service-type
            (list %loopback-static-networking
                  (static-networking
                   (addresses
                    (list
                     (network-address
                      (device "eth0")
                      (value "192.168.178.37/24"))))
                   (routes
                    (list (network-route
                           (destination "default")
                           (gateway "192.168.178.1"))))
                   (requirement '())
                   (provision '(networking))
                   (name-servers '("192.168.178.1")))))
 ...)))

Install the Hurd. Assuming you have an ext2 filesystem mounted on /hurd, do something like:

guix system build --target=i586-pc-gnu vuurvlieg.hurd --verbosity=1
sudo -E guix system init --target=i586-pc-gnu --skip-checks \
 vuurvlieg.hurd /hurd
sudo -E guix system reconfigure vuurvlieg.scm

Reboot and...

Hurray!

We now have Guix/Hurd running on Thinkpad.

Guix/Hurd on Real Iron

While the initial manual install on the X60 was an inspiring milestone, we can do better. As mentioned above, just recently the installer learnt about the Hurd, right after some smaller problems were addressed, like guix system init creating essential devices for the Hurd, not attempting to run a cross-built grub-install to install Grub, soft-coding the hard-coded part:1:device:wd0 root file-system, adding support for booting Guix/Hurd more than once.

To install Guix/Hurd, first, build a 32bit installation image and copy it to a USB stick:

guix system image --image-type=iso9660 --system=i686-linux gnu/system/install.scm
dd if=/gnu/store/cabba9e-image.iso of=/dev/sdX status=progress
sync

then boot it on a not-too-new machine that has wired internet (although installation over WIFI is possible, there is currently no WIFI support for the installed Hurd to use it). On the new Kernel page:

choose Hurd. Do not choose a desktop environment, that's not available yet. On the Network management page:

choose the new Static networking service. In the final Configuration file step, don't forget to edit:

and fill-in your IP and GATEWAY:

You may want to add some additional packages such as git-minimal from (gnu packages version-control) and sqlite from (gnu packages sqlite).

If you also intend to do Guix development on the Hurd—e.g., debugging and fixing native package builds—then you might want to include all dependencies to build the guix package, see the devel-hurd.tmpl for inspiration on how to do that. Note that any package you add must already have support for cross-building.

Good luck, and let us know if it works for you and on what kind of machine, or why it didn't!

What's next?

The most pressing problem currently is that the guix-daemon fails when invoking guix authenticate on the Hurd, which means that we cannot easily keep our substitutes up to date. 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.savannah.gnu.org/git/guix.git master
guix pull --url=~/src/guix/master

kinda like we did it in the old days. Sometimes it seems that guix does not grok the sqlite store database. This is needs to be resolved but as sqlite does read it this can be easily worked around by doing something like:

mv /var/guix/db/db.sqlite /var/guix/db/db.sqlite.orig
sqlite3 /var/guix/db/db.sqlite.orig .dump > /var/guix/db/db.sqlite.dump
sqlite3 -init /var/guix/db/db.sqlite.dump /var/guix/db/db.sqlite .quit

Also, the boot process still fails to handle an unclean root file system. Whenever the Hurd has suffered an unclean shutdown, cleaning it must currently be done manually, e.g., by booting from the installer USB stick.

Upstream now has decent support for 64bit (x86_64) albeit with more bugs and fewer packages. As mentioned in the overview we are now working to have that in Guix and have made some progress:

more on that in another post. Other interesting task for Guix include:

Have guix system reconfigure work on the Hurd,
Figure out WiFi support with NetDDE (and add it to installer!),
An isolated build environment (or better wait for, err, contribute to the Guile guix-daemon?),
An installer running the Hurd, and,
Packages, packages, packages!

Audio support (this is sponsored by NLnet, thanks!),
Rumpnet,
SMP,
AArch64.

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

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

Addendum

It has been brought to our attention that people haven't heard that Debian GNU/Hurd has been a reality for some years now. 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 (eg: 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!

GNU Mes 0.27 released

2024-07-06T12:00:00Z

We are happy to announce the release of GNU Mes 0.27.

It's been only a month since the previous release mainly because most this work has been waiting for 0.26 to be released. This release represents 55 commits over 17 weeks. This release resurrects running Mes on the Hurd and adds support for using NYACC versions 0.99.0 through 1.09.4.

We are excited that the NLnet Foundation is sponsoring this work!

What's next?

Bringing the Full Source Bootstrap to NixOS. Remove indirect Guile dependencies (via Gash and Gash-Utils) from the Mes bootstrap in Guix. Support for bootstrapping gcc-4.6.4, and a Full Source Bootstrap for armhf-linux, and riscv64-linux.

Enjoy!

ABOUT

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. Mes can now be bootstrapped from M2-Planet and Mescc-Tools.

DOWNLOAD

git clone git://git.savannah.gnu.org/mes.git

Here is the GNU mes home page:
gnu.org/s/mes/

For a summary of changes and contributors, see:
git.sv.gnu.org/gitweb/?p=mes.git;a=shortlog;h=v0.27

or run this command from a git-cloned mes directory:

git shortlog v0.26.2..v0.27

Here are the compressed sources and a GPG detached signature:

mes-0.27.tar.gz
mes-0.27.tar.gz.sig

Use a mirror for higher download bandwidth:

mes-0.27.tar.gz
mes-0.27.tar.gz.sig

Here are the SHA1 and SHA256 checksums:

273ad95203efe83d0b0e8bdbce5b41cfebb316e4  mes-0.27.tar.gz  
033ee656d98cfc04a826eab27eed6e6a276d15bbb980a7cd71d00f30227aaaa8  mes-0.27.tar.gz

Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this:

gpg --verify mes-0.27.tar.gz.sig

The signature should match the fingerprint of the following key:

pub   rsa4096 2018-04-08 [SC]  
      1A85 8392 E331 EAFD B8C2  7FFB F3C1 A0D9 C1D6 5273  
uid   Jan (janneke) Nieuwenhuizen <janneke@gnu.org>

If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command.

gpg --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

As a last resort to find the key, you can try the official GNU keyring:

wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg  
gpg --keyring gnu-keyring.gpg --verify mes-0.27.tar.gz.sig

Alternatively, Mes can be installed using GNU Guix:

guix pull  
guix install mes

NEWS

Changes in 0.27 since 0.26.2

Core
- Support for running Mes on the Hurd has been resurrected.
Mes
- (ice-9 optargs) now supports lambda* #:optional with #:key.
- Define-module now handles #:version by ignoring it.
- 2 new functions: pair-for-each, with-fluids*.
- 2 new modules: (rnrs arithmetic bitwise), (srfi srfi-39).
- For Guile compatibility, (srfi srfi-39) is loaded by default.
Build
- When configuring using `--with-courage, mescc-tools are now optional.
MesCC
- MesCC now works with NYACC versions 0.99.0 to 1.09.4.
- Legacy mes-style module support was removed for NYACC.
- Legacy mes-style module support was removed for MesCC.

See also bootstrappable.org.
Join bug-mes@gnu.org and #bootstrappable on irc.libera.chat for discussions.

Janneke
[on behalf of the mes maintainers]

GNU Mes 0.26.2 released

2024-06-30T12:00:00Z

Mes 0.26.2 is a bug-fix release.

Enjoy!

ABOUT

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. Mes can now be bootstrapped from M2-Planet and Mescc-Tools.

DOWNLOAD

git clone git://git.savannah.gnu.org/mes.git

Here is the GNU Mes home page:
gnu.org/s/mes/

For a summary of changes and contributors, see:
git.sv.gnu.org/gitweb/?p=mes.git;a=shortlog;h=v0.26.2

or run this command from a git-cloned mes directory:

git shortlog v0.26.1..v0.26.2

Here are the compressed sources and a GPG detached signature:

mes-0.26.2.tar.gz
mes-0.26.2.tar.gz.sig

Use a mirror for higher download bandwidth:

mes-0.26.2.tar.gz
mes-0.26.2.tar.gz.sig

Here are the SHA1 and SHA256 checksums:

dbc1bdbcc4784555cf8afdcf6d4ab7717f3b5892  mes-0.26.2.tar.gz  
2fb8bf99f13c4b769af2f50d2dceac0c25caccc6342b65e31121456f253d0a88  mes-0.26.2.tar.gz

Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this:

gpg --verify mes-0.26.2.tar.gz.sig

The signature should match the fingerprint of the following key:

pub   rsa4096 2018-04-08 [SC]  
      1A85 8392 E331 EAFD B8C2  7FFB F3C1 A0D9 C1D6 5273  
uid   Jan (janneke) Nieuwenhuizen <janneke@gnu.org>

If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command.

gpg --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

As a last resort to find the key, you can try the official GNU keyring:

wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg  
gpg --keyring gnu-keyring.gpg --verify mes-0.26.2.tar.gz.sig

Alternatively, Mes can be installed using GNU Guix:

guix pull  
guix install mes

NEWS

Changes in 0.26.2 since 0.26.1

Build
- Make check now succeeds again for x86_64 and ARM.
Noteworthy bug fixes
- A typo was fixed in in the ARM signal.h header.

See also bootstrappable.org.
Join bug-mes@gnu.org and #bootstrappable on irc.libera.chat for discussions.

Janneke
[on behalf of the mes maintainers]

GNU Mes 0.26.1 released

2024-06-08T09:00:00Z

We are happy to announce the release of GNU Mes 0.26.1.

This release represents 57 commits by five people in 26 weeks. It brings full Gash support and many fixes for the riscv64-linux bootstrap. See the NEWS below for a brief summary.

We are excited that the NLnet Foundation is sponsoring this work!

What's next?

Support newer versions of Nyacc. Resurrect support for the Hurd. Remove indirect Guile dependencies (via Gash and Gash-Utils) from the Mes bootstrap in Guix. Support for bootstrapping gcc-4.6.4 without depending on gcc-2.95.3, and a Full Source Bootstrap for armhf-linux, and riscv64-linux. Bringing the Full Source Bootstrap to NixOS.

ABOUT

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. Mes can now be bootstrapped from M2-Planet and Mescc-Tools.

DOWNLOAD

git clone git://git.savannah.gnu.org/mes.git

Here is the GNU mes home page: https://gnu.org/s/mes/

For a summary of changes and contributors, see: https://git.sv.gnu.org/gitweb/?p=mes.git;a=shortlog;h=v0.26.1

or run this command from a git-cloned mes directory:

git shortlog v0.26..v0.26.1

Here are the compressed sources and a GPG detached signature:

https://ftp.gnu.org/gnu/mes/mes-0.26.1.tar.gz  
https://ftp.gnu.org/gnu/mes/mes-0.26.1.tar.gz.sig

Use a mirror for higher download bandwidth:

https://ftpmirror.gnu.org/mes/mes-0.26.1.tar.gz
https://ftpmirror.gnu.org/mes/mes-0.26.1.tar.gz.sig

Here are the SHA1 and SHA256 checksums:

f228703f3e6c1104d825ade5183b74ef47d6cde4  mes-0.26.1.tar.gz  
e1370d528cbfcbb477ca35e59ae2f6fb71f611f9c856330e6dcb5f2459c2fcf4  mes-0.26.1.tar.gz

Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this:

gpg --verify mes-0.26.1.tar.gz.sig

The signature should match the fingerprint of the following key:

pub   rsa4096 2018-04-08 [SC]  
      1A85 8392 E331 EAFD B8C2  7FFB F3C1 A0D9 C1D6 5273  
uid   Jan (janneke) Nieuwenhuizen <janneke@gnu.org>

If that command fails because you don't have the required public key, or that public key has expired, try the following commands to retrieve or refresh it, and then rerun the 'gpg --verify' command.

gpg --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

As a last resort to find the key, you can try the official GNU keyring:

wget -q https://ftp.gnu.org/gnu/gnu-keyring.gpg  
gpg --keyring gnu-keyring.gpg --verify mes-0.26.1.tar.gz.sig

Alternatively, Mes can be installed using GNU Guix:

guix pull  
guix install mes

NEWS

Changes in 0.26.1 since 0.26

Mes
- Running Gash is now fully supported.
- The REPL's ,use command now loads Guile-style modures.
MesCC
- The comma operator is now better supported.
- New type: ucontext_t.
  - 1 new function pathconf.
  - 2 new stubs putenv, realpath.
Noteworthy bug fixes
- A workaround was added to run Gash-Utils in the kaem bootstrap.
- A Guile-style module bug was fixed where MesCC would run twice.
- ./configure.sh can be run without using --host during bootstrap.
- srfi-43 vector-fold has been resurrected.
- The armhf build has been resurrected.
- On x86_64-linux, getdents64 is being used instead of getdents.
- MesCC now produces position-independent binaries for x86_64.
- Several RISCV-64 MesCC (signed) integer problems were fixed.
- Setjmp/longjmp for RISCV-64 on TinyCC has been fixed.
- CHAR_MAX is now depends on the signedness of char.
- intmax_t and uintmax_t were fixed for 64bit archtectures.
- A buffer-overflow for very large integers in ntoab was fixed.

Thanks to everyone who contributed to this release:

Andrius Štikonas (7)  
Ekaitz Zarraga (15)  
Janneke Nieuwenhuizen (29)  
Michael Forney (4)  
Timothy Sample (2)

See also https://bootstrappable.org.
Join bug-mes@gnu.org and #bootstrappable on irc.libera.chat for discussions.

Janneke
[on behalf of the mes maintainers]

GNU Mes 0.26 released

2023-12-03T14:00:00Z

We are happy to announce the release of GNU Mes 0.26.

It's been only a month since the previous release mainly because most this work has been waiting for 0.25 to be released. This release represents 194 commits over one year by two people. This release brings Guile module support and support for running Gash and Gash-Utils.

We are excited that the NLnet Foundation is sponsoring this work!

What's next?

Enjoy!

About

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. Mes can now be bootstrapped from M2-Planet and Mescc-Tools.

Download

git clone git://git.savannah.gnu.org/mes.git

Here are the compressed sources and a GPG detached signature[*]:

https://ftp.gnu.org/gnu/mes/mes-0.26.tar.gz  
https://ftp.gnu.org/gnu/mes/mes-0.26.tar.gz.sig

Use a mirror for higher download bandwidth:

https://ftpmirror.gnu.org/mes/mes-0.26.tar.gz  
https://ftpmirror.gnu.org/mes/mes-0.26.tar.gz.sig

Here are the SHA1 and SHA256 checksums:

581d7dba5f9749dd232a203d04175494ded0e77d  mes-0.26.tar.gz  
0f2210ad5896249466a0fc9a509e86c9a16db2b722741c6dfb5e8f7b33e385d4  mes-0.26.tar.gz

[*] Use a .sig file to verify that the corresponding file (without the .sig suffix) is intact. First, be sure to download both the .sig file and the corresponding tarball. Then, run a command like this:

gpg --verify mes-0.26.tar.gz.sig

If that command fails because you don't have the required public key, or that public key has expired, try the following commands to update or refresh it, and then rerun the 'gpg --verify` command.

gpg --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

Alternatively, Mes can be installed or updated using Guix:

guix pull
guix install mes

Changes in 0.26 since 0.25.1

Core
- Mes now has a Guile-compatible record interface.
- Mes now has a Guile-compatible hash-table interface.
- Mes now uses exceptions instead of asserts.
- Mes now supports Guile-compatible modules and variable lookup.
- The reader now supports #\fs',#\nl', and `#\np'.
- Mes now supports vectors in syntax-rules.
- Dynamic-wind was fully implemented.
- Mes now has regex support.
- Mes now supports functional record setters.
- simple-format now supports `~%'.
- Charsets can now be used in `string-index'.
- The (srfi srfi-14) module was completed.
  - 9 new modules (ice-9 ftw), (ice-9 i18n), (ice-9 receive), (ice-9 regex), (rnrs io ports), (rnrs bytevectors), (srfi srfi-2). (srfi srfi-11). (srfi srfi-37).
  - 46 new functions alist-cons, append-reverse!, call-with-port, call-with-input-file, call-with-input-string, call-with-output-file, chdir, clone-port, closedir, concatenate, drop, drop-while. environ, execle, file-system-fold, fold-matches, getpid, hash-clear!, hash-fold, hash-map->list, hash-remove!, hash-table?, link, list-matches, match-let, mkdir, opendir, partition, pipe, primitive-exit, readdir, reduce, rename-file, rmdir, seek, set-fields, span, sleep, string-concatenate-reverse, string-count, string-pad, string-pad-right, string>, string<, umask, uname, utimes, vector-fold.
- Mes now supports running Gash and Gash-Utils.
MesCC
- MesCC now uses Guile-compatible modules.
Noteworthy bug fixes
- Many bug-fixes to hygiene, string primitives, optional arguments.

Get informed, get involved

See bootstrappable.org.

Join bug-mes@gnu.org and #bootstrappable on irc.libera.chat for discussions.

Thanks to everyone who contributed to this release:

 35	Janneke Nieuwenhuizen
159	Timothy Sample

GNU Mes 0.25.1 released

2023-12-02T11:00:00Z

Mes 0.25.1 is a bug-fix release.

Enjoy!

About

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. Mes can now be bootstrapped from M2-Planet and Mescc-Tools.

Download

git clone git://git.savannah.gnu.org/mes.git

Here are the compressed sources and a GPG detached signature[*]:

https://ftp.gnu.org/gnu/mes/mes-0.25.1.tar.gz  
https://ftp.gnu.org/gnu/mes/mes-0.25.1.tar.gz.sig

Use a mirror for higher download bandwidth:

https://ftpmirror.gnu.org/mes/mes-0.25.1.tar.gz  
https://ftpmirror.gnu.org/mes/mes-0.25.1.tar.gz.sig

Here are the SHA1 and SHA256 checksums:

62b48a4771d4935840b3603e8b034886e9e5e4fd  mes-0.25.1.tar.gz  
36a2d31990026ff2b602961411922b1e8da536ac59e0dde48e8fa48e0934d70e  mes-0.25.1.tar.gz

gpg --verify mes-0.25.1.tar.gz.sig

If that command fails because you don't have the required public key, or that public key has expired, try the following commands to update or refresh it, and then rerun the gpg --verify command.

gpg --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

Alternatively, Mes can be installed or updated using Guix:

guix pull
guix install mes

Changes in 0.25.1 since 0.25

Build
- The bootstrap on x86 has been fixed:
  - The tcc-lib target is only built if lib/<kernel>/<cpu>-mes-tcc exists,
  - If __raise is a macro, do not define it as a function.
- The clean targets have been fixed.
- The out-of-directory --srcdir build has been resurrected.

Get informed, get involved

See bootstrappable.org.

Join bug-mes@gnu.org and #bootstrappable on irc.libera.chat for discussions.

Thanks to everyone who contributed to this release:

14	Janneke Nieuwenhuizen
 2	Timothy Sample
 1	Vagrant Cascadian

GNU Mes 0.25 released

2023-11-11T08:00:00Z

We are happy to announce the release of GNU Mes 0.25!

Although it's been only nine months since the previous release, this release represents 116 commits over two years by six people. This release brings RISC-V64-linux support.

We are excited that the NLnet Foundation is sponsoring this work!

What's next?

Bringing the Full Source Bootstrap to NixOS. Full Guile compatible module support, and support for running Gash and Gash-Utils. Support for bootstrapping gcc-4.6.4, and a Full Source Bootstrap for armhf-linux, and riscv64-linux.

Enjoy!

About

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. Mes can now be bootstrapped from M2-Planet and Mescc-Tools.

Download

git clone git://git.savannah.gnu.org/mes.git

Here are the compressed sources and a GPG detached signature[*]:

https://ftp.gnu.org/gnu/mes/mes-0.25.tar.gz  
https://ftp.gnu.org/gnu/mes/mes-0.25.tar.gz.sig

Use a mirror for higher download bandwidth:

https://ftpmirror.gnu.org/mes/mes-0.25.tar.gz  
https://ftpmirror.gnu.org/mes/mes-0.25.tar.gz.sig

Here are the SHA1 and SHA256 checksums:

a0fcd35a32d16580cacb52add632d96eae0548a9  mes-0.25.tar.gz  
325250b3567ed9203ba70161c835af01079e73ebed97b4b5bb77ca500b828940  mes-0.25.tar.gz

gpg --verify mes-0.25.tar.gz.sig

If that command fails because you don't have the required public key, or that public key has expired, try the following commands to update or refresh it, and then rerun the 'gpg --verify` command.

gpg --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

Alternatively, Mes can be installed or updated using Guix:

guix pull
guix install mes

Changes in 0.25 since 0.24.2

Core
- Support for riscv64-linux.
Build
- Support M2-Planet build for x86_64-linux.
- Building with M2-Planet-1.11.0 is now supported.
- The requirement for M2-Planet's --bootstrap-mode was dropped.
Noteworthy bug fixes
- In the REPL, include, load, and ,use MODULE now work.
- Using mes' access with R_OK now respects read permissions.
- On 64bit, displayed values are no longer truncated.
- On 64bit, MesCC now correctly supports 8-byte immediate values.
- MesCC now initializes struct fields to 0.
- The MesCC test suite passes with gcc >= 10 An array overflow bug was fixed in 63-struct-cell.c.
- Debugging MesCC binaries (function scope) has been resurrected.

Get informed, get involved

See bootstrappable.org.

Join bug-mes@gnu.org and #bootstrappable on irc.libera.chat for discussions.

Thanks to everyone who contributed to this release:

12	Andrius Štikonas
 1	Efraim Flashner
24	Ekaitz Zarraga
 1	Emily Trau
69	Janneke Nieuwenhuizen
15	W. J. van der Laan

The Full-Source Bootstrap: Building from source all the way down

2023-04-26T16:00:00Z

We are delighted and somewhat relieved to announce that the third reduction of the Guix bootstrap binaries has now been merged in the main branch of Guix! If you run guix pull today, you get a package graph of more than 22,000 nodes rooted in a 357-byte program—something that had never been achieved, to our knowledge, since the birth of Unix.

We refer to this as the Full-Source Bootstrap. In this post, we explain what this means concretely. This is a major milestone—if not the major milestone—in our quest for building everything from source, all the way down.

How did we get there, and why? In two previous blog posts, we elaborated on why this reduction and bootstrappability in general is so important.

One reason is to properly address supply chain security concerns. The Bitcoin community was one of the first to recognize its importance well enough to put the idea into practice. At the Breaking Bitcoin conference 2020, Carl Dong gave a fun and remarkably gentle introduction. At the end of the talk, Carl states:

The holy grail for bootstrappability will be connecting hex0 to mes.

Two years ago, at FOSDEM 2021, I (Janneke) gave a short talk about how we were planning to continue this quest.

If you think one should always be able to build software from source, then it follows that the “trusting trust” attack is only a symptom of an incomplete or missing bootstrap story.

The Road to Full-Source Bootstrap

Three years ago, the bootstrap binaries were reduced to just GNU Mes and MesCC-Tools (and the driver to build Guix packages: a static build of GNU Guile 2.0.9).

The new Full-Source Bootstrap, merged in Guix master yesterday, removes the binaries for Mes and MesCC-Tools and replaces them by bootstrap-seeds. For x86-linux (which is also used by the x86_64-linux build), this means this program hex0-seed, with ASCII-equivalent hex0_x86.hex0. Hex0 is self-hosting and its source looks like this:

    ; Where the ELF Header is going to hit  
    ; Simply jump to _start  
    ; Our main function  
    # :_start ; (0x8048054)  
    58 # POP_EAX ; Get the number of arguments

you can spot two types of line-comment: hex0 (;) and assembly (#). The only program-code in this snippet is 58: two hexidecimal digits that are taken as two nibbles and compiled into the corresponding byte with binary value 58.

Starting from this 357-byte hex0-seed binary provided by the bootstrap-seeds, the stage0-posix package created by Jeremiah Orians first builds hex0 and then all the way up: hex1, catm, hex2, M0, cc_x86, M1, M2, get_machine (that's all of MesCC-Tools), and finally M2-Planet.

The new GNU Mes v0.24 release can be built with M2-Planet. This time with only a remarkably small change, the bottom of the package graph now looks like this (woohoo!):

                              gcc-mesboot (4.9.4)
                                      ^
                                      |
                                    (...)
                                      ^
                                      |
               binutils-mesboot (2.20.1a), glibc-mesboot (2.2.5),
                          gcc-core-mesboot (2.95.3)
                                      ^
                                      |
                             patch-mesboot (2.5.9)
                                      ^
                                      |
                       bootstrappable-tcc (0.9.26+31 patches)
                                      ^
                                      |
                            gnu-make-mesboot0 (3.80)
                                      ^
                                      |
                              gzip-mesboot (1.2.4)
                                      ^
                                      |
                               tcc-boot (0.9.27)
                                      ^
                                      |
                                 mes-boot (0.24.2)
                                      ^
                                      |
                         stage0-posix (hex0..M2-Planet)
                                      ^
                                      |
                          gash-boot, gash-utils-boot
                                      ^
                                      |
                                      *
                     bootstrap-seeds (357-bytes for x86)
                                     ~~~
                   [bootstrap-guile-2.0.9 driver (~25 MiB)]

full graph

We are excited that the NLnet Foundation has been sponsoring this work!

However, we aren't done yet; far from it.

Lost Paths

The idea of reproducible builds and bootstrappable software is not very new. Much of that was implemented for the GNU tools in the early 1990s. Working to recreate it in present time shows us much of that practice was forgotten.

Most bootstrap problems or loops are not so easy to solve and sometimes there are no obvious answers, for example:

In 2013, the year that Reproducible Builds started to gain some traction, the GNU Compiler Collection released version 4.8.0, making C++ a build requirement, and
Even more recently (2018), the GNU C Library glibc-2.28 adds Python as a build requirement,

While these examples make for a delightful puzzle from a bootstrappability perspective, we would love to see the maintainers of GNU packages consider bootstrappability and start taking more responsibility for the bootstrap story of their packages.

Next Steps

Despite this major achievement, there is still work ahead.

First, while the package graph is rooted in a 357-byte program, the set of binaries from which packages are built includes a 25 MiB statically-linked Guile, guile-bootstrap, that Guix uses as its driver to build the initial packages. 25 MiB is a tenth of what the initial bootstrap binaries use to weigh, but it is a lot compared to those 357 bytes. Can we get rid of this driver, and how?

A development effort with Timothy Sample addresses the dependency on guile-bootstrap of Gash and Gash-Utils, the pure-Scheme POSIX shell implementation central to our second milestone. On the one hand, Mes is gaining a higher level of Guile compatibility: hash table interface, record interface, variables and variable-lookup, and Guile (source) module loading support. On the other hand, Gash and Gash-Utils are getting Mes compatibility for features that Mes is lacking (notably syntax-case macros). If we pull this off, guile-bootstrap will only be used as a dependency of bootar and as the driver for Guix.

Second, the full-source bootstrap that just landed in Guix master is limited to x86_64-linux and i686-linux, but ARM and RISC-V will be joining soon. We are most grateful and excited that the NLnet Foundation has decided to continue sponsoring this work!

Some time ago, Wladimir van der Laan contributed initial RISC-V support for Mes but a major obstacle for the RISC-V bootstrap is that the “vintage” GCC-2.95.3 that was such a helpful stepping stone does not support RISC-V. Worse, the RISC-V port of GCC was introduced only in GCC 7.5.0—a version that requires C++ and cannot be bootstrapped! To this end, we have been improving MesCC, the C compiler that comes with Mes, so it is able to build GCC 4.6.5; meanwhile, Ekaitz Zarraga backported RISC-V support to GCC 4.6.5, and backported RISC-V support from the latest tcc to our bootstrappable-tcc.

Outlook

The full-source bootstrap was once deemed impossible. Yet, here we are, building the foundations of a GNU/Linux distro entirely from source, a long way towards the ideal that the Guix project has been aiming for from the start.

There are still some daunting tasks ahead. For example, what about the Linux kernel? The good news is that the bootstrappable community has grown a lot, from two people six years ago there are now around 100 people in the #bootstrappable IRC channel. Interesting times ahead!

About Bootstrappable Builds and GNU Mes

Software is bootstrappable when it does not depend on a binary seed that cannot be built from source. Software that is not bootstrappable---even if it is free software---is a serious security risk (supply chain security) for a variety of reasons. The Bootstrappable Builds project aims to reduce the number and size of binary seeds to a bare minimum.

GNU Mes is closely related to the Bootstrappable Builds project. Mes is used in the full-source bootstrap path for the Guix System.

Currently, Mes consists of a mutual self-hosting scheme interpreter and C compiler. It also implements a C library. Mes, the scheme interpreter, is written in about 5,000 lines of code of simple C and can be built with M2-Planet. MesCC, the C compiler, is written in scheme. Together, Mes and MesCC can compile bootstrappable TinyCC that is self-hosting. Using this TinyCC and the Mes C library, the entire Guix System for i686-linux and x86_64-linux is bootstrapped.

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the Hurd or the Linux kernel, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, AArch64 and POWER9 machines.

In addition to standard package management features, Guix supports transactional upgrades and roll-backs, unprivileged package management, per-user profiles, and garbage collection. When used as a standalone GNU/Linux distribution, Guix offers a declarative, stateless approach to operating system configuration management. Guix is highly customizable and hackable through Guile programming interfaces and extensions to the Scheme language.

GNU Mes 0.24.2 released

2023-02-15T09:00:00Z

We are happy to announce the release of GNU Mes 0.24.2, representing 25 commits over nine months by four people.

This release should fix the long standing `stat64' bug #41264.

We are very grateful that the NLnet Foundation is sponsoring this work!

What's next?

Work to prototype this so-called "Full Source Bootstrap" for ARM on Aarch64 is happening on the Guix wip-aarch64-bootstrap branch branch. Also, full Guile compatible module support, and RISC-V support.

Enjoy!

About

GNU Mes is a Scheme interpreter and C compiler for bootstrapping the GNU System. Since version 0.22 it has again helped to halve the size of opaque, uninspectable binary seeds that are currently being used in the Reduced Binary Seed bootstrap of GNU Guix. The final goal is to help create a full source bootstrap as part of the bootstrappable builds effort for UNIX-like operating systems.

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. Mes can now be bootstrapped from M2-Planet and Mescc-Tools.

Mes has a Garbage Collector, a library of loadable Scheme modules-- notably Dominique Boucher's LALR, Pre-R6RS portable syntax-case with R7RS ellipsis, Matt Wette's Nyacc --and test suite, just enough to support a REPL and a C99 compiler: mescc.

Mes + MesCC + Mes C Library can build a bootstrappable TinyCC that is self-hosting. Using this tcc and the Mes C library we now have a Reduced Binary Seed bootstrap for the gnutools triplet: glibc-2.2.5, binutils-2.20.1, gcc-2.95.3. This is enough to bootstrap Guix for i686-linux, x86_64-linux, armhf-linux and aarch64-linux.

Mes is inspired by The Maxwell Equations of Software: LISP-1.5 -- John McCarthy page 13, GNU Guix's source/binary packaging transparency and Jeremiah Orians's stage0 ~500 byte self-hosting hex assembler.

Download

git clone git://git.savannah.gnu.org/mes.git

Here are the compressed sources and a GPG detached signature[*]:
mes-0.24.2.tar.gz
mes-0.24.2.tar.gz.sig

Use a mirror for higher download bandwidth:
mes-0.24.2.tar.gz
mes-0.24.2.tar.gz.sig

Here are the SHA1 and SHA256 checksums:

30b0ce4cd37c87dca37b85a6c19646001881be46  mes-0.24.2.tar.gz  
7ddae0854e46ebfa18c13ab37e64839a7b86ea88aeed366a8d017efd11dae86e  mes-0.24.2.tar.gz

gpg --verify mes-0.24.tar.gz.sig

If that command fails because you don't have the required public key, or that public key has expired, try the following commands to update or refresh it, and then rerun the 'gpg --verify' command.

gpg --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

Get informed, get involved

See bootstrappable.org
Join #bootstrappable on irc.libera.chat

NEWS

Changes in 0.24.2 since 0.24.1

Build
- A number of compile warnings have been fixed.
- The simple.make and simple.sh builds have been resurrected.
MesCC
- Some assembly defines were added for building TinyCC for x86_64.
- __assert_fail has been updated to use the standard signature.
Noteworthy bug fixes
- A bootstrap build without M2-Planet is now supported again.
- gettimeofday no longer segfaults in the M2-Planet build.
- stat64 and friends are now used on 32bit platforms. This fixes #41264, and should also fix #49985, #53415, and #53416.
- The Mes C Library now supports uppercase hex conversions.
Links

GNU Mes 0.24.1 released

2022-10-16T11:00:00Z

We are happy to announce the release of GNU Mes 0.24.1, representing 23 commits over five months by four people.

Mes now supports the stage0-posix and M2-Planet Full Source bootstrap on Aarch64 for ARM. Because stage0-posix does not support ARM yet, the Mes ARM bootstrap is currently prototyped on Aarch64.

We are excited that the NlNet Foundation[4] is again sponsoring this work!

What's next?

Work to prototype this so-called "Full Source Bootstrap" for ARM on Aarch64 is happening on the wip-aarch64-bootstrap[3] branch. Also, full Guile compatible module support, and RISC-V support.

Enjoy!

About

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. Mes can now be bootstrapped from M2-Planet and Mescc-Tools.

Download

git clone git://git.savannah.gnu.org/mes.git

Here are the compressed sources and a GPG detached signature[*]:
mes-0.24.1.tar.gz
mes-0.24.1.tar.gz.sig

Use a mirror for higher download bandwidth:
mes-0.24.1.tar.gz
mes-0.24.1.tar.gz.sig

Here are the SHA1 and SHA256 checksums:

bceaaaf1cafaa31ccb1ee1247ce2dd651a2f67be  mes-0.24.1.tar.gz  
35120ceb0676632e58973355b9f86dff9cc717ed65ed2a17ff5272c59f2a0535  mes-0.24.1.tar.gz

gpg --verify mes-0.24.tar.gz.sig

If that command fails because you don't have the required public key, or that public key has expired, try the following commands to update or refresh it, and then rerun the 'gpg --verify' command.

gpg --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

Get informed, get involved

See bootstrappable.org
Join #bootstrappable on irc.libera.chat

NEWS

Changes in 0.24.1 since 0.24

Build
- Support M2-Planet bootstrap for ARM.
MesCC
- The Mes C Library now supports bootstrapping ARM.
Noteworthy bug fixes
- The definition of S_ISUID was fixed.
- Unsigned modulo has been fixed for ARM.
- A bug with abtol has been fixed.
- Workarounds for building with gcc-12.2.0 have been added.
Links

GNU Mes 0.24 released

2022-05-02T20:00:00Z

We are thrilled to announce the release of GNU Mes 0.24, representing 222 commits over one year by four people.

Mes has now been ported to M2-Planet and can be bootstrapped using stage0-posix , starting from the 357-byte hex0 binary of the bootstrap-seeds, as was promised at FOSDEM'21.

We are exciteda that the NLnet Foundation is again sponsoring this work!

What's next?

Work to integrate this so-called "Full Source Bootstrap" is happening on wip-full-source-bootstrap branch

branch. Also, full Guile compatible module support, and RICS-V support.

Enjoy!

About

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. Mes can now be bootstrapped from M2-Planet and Mescc-Tools.

Download

git clone git://git.savannah.gnu.org/mes.git

Here are the compressed sources and a GPG detached signature[*]:
mes-0.24.tar.gz
mes-0.24.tar.gz.sig

Use a mirror for higher download bandwidth:
mes-0.24.tar.gz
mes-0.24.tar.gz.sig

Here are the SHA1 and SHA256 checksums:

f6681aa02edc6729af43f1d7c46ae1a97cbc1c92  mes-0.24.tar.gz  
828be15e02c103df8a248232491fba10d763724d6ec10f08a2e0e1d249bd9902  mes-0.24.tar.gz

gpg --verify mes-0.24.tar.gz.sig

If that command fails because you don't have the required public key, or that public key has expired, try the following commands to update or refresh it, and then rerun the 'gpg --verify' command.

gpg --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

Get informed, get involved

See bootstrappable.org
Join #bootstrappable on irc.libera.chat

NEWS

Changes in 0.24 since 0.23
- Core
  - Mes and Mes C Library can now be built with M2-Planet.
  - Mes now supports the --bootstrap build on ARM.
- MesCC
  - MesCC now supports the integer suffixes:
    Next to U, also support ULL, UL, L, and LL.
- Noteworthy bug fixes
  - MesCC now uses the unsigned type for sizeof.
  - MesCC now only uses signed division if numerator is signed.
  - The Mes C library now supports an argv bigger than 255.
  - Development build support with Guile-2 was resurrected.
  - The logand procedure now works correctly.
  - The 64bit build was resurrected.
Links

GNU Mes 0.23.1 released

2022-03-01T17:00:00Z

We are happy to announce the release of GNU Mes 0.23.1, representing 22 commits over one year by four people.

Mes was ported to ARM and can now be used in the GNU Guix Reduced Binary Seed bootstrap as described here

Guix Further Reduces Bootstrap Seed to 25%

and now also for armhf-linux and aarch-linux. Work to integrate this into Guix is ongoing: bootstrappable-tinycc and gcc-core-2.95.3 have been built.

We are excited that the Nlnet Foundation is sponsoring this work!

Enjoy, Janneke and Danny.

About

GNU Mes is a Scheme interpreter and C compiler for bootstrapping the GNU System. Since version 0.22 it has again helped to halve the size of opaque, uninspectable binary seeds that are currently being used in the Reduced Binary Seed bootstrap of GNU Guix . The final goal is to help create a full source bootstrap as part of the bootstrappable builds effort for UNIX-like operating systems.

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. This mes.c is now being simplified to be transpiled by M2-Planet.

Mes has a Garbage Collector, a library of loadable Scheme modules-- notably Dominique Boucher's LALR, pre-R6RS portable syntax-case with R7RS ellipsis, Matt Wette's Nyacc –and test suite, just --and test suite, just enough to support a REPL and a C99 compiler: mescc.

Mes is inspired by The Maxwell Equations of Software: LISP-1.5 LISP-1.5 – -- John McCarthy page 13, GNU Guix's source/binary packaging transparency and Jeremiah Orians's stage0 ~500 byte self-hosting hex assembler.

We are very grateful to NLNet for sponsoring the Reduced Binary Seed bootstrap and the ARM port .

Download

git clone git://git.savannah.gnu.org/mes.git

Here are the compressed sources and a GPG detached signature[*]:
ftp.gnu.org/gnu/mes/mes-0.23.1.tar.gz
ftp.gnu.org/gnu/mes/mes-0.23.1.tar.gz.sig

Use a mirror for higher download bandwidth:
ftpmirror.gnu.org/mes/mes-0.23.1.tar.gz
ftpmirror.gnu.org/mes/mes-0.23.1.tar.gz.sig

Here are the MD5 and SHA1 checksums:

16b5bdf1c1ec0b743652f769b7bed772  mes-0.23.1.tar.gz  
a73b69e903eaab94c680d50436b51366e770130c  mes-0.23.1.tar.gz

gpg --verify mes-0.23.1.tar.gz.sig

If that command fails because you don't have the required public key, then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

and rerun the 'gpg --verify' command.

Get informed, get involved

See bootstrappable.org
Join #bootstrappable on irc.freenode.net.

Changes in 0.23.1 since 0.23

Build: Move to libera.chat.
Core
- Mes and Mes C Library can now support ARM bootstrap.
MesCC
- MesCC now supports ARM bootstrap.
Noteworthy bug fixes
- Stack frame 0 does not perform out of bounds access.
- MesCC's -m64 works again.
- Guile-2 support has been resurrected.
- logand has been fixed.
- Mes C Library now supports more than 255 command line parameters.

GNU Mes 0.23 released

2021-03-14T17:00:00Z

We are happy to announce the release of GNU Mes 0.23, representing 125 commits over one year by four people.

Mes was ported to ARM and can now be used in the GNU Guix Reduced Binary Seed bootstrap as described here

Guix Further Reduces Bootstrap Seed to 25%

and now also for armhf-linux and aarch-linux. Work to integrate this into Guix is ongoing: bootstrappable-tinycc and gcc-core-2.95.3 have been built.

We are excited that the Nlnet Foundation is sponsoring this work!

Enjoy, Janneke and Danny.

About

GNU Mes is a Scheme interpreter and C compiler for bootstrapping the GNU System. Since version 0.22 it has again helped to halve the size of opaque, uninspectable binary seeds that are currently being used in the Reduced Binary Seed bootstrap of GNU Guix . The final goal is to help create a full source bootstrap as part of the bootstrappable builds effort for UNIX-like operating systems.

The Scheme interpreter is written in ~5,000 LOC of simple C, and the C compiler written in Scheme and these are mutual self-hosting. This mes.c is now being simplified to be transpiled by M2-Planet.

We are very grateful to NLNet for sponsoring the Reduced Binary Seed bootstrap and the ARM port .

Download

git clone git://git.savannah.gnu.org/mes.git

Here are the compressed sources and a GPG detached signature[*]:
ftp.gnu.org/gnu/mes/mes-0.23.tar.gz
ftp.gnu.org/gnu/mes/mes-0.23.tar.gz.sig

Use a mirror for higher download bandwidth:
ftpmirror.gnu.org/mes/mes-0.23.tar.gz
ftpmirror.gnu.org/mes/mes-0.23.tar.gz.sig

Here are the MD5 and SHA1 checksums:

e9a0ae6e2c3842cf57fccb54909463ba  mes-0.23.tar.gz  
0560879358e5a980f7374844c495c92014b47878  mes-0.23.tar.gz

gpg --verify mes-0.23.tar.gz.sig

If that command fails because you don't have the required public key, then run this command to import it:

gpg --keyserver keys.gnupg.net --recv-keys 1A858392E331EAFDB8C27FFBF3C1A0D9C1D65273

and rerun the 'gpg --verify' command.

Get informed, get involved

See bootstrappable.org
Join #bootstrappable on irc.freenode.net.

Changes in 0.23 since 0.22

Core
- Mes and Mes C Library can now be built with GCC 10.x.
MesCC
- The Mes C Library now supports an armhf-linux bootstrap.
- MesCC now supports ARM.
- mini.c library was split into _exit.c, and _write.c.
- When building with GCC, -lgcc is now used.
- MesCC now has it's own support library libmescc.a (-lmescc).
- MesCC now requires mescc-tools-0.7.0 or later for ARM.
- MesCC can be now built with nyacc-1.00.2: note that nyacc-1.03.0 is not (backwards) compatible.
- MesCC can be built with Guile 3.0.x: See bugs.gnu.org/43831; use guild compile -O1 with Guile 3.0.x.
- MesCC now raises SIGABRT on abort, if supported.
Noteworthy bug fixes
- unreadchar on EOF is now a no-op.
- malloc now aligns the blocks it gives out to max_align_t.

We did it!

2021-01-07T08:00:00Z

Last Monday I sent an update essentially saying $Subject:

WE DID IT!!!

A proper blog post will follow once GNU Mes 0.24 has been released and the Full Source Bootstrap has been merged, i.e, when GNU Guix has a bootstrap rooted in this 357-byte hex0-seed binary with an ASCII-equivalent.

Once released, this is what the bottom of the provisional Guix package graph will looks like .

At FOSDEM'21 I will be giving a short talk in the Declarative and Minimalistic Computing devroom.

Coverage

2021-01-06: Linux Weekly News has a story on Bootstrappable builds.

About Bootstrappable Builds and GNU Mes

Software is bootstrappable when it does not depend on a binary seed that cannot be built from source. Software that is not bootstrappable---even if it is free software---is a serious security risk for a variety of reasons. The Bootstrappable Builds project aims to reduce the number and size of binary seeds to a bare minimum.

GNU Mes is closely related to the Bootstrappable Builds project. Mes aims to create an entirely source-based bootstrapping path for the Guix System and other interested GNU/Linux distributions. The goal is to start from a minimal, easily inspectable binary that has an ASCII-equivalent and bootstrap into something close to R6RS Scheme.

Currently, Mes consists of a mutual self-hosting scheme interpreter and C compiler. It also implements a C library. Mes, the scheme interpreter, is written in about 5,000 lines of code of simple C or M2. It can be bootstrapped using the M2-Planet transpiler from the Stage0 project. MesCC, the C compiler, is written in scheme. Together, Mes and MesCC can compile a lightly patched TinyCC that is self-hosting. Using this TinyCC and the Mes C library, it is possible to bootstrap the entire Guix System for i686-linux and x86_64-linux.

About GNU Guix

GNU Guix is a transactional package manager and an advanced distribution of the GNU system that respects user freedom. Guix can be used on top of any system running the kernel Linux, or it can be used as a standalone operating system distribution for i686, x86_64, ARMv7, and AArch64 machines.

Childhurds and GNU/Hurd substitutes

2020-10-08T14:15:00Z

A lot has happened since our Hello Hurd post beginning of April. No, not nearly as much as we joked on April 1st , but more than enough to share and be proud of.

Building a Hurd virtual machine

As some of you noticed, the previous hacks to build a Hurd virtual machine (VM) were removed and no longer work; using Guix you can now build a GNU/Hurd VM just like you would build a GNU/Linux VM:

guix system disk-image -t hurd-raw bare-hurd.tmpl

This cross-compiles all the relevant packages for GNU/Hurd—specifically the i586-pc-gnu triplet—and produces a VM image:

/gnu/store/n7jkfajw0fzp975hv0b9v18r9bbr961q-disk-image

You can build it and start it from your GNU/Linux machine with this command:

qemu-system-i386 -enable-kvm -m 512 -snapshot -hda \
  $(guix system disk-image -t hurd-raw bare-hurd.tmpl)

We are using this ready-made, minimal GNU/Hurd operating system description gnu/system/examples/bare-hurd.tmpl that looks suprisingly familiar:

(use-modules (gnu) (gnu system hurd) (guix utils))
(use-service-modules ssh)
(use-package-modules ssh)

(define %hurd-os
  (operating-system
    (inherit %hurd-default-operating-system)
    (bootloader (bootloader-configuration
                 (bootloader grub-minimal-bootloader)
                 (target "/dev/sdX")))
    (file-systems (cons (file-system
                          (device (file-system-label "my-root"))
                          (mount-point "/")
                          (type "ext2"))
                        %base-file-systems))
    (host-name "guixygnu")
    (timezone "Europe/Amsterdam")
    (packages (cons openssh-sans-x %base-packages/hurd))
    (services (cons (service openssh-service-type
                             (openssh-configuration
                              (openssh openssh-sans-x)
                              (use-pam? #f)
                              (port-number 2222)
                              (permit-root-login #t)
                              (allow-empty-passwords? #t)
                              (password-authentication? #t)))
               %base-services/hurd))))

%hurd-os

and it can be customized just like a GNU/Linux operating system description. The end result is a full-blown Guix System with the Shepherd managing system services and all that—finally we can run herd on the Hurd.

A lot of things had to be in place to support this, we worked on

Adding multiboot support to grub-minimal-bootloader; a nice standard that Linux sadly does not support,
Support for the Hurd and cross-building of the core packages listed in %base-packages/hurd,
Support for the Hurd and cross-building of the system services in %base-services/hurd,
- Add hurd-console-service,
- Add hurd-getty-service,
- Add hurd-default-essential-services,
- Add Hurd support to %boot-service
- Add a hurd-startup-service,
- Add Hurd support to activation-service,
- Add Hurd support for “syscalls”: define-c-struct, ioctl, readdir*, sockaddr-in, getxattr, setxattr,

counting some ~200 patches by ten people over six months; including generic cross-compilation fixes and support, and Hurd fixes and support.

Also, we finished the passive translator settings over extended attributes (xattrs) for the Hurd and for Linux.

You may notice that we are using the new disk-image command rather than the old vm-image. One of the big hurdles in producing a VM image was the way Guix produces VM images: it would run a target QEMU, e.g. qemu-arm. That does not work for the Hurd, as there is no qemu-hurd. Without going into the hairy details, when Ludo and Janneke were—three patch sets, 50 messages and 13 days later—almost ready to give up, Mathieu came to the rescue with his brand-new implementation of the disk-image command. At the time, Hurd work was done on the wip-hurd branch and the disk-image work on wip-disk-image. Soon after, Mathieu proposed an explosive mix of the two branches; we managed to create the first Hurd system that really felt like Guix System.

The new implementation of the disk-image command was followed by the introduction of an --image-type or -t option. This option allows to produce disk images targeting different supports. The hurd-raw and hurd-qcow2 image types, producing respectively a raw Hurd disk-image and a Hurd QCOW2 disk-image were introduced. They can be used this way:

guix system disk-image -t hurd-raw bare-hurd.tmpl
guix system disk-image -t hurd-qcow2 bare-hurd.tmpl

This mechanism providing much more flexibility in the Guix System image generation will be described in a future blog post.

We also offer downloads of continuously built (actually cross-built) Guix System on GNU/Hurd (~350 MiB).

Substitutes

While amazing to be able to just run the Hurd in a VM, development without substitutes is a real pain; a Guix system needs substitutes. How to go about that? We have a build farm but currently Hurd only runs on ancient hardware: not an option. We need a machine running Guix/Hurd to offload Hurd build jobs to.

The proposed solution was to automate the building and running of a Guix VM into a new Guix service: the so-called hurd-vm or childhurd service. We would add something like:

(service hurd-vm-service-type)

to a couple of our build nodes to add a hird of virtual Hurd machines to our build farm.

The Childhurd service

The Hurd—being based on a microkernel—has some beautiful built-in "virtualization" possibilites that have their own naming: neighborhurds, subhurds. Similarly, we are adding childhurds to this mix: a childhurd is a GNU/Hurd VM running on GNU/Linux and managed by Guix.

When you are running Guix System, building a Hurd VM manually is no longer necessary. Just add the hurd-vm service to your operating system description:

(service hurd-vm-service-type
         (hurd-vm-configuration
          (disk-size (* 12 (expt 2 30))) ;12GiB
          (memory-size 1024)))           ; 1GiB

and this will build a childhurd for you when you reconfigure your system. This childhurd can be stopped and started just like any other service:

herd stop hurd-vm
herd start childhurd

(childhurd is an alias for hurd-vm).

WARNING

It is highly addictive.

Having shaved this yak, let’s not lose sight that our initial goal was to offload builds to those GNU/Hurd VMs. The childhurd service does all the heavy lifting. To offload from GNU/Linux to my childhurd, I added this to my /etc/guix/machines.scm:

 (build-machine
  (name "localhost")
  (systems (list "i586-gnu"))
  (host-key "ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIHZsrZ63zs+AhWbVJgYq6j1h2rgQGrWKCokpR2/Q/Jzy root@guixygnu")
  (port 10022)  ;the Hurd VM has SSH listening on that port
  (user "root")
  (private-key "/home/janneke/.ssh/id_rsa_childhurd"))

That can be used to transparently offload builds from GNU/Linux to the childhurd:

$ uname -o
GNU/Linux
$ guix build hello -s i586-gnu
The following derivation will be built:
   /gnu/store/jqdvjhcxxnbq370y8i2c973c9zfiqrgl-hello-2.10.drv
[…]
guix offload: sending 1 store item (12 MiB) to 'localhost'...
offloading '/gnu/store/jqdvjhcxxnbq370y8i2c973c9zfiqrgl-hello-2.10.drv' to 'localhost'...
[…]
/gnu/store/803q5wapfnmr91ag8d9dzwabkbdxz3ay-hello-2.10
$ file -L $(guix build hello -s i586-gnu)/bin/hello
/gnu/store/803q5wapfnmr91ag8d9dzwabkbdxz3ay-hello-2.10/bin/hello: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked, interpreter /gnu/store/9vs3gkp6svam82zw7vjlml7iiarcs11c-glibc-2.31/lib/ld.so.1, for GNU/Hurd 0.0.0, not stripped

Hurrah!

Hurd substitutes

Last Friday we produced the very first GNU Hello substitute for the Hurd:

StorePath: /gnu/store/803q5wapfnmr91ag8d9dzwabkbdxz3ay-hello-2.10
URL: nar/gzip/803q5wapfnmr91ag8d9dzwabkbdxz3ay-hello-2.10
Compression: gzip
FileSize: 61822
URL: nar/lzip/803q5wapfnmr91ag8d9dzwabkbdxz3ay-hello-2.10
Compression: lzip
FileSize: 52887
NarHash: sha256:0g4k1kppjs5148ynm4zw4x1kpaby67npc3ws6s7y7hf0il1cgryk
NarSize: 204328
References: 803q5wapfnmr91ag8d9dzwabkbdxz3ay-hello-2.10 9vs3gkp6svam82zw7vjlml7iiarcs11c-glibc-2.31 bwvd5338kfm0vsc4i9xvh48vdxr5ywrz-gcc-7.5.0-lib
System: i586-gnu
Deriver: jqdvjhcxxnbq370y8i2c973c9zfiqrgl-hello-2.10.drv
Signature: 1;berlin.guix.gnu.org;KHNpZ25hdHVyZSAKIChkYXRhIAogIChmbGFncyByZmM2OTc5KQogIChoYXNoIHNoYTI1NiAjMDVGOEY5NjMxRUU5QzcxM0REQUNBRTYwNUNCNjJBNzlDNUY4NEVFQTIwMjc5OERBNTQ3NURCOUU2Q0FBRDMwMSMpCiAgKQogKHNpZy12YWwgCiAgKGVjZHNhIAogICAociAjMDVBMzkzMTgwOUY1RkQyMTdGMDM4MUVDMTJEODYyNzIyOEYyNjJGRDA4MTcxQjREMzZBNEM0RjBBNjZEQkY4NSMpCiAgIChzICMwQTc2RjZGNENCOTMzQTczNzA4QkNGMzRGREExMzkyOTRGQTQxREQzQTUwQkEwOUE0ODRCQUQyOTA4MjQ5ODIxIykKICAgKQogICkKIChwdWJsaWMta2V5IAogIChlY2MgCiAgIChjdXJ2ZSBFZDI1NTE5KQogICAocSAjOEQxNTZGMjk1RDI0QjBEOUE4NkZBNTc0MUE4NDBGRjJEMjRGNjBGN0I2QzQxMzQ4MTRBRDU1NjI1OTcxQjM5NCMpCiAgICkKICApCiApCg==

For development, porting and fixing of packages, you can use a Childhurd configuration like this:

(use-modules (srfi srfi-1) (guix packages) (guix records))
(use-package-modules base compression file gawk gdb hurd less m4 package-management)

(define guix-packages
  (filter-map input->package
              (fold alist-delete (package-direct-inputs guix)
                    '("glibc-utf8-locales" "graphviz" "po4a"))))

(operating-system
  (inherit %hurd-vm-operating-system)
  (users ...)
  (packages
    (cons* diffutils file findutils gawk gdb-minimal git-minimal
           gnu-make grep gzip less m4 openssh-sans-x tar xz
           (append
            guix-packages
            (delete guile-3.0 %base-packages/hurd)))))

… which allows working from a Git clone:

15:51:05 janneke@dundal:~/src/guix/master [env]
$ ssh -A janneke@childhurd
Last login: Sat Oct  3 15:31:55 2020 from 10.0.2.2


  This is the GNU Hurd.  Welcome.

janneke@childhurd ~$ git config --global url."git+ssh://git.sv.gnu.org/srv/git/".insteadOf gnu:
janneke@childhurd ~$ git clone gnu:guix
Cloning into 'guix'...
remote: Counting objects: 394436, done.
remote: Compressing objects: 100% (85728/85728), done.
remote: Total 394436 (delta 309572), reused 392294 (delta 307893)
Receiving objects: 100% (394436/394436), 137.05 MiB | 1.18 MiB/s, done.
Resolving deltas: 100% (309572/309572), done.
Updating files: 100% (2199/2199), done.

but before we continue let's first check the weather:

janneke@childhurd ~$ guix weather
computing 11079 package derivations for i586-gnu...
looking for 11521 store items on https://ci.guix.gnu.org...
updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
https://ci.guix.gnu.org
  1.5% substitutes available (169 out of 11521)
  at least 443.3 MiB of nars (compressed)
  966.7 MiB on disk (uncompressed)
  0.012 seconds per request (142.2 seconds in total)
  81.0 requests per second
[..]

this gives an idea of how young this project is. Any day now, more Hurd substitutes will follow. Now let's configure and build Guix:

janneke@childhurd ~$ cd guix
janneke@childhurd ~/guix$ guix environment --bootstrap \
  --ad-hoc gcc-toolchain@7 libgcrypt zlib
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
The following derivations will be built:
   /gnu/store/gxq5flc8kwpn999dw9xxvldy9xfd0q2x-profile.drv
   /gnu/store/vfkjnwgl4ckyklrl2z4q8x2vnlrwwyfr-gcc-toolchain-7.5.0.drv
   /gnu/store/zh6snj49ayrpw24jn7whpzygj1fpy9cm-module-import-compiled.drv

66.3 MB will be downloaded
[..]
building profile with 3 packages...
janneke@childhurd ~/guix [env]$ ./bootstrap
[..]
janneke@childhurd ~/guix [env]$ ./configure --with-courage\
  --localstatedir=/var --sysconfdir=/etc
[..]
janneke@childhurd ~/guix [env]$ make
[..]
janneke@childhurd ~/guix [env]$ ./pre-inst-env guix build hello
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
0.1 MB will be downloaded:
   /gnu/store/803q5wapfnmr91ag8d9dzwabkbdxz3ay-hello-2.10
substituting /gnu/store/803q5wapfnmr91ag8d9dzwabkbdxz3ay-hello-2.10...
downloading from https://ci.guix.gnu.org/nar/lzip/803q5wapfnmr91ag8d9dzwabkbdxz3ay-hello-2.10 ...
 hello-2.10  52KiB                    258KiB/s 00:00 [##################] 100.0%

/gnu/store/803q5wapfnmr91ag8d9dzwabkbdxz3ay-hello-2.10

just like we are used to do…almost. We are using --bootstrap and a targeted --ad-hoc to avoid dependencies like libx11, python-minimal, and other packages that do not build yet.

Isolated build environments

To help achieve reproducible builds, Guix builds packages in isolated build environments: build environments contain nothing but the inputs explicitly declared in the package definition—not even /bin/sh. Build environments also lack network access. On GNU/Linux this is achieved by running builds in separate namespaces. Besides, the environment contains device nodes and “special” file systems that are usually expected to be available: /dev/null, /dev/pts, /dev/shm, /proc, the loopback networking device, and so on. (The exact contents are documented.)

On GNU/Linux, these special files and file systems are implemented by the kernel. Guix only cares about user-land software, meaning that these devices “leak” from the host kernel instead of being an explicit “input” of derivations, but that’s OK, that’s the deal: the kernel and hardware are considered outside of Guix’s control.

What about GNU/Hurd, though? In GNU/Hurd, /dev/null, a Linux-compatible /proc, the TCP/IP stack necessary to implement the loopback device, and even support for pipes are all implemented in user-land: writing to /dev/null amounts to talking to the /hurd/null service (or translator), operations on AF_INET sockets translate to remote procedure calls (RPCs) to /servers/socket/2, which the /hurd/pfinet program listens to, and so on.

That raises an interesting question: what should the build environment contain on GNU/Hurd? So far our GNU/Hurd builds were made in non-isolated environments; we have just started implementing support for isolated builds but we’ll have to answer that question first. If we stick to our approach—every piece of user-land software must be an explicit input of the build process—then code that implements TCP/IP, /dev/null, or even pipe should be an explicit input of any build process that needs those facilities.

This principled approach can push the notion of controlled, reproducible build environments to a whole new level. For example, we’ve had cases where the choice of the root file system—e.g., ext4 vs. Btrfs—has an observable effect on software behavior, leading to concrete issues such as test failures in one case and not in the other. On GNU/Hurd, build processes could run their own root file system, doing away with this kind of discrepancy.

On the other hand, there are practical issues that cannot be ignored: virtually all build processes need these facilities so they’ll need to be set up one way or another. Also, one could argue that things like /dev/null have a well-defined interface that’s set in stone and that, consequently, how they’re implemented does not matter at all. Can we say the same of the TCP/IP stack though? Maybe not. A line needs to be drawn somewhere.

We have yet to decide where to draw the line and to precisely define what the build environment contains on GNU/Hurd. These questions are closely related to bootstrapping issues we notably discussed at the 2019 Reproducible Builds Summit. Tricky, but exciting.

What's next?

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

user-space driver/modern hardware support
audio support (this is sponsored by NLnet, thanks!),
SMP support,
64-bit/ x86_64 support (!), as well as porting to non-Intel CPUs.

Join #guix and #hurd on irc.freenode.net or the mailing lists and get involved!

About GNU Guix

About the GNU Hurd

The GNU Hurd is the GNU project's replacement for the Unix kernel. It is a collection of servers that run on the Mach microkernel to implement file systems, network protocols, file access control, and other features that are implemented by the Unix kernel or similar kernels (such as Linux). More info.

The mission of the GNU Hurd project is to create a general-purpose kernel suitable for the GNU operating system, which is viable for everyday use, and gives users and programs as much control over their computing environment as possible.

Guix Further Reduces Bootstrap Seed to 25%

2020-06-15T12:00:00Z

We are delighted to announce that the second reduction by 50% of the Guix bootstrap binaries has now been officially released!

The initial set of binaries from which packages are built now weighs in at approximately 60~MiB, a quarter of what it used to be.

In a previous blog post we elaborate on why this reduction and bootstrappability in general is so important. One reason is to eliminate---or greatly reduce the attack surface of---a “trusting trust” attack. Last summer at the Breaking Bitcoin conference, Carl Dong gave a fun and remarkably gentle introduction and at FOSDEM2020 I also gave a short talk about this. If you choose to believe that building from source is the proper way to do computing, then it follows that the “trusting trust” attack is only a symptom of an incomplete or missing bootstrap story.

Further Reduced Binary Seed bootstrap

Last year, the first reduction removed the GCC, glibc and Binutils binary seeds. The new Further Reduced Binary Seed bootstrap, merged in Guix master last month, removes the “static-binaries tarball” containing GNU Awk, Bash, Bzip2, the GNU Core Utilities, Grep, Gzip, GNU Make, Patch, sed, Tar, and Xz. It replaces them by Gash and Gash Core Utils. Gash is a minimalist POSIX shell written in Guile Scheme, while Gash Core Utils is a Scheme implementation for most of the tools found in GNU Coreutils, as well as the most essential bits of Awk, grep and sed.

After three new GNU Mes releases with numerous Mes C Library updates and fixes, a major update of Gash and the first official Gash Utils release, and the delicate balancing of 17 new bootstrap source packages and versions, the bottom of the package graph now looks like this (woohoo!):

                              gcc-mesboot (4.9.4)
                                      ^
                                      |
                                    (...)
                                      ^
                                      |
               binutils-mesboot (2.14), glibc-mesboot (2.2.5),
                          gcc-core-mesboot (2.95.3)
                                      ^
                                      |
            bash-mesboot (2.05), bzip2-mesboot, gawk-mesboot (3.0.0)
       diffutils-mesboot (2.7), patch-mesboot (2.5.9), sed-mesboot (1.18)
                                      ^
                                      |
                             gnu-make-mesboot (3.82)
                                      ^
                                      |
                                gzip-mesboot (1.2.4)
                                      ^
                                      |
                                  tcc-boot
                                      ^
                                      |
                                  mes-boot
                                      ^
                                      |
                          gash-boot, gash-utils-boot
                                      ^
                                      |
                                      *
                 bootstrap-mescc-tools, bootstrap-mes (~12 MiB)
                            bootstrap-guile (~48 MiB)

full graph

We are excited that the Nlnet Foundation has sponsored this work!

However, we aren't done yet; far from it.

Lost Paths

Readers who are familiar with the GNU toolchain may have noticed the version numbers of the *-mesboot source packages in this great new bootstrap: They are ancient! That's a problem.

Typically, newer versions of the tool chain fix all kinds of bugs, make the software easier to build and add support for new CPU architectures, which is great. However---more often than not--- simultaneously new features are introduced or dependencies are added that are not necessary for bootstrapping and may increase the bootstrap hurdle. Sometimes, newer tools are more strict or old configure scripts do not recognise newer tool versions.

A trivial example is GNU sed. In the current bootstrap we are using version 1.18, which was released in 1993. Until recently the latest version of sed we could hope to bootstrap was sed-4.2.2 (2012). Newer releases ship as xz-compressed tarballs only, and xz is notoriously difficult to bootstrap (it needs a fairly recent GCC and try building that without sed).

Luckily, the sed maintainers (Jim Meyering) were happy to correct this mistake and starting from release sed-4.8 (2020) also gzip-compressed tarballs will be shipped. Similar for the GNU Core Utils: Releases made between 2011 and 2019 will probably be useless for bootstrapping. Confronted with this information, also the coreutils maintainers (Pádraig Brady) were happy to release coreutils-8.32 also in gzip compression from now on.

Even these simple cases show that solving bootstrap problems can only be done together: For GNU it really is a project-wide responsibility that needs to be addressed.

Most bootstrap problems or loops are not so easy to solve and sometimes there are no obvious answers, for example:

In 2013, the year that Reproducible Builds started to gain some traction, the GNU Compiler Collection released gcc-4.8.0, making C++ a build requirement, and
Even more recently (2018), the GNU C Library glibc-2.28 adds Python as a build requirement,

and while these examples make for a delightful puzzle from a bootstrappability perspective, we would love to see the maintainers of GNU softwares to consider bootstrappability and start taking more responsibility for the bootstrap story of their packages.

Towards a Universal, Full Source Bootstrap

Our next target will be a third reduction by ~50%; the Full-Source bootstrap will replace the MesCC-Tools and GNU Mes binaries by Stage0 and M2-Planet.

The Stage0 project by Jeremiah Orians starts everything from ~512 bytes; virtually nothing. Have a look at this incredible project if you haven’t already done so.

We are most grateful and excited that the Nlnet Foundation has again decided to sponsor this work!

While the reduced bootstrap currently only applies to the i686-linux and x86_64-linux architectures, we are thrilled that ARM will be joining soon. The Trusted ARM bootstrapping work is progressing nicely, and GNU Mes is now passing its entire mescc test suite on native ARMv7, and passing nigh its entire gcc test suite on native ARMv7. Work is underway to compile tcc using that GNU Mes. Adding this second architecture is a very important one towards the creation of a universal bootstrap!

Upcoming releases of Gash and Gash-Utils will allow us to clean up the bottom of the package graph and remove many of the “vintage” packages. In particular, the next version of Gash-Utils will be sophisticated enough to build everything up to gcc-mesboot using only old versions of GNU Make and Gzip. This is largely thanks to improvements to the implementation of Awk, which now includes nearly all of the standard features.

Looking even further into the future, we will likely have to remove the “vintage” GCC-2.95.3 that was such a helpful stepping stone and reach straight for GCC-4.6.4. Interesting times ahead!

About Bootstrappable Builds and GNU Mes

Software is bootstrappable when it does not depend on a binary seed that cannot be built from source. Software that is not bootstrappable---even if it is free software---is a serious security risk for a variety of reasons. The Bootstrappable Builds project aims to reduce the number and size of binary seeds to a bare minimum.

GNU Mes is closely related to the Bootstrappable Builds project. Mes aims to create an entirely source-based bootstrapping path for the Guix System and other interested GNU/Linux distributions. The goal is to start from a minimal, easily inspectable binary (which should be readable as source) and bootstrap into something close to R6RS Scheme.

Currently, Mes consists of a mutual self-hosting scheme interpreter and C compiler. It also implements a C library. Mes, the scheme interpreter, is written in about 5,000 lines of code of simple C. MesCC, the C compiler, is written in scheme. Together, Mes and MesCC can compile a lightly patched TinyCC that is self-hosting. Using this TinyCC and the Mes C library, it is possible to bootstrap the entire Guix System for i686-linux and x86_64-linux.

About GNU Guix

Guix System on the Pinebook Pro

2020-02-15T00:00:00Z

The new Pinebook Pro is a very lovable machine. For only $200 excluding shipping (and possibly taxes, I paid $68) the keyboard feels different but comparable to a flat Dell XPS 13 9350. The screen is beautiful and the machine is remarkably silent. So much that at times you can hear the display almost like in the old days.

I have been waiting for an affordable ARM with more than 2GiB of memory to help out with the ARM port of GNU Mes. Although the Qemu-service in Guix works neat, having the actual hardware helps a lot.

It does feel slow---even although it has 6 cores---so it may take some time before we can really leave proprietary MEs and BIOSes behind. Also, the Hurd does not run on ARM/AArch64 yet. Bogomips are at 48 per CPU compared to 4400 for an i7, but it is certainly not two orders slower. Is it? Compiling seems to be about 4x slower than the i7.

I got some inspiration from the lovely post on Guix on an ARM board by Julien Lepiller and had lots of help from Danny Milosavljevic during the Guix Days at Fosdem20.

In a previous post I described how I hacked to boot into a GNU Guix root on a Pinebook Pro, using the default kernel provided with the Debian image.

For the Guix System, I have packaged and deblobbed the Manjaro kernel, which seems to be where development of mainlining the Pinebook Pro kernel has moved.

We now have a recipe to install a true Guix System with Linux Libre. Also, I have added a u-boot package variants: we no longer depend on 3rd party binary images.

We start by infecting our beautiful Debian system with the Guix package manager

sudo apt install gpg
wget https://sv.gnu.org/people/viewgpg.php?user_id=15145 -qO - | gpg --import -
wget https://git.savannah.gnu.org/cgit/guix.git/plain/etc/guix-install.sh
sudo bash guix-install.sh

First, insert the microSD, tail -f /var/log/messages should say something like

Feb 15 14:33:01 armzalig kernel: [ 4150.344615] mmc0: new ultra high speed SDR104 SDXC card at address 0001
Feb 15 14:33:01 armzalig kernel: [ 4150.345537] mmcblk0: mmc0:0001 SD16G 58.9 GiB 
Feb 15 14:33:01 armzalig kernel: [ 4150.346755]  mmcblk0:

Then, add a bootable partition and create a file system (please verify the correctness of /dev/mmc* for your device!)

sudo parted -- /dev/mmcblk0 mkpart p 0% -1
sudo parted -- /dev/mmcblk0 set 1 boot on
sudo mkfs.ext4 -F /dev/mmcblk0p1

We need to upgrade Guix to a more recent version. At the time of writing we need to avoid bug #39352 and pull to c7dd15596ffd09ab40629c89e7014e51a4d7e95e

guix pull --commit=c7dd15596ffd09ab40629c89e7014e51a4d7e95e

After running that, it told me to do

export PATH="/home/janneke/.config/guix/current/bin${PATH:+:}$PATH"
hash guix

which I did, that may be a bit different for you.

guix environment guix --ad-hoc git
#git clone https://git.savannah.gnu.org/git/guix.git  # not yet
git clone https://gitlab.com/janneke/guix.git
cd guix
git checkout wip-pinebook-pro
./bootstrap
./configure --localstatedir=/var GUILE=$(type -p guile) GUILD=$(type -p guild)
make

I copied pine-book-pro.tmpl@savannah/pine-book-pro.tmpl@gitlab into arm-baar.scm

;; This is an operating system configuration template
;; for a "bare bones" pinebook pro

;; The default image's kernel 4.4.190 has
;;    microSD: /dev/mmcblk0
;;    eMMC: /dev/mmcblk1
;;
;; Note that after booting the Guix System with linux-libre
;; 5.5-pinebook-pro this changes to
;;    microSD: /dev/mmcblk1
;;    eMMC: /dev/mmcblk2

;; Assuming https://gitlab.com/janneke/guix.git wip-pinebook-pro
;; has been built in .
;; cp gnu/system/examples/pinebook-pro.tmpl arm-baar.scm
;; sudo -E ./pre-inst-env guix system init arm-baar.scm /mnt --fallback

(use-modules (gnu) (gnu bootloader u-boot))
(use-service-modules avahi networking ssh)
(use-package-modules admin bootloaders certs linux ssh)

(operating-system
  (host-name "armzalig")
  (timezone "Europe/Amsterdam")
  (locale "en_US.utf8")

  ;; Assuming not using a typewriter that needs qwerty slowdown
  (keyboard-layout (keyboard-layout "us" "dvorak"
                                    #:options '("ctrl:nocaps" "compose:menu")))

  ;; Assuming /dev/mmcblk0 is the microSD...
  (bootloader (bootloader-configuration
               (target "/dev/mmcblk0")
               (bootloader u-boot-pinebook-pro-rk3399-bootloader)))
  ;; ...and after booting, /dev/mmcblk1p1 is the root file system
  (file-systems (cons* (file-system (device "/dev/mmcblk1p1")
                                    (mount-point "/")
                                    (type "ext4"))
                       %base-file-systems))

  (kernel linux-libre-pinebook-pro)
  (kernel-arguments '("ethaddr=${ethaddr}" "eth1addr=${eth1addr}" "serial=${serial#}"
                      "video=HDMI-A-1:1920x1080@60" "video=eDP-1:1920x1080@60"
                      "vga=current"))
  (initrd-modules '())

  (users (cons* (user-account (name "guix")
                              (group "users")
                              (supplementary-groups '("wheel")))
                %base-user-accounts))
  (name-service-switch %mdns-host-lookup-nss)
  (packages (cons* nss-certs openssh wpa-supplicant-minimal %base-packages))
  (services (cons* (service dhcp-client-service-type)
                   (service openssh-service-type
                            (openssh-configuration
                             (port-number 2222)))
                   %base-services)))

Save it as arm-baar.scm, choose your hostname, timezone, locale and keyboard layout. After mounting the root file system

sudo mount /dev/mmcblk0p1 /mnt

install Guix onto it, doing

sudo -E ./pre-inst-env guix system init arm-baar.scm /mnt --fallback

says something like

The following derivations will be built:
   /gnu/store/7pad9i05ay9kmayh8l8i8r6wpir88f5g-system.drv
   /gnu/store/0rkjcqhkb30cban0291mqbv2yfi02n0f-boot.drv
   /gnu/store/vrfajn06i669wh27c2zia9wah7k1j3ws-activate.scm.drv
   /gnu/store/w1qchgxmvrsysd7q1r8h7izxb18r33g6-activate-service.scm.drv
   /gnu/store/g5awvk155l1nygd7mbg947pgcxx3cp3c-etc.drv
   /gnu/store/md0p8hcnfq2pf43wa51ajsapky53a1jm-provenance.drv
   /gnu/store/l2g009sdbm3x5qajnfgjfn4rj04p4l58-extlinux.conf.drv
building /gnu/store/md0p8hcnfq2pf43wa51ajsapky53a1jm-provenance.drv...
building /gnu/store/g5awvk155l1nygd7mbg947pgcxx3cp3c-etc.drv...
building /gnu/store/w1qchgxmvrsysd7q1r8h7izxb18r33g6-activate-service.scm.drv...
building /gnu/store/vrfajn06i669wh27c2zia9wah7k1j3ws-activate.scm.drv...
building /gnu/store/0rkjcqhkb30cban0291mqbv2yfi02n0f-boot.drv...
building /gnu/store/7pad9i05ay9kmayh8l8i8r6wpir88f5g-system.drv...
building /gnu/store/l2g009sdbm3x5qajnfgjfn4rj04p4l58-extlinux.conf.drv...
/gnu/store/bpq3gjfih8c1xgahw7yj3h18d1sw670l-system
/gnu/store/hgk8ya40n3pppp7sja12cdr6wkb3k0nr-extlinux.conf

initializing operating system under '/mnt'...
copying to '/mnt'...
populating '/mnt'...
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https//kluit.dezyne.org:8181'... 100.0%
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
substitute: updating substitutes from 'https//kluit.dezyne.org:8181'... 100.0%
downloading from https://ci.guix.gnu.org/nar/gzip/0dqzh840z4a8a23gvwc38ssmxb9qfcc2-u-boot-2020.01-pinebook-pro-1.365495a-checkout...
 u-boot-2020.01-pinebook-pro-1.365495a-checkout            1.8MiB/s 00:11 | 20.4MiB transferred
building /gnu/store/djgdaps803zizw77y9jgsg4m0dl06aik-u-boot-pinebook-pro-rk3399-2020.01-pinebook-pro-1.365495a.drv...
substitute: updating substitutes from 'https://ci.guix.gnu.org'... 100.0%
building /gnu/store/p97hj16a738kg64f5b87s2g54d5qmc3s-module-import-compiled.drv...
building /gnu/store/6r1xrpk1d17scaxpv7fzv1dxany9fafz-install-bootloader.scm.drv...
guix system: bootloader successfully installed on '/dev/mmcblk0'

Weirdly, we need to fixup extlinux.conf. Although the default

$ grep DEFAULT_FDT /gnu/store/zxb488q5l9c6j5pnazvp5s30z1p18gnm-u-boot-pinebook-pro-rk3399-2020.01-pinebook-pro-1.365495a/libexec/.config 
CONFIG_DEFAULT_FDT_FILE="rockchip/rk3399-pinebook-pro.dtb"

seems to be correct, upon boot u-boot wants to load rockchip-evb_rk3399.dtb

** File not found /gnu/store/4zsyqb40r34hp8q83fs5q3kpw4djs046-linux-libre-pinebook-pro-5.5.0/lib/dtbs/rockchip-evb_rk3399.dtb **

Oh, well

sudo sed 's,FDTDIR \([^ ]*\),FDT \1/rockchip/rk3399-pinebook-pro.dtb,' /mnt/boot/extlinux/extlinux.conf

And that's it, good luck!

sudo umount /mnt
sudo reboot

And there you have it

no WIFI or accelerated X yet; but you gotta love This is the GNU system. Welcome.

What really got me going here was a serial console. The trick is to get a working cable, remove the backcover

and flip the switch #9 Audio/UART upward

I first got one that did not work. When you plug-in a working cable in the client, /var/log/messages should show something like

Feb 15 15:03:55 localhost vmunix: [113105.608514] usb 1-1: new full-speed USB device number 8 using xhci_hcd
Feb 15 15:03:55 localhost vmunix: [113105.762159] usb 1-1: New USB device found, idVendor=0403, idProduct=6001, bcdDevice= 6.00
Feb 15 15:03:55 localhost vmunix: [113105.762161] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3
Feb 15 15:03:55 localhost vmunix: [113105.762162] usb 1-1: Product: FT232R USB UART
Feb 15 15:03:55 localhost vmunix: [113105.762163] usb 1-1: Manufacturer: FTDI
Feb 15 15:03:55 localhost vmunix: [113105.762164] usb 1-1: SerialNumber: AC01OG7W
Feb 15 15:03:55 localhost vmunix: [113105.765223] ftdi_sio 1-1:1.0: FTDI USB Serial Device converter detected
Feb 15 15:03:55 localhost vmunix: [113105.765246] usb 1-1: Detected FT232RL
Feb 15 15:03:55 localhost vmunix: [113105.765527] usb 1-1: FTDI USB Serial Device converter now attached to ttyUSB0

telling you that ttyUSB0 is now available. Then you can connect using screen

screen /dev/ttyUSB0 1500000

that even works before plugging it into the Pinebook. After plugging in the earphone jack and rebooting the Pinebook, you can follow, interact and debug the boot process.

About GNU Guix

About Pinebook Pro

PINEBOOK Pro

A Powerful, Metal and Open Source ARM 64-Bit Laptop for Work, School or Fun The Pinebook Pro is meant to deliver solid day-to-day Linux or *BSD experience and to be a compelling alternative to mid-ranged Chromebooks that people convert into Linux laptops. In contrast to most mid-ranged Chromebooks however, the Pinebook Pro comes with an IPS 1080p 14″ LCD panel, a premium magnesium alloy shell, 64/128GB of eMMC storage, a 10,000 mAh capacity battery and the modularity / hackability that only an open source project can deliver – such as the unpopulated PCIe m.2 NVMe slot (an optional feature which requires an optional adapter). The USB-C port on the Pinebook Pro, apart from being able to transmit data and charge the unit, is also capable of digital video output up-to 4K at 60hz.

[0]: A difficulty here is that the Pinebook Pro currently does not want to show a U-Boot prompt, command line or debug output. If you consider to buy one, you may want to also order a serial cable that might help debugging the boot sequence.