Beginners Guide Appendix
Template:Article summary start Template:Article summary text Template:Article summary heading Template:I18n entry Template:I18n entry Template:I18n entry Template:I18n entry Template:Article summary heading Template:Article summary wiki Template:Article summary wiki (provides a more general approach) Template:Article summary end
- 1 An Introduction to ABS
- 2 An Introduction to The AUR
- 3 File and directory explanation
- 4 Arch Boot Process
- 5 Maintaining the system
- 6 Tweaks/Finishing touches
- 6.1 HAL
- 6.2 Backgrounding DAEMONS on startup
- 6.3 Turn off Control Echo in Bash
- 6.4 Beautifying Fonts for LCD's
- 6.5 Adjusting Mouse for scroll wheel
- 6.6 Get All Mouse Buttons Working
- 6.7 Configuring Touchpad for Laptops
- 6.8 Adjusting Keyboard Layout
- 6.9 Additional tweaks for laptops
- 6.10 Configuring CPU frequency scaling
- 6.11 Pm-Utils
- 6.12 Laptop-Mode
- 6.13 Add additional repositories
- 7 Polishing & Further information
- 8 External links
An Introduction to ABS
ABS is the Arch Linux Build System. It is a ports-like system for compiling sources into installable packages.
'Ports' is a system used by *BSD, which uses simple build scripts residing in a directory tree on the local machine. Each port is simply a directory, named for the installable 3rd party software, and containing a build script. Typically, a *BSD user who wanted to build and install firefox, would cd into the corresponding firefox port residing under /usr/ports and do
make install clean. The firefox sourcecode would then be downloaded from a 3rd party source. According to the port build script, the sources would then be compiled, patched (if directed), and finally, installed to the system.
ABS offers the same functionality by providing build scripts called PKGBUILDs, which contain all information for a given piece of software; The md5sums, source URL, version, license and compilation instructions. In addition, ABS provides the advantage of compiling the sources into an installable package with the extension .pkg.tar.gz. Obviously, it is a simple g-zipped tarball, but it is cleanly installable/removable/trackable via pacman.
Install the abs package:
# pacman -Sy abs
After installing the abs package with pacman, run the
/usr/bin/abs script as root:
The ABS tree is then extracted under /var/abs, organized according to the installable software.
To build a package from source, create a build directory and copy the abs directory for a given application to the build directory:
$ mkdir ~/abs $ cp -r /var/abs/extra/slim ~/abs
This will move the slim subdir and PKGBUILD script for slim to the build directory.
navigate to the slim build directory and, after modifying the PKGBUILD if desired or necessary, invoke the abs
$ makepkg -cs
- -c Cleans up any leftover files from the source compilation
- -s Downloads and installs any missing dependencies by invoking pacman
Install with pacman's -U (upgrade) switch:
# pacman -U slim-<version>.pkg.tar.gz
Done. Slim sources are downloaded, compiled, compressed into a package and finally, installed. Template:Box Note Q: Why would I need ABS to compile and create an installable package from source, when I have access to all of the same software via pacman and the binary repos?
A: A few reasons:
- For installing newer, unstable, custom, or development versions of an application.
PKGBUILDs are transparent and simple. Edit the software version and the md5sums of the desired versions within the PKGBUILD, and build and install your custom packages.
- For patching.
Copy the corresponding PKGBUILD to a build directory along with your patch, edit the PKGBUILD, and build/install with
You are not limited to the PKGBUILDs under /var/abs. Create your own to build from 3rd party sourcecode. They are simple, open and transparent. Explore the prototype PKGBUILD provided at /usr/share/pacman/PKGBUILD.proto
- ABS provides an expedient method for recompiling, if necessary.
For example, to recompile your video or wireless drivers.
- To build an installable package with custom configurations
Enable or disable options in any package by modifying the PKGBUILD
- To build an installable package, further optimized for your machine's architecture,
- To rebuild your entire system, BSD-style, further optimized for your machine's architecure.
Use the makeworld script, or the community-contributed pacbuilder
An Introduction to The AUR
The Arch User Repository
The ABS tree provides the ability to build all Arch software available in the [core], [extra], [community], and [testing] repositories by providing build scripts on the local machine. In contrast, the AUR does not provide a tree on the local machine, but rather, an unsupported repository of build scripts, sporting a handsome web interface at http://aur.archlinux.org/index.php Also, there is an AUR link tab at the top right of every page on the Arch site.
Once you have navigated to the AUR web page, click on the Packages button on the top right. You will be brought to the packages search page.
The general procedure will be:
- Enter the search criteria into the keywords field and click on go. The next screen will present all related results.
- Take note of the Location on the package listing. If the package location is in community, you have not done your homework, and should simply use pacman or ABS to install. If the location is unsupported, continue.
- Click on the name of the package on the package listing. You will be brought to the Package Details page.
An example for the yaourt package:
yaourt 0.9-2 http://www.archlinux.fr/yaourt-en/ A Pacman frontend with more features and AUR support unsupported :: system Maintainer: wain Votes: 943 License: GPL Last Updated: Sat, 15 Mar 2008 17:15:20 +0000 First Submitted: Tue, 04 Jul 2006 20:37:58 +0000 Tarball :: Files :: PKGBUILD
Click on the Tarball link in the last line of the details, and save to a build directory.
Navigate to, and extract the tarball:
$ tar -xvf yaourt.tar.gz
Enter the build directory and invoke makepkg, which will download the sources, compile, and compress the installation into an installable .pkg.tar.gz package:
$ makepkg -cs
- -c Cleans up any leftover files from the source compilation
- -s Downloads and installs any missing dependencies by invoking pacman
Install with pacman's -U (upgrade) switch:
# pacman -U yaourt<version>.pkg.tar.gz
See the AUR wiki entry for more information.
Install an AUR Helper
File and directory explanation
"Shareable" files are defined as those that can be stored on one host and used on others. "Unshareable" files are those that are not shareable. For example, the files in user home directories are shareable whereas device lock files are not. "Static" files include binaries, libraries, documentation files and other files that do not change without system administrator intervention. "Variable" files are defined as files that are not static.
/ (root) The root filesystem, represented by the slash symbol by itself, is the primary filesystem from which all other filesystems stem; the top of the hierarchy. All files and directories appear under the root directory "/", even if they are stored on different physical devices. The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system.
/bin/ Essential command binaries that must be available in single user mode; for all users (e.g., cat, ls, cp). /bin/ provides programs that must be available even if only the partition containing / is mounted. This situation may arise should one need to repair other partitions but have no access to shared directories (i.e. you are in single user mode and therefore have no network access). Unlike /sbin, the /bin directory contains several useful commands that are of use to both the root user as well as non-root users.
/boot/ Unshareable, static directory containing the kernel and ramdisk images as well as the bootloader configuration file, and bootloader stages. /boot also stores data that is used before the kernel begins executing userspace programs. This may include saved master boot sectors and sector map files.
/dev/ Essential device nodes created by udev during the boot process and as machine hardware is discovered by events. This directory highlights one important aspect of the
UNIX filesystem - everything is a file or a directory. Exploring this directory will reveal many files, each representing a hardware component of the system. The majority of devices are either block or character devices; however other types of devices exist and can be created. In general, 'block devices' are devices that store or hold data, whereas 'character devices' can be thought of as devices that transmit or transfer data. For example, hard disk drives and optical drives are categorized as block devices while serial ports, mice and USB ports are all character devices.
/etc/ Host-specific, unshareable global configuration files shall be placed in the /etc directory. If more than one configuration file is required for an application, it is customary to use a subdirectory in order to keep the /etc/ area as clean as possible. It is considered good practice to make frequent backups of this directory as it contains all system related configuration files.
- /etc/conf.d/ Some daemon scripts will have a matching configuration file in this directory that contains some useful default values. When a daemon is started, it will first source the settings from its config file within this directory, and then source /etc/rc.conf. Arch's simple, transparent scripting approach means you can easily centralize all your daemon configuration options in your /etc/rc.conf simply by setting an appropriate variable value, or, split up your configuration over multiple files if you prefer a decentralized approach to this issue.
- /etc/rc.d/ All Arch daemons reside here. Custom scripts may also be placed here and invoked from the DAEMONS= array in /etc/rc.conf
- /etc/X11/ Configuration files for the X Window System
- /etc/X11/xinit/ xinit configuration files. 'xinit' is a configuration method of starting up an X session that is designed to be used as part of a script.
- /etc/X11/xinit/xinitrc Global xinitrc file, used by all X sessions started by xinit (startx). Its usage is of course overridden by a .xinitrc file located in the home directory of a user.
UNIX is a multi-user environment. Therefore, each user is also assigned a specific directory that is accessible only to them and to the root user. These are the user home directories, which can be found under '/home/$USER' (~/). Within their home directory, a user can write files, delete them, install programs, etc. Users' home directories contain their data and personal configuration files, the so-called 'dot files' (their name is preceded by a dot), which are 'hidden'. To view dotfiles, enable the appropriate option in your file manager or run ls with the -a switch. If there is a conflict between personal and system wide configuration files, the settings in the personal file will prevail. Dotfiles most likely to be altered by the end user include .xinitrc and .bashrc files. The configuration files for xinit and Bash respectively. They allow the user the ability to change the window manager to be started upon login and also aliases, user-specified commands and environment variables respectively. When a user is created, their dotfiles shall be taken from the /etc/skel directory where system sample files reside.
/home can become quite large as it is typically used for storing downloads, compiling, installing and running programs, mail, collections of multimedia files etc.
/lib/ Contains kernel modules and essential shared library images (the C programming code library) needed to boot the system and run the commands under /bin/ and /sbin/. Libraries are collections of frequently used program routines and are readily identifiable through their filename extension of *.so. They are essential for basic system functionality. Kernel modules (drivers) are in the subdirectory /lib/modules/<kernel-version>.
UNIX-like operating systems must execute a proper shutdown sequence. At times, a system might crash or a power failure might take the machine down. Either way, at the next boot, a filesystem check using the fsck program shall be performed. Fsck will go through the system and try to recover any corrupt files that it finds. The result of this recovery operation will be placed in this directory. The files recovered are not likely to be complete or make much sense but there always is a chance that something worthwhile is recovered.
/media/ Mount points for removable media. CDROMs, DVD's, and USB sticks shall have an appropriate mount point under /media/. The motivation for the creation of this directory has been that historically there have been a number of other different places used to mount removeable media such as /cdrom, /mnt or /mnt/cdrom. Placing the mount points for all removable media directly in the root directory would potentially result in a large number of extra directories in /. Although the use of subdirectories in /mnt as a mount point has recently been common, it conflicts with a much older tradition of using /mnt directly as a temporary mount point. Therefore, Arch allocates /media as the mountpoint for removable media. On systems where more than one device exists for mounting a certain type of media, mount directories shall be created by appending a digit to the name of those available above starting with '0', but the unqualified name must also exist.
The "hal" (Hardware Abstraction Layer) daemon mounts removable media to /media as /media/<name_of_removable_filesystem>
/mnt/ This is a generic mount point for temporary filesystems or devices. Mounting is the process of making a filesystem available to the system. After mounting, files will be accessible under the mount-point. Additional mount-points (subdirectories) may be created under /mnt/. There is no limitation to creating a mount-point anywhere on the system, but by convention and for practicality, littering a file system with mount-points should be avoided.
/opt/ Packages and large static files that do not fit cleanly into the above GNU filesystem layout can be placed in /opt. A package placing files in the /opt/ directory creates a directory bearing the same name as the package. This directory in turn holds files that otherwise would be scattered throughout the file system. 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 Arch places all the files in a subdirectory of /opt.
/proc/ /proc is very special in that it is also a virtual filesystem. It is sometimes referred to as the process information pseudo-file system. It doesn't contain 'real' files, but rather, runtime system information (e.g. system memory, devices mounted, hardware configuration, etc). For this reason it can be regarded as a control and information center for the kernel. In fact, quite a lot of system utilities are simply calls to files in this directory. For example, 'lsmod' is the same as 'cat /proc/modules' while 'lspci' is a synonym for 'cat /proc/pci'. By altering files located in this directory, kernel parameters may be read/changed (sysctl) while the system is running.
The most distinctive facet about files in this directory is the fact that all of them have a file size of 0, with the exception of kcore, mounts and self.
/root/ Home directory of the System Administrator, 'root'. This may be somewhat confusing, ('/root under root') but historically, '/' was root's home directory (hence the name of the Administrator account). To keep things tidier, 'root' eventually got his own home directory. Why not in '/home'? Because '/home' is often located on a different partition or even on another system and would thus be inaccessible to 'root' when - for some reason - only '/' is mounted.
UNIX discriminates between 'normal' executables and those used for system maintenance and/or administrative tasks. The latter reside either here or - the less important ones - in /usr/sbin. Programs executed after /usr is known to be mounted (when there are no problems) are generally placed into /usr/sbin. This directory contains binaries that are essential to the working of the system. These include system administration as well as maintenance and hardware configuration programs. grub (the command), fdisk, init, route, ifconfig, etc., all reside here.
/srv/ Site-specific data which is served by the system. The main purpose of specifying this is so that users may find the location of the data files for a particular service, and so that services which require a single tree for readonly data, writable data and scripts (such as cgi scripts) can be reasonably placed. Data of interest to a specific user shall be placed in that user's home directory.
/tmp This directory contains files that are required temporarily. Many programs use this to create lock files and for temporary storage of data. Do not remove files from this directory unless you know exactly what you are doing! Many of these files are important for currently running programs and deleting them may result in a system crash. On most systems, this directory is cleared out at boot or at shutdown by the local system. The basis for this was historical precedent and common practice.
/usr/ While root is the primary filesystem, /usr is the secondary hierarchy, for user data, containing the majority of (multi-)user utilities and applications. /usr is shareable, read-only data. This means that /usr shall be shareable between various hosts and must not be written to, except in the case of system administrator intervention (installation, update, upgrade). Any information that is host-specific or varies with time is stored elsewhere.
Aside from /home/, /usr/ usually contains by far the largest share of data on a system. Hence, this is one of the most important directories in the system as it contains all the user binaries, their documentation, libraries, header files, etc. X and its supporting libraries can be found here. User programs like telnet, ftp, etc., are also placed here. In the original
UNIX implementations, /usr/ (for user), was where the home directories of the system's users were placed (that is to say, /usr/someone was then the directory now known as /home/someone). Over time, /usr/ has become where userspace programs and data (as opposed to 'kernelspace' programs and data) reside. The name has not changed, but its meaning has narrowed and lengthened from everything user related to user usable programs and data. As such, the backronym 'User System Resources' was created.
- /usr/bin/ Non-essential command binaries (not needed in single user mode); for all users. This directory contains the vast majority of binaries (applications) on your system. Executables in this directory vary widely. For instance vi, gcc, and gnome-session reside here.
- /usr/include/ Header files needed for compiling userspace source code..
- /usr/lib/ Libraries for the binaries in /usr/bin/ and /usr/sbin/.
- /usr/sbin/ Non-essential system binaries of use to the system administrator. This is where the network daemons for the system reside, along with other binaries that (generally) only the system administrator has access to, but which are not required for system maintenance and repair. Normally, these directories are never part of normal user's $PATHs, only of root's (PATH is an environment variable that controls the sequence of locations that the system will attempt to look in for commands).
- /usr/share/ This directory contains 'shareable', architecture-independent files (docs, icons, fonts etc). Note, however, that '/usr/share' is generally not intended to be shared by different operating systems or by different releases of the same operating system. Any program or package which contains or requires data that don't need to be modified should store these data in '/usr/share/' (or '/usr/local/share/', if manually installed - see below). It is recommended that a subdirectory be used in /usr/share for this purpose.
- /usr/src/ The 'linux' sub-directory holds the Linux kernel sources, and header-files.
- /usr/local/ Optional tertiary hierarchy for local data. The original idea behind '/usr/local' was to have a separate ('local') '/usr/' directory on every machine besides '/usr/', which might be mounted read-only from somewhere else. It copies the structure of '/usr/'. These days, '/usr/local/' is widely regarded as a good place in which to keep self-compiled or third-party programs. This directory is empty by default in Arch Linux. It may be used for manually compiled software installations if desired. Pacman installs to /usr/, therefore, manually compiled/installed software installed to /usr/local/ may peacefully co-exist with pacman-tracked system software.
/var/ Variable files, such as logs, spool files, and temporary e-mail files. On Arch, the ABS tree and pacman cache also reside here. Why not put the variable and transient data into /usr/? Because there might be circumstances when /usr/ is mounted as read-only, e.g. if it is on a CD or on another computer. '/var/' contains variable data, i.e. files and directories the system must be able to write to during operation, whereas /usr/ shall only contain static data. Some directories can be put onto separate partitions or systems, e.g. for easier backups, due to network topology or security concerns. Other directories have to be on the root partition, because they are vital for the boot process. 'Mountable' directories are: '/home', '/mnt', '/tmp', '/usr' and '/var'. Essential for booting are: '/bin', '/boot', '/dev', '/etc', '/lib', '/proc' and '/sbin'.
- /var/abs/ The ABS tree. A ports-like package build system hierarchy containing build scripts within subdirectories corresponding to all installable Arch software.
- /var/cache/pacman/pkg/ The pacman package cache.
- /var/lib/ State information. Persistent data modified by programs as they run (e.g. databases, packaging system metadata etc.).
- /var/lock/ Unsharable Lock files data. Files keeping track of resources currently in use.
- /var/log/ Log files.
- /var/mail/ Shareable directory for users' mailboxes.
- /var/run/ Unshareable data about the running system since last boot (e.g. currently logged-in users and running daemons).
- /var/spool/ Spool for tasks waiting to be processed (e.g. print queues and unread mail).
- /var/spool/mail/ Deprecated location for users' mailboxes.
- /var/tmp/ Temporary files to be preserved between reboots.
Arch Boot Process
After the initial POST, the BIOS directs the computer to load a boot sector from the hard drive. Actually, a small program called GRUB stage1 is within this sector. This is a tiny program. Its only function is to load GRUB stage1.5 or stage2 (depending on filesystem type).
GRUB stage1.5/stage2 will present a boot menu with various (customizable) choices of operating systems to boot. The path to the device, partition and filename of the kernel and initial ram filesystem is contained for GRUB in /boot/grub/menu.lst.
After choosing an Arch Linux entry, GRUB loads the Linux kernel. The kernel is the core of an operating system. It functions on a low level (kernelspace) interacting between the hardware of the machine, and the programs which use the hardware to run. To make efficient use of the cpu, the kernel uses a scheduler to arbitrate which tasks take priority at any given moment, creating the illusion (to human perception) of many tasks being executed simultaneously.
After the kernel is loaded, it reads from the initramfs. The purpose of the initramfs is to bootstrap the system to the point where it can access the root filesystem. This means it has to load any modules that are required for devices like IDE, SCSI, or SATA drives (or USB/FW, if you are booting off a USB/FW drive). Once the initramfs loads the proper modules, either manually or through udev, it passes control to the kernel and the boot process continues. For this reason, the initrd only needs to contain the modules necessary to access the root filesystem. It does not need to contain every module you would ever want to use. The majority of your everyday modules will be loaded later on by udev, during the init process.
The kernel then looks for the program
init which resides at
init relies on
glibc, the GNU C library. Libraries are collections of frequently used program routines and are readily identifiable through their filename extension of *.so. They are essential for basic system functionality. This part of the boot process is called early userspace.
The purpose of
init is to bring (and keep) the system up into a usable state. It uses the boot scripts to do so. As you may be aware, Arch uses BSD-style boot scripts.
init reads the file
/etc/inittab, which tells it what to do. Looking over the
inittab script, you will find that the first uncommented line defines the default system runlevel, or, 3. The next thing it is told to do is to run an initialization script. The program that executes (or interprets) this script is bash, the same program that gives you a command prompt. In Arch Linux, the main initialization script is
/etc/inittab also defines your virtual consoles, which are 'respawned' by
/sbin/init if terminated. Lastly,
inittab defines a login manager, if starting the system at runlevel 5 is desired. By default the login manager is also respawned by
/sbin/init if terminated.
init to call the first boot script,
/etc/rc.sysinit, after which
/etc/rc.multi will be called (in a normal boot). The last script to run will be
/etc/rc.local, which is empty by default.
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 boot 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/inittab (covered above)
The main system boot script, which mounts filesystems, runs udev, activates swap, loads modules, sets localization parameters, etc. When called, udev shall probe system hardware, loading appropriate kernel modules and creating device nodes under /dev. For more, open /etc/rc.sysinit in your editor of choice; the file is well commented.
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 is usually quite useless.
Multi-user startup script. It starts all daemons (such as a logger, a network script, etc) specified in the DAEMONS= array in /etc/rc.conf, after which it calls /etc/rc.local.
Local multi-user startup script. Empty by default. It is a good place to put any last-minute commands you want the system to run at the very end of the boot process. 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 is not already residing in /etc/profile.d/, or any other existing configuration location instead.
/etc/profile This script is run on each user login to initialize the system. It globally defines PS1, $PATH, bash aliases, etc. It is kept quite simple under Arch Linux, as most things are. You may wish to edit or customize it to suit your needs.
System shutdown script. It stops daemons, unmounts filesystems, deactivates the swap, etc.
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 boot, you can use these scripts when the system is running to manage the services of your system. For example the command
will stop the postfix daemon. This directory is not in the $PATH by default, but may be added for convenience. Obviously a corresponding daemon script only exists when the appropriate package has been installed (in this case postfix). With a base system install, there are few scripts in here, but rest assured that all relevant daemon scripts end up here. If you wish, you can, of course, create your own scripts and place them here, to be called by the DAEMONS= array in /etc/rc.conf on system startup.
This directory is pretty much the equivalent to the /etc/rc3.d/ or /etc/init.d/ directories of other distributions, but without all the symlink hassle. The lack of symlink requirement is a defining difference of a *BSD-style init framework, vs a sysvinit.
agetty and login
After the Arch boot scripts are completed, the
agetty program prompts you for a login name. After a login name is received,
login to prompt for the login password.
Finally, with a successful login, the
login program starts your default shell. The default shell and environment variables may be globally defined within /etc/profile. All variables within a users home directory shall take precedence over those globally defined under /etc. For instance, if 2 conflicting variables are specified within /etc/profile and ~/.bashrc, the one dictated by ~/.bashrc shall prevail.
For more, see The Arch boot process
Maintaining the system
su or su - ?
The default behavior of
is to remain within the current directory and to maintain the environmental variables of the original user (rather than switch to those of the new user). It sometimes can be advantageous for a system administrator to use the shell account of an ordinary user rather than its own. In particular, occasionally the most efficient way to solve a user's problem is to log into that user's account in order to reproduce or debug the problem.
However, in many situations it is not desirable, or it can even be dangerous, for the root user to be operating from an ordinary user's shell account and with that account's environmental variables rather than from its own. While inadvertently using an ordinary user's shell account, root could install a program or make other changes to the system that would not have the same result as if they were made while using the root account. For instance, a program could be installed that could give the ordinary user power to accidentally damage the system or gain unauthorized access to certain data.
Thus, it is advisable that administrative users, as well as any other users that are authorized to use su (of which there should be very few, if any), acquire the habit of always following the su command with a space and then a hyphen. (login shell option) The hyphen has two effects: (1) it switches from the current directory to the home directory of the new user (e.g., to /root in the case of the root user) by logging in as that user, and (2) it changes the environmental variables to those of the new user as dictated by their ~/.bashrc. That is, if the first argument to su is a hyphen, the current directory and environment will be changed to what would be expected if the new user had actually logged on to a new session (rather than just taking over an existing session).
Thus, administrators should generally use su as follows:
$ su -
An identical result is produced by adding the username root, i.e.,
$ su - root
Likewise, the same can be done for any other user, e.g., for a user named archie:
# su - archie
Pacman is both a binary and source package manager which is able to download, install, and upgrade packages from both remote and local repositories with full dependency handling, and has easy-to-understand tools for crafting your own packages too.
A more-detailed description of Pacman can be found in its article.
To view the options available for a particular operational command, say -Q, just append it with -h:
To synchronize and update the local packages database with the remote repositories (it is a good idea to do this before installing and upgrading packages):
To upgrade all packages on the system:
To sync, update, and upgrade all the packages on the system with one command:
To install or upgrade a single package or list of packages (including dependencies):
pacman -S packageA packageB
You can also sync, update the package database, and install packages in one command:
pacman -Sy packageA packageB
To remove a single package, leaving all of its dependencies installed:
pacman -R package
To remove a package and all of the package's dependencies which are not used by any other installed package:
pacman -Rs package
(-Rs is typically preferred vs R to remove any package as it will clean up all unused dependencies)
To remove all of the package's now unneeded dependencies and also instruct pacman to ignore file backup designations. (Normally, when a file is removed from the system the database is checked to see if the file should be renamed with a ".pacsave" extension.):
pacman -Rsn package
To search the remote (repo) package database for a list of packages matching a given keyword:
pacman -Ss keyword
List all available packages in a given repo. e.g., core:
pacman -Sl core
To list all packages on your system
To list all packages on your system without the version strings, we add the -q option:
To search (query) the local (your machine) package database for a given package:
pacman -Q package
To search (query) the local (your machine) package database for a given package and list all pertinent information:
pacman -Qi package
To list all files installed by a given package:
pacman -Ql package
Conversely, to find the package that owns a given file (in this example, the ls executable):
pacman -Qo /bin/ls
List all unused packages no longer required as dependencies, (orphans):
Remove all orphans: (Recommended for experienced users only.)
pacman -Rsn $(pacman -Qdtq)
Missing libraries: Suppose you receive an error message like this:
mplayer: error while loading shared libraries: libgssapi.so.2: cannot open shared object file: No such file or directory
This may be an indication that a package you have previously installed is now corrupt (some or all of its files are missing). You should try to find the package name that provides the missing shared library. In this example, you could type:
pacman -Ql | grep libgssapi.so.2
The first column in the output is the package name:
heimdal /usr/lib/libgssapi.so.2 heimdal /usr/lib/libgssapi.so.2.0.0
Then, you can just re-install it:
pacman -Sy heimdal
To defragment pacman's cache database and optimize for speed:
To count how many packages are currently on your system:
pacman -Q | wc -l
To install a package compiled from source using ABS and makepkg:
pacman -U packagename.pkg.tar.gz
Note: There are countless additional pacman functions and commands. Try man pacman and consult the pacman wiki entries.
There are a number of files left and created by pacman and other programs to facilitate maintenance and to conform to a safe computing practice. When pacman is installing something, the package contains information on whether to back up a particular file. Such files will have the .pacsave extension. When you force a "NoUpgrade" on a file via pacman.conf, it will not be replaced during an upgrade and the new file will come with the .pacnew extension. For example, you have edited a configuration file thoroughly and you do not want an upgrade of the respective package to replace the file with a new one, we must have the following line in /etc/pacman.conf:
NoUpgrade = /path/to/config/file
To view the differences of the old and new versions of these files, we can either edit them manually or use a diff utility to take note of the differences. There is an automated tool to find and view such files available from the community repository:
pacman -S pacman-contrib cd ~/ pacdiff # as root
There is a bug in the above tool where if you navigate to /etc and run it from there, the paths will be messed up. We remain on the safer side by being at "home". You may want to run it as user first in case you happen to be a careless person (you may just overwrite or remove files because you think that is the right way).
There are other types of leftovers depending on the programs available on your system. Some will create backups with a .bak extension, while others with something like "~" or "-". Unfortunately, there is currently no way to "automatically" find and review them. Fear not, as we have no need for automated tools to deal with such trivial tasks. Simply use locate to search for them:
locate -e *.~ *.- *.bak
And we can use something useful like vimdiff to look at the differences manually:
pacman -S vim vimdiff file1 file2
Since you have now installed a desktop environment/window manager, and if you did not do so earlier, now would be a good time to also install HAL. HAL allows plug-and-play for your mobile phone, your iPod, your external HD's, etc. It will mount the device and make a nice visual icon on your desktop and/or in 'My Computer', allowing you to access the device after you have plugged it in instead of having to manually configure the /etc/fstab file or udev rules for each and every new device.
KDE, GNOME and XFCE all use HAL.
Backgrounding DAEMONS on startup
To speed up system start up procedure, background selected DAEMONS in /etc/rc.conf by prefixing them with a '@' e.g.:
DAEMONS=(syslog-ng @network crond @alsa @hal @fam @kdm)
This will enable daemons to load in the background, without waiting for the preceding daemon to load first. In some cases, this may cause issues, especially if you require daemons to start in the specified order.
Prefix any daemons which you do not need with a bang (!) e.g.:
DAEMONS=(syslog-ng @network !netfs !crond @alsa @hal @fam @kdm)
(Alternatively, you may also simply remove unneeded daemons from the array).
Turn off Control Echo in Bash
Some users may have noticed that since the readline update their terminal has been displaying ^C after ctrl+c has been pressed. While this is not a problem, it can be annoying. For any users who wish to disable this, simply add the following to /etc/profile or $HOME/.bash_profile:
Beautifying Fonts for LCD's
Adjusting Mouse for scroll wheel
While your mouse should be working out of the box, you may want to use your scroll wheel. Add this to your Input Section (mouse0):
Option "ZAxisMapping" "4 5 6 7"
Get All Mouse Buttons Working
Configuring Touchpad for Laptops
Adjusting Keyboard Layout
You may want to change your keyboard layout. To do this edit your /etc/X11/xorg.conf and add these lines in the InputDevice Section (Keyboard0) (the example shows a German keyboard layout with no dead keys; alter this to fit your needs).
Option "XkbLayout" "de" Option "XkbVariant" "nodeadkeys"
Additional tweaks for laptops
ACPI support is needed if you want to use some special functions on your notebook (e.g. sleep, sleep when lid is closed, special keys...). Install acpid using
pacman -S acpid
and add it to the daemons in /etc/rc.conf. If you already have hal specified in your DAEMONS, there is no need to add acpid. HAL will automatically detect and load the acpid daemon. Manually, it can be started by
More-specific information about Arch Linux on various Laptops can be found at Category:Laptops (English)
Configuring CPU frequency scaling
Modern processors can decrease their frequency and voltage to reduce heat and power consumption. Less heat leads to a quieter system; Laptop users will definitely want this, but even a desktop system will benefit from it. Install cpufrequtils with
pacman -S cpufrequtils
Edit the config file /etc/conf.d/cpufreq and change
which dynamically increases the CPU frequency if needed (which is a safe choice on desktop systems too). Alter min_freq and max_freq to match your system's CPU spec. If you do not know the frequencies, run cpufreq-info after loading one of the frequency scaling modules. You can also comment out or delete the min_freq and max_freq lines: things will work automatically. Add the frequency scaling modules to your /etc/rc.conf modules line. Most modern notebooks and desktops can simply use the acpi-cpufreq driver, however other options include the p4-clockmod, powernow-k6, powernow-k7, powernow-k8, and speedstep-centrino drivers. Load the module with
and start cpufreq with
For more details, see Cpufrequtils
The pm-utils package will allow you to suspend-to-RAM and hibernate:
pacman -S pm-utils
Pm-utils wiki page.
The laptop-mode-tools package is sort of a one-stop configuration for all laptop power management utilities. It works in conjunction with other installed tools to fully configure everything from hard disk spin-down to X display DPMS standby times, if desired.
pacman -S laptop-mode-tools
Add laptop-mode to your DAEMONS= line in /etc/rc.conf and configure /etc/laptop-mode/laptop-mode.conf.
Add additional repositories
In several special cases, a package may not be in the official repositories for certain reasons, e.g. size or popularity. In these cases, you might find a specialized user repository that maintains the package you want. See Unofficial user repositories for a maintained list of additional repos. Be aware that using the packages you want from AUR might be better in some cases, depending on the type of package you want.
Polishing & Further information
For more information on the jargon used in Arch, see Arch Terminology/Jargon for newbies
Where to go from here?
You may also be interested in:
- Post Installation Tips
- ArchLinux User-community Repository (AUR)
- Get All Mouse Buttons Working
- Improve Pacman Performance
- Kernel Compilation
- Eye Candy
- Useful Applications