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

From ArchWiki
Jump to: navigation, search
m
(redirect; content is all covered elsewhere (or out-of-date))
(20 intermediate revisions by 6 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)}}
 
{{i18n_entry|English|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.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
 

Revision as of 17:51, 7 December 2010