1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
|
[[!meta copyright="Copyright © 2026 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]
[[!meta date="2026-03-02 06:07 UTC"]]
Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd
developments in Q1 of 2026!
[[!if test="included()" then="""[[!toggle id=full_news
text="Details."]][[!toggleable id=full_news text="[[!paste id=full_news]]"]]"""
else="
[[!paste id=full_news]]"]]
[[!cut id="full_news" text="""
Brent W. Baccala debugged some `x86_64` SMP issues with a Claude AI
bot. The bot did not contribute any code. It just found some
incorrect code that Damien then fixed. It did get [some things
wrong](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00134.html),
but it was incredibly helpful pointing out several problems. You can
read its report
[here](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00045.html).
Joshua Branson tweaked the hurd wiki. The most helpful addition is [[this
page|/hurd/running/flash_qemu_img]],
which documents how to flash a working qemu hurd image directly to an
HDD or SSD. This is a *really easy* way to install the Hurd on real
hardware! Buy a supported machine from [[this page|faq/drivers]] and
give it a shot! Consider this another reminder that the Hurd project
could use more documentation writers. It's an easy way to
[[contribute|contributing#index3h1]]. As a fun fact, Joshua wrote this qoth on
the Hurd running on a T420 with 12 GB of RAM! Running Debian GNU/Hurd on
bare metal these days is largely fairly stable. Emacs, i3, netsurf,
and luakit all work just fine and most of the Debian package archive
compiles without issue on the Hurd.
Etienne Brateau fixed a [compilation error](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00194.html).
He also provided a [simple test program](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00010.html)
that exposed a [rather serious threading bug](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00012.html),
which [Samuel promptly fixed](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00038.html).
This is a good reminder that writing simple C test programs that
successfully run on Linux, but fail on the Hurd can have a large
impact.
Gianluca Cannata worked on our [httpfs translator](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00138.html).
Diego Nieto Cid added a `daemon-wait` [option for console-client](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00229.html).
This can help users with slow machines avoid a broken Hurd console.
He also fixed a [rumpdisk compilation issue](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00195.html).
Mike Kelley fixed a deadlock in [SMP enabled GNU Mach kernels](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00165.html).
He also fixed a [page fault in amd64 SMP kernels](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00197.html).
He fixed another deadlock in the [alarm () function](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00059.html).
He fixed a [panic when running large builds](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00122.html)
without the `mach-defpager`. He also fixed some of our [signal related code](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00003.html).
He worked with Samuel to investigate an odd [bug](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00135.html).
Their detailed investigation uncovered and lead to a fix in the [Hurd's ext2's xattr code](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00072.html).
Joan Lledó updated some patches for the [dhcpcd port](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00062.html)
as well as some patches for [upstream liblwip](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00054.html).
He also tweaked our [lwip translator](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00049.html).
He also added a [glibc patch](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00041.html)
for `IP_PKTINFO`.
Milos Nikic
[added](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00048.html)
[some](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00244.html)
[various](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00245.html)
[fixes](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00113.html).
He also made
[many](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00060.html)
[considerable](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00235.html)
[contributions](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00221.html)
[on](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00220.html)
[filesystem](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00219.html)
[related](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00142.html)
things including [adding ext2fs support for 64 bit time](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00230.html),
He also fixed a [rumpdisk deadlock](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00233.html).
He also fixed a potential lock in [GNU Mach](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00039.html).
He fixed some [IPC issues in glibc](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00040.html).
He [contributed some](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00043.html)
[tiny fixes](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00028.html)
to speed up GNU Mach's IPC. His most exciting work is a [JDB2 binary
compliant journal](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00186.html),
which is an ext3/ext4 compatible journal. The Hurd may soon be running on
`ext3fs` or `ext4fs` instead of `ext2fs`! He writes:
I have been working on creating a prototype for a journal inside
ext2fs which is fully Linux compatible (binary JBD2 compatible). This
enables standard Linux tools (e2fsck, tune2fs, debugfs, etc.) to work
seamlessly with Hurd partitions.
This means one can mount a Hurd image from Linux and fix any issues
with the drive using standard journaling tools if the need
arises. While this is currently a prototype with polish still
required, it is functional.
Key Features:
* Log Replay: The driver writes JBD2-compliant transactions. I have
verified that after a hard crash of the Hurd guest, a Linux host
running e2fsck correctly replays the journal and restores filesystem
metadata consistency.
* Continuous Operation: The driver handles ring-buffer wrap-around and
checkpoints correctly. I have tested it with sustained loads
(50,000+ transaction loops) without deadlocks or corruption.
* Crash Safety: I have verified via "sabotage tests" (modifying the
disk offline after a crash) that the journal accurately restores the
correct metadata state.
* Lightweight: The implementation consists of only a few new files and
~800 lines of code.
You can read the complete email [here](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00186.html).
He then tweaked the code a few times and summed up the current status.
He [writes:](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00166.html)
This is it. I have applied numerous fixes, performance tweaks, and
cleanups. I am happy to report that this (the journal) now performs on
par with unjournaled ext2 on normal workloads, such as
configuring/compiling the Hurd, installing and reinstalling packages
via APT, and untarring large archives (like the Linux kernel). I have
also heavily tested it against artificial stress conditions (which I
am happy to share if there is interest), and it handles highly
concurrent loads beautifully without deadlocks or memory leaks.
Progressive checkpointing ensures the filesystem runs smoothly, and
the feature remains strictly opt-in (until a partition is tuned with
tune2fs -j, the journal is completely inactive).
The new API in libdiskfs is minimal but expressive enough to wrap all
filesystem operations in transactions and handle strict POSIX sync
barriers.
Manolo de Medici fixed a [bug allowing unprivileged users to modify the system
time](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00235.html).
He also worked on [partially opening up the processor set API to unprivileged processes](https://lists.gnu.org:443/archive/html/bug-hurd/2026-03/msg00169.html).
Samuel Thibault gave an update on the [GNU Hurd project](https://fosdem.org/2026/schedule/event/7FZXHF-updates_on_gnuhurd_progress_rump_drivers_64bit_smp_software_bootstrapping/).
His talk dived into [[hurd/rump/rumpnet]], [[hurd/rump/rumpdisk]],
[[open_issues/smp]], etc. It was quite an interesting talk.
Essentially the Hurd is becoming a fairly stable option for daily
computing. Check out our [[hurd/status]] page for more information.
He provided numerous fixes for packages that were failing to build,
like
[xserver-xorg-input-keyboard](https://lists.debian.org/debian-hurd/2026/01/msg00020.html).
He also reported on a [rumpnet bug](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00075.html),
which highlighted an interesting feature of the Hurd's design. When
Hurd's new or experimental device drivers crash, it does not bring
down the system. One can just restart the driver. If a device driver
crashes in Linux or BSD land, you may be in trouble.
He also discovered why the Hurd's crash translator [hanged when generating core files on amd64](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00074.html).
Thanks to a lot of code from Damien, Samuel was able to upload an
[amd64 SMP kernel to Debian Hurd](https://lists.debian.org/debian-hurd/2026/02/msg00103.html)!
This kernel still restricts processes to `cpu0`, but with the
`/sbin/smp` utility, one can experimentally run applications on
multiple cores. Once we fix the various race conditions, we can run
more of the Hurd via SMP. Please be aware that testing programs via
`/sbin/smp` can lead to crashes.
He also worked on fixing [xmm state restoration on signal](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00056.html).
Mesa was also ported to the Hurd. The patches are not quite [merged upstream](https://gitlab.freedesktop.org/mesa/libdrm/-/merge_requests/443).
The Hurd does not have a DRM yet, so the performance
is quite poor. `nexussfan` on irc ported
[ClassiCube](https://github.com/ClassiCube/ClassiCube/pull/1517).
It runs quite slowly. We are hoping to eventually add a proper DRM
to the Hurd. Please reach out if you'd like to help us achieve this.
Damien Zammit [ported qemu to the Hurd](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00266.html).
He is currently using it for his [continuous integration](https://mail.gnu.org/archive/html/bug-hurd/2026-01/msg00199.html).
It uses a Hurd host to launch qemu to test GNU Mach. He made many
contributions to the Hurd's
[CI](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00183.html)
including [testing the Hurd's xen support](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00021.html). He
[fixed GNU Mach compilation on GCC 10](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00182.html).
He also contributed
[a](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00111.html)
[lot](https://lists.gnu.org/archive/html/bug-hurd/2026-02/msg00127.html)
[of](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00148.html)
[fixes](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00181.html)
[for](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00098.html)
[the Hurd's](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00083.html)
[x86_64](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00007.html)
[support](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00185.html).
Thanks to Damien's numerous contributions, the Hurd's SMP support is
becoming far more useful!
If you did not see the recent Guix Hurd news, then please check out
their [most recent blog post](https://guix.gnu.org/en/blog/2026/the-64-bit-hurd)! There are
currently two active GNU Hurd distributions: Debian GNU/Hurd and GNU
Guix Hurd. These two distributions run on real hardware! If you have
been closely reading the `#hurd` irc channel, then you may have heard
about some work on adding another Hurd distribution. Perhaps we will
have more to report on this exciting news in the next Qoth!
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
detailed|hurd/documentation]].
**GNU Mach** is the microkernel upon which a GNU Hurd system is based. It
provides an Inter Process Communication (IPC) mechanism that the Hurd uses to
define interfaces for implementing in a distributed multi-server fashion the
services a traditional operating system kernel provides. [[More
detailed|microkernel/mach/gnumach]].
"""]]
|
