diff options
64 files changed, 961 insertions, 758 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/gsoc/project_ideas/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn index 28c95626..99befbf7 100644 --- a/community/gsoc/project_ideas/tcp_ip_stack.mdwn +++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn @@ -19,7 +19,7 @@ lwip as a complete replacement for pfinet. However, lwip uses the netdde device drivers for wireless chips, which are old drivers from an old version of linux. To use lwip for a wifi connection on more modern hardware, one would also need modern device drivers to access the internet. The promising approach to this is using -a rump kernel. This is essentially the New Driver Framework google summer of +[[hurd/rump/rumpnet]]. This is essentially the [[New Driver Framework|community/gsoc/project_ideas/driver_glue_code]] google summer of code project idea. Hopefully, one day soon the Hurd project will completely replace pfinet with lwip. diff --git a/community/gsoc/project_ideas/xmlfs.mdwn b/community/gsoc/project_ideas/xmlfs.mdwn index 5e5eaa13..41c0b018 100644 --- a/community/gsoc/project_ideas/xmlfs.mdwn +++ b/community/gsoc/project_ideas/xmlfs.mdwn @@ -15,7 +15,7 @@ different format. This is a very powerful ability: it allows using standard tools on all kinds of data, and combining existing components in new ways, once you have the necessary translators. -A typical example for such a translator would be xmlfs: a translator that +A typical example for such a translator would be [[hurd/translator/xmlfs]]: a translator that presents the contents of an underlying XML file in the form of a directory tree, so it can be studied and edited with standard filesystem tools, or using a graphical file manager, or to easily extract data from an XML file in a 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 127554a4..90ec1eee 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -90,6 +90,7 @@ people who would like to dive into the code but just lack a "somewhere to begin with". Make sure to check out the most up-to-date version on <https://darnassus.sceen.net/~hurd-web/contributing> +* Make block size configurable in libstore, probably through a libstore layer (similarly to the part libstore layer) * Teach rsync to use `*getxattr` and friends on GNU/Hurd too, to enable the -X option, so as to preserve translator entries. * Avoid GCC trampolines: as discussed in <https://gcc.gnu.org/onlinedocs/gccint/Trampolines.html> these happen when we pass the address of a nested function to another function. This can be seen by running `readelf -S file.o | grep GNU-stack | grep X`, for instance that happens in libdiskfs/file-exec.c, libdiskfs/io-revoke.c. We can't really use -fno-trampoline, we should instead add `void *data` parameters to iterators such as `ports_class_iterate` or `fshelp_exec_reauth`, so that the nested functions can be made mere static functions that get their information from the `void *data` parameter. * Implement `pthread_setschedparam` and `sched_setscheduler` in glibc by calling mach's `thread_policy` and `thread_priority`. @@ -160,11 +161,10 @@ 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: -* 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. +* Finish fixing shell output pipe replacement issue on amd64, see +[discussion](https://lists.gnu.org/archive/html/bug-hurd/2025-04/msg00021.html) and [remaining issue](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00115.html) +* Fix `i386_debug_state` for 64b support for use by gdb's hardware watchpoints * Check the [packages build failures differences](https://people.debian.org/~sthibault/hurd-amd64/failed_diff.txt) between hurd-i386 and hurd-amd64: they are failing on hurd-amd64 but are successful on hurd-i386. Possibly it's just a mere missing `s/hurd-i386/hurd-any/` in the debian/ directory, or a new bug that actually also affects hurd-i386 if you rebuild the package there now, but possibly it's a more profound issue in the amd64 port. -* On amd64, fix memcpy (> 16 bytes) from `/dev/mem` (makes hurd-console crash) * On amd64, fix crash-core * On amd64, fix running posixtestsuite (not necessarily fixing the tests themselves, but at least make sure it doesn't crash the box ; it could still be useful to compare the output on 32bit and 64bit are the same with the same gnumach/hurd/glibc). * Settle CI for mig+gnumach+hurd+glibc. @@ -179,24 +179,23 @@ This is the list of tasks that we *want* to address soon, starting with the most * Prevent duplicate instances of `rumpdisk` from competing for the disk PCI cards (e.g. when a second one gets started from a chroot), otherwise mayhem happens. * Fix the memory consumption of `rumpdisk`. * Plug acpi shutdown event. -* Add overcommit limitation support to gnumach (`RLIMIT_AS`): limit the virtual size of processes to half of the memory + swap size. Unless `MAP_NORESERVE` is passed to `mmap`. -* Integrate `rumpusbdisk` with the rest of the disk translators etc. +* Check that `MAP_NORESERVE` passed to `mmap` avoids the overcommit limitation recently introduced in gnumach (`RLIMIT_AS`) * Fix `tmpfs` losing files, see [discussion](https://lists.gnu.org/archive/html/bug-hurd/2015-02/msg00091.html). * Port `libasan`/`lsan`/`ubsan`/`libtasn` so we can use these sanitizers (youpi did some of it, pending clean/submit). -* Finish moving `pthread_` symbols from `libpthread` to `libc`, see for instance [some moves](https://sourceware.org/pipermail/libc-alpha/2023-March/146425.html), synchronize with Guy-Fleury Iteriteka. * 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. * 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. +* Port `golang` (gccgo is already ported). * Fix the `git` testsuite (just a few tests failing, used to pass). * 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`. * Implement a `rumpnet`. + * A first version was committed, with just the wm support is included. The phy lib is there but not the if_* drivers. * Implement a `rumpfs`. * Fix `SMP` support. @@ -245,6 +244,12 @@ After you have a Hurd vm set up and running: * Start hacking. * For shutting down, use `reboot`, then press `c` in grub and issue halt (to avoid filesystem corruption). Adding `--no-reboot` to the qemu line should help, too. +<a id="developer-workflows" name="developer-workflows"></a> +## Developer Workflows + +You might want to take a look at our [[developer workflow +recommendations|contributing/developer-workflows]]. + --- <a name="hurd_on_modern_microkernel"></a> # Design / Research: GNU Hurd on a Modern Microkernel diff --git a/contributing/developer-workflows.mdwn b/contributing/developer-workflows.mdwn new file mode 100644 index 00000000..6e94661a --- /dev/null +++ b/contributing/developer-workflows.mdwn @@ -0,0 +1,110 @@ +[[!meta copyright="Copyright © 2024 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="Developer Workflows"]] + +[[!toc levels=2]] + +Contributing to a free software project for the first time, can be a +little overwhelming. There's lots of tools that can help you +contribute: autotools, +[[gdb|https://www.sourceware.org/gdb/documentation/]], +[[git|https://git-scm.com/docs/user-manual]], handling lots of email +from mailing lists, text editors, etc. Don't try to immediately +master everything! You have time to figure it all out! Learn a +little bit and go from there. To help you in that process, this is a +quick guide to get you started contributing to the Hurd: + +--- + +<a id="sending-patches" name="sending-patches"></a> +# Sending Patches + +The easiest way to send patches is with `git send-email`. +[[https://git-send-email.io/]] will get you up and running with +sending patches really quickly! + +To email your most recent change, you can use `git send-email` like +so: + + $ git send-email -1 --to=bug-hurd@gnu.org + +Where `-1` means sending the current (latest) commit; you can do more +than 1 of course. You can do multiple `--to`'s, if you want to send +the patch to multiple lists (e.g. both to libc-alpha and bug-hurd, for +glibc patches), as well as `--cc` to cc specific people. It is a good +idea to cc the people who wrote or last changed the part of code +you are changing. + +If you add `--rfc`, the generated subject line will have [RFC PATCH] +instead of [PATCH], which is roughly analogous to WIP MRs on GitLab or +Draft PRs on GitHub, which means that you want to gather feedback, but +don't expect the patches to merged as-is. If you post a modified +version (aka a re-roll) of your patch (set), add -v2 (or -v3, -v4 +etc), which will result in e.g. [PATCH v2]. + +When posting a larger patch series, you might want to generate the +patches and send them in two distinct steps. For this, you can use git +format-patch (with pretty much all the same options); that will +generate a bunch of text files in your cwd that you can edit with your +favorite text editor. + + $ git format-patch -4 --to-bug-hurd@gnu.org \ + --cover-letter --cc=hurdExpert@gnu.org + $ git send-email *.patch + +It's oftentimes a good idea to give an overview of a patch series; for +this you use `--cover-letter`, which will generate a dummy patch number +0, which you can then write your description over. + +<a id="using-git" name="using-git"></a> +# Using Git + +Git can be a little tricky to use, if you are not used to it. + + $ git clone https://salsa.debian.org/hurd-team/hurd.git + $ cd hurd + $ # make a change to file + $ git add FILENAME + $ git commit -m 'trans/hello.c: Fixed a typo in a comment.' + +You should probably read some of the documentation from +[git-scm.com](https://git-scm.com/doc). `man git` is another good +resource. + +<a id="text-editors" name="text-editors"></a> +# Using Emacs' Magit + +The git command line is fine enough, but Emacs' magit mode makes using +git much easier (my opinion, obviously). With Magit, you can +trivially re-order commits, easily reword commit messages, commit a +change to an old commit (that is not HEAD), commit only portions of a +file, squash commits togethor, etc. Magit is probably one of the +easiest ways to work with git. You could code with any other editor, +but just use Emacs to handle your git workflow. + +With magit, it is easy to create patches via highlighting one or more +commits, and one can then type "W" followed by "c". I personally, +output said patches to the $hurd-src/patches directory. Then I can +send my patches to the mailing list via: + + $ cd $hurd-src/patches + $ git send-email --to=bug-hurd@gnu.org . + +# Using vim-figitive +vim users can use vim-fugitive, which is similiar to Magit. + +# Develop the Debian way + +You can develop the GNU/Hurd via Debian GNU/Hurd. This [Hurd wiki +page](https://www.debian.org/ports/hurd/hurd-devel-debian) has more +information. + +This page describes how to [[build|hurd/building]] the hurd. diff --git a/extensibility.mdwn b/extensibility.mdwn index ef89d5f2..d81acee8 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|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/2_gib_partition_limit.mdwn b/faq/2_gib_partition_limit.mdwn index fa5105bd..654379a3 100644 --- a/faq/2_gib_partition_limit.mdwn +++ b/faq/2_gib_partition_limit.mdwn @@ -15,8 +15,8 @@ License|/fdl]]."]]"""]] The 2 GiB ext2fs limit has been removed. -IDE disk drivers however currently do not support more than 2^28 sectors, i.e. 128GiB. +IDE disk drivers (`hd*`) however currently do not support more than 2^28 sectors, i.e. 128GiB. -The gnumach AHCI disk driver supports up to 2^48 sectors, i.e. 128PiB, but the device interface supports only 2^32 sectors, i.e. 2TiB. +The gnumach AHCI disk driver (`sd*`) and rumpkernel drivers (`wd*`) support up to 2^48 sectors, i.e. 128PiB, but the device interface supports only 2^32 sectors, i.e. 2TiB. You can have a bigger disk, you just should not put disk partitions beyond these limits for the drivers to be able to read from them. 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/dev-console.mdwn b/faq/dev-console.mdwn new file mode 100644 index 00000000..743c6f5a --- /dev/null +++ b/faq/dev-console.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 faq/running]] + +[[!meta title="Fails to boot with /dev/console: Read-only file system"]] + +Somehow your `/dev/console` got hurt. You can mount by hand (e.g. on `/target`) +your root filesystem from a Hurd installation CD and run + + settrans -c /target/dev/console /hurd/term /dev/console device console + +to restore it. + +You can also set it from a Linux system (mounting it as ext4) with: + + touch /target/dev/console + setfattr -n gnu.translator -v "/hurd/term\0/dev/console\0device\0console\0" /target/dev/console diff --git a/faq/dev-init.mdwn b/faq/dev-init.mdwn new file mode 100644 index 00000000..4264c39d --- /dev/null +++ b/faq/dev-init.mdwn @@ -0,0 +1,47 @@ +[[!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 faq/running]] + +[[!meta title="Fails to boot, hangs at auth."]] + +Perhaps your `/dev/` got hurt. You can mount by hand (e.g. on `/target`) +your root filesystem from a Hurd installation CD and run + + chroot /target dpkg-reconfigure hurd + +or + + chroot /target /usr/lib/hurd/setup-translators -k -p + +or even completely by hand: + + settrans -cfg /target/dev/console /hurd/term /dev/console device console + settrans -cfg /target/dev/null /hurd/null + settrans -cfg /target/servers/socket/1 /hurd/pflocal + settrans -cfg /target/dev/urandom /hurd/random --seed-file /var/lib/random-seed --fast + +to restore it or at least the basic parts. + +You can also try to fix some entries from a Linux system (mounting it as ext4) with: + + rm -f /target/dev/console + rm -f /target/dev/null + rm -f /target/servers/socket/1 + rm -f /target/dev/urandom + touch /target/dev/console + touch /target/dev/null + touch /target/servers/socket/1 + touch /target/dev/urandom + setfattr -n gnu.translator -v "/hurd/term\0/dev/console\0device\0console\0" /target/dev/console + setfattr -n gnu.translator -v "/hurd/null\0" /target/dev/null + setfattr -n gnu.translator -v "/hurd/pflocal\0" /target/servers/socket/1 + setfattr -n gnu.translator -v "/hurd/random\0--seed-file\0/var/lib/random-seed\0--fast\0" /target/dev/urandom diff --git a/faq/dev-rebuild.mdwn b/faq/dev-rebuild.mdwn index 5a4678d1..84c2ece8 100644 --- a/faq/dev-rebuild.mdwn +++ b/faq/dev-rebuild.mdwn @@ -11,7 +11,7 @@ License|/fdl]]."]]"""]] [[!tag faq/running]] -[[!meta title="Some ntries in /dev are bogus"]] +[[!meta title="Some entries in /dev are bogus"]] Possibly something broke translators there. You can run diff --git a/faq/drivers.mdwn b/faq/drivers.mdwn index 923e3b38..0d73f995 100644 --- a/faq/drivers.mdwn +++ b/faq/drivers.mdwn @@ -19,14 +19,17 @@ 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. +boot these machines, but you can install the Hurd from a linux +installation via [[crossinstall method|hurd/running/debian/CrossInstall]]. + +_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/faq/how_rpcs_work.mdwn b/faq/how_rpcs_work.mdwn new file mode 100644 index 00000000..cda7e2d9 --- /dev/null +++ b/faq/how_rpcs_work.mdwn @@ -0,0 +1,18 @@ +[[!meta copyright="Copyright © 2010, 2011, 2013, 2016 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 faq/general faq/_important]] + +[[!meta title="How do RPCs work, similarly to system calls?"]] + +There is a talk that explains the path of RPCs (i.e. system calls): + +<https://archive.fosdem.org/2015/schedule/event/hurd/> diff --git a/faq/other_repositories.mdwn b/faq/other_repositories.mdwn index a55ac1e3..ae00e276 100644 --- a/faq/other_repositories.mdwn +++ b/faq/other_repositories.mdwn @@ -14,6 +14,4 @@ License|/fdl]]."]]"""]] If you want to use the `apt source` facility, make sure that `/etc/apt/sources.list` contains a line like - deb-src http://ftp.de.debian.org/debian unstable main - -... replacing _de_ with your homeland's code. + deb-src http://deb.debian.org/debian unstable main diff --git a/faq/ram_limit.mdwn b/faq/ram_limit.mdwn index 8e13f321..4e7e47b0 100644 --- a/faq/ram_limit.mdwn +++ b/faq/ram_limit.mdwn @@ -13,16 +13,12 @@ License|/fdl]]."]]"""]] [[!meta title="830 MiB RAM Limit"]] -The 830MB RAM limit has been removed, but just like any 32-bit OS without bad tricks, -GNU Mach can not cope well with lots of memory. Latest versions of the Debian `gnumach` -package will limit themselves to 3 GiB of memory. If you want more, you can twiddle -the `VM_MAX_ADDRESS` limit between kernelland and userland in -`i386/include/mach/i386/vm_param.h`, but glibc and the hurd servers will not cope -well with less than 1 GB. +The 830MB RAM limit has been removed since long. The default version of the +Debian `gnumach` package will limit themselves to 3 GiB of memory. If you +want more, you can try the PAE version, but this requires using rumpdisk for +accessing disks. -There is a [[64-bit port|open_issues/64-bit_port]] in progress. - -If you have an older version, or still experience problems with `vmstat` (see -above) reported much less memory than you have, the best is to limit the memory -it can see via GRUB's `upppermem` feature. Add `uppermem 786432` to GRUB's Hurd -entry in `menu.lst`. +Note that by architecture design, 32bit systems can only provide at most 4GiB +addressing space for processes. With a 32bit kernel, part of is is used by the +kernel. It is also possible you use a 32-on-64 kernel, to provide the full 4GB +adress space to userland. To give more to userland, use a fully-64b Hurd. diff --git a/faq/slow.mdwn b/faq/slow.mdwn index ffa20fe3..02173952 100644 --- a/faq/slow.mdwn +++ b/faq/slow.mdwn @@ -18,12 +18,13 @@ completely usable. Take care when running the Hurd in fully-virtualized machines: virtualization software use ugly heuristics to make Linux run faster, which will not work on the Hurd (or BSD, etc.) so comparisons in virtualized environments do not really -hold. Also take care of not comparing Hurd (which is currently 32bit) with a +hold. Also take care of not comparing a 32bit Hurd with a 64bit Linux execution: 64bit has *much* more computational and optimization possibilities than 32bit. At least, use -m32 to build a 32bit Linux version of a -test for comparison. +test for comparison, or use a 64b Hurd. -The main reason for slowness is *not* because of the overhead of RPCs. It's +Contrary to common belief that is terribly widespread in webnews comments, the +main reason for slowness is *not* because of the overhead of RPCs. It's mostly simply because less care has been done on implementing what makes Linux fast: intelligent read-ahead, carefully-tuned page cache, etc. or even just missing DMA support for your disk controller. diff --git a/faq/smp.mdwn b/faq/smp.mdwn index ee0bf53f..d6001b3a 100644 --- a/faq/smp.mdwn +++ b/faq/smp.mdwn @@ -21,18 +21,18 @@ This needs testing as SMP support has recently been added to Mach. Intel_iPSC/860]], so principally has the required infrastructure. It has recently been enhanced to support nowadays' SMP standards like ACPI. -However, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue -code isn't SMP-safe so build with --disable-linux-groups to test SMP and use +However, [[GNU Mach|microkernel/mach/gnumach]]'s Linux device driver glue code +isn't SMP-safe so the in-kernel drivers will be disabled, and one has to use rumpdisk to provide disk access. To build an SMP supported gnumach with kdb: -../configure --enable-ncpus=8 --enable-kdb --enable-apic --disable-linux-groups +../configure --enable-ncpus=8 --enable-kdb This will by default allow you to boot with one core isolated to the default processor set, and all the other detected cpus will be in the slave processor set. The slave processors need to be enabled per-task using RPCs to manipulate processor sets. -See https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html for a test program +See [Damien's post](https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html) for a test program that can enable a task to use the slave processors by calling ./smp /bin/bash for example. Unfortunately, there are race conditions causing hangs or crashes in Mach when attempting diff --git a/faq/software.mdwn b/faq/software.mdwn index 719e123c..90e7a524 100644 --- a/faq/software.mdwn +++ b/faq/software.mdwn @@ -13,7 +13,7 @@ License|/fdl]]."]]"""]] [[!meta title="What software is available for GNU?"]] -As of March 2014, 79% of all [Debian](http://www.debian.org/) +As of August 2025, 72% of all [Debian](http://www.debian.org/) [packages](http://packages.debian.org/) are available for [[Debian GNU/Hurd|hurd/running/debian]]. Of course, testing and bug fixing is welcome, as we have obviously not tested all of them. diff --git a/faq/still_useful.mdwn b/faq/still_useful.mdwn index 575781a1..b2b1b272 100644 --- a/faq/still_useful.mdwn +++ b/faq/still_useful.mdwn @@ -13,10 +13,10 @@ License|/fdl]]."]]"""]] [[!meta title="What are the advantages with the Hurd over Linux/BSD?"]] -The Hurd will be considerably more flexible and robust +The Hurd is already considerably more flexible and robust than generic Unix. Wherever possible, Unix kernel features have been moved into unprivileged space. Once there, anyone who desires can -develop custom replacements for them. Users will be able to write and +develop custom replacements for them. Users are able to write and use their own file systems, their own `exec' servers, or their own network protocols if they like, all without disturbing other users. @@ -24,8 +24,8 @@ A [[series of interesting examples|hurd/documentation/translator_primer]] is available. The Linux kernel has now been modified to allow user-level file -systems, so there is proof that people will actually use features such -as these. It will be much easier to do under the Hurd, however, +systems, so there is proof that people actually use features such +as these. It is much easier to do under the Hurd, however, because the Hurd is almost entirely run in user space and because the various servers are designed for this sort of modification. @@ -43,31 +43,33 @@ various servers are designed for this sort of modification. > $ settrans myspace /hurd/ext2fs myspace.img > $ cd myspace ->> Just curious, but I keep seeing these (and other similar) concepts being ->> brought up as the amazing selling points of the Hurd, but all of this is ->> entirely doable now in Linux with FUSE or things like it. +Other variants of the question include: ->>> Nowadays, at LAST, yes, partly. ->>> And only on machines where fuse is enabled. Is it enabled on the servers you have an account on? +> Just curious, but I keep seeing these (and other similar) concepts being +> brought up as the amazing selling points of the Hurd, but all of this is +> entirely doable now in Linux with FUSE or things like it. ->> I'm not sure if an ftp filesystem has been implemented for FUSE yet, but its ->> definately doable; and loopback filesystems like in your second example have ->> been supported for years. +>> Nowadays, at LAST, yes, partly. +>> And only on machines where fuse is enabled. Is it enabled on the servers you have an account on? ->>> As a normal user? And establish a tap interface connected through ppp over ->>> ssh or whatever you could want to imagine? +> I'm not sure if an ftp filesystem has been implemented for FUSE yet, but its +> definately doable; and loopback filesystems like in your second example have +> been supported for years. ->> What, then, are the major selling points or benefits? +>> As a normal user? And establish a tap interface connected through ppp over +>> ssh or whatever you could want to imagine? ->>> These were just examples, Linux is trying to catch up in ugly ways indeed ->>> (yes, have a look at the details of fuse, it's deemed to be inefficient). ->>> In the Hurd, it's that way from the _ground_ and there is no limitation ->>> like having to be root or ask for root to add magic lines, etc. +> What, then, are the major selling points or benefits? -> It also for instance provides userland drivers, for instance the network -> drivers are actually Linux drivers running in a separate userland process. +>> These were just examples, Linux is trying to catch up in ugly ways indeed +>> (yes, have a look at the details of fuse, it's deemed to be inefficient). +>> In the Hurd, it's that way from the _ground_ and there is no limitation +>> like having to be root or ask for root to add magic lines, etc. -> It also for instance provides very fine-grain virtualization support, such as -> [[VPN for only one process|open_issues/virtualization/networking]], etc. +The Hurd also for instance provides userland drivers, for instance the network +drivers are actually Linux drivers running in a separate userland process. -> etc. etc. The implications are really very diverse... +It also for instance provides very fine-grain virtualization support, such as +[[VPN for only one process|open_issues/virtualization/networking]], etc. + +etc. etc. The implications are really very diverse... @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013, 2015 Free -Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2012, 2013, +2015, 2024 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 @@ -28,9 +28,11 @@ repository|source_repositories/glibc]]. Porting glibc to a specific architecture is non-trivial. -The main port is x86, which is somewhat complete and is maintained. There were -incomplete ports for Alpha, MIPS, and PowerPC, but they were unmaintained and -have been removed. +The main port is x86, which is somewhat complete and is maintained. +We are actively stabilizing the [[X86_64 +port|open_issues/64-bit_port]]. There were incomplete ports for +Alpha, MIPS, and PowerPC, but they were unmaintained and have been +removed. ## [[Hurd-specific Port|hurd/glibc]] @@ -54,6 +56,8 @@ fact simply forwarded to/implemented as [[system_call]]s. * [[startup]] + * [[glibc/error-reporting]] + ## Concepts @@ -80,7 +84,6 @@ Some of these are well-known as [[UNIX]] [[system call]]s. * [[poll]] - # Debugging Some hints for [[debugging]]. diff --git a/glibc/error-reporting.mdwn b/glibc/error-reporting.mdwn new file mode 100644 index 00000000..78482558 --- /dev/null +++ b/glibc/error-reporting.mdwn @@ -0,0 +1,57 @@ +[[!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]]."]]"""]] + +[[!meta title="glibc error reporting"]] + +When reporting errors in the Hurd part of glibc, please use these +functions. They can be found in `$glibc-SRC/hurd/hurd/fd.h`. + + `__hurd_fail (error_t err)` + +The `__hurd_fail ()` inline function is the recommended way of +reporting errors in the Hurd part of glibc. It is more concise than `{ +errno = err; return -1; }`, and it translates some MIG and Mach errors +into POSIX errors. + +You can see some example uses of it from this +[[email|https://lists.gnu.org/archive/html/bug-hurd/2023-05/msg00369.html]] +to bug-hurd. + + extern int __hurd_dfail (int fd, error_t err); + +Handle error code `ERR` from an RPC on file descriptor FD's port. +This function converts some errors into signals as expressed by +POSIX. It sets `errno` to the appropriate error code and always return +-1. Most developers will rarely use this function, since `__hurd_fail +()` handles most usecases. + + + `_hurd_fd_error (error_t err)` + +Handle an error from an RPC on a file descriptor's port. This +function is almost the same as `__hurd_dfail ()`. `_hurd_fd_error ()` +returns the error, while `__hurd_dfail ()` sets errno and returns +`-1`. You should always use this function to handle errors from RPCs +made on file descriptor ports. Some errors are translated into +signals. + + + `__hurd_sockfail (int fd, int flags, error_t err)` + +Handle error code ERR from an RPC on file descriptor FD's port. Set +`errno` to the appropriate error code, and always return -1. It +differs from `__hurd_dfail ()` in that it does not raise `SIGPIPE` on +`EPIPE` if flags contain `MSG_NOSIGNAL`. + + + extern int _hurd_fd_error_signal (error_t err); + +Check if ERR should generate a signal. Returns the signal to take, or +zero if none. @@ -29,9 +29,11 @@ supports the multiboot standard, necessary to boot the Hurd. --device-master-port='${device-port}' \ --exec-server-task='${exec-task}' -T typed '${root}' \ '$(task-create)' '$(task-resume)' - module /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)' + module /lib/ld-x86-64.so.1 exec /hurd/exec '$(exec-task=task-create)' } + * Use `ld.so.1` instead of `ld-x86-64.so.1` on 32b systems. + # syslinux' `mboot.c32` diff --git a/grub/tftp_boot.mdwn b/grub/tftp_boot.mdwn index a094f248..1a2f5848 100644 --- a/grub/tftp_boot.mdwn +++ b/grub/tftp_boot.mdwn @@ -33,4 +33,6 @@ The `menu.lst` can look something like this: --device-master-port=${device-port} \ --exec-server-task=${exec-task} \ -T typed ${root} $(task-create) $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) + module /lib/ld-x86-64.so.1 /hurd/exec $(exec-task=task-create) + +Note: use `ld.so.1` instead of `ld-x86-64.so.1` on 32b systems. diff --git a/hurd/bootstrap.mdwn b/hurd/bootstrap.mdwn index 76ad0dc5..875541cf 100644 --- a/hurd/bootstrap.mdwn +++ b/hurd/bootstrap.mdwn @@ -44,8 +44,9 @@ bootloader can have the following typical configuration: --multiboot-command-line='${kernel-command-line}' \ --exec-server-task='${exec-task}' -T typed '${root}' \ '$(fs-task=task-create)' - module /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)' + module /lib/ld-x86-64.so.1 exec /hurd/exec '$(exec-task=task-create)' +Note: use `ld.so.1` instead of `ld-x86-64.so.1` on 32b systems. GNU Mach will first make the `$(task-create)` function calls, and thus create a series of tasks for the various modules, and assign to the `pci-task`, diff --git a/hurd/building.mdwn b/hurd/building.mdwn index ea3213e5..ef8c94d1 100644 --- a/hurd/building.mdwn +++ b/hurd/building.mdwn @@ -24,8 +24,8 @@ Building the Hurd requires the *build-essential* and *fakeroot* packages, their dependencies and additional packages that are specified by the source hurd package: - # apt install build-essential fakeroot - # apt build-dep hurd + # apt install build-essential fakeroot quilt + # apt build-dep -y hurd gnumach ## ... on non-Debian systems @@ -41,6 +41,10 @@ git](http://savannah.gnu.org/git/?group=hurd): ... or (if you are working on a Debian system) the ones that are used for the [current Debian hurd package](http://packages.debian.net/source/unstable/hurd): + $ git clone https://salsa.debian.org/hurd-team/hurd.git + +Or you could use apt source + $ apt source hurd Please see the Debian [[FAQ]] before using `apt source`. diff --git a/hurd/debugging/glibc.mdwn b/hurd/debugging/glibc.mdwn index 1b7e6ab1..a5515e29 100644 --- a/hurd/debugging/glibc.mdwn +++ b/hurd/debugging/glibc.mdwn @@ -23,9 +23,11 @@ newly created libraries and loader actually work: they'll be used to run the `rpcgen` program. If that step doesn't succeed, it'll look similar to this: [...] - CPP='gcc -E -x c-header' [...]/build/elf/ld.so.1 --library-path [...] [...]/build/sunrpc/rpcgen [...] + CPP='gcc -E -x c-header' [...]/build/elf/ld-x86-64.so.1 --library-path [...] [...]/build/sunrpc/rpcgen [...] Segmentation fault +Note: use `ld.so.1` instead of `ld-x86-64.so.1` on 32b systems. + --- Unless cross-compiling, the next thing you'll probably want to do diff --git a/hurd/debugging/subhurd.mdwn b/hurd/debugging/subhurd.mdwn index 7b5b07b1..34b3e097 100644 --- a/hurd/debugging/subhurd.mdwn +++ b/hurd/debugging/subhurd.mdwn @@ -42,11 +42,11 @@ with _ps_.) W3 - $ sudo gdb /var/tmp/one.full/lib/ld.so.1 + $ sudo gdb /var/tmp/one.full/lib/ld-x86-64.so.1 [...] (gdb) set solib-absolute-prefix /var/tmp/one.full (gdb) attach 854 - Attaching to program `/var/tmp/one.full/lib/ld.so.1', pid 854 + Attaching to program `/var/tmp/one.full/lib/ld-x86-64.so.1', pid 854 warning: Can't modify tracing state for pid 854: No signal thread Can't fetch registers from thread 1: No such thread @@ -54,7 +54,7 @@ W1 [<Enter>.] /hurd/ext2fs.static --bootflags=-dsf --host-priv-port=38 --device-master-port=43 --exec-server-task=47 -Tdevice pseudo-root - /lib/ld.so.1 /hurd/exec + /hurd/exec.static Now that this step has been accomplished, you can set break points in GDB, etc. 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/documentation.mdwn b/hurd/documentation.mdwn index f9a2428f..1a9ff3b3 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -69,6 +69,9 @@ is included in the section entitled * [[glibc]] * Device Drivers * [[rump|hurd/rump]] NetBSD drivers + * [[hurd/rump/rumpdisk]] + * [[hurd/rump/rumpnet]] + * [[hurd/rump/rumpusbdisk]] * [[DDE|hurd/dde]] Outdated Linux Drivers (unmaintained) * RPC [[Interface]]s * Libraries 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/rumpfs.mdwn b/hurd/rump/rumpfs.mdwn index 8236defa..b98ceae5 100644 --- a/hurd/rump/rumpfs.mdwn +++ b/hurd/rump/rumpfs.mdwn @@ -29,3 +29,7 @@ some existing experimental code. Another option is to create translators out of [[libguestfs|hurd/translator/libguestfs]]. + +Another option is the newly created +[[experimental journal for ext2fs|https://lists.gnu.org/archive/html/bug-hurd/2025-08/msg00040.html]]. +As of November 9, 2025, this has not yet been merged upstream. diff --git a/hurd/rump/rumpnet.mdwn b/hurd/rump/rumpnet.mdwn index 5ea3ba61..ec67d6b5 100644 --- a/hurd/rump/rumpnet.mdwn +++ b/hurd/rump/rumpnet.mdwn @@ -13,10 +13,29 @@ License|/fdl]]."]]"""]] # RumpNet -Hurd developers want to use rumpnet, so that we can use modern -ethernet and wifi device drivers. The Hurd is currently using Linux's -old TCP/IP stack (`pfinet`) and device drivers. We plan to replace -`pfinet` with [[lwip|hurd/translator/lwip]] and use rumpnet's modern -device drivers for ethernet and wifi hardware. Alternatively, we -could use rump's TCP/IP stack. +The Hurd is currently using an old Linux's TCP/IP stack (`pfinet`) and +device drivers. Hurd developers are replacing Linux's old ethernet +drivers with rumpnet's modern ethernet and wifi device drivers. While +porting Linux's device drivers would provide better hardware support, +we do not have the developer man-power to maintain it. Hurd +Developers prefer rumpnet's stable API over Linux's code churn. We +plan to replace `pfinet` with [[lwip|hurd/translator/lwip]] (or use +rump's TCP/IP stack). + +In 2025, Damien Zammit make significant progress with rumpnet. He +coded rumpnet to work with `/dev/wmX` cards, which are Intel i8254x +Gigabit Ethernet devices. (Documentation is available at +man.netbsd.org's [wm(4)](https://man.netbsd.org/wm.4) web +page). Please note that these are ethernet cards not wifi cards. This +should be easily extended to support other NICs by contributing to +netbsd/rump's makefiles. + +Example usage: + + $ settrans -fgap /dev/rumpnet /hurd/rumpnet + $ settrans -fgap /dev/wm0 /hurd/devnode -M /dev/rumpnet wm0 + $ settrans -fgap /servers/socket/2 /hurd/pfinet -i /dev/wm0 + $ ifup /dev/wm0 + + diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn index 0772c48e..e28d7ed4 100644 --- a/hurd/running/debian.mdwn +++ b/hurd/running/debian.mdwn @@ -5,7 +5,7 @@ Debian GNU/Hurd is an effort to port the Debian distribution to the Hurd. Around <!-- I don't know what it means that /etc/mtab -> /proc/mounts, but this is what I could interpret. It was simply a line (h1, for some reason, on this page and it looked out of place. Correct or even delete this if it makes no sense --> -One noteable difference in this port, is that `/etc/mtab` -> `/proc/mounts` +One notable difference in this port, is that `/etc/mtab` -> `/proc/mounts` --- # QEMU Image @@ -13,9 +13,14 @@ One noteable difference in this port, is that `/etc/mtab` -> `/proc/mounts` --- # Installing -- [Installation Instructions](http://www.debian.org/ports/hurd/hurd-install) - - [Upgrading K11 or K14 based systems to unstable](http://lists.debian.org/debian-hurd/2007/09/msg00007.html) -- [[After_install]] — Do this to get networking, new console and X +The Debian installer runs natively on the Hurd and it is possible to install a Debian GNU/Hurd system booting it from an IDE or SATA CD-ROM drive or from a USB stick. See +[installation instructions](http://www.debian.org/ports/hurd/hurd-install) for details and post-installation configuration. + +As of late 2025 installation may require larger amount of RAM (≥ 2 GB) due to [[hurd/rump/rumpdisk]] memory requirements. It is possible to install 32 bit Hurd (`hurd-i386`) on lower RAM conditions (~ 500 MB) using the [CrossInstall](#crossinstall) method. + +--- +# <a id="crossinstall">CrossInstall</a> +It is possible to install a Debian GNU/Hurd system on a spare partition from an existing Debian GNU/Linux installation. We call this [[CrossInstall]]. --- # Contributing @@ -23,68 +28,9 @@ One noteable difference in this port, is that `/etc/mtab` -> `/proc/mounts` * [[Patch_submission]] — How to submit patches for build failures - [[Creating_image_tarball]] -### IRC, freenode, #hurd, 2014-02-12 - - <braunr> hm, there is something weird - <braunr> after successfully installing (with the new installer cd), and rebooting, system init fails because fsck can't be run on /home (a separate partition) - <braunr> it can't fsck because at that point, /home is already mounted, and indeed the translator is running - <braunr> teythoon: any idea what might cause that ? - <teythoon> me ? - <teythoon> no - <braunr> ok - <braunr> ah no, actually /home isn't mounted oO - <braunr> but fsck still refuses to check it, stating that reason - <braunr> hm, /etc/mtab isn't a link to /proc/mounts here, might explain - - -### IRC, freenode, #hurd, 2014-02-12 - - <braunr> yes, better with a proper symlink :) - <teythoon> good - <youpi> Mmm, what is supposed to create that symlink? - <teythoon> one debian init script did that at one time - <teythoon> i believe they dropped that - <youpi> err, but something must be creating it for newer systems - <teythoon> good point - <braunr> well, except for these small details, everything went pretty smooth - <braunr> both on ide and ahci - <youpi> it seems /etc/mtab gets created at boot - <youpi> (on Linux I mean) - <teythoon> youpi: i cannot find the init script, but i'm sure that it was there - <youpi> I can't find it either on the installed system... - <azeem> maybe pere or rleigh in #debian-hurd can help - - -### IRC, freenode, #hurd, 2014-02-13 - - <braunr> 6<--60(pid1698)->dir_lookup ("var/run/mtab" 4194305 0) = 0 3 "/run/mtab" (null) - <braunr> looks like /etc/mtab isn't actually used anymore - <teythoon> it never was on hurd - <tomodach1> braunr: well it is generated i believe from mounted filesystems - <tomodach1> if its still around there is a reason for it, like posix compatiblity perhaps? - <braunr> well the problem is that, as mentioned in pere's thread on bug-hurd, some tools now expect /var/run/mtab instead of /etc/mtab - <braunr> and since nothing currently creates this file, these tools, such as df, are lost - <braunr> they can't find the info they're looking for - - -### IRC, freenode, #hurd, 2014-02-17 - - <braunr> i still don't have mtab at the proper location on darnassus - <pere> is there something missing with sysvinit on hurd? - <braunr> is that normal ? - <pere> yes. I recommended fixing it in the hurd package. (BTS #737759) - <braunr> yes i saw but was there any action taken ? - <pere> did not check - <teythoon> i thought youpi mentioned that it is fixed in the libc and we just need to rebuild coreutils or something - <pere> yes - <braunr> oh ok - <braunr> but doesn't that mean it will use /etc/mtab ? - <pere> if I was a hurd porter, I would fix it in hurd while waiting for a fix in coreutils, just to save people for wondering about the breakage, but I am not the most patient of developers. :) - --- -# Externel +# Other links * Official page about the Debian GNU/Hurd port: [Debian GNU/Hurd](http://www.debian.org/ports/hurd/) * Debian [[FAQ]] — Frequently Asked Questions -* [Presentation](http://people.debian.org/~mbanck/talks/hurd_lt2004/html/) -Debian GNU/Hurd*, [[MichaelBanck]], LinuxTag 2004 Karlsruhe * [Archive Qualification](http://wiki.debian.org/ArchiveQualification/hurd-i386) * [[!wikipedia Debian_GNU/Hurd]] on Wikipedia diff --git a/hurd/running/debian/CrossInstall.mdwn b/hurd/running/debian/CrossInstall.mdwn index 26cd77af..675d9992 100644 --- a/hurd/running/debian/CrossInstall.mdwn +++ b/hurd/running/debian/CrossInstall.mdwn @@ -1,31 +1,41 @@ -## <a name="Easy_install_with_CrossHurd"> Easy install with CrossHurd </a> +Curious about the Hurd? Have a 1-5 GiB partition free? Let's install GNU/Hurd on it! -Qurious about the Hurd? Have a 1-5 GiB partition free? Let's install GNU/Hurd on it! +This page covers two ways to install a Debian GNU/Hurd system from a running +Debian GNU/Linux in a dual boot type of setup, using either +[crosshurd](#CrossHurd) or [mmdebstrap](#mmdebstrap). -### <a name="Preparing_the_partition"> Preparing the partition </a> +For the sake of the examples in this page we will consider `/dev/hda3` as +the partition where you want to install your Hurd system as displayed from linux. -We'll assume you have a partition ready, for the sake of argument we use an example here: /dev/hda3 is the Hurd partition (type: Linux) and /dev/hda4 is the Linux swap that we'll reuse. +The examples here assume the installation of a `hurd-i386` system, but it is +simple to modify for a `hurd-amd64` installation. -First we create the Ext2 filesystem, notice the `hurd` option. - # mke2fs -o hurd /dev/DEVICE +## <a name="CrossHurd"> CrossHurd method </a> -Next we create a useful mountpoint and mount the partition. +First install the [crosshurd package](http://packages.debian.org/crosshurd). - # mkdir /gnu - # mount /dev/hda3 /gnu + # apt install crosshurd -### <a name="Retrieving_CrossHurd"> Retrieving CrossHurd </a> +If you have problems it might be because the crosshurd version in the Stable +distribution is out of date, try the version in Unstable before reporting the issue. -Unless you don't run Debian GNU/Linux download it from <http://packages.debian.org/crosshurd>, or simply apt the package from Testing or Unstable. Avoid using the version from Stable since it probably is outdated. In case of problems, make sure to try the Unstable version before reporting the issue. +### <a name="Preparing_the_partition"> Preparing the partition </a> + +Create the Ext2 filesystem for the Hurd system, notice the `hurd` option. + + # mke2fs -o hurd /dev/hda3 + +Next create a useful mountpoint and mount the partition. + + # mkdir /gnu + # mount /dev/hda3 /gnu - # apt install crosshurd ### <a name="Cross_installing"> Cross installing </a> The crosshurd package only operates in the given target directory, which is the first question asked when running the program. - # cd /gnu # crosshurd Answer the questions you get: $ What is the target directory?: `/gnu` $ Target Debian system?: gnu $ Target CPU?: i386 @@ -34,41 +44,96 @@ Now the program starts retrieving all the necessary base packages. ### <a name="Preparing_to_reboot"> Preparing to reboot </a> -When all packages have been extracted we must prepare [[GRUB]] for the Hurd when we reboot. Add the below entry to your `/boot/grub/menu.lst` file to boot the Hurd in single user mode (-s). Single user mode is needed only for the two reboots when running the Native Install. +When all packages have been extracted we must prepare [[GRUB]] for the Hurd when we reboot. +Add the below entry to `/etc/grub.d/40_custom` file in your linux installation. + + menuentry "Debian GNU/Hurd" { + set root='hd0,msdos3' + echo 'Loading GNU Mach ...' + multiboot /boot/gnumach-1.8-486-up.gz root=part:3:device:wd0 noide + echo 'Loading the Hurd ...' + module /hurd/pci-arbiter.static pci-arbiter \ + --host-priv-port='${host-port}' --device-master-port='${device-port}' \ + --next-task='${acpi-task}' \ + '$(pci-task=task-create)' '$(task-resume)' + module /hurd/acpi.static acpi \ + --next-task='${disk-task}' \ + '$(acpi-task=task-create)' + module /hurd/rumpdisk.static rumpdisk \ + --next-task='${fs-task}' \ + '$(disk-task=task-create)' + module /hurd/ext2fs.static ext2fs \ + --multiboot-command-line='${kernel-command-line}' \ + --exec-server-task='${exec-task}' -T typed '${root}' \ + '$(fs-task=task-create)' + module /hurd/exec.static exec '$(exec-task=task-create)' + } - title GNU (kernel GNUmach 1.5) - root (hd0,2) - kernel /boot/gnumach-1.5-486.gz root=device:hd0s3 -s - module /hurd/ext2fs.static \ - --multiboot-command-line=${kernel-command-line} \ - --host-priv-port=${host-port} \ - --device-master-port=${device-port} \ - --exec-server-task=${exec-task} \ - -T typed ${root} $(task-create) $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) +*Nota Bene:* In your menu file there should be no extra white space after the back slashes. -**_Nota Bene:_** In your menu file there should be no extra white space after the back slashes. +Following this, re-create the grub configuration file: + + # update-grub ### <a name="Native_install"> Native install </a> -Ah, reboot and select "GNU (kernel GNUmach 1.3)" from the Grub menu. At the prompt, setup TERM and run the native-install script. +Then, reboot and select "Debian GNU/Hurd" from the Grub menu. At the prompt, setup TERM and run the native-install script. # export TERM=mach # ./native-install -When done the native install requests that you reboot once again and rerun native-install. +You should add a swap partition to `/etc/fstab`. You can share the swap +partition between your Hurd and linux installations. If the swap partition +was `/dev/hda4` on linux, it will be `/dev/wd0s4` on the Hurd. - # reboot - ... - # export TERM=mach - # ./native-install +Before you reboot the system be sure to set a root password. + + # passwd + +We can now reboot into the newly configured system. + + # reboot-hurd + +## <a name="mmdebstrap"> mmdebstrap method </a> + +First we need to install the [mmdebstrap](http://packages.debian.org/mmdebstrap) and libarchive13t64 packages. + + # apt install mmdebstrap libarchive13t64 + +The way this installation method works is to run mmdebstrap in the +[chrootless mode](https://gitlab.mister-muffin.de/josch/mmdebstrap/wiki#modes) +from a linux host. But because misconfigured package Maintainer scripts may +damage the host installation while running in chrootless mode, we wrap two +mmdebstrap calls: the first creates a throw-away linux chainroot from within +which we call mmdebstrap in chrootless mode to install our GNU/Hurd image. + +We run the following command (we use line breaks for readability, but it is a +single command): + + # mmdebstrap --variant=apt + --include=passwd,debian-ports-archive-keyring,mmdebstrap,sysvinit-core,sysv-rc,e2fsprogs,libarchive13t64 + --customize-hook='chroot "$1" + mmdebstrap --mode=chrootless --arch=hurd-i386 + --include=sysvinit-core,sysv-rc,debian-ports-archive-keyring,netdde,gnumach-image-1-486 + --customize-hook="passwd --root=\"\$1\" --delete root" + --variant=apt unstable - + "deb http://ftp.ports.debian.org/debian-ports/ unstable main" + "deb http://ftp.ports.debian.org/debian-ports/ unreleased main" + | mkfs.ext2 -o hurd -d - /dev/hda3' + stable /dev/null -Done, continue setting up your system. +We then need to [configure the bootloader grub](#Preparing_to_reboot) in the +same way as described in the crosshurd method above. ----- +We can then reboot into the Debian GNU/Hurd system. If we check the `/etc/fstab` +file we will note that the system boots even without specifying a root mountpoint. +At the moment there is no swap partition defined either, and it is a good idea to +edit `/etc/fstab` to add both root and swap partitions. We can share the swap +partition between Hurd and linux installations. If the swap partition +was `/dev/hda4` on linux, it will be `/dev/wd0s4` on the Hurd. To activate swap +without rebooting we use the command -Jeff Bailey has set up a system where you can install a Hurd system without having to use CDs. It's another type of cross-installation method which uses Debian package management tools to get the packages required as opposed to the one single big tarball. + # swapon /dev/wd0s4 -As of 2005-03-22, the latest version of crosshurd is 1.7.11. It can be found at <http://packages.debian.org/crosshurd>. +Any other packages can now be installed using `apt`. --- [[Main/PeterMelville]] - 12 Jun 2004 diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index 8409bc8c..c6da1555 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 cache=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 -m 2G -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..16e2140c 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|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/subhurd.mdwn b/hurd/subhurd.mdwn index d24369bc..5bd81425 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -46,7 +46,6 @@ The 'fastboot' is necessary to skip the filesystem check which fails because the image assumes the root filesystem to be /etc/hd0s1. Once booted, you can correct this: - root@debian:~# settrans -c /dev/pseudo-root /hurd/storeio pseudo-root root@debian:~# echo /dev/pseudo-root / ext2 defaults 0 1 >/etc/fstab root@debian:~# halt @@ -83,8 +82,16 @@ debootstrap as root: mke2fs /dev/hd0s6 settrans -ca mnt /hurd/ext2fs /dev/hd0s6 debootstrap --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg --extra-suites=unreleased sid chroot http://deb.debian.org/debian-ports/ + chroot mnt passwd settrans -fga mnt +## Using mmdebstrap + +One can also use mmdebstrap: + + mmdebstrap --mode=chrootless --variant=required --keyring=/usr/share/keyrings/debian-ports-archive-keyring.gpg '' rootfs.tar.gz 'deb http://deb.debian.org/debian-ports unreleased main' 'deb http://deb.debian.org/debian-ports/ unstable main' + mke2fs /dev/hd0s6 -d rootfs.tar.gz + ## Booting If you are using a recent version of the Hurd (>= 0.9), then you can @@ -152,6 +159,17 @@ numbers are different, the order should usually match. Often it also helps to look at the number of threads (e.g. using `ps -l`), as many servers have very characteristic thread counts. +## Faster boot + +If you do not need daemons etc. you can just run a shell, similary to a chroot: + + boot /dev/hd0s6 -c init=/bin/bash + +Unless you change the boot script to pass `--writable` to ext2fs, you will want to remount / read-write: + + fsysopts / --writable + +And `poweroff-hurd` should be used to stop the subhurd. ### IRC, freenode, #hurd, 2013-08-09 diff --git a/hurd/translator/nfs.mdwn b/hurd/translator/nfs.mdwn index ee960c04..ff157f8e 100644 --- a/hurd/translator/nfs.mdwn +++ b/hurd/translator/nfs.mdwn @@ -15,6 +15,31 @@ Only NFSv2/v3 is currently supported. [[!tag open_issue_hurd]]There are a few unmerged changes on a former GSoC project's topic-branch. +#### A setup example (2025-12-21), Linux server + +This example has the **NFS server on a Linux system** +and the **NFS client on a GNU hurd-amd64 system**. +Specifically, the Linux system is a *Devuan 5 (daedalus)*, which thus corresponds to *Debian 12 (bookworm)* with the *nfs-kernel-server* package version *1:2.6.2-4+deb12u1*; +the hurd-amd64 is from the *debian port snapshot dated 2025-08-07*, +and running in a QEMU VM on the server host. + +It all ran OOTB with only two specific configuration changes: + +1. The configuration file **/etc/default/nfs-kernel-server** is changed by adding **"-u"** for the NFSD startup variable RPCNFSDCOUNT, so as to enable UDP for the NFS server (it is disabled by default). The configuration line will thus read: + + **RPCNFSDCOUNT="-u 8"** + + The nfs-kernel-server needs to be restarted following the configuration change. + + Also, the export configuration file, **/etc/exports**, needs to be set up to nominate path(s) to export and which clients are allowed to use them. (See "man exports" on the Linux system for its details) + +2. The **/hurd/nfs translator** is started with argument **"--nfs-program=3"** so as to make it use NFSv3 (the default is NFSv2). The startup command used thus has the following form: + + **settrans $LOCAL /hurd/nfs -s --nfs-program=3 $REMOTE $SERVER** + + where $LOCAL is a local existing pathname, e.g. */nfs*, $REMOTE is the exported path on the server, e.g. */home/rrq/shared*, and $SERVER is the server hostname or IP address, e.g. *172.18.46.1*. + + Note that the *"-s"* argument is an optional author's choice, to let the **nfs** translator exit if it fails to connect on the first 3 attempts. Its default, without "-s", is to keep trying. # See Also 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/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn index bcff970e..2aeae7f4 100644 --- a/microkernel/mach/gnumach/debugging.mdwn +++ b/microkernel/mach/gnumach/debugging.mdwn @@ -165,9 +165,10 @@ example `/boot/grub/grub.cfg`: --host-priv-port='${host-port}' --device-master-port='${device-port}' \ --exec-server-task='${exec-task}' -T typed '${root}' \ '$(fs-task=task-create)' '$(task-resume)' - module /lib/ld.so.1 exec /hurd/exec '$(exec-task=task-create)' + module /lib/ld-x86-64.so.1 exec /hurd/exec '$(exec-task=task-create)' +Note: use `ld.so.1` instead of `ld-x86-64.so.1` on 32b systems. # Code Inside the Kernel 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/news/2023-q4.mdwn b/news/2023-q4.mdwn index ae36dea8..5158111c 100644 --- a/news/2023-q4.mdwn +++ b/news/2023-q4.mdwn @@ -67,7 +67,7 @@ untyped, but it appears that the Hurd only uses typed RPC. So it seems best to remove any untyped RPC code. Sergey Bugaev added [[GNU Mach entry re-coalescing -support|https://darnassus.sceen.net/~hurd-web/open_issues/gnumach_vm_map_entry_forward_merging/]]. +support|open_issues/gnumach_vm_map_entry_forward_merging]]. Essentially, Mach was not always able to merge two vm entries that are made next to each other, which was slowing down ext2, bash, etc. Sergey allowed GNU Mach to merge entries in the common cases, which greatly diff --git a/news/2024-q2.mdwn b/news/2024-q2.mdwn index bcbcb470..04799e7d 100644 --- a/news/2024-q2.mdwn +++ b/news/2024-q2.mdwn @@ -48,7 +48,7 @@ right](https://lists.gnu.org/archive/html/bug-hurd/2024-04/msg00001.html) to Mach and MIG. Some time ago, Sergey also wrote the -[terrible-mdns-responder](https://darnassus.sceen.net/~hurd-web/hurd/terrible-mdns-responder/), +[terrible-mdns-responder][hurd/terrible-mdns-responder], and if you would like to be able to type in `ssh HOSTNAME.local` and connect to a locally running Hurd, then you may want to try it! @@ -72,7 +72,7 @@ archive](https://logs.guix.gnu.org/hurd/2024-06-25.log). Now for something trivial but fun! I updated the guide on the Hurd wiki that shows how one can run their own [personal ext2fs -translator](https://darnassus.sceen.net/~hurd-web/hurd/translator/ext2fs/). +translator][hurd/translator/ext2fs]. You could go crazy even! Why not make something like this: diff --git a/news/2025-08-10-debian_gnu_hurd_2025.mdwn b/news/2025-08-10-debian_gnu_hurd_2025.mdwn new file mode 100644 index 00000000..affd3c41 --- /dev/null +++ b/news/2025-08-10-debian_gnu_hurd_2025.mdwn @@ -0,0 +1,50 @@ +[[!meta copyright="Copyright © 2021 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="2025-08-10 00:00 UTC"]] + +Debian GNU/Hurd 2025 released! +[[!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=""" + +It is with huge pleasure that the Debian GNU/Hurd team announces the +**release of Debian GNU/Hurd 2025**. + +This is a snapshot of Debian "sid" at the time of the stable Debian +"Trixie" release (Auguest 2025), so it is mostly based on the same +sources. It is not an official Debian release, but it is an official +[[Debian GNU/Hurd|hurd/running/debian]] port release. + +Before posting questions on various webnews, please read +[the FAQ][faq] which will answer most if +not all of them. + +For release details, please read the +[announcement email](https://lists.gnu.org/archive/html/bug-hurd/2025-08/msg00008.html). + +--- + +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]]. + +"""]] diff --git a/news/2025-q4.mdwn b/news/2025-q4.mdwn new file mode 100644 index 00000000..50266f47 --- /dev/null +++ b/news/2025-q4.mdwn @@ -0,0 +1,171 @@ +[[!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-01-02 06:07 UTC"]] + +Hello! Welcome to a new qoth. This qoth covers new and interesting GNU/Hurd +developments in Q4 of 2025! +[[!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=""" + +Joan Lledó worked on [porting dhcpcd](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00084.html) + to the hurd. He also made some changes so that +[lwip would work with dhcpcd](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00068.html). In +this [message](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00084.html) he writes: + +> This is the current state of the port: +> +> - Support only for IPv4. IPv6 not supported yet. +> - It works only over lwip. First, because dhcpcd requires some definitions from +> headers and pfinet doesn't provide them AFAIK, but lwip provide the headers +> through the liblwip-dev package. +> Second, because both pfinet and lwip need changes in the translator in order +> to be fully compatible with dhcpcd, and I made the changes in lwip since I +> know it better. +> - Only Ethernet is supported. This is because the Hurd doesn't define `AF_LINK` +> so dhcpcd can't get any data from the interface other thant what is returned +> by `getifaddrs()`. +> I'm manually providing the MAC address and hardcoding the interface type to +> Ethernet in the `if_init` function. I assume this is correct because the Hurd +> only supports ethernet interfaces AFAIK. +> - dhcpcd monitors the interfaces and gets notified when there are changes in +> routes or network configurations. This is not working yet for the Hurd. +> - dhcpcd implements some privilege separation by which the process spawns new +> processes that run as a non-privileged user. Or that's what I understood. +> It's not implemented for the Hurd because I've deferred this for now. +> - Access to BPF is provided by libpcap. +> - libpcap and liblwip-dev are dependencies for the Hurd. +> - This has been tested only in a 32-bit Hurd. + +Damien Zammit worked on fixing [some](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00123.html) + [interrupt bugs](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00132.html) +in the acpi server. + +He also made some [fixes](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00059.html) for rumpnet. + +He also worked on adding a +[callwheel to GNU Mach's clock](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00015.html). +This would make GNU Mach faster in certain ways. He writes: + +> Timeouts are now very fast to look up, at the expense of more memory, +> a much shorter list is traversed rather than all of them. See [1]. +> Timeouts that are stopped before expiry are now faster to remove, +> and inserting a timeout is faster. +> [1] [https://doi.org/10.7936/K7VM49H5](https://doi.org/10.7936/K7VM49H5) + +Damien also made some progress on the +[SMP support for `x86_64`](https://lists.gnu.org/archive/html/bug-hurd/2026-01/msg00007.html). He writes: + +> This allows gnumach to be compiled with `--enable-ncpus > 1 on x86_64`. +> However, there is still work to be done particularly with SWAPGS +> instruction. Notably, this changeset modifies the AP low boot address +> to be hardcoded to 0x11000 because it is very difficult to implement +> 64 bit AP bringup without knowing the offset in advance of waking up +> the AP via SIPI. +> +> TESTED: +> +> - i386 UP still boots +> - i386 SMP still works with -smp 1 (but freezes during rumpdisk probe) +> - i386 SMP still works with -smp 6 (but freezes during rumpdisk probe) +> - `x86_64 UP` still boots +> - `x86_64 SMP` now compiles, but freezes with -smp 1 during grub module load +> - `x86_64 SMP` now compiles, but freezes with -smp 6 just before AP bringup +> +> We still have work to do, but this definitely makes progress. + + +We had a kind developer submit a tiny patch that kills +[lingering zombie processes](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00019.html). + + +Diego Nieto Cid fixed several compiler warnings throughout our codebase: +[lwip](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00052.html), +[nfsd](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00050.html), +[nfs](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00047.html), etc. + +He also tidied up the glibc `setrlimit ()` call that lets a process limit +its consumption of system resources. When Samuel committed this he +[noticied](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00052.html) +that it works well. Samuel wrote: + +> Thanks for this! That will stabilize boxes against programs that +> allocate like crazy! +> +> Yes, it works well ; on packages that used to kill buildd boxes, we +> properly get virtual addressing space limitation errors. + +For some time now, Mike Kelly has used `stress-ng` to stress test the hurd, +and he keeps finding bugs to +[fix](https://lists.gnu.org:443/archive/html/bug-hurd/2025-11/msg00038.html). He +has even started to stress test in +[real hardware](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00023.html)! +Thanks Mike for making the Hurd more stable! + +He also worked on gnumach [fiddling to](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00026.html) +[decrease compile time](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00047.html). He writes: + +> This implementation now searches for pages in the order: inactive/external, +> inactive/internal, active/external and active/internal as suggested by Samuel +> (https://lists.gnu.org/archive/html/bug-hurd/2025-12/msg00034.html). The +> performance improvement is considerable. A test case involving 3 instances of +> g++ compiling C++ template code (MatrixSine.cpp from libeigen-dev) uses +> sufficient memory on a 4GB machine to require around 500MB of swap. This test +> takes about 11 minutes with previous gnumach version (using a virtual machine) +> but 3 minutes with this alteration. I have not been able to complete this test +> on a 64 bit Hurd 'real hardware' installation with previous gnumach but the +> compilation does complete with this patch after about 10 minutes + +João Pedro Malhado updated our +[alternative hurd installation documentation page](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00035.html). +I think it's pretty cool, that using a Debian GNU/Linux computer, one can install +the Hurd via mmdebstrap. + +We also now have some people running the `x86_64` hurd port on +[real hardware](https://lists.gnu.org/archive/html/bug-hurd/2025-10/msg00001.html). + +Some time ago, Milos Nikic, implemented a +[metadata journal for ext2fs](https://lists.gnu.org:443/archive/html/bug-hurd/2025-08/msg00040.html). +It has not been commited to `libdiskfs`, and it is a +[different design from ext3](https://lists.gnu.org:443/archive/html/bug-hurd/2025-07/msg00048.html). +He writes: + +> This patch introduces a working implementation that captures metadata changes, +> writes them to a CRC32-protected journal file, and replays them during early +> boot—before fsck runs—allowing us to correct inconsistencies proactively. +> +> I'm now using this system routinely without issues, and I believe it already +> provides value for users. + +Some people are mentioning on other news channels that Debian is considering +requiring rust for apt. We just want to mention that rust was ported to the Hurd, +so while there might be some challenges in getting a "rusted" apt working on the Hurd, +we do not forsee any +[unsurmountable problems](https://lists.gnu.org:443/archive/html/bug-hurd/2025-11/msg00014.html). + +In other rust news, apparently the crate `uzers-rs` has recently been built with +[Hurd support](https://lists.gnu.org:443/archive/html/bug-hurd/2025-12/msg00020.html). Apparently, +this is quite a commonly used crate, which should help more rust code work on the 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 +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]]. + +"""]] 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/smp.mdwn b/open_issues/smp.mdwn index 9820f561..ce2c2ce2 100644 --- a/open_issues/smp.mdwn +++ b/open_issues/smp.mdwn @@ -56,7 +56,7 @@ Once you have the Hurd running you can build an SMP enabled GNU Mach. $ autoreconf -i $ mkdir build $ cd build - $ ../configure --enable-ncpus=4 --enable-apic --enable-kdb --disable-linux-groups + $ ../configure --enable-ncpus=4 --enable-kdb $ make gnumach.gz $ su # mv /boot/gnumach-1.8-486.gz /boot/gnumach-1.8-486.gz.bak @@ -88,252 +88,6 @@ To test smp: smp.c source can be found [[here|https://lists.gnu.org/archive/html/bug-hurd/2024-02/msg00088.html]]. -# What was done to get the 32-bit SMP support - -The GNU Mach source code includes many special cases for multiprocessor, -controlled by #if NCPUS > 1 macro. - -But this support is very limited: - -- GNU Mach don't detect CPUs in runtime: The number of CPUs must be hardcoded in -compilation time. The number of cpus is set in `mach_ncpus` configuration -variable, set to 1 by default, in configfrag.ac file. This variable will -generate `NCPUS` macro, which is used by gnumach to control the special cases -for multiprocessor. If `NCPUS` > 1, then gnumach will enable multiprocessor -support, with the number of cpus set by the user in mach_ncpus -variable. Otherwise, SMP will be disabled. - -- The special cases to multicore in gnumach source code have never been tested, - so these can contain many errors. Furthermore, these special case are - incomplete: many functions, such as `cpu_number()` or `intel_startCPU()` aren't - written. - -- GNU Mach doesn't initialize the processor with the proper options for - multiprocessing. For this reason, the current support is only multithread and - not real multiprocessor support. - -- Many drivers included in Hurd aren't thread-safe, and these could crash in a - SMP environment. So, it's necessary to isolate this drivers, to avoid - concurrency problems. - - -### Solution - -To solve this, we need to implement some routines to detect the number of -processors, assign an identifier to each processor, and configure the lapic and -IPI support. These routines must be executed during Mach boot. - -> "Really, all the support you want to get from the hardware is just getting the -> number of processors, initializing them, and support for interprocessor -> interrupts (IPI) for signaling." - Samuel Thibault -> [link](https://lists.gnu.org/archive/html/bug-hurd/2018-08/msg00071.html) - -> "The process scheduler probably already has the support. What is missing is -the hardware driver for SMP: enumeration and initialization." - Samuel Thibault -[link](https://lists.gnu.org/archive/html/bug-hurd/2018-08/msg00083.html) - -The current necessary functions are `cpu_number()` (in kern/cpu_number.h) and -`intel_startCPU()`. Another non-critical function, is `cpu_control()` -[*Reference*](https://www.gnu.org/software/hurd/gnumach-doc/Processor-Control.html#Processor-Control) - -Other interesting files are `pmap.c` and `sched_prim.c` We also -have to build an isolated environment to execute the non-thread-safe drivers. - -> "Yes, this is a real concern. For the Linux drivers, the long-term goal is to -> move them to userland anyway. For Mach drivers, quite often they are not -> performance-sensitive, so big locks would be enough." - Samuel Thibault -> [link](https://lists.gnu.org/archive/html/bug-hurd/2018-08/msg00073.html) - -### Task list - -1. DONE Implement a routine to detect and identify the processors - - This routine must check the number of processors, initialize the lapic of BSP - (the master processor), and assign a kernel ID for each processor. This kernel - ID does not have to be equal to the APIC ID. The relation kernel/APIC can be - settled with an array, where the kernel ID is the index, and the APIC contains - the data. GNU Mach can derive the list of processors from memory, reading from - ACPI table, or from MP table. However, MP table is deprecated in most modern - CPUs, so it is preferable to use ACPI table for this. - - The tasks to do for this are: - - - Detect the number of processors - - - Create a array indexed by kernel ID, which sets a relation with APIC ID. - - - Initialize the lapic of BSP - - - Initialize IOAPIC - - This routine could be called from `i386at_init()` - (i386/i386at/model_dep.c). This function will call the functions which - initialize the lapic and the ioapic. - - **NOTE**: This routine must be executed before `intel_startCPU()` or other routines. - - - **How to find APIC table** - - To find APIC table, we can read - RSDT table [RSDT reference](http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf#G10.1358180). - To get the address of RSDT, we need to read RDSP table. We can get the - RSDP table by this [RDSP - reference](http://www.uefi.org/sites/default/files/resources/ACPI%206_2_A_Sept29.pdf#G10.1357698) - Once we have the RSDT table, we need to read *Entry* field, and search the pointer to - the APIC table in the array referenced in this field. - - We can find an example about reading ACPI table in X15 OS: - [Reference](https://github.com/richardbraun/x15/blob/0c0e2a02a42a8161e1b8dc1e1943fe5057ecb3a3/arch/x86/machine/acpi.c#L576) - - - We need to initialize the `machine_slot` of each processor (currently only initializes cpu0). - The `machine_slot` has this structure. [Reference](https://github.com/AlmuHS/GNUMach_SMP/blob/0d490ef21c156907f3f26a6cdc00842f462a877a/include/mach/machine.h#L68): - - > `struct machine_slot { /*boolean_t*/` <br/> - > `integer_t is_cpu;` <br/> - > `/* is there a cpu in this slot? */ ` <br/> - > `cpu_type_t cpu_type; /* type of cpu */` <br/> - > `cpu_subtype_t cpu_subtype; /* subtype of cpu */` <br/> - > `/*boolean_t*/ integer_t running; /* is cpu running */` <br/> - > `integer_t cpu_ticks[CPU_STATE_MAX]; integer_t` <br/> - > `clock_freq; /* clock interrupt frequency */ };` <br/> - - - We can find an example of initialization in this [link:](https://github.com/AlmuHS/GNUMach_SMP/blob/0d490ef21c156907f3f26a6cdc00842f462a877a/i386/i386at/model_dep.c#L612) - - This modification also involve the redefinition of `NCPUS`, which must be set - to the maximum **possible** number of processors. We can do this by modifying - `configfrag.ac`, with this: - - > `# Multiprocessor support is still broken.` <br/> - > `AH_TEMPLATE([MULTIPROCESSOR], [set things up for a uniprocessor])` <br/> - > `mach_ncpus=2` <br/> - > `AC_DEFINE_UNQUOTED([NCPUS], [$mach_ncpus], [number of CPUs])` </br> - > `[if [$mach_ncpus` > `-gt 1 ]; then]` <br/> - > `AC_DEFINE([MULTIPROCESSOR], [1], [set things up for a` > `multiprocessor])` - > `AC_DEFINE_UNQUOTED([NCPUS], [256], [number of CPUs]) ` <br/> - > `[fi]` <br/> - - - Interesting files and functions - `machine.c` - [Link](https://github.com/AlmuHS/GNUMach_SMP/blob/master/kern/machine.c) - - `c_boot_entry()` - [Link](https://github.com/AlmuHS/GNUMach_SMP/blob/0d490ef21c156907f3f26a6cdc00842f462a877a/i386/i386at/model_dep.c#L529) - - - Example, in X15 OS: - [Link](https://github.com/richardbraun/x15/blob/d6d90a3276a09da65690b019e985392bf77b53b0/arch/x86/machine/cpu.c#L1114) - - 1.1. Implement a `cpu_number()` function. - - - This function must return the kernel ID of the processor which is executing the function. To - get this, we have to read the local apic memory space, which will show the - lapic of the current CPU. Reading the lapic, we can get its APIC ID. Once - we have the APIC ID of the current CPU, the function will search in the - Kernel/APIC array until it finds the same APIC ID. Then it will return the - index (Kernel ID) of this position. - -2. DONE Implement a routine to initialize the processors - - - This routine will initialize the lapic of each processor and other structures - needed to run the kernel. We can find an example of lapic initialization - here - [reference](https://github.com/mit-pdos/xv6-public/blob/b818915f793cd20c5d1e24f668534a9d690f3cc8/lapic.c#L55) - Also, we can get more information in Chapter 8.4 and 8.11 of Intel - Developer Guide, - Volume 3. [link](https://software.intel.com/sites/default/files/managed/a4/60/325384-sdm-vol-3abcd.pdf) - -3. DONE Implement `intel_startCPU()` - - - This function will initialize the descriptor tables of the processor specified by the - parameter, and launch the startup IPI to this processor. This function will be - executed during the boot of the kernel (process 0). The task to do in this function - are: - - - Initialize the processor descriptor tables - - Launch Startup IPI to this processor - We have a current implementation of `intel_startCPU()` in this - [link](https://github.com/AlmuHS/GNUMach_SMP/blob/smp/i386/i386/mp_desc.c). - This implementation is based in XNU's `intel_startCPU()` - [function](https://github.com/nneonneo/osx-10.9-opensource/blob/f5a0b24e4d98574462c8f5e5dfcf0d37ef7e0764/xnu-2422.1.72/osfmk/i386/mp.c#L423) - - We can find explainations about how to raise an IPI in this pages: - [*Reference 1*](https://www.cs.usfca.edu/~cruse/cs630f08/lesson22.ppt), - [*Reference 2*](https://www.cheesecake.org/sac/smp.html), [*Reference - 3*](http://www.dis.uniroma1.it/pub/quaglia/AOSV-traps-interrupts.pdf) We can - get information about how to raise an IPI in Intel Developer Guide, Volume 3, - Chapter 10.6 - -4. Implement another routine to start the processors - - - This routine calls to `processor_start()` for each processor, which will start the - processor using this sequence of calls: [`processor_start(processor_t - processor)`](https://github.com/AlmuHS/GNUMach_SMP/blob/5d527f532dfba9f2da54555d5fbe585dd458579b/kern/processor.c#L447) - -> - [`cpu_start(processor->slot_num)`](https://github.com/AlmuHS/GNUMach_SMP/blob/5d527f532dfba9f2da54555d5fbe585dd458579b/i386/i386/mp_desc.c#L335) - -> - [`intel_startCPU(cpu)`](https://github.com/AlmuHS/GNUMach_SMP/blob/5d527f532dfba9f2da54555d5fbe585dd458579b/i386/i386/mp_desc.c#L180) - - These articles shows some annotations about how to do the AP Startup: - - - [Reference1](https://wiki.osdev.org/Symmetric_Multiprocessing#AP_startup), - - [Reference2](https://stackoverflow.com/a/16368043/7077301) (...) - - After implement IPI support, It's recommended reimplement `machine_idle()`, - `machine_relax ()`, `halt_cpu()` and `halt_all_cpus()` using IPI. - - [reference](https://github.com/AlmuHS/GNUMach_SMP/blob/0d490ef21c156907f3f26a6cdc00842f462a877a/i386/i386at/model_dep.c#L201) - - Also in `ast_check.c`, we have to implement both functions, using - IPI - [Reference](https://github.com/AlmuHS/GNUMach_SMP/blob/master/i386/i386/ast_check.c) - - - This functions must force the processors to check if there are any AST - signal, and we ought to keep in the mind the following irc chat: - - -> <AlmuHS> what is the use of AST in gnumach? <br/> -> <AlmuHS> this file what do? <br/> -> https://github.com/AlmuHS/GNUMach_SMP/blob/master/i386/i386/ast_check.c <br/> -> <youpi> I don't know <br/> -> <youpi> but look at what calls that <br/> -> <youpi> see e.g. the call in thread.c <br/> -> <AlmuHS> This <br/> -> function is called during the sequence of cpu_up(), in machine.c <br/> -> <AlmuHS> but only if NCPUS > 1 <br/> -> <youpi> it seems like it's to trigger an AST check on another <br/> -> processor <br/> -> <youpi> i.e. a processor tells another to run ast_check <br/> -> <youpi> (see the comment in thread.c) <br/> -> <AlmuHS> <br/> -> https://github.com/AlmuHS/GNUMach_SMP/blob/master/kern/machine.c <br/> -> <youpi> well, the initialization part is not necessarily what's -> important to <br/> -> think about at first <br/> -> <youpi> i.e. until you know what you'll have <br/> -> to do during execution, you don't know what you'll need to intialize at <br/> -> initialization <br/> -> <youpi> you might even not need to initialize anything <br/> -> <AlmuHS> then, this is the reason because all functions <br/> -> in ast_check.c are empty <br/> -> <youpi> cause_ast_check being empty is really probably a TODO <br/> -> <AlmuHS> but I'm not clear what I need to write in this functions <br/> -> <youpi> what the comment said: make another processor run ast_check() <br/> -> <youpi> which probably means raising an inter-processor interrupt <br/> -> <youpi> (aka IPI) <br/> -> <youpi> to get ast_check() called by the other processor <br/> -> <AlmuHS> then, this funcions must raise an IPI in the processor? <br/> -> <youpi> that's the idea <br/> -> <youpi> the IPI probably needs some setup <br/> - -We can use [XV6 source - code](https://pdos.csail.mit.edu/6.828/2018/xv6.html). as model to implements - the function and routines. Some interesting files are - [`lapic.c`](https://github.com/mit-pdos/xv6-public/blob/master/lapic.c), - [`proc.c`](https://github.com/mit-pdos/xv6-public/blob/master/proc.c) and - [`main.c`](https://github.com/mit-pdos/xv6-public/blob/master/main.c) - - ## References - [Comments about the project bug-hurd maillist](https://lists.gnu.org/archive/html/bug-hurd/2018-08/msg00048.html) 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_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/BuildingHurdLiveCD.mdwn b/unsorted/BuildingHurdLiveCD.mdwn index e2082268..a0830c77 100644 --- a/unsorted/BuildingHurdLiveCD.mdwn +++ b/unsorted/BuildingHurdLiveCD.mdwn @@ -49,6 +49,7 @@ That was the recipe for using a floppy image. If you use the `-t hd` switch of ` * `/hurd/iso9660fs.static` * `/hurd/exec` * `/lib/ld.so.1` +* `/lib/ld-x86-64.so.1` ## <a name="Contents_of_grub_conf"> Contents of grub.conf </a> @@ -63,7 +64,9 @@ That was the recipe for using a floppy image. If you use the `-t hd` switch of ` --host-priv-port=${host-port} --device-master-port=${device-port} \ --exec-server-task=${exec-task} -T typed ${root} $(task-create) \ $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) + module /lib/ld-x86-64.so.1 /hurd/exec $(exec-task=task-create) + +Note: use `ld.so.1` instead of `ld-x86-64.so.1` on 32b systems. **_Note:_** The `root (cd)` line may prevent some computers from booting the livecd. diff --git a/unsorted/CrossHurd.mdwn b/unsorted/CrossHurd.mdwn deleted file mode 100644 index 3313eba3..00000000 --- a/unsorted/CrossHurd.mdwn +++ /dev/null @@ -1,96 +0,0 @@ -This will eventually become an installation guide for the Debian crosshurd package (GNU/Hurd cross install only). However, for the time being I am setting it up as a diet version of Hurd/InstalNotes, adapted for crosshurd, adapted for me. - --- [[Main/JoachimNilsson]] - 14 Mar 2004 - -## <a name="Reserving_partitions"> Reserving partitions </a> - -You need a swap and root partition, much like any other UNIX system. Two things to remember: - -1. Root partition still <2.0 GiB -2. Root partition: mke2fs -o hurd -b 4096 -L Carlsberg - -From a Debian GNU/Linux installation preparing install of GNU/Hurd on /dev/hdb2 reusing the Linux swap on /dev/hdb4. - - # mke2fs -o hurd -b 4096 -L Carlsberg /dev/hdb2 - -<div> - <center> "Carlsberg. Probably the best beer in the world." </center> -</div> - -## <a name="Bootstrapping"> Bootstrapping </a> - -After having installed the Debian crosshurd package you need to mount your newly created Hurd partition. - - mkdir /gnu - mount /dev/hdb2 /gnu - -Now, simply run the crosshurd program and follow the onscreen directions. **Do** select the usr symlink. - - crosshurd - -crosshurd burps a lot of unneeded information on screen and probably fails to install one or two files due to duplicates between GNU and Debian packages. Lets hope this mess is worked out some day. - -## <a name="Rebooting"> Rebooting </a> - -Before we reboot you must setup a Hurd entry in the menu.lst file of Grub. Do it like this and remember, **no trailing spaces**! - -The first two runs (reboots) you must run the Hurd in single-user mode! - - title GNU (kernel GNUmach 1.5) - root (hd1,1) - kernel /boot/gnumach-1.5-486.gz root=device:hd1s2 -s - module /hurd/ext2fs.static \ - --multiboot-command-line=${kernel-command-line} \ - --host-priv-port=${host-port} \ - --device-master-port=${device-port} \ - --exec-server-task=${exec-task} \ - -T typed ${root} $(task-create) $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) - -N.B. the '-s' on the kernel line, it is "single user mode", which you need for the first two reboots. - -OK, reboot now. - -## <a name="First_steps"> First steps </a> - -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. - -## <a name="Logging_in"> Logging in </a> - -Finally, a complete bootstrapped GNU system. - - login root - - export TERM=mach - - nano /etc/fstab - [add swap partition /dev/hd1s4] - - nano /etc/ttys - [remove all hashes to enable the new Hurd Console] - - settrans -fgap /servers/socket/2 /hurd/pfinet -i /dev/eth0 -a 192.168.1.3 -g 192.168.1.1 -m 255.255.255.0 - - dselect - -Now, do the old Debian thing of dancing with dselect for a couple of hours. - -Reboot and start the new [[Console]] - - login root - - console -d vga -d pc_kbd -d generic_speaker /dev/vcs - -Move around just like in Linux console, but with persistent scroll-back buffers for each console. - -## <a name="References"> References </a> - -* [[Network]] -* [[Console]] diff --git a/unsorted/MakeImage.mdwn b/unsorted/MakeImage.mdwn index b9b6e21a..f71743a6 100644 --- a/unsorted/MakeImage.mdwn +++ b/unsorted/MakeImage.mdwn @@ -45,12 +45,14 @@ I use this for testing OSKit... --host-priv-port=${host-port} --device-master-port=${device-port} \ --exec-server-task=${exec-task} -T typed ${root} $(task-create) \ $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) + module /lib/ld-x86-64.so.1 /hurd/exec $(exec-task=task-create) EOF mkisofs -R -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 \ -boot-info-table -o grub.iso iso +Note: use `ld.so.1` instead of `ld-x86-64.so.1` on 32b systems. + ## <a name="Booting_Qemu"> Booting Qemu </a> qemu -m 512 -boot d -cdrom grub.iso -drive cache=writeback,file=gnu.img diff --git a/unsorted/OskitMach.mdwn b/unsorted/OskitMach.mdwn index 0f7dfa54..6e1b8e31 100644 --- a/unsorted/OskitMach.mdwn +++ b/unsorted/OskitMach.mdwn @@ -48,7 +48,9 @@ You start Oskit-Mach almost the same way as the old 1.x version of GNUmach. Usin --device-master-port=${device-port} \ --exec-server-task=${exec-task} \ -T typed ${root} $(task-create) $(task-resume) - module /lib/ld.so.1 /hurd/exec $(exec-task=task-create) + module /lib/ld-x86-64.so.1 /hurd/exec $(exec-task=task-create) + +Note: use `ld.so.1` instead of `ld-x86-64.so.1` on 32b systems. _Remember_ to ensure that there are no trailing spaces after the backslashes on the lines above if you copy-paste this into your menu.list file. |