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

From ArchWiki
Jump to: navigation, search
m (Reverted edits by Thestinger (Talk) to last revision by Code m)
(fix double redirect)
 
(14 intermediate revisions by one other user not shown)
Line 1: Line 1:
[[Category: General (English)]]
+
#REDIRECT [[General recommendations]]
{{Article summary start}}
+
{{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)}}
+
{{i18n_entry|简体中文|Arch 官方安装指南附录 (简体中文)}}
+
{{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==
+
*[[KDE]]
+
*[[KDEmod]]
+
*[[GNOME]]
+
*[[Xfce]]
+
*[[Openbox]]
+
*[[Wmii]]
+
*[[Awesome3]]
+
*[[Fluxbox]]
+
*[[LXDE]]
+
*[[E17]]
+
*[[Xmonad]]
+
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
+
 
+
#/etc/rc.sysinit
+
#/etc/rc.single
+
#/etc/rc.multi
+
#/etc/rc.local
+
#/etc/rc.shutdown
+
#/etc/rc.local.shutdown
+
#/etc/rc.d/*
+
 
+
 
+
'''/etc/rc.sysinit'''
+
 
+
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!
+
 
+
 
+
'''/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 should
+
have no 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 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.
+
 
+
 
+
'''/etc/rc.shutdown'''
+
 
+
System shutdown script. It stops daemons, unmounts filesystems,
+
deactivates the swap, etc. Just don't touch.
+
 
+
 
+
'''/etc/rc.local.shutdown'''
+
 
+
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.
+
 
+
 
+
'''/etc/rc.d/*'''
+
 
+
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.
+
 
+
===ISDN===
+
 
+
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
+
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
+
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|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:
+
# 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
+
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.
+
 
+
 
+
'''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/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:
+
# 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)
+
 
+
 
+
'''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/{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: <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
+
/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
+
  /etc/start_udev
+
  mount /dev/pts
+
  mount /dev/shm
+

Latest revision as of 03:15, 17 February 2014