summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
-rw-r--r--challenges.mdwn12
-rw-r--r--community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn13
-rw-r--r--contributing.mdwn7
-rw-r--r--extensibility.mdwn15
-rw-r--r--faq/64-bit.mdwn24
-rw-r--r--faq/context_switch.mdwn8
-rw-r--r--faq/debugging_translators.mdwn10
-rw-r--r--faq/drivers.mdwn12
-rw-r--r--faq/foo_max.mdwn14
-rw-r--r--hurd/debugging/translator/gdb.mdwn10
-rw-r--r--hurd/glibc.mdwn4
-rw-r--r--hurd/rump/rumpusbdisk.mdwn2
-rw-r--r--hurd/running/debian/CrossInstall.mdwn7
-rw-r--r--hurd/running/debian/qemu_image.mdwn2
-rw-r--r--hurd/running/gnu.mdwn31
-rw-r--r--hurd/status.mdwn18
-rw-r--r--hurd/translator/remap.mdwn7
-rw-r--r--hurd/what_is_the_gnu_hurd.mdwn17
-rw-r--r--microkernel/mach/external_pager_mechanism.mdwn12
-rw-r--r--microkernel/mach/gnumach/projects/mach_5.mdwn10
-rw-r--r--news/2010.mdwn2
-rw-r--r--news/2013-09-27.mdwn2
-rw-r--r--news/2015-04-10-releases.mdwn2
-rw-r--r--news/2015-10-31-releases.mdwn2
-rw-r--r--news/2016-05-18-releases.mdwn2
-rw-r--r--news/2016-12-18-releases.mdwn2
-rw-r--r--open_issues/64-bit_port.mdwn160
-rw-r--r--open_issues/bcachefs.mdwn3
-rw-r--r--open_issues/runit.mdwn43
-rw-r--r--open_issues/tmpfs.mdwn26
-rw-r--r--tag/open_issue.mdwn15
-rw-r--r--tag/open_issue_tmpfs.mdwn15
-rw-r--r--unsorted/CrossHurd.mdwn4
33 files changed, 226 insertions, 287 deletions
diff --git a/challenges.mdwn b/challenges.mdwn
index 4c8e00f0..6a767aa7 100644
--- a/challenges.mdwn
+++ b/challenges.mdwn
@@ -19,12 +19,12 @@ successful true multi-server [[microkernel]] system for general-purpose desktop
use yet. This is still an ongoing research effort. Also the Hurd is not the
only multiserver operating system. Other examples include:
[[Genode OS|https://genode.org/]] (FOSS), [[MINIX 3|https://www.minix3.org/]] (FOSS),
-[[HELON OS|http://www.helenos.org/]] (FOSS), and [[QNX|https://blackberry.qnx.com/en]]
-(proprietary).
+[[HELON OS|http://www.helenos.org/]] (FOSS), [[Redox OS|https://www.redox-os.org/]],
+and [[QNX|https://blackberry.qnx.com/en]] (proprietary).
-Likewise, resource scheduling in distributed operating system kernels is a
-research topic. For example, read more about it on the relevant [[Open Issues
-page|open_issues/multiprocessing]]. Also, the [[microkernel/Viengoos]]
-research kernel project strives to explore these.
+Likewise, [[resource scheduling|open_issues/multiprocessing]] in distributed operating system kernels is a
+research topic. The GNU/Hurd also has
+[[open_issues/resource_management_problems]]. The [[microkernel/Viengoos]]
+research kernel project strives to fix these issues, but its development has ended.
TODO: more to come. [[!tag open_issue_documentation]]
diff --git a/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn b/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn
index 35e55518..b2fa5585 100644
--- a/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn
+++ b/community/weblogs/ArneBab/technical-advantages-of-the-hurd.mdwn
@@ -15,13 +15,22 @@ The filesystem implements stuff like Gnome VFS (gvfs) and KDE **network transpar
One practical advantage of this is that the following works:
- settrans -a ftp\: /hurd/hostmux /hurd/ftpfs /
- dpkg -i ftp://ftp.gnu.org/path/to/*.deb
+ $ settrans -a ftp\: /hurd/hostmux /hurd/ftpfs /
+ $ dpkg -i ftp://ftp.gnu.org/path/to/*.deb
This installs all deb-packages in the folder `path/to` on the FTP server. The shell sees normal directories (beginning with the directory “ftp:”), so shell expressions just work.
You could even define a Gentoo mirror translator (`settrans mirror\: /hurd/gentoo-mirror`), so every program could just access mirror://gentoo/portage-2.2.0_alpha31.tar.bz2 and get the data from a mirror automatically: `wget mirror://gentoo/portage-2.2.0_alpha31.tar.bz2`
+How about mounting a remote ISO file? Now that we can access ftp.gnu.org transparently,
+this is trivial!
+
+ $ settrans -c mnt /hurd/iso9660fs $PWD/ftp://ftp.gnu.org/old-gnu/gnu-f2/hurd-F2-main.iso
+ $ ls mnt/
+
+It is interesting to note that since the ISO9660 format is indexed, ftpfs does not have to
+download the whole ISO file, it merely fetches what iso9660fs requests.
+
Or you could add a unionmount translator to root which makes writes happen at another place. **Every user is able to make a readonly system readwrite** by just specifying where the writes should go. But the writes **only affect his view of the filesystem**.
Starting a network process is done by a translator, too: The first time something accesses the network card, the network translator starts up and actually provides the device. This replaces most **initscripts in the Hurd: Just add a translator to a node**, and the service will persist over restarts.
diff --git a/contributing.mdwn b/contributing.mdwn
index 7f4f3554..127554a4 100644
--- a/contributing.mdwn
+++ b/contributing.mdwn
@@ -160,7 +160,6 @@ packages](http://people.debian.org/~sthibault/hurd-i386/failed_packages.txt).
This is the list of tasks that we *want* to address soon, starting with the most pressing:
-* Add amd64 support to gdb, see [Flavio patch pending commit](https://sourceware.org/pipermail/gdb-patches/2024-February/206895.html)
* Fix shell output pipe replacement issue on amd64, see
[discussion](https://lists.gnu.org/archive/html/bug-hurd/2023-10/msg00062.html).
- This means adding an `i386x_float_state` and `i386_XFLOAT_STATE` thread status, that glibc would be able to use along `i386_REGS_SEGS_STATE` and `i386_FLOAT_STATE` in `_hurd_setup_sighandler` and `sigtreturn.c`. The structure would contain the `fp_save_kind`. That'll actually be needed both on `i386` and `x86_64` actually, to fix SSE use against signals in general.
@@ -172,7 +171,8 @@ This is the list of tasks that we *want* to address soon, starting with the most
* Port `dhcpcd`, see [call for help](https://lists.debian.org/debian-hurd/2023/11/msg00030.html)
* Make sure that lwip supports configuration by DHCP.
* Extensively test (e.g. running testsuites of glibc, perl, curl, rust-mio) and fix the lwip-based TCP/IP stack, to be sure we don't get regressions by switching to it.
-* Fix swapping with `rumpdisk`.
+* Fix swapping with `rumpdisk`
+ * Apparently some wiring cases is not effective, we are seeing pageout of rumpdisk memory.
* Fix the [GPLv2 vs GPLv3 licence incompatibility between ext2fs and libparted](https://bugs.debian.org/838244):
* For /hurd/ext2fs, use a different libstore that does not include the parted module.
* For /hurd/ext2fs.static in the bootstrap chain (e.g. to access wd0s1), add a storeio translator before it, and have ext2fs open it, use `file_get_storage_info` and access the underlying device. That wouldn't need any code modification if we were using an initial ramfs exposing that storeio on /dev/wd0s1.
@@ -187,13 +187,12 @@ This is the list of tasks that we *want* to address soon, starting with the most
* Rewrite `pthread_cond_*`, `pthread_rwlock_*`, `pthread_barrier_*` to use `gsync`, like `pthread_mutex_*` do (also see the nptl implementations, possibly just share with them).
* Improve rumpdisk's asynchronism, see end of `hurd/rumpdisk/block-rump.c`.
* Check performance of `rumpdisk` against the in-`gnumach` drivers.
-* Make `ext2fs` use xattr by default to store translators (see `use_xattr_translator_records`) after making sure the upgrade path works fine.
* Finish glib's file monitoring (see [merge request draft](https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3626) and [Debian bug](https://bugs.debian.org/1008208))
* Extend `ext2fs` to support 64bit time.
* Fix the `git` testsuite (just a few tests failing, used to pass).
-* Fix the `curl` testsuite (just a few tests failing).
* Fix the `subversion` testsuite (just a few tests failing).
* Fix the `vim` testsuite (just a few tests failing, used to pass).
+* Fix the `cmake` testsuite (just a few tests failing in latest version 4.0.0).
* Fix building `mesa`.
* Fix building `wayland`.
* Port `python-procps`.
diff --git a/extensibility.mdwn b/extensibility.mdwn
index ef89d5f2..bb1e0bee 100644
--- a/extensibility.mdwn
+++ b/extensibility.mdwn
@@ -17,5 +17,20 @@ no way to hook into the virtual file system. This has motivated the introductio
of separate, parallel interfaces by both the GNOME and KDE projects to provide
users a more integrated view of their objects.
+The Hurd introduces the concept of [[translators|hurd/translator]] to let users
+hook into the virtual filesystem. We have translators that let ordinary users
+create their own [[ext2 filesystem|hurd/translator/ext2fs]],
+[[ftp filesystem|hurd/translator/ftpfs]], iso filesystem,
+[[http filesystem|hurd/translator/httpfs]], etc. You can get started using
+the existing translators by reading the [[how to|hurd/translator/examples]] page.
+
+The Hurd's extensibility is not just limited to the VFS. It is possible for
+users to have their own [[TCP/IP|hurd/translator/pfinet]]
+[[stack|hurd/translator/lwip]] using the [[hurd/translator/remap]]
+translator. Users can create their own
+[[personal firewall|https://darnassus.sceen.net/~hurd-web/hurd/translator/eth-filter/]],
+run a personal [[hurd/translator/auth]] server, or isolate untrusted applications inside
+a [[hurd/subhurd]]. The possibilities are endless!
+
# External
* The Wikipedia article on [[!wikipedia extensibility]]
diff --git a/faq/64-bit.mdwn b/faq/64-bit.mdwn
index a41d215d..d3d6d046 100644
--- a/faq/64-bit.mdwn
+++ b/faq/64-bit.mdwn
@@ -13,23 +13,17 @@ License|/fdl]]."]]"""]]
[[!meta title="Is there a 64-bit version?"]]
-There are plans for 64-bit kernelland with 32-bit userland, which will notably
-permit to efficiently make use of more than 2 GiB memory and provide 4 GiB
+64-bit kernelland is supported with 32-bit userland, which notably
+permits to efficiently make use of more than 2 GiB memory and provide 4 GiB
userland addressing space.
-A 64-bit GNU/Hurd is also coming soon,
-progress is tracked on [[open_issues/64-bit_port]]!
-Hurd developers ported GNUMach to
-64-bit some time ago. Then they started making significant progress
-on the x86_64 userland port in Feb 2023. As of September 2024, the
-Debian hurd-amd64 port works just like the hurd-i386, except for
-missing packages and more
-[[bugs|https://lists.gnu.org/archive/html/bug-hurd/2024-07/msg00058.html]],
-namely swapping issues with rumpdisk and deadlocking issues with
-libdiskfs/ext2fs. We are currently building
-64-bit packages. We plan on supporting both a 32-bit and 64-bit Debian
-GNU/Hurd, only not both at the same time. However, there is no plan to fix the
-year 2038 concern on a 32-bit system.
+A 64-bit GNU/Hurd is also available, progress is tracked on [[open_issues/64-bit_port]]!
+As of April 2025, the Debian hurd-amd64 port works just like the hurd-i386, except for
+some bugs, namely swapping issues with rumpdisk and dumping core files.
+
+We plan on supporting both a
+32-bit and 64-bit Debian GNU/Hurd, only not both at the same time.
+However, there is no plan to fix the year 2038 concern on a 32-bit system.
That being said, you can always run a 32-bit version on a 64-bit machine, it
just works, processes are just limited to a couple GiB available memory.
diff --git a/faq/context_switch.mdwn b/faq/context_switch.mdwn
index 2d090c4c..55d20429 100644
--- a/faq/context_switch.mdwn
+++ b/faq/context_switch.mdwn
@@ -17,7 +17,13 @@ It is not, there is no real reason why it would be particularly slow, it is just
about switching virtual addresses and registers, which all OS have to perform
anyway.
-A quick-and-dirty benchmark:
+A quick-and-dirty benchmark.
+
+You can build this file with:
+
+ gcc -pthread -rt -o context-switch context-switch.c
+
+In `context-switch.c` write:
#include <fcntl.h>
#include <semaphore.h>
diff --git a/faq/debugging_translators.mdwn b/faq/debugging_translators.mdwn
index 1bd0deec..031b5778 100644
--- a/faq/debugging_translators.mdwn
+++ b/faq/debugging_translators.mdwn
@@ -11,12 +11,4 @@ License|/fdl]]."]]"""]]
[[!tag faq/development]]
-In order to [[debug|debugging]] translators and being able to step into glibc
-during it, on Debian you need the `hurd-dbgsym` and `libc0.3-dbg` packages installed.
-If you need to debug the initialization of the translator, start the translator
-like
-
- $ settrans -Pa /foo /usr/bin/env LD_LIBRARY_PATH=/usr/lib/debug /hurd/foofs
-
-The `-P` option will make it
-pause and you will be able to attach [[debugging/GDB]] to the process.
+See [[/hurd/debugging/translator]].
diff --git a/faq/drivers.mdwn b/faq/drivers.mdwn
index 923e3b38..16d60a9a 100644
--- a/faq/drivers.mdwn
+++ b/faq/drivers.mdwn
@@ -19,14 +19,18 @@ and you can use an [[SSD|hurd/rump/rumpdisk]]. If you have difficulty
installing the Hurd, then try setting your harddrive mode to "legacy"
in the BIOS. A cheaper option is the T43 (2GB max RAM).
-Other working Thinkpads include the X200, T400, or T500 Thinkpads,
+Other working Thinkpads include the X200, T400,
+[[T410|https://logs.guix.gnu.org/hurd/2025-04-25.log#103752]] or T500 Thinkpads,
which support internet connectivity via the ethernet port. You can
use an [[SSD|hurd/rump/rumpdisk]] on these laptops, which support a
maximum of 8GB of RAM. The Debian installer images from 2023 fail to
boot these machines, but you can install the Hurd via [[Debian's
-CrossInstall|hurd/running/debian/CrossInstall]]. Until we fix the
-libdiskfs/ext2fs issues on the [[64 bit port|faq/64-bit]], we
-recommend that you use the 32 bit version of the Hurd.
+CrossInstall|hurd/running/debian/CrossInstall]] or
+[[mmdebstrap|https://lists.debian.org/debian-hurd/2024/12/msg00003.html]].
+
+_While the [[64 bit port|faq/64-bit]] is about as stable as the 32-bit
+port, the rumpdisk support needed for it is still relatively experimental.
+For this reason we recommend casual Hurd users to use the 32 bit port._
Other hardware that is known to work includes the [[Dell Inspiron
1750|https://logs.guix.gnu.org/hurd/2024-09-28.log]] on i386
diff --git a/faq/foo_max.mdwn b/faq/foo_max.mdwn
index 5f736680..ccd09904 100644
--- a/faq/foo_max.mdwn
+++ b/faq/foo_max.mdwn
@@ -18,7 +18,12 @@ For porting guidelines, see [[hurd/porting/guidelines#PATH_MAX_tt_MAX_PATH_tt_MA
# Is it really standard not to define them?
-These macros are indeed optional in Posix, so not defining them remains standard-compliant.
+These macros are indeed optional in Posix, so not defining them remains
+standard-compliant. Quoting the standard:
+
+ A definition of one of the symbolic constants in the following list shall be
+ omitted from <limits.h> on specific implementations where the corresponding
+ value is equal to or greater than the stated minimum, but is unspecified.
Their definition was actually not completely clear, Posix 1990 was ambiguous
about it including `\0` or not, it was made clear later on that it does include
@@ -30,13 +35,14 @@ even depend on its revision, so to be rather queried at runtime with `pathconf`.
# But it's really convenient! Isn't allocating dynamically much more complex?
`FOO_MAX` constants are most often used as “reasonable size to allocate a
-path”. On Linux it is typically 4096, which is not that reasonable (a whole
+path”. On Linux `PATH_MAX` is typically 4096, which is not that reasonable (a whole
memory page, thus a TLB lookup) when manipulating a lot of paths. Allocating
dynamically would use much less memory.
Most often interfaces can be made to properly allocate dynamically. Notably,
-since Posix 2008 `realpath(path, NULL)` and `getcwd(NULL, 0)` allocate the path
-dynamically.
+since Posix 2008 `realpath(path, NULL)` allocates the path dynamically.
+Posix 2008 does not say that `getcwd(NULL, 0)` allocates the path dynamically,
+but BSD, Linux, and even windows do.
In general, using `FOO_MAX` in source code (with a large value) leads to code
that is not actually checking against overflows. `PATH_MAX` being 4096 is
diff --git a/hurd/debugging/translator/gdb.mdwn b/hurd/debugging/translator/gdb.mdwn
index 82a50736..fdf6adff 100644
--- a/hurd/debugging/translator/gdb.mdwn
+++ b/hurd/debugging/translator/gdb.mdwn
@@ -12,6 +12,8 @@ Say you want to try running file system server ([[`ext2fs`|translator/ext2fs]],
[[`jfs`|translator/jfs]], ...) against a modified version of
[[`libpager`|libpager]] and debug the latter one using [[debugging/GDB]].
+On Debian you need the `hurd-dbgsym` and `libc0.3-dbg` packages installed.
+
Set the [[hurd/translator]] like this:
$ settrans -fgap ↩
@@ -51,3 +53,11 @@ course):
[...]
Voilà.
+
+If you need to debug the initialization of the translator, start the translator
+like
+
+ $ settrans -Pa /foo /hurd/foofs
+
+The `-P` option will make it
+pause and you will be able to attach [[debugging/GDB]] to the process.
diff --git a/hurd/glibc.mdwn b/hurd/glibc.mdwn
index 8e330aef..736cc099 100644
--- a/hurd/glibc.mdwn
+++ b/hurd/glibc.mdwn
@@ -49,6 +49,10 @@ One can build libc this way:
$ make
$ make check -k
+One can run tests individually with:
+
+ $ make test t=wcsmbs/test-wcsnlen
+
One can run tests with the new libc by hand:
$ ./testrun.sh ~/test
diff --git a/hurd/rump/rumpusbdisk.mdwn b/hurd/rump/rumpusbdisk.mdwn
index 26e1a101..8463e670 100644
--- a/hurd/rump/rumpusbdisk.mdwn
+++ b/hurd/rump/rumpusbdisk.mdwn
@@ -14,7 +14,7 @@ License|/fdl]]."]]"""]]
# RumpUSBDisk
With RumpUSBDisk, the Hurd can use a usb to SATA dongle to access a
-SATA device. The StarTech offers a good quality dongle that works
+SATA device. StarTech offers a good quality dongle that works
well. The Hurd could then read/write data from a SATA device with an
fatfs or ext2 filesystem. Damien Zammit implemented [[rumpusbdisk
already|https://lists.gnu.org/archive/html/bug-hurd/2023-07/msg00025.html]].
diff --git a/hurd/running/debian/CrossInstall.mdwn b/hurd/running/debian/CrossInstall.mdwn
index 26cd77af..0f56a3e7 100644
--- a/hurd/running/debian/CrossInstall.mdwn
+++ b/hurd/running/debian/CrossInstall.mdwn
@@ -56,13 +56,6 @@ Ah, reboot and select "GNU (kernel GNUmach 1.3)" from the Grub menu. At the prom
# export TERM=mach
# ./native-install
-When done the native install requests that you reboot once again and rerun native-install.
-
- # reboot
- ...
- # export TERM=mach
- # ./native-install
-
Done, continue setting up your system.
----
diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn
index 9984ac33..8409bc8c 100644
--- a/hurd/running/debian/qemu_image.mdwn
+++ b/hurd/running/debian/qemu_image.mdwn
@@ -42,7 +42,7 @@ Optionally you may use `--curses` to keep your keyboard layout. If need be modpr
Note that if you do not have a command named `kvm`, you can try something across the lines of:
- $ qemu-system-i386 --enable-kvm -drive cche=writeback,file=$(echo debian-hurd-*.img) -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000
+ $ qemu-system-i386 --enable-kvm -drive cache=writeback,file=$(echo debian-hurd-*.img) -net user,hostfwd=tcp:127.0.0.1:2222-:22 -net nic,model=e1000
Or, if your machine does not allow for KVM acceleration, omit `--enable-kvm` from the command.
diff --git a/hurd/running/gnu.mdwn b/hurd/running/gnu.mdwn
index 964e7e8e..b45841df 100644
--- a/hurd/running/gnu.mdwn
+++ b/hurd/running/gnu.mdwn
@@ -2,31 +2,32 @@
# <a name="The_GNU_Operating_System"> </a> The GNU Operating System
-The GNU Operating System, Commonly referred to as simply "The GNU System", is a
+The GNU Operating System, commonly referred to as simply "The GNU System", is a
complete [[Unix]]-like operating system composed entirely of [free
software](http://www.gnu.org/philosophy/free-sw.html). The creation of the GNU
System is one of the goals of the [GNU Project](http://www.gnu.org/), which was
[launched in 1983](http://www.gnu.org/gnu/initial-announcement.html) by
-[Richard Stallman](http://www.stallman.org/). It has many ambitious goals that
-the GNU/Hurd intends to address.
-
-These goals include increased security through the [[principle of least
-privilege|https://en.wikipedia.org/wiki/Principle%5Fof%5Fleast%5Fprivilege]], an
-[[extensible system|extensibility]], conformation to open operating standards
-including [[POSIX|https://en.wikipedia.org/wiki/POSIX]], modularity, and
-respecting user freedom. Many of these goals are things that the GNU/Hurd can
-resolve, however the GNU/Hurd is not the most stable operating system yet.
+[Richard Stallman](http://www.stallman.org/). The GNU/Hurd intends to
+increase security through the [[principle of least
+privilege|https://en.wikipedia.org/wiki/Principle%5Fof%5Fleast%5Fprivilege]], provide an
+[[extensible system|extensibility]], conform to open operating standards
+including [[POSIX|https://en.wikipedia.org/wiki/POSIX]], contain a modular code-base, and
+[[respect user freedom|https://www.gnu.org/philosophy/free-sw.html]].
+Many of these goals are things that the GNU/Hurd can
+resolve, however the GNU/Hurd is not yet the most stable operating system.
If you are looking for a production ready GNU system, then [[hurd/running/Debian]] GNU/Hurd may
-not be the best choice for you. Debian GNU/Hurd currently lacks 64-bit support,
-many device drivers, sound support, SMP, and a few other essential bits that
-provide a flexible operating system.
+not be the best choice for you. Debian GNU/Hurd currently lacks many device drivers, sound
+support, and a few other essential bits that provide a flexible operating system.
+It also has some tricky [[problems|challenges]] to solve.
However, [[gnu.org|https://www.gnu.org/distros/free-distros.html]] maintains a
list of freedom respecting and production ready GNU/Linux systems. One of the
-most promising of these is [[GuixSD|https://www.gnu.org/software/guix/]], which
+most promising of these is [[Guix System|https://www.gnu.org/software/guix/]], which
is the GNU Guix System Distribution, which eventually plans to support the GNU
-Hurd as the kernel!
+Hurd as the kernel! You can even use a
+[[childhurd|https://guix.gnu.org/manual/devel/en/html_node/Virtualization-Services.html#The-Hurd-in-a-Virtual-Machine]]
+on Guix System!
## Resources
diff --git a/hurd/status.mdwn b/hurd/status.mdwn
index bc04d78d..28919995 100644
--- a/hurd/status.mdwn
+++ b/hurd/status.mdwn
@@ -34,6 +34,8 @@ drivers, and experimental support for SATA devices was added in May 2013.
Robert Millan worked on a port of the Rump kernel, which allowed to run a
sound driver in userland. This work now needs to be extended. Support for
character devices and other hardware (USB, multicore) is mostly missing.
+Damien Zammit added [[RumpDisk|hurd/rump/rumpdisk]], which lets the Hurd
+boot and use SSDs with a minimal NetBSD kernel running in userspace.
Although the [[POSIX
interface|faq/posix_compatibility]] is provided, some additional interfaces
@@ -56,14 +58,28 @@ official Debian release), in April 2015 the [[Debian
GNU/Hurd|hurd/running/debian]] team released [[Debian GNU/Hurd
2015|news/2015-04-29-debian_gnu_hurd_2015]]. Similarly, along Debian "stretch",
in June 2017 [[Debian GNU/Hurd 2017|news/2017-06-18-debian_gnu_hurd_2017]] was released.
+The latest release is from
+[[2023|https://darnassus.sceen.net/~hurd-web/news/2023-06-11-debian_gnu_hurd_2023/]].
+
+With [[Guix System|hurd/running/guix]] one can trivially run a childhurd or a
+hurd vm running atop GNU/Linux. The adventurous can run it on
+[[real iron|https://guix.gnu.org/blog/2024/hurd-on-thinkpad/]].
[[hurd/running/Arch_Hurd]] offers *LiveCDs* for testing and installation.
[[hurd/running/Nix]] provides QEMU images.
-
## Usability Reports
+### Joshua Branson, 2025-04-30
+
+I've had my T43 Thinkpad with 1.5 GB of RAM running Debian GNU/Hurd
+for about a year now. I use a combination of the i3 window
+manager, emacs, git, the netsurf web browser, and a terminal to edit
+this wiki. The Hurd is fairly stable, but it tends to lock up on me
+about once a month. While I am fairly certain that I have had some
+filesystem corruption, I have not noticed any lost files yet.
+
### Svante Signell, 2013-05-21
I have been running GNU/Hurd for some years now, with VMs, mainly in the
diff --git a/hurd/translator/remap.mdwn b/hurd/translator/remap.mdwn
index a0544c7c..06e3c8c5 100644
--- a/hurd/translator/remap.mdwn
+++ b/hurd/translator/remap.mdwn
@@ -31,9 +31,12 @@ On Debian, `/bin/sh` points to `dash`. Maybe you would rather it
point to `bash`.
$ ls -lha /bin/sh
- lrwxr-xr-x 1 root root 4 Jun 5 04:08 /bin/sh -> dash
+ lrwxr-xr-x 1 root root 4 Jun 5 04:08 /bin/sh -> dash
$ remap /bin/sh /bin/bash -- ls -lha /bin/sh
- -rwxr-xr-x 1 root root 1,2M 20 oct. 12:53 /bin/sh
+ -rwxr-xr-x 1 root root 1,2M 20 oct. 12:53 /bin/sh
+ /bin/settrans: fsys_goaway: (ipc/mig) server died
+
+(the warning is expected, it just tells that the exected command has finished)
## remapping python3
diff --git a/hurd/what_is_the_gnu_hurd.mdwn b/hurd/what_is_the_gnu_hurd.mdwn
index 09c26ee7..0ccead52 100644
--- a/hurd/what_is_the_gnu_hurd.mdwn
+++ b/hurd/what_is_the_gnu_hurd.mdwn
@@ -12,6 +12,13 @@ License|/fdl]]."]]"""]]
[[!meta title="What Is the GNU Hurd?"]]
The Hurd is the GNU project's replacement for the [[UNIX]] system's [[kernel]].
+There are several
+[[free software operating systems|https://www.gnu.org/distros/free-distros.en.html]]
+using the [[Linux kernel|https://en.wikipedia.org/wiki/Linux_kernel]]. The
+Hurd is an alternate operating system that uses a different kernel. You can
+read more about the status of the Hurd [[here|hurd/status]]. If you decide
+to use the Hurd, then we would recommend
+[[the Debian GNU/Hurd distribution|https://www.debian.org/ports/hurd/]].
The Hurd is firstly a collection of protocols formalizing how different
components may interact. The protocols are designed to reduce the mutual
@@ -23,7 +30,8 @@ access to its backing store and that the [[principal]] that started it own the
file system node to which it connects.
The Hurd is also a set of [[servers|translator]] that implement these
-protocols. They include file systems, network protocols and authentication.
+protocols. They include [[file systems|hurd/translator/ext2fs]], network
+protocols and [[authentication|hurd/translator/auth]].
The servers run on top of the [[microkernel/Mach]] [[microkernel]] and use
Mach's [[microkernel/mach/IPC]] mechanism to transfer information.
@@ -39,8 +47,8 @@ programs and libraries to operate. Let's look at an example.
Firefox invokes glibc's `send ()`, which in turn uses the pfinet (or
lwip) TCP/IP stack, which talk to our device drivers (rump or netdde),
-which finally talk to GNU Mach. Only GNU Mach runs in kernel space!
-Everything else is userspace!
+which can actually access the hardware without entering kernel space
+(GNU Mach). That's a lot of power for userspace!
The Hurd supplies the last major software component needed for a complete
[[GNU_operating_system|running/gnu]] as originally conceived by Richard
@@ -51,7 +59,10 @@ organization that is the home of the [GNU project](http://gnu.org/gnu/).
The Hurd development effort is a somewhat separate project from the
[[Debian_GNU/Hurd|hurd/running/debian]] port.
+Want to know what the Hurd can do? Read the [[status|hurd/status]] page.
Read about what the GNU Hurd is [[gramatically_speaking]].
Read about the [[origin_of_the_name]].
+
+Want to read more [[Hurd documentation|hurd/documentation]]?
diff --git a/microkernel/mach/external_pager_mechanism.mdwn b/microkernel/mach/external_pager_mechanism.mdwn
index ccb72421..4bc863f1 100644
--- a/microkernel/mach/external_pager_mechanism.mdwn
+++ b/microkernel/mach/external_pager_mechanism.mdwn
@@ -39,10 +39,10 @@ is sent an [[exception]], which is normally further propagated
as a segmentation fault. If there is an associated memory
object, Mach checks whether the corresponding [[page]] is in core.
If it is, it installs the page and resumes the task. Mach
-then invokes the memory object with the `memory_object_request`
+then invokes the memory object with the `memory_object_data_request`
method and the page to read. The memory manager then fetches
or creates the content as appropriate and supplies it to
-Mach using the `memory_object_supply` method.
+Mach using the `memory_object_data_supply` method.
# Creating and Mapping a Memory Object
@@ -120,7 +120,7 @@ mappings etc.
(A) The client does a memory access and [[faults|page_fault]]. The kernel catches
the fault and maps the address to the appropriate memory object. It
-then invokes the `memory_object_request` method on the associated
+then invokes the `memory_object_data_request` method on the associated
capability. (In addition to the page to supply, it also supplies the
control port so that the server can determine which kernel
sent the message.)
@@ -147,7 +147,7 @@ its own address space at the same time.
(E) The storeio server transfers the page to the server. The page is still
anonymous.
-(F) The manager does a `memory_object_supply` transferring the page to
+(F) The manager does a `memory_object_data_supply` transferring the page to
the kernel. Only now is the page not considered to be anonymous but
managed.
@@ -174,8 +174,8 @@ if the server does not deallocate the page quickly enough, it cannot
cause a denial of service: the kernel will just later double page it
to swap (the default pager is part of the [[tcb]]).
-(C) Mach then invokes `memory_object_return` <!-- doesn't exist --> method on the control
-object. The server is expected to save the page free <!-- ? --> it in a timely
+(C) Mach then invokes `memory_object_data_return` method on the control
+object. The server is expected to save the page and free it in a timely
fashion. The server is not required to send a response to the kernel.
(D) The manager then transfers the data to the storeio server which
diff --git a/microkernel/mach/gnumach/projects/mach_5.mdwn b/microkernel/mach/gnumach/projects/mach_5.mdwn
index 7b59170b..d7355f4b 100644
--- a/microkernel/mach/gnumach/projects/mach_5.mdwn
+++ b/microkernel/mach/gnumach/projects/mach_5.mdwn
@@ -54,11 +54,11 @@ rewrite rights and pointers to out-of-band memory, it has to parse the
message. As type information and values are interleaved, it has to
iterate over the whole message.
-Furthermore, there are two kinds of type descriptors, mach_msg_type_t
-and mach_msg_type_long_t. The reason for this is that the amount of
-data that can be described using mach_msg_type_t is just 131072 byte.
-This is because msgt_size is an 8-bit value describing the size of one
-element in bits, and msgt_number is an 12-bit value describing the
+Furthermore, there are two kinds of type descriptors, `mach_msg_type_t`
+and `mach_msg_type_long_t`. The reason for this is that the amount of
+data that can be described using `mach_msg_type_t` is just 131072 byte.
+This is because `msgt_size` is an 8-bit value describing the size of one
+element in bits, and `msgt_number` is an 12-bit value describing the
number of items.
### Required change to the message format
diff --git a/news/2010.mdwn b/news/2010.mdwn
index a1adc686..0e60451b 100644
--- a/news/2010.mdwn
+++ b/news/2010.mdwn
@@ -120,7 +120,7 @@ multi-server microkernel-based operating system, or if you are
interested in contributing to Hurd development in general, please see
<http://www.gnu.org/software/hurd/contributing.html>. Or just
talk to us at <bug-hurd@gnu.org> or the `#hurd` IRC
-channel on freenode.
+channel on libera.chat.
---
diff --git a/news/2013-09-27.mdwn b/news/2013-09-27.mdwn
index 4c4e9b81..9f5f7d32 100644
--- a/news/2013-09-27.mdwn
+++ b/news/2013-09-27.mdwn
@@ -46,7 +46,7 @@ Bug reports should be sent to [[mailing_lists/bug-hurd]] or filed on
<http://savannah.gnu.org/bugs/?group=hurd>. Requests for assistance
should be sent to [[mailing_lists/help-hurd]] or filed on
<http://savannah.gnu.org/support/?group=hurd>. You can also find us on
-the Freenode IRC network in the [[#hurd|IRC]] channel.
+the libera.chat IRC network in the [[#hurd|IRC]] channel.
---
diff --git a/news/2015-04-10-releases.mdwn b/news/2015-04-10-releases.mdwn
index 853eb81a..322c5000 100644
--- a/news/2015-04-10-releases.mdwn
+++ b/news/2015-04-10-releases.mdwn
@@ -36,7 +36,7 @@ Bug reports should be sent to [[mailing_lists/bug-hurd]] or filed on
<http://savannah.gnu.org/bugs/?group=hurd>. Requests for assistance
should be sent to [[mailing_lists/help-hurd]] or filed on
<http://savannah.gnu.org/support/?group=hurd>. You can also find us on
-the Freenode IRC network in the [[#hurd|IRC]] channel.
+the libera.chat IRC network in the [[#hurd|IRC]] channel.
---
diff --git a/news/2015-10-31-releases.mdwn b/news/2015-10-31-releases.mdwn
index b721b1fd..7721b762 100644
--- a/news/2015-10-31-releases.mdwn
+++ b/news/2015-10-31-releases.mdwn
@@ -164,6 +164,6 @@ Bug reports should be sent to [[mailing_lists/bug-hurd]] or filed on
<http://savannah.gnu.org/bugs/?group=hurd>. Requests for assistance
should be sent to [[mailing_lists/help-hurd]] or filed on
<http://savannah.gnu.org/support/?group=hurd>. You can also find us on
-the Freenode IRC network in the [[#hurd|IRC]] channel.
+the libera.chat IRC network in the [[#hurd|IRC]] channel.
"""]]
diff --git a/news/2016-05-18-releases.mdwn b/news/2016-05-18-releases.mdwn
index 33702f8c..f73b222f 100644
--- a/news/2016-05-18-releases.mdwn
+++ b/news/2016-05-18-releases.mdwn
@@ -174,6 +174,6 @@ Bug reports should be sent to [[mailing_lists/bug-hurd]] or filed on
<http://savannah.gnu.org/bugs/?group=hurd>. Requests for assistance
should be sent to [[mailing_lists/help-hurd]] or filed on
<http://savannah.gnu.org/support/?group=hurd>. You can also find us on
-the Freenode IRC network in the [[#hurd|IRC]] channel.
+the libera.chat IRC network in the [[#hurd|IRC]] channel.
"""]]
diff --git a/news/2016-12-18-releases.mdwn b/news/2016-12-18-releases.mdwn
index 6d4f9e26..f6213488 100644
--- a/news/2016-12-18-releases.mdwn
+++ b/news/2016-12-18-releases.mdwn
@@ -165,6 +165,6 @@ Bug reports should be sent to [[mailing_lists/bug-hurd]] or filed on
<http://savannah.gnu.org/bugs/?group=hurd>. Requests for assistance
should be sent to [[mailing_lists/help-hurd]] or filed on
<http://savannah.gnu.org/support/?group=hurd>. You can also find us on
-the Freenode IRC network in the [[#hurd|IRC]] channel.
+the libera.chat IRC network in the [[#hurd|IRC]] channel.
"""]]
diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
index b85d95de..01a2aad5 100644
--- a/open_issues/64-bit_port.mdwn
+++ b/open_issues/64-bit_port.mdwn
@@ -13,171 +13,25 @@ License|/fdl]]."]]"""]]
[[!inline pages="title(Is there a 64-bit version?)" feeds="no" raw="yes"]]
-**What is left for initial support (32-on-64) is**
-
- * Fixing bugs :)
-
**For pure 64bit support, we need to**
* bootstrap a distribution. Debian is done. Alpine-Hurd is mostly
bootstrapped. Reach out to Sergey if you are interested in an
Alpine-Hurd distribution with bleeding-edge software. Reach out
to Guix, if you want to help them bootstrap a 64bit Hurd.
- * port gdb
- * Fix bugs :)
- * Notably it seems to be requiring at least 2G memory to boot.
+
+**TODO**
+
+ * Fix swapping with rumpdisk
+ * Fix crash-dump-core server
**Installing via the installer image**
-The installer appears to work in qemu. Give it a shot! Let us know
+The installer works fine in qemu. Give it a shot! Let us know
how it works in real hardware!
[[http://cdimage.debian.org/cdimage/ports/latest/hurd-amd64/current/]]
-**Installing a 64bit chroot**
-
-You can use the pre-built image from https://people.debian.org/~sthibault/hurd-i386/initrd-amd64.img.gz and boot that.
-
-Make sure to have `debootstrap >= 1.0.128+nmu2+hurd.1`
-
- debootstrap --foreign --verbose --arch hurd-amd64 --include=debian-keyring,wget,curl,inetutils-ping,openssh-server,openssh-client,nano,less --keyring=/usr/share/keyrings/debian-keyring.gpg sid chroot-hurd-amd64 https://people.debian.org/~sthibault/tmp/hurd-amd64
- mkdir chroot-hurd-amd64/etc/apt/trusted.gpg.d
- ln -s /usr/share/keyrings/debian-keyring.gpg chroot-hurd-amd64/etc/apt/trusted.gpg.d/
-
-Then boot it, it will drop you into a shell. You'll probably want to use a nicer shell:
-
- bash
-
-You need to make / writable:
-
- fsysopts / --writable
-
-and then run the second stage of the deboostrap (and clear debs):
-
- /debootstrap/debootstrap --second-stage
- apt clean
-
-set a root password:
-
- passwd
-
-Avoid core dumpings for now (not supported and hangs):
-
- rm -f /servers/crash
- ln -s crash-kill /servers/crash
-
-Disable the Hurd console, buggy for now:
-
- export TERM=mach
- nano /etc/default/hurd
- # set ENABLE to 'false'
-
-And reboot:
-
- reboot-hurd
-
-After reboot, you'll probably want to setup network:
-
- vi /etc/network/interfaces
- # put there this:
- auto /dev/eth0
- iface /dev/eth0 inet static
- address 10.0.2.15/16
- gateway 10.0.2.2
-
-**Creating a 64bit disk image**
-
-You can use the pre-built image from https://people.debian.org/~sthibault/hurd-i386/disk-amd64.img.gz and boot that.
-
-To make a bootable system we really better make the disk image partitioned, and mount the partition:
-
- dd < /dev/zero > disk.img bs=1M count=1 seek=1000
- fdisk disk.img
- # create a new primary partition spanning the whole disk: n p and just accept the defaults, and finish with w
- settrans -ca disk /hurd/storeio -T typed file:disk.img
- settrans -ca disk1 /hurd/storeio -T typed part:1:file:disk.img
- /sbin/mke2fs -E root_owner=$UID:0 disk1
- settrans -ca chroot-hurd-amd64 /hurd/ext2fs disk1
-
-(here we assume that fdisk puts the partition at sector 2048, that's indeed the
-current default behavior)
-
-Then run the same debootstrap command as above.
-
-You can then make the disk bootable:
-
- mkdir chroot-hurd-amd64/boot/grub
- tee chroot-hurd-amd64/boot/grub/grub.cfg << 'EOF'
- set default="0"
- set timeout=5
- menuentry "Debian GNU/Hurd amd64" {
- insmod ext2
- set root=(hd0,1)
- multiboot /boot/gnumach-1.8-486.gz root=part:1:device:wd0
- module /hurd/pci-arbiter.static pci-arbiter \
- --host-priv-port='${host-port}' --device-master-port='${device-port}' \
- --next-task='${disk-task}' \
- '$(pci-task=task-create)' '$(task-resume)'
- module /hurd/rumpdisk.static rumpdisk \
- --next-task='${fs-task}' \
- '$(disk-task=task-create)'
- module /hurd/ext2fs.static ext2fs --readonly \
- --multiboot-command-line='${kernel-command-line}' \
- --exec-server-task='${exec-task}' -T typed '${root}' \
- '$(fs-task=task-create)'
- module /lib/ld-x86-64.so.1 exec /hurd/exec '$(exec-task=task-create)'
- }
- EOF
- grub-install --modules="part_msdos ext2" --boot-directory chroot-hurd-amd64/boot disk
- settrans -ga chroot-hurd-amd64
- settrans -ga disk
- settrans -ga disk1
-
-Then boot it, and proceed like for the chroot case.
-
-**Creating a pbuilder chroot**
-
-Here is a sample `/etc/pbuilderrc`:
-
- MIRRORSITE=https://people.debian.org/~sthibault/tmp/hurd-amd64
- AUTOCLEANAPTCACHE=yes
- EXTRAPACKAGES="eatmydata"
- if [ -z "$LD_PRELOAD" ]; then
- LD_PRELOAD=libeatmydata.so
- else
- LD_PRELOAD="$LD_PRELOAD":libeatmydata.so
- fi
- export LD_PRELOAD
- DEBOOTSTRAPOPTS=(
- '--variant=buildd'
- '--force-check-gpg'
- '--keyring=/usr/share/keyrings/debian-keyring.gpg'
- )
- APTKEYRINGS=(/usr/share/keyrings/debian-keyring.gpg)
-
-And this is needed until we get the `aptitude` package built:
-
- sudo ln -sf pbuilder-satisfydepends-apt /usr/lib/pbuilder/pbuilder-satisfydepends
-
-And then you can run `sudo pbuilder create` , `sudo pbuilder login` , `pdebuild`
-
-**Installing from the debian-ports archive**
-
-For now it's quite empty (not even gcc), but it can be debootstrapped. That will be used to build packages on the buildds.
-
- debootstrap --foreign --verbose --arch hurd-amd64 --extra-suites=unreleased --include=debian-ports-archive-keyring --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg sid chroot-hurd-amd64 https://deb.debian.org/debian-ports/
-
-**Installing proper & more packages**
-
-The `people.debian.org` repository is only for bootstraping the distribution. Proper packages are getting uploaded on the usual mirror:
-
- deb http://deb.debian.org/debian-ports sid main
- deb http://deb.debian.org/debian-ports unreleased main
-
**Installing a 64bit system**
-In principle crosshurd should be working, one however should add this source to get more packages for now:
-
- deb http://people.debian.org/~sthibault/tmp/hurd-amd64 unstable
-
-into /etc/crosshurd/sources.list/gnu
+In principle crosshurd should be working.
diff --git a/open_issues/bcachefs.mdwn b/open_issues/bcachefs.mdwn
index aa39bce0..330a41e1 100644
--- a/open_issues/bcachefs.mdwn
+++ b/open_issues/bcachefs.mdwn
@@ -12,8 +12,7 @@ License|/fdl]]."]]"""]]
[[!tag open_issue_hurd]]
The Hurd's primary filesystem is ext2, which works but lacks modern
-features. With ext2, Hurd users reguarly deal with filesystem
-corruption. Ext2 does not have a journal, so Hurd users occasionally
+features. Ext2 does not have a journal, so Hurd users occasionally
have to deal with filesystem corruption. `fsck` can fix most of the
issues (with loss of random data), but without a proper journal the
Hurd currently is not a good a OS for long-term data storage.
diff --git a/open_issues/runit.mdwn b/open_issues/runit.mdwn
index 659b81ea..cda495ae 100644
--- a/open_issues/runit.mdwn
+++ b/open_issues/runit.mdwn
@@ -9,42 +9,11 @@ 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]]."]]"""]]
-[[!tag open_issue_porting]]
+[[!tag open_issue]]
-The `runit` package doesn't work, even its test suite doesn't finish.
+In March of 2025, João got the Hurd to use
+[[runit instead of sysvinit|https://lists.debian.org/debian-hurd/2025/03/msg00023.html]].
+He has so far been unsuccessful to start the [[hurd-console|hurd/console]].
-[[Thomas_Schwinge|tschwinge]] once was having a look at that, but this very
-report is just from his memory, and his memory is dim... The problem *might*
-either be a time stamping issue (which might be fixed by now) or it *might* be
-the `select` call failing issue we're seeing from time to time. Or something
-else.
-
-[[Harish Badrinath|harishbadrinath]]
-Originally answered by Samuel Thibault:
-> 120->proc_dostop_request ( 138) = 0
->
-> </snip>
-
-Usual issue with rpctrace: it does not support fork().
-
- I've checked a backtrace in gdb, got this:
-
- 0x0105af6c in mach_msg_trap ()
- at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
- 1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140,
- timeout=1000020, notify=0) at msg.c:110
- 2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0,
- timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324
- 3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48
- 4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29
- 5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543
-
- and main() shows up as:
-
- sig_unblock(sig_term);
- sig_unblock(sig_child);
- -> iopause(x, 2 +haslog, &deadline, &now);
- sig_block(sig_term);
- sig_block(sig_child);
-
-So it simply looks like the known "signals don't interrupt select" bug.
+The Hurd project could also use the [[Shepherd|open_issues/shepherd]]
+as another alternative init system.
diff --git a/open_issues/tmpfs.mdwn b/open_issues/tmpfs.mdwn
new file mode 100644
index 00000000..9c86db9a
--- /dev/null
+++ b/open_issues/tmpfs.mdwn
@@ -0,0 +1,26 @@
+[[!meta copyright="Copyright © 2025 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]]."]]"""]]
+
+[[!tag open_issue_tmpfs]]
+
+For instance the X server crashes on fvwm startup, or mupdf crashes,
+when /run is served by a tmpfs.
+
+What happens is that they create an shm (shmget, thus a file in
+/run/shm/, backed by tmpfs), then map it (shmat, i.e. open/mmap/close of
+the file), then remove access to it (shmctl(`IPC_RMID`), i.e. unlink the
+file).
+
+The issue is that even if the file is still mapped, unlinking it from
+tmpfs makes tmpfs `mach_port_deallocate` the memobj, which apparently
+drops the object completely, and subsequent accesses to the mmap thus
+fail with SIGBUS. We'd need a way for tmpfs to know about the
+mappings of the pager object, to avoid shutting it down. Or a way to
+keep the object alive even if tmpfs has deallocated its port to it.
diff --git a/tag/open_issue.mdwn b/tag/open_issue.mdwn
new file mode 100644
index 00000000..d4fac733
--- /dev/null
+++ b/tag/open_issue.mdwn
@@ -0,0 +1,15 @@
+[[!meta copyright="Copyright © 2018 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 title="open_issue"]]
+
+[[!map
+pages="tagged(open_issue)"
+show=title]]
diff --git a/tag/open_issue_tmpfs.mdwn b/tag/open_issue_tmpfs.mdwn
new file mode 100644
index 00000000..7c410b8a
--- /dev/null
+++ b/tag/open_issue_tmpfs.mdwn
@@ -0,0 +1,15 @@
+[[!meta copyright="Copyright © 2018 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 title="open_issue_tmpfs"]]
+
+[[!map
+pages="tagged(open_issue_tmpfs)"
+show=title]]
diff --git a/unsorted/CrossHurd.mdwn b/unsorted/CrossHurd.mdwn
index 3313eba3..3e3eca8c 100644
--- a/unsorted/CrossHurd.mdwn
+++ b/unsorted/CrossHurd.mdwn
@@ -58,9 +58,7 @@ Set TERM variable and run native-install script.
export TERM=mach
./native-install
-At the end native-install wants you to reboot and run it again. Do so and remember to set the TERM variable as well.
-
-After the second reboot and native-install run you can remove the '-s' in the kernel line above and boot GNU/Hurd as a normal user.
+You can then remove the '-s' in the kernel line above and boot GNU/Hurd as a normal user.
## <a name="Logging_in"> Logging in </a>