Arch Hurd Wiki - User contributions [en]

Main Page

2019-04-14T10:18:09Z

Z3ntu: Z3ntu moved page Thanks Creation9 - Best SEO Company Ahmedabad to Main Page over a redirect without leaving a redirect: revert

== Welcome to Arch Hurd ==

The wiki is currently undergoing reconstruction.

* [[Installation Guide]]

== Get in touch ==

* IRC: #archhurd on irc.freenode.net

Main Page

2018-07-30T11:24:42Z

Z3ntu: Import from https://web.archive.org/web/20160418182215/http://wiki.archhurd.org/index.php?title=Main_Page

== Welcome to Arch Hurd ==

The wiki is currently undergoing reconstruction.

* [[Installation Guide]]

== Get in touch ==

* IRC: #archhurd on irc.freenode.net

Porting Guide

2018-07-30T11:24:42Z

Z3ntu: Import from https://web.archive.org/web/20120205063445/http://wiki.archhurd.org:80/wiki/Porting_Guide using https://wiki-conv.appspot.com/

This is a guide for porting your favorite application to Arch Hurd. Before you start read the Arch Linux wiki pages about Creating Packages and the PKGBUILD. [https://web.archive.org/web/20120205063445/http://wiki.archlinux.org/index.php/Creating_Packages][http://wiki.archlinux.org/index.php/PKGBUILD]

You can upload your PKGBUILD to the [[AUR]], if you already created one.

=== Preliminary Checks ===

First, make sure the Dev team hasn't already moved it! Check our packages list, or run a command like

<pre>pacman -Sys $PACKAGE
</pre>

Second, make sure the [[AUR]] doesn't have it.

=== Downloading files ===

There are a few ways to do this, but the end result needs to be a collection of source files on your Hurd system that [mostly] resemble the ones used to build the package for ArchLinux.

==== From ABS-Archlinux ====

This is the recommended way (for now). Download [[ABS-Archlinux]] from our AUR, then run

<pre>abs-archlinux $REPO/$PACKAGE
cp -r /var/abs-archlinux/$REPO/$PACKAGE ~/builds
cd ~/builds/$PACKAGE
</pre>

Assuming you have a folder called 'builds' in your home directory for this sort of thing.

==== By some other script ====

If for some reason that doesn't work, you need to get all the sources for the Arch Linux package. Scripts like [[this one]] may be helpful, or you can manually download the sources from the [[Arch Linux Repositories]].

=== Making sure it's Hurd-ready ===

Hurd has a few caveats that may trip you up.

==== Removing /usr/ ====

Arch Hurd does not make use of the /usr/ directory, instead placing everything under /. Most of the time, this isn't a big deal, commands like the following will help greatly:

<pre>sed -e 's|/usr||' -i PKGBUILD
sed -e 's|usr/||' -i PKGBUILD
</pre>

Repeat as necessary for other files, like the install files if your are porting an Arch Linux package. This may damage the checksums of some crucial files, however, so running
<pre>makepkg -g
</pre>
to obtain the correct checksums when finished is almost certainly necessary.

==== The Ubiquitous MAX_PATH & PATH_MAX ====

Many *nix systems define a variable that represents the number of characters a file path can have without failing. Often this is a relatively large - but still finite - number like 4,096. Hurd does not have any such restriction. Some programs, however, expect this macro to be present when compiling, and will throw errors if it does not exist. The simplest way to fix this is to edit the source of the offending files, placing

<pre>#ifndef MAX_PATH
#define MAX_PATH 4096
#endif
</pre>

somewhere close to other defines.

There is sometimes a MAXHOSTNAMELEN variable, which can be replaced with 1024.

<pre>#define MAXHOSTNAMELEN 1024
</pre>

''Note: If you're feeling particularly adventurous, the [[GNU Hurd Porting Guide]] specifies replacements for uses of these constants, for example using dynamic allocation.''

Since the source is modified, of course, you will need to do a few things:

# Create a patch. (You may find [[this]] particularly helpful.)
# Add the patch to your sources=() section of the PKGBUILD and add an appropriate entry in md5sums. One of my friends recommended me to order [[[custom writing]]]on EssaysProfessors.Com. To tell you the truth, I have never regretted my decision. The writers are real professionals and know how to write impressive work full of knowledgeable information. (An easy way to update this is to copy the output from makepkg -g after saving the changes to sources=().)
# Place a line of code in your build() function that applies the patch, something like: <pre>cd ${srcddir}/${pkgname}-${pkgver} #add this line, or something similar patch -p1 < ${srcdir}/mypatch.patch ./configure --prefix= </pre>

==== Fixing Python setup.py Installs ====

For some strange (and currently unknown) reason, python's setup.py does not respect the --root= argument. This means that any PKGBUILDs using said argument will likely produce empty packages, or fail to build at all.

To fix this, you can instead use the other arguments to setup.py to tell it to install into ${pkgdir}. For most packages, all you should need to do is change the --root= argument to --prefix. Don't forget the trailing / - the setup.py scripts are having sometimes problems without it.

<pre>python setup.py install --prefix="${pkgdir}/"
</pre>

===== Hardcoded paths =====

On a related note, some setup.py scripts may have file paths hardcoded into them, and due to the lack of --root will try to install the hardcoded files directly into your filesystem (obviously not useful when trying to build a package!). Usually, sed can help here. For example:

<pre>sed -i "s:/usr/share/:${pkgdir}/share/:g" setup.py
</pre>

added to the build() clause of your PKGBUILD will replace any instances of /usr/share/ in the setup.py with (package dir)/share, therefore ensuring the files originally bound for /usr/share will instead appear in the /share directory of your package. (Remember that Arch Hurd doesn't need or use /usr.)

Note that putting single quotes around the sed statement will cause the /usr/share/ to quite literally be replaced with "${pkgdir}/share/", which is definitely not the desired effect.

==== Other Traps ====

There are a few more, less common, problems that are known to porters. A more detailed list, with elegant suggestions for these problems can be found at [[GNU Hurd's porting guidelines]].

=== Building It ===

Once you've got all that out of the way, you can try running

<pre>makepkg -i
</pre>

The '''-i''' argument tells makepkg to automtically install the package.

==== Success ====

Congratulations! You've built a package! Now run
<pre>makepkg --source
</pre>
and submit the resultant tarball to AUR so that everyone else can enjoy the fruits of your labor.

==== Failure ====

If something goes wrong, as it probably will, don't be discouraged. You can consult other Hurd folks on the forums or IRC channels for advice, look at [[Debian's patch list]] and see if their patches will help you, or just dive right in and fix it yourself!

Sometimes, fakeroot/fakeauth can cause strange and seemingly random errors while in the final stages of making a package. If you're sure nothing could go wrong by doing so, trying to build the package as root (using --asroot with makepkg) can help as a workaround.

Alternate Installation Guide

2018-07-30T11:24:42Z

Z3ntu: Import from https://web.archive.org/web/20110902094241/http://wiki.archhurd.org/wiki/Alternate_Installation_Guide using https://wiki-conv.appspot.com/

== Creating the Partition ==

The mainly-used filesystem for the Hurd is ext2; the code is mature and seems to work reasonably well, for the most part. So we'll be using ext2 in our set up.

=== Making a qemu image ===

Qemu is currently the main way we use Arch Hurd, so if you don't have a spare partition or HDD lying around, you can use a qemu image to house your installation.

Barrucadu has created a script which can automatically create 10GB Arch Hurd qemu images containing the base and base-devel groups which you may wish to consider. It can be found [[here]]

<pre># Create the image
qemu-img create -f raw hurd.img 1GB

# Make and format partition
losetup /dev/loop0 hurd.img
fdisk /dev/loop0
losetup -d /dev/loop0

# partition should start at sector 63. Check with fdisk -u=sectors -l hurd.img
losetup -o 32256 /dev/loop0 hurd.img
mkfs.ext2 -b 4096 -I 128 -o hurd /dev/loop0 261048
# See below if you do not plan on making a 1GB image

# mount image
mount -o loop /dev/loop0 /mnt

</pre>

==== Finding the Block Number ====

If you don't plan on making a 1GB image, you will need to change the '261048' in the above command. Unfortunately, mkfs.ext2 does not do a good job of automatically calculating the correct number of blocks.

One method of calculating the number is 'number of sectors' * 512 / 'block size'. The following command parses fdisk output to compute the number:

<pre>echo `sudo fdisk -u=sectors -l /dev/loop0 \
| grep /dev/loop0p1 \
| sed 's/ \+/ /g' \
| cut -d' ' -f4` '*' 1024 / 4096 | bc

</pre>

If this does not work, examine the get_hypermetadata error you will find when attempting to boot, go back to this section, and replace the number with 'disk size reported' / 'block size'.

Selman has recommended using qemu-nbd to eliminate this step. See [[Another_Installation_Guide]].

=== Using a real partition ===

So, you have a partition or HDD sitting around, and have decided to install Arch Hurd on it. Good! However, if you're planning to boot off of this device, note that the Hurd only supports PATA and SCSI disks currently, though you can use a SATA disk if you'll be running it in an emulator, or if your BIOS supports putting SATA drives into legacy mode, which some do.

I shall assume your partition has been created, so we'll jump straight to the end.

<pre># Note that this command is slightly different to the one for a qemu image
mkfs.ext2 -b 4096 -I 128 -o hurd /dev/sdXY

# Mount partition
mount /dev/sdXY /mnt

</pre>

Obviously, substituting '''X''' and '''Y''' for the appropriate values.

Installing Arch Hurd to the image can now be done with either pacman (the preferred method) or using the crosshurd scripts.

== Installing ==

=== Pacman ===

To do this you will first need to acquire a copy of pacman, if not installing from within Arch Linux. The simplest way to do this is to download the latest version of pacman from the Arch Linux mirrors and extract it. You will then need a pacman.conf file suitable for Arch Hurd, such as this:

<pre>[options]
RootDir = /mnt/
DBPath = /mnt/var/lib/pacman/
CacheDir = /mnt/var/cache/pacman/pkg/
LogFile = /mnt/var/log/pacman.log
SyncFirst = pacman
XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u
CleanMethod = KeepCurrent

[core]
Server = [[http://files.archhurd.org/repo/core/]]

[extra]
Server = [[http://files.archhurd.org/repo/extra/]]
</pre>

''note: when your host is 64bit, use in the pacman.conf ARCHITECTURE = i686''

Now that you have both pacman and a configuration file, you can continue to install with pacman. This process is similar to [[installing Arch Linux from another Linux distro]]. Now, assuming your pacman configuration is named ./pachurd.conf:

<pre>mkdir /mnt/var/lib/pacman -p
pacman --config pachurd.conf -Sy

pacman --config pachurd.conf -S base

</pre>

In addition, if you are going to be building packages, you may as well install the base-devel group now.

<pre>pacman --config pachurd.conf -S base-devel

</pre>

Finally, copy the grub images to the correct location (ie: /boot)

<pre>cp -a /mnt/lib/grub/i386-pc/* /mnt/boot/grub/

</pre>

=== Crosshurd ===

This method was used to install Arch Hurd before it was easy, or even possible, to do so using pacman. As such, it is now deprecated and should not be used unless you have a specific reason (such as needing to build for something other than i686). Firstly you will need to acquire the latest version of the crosshurd scripts, which is currently [[crosshurd-20100312.tar.bz2]].

<pre>mkdir crosshurd
tar xvf /path/to/crosshurd-20100312.tar.bz2

# Now you need to set important variables in the prepare script:
# $ROOT needs to be set to where you extracted the tarball (ie: the current directory)
# $HOST needs to be set to your current system (i686-pc-linux-gnu for i686, x86_64-unknown-linux-gnu for x86_64).
# Note: currently building the cross-toolchain fails on x86_64.
# $TARGET needs to be set to what you're building for. You shouldn't need to change this.
# You can also edit the version numbers of the programs used in the cross-compile, but the default versions are known to work.
nano ./scripts/prepare
sed -i -e "/source.*pkgver/i \\
source ./scripts/prepare" -e 's/$SRCDIR/$SOURCE_DIR/g' \
-e 's/$DIFFUTILS_VER/$DIFF_VER/g' \
-e 's/$XZUTILS_VER/$XZ_UTILS_VER/g' scripts/get-sources
source ./scripts/get-sources
source ./scripts/makeall

</pre>

You'll then need to move the built system to /mnt. The rest of this installation guide will, however, refer exclusively to a system installed using pacman.

== Configuring the system ==

If you are familiar with Arch Linux configuration, you will find this section very familiar.

=== /etc/rc.conf ===

Like Arch Linux, Arch Hurd uses a main configuration file called /etc/rc.conf containing a range of configuration information used by the initscripts when starting the system. The default values for all variables are safe to use.

==== LOCALIZATION Section ====

* '''LOCALE=''': This sets the system locale, which is used by i18n-aware applications, available locales can be listed by running '''locale -a'''.
* '''USECOLOR=''': If you have a colour console, and want to use colours during the system start up, set this to yes.

<pre>LOCALE="POSIX"
USECOLOR="yes"

</pre>

==== CONSOLE Section ====

* '''CONSOLEDISPLAY=''': Display driver used for the console client, available drivers are vga and ncursesw (which doesn't currently work on Arch Hurd).
* '''CONSOLEFONT=''': Full path to the font to be used in the VGA console.
* '''CONSOLEMOUSE=''': The following three variables are a little superfluous, as there is only one driver for each. "pc_mouse" if you want to use the mouse driver.
* '''CONSOLEKBD=''': "pc_kbd" if you want to use the US keyboard (other layouts not yet supported) driver.
* '''CONSOLESPEAKER=''': "generic_speaker" if you want to use the speaker driver.
* '''CONSOLEOPTS=''': Additional options to pass to the console client, see '''console --help''' for more information.

<pre>CONSOLEDISPLAY="vga"
CONSOLEFONT=
CONSOLEMOUSE=
CONSOLEKBD="pc_kbd"
CONSOLESPEAKER="generic_speaker"
CONSOLEOPTS=

</pre>

==== NETWORKING Section ====

* '''HOSTNAME=''': The hostname of your computer.

<pre>HOSTNAME="myhost"

</pre>

==== DAEMONS Section ====

This is simply an array listing daemons to start up at boot.

<pre>DAEMONS=(syslog-ng !crond)

</pre>

A daemon can be started in the background by prefixing it with an '''@''', and can not be started at all by prefixing with a '''!'''.

All Arch Hurd daemons, as on Arch Linux, reside in /etc/rc.d.

=== /etc/fstab ===

The filesystems table file contains a list of all filesystems which are present in the system and how they are to be mounted. This file is most commonly used by the '''mount''' command. For example, the '''mount -a''' command mounts all filesystems which do not have the '''noauto''' option set.

==== Example /etc/fstab ====

This is for a system with two partitions on one HDD, the first partition being an ext2 filesystem containing / and the second being a swap partition:

<pre># <file system> <dir> <type> <options> <dump> <pass>
/dev/hd0s1 / ext2 rw 1 1
/dev/hd0s2 none swap sw 0 0

</pre>

* '''<file system>''' denotes the device node or file which is to be mounted. For most cases, this field will contain a device node in /dev.
* '''<dir>''' denotes where the device will be mounted. Note that, for the swap partition, this is not an actual location but a keyword.
* '''<type>''' denotes the type of the filesystem. The Hurd supports only ext2 at the moment.
* '''<options>''' denotes any special options to be used when mounting the partition, see '''man mount''' for a detailed explanation of these.
* '''<dump>''' is used by the '''dump''' command, a backup utility.
* '''<pass>''' is used by '''fsck''' to determine the order in which filesystem checks are to be done at boot. The root partition should have a <pass> of 1, and all other partitions 0 or 2, with 0 meaning that the partition does not need to be checked.

However, you should know that an /etc/fstab file is nearly completely useless on Hurd. In fact, I only have my swap partition in mine, so I can use '''swapon -a'''. The reason for this is [[translators]]. You can, and I have, 'mount' all of your partitions with '''settrans''', in such a way that these 'mounts' will persist between reboots. Translators are very powerful tools.

==== Device Naming ====

The Hurd uses a different naming scheme for block devices than Linux, devices are named in the form:

* '''hdX''': PATA drive.
* '''hdXsY''': partition on a PATA drive.
* '''sdX''': SCSI drive.
* '''sdXsY''': partition on a SCSI drive.

The numbering for '''X''' starts from 0, and the numbering for '''Y''' starts from 1. Some examples of Linux devices and their corresponding Hurd devices follow:

* '''hda2''' becomes '''hd0s2'''
* '''hdb''' becomes '''hd1'''
* '''hdd4''' becomes '''hd3s4'''

== Installing GRUB ==

Installing GRUB is as simple as for any other distro; boot with a grub floppy and set up the MBR. So, firstly, get a GRUB floppy, [[such as this one]], then:

<pre># Unmount
umount /mnt
losetup -d /dev/loop0 # Only needed if you used a qemu image.

# Note: If networking doesn't work make sure model=pcnet is set
qemu -boot a -fda grub.img -hda hurd.img -net nic,vlan=1,model=pcnet -net user,vlan=1
# if using a real partition, use the device node rather than 'hurd.img'

</pre>

If you installed using pacman, the commands you need are simple:

<pre>root (hd0,0)
setup (hd0)

</pre>

At this point, GRUB has been set up and when you reboot, you should be presented with the menu.

== Swap ==

You will probably want some swap space, and the easiest way to do this if you used a qemu image is to create another HDD image and use the entire thing as swap rather than create a swap partition on it.

<pre>qemu-img create -f raw swap.img 1GB
mkswap swap.img

</pre>

When you next boot, tell qemu that hdb is your swap image, and enable the swap in Hurd.

<pre>qemu -hda hurd.img -hdb swap.img -net nic,vlan=1,model=pcnet -net user,vlan=1

# After booting and creating the device node:
swapon /dev/hd1

</pre>

If you used a real partition or disk, you will probably want to have an equally real swap partition. If so, simply make a swap partition and pass that to qemu as hdb, rather than an image file.

== First Boot ==

All there is left to do now is to setup the devices, and start the network. After booting:

<pre># Create the required device nodes
cd /dev
MAKEDEV hd0 hd0s1 # Et cetera

# For qemu networking:
touch /servers/socket/2
settrans -afgp /servers/socket/2 /hurd/pfinet -i eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0

</pre>

=== Adding a User ===

It is best not to work as root whilst doing your everyday things, as a slight mistake can destroy your system. Thus, you should create a new user and begin using it. This can be done quite simple:

<pre>adduser

</pre>

If, however, you prefer to automate this process (or simply find adduser slow) you can use '''useradd''':

<pre>useradd -m -G [groups] -s [shell] [username]
passwd [username]

</pre>

* '''-m''': Creates the user home directory as '''/home/username'''
* '''-G''': A list of supplementary groups which a user is a member of, each group must be separated by a command and no spaces.
* '''-s''': The path of the users login shell.

Useful groups include:

* '''users''': The group to which all users belong
* '''wheel''': Commonly a group given unfettered access to the '''sudo''' command.

Thus, for a typical system, one may issue this command:

<pre>useradd -m -G users,wheel -s /bin/bash archie

</pre>

=== Setting up Sudo ===

'''sudo''' is a common privilege-escalation utility for UNIX systems which allows a user to run a command as another user, most commonly root. Sudo can be found in the core repository, and so can be installed quite simply with pacman:

<pre>pacman -S sudo

</pre>

To make a user a sudoer (ie: give them sudo access), you must run the '''visudo''' command as root. If you are unfamiliar with vim, you can specify a different editor by setting the EDITOR environmental variable.

<pre># For example, to use nano:
EDITOR=nano visudo

</pre>

To give a user the ability to run any command with sudo, add a line such as this:

<pre>[username] ALL=(ALL) ALL

</pre>

To give a group the ability, add a line such as this:

<pre>%[groupname] ALL=(ALL) ALL

</pre>

You ''must'' edit /etc/sudoers with visudo, otherwise annoyances can occur. Like rendering root unusable.

=== /dev/random and /dev/urandom ===

As you will see when you try to run anything requiring a source of random data, you have no /dev/random and /dev/urandom devices. We don't set up these devices by default for you because some users might want to use a different random translator for /dev/{u,}random, which would conflict with an automatic set-up despite the translator programs themselves not conflicting at all.

Assuming you want to use the random-64 package, which is in the base group, for your source of randomness, the following three commands can enable the translators:

<pre>settrans -c /dev/random /hurd/random --secure
settrans -c /dev/urandom /hurd/random --fast
chmod 0644 /dev/random /dev/urandom

</pre>

=== A note on using HDDs ===

If you have used a full HDD for your Hurd installation it is perfectly fine to boot it using qemu like so:

<pre>qemu -hda /dev/sdX -net nic,vlan=1,model=pcnet -net user,vlan=1

</pre>

If your user has write permission to the device nodes, you can use an entire HDD like that. Of course, within the Hurd your partitions will be named differently. Refer to the section on partition naming for more details.

== OpenSSH ==

openssh is currently is the ''testing'' repository. Follow the instructions [[on the official Arch wiki]] (don't forget to add sshd: ALL to /etc/hosts.allow).

To be able to log in as a normal user, you will need to add the following directive to /etc/ssh/sshd_config

<pre>UsePrivilegeSeparation no

</pre>

And to get a console when logging in you will have to create some nodes in /dev for the ptys. Running

<pre>cd /dev && MAKEDEV ptyp

</pre>

will create nodes named ptyp0 through ptypv.

=== Logging into a Qemu VM ===

The qemu virtual machine, as started in a previous section, runs in an isolated network that cannot be accessed directly from the host machine. However, ssh can be used to create a tunnel to forward connections back to the VM.

First you need to create an alias of the loopback device and give it a different address:

<pre>host# ifconfig lo:0 172.20.0.1

</pre>

And start a ssh server at the host:

<pre>host# /etc/rc.d/sshd start

</pre>

Then connect to the host's server to establish the forwarding:

<pre>hurd# ssh -R 2222:127.0.0.1:22 user@172.20.0.1

</pre>

Finally the ssh server at the qemu virtual machine may be contacted through the local port 2222 at the host:

<pre>host# ssh -p 2222 user@127.0.0.1

</pre>

=== Restarting the server ===

Please note that there is currently a problem when trying to restart the sshd server because the server is not correctly killed. To do it, follow these steps :

Find the PID of the sshd server.

<pre>cat /var/run/sshd.pid

</pre>

Kill the process

<pre>kill -9 <PID>

</pre>

Remove the sshd.pid file and start the server.

<pre>rm /var/run/sshd.pid
/etc/rc.d/sshd start

</pre>

== Troubleshooting ==

=== Boot halts and complains about a missing /dev/console ===

Whilst undoubtly a scary thing to encounter on your first excursion into Hurd, this can be fixed with a few simple commands. If your system is currently read-only, fix that:

<pre>fsysopts / --writable

</pre>

Then create the console device:

<pre>cd /dev
settrans -cg console
chown root console
chmod 600 console
settrans console "/hurd/term /dev/console device console"

</pre>

=== "cannot make pipe for command substitution" ===

Something is wrong with your pflocal server, again, ensure the system is writable:

<pre>fsysopts / --writable

</pre>

And restart the translator:

<pre>settrans -acp /servers/socket/1 /hurd/pflocal

</pre>

=== "login: Invalid password" ===

If '''login''' complains that you have given an invalid password before it even asks you to enter one, well, I have no idea why it does that. The only solution is to unset the password for the account you're trying to log in to (watch this space for a better solution...). So, firstly, reboot to single-user mode (append "-s" flag to GNU Mach command line in GRUB), then:

<pre>fsysopts / --writable # If read-only
passwd -d $user
reboot

</pre>

Obviously, this isn't a very good solution. When I figure out how to properly fix it, this will be updated.

=== Everything freezes after a while ===

Believe me, we're as confused about this as you. Everything seems to freeze if nothing gets sent to STDOUT for a while so, start up something that generates continuous output in one of your TTYs. We like

<pre>vmstat 5

</pre>

Retrieved from "[[http://wiki.archhurd.org/wiki/Alternate_Installation_Guide]]" [[Category]]: [[Guides]]

Xorg

2018-07-30T11:24:41Z

Z3ntu: Import from https://web.archive.org/web/20120205063543/http://wiki.archhurd.org:80/index.php?title=Xorg&action=edit

== Support ==

Xorg was successfully tested on :

* qemu
* VMware
* VirtualBox
* Actual Hardware Installations

== Installing ==

Xorg is available in extra, and so can be installed as simply as anything else:

pacman -Sy xorg xf86-input-keyboard xf86-input-mouse xf86-video-vesa

You will also need to add "-c" to the CONSOLEOPTS variable in your /etc/rc.conf file. While you are editing rc.conf you also need to set a driver for CONSOLEMOUSE (usually pc_mouse). Once you have done this, reboot.

You should now see a new directory, /dev/cons. This contain the console mouse and keyboard interfaces, but Xorg expects those device nodes to be in different places. If you use a xorg.conf file, you can simply edit it to point to those devices, if not:

ln -s /dev/cons/kbd /dev/kbd
ln -s /dev/cons/mouse /dev/mouse

Additionally, if you wish to run X terminal emulators as a normal user, you need to create the ptyp device:

cd /dev
MAKEDEV ptyp

Now your system is ready to run Xorg.

== .xinitrc ==

The most convenient way to run Xorg is to set up a .xinitrc file starting various programs and suchlike for you when you start the X server. A simple example below, saved as ~/.xinitrc, is sufficient to start openbox:

#!/bin/bash

exec openbox

The .xinitrc file is executed by whatever interpreter you specify (even python, if you so desire), so it can contain whatever logic or commands you like, for example:

#!/bin/bash

if <nowiki>[[ "$WM" == "" ]]</nowiki>; then
echo "Starting openbox..."
exec openbox
else
echo "Starting $WM..."
exec $WM
fi

== Starting X ==

It is advisable to install a window manager, such as openbox, which is currently in the xorg repository.

pacman -S openbox

Once you have your .xinitrc (or whatever you're using) and your window manager set up, simply start X:

startx -- -retro

[[Category:Guides]]

Installation Guide

2018-07-30T11:24:41Z

Z3ntu: Import from https://web.archive.org/web/20160730194855/http://wiki.archhurd.org/index.php?title=Installation_Guide&action=edit

__NOTOC__
This guide is for installing an configuring Arch Hurd using the LiveCD.

__TOC__

= Part I: Installing the base system =

== A note on hardware support ==
Currently GNU Mach does not support SATA, USB, sound, or wireless networking. If you require one of these to use your computer, you will be unable to install Arch Hurd. However, there is currently work on porting DDE linux26 to GNU Mach, which would bring support for hardware drivers from Linux 2.6.29.

== Obtaining the LiveCD ==
The latest version of the Arch Hurd livecd can be found [http://files.archhurd.org/livecd/i686-core-latest.iso here].

* The LiveCD can be used to install an Arch Hurd base system, this contains only what is necessary to run Arch Hurd and so, for example, lacks a graphical user interface.
* There is currently no option to install from the official repositories, the package cache on the CD is used instead. This can result in your system being out-of-date immediately after installing.
* There are currently some bugs in the installer; neither locale-gen or grub-install are run and must be performed manually by the user (after booting for the first time, and by using a GRUB disk, such as the Arch Hurd ISO).

After downloading the LiveCD burn the ISO file to a blank CD.

== Booting the live environment ==
Insert the CD and boot it. You may need to edit your BIOS settings by pressing a key during the boot process. At this point, the GRUB menu should be displayed. You will need to edit the GRUB configuration by pressing e, and change the root device to that of your CD drive.

* If your CD drive is the master on the primary IDE bus, it will be called '''hd0'''
* If your CD drive is the slave on the primary IDE bus, it will be called '''hd1'''
* If your CD drive is the master on the secondary IDE bus, it will be called '''hd2'''
* If your CD drive is the slave on the secondary IDE bus, it will be called '''hd3'''

Most computers do not have more than two IDE buses, though if you do you should be able to easily figure out the appropriate device name.

After booting, you will be presented with some instructions at the login prompt. To log in, enter '''login root'''. The root account has no password. Additionally, this installation guide can be found at '''/arch/guide''', so, to read this guide, change to virtual console 2 by pressing Alt+F2 and invoke less by typing at the prompt:

less /arch/guide

You can switch back to virtual console 1 with Alt+F1, and refer to the guide at any point in the installation.

=== Translators ===
After booting, you will need to set up translators for any hard drives and partitions you wish to make use of during the installation process. You do this by changing to the /dev directory and using the MAKEDEV script. Hard drives in the Hurd are named, as previously explained, in a '''hdX''' format, where '''X''' is a zero-based index number for the position on the system IDE buses. For partitions, the naming scheme is '''hdXsY''', where '''Y''' is a one-based index for the partition on the hard drive.

For example, to create a translator for the master hard drive on the primary IDE bus, which has two partitions, and the slave on the primary IDE bus, you would do this:

cd /dev
MAKEDEV hd0 hd0s1 hd0s2 hd1

These translators will be copied over to your finished system after the installation is complete so you do not have to do this again.

== Installation Process ==
In the console, enter '''/arch/setup''' to launch the interactive installer which will be used to install your Arch Hurd base system.

=== Prepare Hard Drives ===
'''Partitioning can destroy data, ensure you have a suitable backup!'''

Additionally, partitioning can be done using another partitioning tool if you so desire, if that is the case skip the partitioning stage and go straight to formatting the partitions and setting mount points.

==== Partition hard drives ====
At this stage you will be presented with a list of hard drives and be given the option of partitioning each of them with cfdisk. Below is what I would recommend for a partitioning scheme:
* '''/''' (root) The root filesystem contains all installed programs, their data, and is the top of the filesystem hierarchy. All other filesystems are mounted relative to root, thus, the root filesystem must contain suitable files to be able to boot the system.
* '''/home''' User-specific configuration and data is stored in the home directory, and having a separate partition is useful if sharing between distributions. However, note that the Hurd only fully supports ext2 for now.
* '''swap''' A partition which the GNU Mach kernel pages data to if the RAM is full. Having swap is greatly recommended on the Hurd, as it massively increases stability.

It is obviously dependent on your needs how big you make the partitions, but for most purposes a 20GB root partition should be enough.

After partitioning, you will be prompted to reboot, as GNU Mach currently can not detect partition table changes whilst running. After rebooting, resume the installation at the next step, formatting partitions.

==== Format partitions ====
The Hurd currently supports a few filesystems (ext2, UFS, iso9660, and Linux swap), thus the only choices offered in this section are for ext2 and swap. If you are going to be sharing a /home partition with another distribution, this is obviously not ideal as the Linux kernel supports a vast number of filesystems.

Formatting a partition '''will''' cause data loss, so double-check before you do so.

==== Choose mount points ====
At minimum, you should have a root partition, for which the mount point is '''/'''. It is recommended you also have a swap partition, for which the mount point will be '''swap''' and, if you used the recommended partitioning scheme in the partitioning section, you will also have a third partition mounted at '''/home'''.

=== Select Packages ===
After preparing the hard drives, you will need to select the packages you wish to install. All of the packages you can choose between are in the '''base''' and '''base-devel''' groups. Thus, you will almost certainly need them all at some point. It is recommended to simply install all of them unless you have some particular need.

Additionally, it is possible that some packages, even if de-selected, will be pulled in as dependencies for other packages which you have selected.

After selecting the packages, continue with the next step of the installation, installing the system.

=== Install System ===
'''Note: you need to mount your new root partition manually in the 2010-06-05 LiveCD before running this step. The command is: settrans -a /mnt /hurd/ext2fs /dev/hdXsY, where X and Y are the appropriate numbers.'''

After confirming that you wish to commit to the installation, the installation will begin. In this stage a number of things happen

* All your partitions are mounted and the /etc/fstab file is generated
* The package files are copied from the LiveCD to the package cache in your new installation, in '''/var/cache/pacman/pkg'''
* The packages themselves are installed
* Some basic translators are set up in '''/dev''', including ones for all of your partitions and hard drives which you set up at the beginning of the installation, after booting the LiveCD.

=== Configure System ===
If you are familiar with Arch Linux configuration, you will find this section very familiar.

==== /etc/rc.conf ====
Like Arch Linux, Arch Hurd uses a main configuration file called /etc/rc.conf containing a range of configuration information used by the initscripts when starting the system. The default values for all variables are safe to use.

==== LOCALIZATION Section ====
* '''LOCALE'''=: This sets the system locale, which is used by i18n-aware applications, available locales can be listed by running '''locale -a'''.
* '''USECOLOR'''=: If you have a colour console, and want to use colours during the system start up, set this to yes.

LOCALE="POSIX"
USECOLOR="yes"

==== CONSOLE Section ====
* '''CONSOLEDISPLAY'''=: Display driver used for the console client, available drivers are vga and ncursesw (which doesn't currently work on Arch Hurd).
* '''CONSOLEFONT'''=: Full path to the font to be used in the VGA console.
* '''CONSOLEMOUSE'''=: The following three variables are a little superfluous, as there is only one driver for each. "pc_mouse" if you want to use the mouse driver.
* '''CONSOLEKBD'''=: "pc_kbd" if you want to use the US keyboard (other layouts not yet supported) driver.
* '''CONSOLESPEAKER'''=: "generic_speaker" if you want to use the speaker driver.
* '''CONSOLEOPTS'''=: Additional options to pass to the console client, see console --help for more information.

CONSOLEDISPLAY="vga"
CONSOLEFONT=
CONSOLEMOUSE=
CONSOLEKBD="pc_kbd"
CONSOLESPEAKER="generic_speaker"
CONSOLEOPTS="-c"

==== NETWORKING Section ====
* '''HOSTNAME'''=: The hostname of your computer.
HOSTNAME="myhost"

==== DAEMONS Section ====
his is simply an array listing daemons to start up at boot.

DAEMONS=(syslog-ng !crond)

A daemon can be started in the background by prefixing it with an '''@''', and can not be started at all by prefixing with a '''!'''.

All Arch Hurd daemons, as on Arch Linux, reside in /etc/rc.d/.

==== /etc/pacman.conf ====
The pacman configuration file contains repositories, amongst other things, which you can access packages from. For most users, this configuration file is fine as it is, so you do not need to do anything. However, if you wish to use the Arch Hurd testing repository find and uncomment this section of the configuration:

#[testing]
## Add your preferred servers here, they will be used first
#Include = /etc/pacman.d/mirrorlist

The '''testing''' repository must be above the '''core''' and '''extra''' repositories in the configuration, as package names can (and will) conflict.

==== /etc/pacman.d/mirrorlist ====
The pacman mirrorlist contains a list of servers to download packages from. Bear in mind that files.archhurd.org is throttled when making your choice.

Most of the mirrors update at least four times a day, so they should all be fairly up-to-date.

==== /etc/fstab ====
The filesystems table file contains a list of all filesystems which are present in the system and how they are to be mounted. This file is most commonly used by the '''mount''' command. For example, the '''mount -a''' command mounts all filesystems which do not have the '''noauto''' option set.

==== Example /etc/fstab ====
This is for a system with two partitions on one HDD, the first partition being an ext2 filesystem containing / and the second being a swap partition:

# <file system> <dir> <type> <options> <dump> <pass>
/dev/hd0s1 / ext2 defaults 1 1
/dev/hd0s2 none swap defaults 0 0

* '''<file system>''' denotes the device node or file which is to be mounted. For most cases, this field will contain a device node in /dev.
* '''<dir>''' denotes where the device will be mounted. Note that, for the swap partition, this is not an actual location but a keyword.
* '''<type>''' denotes the type of the filesystem. The Hurd supports a variety of filesystems.
* '''<options>''' denotes any special options to be used when mounting the partition, see man mount for a detailed explanation of these.
* '''<dump>''' is used by the '''dump''' command, a backup utility.
* '''<pass>''' is used by '''fsck''' to determine the order in which filesystem checks are to be done at boot. The root partition should have a <pass> of 1, and all other partitions 0 or 2, with 0 meaning that the partition does not need to be checked.

However, you should know that an /etc/fstab file is nearly completely useless on Hurd. In fact, I only have my swap partition in mine, so I can use '''swapon -a'''. The reason for this is translators. You can, and I do, 'mount' all of your partitions with '''settrans''', in such a way that these 'mounts' will persist between reboots. Translators are very powerful tools.

==== /etc/locale.gen ====
This configuration file contains available locales on your Arch Hurd system. For example, to add the UK and US English locales, you would append the following to the configuration:

en_GB ISO-8859-1
en_GB.UTF-8 UTF-8

en_US ISO-8859-1
en_US.UTF-8 UTF-8

The LiveCD currently does not generate the locales for you after editing this configuration file, you must do so after booting your installation, by running the command locale-gen.

==== /etc/hosts ====
This configuration file acts as a simple local DNS server (sort of), it associates IP addresses with names, and should, at a minimum, contain a line like this:

127.0.0.1 localhost.localdomain localhost '''hostname'''

Where '''hostname''' is the hostname you specified in '''/etc/rc.conf'''. This is required for program compatability. A popular use of the hosts file is for local networked computers, for example:

10.1.1.1 router
10.1.1.2 fileserver

==== /etc/resolv.conf ====
The resolver is a set of functions in glibc which provide access to the domain name system (DNS). The main function of the DNS is to translate hostnames into IP addresses (like the hosts file), and the resolver configuration file contains information that is read by the resolver when it is invoked. Commonly, this information is nameservers. For example, to use the OpenDNS nameservers, add the following to the file:

nameserver 208.67.222.222
nameserver 208.67.220.220

==== Root Password ====
Set a root password, as you will use this to log in after booting your system.

=== Exit Install ===
At this point, your system is as installed and configured as the LiveCD can make it, unfortunately this does not include installing GRUB due to problems with the Arch Hurd GRUB package. At this point you should exit the installation program and reboot into your new installation (after installing GRUB with appropriate media).

==== Installing with a GRUB boot disk ====
Installing GRUB is easy after using the LiveCD as the configuration and binary files are all in the appropriate locations. To install GRUB from the Arch Hurd installation disk, open the command line by pressing c and enter the following commands:

find /boot/gnumach
root (hd0,0)
setup (hd0)

Obviously, change '''(hd0,0)''' and '''(hd0)''' if the value of the find command doesn't point to those devices.

= Part II: Configuration and Updating =
Well done, you now have (presumably) a booting Arch Hurd base system! From here you can configure and install things to your hearts content and turn your Arch Hurd system into whatever you like. Log in using the root account and password you specified during the system configuration stage. If you did not specify a password, just press enter after typing in '''login root'''.

== Configuring the network ==
The Hurd currently has no support for wireless networking, but most ethernet controllers should work. Networking on the Hurd is managed by a '''translator''', these are magical Hurd-thingies that implement most of the really useful functionality (like mounting partitions), the good thing about translators is that you don't have to re-create them every time you boot (usually), so you only need to configure your network once, and it will work forever!

Translators attach themselves to nodes in the filesystem, and then work by intercepting requests to that node and acting accordingly. So first we need to give our network translator somewhere to live:

touch /servers/socket/2

Now, you need to start the appropriate translator, we'll be using the pfinet translator:

settrans -fgap /servers/socket/2 /hurd/pfinet -i '''INTERFACE''' -a '''ADDRESS''' -g '''GATEWAY''' -m '''NETMASK'''

* INTERFACE is the network interface you'll be using, this probably should be eth0.
* ADDRESS is the IP address, currently the Hurd doesn't support DHCP so you need to enter these values yourself.
* GATEWAY is the address of your default gateway (router).
* NETMASK is the network mask for your subnet, probably 255.255.255.0

Now, let us examine this magical command:
* '''settrans''' is the command to create a translator.
* '''-fgap''' deletes any active or passive translators on the node ('''-f''' and '''-g''' options), and creates a new active and passive translator ('''-a''' and '''-p''' options). Active translators begin working immediately, whereas passive ones start up when they receive a request.
* '''/servers/socket/2''' is where the translator will attach itself.
* '''/hurd/pfinet''' is the name of the translator.
* And everything after that is options to the specific translator.

As a passive translator was created (as well as an active one), networking will work every time you boot. This is a big factor in why we didn't port most of the networking stuff from Arch Linux's rc.conf to Arch Hurd.

== Package Management in Arch Hurd ==
Arch Hurd, like Arch Linux, uses the '''pacman''' package manager, which in turn uses '''libalpm'''. Thus, if you have used Arch Linux, you can use Arch Hurd (as far as package management goes). Some basic commands are as follows:

pacman -S '''pkgname''' : install ''pkgname''.
pacman -Ss '''query''' : search the repositories for ''query''.
pacman -R '''pkgname''' : uninstall ''pkgname''.
pacman -Rs '''pkgname''' : uninstall ''pkgname'', removing all of its dependencies.

More useful parameters can be found in the manpage. However, we're going to focus on one particular set of options here, the command to update your system:

pacman -Syu

* '''-S''' specifies that this is a sync operation.
* '''-y''' synchronises the locale package database with the repositories.
* '''-u''' installs any package upgrades.

If you leave out the -u option, you can synchronise the database with '''pacman -Sy''', and then list available updates with '''pacman -Qu'''. You should update your system before installing any packages, as your packages are likely to be out of date, and mixing old and new packages is not recommended.

=== Repositories ===
Arch Hurd has three main repositories, a list of mirrors can be obtained here, these are:

==== core ====
Core contains what is required to get an Arch Hurd base system up and running. It is the source of the packages for the LiveCD installation, and all packages in core can only depend on other packages in core. Core is intended to be a stable repository from which you can construct a very basic Hurd system and from there expand it to your needs.

==== extra ====
Extra contains other packages, that aren't '''needed''', but are useful. Xorg, for example, lives in extra. Packages in extra may depend on packages in either core or extra.

==== testing ====
Testing contains updates for the core repository, and any other packages which the developers feel need testing before being pushed to the main repositories. All updates to core '''must''' go through testing first, so we can (hopefully) catch any show-stopping bugs before they hit the main repo.

==== AUR (Arch User Repository) ====
Finally, the AUR. This is not a binary repository, but rather a collection of user-submitted build scripts and patches to build packages which are not maintained in the official repositories. We make no guarantee of quality or functionality of packages in the AUR.

== Adding a User ==
It is best not to work as root whilst doing your everyday things, as a slight mistake can destroy your system. Thus, you should create a new user and begin using it. This can be done quite simply as in most other distributions, using either the '''adduser''' (easier to do manually) or '''useradd''' (easier to automate) commands:

adduser

If, however, you prefer to automate this process (or simply find adduser slow) you can use useradd:

useradd -m -G [groups] -s [shell] [username]
passwd [username]

* '''-m''': Creates the user home directory as /home/username
* '''-G''': A list of supplementary groups which a user is a member of, each group must be separated by a command and no spaces.
-s: The path of the users login shell.

Useful groups include:

* '''users''': The group to which all users belong
* '''wheel''': Commonly a group given unfettered access to the sudo command.

Thus, for a typical system, one may issue this command:

useradd -m -G users,wheel -s /bin/bash archie

== Installing and Configuring sudo ==
'''sudo''' is a common privilege-escalation utility for UNIX systems which allows a user to run a command as another user, most commonly root. Sudo can be found in the core repository, and so can be installed quite simply with pacman:

pacman -S sudo

To make a user a sudoer (ie: give them sudo access), '''you must run the visudo command as root'''. If you are unfamiliar with vim, you can specify a different editor by setting the '''EDITOR''' environmental variable. For example, to use nano:

EDITOR=nano visudo

To give a user the ability to run any command with sudo, add a line such as this:

[username] ALL=(ALL) ALL

To give a group the ability, add a line such as this:

%[groupname] ALL=(ALL) ALL

You '''must''' edit /etc/sudoers with visudo, otherwise sudo can be rendered unusable, which would be quite annoying.

= Part III: Let's play with the Hurd =
Well done, now you have a bootable and configured Arch Hurd system ! I presume you wanna do something with it ? Contact us on irc, we have a lot of work for you :)

== Troubleshooting ==
Need help? Look at [[troubleshooting]] or [[tips]] pages, or contact us on irc (#archhurd & #archhurdfr on freenode)

[[Category: Installation]]

DDE

2018-07-30T11:24:40Z

Z3ntu: Import from https://web.archive.org/web/20110902094011/http://wiki.archhurd.org/index.php?title=DDE&action=edit

DDE is a universal interface for drivers that makes it easy for systems without many native drivers (such as the hurd) to use drivers from systems with many native drivers (like Linux 2.6). These drivers can run in userspace, which has some interesting implications.

=== Overview ===

Porting DDE to the Hurd was originally the work of [http://www.gnu.org/software/hurd/user/zhengda.html Zheng Da]. His work is currently in the [http://git.savannah.gnu.org/cgit/hurd/incubator.git/log/?h=dde incubator] git repository of the hurd. See [http://www.gnu.org/software/hurd/dde.html GNU's DDE page] for a more in-depth dicussion.

=== From a User Perspective ===

For the user, this means that, once we have completed the implementation of DDE, Hurd will support a wider variety of hardware, using Linux 2.6's drivers. You need to do only three things to get DDE running:
<ul><li>Download a modified Gnumach <li>Download the DDE drivers<li>Start the translators!</ul>

==== Gnumach ====

The normal gnumach that is distributed with Arch Hurd cannot use DDE's user level drivers. A build of gnumach from the master-userleveldrivers git branch is in [extra], however, so run <pre>pacman -S gnumach-userleveldrivers</pre>!Warning! This kernel overwrites the normal gnumach, and has forfeited some kernel-side drivers for DDE ones, such as the pcnet32 driver required to access the internet from Qemu. Thus, either back up your gnumach package (see /var/cache/pacman/pkg/) or make sure you install your ethernet drivers at the same time, otherwise, if something goes very wrong, your system may not be able to connect to the internet.

==== Drivers ====

Drivers that use DDE are available in [testing], and may come to [extra] soon. To get them, run <pre>pacman -S dde</pre>. The ne2k driver has been tested to have internet connection!

==== Using ====

These commands have been tested to use the driver dde_ne2k with gnumach-userleveldrivers under QEMU

===== Gnumach =====

While you are still using gnumach from [core], install the packages you will need

<pre>pacman -S gnumach-userleveldrivers dde</pre>

===== QEMU =====

Out of the box, QEMU uses an emulated pcnet32 driver. The dde_pcnet32 driver has not been tested to fully work, so it is advisable to use the ne2k driver instead. Add this to the end of your QEMU launch command (and remove other -net commands)

<pre> -net nic,vlan=1,model=ne2k_pci -net user,vlan=1</pre>

===== Arch Hurd =====

Boot your qemu image, then login as root. It is probably not necessary to run as root, since these are *user* level drivers, but this has not been tested fully. Run the following commands

<pre>settrans -fgap ne2k /hurd/dde/dde_ne2k_pci
settrans -fgap /dev/eth0 /hurd/dde/devnode eth0 -M ne2k
settrans -fgap /servers/socket/2 /hurd/dde/pfinet -i /dev/eth0 -a 10.0.2.15 -g 10.0.2.2 -m 255.255.255.0</pre>

As you run these commands, you should see status messages informing you that a device is being detected. If all goes well, you should be able to run 'ifconfig' and be informed that eth0 is UP BROADCAST RUNNING MULTICAST

Congratulations! You are now running a network driver compiled from linux source in your Hurd's userspace!