Difference between revisions of "Official Arch Linux Install Guide Appendix"

From ArchWiki
Jump to navigation Jump to search
m (How should I load modules during boot now?)
Line 677: Line 677:
it. To pass any options to a module you want to load through the
it. To pass any options to a module you want to load through the
MODULES array, only add the appropriate options line to your
MODULES array, only add the appropriate options line to your
==Kernel refuses to boot because of "lost interrupt"==
==Kernel refuses to boot because of "lost interrupt"==

Revision as of 11:36, 27 January 2010

Template:Article summary start Template:Article summary text Template:Article summary heading Template:I18n entry Template:I18n entry Template:I18n entry Template:Article summary heading Template:Article summary wiki (If you are new to Arch) Template:Article summary wiki Template:Article summary end

Adding a Window Manager/Desktop Environment

See also .xinitrc

Boot Scripts

Arch Linux uses a fairly simple bootup sequence quite similar to *BSDs. The first boot script to run is /etc/rc.sysinit. When it's done, /etc/rc.multi will be called (in a normal bootup). The last script to run will be /etc/rc.local. When started in runlevel 1, the single user mode, the script /etc/rc.single is run instead of /etc/rc.multi. You will not find an endless symlink collection in the /etc/rc?.d/ directories to define the bootup sequence for all possible runlevels. In fact, due to this approach Arch only really has three runlevels, if you take starting up X in runlevel 5 into account. The boot scripts are using the variables and definitions found in the /etc/rc.conf file and also a set of general functions defined in the /etc/rc.d/functions script. If you plan to write your own daemon files, you should consider having a look at this file and existing daemon scripts.

