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

From ArchWiki
Jump to: navigation, search
m (Added i18n menu, and italian translation link)
(fix double redirect)
(25 intermediate revisions by 8 users not shown)
Line 1: Line 1:
{{Article summary start}}
#REDIRECT [[General recommendations]]
{{Article summary text|Appendix of the Official Arch Linux Install Guide}}
{{Article summary heading|Available Languages}}
{{i18n_entry|English|Official Arch Linux Install Guide Appendix}}
{{i18n_entry|Italiano|Official Arch Linux Install Guide Appendix (Italiano)}}
{{Article summary heading|Related articles}}
{{Article summary wiki|Beginners Guide}} (If you are new to Arch)
{{Article summary wiki|Official Arch Linux Install Guide}}
{{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
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
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
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 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 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
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:
#Install and configure hardware
#Install and configure the ISDN utilities
#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
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
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|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
  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:
# Install the '''abs''' package via pacman
# Synchronize your ABS tree with the server by running '''abs''' as root.
# Create a build directory, 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 to fit 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 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
==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
# Checks if package dependencies are installed
# Downloads source files from servers
# Unpacks source files
# Performs any necessary patching, if specified in the PKGBUILD script
# 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)
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
Avoid using /usr/libexec/ for anything. Use /usr/lib/{pkgname}
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: <code>sshd:all</code> 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
==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

Latest revision as of 03:15, 17 February 2014