Set Filesystem Mountpoints should also be skipped if you chose to Auto-Prepare your hard drive. You should select this choice once the partition information is edited to your liking with the previous menu selection, or already existent through whatever other means.

−

The first question to answer is what partition to use as swap. Select the previously created swap partition from the list, and select the partition that is supposed to become your root partition in the next step.

−

Every time you specify a partition to mount, you will be asked if you want to create a filesystem on the respective partition. If you select YES, you will be asked what filesystem to create (a matter of taste, really. Choose ext2 if you have no clue), and the partition will be formatted with the chosen filesystem, destroying all data in the process. It should be no problem, however, to say NO at this point to preserve any existing files on the partition.

−

If you want to preserve existing data on a partition, you are strongly advised to create backups instead of hoping that nothing will go wrong during the install. Don't say I didn't warn you!

−

You will not be asked for a filesystem to use on your swap partition, as this partition uses a specific filesystem of it's own.

−

If you want to mount any other partitions, for example a separate /boot or /home partition, you will be able to do so now. Simply

−

select a partition to mount

−

choose a filesystem (if you want to create one instead of keeping the data)

−

choose a mountpoint for the partition

−

Repeat these steps until you're satisfied, then select DONE to create any filesystems and mount the partitions in their respective places. After formatting and mounting all partitions, you will be dropped into the Main Menu, ready to proceed.

−

Do not mount /tmp on a seperate partition just yet, as it will badly confuse the installer! Simply leave the designated /tmp partition alone until the installation is done, and configure the partition manually after you have a running system if you must have a seperate partition for /tmp.

−

Select Packages

−

Select Packages will let you select the packages you wish to install from the CD or your FTP mirror.

If you chose CD-ROM installation, you have to tell the installer whether it should try to mount the CD itself, or whether you already mounted the source media in /src. Select the option according to what you need; Normally you will want to choose CD, after which you will be given the possibility to choose a CDROM drive from the list of all detected devices.

If you chose CD-ROM installation, you have to tell the installer whether it should try to mount the CD itself, or whether you already mounted the source media in /src. Select the option according to what you need; Normally you will want to choose CD, after which you will be given the possibility to choose a CDROM drive from the list of all detected devices.

If your CD-ROM drive is not displayed in the list, make sure you loaded any modules that may be needed, like SCSI or USB storage support.

If your CD-ROM drive is not displayed in the list, make sure you loaded any modules that may be needed, like SCSI or USB storage support.

If you chose CD-ROM installation, you have to tell the installer whether it should try to mount the CD itself, or whether you already mounted the source media in /src. Select the option according to what you need; Normally you will want to choose CD, after which you will be given the possibility to choose a CDROM drive from the list of all detected devices.

If your CD-ROM drive is not displayed in the list, make sure you loaded any modules that may be needed, like SCSI or USB storage support.

If you chose FTP Installation, you will be asked to choose a mirror close to you from a list, or select CUSTOM to enter your own fully qualified FTP path to an installation source, ie. a prepared server in your LAN, or a mirror that's not listed for whatever reason.

Whatever source you chose, after fetching the package list you'll be dropped into the package category selection screen.
If you are presented an error while fetching the package database, you should either choose another FTP mirror, make sure your network is working at all, and you didn't slip any typos into your custom server address. You might also have goofed mounting of your source media in the /src directory, if you chose that option.
Now, once that is tackled, you have the opportunity to specify whole package groups from which you'd generally like to install packages, then fine-tune your coarse selection by (de)selecting individual packages.
Any packages in the BASE category should stay selected under all circumstances, and you should select any other group which contains a package you might need. Please note that the upcoming individual package selection screen will only offer packages which are in the categories you select here, so if you only select BASE, you won't be able to add any other packages than those in the BASE category.
If you want to only select the bare minimum for installation, but be able to browse through all available packages nevertheless to see if anything interesting is there to add, you should select all package categories, but choose to NOT select all packages by default.
The Select all packages by default? question can be easily misunderstood; Basically you are asked whether you want all the packages in the categories you just chose to be selected or not.
If you select YES, the whole list of packages contained in the chosen categories will be displayed and selected, and your job will be to deselect what you do not want.
If you select NO, the same list of packages will displayed, but only packages of the BASE category will be selected, and you'll have to explicitly select any other packages you want to install.
Choosing NO helps to install a lean system!
It is recommended that you install all the BASE packages, but not anything else at this point. Don't worry about getting all the packages you want - you can easily install more of them once the basic system boots by itself. The only exception to this rule is installing any packages you need for setting up internet connectivity. These packages usually are:

