diff options
Diffstat (limited to 'hurd')
29 files changed, 483 insertions, 69 deletions
diff --git a/hurd/ada4hurd.mdwn b/hurd/ada4hurd.mdwn index c783e53b..e5ef1359 100644 --- a/hurd/ada4hurd.mdwn +++ b/hurd/ada4hurd.mdwn @@ -51,7 +51,7 @@ Ada4Hurd provides tools and examples to ease Ada development in Hurd. It is at a * Install the build dependencies as root - $ apt-get install gnat libopentoken4-dev libxmlada5-dev libasis2014-dev + $ apt install gnat libopentoken4-dev libxmlada5-dev libasis2014-dev * Build @@ -65,4 +65,4 @@ Ada4Hurd provides tools and examples to ease Ada development in Hurd. It is at a * Run netfs tests * In netfs\_base directory - $ make trans\_dbg\_on
\ No newline at end of file + $ make trans\_dbg\_on diff --git a/hurd/bootstrap.mdwn b/hurd/bootstrap.mdwn index fbce3bc1..c77682b9 100644 --- a/hurd/bootstrap.mdwn +++ b/hurd/bootstrap.mdwn @@ -15,8 +15,15 @@ this text. --> [[!toc]] +[[!inline pagenames=hurd/what_is_an_os_bootstrap raw=yes feeds=no]] + # State at the beginning of the bootstrap +Please note that as of May 2024 this document is out of date. It does +not explain how rumpdisk or the pci-arbitor is started. Also consider +reading about [[Serverboot V2|open_issues/serverbootv2]], which +is a new bootstrap proposal. + After initializing itself, GNU Mach sets up tasks for the various bootstrap translators (which were loader by the GRUB bootloader). It notably makes variables replacement on their command lines and boot script function calls (see diff --git a/hurd/building.mdwn b/hurd/building.mdwn index 31d909e5..63c33498 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-get install build-essential fakeroot - # apt-get build-dep hurd + # apt install build-essential fakeroot + # apt build-dep hurd ## ... on non-Debian systems @@ -41,9 +41,9 @@ 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): - $ apt-get source hurd + $ apt source hurd -Please see the Debian [[FAQ]] before using `apt-get source`. +Please see the Debian [[FAQ]] before using `apt source`. The unpacked source tree is around 20 MiB, and the build tree (configured with `--disable-profile`) is around 100 MiB. @@ -93,6 +93,12 @@ or `/local/`, so your current Hurd servers will be replaced. To install to a different location, specify `--prefix=PREFIX` as `configure` parameter, e.g. `--prefix=/usr` (as done when having a real `/usr`). +To build acpi: + + $ make acpi + +You may need to install necessary acpi headers (`libacpica-dev` package in Debian based distro). + By default profiling versions of all the libraries and code are generated but this is useless in most of the cases, so we disable them by specifying `--disable-profile` on `configure`'s command line. diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index dd36f1f5..b6cf7753 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -58,11 +58,11 @@ Download the packages for offline installation: $ cd /mnt - $ apt-get -c etc/apt/apt.conf.offline update + $ apt -c etc/apt/apt.conf.offline update - $ apt-get -c etc/apt/apt.conf.offline build-dep hurd gnumach + $ apt -c etc/apt/apt.conf.offline build-dep hurd gnumach - $ apt-get -c etc/apt/apt.conf.offline install git-core build-essential libpciaccess-dev libpcap0.8-dev hurd-dev zlib1g-dev + $ apt -c etc/apt/apt.conf.offline install git-core build-essential libpciaccess-dev libpcap0.8-dev hurd-dev zlib1g-dev Get DDE code: @@ -117,9 +117,9 @@ so we can boot into Hurd to do the actual work. Once there, install the packages previously downloaded (again as root): - $ apt-get build-dep hurd gnumach + $ apt build-dep hurd gnumach - $ apt-get install git-core build-essential libpciaccess-dev libpcap0.8-dev hurd-dev zlib1g-dev + $ apt install git-core build-essential libpciaccess-dev libpcap0.8-dev hurd-dev zlib1g-dev Make sure we can build stuff as normal user: diff --git a/hurd/debugging/glibc.mdwn b/hurd/debugging/glibc.mdwn index a409f392..1b7e6ab1 100644 --- a/hurd/debugging/glibc.mdwn +++ b/hurd/debugging/glibc.mdwn @@ -44,24 +44,26 @@ testsuite, use: To save even more build, stop the build after configure has run, and then you can restart the build of only libc.so and libc.a with: - cd build-tree/hurd-i386-libc - make lib + make -C build-tree/hurd-i386-libc lib or of only libc.so with: - make objdir=$PWD/build-tree/hurd-i386-libc $PWD/build-tree/hurd-i386-libc/libc.so + make -C build-tree/hurd-i386-libc objdir=$PWD/build-tree/hurd-i386-libc $PWD/build-tree/hurd-i386-libc/libc.so or of the whole tree with: - cd build-tree/hurd-i386-libc - make + make -C build-tree/hurd-i386-libc or of just one subdir with for instance: - make subdir=libpthread -C libpthread ..=../ objdir=$PWD/build-tree/hurd-i386-libc + make -C htl subdir=htl ..=../ objdir=$PWD/build-tree/hurd-i386-libc (note that most subdirs need libc.so built) +Similarly, you can run the testsuite of a single directory the same way: + + make check -C htl subdir=htl ..=../ objdir=$PWD/build-tree/hurd-i386-libc + --- In some cases, printing to stdout/stderr is problematic. One can use a kernel diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index f095cf26..0d9bed65 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -22,7 +22,9 @@ is included in the section entitled * [[*Towards_a_New_Strategy_of_OS_Design*|/hurd-paper]], an architectural overview by Thomas Bushnell, BSG, notably: * [[The design|/hurd-paper#design]] - * [[Translators|/hurd-paper#translator]] + * [[Introduction to Translators|/hurd-paper#translator]] and + [[Existing Translators|hurd/translator]] + * [[Subhurds|hurd/subhurd]] * [[The auth translator|/hurd-paper#auth]] * [[The proc translator|/hurd-paper#proc]] * [[The exec translator|/hurd-paper#exec]] diff --git a/hurd/glibc.mdwn b/hurd/glibc.mdwn index 4b5e8d38..8e330aef 100644 --- a/hurd/glibc.mdwn +++ b/hurd/glibc.mdwn @@ -27,18 +27,18 @@ glibc. This should be working as per the following: $ mkdir -p /tmp/build/src $ cp -a /usr/src/glibc /tmp/build/src/ $ unset CFLAGS - $ /tmp/build/src/glibc/scripts/build-many-glibcs.py /tmp/build checkout - $ /tmp/build/src/glibc/scripts/build-many-glibcs.py /tmp/build host-libraries - $ /tmp/build/src/glibc/scripts/build-many-glibcs.py /tmp/build compilers i686-gnu + $ /tmp/build/src/glibc/scripts/build-many-glibcs.py --shallow /tmp/build checkout + $ /tmp/build/src/glibc/scripts/build-many-glibcs.py --strip /tmp/build host-libraries + $ /tmp/build/src/glibc/scripts/build-many-glibcs.py --strip /tmp/build compilers i686-gnu $ /tmp/build/src/glibc/scripts/build-many-glibcs.py /tmp/build glibcs i686-gnu Currently the master branch builds that way without any testsuite issue. -# Building +To save some disk space, after the compilers stage you can remove src/mpc, src/mpfr, src/binutils, src/linux. -One of the tests really put boxes on its knees: +Build logs are available in `/tmp/build/logs` - $ echo "tests-unsupported += test-lfs" >> sysdeps/mach/hurd/i386/Makefile +# Building One can build libc this way: @@ -52,3 +52,7 @@ One can build libc this way: One can run tests with the new libc by hand: $ ./testrun.sh ~/test + +One can build by hand some target with e.g.: + + $ make $PWD/htl/libpthread.so -C ../htl subdir=htl objdir=$PWD ..=../ diff --git a/hurd/porting/guidelines.mdwn b/hurd/porting/guidelines.mdwn index d132f516..624f7fd5 100644 --- a/hurd/porting/guidelines.mdwn +++ b/hurd/porting/guidelines.mdwn @@ -132,7 +132,7 @@ If you get Bad File Descriptor error when trying to read from a file (or accessi <http://pubs.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html> -Also see <https://eklitzke.org/path-max-is-tricky> +Also see <https://eklitzke.org/path-max-is-tricky> and <https://insanecoding.blogspot.com/2007/11/pathmax-simply-isnt.html> Every unconditionalized use of `PATH_MAX`, `MAX_PATH` or `MAXPATHLEN` is a POSIX incompatibility. If there is no upper limit on the length of a path (as its the case for GNU), this symbol is not defined in any header file. Instead, you need to either use a different implementation that does not rely on the length of a string or use `sysconf()` to query the length at runtime. If `sysconf()` returns -1, you have to use `realloc()` to allocate the needed memory dynamically. Usually it is thus simpler to just use dynamic allocation. Sometimes the amount is actually known. Else, a geometrically growing loop can be used: for instance, see [Pulseaudio patch](http://bugs.debian.org/cgi-bin/bugreport.cgi?msg=5;filename=patch-pulse;att=1;bug=522100). Note that in some cases there are GNU extensions that just work fine: when the `__GLIBC__` macro is defined, `getcwd()` calls can be just replaced by `get_current_dir_name()` calls. @@ -142,10 +142,10 @@ for a potential corresponding `PATH_MAX` macro. They are not a replacement for Note 2: Yes, some POSIX functions such as `realpath()` actually assume that `PATH_MAX` is defined. This is a bug of the POSIX standard, which got fixed in -POSIX 2001, in which one can simply pass `NULL` to get a dynamically +POSIX 2008, in which one can simply pass `NULL` to get a dynamically allocated buffer. One can thus use: - #if _POSIX_VERSION >= 200112 || defined(__GLIBC__) + #if _POSIX_VERSION >= 200809 || defined(__GLIBC__) char *path = realpath(orig, NULL); #else char path[PATH_MATH]; diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn index 1615ccc0..5fe13fdb 100644 --- a/hurd/porting/system_api_limitations.mdwn +++ b/hurd/porting/system_api_limitations.mdwn @@ -22,8 +22,5 @@ These are the known system API limits that have porting implications. **_[\#47998](http://bugs.debian.org/47998): `msgget` IPC not implemented_** -**_[[nice() doesn't work|open_issues/nice_vs_mach_thread_priorities]]_**. - **_[\#187391](http://bugs.debian.org/187391): libc0.3-dev: `sockaddr_un.sun_path` can't be assigned a `const char *` when compiling with g++_**<br />**breaks:** fam, gail<br />**status:** maybe this should be in [[PortingIssues]] (see _long_ bug log) -**_[\#190367](http://bugs.debian.org/190367): libc0.3-dev: `fcntl` `F_GETLK` not implemented (`ENOSYS`)_**<br />**breaks:** gnome-session (and others) from running<br />**error:** misc lock-related errors diff --git a/hurd/rump.mdwn b/hurd/rump.mdwn new file mode 100644 index 00000000..ddde657f --- /dev/null +++ b/hurd/rump.mdwn @@ -0,0 +1,65 @@ +[[!meta copyright="Copyright © 2009, 2010, 2011 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 stable_URL]] + + * [[community/gsoc/project ideas/driver glue code]] + + * [[open issues/user-space device drivers]] + + * [[open issues/device drivers and io systems]] + +--- + +The rump kernels provide existing real world drivers from netbsd. +Since [[DDE]] no longer seems like a promising approach to get drivers +for the Hurd, it appears that rump kernels are the best alternative. +It already does the hard work of providing an environment where the +foreign drivers can run, and offers the additional benefit of being +externally maintained. Rump also offers the necessary facilities for +running all drivers in separate userspace processes, which is more +desirable than drivers running in the microkernel. + +A rump kernel is a minimal and portable NetBSD kernel running in +userspace. Rump kernels provide drivers for modern hard drives, sound +cards, usb support, and a TCP/IP stack. Instead of re-inventing and +maintaining drivers ourselves, we can re-use the existing NetBSD +drivers. + +Hurd developers have enabled experimental support for modern hard +drives with a rump kernel. We call it rumpdisk, and you can try it in +the [[Debian GNU/Hurd image|hurd/running/qemu]]. + +As of May 2023, Hurd users are having good success with it in qemu +environments and some are using it on real hardware! + +We do hope to use rump kernels for usb support, sound support (this +was working at some point), and possibly a new TCP/IP stack, but work +has not completed on those projects. + +# Documentation + + * <http://www.fixup.fi/misc/usenix-login-2015/login_oct15_02_kantee.pdf> + + This is an an opinion paper that explains why operating systems need compartmentalized kernel drivers. + + * <https://github.com/rumpkernel/wiki/wiki/Tutorial:-Getting-started> + + A tutorial introduction for those interested in using and deploying rump kernels. + + * <https://core.ac.uk/display/41816390> + + "User space approach to audio device driving on UNIX-like systems" by Robert Millan Hernandez. + + +# Source Code + + * <https://github.com/rumpkernel> diff --git a/hurd/running/debian/CrossInstall.mdwn b/hurd/running/debian/CrossInstall.mdwn index c7a099c6..26cd77af 100644 --- a/hurd/running/debian/CrossInstall.mdwn +++ b/hurd/running/debian/CrossInstall.mdwn @@ -17,9 +17,9 @@ Next we create a useful mountpoint and mount the partition. ### <a name="Retrieving_CrossHurd"> Retrieving CrossHurd </a> -Unless you don't run Debian GNU/Linux download it from <http://packages.debian.org/crosshurd>, or simply apt-get 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. +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. - # apt-get install crosshurd + # apt install crosshurd ### <a name="Cross_installing"> Cross installing </a> diff --git a/hurd/running/debian/DebianAptOffline.mdwn b/hurd/running/debian/DebianAptOffline.mdwn index 9596040d..f97e5148 100644 --- a/hurd/running/debian/DebianAptOffline.mdwn +++ b/hurd/running/debian/DebianAptOffline.mdwn @@ -24,11 +24,11 @@ As root on the internet connected OS: # mount /dev/DEBIAN_GNU_HURD_PARTITON /mnt # cd /mnt - # apt-get -c etc/apt/apt.conf.offline {update, upgrade, install foo, etc.} + # apt -c etc/apt/apt.conf.offline {update, upgrade, install foo, etc.} Then, reboot into your Debian GNU/Hurd installation and as root, run: - # apt-get {update, upgrade, install foo, etc.} + # apt {update, upgrade, install foo, etc.} ## If you _cannot_ mount your Debian GNU/Hurd partition under another OS. @@ -47,7 +47,7 @@ From the remote sytem, as any user, run: $ cd myhurd $ tar -xf myhurdsconf.tar $ mkdir -p var/lib/apt/lists/partial var/cache/apt/archives/partial tmp - $ apt-get -c etc/apt/apt.conf.offline {update, upgrade, install foo, etc.} + $ apt -c etc/apt/apt.conf.offline {update, upgrade, install foo, etc.} $ tar cf myhurdsconf.tar etc/apt/{apt.conf.offline,sources.list} var/ Copy _myhurdsconf.tar_ back to your Debian GNU/Hurd system. @@ -59,4 +59,4 @@ Finally, from your Debian GNU/Hurd installation as the root user: # tar -xf myhurdsconf.tar # mv var/cache/apt/archives/*.deb /var/cache/apt/archives/ # mv var/lib/apt/lists/*_* /var/lib/apt/lists/ - # apt-get {update, upgrade, install foo, etc.} + # apt {update, upgrade, install foo, etc.} diff --git a/hurd/running/debian/MediaPressKitDiscuss.mdwn b/hurd/running/debian/MediaPressKitDiscuss.mdwn index 2bd97290..05e1761a 100644 --- a/hurd/running/debian/MediaPressKitDiscuss.mdwn +++ b/hurd/running/debian/MediaPressKitDiscuss.mdwn @@ -71,6 +71,6 @@ I think another active process for tracking recent news (if it doesn't already e Here are some interesting urls from [this issue](http://www.debian.org/News/weekly/2003/03/) of the Debian Weekly news: -**Debian Presentations.** Wolfgang Borgert was [looking](http://lists.debian.org/debian-devel-0301/msg00991.html) for a set of slides on dpkg, apt-get and debconf. Javier Fern�ndez-Sanguino Pe�a [intends](http://lists.debian.org/debian-devel-0301/msg01022.html) to provide a 'presentations' section in the [Debian Documentation Project](http://cvs.debian.org/ddp/?cvsroot=debian-doc) (DDP) and has already created an [archive](http://dat.etsit.upm.es/~jfs/debian/www/ddp/slides/) of slides. Whilst the Debian web site does link to [talks](http://www.debian.org/events/talks) given by developers and some [sample slides](http://www.debian.org/events/materials/slides/), it is difficult to gather this information and publish it in a homogeneous way. Talks should be reported to <events@debianNOSPAM.org> and forwarded to him. +**Debian Presentations.** Wolfgang Borgert was [looking](http://lists.debian.org/debian-devel-0301/msg00991.html) for a set of slides on dpkg, apt and debconf. Javier Fern�ndez-Sanguino Pe�a [intends](http://lists.debian.org/debian-devel-0301/msg01022.html) to provide a 'presentations' section in the [Debian Documentation Project](http://cvs.debian.org/ddp/?cvsroot=debian-doc) (DDP) and has already created an [archive](http://dat.etsit.upm.es/~jfs/debian/www/ddp/slides/) of slides. Whilst the Debian web site does link to [talks](http://www.debian.org/events/talks) given by developers and some [sample slides](http://www.debian.org/events/materials/slides/), it is difficult to gather this information and publish it in a homogeneous way. Talks should be reported to <events@debianNOSPAM.org> and forwarded to him. -- [[Main/GrantBow]] - 22 Jan 2003 diff --git a/hurd/running/debian/after_install.mdwn b/hurd/running/debian/after_install.mdwn index d3d32a6f..927d05f1 100644 --- a/hurd/running/debian/after_install.mdwn +++ b/hurd/running/debian/after_install.mdwn @@ -11,7 +11,7 @@ typing a boring arcane. There are Debian-specific scripts that may help you. See [[GRUB]]'s page for this. -# Setup `apt-get` +# Setup `apt Installing packages without having a network connection is described [[DebianAptOffline]]. diff --git a/hurd/running/debian/patch_submission.mdwn b/hurd/running/debian/patch_submission.mdwn index d1a3ba33..e8c8aab0 100644 --- a/hurd/running/debian/patch_submission.mdwn +++ b/hurd/running/debian/patch_submission.mdwn @@ -18,9 +18,9 @@ package, or otherwise frequently used package, or you know upstream anyway. If you had to change the code considerably and are not 100% sure you did not introduce a regression, or are not very experienced with these kinds of code -changes, you should first submit your patch for review to the [Debian alioth -patch -tracker](http://alioth.debian.org/tracker/?atid=410472&group_id=30628&func=browse). +changes, you should first submit your patch for review to +[[https://salsa.debian.org/hurd-team/hurd/|https://salsa.debian.org/hurd-team/hurd/]]. Its +documentation is available [[here|https://wiki.debian.org/Salsa]]. If the patch is trivial, or one of the Debian porters approved your patch for submission, submit the patch to the Debian BTS (bug tracking system). You can diff --git a/hurd/running/debian/qemu_image.mdwn b/hurd/running/debian/qemu_image.mdwn index d96d619d..9984ac33 100644 --- a/hurd/running/debian/qemu_image.mdwn +++ b/hurd/running/debian/qemu_image.mdwn @@ -27,6 +27,8 @@ Usage: * Log in as root (the root password is empty) * Set up a root password with `passwd` +* update the system with `apt update && apt upgrade` + * Log in as demo (the demo password is empty) * Set up a demo password with `passwd` diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn index 190602ed..c56292c8 100644 --- a/hurd/running/qemu.mdwn +++ b/hurd/running/qemu.mdwn @@ -24,6 +24,56 @@ You can use the following images to give the Hurd a try. [[!inline pages=hurd/running/debian/qemu_image raw=yes feeds=no]] +#### Trying out rumpdisk + +[[Rump kernels|hurd/rump]] provide new modern drivers for the Hurd. +We refer to rumpdisk as a rump kernel that provides drivers for modern +hard drives, SSDs, etc. The Rump kernels' integration into the Hurd +are still somewhat experimental, but they seem to work fairly well on +bleeding edge Debian. + +Once you have your latest qemu Debian GNU/Hurd image running, then you +can try the rumpdisk (be sure to pass "-m 2GB" or more). First, +add these sources to your /etc/apt/sources.list + + deb http://deb.debian.org/debian-ports unstable main + deb-src http://deb.debian.org/debian unstable main + deb http://deb.debian.org/debian-ports unreleased main + +Then, upgrade to the bleeding edge Debian GNU/Hurd: + + # apt update + # apt upgrade --without-new-pkgs + # apt dist-upgrade + +Now test to see if the rump kernel works before you make the change +permanent. Manually tweak your /boot/grub/grub.cfg like so: + + # multiboot /boot/gnumach-1.8-486.gz root=part:2:device:hd0 console=com0 + multiboot /boot/gnumach-1.8-486.gz root=part:2:device:wd0 console=com0 noide + +and your /etc/fstab + + #/dev/hd0s2 / ext2 defaults 0 1 + /dev/wd0s2 / ext2 defaults 0 1 + #/dev/hd0s1 none swap sw 0 0 + /dev/wd0s1 none swap sw 0 0 + #/dev/hd2 /media/cdrom0 iso9660 noauto 0 0 + /dev/wd2 /media/cdrom0 iso9660 noauto 0 0 + +Now you can poweroff your machine, reboot, and start using the +rumpdisk! You can make these changes permanent by tweaking +/etc/default/grub and telling it to use rumpdisk: + + GRUB_CMDLINE_GNUMACH="noide" + +Then update your grub: + + # update-grub + +Check that "noide" does appear in your /boot/grub/grub.cfg. + + ## Arch Hurd Live CD [[!inline pages=hurd/running/live_cd raw=yes feeds=no]] @@ -60,7 +110,7 @@ Check if your CPU supports kvm: $ egrep '^flags.*(vmx|svm)' /proc/cpuinfo #### If you don't have hardware support (slow): - $ apt-get install qemu + $ apt install qemu Do not enable kernel-kqemu, as that assumes some particular behavior from the guest kernel, which we are reluctant to artificially add to gnumach. @@ -68,7 +118,7 @@ If QEMU with KVM is not available, [[Virtualbox]] reportedly has better performance. #### If you have hardware support (recommended): - $ apt-get install qemu-kvm + $ apt install qemu-kvm $ modprobe kvm Intel VTx/VTd: Enable Intel kvm in the BIOS @@ -252,13 +302,13 @@ If you are on [[Debian GNU/Hurd|debian]], you can even use [[debian/DHCP]]. To get ssh working: - # apt-get install random-egd openssh-server (Similarly for telnet if preferred) + # apt install openssh-server (Similarly for telnet if preferred) (See also <http://www.nongnu.org/qemu/qemu-doc.html#SEC32>.) Outgoing internet connections should just work then. Testing it can be difficult with a minimal installation, -but `apt-get update` should work after you have filled out +but `apt update` should work after you have filled out `/etc/apt/sources.list`. After that you should be able to install other network packages, but note that `ping` doesn't work with QEMU's user-networking stack. @@ -355,7 +405,7 @@ Once you have logged in as `root` run the `pfinet` translator with values that a That should do it! Do not forget to edit/update `/etc/resolv.conf` to get DNS working. --- -# Multiboot +# Booting Hurd without grub, using qemu's multiboot support See "Linux/Multiboot boot specific" section on QEMU manpage. @@ -374,18 +424,15 @@ you'll get told: *qemu: linux kernel too old to load a ram disk*. $ qemu [...] \ > --kernel gnumach \ + > --append 'root=device:hd0s1' \ > --initrd \ - > '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 device:hd0s1 $(task-create) $(task-resume)',\ + > '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)',\ > 'exec.static $(exec-task=task-create)' Note that, contrary to [[GRUB]]'s configuration file, you don't specify "`argv[0]`" here, and it's fortunate that neither ext2fs nor exec need a comma on their command line... -You can also use `--append [...]`, which will show up in `/proc/cmdline`. - -Command line above crashes with old qemu versions, for instance qemu 1.1.2 on Debian Wheezy, fixed by upgrading to wheezy-backports currently qemu 1.7.0, see [[!debbug 741873]] - --- # Related Links diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn index 587cc227..d24369bc 100644 --- a/hurd/subhurd.mdwn +++ b/hurd/subhurd.mdwn @@ -37,6 +37,11 @@ boot it: $ gunzip debian-hurd.img.gz $ boot --kernel-command-line="fastboot root=pseudo-root" -T typed part:1:file:debian-hurd.img +/!\ If you face an error from the mach-defpager (most probably +because there is already a default pager), you can comment +the part that says `/hurd/mach-defpager` from the `/etc/hurd/runsystem.sysv` file +included within the `debian-hurd.img` file you are trying to use. + 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: @@ -134,7 +139,7 @@ In the subhurd, you can do basically all the same things as in the main Hurd. You can even set up networking: Just invoke `settrans` on the `/servers/socket/2` as usual inside the subhurd, using `/dev/eth0`, only using a different local IP than in the main Hurd. This way, the subhurd will be able to communicate to -the outside world with its own IP -- allowing for example to do `apt-get` +the outside world with its own IP -- allowing for example to do `apt inside the subhurd, or to `ssh` directly into the subhurd. If you want to access the subhurd processes from the outside, e.g. for diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index 6c338794..dad26881 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -108,6 +108,7 @@ The [[concept|concepts]] of translators creates its own problems, too: * [[firmlink]] * [[fifo]] * [[term]] +* [[checkperms]] * ... diff --git a/hurd/translator/checkperms.mdwn b/hurd/translator/checkperms.mdwn new file mode 100644 index 00000000..a8a52cb1 --- /dev/null +++ b/hurd/translator/checkperms.mdwn @@ -0,0 +1,233 @@ +[[!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]]."]]"""]] + +The *checkperms* translator implements deferred authorization. + +It is part of a project to enable asking for a grant of authorization +when processes access a file. It is built as a translator and a simple +permission granting program. + +The translator can delegate permission-granting to the program via two +FIFO files. The goal is to create a simple replacement for the +use-case of polkit of granting privilege to a process to access some +resource after user-interaction with a permission-granting daemon. + + +# Code + +The translator is available in the checkperm-deferred-authorization branch in [the hurd repository](https://git.savannah.gnu.org/cgit/hurd/hurd.git). + +The code for the program is provided in this article + +# Usage Example + +We restrict a the node /hello to require explicit permission for every +PID that does not have the group `user`. This notably does include +processes started by root. + + +## How it looks + +**First shell** as root: + + settrans -cga /hello $(realpath ~/Dev/hurd/trans/checkperms) --groupname=user + su - user --shell /bin/bash -c 'cat /hello' + # ⇒ HELLOWORLD # user has the group user + cat /hello # root does not have the group user, so + # this blocks until positive reply in the other shell + +**Second shell** (run the program): + + Process 732 tries to access file /hello but is not in the required group user. + USER PID %CPU %MEM SZ RSS TT STAT START TIME COMMAND + root 732 0.0 0.1 148M 3.55M p2 Sso Mon 1AM 0:01.10 -bash + Grant permission and add group "user" for 5 minutes? [y/N]> y + +**First shell** as root: + + # ⇒ HELLOWORLD + # only blocks once despite getting two reads from cat, + # because for the second read cat already has the group `user`. + + + +## Trying it yourself + +Setup the development environment with the code at ~/Dev similar to +https://www.draketo.de/software/hurd-development-environment + + +Compile and setup the translator: + + cd ~/Dev/hurd && \ + patch -p1 < checkperms.patch && \ + autoreconf -i && \ + ./configure --without-parted && \ + make && \ + touch trans/checkperms.c && \ + CFLAGS="$CFLAGS -g" make && \ + echo HELLOWORLD > /hello && \ + settrans -cga /hello $(realpath ~/Dev/hurd/trans/checkperms) --groupname=user + +Create the FIFOs: + + USER=root + GROUP=user + mkdir -p /run/$USER/request-permission + mkdir -p /run/$USER/grant-permission + mkfifo /run/$USER/request-permission/$GROUP + mkfifo /run/$USER/grant-permission/$GROUP + +Setup the permission-granting program in a separate shell: + + USER=root + GROUP=user + while true; do + PID="$(cat /run/$USER/request-permission/$GROUP)" + echo Process $PID tries to access file /hello but is not in the required group $GROUP. + ps-hurd -p $PID -aeux + if [[ "$(read -e -p 'Grant permission and add group "'$GROUP'" for 5 minutes? [y/N]> '; echo $REPLY)" == [Yy]* ]]; then + addauth -p $PID -g $GROUP + echo 0 > /run/$USER/grant-permission/$GROUP + (sleep 300 && rmauth -p $PID -g $GROUP 2>/dev/null) & + else + echo 1 > /run/$USER/grant-permission/$GROUP + fi + done + + +Access the translator as user without the required group and with the group: + + su - user --shell /bin/bash -c cat /hello' + cat /hello & + + +# Concept + +## The translator + +The translator is started with a GROUP as argument. When the file is +accessed, the translator checks whether the process has the given +group. If it does, it returns data read from the underlying file. + +If the process lacks the required group, the translator retrieves its +USER and PID and writes the PID into a FIFO located at + + /run/USER/request-permission/GROUP + +Then it reads from + + /run/USER/grant-permission/GROUP + +It blocks until it gets a reply. If it reads a 0 (=success), it reads +from the file and returns the data. + +## The permission granting program + +The permission granting program reads the PID from + + /run/USER/request-permission/GROUP + +retrieves information about the PID and asks the user whether to allow +the program. + +If the USER answers no, the RET value is non-zero. + +If the USER answers yes, the RET value is zero (0) +and the program adds the GROUP to the process at PID (using addauth). + +It also starts a daemon that will remove the group again after 5 +minutes (modelled after the temporary permissions to run privileged +without password granted by sudo). + +The program then writes the RET value into + + /run/USER/grant-permission/GROUP + +## What if the translator crashes? + +If the translator crashes, the permissions return to those of the +underlying node. For every user except root this usually means that +the process does not have access to the file. + +The failure-mode should therefore be safe. + +# Possibilities + +The most important use-case for this translator is to make it easier +to start programs with reduced permissions and only add these when +required. + +To setup deferred permissions for a single file, you can create a +group just for that file. Then each file can have its own permission +granting program. Having dedicated groups decouples authentication and +authorization while staying in the conventional *nix permissions +scheme. + +You can also set this translator on a file that gets accessed first +when a process accesses a set of related files that all have the same +group. Since the authorization-program here adds the group for 5 +minutes, the other files can afterwards be accessed, too. + +Since the translator simply defers to a program, that program could do +any action to get authorization, including `curl`. Administrators for +a local network could therefore set up terminals for unprivileged +users that request permissions from a local server when accessing a +file. That way permissions can easily be coordinated over multiple +machines. (naturally this does not restrict root who can always use +settrans -g to get raw access to the file) + + + + +# Open Issues + +## read-only + +[[!tag open_issue_hurd]] + +The current implementation only provides read-access, writing is +prevented. This is not an intrinsic limitation, only an implementation +artefact. + +## delegate + +The underlying file is currently read by the translator and the data +returned to the reading process. To reduce delays, it could directly +delegate to the underlying file. With the long term goal to provide +multiplexing of access, for example for audio, reading via the +translator could be preferable, though. + +## writing via system shell + +Writing to and reading from the FIFOs is currently done with +`system()`. It would be nicer to move to an implementation that does +not rely on the system-shell. + +## potential race-condition + +Accesses from two different translators can currently race for the +reply. To fix this, the translator should write the PID and a random +LABEL into the request. The program should repeat that label for +replies to ensure that the reply and request can be matched. If +receiving a non-matching reply, it MUST be written into the grant +again after a random delay to enable a matching translator to +retrieve the grant. +REQUEST: PID LABEL +GRANT: RET LABEL (RET=0 is success) +LABEL=$RANDOM + + +## multiple permission-granting programs + +The system assumes having a single permission granting program per +user. For a setup with multiple unconnected sessions per user (like +several TTYs) the permission granting program needs to coordinate +between these. diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index 81e54dff..957b9c13 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.mdwn @@ -22,16 +22,17 @@ License|/fdl]]."]]"""]] * [[internal_allocator]] +## Current Limitations -## Large Stores +### Use 64 bit time by default -The `ext2fs` translator from the upstream Hurd code base can only handle file -systems with sizes of less than roughly 2 GiB. +Extend ext2fs to support 64bit time. -[[!tag open_issue_hurd]] +## Large Stores +[[!inline pagenames=faq/2_gib_partition_limit raw=yes feeds=no]] -### Ognyan's Work +### Ognyan's Work to allow ext2 to surpass the 2 GiB limit * Ognyan Kulev, [[*Supporting Large ext2 File Systems in the Hurd*|ogi-fosdem2005.mgp]], 2005, at FOSDEM @@ -40,8 +41,8 @@ systems with sizes of less than roughly 2 GiB. * <http://kerneltrap.org/node/4429> -Ognyan's patch lifts this limitation (and is being used in the -[[Debian_GNU/Hurd_distribution|running/debian]]), but it introduces another +Ognyan's patch lifted this limitation (and is being used in the +[[Debian_GNU/Hurd_distribution|running/debian]]), but it introduced another incompatibility: `ext2fs` then only supports block sizes of 4096 bytes. Smaller block sizes are commonly automatically selected by `mke2fs` when using small backend stores, like floppy devices. diff --git a/hurd/translator/httpfs.mdwn b/hurd/translator/httpfs.mdwn index 3ac9f8ab..0ce0f30b 100644 --- a/hurd/translator/httpfs.mdwn +++ b/hurd/translator/httpfs.mdwn @@ -78,11 +78,17 @@ through a proxy server, substitute your proxies IP and port no.s - query-string and fragment support - HTTP/1.1 support - HTTP/2 support -- HTTP/3 support +- HTTP/3 support (there may exist a C library that provides HTTP/[123] + support). - Teach httpfs to understand HTTP status codes like re-directs, 404 not found, etc. - Teach httpfs to look for "sitemaps". Many sites offer a sitemap, and this - would be a nifty way for httpfs to allow grep-ing the entire site's contents. + would be a nifty way for httpfs to allow grep-ing the entire site's + contents. [[sitemaps.org|https://www.sitemaps.org]] is a great resource for + this. +- Teach httpfs to check if the computer has an internet connection at + startup and during operation. The translator causes 30 second + pauses on commands like "ls", when the internet is down. # Source diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn index ccb359cb..d864e256 100644 --- a/hurd/translator/pfinet/ipv6.mdwn +++ b/hurd/translator/pfinet/ipv6.mdwn @@ -139,7 +139,7 @@ Indeed, IPv6 now works properly, and the very machine hosting this wiki <youpi> which repo? <youpi> I don't have such commit here <gnu_srs> - http://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=2b2d7fdc42475019e5ce3eabc9c9673e3c13d89f + https://git.savannah.gnu.org/cgit/hurd/hurd.git/commit/?id=2b2d7fdc42475019e5ce3eabc9c9673e3c13d89f <gnu_srs> From which release, 2.4.x, 2.6.x? <youpi> it's very old <youpi> 2002 diff --git a/hurd/translator/procfs.mdwn b/hurd/translator/procfs.mdwn index 0228d4d4..b3753592 100644 --- a/hurd/translator/procfs.mdwn +++ b/hurd/translator/procfs.mdwn @@ -31,7 +31,7 @@ Madhusudan.C.S has implemented a new, fully functional [[procfs|madhusudancs]] f In August 2010, Jérémie Koenig [published another, new version](http://lists.gnu.org/archive/html/bug-hurd/2010-08/msg00165.html). -This can be found in <http://git.savannah.gnu.org/cgit/hurd/procfs.git/>. +This can be found in <https://git.savannah.gnu.org/cgit/hurd/procfs.git/>. Testing it is as simple as this: diff --git a/hurd/translator/tmpfs.mdwn b/hurd/translator/tmpfs.mdwn index 3d5cb74e..4db6542b 100644 --- a/hurd/translator/tmpfs.mdwn +++ b/hurd/translator/tmpfs.mdwn @@ -20,6 +20,18 @@ system|ext2fs]] on it, having a real `tmpfs` is better, as it need not deal with the additional block-level indirection layer that `ext2` (or any other disk-based file system) imposes. -`tmpfs` generally works, although it requires root permissions for file content; -see the [[discussion]] sub-pages for the past and current issues. -There is a [[!FF_project 271]][[!tag bounty]] on this task. +`tmpfs` generally works. See the [[discussion]] sub-pages for the +past and current issues. There is a [[!FF_project 271]][[!tag +bounty]] on this task. + +## How to use tmpfs + + $ settrans -ac tmp /hurd/tmpfs 1MB + $ cd tmp + $ touch file + $ cat file + + $ echo "tmpfs rocks!" > ./file + $ cat file + tmpfs rocks! + $
\ No newline at end of file diff --git a/hurd/translator/tmpfs/discussion.mdwn b/hurd/translator/tmpfs/discussion.mdwn index 72400121..d61fd796 100644 --- a/hurd/translator/tmpfs/discussion.mdwn +++ b/hurd/translator/tmpfs/discussion.mdwn @@ -107,7 +107,7 @@ License|/fdl]]."]]"""]] <antrik> mcsim: did you publish your in-progress work? <mcsim> there is a branch with working tmpfs in git repository: - http://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/defpager + https://git.savannah.gnu.org/cgit/hurd/hurd.git/log/?h=mplaneta/tmpfs/defpager <jd823592> sorry for interrupting the meeting but i wonder what is a lazyfs? <mcsim> jd823592: lazyfs is tmpfs which uses own pager diff --git a/hurd/translator/ufs.mdwn b/hurd/translator/ufs.mdwn index 4d611e95..9e9c6f75 100644 --- a/hurd/translator/ufs.mdwn +++ b/hurd/translator/ufs.mdwn @@ -19,7 +19,7 @@ and will eat your data. <Arne`> There might be a copyright problem: <nalaginrut> well, there seems BSD-4clauses in the code: - http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/ufs/alloc.c + https://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/ufs/alloc.c <Arne`> braunr, tschwinge: Do you have any info on that? 4-clause BSD and GPL on the same code are a license incompatibility… <tschwinge> Arne`: I've put it onto my (long) TODO list. diff --git a/hurd/translator/unionfs.mdwn b/hurd/translator/unionfs.mdwn index 06524f3e..31162c37 100644 --- a/hurd/translator/unionfs.mdwn +++ b/hurd/translator/unionfs.mdwn @@ -15,7 +15,7 @@ License|/fdl]]."]]"""]] *Unionfs allows you to simply union one directory or translator into another one, so you see the files of both of them side by side.* -Source repository: <http://git.savannah.gnu.org/cgit/hurd/unionfs.git/> +Source repository: <https://git.savannah.gnu.org/cgit/hurd/unionfs.git/> Right now there are some problems with syncing, so please be aware that it might not work as expected. diff --git a/hurd/what_is_an_os_bootstrap.mdwn b/hurd/what_is_an_os_bootstrap.mdwn new file mode 100644 index 00000000..b2db2554 --- /dev/null +++ b/hurd/what_is_an_os_bootstrap.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2020 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="What is an OS bootstrap"]] + +# What is an OS bootstrap? + +An operating system's bootstrap is the process that happens shortly +after you press the power on button, as shown below: + +Power-on -> Bios -> Bootloader -> **OS Bootstrap** -> service manager + +Note that in this context the OS bootstrap is not [building a +distribution and packages from source +code](https://guix.gnu.org/manual/en/html_node/Bootstrapping.html). +The OS bootstrap has nothing to do with [reproducible +builds](https://reproducible-builds.org/). |