Boot Script Overview

  1. /etc/rc.sysinit
  2. /etc/rc.single
  3. /etc/rc.multi
  4. /etc/rc.local
  5. /etc/rc.shutdown
  6. /etc/rc.local.shutdown
  7. /etc/rc.d/*


The main system boot script. It does boot-critical things like mounting filesystems, running udev, activating swap, loading modules, setting localization parameters, etc. You will most likely never need to edit this file!


Single-user startup. Not used in a normal boot-up. If the system is started in single-user mode, for example with the kernel parameter 1 before booting or during normal multi-user operation with the command init 1, this script makes sure no daemons are running except for the bare minimum; syslog-ng and udev. The single-user mode is useful if you need to make any changes to the system while making sure that no remote user can do anything that might cause data loss or damage.

For desktop users, this mode usually is useless as crud. You should have no need to edit this script, either.


Multi-user startup script. It starts all daemons you configured in the DAEMONS array (set in /etc/rc.conf) after which it calls /etc/rc.local. You shouldn't feel a pressing need to edit this file.


Local multi-user startup script. It is a good place to put any last-minute commands you want the system to run at the very end of the bootup process. This is finally the one and only script you should modify if needed, and you have total freedom on what to add to this script.

Most common system configuration tasks, like loading modules, changing the console font or setting up devices, usually have a dedicated place where they belong. To avoid confusion, you should make sure that whatever you intend to add to your rc.local isn't feeling just as home in /etc/profile.d/ or any other already existant config location instead.


System shutdown script. It stops daemons, unmounts filesystems, deactivates the swap, etc. Just don't touch.


Analogous to the /etc/rc.local file, this file may contain any commands you want to run right before the common rc.shutdown is executed. Please note that this file does not exist by default, and for it to work properly, it must be set as executable.


This directory contains the daemon scripts referred to from the rc.conf's DAEMONS array. In addition to being called on bootup, you can use these scripts when the system is running to manage the services of your system. For example the command

 /etc/rc.d/postfix stop

will stop the postfix daemon. Of course a script only exists when the appropriate package has been installed (in this case postfix). With a basic system install, you don't have many scripts in here, but rest assured that all relevant daemon scripts end up here. This directory is pretty much the equivalent to the /etc/rc3.d/ or /etc/init.d/ directories of other distributions, without all the symlink hassle.

User & Group Management

Users and groups can be added and deleted with the standard commands provided in the util-linux package: useradd, userdel, groupadd, groupdel, passwd, and gpasswd. The typical way of adding a user is similar to this procedure:

 useradd -m -s /bin/bash johndoe
 passwd johndoe

The first command will add the user named johndoe to the system, create a home directory for him at /home/johndoe, and place some default login files in his home directory. It will also set his login shell to be /bin/bash. The second command will ask you for a password for the johndoe user. A password is required to activate the account.

As an alternative to the useradd command, the adduser script is also available to interactively create new users on your system simply by answering questions.

See the manpages for more information on the remaining commands. It is a good idea to create one or multiple normal users for your day-to-day work to fully use the available security features and minimize potential damage that may be the result of using the root user for anything but system administration tasks.

Additional information about adding users and groups can be found on the User Management wiki and on the Groups wiki.

Internet Access

Due to a lack of developers for dialup issues, connecting Arch to the Internet with a dialup line is requiring a lot of manual setup. If at all possible, set up a dedicated router which you can then use as a default gateway on the Arch box.

There are quite a few dialup related documents in the Arch Linux Wiki

Analog Modem

To be able to use a Hayes-compatible, external, analog modem, you need to at least have the ppp package installed. Modify the file /etc/ppp/options to suit your needs and according to man pppd. You will need to define a chat script to supply your username and password to the ISP after the initial connection has been established. The manpages for pppd and chat have examples in them that should suffice to get a connection up and running if you're either experienced or stubborn enough. With udev, your serial ports usually are /dev/tts/0 and /dev/tts/1.

Instead of fighting a glorious battle with the plain pppd, you may opt to install wvdial or a similar tool to ease the setup process considerably.

In case you're using a so called WinModem, which is basically a PCI plugin card working as an internal analog modem, you should indulge in the vast information found on the LinModem homepage.


Setting up ISDN is done in three steps:

  1. Install and configure hardware
  2. Install and configure the ISDN utilities
  3. Add settings for your ISP

The current Arch stock kernels include the necessary ISDN modules, meaning that you won't need to recompile your kernel unless you're about to use rather odd or old ISDN hardware. After physically installing your ISDN card in your machine or plugging in your USB ISDN-Box, you can try loading the modules with modprobe. Nearly all passive ISDN PCI cards are handled by the hisax module which needs two parameters; type and protocol. You must set protocol to '1' if your country uses the 1TR6 standard, '2' if it uses EuroISDN (EDSS1), '3' if you're hooked to a so called leased-line without D-channel, and '4' for US NI1.

Details on all those settings and how to set them is included in the kernel documentation, more specifically in the isdn subdirectory, available online. The type parameter depends on your card; A list of all possible types is to be found in the README.HiSax kernel documentation. Choose your card and load the module with the appropriate options like this:

 modprobe hisax type=18 protocol=2

This will load the hisax module for my (Dennis) ELSA Quickstep 1000PCI, being used in Germany with the EDSS1 protocol. You should find helpful debugging output in your /var/log/everything.log file in which you should see your card being prepared for action. Please note that you will probably need to load some usb modules before you can work with an external USB ISDN Adapter.

Once you confirmed that your card works with certain settings, you can add the module options to your /etc/modprobe.conf:

 alias ippp0 hisax
 options hisax type=18 protocol=2

Alternatively you can only add the options line here, and add hisax to your MODULES array in the rc.conf. Your choice, really, but this example has the advantage that the module will not be loaded until it's really needed.

That being done you should have working, supported hardware. Now you need the basic utilities to actually use it!

Install the isdn4k-utils package, and read the manpage to isdnctrl, it'll get you started. Further down in the manpage you will find explanations on how to create a configuration file that can be parsed by isdnctrl, as well as some helpful setup examples.

Please note that you have to add your SPID to your MSN setting separated by a colon if you use US NI1.

After you configured your ISDN card with the isdnctrl utility, you should be able to dial into the machine you specified with the PHONE_OUT parameter, but fail the username and password authentication. To make this work add your username and password to /etc/ppp/pap-secrets or /etc/ppp/chap-secrets as if you were configuring a normal analogous PPP link, depending on which protocol your ISP uses for authentication. If in doubt, put your data into both files.

If you set up everything correctly, you should now be able to establish a dialup connection with isdnctrl dial ippp0 as root. If you have any problems, remember to check the logfiles!


These instructions are only relevant to you if your PC itself is supposed to manage the connection to your ISP. You do not need to do anything but define a correct default gateway if you are using a separate router of some sort to do the grunt work.

Before you can use your DSL online connection, you will have to physically install the network card that is supposed to be connected to the DSL-Modem into your computer. After adding your newly installed network card to the modprobe.conf or the MODULES array, you should install the rp-pppoe package and run the pppoe-setup script to configure your connection. After you have entered all required data, you can connect and disconnect your line with

# /etc/rc.d/adsl start
# /etc/rc.d/adsl stop

respectively. The setup usually is rather easy and straightforward, but feel free to read the manpages for hints. If you want to automatically dial in on bootup, add adsl to your DAEMONS array, and put a ! before the network entry, since the network is handled by adsl now.

Package Management


Pacman is the package manager which tracks all the software installed on your system. It has simple dependency support and uses the standard gzipped tar archive format for all packages. Some common tasks are explained below with the respective commands in long and short option form. For an up to date explanation of pacman's options, read man pacman. This overview is merely scratching the surface of pacman's current capabilities.

Typical tasks:

Adding/Upgrading a package with a package file

 pacman --upgrade foo.pkg.tar.gz
 pacman -U foo.pkg.tar.gz

This will install the foo.pkg.tar.gz package on the system. If dependencies are missing, pacman will exit with an error and report the missing deps, but not attempt to resolve the dependencies automatically. Look at the --sync option if you expect this functionality. Adding multiple package files is possible, and if the listed files depend on each other, the packages will be automatically installed in the correct order. This will additionally upgrade an already-installed package at no extra cost.

Removing packages

 pacman --remove foo
 pacman -R foo

This will remove all files belonging to the package named foo, except for configuration files that have been edited. Only supply the name of the package to this command, without the pkg.tar.gz suffix.

To remove any and all trace of a package, add the --nosave option to the above command.

Refreshing the package list

 pacman --sync --refresh
 pacman -Sy

This will retrieve a fresh master package list from the repositories defined in the /etc/pacman.conf file and uncompress it into the database area. You should use this before using --sysupgrade to make sure you get the newest packages. Depending on your pacman.conf settings, this command may require a working internet connection to access FTP/HTTP-based repositories. This option is quite similar to Debian's apt-get update command.

Upgrading the system

 pacman --sync --sysupgrade
 pacman -Su

This command will upgrade all packages that are out-of-date on your system by comparing the local package version to the versions in the master package list that get downloaded with the --refresh command. It's a good idea to run this regularly to keep your system up to date. Note that this command does NOT implicitly refresh the master package list, so it's usually wiser to combine both commands into one like this:

 pacman --sync --refresh --sysupgrade
 pacman -Syu

With these options pacman will automatically retrieve the current master package list and do a full system upgrade to the latest packages with all dependencies being automagically resolved. You will want to run this quite often.

Adding/Upgrading a package from the repositories

 pacman --sync foo
 pacman -S foo

Retrieve and install package foo, complete with all dependencies it requires. Before using any sync option, make sure you refreshed the package list, or add --refresh or -y to the options to do it before the installation attempt. Unlike --add, the --sync option does not differ between installing and upgrading packages. Depending on your pacman.conf settings this function requires working internet access.

Receiving strange errors when downloading packages from the server, ie. broken downloads or files that aren't found, usually are either caused by not refreshing the package list with --sync, or if you're unlucky enough to try downloading from a mirror while it's syncing its contents, and is thus in an inconsistent state.

Searching for packages

 pacman -Ss foo

Search for package foo.

List installed packages

 pacman --query
 pacman -Q

Displays a list of all installed packages in the system.

Check if a specific package is installed

 pacman --query foo
 pacman -Q foo

Instead of grepping the full list for a name, you can append the name of the package you are looking for to the query command. This command will display the name and version of the foo package if it is installed, nothing otherwise.

Display specific package info

 pacman --query --info foo
 pacman -Qi foo

Displays information on the installed package foo (size, install date, build date, dependencies, conflicts, etc.). To display this information for a package file that is not yet installed, add the --file or -p option, respectively:

 pacman --query --info --file foo.pkg.tar.gz
 pacman -Qip foo.pkg.tar.gz

Display list of files contained in a package

 pacman --query --list foo
 pacman -Ql foo

Lists all files belonging to package foo.

Find out which package a specific file belongs to

 pacman --query --owns /path/to/file
 pacman -Qo /path/to/file

This query displays the name and version of the package which contains the file referenced by its full path as a parameter. Just using the file name without the path will not yield results.

Accessing Repositories

A package repository is a collection of packages and a package meta-info file that can reside in a local directory or on a remote FTP/HTTP server. The default repository for an Arch system is the core repository. This is kept up to date by developers with the latest version of most software and stays fairly bleeding-edge.

Many users also choose to activate the extra package repository which contains more packages that are not part of Arch's core package set. You can activate this repo by uncommenting the appropriate lines in your /etc/pacman.conf. This repository is activated by default.

You can also build, maintain and use your own package repositories. See the pacman manpage for instructions.

If you install from CD-ROM and end up having problems accessing the Internet, you may need to install additional packages from the CD. Refer to the FAQs, specifically FAQ #3 later in this document, to find out how to define a repository that uses the installation CD-ROM as a package source.

Arch Build System (ABS)

Binary vs. Source

Where pacman is responsible for the binary side of the package world, ABS is responsible for the source side: It helps you to build your own custom packages from source code, also letting you rebuild Arch Linux packages with your own customizations.

The procedure usually goes as follows:

  1. Install the abs package via pacman
  2. Synchronize your ABS tree with the server by running abs as root.
  3. Create a build directory, named after the package you are going to create.
  4. Copy the PKGBUILD.proto prototype from /var/abs/ into your newly created directory, remove the .proto suffix, and edit it to fit the new package.
  5. Run makepkg in the working directory with the PKGBUILD file.
  6. Install the newly built package with pacman.
  7. Send the package to your friends for bragging rights (or give it to an Archer so s/he can stick it in the master ABS tree).

Synchronizing Your ABS Tree

You can synchronize all the required package building files in /var/abs by running the abs script as root. A working internet connection is also required, of course. Using SVN as the transfer medium allows you to follow different version trees within ABS - this can be configured in /etc/abs/supfile.arch. For example, the default supfile is set to track the core package tree, which is bleeding-edge and the recommended source to follow. You can also follow specific versions. See the comments in the supfiles for more info.

ABS supports multiple repositories, which can be enabled or disabled in /etc/abs/abs.conf. By default, abs will follow the core and extra repositories, but not anything else.

You will also see an /etc/abs/supfile.extra file. This will give you access to all the unofficial build scripts that were not included in the main ABS repository. If you do not want to use this repository, you can delete the file, but usually it makes more sense to edit abs.conf accordingly instead, and disable the repositories you don't need.

How to Build Packages

The build process is thoroughly explained in the makepkg manpage. Read it for instructions on building your own packages. If that's not helping you, keep your eyes peeled for tutorials in the Wiki, or ask for help in the forums or IRC.

Package Guidelines

When building a package for Arch Linux, you should adhere to the package guidelines below, especially if you would like to contribute your new package to Arch Linux.

Package Naming

  • Package names should consist of alphanumeric characters only; all letters should be lowercase.
  • Package versions should be the same as the version released by the author. Versions can include letters if need be (eg, nmap'sversion was 2.54beta32 a good while ago). Version tags may not include hyphens! Letters, numbers, and periods only.
  • Package releases are specific to Arch Linux packages. These allow users to differentiate between newer and older package builds. When a new package version is first released, the release countstarts at 1. Then as fixes and optimizations are made, the package will be re-released to the AL public and the release number will increment. When a new version comes out, the release count resets to 1. Package release tags follow the same naming restrictions as version tags.


Configuration files should be placed in the /etc directory. If there's more than one configuration file, it's customary to use a subdirectory in order to keep the /etc area as clean as possible. Use /etc/{pkgname}/ where {pkgname} is the name of your package (or a suitable alternative, eg, apache uses /etc/httpd/).

Package files should follow these general directory guidelines:

 /etc             System-essential configuration files
 /usr/bin         Application binaries
 /usr/sbin        System binaries
 /usr/lib         Libraries
 /usr/include     Header files
 /usr/lib/{pkg}   Modules, plugins, etc.
 /usr/share/man   Manpages
 /usr/share/{pkg} Application data
 /etc/{pkg}       Configuration files for {pkg}
 /opt             Packages that do not fit cleanly into the GNU filesystem layout can be
                  placed here. If a package's files can be cleanly placed into the above
                  directories, then do so. If there are other high-level directories
                  that do not fit, then you should use /opt.

For example, the acrobat package has Browser, Reader, and Resource directories sitting at the same level as the bin directory. This doesn't fit into a normal GNU filesystem layout, so we place all the files in a subdirectory of /opt.

Clear as mud? Good.

makepkg Duties

When you use makepkg to build a package for you, it does the following automatically:

  1. Checks if package dependencies are installed
  2. Downloads source files from servers
  3. Unpacks source files
  4. Performs any necessary patching, if specified in the PKGBUILD script
  5. Builds the software and installs it in a fake root
  6. Removes /usr/doc, /usr/info, /usr/share/doc, and /usr/share/info from the package
  7. Strips symbols from binaries
  8. Strips debugging symbols from libraries
  9. Generates the package meta file which is included with each package
  10. Compresses the fake root into the package file
  11. Stores the package file in the configured destination directory (cwd by default)


Do not introduce new variables into your PKGBUILD build scripts, unless the package cannot be built without doing so, as these could possibly conflict with variables used in makepkg itself. If a new variable is absolutely required, prefix the variable name with an underscore.

Avoid using /usr/libexec/ for anything. Use /usr/lib/{pkgname} instead.

The "Packager" field from the package meta file can be customized by the package builder by modifying the appropriate option in the /etc/makepkg.conf file, or alternatively by exporting the PACKAGER environment variable before building packages with makepkg:

 export PACKAGER="John Doe <your.email>"

Submitting Packages

If you'd like to submit packages, please take a look at the Arch User Repository and their guidelines. New packages should be submitted to the AUR.

If you're submitting a package, please do the following:

  • Please add a comment line to the top of your PKGBUILD file that follows this format:
 Contributor: Your Name <your.email>
  • Verify the package dependencies (eg, run ldd on dynamic executables, check tools required by scripts, etc.). It's also a good idea to use the namcap utility, written by Jason Chu jason@archlinux.org, to analyze the sanity if your package. namcap will tell you about bad permissions, missing dependencies, un-needed dependencies, and other common mistakes. You can install the namcap package with pacman as usual.
  • All packages should come as a compressed tar file containing a directory with the newly built package, the PKGBUILD, filelist, and additional files (patches, install, ...) in it. The archive name should at least contain the name of the package.
  • Read the appropriate documents regarding the AUR, and the newest version of the packaging guildelines on the AUR Homepage.

Frequently Asked Questions

The FAQs listed here are only covering any problems that may keep you from booting or installing an initial Arch Linux system. If you have questions regarding further usage of the system utilities, X11 setup, etc. or how to configure your hardware, please head over to the Wiki. If you think an issue is not covered here that should be, please notify the author of this document, whose address is to be found at the very top of this file.

During the initial package installation, pacman fails to resolve dependencies for package A because package B is not in the package set

Unless something is very broken and thus very likely to be reported by multiple people soon, you probably just forgot to mount your target partitions properly. This causes pacman to decompress the package database into the initial ramdisk, which fills up quite nicely and ultimatively leads to this error.

Make sure that you use the DONE and not the CANCEL option offered by the Filesystem Mountpoints menu to apply your choices. This error should not happen if you use the Auto-Prepare feature; If it does nevertheless, please report this as a bug.

How can I install packages from the install CD with pacman --sync (so it resolves dependencies for me)?

If you would rather have packages install from the CD instead of downloading them, then mount the install CD somewhere (eg. /mnt/cd) and add this line right below the [core] line in /etc/pacman.conf: Server = file:///mnt/cd

Replace /mnt/cd with the mountpoint you chose. Then use pacman --sync as you normally would - It will now check the /mnt/cd directory first for packages.

How can I create multiple swap partitions during the install?

Naturally you won't be able to use the Auto-Prepare feature if you want to create and use multiple swap partitions. Create the partitions manually instead, and create as many swap partitions as your little heart desires. Go through the rest of the disk preparation steps, don't mind that you're only asked for one swap partition during the mount-point setting. Once you're through with the install and are about to edit your system configuration files, you can edit the fstab file and include a line for every swap device you created earlier. Simply copy the automatically generated swap line, and modify the referenced device according to your setup. The additional swaps will be activated after the bootup when swapon -a is being run by the initscripts. Make sure you ran mkswap on all of your swap partitions manually, or else your system will complain on bootup!

If, for any odd reason, you can not wait until after the installation with activating multiple swap partitions or files, you will have to open a shell on one of the virtual terminals and issue the swapon <device> for every swap drive or file you partitioned/readied before with mkswap. Then continue as explained above with the install.

In case you are honestly contemplating setting up multiple swap files or drives, you should keep in mind that a kernel that needs to swap is actually crying bitterly for more RAM, not more swap space. Please keep your penguin well fed. Thank you.

How do I reconfigure LILO from the rescue system?

As a first step you simply boot from the Arch Install CD or disks. If your partitions are intact and don't need checking, you can try choosing one of the recovery boot options according to your partition layout, or fiddle with the GRUB boot manager settings on your own to get your existing system to boot properly. That will boot directly into your system, and you can skip all but the last step of actually reconfiguring and running LILO.

If you cannot boot your old root directly, boot from the CD as if you were going to start an installation. Once you're in a shell, you mount the root partition of your harddisk into the /mnt directory, for example like this:

 mount /dev/hda3 /mnt

Then you mount any other partitions to their respective mount points within that root of yours, for example a /boot partition:

 mount /dev/hda1 /mnt/boot

Now you need to mount a /dev tree in the /mnt area, where LILO will be able to find it:

 /mnt/bin/mount --bind /dev /mnt/dev

Once everything is mounted, make this /mnt directory your new root with the chroot /mnt command. This will start a new shell and drop you into the /mnt directory, which will be considered your / from then on.

Now you can edit /etc/lilo.conf to your liking and run lilo to fix anything that needs fixing. Simply type exit when you want to break out of this root again, back into the original file tree. You can now reboot and test your changes.

I can't ssh into my machine!

The default configuration will reject all incoming connections, not only ssh connections. Edit your /etc/hosts.allow file and add the line: sshd:all to allow all incoming ssh connections.

How should I load modules during boot now?

If you want to load a module unconditionally without a specific device binding, add the name of the module to the MODULES array of your /etc/rc.conf. For on demand loading on device access, add it as usual with the alias and optioncommands to your /etc/modprobe.conf, in the rare cases that the automatisms employed by udev don't cut it. To pass any options to a module you want to load through the MODULES array, only add the appropriate options line to your /etc/modprobe.d/modprobe.conf.

Kernel refuses to boot because of "lost interrupt"

Kernel refuses to boot. It locks at: IRQ probe failed for hda hda lost interrupt

This or a similar error occurs for some HD controllers on kernel 2.6.x. A workaround is to pass the acpi=off option to the kernel at boot time.

I get "access denied" errors trying to play music or read DVDs

Add your user to the optical and audio groups.

 gpasswd -a johndoe optical
 gpasswd -a johndoe audio

Logout, then login again as that user (eg. johndoe) so the group changes can take effect, and the device permissions shouldn't be a problem anymore.

If you have a DVD drive, you may want to create a /dev/dvd symlink to your real DVD device. Usually udev does this for you already, but this will serve well as an example for setting up similar symlinks.

For example, if your DVD drive is accessible through /dev/sdc, you can do the following as root:

 cat >>/etc/udev/rules.d/00.rules <<EOF
 > KERNEL="sdc", NAME="sdc", SYMLINK="dvd"
 > EOF
 mount /dev/pts
 mount /dev/shm