dhcpcd (base)
Add if your machine is a DHCP client.
isdn4k-utils (network)
Add if you use ISDN for dialup.
ppp (base)
Add if you use an analog modem for dialup.
rp-pppoe (base)
Add if you use DSL for pseudo-dialup.

The downloadable base ISO does not contain any packages but those in the BASE category, so be advised to get the full sized ISO if you need ISDN packages!
Once you're done selecting the packages you need need, leave the selection screen and continue to the next step, Install Packages.

Install Packages
Install Packages will now install pacman and any other packages you selected with resolved dependencies onto your harddisk.
If you skipped preparation of your hard drive, you will be asked where your root partition has been mounted. This should only happen to people who partitioned and created filesystems on the target devices manually. Those people will have to enter the root directory where the packages shall be installed. By default, the installer mounts the root partition in /mnt, and any extra partitions below.

Error messages and debugging output is output to terminal five (ALT-F5). After the packages are installed, proceed to the next step, Configure System.

Configure System
Configure System allows you to edit the configuration files crucial for your newly installed system.

If you're in a real hurry, you may skip this step entirely and hope the defaults will work, but it's strongly recommended to iterate through the list of config file presented here and change options accordingly. Please refer to the System Configuration section for detailed instructions.

Install the stock 2.6.x kernel with SCSI/SATA/IDE support. The exact support each 2.6.x kernel has will depend on how you have configured your initial ramdisk, but the default has support for all known SCSI, SATA, and IDE systems. See the System Configuration section for more information about the initrd.

Install the stock 2.4.x kernel with IDE and SCSI support. Choose this if you have any SCSI drives installed, or need SCSI emulation for an IDE CD-Writer drive or USB Storage devices.
Please note that Arch Linux uses the 2.6 kernel by default. We are phasing out support for the 2.4 series, so you should only use it if 2.6 just isn't working out for you.

Before installing the bootloader, the setup script will want you to examine the appropriate configuration file to confirm the proper settings. Make sure you know what your root (and /boot, if you have it) partitions are.
If you choose to install LILO, the bootloader will be automatically installed according to your settings in the configuration file, whilst GRUB demands the selection of a partition to install the bootloader to. Here you should choose what you would enter as the boot option of LILO, which is usually the entry named /dev/hda, as it refers the master boot record of the first hard disk. Detailed error messages can be found as usual on VC5 (virtual console 5), if anything goes wrong.
If you plan on setting up a multiboot system, it might be a better option to install the bootloader in your root or /boot partition, and refer to that boot sector from whatever other boot loader you want to reside in the master boot record.
Installing a boot loader in the MBR will relentlessly overwrite any existing bootloader! Make sure you understand the implications of that if you're running a multiboot system, or want to preserve an installed bootloader from another OS!

Exit Install
Exit Install now, remove the CD from the drive, type reboot at the command line and cross your fingers!

If your system boots up, you can log in as root without any password, so your first things to do are setting a password for root with the passwd command once you're logged in, add a user as outlined in the User Management section, and set up your Internet Connection.
Congratulations! Now you can proceed getting into the nitty-gritty of configuring the interesting parts of your system.

System Configuration

These are the core configuration files for Arch Linux. You should be comfortable hand-editing these files with a text-editor, because there aren't any GUI apps to help you out. Only the most basic configuration files are listed here. If you need help configuring a specific service, please read the appropriate manpage or refer to any online documentation.
Arch Linux does not use any abstraction layer to administrate your system. As a result, you can usually stick to any instructions published by the author of a software, or whatever you find in a search engine of your choice, and it'll work out without confusing your system, because your system just does not care.

Configuration Files

Before attempting to boot your newly installed system, you should at least glance over these files and make sure they are not too far off.

This is the main configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. You should read through all the settings in this file and make sure you understand them:

LOCALE

This sets your system language, which will be used by all i18n-friendly applications and utilities. You can get a list of the available locales by running locale -a from the commandline. This setting is not needed for US English users.

HARDWARECLOCK

Either UTC if your BIOS clock is set to UTC or GMT, or localtime if your BIOS clock is set to your local time. If you have an OS installed which cannot handle UTC BIOS times correctly, like Windows, choose localtime here, otherwise prefer UTC, which makes daylight savings time a non-issue and has a few other positive aspects.

TIMEZONE

Specifies your time zone. Possible time zones are the relative path to a zoneinfo file starting from the directory /usr/share/zoneinfo. For example, a german timezone would be Europe/Berlin, which refers to the file /usr/share/zoneinfo/Europe/Berlin. If you don't know the exact name of your timezone file, worry about it later.

KEYMAP

Defines the keymap to load with the loadkeys program on bootup. Possible keymaps are found in /usr/share/kbd/keymaps. Please note that this setting is only valid for your TTYs, not any graphical window managers or X.

CONSOLEFONT

Defines the console font to load with the setfont program on bootup. Possible fonts are found in /usr/share/kbd/consolefonts.

USECOLOR

Enable (or disable) colorized status messages during boot-up.

MOD_AUTOLOAD

If set to "YES", Arch will scan your hardware at bootup and attempt to automatically load the proper modules for your system. This is done with the hwdetect utility.

MOD_BLACKLIST

This is an array of modules that you do not want to be loaded at bootup. For example, if you don't want that annoying PC speaker, you could blacklist the pcspkr module.

MODULES

In this array you can list the names of modules you want to load during bootup without the need to bind them to a hardware device as in the modprobe.conf (or modules.conf, if you're using kernel 2.4.x). Simply add the name of the module here, and put any options into the modprobe.conf if need be. Prepending a module with a bang ('!') will not load the module during bootup (this is not the same as MOD_BLACKLIST).

USELVM

Set to "YES" to run a vgchange during sysinit, thus activating any LVM groups. If you have no idea what this means, don't bother.

HOSTNAME

Set this to the hostname of the machine, without the domain part. This is totally your choice, as long as you stick to letters, digits and a few common special characters like the dash. Don't be too creative here, though.

INTERFACES

Here you define the settings for your networking interfaces. The default lines and the included comments explain the setup well enough. If you do not use DHCP to configure a device, just keep in mind that the value of the variable (whose name must be equal to the name of the device which is supposed to be configured) equals the line which would be appended to the ifconfig command if you were to configure the device manually in the shell.

ROUTES

You can define your own static network routes with arbitrary names here. Look at the example for a default gateway to get the idea. Basically the quoted part is passed exactly as you pass it to the route add command, therefore reading man route is recommended if you don't know what to write here.

NET_PROFILES

Enable certain network profiles at bootup. Network profiles provide a convenient way of managing multiple network configurations, and are intended to replace the standard INTERFACES/ROUTES setup that is still recommended for systems with only one network configuration. If your computer will be participating in various networks at various times (eg, a laptop) then you should take look in the /etc/network-profiles directory to set up some profiles. There is a template file included there that can be used to create new profiles.

DAEMONS

This array simply lists the names of those scripts contained in /etc/rc.d/ which are supposed to be started during the boot process. If a script name is prefixed with a bang (!), it is not executed. If a script is prefixed with an "at" symbol (@), then it will be executed in the background (ie, the startup sequence will not wait for successful completion before continuing). Usually you do not need to change the defaults to get a running system, but will edit this array quite often once you install system services like sshd.

/boot/grub/menu.lst
GRUB is the default bootloader for Arch Linux. You should check and modify this file to accomodate your boot setup if you want to use GRUB, otherwise read on about the LILO configuration.

Configuring GRUB is quite easy, the biggest hurdle is that it uses yet another device naming scheme different from /dev; Your hard disks as a whole are referred to as (hd0), (hd1), etc., sequentially numbered in order of appearance on the IDE/SCSI bus, just like the hda, hdb, etc. names in Linux. The partitions of a disk are referred to with (hd0,0), (hd0,1) and so on, with 0 meaning the first partition. A few conversion examples are included in the default menu.lst to aid your understanding.
Once you grasped the concept of device naming, all you need to do is to choose a nice title for your boot section(s), supply the correct partition device as a parameter to the root option to have it mounted as / on bootup, and create a kernel line that includes the partition and path where the kernel is located as well as any boot parameters. If using the stock Arch 2.6.x kernel, you'll also need an initrd line that points to the initrd26.img file in your /boot directory. The path you put on your initrd line should be the same as the path to vmlinuz26 that you provide on the kernel line. You should be fine with the defaults, just check whether the partition information is correct in the root and kernel lines.
To create a boot option that loads the bootsector of a different OS, this example might be helpful. You will probably succeed in starting any Microsoft-based operating system with it, just add this block to the file after any other sections, and modify the partition device accordingly to refer to the partition containing the bootsector of the OS you are intending to boot.

(1) Other OS

title My Other OS
rootnoverify (hd0,1)
makeactive
chainloader +1

For advanced configuration of other OSes, please refer to the online GRUB manual.

/etc/lilo.conf

This is the configuration file for the LILO bootloader. Make sure you check this one and get it right if you want to use LILO to boot your system. See LILO documentation for help on this.
Things you should check are the root= lines in the image sections and the boot= line right at the beginning of the file. The root lines specify the device which shall be mounted as the root filesystem on bootup. If you don't know what is supposed to be entered here, change to another terminal and type mount to see a list of all currently mounted drives, and look for the line which displays a device name mounted on /mnt type [...]. The device path at the beginning of this very line should be entered in the root lines of your lilo.conf. Change if necessary.
The boot line should be okay by default in most cases. Unless you have a weird boot manager setup in mind with multiple OSes, the device referenced here should be having the same prefix your root lines have, but not end with a number. For example, a root of /dev/hda3 means you probably want to install LILO into the Master Boot Record of the hard disk, so you would set boot to /dev/hda, which references the disk as a whole.
To prevent some serious grief, you should make sure you know how to restore the bootsector of your other OSes, for example with Windows's FIXBOOT/FIXMBR tools.
To be on the safe side, you should keep the option lba32 right below the prompt line. This will prevent some geometry issues from happening.
In some cases, depending on your BIOS, LILO will not run on bootup and spill out an error code infinitely. In most cases you either removed the lba32 option, or your hardware setup is a little special, meaning that maybe your CD-ROM drive is primary master and the hard disk you installed secondary slave. This can very well irritiate your BIOS, and prevent a boot up. To prevent that you can try and make the install drive the primary master on your IDE bus. If you've got a mixed IDE and SCSI system and the problem persists, you'll probably need some experimentation with the disk and bios options of LILO to provide a working mapping; The disk drives in your system are numbered sequentially by your BIOS, starting with 0x80. If you're lucky your SCSI controller tells you which drive has which BIOS ID, but usually you're not. How the drives are effectively numbered is depending on your BIOS, so in the worst case you can only guess until it works. A typical disk line would look like this:

boot=/dev/hda
disk=/dev/hda bios=0x80

The disk option maps a BIOS ID to the disk device known to linux. Note that there is still no guarantee that things will work as other things can be wrong, so do not despair if all your tries fail, but rather try rearranging your hardware in a way that's not totally odd. In this area too much can go wrong and needs special handling to be explained here. In most cases the lba32 option will suffice anyway. Old hard drives will usually need a little more special care until they do as told.
Don't become fidgety when reading this section, I (Dennis) just happened to stumble over this problem when experimenting with a rather odd system, and figured it'd be a good idea to mention this show stopper and workarounds here. You probably won't ever experience this, and if you do, use GRUB. ;)
How to recreate a LILO boot sector with only a rescue disk is explained later in this document.

/etc/mkinitrd.conf

This file allows you to fine-tune the initial ramdisk (also commonly referred to as the "initrd") for your system. The initrd is a gzipped image that is read by the kernel during bootup. The purpose of the initrd is to bootstrap the system to the point where it can access the root filesystem. This means it has to load any modules that are required to "see" things like IDE, SCSI, or SATA drives (or USB/FW, if you are booting off a USB/FW drive). Once the initrd loads the proper modules, it passes control to the Arch system and your bootup continues. For this reason, the initrd only needs to contain the modules necessary to access the root filesystem. It does not need to contain every module you would ever want to use. The majority of these modules will be loaded later on by hwdetect or hwd.
By default, mkinitrd.conf is configured to provide all known modules for IDE, SCSI, or SATA systems. This means the default initrd should work for almost everybody. The downside to this is that there are many modules loaded that you will not need. This is easily visible by examining your module table after booting up (with the lsmod command). While this doesn't actually hurt anything, some people find it annoying. To cull this list down to only what you actually need, you can edit mkinitrd.conf and disable the subsystems (ie, IDE, SCSI, RAID, USB, etc) that you don't need. Each subsystem has a variable that starts with REMOVE_. Setting the variable to 1 (one) will remove it from the initrd.
You can customize even further by specifying the exact modules you need in the HOSTCONTROLLER_ variables. Or, if you'd rather trust the auto-detection utility (hwdetect) to find the modules for you, you can set the AUTODETECT variable to 1 and ignore the other settings.
If you're using RAID or encryption on your root filesystem, then you'll have to tweak the RAID/CRYPT settings near the bottom. See the wiki pages for RAID/LVM, filesystem encryption, and Initrd for more info.
When you're finished tweaking mkinitrd.conf, you must run mkinitrd auto to regenerate the initrd. You can include the -show switch if you want to see a list of the modules being included.

mkinitrd auto -show

WARNING: If you fail to include the correct module(s) in your initrd, your system will not boot! For this reason, you should be especially careful when tweaking your initrd. Do not over-tweak unless you know your hardware well.

If you do manage to break your system, you can use the backup initrd that is included with the stock 2.6.x kernel, but only if you use the GRUB bootloader. To use the backup initrd, you must edit the initrd line from the GRUB menu at bootup and change it to point to the backup image. For example, if your normal initrd line is initrd /initrd26.img, you should change it to initrd /initrd26-full.img. Then bootup with the backup initrd and fix your primary!

/etc/hosts

This is where you stick hostname/ip pairs of other computers on your network. If a hostname isn't part of DNS, you can add it here. You usually don't need to change anything here, but you might want to add the hostname and hostname + domain of the machine to this file, resolving to the IP of your network interface. If you don't know what you're doing, leave this file alone until you read man hosts.

/etc/fstab

Your filesystem settings and mountpoints are configured here. The install program should have created the necessary entries for you, but you should look over it and make sure it's right.

/etc/modprobe.conf

This is for use with 2.6.x kernels only.
This tells the kernel which modules it needs to load for system devices. For example, to have the kernel load your Realtek 8139 ethernet module when it starts the network (ie. tries to setup eth0), use this line:

alias eth0 8139too

The syntax of this file is nearly identical to the old modules.conf scheme, unless you use some of the more exotic options like post-install. Then you should invest a little time into reading man modprobe.conf.

/etc/modules.conf

This is for use with 2.4.x kernels only.
This tells the kernel which modules it needs to load for system devices. For example, to have the kernel load your Realtek 8139 ethernet module when it starts the network (ie. tries to setup eth0), use this line:

alias eth0 8139too
/etc/resolv.conf

Use this file to setup your nameserver(s) that you will use. It should basically look like this:

search domain.tld
nameserver 192.168.0.1
nameserver 192.168.0.2

Replace domain.tld and the ip addresses with your settings. The so called search domain specifies the default domain that is appended to unqualified hostnames automatically. Setting this, a ping myhost will effectively become a ping myhost.domain.tld with the above values. These settings usually aren't mighty important, though, and most people should leave them alone for now. If you use DHCP, this file will be fed with the correct values automatically when networking is started, meaning you can and should happily ignore this file altogether.

/etc/conf.d/*

During setup, this is totally unimportant. Consider this as reference for the interested.
Some daemon scripts will have a matching configuration file in this directory that contains some more-or-less useful default values. When a daemon is started, it will first source the settings from it's config file within this directory, and then source the /etc/rc.conf. This means you can easily centralize all your daemon configuration options in the rc.conf simply by setting an appropriate variable value, or split up your configuration over multiple files if you prefer a decentralized approach to this issue. Ain't life great if it's all just simple scripting?

/etc/profile

This script is run on each user login to initialize the system. It is kept quite simple under Arch Linux (most things are). You may wish to edit or customize it to suit your needs.

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 runleves. 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.

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

/etc/rc.single

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'll probably never need to edit this script, either.

/etc/rc.multi

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.

/etc/rc.local

Local multi-user startup script. It is a good place to put any last-minute commands you want the system to run at the 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.

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 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.
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 passwort 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 endulge in the vast information found on the LinModem homepage.

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 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, or 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 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 (or /etc/modules.conf if you're using kernel 2.4.x):

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 seperated 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!

DSL (PPPoE)

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 seperate 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 modules.conf/modprobe.conf or the MODULES array, you should install the rp-pppoe package and run the adsl-setup script to configure your connection. After you have entered all the data, you can connect and disconnect your line with

/etc/rc.d/adsl start

and

/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.

Package Management
Pacman
pacman is the package manager which tracks all the software installed on your system. It has simple dependency support and uses the standard tar-gz 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 a new package with a package file
Upgrading a package with a package file
Removing packages
Refreshing the package list
Upgrading the system
Adding/Upgrading a package from the repositories
List installed packages
Check if a specific package is installed
Display specific package info
Display list of files contained in package
Find out which package a specific file belongs to
Adding a new package with a package file

pacman --add foo.pkg.tar.gz

pacman -A 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.

Upgrading a package with a package file

pacman --upgrade foo.pkg.tar.gz

pacman -U foo.pkg.tar.gz

This does essentially the same as the --add operation, but will additionally upgrade an already-installed package at no extra cost. I can personally not imagine a case where you'd prefer --add over this --upgrade function.

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-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 gets downloaded with the --refresh command. It's a good idea to run this every now and then 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:

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.

List installed packages

pacman --query

pacman -Q

Displays the 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 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 it's full path as a parameter.

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 current repository. This is kept up to date 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 a CD and end up having a problem accessing the Internet, you may need to install additional packages from the CD. You can locate the packages on the cd and install them manually using pacman -A packagename.pkg.tar.gz Alternatively, you can temporarily set up a local repository to access the CD. Mount the CD on /mnt/cd using the command mount /mnt/cd (assuming your fstab is properly set up). Then add the following lines to your /etc/pacman.conf:

[cd]
Server = file:///mnt/cd/arch/pkg

You will then be able to install additional packages to help you get your Internet access set up.

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:
Synchronize your ABS tree with the server (run abs as root)
Create a new directory in /var/abs/local/ named after the package you are going to create
Copy the PKGBUILD.proto prototype from /var/abs/ into your newly created directory, remove the proto, suffix, and edit it for the new package.
Run makepkg in the working directory with the PKGBUILD file.
Install the newly built package with pacman.
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 PKGBUILD files in /var/abs by running the abs script as root. It requires the cvsup package to operate and will complain if you don't have it installed. Using CVS 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 current 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 from /etc/abs/abs.conf. By default abs will follow the current and extra repositories, but not unstable.
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.

How to Build Packages

The build process is thoroughly explained in the makepkg manpage. See 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 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's version is 2.54BETA32). 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 count starts 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.

Directories
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/man Manpages
/usr/share/{pkg} Application data
/etc/{pkg} Configuration files for {pkg}
/opt
Packages that do not fit cleanly into Linux 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 Linux 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:
Checks if package dependencies are installed

Downloads source files from servers
Unpacks source files

Does any necessary patching

Builds the software and installs it in a fake root
Removes /usr/doc, /usr/info, /usr/share/doc, and /usr/share/info from the package
Strips symbols from binaries
Strips debugging symbols from libraries

Generates the package meta file which is included with each package

Compresses the fake root into the package file
Stores the package file in the configured destination directory (cwd by default)
Other
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/{pkg} 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 directly to the Arch developers, we ask 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.
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.
Watch for announcements regarding the actual submission of packages, as a new implementation of the whole procedure is currently being discussed among the developers. If you think your package is too important to wait, you may of course ask a Trusted User if he would be willing to take your package for inclusion in his repository.

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, XFree86 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 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; 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 [current] 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 much swap partitions as your little heart desires. Go through the rest of the install, 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.
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. 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 should supply the root= kernel boot parameter as the instructions tell you. 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 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!

Edit your /etc/hosts.deny file. The default configuration will reject all incoming 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 command to your /etc/modprobe.conf (/etc/modules.conf for 2.4 kernels). To pass any options to a module you want to load through the MODULES array, only add the appropriate options line to the /etc/modprobe.conf.
Kernel refuses to boot because of lost interrupt

This 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 sound or read DVDs
Add your user to the optical and audio groups.

gpasswd -a johndoe optical

gpasswd -a johndoe audio

Logout, then login as your regular user (eg, johndoe) so the group changes can take effect.
If you have a DVD drive, you may want to create a /dev/dvd symlink to your real DVD device.
For example, if you use udev and your DVD drive is on /dev/hdc, you can do the following as root:

cat >>/etc/udev/rules.d/00.rules <<EOF

> KERNEL="hdc", NAME="hdc", SYMLINK="dvd"
> EOF

/etc/start_udev

mount /dev/pts

mount /dev/shm

When trying to install packages with pacman, I get this: error: xorg conflicts with xfree86
This is a temporary problem as we make a full switch over to xorg. Currently, some packages still depend on xfree86 specifically, so pacman gets confused.
You can fix this problem by installing xorg explicitly, then installing other packages afterwards.