https://wiki.archlinux.org/api.php?action=feedcontributions&user=Daenyth&feedformat=atom
ArchWiki - User contributions [en]
2024-03-29T06:49:25Z
User contributions
MediaWiki 1.41.0
https://wiki.archlinux.org/index.php?title=Talk:VCS_package_guidelines&diff=101227
Talk:VCS package guidelines
2010-03-26T20:35:06Z
<p>Daenyth: Removed outdated cruft</p>
<hr />
<div>Q: Any reason for using 'svn co' instead of 'svn export'? export is way faster for these situations and it doesn't create all the .svn files.<br />
<br />
A: Look at http://bbs.archlinux.org/viewtopic.php?pid=245213<br />
----<br />
<br />
What's the reason for using 'cp -r $_svnmod $_svnmod-build' instead of using 'svn export $_svnmod $_svnmod-build'?--[[User:BertiBoeller|BertiBoeller]] 19:21, 15 March 2009 (EDT)<br />
<br />
-- no reason afaik. Please send a patch against /usr/share/pacman/PKGBUILD-svn.proto from abs package to the bug tracker. --[[User:Shining|shining]] 07:59, 4 October 2009 (EDT)<br />
<br />
----<br />
<br />
Please submit the Mercurial proto to flyspray so that it can be added to abs package.<br />
--[[User:Shining|shining]] 17:37, 18 December 2009 (EST)</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Arch_terminology&diff=101181
Arch terminology
2010-03-25T21:07:12Z
<p>Daenyth: /* versionpkg */ Delete -- built into makepkg</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:General (English)]]<br />
This page is intended to be a page to demystify common terms used among the Arch Linux community. Feel free to add or modify any terms, but please use that particular section's edit option. If you decide to add one, please put it in alphabetical order.<br />
<br />
==Arch Linux==<br />
Arch should be referred to as:<br />
*'''Arch Linux'''<br />
*'''Arch''' (Linux implied)<br />
*'''archlinux''' (UNIX name)<br />
<br />
Archlinux, ArchLinux, archLinux, aRcHlInUx, and etc are all weird, and weirder mutations.<br />
<br />
Officially, the 'Arch' in "Arch Linux" is pronounced as in an "archer"/bowman, or "arch-nemesis", and not as in "ark" or "archangel".<br />
<br />
==ABS==<br />
The Arch Build System (ABS for short) is useful to:<br />
<br />
* Make new packages of software for which no packages are yet available<br />
* Customize/Modify existing packages to fit your needs (enabling or disabling options)<br />
* Re-build your entire system using your compiler flags, "a la Gentoo" <br />
* Getting kernel modules working with your custom kernel<br />
<br />
ABS is not necessary to use Arch Linux, but it is useful. <br />
<br />
For more information see the [[ABS]] page<br />
<br />
==The AUR==<br />
The Arch Linux User Community Repository (AUR) is a community driven repository for Arch users. The AUR was initially conceived to organize the sharing of PKGBUILDs amongst the wider community and to expedite the inclusion of popular user-contributed packages into the [core] and [extra] repos via the AUR [community] repo. <br />
<br />
The AUR is the birthplace of new Arch packages. Users contribute their own packages to the AUR. The AUR community votes for their favourite packages and eventually, once a package has garnered enough votes, an AUR Trusted User may take it to the [community] repository, which is accessible via pacman and ABS.<br />
<br />
You can access the Arch Linux User Community Repository [http://aur.archlinux.org here]<br />
<br />
==PKGBUILD==<br />
PKGBUILDs are small scripts that are used to build Arch Linux packages. See [[Creating Packages]] for more detail.<br />
<br />
==TU, Trusted User==<br />
A Trusted User is someone who maintains the AUR and the [community] repository.<br />
Trusted Users may move a package into the [community] repository if it has been voted as popular.<br />
TUs are appointed by a majority vote by the existing TUs.<br />
<br />
Trusted users follow the [[AUR Trusted User Guidelines]] and [http://archlinux.org/~simo/TUbylaws.html TU by-laws]<br />
<br />
==TUR, Trusted User Repository (obsolete)==<br />
Before the AUR and [community], TUs had their own repositories with applications that weren't available in the official ones. Anyone can make a repository, but TURs were thought to be of higher quality, because TUs are voted for their knowledge and effort.<br />
<br />
==bbs==<br />
''B''ulletin ''b''oard ''s''ystem, but in Arch's case it's just the support forum located at http://bbs.archlinux.org.<br />
<br />
==community/[community]==<br />
The community repository is where pre-built packages are made available by Trusted Users. A majority of the packages in community, come from the AUR.<br />
<br />
To access the community repository, uncomment it in /etc/pacman.conf.<br />
<br />
==core/[core]==<br />
The Core repository contains the bare packages needed for an Arch System. It has everything needed to get a working command line system<br />
<br />
==custom/user repository==<br />
Anyone can create a repo and put it online for other users. To create a repository, you need a set of packages and a pacman compatible database file for your packages. Host your files online and everyone will be able to use your repo by adding it as a regular repository.<br />
<br />
See [[Custom local repository]].<br />
<br />
==developer==<br />
Half gods working to improve Arch for no financial gain. Developers are outranked only by our god, Judd Vinet, who in turn is outranked by pizza.<br />
<br />
==devfs==<br />
The ''dev''ice ''f''ile ''s''ystem. DevFS handles, dynamically, the creation, deletion and permission management of device nodes in the /dev directory. It was the default kernel device manager in Arch Linux until release 0.7. Now DevFS is deprecated and in the process of being removed from the Linux kernel. DevFS has been superseded by [[udev]].<br />
<br />
Note that Arch installation CDs prior to 0.7.1 use the devfs naming scheme when creating /etc/fstab entries.<br />
<br />
==/etc/network-profiles==<br />
In this, you can create various network configurations.<br />
<br />
This is very useful for laptop users that switch networks very often, for example between a home and an office network.<br />
<br />
Additionally it can be used with wpa-supplicant that can manage all of you wireless networks.<br />
For each configuration you need to make a configuration file. The easiest way to do this, is by copying the template.<br />
After you are done with this, you need to enable these in /etc/rc.conf<br />
<br />
After applying changes, you should restart your network by using, as root,<br />
/etc/rc.d/network restart<br />
<br />
==/etc/rc.conf==<br />
/etc/rc.conf is the main system configuration file for Arch Linux. It allows you to set your keyboard, timezone, hostname, network, daemons to run and modules to load at bootup, profiles, and more. Detailed description of the configuration options is given here: [[Rc.conf]]<br />
<br />
==/etc/rc.d==<br />
/etc/rc.d is a directory that contains the scripts that handle starting and stopping of services. On every boot, the services that are present in the DAEMONS= array in /etc/rc.conf are started by running the corresponding scripts in /etc/rc.d.<br />
<br />
It is also possible to control the services from the command line (as root), e.g.,<br />
<br />
/etc/rc.d/cups start<br />
<br />
would start the CUPS daemon. Typical arguments for the scripts are start, stop and restart.<br />
<br />
==/etc/rc.local==<br />
This script is run at the end of every boot. It is intended for miscellaneous commands that you might want to execute before the login prompt. It is not recommended to add any services or settings in /etc/rc.local that could be started or set from /etc/rc.conf instead.<br />
<br />
==extra/[extra]==<br />
Arch's official package set is fairly streamlined, but we supplement this with a larger, more complete "extra" repository that contains a lot of the stuff that never made it into our core package set. This repository is constantly growing with the help of packages submitted from our strong community.<br />
This is where desktop environments, window managers and common programs are found.<br />
<br />
==hwd==<br />
Hwd; hardware detect for Arch Linux, is for both devfs and udev device systems and also for kernels 2.4.x and 2.6.x. Instead of running an auto configure script which may be expected, Hwd (/usr/bin/hwd) doesn't change existing configurations. It detects hardware and modules, and provides information on how to make changes manually. This allows the user to have control over his/her system; the basic philosophy of Arch Linux.<br />
<br />
Hwd is available in the [http://aur.archlinux.org/packages.php?ID=26913 AUR].<br />
<br />
==hwdetect==<br />
<br />
==initramfs==<br />
<br />
==initrd==<br />
The special file /dev/initrd is a read-only block device. Device /dev/initrd is a RAM disk that is initialized (e.g. loaded) by the boot loader before the kernel is started. The kernel then can use the block device /dev/initrd's contents for a two phased system boot-up.<br />
<br />
In the first boot-up phase, the kernel starts up and mounts an initial root file-system from the contents of /dev/initrd (e.g. RAM disk initialized by the boot loader). In the second phase, additional drivers or other modules are loaded from the initial root device's contents. After loading the additional modules, a new root file system (i.e. the normal root file system) is mounted from a different device.<br />
<br />
==makepkg==<br />
makepkg will build packages for you. makepkg will read the metadata required from a PKGBUILD file.<br />
All it needs is a build-capable linux platform, wget, and some build scripts. The advantage to a script-based build is that you only really do the work once. Once you have the build script for a package, you just need to run makepkg and it will do the rest: download and validate source files, check dependencies, configure the build time settings, build the package, install the package into a temporary root, make customizations, generate meta-info, and package the whole thing up for pacman to use.<br />
<br />
==namcap==<br />
namcap is a package analysis utility that looks for problems with Arch Linux packages or their PKGBUILD files. It can apply rules to the file list, the files themselves, or individual PKGBUILD files.<br />
<br />
Rules return lists of messages. Each message can be one of three types: error, warning, or information (think of them as notes or comments). Errors (designated by 'E:') are things that namcap is very sure are wrong and need to be fixed. Warnings (designated by 'W:') are things that namcap thinks should be changed but if you know what you're doing then you can leave them. Information (designated 'I:') are only shown when you use the info argument. Information messages give information that might be helpful but isn't anything that needs changing.<br />
<br />
==package==<br />
A package is an archive containing<br />
* all the (compiled) files of an application<br />
* metadata about the application, such as application name, version, dependencies, ...<br />
* installation files and directives for pacman<br />
* (optionally) extra files to make your life easier, such as a start/stop script<br />
Arch's package manager pacman can install, update and remove programs cleanly those packages. Using packages instead of compiling and installing programs yourself has various benefits:<br />
* easily updatable: pacman will update existing packages as soon as updates are available<br />
* dependency checks: pacman handles dependencies for you, you only need to specify the program and pacman installs it together with every other program it needs<br />
* clean removal: pacman has a list of every file in a package. This way no files are left behind when you decide to remove a package<br />
Note: different GNU/Linux distributions use different packages and package manager, meaning that you can't use pacman to install a Debian package on Arch.<br />
<br />
==pacman==<br />
The [[Pacman]] package manager is one of the great highlights of Arch Linux. It combines a simple binary package format with an easy-to-use build system (see [[ABS]]). Pacman makes it possible to easily manage and customize packages, whether they be from the official Arch repositories or the user's own creations. The repository system allows users to build and maintain their own custom package repositories, which encourages community growth and contribution (see [[AUR]]). <br />
<br />
Pacman can keep a system up to date by synchronizing package lists with the master server, making it a breeze for the security-conscious system administrator to maintain. This server/client model also allows you to download/install packages with a simple command, complete with all required dependencies (similar to Debian's apt-get). <br />
<br />
NB: Pacman was written by Judd Vinet, the creator of Arch Linux. It is used as a package management tool by other distros as well, such as FrugalWare, Rubix, UfficioZero (in Italian, based on Ubuntu), and, of course, Arch Linux derivatives such as Archie and AEGIS.<br />
<br />
==pacman.conf==<br />
This is the configuration file of pacman. It's located in /etc. For a full explanation of its powers, type this at the command line:<br />
man pacman.conf<br />
<br />
==release/[release]==<br />
Release repository follows the semi-regular snapshot releases and does not update until the next snapshot/iso has been released. For example, the Release repository will point to all packages on the 0.5 ISO until we release 0.6; then it will point to 0.6 packages until 0.7 is released. This is useful if you only want to update your system when a new release is available.<br />
<br />
==repository/repo==<br />
The repository has the pre-compiled packages of one or (usually) more PKGBUILDs. Official repositories are<br />
* core: containing the latest version of packages required for a full CLI system<br />
* extra: containing the latest version of packages not needed for a working system, but needed for an enjoyable system ;)<br />
* community: containing packages that came from [http://aur.archlinux.org AUR] and got enough user votes<br />
Pacman uses these repositories to search for packages and install them. A repository can be local (i.e. on your own computer) or remote (i.e. the packages are downloaded before they're installed).<br />
<br />
==[[Wikipedia:RTFM|RTFM]]==<br />
"Read The Fucking (or Fine) Manual". This simple message is replied to a lot of new Linux/Arch users who ask about the functionality of a program when it is clearly defined in the program's manual.<br />
<br />
It is often used when a user fails to make any attempt to find a solution to the problem themselves. If someone tells you this, they are not trying to offend you, they are just frustrated with your lack of effort. <br />
<br />
The best thing to do if you are told to do this is to read the manual page.<br />
* To read the program manual page for a particular program, type this at the command line:<br />
man PROGRAM-NAME<br />
<br />
where PROGRAM-NAME is the name of the program you need more information about.<br />
<br />
If you do not find the answer to your question in the program manual, there are more ways to find the answer. You can:<br />
* search the [[Special:Search|wiki]]<br />
* search the [http://bbs.archlinux.org forum]<br />
* search the [http://www.google.com/#hl=en&q=arch+site%3Ahttp%3A%2F%2Fwww.archlinux.org%2Fpipermail%2F mailing lists]<br />
* search the [http://www.google.com web]<br />
<br />
==taurball==<br />
The tarballed PKGBUILD and local source files that are required by makepkg to create an installable binary package. The name derives from the practice of uploading such tarball to the AUR, whence "tAURball".<br />
<br />
==testing/[testing]==<br />
This is the repo where major packages/updates to packages are kept prior to release into the main repos, so they can be bug tested and upgrade issues can be found. It is disabled by default, but can be enabled in <code>/etc/pacman.conf</code><br />
<br />
==udev==<br />
[[udev]] provides a dynamic device directory containing only the files for actually present devices. It creates or removes device node files in the /dev directory, or it renames network interfaces.<br />
<br />
Usually udev runs as udevd(8) and receives uevents directly from the kernel if a device is added/removed from/to the system.<br />
<br />
If udev receives a device event, it matches its configured rules against the available device attributes provided in sysfs to identify the device. Rules that match may provide additional device information or specify a device node name and multiple symlink names and instruct udev to run additional programs as part of the device event handling.<br />
<br />
==[[Wikipedia:Wiki|wiki]]==<br />
[[Main Page|This!]] A place to find documentation about Arch Linux. Anyone can add and modify the documentation.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Gaming&diff=101165
Gaming
2010-03-25T15:43:47Z
<p>Daenyth: /* Getting games */ Changed arch-games url</p>
<hr />
<div>==Running games in Arch==<br />
<br />
For the most part, games will work right out of the box in Arch Linux with possibly better performance than on other distributions due to compile time optimizations. However, some special setups may require a bit of configuration or scripting to make games run as smoothly as desired. For instance, running a multi-screen setup may lead to problems with fullscreen games. In such a case, [[#Starting_games_in_a_seperate_X_server|running a second X server]] is one possible solution. Another solution may be found in the [[NVIDIA#Gaming_using_Twinview|NVIDIA article]] (may also apply to non-NVIDIA users).<br />
<br />
==Getting games==<br />
<br />
While a lot of games can currently be found in the official repositories, not all current Linux games are packaged there. Some of them can only be found on [[AUR]]. However, there is a dedicated [http://archlinux-gaming.org Arch Linux gaming repository] that addresses this by providing pre-compiled packages from AUR. <br />
<br />
===Arch Linux gaming repository===<br />
<br />
To make use of the gaming repo, add these to your pacman.conf:<br />
[arch-games]<br />
# The Arch Linux Gaming repository project<br />
Server = http://arch.twilightlair.net/games/i686<br />
Server = http://pseudoform.org/arch-games/games/i686<br />
Don't forget to change the arch at the end to x86_64 if applicable.<br />
<br />
== Executing Games ==<br />
<br />
Certain games or game types may need special configuration to run or to run as expected.<br />
<br />
=== Starting games in a separate X server ===<br />
<br />
In some cases like those mentioned above, it may be necessary or desired to run a second X server. Running a second X server has multiple advantages such as better performance, the ability to "tab" our of your game by using CTRL-ALT-F7 / CTRL-ALT-F8, no crashing your primary X session (which may have open work) in case a game conflicts with the graphics driver. To start a second X server (using Nexuiz as an example) you can simply do: <br />
xinit /usr/bin/nexuiz-glx -- :1<br />
This can further be spiced up by using a seperate X configuration file:<br />
xinit /usr/bin/nexuiz-glx -- :1 -xf86config xorg-game.conf <br />
A good reason to provide an alternative xorg.conf here may be that your primary configuration makes use of NVIDIA's Twinview which would render your 3D games like Nexuiz in the middle of your multiscreen setup, spanned across all screens. This is undesirable, thus starting a second X with an alternative config where the second screen is disabled is advised.<br />
<br />
A game starting script making use of Openbox for your home directory or /usr/local/bin may look like this:<br />
$ cat ~/game.sh<br />
if [ $# -ge 1 ]; then<br />
game="`which $1`"<br />
openbox="`which openbox`"<br />
tmpgame="/tmp/tmpgame.sh"<br />
DISPLAY=:1.0<br />
echo -e "${openbox} &\n${game}" > ${tmpgame}<br />
echo "starting ${game}"<br />
xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1<br />
else<br />
echo "not a valid argument"<br />
fi<br />
<br />
So after a chmod +x you would be able to use this script like:<br />
$ ~/game.sh nexuiz-glx<br />
<br />
==See also==<br />
* [[Games]]<br />
* [[Xorg]]<br />
* [[NVIDIA#Gaming_using_Twinview]]<br />
[[Category:Games and entertainment (English)]]</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Wine&diff=100339
Wine
2010-03-16T17:19:50Z
<p>Daenyth: /* x86_64 */ Arch-Games :3</p>
<hr />
<div>[[Category:Wine (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Wine}}<br />
<br />
[http://www.winehq.org/ Wine] is a translation layer (a program loader) capable of running Windows applications on GNU/Linux and other POSIX compatible operating systems. Windows programs running in Wine act as native programs would, running without the performance or memory usage penalties of an emulator, with a similar look and feel to other applications on your desktop.<br />
<br />
== Installation ==<br />
=== i686 ===<br />
Wine is constantly updated and available in the [extra] repository:<br />
<br />
pacman -S wine<br />
<br />
=== x86_64 ===<br />
There's as of writing no x86_64 version of wine available, but that should be the case soon because the devs already have a hello world running.<br />
If you don't bother stuffing your PC with i686 libraries and binarys, then use one of the bin32-wine packages in the [[AUR]]: [http://aur.archlinux.org/packages.php?ID=7915 bin32-wine] and [http://aur.archlinux.org/packages.php?ID=16531 bin32-wine-suse]. bin32-wine is also available in the [http://archlinux-gaming.org Arch-Games] repo.<br />
<br />
'''Important:''' If you have a '''nvidia'''-graphicscard, you'll need to do<br />
<br />
pacman -S lib32-nvidia-utils<br />
<br />
to use 3D-allocation! Or look [http://aur.archlinux.org/packages.php?K=lib32-nvidia-utils here] for other than the newest lib32-nvidia-utils version, if you use the nvidia-96xx driver version for example.<br />
<br />
== Configuration ==<br />
To create configuration files do<br />
winecfg<br />
review the settings and click ok to save. The wine directory with config files resides in <br />
~/.wine<br />
and by default C:\> will be mapped to<br />
~/.wine/drive_c<br />
<br />
Ok! This is the basic configuration. You can try to run something using:<br />
wine /path/to/something.exe<br />
<br />
If you're having trouble getting DirectX apps to run properly, try adding the '''-opengl''' flag:<br />
wine /path/to/3d_game.exe '''-opengl'''<br />
<br />
===Sound===<br />
{{Note|This section may be outdated.}}<br />
<br />
By default sound issues may arise when running Wine applications. Ensure only one sound device is selected in ''winecfg''. Alsa should work out of the box but is still glitchy & slow in some games, there exists a patch for this issue here:<br />
<br />
http://kcat.strangesoft.net/wine_thread_prio.diff<br />
<br />
but using oss and selecting winecfg -> Sound -> Hw acceleration -> Emulation will also fix the audio issues for you provided you are using the alsa oss emulation kernel modules. (<b>Note:</b> using the aoss utility does <i>not</i> solve the issue; you must load the snd-pcm-oss module.)<br />
<br />
===Fonts===<br />
<br />
*If wine applications are not showing easily readable fonts, you may not have Microsoft's Truetype fonts installed. Luckily arch has a package for that.<br />
pacman -S ttf-ms-fonts<br />
<br />
After running such program, kill all wine servers and run winecfg; fonts should be legible now.<br />
<br />
Other TTF fonts you wish to install should go in $C_DRIVE/windows/fonts/ (where $C_DRIVE is usually ~/.wine/drive_c) for wine to recognize them.<br />
<br />
If the fonts look somehow smeared, enter the .wine directory and create a file fontrender.txt with the content:<br />
[HKEY_CURRENT_USER\Software\Wine\X11 Driver]<br />
"ClientSideWithRender"="N"<br />
<br />
Add the key to your wine configuration by executing the following command:<br />
regedit fontrender.txt<br />
<br />
====Enabling font anti-aliasing====<br />
<br />
{{Note | A [http://files.polosatus.ru/winefontssmoothing_en.sh script] has been created to simplify this process.}}<br />
<br />
Create a file with a .reg (example: aa.reg) with the following content :<br />
<br />
REGEDIT4<br />
<br />
[HKEY_CURRENT_USER\Control Panel\Desktop]<br />
"FontSmoothing"="2"<br />
"FontSmoothingType"=dword:00000002<br />
"FontSmoothingGamma"=dword:00000578<br />
"FontSmoothingOrientation"=dword:00000001<br />
<br />
run <br />
regedit <br />
and choose <br />
File -> Import registry file... <br />
<br />
and select your .reg file. Anti-aliasing fonts will be after the conclusion of regedit, and run wine applications again.<br />
<br />
===Sub-Menu===<br />
<br />
After installation, there will likely be no menu in your Desktop Manager. After installing a program using Wine, it will create a menu with your installed programs in it automatically. If you wish to add on to the menu to create a Ubuntu-like Wine sub-menu, then follow these instructions:<br />
<br />
====Create Menu Entries====<br />
<br />
First, install a Windows program using Wine to create the base menu. After the base menu is created, you can start to add the menu entries. In GNOME, right-click on the desktop and select "''Create Launcher...''". The steps might be different for KDE/Xfce. Make three launchers using these settings:<br />
<br />
'''Type''': Application<br />
'''Name''': Configuration<br />
'''Command''': winecfg<br />
'''Comment''': Configure the general settings for Wine<br />
<br />
'''Type''': Application<br />
'''Name''': Uninstall Programs<br />
'''Command''': wine uninstaller<br />
'''Comment''': Uninstall Windows programs under Wine properly<br />
<br />
'''Type''': Application<br />
'''Name''': Browse C:\ Drive<br />
'''Command''': wine winebrowser c:\\<br />
'''Comment''': Browse the files in the virtual Wine C:\ drive<br />
<br />
Now that you have these three launchers on your desktop, it is time to put them into the menu. But, first you should change the launchers to dynamically change icons when a new icon set is installed. To do this, open the launchers that you just made in your favorite text editor. Change the following settings to these new values:<br />
<br />
<br />
''Configuration'' launcher:<br />
Icon[en_US]=wine-winecfg<br />
Icon=wine-winecfg<br />
''Uninstall Programs'' launcher:<br />
Icon[en_US]=wine-uninstaller<br />
Icon=wine-uninstaller<br />
''Browse C:\ Drive'' launcher:<br />
Icon[en_US]=wine-winefile<br />
Icon=wine-winefile<br />
<br />
If these settings produce a ugly/non-existent icon, it means that there are no icons for these launchers in the icon set that you have enabled. You should replace the icon setting with the explicit location of the icon that you want. Clicking the icon in the launcher's properties menu will have the same effect. A great icon set that supports these shortcuts is [http://www.gnome-look.org/content/show.php/GNOME-colors?content=82562 GNOME-colors].<br />
<br />
Now that you have the launchers fully configured, 'now' it is time to put them in the menu. Plop them into "''~/.local/share/applications/wine/''" using a terminal or file browser.<br />
<br />
Wait a second, they aren't in the menu yet! There is one last step. Copy the following text into a text file named "''wine-utilities.menu''".<br />
<br />
<!DOCTYPE Menu PUBLIC "-//freedesktop//DTD Menu 1.0//EN"<br />
"http://www.freedesktop.org/standards/menu-spec/menu-1.0.dtd"><br />
<Menu><br />
<Name>Applications</Name><br />
<Menu><br />
<Name>wine-wine</Name><br />
<Directory>wine-wine.directory</Directory><br />
<Include><br />
<Filename>wine-Configuration.desktop</Filename><br />
</Include><br />
<Include><br />
<Filename>wine-Browse C:\ Drive.desktop</Filename><br />
</Include><br />
<Include><br />
<Filename>wine-Uninstall Programs.desktop</Filename><br />
</Include><br />
</Menu><br />
</Menu><br />
<br />
Now, just move the newly made file to the "''~/.config/menus/applications-merged/''" folder. Go check in the menu and there should be the minty fresh options waiting to be used!<br />
<br />
===KDE 4 Menu Fix[https://bugs.launchpad.net/ubuntu/+source/wine/+bug/263041]===<br />
The Wine menu items may appear in "Lost & Found" instead of the Wine menu for KDE 4. This is because kde-applications.menu is missing the MergeDir option.<br />
<br />
Edit '''/etc/xdg/menus/kde-applications.menu'''<br />
<br />
At the end of the file add <MergeDir>applications-merged</MergeDir> after <DefaultMergeDirs/>, it should look like this:<br />
<br />
<Include><br />
<And><br />
<Category>KDE</Category><br />
<Category>Core</Category><br />
</And><br />
</Include><br />
<DefaultMergeDirs/><br />
<MergeDir>applications-merged</MergeDir><br />
<MergeFile>applications-kmenuedit.menu</MergeFile><br />
</Menu><br />
<br />
Alternatively you can create a symlink to a folder that KDE does see:<br />
ln -s ~/.config/menus/applications-merged ~/.config/menus/kde-applications-merged<br />
<br />
This has the added bonus that an update to KDE won't change it, but is per user instead of system wide.<br />
<br />
=== Wine Configuration Utilities ===<br />
These tools will assist in the installation of typical Windows components. In most cases they should be used as a last effort, as it may severely alter your wine configuration. <br />
<br />
==== WineTricks ====<br />
[http://wiki.winehq.org/winetricks Winetricks] is a quick (slightly dirty) script that will allow you to install base requirements needed to run some windows programs. Installable components include DirectX 9.x, msxml (office 2007 / IE requirement), visual runtimes and many more.<br />
<br />
To install simply:<br />
pacman -S winetricks<br />
<br />
You can now start winetricks (as a normal user!) with:<br />
winetricks<br />
<br />
==== WineTools assistant ====<br />
(currently slightly outdated, but working)<br />
<br />
Winetools is a program (more of a script, in fact) that facilitates in the installation of some core components for wine in order to install other programs. Note this is not necessary for wine, but does help if you want to get Internet Explorer running.<br />
<br />
[http://www.von-thadden.de/Joachim/WineTools/ WineTools Site]<br />
<br />
Microsoft policy is that you must have a license for IE6 in order to install DCOM98 or Internet Explorer 6. If you've ever owned a copy of Windows, you should be fine.<br />
<br />
*Download the [http://aur.archlinux.org/packages.php?ID=8913 PKGBUILD]<br />
<br />
*Build the package using the [[Arch Build System]]<br />
<br />
==== Sidenet Wine Configuration Utility ====<br />
<br />
[http://sidenet.ddo.jp/winetips/config.html wine-config]<br />
<br />
* Download the latest version<br />
* unpack it<br />
* READ THE README<br />
* execute<br />
./setup<br />
* Follow the instructions<br />
<br />
'''Keep in mind''': Like stated on the [http://sidenet.ddo.jp/winetips/config.html site], you're only allowed to install DCOM98 if you possess a valid License for Windows98.<br />
<br />
==== Wine-doors ====<br />
<br />
[http://www.wine-doors.org/ Wine-doors]<br />
<br />
Wine-doors is a WineTools replacement. It features a GNOME GUI and works like a package manager. Works fine in 64bit. You can [http://aur.archlinux.org/packages.php?ID=11823 find it in the AUR].<br />
<br />
== Using Wine to execute Win16 / Win32 binaries ==<br />
<br />
You can execute binaries by calling '''wine''' manually<br />
<br />
wine programsname.exe<br />
<br />
If installing using an MSI installer, use the included '''msiexec''' utility.<br />
<br />
msiexec installername.msi<br />
<br />
It is also possible to tell the kernel to use '''wine''' as an interpreter for all Win16/Win32 binaries. First mount the binfmt_misc filesystem:<br />
<br />
mount -t binfmt_misc none /proc/sys/fs/binfmt_misc<br />
<br />
or add this line to your '''/etc/fstab'''<br />
<br />
none /proc/sys/fs/binfmt_misc binfmt_misc defaults 0 0<br />
<br />
Then tell the kernel how to interpret Win16 and Win32 binaries:<br />
<br />
echo ':DOSWin:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register<br />
<br />
You can add this line to '''/etc/rc.local''' to make this setting permanent. In this case you may want to ignore stderr to avoid error messages when changing runlevels:<br />
<br />
{ echo ':DOSWin:M::MZ::/usr/bin/wine:' > /proc/sys/fs/binfmt_misc/register; } 2>/dev/null<br />
<br />
Now try this:<br />
<br />
chmod 755 exefile.exe<br />
./exefile.exe<br />
<br />
You can even remove the '''.exe''' extension, because the kernel doesn't identify the file by its extension.<br />
<br />
== Alternatives to Win16 / Win32 binaries ==<br />
<br />
* [[Cedega]] - Aimed at gamers<br />
* [[CVSCedega]] - CVS source version of cedega<br />
* [[Codeweavers]] - Codeweavers' Crossover Office; Aimed at Office Users<br />
<br />
== External Resources ==<br />
* [http://www.winehq.com/ Official Wine Website]<br />
* [http://gwos.org/doku.php/wine:winestuff Optimization Guide]<br />
* Installing Internet Explorer 5, 5.5 and 6 with wine: [[Ies4linux]]<br />
* [http://linuxgamingtoday.wordpress.com/2008/02/16/quick-tips-to-speed-up-your-gaming-in-wine/ Advanced configuring your gfx card and opengl settings on wine; Speed up wine]<br />
<!-- vim: set ft=Wikipedia: --></div>
Daenyth
https://wiki.archlinux.org/index.php?title=Ext3&diff=100101
Ext3
2010-03-14T19:56:01Z
<p>Daenyth: /* Copyright */ The whole wiki is under that license, no need to specify it here.</p>
<hr />
<div>[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==Overview==<br />
<br />
I'm a big fan of the Third Extended ("ext3") filesystem. It's in-kernel and userspace code has been tried, tested, fixed, and improved upon more than almost every other Linux-compatible filesystem. It's simple, robust, and extensible. In this article I intend to explain some tips that can improve both the performance and the reliability of the filesystem.<br />
<br />
In the document, /dev/hdXY will be used as a generic partition. You should replace this with the actual device node for your partition, such as /dev/hdb1 for the first partition of the primary slave disk or /dev/sda2 for the second partition of your first SCSI or Serial ATA disk.<br />
<br />
==Using The tune2fs and e2fsck Utilities==<br />
<br />
Before we begin, we need to make sure you are comfortable with using the tune2fs utility to alter the filesystem options of an ext2 or ext3 partition. Please make sure to read the tune2fs man page:<br />
<br />
$ man tune2fs<br />
It's generally a good idea to run a filesystem check using the e2fsck utility after you've completed the alterations you wish to make on your filesystem. This will verify that your filesystem is clean and fix it if needed. You should also read the manual page for the e2fsck utility if you have not yet done so:<br />
<br />
$ man e2fsck<br />
<br />
'''WARNING: ONLY RUN UNMOUNTED:''' Make sure any filesystems are cleanly unmounted before altering them with the tune2fs or e2fsck utilities! (Boot from a LiveCD such as '''Archie''' or Knoppix if you need to.) Altering or tuning a filesystem while it is mounted can cause severe corruption! You have been warned!<br />
<br />
==Using Directory Indexing==<br />
<br />
This feature improves file access in large directories or directories containing many files by using hashed binary trees to store the directory information. It's perfectly safe to use, and it provides a fairly substantial improvement in most cases; so it's a good idea to enable it:<br />
<br />
# tune2fs -O dir_index /dev/hdXY<br />
<br />
This will only take effect with directories created on that filesystem after tune2fs is run. In order to apply this to currently existing directories, we must run the e2fsck utility to optimize and reindex the directories on the filesystem:<br />
<br />
# e2fsck -D -f /dev/hdXY<br />
<br />
'''Note:''' This should work with both ext2 and ext3 filesystems. Depending on the size of your filesystem, this could take a long time. Perhaps you should go get some coffee...<br />
<br />
'''Note:''' Directory indexing is activated by default in Arch Linux via /etc/mke2fs.conf<br />
<br />
==Enable Full Journaling==<br />
<br />
By default, ext3 partitions mount with the 'ordered' data mode. In this mode, all data is written to the main filesystem and its metadata is committed to the journal, whose blocks are logically grouped into transactions to decrease disk I/O. This tends to be a good default for most people. However, I've found a method that increases both reliability and performance (in some situations): journaling everything, including the file data itself (known as 'journal' data mode). Normally, one would think that journaling all data would decrease performance, because the data is written to disk twice: once to the journal then later committed to the main filesystem, but this does not seem to be the case. I've enabled it on all nine of my partitions and have only seen a minor performance loss in deleting large files. In fact, doing this can actually improve performance on a filesystem where much reading and writing is to be done simultaneously. See [http://www-106.ibm.com/developerworks/linux/library/l-fs8.html#4 this article] written by Daniel Robbins on IBM's website for more information.<br />
<br />
<br />
There are two different ways to activate journal data mode. The first is by adding data=journal as a mount option in /etc/fstab. If you do it this way and want your root filesystem to also use it, you should also pass rootflags=data=journal as a kernel parameter in your bootloader's configuration. In the second method, you will use tune2fs to modify the default mount options in the filesystem's superblock:<br />
<br />
# tune2fs -O has_journal -o journal_data /dev/hdXY<br />
Please note that the second method may not work for older kernels. Especially Linux 2.4.20 and below will likely disregard the default mount options on the superblock. If you're feeling adventurous you may also want to tweak the journal size. (I've left the journal size at the default.) A larger journal may give you better performance (at the cost of more disk space and longer recovery times). Please be sure to read the relevant section of the tune2fs manual before doing so:<br />
<br />
# tune2fs -J size=$SIZE /dev/hdXY<br />
<br />
==Disable Lengthy Boot-Time Checks==<br />
<br />
'''WARNING:''' Only do this on a journaling filesystem such as ext3. This may or may not work on other journaling filesystems such as ReiserFS or XFS, but has not been tested. Doing so may damage or otherwise corrupt other filesystems. You do this AT YOUR OWN RISK.<br />
<br />
Hmm..It seems that our ext3 filesystems are still being checked every 30 mounts or so. This is a good default for many because it helps prevent filesystem corruption when you have hardware issues, such as bad IDE/SATA/SCSI cabling, power supply failures, etc. One of the driving forces for creating journaling filesystems was that the filesystem could easily be returned to a consistent state by recovering and replaying the needed journaled transactions. Therefore, we can safely disable these mount-count- and time-dependent checks if we are certain the filesystem will be quickly checked to recover the journal if needed to restore filesystem and data consistency. Before you do this please make sure your filesystem entry in /etc/fstab has a positive integer in its 6th field (pass) so that it is checked at boot time automatically. You may do so using the following command:<br />
<br />
# tune2fs -c 0 -i 0 /dev/hdXY<br />
<br />
If you just want to limit the checks to happen less often without totally disabling them (for peace of mind). A great method is to change from a number of count's check to a time frame check. See the man. Here is once every month...<br />
<br />
# tune2fs -c 0 -i 1m /dev/hdXY<br />
<br />
==Reclaim Reserved Filesystem Space==<br />
Ext3 partition contain a used space of 5% for special reasons by default. The main reason for such space is so root can log in even when the filesystem becomes 100% used. Without this option, the root user might not be able to log in to "clean up" because they system could become unstable, trying to write logs to a 100% full system for example. The other reason is to help with less fragmentation on the filesystem.<br />
<br />
The issue with this is that hard drives are getting so big the 5% can add up to be quite a large amount of wasted space. (eg. 100 GB = 5 GB reserved). Now if you separate your filesystems to like /home for example it might be a good idea to adjust these and reclaim that wasted space. It's a safe bet to leave your / filesystem at 5% reserved just in case. Leave reserved space for filesystems containing /var and /tmp also or else you'll end up with problems.<br />
<br />
Now to change your reserved space to 1% of the drive, which is fair for non-root filesystems.<br />
<br />
# tune2fs -m 1 /dev/sdXY<br />
<br />
==Assigning a Label==<br />
<br />
Once you have created and formated a partition, you can assign it a label using the e2label command. This allows you to add the partition to /etc/fstab using a label instead of using a device path (usefull for an USB drive). To add a label to a partition, type the following command as root: <br />
<br />
e2label /dev/sdXY ''new-label''<br />
<br />
If the optional argument ''new-label'' is not present, e2label will simply display the current filesystem label. If the optional argument ''new-label'' is present, then e2label will set the filesystem label to be ''new-label''q. Ext2 and ext3 filesystem labels can be at most 16 characters long; if new-label is longer than 16 characters, e2label will truncate it and print a warning message.<br />
<br />
==User experiences==<br />
<br />
I never had problems with these tips on large (>750) filesystems. Disabling lengthy boot-time works fine as well.<br />
<br />
<br />
<br />
I get filesystem errors even with this tips. Do not disable lengthy Boot-Time<br />
<br />
If you have some big partitions, do not enable full journaling on them. I experienced reproducible freezes (about 30 seconds) when enabling this on my 250gb home partition.<br />
<br />
: Did you try tweaking bdflush as described [http://www.ibm.com/developerworks/linux/library/l-fs8.html by Daniel Robbins]?</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Custom_Kernel_Compilation_with_ABS&diff=99936
Custom Kernel Compilation with ABS
2010-03-13T00:20:13Z
<p>Daenyth: Link to modern method</p>
<hr />
<div>[[Category:Kernel (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{out of date}}<br />
<br />
{{i18n|Custom Kernel Compilation with ABS}}<br />
<br />
=== Introduction ===<br />
{{Warning|This article is badly outdated. See [http://bugs.archlinux.org/task/12384 here] for the modern method.}}<br />
<br />
There are many ways to build the kernel in arch, this is just one example - for other possibilities see [[Kernel_Compilation|Kernel Compilation]]. Some Arch users prefer [[Kernel Compilation From Source|the traditional way]], however using ABS is helpful for automating certain tasks. The choice is yours; neither way is inherently better than the other. <br />
<br />
This howto has been updated to provide a definitive PKGBUILD for the creation of custom kernel packages. It allows you to maintain multiple custom kernels with a unique naming scheme under pacman version control. It is ideal for ANY custom kernel build and can be easily adapted to fit many requirements. The PKGBUILD automatically accounts for the <code>EXTRAVERSION</code> and <code>LOCALVERSION</code> variables that are now fully supported in the kernel. <code>EXTRAVERSION</code> is frequently set by major patchsets such as -ck and -nitro. <code>EXTRAVERSION</code> is also used in the 2.6.x.y branch to carry the <code>.y</code> variable. <code>LOCALVERSION</code> can be set during the config stage and is the easiest and RECOMMENDED way to customize your kernel pkgnames. Simply setting <code>LOCALVERSION</code> to <code>-custom</code> or the date e.g. <code>-20050105</code> will suffice! A unique LOCALVERSION guarantees a unique pkg.<br />
<br />
Note that this is NOT an ABS howto - to successfully follow this HOWTO a working knowledge of building packages with ABS is ESSENTIAL - please read [[Arch Build System]], [[Creating Packages]] and [[Patching in ABS]].<br />
<br />
=== Philosophy and Logic (how it works and why it works this way) ===<br />
* The Arch Way - Keep It Simple.<br />
* This PKGBUILD builds on the previous, widely accepted version.<br />
* This build provides kernel packages and components with a simple, logical and uncomplicated naming scheme that ONLY uses variables that are part of the ABS system and part of the kernel compilation process itself. Rationale:<br />
** The stock Arch kernel uses the <code>kernel26</code> base pkgname which is logically extended here under the 2.6.x and 2.6.x.y schemes e.g <code>kernel2611</code> and <code>kernel26117</code><br>These also provide the basis of <code>/boot</code> filenames e.g. <code>vmlinux26</code> and <code>vmlinuz26117</code><br />
** The ''kernel compilation process'' uses the kernel version (2.6.x), <code>EXTRAVERSION</code> from the <code>Makefile</code> and <code>CONFIG_LOCALVERSION</code> from the kernel config to create the name for the kernel's module directory, e.g.:<br />
<br />
<pre><br />
2.6.x$EXTRAVERSION$LOCALVERSION<br />
2.6.11-cko2-ARCH/<br />
</pre><br />
<br />
: This is beyond the control of the PKGBUILD so to provide a pkg with similarly named components the PKGBUILD uses the same scheme to create unique <code>/boot</code> files and a unique <code>/usr/src</code> directory by appending <code>-EXTRAVERSION-LOCALVERSION</code>, e.g.:<br />
<br />
<pre><br />
/boot/vmlinuz2611-cko2-ARCH<br />
/boot/System.map2611-cko2-ARCH<br />
/boot/kconfig2611-cko2-ARCH<br />
<br />
/usr/src/linux-2.6.11-cko2-ARCH/<br />
</pre><br />
<br />
* If you have the recommended knowledge of ABS you will see that the PKGBUILD is transparently constructed, self-explanatory and can be customized easily.<br />
* User input is almost identical to all ABS builds: simply set <code>pkgver</code>, <code>pkgrel</code> and <code>pkgdesc</code> and add additional sources, including patches, to the <code>source</code> array. Patch users should insert the appropriate patch commands where indicated. Aside from uncommenting the config method and choosing whether to <code>make clean</code> or not the rest of the build is automated.<br />
* Having created a custom pkg naming scheme during the build, the PKGBUILD automatically corrects/updates itself with the new <code>pkgname</code> variable allowing simple <code>gensync</code> operation.<br />
<br />
=== Usage Notes ===<br />
<br />
* <code>pkgname</code> must be declared within 10 lines of the top of the PKGBUILD - so '''DO NOT''' move it - just leave it.<br><br />
If you miss this simple instruction don't worry, it won't screw up your build but your PKGBUILD file will not have the pkgname automatically updated at the end of the build. This is to allow you to use gensync correctly BUT you can edit the PKGBUILD file manually afterwards of course.<br />
<br />
* Until you have your own config that you are happy with it is easiest just to start with the default Arch config; you should also get the Arch <code>kernel26.install</code> file, make your own <code>kernel26.install</code> script or comment out the line <code>install=kernel26.install</code> from the PKGBUILD. The official Arch files are both in your ABS tree, normally under <code>/var/abs/core/kernel26</code>. To download the ABS tree to your system simply run <code>abs</code> as root. It doesn't take long, even on dialup. You should keep this updated by running <code>abs</code> as root on a regular basis.<br />
:NOTE: If you use LILO or any other static bootloader (that is, one that requires update after every kernel change) you are advised to use an install file too. This is an example, <code>kernel26.install</code>, for use with Lilo:<br />
<br />
# arg 1: the new package version<br />
# arg 2: the old package version<br />
<br />
# Script by Jouke Witteveen (j <dot> witteveen <at> gmail)<br />
# Revision: 4<br />
<br />
link () {<br />
dialog --backtitle &quot;$ba&quot; --title Linking --yesno<br />
&quot;\nDo you want to link /vmlinuz to the $ke kernel?\n(This can be useful for configuring your bootloader)&quot; 9 60 &&{<br />
[ -e /vmlinuz -o -h /vmlinuz ] &&\<br />
mv -f /vmlinuz /vmlinuz.old<br />
kern () {<br />
ls -t /boot/vmlinuz$1* 2> /dev/null | head -n 1<br />
}<br />
vm=`kern \`echo $1 | sed &quot;s|\.||g&quot;\``<br />
[ ! -e &quot;$vm&quot; ] &&\<br />
vm=`kern`<br />
ln -s $vm /vmlinuz<br />
}<br />
}<br />
<br />
exec () {<br />
dialog --backtitle &quot;$ba&quot; --title &quot;Bootloader execution&quot; --yesno<br />
&quot;\nDo you want to run Lilo to make the $ke kernel bootable?\n\n\<br />
Remember: If you choose 'No' now you will not be able to boot the $ke kernel until you manually update your bootloader!&quot; 12 60 &&\<br />
lilo &&\<br />
echo -e $1 # At least Lilo did not return an error<br />
}<br />
<br />
warn () {<br />
dialog --backtitle &quot;$ba&quot; --title Warning --msgbox<br />
&quot;\nYou will not be able to boot the $ke kernel until you manually update your bootloader.&quot; 9 60<br />
}<br />
<br />
<br />
post_install () {<br />
ba=&quot;Installing kernel $1&quot;<br />
ke=&quot;new&quot;<br />
link $1 &&\<br />
exec &quot;\nKernel $1 successfully installed!\n&quot; ||\<br />
warn<br />
}<br />
<br />
post_upgrade () {<br />
ba=&quot;Upgrading kernel $2 to kernel $1&quot;<br />
ke=&quot;upgraded&quot;<br />
link $1<br />
exec &quot;\nKernel $2 successfully upgraded to version $1!\n&quot; ||\<br />
warn<br />
}<br />
<br />
post_remove () {<br />
unli () {<br />
[ -h $1 -a ! -e $1 ] &&\<br />
unlink $1<br />
}<br />
unli /vmlinuz<br />
unli /vmlinuz.old<br />
[ -e /vmlinuz.old -a ! -e /vmlinuz ] &&{<br />
ba=&quot;Removing kernel $1&quot;<br />
ke=&quot;old&quot;<br />
mv /vmlinuz.old /vmlinuz<br />
exec &quot;\nThe old kernel was successfully restored\n&quot; ||\<br />
warn<br />
}<br />
}<br />
<br />
<br />
<br />
* To check if <code>EXTRAVERSION</code> is set by your patchset try doing<br />
<br />
grep +EXTRAVERSION= ./patchname<br />
<br />
: and it should return something like this:<br />
<br />
+EXTRAVERSION = -ck3<br />
<br />
: if it doesn't then <code>EXTRAVERSION</code> is '''probably not being set''' by your patchset and you should ensure you use LOCALVERSION to customize the pkgname.<br>Arch default kernels are set with the <code>-ARCH</code> <code>LOCALVERSION</code> variable - you can set anything you like e.g. <code>-custom</code> (note the need for the preceding dash <code>-</code>)<br>Because of these added variables there is no need to alter the pkgname manually at any point or use any other variables. The build process automatically updates the pkgname variable in the PKGBUILD file at the end of each build to reflect the final full kernel version naming scheme.<br />
<br />
* If used correctly this PKGBUILD '''should''' always provide a unique kernel build based on EXTRAVERSION and LOCALVERSION, and on the pkgver and pkgrel (as normal) - however it is up to the user to '''double check''' resulting pkgnames and contents '''before''' installation to prevent overwrites (see below for more details and examples).<br />
<br />
=== Configuring the PKGBUILD ===<br />
Note that this PKGBUILD cannot be used with kernel 2.4, which is no longer supported by Arch Linux. ([http://www.archlinux.org/news/232/ news])<br />
<br />
Copy the PKGBUILD below to your $startdir. Before building remember the following:<br />
# <code>pkgname</code> can be left as it is; it will automatically be set and correct itself.<br />
# Insert the <code>pkgver</code> for your kernel (for example: <code>2.6.9</code>).<br />
# Change the <code>pkgrel</code> for your current revision. You should increment this each time you make changes to the kernel config and want to build a REPLACEMENT pkg. If you don't want to replace the previous build but rather install in parallel you should use <code>LOCALVERSION</code> to create a unique pkg.<br />
# Change/expand the <code>pkgdesc</code> to describe any patches or special config options applied.<br />
# Change the source to use a closer mirror and if you are using a patchset, add the patches to the source array.<br />
# {OPTIONAL} Place the patch commands where indicated.<br />
# Choose a make method by leaving your preferred method uncommented - gconfig (gtk based) xconfig (qt based) menuconfig (ncurses based).<br />
# During the build you will be asked if you want to <code>make clean</code> - the default is <code>yes</code>, reply <code>NO</code> if you know what you are doing.<br />
<br />
<pre><br />
# Contributor: dibblethewrecker <dibblethewrecker.at.jiwe.org><br />
pkgname=kernel26<br />
pkgver=2.6.x.y<br />
pkgrel=1<br />
pkgdesc=&quot;The Linux Kernel 2.6.x.y and modules (IDE support)&quot;<br />
url=&quot;http://www.kernel.org&quot;<br />
depends=('module-init-tools')<br />
install=kernel26.install<br />
arch=(i686 x86_64)<br />
license=('GPL')<br />
<br />
##### add any patch sources to this section<br />
source=(config ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$pkgver.tar.bz2 )<br />
<br />
# Function to grab var from src<br />
getvar() {<br />
old=$(cat Makefile | grep &quot;^$1&quot;)<br />
echo $(echo ${old/&quot;$1 =&quot;/} | sed -e &quot;s/[ ]*\(.*\)[ ]*/\1/g&quot;)<br />
return 0<br />
}<br />
<br />
build() {<br />
cd $srcdir/linux-$pkgver<br />
<br />
##### Uncomment and apply any patches here<br />
#patch -Np1 -i ../patchname || return 1<br />
<br />
# get rid of the 'i' in i686<br />
carch=`echo $CARCH | sed 's|i||'`<br />
cat ../config | sed &quot;s|#CARCH#|$carch|g&quot; >./.config<br />
<br />
##### Load config - uncomment your preferred config method<br />
#yes &quot;&quot; | make config<br />
#make oldconfig || return 1<br />
#make menuconfig<br />
#make xconfig<br />
make gconfig<br />
<br />
##### NO USER CHANGES BELOW HERE #####<br />
<br />
# save the current pkgname<br />
old_pkgname=$pkgname<br />
<br />
# set pkgname for build purposes - DO NOT alter!<br />
pkgname=kernel26<br />
<br />
# save the updated config to build with today's date<br />
cp ./.config $startdir/config-$(date +%b%d\-%Hh)<br />
<br />
# get EXTRAVERSION from Makefile to create a unique pkgname and /usr/src directory<br />
_kernextra=$(getvar &quot;EXTRAVERSION&quot;)<br />
# grab the 2.6.x.y version suffix from pkgver<br />
_y=&quot;`echo $pkgver | cut --delim &quot;.&quot; --fields 4`&quot;<br />
# remove .y version suffix from _kernextra<br />
_kernextra=&quot;`echo $_kernextra | sed &quot;s|\.$_y||g&quot;`&quot;<br />
<br />
# Read the full kernel version info from new config to use in pathnames and pkgname<br />
. ./.config<br />
<br />
# Kernel custom - to create a unique pkgname (see below)<br />
_kerncust=&quot;${_kernextra}${CONFIG_LOCALVERSION}&quot;<br />
# Kernel release - will be the same as Makefile<br />
_kernrel=&quot;${pkgver}${_kerncust}&quot;<br />
# Get the pkgver suffix for unique pkgname and /boot file suffices<br />
_pkgversuf=&quot;`echo $pkgver | sed &quot;s|2.6.||g&quot; | sed &quot;s|\.||g&quot;`&quot;<br />
# Set /boot file suffices from kernel release and pkgver suffix<br />
_kernboot=&quot;${_pkgversuf}${_kerncust}&quot;<br />
<br />
# Set a new pkgname from kernel release and pkgver suffix<br />
pkgname=&quot;${pkgname}${_pkgversuf}${_kerncust}&quot;<br />
<br />
# build!<br />
echo<br />
echo -n &quot;Do you want to make clean (default YES)? (YES/NO): &quot;<br />
read choice<br />
echo<br />
echo -n &quot;Press any key to start make or CTRL+C to quit&quot;<br />
read anykey<br />
<br />
if [ &quot;${choice}&quot; = &quot;NO&quot; ] ; then<br />
make bzImage modules || return 1<br />
else<br />
make clean bzImage modules || return 1<br />
fi<br />
<br />
mkdir -p $pkgdir/{lib/modules,boot}<br />
make INSTALL_MOD_PATH=$pkgdir modules_install || return 1<br />
cp System.map $pkgdir/boot/System.map26${_kernboot}<br />
cp arch/i386/boot/bzImage $pkgdir/boot/vmlinuz26${_kernboot}<br />
install -D -m644 Makefile \<br />
$pkgdir/usr/src/linux-${_kernrel}/Makefile<br />
install -D -m644 kernel/Makefile \<br />
$pkgdir/usr/src/linux-${_kernrel}/kernel/Makefile<br />
install -D -m644 .config \<br />
$pkgdir/usr/src/linux-${_kernrel}/.config<br />
install -D -m644 .kernelrelease \<br />
$pkgdir/usr/src/linux-${_kernrel}/.kernelrelease<br />
install -D -m644 .config $pkgdir/boot/kconfig26${_kernboot}<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/include<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/arch/i386/kernel<br />
for i in acpi asm-generic asm-i386 config linux math-emu media net pcmcia scsi sound video; do<br />
cp -a include/$i $pkgdir/usr/src/linux-${_kernrel}/include/<br />
done<br />
# copy files necessary for later builds, like nvidia and vmware<br />
cp Module.symvers $pkgdir/usr/src/linux-${_kernrel}<br />
cp -a scripts $pkgdir/usr/src/linux-${_kernrel}<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/.tmp_versions<br />
cp arch/i386/Makefile $pkgdir/usr/src/linux-${_kernrel}/arch/i386/<br />
cp arch/i386/Makefile.cpu $pkgdir/usr/src/linux-${_kernrel}/arch/i386/<br />
cp arch/i386/kernel/asm-offsets.s \<br />
$pkgdir/usr/src/linux-${_kernrel}/arch/i386/kernel/<br />
# copy in Kconfig files<br />
for i in `find . -name &quot;Kconfig*&quot;`; do<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/`echo $i | sed 's|/Kconfig.*||'`<br />
cp $i $pkgdir/usr/src/linux-${_kernrel}/$i<br />
done<br />
cd $pkgdir/usr/src/linux-${_kernrel}/include && ln -s asm-i386 asm<br />
chown -R root.root $pkgdir/usr/src/linux-${_kernrel}<br />
cd $pkgdir/lib/modules/${_kernrel} && \<br />
(rm -f source build; ln -sf /usr/src/linux-${_kernrel} build)<br />
<br />
# Correct the pkgname in our PKGBUILD - this allows correct gensync operation<br />
# NOTE: pkgname variable must be declared with first 10 lines of PKGBUILD!<br />
cd $startdir<br />
sed -i &quot;1,11 s|pkgname=$old_pkgname|pkgname=$pkgname|&quot; ./PKGBUILD<br />
}<br />
# vim:syntax=sh<br />
</pre><br />
<br />
* Install your new pkg as normal.<br />
<br />
=== Your <code>config</code> file ===<br />
PLEASE NOTE: during the build the '''final''' kernel config is stored in your <code>$startdir</code> as, for example, <code>config-Apr13-12h</code>. Your '''original''' config remains in the <code>$startdir</code> named <code>config</code>. If you wish to use the new config in another build make sure you copy the correct file!<br />
<br />
===Update Bootloader===<br />
* Remember to edit the bootloader (e.g. [[LILO]] or [[GRUB]]) configuration files to include an entry to the new kernel. The new kernel will install alongside any existing stock or custom kernels, so you may wish to keep a reference to your old kernel in the bootloader configuration file - at least, until you're sure the new one is working.<br />
<br />
* If you use a static bootloader (one that requires update after every kernel change), remember to update it. For LILO, running <code>lilo</code> as root should suffice.<br />
<br />
=== Other versions ===<br />
There are several variations on this PKGBUILD available, they all provide identical results but the mechanics are slightly different:<br />
* [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_patch patch] - includes the old <code>patch=</code> variable.<br />
* [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_verbose verbose] - provides Package Info (like that shown above) for review before starting the make process.<br />
* [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_buildstats buildstats] - similar to verbose but writes more info, including build times, to a file called buildstats, which is stored in the $startdir. This can also be reviewed before starting the make process but also provides a permanent record.<br />
<br />
=== I want the Arch logo! ===<br />
Download the <code>logo_linux_clut224.ppm</code> to your <code>$startdir</code> from:<br />
<br />
[http://projects.archlinux.org/?p=linux-2.6-ARCH.git;a=tree;f=patches http://projects.archlinux.org/?p=linux-2.6-ARCH.git;a=tree;f=patches]<br />
<br />
Add the the file <code>logo_linux_clut224.ppm</code> to the source array, and add the copy command marked with (<code>>></code>) below into the PKGBUILD as indicated:<br />
<br />
<pre><br />
##### Uncomment and apply any patches here<br />
#patch -Np1 -i ../patchname || return 1<br />
<br />
>> ##### Arch logo - not compatible with gensplash!<br />
>> cp ../logo_linux_clut224.ppm drivers/video/logo/<br />
<br />
# get rid of the 'i' in i686<br />
carch=`echo $CARCH | sed 's|i||'`<br />
cat ../config | sed &quot;s|#CARCH#|$carch|g&quot; >./.config<br />
</pre><br />
<br />
The stock Arch config uses the following logo settings, ensure you set them at the config stage or use the stock config:<br />
<br />
<pre><br />
#<br />
# Logo configuration<br />
#<br />
CONFIG_LOGO=y<br />
CONFIG_LOGO_LINUX_MONO=y<br />
CONFIG_LOGO_LINUX_VGA16=y<br />
CONFIG_LOGO_LINUX_CLUT224=y<br />
</pre><br />
<br />
=== Customization and Advanced Use (normal people can stop here) ===<br />
Several people have successfully customized this PKGBUILD to their own needs, while others have derived a completely new approach from it. One customization recommended to people who make multiple builds of the same version for use in parallel is to add a sed command that automatically sets the <code>CONFIG_LOCALVERSION</code> variable in the config to a unique value before the config stage. This can be based on the date, your hostname, etc.<br />
For example:<br />
<pre><br />
# get rid of the 'i' in i686<br />
carch=`echo $CARCH | sed 's|i||'`<br />
cat ../config | sed &quot;s|#CARCH#|$carch|g&quot; >./.config<br />
<br />
>> # set LOCALVERSION to -date<br />
>> sed -i &quot;s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=-`date +%y%m%d`|g&quot; ./.config<br />
<br />
##### Load config - uncomment your preferred config method<br />
#yes &quot;&quot; | make config<br />
</pre><br />
<br />
or<br />
<br />
<pre><br />
# set LOCALVERSION to -date-hostname<br />
sed -i &quot;s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=-`date +%y%m%d`-`hostname`|g&quot; ./.config<br />
</pre><br />
<br />
For a truly unique <code>LOCALVERSION</code> you can set the date to seconds since <code>00:00:00 1970-01-01 UTC</code>!<br />
<br />
<pre><br />
sed -i &quot;s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=-`date +%s`|g&quot; ./.config<br />
</pre><br />
<br />
=== Problems ===<br />
<br />
If you have problems with wrong package names try using the [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_verbose verbose] PKGBUILD described in [[Custom_Kernel_Compilation_with_ABS#Other_versions|Other Versions]] above to see what naming scheme is being created before you commit to the build - you can quit with ''ctrl+c'' at most points before the make starts.<br />
<br />
=== Using the nVIDIA video driver with your custom kernel ===<br />
<br />
To use the nvidia driver with your new custom kernel, see: [[NVIDIA#Alternate_install:_custom_kernel|How to install NVIDIA driver with custom kernel]]<br />
<br />
=== Feedback ===<br />
If you have any questions/comments/suggestions about the above PKGBUILD feel free to join the discussion at: http://bbs.archlinux.org/viewtopic.php?t=9272<br />
<br />
Some suggestions have already been incorporated but please consider the Keep It Simple philosophy and remember the original goal. Kernel compilation is a very individual process and there are a HUGE variety of ways to go about it. This PKGBUILD does not even attempt to account for all eventualities, it would be fruitless to try but of course you are completely free to customize this build to your precise needs. Best of luck!<br />
<br />
''DibbleTheWrecker''</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Firefox&diff=99935
Firefox
2010-03-13T00:12:49Z
<p>Daenyth: /* Recompiling */ Remove startdir</p>
<hr />
<div>[[Category:Internet and Email (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|Česky|FireFox (Česky)}}<br />
{{i18n_entry|English|Firefox}}<br />
{{i18n_entry|Italiano|Firefox_(Italiano)}}<br />
{{i18n_links_end}}<br />
<br />
[http://www.firefox.com Firefox] is an open-source graphical web browser from [http://www.mozilla.com Mozilla]. The Firefox package in Arch Linux is compiled without official branding, which means that when Firefox is started it will use an alternate icon and will be named after its release series' codename. This has to be done because a distribution may use the name "Firefox" and its artwork only if there are no unofficial modifications, including security patches.<br />
<br />
== Enabling Firefox Branding ==<br />
There are a few ways to enable official branding and to change the browser's user agent string. Among them, there is recompiling, modifying the browser with add-ons, or using the advanced configuration ({{Codeline|about:config}}). Please note that distributing a version with official branding without previous approval from Mozilla is against the law.<br />
<br />
=== Recompiling ===<br />
This guide will employ [[ABS]] for rebuilding Firefox version 2.x. A branded version of Firefox 3.x is available in the [http://aur.archlinux.org/packages.php?ID=18019 AUR].<br />
<br />
After installing ABS,<br />
# pacman -S abs<br />
sync the ABS tree.<br />
# abs<br />
If this is the first time running abs, it may take a while to sync the package tree. Subsequent runs will be much faster. Now make a temporary work path:<br />
$ mkdir -p ~/devel/abs<br />
$ cp -r /var/abs/extra/firefox ~/devel/abs/<br />
$ cd ~/devel/abs/firefox<br />
<br />
Use an editor of choice to open the mozconfig file. Add the following line to the end:<br />
ac_add_options --enable-official-branding<br />
<br />
Save and exit, then run:<br />
$ makepkg -g >> PKGBUILD<br />
This command copies the md5sum values of modified source files (mozconfig in this case) to the PKGBUILD.<br />
<br />
Edit the PKGBUILD file by replacing this line<br />
convert $srcdir/mozilla/browser/app/default.xpm $pkgdir/usr/share/pixmaps/firefox.png<br />
<br />
with the following:<br />
convert $srcdir/mozilla/dist/branding/default.xpm $pkgdir/usr/share/pixmaps/firefox.png<br />
<br />
Now scroll down and look for these two lines.<br />
install -m644 $srcdir/mozilla/browser/app/default.xpm $pkgdir/usr/lib/firefox/chrome/icons/default/<br />
install -m644 $srcdir/mozilla/browser/app/default.xpm $pkgdir/usr/lib/firefox/icons/<br />
<br />
Replace them with the following:<br />
install -m644 $srcdir/mozilla/dist/branding/default.xpm $pkgdir/usr/lib/firefox/chrome/icons/default/<br />
install -m644 $srcdir/mozilla/dist/branding/default.xpm $pkgdir/usr/lib/firefox/icons/ <br />
<br />
Save and exit, then run:<br />
makepkg -s<br />
This will install the required packages for building Firefox prior to making the package itself.<br />
<br />
Once it has created the package, remove the currently installed Firefox version, if any:<br />
pacman -Rd firefox<br />
Then install the newly created version with:<br />
pacman -U firefox-*.pkg.tar.gz<br />
<br />
=== Advanced Configuration ===<br />
Enter {{Codeline|about:config}} in Firefox's address bar to access the advanced configuration options. In the filter, enter {{Codeline|useragent.extra.firefox}}. This will show the current user-agent string, which can be modified as desired. Leave the version part of the string unaltered, and replace {{Codeline|Shiretoko}} with "Firefox" in order to make the browser identify itself with the traditional user-agent string.<br />
<br />
=== Branding without recompilation ===<br />
To brand "Shiretoko" without recompiling the whole browser, it is required to replace the Bon Echo icons with the official Firefox icons, and change the string "Shiretoko" in a few files. The [http://bbs.archlinux.org/viewtopic.php?id=44320 firebrand] script takes care of this (see note in bold in the initial thread post). Run it (as root) after an upgrade or installation of firefox. To revert to the Shiretoko brand again, simply reinstall firefox. The script will by default download the icons every time it is run. To "cache" the icons locally for later firefox upgrades, set the {{Codeline|NEWICONSDIR}} variable to a suitable directory, for instance:<br />
NEWICONSDIR=/usr/local/share/firebrand<br />
<br />
== Fonts ==<br />
<br />
=== DPI ===<br />
Modifying the following value can help improve the way fonts looks in Firefox if the system's DPI is below 96. Firefox, by default, uses 96 and only uses the system's DPI if it is a higher value. To force the system's DPI regardless of its value, type about:config into the address bar and search for '''layout.css.dpi'''. Change it to '''0'''.<br />
<br />
=== Font Replacement ===<br />
Another way to improve how fonts look is to replace them with another. Add to, or create a {{Filename|~/.fonts.conf}} file with the following:<br />
<br />
<match target="pattern" name="family" ><br />
<test name="family" qual="any" ><br />
<string>'''Helvetica'''</string><br />
</test><br />
<edit mode="assign" name="family" ><br />
<string>'''Bitstream Vera Sans'''</string><br />
</edit><br />
</match><br />
The first font name is the one being replaced, whereas the second is the replacement font.<br />
<br />
'''For more information on font configuration, please read [[Font Configuration]]'''<br />
<br />
=== Default font settings from MS Windows ===<br />
Below are the default font preferences when Firefox is installed in Microsoft Windows. Many web sites use the Microsoft fonts.<br />
<pre><br />
Proportional: Serif Size (pixels): 16<br />
Serif: Times New Roman<br />
Sans-serif: Arial<br />
Monospace: Courier New Size (pixels): 13<br />
</pre><br />
<br />
<br />
== Add-ons ==<br />
Before you try to install add-ons, make sure that your /tmp directory was created with the right permissions. If addons won't install, <code>chmod 1777 /tmp</code> should fix it.<br />
<br />
*[https://addons.mozilla.org/firefox/1865/ Adblock Plus]<br />
:Highly effective ad and popup blocker with lots of options and a simplistic UI.<br />
<br />
*[https://addons.mozilla.org/en-US/firefox/addon/9622 FirefoxNotify]<br />
:Integrate Firefox download complete messages with Linux notifications.<br />
<br />
*[https://addons.mozilla.org/en-US/firefox/addon/220 FlashGot]<br />
:Download all the links, movies and audio clips of a page at the maximum speed with a single click. Very powerful, lightweight and reliable external download manager.<br />
<br />
*[https://addons.mozilla.org/en-US/firefox/addon/722 NoScript]<br />
:Selectively blocks javascript, flash, and other types of content. Allows active content to run only from trusted sites, and protects the system against XSS and Clickjacking attacks.<br />
<br />
*[https://addons.mozilla.org/firefox/446/ MediaPlayerConnectivity]<br />
:Allows launching an embedded video from a website in an external application. Good for those who have problems with media plugins.<br />
<br />
*[https://addons.mozilla.org/firefox/2553/ CCK Wizard]<br />
:Allows customizing every aspect of Firefox. Title bar, user agent, icons, about graphic, and more. <br />
<br />
*[https://addons.mozilla.org/firefox/59/ User Agent Switcher]<br />
:Adds a menu and a toolbar button to switch the user agent of the browser.<br />
<br />
== Plugins ==<br />
See: [[Browser Plugins]].<br />
<br />
To find out what plugins are installed/enabled, enter:<br />
about:plugins<br />
in the Firefox address bar. Or go to ''Addons'' from the main bar drop downs <!-- I use vimperator so I don't know what's the name --> and select the ''Plugins'' tab.<br />
<br />
== Tips ==<br />
Recommended readings:<br />
*[[Firefox Tips and Tweaks]]<br />
*[[Firefox Widgets]]<br />
*[[Adding Firefox Search Engines As User|Adding Firefox Search Engines]]<br />
<br />
=== Enable Spell Checking ===<br />
Right click in any text entry field and add the dictionary for the solicited language. Restart firefox, and click in a text entry field again to enable spell checking.<br />
<br />
=== Wheel Mouse Scroll Speed ===<br />
To modify the default values (i.e. speed-up) of the wheel mouse scroll speed, type the following into Firefox's address bar:<br />
about:config<br />
Now enter the following into the 'filter' dialog: '''mousewheel.withnokey'''<br />
<br />
*Double-click the entry entitled, '''mousewheel.withnokey.sysnumlines''' and thereby setting its value to '''True'''<br />
*Double-click the entry entitled, '''mousewheel.withnokey.numlines''' and enter the desired number of lines per movement into the box (12, for example).<br />
<br />
Restart Firefox for this setting to take effect.<br />
<br />
=== Speed-Up Firefox by Defragmenting the Profile's SQLite Databases ===<br />
<br />
{{Warning| This procedure may damage the databases in such a way that sessions are not saved properly.}}<br />
<br />
Firefox 3.0, bookmarks, history, passwords are kept in SQLite databases. SQLite databases become fragmented over time and empty spaces appear all around. But, since there are no managing processes checking and optimizing the database, these factors eventually result in a performance hit. A good way to improve startup and some other bookmarks and history related tasks is to defragment and trim unused space from these databases.<br />
<br />
Run '''sqlite3''' {{Codeline|vacuum}} and {{Codeline|reindex}} commands in the profile directory.<br />
<br />
Example:<br />
$ cd ~/.mozilla/firefox/9jdn39sdjk.default<br />
$ sqlite3 urlclassifier3.sqlite 'VACUUM;'<br />
$ sqlite3 urlclassifier3.sqlite 'REINDEX;'<br />
$ sqlite3 places.sqlite 'VACUUM;'<br />
$ sqlite3 places.sqlite 'REINDEX;'<br />
<br />
'''Sample Size Differences Comparison'''<br />
{| border="1"<br />
| SQLite DB || Size Before || Size After || % change<br />
|- <br />
|urlclassifier3.sqlite|| 37 M || 30 M || 19 %<br />
|-<br />
|places.sqlite || 16 M || 2.4 M || 85 %<br />
|-<br />
|}<br />
<br />
To automate the process for all the databases in all the profiles directory, use the following:<br />
for i in `find ~/.mozilla -name \*.sqlite`; do sqlite3 $i vacuum; done<br />
for i in `find ~/.mozilla -name \*.sqlite`; do sqlite3 $i reindex; done<br />
<br />
=== Cache Your Entire Profile into RAM via tmpfs ===<br />
If the system has memory to spare, {{Codeline|tmpfs}} can be used to cache the entire profile directory, which might incur in increased Firefox responsiveness. Full list of possible benifits include:<br />
<br />
*Reduced disk read/writes (ideal when using a SSD)<br />
<br />
*Better user experience through heightened responsive feel<br />
<br />
*Many operations within Firefox become instantaneous (quick search, history, etc.)<br />
<br />
See [[Speed-up Firefox using tmpfs]] for more information<br />
<br />
=== Speed up rendering by disabling pango ===<br />
''Also, font fix for Mozilla suite''<br />
<br />
Add:<br />
export MOZ_DISABLE_PANGO=1<br />
to ~/.bash_profile and relogin for the change to take place.<br />
|'''OR.... just execute it in terminal...?'''|<br />
<br />
=== Firefox keeps creating ~/Desktop even when I don't want it! ===<br />
See [http://support.mozilla.com/tiki-view_forum_thread.php?locale=ja&comments_parentId=428359&forumId=1 here]<br />
<br />
== Projects Related to Firefox ==<br />
<br />
=== Firefox Derivatives ===<br />
*[http://en.wikipedia.org/wiki/Iceweasel Iceweasel] - The name of '''two''' different Firefox forks. One was a GNU project; the name of this project has since changed to [http://en.wikipedia.org/wiki/GNU_IceCat Icecat]. The [http://wiki.debian.org/Iceweasel second] is being developed by Debian and is based on 2.0. At the time of writing the [[AUR]] only has Icecat.<br />
<br />
*[http://en.wikipedia.org/wiki/GNU_IceCat GNU/IceCat] - formerly known as GNU IceWeasel, is a web browser distributed by the GNU Project. IceCat, which is made entirely of free software, is a fork of Mozilla Firefox. It is compatible with the GNU/Linux operating system and almost all of Firefox's addons. GNU/IceCat really can fully replace Firefox.<br />
<br />
*[http://getswiftfox.com/ Swiftfox] - An optimized and processor-specific build of Firefox. Currently available via AUR. It should be noted that, considering Arch Linux has ABS, you could build your own optimized build of Firefox.<br />
<br />
*[http://swiftweasel.sourceforge.net/ Swiftweasel] - Mostly like Swiftfox, but the binaries aren't under proprietary license. Some PKGBUILDs are available in AUR.<br />
<br />
=== Firefox Alternatives ===<br />
*[[Opera]]<br />
:A closed-sourced full-featured web suite.<br />
*[http://en.wikipedia.org/wiki/Epiphany_%28browser%29 Epiphany]<br />
:GNOME's default web browser. Previously used the same rendering engine as firefox, newer versions use webkit.<br />
*[http://en.wikipedia.org/wiki/Konqueror Konqueror]<br />
:KDE's default web browser. Uses the KHTML rendering engine.<br />
*[http://en.wikipedia.org/wiki/Dillo Dillo]<br />
:A very lightweight web browser.<br />
*[http://en.wikipedia.org/wiki/SeaMonkey SeaMonkey]<br />
:The continuation of the original Mozilla suite. Includes web browser, email client, etc.<br />
*[http://en.wikipedia.org/wiki/Midori_(browser) Midori]<br />
:A webkit-based GTK+ browser. Lightweight and Stable, with plenty of features already.<br />
*[http://en.wikipedia.org/wiki/Arora_(web_browser) Arora]<br />
:A webkit-based Qt browser in development, very capable and fast.<br />
*[http://www.uzbl.org uzbl]<br />
:A lightweight webkit browser following the UNIX philosophy; to do one thing and do it well.<br />
*[http://surf.suckless.org/ surf]<br />
:A very small, fast webkit browser, from suckless.org<br />
<br />
=== Firefox customized for Speed ===<br />
Building with [https://developer.mozilla.org/en/Building_with_Profile-Guided_Optimization Profile-Guided Optimization (PGO)] is now available with GCC 4 or newer. A PGO build consists of two passes: a first pass to build instrumented binaries, then a second pass to re-build optimized binaries using profile information gleaned from running the instrumented binaries. The Mozilla build system will run both passes for you, you simply need to provide a script to run the application through some profiling scenarios in between the build passes. [https://wiki.mozilla.org/JavaScript:TraceMonkey TraceMonkey] adds native‐code compilation to Mozilla’s JavaScript engine (known as “SpiderMonkey”). It is based on a technique developed at UC Irvine called “trace trees”, and building on code and ideas shared with the Tamarin Tracing project. The net result is a massive speed increase both in the browser chrome and Web‐page content. <br />
<br />
*[http://aur.archlinux.org/packages.php?ID=22296 firefox-pgo]<br />
:XULRunner independent, PGO optimized<br />
<br />
*[http://aur.archlinux.org/packages.php?ID=22919 firefox-pgo-beta]<br />
:XULRunner independent, PGO optimized, 64-bit TraceMonkey, beta<br />
<br />
'''Experimental'''<br />
*[http://aur.archlinux.org/packages.php?ID=32030 firefox-pgo-minefield]<br />
:Mozilla Firefox customizable web browser (XULRunner independent, PGO optimized, 64-bit TraceMonkey, Dev tree<br />
This package is similar to firefox-pgo and firefox-pgo-beta. The difference is that it will track mozilla-current, the Firefox trunk, via Mercurial.<br />
<br />
*[http://aur.archlinux.org/packages.php?ID=33506 firefox-pgo-minefield-smp]<br />
:Mozilla Firefox customizable web browser (XULRunner independent, PGO optimized, 64-bit TraceMonkey, Dev tree, Multithreaded<br />
See [https://wiki.mozilla.org/Electrolysis Mozilla Electrolysis project] Read instructions given by the .install file to enable SMP, and enjoy!<br />
Expect this to be very unstable for quite a while<br />
<br />
=== Firefox with Better KDE Integration ===<br />
*[http://aur.archlinux.org/packages.php?ID=32598 firefox-kde-opensuse]<br />
:with OpenSUSE patch, integrates better with KDE. OpenSUSE's patch and integration of Firefox with KDE is considered the best by many users.<br />
<br />
*[http://aur.archlinux.org/packages.php?ID=31117 firefox-branded-kde]<br />
:similar to firefox-kde-opensuse and projects are seeing into merging into one package. If it uses the OpenSUSE patch is unknown but it has other features that make Firefox integrate better with KDE<br />
<br />
== Troubleshooting ==<br />
<br />
=== Middle-click errors ===<br />
! The URL is not valid and cannot be loaded.<br />
Another symptom is that middle-clicking results in unexpected behavior, like accessing a random webpage.<br />
<br />
The reason stems from the use of the middle mouse buttons in UNIX-like operating systems. The middle mouse button is used to paste whatever text has been highlighted/added to the clipboard. Then there is the possibly conflicting feature in Firefox, which defaults to loading the url of the corresponding text when the button is depressed. This can be disabled like so:<br />
<br />
Open the browser, and type the following into the address bar:<br />
about:config<br />
Search for '''middlemouse.contentLoadURL''' and set it to false.<br />
<br />
Alternatively, having the traditional scroll cursor on middle-click (default behaviour on Windows browsers) can be achieved by searching for '''general.autoScroll''' and setting it to true.<br />
<br />
=== Backspace does not work as the 'Back' button ===<br />
As per [http://ubuntu.wordpress.com/2006/12/21/fix-firefox-backspace-to-take-you-to-the-previous-page/ this article], the feature has been removed in order to fix a bug. Follow the next steps to retain the original behaviour.<br />
<br />
Open the browser and type the following address:<br />
about:config<br />
Search for '''browser.backspace_action''' and set it to 0 (zero).<br />
<br />
=== Firefox does not remember login information ===<br />
<br />
It maybe cause of a corrupted {{Codeline|cookies.sqlite}} file in [http://support.mozilla.com/en-US/kb/Profiles#How_to_find_your_profile Firefox's profile] folder. In order to fix this, just rename or remove the cookie.sqlite while Firefox is not running.<br />
<br />
Open a terminal of choice and type the following:<br />
$ cd ~/.mozilla/firefox/xxxxxxxx.default/<br />
$ rm -f cookies.sqlite<br />
{{Note|xxxxxxxx represents a random string of 8 characters.}}<br />
<br />
Restart Firefox and see if it solved the problem.<br />
<br />
=== Broken websites / input fields with dark Gtk Themes ===<br />
When using a dark [[GTK]] theme, one might encounter Internet pages with unreadable input and text fields (p.e. Amazon - white text on white background). This can happen because the site only sets either background or text color, and Firefox takes the other one from the theme.<br />
<br />
A work around is to explicitly setting standard colours for all web pages in {{Filename|~/.mozilla/firefox/.../chrome/userContent.css}}.<br />
<br />
The following sets input fields to standard black text / white background; both can be overridden by the displayed site, so that colors are seen as intended:<br />
<pre><br />
input {<br />
background-color: white;<br />
color: black;<br />
}<br />
<br />
textarea {<br />
background-color: white;<br />
color: black;<br />
}<br />
</pre><br />
This will force the colours ("Allow paged to choose their own colors [..]" setting, in the '''Preferences > Content > Color''' dialog):<br />
<pre><br />
input {<br />
background-color: pink !important;<br />
color: green !important;<br />
}<br />
<br />
textarea {<br />
background-color: pink !important;<br />
color: green !important;<br />
}<br />
</pre><br />
Change color values to suit, or use an add-on like [https://addons.mozilla.org/en-US/firefox/addon/2108 Stylish].<br />
<br />
=== Preferences window appears blank ===<br />
This seems to be caused by files used by an older version of Firefox. Removing the <tt>~/.mozilla/firefox/[profile]/chrome</tt> directory fixes it. See the [http://support.mozilla.com/tiki-view_forum_thread.php?locale=fy-NL&comments_parentId=379718&forumId=1#threadId391374 Mozilla Support] page.<br />
<br />
=== File association problems ===<br />
For non-[[GNOME]] users, Firefox may not associate file types (in the "Open With" part of the download dialog). Installing {{Package Official|libgnome}} ammends the problem:<br />
pacman -S libgnome<br />
<br />
=== "Pop-in" Facebook chat won't work ===<br />
Facebook only enables the pop-in chat feature for specific browsers, your browser is most likely not one of those. You can change your user agent to mimic a specific browser version.<br />
<br />
In Firefox it's quite easy:<br />
Open a new tab, insert in the address bar following: about:config<br />
Click on the button and be careful<br />
Filter for useragent<br />
Doubleclick on the value and insert something like: Firefox/3.5.3 (It was Shiretoko/3.5.3 here)<br />
Reload facebook and the pop-in chat should be working again<br />
<br />
== Resources ==<br />
*[http://web.glandium.org/blog/?p=97 Facts about Debian and Mozilla® Firefox]<br />
:An account of the trademark issues from the Firefox package maintainer for Debian.<br />
*[http://www.gnu.org/software/gnuzilla/ Gnuzilla and IceWeasel]<br />
:Official website for the GNU Mozilla forks.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Creating_packages&diff=99931
Creating packages
2010-03-13T00:04:24Z
<p>Daenyth: /* The {{Codeline|build()}} function */ $stardir must die</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:Package development (English)]]<br />
[[Category:Guidelines (English)]]<br />
{{i18n|Creating Packages}}<br />
{{Article summary start}}<br />
{{Article summary text|A detailed description of the package building process. Covers package creation, testing, and submission to the [[AUR]].}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Build System}}<br />
{{Article summary wiki|Arch User Repository}}<br />
{{Article summary wiki|makepkg}}<br />
{{Article summary wiki|pacman}}<br />
{{Article summary wiki|PKGBUILD}}<br />
{{Article summary wiki|PKGBUILD Tricks}}<br />
{{Article summary wiki|VCS PKGBUILD Guidelines}}<br />
{{Article summary end}}<br />
<br />
This article aims to assist users creating their own packages using the Arch Linux "ports-like" build system. It covers creation of a [[PKGBUILD]] &ndash; a package build description file sourced by {{Codeline|makepkg}} to create a binary package from source. If already in possession of a {{Filename|PKGBUILD}}, see [[makepkg]].<br />
<br />
== Overview == <br />
<br />
Packages in Arch Linux are built using the [[makepkg]] utility and the information stored in a [[PKGBUILD]] file. When {{Codeline|makepkg}} is run, it searches for a {{Filename|PKGBUILD}} in the current directory and follows the instructions therein to either compile or otherwise acquire the required files to be packaged within a package file ({{Filename|pkgname.pkg.tar.gz}}). The resulting package contains binary files and installation instructions; readily installed with [[pacman]].<br />
<br />
An Arch package is no more than a gzipped tar archive, or 'tarball', which contains:<br />
<br />
* The binary files to install<br />
<br />
* {{Filename|.PKGINFO}}: contains all the metadata needed by pacman to deal with packages, dependencies, etc.<br />
<br />
* {{Filename|.INSTALL}}: an optional file used to execute commands after the install/upgrade/remove stage. (This file is present only if specified in the {{Filename|PKGBUILD}}.)<br />
<br />
* {{Filename|.Changelog}}: an optional file kept by the package maintainer documenting the changes of the package. (It is not present in all packages.)<br />
<br />
== Preparation ==<br />
<br />
===Prerequisite software===<br />
<br />
First ensure that the necessary tools are installed. The package group "base-devel" should be sufficient; it includes ''make'' and additional tools needed for compiling from source.<br />
<br />
# pacman -S base-devel<br />
<br />
One of the key tools for building packages is [[makepkg]] (provided by {{Package Official|pacman}}) which does the following:<br />
#Checks if package dependencies are installed.<br />
#Downloads the source file(s) from the specified server(s).<br />
#Unpacks the source file(s).<br />
#Compiles the software and installs it under a fakeroot environment.<br />
#Strips symbols from binaries and libraries.<br />
#Generates the package meta file which is included with each package.<br />
#Compress the fakeroot environment into a package file.<br />
#Stores the package file in the configured destination directory, which is the present working directory by default.<br />
<br />
=== Download and test the installation ===<br />
<br />
Download the source tarball of the software you want to package, extract it, and follow the author's steps to install the program. Make a note of all commands and/or steps needed to compile and install it. You will be repeating those same commands in the ''PKGBUILD'' file.<br />
<br />
Most software authors stick to the 3-step build cycle:<br />
<br />
./configure<br />
make<br />
make install<br />
<br />
This is a good time to make sure the program is working correctly.<br />
<br />
== Creating a PKGBUILD ==<br />
<br />
When you run {{Codeline|makepkg}}, it will look for a {{Filename|PKGBUILD}} file in the present working directory. If a {{Filename|PKGBUILD}} file is found it will download the software's source code and compile it according to the instructions specified in the {{Filename|PKGBUILD}} file. The instructions must be fully interpretable by the [[Wikipedia:Bash|Bash]] shell. After successful completion, the resulting binaries and metadata of the package, i.e. package version and dependencies, are packed in a {{Filename|pkgname.pkg.tar.gz}} package file that can be installed with {{Codeline|pacman -U [package file]}}.<br />
<br />
To begin with a new package, you should first create an empty working directory, (preferably {{Filename|~/abs/'''pkgname'''}}), change into that directory, and create a {{Filename|PKGBUILD}} file. You can either copy the prototype PKGBUILD {{Filename|/usr/share/pacman/PKGBUILD.proto}} to your working directory or copy a {{Filename|PKGBUILD}} from a similar package. The latter may be useful if you only need to change a few options.<br />
<br />
=== Defining PKGBUILD variables ===<br />
<br />
The {{Filename|PKGBUILD}} file contains metadata about a package. It is a plain text file. The following is a prototype {{Filename|PKGBUILD}}. It can be found in {{Filename|/usr/share/pacman}} along with other templates.<br />
<br />
{{File|name=/usr/share/pacman/PKGBUILD.proto|content=<br />
# This is an example PKGBUILD file. Use this as a start to creating your own,<br />
# and remove these comments. For more information, see 'man PKGBUILD'.<br />
# Note: Please fill out the license field for your package. If it is unknown,<br />
# then please put 'unknown'.<br />
<br />
# Contributor: Your Name <youremail@domain.com><br />
pkgname=NAME<br />
pkgver=VERSION<br />
pkgrel=1<br />
pkgdesc=""<br />
arch=()<br />
url=""<br />
license=('GPL')<br />
groups=()<br />
depends=()<br />
makedepends=()<br />
provides=()<br />
conflicts=()<br />
replaces=()<br />
backup=()<br />
install=<br />
source=($pkgname-$pkgver.tar.gz)<br />
noextract=()<br />
md5sums=() #generate with 'makepkg -g'<br />
<br />
build() {<br />
cd "$srcdir/$pkgname-$pkgver"<br />
<br />
./configure --prefix=/usr<br />
make || return 1<br />
make DESTDIR="$pkgdir/" install<br />
}<br />
}}<br />
<br />
An explanation of possible {{Filename|PKGBUILD}} variables can be found in the [[PKGBUILD]] article.<br />
<br />
=== The {{Codeline|build()}} function ===<br />
<br />
Now you need to implement the {{Codeline|build()}} function in the {{Filename|PKGBUILD}} file. This function uses common shell commands in [http://en.wikipedia.org/wiki/Bash Bash] syntax to automatically compile software and create a {{Filename|pkg}} directory to install the software to. This allows ''makepkg'' to package files without having sift through your filesystem.<br />
<br />
The first step in the {{Codeline|build()}} function is to change into the directory created by uncompressing the source tarball. In most common cases the first command will look like this:<br />
<br />
cd $srcdir/$pkgname-$pkgver<br />
<br />
Now, you need to list the same commands you used when you manually compiled the software. The {{Codeline|build()}} function in essence automates everything you did by hand and compiles the software in the fakeroot build environment. If the software you are packaging uses a configure script, it is good practice to use {{Codeline|1=--prefix=/usr}} when building packages for ''pacman''. A lot of software installs files relative to the {{Filename|/usr/local}} directory, which should only be done if you are manually building from source. All Arch Linux packages should use the {{Filename|/usr}} directory. As seen in the {{Filename|/usr/share/pacman/PKGBUILD.proto}} file, the next two lines often look like this:<br />
<br />
./configure --prefix=/usr<br />
make || return 1<br />
<br />
The final step in the {{Codeline|build()}} function is to put the compiled files in a directory where ''makepkg'' can retrieve them to create a package. This by default is the {{Filename|pkg}} directory - a simple fakeroot environment. The {{Filename|pkg}} directory replicates the hierarchy of the root file system of the software's installation paths. If you have to manually place files under the root of your filesystem, you should install them in the {{Filename|pkg}} directory under the same directory structure. For example, if you want to install a file to {{Filename|/usr/bin}}, it should instead be placed under {{Filename|$pkgdir/usr/bin}}. Very few install procedures require the user to copy dozens of files manually. Instead, for most software, calling {{Codeline|make install}} will do so. The final line should look like the following in order to correctly install the software in the {{Filename|pkg}} directory:<br />
<br />
make DESTDIR=$pkgdir install || return 1<br />
<br />
{{Note|It is sometimes the case where {{Codeline|DESTDIR}} is not used in the {{Filename|Makefile}}; you may need to use {{Codeline|prefix}} instead. If the package is built with ''autoconf''/''automake'', use {{Codeline|DESTDIR}}; this is what is [http://sources.redhat.com/automake/automake.html#Install documented] in the manuals. If {{Codeline|DESTDIR}} does not work, try building with {{Codeline|1=make prefix="$pkgdir/usr/" install}}. If that does not work, you'll have to look further into the install commands that are executed by "{{Codeline|make <...> install}}".}}<br />
<br />
In some odd cases, the software expects to be run from a single directory. In such cases, it is wise to simply copy these to {{Filename|$pkgdir/opt}}.<br />
<br />
More often than not, the installation process of the software will create any subdirectories below the {{Filename|pkg}} directory. If it does not, however, ''makepkg'' will generate a lot of errors and you will need to manually create subdirectories by adding the appropriate {{Codeline|mkdir -p}} commands in the {{Codeline|build()}} function before the installation procedure is run.<br />
<br />
Also, ''makepkg'' defines three variables that you should use as part of the build and install process:<br />
; {{Codeline|startdir}}: This contains the absolute path to the directory where the {{Filename|PKGBUILD}} file is located. This variable used to be used in combination with {{Filename|/src}} or {{Filename|/pkg}} postfixes, but the use of {{Codeline|srcdir}} and {{Codeline|pkgdir}} variables is the modern method. {{Codeline|$startdir/src}} is '''not''' guaranteed to be the same as {{Codeline|$srcdir}}, and likewise for {{Codeline|$pkgdir}}. Use of this variable is deprecated and strongly discouraged.<br />
; {{Codeline|srcdir}}: This points to the directory where ''makepkg'' extracts or copies all source files.<br />
; {{Codeline|pkgdir}}: This points to the directory where ''makepkg'' bundles the installed package, which becomes the root directory of your built package.<br />
<br />
{{Note|''makepkg'', and thus the {{Codeline|build()}} function, is intended to be non-interactive. Interactive utilities or scripts called in the {{Codeline|build()}} function may break ''makepkg'', particularly if it is invoked with build-logging enabled ({{Codeline|-l}}). (See [http://bugs.archlinux.org/task/13214 Arch Linux Bug #13214].)}}<br />
<br />
=== Additional guidelines ===<br />
<br />
Please read [[Arch Packaging Standards]] thoroughly for best practices and additional considerations.<br />
<br />
== Testing the PKGBUILD and package ==<br />
<br />
As you are writing the {{Codeline|build()}} function, you will want to test your changes frequently to ensure there are no bugs. You can do this using the {{Codeline|makepkg}} command in the directory containing the {{Filename|PKGBUILD}} file. With a properly formatted {{Filename|PKGBUILD}}, makepkg will create a package; with a broken or unfinished {{Filename|PKGBUILD}}, it will raise an error.<br />
<br />
If makepkg finishes successfully, it will place a file named {{Filename|pkgname-pkgver.pkg.tar.gz}} in your working directory. This package can be installed with the {{Codeline|pacman -U}} command. However, just because a package file was built does not imply that it is fully functional. It might conceivably contain only the directory and no files whatsoever if, for example, a prefix was specified improperly. You can use pacman's query functions to display a list of files contained in the package and the dependencies it requires with {{Codeline|pacman -Qlp [package file]}} and {{Codeline|pacman -Qip [package file]}} respectively.<br />
<br />
If the package looks sane, then you are done! However, if you plan on releasing the {{Filename|PKGBUILD}} file, it is imperative that you check and double-check the contents of the {{Codeline|depends}} array. <br />
<br />
Also ensure that the package binaries actually ''run'' flawlessly! It is annoying to release a package that contains all necessary files, but crashes because of some obscure configuration option that doesn't quite work well with the rest of the system. If you're only going to compile packages for your own system, though, you don't need to worry too much about this quality assurance step, as you're the only person suffering from mistakes, after all.<br />
<br />
=== {{Codeline|ldd}} and {{Codeline|namcap}} ===<br />
<br />
Dependencies are the most common packaging error. There are two excellent tools you can use to check dependencies. The first one is ''ldd'', which will show you the shared library dependencies of dynamic executables:<br />
$ ldd gcc<br />
linux-gate.so.1 => (0xb7f33000)<br />
libc.so.6 => /lib/libc.so.6 (0xb7de0000)<br />
/lib/ld-linux.so.2 (0xb7f34000)<br />
<br />
The other tool is [[namcap]], which not only checks for dependencies but the overall sanity of your package. Please read the [[namcap]] article for a detailed description.<br />
<br />
== Submitting packages to the AUR ==<br />
<br />
Please read [[AUR User Guidelines#Submitting Packages to UNSUPPORTED]] for a detailed description of the submission process.<br />
<br />
== Summary ==<br />
<br />
#Download the source tarball of the software you want to package.<br />
#Try compiling the package and installing it into an arbitrary directory.<br />
#Copy over the prototype {{Filename|/usr/share/pacman/PKGBUILD.proto}} and rename it to {{Filename|PKGBUILD}} in a temporary working directory -- preferably {{Filename|~/abs/}}.<br />
#Edit the {{Filename|PKGBUILD}} according to the needs of your package.<br />
#Run {{Codeline|makepkg}} and see whether the resulting package is built correctly.<br />
#If not, repeat the last two steps.<br />
<br />
=== Warnings ===<br />
<br />
* Before you can automate the package building process, you should have done it manually at least once unless you know ''exactly'' what you're doing ''in advance'', in which case you would not be reading this in the first place. Unfortunately, although a good bunch of program authors stick to the 3-step build cycle of "{{Codeline|./configure}}; {{Codeline|make}}; {{Codeline|make install}}", this is not always the case, and things can get real ugly if you have to apply patches to make everything work at all. Rule of thumb: If you can't get the program to compile from the source tarball, and make it install itself to a defined, temporary subdirectory, you don't even need to try packaging it. There isn't any magic pixie dust in {{Codeline|makepkg}} that makes source problems go away.<br />
* In a few cases, the packages are not even available as source and you have to use something like {{Codeline|sh installer.run}} to get it to work. You will have to do quite a bit of research (read READMEs, INSTALL instructions, man pages, perhaps ebuilds from Gentoo or other package installers, possibly even the MAKEFILEs or source code) to get it working. In some really bad cases, you have to edit the source files to get it to work at all. However, {{Codeline|makepkg}} needs to be completely autonomous, with no user input. Therefore if you need to edit the makefiles, you may have to bundle a custom patch with the {{Filename|PKGBUILD}} and install it from inside the {{Codeline|build()}} function, or you might have to issue some {{Codeline|sed}} commands from inside the {{Codeline|build()}} function.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Patching_packages&diff=99930
Patching packages
2010-03-13T00:00:50Z
<p>Daenyth: /* Applying patches */ Update references away from $startdir</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:HOWTOs (English)]]<br />
:''There have been quite a few questions about creating and/or applying patches to packages when using ABS. This document outlines the steps and options required to do these tasks. http://www.kegel.com/academy/opensource.html also has some useful information on patching files.''<br />
<br />
==Creating patches==<br />
If you are attempting to use a patch that you got from elsewhere (ie: you downloaded a patch to the Linux kernel), you can skip to the next section. However, if you need to edit source code, make files, configuration files, etc, you will need to be able to create a patch.<br />
<br />
Note: If you need only to change one or two lines in a file (ie: a Makefile), you may be better off investigating the properties of <code>sed</code> instead.<br />
<br />
Creating a patch for a package involves creating two copies of the package, editing the new copy, and creating a unified diff between the two files. When creating an Arch Linux package, this can be done as follows:<br />
<br />
# Add the download source of the file to the source array of the <code>PKGBUILD</code> you are creating. Of course, if you are altering an existing PKGBUILD, this step is taken care of.<br />
# Create a dummy (empty, or containing a single <code>echo</code> command is good) build() function. If you are altering an existing <code>PKGBUILD</code>, you should comment out most of the lines of the build function, as you're likely going to be running <code>makepkg</code> several times, and you won't want to spend a lot of time waiting for a broken package to build.<br />
# Run <code>makepkg -o</code> This will download the source files you need to edit into the <code>src</code> directory.<br />
# Change to the <code>src</code> directory. In standard cases, there will be a directory containing a bunch of files that were unzipped or untarred from a downloaded archive there (Sometimes it's a single file, but diffs work on multiple files too!) You should make two copies of these directories. One is a pristine copy that makepkg won't be allowed to manipulate, and one will be the new copy that you will create a patch from. You can name the two copies <code>package.pristine</code> and <code>package.new</code> or something similar.<br />
# Change into the <code>package.new</code> directory. Edit whichever files need to be edited. The changes needed depend on what the patch has to do; it might correct a Makefile paths, it may have to correct source errors (for example, to agree with <code>gcc 3.4</code>), and so on. You can also edit files in subfolders of the <code>package.new</code> directory, of course. '''Do not''' issue any commands that will inadvertently create a bunch of files in the <code>package.new</code> directory; ie: do not try to compile the program to make sure your changes work. The problem is that all the new files will show up in the patch, and you don't want that. Instead, apply the patch to another copy of the directory ('''not''' the pristine directory), either manually with the <code>patch</code> command, or in the <code>PKGBUILD</code> (described below) and test the changes from there.<br />
# Change back to the <code>src</code> directory.<br />
# Run <code>diff -aur package.pristine package.new</code> This will output all the changes you made in unified diff format. You can scan these to make sure the patch is good.<br />
# Run <code>diff -aur package.pristine package.new > package.patch</code> to capture all the changes in a file named <code>package.patch</code>. This is the file that will be used by patch. You may now apply the changes to a copy of the original directory and make sure they are working properly. You should also check to ensure that the patch does not contain any extraneous details. For example, you don't want the patch to convert all tabs in the files you edited to spaces because your text editor did that behind your back. You can edit the patch either using a text editor, or to be safer (and not accidentally introduce errors into the diff file), edit the original files and create the patch afresh.<br />
<br />
==Applying patches==<br />
This section outlines how to apply patches you created or downloaded from the Internet from within a <code>PKGBUILD</code>'s <code>build()</code> function. Follow these steps:<br />
<br />
# Add an entry to the <code>source</code> array of the <code>PKGBUILD</code> for the patch file, separated from the original source url by a space. If the file is available online, you can provide the full URL and it will automatically be downloaded and placed in the <code>src</code> directory. If it is a patch you created yourself, or is otherwise not available, you should place the patch file in the same directory as the <code>PKGBUILD</code> file, and just add the name of the file to the source array so that it is copied into the <code>src</code> directory. If you redistribute the <code>PKGBUILD</code>, you should, of course, include the patch with the <code>PKGBUILD</code>.<br />
# Then add an entry to the <code>md5sums</code> array. You can generate sum of your patch using <code>md5sum</code> tool.<br />
# Create the <code>build()</code> function in the <code>PKGBUILD</code>. In most cases you will want to apply the patch first thing in the function, but you will know best where the patch lines need to be applied.<br />
# The first step is to change into the directory that needs to be patched (in the <code>build()</code> function, not on your terminal! You want to automate the process of applying the patch). You can do this with something like <code>cd $srcdir/$pkgname-$pkgver</code> or something similar. <code>$pkgname-$pkgver</code> is often the name of a directory created by untarring a downloaded source file, but not in all cases.<br />
# Now you simply need to apply the patch from within this directory. This is very simply done by adding <br />
patch -p1 -i ../pkgname.patch <br />
to your <code>build()</code> function, changing <code>pkgname.patch</code> to the name of the file containing the diff (the file that was automatically copied into your <code>src</code> directory because it was in the <code>source</code> array of the <code>PKGBUILD</code> file).<br />
<br />
An example build array with patch function:<br />
build() {<br />
cd $srcdir/${pkgname}-${pkgver}<br />
patch -Np1 -i ../eject.patch || return 1<br />
./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/xfce4 \<br />
--localstatedir=/var --disable-static \<br />
--enable-mcs-plugin --enable-python<br />
make || return 1<br />
make DESTDIR=$pkgdir install<br />
}<br />
<br />
Run <code>makepkg</code> (from the terminal now). If all goes well, the patch will be automatically applied, and your new package will contain whatever changes were included in the patch. If not, you may have to experiment with the <code>-p</code> option of patch. read <code>man patch</code> for more information.<br />
Basically it works as follows. If the diff file was created to apply patches to files in <code>myversion/</code>, the diff files will be applied to <code>myversion/file</code>. You are running it from within the <code>yourversion/</code> directory (because you cd'd into that directory in the <code>PKGBUILD</code>), so when patch applies the file, you want it to apply it to the file <code>file</code>, taking off the <code>myversion/</code> part. <code>-p1</code> does this, by removing one directory from the path. However, if the developer patched in <code>myfiles/myversion</code>, you need to remove two directories, so you use <code>-p2</code>.<br />
<br />
If you don't apply a -p option, it will take off all directory structure. This is ok if all the files are in the base directory, but if the patch was created on <code>myversion/</code> and one of the edited files was <code>myversion/src/file</code>, and you run the patch without a <code>-p</code> option from within <code>yourversion</code>, it will try to patch a file named <code>yourversion/file</code>.<br />
<br />
Most developers create patches from the parent directory of the directory that is being patched, so <code>-p1</code> will usually be right.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Zsh&diff=99929
Zsh
2010-03-12T23:57:48Z
<p>Daenyth: /* Enable Unicode (obsolete) */ If this is truly obsolete then the info no longer belongs on the wiki</p>
<hr />
<div>[[Category:Command shells (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Zsh}}<br />
{{i18n_entry|Česky|Zsh (Česky)}}<br />
{{i18n_links_end}}<br />
[http://www.zsh.org Zsh] is a powerful shell that operates as both an interactive shell and as a scripting language interpreter. While being similar to [[Bash]], it offers many advantages such as:<br />
<br />
*Faster<br />
*Improved tab completion<br />
*Improved globbing<br />
*Improved array handling<br />
*Fully customisable<br />
<br />
The Zsh FAQ offers [http://zsh.sourceforge.net/FAQ/zshfaq01.html#l4 more reasons] to use Zsh as your shell.<br />
<br />
==Installation Instructions==<br />
<br />
Before starting lets find out what shell is currently being used:<br />
<br />
$ echo $SHELL<br />
<br />
===Installing===<br />
<br />
To install the package for Zsh, run:<br />
<br />
# pacman -S zsh<br />
<br />
Before proceeding with the next step to make Zsh your default shell, you should ensure that it has been installed correctly by running Zsh in a xterm or in a tty:<br />
<br />
$ zsh<br />
<br />
If the installation has gone smoothly you should now find yourself staring at a rather unfamiliar prompt, for now just type exit:<br />
<br />
$ exit<br />
<br />
===Making Zsh your default shell===<br />
<br />
To change a user's default shell without root access, the chsh command is used. The chsh command can be used to change a user's default shell without root access if the shell is listed in {{Filename|/etc/shells}}. If you installed Zsh using pacman, Zsh should already have an entry in {{Filename|/etc/shells}}. <br />
<br />
To proceed you need to know the full path for Zsh, so run:<br />
<br />
$ which zsh<br />
<br />
Change the default shell for the current user (e.g. if you have no root access):<br />
<br />
$ chsh -s /bin/zsh<br />
<br />
An alternative way to change a user's default shell is with the command usermod. The disadvantage of this method is that you must have root access. But multiple users default shell can be changed quickly as root, using usermod or chsh. <br />
<br />
Change the default shell for multiple users, using usermod:<br />
<br />
# usermod -s /bin/zsh username<br />
<br />
Change the default shell for multiple users, using chsh:<br />
<br />
# chsh -s /bin/zsh username<br />
<br />
{{Note| The user needs to logout and log back in, to start using Zsh as their default shell.}}<br />
<br />
After logging back in, the user can verify that Zsh is their default shell by (it also looks a little different unless you have suse theme ('prompt suse' in .zshrc)):<br />
<br />
$ echo $SHELL<br />
<br />
==Configuration==<br />
<br />
Although Zsh is usable out of the box, it is almost certainly not set up the way you would like to use it, but due to the sheer amount of customisation available in Zsh, creating a Zsh config can be a daunting and time-consuming experience.<br />
<br />
Included below is a sample configuration file, it provides a decent set of default options as well as giving examples of many ways that Zsh can be customised. In order to use this configuration save it as a file named {{Filename|.zshrc}}. You can then apply the changes without needing to logout and then back in by running:<br />
<br />
$ source ~/.zshrc<br />
<br />
===Simple .zshrc===<br />
<br />
Here is a simple {{Filename|.zshrc}}, that should be sufficient to get you started:<br />
<br />
{{File|name=~/.zshrc|content=<br />
autoload -U compinit promptinit<br />
compinit<br />
promptinit<br />
<br />
# This will set the default prompt to the walters theme<br />
prompt walters}}<br />
<br />
===/etc/profile===<br />
<br />
Much like the {{Filename|/etc/profile}} used for Bash, this file is for global Zsh settings & is a good place from which to run scripts from {{Filename|/etc/profile.d/}} and set up environment variables such as $PATH. <br />
When setting up $PATH etc. in {{Filename|.zshrc}} and using a login-manager such as kdm, you may find those settings not being taken up by the window-manager, whereas they are when using {{Filename|/etc/profile}}. <br />
<br />
An example configuration: <br />
<br />
{{File|name=/etc/profile|content=<br />
<br />
###############<br />
# Zsh profile #<br />
###############<br />
<br />
export PATH="/bin:/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin:/opt/bin"<br />
<br />
export MANPATH="/usr/man:/usr/X11R6/man"<br />
export LESSCHARSET="latin1"<br />
export LESS="-R"<br />
<br />
# load profiles from /etc/profile.d<br />
# (to disable a profile, just remove execute permission on it)<br />
if [ `ls -A1 /etc/profile.d/ | wc -l` -gt 0 ]; then<br />
for profile in /etc/profile.d/*.sh; do<br />
if [ -x $profile ]; then<br />
. $profile<br />
fi<br />
done<br />
unset profile<br />
fi<br />
<br />
<br />
# Locale settings (find your locale with 'locale -a')<br />
export LANG="en_GB.utf8"<br />
export LC_COLLATE="C"<br />
umask 022}}<br />
<br />
{{Note| By default zsh would use /etc/zprofile. To follow the KISS philosophy it uses /etc/profile instead.}}<br />
<br />
=== Command Completion ===<br />
Perhaps the most compelling feature of Zsh is its advanced autocompletion abilities. At the very least, you will want to enable autocompletion in your {{Filename|.zshrc}}. To enable autocompletion, add the following to:<br />
<br />
{{File|name=~/.zshrc|content=<br />
autoload -U compinit<br />
compinit}}<br />
<br />
For autocompletion with an arrow-key driven interface, add the following to:<br />
{{File|name=~/.zshrc|content=<br />
zstyle ':completion:*' menu select}}<br />
<br />
=== Key Bindings ===<br />
Zsh doesn't read {{Filename|/etc/inputrc}}, which tells the shell what commands sent by the terminal emulator mean. To have some standard key bindings working on Zsh, add something like this to:<br />
<br />
{{File|name=~/.zshrc|content= <br />
# key bindings<br />
bindkey "\e[1~" beginning-of-line<br />
bindkey "\e[4~" end-of-line<br />
bindkey "\e[5~" beginning-of-history<br />
bindkey "\e[6~" end-of-history<br />
bindkey "\e[3~" delete-char<br />
bindkey "\e[2~" quoted-insert<br />
bindkey "\e[5C" forward-word<br />
bindkey "\eOc" emacs-forward-word<br />
bindkey "\e[5D" backward-word<br />
bindkey "\eOd" emacs-backward-word<br />
bindkey "\e\e[C" forward-word<br />
bindkey "\e\e[D" backward-word<br />
bindkey "^H" backward-delete-word<br />
# for rxvt<br />
bindkey "\e[8~" end-of-line<br />
bindkey "\e[7~" beginning-of-line<br />
# for non RH/Debian xterm, can't hurt for RH/DEbian xterm<br />
bindkey "\eOH" beginning-of-line<br />
bindkey "\eOF" end-of-line<br />
# for freebsd console<br />
bindkey "\e[H" beginning-of-line<br />
bindkey "\e[F" end-of-line<br />
# completion in the middle of a line<br />
bindkey '^i' expand-or-complete-prefix}}<br />
<br />
===Prompts===<br />
<br />
There is a quick and easy way to set up a colored prompt in Zsh. Make sure that prompt is set to autload in your {{Filename|.zshrc}}. This can be done by adding these lines to:<br />
<br />
{{File|name=~/.zshrc|content=<br />
autoload -U promptinit<br />
promptinit}}<br />
<br />
You can now see available prompts by running the command:<br />
<br />
$ prompt -l<br />
<br />
To try one of the commands that is listed, use the command prompt followed by the name of the prompt you like. For example, to use the "walters" prompt, you would enter:<br />
<br />
$ prompt walters<br />
<br />
===Advanced .zshrc===<br />
<br />
This is an example of a more advanced {{Filename|.zshrc}}:<br />
<br />
{{File|name=~/.zshrc|content=<nowiki><br />
########################################################### <br />
# Options for Zsh<br />
<br />
export HISTFILE=~/.zsh_history<br />
export HISTSIZE=50000<br />
export SAVEHIST=50000<br />
eval `dircolors -b`<br />
<br />
autoload -U compinit compinit<br />
setopt autopushd pushdminus pushdsilent pushdtohome<br />
setopt autocd<br />
setopt cdablevars<br />
setopt ignoreeof<br />
setopt interactivecomments<br />
setopt nobanghist<br />
setopt noclobber<br />
setopt HIST_REDUCE_BLANKS<br />
setopt HIST_IGNORE_SPACE<br />
setopt SH_WORD_SPLIT<br />
setopt nohup<br />
<br />
# PS1 and PS2<br />
export PS1="$(print '%{\e[1;34m%}%n%{\e[0m%}'):$(print '%{\e[0;34m%}%~%{\e[0m%}')$ "<br />
export PS2="$(print '%{\e[0;34m%}>%{\e[0m%}')"<br />
<br />
# Vars used later on by Zsh<br />
export EDITOR="gvim -geom 82x35"<br />
export BROWSER=links<br />
export XTERM="aterm +sb -geometry 80x29 -fg black -bg lightgoldenrodyellow -fn -xos4-terminus-medium-*-normal-*-14-*-*-*-*-*-iso8859-15"<br />
<br />
##################################################################<br />
# Stuff to make my life easier<br />
<br />
# allow approximate<br />
zstyle ':completion:*' completer _complete _match _approximate<br />
zstyle ':completion:*:match:*' original only<br />
zstyle ':completion:*:approximate:*' max-errors 1 numeric<br />
<br />
# tab completion for PID :D<br />
zstyle ':completion:*:*:kill:*' menu yes select<br />
zstyle ':completion:*:kill:*' force-list always<br />
<br />
# cd not select parent dir<br />
zstyle ':completion:*:cd:*' ignore-parents parent pwd<br />
<br />
##################################################################<br />
# Key bindings<br />
# http://mundy.yazzy.org/unix/zsh.php<br />
# http://www.zsh.org/mla/users/2000/msg00727.html<br />
<br />
typeset -g -A key<br />
bindkey '^?' backward-delete-char<br />
bindkey '^[[1~' beginning-of-line<br />
bindkey '^[[5~' up-line-or-history<br />
bindkey '^[[3~' delete-char<br />
bindkey '^[[4~' end-of-line<br />
bindkey '^[[6~' down-line-or-history<br />
bindkey '^[[A' up-line-or-search<br />
bindkey '^[[D' backward-char<br />
bindkey '^[[B' down-line-or-search<br />
bindkey '^[[C' forward-char <br />
<br />
##################################################################<br />
# My aliases<br />
<br />
# Set up auto extension stuff<br />
alias -s html=$BROWSER<br />
alias -s org=$BROWSER<br />
alias -s php=$BROWSER<br />
alias -s com=$BROWSER<br />
alias -s net=$BROWSER<br />
alias -s png=feh<br />
alias -s jpg=feh<br />
alias -s gif=feg<br />
alias -s sxw=soffice<br />
alias -s doc=soffice<br />
alias -s gz=tar -xzvf<br />
alias -s bz2=tar -xjvf<br />
alias -s java=$EDITOR<br />
alias -s txt=$EDITOR<br />
alias -s PKGBUILD=$EDITOR<br />
<br />
# Normal aliases<br />
alias ls='ls --color=auto -F'<br />
alias lsd='ls -ld *(-/DN)'<br />
alias lsa='ls -ld .*'<br />
alias f='find |grep'<br />
alias c="clear"<br />
alias dir='ls -1'<br />
alias gvim='gvim -geom 82x35'<br />
alias ..='cd ..'<br />
alias nicotine='/home/paul/downloads/nicotine-1.0.8rc1/nicotine'<br />
alias ppp-on='sudo /usr/sbin/ppp-on'<br />
alias ppp-off='sudo /usr/sbin/ppp-off'<br />
alias firestarter='sudo su -c firestarter'<br />
alias mpg123='mpg123 -o oss'<br />
alias mpg321='mpg123 -o oss'<br />
alias vba='/home/paul/downloads/VisualBoyAdvance -f 4'<br />
alias hist="grep '$1' /home/paul/.zsh_history"<br />
alias irssi="irssi -c irc.freenode.net -n yyz"<br />
alias mem="free -m"<br />
alias msn="tmsnc -l hutchy@subdimension.com"<br />
<br />
# command L equivalent to command |less<br />
alias -g L='|less' <br />
<br />
# command S equivalent to command &> /dev/null &<br />
alias -g S='&> /dev/null &'<br />
<br />
# type a directory's name to cd to it<br />
compctl -/ cd<br />
</nowiki>}}<br />
<br />
There are many more ways that you can customise Zsh, obviously far too many to list here, see the [http://zsh.sourceforge.net/Doc/Release/zsh.html Zsh manual] for more information.<br />
<br />
===Sample .zshrc files===<br />
<br />
Here is a list of {{Filename|.zshrc}} files. Feel free to add your own:<br />
<br />
* Øyvind 'Mr.Elendig' Heggstad <=> Basic setup, with dynamic prompt and window title/hardinfo <=> http://arch.har-ikkje.net/configs/home/dot.zshrc<br />
<br />
==Uninstallation==<br />
If you decide that Zsh is not the shell for you and you want to return to Bash. You must first change your default shell back to Bash, before removing the Zsh package.<br />
<br />
Follow, [[Zsh#Making Zsh your default shell]] to change the default shell back to Bash, just replace zsh with bash.<br />
<br />
Now you can safely remove the Zsh package.<br />
<br />
{{Warning| Failure to follow the above will result in all kinds of problems.}}<br />
<br />
If you did not follow the above, you can still change the default shell back to Bash by editing /etc/passwd as root. For example: <br />
<br />
from:<br />
username:x:1000:1000:Full Name,,,:/home/username:/bin/zsh<br />
to:<br />
username:x:1000:1000:Full Name,,,:/home/username:/bin/bash<br />
<br />
==External Resources==<br />
*[http://zsh.sourceforge.net/Intro/intro_1.html#SEC1 Zsh Introduction]<br />
*[http://zsh.sourceforge.net/Guide/zshguide.html Users Guide]<br />
*[http://zsh.sourceforge.net/Doc/Release/index-frame.html Zsh Docs] (you can choose a different format for the doc in http://zsh.sourceforge.net/Doc/)<br />
*[http://zsh.sourceforge.net/FAQ/zshfaq01.html Zsh FAQ]<br />
*[http://zshwiki.org/home/ Zsh Wiki]<br />
*[http://grml.org/zsh/zsh-lovers.html Zsh-lovers]<br />
*[http://www.bash2zsh.com/zsh_refcard/refcard.pdf Bash2Zsh Reference Card]<br />
<br><br />
*<b>IRC channel:</b> #zsh at irc.freenode.org</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Plymouth&diff=99501
Plymouth
2010-03-10T01:59:47Z
<p>Daenyth: /* Configuration */ link to LUKS page</p>
<hr />
<div>[[Category: Boot process (English)]]<br />
[[Category: Eye candy (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Plymouth}}<br />
{{i18n_entry|Česky|Plymouth (Česky)}}<br />
{{i18n_entry|Italiano|Plymouth (Italiano)}}<br />
{{i18n_links_end}}<br />
<br />
[http://fedoraproject.org/wiki/Releases/FeatureBetterStartup Plymouth] is a project from Fedora that provides a flicker-free graphical boot process. It relies on [[kernel mode setting]] to set the native resolution of the display as early as possible, then provides an eye-candy splash screen leading up to the login manager.<br />
<br />
==Installation==<br />
<br />
{{Note|Kernel mode setting is currently only available for Intel and ATI graphics cards (as of Kernel 2.6.32). Plymouth can run without it, but may fall back to its text-mode plugin.}}<br />
<br />
{{Warning|Plymouth is currently under heavy development and may contain bugs}}<br />
<br />
Before you can use Plymouth, you must enable kernel mode setting. Please refer to the instructions [[ATI#AMD.2FAti_cards_and_KernelModeSetting_.28KMS.29|for ATI cards]] and [[Intel#KMS_.28Kernel_Mode_Setting.29|for Intel cards]]. Both of these require you to rebuild your kernel image. You will also have to do that later on in this article, so you may wish to skip that step for now.<br />
<br />
If you don't have KMS you will need to use [[Framebuffer#Framebuffer_Resolution|framebuffer]] instead. <br />
{{Note|This may well not work. Plymouth is designed to work '''with''' KMS, although it can sometimes work with framebuffer.}}<br />
<br />
Grab Plymouth from the [[AUR]]. It is best to use the [http://aur.archlinux.org/packages.php?ID=26117 git version], as this is most up to date and likely to work better.<br />
<br />
Instructions on installing packages from the AUR are available [[AUR_User_Guidelines#Installing_Packages_from_the_AUR|here]].<br />
<br />
==Configuration==<br />
<br />
First of all, set a theme for plymouth. Plymouth comes with a selection of themes:<br />
#Fade-in: "Simple theme that fades in and out with shimmering stars"<br />
#Glow: "Corporate theme with pie chart boot progress followed by a glowing emerging logo"<br />
#Solar: "Space theme with violent flaring blue star" and <br />
#Spinfinty: "Simple theme that shows a rotating infinity sign in the center of the screen"<br />
Set your desired theme with plymouth-set-default-theme utility, eg:<br />
$ su<br />
# plymouth-set-default-theme spinfinity<br />
<br />
Add plymouth to the hooks array in mkinitcpio.conf. It '''must''' be added ''after'' base udev and autodetect for it to work.<br />
# nano /etc/mkinitcpio.conf<br />
<br />
{{Warning|If you use [[System Encryption with LUKS for dm-crypt|hard drive encryption]] using the encrypt hook, you '''must''' replace ''encrypt'' with ''plymouth-encrypt'' in order to get password prompts. You will not be able to boot the machine if you do not.}}<br />
Add plymouth to the hooks array:<br />
HOOKS="base udev autodetect plymouth ..."<br />
<br />
Rebuild your kernel image:<br />
# mkinitcpio -p kernel26<br />
<br />
Grub now needs configuring to work with plymouth:<br />
# nano /boot/grub/menu.lst<br />
<br />
If you have KMS enabled, at the end of your kernel line remove any VGA= statement. If you don't have KMS you will need to use framebuffer and so will need to add a VGA= statement. In either case, add "quiet splash" on the end:<br />
kernel /vmlinuz26 root=/dev/disk/by-uuid/xxxx ro quiet splash<br />
<br />
Finally, the plymouth daemon has to be killed towards the end of the boot process. This can be done with a command in rc.local:<br />
# nano /etc/rc.local<br />
<br />
and add the line<br />
/bin/plymouth quit --retain-splash<br />
<br />
Reboot, and enjoy the eye-candy start-up!<br />
<br />
==Changing the Theme==<br />
<br />
As mentioned above, plymouth comes with several themes. If you wish to try a different one, simply issue<br />
# plymouth-set-default-theme ''themename''<br />
<br />
Rebuild your kernel image:<br />
# mkinitcpio -p kernel26<br />
<br />
And reboot.<br />
<br />
==Troubleshooting==<br />
<br />
For some reason on both my computers (a laptop with an ATI graphics card and KMS, and my desktop with an nVidia card and framebuffer) the command to quit plymouth left small black squares around the top of my screen which attached themselves permanently to any window which passed under them. The issue was caused by the --retain-splash option which is required to keep the boot process as seamless as possible. If you are having this problem, the work-around is to kill plymouth ''after'' login, when the --retain-splash option is no longer needed.<br />
{{Note|This requires the use of [sudo].<br />
<br />
Edit /etc/rc.local again and remove the "/bin/plymouth quit --retain-splash" line.<br />
<br />
As yourself, edit xinitrc and add a line to kill plymouth. <br />
{{Warning|This must be '''above''' the line which starts your session (eg exec startxfce4) or your desktop session '''will not start'''}}<br />
$ nano ~/.xinitrc<br />
<br />
And add<br />
sudo /bin/plymouth quit &<br />
<br />
Note the lack of --retain-splash and the additional & sign on the end. This is required so that the xinitrc script will go on to start your desktop session.<br />
<br />
You now need to give yourself permission to kill the plymouth daemon without a password, by editing the sudoers file:<br />
$ su<br />
# EDITOR=nano visudo<br />
<br />
And add<br />
''yourusername'' ALL=(ALL) NOPASSWD: /bin/plymouth<br />
<br />
Reboot, and all should be well.<br />
<br />
==Credits==<br />
<br />
Thanks to drf for his [http://bbs.archlinux.org/viewtopic.php?id=81406 excellent forum post] on which this wiki article is based.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Plymouth&diff=99500
Plymouth
2010-03-10T01:58:32Z
<p>Daenyth: /* Configuration */ encryption configuration</p>
<hr />
<div>[[Category: Boot process (English)]]<br />
[[Category: Eye candy (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Plymouth}}<br />
{{i18n_entry|Česky|Plymouth (Česky)}}<br />
{{i18n_entry|Italiano|Plymouth (Italiano)}}<br />
{{i18n_links_end}}<br />
<br />
[http://fedoraproject.org/wiki/Releases/FeatureBetterStartup Plymouth] is a project from Fedora that provides a flicker-free graphical boot process. It relies on [[kernel mode setting]] to set the native resolution of the display as early as possible, then provides an eye-candy splash screen leading up to the login manager.<br />
<br />
==Installation==<br />
<br />
{{Note|Kernel mode setting is currently only available for Intel and ATI graphics cards (as of Kernel 2.6.32). Plymouth can run without it, but may fall back to its text-mode plugin.}}<br />
<br />
{{Warning|Plymouth is currently under heavy development and may contain bugs}}<br />
<br />
Before you can use Plymouth, you must enable kernel mode setting. Please refer to the instructions [[ATI#AMD.2FAti_cards_and_KernelModeSetting_.28KMS.29|for ATI cards]] and [[Intel#KMS_.28Kernel_Mode_Setting.29|for Intel cards]]. Both of these require you to rebuild your kernel image. You will also have to do that later on in this article, so you may wish to skip that step for now.<br />
<br />
If you don't have KMS you will need to use [[Framebuffer#Framebuffer_Resolution|framebuffer]] instead. <br />
{{Note|This may well not work. Plymouth is designed to work '''with''' KMS, although it can sometimes work with framebuffer.}}<br />
<br />
Grab Plymouth from the [[AUR]]. It is best to use the [http://aur.archlinux.org/packages.php?ID=26117 git version], as this is most up to date and likely to work better.<br />
<br />
Instructions on installing packages from the AUR are available [[AUR_User_Guidelines#Installing_Packages_from_the_AUR|here]].<br />
<br />
==Configuration==<br />
<br />
First of all, set a theme for plymouth. Plymouth comes with a selection of themes:<br />
#Fade-in: "Simple theme that fades in and out with shimmering stars"<br />
#Glow: "Corporate theme with pie chart boot progress followed by a glowing emerging logo"<br />
#Solar: "Space theme with violent flaring blue star" and <br />
#Spinfinty: "Simple theme that shows a rotating infinity sign in the center of the screen"<br />
Set your desired theme with plymouth-set-default-theme utility, eg:<br />
$ su<br />
# plymouth-set-default-theme spinfinity<br />
<br />
Add plymouth to the hooks array in mkinitcpio.conf. It '''must''' be added ''after'' base udev and autodetect for it to work.<br />
# nano /etc/mkinitcpio.conf<br />
<br />
{{Warning|If you use hard drive encryption using the encrypt hook, you '''must''' replace ''encrypt'' with ''plymouth-encrypt'' in order to get password prompts. You will not be able to boot the machine if you do not.}}<br />
Add plymouth to the hooks array:<br />
HOOKS="base udev autodetect plymouth ..."<br />
<br />
Rebuild your kernel image:<br />
# mkinitcpio -p kernel26<br />
<br />
Grub now needs configuring to work with plymouth:<br />
# nano /boot/grub/menu.lst<br />
<br />
If you have KMS enabled, at the end of your kernel line remove any VGA= statement. If you don't have KMS you will need to use framebuffer and so will need to add a VGA= statement. In either case, add "quiet splash" on the end:<br />
kernel /vmlinuz26 root=/dev/disk/by-uuid/xxxx ro quiet splash<br />
<br />
Finally, the plymouth daemon has to be killed towards the end of the boot process. This can be done with a command in rc.local:<br />
# nano /etc/rc.local<br />
<br />
and add the line<br />
/bin/plymouth quit --retain-splash<br />
<br />
Reboot, and enjoy the eye-candy start-up!<br />
<br />
==Changing the Theme==<br />
<br />
As mentioned above, plymouth comes with several themes. If you wish to try a different one, simply issue<br />
# plymouth-set-default-theme ''themename''<br />
<br />
Rebuild your kernel image:<br />
# mkinitcpio -p kernel26<br />
<br />
And reboot.<br />
<br />
==Troubleshooting==<br />
<br />
For some reason on both my computers (a laptop with an ATI graphics card and KMS, and my desktop with an nVidia card and framebuffer) the command to quit plymouth left small black squares around the top of my screen which attached themselves permanently to any window which passed under them. The issue was caused by the --retain-splash option which is required to keep the boot process as seamless as possible. If you are having this problem, the work-around is to kill plymouth ''after'' login, when the --retain-splash option is no longer needed.<br />
{{Note|This requires the use of [sudo].<br />
<br />
Edit /etc/rc.local again and remove the "/bin/plymouth quit --retain-splash" line.<br />
<br />
As yourself, edit xinitrc and add a line to kill plymouth. <br />
{{Warning|This must be '''above''' the line which starts your session (eg exec startxfce4) or your desktop session '''will not start'''}}<br />
$ nano ~/.xinitrc<br />
<br />
And add<br />
sudo /bin/plymouth quit &<br />
<br />
Note the lack of --retain-splash and the additional & sign on the end. This is required so that the xinitrc script will go on to start your desktop session.<br />
<br />
You now need to give yourself permission to kill the plymouth daemon without a password, by editing the sudoers file:<br />
$ su<br />
# EDITOR=nano visudo<br />
<br />
And add<br />
''yourusername'' ALL=(ALL) NOPASSWD: /bin/plymouth<br />
<br />
Reboot, and all should be well.<br />
<br />
==Credits==<br />
<br />
Thanks to drf for his [http://bbs.archlinux.org/viewtopic.php?id=81406 excellent forum post] on which this wiki article is based.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Mkinitcpio&diff=99035
Mkinitcpio
2010-03-05T00:42:32Z
<p>Daenyth: /* MODULES */ TODO: Find modules which fail to autoload on new kernels</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:Kernel (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|mkinitcpio}} {{DISPLAYTITLE:mkinitcpio}}<br />
{{Article summary start}}<br />
{{Article summary text|A detailed guide to the Arch initramfs creation utility.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
'''mkinitcpio''' is the next generation of initramfs creation.<br />
<br />
From [[Wikipedia:initrd]]:<br />
<br />
:''The '''initial ramdisk''', ['''initramfs'''], or '''initrd''' is a temporary file system commonly used in the [[boot process]] of the Linux kernel. It is typically used for making preparations before the real root file system can be mounted.''<br />
<br />
== Overview ==<br />
<br />
mkinitcpio is a Bash script used to create an initial ramdisk environment. From the [http://projects.archlinux.org/mkinitcpio.git/tree/mkinitcpio.5.txt mkinitcpio man page]:<br />
<br />
:''The initial ramdisk is in essence a very small environment (early userspace) which loads various kernel modules and sets up necessary things before handing over control to init. This makes it possible to have, for example, encrypted root filesystems and root filesystems on a software RAID array. mkinitcpio allows for easy extension with custom hooks, has autodetection at runtime, and many other features.''<br />
<br />
Traditionally, the kernel was responsible for all hardware detection and initialization tasks early in the [[boot process]] before mounting the root filesystem and passing control to {{Codeline|init}}. However, as technology advances, these tasks have become increasingly complex. <br />
<br />
Nowadays, the root filesystem may be on a wide range of hardware, from SCSI to SATA to USB drives, controlled by a variety of drive controllers from different manufacturers. Additionally, the root filesystem may be encrypted or compressed; within a software RAID array or a logical volume group. The simple way to handle that complexity is to pass management into userspace: an initial ramdisk. <br />
<br />
See also: [http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ /dev/brain0 &raquo; Blog Archive &raquo; Early Userspace in Arch Linux].<br />
<br />
mkinitcpio is a modular tool for building an init ramfs cpio image, offering many advantages over alternative methods, including:<br />
<br />
* The use of '''busybox''' to provide a small and lightweight base for early userspace (prior to version 0.6, [http://www.archlinux.org/news/486/ '''klibc'''] was used instead).<br />
* Support for '''[[udev]]''' for hardware autodetection at runtime, thus preventing the loading of unnecessary modules.<br />
* Being an extendable hook-based init script, custom hooks can easily be included in [[pacman]] packages.<br />
* Support for '''lvm2''', '''dm-crypt''' for both legacy and LUKS volumes, '''raid''', '''mdadm''', and '''swsusp''' and '''suspend2''' for resuming and booting from USB mass storage devices.<br />
* The ability to allow many features to be configured from the kernel command line without needing to rebuild the image.<br />
* Support for the inclusion of the image in a kernel, thus making a self-contained kernel image possible.<br />
<br />
mkinitcpio has been developed by '''phrakture''' and '''tpowa''' with some help from the community.<br />
<br />
== Installation ==<br />
<br />
The {{Package Official|mkinitcpio}} package is available in the [core] repository, and is installed by default as a member of the '''base''' group:<br />
# pacman -S mkinitcpio<br />
<br />
Users may wish to install the latest development version of mkinitcpio from Git:<br />
$ git clone git://projects.archlinux.org/mkinitcpio.git<br />
<br />
== Image creation and activation ==<br />
<br />
By default, the mkinitcpio script generates two images after kernel installation or upgrades: {{Filename|/boot/kernel26.img}} and {{Filename|/boot/kernel26-fallback.img}}. The ''fallback'' image utilizes the same configuration file as the ''default'' image, except the '''autodetect''' hook is skipped during creation, thus including a full range of modules. The '''autodetect''' hook detects required modules and tailors the image for specific hardware, shrinking the initramfs. <br />
<br />
Users may create any number of initramfs images with a variety of different configurations. The desired image must be specified for the bootloader, often in its configuration file ({{Filename|/boot/grub/menu.lst}} for [[GRUB]] users). After changes are made to the configuration file, the image must be regenerated. For the stock Arch Linux kernel, {{Package Official|kernel26}}, this is accomplished with the command:<br />
<br />
# mkinitcpio -p kernel26<br />
<br />
The {{Codeline|-p}} switch specifies a ''preset'' to utilize; most kernel packages provide a related mkinitcpio preset file, found in {{Filename|/etc/mkinitcpio.d}} (e.g. {{Filename|/etc/mkinitcpio.d/kernel26.preset}} for <tt>kernel26</tt>). A preset is a predefined definition of how to create an initramfs image instead of specifying the configuration file and output file every time.<br />
<br />
{{Warning|{{Filename|preset}} files are used to automatically regenerate the initramfs after a kernel update; be careful when editing them.}}<br />
<br />
Users can manually create an image using an alternate configuration file:<br />
<br />
# mkinitcpio -c /etc/mkinitcpio-custom.conf -g /boot/kernel26-custom.img<br />
<br />
This will generate the initramfs image for the currently running kernel and save it at {{Filename|/boot/kernel26-custom.img}}. <br />
<br />
If creating an image for a kernel other than the one currently running, add the kernel version to the command line:<br />
<br />
# mkinitcpio -g /boot/kernel26.img -k 2.6.16-ARCH<br />
<br />
== Configuration ==<br />
<br />
The primary configuration file for '''mkinitcpio''' is {{Filename|/etc/mkinitcpio.conf}}. Additionally, preset definitions are provided by kernel packages in the {{Filename|/etc/mkinitcpio.d}} directory (e.g. {{Filename|/etc/mkinitcpio.d/kernel26.preset}}).<br />
<br />
{{Warning|'''lvm2''', '''raid''', '''mdadm''', and '''encrypt''' are '''NOT''' enabled by default. Please read this section carefully for instructions if these hooks are required.}}<br />
<br />
{{Note|Users with multiple hardware disk controllers that use the same node names but different kernel modules (e.g. two SCSI/SATA or two IDE controllers) should ensure the correct order of modules is specified in {{Filename|/etc/mkinitcpio.conf}}. Otherwise, the root device location may change between boots, resulting in kernel panics.<br />
<br />
A more elegant alternative is to use [[persistent block device naming]] to ensure that the right devices are mounted.}}<br />
<br />
Users can modify five variables within the configuration file:<br />
<br />
; {{Codeline|MODULES}}: Kernel modules to be loaded before any boot hooks are run. <br />
; {{Codeline|BINARIES}}: Additional binaries to be included in the initramfs image.<br />
; {{Codeline|FILES}}: Additional files to be included in the intramfs image.<br />
; {{Codeline|HOOKS}}: Hooks are scripts that execute in the initial ramdisk.<br />
; {{Codeline|COMPRESSION}}: Used to compress the initramfs image.<br />
<br />
=== HOOKS ===<br />
<br />
A hook is a script that executes in the initial ramdisk. Hooks are listed in order of execution, and control the modules and scripts added to the image. <br />
<br />
Hooks are found within the {{Filename|/lib/initcpio/install}} directory; for a list of available hooks:<br />
<br />
$ ls -1 /lib/initcpio/install<br />
<br />
Use mkinitcpio's {{Codeline|-H}} option to output help for a specific hook. For example, to display information about the '''base''' hook:<br />
<br />
$ mkinitcpio -H base<br />
<br />
The default configuration will work for most users with a standard setup:<br />
<br />
HOOKS="base udev autodetect pata scsi sata filesystems"<br />
<br />
If using the image on more than one machine, remove the '''autodetect''' hook, which tailors the image to the build machine:<br />
<br />
HOOKS="base udev pata scsi sata filesystems"<br />
<br />
For support for encrypted volumes on LVM2 volume groups:<br />
<br />
HOOKS="base udev autodetect pata scsi sata lvm2 encrypt filesystems"<br />
<br />
A table of common hooks and their function follows. Note that this table is not complete, as packages can provide custom hooks. <br />
<br />
{| border="1" <br />
|+ '''Common hooks'''<br />
|-<br />
! Hook || Installation || Runtime<br />
|-<br />
| '''base''' || Sets up all initial directories and installs base utilities and libraries. Always add this hook unless you know what you are doing. || --<br />
|-<br />
| '''udev''' || Adds udev to your image || Udev will be used to create your root device node and detect the needed modules for your root device. As it simplifies things, using the udev hook is recommended.<br />
|-<br />
| '''autodetect''' || Shrinks your initramfs to a smaller size by autodetecting your needed modules. Be sure to verify included modules are correct and none are missing. This hook must be run before other subsystem hooks in order to take advantage of auto-detection. Any hooks placed before 'autodetect' will be installed in full. || --<br />
|-<br />
| '''ide''' || Adds legacy IDE modules to the image. You may choose to use this if your root device is on an IDE disk. Also use the '''autodetect''' hook if you want to minimize your image size || Loads legacy IDE modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''pata''' || Adds the new libata/PATA IDE modules to the image. Use this if your root device is on a IDE disk. Also use the '''autodetect''' hook if you want to minimize your image size || Loads IDE modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below). PATA is the kernel's new IDE driver. PATA utilizes SCSI emulation and will change {{Filename|/dev/hd''x''}} to {{Filename|/dev/sd''x''}}. [http://archlinux.org/news/272/ More information].<br />
|-<br />
| '''sata''' || Adds serial ATA modules to the image. Use this if your root device is on a SATA disk. Also use the '''autodetect''' hook if you want to minimize your image size. || Loads SATA modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''scsi''' || Adds SCSI modules to the image. Use this if your root device is on a SCSI disk. Also use the '''autodetect''' hook if you want to minimize your image size. || Loads SCSI modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''usb''' || Adds USB modules to the image. Use this if your root device is on a USB mass storage device or if your USB mass storage device needs to be accessed otherwise (checked, mounted, etc.) at boot time. || Loads USB modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''usbinput''' || Adds USB HID modules to the image. Use this if you have an USB keyboard and need it in early userspace (either for entering encryption passphrases or for failsafe mode). || Loads USB HID modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''fw''' || Adds FireWire modules to the image. Use this if your root device is on a FW mass storage device. || Loads FW modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''net''' || Adds the necessary modules for a network device. For PCMCIA net devices please add the '''pcmcia''' hook too. || Loads network modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below). See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''pcmcia''' || Adds the necessary modules for PCMCIA devices. You need to have {{Package Official|pcmciautils}} installed to use this. || Loads pcmcia modules. You will need the '''udev''' hook unless you specify the needed modules manually (see MODULES section below).<br />
|-<br />
| '''[[DSDT|dsdt]]''' || Loads a custom ACPI DSDT file during boot. Place your custom DSDT file for inclusion at {{Filename|/lib/initcpio/custom.dsdt}} || The custom DSDT file is automatically used by the kernel if it is present in initramfs.<br />
|-<br />
| '''filesystems''' || This includes necessary filesystem modules into your image. This hook is '''required''' unless you specify your filesystem modules in MODULES. || This will detect the filesystem type at runtime, load the module and pass it to kinit. (Will NOT detect '''reiser4''', which must be added to modules list.)<br />
|-<br />
| '''lvm2''' || Adds the device mapper kernel module and the {{Codeline|lvm}} tool to the image. You need to have the {{Package Official|lvm2}} package installed to use this. || Enables all LVM2 volume groups. This is necessary if you have your root filesystem on LVM.<br />
|-<br />
| '''raid''' || Adds the modules and {{Codeline|mdassamble}} for a software RAID setup. This hook has been superseded by the '''mdadm''' hook. You need to have {{Package Official|mdadm}} installed to use this. || Loads the necessary modules for software raid devices, and assembles the raid devices when run. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''mdadm''' || This hook supersedes the above '''raid''' hook. It supports assembling the arrays from {{Filename|/etc/mdadm.conf}}, or autodetection during boot. || Loads the necessary modules for software raid devices, and assembles the raid devices when run. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''encrypt''' || Adds the '''dm-crypt''' kernel module and the {{Codeline|cryptsetup}} tool to the image. You need to have the {{Package Official|cryptsetup}} package installed to use this. || Detects and unlocks an encrypted root partition. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''resume''' || -- || This tries to resume from the "suspend to disk" state. Works with both ''swsusp'' and ''[[suspend2]]''. See [[#Customizing the kernel command line]] for further configuration.<br />
|-<br />
| '''firmware''' || Adds {{Filename|/lib/firmware}} files. || Loads firmware. You will need the '''udev''' hook to get firmware loaded. <br />
|-<br />
| '''keymap''' || Adds keymap and consolefonts from [[rc.conf]]. || Loads the specified keymap and consolefont from {{Filename|rc.conf}} during early userspace.<br />
|}<br />
<br />
=== MODULES ===<br />
<br />
The MODULES array is used to specify modules to load before anything else is done. To accelerate the boot process, users may opt to disable the '''udev''' hook and list required modules here instead:<br />
<br />
MODULES="piix ide_disk reiserfs"<br />
<br />
[...]<br />
<br />
HOOKS="base autodetect ide filesystems"<br />
<br />
{{Note|If using '''reiser4''', it ''must'' be added to the modules list.}}<br />
<br />
{{Box YELLOW|TODO:|Find out which modules fail on modern kernels}}<br />
Known modules that are not autoloaded during boot process (status stock kernel 2.6.18):<br />
<br />
<tt>scsi_transport_sas, ultrastor, qlogicfas, eata, BusLogic, pas16, wd7000, sym53c416, g_NCR5380_mmio, fdomain, u14-34f, dtc initio, in2000, imm, t128, aha1542, aha152x, atp870u, g_NCR5380, NCR53c406a, qlogicfas408, megaraid_mm, advansys</tt><br />
<br />
If one of the above modules are required for the root device, consider explicitly adding it to {{Filename|/etc/mkinitcpio.conf}} to avoid kernel panics.<br />
<br />
=== BINARIES and FILES ===<br />
<br />
These options allow users to add files to the image; the difference being that BINARIES checks binaries and libraries for dependencies, while FILES simply adds the file without checks. For example:<br />
<br />
FILES="/etc/modprobe.conf"<br />
<br />
BINARIES="/usr/bin/somefile"<br />
<br />
{{Box YELLOW|TODO:|Find a real-world example of why/how I would use BINARIES.}}<br />
<br />
== Customizing the kernel command line ==<br />
<br />
Just like without initramfs, some options need to be passed on the kernel command line to configure your kernel, like the root device. Some of the mkinitcpio hooks have special options. These are discussed below.<br />
<br />
If you don't know what a kernel command line is, please refer to the [[GRUB]] or [[Lilo]] documentation.<br />
<br />
=== Entering failsafe mode ===<br />
<br />
If you add the option<br />
break=y<br />
to the kernel command line, init stops after the setup is completed and you are left with a ''dash'' shell. This can be used to verify that everything went fine. If you logout, normal boot continues.<br />
<br />
=== Disabling hooks ===<br />
<br />
You can disable a hook at runtime by adding the ''disablehooks'' option to the kernel command line like this:<br />
<br />
disablehooks=hook1,hook2,hook2<br />
<br />
for example<br />
<br />
disablehooks=resume<br />
<br />
=== Blacklisting modules ===<br />
<br />
You can blacklist modules by adding the ''disablemodules'' option to the kernel command line like this:<br />
<br />
disablemodules=mod1,mod2,mod3<br />
<br />
for example<br />
<br />
disablemodules=ata_piix<br />
<br />
=== Using raid ===<br />
First add the 'mdadm' hook to the HOOKS list and any required raid modules to the MODULES list in '''/etc/mkinitcpio.conf'''.<br />
<br />
'''Kernel Parameters: '''<br />
Using the 'mdadm' hook, you no longer need to configure your RAID array in the GRUB parameters. The 'mdadm' hook will either use your /etc/mdadm.conf file, or automatically detect the arrays during the init phase of boot.<br />
<br />
=== Using net ===<br />
<br />
'''Kernel Parameters:''' <br />
<br />
'''ip=''' <br />
<br />
An interface spec can be either short form, which is just the name of<br />
an interface (eth0 or whatever), or long form. The long form consists<br />
of up to seven elements, separated by colons:<br />
<br />
ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf><br />
nfsaddrs= is an alias to ip= and can be used too.<br />
<br />
''Parameter explanation:''<br />
<client-ip> IP address of the client. If empty, the address will<br />
either be determined by RARP/BOOTP/DHCP. What protocol<br />
is used de- pends on the <autoconf> parameter. If this<br />
parameter is not empty, autoconf will be used.<br />
<br />
<server-ip> IP address of the NFS server. If RARP is used to<br />
determine the client address and this parameter is NOT<br />
empty only replies from the specified server are<br />
accepted. To use different RARP and NFS server,<br />
specify your RARP server here (or leave it blank), and<br />
specify your NFS server in the `nfsroot' parameter<br />
(see above). If this entry is blank the address of the<br />
server is used which answered the RARP/BOOTP/DHCP<br />
request.<br />
<br />
<gw-ip> IP address of a gateway if the server is on a different<br />
subnet. If this entry is empty no gateway is used and the<br />
server is assumed to be on the local network, unless a<br />
value has been received by BOOTP/DHCP.<br />
<br />
<netmask> Netmask for local network interface. If this is empty,<br />
the netmask is derived from the client IP address assuming<br />
classful addressing, unless overridden in BOOTP/DHCP reply.<br />
<br />
<hostname> Name of the client. If empty, the client IP address is<br />
used in ASCII notation, or the value received by<br />
BOOTP/DHCP.<br />
<br />
<device> Name of network device to use. If this is empty, all<br />
devices are used for RARP/BOOTP/DHCP requests, and the<br />
first one we receive a reply on is configured. If you<br />
have only one device, you can safely leave this blank.<br />
<br />
<autoconf> Method to use for autoconfiguration. If this is either<br />
'rarp', 'bootp', or 'dhcp' the specified protocol is<br />
used. If the value is 'both', 'all' or empty, all<br />
protocols are used. 'off', 'static' or 'none' means<br />
no autoconfiguration.<br />
''Examples:''<br />
ip=127.0.0.1:::::lo:none --> Enable the loopback interface.<br />
ip=192.168.1.1:::::eth2:none --> Enable static eth2 interface.<br />
ip=:::::eth0:dhcp --> Enable dhcp protocol for eth0 configuration.<br />
'''nfsroot='''<br />
<br />
If the 'nfsroot' parameter is NOT given on the command line, the default<br />
"/tftpboot/%s" will be used.<br />
<br />
nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]<br />
<br />
''Parameter explanation:''<br />
<br />
<server-ip> Specifies the IP address of the NFS server. If this field<br />
is not given, the default address as determined by the<br />
`ip' variable (see below) is used. One use of this<br />
parameter is for example to allow using different servers<br />
for RARP and NFS. Usually you can leave this blank.<br />
<br />
<root-dir> Name of the directory on the server to mount as root. If<br />
there is a "%s" token in the string, the token will be<br />
replaced by the ASCII-representation of the client's IP<br />
address.<br />
<br />
<nfs-options> Standard NFS options. All options are separated by commas.<br />
If the options field is not given, the following defaults<br />
will be used:<br />
port = as given by server portmap daemon<br />
rsize = 1024<br />
wsize = 1024<br />
timeo = 7<br />
retrans = 3<br />
acregmin = 3<br />
acregmax = 60<br />
acdirmin = 30<br />
acdirmax = 60<br />
flags = hard, nointr, noposix, cto, ac<br />
<br />
'''root=/dev/nfs'''<br />
If you don't use nfsroot= parameter you need to set root=/dev/nfs <br />
to boot from a nfs root by autoconfiguration.<br />
<br />
=== Using lvm ===<br />
<br />
If your root device is on lvm, you have to add the '''lvm2''' hook. You have to pass your root device on the kernel command line in the format<br />
<br />
root=/dev/mapper/<volume group name>-<logical volume name><br />
<br />
for example<br />
<br />
root=/dev/mapper/myvg-root<br />
<br />
=== Using encrypted root ===<br />
<br />
If your root volume is encrypted, you need to add the '''encrypt''' hook. Then specify your root device on the kernel command line, just as if it was unencrypted.<br />
<br />
For an encrypted partition on an sata or scsi disk:<br />
root=/dev/sda5<br />
<br />
For an encrypted lvm volume:<br />
root=/dev/mapper/myvg-root<br />
<br />
The root device will be automatically changed to ''/dev/mapper/root''.<br />
<br />
==== Using LUKS volumes ====<br />
<br />
If you use LUKS for hard disk encryption, the init script will detect the encryption automatically if the '''encrypt''' hook is enabled. It will then ask for a passphrase and try to unlock the volume.<br />
<br />
If this fails try to add you filesystem-module to the module list in /etc/mkinitcpio.conf if it's not compiled into your kernel.<br />
<br />
==== Using a key-file ====<br />
<br />
You can use a keyfile to encrypt your root-fs. Use the following format:<br />
<br />
cryptkey=device:fs-type:path<br />
<br />
Device is the device-file representing the device your key is stored on (e.g. /dev/sda1), fs-type is the filesystemtype of this device (e.g. ext3) and path is the path to the keyfile inside the fs of this device.<br />
<br />
==== Using legacy cryptsetup volumes ====<br />
<br />
If you are using a legacy cryptsetup volume, you have to specify all cryptsetup options necessary to unlock it on the kernel command line. The option format is<br />
<br />
crypto=hash:cipher:keysize:offset:skip<br />
<br />
representing cryptsetup's --hash, --cipher, --keysize, --offset and --skip options. If you omit an option, cryptsetup's default value is used, so you can just specify<br />
<br />
crypto=::::<br />
<br />
if you created your volume with the default settings.<br />
<br />
'''NOTE:''' For technical reasons, it is not possible to verify the correctness of your passphrase with legacy cryptsetup volumes. If you typed it wrong, mounting will simply fail. It is recommended that you use LUKS instead.<br />
<br />
==== Using loop-aes volumes ====<br />
<br />
'''mkinitcpio''' does not support loop-aes yet.<br />
<br />
=== Add a Delay ===<br />
<br />
if you need to wait for a few seconds before mounting /. For example if you have a usb hard drive that takes a while to become ready. The example below will pause 8 seconds before continuing.<br />
<br />
rootdelay=8<br />
<br />
=== Example bootloader configuration files ===<br />
<br />
If you use the beyond kernel, the filenames are ''kernel26beyond.img'' and ''kernel26beyond-fallback.img'' instead of ''kernel26.img'' and ''kernel26-fallback.img'', respectively. Also, change "vmlinuz26" to "vmlinuz26beyond". <br />
<br />
==== GRUB ====<br />
<br />
For those who have /boot on a separate partition:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,3)<br />
kernel /vmlinuz26 root=/dev/hda4 vga=791 ro<br />
initrd /kernel26.img<br />
<br />
title Arch Linux Fallback<br />
root (hd0,3)<br />
kernel /vmlinuz26 root=/dev/hda4 vga=791 ro<br />
initrd /kernel26-fallback.img<br />
<br />
For those who do _not_ have /boot on a separate partition:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,3)<br />
kernel /boot/vmlinuz26 root=/dev/hda4 vga=791 ro<br />
initrd /boot/kernel26.img<br />
<br />
title Arch Linux Fallback<br />
root (hd0,3)<br />
kernel /boot/vmlinuz26 root=/dev/hda4 vga=791 ro<br />
initrd /boot/kernel26-fallback.img<br />
<br />
==== LILO ====<br />
<br />
If you use LILO, it is recommended that you use ''append="root=/dev/XYZ"'' instead of ''root=/dev/XYZ''. If you already have a global ''append'' option, then use ''addappend''.<br />
<br />
boot=/dev/hdX <br />
default = ArchLinux<br />
timeout=50 <br />
vga=791<br />
lba32<br />
prompt<br />
<br />
# for the hardware-autodetecting image<br />
image=/boot/vmlinuz26<br />
label=ArchLinux<br />
append="root=/dev/hdXY"<br />
initrd=/boot/kernel26.img<br />
read-only<br />
<br />
# fallback image if the other doesnt work (Will most prob. never be used)<br />
image=/boot/vmlinuz26<br />
label=ArchLinuxFallBack<br />
append="root=/dev/hdXY"<br />
initrd=/boot/kernel26-fallback.img<br />
read-only<br />
<br />
== Troubleshooting ==<br />
<br />
=== mkinitcpio hangs on 'autodetect' during kernel upgrade ===<br />
This [http://bugs.archlinux.org/task/10061 '''bug'''] sometimes causes mkinitcpio to hang when upgrading the kernel. It has been noted that certain usb devices and pata hard drives/chipsets may irritate the issue, but the actual cause is currently unknown (2010-03-01). The best known method to circumvent this bug is to edit '/etc/mkinitcpio.conf' and remove 'autodetect' from the HOOKS parameter. Once removed, force reinstall the kernel with 'pacman -Sf kernel26', and mkinitcpio should process cleanly.<br />
<br />
Reboot the system, and then add 'autodetect' back to the HOOKS parameter, and force reinstall the kernel again to complete this workaround. While running on the new kernel, 'autodetect' seems to process successfully.<br />
<br />
NOTE: Be very careful modifying 'etc/mkinitcpio.conf'. Review the procedures BEFORE modifying, and make a backup. Some systems may need another hook for pata/ide, or sata if the respective hook is not yet present. If mkinitcpio fails during a kernel upgrade, and the issue is not resolved before a reboot is executed, this will most likely result in a kernel panic/nonfunctioning system!<br />
<br />
<br />
=== Extracting the image ===<br />
<br />
If you are curious about what is inside the initrd image you can extract it and poke at the files inside of it. <br />
<br />
The initrd image is a '''cpio''' archive, generated by the <tt>gen_init_cpio</tt> command, optionally compressed with one the 3 compression schemes understood by the kernel: namely '''gzip''' or '''bzip2''' or '''lzma'''. Only kernels later than 2.6.30 undertand bzip2 and lzma compression.<br />
<br />
<tt>bsdtar</tt> is powerful enough to autodetect the compression used and to extract to the current directory.<br />
<br />
You can list the files in the image with:<br />
$ bsdtar -t -f /boot/kernel26.img<br />
<br />
And to extract them all in the current directory:<br />
$ bsdtar -x -f /boot/kernel26.img</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Vbox&diff=98635
Vbox
2010-03-01T19:36:22Z
<p>Daenyth: -> VirtualBox</p>
<hr />
<div>#Redirect: [[VirtualBox]]</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Talk:Netcfg&diff=98226
Talk:Netcfg
2010-02-25T22:46:34Z
<p>Daenyth: /* Move to netcfg */ +1</p>
<hr />
<div>== DHCLIENT ==<br />
<br />
DHCLIENT=no<br />
This will tell netcfg to use dhcpcd instead of dhclient<br />
<br />
I is correct? Without setting DHCLIENT, IP="dhcp" in my profile launches dhcpcd. [[User:Mykhal|Mykhal]] 17:28, 22 May 2009 (EDT)<br />
<br />
:This appears to refer to an older revision. See [http://projects.archlinux.org/netcfg.git/commit/?id=75b7abe2727a9ce7e72721a5c79f070d6126b6b3 this commit: "Restore dhcpcd as default dhcp client"]. I've removed the offending line from the article.<br />
<br />
:-- [[User:Pointone|pointone]] 14:51, 24 February 2010 (EST)<br />
<br />
== Move to [[netcfg]] ==<br />
<br />
Are there any objections to renaming this article "netcfg"? I think this would be much clearer. -- [[User:Pointone|pointone]] 12:19, 23 February 2010 (EST)<br />
<br />
+1 [[User:Daenyth|Daenyth]] 17:46, 25 February 2010 (EST)</div>
Daenyth
https://wiki.archlinux.org/index.php?title=KDE&diff=98225
KDE
2010-02-25T20:12:57Z
<p>Daenyth: /* Configuring */ Fix some links to be internal</p>
<hr />
<div>[[Category:Desktop environments (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|KDE}}<br />
<br />
KDE is a full featured desktop environment known for its well integrated applications, like Konqueror, Dolphin, Plasma, KWrite and Konsole.<br />
<br />
==KDE 4.4 Arch Linux Notes==<br />
<br />
'''KDE 4.4''' Software Compilation is the current major release of KDE that includes a number of improvements and bug fixes. The new Arch package set for KDE makes it possible to only install those applications you like.''<br />
<br />
Important changes in short:<br />
* '''Split packages'''; for more Information see [[KDE_Packages|KDE Packages]] and [[DeveloperWiki:Splitting_KDE|Splitting KDE]].<br />
* Qt uses the '''Gstreamer backend''' for Phonon by default. Other backends like '''phonon-xine''' can be installed optionally.<br />
* Meta packages ensure a smooth upgrade and emulate the old monolith packages for those who prefer them.<br />
<br />
Important hints for upgraders:<br />
* Check if your mirror is '''up to date'''.<br />
* pacman will ask you to replace '''all''' kde packages with kde-meta packages.<br />
* '''Do not force an update'''. If pacman complains about conflicts please '''file a bug report'''.<br />
* You can remove the meta packages and the sub packages you do not need after the update.<br />
* If you do not like split packages just keep using the kde-meta packages.<br />
<br />
:Information about upstream changes are be available [http://kde.org/announcements/4.4 here]<br />
<br />
==Installing KDE 4.4 Software Compilation==<br />
<br />
=== Installing full KDE SC ===<br />
<br />
To install the entire KDE set, first '''fully upgrade your system''':<br />
<br />
pacman -Syu<br />
<br />
and then:<br />
<br />
pacman -S kde<br />
<br />
{{Warning| In case you encounter dependency problems regarding '''Qt/kdelibs/phonon''' while '''upgrading''' KDE, [http://wiki.archlinux.org/index.php/KDE#Arch_linux_specific_packaging_issues follow this section.] }}<br />
<br />
If you need language files:<br />
<br />
pacman -S kde-l10n-yourlanguagehere<br />
<br />
i.e. kde-l10n-'''de''', for the German language.<br />
<br />
{{Note| KDE 4.x is '''modular'''; you can install your preferred KDE applications without having to install an entire set of packages. See [[KDE Packages]] for more information.}}<br />
<br />
=== Minimal Install ===<br />
<br />
If you want to have a minimal installation of the KDE SC:<br />
<br />
pacman -S kdebase-workspace kdebase-konsole<br />
<br />
== Starting KDE ==<br />
<br />
Running KDE depends on your preferences. Basically there are two ways of starting KDE. Using '''KDM''' or '''xinitrc'''.<br />
<br />
=== Using KDM (KDE Display Manager)===<br />
''It is highly recommended to get familiar with the [http://wiki.archlinux.org/index.php/Display_Manager full article] concerning display managers, before you make any changes. See also [[KDM]] Wiki page.''<br />
<br />
==== Starting KDM as a daemon ====<br />
Add "'''kdm'''" (without the quotes) to deamons array in '''{{Filename|/etc/rc.conf}}'''<br />
<br />
DAEMONS=(dbus hal syslog-ng network netfs crond ... '''kdm''')<br />
<br />
==== Starting KDM through /etc/inittab ==== <br />
<br />
Edit '''{{Filename|/etc/inittab}}''' and comment out:<br />
#id:3:initdefault:<br />
<br />
[...]<br />
<br />
#x:5:respawn:/usr/bin/xdm -nodaemon<br />
<br />
Then uncomment:<br />
<br />
id:5:initdefault:<br />
<br />
[...]<br />
<br />
x:5:respawn:/usr/bin/kdm -nodaemon<br />
<br />
{{Note| In both methods KDM loads Xorg automatically.}}<br />
<br />
===Using xinitrc===<br />
''The meaning and usage of '''xinitrc''' is very well described [http://wiki.archlinux.org/index.php/Xinitrc here].<br />
<br />
Edit '''{{Filename|/home/}}'''{{Filename|''your-username''}}'''{{Filename|/.xinitrc}}'''. Then uncomment:<br />
exec startkde <br />
After a reboot or/and login, each execution of Xorg ('''startx''' or '''xinit''') will start KDE automatically.<br />
<br />
{{Note| If you want to start Xorg at boot, please read [[Start X at boot]] article.}}<br />
<br />
==Configuring==<br />
<br />
{{Note| Configuring KDE is primarily done in ''''System Settings''''. There are also a few other options available for the desktop with 'Desktop Settings' when you right click the desktop.}}<br />
<br />
For other personalization options not covered below such as activities, different wallpapers on one cube, etc please refer to the [[Plasma]] wiki page.<br />
<br />
===Personalization===<br />
<br />
How to set up the KDE desktop to your personal style; use different Plasma themes, window decorations and icon themes.<br />
<br />
====What is Plasma?====<br />
<br />
[[Plasma]] is a desktop integration technology that provides many functions from displaying the wallpaper to adding widgets to the desktop.<br />
<br />
=====Plasma themes=====<br />
<br />
[http://kde-look.org/index.php?xcontentmode=76&PHPSESSID=bba0ae5354c7818b519687ebf5badf0e Plasma themes] can be installed through the Desktop Settings control panel. If you like to have them installed system-wide, themes can be found in both the official repositories and [http://aur.archlinux.org/packages.php?O=0&K=plasmatheme&do_Search=Go AUR].<br />
<br />
====Window Decorations====<br />
<br />
[http://kde-look.org/index.php?xcontentmode=75 Window decorations] can be changed in the '''System Settings > Appearance > Windows control''' panel and some are available on [http://aur.archlinux.org/packages.php?O=0&K=kdestyle&do_Search=Go&PP=25&SO=d&SB=v AUR].<br />
<br />
====KDE 4 Theme Integration with GTK Applications====<br />
<br />
<br />
To better integrate GTK and KDE 4 themes, you can use '''QtCurve'''.<br />
<br />
pacman -S qtcurve-gtk2 qtcurve-kde4<br />
<br />
=====Automatic procedure=====<br />
<br />
To change the GTK theme to QtCurve a few applications are available:<br />
<br />
pacman -S lxappearance<br />
pacman -S gtk-theme-switch2<br />
pacman -S gtk-chtheme<br />
<br />
Then change the theme to QtCurve in the respective application:<br />
<br />
lxappearance<br />
switch2<br />
gtk-chtheme<br />
<br />
=====Manual procedure=====<br />
<br />
To manually change the GTK theme to QtCurve, you need to create the file {{Filename|~/.gtkrc-2.0-kde4}} with the following content:<br />
<br />
include "/usr/share/themes/QtCurve/gtk-2.0/gtkrc"<br />
include "/etc/gtk-2.0/gtkrc"<br />
<br />
style "user-font"<br />
{<br />
font_name="Sans Serif"<br />
}<br />
widget_class "*" style "user-font"<br />
<br />
gtk-theme-name="QtCurve"<br />
<br />
Then you need to create the symbolic link {{Filename|~/.gtkrc-2.0}}:<br />
<br />
ln -s .gtkrc-2.0-kde4 .gtkrc-2.0<br />
<br />
If you want also specify a font, you can add (and adapt) the following line to the file:<br />
<br />
gtk-font-name="Sans Serif 9"<br />
<br />
=====Icons=====<br />
<br />
If you're using Oxygen icons and want a consistent look in GTK open/save dialogs, you can install an [http://aur.archlinux.org/packages.php?O=0&K=oxygenrefit2-icon-theme&do_Search=Go oxygenrefit2] icon theme from AUR and set it as your GTK icon theme. Add the theme to the {{Filename|~/.gtkrc-2.0}} file or you can use lxappearance and set it.<br />
<br />
gtk-icon-theme-name="OxygenRefit2"<br />
<br />
There are also a couple GTK themes built on the [http://aur.archlinux.org/packages.php?ID=24329 gtk-kde42-oxygen-theme Oxygen style] that can also do this.<br />
<br />
====Icon Themes====<br />
<br />
Not many full system icons themes are available for KDE 4. You can open up '''System Settings > Appearance > Icons''' and browse for new ones or install them manually. Many of them can be found on [http://www.kde-look.org/ kde-look.org].<br />
<br />
=====Arch Linux Logo Icon in Kicker menu=====<br />
<br />
Right-Click on the Kicker menu button, press "'''Application launcher settings'''" and then press the icon on the '''right'''. Then you may choose Arch Linux icon or any other icon that will replace the default one.<br />
<br />
====Plasmoids====<br />
<br />
KDE 4 supports plasmoids (aka plasma applets, and widgets). These are also available in the [http://aur.archlinux.org/packages.php?O=0&K=plasmoid&do_Search=Go&PP=25&SO=d&SB=v repositories] or you can find more on [http://www.kde-look.org/ kde-look.org].<br />
<br />
====Fonts====<br />
<br />
If you have personally set up how your [[Fonts]] render, be aware that System Settings may alter their appearance. When you go 'System Settings > Appearance > Fonts' System Settings will likely alter your font configuration file ({{Filename|fonts.conf}}). There is no way to prevent this but if you set the values to match your {{Filename|fonts.conf}} file the expected font rendering will return (it will require you to restart your application or in a few cases for you to have to restart your desktop). Note too that Gnomes' Font Preferences will also do this if you use both desktop environments.<br />
<br />
=== Networking/Printing ===<br />
<br />
NetworkManager support has been added in KDE 4.4 SC. See [[Networkmanager#KDE4|NetworkManager]] for more information.<br />
<br />
===Samba/Windows support===<br />
<br />
If you want to have access to Windows services:<br />
<br />
pacman -S samba<br />
<br />
You may then configure your Samba shares through <br />
<br />
System Settings > Advanced (Tab) > Samba<br />
<br />
===Printing support===<br />
<br />
{{Tip|Use the web frontend of CUPS for quicker configuration.}} Printers configured this way are available in KDE applications. <br />
<br />
You may also prefer the printer configuration through 'System Settings > Printer Configuration'.<br />
<br />
===Powersaving===<br />
<br />
Since v.4.2, KDE has integrated Powersaving service called "'''Powerdevil Power Management'''". You may need to configure powersaving, especially on notebooks and netbooks that need to have the CPU core default on '''powersaving''' options or the screen brightness set lower.<br />
<br />
Install cpufrequtils<br />
<br />
pacman -S cpufrequtils<br />
<br />
and make sure you have your CPU's cpufreq module loaded. For more information on this, visit [[Cpufreq|this article]].<br />
<br />
Then, in 'System Settings > Advanced (Tab) > Power Management' configure the options the way you prefer.<br />
<br />
==System Administration==<br />
<br />
===Akonadi and external MySQL-Server===<br />
<br />
As of December 2009, akonadi's configuration panel''' does not offer the option to connect to an external MySQL-server via TCP'''. You can however enable this via its configuration file (it's located within ${HOME}/.config/akonadi, the file is called akonadiserverrc). After you've stopped akonadi from the command line (with ''akonadictl stop'') Open the file with your favorite editor, and edit it like so:<br />
<br />
[QMYSQL]<br />
Name=${DBNAME}<br />
User=${USER}<br />
Password=${YOUR_PASSWORD_FOR_THE_USER}<br />
Options=<br />
ServerPath=/usr/sbin/mysqld<br />
StartServer=false<br />
Host=${THE_IP_WHERE_MYSQL_RUNS}<br />
Port=3306<br />
<br />
(of course, substitute your values for variables here)<br />
<br />
Test your setup from the command line (''akonadictl start''). If it starts, you succeeded and akonadi will now connect to MySQL via TCP. stop it once more, and go to system settings -> akonadi configuration (on the "Advanced" tab) and click "start" on the "Akonadi Server configuration" tab to restart akonadi. Alternatively, restart KDE.<br />
<br />
==Desktop Search and Semantic Desktop==<br />
<br />
===Nepomuk===<br />
<br />
From Wikipedia:<br />
''<br />
:NEPOMUK-KDE is featured as one of the newer technologies in KDE 4. It uses the RDF store Soprano and, on a technical level, :allows associating metadata to various items present on a normal user's desktop such as files, bookmarks, e-mails, and :calendar entries. Metadata can be arbitrary RDF; as of KDE 4, tagging is the most user-visible metadata application.'' <br />
<br />
Nepomuk is enabled by default. Nepomuk can be turned on and off in<br />
<br />
System Settings > Advanced > Desktop Search<br />
<br />
Visit [http://en.wikipedia.org/wiki/NEPOMUK_(framework) this Wikipedia article] for more information.<br />
See [http://lwn.net/Articles/358148/ here], [http://www.well.com/~doctorow/metacrap.htm here] and [http://tech.slashdot.org/article.pl?sid=08/12/16/1546219 here] for additional information.<br />
<br />
===Strigi Search===<br />
<br />
KDE4 has '''Strigi''' for file indexing. It is located under '''Desktop Search''', like Nepomuk. It can be turned on only if Nepomuk is turned on as well.<br />
<br />
Strigi indexes your files and helps you find them easily after by just pressing <br />
<br />
{{Keypress|Alt}} + {{Keypress|F2}}<br />
<br />
and typing what you want to find.<br />
<br />
'''Nepomuk/Strigi''' search is also integrated into ''Dolphin''. By default, Dolphin has a search bar on top-right where you may type what you want to be found from Strigi's index. <br />
<br />
{{Note | Strigi has implications for resource usage on your computer - CPU, memory, disk access, disk space, battery life. If Strigi is too resource-hungry for you, you can turn it off in "'''System Settings > Advanced > Desktop Search'''". }}<br />
<br />
Strigi index folders can be configured in "Advanced" tab.<br />
<br />
{{Tip|An efficient alternative to Strigi is [http://www.archlinux.org/packages/community/i686/recoll/ Recoll] [http://www.lesbonscomptes.com/recoll/ 1].}}<br />
<br />
==KDM (KDE Desktop Manager)==<br />
<br />
===KDM Xserver file===<br />
An example configuration for KDM can be found at '''/usr/share/config/kdm/kdmrc'''. See '''/usr/share/doc/HTML/en/kdm/kdmrc-ref.docbook''' for all options.<br />
<br />
===Configure KDM as root===<br />
<br />
You cannot configure KDM settings when launching System Settings as user. In order to do that, press<br />
<br />
{{Keypress|Alt}} + {{Keypress|F2}}<br />
<br />
and type<br />
<br />
kdesu systemsettings<br />
<br />
In the pop-up kdesu window, enter your root password and wait for System Settings to be launched.<br />
<br />
{{Note| Since you have launched it as root, be careful when changing your settings. All settings configuration in root-launched System Settings are saved under /root/.kde4 and not under ~/.kde4 (your home location).}}<br />
<br />
In the System Settings window, go to <br />
<br />
Advanced (Tab) > Login Manager<br />
<br />
==Phonon==<br />
<br />
===What is Phonon ?===<br />
<br />
''Phonon is the multimedia API for KDE 4. Phonon was created to allow KDE 4 to be independent of any single multimedia framework such as GStreamer or xine and to provide a stable API for KDE 4's lifetime. It was done for various reasons: to create a simple KDE/Qt style multimedia API, to better support native multimedia frameworks on Windows and Mac OS X, and to fix problems of frameworks becoming unmaintained or having API or ABI instability.<br />
''<br />
<br />
from Wikipedia.<br />
<br />
===Which backend should I choose ?===<br />
<br />
KDE4 on Arch Linux has '''Gstreamer''' backend for Phonon. But there are more backends as well. You could use Xine ( [http://www.archlinux.org/packages/?q=phonon phonon-xine] ), Mplayer ( [http://aur.archlinux.org/packages.php?ID=26082 phonon-mplayer-svn] ) , or VLC ( [http://aur.archlinux.org/packages.php?ID=29113 phonon-vlc-svn] ).<br />
<br />
==Troubleshooting==<br />
<br />
===KHotkeys issue===<br />
<br />
Ιf '''khotkeys''' does not work, make sure you have a fully updated system first.<br />
<br />
You can also create ~/.kde4/Autostart/reloadkhotkeys.sh with contents <br />
#!/bin/bash<br />
(sleep 3 && qdbus org.kde.kded /modules/khotkeys reread_configuration) &<br />
and then do a<br />
chmod u+x ~/.kde4/Autostart/reloadkhotkeys.sh<br />
then logout & login.<br />
<br />
===Enabling thumbnails under Konqueror and Dolphin file managers===<br />
<br />
For thumbnails of videos in konqueror and dolphin:<br />
<br />
pacman -S kdemultimedia-mplayerthumbs<br />
<br />
===First login on KDE is slow===<br />
<br />
The first login takes a while; no need to worry. KDE is creating all the proper configuration files under '''~/.kde4''' in order to start.<br />
<br />
===I encounter problems with automounting (or) KDE behaves strangely for no apparent reason===<br />
<br />
====Possible HAL problem====<br />
<br />
=====HAL not installed/not running=====<br />
<br />
It is possible that you have not installed HAL yet.<br />
<br />
Install HAL<br />
<br />
pacman -S hal<br />
<br />
if it is not already installed and then add it to the DAEMONS array in '''/etc/rc.conf''' for full media functionality.<br />
<br />
=====Consolekit session not running=====<br />
<br />
'''ck-launch-session''' command attaches a consolekit session to the X session that is going to run, and it is needed by '''HAL'''.<br />
<br />
If you are starting KDE with '''startx''' try adding <code>ck-launch-session</code> to the '''.xinitrc''',<br />
as so:<br />
<br />
#!/bin/sh<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
# exec gnome-session<br />
exec ck-launch-session startkde<br />
# exec startxfce4<br />
# ...or the Window Manager of your choice<br />
<br />
This is done automatically with KDM. <br />
{{Tip|This should also clear up any power (i.e. suspend to RAM/Disk) issues you may also be having.}}<br />
<br />
==== Possible previous KDE4 faulty settings ====<br />
<br />
It may be possible that some previous KDE4 settings in {{Filename|~/.kde4}} may be configured in a wrong way (by an application, by the user etc). If you cannot find any way to solve the problem by editing/configuring/deleting/adding settings in {{Filename|~/.kde4}}, [[KDE#I_want_a_fresh_installation_of_KDE_for_my_system._What_should_I_do_.3F|'''delete''']] the whole directory or just {{Filename|~/.kde4/share/config}} and restart KDE.<br />
<br />
===Suspend to Disk/Ram not working===<br />
If suspend to disk/ram does not work then try installing acpid with<br />
<br />
pacman -S acpid<br />
<br />
It will autoload with hal, also make sure you are in the power group (remember to logout)<br />
<br />
Also, if you are starting KDE with startx try adding ck-launch-session to the .xinitrc,<br />
as so:<br />
<br />
#!/bin/sh<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
# exec gnome-session<br />
exec ck-launch-session startkde<br />
# exec startxfce4<br />
# ...or the Window Manager of your choice<br />
<br />
This is done automatically with kdm.<br />
<br />
===GPG and SSH===<br />
To disable gpg-agent and/or ssh-agent in KDE sessions, edit <code>/etc/kde/env/agent-startup.sh</code> and <code>/etc/kde/shutdown/agent-shutdown.sh</code>.<br />
<br />
=== Graphics' related issues ===<br />
<br />
==== Low 2D desktop performance (or) Artifacts appear when on 2D ====<br />
<br />
===== Possible driver problem =====<br />
<br />
Make sure you have the proper driver for your card installed, so that your desktop is at least 2D accelerated. Follow these articles for more information: [[ATI]], [[NVIDIA]], [[Intel]] for more information, in order to make sure that everything is all right. <br />
<br />
The open source ATI and Intel drivers and the proprietary Nvidia driver should provide the best 2D acceleration.<br />
<br />
==== Konsole is slow in applications like vim ====<br />
This is a problem that is caused by slow glyph rendering. You can solve this by switching to a scalable font like Bitstream Vera Sans Mono.<br />
<br />
==== Low 3D desktop performance====<br />
<br />
KDE begins with desktop effects enabled. Older cards may be insufficient for 3D desktop acceleration. You can disable desktop effects in <br />
<br />
System Settings > Desktop <br />
<br />
or you can toggle desktop effects with <br />
{{Keypress|Alt}} + {{Keypress|Shift}} + {{Keypress|F12}}<br />
<br />
<br />
{{Note| You may encounter such problems with 3D desktop performance even when using a more powerful graphics card, but using catalyst proprietary driver (fglrx). This driver is known for having issues with 3D acceleration. Visit [[ATI|the ATi Wiki page]] for more troubleshooting.}}<br />
<br />
===Sound problems under KDE===<br />
====ALSA related problems====<br />
<br />
{{Note| First make sure you have '''alsa-lib''' and '''alsa-utils''' installed.}}<br />
<br />
====="Falling back to default" messages when trying to listen to any sound in KDE=====<br />
<br />
When you encounter such messages:<br />
<br />
:The audio playback device ''<name-of-the-sound-device>'' does not work.<br />
:Falling back to default<br />
<br />
Go to<br />
<br />
System Settings > Multimedia<br />
<br />
and set the device named "'''default'''" above all the other devices in each box you see.<br />
<br />
=====I cannot play mp3 files when having Gstreamer backend in Qt Phonon=====<br />
<br />
That can be solved by installing gstreamer0.10-plugins<br />
<br />
pacman -S gstreamer0.10-plugins<br />
<br />
You can also change the backend used by Phonon, by installing the phonon-xine<br />
<br />
pacman -S phonon-xine<br />
<br />
if you encounter problems that are not solved after installing gstreamer plugins. Then choose Xine in<br />
<br />
System Settings > Multimedia > Backend (tab)<br />
<br />
(it may have been autoselected after installing phonon-xine)<br />
<br />
=====Amarok "waits" before playing any track=====<br />
<br />
If you have encountered this error, the problem is backend specific. In order to solve this problem, change Amarok's backend from '''gstreamer''' to '''xine'''.<br />
<br />
====OSS4 related problems====<br />
<br />
=====I have OSS4 installed, but I have problems with Kmix etc=====<br />
<br />
Developers of Kmix are still integrating OSSv4 support. There is an [http://aur.archlinux.org/packages.php?ID=29286 AUR package] that is still experimental.<br />
<br />
Arch uses phonon with the Gstreamer backend that should work for most applications. Alternately you could try [[KDE#I_can.27t_play_mp3_files_when_having_Gstreamer_backend_in_Qt_Phonon|phonon with Xine]].<br />
<br />
=== Arch linux specific packaging issues ===<br />
<br />
Due to some changes on the packages or pacman problems, there could be some problems during upgrading. Please read the sections below, if you have a problem.<br />
<br />
==== Qt updating problem during upgrading from KDE SC 4.3 (or previous version) to KDE SC 4.4 ====<br />
<br />
If you encounter this error message during upgrading:<br />
<br />
error: failed to prepare transaction (could not satisfy dependencies)<br />
:: kdelibs: requires phonon<br />
<br />
First, you need to update Qt, which doesn't provide phonon anymore. <br />
<br />
So in that case:<br />
<br />
pacman -Syy '''--asdeps qt'''<br />
<br />
pacman -Su<br />
<br />
==== Kdepim meta-package is blocking the upgrade. ====<br />
<br />
Due to changes to the KDE meta-packages, there could be a problem with '''kde-meta-kdepim''' meta-package. So, in that case<br />
<br />
pacman -Syy '''--asdeps kdepim-runtime'''<br />
pacman -Su<br />
<br />
===I wanted a minimal installation of KDE. After I installed some packages and logged in KDE, there are no panels===<br />
<br />
If you wanted a minimal installation of KDE, logged in, heard the login sound but nothing else happened, you may not have installed the Plasma binaries. These are included in<br />
<br />
kdebase-workspace<br />
<br />
Install this package and restart Xorg.<br />
<br />
===I want a fresh installation of KDE for my system. What should I do ?===<br />
<br />
If you really want that, just rename the settings directory of KDE (just in case you'll need a backup later):<br />
<br />
mv ~/.kde4 ~/.kde4-backup<br />
<br />
===Plasma desktop behaves strangely but I do not know what to do===<br />
<br />
Plasma issues are caused mainly by unstable '''plasmoids''' or '''plasma themes'''. First, find which was the last plasmoid or plasma theme you had installed and disable it or even remove it. <br />
<br />
If you cannot find which the problem is, but you do not want all the KDE settings to be lost, do:<br />
<br />
rm -r ~/.kde4/share/config/plasma*<br />
<br />
This command will '''delete all plasma configs''' of your user and when you will relogin into KDE, you will have the '''default''' settings back.<br />
<br />
===My external HDD/my CD/DVD cannot be found by Device Notifier plasmoid (or) is not automounted===<br />
<br />
That might happen if you have devicekit related packages installed, like <code> devicekit-disks </code> . It seems to work properly only GNOME. <br />
<br />
So, remove anything '''devicekit''' related<br />
<br />
# pacman -Rcn $(pacman -Q | grep devicekit | awk '{print $1}')<br />
<br />
restart HAL <br />
<br />
# /etc/rc.d/hal restart<br />
<br />
and relogin into KDE. Your external HDD or CD/DVD can be found or automounted again.<br />
<br />
{{Warning| Make sure that this problem occurs on your machine '''only''' due to DeviceKit operations and not''' due to hardware issues'''. Removing DeviceKit makes GNOME's hard disk related features not to work properly.}}<br />
<br />
===Couldn't find MIME type application/octet-stream===<br />
"'''Couldn't find MIME type application/octet-stream'''" can be shown as an alert from KDE after it's updated. <br />
<br />
Can be solved when you create new mime type in KDE Control Center named ''''octet-stream'''' in category ''''application'''' and with the same text (octet-stream) in the description.<br />
<br />
Check contents of '''octet-stream.desktop''' located in {{Filename|~/.kde/share/mimelnk/application}}. Check to see that there is a line that reads '''Hidden=false'''. If Hidden=true you will still get the error message.<br />
<br />
===I encounter a serious lag with bitmap fonts on Konsole===<br />
<br />
That's an issue reported while using KDE 4.x and Nvidia proprietary driver. It's about to be fixed in future Nvidia driver release.<br />
<br />
==Other KDE projects==<br />
===The Chakra Project===<br />
<br />
====Split KDE packages====<br />
[http://chakra-project.org/ The Chakra Project] is a community-based modular version of KDE 4 and Live CD project, which includes a number of UI enhancements for KDE 4.x. Visit [http://chakra-project.org/wiki/index.php/Main_Page the Chakra Project Wiki main page] for more information.<br />
<br />
====Chakra Project Arch Live CD====<br />
<br />
The Chakra Project also provides a full featured Live CD, which has the latest stable KDEmod4 packages included.<br />
You may visit [http://chakra-project.org/download-iso.html the Chakra Project Live CD webpage] in order to find more information.<br />
<br />
====Passing from KDEmod to [extra]'s KDE====<br />
<br />
{{Note|You do have instructions for passing from '''[extra]''''s KDE4 to KDEmod4 [http://chakra-project.org/download-kdemod.html here]. }}<br />
<br />
Both flavours of KDE provide the same Desktop Environment, so if you install the one or the other, in the same upstream version, there should not be any problem regarding plasmoids, themes, styles or any KDE related application.<br />
<br />
So, if you want, for any reason, to pass from KDEmod to '''[extra]''''s KDE, do:<br />
<br />
pacman -Rd kdemod<br />
<br />
OR<br />
<br />
pacman -Rd kdemod-uninstall<br />
<br />
and it should be removed, but with the '''-d''' argument, the KDE dependent packages '''are not''' uninstalled, but only the Desktop Environment. But, if you want to '''completelly''' remove any KDEmod specific application/plasmoid/style etc too, do<br />
<br />
pacman -Rcns kdemod<br />
<br />
and then make sure that everything has been uninstalled:<br />
<br />
pacman -Q | grep kde<br />
<br />
{{Note| If you want to use the same KDE specific settings from the previous KDEmod installation, move or rename ~/'''.kdemod4''' to ~/'''.kde4''' }}<br />
<br />
After this, you may have KDEmod uninstalled.<br />
<br />
Then, follow [[KDE#Installing_KDE_4.4|this]].<br />
<br />
===KDE unstable===<br />
====KDE svn====<br />
<br />
If you want to install an unstable KDE version, visit [http://bbs.archlinux.org/viewtopic.php?id=44507 this thread]<br />
<br />
and follow the instructions there.<br />
<br />
It is currently '''inactive'''.<br />
<br />
====KDEmod testing/unstable====<br />
<br />
You may visit [http://chakra-project.org/repos.html this webpage] and see which repos can you add in''' pacman.conf''' in order to test the KDEmod unstable packages.<br />
<br />
====KDE unstable (snapshot)====<br />
<br />
===== Unofficial kde-unstable =====<br />
<br />
The member '''ProgDan''' has created a repo where he uploads the testing KDE packages when a new '''upstream snapshot''' is out. You may visit [http://bbs.archlinux.org/viewtopic.php?id=76245 this topic] for more information.<br />
<br />
===== Semi-official kde-unstable =====<br />
<br />
When KDE is reaching .90 (RC) milestone, KDE "unstable" packages are uploaded to the [kde-unstable] repo. <br />
<br />
You may add it by adding:<br />
<br />
[kde-unstable]<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
in '''{{Filename|/etc/pacman.conf}}'''<br />
<br />
They stay there until KDE is declared stable and passes to [extra].<br />
<br />
Make sure [http://wiki.archlinux.org/index.php/KDE#Distro_and_Upstream_bug_report you make bug reports] if you find any issues.<br />
<br />
Read [http://wiki.archlinux.org/index.php/DeveloperWiki:KDE#Users this section] in the wiki as well.<br />
<br />
===KDE Legacy===<br />
<br />
====Downgrading to KDEmod3 from KDE 4.4====<br />
For those people who decide that KDE 4.4 is still not yet "ready" for them, there is a website about how to downgrade to a version of KDE 3.5 called '''kdemod3''':<br />
* [http://chakra-project.org/download-kdemod3.html KDEmod3]<br />
<br />
'''Warning''': There have been issues reported regarding Libjpeg7, that caused KDEmod3 to behave strangely. In order to solve that, install [http://aur.archlinux.org/packages.php?ID=28427 libjpeg6 from AUR]. More info [http://chakra-project.org/bbs/viewtopic.php?id=1097 here]<br />
<br />
==Bugs==<br />
===Common bugs===<br />
If you think you found something that seems like bug, please see [[Common_Issues]] and regarding that: KDE 4 config files are usually located at <br />
<br />
~/.kde4/share/config/<br />
<br />
and for app-specific configs <br />
<br />
~/.kde4/share/apps/<br />
<br />
===Distro and Upstream bug report===<br />
It is preferrable that if you find a minor or serious bug, you should visit [http://bugs.archlinux.org the Arch Bug Tracker] or/and [http://bugs.kde.org KDE Bug Tracker] in order to report that. Make sure that you be clear on what you want to report.<br />
<br />
If you have any issue and you write about in on the Arch forums, first make sure that you have '''FULLY''' updated your system using a good sync mirror (check [https://www.archlinux.de/?page=MirrorStatus here]) or try '''reflector'''.<br />
<br />
==External Links==<br />
* [http://www.kde.org KDE Homepage]<br />
* [http://bugs.kde.org KDE Bug Tracker]<br />
* [http://bugs.archlinux.org Arch Linux Bug Tracker]<br />
* [http://websvn.kde.org KDE WebSVN]</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Talk:Plymouth&diff=98223
Talk:Plymouth
2010-02-25T19:17:22Z
<p>Daenyth: </p>
<hr />
<div>Gypsythief, thanks for creating this excellent summary article! Worked like a charm! -- [[User:Pointone|pointone]] 16:58, 26 October 2009 (EDT)<br />
<br />
Plymouth doesn't currently work with the encrypt hook: http://bbs.archlinux.org/viewtopic.php?pid=672262#p672262</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Map_Custom_Device_Entries_with_udev&diff=97588
Map Custom Device Entries with udev
2010-02-20T02:02:10Z
<p>Daenyth: /* Manual method */ die backticks die die die!</p>
<hr />
<div>[[Category:Hardware detection and troubleshooting (English)]]<br />
[[Category:File systems (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Map Custom Device Entries with udev}}<br />
<br />
This process allows to map a specific device to a constant device-node, located in {{filename|/dev}}, by using [[udev]] rules. This can then be used in [[fstab]], among other places, to ensure that the device can be mounted with a unchanging device-node--ideal for desktop shortcuts and other mounting operations.<br />
<br />
This article focuses on USB devices and was copied almost verbatim from the [http://en.gentoo-wiki.com Gentoo wiki], later supplemented with additional hints.<br />
<br />
==Get USB device udev information==<br />
Here is script that facilitates this operation. Simply plug in the device before running the script. Save it as {{filename|usb-show-serial}}, for example, and run it like so:<br />
{{command|name=./usb-show-serial /dev/''sdX'' ''label''|output=<br />
add the following to /etc/udev/rules.d/90-automounter.rules<br />
BUS=="usb", ATTRS{serial}=="23560716050834460007" , KERNEL=="sd?1", NAME="%k", SYMLINK+="foo", GROUP="storage"<br />
}}<br />
The script is available [http://kaizo.org/misc/slackware/current/misc/usb-show-serial here].<br />
<br />
==Manual method==<br />
Make sure one of the target devices is plugged in and then run the following (replacing {{filename|sda}} as needed):<br />
{{command|name=udevadm info -a -p $(udevadm info -q path -n /dev/sda)|output=<br />
Udevadm starts with the device specified by the devpath and then<br />
walks up the chain of parent devices. It prints for every device<br />
found, all possible attributes in the udev rules key format.<br />
A rule to match, can be composed by the attributes of the device<br />
and the attributes from one single parent device.<br />
<br />
looking at device '/block/sda':<br />
KERNEL=="sda"<br />
SUBSYSTEM=="block"<br />
DRIVER==""<br />
ATTR{stat}==" 19 111 137 160 0 0 0 0 0 152 160"<br />
ATTR{size}=="2007040"<br />
ATTR{removable}=="1"<br />
ATTR{range}=="16"<br />
ATTR{dev}=="8:0"<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-5/1-5:1.0/host5/target5:0:0/5:0:0:0':<br />
KERNELS=="5:0:0:0"<br />
SUBSYSTEMS=="scsi"<br />
DRIVERS=="sd"<br />
ATTRS{ioerr_cnt}=="0x0"<br />
ATTRS{iodone_cnt}=="0x1c"<br />
ATTRS{iorequest_cnt}=="0x1c"<br />
ATTRS{iocounterbits}=="32"<br />
ATTRS{timeout}=="30"<br />
ATTRS{state}=="running"<br />
ATTRS{rev}=="1.20"<br />
ATTRS{model}=="01GB Tiny "<br />
ATTRS{vendor}=="Pretec "<br />
ATTRS{scsi_level}=="3"<br />
ATTRS{type}=="0"<br />
ATTRS{queue_type}=="none"<br />
ATTRS{queue_depth}=="1"<br />
ATTRS{device_blocked}=="0"<br />
ATTRS{max_sectors}=="240"<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-5/1-5:1.0/host5/target5:0:0':<br />
KERNELS=="target5:0:0"<br />
SUBSYSTEMS==""<br />
DRIVERS==""<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-5/1-5:1.0/host5':<br />
KERNELS=="host5"<br />
SUBSYSTEMS==""<br />
DRIVERS==""<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-5/1-5:1.0':<br />
KERNELS=="1-5:1.0"<br />
SUBSYSTEMS=="usb"<br />
DRIVERS=="usb-storage"<br />
ATTRS{modalias}=="usb:v4146pBA01d0100dc00dsc00dp00ic08isc06ip50"<br />
ATTRS{bInterfaceProtocol}=="50"<br />
ATTRS{bInterfaceSubClass}=="06"<br />
ATTRS{bInterfaceClass}=="08"<br />
ATTRS{bNumEndpoints}=="03"<br />
ATTRS{bAlternateSetting}==" 0"<br />
ATTRS{bInterfaceNumber}=="00"<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1/1-5':<br />
KERNELS=="1-5"<br />
SUBSYSTEMS=="usb"<br />
DRIVERS=="usb"<br />
ATTRS{configuration}==""<br />
ATTRS{serial}=="14AB0000000096"<br />
ATTRS{product}=="USB Mass Storage Device"<br />
ATTRS{maxchild}=="0"<br />
ATTRS{version}==" 2.00"<br />
ATTRS{devnum}=="7"<br />
ATTRS{speed}=="480"<br />
ATTRS{bMaxPacketSize0}=="64"<br />
ATTRS{bNumConfigurations}=="1"<br />
ATTRS{bDeviceProtocol}=="00"<br />
ATTRS{bDeviceSubClass}=="00"<br />
ATTRS{bDeviceClass}=="00"<br />
ATTRS{bcdDevice}=="0100"<br />
ATTRS{idProduct}=="ba01"<br />
ATTRS{idVendor}=="4146"<br />
ATTRS{bMaxPower}==" 98mA"<br />
ATTRS{bmAttributes}=="80"<br />
ATTRS{bConfigurationValue}=="1"<br />
ATTRS{bNumInterfaces}==" 1"<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2/usb1':<br />
KERNELS=="usb1"<br />
SUBSYSTEMS=="usb"<br />
DRIVERS=="usb"<br />
ATTRS{configuration}==""<br />
ATTRS{serial}=="0000:00:02.2"<br />
ATTRS{product}=="EHCI Host Controller"<br />
ATTRS{manufacturer}=="Linux 2.6.18-ARCH ehci_hcd"<br />
ATTRS{maxchild}=="6"<br />
ATTRS{version}==" 2.00"<br />
ATTRS{devnum}=="1"<br />
ATTRS{speed}=="480"<br />
ATTRS{bMaxPacketSize0}=="64"<br />
ATTRS{bNumConfigurations}=="1"<br />
ATTRS{bDeviceProtocol}=="01"<br />
ATTRS{bDeviceSubClass}=="00"<br />
ATTRS{bDeviceClass}=="09"<br />
ATTRS{bcdDevice}=="0206"<br />
ATTRS{idProduct}=="0000"<br />
ATTRS{idVendor}=="0000"<br />
ATTRS{bMaxPower}==" 0mA"<br />
ATTRS{bmAttributes}=="e0"<br />
ATTRS{bConfigurationValue}=="1"<br />
ATTRS{bNumInterfaces}==" 1"<br />
<br />
looking at parent device '/devices/pci0000:00/0000:00:02.2':<br />
KERNELS=="0000:00:02.2"<br />
SUBSYSTEMS=="pci"<br />
DRIVERS=="ehci_hcd"<br />
ATTRS{broken_parity_status}=="0"<br />
ATTRS{enable}=="1"<br />
ATTRS{modalias}=="pci:v000010DEd00000068sv00001043sd00000C11bc0Csc03i20"<br />
ATTRS{local_cpus}=="f"<br />
ATTRS{irq}=="17"<br />
ATTRS{class}=="0x0c0320"<br />
ATTRS{subsystem_device}=="0x0c11"<br />
ATTRS{subsystem_vendor}=="0x1043"<br />
ATTRS{device}=="0x0068"<br />
ATTRS{vendor}=="0x10de"<br />
<br />
looking at parent device '/devices/pci0000:00':<br />
KERNELS=="pci0000:00"<br />
SUBSYSTEMS==""<br />
DRIVERS==""<br />
}}<br />
<br />
The only part of this that is needed is {{codeline|ATTRS{serial}}}, so use {{codeline|grep}} to filter the information:<br />
{{command|name=udevadm info -a -p $(udevadm info -q path -n /dev/sda) | grep ATTRS{serial}|output=<br />
ATTRS{serial}=="14AB0000000096"<br />
ATTRS{serial}=="0000:00:02.2"<br />
}}<br />
<br />
This narrows down the search to a much greater degree; however, one of the two serials is irrelevant. Trim down the {{codeline|grep}}:<br />
{{command|name=udevadm info -a -p $(udevadm info -q path -n /dev/sda) | grep ATTRS{product}|output=<br />
'''ATTRS{product}=="USB Mass Storage Device"'''<br />
ATTRS{product}=="EHCI Host Controller"<br />
}}<br />
The first choice is obviously the correct one.<br />
<br />
==Create udev rule==<br />
Use the {{codeline|ATTRS{serial}}} in a udev rule as follows. Place it in {{filename|/etc/udev/rules.d/00.rules}}:<br />
BUS=="usb", ATTRS{serial}=="14AB0000000096", KERNEL=="sd?1", NAME="%k", SYMLINK+="usbdrive", GROUP="storage"<br />
{{note|When creating a file with a different naming scheme that those in the directory, remember that udev processes these files in alphabetical order.}}<br />
<br />
==Make fstab entry==<br />
Create a directory for mounting:<br />
# mkdir /mnt/usbdrive<br />
<br />
In {{filename|/etc/[[fstab]]}}, create an entry as:<br />
/dev/usbdrive /mnt/usbdrive vfat rw,noauto,group,flush,quiet,nodev,nosuid,noexec,noatime,dmask=000,fmask=111 0 0<br />
<br />
Options {{codeline|nodev, nosuid, and noexec}} are unnecesary; they are stated for security reasons only. Additionally, depending on your locale preferences, add {{codeline|codepage}} and {{codeline|iocharset}} options (such as {{codeline|<nowiki>codepage=866,iocharset=utf-8</nowiki>}}) in order to be able to display non-Latin file-names correctly.<br />
<br />
Now, root and users who belongs to the {{codeline|storage}} [[group]] can mount the USB device by:<br />
mount /mnt/usbdrive<br />
<br />
To allow a non-root user to access to USB devices, add them to the storage group:<br />
# gpasswd -a ''username'' storage<br />
<br />
==Restart udev==<br />
To load the updated rules, run:<br />
# udevadm control --reload-rules<br />
<br />
==Examples==<br />
Here are some mapping and mounting examples. This system's devices sometimes made nodes as {{filename|sda}} or {{filename|sda1}} so I two rules for each needed to be specified, which aid "device not found" problems. The {{filename|sda}} node is also needed for disk-level activities; e.g., {{codeline|fdisk /dev/sda}}.<br />
<br />
This always maps a specific USB device (in this case, a pendrive) to {{filename|/dev/usbpen}}, which is then set in {{filename|fstab}} to mount on {{filename|/mnt/usbpen}}:<br />
# Symlink USB pen<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd?", NAME="%k", SYMLINK+="usbpen", GROUP="storage"<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd?1", NAME="%k", SYMLINK+="usbpen", GROUP="storage"<br />
<br />
If for devices with multiple partitions, the following example maps the device to {{filename|/dev/usbdisk}}, and partitions 1, 2, 3 etc., to {{filename|/dev/usbdisk1}}, {{filename|/dev/usbdisk2}}, {{filename|/dev/usbdisk3}}, etc.<br />
# Symlink multi-part device<br />
SUSSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd?", NAME="%k", SYMLINK+="usbdisk", GROUP="storage"<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd?[1-9]", NAME="%k", SYMLINK+="usbdisk%n", GROUP="storage"<br />
<br />
The above rules are equivalent to the following one:<br />
# Symlink multi-part device<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd*", NAME="%k", SYMLINK+="usbdisk%n", GROUP="storage"<br />
<br />
It's also possible to omit the {{codeline|NAME}} and {{codeline|GROUP}} statements, so that the defaults from {{filename|udev.rules}} are used. Meaning that the shortest and simplest solution would be adding this rule:<br />
# Symlink multi-part device<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="1730C13B18000B84", KERNEL=="sd*", SYMLINK+="usbdisk%n"<br />
<br />
This always maps a Olympus digicam to {{filename|/dev/usbcam}}, which can be stated in {{filename|fstab}} to mount on {{filename|/mnt/usbcam}}:<br />
# Symlink USB camera<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="000207532049", KERNEL=="sd?", NAME="%k", SYMLINK+="usbcam", GROUP="storage"<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="000207532049", KERNEL=="sd?1", NAME="%k", SYMLINK+="usbcam", GROUP="storage"<br />
<br />
And this maps a Packard Bell MP3 player to {{filename|/dev/mp3player}}:<br />
# Symlink MP3 player<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="0002F5CF72C9C691", KERNEL=="sd?", NAME="%k", SYMLINK+="mp3player", GROUP="storage"<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="0002F5CF72C9C691", KERNEL=="sd?1", NAME="%k", SYMLINK+="mp3player", GROUP="storage"<br />
<br />
To map a selected usb-key to {{filename|/dev/mykey}} and all of other keys to {{filename|/dev/otherkey}}:<br />
# Symlink USB keys<br />
SUBSYSTEMS=="usb", ATTRS{serial}=="insert serial key", KERNEL=="sd?1", NAME="%k", SYMLINK+="mykey"<br />
SUBSYSTEMS=="usb", KERNEL=="sd?1", NAME="%k", SYMLINK+="otherkey"<br />
Note the order of the lines. Since all the USB keys should create the {{filename|/dev/sd<a||b>}} node, udev will first check if it is a rules-stated USB-key, defined by serial number. But if an unknown USB-key is plugged, it will create ''also'' create a node, using the previously stated generic name, "otherkey". That rule should be the last one in rules file so that it does not override the others.<br />
<br />
This is an example on how to distinguish USB HDD drives and USB sticks:<br />
BUS=="usb", ATTRS{product}=="USB2.0 Storage Device", KERNEL=="sd?", NAME="%k", SYMLINK+="usbdisk", GROUP="storage"<br />
BUS=="usb", ATTRS{product}=="USB2.0 Storage Device", KERNEL=="sd?[1-9]", NAME="%k", SYMLINK+="usbdisk%n", GROUP="storage"<br />
BUS=="usb", ATTRS{product}=="USB Mass Storage Device", KERNEL=="sd?1", NAME="%k", SYMLINK+="usbflash", GROUP="storage"<br />
Note that this udev rule doesn't use serials at all.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Talk:Xinit&diff=95349
Talk:Xinit
2010-02-07T17:52:44Z
<p>Daenyth: ck-launch-session?</p>
<hr />
<div>Great article. About time .xinitrc got its own wiki entry. Thanks for your contribution. [[User:Misfit138|Misfit138]] 14:02, 29 September 2008 (EDT)<br />
:: Thanks :) [[User:Chochem|Chochem]] 04:44, 2 October 2008 (EDT)<br />
<br />
<br />
Maybe we could have a section on ck-launch-session? I don't know enough to be useful. [[User:Daenyth|Daenyth]] 12:52, 7 February 2010 (EST)</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Custom_Kernel_Compilation_with_ABS&diff=94463
Custom Kernel Compilation with ABS
2010-01-30T12:22:58Z
<p>Daenyth: Out of date.</p>
<hr />
<div>[[Category:Kernel (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{out of date}}<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Custom_Kernel_Compilation_with_ABS}}<br />
{{i18n_entry|简体中文|从ABS定制内核}}<br />
{{i18n_entry|Italiano|Custom_Kernel_Compilation_with_ABS_(Italiano)}}<br />
{{i18n_links_end}}<br />
<br />
=== Introduction ===<br />
There are many ways to build the kernel in arch, this is just one example - for other possibilities see [[Kernel_Compilation|Kernel Compilation]]. Some Arch users prefer [[Kernel Compilation From Source|the traditional way]], however using ABS is helpful for automating certain tasks. The choice is yours; neither way is inherently better than the other. <br />
<br />
This howto has been updated to provide a definitive PKGBUILD for the creation of custom kernel packages. It allows you to maintain multiple custom kernels with a unique naming scheme under pacman version control. It is ideal for ANY custom kernel build and can be easily adapted to fit many requirements. The PKGBUILD automatically accounts for the <code>EXTRAVERSION</code> and <code>LOCALVERSION</code> variables that are now fully supported in the kernel. <code>EXTRAVERSION</code> is frequently set by major patchsets such as -ck and -nitro. <code>EXTRAVERSION</code> is also used in the 2.6.x.y branch to carry the <code>.y</code> variable. <code>LOCALVERSION</code> can be set during the config stage and is the easiest and RECOMMENDED way to customize your kernel pkgnames. Simply setting <code>LOCALVERSION</code> to <code>-custom</code> or the date e.g. <code>-20050105</code> will suffice! A unique LOCALVERSION guarantees a unique pkg.<br />
<br />
Note that this is NOT an ABS howto - to successfully follow this HOWTO a working knowledge of building packages with ABS is ESSENTIAL - please read [[Arch Build System]], [[The Arch package making HOW-TO - with guidelines]] and [[Patching in ABS]].<br />
<br />
=== Philosophy and Logic (how it works and why it works this way) ===<br />
* The Arch Way - Keep It Simple.<br />
* This PKGBUILD builds on the previous, widely accepted version.<br />
* This build provides kernel packages and components with a simple, logical and uncomplicated naming scheme that ONLY uses variables that are part of the ABS system and part of the kernel compilation process itself. Rationale:<br />
** The stock Arch kernel uses the <code>kernel26</code> base pkgname which is logically extended here under the 2.6.x and 2.6.x.y schemes e.g <code>kernel2611</code> and <code>kernel26117</code><br>These also provide the basis of <code>/boot</code> filenames e.g. <code>vmlinux26</code> and <code>vmlinuz26117</code><br />
** The ''kernel compilation process'' uses the kernel version (2.6.x), <code>EXTRAVERSION</code> from the <code>Makefile</code> and <code>CONFIG_LOCALVERSION</code> from the kernel config to create the name for the kernel's module directory, e.g.:<br />
<br />
<pre><br />
2.6.x$EXTRAVERSION$LOCALVERSION<br />
2.6.11-cko2-ARCH/<br />
</pre><br />
<br />
: This is beyond the control of the PKGBUILD so to provide a pkg with similarly named components the PKGBUILD uses the same scheme to create unique <code>/boot</code> files and a unique <code>/usr/src</code> directory by appending <code>-EXTRAVERSION-LOCALVERSION</code>, e.g.:<br />
<br />
<pre><br />
/boot/vmlinuz2611-cko2-ARCH<br />
/boot/System.map2611-cko2-ARCH<br />
/boot/kconfig2611-cko2-ARCH<br />
<br />
/usr/src/linux-2.6.11-cko2-ARCH/<br />
</pre><br />
<br />
* If you have the recommended knowledge of ABS you will see that the PKGBUILD is transparently constructed, self-explanatory and can be customized easily.<br />
* User input is almost identical to all ABS builds: simply set <code>pkgver</code>, <code>pkgrel</code> and <code>pkgdesc</code> and add additional sources, including patches, to the <code>source</code> array. Patch users should insert the appropriate patch commands where indicated. Aside from uncommenting the config method and choosing whether to <code>make clean</code> or not the rest of the build is automated.<br />
* Having created a custom pkg naming scheme during the build, the PKGBUILD automatically corrects/updates itself with the new <code>pkgname</code> variable allowing simple <code>gensync</code> operation.<br />
<br />
=== Usage Notes ===<br />
<br />
* <code>pkgname</code> must be declared within 10 lines of the top of the PKGBUILD - so '''DO NOT''' move it - just leave it.<br><br />
If you miss this simple instruction don't worry, it won't screw up your build but your PKGBUILD file will not have the pkgname automatically updated at the end of the build. This is to allow you to use gensync correctly BUT you can edit the PKGBUILD file manually afterwards of course.<br />
<br />
* Until you have your own config that you are happy with it is easiest just to start with the default Arch config; you should also get the Arch <code>kernel26.install</code> file, make your own <code>kernel26.install</code> script or comment out the line <code>install=kernel26.install</code> from the PKGBUILD. The official Arch files are both in your ABS tree, normally under <code>/var/abs/core/kernel26</code>. To download the ABS tree to your system simply run <code>abs</code> as root. It doesn't take long, even on dialup. You should keep this updated by running <code>abs</code> as root on a regular basis.<br />
:NOTE: If you use LILO or any other static bootloader (that is, one that requires update after every kernel change) you are advised to use an install file too. This is an example, <code>kernel26.install</code>, for use with Lilo:<br />
<br />
# arg 1: the new package version<br />
# arg 2: the old package version<br />
<br />
# Script by Jouke Witteveen (j <dot> witteveen <at> gmail)<br />
# Revision: 4<br />
<br />
link () {<br />
dialog --backtitle &quot;$ba&quot; --title Linking --yesno<br />
&quot;\nDo you want to link /vmlinuz to the $ke kernel?\n(This can be useful for configuring your bootloader)&quot; 9 60 &&{<br />
[ -e /vmlinuz -o -h /vmlinuz ] &&\<br />
mv -f /vmlinuz /vmlinuz.old<br />
kern () {<br />
ls -t /boot/vmlinuz$1* 2> /dev/null | head -n 1<br />
}<br />
vm=`kern \`echo $1 | sed &quot;s|\.||g&quot;\``<br />
[ ! -e &quot;$vm&quot; ] &&\<br />
vm=`kern`<br />
ln -s $vm /vmlinuz<br />
}<br />
}<br />
<br />
exec () {<br />
dialog --backtitle &quot;$ba&quot; --title &quot;Bootloader execution&quot; --yesno<br />
&quot;\nDo you want to run Lilo to make the $ke kernel bootable?\n\n\<br />
Remember: If you choose 'No' now you will not be able to boot the $ke kernel until you manually update your bootloader!&quot; 12 60 &&\<br />
lilo &&\<br />
echo -e $1 # At least Lilo did not return an error<br />
}<br />
<br />
warn () {<br />
dialog --backtitle &quot;$ba&quot; --title Warning --msgbox<br />
&quot;\nYou will not be able to boot the $ke kernel until you manually update your bootloader.&quot; 9 60<br />
}<br />
<br />
<br />
post_install () {<br />
ba=&quot;Installing kernel $1&quot;<br />
ke=&quot;new&quot;<br />
link $1 &&\<br />
exec &quot;\nKernel $1 successfully installed!\n&quot; ||\<br />
warn<br />
}<br />
<br />
post_upgrade () {<br />
ba=&quot;Upgrading kernel $2 to kernel $1&quot;<br />
ke=&quot;upgraded&quot;<br />
link $1<br />
exec &quot;\nKernel $2 successfully upgraded to version $1!\n&quot; ||\<br />
warn<br />
}<br />
<br />
post_remove () {<br />
unli () {<br />
[ -h $1 -a ! -e $1 ] &&\<br />
unlink $1<br />
}<br />
unli /vmlinuz<br />
unli /vmlinuz.old<br />
[ -e /vmlinuz.old -a ! -e /vmlinuz ] &&{<br />
ba=&quot;Removing kernel $1&quot;<br />
ke=&quot;old&quot;<br />
mv /vmlinuz.old /vmlinuz<br />
exec &quot;\nThe old kernel was successfully restored\n&quot; ||\<br />
warn<br />
}<br />
}<br />
<br />
<br />
<br />
* To check if <code>EXTRAVERSION</code> is set by your patchset try doing<br />
<br />
grep +EXTRAVERSION= ./patchname<br />
<br />
: and it should return something like this:<br />
<br />
+EXTRAVERSION = -ck3<br />
<br />
: if it doesn't then <code>EXTRAVERSION</code> is '''probably not being set''' by your patchset and you should ensure you use LOCALVERSION to customize the pkgname.<br>Arch default kernels are set with the <code>-ARCH</code> <code>LOCALVERSION</code> variable - you can set anything you like e.g. <code>-custom</code> (note the need for the preceding dash <code>-</code>)<br>Because of these added variables there is no need to alter the pkgname manually at any point or use any other variables. The build process automatically updates the pkgname variable in the PKGBUILD file at the end of each build to reflect the final full kernel version naming scheme.<br />
<br />
* If used correctly this PKGBUILD '''should''' always provide a unique kernel build based on EXTRAVERSION and LOCALVERSION, and on the pkgver and pkgrel (as normal) - however it is up to the user to '''double check''' resulting pkgnames and contents '''before''' installation to prevent overwrites (see below for more details and examples).<br />
<br />
=== Configuring the PKGBUILD ===<br />
Note that this PKGBUILD cannot be used with kernel 2.4, which is no longer supported by Arch Linux. ([http://www.archlinux.org/news/232/ news])<br />
<br />
Copy the PKGBUILD below to your $startdir. Before building remember the following:<br />
# <code>pkgname</code> can be left as it is; it will automatically be set and correct itself.<br />
# Insert the <code>pkgver</code> for your kernel (for example: <code>2.6.9</code>).<br />
# Change the <code>pkgrel</code> for your current revision. You should increment this each time you make changes to the kernel config and want to build a REPLACEMENT pkg. If you don't want to replace the previous build but rather install in parallel you should use <code>LOCALVERSION</code> to create a unique pkg.<br />
# Change/expand the <code>pkgdesc</code> to describe any patches or special config options applied.<br />
# Change the source to use a closer mirror and if you are using a patchset, add the patches to the source array.<br />
# {OPTIONAL} Place the patch commands where indicated.<br />
# Choose a make method by leaving your preferred method uncommented - gconfig (gtk based) xconfig (qt based) menuconfig (ncurses based).<br />
# During the build you will be asked if you want to <code>make clean</code> - the default is <code>yes</code>, reply <code>NO</code> if you know what you are doing.<br />
<br />
<pre><br />
# Contributor: dibblethewrecker <dibblethewrecker.at.jiwe.org><br />
pkgname=kernel26<br />
pkgver=2.6.x.y<br />
pkgrel=1<br />
pkgdesc=&quot;The Linux Kernel 2.6.x.y and modules (IDE support)&quot;<br />
url=&quot;http://www.kernel.org&quot;<br />
depends=('module-init-tools')<br />
install=kernel26.install<br />
arch=(i686 x86_64)<br />
license=('GPL')<br />
<br />
##### add any patch sources to this section<br />
source=(config ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$pkgver.tar.bz2 )<br />
<br />
# Function to grab var from src<br />
getvar() {<br />
old=$(cat Makefile | grep &quot;^$1&quot;)<br />
echo $(echo ${old/&quot;$1 =&quot;/} | sed -e &quot;s/[ ]*\(.*\)[ ]*/\1/g&quot;)<br />
return 0<br />
}<br />
<br />
build() {<br />
cd $srcdir/linux-$pkgver<br />
<br />
##### Uncomment and apply any patches here<br />
#patch -Np1 -i ../patchname || return 1<br />
<br />
# get rid of the 'i' in i686<br />
carch=`echo $CARCH | sed 's|i||'`<br />
cat ../config | sed &quot;s|#CARCH#|$carch|g&quot; >./.config<br />
<br />
##### Load config - uncomment your preferred config method<br />
#yes &quot;&quot; | make config<br />
#make oldconfig || return 1<br />
#make menuconfig<br />
#make xconfig<br />
make gconfig<br />
<br />
##### NO USER CHANGES BELOW HERE #####<br />
<br />
# save the current pkgname<br />
old_pkgname=$pkgname<br />
<br />
# set pkgname for build purposes - DO NOT alter!<br />
pkgname=kernel26<br />
<br />
# save the updated config to build with today's date<br />
cp ./.config $startdir/config-$(date +%b%d\-%Hh)<br />
<br />
# get EXTRAVERSION from Makefile to create a unique pkgname and /usr/src directory<br />
_kernextra=$(getvar &quot;EXTRAVERSION&quot;)<br />
# grab the 2.6.x.y version suffix from pkgver<br />
_y=&quot;`echo $pkgver | cut --delim &quot;.&quot; --fields 4`&quot;<br />
# remove .y version suffix from _kernextra<br />
_kernextra=&quot;`echo $_kernextra | sed &quot;s|\.$_y||g&quot;`&quot;<br />
<br />
# Read the full kernel version info from new config to use in pathnames and pkgname<br />
. ./.config<br />
<br />
# Kernel custom - to create a unique pkgname (see below)<br />
_kerncust=&quot;${_kernextra}${CONFIG_LOCALVERSION}&quot;<br />
# Kernel release - will be the same as Makefile<br />
_kernrel=&quot;${pkgver}${_kerncust}&quot;<br />
# Get the pkgver suffix for unique pkgname and /boot file suffices<br />
_pkgversuf=&quot;`echo $pkgver | sed &quot;s|2.6.||g&quot; | sed &quot;s|\.||g&quot;`&quot;<br />
# Set /boot file suffices from kernel release and pkgver suffix<br />
_kernboot=&quot;${_pkgversuf}${_kerncust}&quot;<br />
<br />
# Set a new pkgname from kernel release and pkgver suffix<br />
pkgname=&quot;${pkgname}${_pkgversuf}${_kerncust}&quot;<br />
<br />
# build!<br />
echo<br />
echo -n &quot;Do you want to make clean (default YES)? (YES/NO): &quot;<br />
read choice<br />
echo<br />
echo -n &quot;Press any key to start make or CTRL+C to quit&quot;<br />
read anykey<br />
<br />
if [ &quot;${choice}&quot; = &quot;NO&quot; ] ; then<br />
make bzImage modules || return 1<br />
else<br />
make clean bzImage modules || return 1<br />
fi<br />
<br />
mkdir -p $pkgdir/{lib/modules,boot}<br />
make INSTALL_MOD_PATH=$pkgdir modules_install || return 1<br />
cp System.map $pkgdir/boot/System.map26${_kernboot}<br />
cp arch/i386/boot/bzImage $pkgdir/boot/vmlinuz26${_kernboot}<br />
install -D -m644 Makefile \<br />
$pkgdir/usr/src/linux-${_kernrel}/Makefile<br />
install -D -m644 kernel/Makefile \<br />
$pkgdir/usr/src/linux-${_kernrel}/kernel/Makefile<br />
install -D -m644 .config \<br />
$pkgdir/usr/src/linux-${_kernrel}/.config<br />
install -D -m644 .kernelrelease \<br />
$pkgdir/usr/src/linux-${_kernrel}/.kernelrelease<br />
install -D -m644 .config $pkgdir/boot/kconfig26${_kernboot}<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/include<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/arch/i386/kernel<br />
for i in acpi asm-generic asm-i386 config linux math-emu media net pcmcia scsi sound video; do<br />
cp -a include/$i $pkgdir/usr/src/linux-${_kernrel}/include/<br />
done<br />
# copy files necessary for later builds, like nvidia and vmware<br />
cp Module.symvers $pkgdir/usr/src/linux-${_kernrel}<br />
cp -a scripts $pkgdir/usr/src/linux-${_kernrel}<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/.tmp_versions<br />
cp arch/i386/Makefile $pkgdir/usr/src/linux-${_kernrel}/arch/i386/<br />
cp arch/i386/Makefile.cpu $pkgdir/usr/src/linux-${_kernrel}/arch/i386/<br />
cp arch/i386/kernel/asm-offsets.s \<br />
$pkgdir/usr/src/linux-${_kernrel}/arch/i386/kernel/<br />
# copy in Kconfig files<br />
for i in `find . -name &quot;Kconfig*&quot;`; do<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/`echo $i | sed 's|/Kconfig.*||'`<br />
cp $i $pkgdir/usr/src/linux-${_kernrel}/$i<br />
done<br />
cd $pkgdir/usr/src/linux-${_kernrel}/include && ln -s asm-i386 asm<br />
chown -R root.root $pkgdir/usr/src/linux-${_kernrel}<br />
cd $pkgdir/lib/modules/${_kernrel} && \<br />
(rm -f source build; ln -sf /usr/src/linux-${_kernrel} build)<br />
<br />
# Correct the pkgname in our PKGBUILD - this allows correct gensync operation<br />
# NOTE: pkgname variable must be declared with first 10 lines of PKGBUILD!<br />
cd $startdir<br />
sed -i &quot;1,11 s|pkgname=$old_pkgname|pkgname=$pkgname|&quot; ./PKGBUILD<br />
}<br />
# vim:syntax=sh<br />
</pre><br />
<br />
* Install your new pkg as normal.<br />
<br />
=== Your <code>config</code> file ===<br />
PLEASE NOTE: during the build the '''final''' kernel config is stored in your <code>$startdir</code> as, for example, <code>config-Apr13-12h</code>. Your '''original''' config remains in the <code>$startdir</code> named <code>config</code>. If you wish to use the new config in another build make sure you copy the correct file!<br />
<br />
===Update Bootloader===<br />
* Remember to edit the bootloader (e.g. [[LILO]] or [[GRUB]]) configuration files to include an entry to the new kernel. The new kernel will install alongside any existing stock or custom kernels, so you may wish to keep a reference to your old kernel in the bootloader configuration file - at least, until you're sure the new one is working.<br />
<br />
* If you use a static bootloader (one that requires update after every kernel change), remember to update it. For LILO, running <code>lilo</code> as root should suffice.<br />
<br />
=== Other versions ===<br />
There are several variations on this PKGBUILD available, they all provide identical results but the mechanics are slightly different:<br />
* [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_patch patch] - includes the old <code>patch=</code> variable.<br />
* [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_verbose verbose] - provides Package Info (like that shown above) for review before starting the make process.<br />
* [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_buildstats buildstats] - similar to verbose but writes more info, including build times, to a file called buildstats, which is stored in the $startdir. This can also be reviewed before starting the make process but also provides a permanent record.<br />
<br />
=== I want the Arch logo! ===<br />
Download the <code>logo_linux_clut224.ppm</code> to your <code>$startdir</code> from:<br />
<br />
[http://projects.archlinux.org/?p=linux-2.6-ARCH.git;a=tree;f=patches http://projects.archlinux.org/?p=linux-2.6-ARCH.git;a=tree;f=patches]<br />
<br />
Add the the file <code>logo_linux_clut224.ppm</code> to the source array, and add the copy command marked with (<code>>></code>) below into the PKGBUILD as indicated:<br />
<br />
<pre><br />
##### Uncomment and apply any patches here<br />
#patch -Np1 -i ../patchname || return 1<br />
<br />
>> ##### Arch logo - not compatible with gensplash!<br />
>> cp ../logo_linux_clut224.ppm drivers/video/logo/<br />
<br />
# get rid of the 'i' in i686<br />
carch=`echo $CARCH | sed 's|i||'`<br />
cat ../config | sed &quot;s|#CARCH#|$carch|g&quot; >./.config<br />
</pre><br />
<br />
The stock Arch config uses the following logo settings, ensure you set them at the config stage or use the stock config:<br />
<br />
<pre><br />
#<br />
# Logo configuration<br />
#<br />
CONFIG_LOGO=y<br />
CONFIG_LOGO_LINUX_MONO=y<br />
CONFIG_LOGO_LINUX_VGA16=y<br />
CONFIG_LOGO_LINUX_CLUT224=y<br />
</pre><br />
<br />
=== Customization and Advanced Use (normal people can stop here) ===<br />
Several people have successfully customized this PKGBUILD to their own needs, while others have derived a completely new approach from it. One customization recommended to people who make multiple builds of the same version for use in parallel is to add a sed command that automatically sets the <code>CONFIG_LOCALVERSION</code> variable in the config to a unique value before the config stage. This can be based on the date, your hostname, etc.<br />
For example:<br />
<pre><br />
# get rid of the 'i' in i686<br />
carch=`echo $CARCH | sed 's|i||'`<br />
cat ../config | sed &quot;s|#CARCH#|$carch|g&quot; >./.config<br />
<br />
>> # set LOCALVERSION to -date<br />
>> sed -i &quot;s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=-`date +%y%m%d`|g&quot; ./.config<br />
<br />
##### Load config - uncomment your preferred config method<br />
#yes &quot;&quot; | make config<br />
</pre><br />
<br />
or<br />
<br />
<pre><br />
# set LOCALVERSION to -date-hostname<br />
sed -i &quot;s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=-`date +%y%m%d`-`hostname`|g&quot; ./.config<br />
</pre><br />
<br />
For a truly unique <code>LOCALVERSION</code> you can set the date to seconds since <code>00:00:00 1970-01-01 UTC</code>!<br />
<br />
<pre><br />
sed -i &quot;s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=-`date +%s`|g&quot; ./.config<br />
</pre><br />
<br />
=== Problems ===<br />
<br />
If you have problems with wrong package names try using the [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_verbose verbose] PKGBUILD described in [[Custom_Kernel_Compilation_with_ABS#Other_versions|Other Versions]] above to see what naming scheme is being created before you commit to the build - you can quit with ''ctrl+c'' at most points before the make starts.<br />
<br />
=== Using the nVIDIA video driver with your custom kernel ===<br />
<br />
To use the nvidia driver with your new custom kernel, see: [[NVIDIA#Alternate_install:_custom_kernel|How to install NVIDIA driver with custom kernel]]<br />
<br />
=== Feedback ===<br />
If you have any questions/comments/suggestions about the above PKGBUILD feel free to join the discussion at: http://bbs.archlinux.org/viewtopic.php?t=9272<br />
<br />
Some suggestions have already been incorporated but please consider the Keep It Simple philosophy and remember the original goal. Kernel compilation is a very individual process and there are a HUGE variety of ways to go about it. This PKGBUILD does not even attempt to account for all eventualities, it would be fruitless to try but of course you are completely free to customize this build to your precise needs. Best of luck!<br />
<br />
''DibbleTheWrecker''</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Custom_Kernel_Compilation_with_ABS&diff=94462
Custom Kernel Compilation with ABS
2010-01-30T12:20:55Z
<p>Daenyth: /* Usage Notes */ Remove some outdated info.</p>
<hr />
<div>[[Category:Kernel (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Custom_Kernel_Compilation_with_ABS}}<br />
{{i18n_entry|简体中文|从ABS定制内核}}<br />
{{i18n_entry|Italiano|Custom_Kernel_Compilation_with_ABS_(Italiano)}}<br />
{{i18n_links_end}}<br />
<br />
=== Introduction ===<br />
There are many ways to build the kernel in arch, this is just one example - for other possibilities see [[Kernel_Compilation|Kernel Compilation]]. Some Arch users prefer [[Kernel Compilation From Source|the traditional way]], however using ABS is helpful for automating certain tasks. The choice is yours; neither way is inherently better than the other. <br />
<br />
This howto has been updated to provide a definitive PKGBUILD for the creation of custom kernel packages. It allows you to maintain multiple custom kernels with a unique naming scheme under pacman version control. It is ideal for ANY custom kernel build and can be easily adapted to fit many requirements. The PKGBUILD automatically accounts for the <code>EXTRAVERSION</code> and <code>LOCALVERSION</code> variables that are now fully supported in the kernel. <code>EXTRAVERSION</code> is frequently set by major patchsets such as -ck and -nitro. <code>EXTRAVERSION</code> is also used in the 2.6.x.y branch to carry the <code>.y</code> variable. <code>LOCALVERSION</code> can be set during the config stage and is the easiest and RECOMMENDED way to customize your kernel pkgnames. Simply setting <code>LOCALVERSION</code> to <code>-custom</code> or the date e.g. <code>-20050105</code> will suffice! A unique LOCALVERSION guarantees a unique pkg.<br />
<br />
Note that this is NOT an ABS howto - to successfully follow this HOWTO a working knowledge of building packages with ABS is ESSENTIAL - please read [[Arch Build System]], [[The Arch package making HOW-TO - with guidelines]] and [[Patching in ABS]].<br />
<br />
=== Philosophy and Logic (how it works and why it works this way) ===<br />
* The Arch Way - Keep It Simple.<br />
* This PKGBUILD builds on the previous, widely accepted version.<br />
* This build provides kernel packages and components with a simple, logical and uncomplicated naming scheme that ONLY uses variables that are part of the ABS system and part of the kernel compilation process itself. Rationale:<br />
** The stock Arch kernel uses the <code>kernel26</code> base pkgname which is logically extended here under the 2.6.x and 2.6.x.y schemes e.g <code>kernel2611</code> and <code>kernel26117</code><br>These also provide the basis of <code>/boot</code> filenames e.g. <code>vmlinux26</code> and <code>vmlinuz26117</code><br />
** The ''kernel compilation process'' uses the kernel version (2.6.x), <code>EXTRAVERSION</code> from the <code>Makefile</code> and <code>CONFIG_LOCALVERSION</code> from the kernel config to create the name for the kernel's module directory, e.g.:<br />
<br />
<pre><br />
2.6.x$EXTRAVERSION$LOCALVERSION<br />
2.6.11-cko2-ARCH/<br />
</pre><br />
<br />
: This is beyond the control of the PKGBUILD so to provide a pkg with similarly named components the PKGBUILD uses the same scheme to create unique <code>/boot</code> files and a unique <code>/usr/src</code> directory by appending <code>-EXTRAVERSION-LOCALVERSION</code>, e.g.:<br />
<br />
<pre><br />
/boot/vmlinuz2611-cko2-ARCH<br />
/boot/System.map2611-cko2-ARCH<br />
/boot/kconfig2611-cko2-ARCH<br />
<br />
/usr/src/linux-2.6.11-cko2-ARCH/<br />
</pre><br />
<br />
* If you have the recommended knowledge of ABS you will see that the PKGBUILD is transparently constructed, self-explanatory and can be customized easily.<br />
* User input is almost identical to all ABS builds: simply set <code>pkgver</code>, <code>pkgrel</code> and <code>pkgdesc</code> and add additional sources, including patches, to the <code>source</code> array. Patch users should insert the appropriate patch commands where indicated. Aside from uncommenting the config method and choosing whether to <code>make clean</code> or not the rest of the build is automated.<br />
* Having created a custom pkg naming scheme during the build, the PKGBUILD automatically corrects/updates itself with the new <code>pkgname</code> variable allowing simple <code>gensync</code> operation.<br />
<br />
=== Usage Notes ===<br />
<br />
* <code>pkgname</code> must be declared within 10 lines of the top of the PKGBUILD - so '''DO NOT''' move it - just leave it.<br><br />
If you miss this simple instruction don't worry, it won't screw up your build but your PKGBUILD file will not have the pkgname automatically updated at the end of the build. This is to allow you to use gensync correctly BUT you can edit the PKGBUILD file manually afterwards of course.<br />
<br />
* Until you have your own config that you are happy with it is easiest just to start with the default Arch config; you should also get the Arch <code>kernel26.install</code> file, make your own <code>kernel26.install</code> script or comment out the line <code>install=kernel26.install</code> from the PKGBUILD. The official Arch files are both in your ABS tree, normally under <code>/var/abs/core/kernel26</code>. To download the ABS tree to your system simply run <code>abs</code> as root. It doesn't take long, even on dialup. You should keep this updated by running <code>abs</code> as root on a regular basis.<br />
:NOTE: If you use LILO or any other static bootloader (that is, one that requires update after every kernel change) you are advised to use an install file too. This is an example, <code>kernel26.install</code>, for use with Lilo:<br />
<br />
# arg 1: the new package version<br />
# arg 2: the old package version<br />
<br />
# Script by Jouke Witteveen (j <dot> witteveen <at> gmail)<br />
# Revision: 4<br />
<br />
link () {<br />
dialog --backtitle &quot;$ba&quot; --title Linking --yesno<br />
&quot;\nDo you want to link /vmlinuz to the $ke kernel?\n(This can be useful for configuring your bootloader)&quot; 9 60 &&{<br />
[ -e /vmlinuz -o -h /vmlinuz ] &&\<br />
mv -f /vmlinuz /vmlinuz.old<br />
kern () {<br />
ls -t /boot/vmlinuz$1* 2> /dev/null | head -n 1<br />
}<br />
vm=`kern \`echo $1 | sed &quot;s|\.||g&quot;\``<br />
[ ! -e &quot;$vm&quot; ] &&\<br />
vm=`kern`<br />
ln -s $vm /vmlinuz<br />
}<br />
}<br />
<br />
exec () {<br />
dialog --backtitle &quot;$ba&quot; --title &quot;Bootloader execution&quot; --yesno<br />
&quot;\nDo you want to run Lilo to make the $ke kernel bootable?\n\n\<br />
Remember: If you choose 'No' now you will not be able to boot the $ke kernel until you manually update your bootloader!&quot; 12 60 &&\<br />
lilo &&\<br />
echo -e $1 # At least Lilo did not return an error<br />
}<br />
<br />
warn () {<br />
dialog --backtitle &quot;$ba&quot; --title Warning --msgbox<br />
&quot;\nYou will not be able to boot the $ke kernel until you manually update your bootloader.&quot; 9 60<br />
}<br />
<br />
<br />
post_install () {<br />
ba=&quot;Installing kernel $1&quot;<br />
ke=&quot;new&quot;<br />
link $1 &&\<br />
exec &quot;\nKernel $1 successfully installed!\n&quot; ||\<br />
warn<br />
}<br />
<br />
post_upgrade () {<br />
ba=&quot;Upgrading kernel $2 to kernel $1&quot;<br />
ke=&quot;upgraded&quot;<br />
link $1<br />
exec &quot;\nKernel $2 successfully upgraded to version $1!\n&quot; ||\<br />
warn<br />
}<br />
<br />
post_remove () {<br />
unli () {<br />
[ -h $1 -a ! -e $1 ] &&\<br />
unlink $1<br />
}<br />
unli /vmlinuz<br />
unli /vmlinuz.old<br />
[ -e /vmlinuz.old -a ! -e /vmlinuz ] &&{<br />
ba=&quot;Removing kernel $1&quot;<br />
ke=&quot;old&quot;<br />
mv /vmlinuz.old /vmlinuz<br />
exec &quot;\nThe old kernel was successfully restored\n&quot; ||\<br />
warn<br />
}<br />
}<br />
<br />
<br />
<br />
* To check if <code>EXTRAVERSION</code> is set by your patchset try doing<br />
<br />
grep +EXTRAVERSION= ./patchname<br />
<br />
: and it should return something like this:<br />
<br />
+EXTRAVERSION = -ck3<br />
<br />
: if it doesn't then <code>EXTRAVERSION</code> is '''probably not being set''' by your patchset and you should ensure you use LOCALVERSION to customize the pkgname.<br>Arch default kernels are set with the <code>-ARCH</code> <code>LOCALVERSION</code> variable - you can set anything you like e.g. <code>-custom</code> (note the need for the preceding dash <code>-</code>)<br>Because of these added variables there is no need to alter the pkgname manually at any point or use any other variables. The build process automatically updates the pkgname variable in the PKGBUILD file at the end of each build to reflect the final full kernel version naming scheme.<br />
<br />
* If used correctly this PKGBUILD '''should''' always provide a unique kernel build based on EXTRAVERSION and LOCALVERSION, and on the pkgver and pkgrel (as normal) - however it is up to the user to '''double check''' resulting pkgnames and contents '''before''' installation to prevent overwrites (see below for more details and examples).<br />
<br />
=== Configuring the PKGBUILD ===<br />
Note that this PKGBUILD cannot be used with kernel 2.4, which is no longer supported by Arch Linux. ([http://www.archlinux.org/news/232/ news])<br />
<br />
Copy the PKGBUILD below to your $startdir. Before building remember the following:<br />
# <code>pkgname</code> can be left as it is; it will automatically be set and correct itself.<br />
# Insert the <code>pkgver</code> for your kernel (for example: <code>2.6.9</code>).<br />
# Change the <code>pkgrel</code> for your current revision. You should increment this each time you make changes to the kernel config and want to build a REPLACEMENT pkg. If you don't want to replace the previous build but rather install in parallel you should use <code>LOCALVERSION</code> to create a unique pkg.<br />
# Change/expand the <code>pkgdesc</code> to describe any patches or special config options applied.<br />
# Change the source to use a closer mirror and if you are using a patchset, add the patches to the source array.<br />
# {OPTIONAL} Place the patch commands where indicated.<br />
# Choose a make method by leaving your preferred method uncommented - gconfig (gtk based) xconfig (qt based) menuconfig (ncurses based).<br />
# During the build you will be asked if you want to <code>make clean</code> - the default is <code>yes</code>, reply <code>NO</code> if you know what you are doing.<br />
<br />
<pre><br />
# Contributor: dibblethewrecker <dibblethewrecker.at.jiwe.org><br />
pkgname=kernel26<br />
pkgver=2.6.x.y<br />
pkgrel=1<br />
pkgdesc=&quot;The Linux Kernel 2.6.x.y and modules (IDE support)&quot;<br />
url=&quot;http://www.kernel.org&quot;<br />
depends=('module-init-tools')<br />
install=kernel26.install<br />
arch=(i686 x86_64)<br />
license=('GPL')<br />
<br />
##### add any patch sources to this section<br />
source=(config ftp://ftp.kernel.org/pub/linux/kernel/v2.6/linux-$pkgver.tar.bz2 )<br />
<br />
# Function to grab var from src<br />
getvar() {<br />
old=$(cat Makefile | grep &quot;^$1&quot;)<br />
echo $(echo ${old/&quot;$1 =&quot;/} | sed -e &quot;s/[ ]*\(.*\)[ ]*/\1/g&quot;)<br />
return 0<br />
}<br />
<br />
build() {<br />
cd $srcdir/linux-$pkgver<br />
<br />
##### Uncomment and apply any patches here<br />
#patch -Np1 -i ../patchname || return 1<br />
<br />
# get rid of the 'i' in i686<br />
carch=`echo $CARCH | sed 's|i||'`<br />
cat ../config | sed &quot;s|#CARCH#|$carch|g&quot; >./.config<br />
<br />
##### Load config - uncomment your preferred config method<br />
#yes &quot;&quot; | make config<br />
#make oldconfig || return 1<br />
#make menuconfig<br />
#make xconfig<br />
make gconfig<br />
<br />
##### NO USER CHANGES BELOW HERE #####<br />
<br />
# save the current pkgname<br />
old_pkgname=$pkgname<br />
<br />
# set pkgname for build purposes - DO NOT alter!<br />
pkgname=kernel26<br />
<br />
# save the updated config to build with today's date<br />
cp ./.config $startdir/config-$(date +%b%d\-%Hh)<br />
<br />
# get EXTRAVERSION from Makefile to create a unique pkgname and /usr/src directory<br />
_kernextra=$(getvar &quot;EXTRAVERSION&quot;)<br />
# grab the 2.6.x.y version suffix from pkgver<br />
_y=&quot;`echo $pkgver | cut --delim &quot;.&quot; --fields 4`&quot;<br />
# remove .y version suffix from _kernextra<br />
_kernextra=&quot;`echo $_kernextra | sed &quot;s|\.$_y||g&quot;`&quot;<br />
<br />
# Read the full kernel version info from new config to use in pathnames and pkgname<br />
. ./.config<br />
<br />
# Kernel custom - to create a unique pkgname (see below)<br />
_kerncust=&quot;${_kernextra}${CONFIG_LOCALVERSION}&quot;<br />
# Kernel release - will be the same as Makefile<br />
_kernrel=&quot;${pkgver}${_kerncust}&quot;<br />
# Get the pkgver suffix for unique pkgname and /boot file suffices<br />
_pkgversuf=&quot;`echo $pkgver | sed &quot;s|2.6.||g&quot; | sed &quot;s|\.||g&quot;`&quot;<br />
# Set /boot file suffices from kernel release and pkgver suffix<br />
_kernboot=&quot;${_pkgversuf}${_kerncust}&quot;<br />
<br />
# Set a new pkgname from kernel release and pkgver suffix<br />
pkgname=&quot;${pkgname}${_pkgversuf}${_kerncust}&quot;<br />
<br />
# build!<br />
echo<br />
echo -n &quot;Do you want to make clean (default YES)? (YES/NO): &quot;<br />
read choice<br />
echo<br />
echo -n &quot;Press any key to start make or CTRL+C to quit&quot;<br />
read anykey<br />
<br />
if [ &quot;${choice}&quot; = &quot;NO&quot; ] ; then<br />
make bzImage modules || return 1<br />
else<br />
make clean bzImage modules || return 1<br />
fi<br />
<br />
mkdir -p $pkgdir/{lib/modules,boot}<br />
make INSTALL_MOD_PATH=$pkgdir modules_install || return 1<br />
cp System.map $pkgdir/boot/System.map26${_kernboot}<br />
cp arch/i386/boot/bzImage $pkgdir/boot/vmlinuz26${_kernboot}<br />
install -D -m644 Makefile \<br />
$pkgdir/usr/src/linux-${_kernrel}/Makefile<br />
install -D -m644 kernel/Makefile \<br />
$pkgdir/usr/src/linux-${_kernrel}/kernel/Makefile<br />
install -D -m644 .config \<br />
$pkgdir/usr/src/linux-${_kernrel}/.config<br />
install -D -m644 .kernelrelease \<br />
$pkgdir/usr/src/linux-${_kernrel}/.kernelrelease<br />
install -D -m644 .config $pkgdir/boot/kconfig26${_kernboot}<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/include<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/arch/i386/kernel<br />
for i in acpi asm-generic asm-i386 config linux math-emu media net pcmcia scsi sound video; do<br />
cp -a include/$i $pkgdir/usr/src/linux-${_kernrel}/include/<br />
done<br />
# copy files necessary for later builds, like nvidia and vmware<br />
cp Module.symvers $pkgdir/usr/src/linux-${_kernrel}<br />
cp -a scripts $pkgdir/usr/src/linux-${_kernrel}<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/.tmp_versions<br />
cp arch/i386/Makefile $pkgdir/usr/src/linux-${_kernrel}/arch/i386/<br />
cp arch/i386/Makefile.cpu $pkgdir/usr/src/linux-${_kernrel}/arch/i386/<br />
cp arch/i386/kernel/asm-offsets.s \<br />
$pkgdir/usr/src/linux-${_kernrel}/arch/i386/kernel/<br />
# copy in Kconfig files<br />
for i in `find . -name &quot;Kconfig*&quot;`; do<br />
mkdir -p $pkgdir/usr/src/linux-${_kernrel}/`echo $i | sed 's|/Kconfig.*||'`<br />
cp $i $pkgdir/usr/src/linux-${_kernrel}/$i<br />
done<br />
cd $pkgdir/usr/src/linux-${_kernrel}/include && ln -s asm-i386 asm<br />
chown -R root.root $pkgdir/usr/src/linux-${_kernrel}<br />
cd $pkgdir/lib/modules/${_kernrel} && \<br />
(rm -f source build; ln -sf /usr/src/linux-${_kernrel} build)<br />
<br />
# Correct the pkgname in our PKGBUILD - this allows correct gensync operation<br />
# NOTE: pkgname variable must be declared with first 10 lines of PKGBUILD!<br />
cd $startdir<br />
sed -i &quot;1,11 s|pkgname=$old_pkgname|pkgname=$pkgname|&quot; ./PKGBUILD<br />
}<br />
# vim:syntax=sh<br />
</pre><br />
<br />
* Install your new pkg as normal.<br />
<br />
=== Your <code>config</code> file ===<br />
PLEASE NOTE: during the build the '''final''' kernel config is stored in your <code>$startdir</code> as, for example, <code>config-Apr13-12h</code>. Your '''original''' config remains in the <code>$startdir</code> named <code>config</code>. If you wish to use the new config in another build make sure you copy the correct file!<br />
<br />
===Update Bootloader===<br />
* Remember to edit the bootloader (e.g. [[LILO]] or [[GRUB]]) configuration files to include an entry to the new kernel. The new kernel will install alongside any existing stock or custom kernels, so you may wish to keep a reference to your old kernel in the bootloader configuration file - at least, until you're sure the new one is working.<br />
<br />
* If you use a static bootloader (one that requires update after every kernel change), remember to update it. For LILO, running <code>lilo</code> as root should suffice.<br />
<br />
=== Other versions ===<br />
There are several variations on this PKGBUILD available, they all provide identical results but the mechanics are slightly different:<br />
* [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_patch patch] - includes the old <code>patch=</code> variable.<br />
* [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_verbose verbose] - provides Package Info (like that shown above) for review before starting the make process.<br />
* [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_buildstats buildstats] - similar to verbose but writes more info, including build times, to a file called buildstats, which is stored in the $startdir. This can also be reviewed before starting the make process but also provides a permanent record.<br />
<br />
=== I want the Arch logo! ===<br />
Download the <code>logo_linux_clut224.ppm</code> to your <code>$startdir</code> from:<br />
<br />
[http://projects.archlinux.org/?p=linux-2.6-ARCH.git;a=tree;f=patches http://projects.archlinux.org/?p=linux-2.6-ARCH.git;a=tree;f=patches]<br />
<br />
Add the the file <code>logo_linux_clut224.ppm</code> to the source array, and add the copy command marked with (<code>>></code>) below into the PKGBUILD as indicated:<br />
<br />
<pre><br />
##### Uncomment and apply any patches here<br />
#patch -Np1 -i ../patchname || return 1<br />
<br />
>> ##### Arch logo - not compatible with gensplash!<br />
>> cp ../logo_linux_clut224.ppm drivers/video/logo/<br />
<br />
# get rid of the 'i' in i686<br />
carch=`echo $CARCH | sed 's|i||'`<br />
cat ../config | sed &quot;s|#CARCH#|$carch|g&quot; >./.config<br />
</pre><br />
<br />
The stock Arch config uses the following logo settings, ensure you set them at the config stage or use the stock config:<br />
<br />
<pre><br />
#<br />
# Logo configuration<br />
#<br />
CONFIG_LOGO=y<br />
CONFIG_LOGO_LINUX_MONO=y<br />
CONFIG_LOGO_LINUX_VGA16=y<br />
CONFIG_LOGO_LINUX_CLUT224=y<br />
</pre><br />
<br />
=== Customization and Advanced Use (normal people can stop here) ===<br />
Several people have successfully customized this PKGBUILD to their own needs, while others have derived a completely new approach from it. One customization recommended to people who make multiple builds of the same version for use in parallel is to add a sed command that automatically sets the <code>CONFIG_LOCALVERSION</code> variable in the config to a unique value before the config stage. This can be based on the date, your hostname, etc.<br />
For example:<br />
<pre><br />
# get rid of the 'i' in i686<br />
carch=`echo $CARCH | sed 's|i||'`<br />
cat ../config | sed &quot;s|#CARCH#|$carch|g&quot; >./.config<br />
<br />
>> # set LOCALVERSION to -date<br />
>> sed -i &quot;s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=-`date +%y%m%d`|g&quot; ./.config<br />
<br />
##### Load config - uncomment your preferred config method<br />
#yes &quot;&quot; | make config<br />
</pre><br />
<br />
or<br />
<br />
<pre><br />
# set LOCALVERSION to -date-hostname<br />
sed -i &quot;s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=-`date +%y%m%d`-`hostname`|g&quot; ./.config<br />
</pre><br />
<br />
For a truly unique <code>LOCALVERSION</code> you can set the date to seconds since <code>00:00:00 1970-01-01 UTC</code>!<br />
<br />
<pre><br />
sed -i &quot;s|CONFIG_LOCALVERSION=.*|CONFIG_LOCALVERSION=-`date +%s`|g&quot; ./.config<br />
</pre><br />
<br />
=== Problems ===<br />
<br />
If you have problems with wrong package names try using the [http://dtw.jiwe.org/share/kernel/PKGBUILDS/PKGBUILD.custom_kernel_verbose verbose] PKGBUILD described in [[Custom_Kernel_Compilation_with_ABS#Other_versions|Other Versions]] above to see what naming scheme is being created before you commit to the build - you can quit with ''ctrl+c'' at most points before the make starts.<br />
<br />
=== Using the nVIDIA video driver with your custom kernel ===<br />
<br />
To use the nvidia driver with your new custom kernel, see: [[NVIDIA#Alternate_install:_custom_kernel|How to install NVIDIA driver with custom kernel]]<br />
<br />
=== Feedback ===<br />
If you have any questions/comments/suggestions about the above PKGBUILD feel free to join the discussion at: http://bbs.archlinux.org/viewtopic.php?t=9272<br />
<br />
Some suggestions have already been incorporated but please consider the Keep It Simple philosophy and remember the original goal. Kernel compilation is a very individual process and there are a HUGE variety of ways to go about it. This PKGBUILD does not even attempt to account for all eventualities, it would be fruitless to try but of course you are completely free to customize this build to your precise needs. Best of luck!<br />
<br />
''DibbleTheWrecker''</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Official_repositories&diff=92985
Official repositories
2010-01-22T00:03:58Z
<p>Daenyth: /* [testing] */ More info about the repo.</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:About Arch (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Official Repositories}}<br />
{{i18n_entry|Türkçe|Resmi Depolar}}<br />
{{i18n_entry|Česky|Oficiální repozitáře (Česky)}}<br />
{{i18n_entry|Español|Repositorios Oficiales}}<br />
{{i18n_entry|Italiano|Official_Repositories_(Italiano)}}<br />
{{i18n_entry|简体中文|官方软件仓库}}<br />
{{i18n_entry|Português|Official Repositories (Português)}}<br />
{{i18n_entry|Nederlands|Officiële Repositories (Nederlands)}}<br />
{{i18n_entry|Français|Dépôts Officiels (Français)}}<br />
{{i18n_links_end}}<br />
<br />
''As there is much confusion about the official repositories, this article attempts to explain their meaning.''<br />
<br />
= Historical background =<br />
<br />
Most of the repository splits are for historical reasons. Originally, when Arch Linux was used by very few users, there was only one repository known as ''[official]'' (now '''[core]'''). At the time, [official] basically contained Judd Vinet's preferred applications. It was designed to contain one of each "type" of program -- one DE, one major browser, etc.<br />
<br />
There were users back then that didn't like Judd's selection, so since the [[Arch Build System]] is so easy to use, they created packages of their own. These packages went into a repository called ''[unofficial]'', and were maintained by developers other than Judd. Eventually, the two repositories were both considered equally supported by the developers, so the names [official] and [unofficial] no longer reflected their true purpose. They were subsequently renamed to ''[current]'' and ''[extra]'' sometime near the release version 0.5.<br />
<br />
Shortly after the 2007.8.1 release, [current] was renamed [core] in order to prevent confusion over what exactly it contains. The repositories are now more or less equal in the eyes of the developers and the community, but [core] does have some differences. The main distinction is that packages used for Installation CDs and release snapshots are taken only from [core]. This repository still gives a complete Linux system, though it may not be the Linux system you want.<br />
<br />
Now, sometime around 0.5 or 0.6, they found there were a lot of packages that the developers didn't want to maintain. One of the developers (Xentac) set up the "Trusted User Repositories", which were unofficial repositories in which trusted users could place packages they had created. There was a ''[staging]'' repository where packages could be promoted into the official repositories by one of the Arch Linux developers, but other than this, the developers and trusted users were more or less distinct.<br />
<br />
This worked for a while, but not when trusted users got bored with their repositories, and not when untrusted users wanted to share their own packages. This led to the development of the [http://aur.archlinux.org/ AUR]. The TUs were conglomerated into a more closely knit group, and they now collectively maintain the '''[community]''' repository. The Trusted Users are still a separate group from the Arch Linux developers, and there isn't a lot of communication between them. However, popular packages are still promoted from [community] to '''[extra]''' on occasion. The [http://aur.archlinux.org/ AUR] also supports allowing untrusted users to submit PKGBUILDs for other users to use if they wish. These packages are unsupported, and the packages are sometimes called the '''[unsupported]''' repository, though since no binary packages are distributed, unsupported isn't really a repository. Trusted users can adopt packages from unsupported into [community] at their discretion, whether it is because the package is popular or because they are interested in maintaining it.<br />
<br />
= List of repositories =<br />
<br />
== [core] ==<br />
<br />
The [core] repository can be found in ''core/os/i686'' or ''core/os/x86_64'' on your favorite mirror. It contains Arch core packages and some additional software, and will provide you with a fully functional base system.<br />
<br />
''The installation cd simply contains an installer script, and a snapshot of the core repository.''<br />
<br />
== [extra] ==<br />
<br />
The [extra] repository can be found in ''extra/os/i686'' or ''extra/os/x86_64'' on your favorite mirror. It contains all packages that don't fit in [core]<br><br />
Example: X.org, window managers, web servers, media players, languages like Python, Ruby and Perl, and a lot more.<br />
<br />
== [community] ==<br />
<br />
The [community] repository can be found in ''community/os/i686'' or ''community/os/x86_64'' on your favorite mirror. It is maintained by the ''Trusted Users (TUs)'' and is part of the ''Arch User Repository (AUR)''. It contains packages from the ''AUR'' that have enough votes and were adopted by a ''TU''.<br />
<br />
== [testing] ==<br />
<br />
The [testing] repository can be found in ''testing/os/i686'' on your favorite mirror. [testing] is special because it contains packages that are candidates for the [core] or [extra] repositories. New packages go into [testing] if:<br />
* they are expected to break something on update and need to be tested first<br />
* they require other packages to be rebuilt. In this case, all packages that need to be rebuilt are put into [testing] first and when all rebuilds are done, they are moved back to the other repositories.<br />
<br />
[testing] is the only repository that can have name collisions with any of the other official repositories. If enabled, it has to be the first repo listed in your ''pacman.conf'' file.<br />
<br />
Be careful when enabling [testing]. Your system may break after you perform an update with the [testing] repository enabled. Only experienced users who know how to deal with potential system breakage should use it.<br />
<br />
The [testing] repo is not for the "newest of the new" package versions. Part of its purpose is to hold package updates that have the potential to cause system breakage, either by being part of the [core] set of packages, or by being critical in other ways. As such, users of the [testing] repository are strongly encouraged to subscribe to the arch-dev-public mailing list, and to report all bugs to the bug tracker.<br />
<br />
== [community-testing] ==<br />
<br />
The [community-testing] repository is like the [testing] repository but for packages that are candidates for the [community] repository.<br />
<br />
== AUR a.k.a. [unsupported] ==<br />
<br />
[[AUR]] or Arch User Repository is not really a repository at all. It refers to a database of user-submitted build scripts known as [[PKGBUILD]] files, thus this repository truly is unofficial. Users cannot download or install packages from [[AUR]] using [[pacman]]. They must download the [[PKGBUILD]] files and run [[makepkg]] which downloads the sources and builds packages. These locally build packages can then be installed using [[pacman]]. To automate this task, one of the popular [[AUR Helpers]] can be used.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Official_repositories&diff=92984
Official repositories
2010-01-22T00:00:56Z
<p>Daenyth: /* [testing] */ Mention arch-dev-public and the bug tracker.</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:About Arch (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Official Repositories}}<br />
{{i18n_entry|Türkçe|Resmi Depolar}}<br />
{{i18n_entry|Česky|Oficiální repozitáře (Česky)}}<br />
{{i18n_entry|Español|Repositorios Oficiales}}<br />
{{i18n_entry|Italiano|Official_Repositories_(Italiano)}}<br />
{{i18n_entry|简体中文|官方软件仓库}}<br />
{{i18n_entry|Português|Official Repositories (Português)}}<br />
{{i18n_entry|Nederlands|Officiële Repositories (Nederlands)}}<br />
{{i18n_entry|Français|Dépôts Officiels (Français)}}<br />
{{i18n_links_end}}<br />
<br />
''As there is much confusion about the official repositories, this article attempts to explain their meaning.''<br />
<br />
= Historical background =<br />
<br />
Most of the repository splits are for historical reasons. Originally, when Arch Linux was used by very few users, there was only one repository known as ''[official]'' (now '''[core]'''). At the time, [official] basically contained Judd Vinet's preferred applications. It was designed to contain one of each "type" of program -- one DE, one major browser, etc.<br />
<br />
There were users back then that didn't like Judd's selection, so since the [[Arch Build System]] is so easy to use, they created packages of their own. These packages went into a repository called ''[unofficial]'', and were maintained by developers other than Judd. Eventually, the two repositories were both considered equally supported by the developers, so the names [official] and [unofficial] no longer reflected their true purpose. They were subsequently renamed to ''[current]'' and ''[extra]'' sometime near the release version 0.5.<br />
<br />
Shortly after the 2007.8.1 release, [current] was renamed [core] in order to prevent confusion over what exactly it contains. The repositories are now more or less equal in the eyes of the developers and the community, but [core] does have some differences. The main distinction is that packages used for Installation CDs and release snapshots are taken only from [core]. This repository still gives a complete Linux system, though it may not be the Linux system you want.<br />
<br />
Now, sometime around 0.5 or 0.6, they found there were a lot of packages that the developers didn't want to maintain. One of the developers (Xentac) set up the "Trusted User Repositories", which were unofficial repositories in which trusted users could place packages they had created. There was a ''[staging]'' repository where packages could be promoted into the official repositories by one of the Arch Linux developers, but other than this, the developers and trusted users were more or less distinct.<br />
<br />
This worked for a while, but not when trusted users got bored with their repositories, and not when untrusted users wanted to share their own packages. This led to the development of the [http://aur.archlinux.org/ AUR]. The TUs were conglomerated into a more closely knit group, and they now collectively maintain the '''[community]''' repository. The Trusted Users are still a separate group from the Arch Linux developers, and there isn't a lot of communication between them. However, popular packages are still promoted from [community] to '''[extra]''' on occasion. The [http://aur.archlinux.org/ AUR] also supports allowing untrusted users to submit PKGBUILDs for other users to use if they wish. These packages are unsupported, and the packages are sometimes called the '''[unsupported]''' repository, though since no binary packages are distributed, unsupported isn't really a repository. Trusted users can adopt packages from unsupported into [community] at their discretion, whether it is because the package is popular or because they are interested in maintaining it.<br />
<br />
= List of repositories =<br />
<br />
== [core] ==<br />
<br />
The [core] repository can be found in ''core/os/i686'' or ''core/os/x86_64'' on your favorite mirror. It contains Arch core packages and some additional software, and will provide you with a fully functional base system.<br />
<br />
''The installation cd simply contains an installer script, and a snapshot of the core repository.''<br />
<br />
== [extra] ==<br />
<br />
The [extra] repository can be found in ''extra/os/i686'' or ''extra/os/x86_64'' on your favorite mirror. It contains all packages that don't fit in [core]<br><br />
Example: X.org, window managers, web servers, media players, languages like Python, Ruby and Perl, and a lot more.<br />
<br />
== [community] ==<br />
<br />
The [community] repository can be found in ''community/os/i686'' or ''community/os/x86_64'' on your favorite mirror. It is maintained by the ''Trusted Users (TUs)'' and is part of the ''Arch User Repository (AUR)''. It contains packages from the ''AUR'' that have enough votes and were adopted by a ''TU''.<br />
<br />
== [testing] ==<br />
<br />
The [testing] repository can be found in ''testing/os/i686'' on your favorite mirror. [testing] is special because it contains packages that are candidates for the [core] or [extra] repositories. New packages go into [testing] if:<br />
* they are expected to break something on update and need to be tested first<br />
* they require other packages to be rebuilt. In this case, all packages that need to be rebuilt are put into [testing] first and when all rebuilds are done, they are moved back to the other repositories.<br />
<br />
[testing] is the only repository that can have name collisions with any of the other official repositories. If enabled, it has to be the first repo listed in your ''pacman.conf'' file.<br />
<br />
Be careful when enabling [testing]. Your system may break after you perform an update with the [testing] repository enabled. Only experienced users who know how to deal with potential system breakage should use it.<br />
<br />
Users of the [testing] repository are strongly encouraged to subscribe to the arch-dev-public mailing list, and to report all bugs to the bug tracker.<br />
<br />
== [community-testing] ==<br />
<br />
The [community-testing] repository is like the [testing] repository but for packages that are candidates for the [community] repository.<br />
<br />
== AUR a.k.a. [unsupported] ==<br />
<br />
[[AUR]] or Arch User Repository is not really a repository at all. It refers to a database of user-submitted build scripts known as [[PKGBUILD]] files, thus this repository truly is unofficial. Users cannot download or install packages from [[AUR]] using [[pacman]]. They must download the [[PKGBUILD]] files and run [[makepkg]] which downloads the sources and builds packages. These locally build packages can then be installed using [[pacman]]. To automate this task, one of the popular [[AUR Helpers]] can be used.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Talk:PKGBUILD&diff=86361
Talk:PKGBUILD
2009-12-05T03:55:30Z
<p>Daenyth: Split packages?</p>
<hr />
<div>This needs to be updated for split packages. [[User:Daenyth|Daenyth]] 22:55, 4 December 2009 (EST)</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Official_repositories&diff=86340
Official repositories
2009-12-04T22:28:12Z
<p>Daenyth: /* AUR a.k.a. [unsupported] */ Minor wording clarification</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:About Arch (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Official Repositories}}<br />
{{i18n_entry|Türkçe|Resmi Depolar}}<br />
{{i18n_entry|Česky|Oficiální repozitáře (Česky)}}<br />
{{i18n_entry|Español|Repositorios Oficiales}}<br />
{{i18n_entry|Italiano|Official_Repositories_(Italiano)}}<br />
{{i18n_entry|简体中文|官方软件仓库}}<br />
{{i18n_entry|Português|Official Repositories (Português)}}<br />
{{i18n_entry|Nederlands|Officiële Repositories (Nederlands)}}<br />
{{i18n_entry|Français|Dépôts Officiels (Français)}}<br />
{{i18n_links_end}}<br />
<br />
''As there is much confusion about the official repositories, this article attempts to explain their meaning.''<br />
<br />
= Historical background =<br />
<br />
Most of the repository splits are for historical reasons. Originally, when Arch Linux was used by very few users, there was only one repository known as ''[official]'' (now '''[core]'''). At the time, [official] basically contained Judd Vinet's preferred applications. It was designed to contain one of each "type" of program -- one DE, one major browser, etc.<br />
<br />
There were users back then that didn't like Judd's selection, so since the [[Arch Build System]] is so easy to use, they created packages of their own. These packages went into a repository called ''[unofficial]'', and were maintained by developers other than Judd. Eventually, the two repositories were both considered equally supported by the developers, so the names [official] and [unofficial] no longer reflected their true purpose. They were subsequently renamed to ''[current]'' and ''[extra]'' sometime near the release version 0.5.<br />
<br />
Shortly after the 2007.8.1 release, [current] was renamed [core] in order to prevent confusion over what exactly it contains. The repositories are now more or less equal in the eyes of the developers and the community, but [core] does have some differences. The main distinction is that packages used for Installation CDs and release snapshots are taken only from [core]. This repository still gives a complete Linux system, though it may not be the Linux system you want.<br />
<br />
Now, sometime around 0.5 or 0.6, they found there were a lot of packages that the developers didn't want to maintain. One of the developers (Xentac) set up the "Trusted User Repositories", which were unofficial repositories in which trusted users could place packages they had created. There was a ''[staging]'' repository where packages could be promoted into the official repositories by one of the Arch Linux developers, but other than this, the developers and trusted users were more or less distinct.<br />
<br />
This worked for a while, but not when trusted users got bored with their repositories, and not when untrusted users wanted to share their own packages. This led to the development of the [http://aur.archlinux.org/ AUR]. The TUs were conglomerated into a more closely knit group, and they now collectively maintain the '''[community]''' repository. The Trusted Users are still a separate group from the Arch Linux developers, and there isn't a lot of communication between them. However, popular packages are still promoted from [community] to '''[extra]''' on occasion. The [http://aur.archlinux.org/ AUR] also supports allowing untrusted users to submit PKGBUILDs for other users to use if they wish. These packages are unsupported, and the packages are sometimes called the '''[unsupported]''' repository, though since no binary packages are distributed, unsupported isn't really a repository. Trusted users can adopt packages from unsupported into [community] at their discretion, whether it is because the package is popular or because they are interested in maintaining it.<br />
<br />
= List of repositories =<br />
<br />
== [core] ==<br />
<br />
The [core] repository can be found in ''core/os/i686'' or ''core/os/x86_64'' on your favorite mirror. It contains Arch core packages and some additional software, and will provide you with a fully functional base system.<br />
<br />
''The installation cd simply contains an installer script, and a snapshot of the core repository.''<br />
<br />
== [extra] ==<br />
<br />
The [extra] repository can be found in ''extra/os/i686'' or ''extra/os/x86_64'' on your favorite mirror. It contains all packages that don't fit in [core]<br><br />
Example: X.org, window managers, web servers, media players, languages like Python, Ruby and Perl, and a lot more.<br />
<br />
== [community] ==<br />
<br />
The [community] repository can be found in ''community/os/i686'' or ''community/os/x86_64'' on your favorite mirror. It is maintained by the ''Trusted Users (TUs)'' and is part of the ''Arch User Repository (AUR)''. It contains packages from the ''AUR'' that have enough votes and were adopted by a ''TU''.<br />
<br />
== [testing] ==<br />
<br />
The [testing] repository can be found in ''testing/os/i686'' on your favorite mirror. [testing] is special because it contains packages that are candidates for the [core] or [extra] repositories. New packages go into [testing] if:<br />
* they are expected to break something on update and need to be tested first<br />
* they require other packages to be rebuilt. In this case, all packages that need to be rebuilt are put into [testing] first and when all rebuilds are done, they are moved back to the other repositories.<br />
<br />
[testing] is the only repository that can have name collisions with any of the other official repositories. If enabled, it has to be the first repo listed in your ''pacman.conf'' file.<br />
<br />
Be careful when enabling [testing]. Your system may break after you perform an update with the [testing] repository enabled. Only experienced users who know how to deal with potential system breakage should use it.<br />
<br />
== [community-testing] ==<br />
<br />
The [community-testing] repository is like the [testing] repository but for packages that are candidates for the [community] repository.<br />
<br />
== AUR a.k.a. [unsupported] ==<br />
<br />
[[AUR]] or Arch User Repository is not really a repository at all. It refers to a database of user-submitted build scripts known as [[PKGBUILD]] files, thus this repository truly is unofficial. Users cannot download or install packages from [[AUR]] using [[pacman]]. They must download the [[PKGBUILD]] files and run [[makepkg]] which downloads the sources and builds packages. These locally build packages can then be installed using [[pacman]]. To automate this task, one of the popular [[AUR Helpers]] can be used.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=RTorrent&diff=86314
RTorrent
2009-12-04T16:00:24Z
<p>Daenyth: /* Installing */</p>
<hr />
<div>[[Category:Internet and Email (English)]][[Category:Utilities (English)]][[Category:HOWTOs (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|RTorrent}}<br />
{{i18n_entry|Español|RTorrent - cliente de bittorrent en línea de órdenes (Español)}}<br />
{{i18n_entry|简体中文|RTorrent (简体中文)}}<br />
{{i18n_links_end}}<br />
<br />
[http://libtorrent.rakshasa.no/ rTorrent] is a very simple, elegant and ultra-light bittorent client. It is written in C++ and uses ncurses, so it is completely text based and runs entirely in a console. rTorrent is ideal for low-end systems and with the addition of GNU Screen and openssh it is convenient as a remote bittorrent client.<br />
<br />
== Installing ==<br />
<br />
# pacman -S rtorrent<br />
<br />
You can also install {{Package AUR|rtorrent-svn}} from the [[AUR]].<br />
<br />
== Configuring ==<br />
<br />
Before running rTorrent, copy the default configuration file, which is available at the rTorrent [http://libtorrent.rakshasa.no/browser/trunk/rtorrent/doc/rtorrent.rc?format=raw project page], and save it as .rtorrent.rc in your home directory. <br />
<br />
Once the file has been saved, open it with your preferred text editor and make any necessary changes. Simply uncomment the options you wish to enable/utilize. For more detailed information on the options available, visit [http://libtorrent.rakshasa.no/wiki/RTorrentCommonTasks rTorrent Common Tasks]<br />
<br />
=== Recommended Configuration ===<br />
<br />
These values in the following are subjective and dependent upon your own system and Internet connection speed. To find the optimal settings for you to use, visit the following website and follow the instructions: [http://torrentfreak.com/optimize-your-BitTorrent-download-speed Optimize Your BitTorrent Download Speed]<br />
<br />
<pre><br />
# Maximum and minimum number of peers to connect to per torrent.<br />
#min_peers = 40<br />
max_peers = 52<br />
<br />
# Same as above but for seeding completed torrents (-1 = same as downloading)<br />
#min_peers_seed = 10<br />
max_peers_seed = 52<br />
<br />
# Maximum number of simultanious uploads per torrent.<br />
max_uploads = 8<br />
<br />
# Global upload and download rate in KiB. "0" for unlimited.<br />
download_rate = 200<br />
upload_rate = 28<br />
</pre><br />
<br />
The option below will determine where your torrent data will be saved. Change the default save directory to whatever is most convenient. Be sure to enter the absolute path; there is an odd bug with rTorrent ''sometimes'' does not respect relative paths (i.e. ~/torrents):<br />
<br />
<pre><br />
# Default directory to save the downloaded torrents.<br />
directory = /home/[user]/torrents/<br />
</pre><br />
<br />
This option will allow rTorrent to save the progess of your torrents. Be sure to create a directory called .session (simply run as normal user:''mkdir ~/.session''):<br />
<br />
<pre><br />
# Default session directory. Make sure you don't run multiple instance<br />
# of rtorrent using the same session directory. Perhaps using a<br />
# relative path?<br />
session = /home/[user]/.session/<br />
</pre><br />
<br />
The following option will have rTorrent "watch" a particular directory for new .torrent files. Be careful when using this option as rtorrent will move the torrent file to your session folder and rename it to it's hash value. Using your browser, when you find a .torrent file you would like to download, just save the file into this directory and rTorrent will automatically start the torrent. Be sure to create the directory that will be watched (simply run as normal user:''mkdir ~/watch''): <br />
<br />
<pre><br />
# Watch a directory for new torrents, and stop those that have been<br />
# deleted.<br />
#schedule = watch_directory,5,5,load_start=./watch/*.torrent<br />
#schedule = untied_directory,5,5,stop_untied=<br />
schedule = watch_directory,5,5,load_start=/home/[user]/watch/*.torrent<br />
schedule = untied_directory,5,5,stop_untied=<br />
schedule = tied_directory,5,5,start_tied=<br />
</pre><br />
<br />
The option below will stop rTorrent from downloading any further when disk space is low. This is particuarly useful with a [http://en.wikipedia.org/wiki/Seedbox Seedbox] where disk space is quite limited. Change the value as you like: <br />
<br />
<pre><br />
# Close torrents when diskspace is low.<br />
schedule = low_diskspace,5,60,close_low_diskspace=100M<br />
</pre><br />
<br />
This option will set what port to use for listening. It is recommended to use a port that is higher than 49152. rTorrent allows the use of a single port rather than a range; a single port rather than an actual range is recommended.<br />
<br />
<pre><br />
# Port range to use for listening.<br />
port_range = 49164-49164<br />
</pre><br />
<br />
The following option allow for a hash check whenever a torrent is complete or whenever rTorrent is restarted. This will make sure there are no errors with your acquired/seeding files. <br />
<br />
<pre><br />
# Check hash for finished torrents. Might be usefull until the bug is<br />
# fixed that causes lack of diskspace not to be properly reported.<br />
check_hash = yes<br />
</pre><br />
<br />
The following option allows for the enabling of encryption. This is very important to enable, if not for yourself, but for others in the torrent swarm; people might need to obscure their bandwidth usage from their ISP. Does not hurt you to enable even if you do not need such protection. More information: [http://en.wikipedia.org/wiki/BitTorrent_protocol_encryption Bittorrent Protocol Encryption]<br />
<br />
<pre><br />
# Encryption options, set to none (default) or any combination of the following:<br />
# allow_incoming, try_outgoing, require, require_RC4, enable_retry, prefer_plaintext<br />
#<br />
# The example value allows incoming encrypted connections, starts unencrypted<br />
# outgoing connections but retries with encryption if they fail, preferring<br />
# plaintext to RC4 encryption after the encrypted handshake<br />
#<br />
# encryption = allow_incoming,enable_retry,prefer_plaintext<br />
encryption = allow_incoming,try_outgoing,enable_retry<br />
</pre><br />
<br />
The following is for DHT support. If you use public trackers, you'll want to enable DHT to acquire more peers. If you use only private trackers, '''do not enable DHT''' as this will reduce your speeds and can create a privacy risk. Some private trackers will even warn you if you use DHT. <br />
<br />
<pre><br />
# Enable DHT support for trackerless torrents or when all trackers are down.<br />
# May be set to "disable" (completely disable DHT), "off" (do not start DHT),<br />
# "auto" (start and stop DHT as needed), or "on" (start DHT immediately).<br />
# The default is "off". For DHT to work, a session directory must be defined.<br />
# <br />
# dht = auto<br />
<br />
# UDP port to use for DHT. <br />
# <br />
# dht_port = 6881<br />
<br />
# Enable peer exchange (for torrents not marked private)<br />
#<br />
# peer_exchange = yes<br />
</pre><br />
<br />
Be sure to forward the proper port(s) with your router if you use one. A decent guide per router make/model can be found [http://portforward.com/english/routers/port_forwarding/routerindex.htm here].<br />
<br />
== Pre-allocation ==<br />
<br />
One could recompile ''libtorrent'' from '''ABS''' with a new switch to configure pre-allocation:<br />
./configure --prefix=/usr --disable-debug --with-posix-fallocate|| return 1<br />
<br />
It will pre-allocate files before downloading the torrent but this has its pros and cons:<br />
=== Pros ===<br />
This limits/avoids ''fragmentation'' of the filesystem<br />
<br />
=== Cons ===<br />
This introduces a delay during the pre-allocation '''if''' the filesystem does not support natively the ''fallocate syscall''.<br />
<br />
So i recommend its use for users of ''xfs'' and ''ext4'' and ''btrfs'' which have native fallocate syscall. They will see no delay during preallocation and no fragmented filesystem. Others filesystems will cause delay at pre-allocation time but no fragmented file.<br />
<br />
== Controls ==<br />
<br />
rTorrent relies exclusively on keyboard shortcuts for user input.<br />
A complete guide is available on the main site: [http://libtorrent.rakshasa.no/wiki/RTorrentUserGuide rTorrent User Guide]<br />
<br />
Here are the basics for quick reference:<br />
<br />
*Control-q : closes rTorrent, done twice makes the program shutdown without waiting to send stopping information to the trackers.<br />
*Left arrow : returns to the previous screen.<br />
*Right arrow : goes to the next screen.<br />
*a|s|d : increase global upload throttle about 1|5|50 KB/s<br />
*A|S|D : increase global download throttle about 1|5|50 KB/s<br />
*z|x|c : decrease global upload throttle about 1|5|50 KB/s<br />
*Z|X|C : decrease global download throttle about 1|5|50 KB/s<br />
*Control-S : starts download<br />
*Control-D : stops an active download, removes a stopped download.<br />
*+ or - : changes the download priority of selected torrent.<br />
*Backspace : adds the specified .torrent. After pressing this button write full path or URL of .torrent file. You can use Tab and other tricks from bash.<br />
<br />
== Use rTorrent with Screen ==<br />
<br />
Screen is a program that will allow CLI applications to be run in the background and without X running. <br />
<br />
Install screen:<br />
<br />
# pacman -S screen<br />
<br />
and then copy screenrc to your home directory as normal user:<br />
<br />
$ cp /etc/screenrc ~/.screenrc<br />
<br />
To have rTorrent always start with screen, add the following to your .screenrc file:<br />
<br />
$ screen -t rtorrent rtorrent <br />
<br />
To start screen + rTorrent, simply run ''screen'' from a terminal. Control-a followed by d will detach screen, and running ''screen -r'' will open screen again.<br />
<br />
===On a remote machine===<br />
Most setups of rTorrent on a remote machine involve using Screen. Supposing you have a detached Screen session with rtorrent on the remote machine (and the option to [[SSH]] into it), you can gain access to it using:<br />
<pre>/usr/bin/ssh -t -p <ssh port on remote machine> <user>@<remote machine> screen -RD</pre><br />
If you want immediate access on startup, you will need to [http://bloggerdigest.blogspot.com/2006/11/ssh-auto-login-or-passwordless-login.html upload a key] from your machine to remote host (so you will not be prompted for a password) and setup a terminal to run the command above. An inittab example using [http://aur.archlinux.org/packages.php?ID=19631 rungetty] on virtual console 4:<br />
<pre>sam:45:respawn:/sbin/rungetty tty4 -u <local user> -- /usr/bin/ssh -t -p <ssh port on remote machine> <remote user>@<remote machine> screen -RD</pre><br />
<br />
===rtorrent Daemon with screen===<br />
<br />
I use this on my home server to run rtorrent w/ screen as a daemon. With the username ''rtorrent''<br />
Just create an ''rtorrent'' file in your ''/etc/rc.d/'' and add the following code.<br />
<br />
<pre><br />
#!/bin/bash<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
case "$1" in<br />
start)<br />
stat_busy "Starting rtorrent"<br />
su rtorrent -c 'screen -d -m rtorrent' &> /dev/null<br />
if [ $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
add_daemon rtorrent<br />
stat_done<br />
fi<br />
;;<br />
stop)<br />
stat_busy "Stopping rtorrent"<br />
killall -w -s 2 /usr/bin/rtorrent &> /dev/null<br />
if [ $? -gt 0 ]; then<br />
stat_fail<br />
else<br />
rm_daemon rtorrent<br />
stat_done<br />
fi<br />
;;<br />
restart)<br />
$0 stop<br />
sleep 1<br />
$0 start<br />
;;<br />
*)<br />
echo "usage: $0 {start|stop|restart}"<br />
esac<br />
exit 0<br />
</pre><br />
<br />
On a remote computer I use the following script to connect to the server's daemon process:<br />
<br />
<pre><br />
ssh -t rtorrent@192.168.1.10 'screen -r'<br />
</pre><br />
<br />
== Additional Tips ==<br />
<br />
*To use rTorrent with a tracker that uses https, do the following as root:<br />
<br />
<pre><br />
cd /etc/ssl/certs<br />
wget --no-check-certificate https://www.geotrust.com/resources/root_certificates/certificates/Equifax_Secure_Global_eBusiness_CA-1.cer<br />
mv Equifax_Secure_Global_eBusiness_CA-1.cer Equifax_Secure_Global_eBusiness_CA-1.pem<br />
c_rehash<br />
</pre><br />
<br />
And from now on run rTorrent with:<br />
<br />
<pre><br />
rtorrent -o http_capath=/etc/ssl/certs<br />
</pre><br />
<br />
Be sure to change .screenrc to reflect this change if you use screen:<br />
<br />
<pre><br />
screen -t rtorrent rtorrent -o http_capath=/etc/ssl/certs<br />
</pre><br />
<br />
<br />
*To create .torrent files, I recommend [http://aur.archlinux.org/packages.php?do_Details=1&ID=10635&O=0&L=0&C=0&K=mktorrent&SB=n&SO=a&PP=25&do_MyPackages=0&do_Orphans=0&SeB=nd mktorrent] for commandline interface or [http://benclarke.ca/rubytorrent/ RubyTorrent] for GUI. <br />
<br />
<br />
===Send Text Message Upon Torrent Completion Using GMail===<br />
<br />
Cell phone providers allow you to "email" your phone:<br />
<pre><br />
Verizon: 10digitphonenumber@vtext.com<br />
AT&T: 10digitphonenumber@txt.att.net<br />
Former AT&T customers: 10digitphonenumber@mmode.com<br />
Sprint: 10digitphonenumber@messaging.sprintpcs.com<br />
T-Mobile: 10digitphonenumber@tmomail.net<br />
Nextel: 10digitphonenumber@messaging.nextel.com<br />
Cingular: 10digitphonenumber@cingularme.com<br />
Virgin Mobile: 10digitphonenumber@vmobl.com<br />
Alltel: 10digitphonenumber@alltelmessage.com OR<br />
10digitphonenumber@message.alltel.com<br />
CellularOne: 10digitphonenumber@mobile.celloneusa.com<br />
Omnipoint: 10digitphonenumber@omnipointpcs.com<br />
Qwest: 10digitphonenumber@qwestmp.com<br />
</pre><br />
If you have Verizon, your cell phone's "email" is 5551234567@vtext.com<br />
<br />
*Install '''Heirloom's mailx''' program:<br />
<pre><br />
pacman -Sy mailx-heirloom<br />
</pre><br />
<br />
*Clear the /etc/nail.rc file and enter:<br />
<pre><br />
set smtp=smtp.gmail.com:587<br />
set smtp-use-starttls<br />
set ssl-verify=ignore<br />
set ssl-auth=login<br />
set smtp-auth-user=USERNAME@gmail.com<br />
set smtp-auth-password=PASSWORD<br />
</pre><br />
<br />
Now to send the text, we must pipe a message to the mailx program.<br />
*Make a bash script (/path/to/mail.sh):<br />
<pre><br />
echo "$@: Done" | mailx 5551234567@vtext.com<br />
</pre><br />
Where the $@ is a variable holding all the arguments passed to our script.<br />
<br />
*And finally, add the important ~/.rtorrent.rc line:<br />
<pre><br />
system.method.set_key = event.download.finished,notify_me,"execute=/path/to/mail.sh,$d.get_name="<br />
</pre><br />
Breaking it down:<br />
<br />
<code>notify_me</code> is the command id, which may be used by other commands, it can be just about anything you like, so long as it is unique.<br><br />
<br />
<code>execute=</code> is the rtorrent command, in this case to execute a shell command.<br><br />
<br />
<code>/path/to/mail.sh</code> is the name of our script (or whatever command you want to execute) followed by a comma separated list of all the switches/arguments to be passed.<br><br />
<br />
<code>$d.get_name=</code> 'd' is an alias to whatever download triggered the command, get_name is a function which returns the name of our download, and the '$' tells rtorrent to replace the command with its output before it calls execute.<br><br />
<br />
The end result? When that torrent, 'All Live Nudibranches', that we started before leaving for work finishes, we'll be texted:<br />
<pre>All Live Nudibranches: Done</pre><br />
<br />
=== See Also ===<br />
<br />
[[Screen Tips]]<br />
<br />
A Detailed Intro to Bittorrent including definition of terms [http://www.dessent.net/btfaq/#terms terms]<br />
<br />
== Web GUI Clients for RTorrent ==<br />
* [[WTorrent]] a web interface to rtorrent programmed in php using Smarty templates and XMLRPC for PHP library.<br />
* [http://code.google.com/p/ntorrent/ nTorrent] A graphical user interface client to rtorrent (a cli torrent client) written in java.<br />
* [http://projects.cyla.homeip.net/rtwi/ rTWi] a simple rTorrent web interface written in PHP.<br />
* [http://code.google.com/p/rtgui/ rtGui] a web based front end for rTorrent written in PHP and uses XML-RPC to communicate with the rTorrent client.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Gaming&diff=86222
Gaming
2009-12-03T21:26:03Z
<p>Daenyth: /* Getting games */ link</p>
<hr />
<div>==Running games in Arch==<br />
<br />
For the most part, games will work right out of the box in Arch Linux with possibly better performance than on other distributions due to compile time optimizations. However, some special setups may require a bit of configuration or scripting to make games run as smoothly as desired. For instance, running a multi-screen setup may lead to problems with fullscreen games. In such a case, running a second X server is one possible solution. <br />
<br />
==Getting games==<br />
<br />
While a lot of games can currently be found in the official repositories, not all current Linux games are packaged there. Some of them can only be found on [[AUR]]. However, there is a dedicated [http://arch-games.twilightlair.net/projects/show/gaming-repo Arch Linux gaming repository] that addresses this by providing pre-compiled packages from AUR. <br />
<br />
===Arch Linux gaming repository===<br />
<br />
To make use of the gaming repo, add these to your pacman.conf:<br />
[arch-games]<br />
# The Arch Linux Gaming repository project<br />
Server = http://arch.twilightlair.net/games/i686<br />
Server = http://pseudoform.org/arch-games/games/i686<br />
Don't forget to change the arch at the end to x86_64 if applicable.<br />
<br />
===Starting games in a seperate X server===<br />
<br />
In some cases like those mentioned above, it may be necessary or desired to run a second X server. Running a second X server has multiple advantages such as better performance, the ability to "tab" our of your game by using CTRL-ALT-F7 / CTRL-ALT-F8, no crashing your primary X seession (which may have open work) in case a game conflicts with the graphics driver. To start a second X server (using Nexuiz as an example) you can simply do: <br />
xinit /usr/bin/nexuiz-glx -- :1<br />
This can further be spiced up by using a seperate X configuration file:<br />
xinit /usr/bin/nexuiz-glx -- :1 -xf86config xorg-game.conf <br />
A good reason to provide an alternative xorg.conf here may be that your primary configuration makes use of NVIDIA's Twinview which would render your 3D games like Nexuiz in the middle of your multiscreen setup, spanned across all screens. This is undedisrable, thus starting a second X with an alternative config where the second screen is disabled is advised.<br />
<br />
A game starting script making use of Openbox for your home directory or /usr/local/bin may look like this:<br />
$ cat ~/game.sh<br />
if [ $# -ge 1 ]; then<br />
game="`which $1`"<br />
openbox="`which openbox`"<br />
tmpgame="/tmp/tmpgame.sh"<br />
DISPLAY=:1.0<br />
echo -e "${openbox} &\n${game}" > ${tmpgame}<br />
echo "starting ${game}"<br />
xinit ${tmpgame} -- :1 -xf86config xorg-game.conf || exit 1<br />
else<br />
echo "not a valid argument"<br />
fi<br />
<br />
So after a chmod +x you would be able to use this script like:<br />
$ ~/game.sh nexuiz-glx<br />
<br />
==See also==<br />
* [[Games]]<br />
* [[Xorg]]<br />
* [[NVIDIA#Gaming_using_Twinview]]</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Beginners%27_guide_old&diff=86220
Beginners' guide old
2009-12-03T21:15:17Z
<p>Daenyth: /* LOCALIZATION section */ {{Filename}} {{Codeline}}</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]][[Category:About Arch (English)]]<br />
[[Category:HOWTOs (English)]][[Category:Accessibility (English)]]<br />
{{Article summary start}}<br />
{{Article summary text|Provides a highly detailed, explanatory guide to installing, configuring and using a full-featured Arch Linux system.}}<br />
{{Article summary heading|Languages}}<br />
{{i18n_entry|Česky|Průvodce začátečníka (Česky)}}<br />
{{i18n_entry|简体中文|Arch 新手安装指南 (简体中文)}}<br />
{{i18n_entry|正體中文|Beginner's Guide 新手指南}}<br />
{{i18n_entry|Dansk|Dansk_Begynderguide}}<br />
{{i18n_entry|Deutsch|Beginners Guide (Deutsch)}}<br />
{{i18n_entry|English|Beginners Guide}}<br />
{{i18n_entry|Español|Guía para Principiantes (Español)}}<br />
{{i18n_entry|Français|Manuel_du_Débutant_(Français)}}<br />
{{i18n_entry|Italiano|Beginners Guide (Italiano)}}<br />
{{i18n_entry|Indonesia|Beginners_Guide_(Indonesia)}}<br />
{{i18n_entry|Lietuviškai|Pradedančiųjų gidas (Lietuviškai)}}<br />
{{i18n_entry|Nederlands|Beginners_Guide_(Nederlands)}}<br />
{{i18n_entry|Português Brasil|Guia do Iniciante(Português do Brasil)}}<br />
{{i18n_entry|Português|Guia para Principiantes(Português)}}<br />
{{i18n_entry|Русский|Руководство_для_новичков}}<br />
{{i18n_entry|Türkçe|Başlangıç Rehberi (Türkçe)}}<br />
{{i18n_entry|हिन्दी|नौसिखिया गाइड(हिन्दी)}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Official Arch Linux Install Guide}} (for a more general approach)<br />
{{Article summary wiki|Beginners' Guide Appendix}}<br />
{{Article summary wiki|Post Installation Tips}}<br />
{{Article summary end}}<br />
[http://wiki.archlinux.org/index.php/Category:Accessibility_(English) Accessibility resources available]<!-- Making this a note brakes the format --><br />
==Preface==<br />
=====Everything you ever wanted to know about Arch, but were afraid to ask=====<br />
Welcome. This document will guide you through the process of installing and configuring [[Arch Linux]]; a simple, agile and lightweight GNU/Linux distribution, and <tt>UNIX</tt>-like operating system targeted at competent users. <br />
* Arch Linux requires a certain level of intimate knowledge of its configuration process and of <tt>UNIX</tt>-like system methodology, and for this reason, extra explanatory information is included. <br />
* This guide is aimed at new Arch users, but strives to serve as a strong reference and informative base for all.<br />
<br />
'''Arch Linux distribution highlights:'''<br />
* '''[[The Arch Way | Simple]]''', <tt>UNIX</tt>-like design and philosophy<br />
* Independently Developed Community distro built from scratch and targeted at competent GNU/Linux users<br />
* All packages compiled for '''i686/x86-64'''<br />
* Highly customizable system assembled by the user from the ground up<br />
* '''[[The Arch boot process | BSD-style init]]''' scripts, featuring one centralized configuration file<br />
* '''mkinitcpio''': a simple and dynamic initramfs creator <br />
* '''Rolling Release''' model<br />
* '''[[Pacman]]''' package manager: is written in '''C''', and is fast, lightweight and agile, with a very modest memory footprint<br />
* '''[[ABS]]''': The '''A'''rch '''B'''uild '''S'''ystem, a ports-like package building system, makes it simple to create your own easily-installable Arch packages from source, to use and/or share with the community on the [[AUR]]<br />
* '''[[AUR]]''': The Arch User Repository, offering many thousands of build scripts for Arch from user-provided software packages<br />
<br />
=====License=====<br />
<br />
Arch Linux, pacman, documentation, and scripts are copyright<br />
©2002-2007 by Judd Vinet, ©2007-2009 by Aaron Griffin and are licensed under the GNU General Public License Version 2.<br />
<br />
=====DON'T PANIC !=====<br />
The Arch Linux system is assembled by the ''user'', from the shell, using basic command line tools. This is '''[[The Arch Way]].''' Unlike the more rigid structures of other distributions and installers, there are no default environments nor configurations chosen for you. From the command line, ''you'' will add packages from the Arch repositories using the [[pacman]] tool via your internet connection and manually configure your installation by editing text files until your system is customized to your requirements. You will also manually add non-root user(s) and manage groups and permissions. This method allows for maximum flexibility, choice, and system resource control ''from the base up''.<br />
<br />
Arch Linux is a distribution aimed at competent GNU/Linux users who desire a 'do-it-yourself' approach.<br />
<br />
=====[[The Arch Way]]=====<br />
<br />
'''''The design principles behind Arch are aimed at keeping it [[The Arch Way|simple]].'' '''<br />
<br />
'Simple', in this context, shall mean 'without unnecessary additions, modifications, or complications'. In short; an elegant, minimalist approach.<br />
<br />
'''Some thoughts to keep in mind as you consider simplicity:'''<br />
<br />
*''&quot; 'Simple' is defined from a technical standpoint, not a usability standpoint. It is better to be technically elegant with a higher learning curve, than to be easy to use and technically [inferior].&quot; -Aaron Griffin''<br />
*''Entia non sunt multiplicanda praeter necessitatem'' or &quot;Entities should not be multiplied unnecessarily.&quot; -Occam's razor. The term ''razor'' refers to the act of shaving away unnecessary complications to arrive at the simplest explanation, method or theory.<br />
*''&quot;The extraordinary part of [my method] lies in its simplicity..The height of cultivation always runs to simplicity.&quot;'' - Bruce Lee<br />
<br />
=====About This Guide=====<br />
<br />
The Arch wiki is an excellent resource and should be consulted for issues [http://wiki.archlinux.org/index.php/Main_Page first]. IRC (freenode #archlinux), and the [http://bbs.archlinux.org/ forums] are also available if the answer cannot be found elsewhere.<br />
<br />
{{Note|Following this guide closely is essential in order to successfully install a properly configured Arch Linux system, so ''please'' read it thoroughly. It is strongly recommended you read each section completely <u>before</u> carrying out the tasks contained.}}<br />
<br />
Since GNU/Linux Distributions are fundamentally 'modular' by design, the guide is logically divided into 4 main components of a desktop <tt>UNIX</tt>-like operating system: <br />
<br />
'''[[#Part I: Install the Base System|Part I: Installing the Base system]]'''<br />
<br />
'''[[#Part II: Configure & Update the New Arch Linux base system|Part II: Configure & Update the New Arch Linux base system]]'''<br />
<br />
'''[[#Part III: Install X and configure ALSA|Part III: Installing X and configuring ALSA]]'''<br />
<br />
'''[[#Part IV: Installing and configuring a Desktop Environment|Part IV: Installing a Desktop Environment]]'''<br />
<br />
<br />
'''''Welcome to Arch!'''''<br />
:'''''Enjoy the installation; take your time and have fun!'''''<br />
<br />
'''''Now, let's get started....'''''<br />
<br />
<br><br />
<br />
==Part I: Install the Base System==<br />
<br />
===Step 1: Obtain the latest Installation media ===<br />
<br />
You can obtain Arch's official installation media from [http://archlinux.org/download/ here]. The latest version is 2009.08 <br />
<br />
*Both the Core and the Netinstall images provide only the necessary packages to create an '''Arch Linux base system'''. ''Note that the Base System does not include a GUI. It is mainly comprised of the GNU toolchain (compiler, assembler, linker, libraries, shell, and utilities), the Linux kernel, and a few extra libraries and modules.''<br />
*Core images facilitate both installing from CD and Net. <br />
*Netinstall images are smaller and provide no packages themselves; the entire system is retrieved via internet.<br />
*The isolinux images are provided for people who experience trouble using the grub version. There are no other differences.<br />
* [[Arch64_FAQ|The Arch64 FAQ]] can help you choose between the 32- and 64-bit versions.<br />
<br />
====CD installer====<br />
Burn the .iso image file to a CD with your preferred CD burner drive and software, and continue with [[#Step 2: Boot Arch Linux Installer | Step 2: Boot Arch Linux Installer]]<br />
{{Note| The quality of optical drives, as well as the CD media itself, vary greatly. Generally, using a slow burn speed is recommended for reliable burns; Some users recommend speeds '''''as low as 4x or 2x.''''' If you are experiencing unexpected behavior from the CD, try burning at the minimum speed supported by your system. }}<br />
<br />
====USB stick====<br />
{{Warning|This will irrevocably destroy all data on your USB stick!}}<br />
<br />
'''<tt>UNIX</tt> Method:'''<br />
<br />
Insert an empty or expendable USB stick, determine its path, and write the .img to the USB stick with the <code>/bin/dd</code> program:<br />
dd if=archlinux-2009.08-''{core|netinstall}''-''{i686|x86_64}''.img of=/dev/sd''x''<br />
where <code>if=</code> is the path to the img file and <code>of=</code> is your USB device. Make sure to use {{Filename|/dev/sd'''x'''}} and not {{Filename|/dev/sd'''x1'''}}.<br />
<br />
'''Check md5sum (optional):'''<br />
<br />
Make a note of the number of records (blocks) read in and written out, then perform the following check:<br />
dd if=/dev/sd''x'' count=''number_of_records'' status=noxfer | md5sum<br />
The md5sum returned should match the md5sum of the downloaded archlinux image file; they both should match the md5sum of the image as listed in the md5sums file in the mirror distribution site.<br />
<br />
'''Windows Method:'''<br />
<br />
Download Disk Imager from https://launchpad.net/win32-image-writer/+download. Insert flash media. Start the Disk Imager and select the image file. Select the Drive letter associated with the flash drive. Click "write".<br />
<br />
Continue with [[#Step 2: Boot Arch Linux Installer | Step 2: Boot Arch Linux Installer]]<br />
<br />
===Step 2: Boot Arch Linux Installer===<br />
Insert the CD or USB stick and boot from it. You may have to<br />
change the boot order in your computer BIOS or press a key (usually DEL, F1, F2, F11 or F12) during the BIOS POST (Power On Self-Test) phase.<br />
<br />
{{Tip|The memory requirements for a basic install are:<br />
* Core : 128 MB RAM x86_64/i686 (all packages selected, with swap partition)<br />
* Netinstall : 128 MB RAM x86_64/i686 (all packages selected, with swap partition)}}<br />
<br />
The main menu should be displayed at this point. Select the preferred choice by using the arrow keys to highlight your choice, and then by pressing Enter.<br />
<br />
Usually, the first item, Boot Archlive, is the preferred selection. However, choose Boot Archlive [legacy IDE] if you have trouble with libata/PATA, or have no SATA (Serial ATA) drives.<br />
<br />
To change GRUB boot options, press '''e'''. Many users may wish to change the resolution of the framebuffer, for more readable console output. Append:<br />
vga=773<br />
to the kernel line, followed by <ENTER>, for a 1024x768 framebuffer. When done, press '''b''' to boot into that selection.<br />
<br />
The system will now boot and present a login prompt. Login as 'root', without the quotes.<br />
<br />
If your system has errors trying to boot from the live CD or there are other '''hardware''' errors, refer to the [[Installation Troubleshooting]] wiki page.<br />
<br />
====Changing the keymap====<br />
If you have a non-US keyboard layout you can interactively choose your keymap/console font with the command:<br />
# km<br />
or use the loadkeys command:<br />
# loadkeys ''layout''<br />
(replace ''layout'' with your keyboard layout such as &quot;<code>fr</code>&quot; or &quot;<code>be-latin1</code>&quot;)<br />
<br />
====Documentation====<br />
The official install guide is conveniently available right on the live system! To access it, change to vc/2 (virtual console #2) with <ALT>+F2, and then invoke <code>/usr/bin/less</code> by typing in the following at the # prompt:<br />
# less /arch/docs/official_installation_guide_en<br />
<code>less</code> will allow you to page through the document. Change back to vc/1 with <ALT>+F1 to follow the rest of the install process.<br />
<br />
Change back to vc/2 at any time if you need to reference the Official Guide as you go thru the installation process.<br />
<br />
{{tip|Please note that the official guide only covers installation and configuration of the base system. Once that is installed, it is strongly recommended that you come back here to the wiki to find out more about post-installation considerations and other related issues.}}<br />
<br />
===Step 3: Start the Installation===<br />
As root, run the installer script from vc/1:<br />
# /arch/setup<br />
<br />
===A: Select an installation source===<br />
After a welcome screen, you will be prompted for an installation source. Choose the appropriate source for the installer you are using.<br />
* If you chose the CORE installer, continue below with [[#B: Set Clock|B: Set Clock]].<br />
* Netinstall only: You shall be prompted to load ethernet drivers manually, if desired. Udev is quite effective at loading the required modules, so you may assume it has already done so. You may verify this by invoking ifconfig -a from vc/3. (Select OK to continue.)<br />
<br />
====Configure Network (Netinstall)====<br />
Available Interfaces will be presented. If an interface and HWaddr ('''H'''ard'''W'''are '''addr'''ess) is listed, then your module has already been loaded. If your interface is not listed, you may probe it from the installer, or manually do so from another virtual console.<br />
<br />
The following screen will prompt you to ''Select the interface, Probe,'' or ''Cancel''. Choose the appropriate interface and continue.<br />
<br />
The installer will then ask if you wish to use DHCP. Choosing Yes will run '''dhcpcd''' to discover an available gateway and request an IP address; Choosing No will prompt you for your static IP, netmask, broadcast, gateway DNS IP, HTTP proxy, and FTP proxy. Lastly, you will be presented with an overview to ensure your entries are correct.<br />
<br />
=====(A)DSL Quickstart for the Live Environment (If you have a pure modem (or router in bridge mode) to connect to your ISP) =====<br />
<br />
Switch to another virtual console (<Alt> + F2), login as root and invoke <br />
# pppoe-setup<br />
If everything is well configured in the end you can connect to your ISP with <br />
# pppoe-start<br />
<br />
Return to first virtual console with <ALT>+F1. Continue with [[#B: Set Clock|B: Set Clock]]<br />
<br />
=====Wireless Quickstart For the Live Environment (If you need wireless connectivity during the installation process)=====<br />
<br />
The wireless drivers and utilities are now available to you in the live environment of the installation media. A good knowledge of your wireless hardware will be of key importance to successful configuration. Note that the following quickstart procedure ''executed at this point in the installation'' will initialize your wireless hardware for use ''in the live environment''. These steps (or some other form of wireless management) must be repeated from the actual installed system after booting into it. <br />
<br />
Also note that these steps are optional if wireless connectivity is unnecessary at this point in the installation; wireless functionality may always be established later.<br />
<br />
The basic procedure will be:<br />
* Switch to a free virtual console, e.g.: <ALT>+F3<br />
* (Optional) Identify the wireless interface and driver module:<br />
# lsmod | grep -i net<br />
* Ensure udev has loaded the driver, and that the driver has created a usable wireless kernel interface with <code>/usr/sbin/iwconfig</code>:<br />
# iwconfig<br />
Example output:<br />
lo no wireless extensions.<br />
eth0 no wireless extensions.<br />
wlan0 unassociated ESSID:""<br />
Mode:Managed Channel=0 Access Point: Not-Associated <br />
Bit Rate:0 kb/s Tx-Power=20 dBm Sensitivity=8/0 <br />
Retry limit:7 RTS thr:off Fragment thr:off<br />
Power Management:off<br />
Link Quality:0 Signal level:0 Noise level:0<br />
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0<br />
Tx excessive retries:0 Invalid misc:0 Missed beacon:0<br />
<code>wlan0</code> is the available wireless interface in the example.<br />
* Bring the interface up with <code>/sbin/ifconfig <interface> up</code>.<br />
An example using the wlan0 interface:<br />
# ifconfig wlan0 up<br />
(Remember, your interface may be named something else, depending on your module (driver) and chipset: wlan0, eth1, etc.)<br />
* If the essid has been forgotten or is unknown, use <code>/sbin/iwlist <interface> scan</code> to scan for nearby networks.<br />
# iwlist wlan0 scan<br />
* Specify the id of the chosen wireless network with iwconfig <interface> essid &quot;<youressid>&quot; key <your_wep_key> (give the essid (the 'network name') of the network in quotes). <br />
* An example using WEP and a hexadecimal key:<br />
# iwconfig wlan0 essid &quot;linksys&quot; key 0241baf34c<br />
* An example using WEP and an ASCII passphrase:<br />
# iwconfig wlan0 essid "linksys" key s:pass1<br />
* An example using an unsecured network:<br />
# iwconfig wlan0 essid "linksys"<br />
* Request an IP address with <code>/sbin/dhcpcd <interface> </code>. e.g.:<br />
# dhcpcd wlan0<br />
* Ensure you can route using <code>/bin/ping</code>:<br />
# ping -c 3 www.google.com<br />
Done.<br />
* For connecting to a network using WPA, consult the [[WPA Supplicant]] article, and continue below.<br />
<br />
======Does the Wireless Chipset require Firmware?======<br />
A small percentage of wireless chipsets also require firmware, in addition to a corresponding driver. If unsure, invoke <code>/usr/bin/dmesg</code> to query the kernel log for a firmware request from the wireless chipset:<br />
# dmesg | grep firmware<br />
Example output from an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
{{Note | '''Wireless chipset firmware packages (for cards which require them) are pre-installed under /lib/firmware in the live environment, (on CD/USB stick) ''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!'' Package selection and installation is covered below. Ensure installation of both your wireless module and firmware during the package selection step! See [[Wireless Setup]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset. This is a very common error.'''}}<br />
<br />
After the initial Arch installation is complete, you may wish to refer to [[Wireless Setup]] to ensure a permanent configuration solution for your installed system.<br />
<br />
Return to vc/1 with <ALT>+F1. Continue with [[#B: Set Clock|B: Set Clock]]<br />
<br />
===B: Set Clock===<br />
* UTC - Choose UTC if running only <tt>UNIX</tt>-like operating system(s).<br />
<br />
* localtime - Choose local if multi-booting with a Microsoft Windows OS.<br />
<br />
===C: Prepare Hard Drive===<br />
<br />
{{Warning|Partitioning hard drives can destroy data. You are strongly cautioned and advised to backup your critical data if applicable.}}<br />
<br />
{{Note|Partitioning may be performed before initiating the Arch installation if desired, by utilizing [http://gparted.sourceforge.net/download.php GParted] or other available tools. If the installation drive has already been partitioned to the required specifications, continue with [[#Set Filesystem Mountpoints| Set Filesystem Mountpoints]]}}<br />
<br />
Verify current disk identities and layout by invoking <code>/sbin/fdisk</code> with the <code>-l</code> (lower-case L) switch.<br />
<br />
Open another virtual console (<ALT>+F3) and enter:<br />
# fdisk -l<br />
Take note of the disk(s)/partition(s) to utilize for the Arch installation.<br />
<br />
Switch back to the installation script with <ALT>+F1<br />
<br />
Select the first menu entry &quot;Prepare Hard Drive&quot;.<br />
* Option 1: Auto Prepare<br />
Auto-Prepare divides the disk into the following configuration:<br />
<br />
* ext2 /boot partition, default size 32MB. ''You will be prompted to modify the size to your requirement.''<br />
* swap partition, default size 256MB. ''You will be prompted to modify the size to your requirement.''<br />
* A Separate / and /home partition, (sizes can also be specified). Available filesystems include ext2, ext3, ext4, reiserfs, xfs and jfs, but note that ''both / and /home shall share the same fs type'' if choosing the Auto Prepare option.<br />
<br />
Be warned that Auto-prepare will completely erase the chosen hard drive. Read the <font color=&quot;red&quot;>warning</font> presented by the installer very carefully, and make sure the correct device is about to be partitioned.<br />
<br />
* Option 2: '''(Recommended)''' Partition Hard Drives (with cfdisk)<br />
<br />
This option will allow for the most robust and customized partitioning solution for your personal needs.<br />
<br />
''At this point, more advanced GNU/Linux users who are familiar and comfortable with manually partitioning may wish to skip down to '''[[#D: Select Packages|D: Select Packages]]''' below.''<br />
<br />
{{Note|If you are installing to a USB flash key, see "[[Installing Arch Linux on a USB key]]".}}<br />
<br />
====Partition Hard Drives====<br />
<br />
=====Partition Info=====<br />
<br />
Partitioning a hard disk drive defines specific areas (the partitions) within the disk, that will each appear and behave as a separate disk and upon which a filesystem may be created (formatted).<br />
*There are 3 types of disk partitions:<br />
#Primary<br />
#Extended<br />
#Logical<br />
'''Primary''' partitions can be bootable, and are limited to 4 partitions per disk or raid volume. If a partitioning scheme requires more than 4 partitions, an '''extended''' partition which will contain '''logical''' partitions will be required.<br />
<br />
Extended partitions are not usable by themselves; they are merely a &quot;container&quot; for logical partitions. If required, a hard disk shall contain only one extended partition; which shall then be sub-divided into logical partitions.<br />
<br />
When partitioning a disk, one can observe this numbering scheme by creating primary partitions sda1 through sda3 followed by creating an extended partition, sda4, and subsequently creating logical partition(s) within the extended partition; sda5, sda6, and so on.<br />
<br />
=====Swap Partition=====<br />
A swap partition is a place on the drive where virtual ram resides, allowing the kernel to easily use disk storage for data that does not fit into physical RAM.<br />
<br />
Historically, the general rule for swap partition size was 2x the amount of physical RAM. Over time, as computers have gained ever larger memory capacities, this rule has become increasingly deprecated. Generally, on machines with up to 512MB RAM, the 2x rule is usually quite sufficient. On machines with 1GB RAM, generally a 1x rule is adequate. If the installation machine provides gratuitous amounts of RAM (more than 1024 MB) it may be possible to completely forget a swap partition altogether, though this is not recommended (see note below). A 1 GB swap partition will be used in this example.<br />
{{Note|If using suspend-to-disk, (hibernate) a swap partition at least '''equal''' in size to the amount of physical RAM is required. Some Arch users even recommend oversizing it beyond the amount of physical RAM by 10-15%, to allow for possible bad sectors.}}<br />
<br />
=====Partition Scheme=====<br />
A disk partitioning scheme is a very personalized preference. Each user's choices will be unique to their own computing habits and requirements. If you would like to dual boot Arch Linux and a Windows operating systems please see [[Windows and Arch Dual Boot]].<br />
<br />
Filesystem candidates for separate partitions include:<br />
<br />
'''/''' (root) ''The root filesystem is the primary filesystem from which all other filesystems stem; the top of the hierarchy. All files and directories appear under the root directory &quot;/&quot;, 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. Therefore, certain directories under / are not themselves candidates for separate partitions. (See warning below).''<br />
<br />
'''/boot''' ''This directory contains 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. /boot is essential for booting, but is unique in that it may still be kept on its own separate partition (if required).''<br />
<br />
'''/home''' ''User data and user specific configuration files for applications are stored in each user's home directory in a file that starts with the '.' character (a &quot;dot file&quot;).''<br />
<br />
'''/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 update/upgrade. Any information that is host-specific or varies with time is stored elsewhere.''<br />
<br />
'''/tmp''' ''directory for programs that require temporary files''<br />
<br />
'''/var''' ''contains variable data; spool directories and files, administrative and logging data, pacman's cache, the ABS tree, etc.''<br />
{{Warning | Besides /boot, directories essential for booting are: ''''''/bin', '/dev', '/etc', '/lib', '/proc' and '/sbin'. Therefore, they must not reside on a separate partition from /.'''''}}<br />
'''''There are several advantages for using discrete filesystems, rather than combining all into one partition''''':<br />
<br />
* Security: Each filesystem may be configured in /etc/fstab as 'nosuid', 'nodev', 'noexec', 'readonly', etc.<br />
* Stability: A user, or malfunctioning program can completely fill a filesystem with garbage if they have write permissions for it. Critical programs, which reside on a different filesystem remain unaffected.<br />
* Speed: A filesystem which gets written to frequently may become somewhat fragmented. (An effective method of avoiding fragmentation is to ensure that each filesystem is never in danger of filling up completely.) Separate filesystems remain unaffected, and each can be defragmented separately as well.<br />
* Integrity: If one filesystem becomes corrupted, separate filesystems remain unaffected.<br />
* Versatility: Sharing data across several systems becomes more expedient when independent filesystems are used. Separate filesystem types may also be chosen based upon the nature of data and usage.<br />
In this example, we shall use separate partitions for /, /var, /home, and a swap partition.<br />
<br />
{{Note | /var contains many small files. This should be taken into consideration when choosing a filesystem type for it, (if creating its own separate partition).}}<br />
<br />
=====How big should my partitions be?=====<br />
This question is best answered based upon individual needs.<br />
You may wish to simply create '''one partition for root and one partition for swap or only one root partition without swap''' or refer to the following examples and consider these guidelines to provide a frame of reference:<br />
* The root filesystem (/) in the example will contain the /usr directory, which can become moderately large, depending upon how much software is installed. 15-20 GB should be sufficient for most users.<br />
<br />
* The /var filesystem will contain, among other data, the [[ABS]] tree and the pacman cache. Keeping cached packages is useful and versatile; it provides the ability to downgrade packages if needed. /var tends to grow in size; the pacman cache can grow large over long periods of time, but can be safely cleared if needed. If you are using an SSD, you may wish to locate your /var on an HDD and keep the / and /home partitions on your SSD to avoid needless read/writes to the SSD. 6-8 Gigs on a desktop system should be sufficient for /var. Servers tend to have extremely large /var filesystems.<br />
<br />
* The /home filesystem is typically where user data, downloads, and multimedia reside. On a desktop system, /home is typically the largest filesystem on the drive by a large margin. Remember that if you chose to reinstall Arch, all the data on your /home partition will be untouched (so long as you have a separate /home partition). <br />
<br />
* An extra 25% of space added to each filesystem will provide a cushion for unforeseen occurrence, expansion, and serve as a preventive against fragmentation.<br />
'''''From the guidelines above, the example system shall contain a ~15GB root (/) partition, ~7GB /var, 1GB swap, and a /home containing the remaining disk space.'''''<br />
<br />
=====Create Partition:cfdisk=====<br />
Start by creating the primary partition that will contain the '''root''', (/) filesystem.<br />
<br />
Choose '''N'''ew -> Primary and enter the desired size for root (/). Put the partition at the beginning of the disk.<br />
<br />
Also choose the '''T'''ype by designating it as '83 Linux'. The created / partition shall appear as sda1 in our example.<br />
<br />
Now create a primary partition for /var, designating it as '''T'''ype 83 Linux. The created /var partition shall appear as sda2<br />
<br />
Next, create a partition for swap. Select an appropriate size and specify the '''T'''ype as 82 (Linux swap / Solaris). The created swap partition shall appear as sda3.<br />
<br />
Lastly, create a partition for your /home directory. Choose another primary partition and set the desired size.<br />
<br />
Likewise, select the '''T'''ype as 83 Linux. The created /home partition shall appear as sda4.<br />
<br />
Example:<br />
<br />
Name Flags Part Type FS Type [Label] Size (MB)<br />
-------------------------------------------------------------------------<br />
sda1 Primary Linux 15440 #root<br />
sda2 Primary Linux 6256 #/var<br />
sda3 Primary Linux swap / Solaris 1024 #swap<br />
sda4 Primary Linux 140480 #/home<br />
<br />
Choose '''W'''rite and type ''''yes''''. Beware that this operation may destroy data on your disk. Choose '''Q'''uit to leave the partitioner.<br />
Choose Done to leave this menu and continue with &quot;Set Filesystem Mountpoints&quot;.<br />
<br />
{{Note | Since the latest developments of the Linux kernel which include the libata and PATA modules, all IDE, SATA and SCSI drives have adopted the sd''x'' naming scheme. This is perfectly normal and should not be a concern.}}<br />
<br />
====Set Filesystem Mountpoints====<br />
First you will be asked for your swap partition. Choose the appropriate partition (sda3 in this example). You will be asked if you want to create a swap filesystem; select yes. Next, choose where to mount the / (root) directory (sda1 in the example). At this time, you will be asked to specify the filesystem type.<br />
<br />
=====Filesystem Types=====<br />
Again, a filesystem type is a very subjective matter which comes down to personal preference. Each has its own advantages, disadvantages, and unique idiosyncrasies. Here is a very brief overview of supported filesystems:<br />
<br />
1. '''ext2''' ''Second Extended Filesystem''- Old, reliable GNU/Linux filesystem. Very stable, but ''without journaling support''. May be inconvenient for root (/) and /home, due to very long fsck's. ''An ext2 filesystem can easily be converted to ext3.'' Generally regarded as a good choice for /boot/.<br />
<br />
2. '''ext3''' ''Third Extended Filesystem''- Essentially the ext2 system, but with journaling support. ext3 is completely compatible with ext2. ''Extremely'' stable, mature, and by far the most widely used, supported and developed GNU/Linux FS.<br />
<br />
'''High Performance Filesystems:'''<br />
<br />
3. '''ext4''' ''Fourth Extended Filesystem''- Backward compatible with ext2 and ext3, Introduces support for volumes with sizes up to 1 exabyte and files with sizes up to 16 terabyte. Increases the 32,000 subdirectory limit in ext3 to 64,000. Offers online defragmentation ability. <br />
{{Note | ext4 is a new filesystem and may have some bugs.}}<br />
<br />
4. '''ReiserFS''' (V3)- Hans Reiser's high-performance journaling FS uses a very interesting method of data throughput based on an unconventional and creative algorithm. ReiserFS is touted as very fast, especially when dealing with many small files. ReiserFS is fast at formatting, yet comparatively slow at mounting. Quite mature and stable. ReiserFS is not actively developed at this time (Reiser4 is the new Reiser filesystem). Generally regarded as a good choice for /var/.<br />
<br />
5. '''JFS''' - IBM's '''J'''ournaled '''F'''ile'''S'''ystem- The first filesystem to offer journaling. JFS had many years of use in the IBM AIX® OS before being ported to Linux. JFS currently uses the least CPU resources of any GNU/Linux filesystem. Very fast at formatting, mounting and fsck's, and very good all-around performance, especially in conjunction with the deadline I/O scheduler. (See [[JFS]].) Not as widely supported as ext or ReiserFS, but very mature and stable.<br />
<br />
6. '''XFS''' - Another early journaling filesystem originally developed by Silicon Graphics for the IRIX OS and ported to Linux. XFS offers very fast throughput on large files and large filesystems. Very fast at formatting and mounting. Generally benchmarked as slower with many small files, in comparison to other filesystems. XFS is very mature and offers online defragmentation ability.<br />
* JFS and XFS filesystems cannot be ''shrunk'' by disk utilities (such as gparted or parted magic)<br />
<br />
===== A note on Journaling=====<br />
All above filesystems, except ext2, utilize [http://en.wikipedia.org/wiki/Journaling_file_system journaling]. Journaling file systems are fault-resilient file systems that use a journal to log changes before they are committed to the file system to avoid metadata corruption in the event of a crash. Note that not all journaling techniques are alike; specifically, only ext3 and ext4 offer ''data-mode journaling'', (though, not by default), which journals ''both'' data ''and'' meta-data (but with a significant speed penalty). The others only offer ''ordered-mode journaling'', which journals meta-data only. While all will return your filesystem to a valid state after recovering from a crash, ''data-mode journaling'' offers the greatest protection against file system corruption and data loss but can suffer from performance degradation, as all data is written twice (first to the journal, then to the disk). Depending upon how important your data is, this may be a consideration in choosing your filesystem type.<br />
<br />
'''''Moving on...'''''<br />
<br />
Choose and create the filesystem (format the partition) for / by selecting '''yes'''. You will now be prompted to add any additional partitions. In our example, sda2 and sda4 remain. For sda2, choose a filesystem type and mount it as /var. Finally, choose the filesystem type for sda4, and mount it as /home. <br />
{{Box Note |If you have not created and do not need a separate /boot partition, you may safely ignore the warning that it does not exist.}} Return to the main menu.<br />
<br />
===D: Select Packages===<br />
<br />
*Core ISO: Choose CD as source and select the appropriate CD drive if more than one exist on the installation machine.<br />
*Netinstall: Select an FTP/HTTP mirror. ''Note that archlinux.org is throttled to 50KB/s''.<br />
<br />
Package selection is split into two stages. First, select the package category:<br />
{{Note | For expedience, all packages in '''base''' are selected by default. Use the space-bar to select and de-select packages.}}<br />
* '''Base''': The minimal base environment. ''Always select it and only remove packages that will not be used.''<br />
* '''Base-devel''': Extra tools such as '''make''', '''automake''' and '''wireless-tools''' as well as wireless firmwares. ''Most beginners should choose to install it, and will probably need it later.<br />
''<br />
After category selection, you will be presented with the full lists of packages, allowing you to fine-tune your selections. Use the space bar to select and unselect.<br />
<br />
{{Note | If you are going to require connection to a wireless network with WPA encryption, consider installing netcfg2 (as well as wireless_tools), which will enable you to do so.}}<br />
<br />
Adter selecting the needed packages, leave the selection<br />
screen and continue to the next step, Install Packages.<br />
<br />
===E: Install Packages===<br />
Next, choose 'Install Packages'. You will be asked if you wish to keep the packages in the pacman cache. If you choose 'yes', you will have the flexibility to [[Downgrade packages|downgrade]] to previous package versions in the future, so this is recommended (you can always clear the cache in the future). The installer script will now install the selected packages, as well as the default Arch 2.6 kernel, to your system.<br />
*Netinstall: The [[Pacman]] package manager will now download and install your selected packages. (See vc/5 for output, vc/1 to return to the installer)<br />
*Core image: The packages will be installed from the CD/USB stick.<br />
<br />
===F: Configure the System===<br />
''Closely following and understanding these steps is of key importance to ensure a properly configured system.''<br />
<br />
*At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system.<br />
<br />
*Previous versions of the installer included [[Hwdetect|hwdetect]] to gather information for your configuration. This has been deprecated, and '''[[Udev|udev]]''' should handle most module loading automatically at boot.<br />
<br />
Now you will be asked which text editor you want to use; choose [[Nano|nano]], [http://joe-editor.sourceforge.net/ joe] or [[Vim|vi]], ('''nano''' is generally considered easiest of the 3). You will be presented with a menu including the main configuration files for your system. <br />
<br />
{{Note | ''It is very important at this point to edit, or at least verify by opening, every configuration file.'' The installer script relies on your input to create these files on your installation. A common error is to skip over these critical steps of configuration.}}<br />
<br />
=====Can the installer handle this more automatically?=====<br />
Hiding the process of system configuration is in direct opposition to '''''[[The Arch Way]]'''''. While it is true that recent versions of the kernel and hardware probing tools offer excellent hardware support and auto-configuration, Arch presents the user all pertinent configuration files during installation for the purposes of ''transparency and system resource control''. By the time you have finished modifying these files to your specifications, you will have learned the simple method of manual Arch Linux system configuration and become more familiar with the base structure, leaving you better prepared to use and maintain your new installation productively.<br />
<br />
'''''Moving on...'''''<br />
<br />
====/etc/rc.conf====<br />
Arch Linux uses the file '''/etc/rc.conf''' as the principal location for system configuration. This one file contains a wide range of configuration information, principally used at system startup. As its name directly implies, it also contains settings for and invokes the /etc/rc* files, and is, of course, sourced ''by'' these files.<br />
<br />
=====LOCALIZATION section=====<br />
* '''LOCALE'''=: This sets your system locale, which will be used by all i18n-aware applications and utilities. You can get a list of the available locales by running {{Codeline|locale -a}} from the command line. This setting's default is fine for US English users.<br />
* '''HARDWARECLOCK'''=: Specifies whether the hardware clock, which is synchronized on boot and on shutdown, stores '''UTC''' time, or '''localtime'''. UTC makes sense because it greatly simplifies changing timezones and daylight savings time. localtime is necessary if you dual boot with an operating system such as Windows, that only stores localtime to the hardware clock.<br />
* '''USEDIRECTISA'''=: Use direct I/O request instead of {{Filename|/dev/rtc}} for hwclock<br />
* '''TIMEZONE'''=: Specify your TIMEZONE. (All available zones are under {{Filename|/usr/share/zoneinfo/}}).<br />
* '''KEYMAP'''=: The available keymaps are in {{Filename|/usr/share/kbd/keymaps}}. Please note that this setting is only valid for your TTYs, not any graphical window managers or '''X'''.<br />
* '''CONSOLEFONT'''=: Available console fonts reside under {{Filename|/usr/share/kbd/consolefonts/}} if you must change. The default (blank) is safe.<br />
* '''CONSOLEMAP'''=: Defines the console map to load with the setfont program at boot. Possible maps are found in {{Filename|/usr/share/kbd/consoletrans}}, if needed. The default (blank) is safe.<br />
* '''USECOLOR'''=: Select &quot;yes&quot; if you have a color monitor and wish to have colors in your consoles.<br />
LOCALE=&quot;en_US.utf8&quot;<br />
HARDWARECLOCK=&quot;localtime&quot;<br />
USEDIRECTISA=&quot;no&quot;<br />
TIMEZONE=&quot;US/Eastern&quot;<br />
KEYMAP=&quot;us&quot;<br />
CONSOLEFONT=<br />
CONSOLEMAP=<br />
USECOLOR=&quot;yes&quot;<br />
<br />
=====HARDWARE Section=====<br />
* '''MOD_AUTOLOAD'''=: Setting this to &quot;yes&quot; will use '''udev''' to automatically probe hardware and load the appropriate modules during boot, (convenient with the default modular kernel). Setting this to &quot;no&quot; will rely on the user's ability to specify this information manually, or compile their own custom kernel and modules, etc.<br />
* '''MOD_BLACKLIST'''=: This has become deprecated in favor of adding blacklisted modules directly to the '''MODULES=''' line below.<br />
* '''MODULES'''=: Specify additional MODULES if you know that an important module is missing. If your system has any floppy drives, add "floppy". If you will be using loopback filesystems, add "loop". Also specify any blacklisted modules by prefixing them with a bang (!). Udev will be forced NOT to load blacklisted modules. In the example, the IPv6 module as well as the annoying pcspeaker are blacklisted.<br />
# Scan hardware and load required modules at boot<br />
MOD_AUTOLOAD=&quot;yes&quot;<br />
# Module Blacklist - Deprecated<br />
MOD_BLACKLIST=()<br />
#<br />
MODULES=(!net-pf-10 !snd_pcsp !pcspkr loop)<br />
<br />
=====NETWORKING Section=====<br />
* '''HOSTNAME'''=:Set your HOSTNAME to your liking.<br />
* '''eth0'''=: 'Ethernet, card 0'. Adjust the interface IP address, netmask and broadcast address ''if'' you are using '''static IP'''. Set eth0=&quot;dhcp&quot; if you want to use '''DHCP'''<br />
* '''INTERFACES'''=: Specify all interfaces here. <br />
* '''gateway'''=: If you are using '''static IP''', set the gateway address. If using '''DHCP''', you can usually ignore this variable, though some users have reported the need to define it.<br />
* '''ROUTES'''=: If you are using static '''IP''', remove the '''!''' in front of 'gateway'. If using '''DHCP''', you can usually leave this variable commented out with the bang (!), but again, some users require the gateway and ROUTES defined. If you experience networking issues with pacman, for instance, you may want to return to these variables.<br />
<br />
====== Example, using a dynamically assigned IP address ('''DHCP''') ======<br />
<br />
HOSTNAME=&quot;arch&quot;<br />
#eth0=&quot;eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255&quot;<br />
eth0=&quot;dhcp&quot;<br />
INTERFACES=(eth0)<br />
gateway=&quot;default gw 192.168.0.1&quot;<br />
ROUTES=(!gateway)<br />
<br />
======Example, using a '''static''' IP address======<br />
<br />
HOSTNAME=&quot;arch&quot;<br />
eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"<br />
INTERFACES=(eth0)<br />
gateway="default gw 192.168.0.1"<br />
ROUTES=(gateway)<br />
<br />
Modify {{Filename|/etc/resolv.conf}} to contain the DNS servers of choice. Example:<br />
<br />
search my.isp.net.<br />
nameserver 4.2.2.1<br />
nameserver 4.2.2.2<br />
nameserver 4.2.2.3<br />
<br />
Various processes can overwrite the contents of {{filename|/etc/resolv.conf}}. For example, by default Arch Linux uses the '''dhcpcd''' DHCP client, which will overwrite the file when it starts. [[Resolv.conf|Various methods]] may be used to preserve the nameserver settings in {{filename|/etc/resolv.conf}}. For example, dhcpcd's configurations file may be edited to prevent the dhcpcd daemon from overwriting the file. To do this, you will need to modify the {{Filename|/etc/conf.d/dhcpcd}} configuration:<br />
<br />
# Arguments to be passed to the DHCP client daemon<br />
# DHCPCD_ARGS="-q"<br />
DHCPCD_ARGS="-C resolv.conf -q"<br />
<br />
{{tip|If using a non-standard MTU size (a.k.a. jumbo frames) is desired AND the installation machine hardware supports them, see the [[Jumbo Frames]] wiki article for further configuration.}}<br />
<br />
=====DAEMONS Section=====<br />
This array simply lists the names of those scripts contained in /etc/rc.d/ which are to be started during the boot process, and the order in which they start. <br />
DAEMONS=(network @syslog-ng netfs @crond)<br />
*If a script name is prefixed with a bang (!), it is not executed.<br />
*If a script is prefixed with an &quot;at&quot; symbol (@), it shall be executed in the background; the startup sequence will not wait for successful completion of each daemon before continuing to the next. (Useful for speeding up system boot). Do not background daemons that are needed by other daemons. For example "mpd" depends on "network", therefore backgrounding network may cause mpd to break.<br />
*Edit this array whenever new system services are installed, if starting them automatically during boot is desired.<br />
<br />
{{Note | This 'BSD-style' init, is the Arch way of handling what other distributions handle with various symlinks to an /etc/init.d directory.}}<br />
<br />
======About DAEMONS======<br />
The [[daemons]] line need not be changed at this time, but it is useful to explain what daemons are, as they will be addressed later in this guide.<br />
A ''daemon'' is a program that runs in the background, waiting for events to occur and offering services. A good example is a webserver that waits for a request to deliver a page (e.g.:httpd) or an SSH server waiting for a user login (e.g.:sshd). While these are full-featured applications, there are also daemons whose work is not that visible. Examples are a daemon which writes messages into a log file (e.g. syslog, metalog), a daemon which lowers the CPU frequency if the system has nothing to do (e.g.:cpufreq), and a daemon which provides a graphical login (e.g.: gdm, kdm). All these programs can be added to the daemons line and will be started when the system boots. Useful daemons will be presented during this guide.<br />
<br />
Historically, the term ''daemon'' was coined by the programmers of MIT's Project MAC. They took the name from ''Maxwell's demon'', an imaginary being from a famous thought experiment that constantly works in the background, sorting molecules. <tt>UNIX</tt> systems inherited this terminology and created the backronym '''d'''isk '''a'''nd '''e'''xecution '''mon'''itor.<br />
<br />
{{Tip|All Arch daemons reside under /etc/rc.d/}}<br />
<br />
====/etc/fstab====<br />
The '''fstab''' (for '''f'''ile '''s'''ystems '''tab'''le) is part of the system configuration listing all available disks and disk partitions, and indicating how they are to be initialized or otherwise integrated into the overall system's filesystem. The '''/etc/fstab''' file is most commonly used by the '''mount''' command. The mount command takes a filesystem on a device, and adds it to the main system hierarchy that you see when you use your system. '''mount -a''' is called from /etc/rc.sysinit, about 3/4 of the way through the boot process, and reads /etc/fstab to determine which options should be used when mounting the specified devices therein. If '''noauto''' is appended to a filesystem in /etc/fstab, '''mount -a''' will not mount it at boot.<br />
<br />
=====An example /etc/fstab=====<br />
# <file system> <dir> <type> <options> <dump> <pass><br />
none /dev/pts devpts defaults 0 0<br />
none /dev/shm tmpfs defaults 0 0<br />
#/dev/cdrom /media/cdrom auto ro,user,noauto,unhide 0 0<br />
#/dev/dvd /media/dvd auto ro,user,noauto,unhide 0 0<br />
#/dev/fd0 /media/fl auto user,noauto 0 0<br />
/dev/sda1 / jfs defaults,noatime 0 1<br />
/dev/sda2 /var reiserfs defaults,noatime,notail 0 2<br />
/dev/sda3 swap swap defaults 0 0<br />
/dev/sda4 /home jfs defaults,noatime 0 2<br />
{{Note | The 'noatime' option disables writing read access times to the metadata of files and may safely be appended to / and /home regardless of your specified filesystem type for increased speed, performance, and power efficiency (see [http://kerneltrap.org/node/14148 here] for more). 'notail' disables the ReiserFS tailpacking feature, for added performance at the cost of slightly less efficient disk usage.}}<br />
<br />
* '''<file system>''': describes the block device or remote filesystem to be mounted. For regular mounts, this field will contain a link to a block device node (as created by mknod which is called by udev at boot) for the device to be mounted; for instance, '/dev/cdrom' or '/dev/sda1'. <br />
{{Note | Rather than the sd''x'' naming scheme, you may choose to use UUID, or other persistent block device naming schemes for consistent device mapping. Due to active developments in the kernel and also udev, the ordering in which drivers for storage controllers are loaded may change randomly, yielding an unbootable system/kernel panic. Nearly every motherboard has several controllers (onboard SATA, onboard IDE), and due to the aforementioned development updates, /dev/sda may become /dev/sdb on the next reboot. (See [[Persistent block device naming| this wiki article]] for more information on persistent block device naming. )}}<br />
<br />
* '''<dir>''': describes the mount point for the filesystem. For swap partitions, this field should be specified as 'swap'; (Swap partitions are not actually mounted.)<br />
<br />
* '''<type>''': describes the type of the filesystem. The Linux kernel supports many filesystem types. (For the filesystems currently supported by the running kernel, see /proc/filesystems). An entry 'swap' denotes a file or partition to be used for swapping. An entry 'ignore' causes the line to be ignored. This is useful to show disk partitions which are currently unused.<br />
<br />
* '''<options>''': describes the mount options associated with the filesystem. It is formatted as a comma separated list of options with no intervening spaces. It contains at least the type of mount plus any additional options appropriate to the filesystem type. For documentation on the available options for non-nfs file systems, see mount(8).<br />
<br />
* '''<dump>''': used by the dump(8) command to determine which filesystems are to be dumped. dump is a backup utility. If the fifth field is not present, a value of zero is returned and dump will assume that the filesystem does not need to be backed up. ''Note that dump is not installed by default.''<br />
<br />
* '''<pass>''': used by the fsck(8) program to determine the order in which filesystem checks are done at boot time. The root filesystem should be specified with a <pass> of 1, and other filesystems should have a <pass> of 2 or 0. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.<br />
<br />
*If you plan on using '''hal''' to automount media such as DVDs, you may wish to comment out the cdrom and dvd entries in preparation for '''hal''', which will be installed later in this guide.<br />
<br />
Expanded information available in the [[Fstab]] wiki entry.<br />
<br />
===='''[[Configuring mkinitcpio | /etc/mkinitcpio]].conf'''====<br />
''Most users will not need to modify this file at this time, but please read the following explanatory information.''<br />
<br />
This file allows further fine-tuning of the initial ram filesystem, or initramfs, (also historically referred to as the initial ramdisk or &quot;initrd&quot;) for your system. The initramfs is a gzipped image that is read by the kernel during boot. 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 from a USB/FW drive). Once the initrramfs loads the proper modules, either manually or through udev, it passes control to the kernel and your boot continues. For this reason, the initramfs 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 common kernel modules will be loaded later on by udev, during the init process.<br />
<br />
'''mkinitcpio''' is the next generation of '''initramfs creation'''. It has many advantages over the old '''mkinitrd''' and '''mkinitramfs''' scripts.<br />
<br />
* It uses '''klibc''' and '''kinit''' which are developed by Linux kernel devs to provide a small and lightweight base for early userspace.<br />
* It can use '''udev''' for hardware autodetection at runtime, thus prevents you from having tons of unnecessary modules loaded.<br />
* Its hook-based init script is easily extendable with custom hooks, which can easily be included in pacman packages without having to modifiy mkinitcpio itself.<br />
* It already supports '''lvm2''', '''dm-crypt''' for both legacy and luks volumes, '''raid''', '''swsusp''' and '''suspend2''' resuming and booting from '''usb mass storage''' devices.<br />
* Many features can be configured from the kernel command line without having to rebuild the image.<br />
* The '''mkinitcpio''' script makes it possible to include the image in a kernel, thus making a self-contained kernel image is possible.<br />
* Its flexibility makes recompiling a kernel unnecessary in many cases.<br />
<br />
If using RAID or LVM on the root filesystem, the appropriate HOOKS must be configured. See the wiki pages for [[Installing with Software RAID or LVM| RAID]] and [[Configuring mkinitcpio | /etc/mkinitcpio]] for more info. If using a non-US keyboard. add the "<code>keymap</code>" hook to load your local keymap during boot. Add the "<code>usbinput</code>" hook if using a USB keyboard, e.g.:<br />
HOOKS="base udev autodetect pata scsi sata filesystems keymap usbinput"<br />
(Otherwise, if boot fails for some reason you will be asked to enter root's password for system maintenance but will be unable to do so.)<br />
<br />
If you need support for booting from USB devices, FireWire devices, PCMCIA devices, NFS shares, software RAID arrays, LVM2 volumes, encrypted volumes, or DSDT support, configure your HOOKS accordingly. <br />
<br />
If doing a CF or SD card install, you may need to add the <code>usbinput</code> HOOK for your system to boot properly. <br />
<br />
''If you are using a US keyboard, and have no need for any of the above HOOKS, editing this configuration should be unnecessary at this point.''<br />
<br />
'''mkinitcpio''' is an Arch innovation developed by Aaron Griffin and Tobias Powalowski with some help from the community.<br />
<br />
==== /etc/modprobe.d/modprobe.conf====<br />
<br />
This file can be used to set special configuration options for the kernel modules. It is unnecessary to configure this file at this time.<br />
<br />
====/etc/resolv.conf (for Static IP)====<br />
The ''resolver'' is a set of routines in the C library that provide access to the Internet Domain Name System (DNS). One of the main functions of DNS is to translate domain names into IP addresses, to make the Web a friendlier place. The resolver configuration file, or /etc/resolv.conf, contains information that is read by the resolver routines the first time they are invoked by a process.<br />
<br />
*''If you are using DHCP, you may safely ignore this file, as by default, it will be dynamically created and destroyed by the dhcpcd daemon. You may change this default behavior if you wish. (See [http://wiki.archlinux.org/index.php/Network#For_DHCP_IP Network]]).''<br />
<br />
If you use a static IP, set your DNS servers in /etc/resolv.conf (nameserver <ip-address>). You may have as many as you wish.<br />
An example, using OpenDNS:<br />
nameserver 208.67.222.222<br />
nameserver 208.67.220.220<br />
<br />
If you are using a router, you will probably want to specify your DNS servers in the router itself, and merely point to it from your '''/etc/resolv.conf''', using your router's IP (which is also your gateway from '''/etc/rc.conf'''), e.g.:<br />
nameserver 192.168.1.1<br />
<br />
If using '''DHCP''', you may also specify your DNS servers in the router, or allow automatic assignment from your ISP, if your ISP is so equipped.<br />
<br />
====/etc/hosts====<br />
This file associates IP addresses with hostnames and aliases, one line per IP address. For each host a single line should be present with the following information:<br />
<IP-address> <hostname> [aliases...]<br />
Add your ''hostname'', coinciding with the one specified in /etc/rc.conf, as an alias, so that it looks like this:<br />
127.0.0.1 localhost.localdomain localhost '''''yourhostname'''''<br />
{{Note |''This format, '''including the 'localhost' and your actual host name''', is required for program compatibility! So, if you have named your computer Archhost, then that line above should look like this:<br />
127.0.0.1 localhost.localdomain localhost Archhost<br />
Errors in this entry may cause poor network performance and/or certain programs to open very slowly, or not work at all. This is a very common error for beginners.''}}<br />
<br />
If you use a static IP, add another line using the syntax: <static-IP> <hostname.domainname.org> <hostname> e.g.:<br />
192.168.1.100 '''''yourhostname'''''.domain.org '''''yourhostname'''''<br />
<br />
{{Tip|For convenience, you may also use /etc/hosts aliases for hosts on your network, and/or on the Web, e.g.:<br />
64.233.169.103 www.google.com g<br />
192.168.1.90 media<br />
192.168.1.88 data<br />
The above example would allow you to access google simply by typing 'g' into your browser, and access to a media and data server on your network by name and without the need for typing out their respective IP addresses.}}<br />
<br />
====/etc/hosts.deny and /etc/hosts.allow====<br />
Modify these configurations according to your needs if you plan on using the [[SSH|ssh]] daemon. The default configuration will reject all incoming connections, not only ssh connections. Edit your '''/etc/hosts.allow '''file and add the appropriate parameters: <br />
<br />
* let everyone connect to you<br />
sshd: ALL<br />
<br />
* restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
* restrict it to your local LAN network (range 192.168.0.0 to 192.168.0.255)<br />
sshd: 192.168.0.<br />
<br />
* OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0<br />
<br />
If you do not plan on using the [[SSH|ssh]] daemon, leave this file at the default, (empty), for added security.<br />
<br />
====/etc/locale.gen====<br />
The '''/usr/sbin/locale-gen''' command reads from '''/etc/locale.gen''' to generate specific locales. They can then be used by '''glibc''' and any other locale-aware program or library for rendering text, correctly displaying regional monetary values, time and date formats, alphabetic idiosyncrasies, and other locale-specific standards. The ability to setup a default locale is a great built-in privilege of using a <tt>UNIX</tt>-like operating system.<br />
<br />
By default /etc/locale.gen is an empty file with commented documentation. Once edited, the file remains untouched. '''locale-gen''' runs on every '''glibc''' upgrade, generating all the locales specified in /etc/locale.gen.<br />
<br />
Choose the locale(s) you need (remove the # in front of the lines you want), e.g.:<br />
en_US ISO-8859-1<br />
en_US.UTF-8 <br />
<br />
The installer will now run the locale-gen script, which will generate the locales you specified. You may change your locale in the future by editing /etc/locale.gen and subsequently running 'locale-gen' as root.<br />
<br />
{{Note |'''''If you fail to choose your locale, this will lead to a &quot;The current locale is invalid...&quot; error. This is perhaps the most common mistake by new Arch users, and also leads to the most commonly asked questions on the forum.'''''}}<br />
<br />
====Pacman-Mirror====<br />
Choose a mirror repository for '''pacman'''. <br />
*''archlinux.org is throttled, limiting downloads to 50KB/s''<br />
<br />
====Root password====<br />
Finally, set a root password and make sure that you remember it later. Return to the main menu and continue with installing bootloader.<br />
<br />
===G: Install Bootloader===<br />
Because we have no secondary operating system in our example, we will need a bootloader. [http://www.gnu.org/software/grub/ GNU GRUB] is the recommended bootloader. Alternatively, you may choose [http://lilo.go.dyndns.org/ LILO].<br />
<br />
====GRUB====<br />
The provided '''GRUB''' configuration ('''/boot/grub/menu.lst''') should be sufficient, but verify its contents to ensure accuracy (specifically, ensure that the root (/) partition is specified by UUID on line 3). You may want to alter the resolution of the console by adding a vga=<number> kernel argument corresponding to your desired virtual console resolution. (A table of resolutions and the corresponding numbers is printed in the menu.lst.)<br />
<br />
Example: <br />
title Arch Linux (Main)<br />
root (hd0,0) <br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro vga=773<br />
initrd /boot/kernel26.img<br />
{{Note | ''The linux kernel, 'vmlinuz', is so named because it incorporated '''v'''irtual '''m'''emory capability early in its development. The '''z''' denotes a zipped (compressed) image.''}}<br />
<br />
Explanation:<br />
<br />
Line 1: '''title''': A printed menu selection. &quot;Arch Linux (Main)&quot; will be printed on the screen as a menu selection.<br />
<br />
Line 2: '''root''': '''GRUB''''s root; the drive and partition where the kernel (/boot) resides, according to system BIOS. (More accurately, where GRUB's stage2 file resides). '''NOT necessarily the root''' (/) file system, as they can reside on separate partitions. GRUB's numbering scheme starts at 0, and uses an hd''x,x'' format regardless of IDE or SATA, and enclosed within parentheses. <br />
<br />
The example indicates that /boot is on the first partition of the first drive, according to BIOS, or, (hd0,0).<br />
<br />
Line 3: '''kernel''': This line specifies:<br />
<br />
* The path and filename of the kernel '''''relative to GRUB's root'''''.<br />
In the example, /boot is merely a directory residing on the same partition as / and '''vmlinuz26''' is the kernel filename; '''/boot/vmlinuz26'''. ''If /boot were on a separate partition, the path and filename would be simply '''/vmlinuz26''', being relative to '''GRUB''''s root.'' <br />
<br />
* The root= argument to the kernel statement specifies the partition containing the root (/) directory in the booted system, (more accurately, the partition containing '''/sbin/init'''). <br />
<br />
*An easy way to distinguish the 2 appearances of 'root' in /boot/grub/menu.lst is to remember that the first root statement ''informs GRUB where the kernel resides'', whereas the second root= kernel argument ''tells the kernel where the root filesystem (/) resides''.<br />
<br />
* Kernel options. <br />
<br />
In our example, '''ro''' mounts the filesystem as read only during startup, (usually a safe default; you may wish to change this in case it causes problems booting) and the '''&quot;vga=773&quot;''' argument will give a 1024x768 framebuffer with 256 color depth.<br />
<br />
Line 4: '''initrd''': (For Initial RAM disk) The path and filename of the initial RAM filesystem '''relative to GRUB''''s root. Again, in the example, /boot is merely a directory residing on the same partition as / and '''kernel26.img''' is the initrd filename; '''/boot/kernel26.img'''. ''If /boot were on a separate partition, the path and filename would be simply '''/kernel26.img''', being relative to '''GRUB''''s root.'' <br />
<br />
Install the '''GRUB''' bootloader (to the master boot record, sda in our example).<br />
{{tip|For more details, see the [[GRUB]] wiki page.}}<br />
<br />
===H: Reboot===<br />
That's it; You have configured and installed your Arch Linux base system. Exit the install, and reboot:<br />
# reboot<br />
(Be sure to remove the installer CD)<br />
<br />
==Part II: Configure & Update the New Arch Linux base system==<br />
Your new Arch Linux system will boot up and finish with a login prompt (you may want to change the boot order in your '''BIOS''' back to booting from hard disk).<br />
<br />
'''Congratulations, and welcome to your new Arch Linux base system!'''<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready for customization. From here, you may build this elegant set of tools into whatever you wish or require for your purposes. <br />
<br />
Login with the root account. We will configure pacman and update the system as root, then add a normal user. <br />
{{Note |Virtual consoles 1-6 are available. You may switch between them with ALT+F1...F6}}<br />
<br />
===Step 1: Configuring the network (if necessary)===<br />
*''This section will assist you in configuring most types of networks, if your network configuration is not working for you.''<br />
<br />
If you properly configured your system, you should have a working network. Try to ping www.google.com to verify this.<br />
# ping -c 3 www.google.com<br />
<br />
''If you have successfully established a network connection, continue with '''[[#Step 2: Update, Sync and Upgrade the system with pacman|Update, Sync and Upgrade the system with pacman]]'''.''<br />
<br />
If, after trying to ping www.google.com, an &quot;unknown host&quot; error is received, you may conclude that your network is not properly configured. You may choose to double-check the following files for integrity and proper settings:<br />
<br />
'''/etc/rc.conf''' # Specifically, check your HOSTNAME= and NETWORKING section for typos and errors.<br />
<br />
'''/etc/hosts''' # Double-check your format. (See above.)<br />
<br />
'''/etc/resolv.conf''' # If you are using a static IP. If you are using DHCP, this file will be dynamically created and destroyed by default, but can be changed to your preference. (See [[Network]].)<br />
<br />
{{Tip|Advanced instructions for configuring the network can be found in the [[Network]] article.}}<br />
<br />
====Wired LAN====<br />
<br />
Check your Ethernet with<br />
# ifconfig -a<br />
All interfaces will be listed. You should see an entry for eth0, or perhaps eth1. <br />
*'''Static IP'''<br />
<br />
If required, you can set a new static IP with:<br />
# ifconfig eth0 <ip address> netmask <netmask> up <br />
and the default gateway with<br />
# route add default gw <ip address of the gateway><br />
Verify that /etc/resolv.conf contains your DNS server and add it if it is missing. <br />
Check your network again with ping www.google.com. If everything is working now, adjust /etc/rc.conf as described above for static IP. <br />
*'''DHCP'''<br />
If you have a DHCP server/router in your network try:<br />
# dhcpcd eth0<br />
If this is working, adjust /etc/rc.conf as described above, for dynamic IP.<br />
<br />
====Wireless LAN====<br />
* Ensure the driver has created a usable interface:<br />
# iwconfig<br />
* Bring the interface up with <code>ifconfig <interface> up</code>. e.g.:<br />
# ifconfig wlan0 up<br />
* (Optional) Scan for available access points:<br />
# iwlist wlan0 scan | less<br />
* Specify the id of the wireless network with <code>iwconfig <interface> essid <youressid></code>. Or, if using WEP; <code>iwconfig <interface> essid <youressid> key <yourwepkey></code>, e.g.:<br />
# iwconfig wlan0 essid linksys key ABCDEF01234<br />
* Request an IP address with <code>dhcpcd <interface></code>. e.g.:<br />
# dhcpcd wlan0<br />
* Ensure you can route:<br />
$ ping -c 3 www.google.com<br />
Done.<br />
<br />
Detailed setup guide: [[Wireless Setup]]<br />
<br />
====Analog Modem====<br />
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.<br />
Tip: Read [[Dialup without a dialer HOWTO]].<br />
<br />
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 [http://www.linmodems.org/ LinModem] homepage.<br />
<br />
====ISDN====<br />
<br />
Setting up ISDN is done in three steps:<br />
# Install and configure hardware<br />
# Install and configure the ISDN utilities<br />
# Add settings for your ISP <br />
<br />
The current Arch stock kernels include the necessary ISDN modules, meaning that you will not need to recompile your kernel unless you're about to use rather odd ISDN hardware. After physically installing your ISDN card in your machine or plugging in your USB ISDN-Box, you can try loading the modules with modprobe. Nearly all passive ISDN PCI cards are handled by the hisax module, which needs two parameters: type and protocol. You must set protocol to '1' if your country uses the 1TR6 standard, '2' if it uses EuroISDN (EDSS1), '3' if you're hooked to a so-called leased-line without D-channel, and '4' for US NI1.<br />
<br />
Details on all those settings and how to set them is included in the kernel documentation, more specifically in the isdn subdirectory, and available online. The type parameter depends on your card; a list of all possible types can be found in the README.HiSax kernel documentation. Choose your card and load the module with the appropriate options like this:<br />
<br />
# modprobe hisax type=18 protocol=2<br />
<br />
This will load the hisax module for my ELSA Quickstep 1000PCI, being used in Germany with the EDSS1 protocol. You should find helpful debugging output in your /var/log/everything.log file, in which you should see your card being prepared for action. Please note that you will probably need to load some USB modules before you can work with an external USB ISDN Adapter.<br />
<br />
Once you have confirmed that your card works with certain settings, you can add the module options to your /etc/modprobe.conf:<br />
<br />
alias ippp0 hisax<br />
options hisax type=18 protocol=2<br />
<br />
Alternatively, you can add only the options line here, and add hisax to your MODULES array in the rc.conf. It's your choice, really, but this example has the advantage that the module will not be loaded until it's really needed.<br />
<br />
That being done, you should have working, supported hardware. Now you need the basic utilities to actually use it!<br />
<br />
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.<br />
<br />
After you have 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.<br />
<br />
If you set up everything correctly, you should now be able to establish a dial-up connection with<br />
# isdnctrl dial ippp0<br />
as root. If you have any problems, remember to check the logfiles!<br />
<br />
====DSL (PPPoE)====<br />
<br />
These instructions are relevant to you only 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.<br />
<br />
Before you can use your DSL online connection, you will have to physically install the network card that is supposed to be connected to the DSL-Modem into your computer. After adding your newly installed network card to the modules.conf/modprobe.conf or the MODULES array, you should install the rp-pppoe package and run the pppoe-setup script to configure your connection. After you have entered all the data, you can connect and disconnect your line with<br />
<br />
# /etc/rc.d/adsl start<br />
<br />
and<br />
<br />
# /etc/rc.d/adsl stop<br />
<br />
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' at boot, add adsl to your DAEMONS array, and put a ! before the network entry, since the network is handled by adsl now.<br />
<br />
===Step 2: Update, Sync, and Upgrade the system with [[pacman]]===<br />
Now we will update the system using [[pacman]]. <br />
<br />
====What is pacman ?====<br />
[[Pacman]] is the '''pac'''kage '''man'''ager of Arch Linux. Pacman is written in ''C'' and is designed from the ground up to be lightweight with a very modest memory footprint, fast, simple, and versatile. It manages your entire package system and handles installation, removal, package downgrade (through cache), custom compiled package handling, automatic dependency resolution, remote and local searches and much more. Pacman's output is streamlined, very readable and provides ETA for each package download. Arch uses the .tar.gz package format, which further enhances pacman's speed; Gzipped tarballs, though slightly larger, are decompressed many times faster than their Bzipped counterparts, and are therefore installed much more expediently. <br />
<br />
We will use pacman to download software packages from remote repositories and install them onto your system.<br />
<br />
Pacman is the most important tool in your Arch Linux toolbox for building the base system into whatsoever you please.<br />
<br />
====Package Repositories and /etc/pacman.conf====<br />
Arch currently offers the following 4 repositories readily accessible through pacman:<br />
<br />
'''[core]'''<br />
<br />
The simple principle behind [core] is to provide only one of each necessary tool for a base Arch Linux system; The GNU toolchain, the Linux kernel, one editor, one command line browser, etc. (There are a few exceptions to this. For instance, both vi and nano are provided, allowing the user to choose one or both.) It contains all the packages that MUST be in perfect working order to ensure the system remains in a usable state. These are the absolute system-critical packages. <br />
* Developer maintained<br />
* All binary packages<br />
* pacman accessible <br />
*''The Core installation media simply contains an installer script, and a snapshot of the core repository at the time of release.''<br />
<br />
'''[extra]'''<br />
<br />
The [extra] repository contains all Arch packages that are not themselves necessary for a base Arch system, but contribute to a more full-featured environment. '''X''', KDE, and Apache, for instance, can be found here. <br />
* Developer maintained<br />
* All binary packages<br />
* pacman accessible<br />
'''[testing]'''<br />
<br />
The [testing] repository contains packages that are candidates for the [core] or [extra] repositories. New packages go into [testing] if:<br />
<br />
<nowiki>*</nowiki> they are expected to break something on update and need to be tested first.<br />
<br />
<nowiki>*</nowiki> they require other packages to be rebuilt. In this case, all packages that need to be rebuilt are put into [testing] first and when all rebuilds are done, they are moved back to the other repositories. <br />
* Developer maintained<br />
* All binary packages<br />
* pacman accessible<br />
{{Note|* [testing] is the only repository that can have name collisions with any of the other official repositories. Therefore, if enabled, [testing] must be the first repo listed in <code>pacman.conf</code>.}}<br />
<br />
{{Warning|Only experienced users should use [testing].}}<br />
<br />
'''[community]'''<br />
<br />
The [community] repository is maintained by the ''Trusted Users (TUs)'' and is simply the binary branch of the ''Arch User Repository ([[AUR]])''. It contains binary packages which originated as PKGBUILDs from ''AUR'' [unsupported] that have acquired enough votes and were adopted by a ''TU''. Like all repos listed above, [community] may be readily accessed by pacman.<br />
* TU maintained<br />
* All binary packages<br />
* pacman accessible<br />
<br />
'''AUR (unsupported)'''<br />
<br />
The '''[[AUR]]''' also contains the '''unsupported''' branch, which cannot be accessed directly by pacman*. '''AUR''' [unsupported] does not contain binary packages. Rather, it provides more than sixteen thousand PKGBUILD scripts for building packages from source, that may be unavailable through the other repos. When an AUR unsupported package acquires enough popular votes, it may be moved to the AUR [community] binary repo, if a TU is willing to adopt and maintain it there.<br />
* TU maintained<br />
* All PKGBUILD bash build scripts<br />
* '''''Not''''' pacman accessible by default<br />
<br />
<nowiki>*</nowiki> pacman wrappers ('''''[[AUR Helpers]]''''') can help you seamlessly access AUR.<br />
<br />
'''/etc/pacman.conf'''<br />
<br />
pacman will attempt to read /etc/pacman.conf each time it is invoked. This configuration file is divided into sections, or repositories. Each section defines a package [[Official Repositories|repository]] that pacman can use when searching for packages. The exception to this is the options section, which defines global options.<br />
<br />
Note that the defaults should work, so modifying at this point may be unnecessary, but verification is always recommended. Further info available in the [[Mirrors]] article.<br />
# nano /etc/pacman.conf<br />
Example:<br />
#<br />
# /etc/pacman.conf<br />
#<br />
# See the pacman.conf(5) manpage for option and repository directives<br />
<br />
#<br />
# GENERAL OPTIONS<br />
#<br />
[options]<br />
# The following paths are commented out with their default values listed.<br />
# If you wish to use different paths, uncomment and update the paths.<br />
#RootDir = /<br />
#DBPath = /var/lib/pacman/<br />
#CacheDir = /var/cache/pacman/pkg/<br />
#LogFile = /var/log/pacman.log<br />
HoldPkg = pacman glibc<br />
# If upgrades are available for these packages they will be asked for first<br />
SyncFirst = pacman<br />
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u<br />
#XferCommand = /usr/bin/curl %u > %o<br />
<br />
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup<br />
#IgnorePkg =<br />
#IgnoreGroup =<br />
<br />
#NoUpgrade =<br />
#NoExtract =<br />
<br />
# Misc options (all disabled by default)<br />
#NoPassiveFtp<br />
#UseSyslog<br />
#ShowSize<br />
#UseDelta<br />
#TotalDownload<br />
#<br />
# REPOSITORIES<br />
# - can be defined here or included from another file<br />
# - pacman will search repositories in the order defined here<br />
# - local/custom mirrors can be added here or in separate files<br />
# - repositories listed first will take precedence when packages<br />
# have identical names, regardless of version number<br />
# - URLs will have $repo replaced by the name of the current repo<br />
#<br />
# Repository entries are of the format:<br />
# [repo-name]<br />
# Server = ServerName<br />
# Include = IncludePath<br />
#<br />
# The header [repo-name] is crucial - it must be present and<br />
# uncommented to enable the repo.<br />
# <br />
<br />
# Testing is disabled by default. To enable, uncomment the following<br />
# two lines. You can add preferred servers immediately after the header,<br />
# and they will be used before the default mirrors.<br />
#[testing]<br />
#Include = /etc/pacman.d/mirrorlist<br />
<br />
[core]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
[extra]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist <br />
<br />
[community]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
# An example of a custom package repository. See the pacman manpage for<br />
# tips on creating your own repositories.<br />
#[custom]<br />
#Server = file:///home/custompkgs<br />
<br />
Enable all desired repositories (remove the # in front of the 'Include =' and '[repository]' lines).<br />
<br />
<br />
*'''''When choosing repos, be sure to uncomment both the repository header lines in [brackets] as well as the 'Include =' lines. Failure to do so will result in the selected repository being omitted! This is a very common error.'' '''<br />
<br />
====/etc/pacman.d/mirrorlist ====<br />
Defines pacman repo mirrors and priorities.<br />
<br />
'''Build a mirrorlist using the rankmirrors script'''<br />
<br />
<code>/usr/bin/rankmirrors</code> is a python script which will attempt to detect the mirrors which are closest to the installation machine based on the mirrors specified in /etc/pacman.d/mirrorlist. Faster mirrors will dramatically improve pacman performance, and the overall Arch Linux experience. This script may be run periodically, especially if the chosen mirrors provide inconsistent throughput and/or updates.<br />
<br />
First, use pacman to install python:<br />
# pacman -Sy python <br />
'''cd''' to the /etc/pacman.d/ directory:<br />
# cd /etc/pacman.d<br />
Backup the existing /etc/pacman.d/mirrorlist:<br />
# cp mirrorlist mirrorlist.backup<br />
Edit mirrorlist.backup and uncomment all mirrors on the same continent or within geographical proximity to test with rankmirrors.<br />
# nano mirrorlist.backup<br />
Run the script against the mirrorlist.backup with the -n switch and redirect output to a new /etc/pacman.d/mirrorlist file:<br />
# rankmirrors -n 6 mirrorlist.backup > mirrorlist<br />
'''-n 6''': rank the 6 fastest mirrors<br />
<br />
'''Force pacman to refresh the package lists'''<br />
<br />
After creating/editing /etc/pacman.d/mirrorlist, (manually or by <code>/usr/bin/rankmirrors</code>) issue the following command:<br />
# pacman -Syy<br />
Passing two --refresh or -y flags forces pacman to refresh all package lists even if they are considered to be up to date. Issuing pacman -Syy ''whenever a mirror is changed'', is good practice and will avoid possible headaches.<br />
<br />
====Mirrorcheck for up-to-date packages====<br />
Some of the official mirrors may contain packages that are out-of-date. [http://users.archlinux.de/~gerbra/mirrorcheck.html ArchLinux Mirrorcheck] reports various aspects about the mirrors such as, those experiencing network problems, data collection problems, reports the last time they have been synced, etc.<br />
<br />
One may wish to manually inspect the mirrors in the /etc/pacman.d/mirrorlist insuring that it only contains up-to-date mirrors if having the latest package versions is a priority.<br />
<br />
====Ignoring packages====<br />
After executing the command &quot;pacman -Syu&quot;, the entire system will be updated. It is possible to prevent a package from being upgraded. A typical scenario would be a package for which an upgrade may prove problematic for the system. In this case, there are two options; indicate the package(s) to skip in the pacman command line using the --ignore switch (do pacman -S --help for details) or permanently indicate the package(s) to skip in the /etc/pacman.conf file in the IgnorePkg array. List each package, with one intervening space :<br />
IgnorePkg = wine <br />
The typical way to use Arch is to use pacman to install all packages unless there is no package available, in which case [[ABS]] may be used. Many user-contributed package build scripts are also available in the [[AUR]]. <br />
<br />
The power user is expected to keep the system up to date with pacman -Syu, rather than selectively upgrading packages. You may diverge from this typical usage as you wish; just be warned that there is a greater chance that things will not work as intended and that it could break your system. The majority of complaints happen when selective upgrading, unusual compilation or improper software installation is performed. Use of '''IgnorePkg''' in /etc/pacman.conf is therefore discouraged, and should only be used sparingly, if you know what you are doing.<br />
<br />
====Ignoring Configuration Files====<br />
In the same vein, you can also &quot;protect&quot; your configuration/system files from being overwritten during &quot;pacman -Su&quot; using the following option in your /etc/pacman.conf<br />
<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
<br />
====Get familiar with pacman====<br />
pacman is the Arch user's best friend. It is highly recommended to study and learn how to use the pacman(8) tool. Try:<br />
$ man pacman<br />
<br />
For more information,please look up the [[pacman]] wiki entries at your leisure.<br />
<br />
====Powerpill, a pacman wrapper script====<br />
Before you continue, consider installing Xyne's powerpill (now in [community]) which is a pacman wrapper script that speeds up package retrieval by using aria2c (an external download helper) for concurrent/segmented downloads. In other words, powerpill pulls packages in parallel effectively speeding up your downloads. This is particularly advantageous on new installs when pulling down hundreds of megs of packages.<br />
<br />
# pacman -S powerpill<br />
<br />
Treat powerpill as pacman as you consider installations, for example, the following will update your system:<br />
<br />
# powerpill -Syu<br />
<br />
See the [[Powerpill]] wiki article for more.<br />
<br />
===Step 3: Update System===<br />
You are now ready to upgrade your entire system. Before you do, read through the [http://www.archlinux.org/news/ news] (and optionally the [http://archlinux.org/pipermail/arch-announce/ announce mailing list]). Often the developers will provide important information about required configurations and modifications for known issues. Consulting these pages before any upgrade is good practice. <br />
<br />
Sync, refresh, and upgrade your entire new system with:<br />
# pacman -Syu<br />
or:<br />
# pacman --sync --refresh --sysupgrade<br />
<br />
pacman will now download a fresh copy of the master package list from the server(s) defined in pacman.conf(5) and perform all available upgrades. (You may be prompted to upgrade pacman itself at this point. If so, say yes, and then reissue the pacman -Syu command when finished.) <br />
<br />
Reboot if a kernel upgrade has occurred. <br />
<br />
{{Note|Occasionally, configuration changes may take place requiring user action during an update; read pacman's output for any pertinent information.}}<br />
<br />
Pacman output is saved in /var/log/pacman.log.<br />
<br />
See [[Package_Management_FAQs|Package Management FAQs]] for answers to frequently asked questions regarding updating and managing your packages.<br />
<br />
=====The Arch rolling release model=====<br />
Keep in mind that Arch is a '''rolling release''' distribution. This means there is never a reason to reinstall or perform elaborate system rebuilds to upgrade to the newest version. Simply issuing '''pacman -Syu''' periodically keeps your entire system up-to-date and on the bleeding edge. At the end of this upgrade, your system is completely current. '''Reboot''' if a kernel upgrade has occurred.<br />
=====Network Time Protocol=====<br />
You may wish to set the system time now using OpenNTPD to sync the local clock to remote NTP servers. OpenNTPD may also be added to the DAEMONS= array in /etc/rc.conf to provide this service at each boot. (See the [[Network Time Protocol]] article.)<br />
<br />
===Step 4: Add a user and setup groups===<br />
<tt>UNIX</tt> is a multi-user environment. You should not do your everyday work using the root account. It is more than poor practice; it is dangerous. Root is for administrative tasks. Instead, add a normal, non-root user account using the <code>/usr/sbin/useradd</code> program:<br />
# useradd -m -G [groups] -s [login_shell] [username] <br />
* '''-m''' Creates user home directory as /home/'''username'''. Within their home directory, a user can write files, delete them, install programs, etc. Users' home directories shall 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 ''user'' (under /home/username) and ''global'' configuration files, (usually under /etc/) the settings in the ''user'' file will prevail. Dotfiles 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.<br />
* '''-G''' A list of supplementary groups which the user is also a member of. ''Each group is separated from the next by a comma, with no intervening spaces''. The default is for the user to belong only to the initial group (users). <br />
* '''-s''' The path and filename of the user´s default login shell.<br />
Useful groups for your non-root user include:<br />
*'''audio''' - for tasks involving sound card and related software<br />
*'''floppy''' - for access to a floppy if applicable<br />
*'''lp''' - for managing printing tasks<br />
*'''optical''' - for managing tasks pertaining to the optical drive(s)<br />
*'''storage''' - for managing storage devices<br />
*'''video''' - for video tasks and hardware acceleration<br />
*'''wheel''' - for using sudo<br />
*'''power''' - used w/ power options (e.g.: shutdown with power button) <br />
A typical desktop system example, adding a user named &quot;archie&quot; specifying bash as the login shell:<br />
# useradd -m -G users,audio,lp,optical,storage,video,wheel,power -s /bin/bash archie<br />
Next, add a password for your new user using <code>/usr/bin/passwd</code>.<br />
<br />
An example for our user, 'archie':<br />
# passwd archie<br />
(You will be prompted to provide the new <tt>UNIX</tt> password.)<br />
<br />
Your new non-root user has now been created, complete with a home directory and a login password.<br />
<br />
'''Alternative method, using <code>/usr/sbin/adduser</code>:'''<br />
<br />
Alternatively, you may use <code>adduser</code>, an interactive user adding program which will prompt you for the above data ''(recommended for beginners)'':<br />
# adduser<br />
'''Deleting the user account:'''<br />
<br />
In the event of error, or if you wish to delete this user account in favor of a different name or for any other reason, use <code>/usr/sbin/userdel</code>:<br />
# userdel -r [username]<br />
* '''-r ''' Files in the user´s home directory will be removed along with the home directory itself and the user´s mail spool.<br />
<br />
If you want to change the name of your user or any existing user, see the [[Change username]] page of the Arch wiki and/or the [[Groups]] and [[User Management]] articles for further information. You may also check the man pages for <code>usermod(8)</code> and <code>gpasswd(8)</code>.<br />
<br />
===Step 5: Install and setup Sudo (Optional)===<br />
There has been a recent update to the vi packages since the latest installation media (2009.08) was created. Therefore, before installing sudo, use the following command to remove the incompatible files:<br />
# rm /usr/bin/{view,rview}<br />
Install Sudo and vim:<br />
# pacman -S sudo vim<br />
To add a user as a sudo user (a &quot;sudoer&quot;), the visudo command must be run as root. If you do not know how to use vi, you may set the EDITOR environment variable to the editor of your choice before running visudo. e.g.:<br />
# EDITOR=nano visudo<br />
If you are comfortable using vi, issue the visudo command without the EDITOR=nano variable:<br />
# visudo<br />
This will open the file /etc/sudoers in a special session of vi. visudo copies the file to be edited to a temporary file, edits it with an editor, (vi by default), and subsequently runs a sanity check. If it passes, the temporary file overwrites the original with the correct permissions. <br />
<br />
{{Warning|Do not edit /etc/sudoers directly with an editor; Errors in syntax can cause annoyances (like rendering the root account unusable). You must use the ''visudo'' command to edit /etc/sudoers.}}<br />
<br />
To give the user full root privileges when he/she precedes a command with &quot;sudo&quot;, add the following line:<br />
USER_NAME ALL=(ALL) ALL<br />
where USER_NAME is the username of the individual.<br />
<br />
For more information, such as sudoer <TAB> completion, see [[Sudo]]<br />
<br />
==Part III: Install X and configure ALSA==<br />
<br />
<br />
===Step 1: Configure sound with alsamixer===<br />
The Advanced Linux Sound Architecture (known by the acronym '''ALSA''') is a Linux kernel component intended to replace the original Open Sound System (OSS) for providing device drivers for sound cards. Besides the sound device drivers, '''ALSA''' also bundles a user space library for application developers who want to use driver features with a higher level API than direct interaction with the kernel drivers.<br />
{{Note| Alsa is included in the Arch mainline kernel and udev will automatically probe your hardware at boot, loading the corresponding kernel module for your audio card. Therefore, your sound should already be working, but upstream sources mute all channels by default.}}<br />
{{Note| OSS4.1 has been released under a free license and is generally considered a significant improvement over older OSS versions. If you have issues with ALSA, or simply wish to explore another option, you may choose OSS4.1 instead. Instructions can be found in [[OSS]]}} <br />
<br />
The alsa-utils package contains the alsamixer userspace tool, which allows configuration of the sound device from the console or terminal.<br />
<br />
By default the upstream kernel sources ship with snd_pcsp, the alsa pc speaker module. snd_pcsp is usually loaded before your &quot;actual&quot; sound card module. In most cases, it will be more convenient if this module is loaded last, as it will allow alsamixer to correctly control the desired sound card.<br />
<br />
To have snd_pcsp load last, add the following to /etc/modprobe.d/modprobe.conf:<br />
options snd-pcsp index=2<br />
<br />
Alternatively, if you do not want snd_pcsp to load at all, blacklist it by adding the following to /etc/rc.conf:<br />
MODULES=(... !snd_pcsp)<br />
<br />
{{Note | You will need to unload all your sound modules and reload them for the changes to take effect. It might be easier to reboot. Your choice. }}<br />
<br />
Install the alsa-utils package:<br />
# pacman -S alsa-utils<br />
Also, you may want to install the alsa-oss package, which wraps applications written for [[OSS]] in a compatibility library, allowing them to work with [[ALSA]]. To install the alsa-oss package:<br />
# pacman -S alsa-oss <br />
Did you add your normal user to the audio group? If not, use <code>/usr/bin/gpasswd</code>. As root do:<br />
# gpasswd -a ''yourusername'' audio<br />
As '''''normal, non-root''''' user, invoke <code>/usr/bin/alsamixer</code>:<br />
# su - ''yourusername'' <br />
'''$''' alsamixer<br />
Unmute the Master and PCM channels by scrolling to them with cursor left/right and pressing '''M'''. Increase the volume levels with the cursor-up key. (70-90 Should be a safe range.) Some machines, (like the Thinkpad T61), have a '''Speaker''' channel which must be unmuted and adjusted as well. Leave alsamixer by pressing ESC. <br />
==== Sound test ====<br />
Ensure your speakers are properly connected, and test your sound configuration as normal user using <code>/usr/bin/aplay</code>:<br />
$ aplay /usr/share/sounds/alsa/Front_Center.wav<br />
You should hear a very eloquent woman say, &quot;Front, center.&quot;<br />
==== Saving the Sound Settings ====<br />
Exit your normal user shell and run <code>/usr/sbin/alsactl</code> as root:<br />
$ exit<br />
# alsactl store<br />
This will create the file '/etc/asound.state', saving the alsamixer settings. <br />
<br />
Also, add the alsa ''daemon'' to your DAEMONS section in /etc/rc.conf to automatically restore the mixer settings at boot.<br />
# nano /etc/rc.conf<br />
DAEMONS=(syslog-ng network crond '''alsa''')<br />
''Note that the alsa daemon merely restores your volume mixer levels on boot up by reading /etc/asound.state. It is separate from the alsa audio library (and kernel level API).''<br />
<br />
Expanded information available in the [[ALSA]] wiki entry.<br />
<br />
===Step 2: Install X===<br />
The '''X''' Window System version 11 (commonly '''X11''', or just simply '''X''') is a networking and display protocol which provides windowing on bitmap displays. It provides the standard toolkit and protocol to build graphical user interfaces (GUIs) on <tt>UNIX</tt>-like operating systems.<br />
<br />
'''X''' provides the basic framework, or primitives, for building GUI environments: drawing and moving windows on the screen and interacting with a mouse and/or keyboard. '''X''' does not mandate the user interface — individual client programs handle this. <br />
<br />
'''X''' is so named because it was preceded by the '''W''' Window System, originally developed at Stanford University. <br />
<br />
====A: The <code>X-Files</code>====<br />
Now we will install the base '''[[Xorg]]''' packages using pacman. This is the first step in building a GUI.<br />
If you plan on using an '''open-source''' video driver, and need 3d acceleration, install the libgl library before installing Xorg:<br />
# pacman -S libgl<br />
''(Proprietary video drivers provide their own gl library implementations.)''<br />
<br />
Install the base packages:<br />
# pacman -S xorg<br />
The 3d utilities glxgears and glxinfo are included in the '''mesa''' package:<br />
# pacman -S mesa<br />
<br />
====B: Install Video Driver Package====<br />
Now we have the base packages we need for running the '''X''' Server. You should add the driver for your graphics card now (e.g. xf86-video-<name>). The easiest way to configure X.org is by installing the correct driver packages first, and then generating /etc/X11/xorg.conf using an autoconfiguration script, like Xorg -configure.<br />
<br />
You will need knowledge of which video chipset your machine has. If you do not know, use the <code>/usr/sbin/lspci</code> program:<br />
# lspci | grep VGA<br />
<br />
If you need a list of all '''open-source''' video drivers, do: <br />
# pacman -Ss xf86-video | less<br />
Here is a list of '''open source''' drivers, and the corresponding video chipsets.<br />
*'''xf86-video-apm''' &mdash; Alliance ProMotion video driver<br />
*'''xf86-video-ark''' &mdash; ark video driver<br />
*'''xf86-video-ati''' &mdash; ATI(AMD) radeon video driver<br />
**'''xf86-video-r128''' &mdash; ATI(AMD) video driver for X.org ati Rage128 video<br />
**'''xf86-video-mach64''' &mdash; ATI(AMD) video driver for X.org mach64 video<br />
**'''xf86-video-radeonhd''' &mdash; ATI(AMD) radeonhd video driver<br />
*'''xf86-video-chips''' &mdash; Chips and Technologies video driver<br />
*'''xf86-video-cirrus''' &mdash; Cirrus Logic video driver<br />
*'''xf86-video-dummy''' &mdash; dummy video driver<br />
*'''xf86-video-fbdev''' &mdash; framebuffer video driver<br />
*'''xf86-video-glint''' &mdash; GLINT/Permedia video driver<br />
*'''xf86-video-i128''' &mdash; Number 0 i128 video driver<br />
*'''xf86-video-i740''' &mdash; Intel i740 video driver<br />
*'''xf86-video-i810''' &mdash; Intel i810/i830/i9xx video drivers (deprecated - use -intel)<br />
*'''xf86-video-intel''' &mdash; Newer Version of Intel i810/i830/i9xx video drivers<br />
*'''xf86-video-intel-legacy''' &mdash; Legacy-driver for older intel cards as 82865G (xf86-video-intel currently crashes with older cards)<br />
*'''xf86-video-imstt''' &mdash; Integrated Micro Solutions Twin Turbo video driver<br />
*'''xf86-video-mga''' &mdash; mga video driver (Matrox Graphics Adapter)<br />
*'''xf86-video-neomagic''' &mdash; neomagic video driver<br />
*'''xf86-video-nv''' &mdash; Nvidia nv video driver<br />
*'''xf86-video-nouveau''' &mdash; Open Source 3D acceleration driver for nVidia cards (experimental), check: [http://nouveau.freedesktop.org/wiki/] for Current Status<br />
*'''xf86-video-openchrome''' &mdash; VIA/S3G UniChrome, UniChrome Pro and Chrome9 video driver<br />
*'''xf86-video-rendition''' &mdash; Rendition video driver<br />
*'''xf86-video-s3''' &mdash; S3 video driver<br />
*'''xf86-video-s3virge''' &mdash; S3 Virge video driver<br />
*'''xf86-video-savage''' &mdash; savage video driver<br />
*'''xf86-video-siliconmotion''' &mdash; siliconmotion video driver<br />
*'''xf86-video-sis''' &mdash; SiS video driver<br />
*'''xf86-video-sisusb''' &mdash; SiS USB video driver<br />
*'''xf86-video-tdfx''' &mdash; tdfx video driver<br />
*'''xf86-video-trident''' &mdash; Trident video driver<br />
*'''xf86-video-tseng''' &mdash; tseng video driver<br />
*'''xf86-video-unichrome''' &mdash; VIA S3 Unichrome video drivers<br />
*'''xf86-video-v4l''' &mdash; v4l video driver<br />
*'''xf86-video-vesa''' &mdash; vesa video driver<br />
*'''xf86-video-vga''' &mdash; VGA 16 color video driver<br />
*'''xf86-video-vmware''' &mdash; vmware video driver<br />
*'''xf86-video-voodoo''' &mdash; voodoo video driver<br />
<br />
'''''Note''''': The '''vesa''' driver is the most generic, and should work with almost any modern video chipset. If you cannot find a suitable driver for your video chipset, vesa ''should'' work.<br />
<br />
Use pacman to install the appropriate video driver for your video card/onboard video. e.g.:<br />
# pacman -S xf86-video-savage<br />
(for the Savage driver.)<br />
<br />
*If you have an NVIDIA or ATI graphics card you may wish to install the proprietary NVIDIA or ATI drivers. '''Installing proprietary video drivers is covered below.'''.<br />
*If you do not want to install the proprietary drivers or do not have an NVIDIA or ATI graphics card, you should skip down to '''[[#Step 3: Configure X|Step 3: Configure X]]'''.<br />
<br />
-----<br />
<br />
<br />
=====NVIDIA Graphics Cards=====<br />
The NVIDIA proprietary drivers are generally considered to be of good quality, and offer 3D performance, whereas the open source '''nv''' driver offers only 2d support at this time. <br />
<br />
Before you configure your Graphics Card you will need to know which driver fits. Arch currently has several different driver packages that each match a certain subset of Cards: <br />
<br />
'''1. nvidia-96xx''' ''slightly newer cards up to the GF 4.''<br />
<br />
'''2. nvidia-173xx''' ''Geforce FX series cards''<br />
<br />
'''3. nvidia''' ''newest GPUs after the GF FX''<br />
<br />
{{Note| Nvidia-71xx series proprietary drivers, which are required by extremely old cards like TNT and TNT2, have been removed because they do not work with the new Xorg that Arch makes use of and nvidia has discontinued support for such. You should use the xf86-video-nv or xf86-video-vesa drivers instead.}}<br />
<br />
Consult the NVIDIA website to see which one is for you. The difference is only for the installation; Configuration works the same with every driver.<br />
<br />
Select and install the appropriate NVIDIA driver ''for your card'', e.g.: <br />
# pacman -S nvidia-96xx<br />
<br />
The NVIDIA package has a utility for updating your existing /etc/X11/xorg.conf for use with the NVIDIA driver:<br />
# nvidia-xconfig<br />
<br />
It also has several options which will further specify the contents and options of the xorg.conf file.<br />
For example,<br />
# nvidia-xconfig --composite --add-argb-glx-visuals<br />
<br />
For more detailed information, see nvidia-xconfig(1).<br />
<br />
Some useful tweaking options in the device section are (beware that these may not work on your system):<br />
Option &quot;RenderAccel&quot; &quot;true&quot;<br />
Option &quot;NoLogo&quot; &quot;true&quot;<br />
Option &quot;AGPFastWrite&quot; &quot;true&quot;<br />
Option &quot;EnablePageFlip&quot; &quot;true&quot;<br />
Make sure all instances of DRI are commented out:<br />
# Load &quot;dri&quot;<br />
Double check your /etc/X11/xorg.conf to make sure your default depth, horizontal sync, vertical refresh, and resolutions are acceptable.<br />
<br />
Update kernel module dependencies using <code>/sbin/depmod</code>:<br />
# depmod -a<br />
(A reboot may be necessary.)<br />
{{Tip|Advanced instructions for NVIDIA configuration can be found in the [[NVIDIA]] article.}}<br />
<br />
You may now continue with '''[[#Step 3: Configure X|Step 3: Configure X]]''' to familiarize yourself further, or continue the installation process with '''[[#C: Test X|Test X]]'''.<br />
<br />
=====ATI Graphics Cards=====<br />
ATI owners have multiple options for drivers. <br />
* The open source '''''radeon''''' driver provided by the '''xf86-video-ati''' package. <br />
** This is the original, reverse-engineered open source driver which fully supports Radeon chipsets up to X1950 (latest R500 chipsets). Cards up to the 9200 series are fully supported, stable, and provide full 2D and 3D acceleration. Cards from 9500 to X1950 feature full 2D acceleration, and stable 3D acceleration, but lack certain features provided by the proprietary driver, (for example, powersaving is still in a testing phase). Cards from HD2xxx (R6xx) to the newest are supported by xf86-video-ati, but only offer 2d support at this time.<br />
* The open source '''''radeonhd''''' driver provided by the '''xf86-video-radeonhd''' package.<br />
** This driver supports ATI R500 chipsets (Radeon X1000 series) and newer. It is written by Novell with specifications provided to the public by AMD. It supports RandR 1.2 and development is currently very active. Therefore, functionality may be inconsistent across the spectrum of cards supported. (Some users report excellent performance and reliability while others experience trouble.) It also supports HDMI, with sound.<br />
* The proprietary '''''fglrx''''' driver provided by the Catalyst package located in the AUR. The proprietary driver is covered below.<br />
The open-source drivers will usually suit most needs and are generally less problematic.<br />
<br />
Install the '''''radeon''''' ATI Driver with<br />
# pacman -S xf86-video-ati libgl ati-dri<br />
Install the '''''radeonhd''''' ATi Driver with<br />
# pacman -S xf86-video-radeonhd libgl ati-dri<br />
<br />
The proprietary ATI driver '''Catalyst''' was once a precompiled package offered by Arch in the <code>extra</code> repository, but as of March 2009, official support has been dropped because of dissatisfaction with the quality and speed of development of the proprietary driver.The catalyst driver is now available in [http://aur.archlinux.org/packages.php?ID=22899 AUR]. Installation information for Catalyst driver is available [[ATI#Proprietary_ATI_Catalyst_driver | here]]<br />
<br />
{{Warning| The proprietary ATI driver supports only R600 and newer devices (that means, HD2xxx and newer). Older series cards (X1xxx and older) are not supported.}}<br />
<br />
{{Tip|Advanced instructions for ATI configuration can be found in the [[ATI | ATI wiki article]].}}<br />
<br />
====C: Install Input Driver Packages====<br />
The latest X requires you to install drivers for your input devices, keyboard and mouse included. For a complete list of available input drivers,<br />
# pacman -Ss xf86-input | less<br />
<br />
For most users, xf86-input-keyboard and xf86-input-mouse should be sufficient for a basic setup. Use pacman to install your desired drivers for your input devices. e.g.:<br />
# pacman -S xf86-input-keyboard xf86-input-mouse<br />
<br />
===Step 3: Configure X===<br />
<br />
====A: The xorg.conf file====<br />
<br />
/etc/X11/xorg.conf is the main configuration file for your '''X''' Window System, the foundation of your '''G'''raphical '''U'''ser '''I'''nterface. It is a plain text file ordered into sections and subsections. Important sections are ''Files, InputDevice, Module, Monitor, Modes, Screen, Device, and ServerLayout''. Sections can appear in any order and there may be more than one section of each kind, for example, if you have more than one monitor, or if your laptop has a trackpoint as well as a mouse. <br />
<br />
Since X11R7.2 the X.Org X Server features autoconfiguration. Therefore, it can function without an xorg.conf file in many cases. ''If'' the autoconfiguration ''works satisfactorily'' and you do not need to specify special features such as aiglx, compositing and so forth, you may forgo creating an xorg.conf file and continue below with [[#B: Input hotplugging| Input hotplugging]].<br />
<br />
=====Standard xorg.conf generation=====<br />
<br />
Advanced users may wish to manually create their own xorg.conf file. You may also use the <code>/usr/bin/Xorg</code> program with the -configure option to generate a basic config file; As root, do:<br />
# Xorg -configure<br />
This will create a config file at /root/xorg.conf.new <br />
<br />
Copy the file to <code>/etc/X11/</code>:<br />
# cp /root/xorg.conf.new /etc/X11/xorg.conf<br />
<br />
=====Alternative xorg.conf generation=====<br />
<br />
Newer versions of the Xorg Server(>1.6) do not include the /usr/bin/xorgconfig or /usr/bin/xorgcfg scripts. If you run into problems generating/using an xorg.conf file, you might want to consider using this guide.<br />
<br />
See the [[Xorg#Without_xorg.conf|article on X.Org, section "Without xorg.conf"]].<br />
<br />
* Note that if you are in possession of a properly configured xorg.conf under another distribution and with the same Xorg version, you may easily copy it over to your current Arch system's <code>/etc/X11/</code> directory.<br />
<br />
<br />
{{Tip | For Intel graphics card, specific configuration may be necessary to get proper 2D or 3D performance, as stated in [[Intel_Graphics]] wiki article.}}<br />
<br />
====B: Input hotplugging====<br />
<br />
[[Xorg input hotplugging|Input hotplugging]] is supported since the 1.4 version of the X.Org X Server and enabled by default. When enabled, X will utilize hal to allow for the hotplugging and removal of human interface devices without having to restart X. <br />
<br />
{{Warning | Starting the '''X''' server using input hotplugging without the '''HAL''' daemon installed and running may result in the inability to use the mouse and/or keyboard, and the '''X''' server appearing to freeze as a result .}}<br />
<br />
You must decide whether you will use input hotplugging (enabled by default), or disable it. Input hotplugging is convenient for many users, especially those with mobile machines like laptops and netbooks. Other users may wish to disable it in favor of manual or more static device configuration within /etc/xorg.conf.<br />
<br />
{{Tip | See the article on [[Xorg input hotplugging]] for full details.}}<br />
<br />
=====Using input hotplugging=====<br />
<br />
Install HAL, dbus and the evdev input driver:<br />
# pacman -S hal dbus xf86-input-evdev<br />
<br />
Set the keyboard layout (if you do not use a standard US keyboard)<br />
# cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/<br />
# nano /etc/hal/fdi/policy/10-keymap.fdi<br />
Edit the &quot;input.xkb.layout&quot; key and possibly the &quot;input.xkb.variant&quot; key in this file.<br />
<br />
Laptop users will also need the synaptics package to allow X to configure the touchpad:<br />
# pacman -S xf86-input-synaptics<br />
<br />
{{Tip|For instructions on fine tuning or troubleshooting touchpad settings, see the [[Touchpad Synaptics]] article.}}<br />
<br />
<br />
'''The HAL daemon'''<br />
<br />
The hal daemon '''must''' be started '''before''' the '''X''' server:<br />
# /etc/rc.d/hal start<br />
Add the hal daemon to the DAEMONS array in /etc/rc.conf to start it at every boot.<br />
<br />
=====Disable input hotplugging=====<br />
Disabling input hotplugging will skip devices detected by hal and will use the keyboard/mouse configuration from xorg.conf:<br />
# nano /etc/X11/xorg.conf<br />
add the following:<br />
Section &quot;ServerFlags&quot;<br />
Option &quot;AutoAddDevices&quot; &quot;False&quot;<br />
EndSection<br />
<br />
======Set the keyboard layout if not using a standard US keyboard======<br />
Add option lines in the &quot;InputDevice&quot; section of the /etc/X11/xorg.conf file specifying the keyboard layout and variant:<br />
Option &quot;XkbLayout&quot; &quot;be&quot;<br />
Option &quot;XkbVariant&quot; &quot;&quot;<br />
<br />
Alternative method using the setxkbmap command:<br />
# setxkbmap pl <br />
(with the proper keyboard layout instead of <code>pl</code> of course) should switch your keyboard layout in x.<br />
To make this permanent, add this command to <code>/home/<youruser>/.xinitrc</code> before starting the window manager (before command like <code>exec startxfce4</code>).<br />
<br />
==== C: Test X ====<br />
<br />
First, read the warning about input hotplugging in the previous section. At this point, you should have xorg installed, with a suitable video driver and an /etc/X11/xorg.conf configuration file. If you want to test your configuration quickly, to ensure your ability to successfully start '''X''' from the command line before installing a complete desktop environment, you can do so by configuring ~/.xinitrc to invoke '''Xterm'''. Xterm is a very simple terminal emulator which runs in the '''X '''Server environment; it is installed as part of the base xorg packages.<br />
<br />
===== Prepare for the test by configuring ~/.xinitrc=====<br />
<br />
One of the main functions of this file is to dictate what '''X''' Window client is invoked with the '''/usr/bin/startx''' and/or '''/usr/bin/xinit''' program ''on a per-user basis''. (The '''startx''' script is merely a front end to the more versatile '''xinit''' command.) There are vast amounts of additional configurable specifications and commands that may also be added to ~/[[.xinitrc]] as you further customize your system. <br />
{{Note | '''[[.xinitrc]]''' is a so-called 'dot' (.) file. Files in a UNIX filesystem which are preceded with a dot (.) are 'hidden', and will not show up with a regular 'ls' command, usually for the sake of keeping directories tidy. Dot files may be seen by issuing '''ls -a'''. The 'rc' denotes ''Run Commands'' and simply indicates that it is a configuration file. Since it controls how a program runs, it is (although historically incorrect) also said to stand for &quot;Run Control&quot;.}}<br />
<br />
'''startx/xinit''' will start the '''X''' server and clients. To determine the client to run, '''startx/xinit''' will first look to parse a [[.xinitrc]] file in the user's home directory. In the absence of file ~/[[.xinitrc]], it defaults to the global xinitrc in the xinit library directory; /etc/X11/xinit/xinitrc, which defaults to using the TWM window manager. (Hence, if you invoke startx without a ~/[[.xinitrc]] file, a TWM session will start.) Further details in the [[.xinitrc]] wiki entry.<br />
<br />
Switch to your '''''normal, non-root''''' user:<br />
<br />
# su - ''yourusername''<br />
<br />
* /etc/skel/ contains files and directories to provide sane defaults for newly created user accounts. The name '''skel''' is derived from the word '''skeleton''', because the files it contains form the basic structure for users' home directories.<br />
<br />
* Sample .xinitrc provided [[Xinitrc#A_standard_.xinitrc | here]] <br />
Copy the sample xinitrc file from /etc/skel/ to your home directory: <br />
<br />
$ cp /etc/skel/[[.xinitrc]] ~/<br />
Edit the file: <br />
$ nano ~/.xinitrc<br />
and add &quot;<code>exec xterm</code>&quot; so that it looks like this:<br />
<br />
#!/bin/sh<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
#<br />
# exec wmaker<br />
# exec startkde<br />
# exec icewm<br />
# exec blackbox<br />
# exec fluxbox<br />
#<br />
exec xterm<br />
<br />
{{Note | ''Be sure to have only '''one''' uncommented '''exec''' line in ~/.xinitrc'' for now.}}<br />
<br />
Below, we shall edit this file again to specify the appropriate desktop environment/window manager of your choice.<br />
<br />
===== Perform the test =====<br />
<br />
Test your configurations by starting '''X''' as '''normal, non-root''' user, with:<br />
<br />
$ startx<br />
or<br />
$ xinit<br />
<br />
You should have an '''xterm''' session open up. You can test your keyboard and its layout in it. You may have to move your mouse around until it enters the xterm area before you see the mouse cursor or xterm responds to your keyboard.<br />
<br />
If you prove a properly configured /etc/X11/xorg.conf by successfully running the test, you can be assured that your DE/WM of choice will work smoothly.<br />
<br />
Exit Xterm with:<br />
$ exit<br />
{{Tip|Advanced instructions for Xorg configuration can be found in the [[Xorg]] article.}}<br />
<br />
<br />
{{Note| With Xorg 1.6 CTRL-Alt-Backspace has been deprecated and will not work to exit out of this test. A somewhat messy work around is to switch to a different virtual console (CTRL-Alt-F2, for example) and then switch back to the console the test is running in (probably CTRL-Alt-F1). You will then be able to use CTRL-C to kill the X test. You can enable CTRL-Alt-Backspace by editing xorg.conf, as described [http://wiki.archlinux.org/index.php/Xorg#Ctrl-Alt-Backspace_doesn.27t_exit_X here].}}<br />
If the screen goes black, you may still attempt to switch to a different virtual console (CTRL-Alt-F2, for example), and login blindly as root, followed by <Enter>, followed by root's password followed by <enter>. Finally, reboot blindly with:<br />
# reboot<br />
or <br />
# init 6<br />
<br />
=====In case of errors=====<br />
If you have problems starting '''X''', you can look for errors in the /var/log/Xorg.0.log file and on the console output of the virtual console you started '''X''' from. <br />
<br />
'''''If using /etc/X11/xorg.conf'''''<br />
<br />
Inspect the config file:<br />
<br />
# nano /etc/X11/xorg.conf<br />
<br />
The video driver may need to be specified. e.g.:<br />
Section &quot;Device&quot;<br />
<br />
...<br />
Driver &quot;savage&quot;<br />
...<br />
<br />
EndSection<br />
<br />
Horizontal sync and vertical refresh specs under section &quot;Monitor&quot; may need to be added:<br />
Section &quot;Monitor&quot;<br />
Identifier &quot;Monitor0&quot;<br />
VendorName &quot;Monitor Vendor&quot;<br />
ModelName &quot;Monitor Model&quot;<br />
HorizSync 30.0 - 130.0 # Safe for LCD's<br />
VertRefresh 50.0 - 100.0 # Safe for LCD's and most CRT's.<br />
EndSection<br />
(If these specs are unknown, consult the documentation of the computer monitor.)<br />
<br />
Color depth can be specified under section &quot;Screen&quot;:<br />
Section &quot;Screen&quot;<br />
Identifier &quot;Screen0&quot;<br />
Device &quot;Card0&quot;<br />
Monitor &quot;Monitor0&quot;<br />
DefaultDepth 24<br />
(Typically, this will be set to 24 for true color.)<br />
<br />
Also add desired Modes to the &quot;Display&quot; subsection, at least under the Depth 24 header, e.g.:<br />
SubSection &quot;Display&quot;<br />
Viewport 0 0<br />
Depth 24<br />
Modes &quot;1024x768&quot; &quot;800x600&quot; &quot;640x480&quot;<br />
Add the following section, if eye candy which requires the composite extension is desired: <br />
Section &quot;Extensions&quot;<br />
Option &quot;Composite&quot; &quot;Enable&quot;<br />
EndSection<br />
Try the config again, after modifying:<br />
# startx<br />
or<br />
# xinit<br />
'''''Still having trouble? Detailed instructions are in the [[Xorg]] article.'''''<br />
<br />
=====Need Help?=====<br />
<br />
If you are still having trouble after consulting the [[Xorg]] article and need assistance via the Arch forums, be sure to install and use wgetpaste:<br />
<br />
# pacman -S wgetpaste<br />
Use wgetpaste and provide links for the following files when asking for help in your forum post:<br />
* ~/.xinitrc<br />
* /etc/X11/xorg.conf<br />
* /var/log/Xorg.0.log.old<br />
Use wgetpaste like so:<br />
$ wgetpaste </path/to/file><br />
Post the corresponding links given within your forum post. Be sure to provide appropriate hardware and driver information as well.<br />
{{Warning| '''''It is very important to provide detail when troubleshooting X. Please provide all pertinent information as detailed above when asking for assistance on the Arch forums. '''''}}<br />
<br />
==Part IV: Installing and configuring a Desktop Environment ==<br />
While The '''X''' Window System provides the basic framework for building a ''graphical user interface'' (GUI), a '''Desktop Environment''' (DE), works atop and in conjunction with '''X''', to provide a completely functional and dynamic GUI. A DE typically provides a window manager, icons, applets, windows, toolbars, folders, wallpapers, a suite of applications and abilities like drag and drop. The particular functionalities and designs of each DE will uniquely affect your overall environment and experience. Therefore, choosing a DE is a very subjective and personal decision. Choose the best environment for ''your'' needs.<br />
<br />
If you desire a lighter, less demanding GUI to configure manually, you may choose to simply install a '''Window Manager''', or WM. A WM controls the placement and appearance of application windows in conjunction with the X Window System but does NOT include such features as panels, applets, icons, applications, etc., by default.<br />
* Lightweight floating WM's include: [[#Openbox|'''Openbox''']], [[#Fluxbox|'''Fluxbox''']], [[#fvwm2|'''fvwm2''']], [[PekWM|'''pekwm''']], [[Evilwm|'''evilwm''']], '''Windowmaker, and TWM'''.<br />
* If you need something completely different, try a tiling WM like [[Awesome|'''awesome''']], [[Ion3|'''ion3''']], [[Wmii|'''wmii''']], [[Dwm|'''dwm''']], [[Xmonad|'''xmonad''']], or [[Ratpoison|'''ratpoison''']].<br />
<br />
===Step 1: Install Fonts===<br />
At this point, you may wish to save time by installing visually pleasing, true type fonts, before installing a desktop environment/window manager. Dejavu and bitstream-vera are good, general-purpose font sets. You may also want to install the Microsoft font sets, which are especially popular on websites, and may be required for the proper function of Flash animations which feature text.<br />
<br />
Install with:<br />
# pacman -S ttf-ms-fonts ttf-dejavu ttf-bitstream-vera<br />
<br />
Refer to [[Xorg Font Configuration]] for how to configure fonts.<br />
<br />
===Step 2: ~/.xinitrc (again)===<br />
<br />
As '''non-root user''', edit your /home/username/.xinitrc to specify the DE you wish to use. This will allow you to use '''startx/xinit''' from the shell, in the future, to open your DE/WM of choice:<br />
<br />
$ nano ~/.xinitrc<br />
<br />
Uncomment or add the ''''exec''' ..' line of the appropriate desktop environment/window manager. Some examples are below:<br />
<br />
For the Xfce4 desktop environment:<br />
exec startxfce4 <br />
<br />
For the KDE desktop environment:<br />
exec startkde<br />
A '''startkde''' or '''startxfce4''' command starts the KDE or Xfce4 desktop environment. This is exactly the same as entering: <br />
$ xinit /usr/bin/startxfce4<br />
or<br />
$ xinit /usr/bin/starkde<br />
from the shell prompt. Note that such a command does not finish until you logout of the DE. Normally the shell would wait for KDE to finish, then run the next command. The &quot;exec&quot; prefix to this command within the ~/.xinitrc file tells the shell that this is the last command, so the shell does not need to wait to run a subsequent command.<br />
<br />
In the future, after the DE of choice is installed and if trouble with automounting is experienced, try using the following command in ~/.xinitrc instead. (Replace "startxfce4" with the command that is appropriate for your window manager/DE.)<br />
exec ck-launch-session startxfce4<br />
This will ensure the various environment variables are set correctly by starting a clean consolekit session. ConsoleKit is a framework for keeping track of the various users, sessions, and seats present on a system. It provides a mechanism for software to react to changes of any of these items or of any of the metadata associated with them. It works in conjunction with dbus, and other tools.<br />
<br />
Remember to have only one uncommented '''exec''' line in your ~/.xinitrc for now.<br />
<br />
===Step 3: Install a Desktop Environment===<br />
<br />
Continue below, installing the DE/WM of your choice.<br />
<br />
* [[#GNOME|'''GNOME''']]<br />
* [[#KDE|'''KDE''']]<br />
* [[#Xfce|'''Xfce''']]<br />
* [[#LXDE|'''LXDE''']]<br />
* [[#Openbox|'''Openbox''']]<br />
* [[#Fluxbox|'''Fluxbox''']]<br />
* [[#fvwm2|'''fvwm2''']]<br />
<br />
====GNOME====<br />
=====About GNOME=====<br />
The '''G'''NU '''N'''etwork '''O'''bject '''M'''odel '''E'''nvironment. The GNOME project provides two things: The GNOME desktop environment, an intuitive and attractive desktop for end-users, and the GNOME development platform, an extensive framework for building applications that integrate into the rest of the desktop.<br />
<br />
=====Installation=====<br />
Install the base GNOME environment with:<br />
# pacman -S gnome<br />
<br />
Additionally, you can install the extras:<br />
# pacman -S gnome-extra<br />
<br />
It's safe to choose all packages shown in the extra package.<br />
<br />
=====Useful DAEMONS for GNOME=====<br />
Recall from above that a daemon is a program that runs in the background, waiting for events to occur and offering services. Some users prefer to use the '''hal''' daemon. The '''hal''' daemon, among other things, will automate the mounting of disks, optical drives, and USB drives/thumbdrives for use in the GUI. The '''fam''' daemon will allow real-time representation of file alterations in the GUI, allowing instant access to recently installed programs, or changes in the file system. Both '''hal''' and '''fam''' can make life easier for the GNOME user. The hal and fam packages are installed when you install GNOME, but must be invoked to become useful.<br />
<br />
You may want to install a graphical login manager. For GNOME, the '''gdm''' daemon is a good choice. <br />
<br />
As root:<br />
# pacman -S gdm<br />
<br />
Start hal and fam:<br />
# /etc/rc.d/hal start<br />
<br />
# /etc/rc.d/fam start<br />
<br />
Add them to your /etc/rc.conf DAEMONS section, so they will be invoked at boot:<br />
# nano /etc/rc.conf<br />
<br />
DAEMONS=(syslog-ng network crond alsa '''hal fam gdm''')<br />
(If you prefer to log into the console and manually start X, leave out gdm.)<br />
<br />
Then edit your /etc/gdm/custom.conf and in the '''[servers]''' section add:<br />
0=Standard vt7<br />
<br />
As normal user, start X:<br />
$ startx<br />
or<br />
$ xinit<br />
If ~/.xinitrc is not configured for GNOME, you may always start it with '''xinit''', followed by the path to GNOME:<br />
$ xinit /usr/bin/gnome-session<br />
<br />
{{Tip|Advanced instructions for installing and configuring GNOME can be found in the [[Gnome]] article.}}<br />
<br />
Congratulations! Welcome to your GNOME desktop environment on your new Arch Linux system! You may wish to continue by viewing '''[[Beginners Guide Appendix#Tweaks.2FFinishing_touches|Tweaks and finishing touches]]''', or the rest of the information below. You may also be interested in the [[Post Installation Tips]] wiki article.<br />
<br />
=====Eye Candy=====<br />
By default, GNOME does not come with many themes and icons. You may wish to install some more attractive artwork for GNOME:<br />
<br />
A nice gtk (gui widget) theme engine (includes themes) is the murrine engine. Install with:<br />
# pacman -S gtk-engine-murrine<br />
<br />
Optional for more themes:<br />
# pacman -S murrine-themes-collection <br />
<br />
Once it has been installed, select it with System -> Preferences -> Appearance -> Theme tab.<br />
<br />
The Arch Linux repositories also have a few more nice themes and engines. Install the following to see for yourself:<br />
<br />
# pacman -S gtk-engines gtk-aurora-engine gtk-candido-engine gtk-rezlooks-engine<br />
<br />
You can find many more themes, icons, and wallpapers at [http://www.gnome-look.org GNOME-Look].<br />
<br />
====KDE====<br />
=====About KDE=====<br />
The '''K''' '''D'''esktop '''E'''nvironment. KDE is a powerful Free Software graphical desktop environment for GNU/Linux and <tt>UNIX</tt> workstations. It combines ease of use, contemporary functionality, and outstanding graphical design with the technological superiority of <tt>UNIX</tt>-like operating systems.<br />
<br />
=====Installation=====<br />
Choose one of the following, then continue below with '''[[#Useful KDE DAEMONS|Useful KDE DAEMONS]]''': <br />
<br />
1. The package '''kde''' is the official and complete vanilla KDE 4.2 residing under the Arch [extra] repo.<br />
<br />
Install base kde:<br />
# pacman -S kdebase-workspace<br />
Install the whole Desktop Environment: <br />
# pacman -S kde<br />
''or'' <br />
# pacman -S kde-meta<br />
<br />
2. Alternatively, another KDE project exists called '''KDEmod''', part of the Chakra distribution. It is an Arch Linux (and spinoff) exclusive, community-driven package set designed for modularity and offers a choice between KDE 3.5.10 or 4.x.x. KDEmod can be installed with pacman, after adding the proper repositories to /etc/pacman.conf. The project website, including complete installation instructions, can be found at [http://www.chakra-project.org/ http://www.chakra-project.org/].<br />
<br />
=====Useful KDE DAEMONS=====<br />
<br />
Recall from above that a daemon is a program that runs in the background, waiting for events to occur and offering services.<br />
<br />
KDE will require the '''hal''' ('''H'''ardware '''A'''bstraction '''L'''ayer) daemon for optimal functionality. The hal daemon, among other things, will facilitate the automatic mounting of disks, optical drives, and USB drives/thumbdrives for use in the GUI. The hal package is installed when you install xorg-server, but must be invoked to become useful.<br />
<br />
The '''kdm''' daemon is the '''K''' '''D'''isplay '''M'''anager, which provides a '''graphical login''', if desired.<br />
<br />
-----<br />
<br />
Start hal:<br />
# /etc/rc.d/hal start<br />
<br />
{{Note|The hal daemon relies on, and will automatically start, the dbus daemon.}}<br />
Edit your DAEMONS array in /etc/rc.conf:<br />
# nano /etc/rc.conf<br />
Add '''hal''' to your DAEMONS array, to invoke it on boot. If you prefer a graphical login, add '''kdm''' as well: <br />
DAEMONS=(syslog-ng '''hal''' network crond alsa '''kdm''')<br />
{{Note|If you installed KDEmod3 instead of normal KDE, use kdm3 instead of kdm.}}<br />
<br />
*This method will start the system at runlevel 3, (/etc/inittab default, multiuser mode), and then start KDM as a daemon. <br />
<br />
*Some users prefer an alternative method of starting a display manager like KDM on boot by utilizing the /etc/inittab method and starting the system at runlevel 5. See [[Adding a login manager (KDM, GDM, or XDM) to automatically boot on startup]] for more.<br />
<br />
*If you prefer to log into the '''console''' at runlevel 3, and manually start X, leave out kdm, or comment it out with a bang, ( ! ).<br />
<br />
Now try starting your X Server as normal user:<br />
$ startx<br />
or<br />
$ xinit<br />
{{Tip|Advanced instructions for installing and configuring KDE can be found in the [[KDE]] article.}}<br />
<br />
Congratulations! Welcome to your KDE desktop environment on your new Arch Linux system! You may wish to continue by viewing '''[[Beginners Guide Appendix|The Beginners Guide Appendix]]''', or the rest of the information below. You may also be interested in the [[Post Installation Tips]] wiki article.<br />
<br />
====Xfce====<br />
=====About Xfce=====<br />
Xfce is another free software desktop environment for Linux. It aims to be fast and lightweight, while still being visually appealing and easy to use. Xfce is modular and reusable. It consists of separately packaged components that together provide the full functionality of the desktop environment, but which can be selected in subsets to create the user's preferred personal working environment. Xfce is mainly used for its ability to run a modern desktop environment on relatively modest hardware. It is based on the GTK+ 2 toolkit (the same as GNOME). It uses the Xfwm window manager, described below. Its configuration is entirely mouse-driven, and the configuration files are hidden from the casual user.<br />
<br />
=====Installation=====<br />
Install Xfce: <br />
# pacman -S xfce4 <br />
You may also wish to install themes and extras:<br />
# pacman -S xfce4-goodies gtk2-themes-collection<br />
Note: '''xfce4-xfapplet-plugin''' (a plugin that allows the use of GNOME applets in the Xfce4 panel) is part of the '''xfce4-goodies''' group and depends on '''gnome-panel''', which in turn depends on '''gnome-desktop'''. You may wish to take this into consideration before installing, since it represents a significant number of extra dependencies.<br />
<br />
If you get errors about dbus-launch then you need to install dbus aswell:<br />
# pacman -S dbus<br />
<br />
If you wish to admire 'Tips and Tricks' on login, install the '''fortune-mod''' package:<br />
# pacman -S fortune-mod<br />
<br />
=====Useful DAEMONS=====<br />
Recall from above that a daemon is a program that runs in the background, waiting for events to occur and offering services. Some Xfce users prefer to use the '''hal''' daemon. The hal daemon, among other things, will automate the mounting of disks, optical drives, and USB drives/thumbdrives for use in the GUI. The fam daemon will allow real-time representation of file alterations in the GUI, allowing instant access to recently installed programs, or changes in the file system. The hal and fam packages are installed when you install Xfce, but must be invoked to become useful.<br />
<br />
Start hal and fam:<br />
<br />
# /etc/rc.d/hal start<br />
<br />
# /etc/rc.d/fam start<br />
{{Note|The hal daemon relies on, and will automatically start, the dbus daemon.}}<br />
Edit your DAEMONS array in /etc/rc.conf:<br />
# nano /etc/rc.conf<br />
Add '''hal''' and '''fam''' to your DAEMONS array, to invoke them at boot.<br />
<br />
{{Tip|Advanced instructions for installing and configuring Xfce can be found in the [[Xfce]] article.}}<br />
<br />
If you wish to install one, see [[Adding a login manager (KDM, GDM, or XDM) to automatically boot on startup]]. Otherwise you can login in via the console and run:<br />
<br />
$ startxfce4<br />
<br />
Congratulations! Welcome to your Xfce desktop environment on your new Arch Linux system! You may also be interested in the [[Post Installation Tips]] wiki article.<br />
<br />
====LXDE====<br />
=====About LXDE=====<br />
LXDE, (for ''L''ightweight ''X''11 ''D''esktop ''E''nvironment), is a new project focused on providing a modern desktop environment which aims to be lightweight, fast, intuitive and functional while keeping system resource usage low. LXDE is quite different from other desktop environments, since each component of LXDE is a discrete and independent application, and each can be easily substituted by other programs. This modular design eliminates all unnecessary dependencies and provides more flexibility. Details and screenshots available at: http://lxde.org/ <br />
<br />
LXDE provides:<br />
# The OpenBox windowmanager<br />
# PCManFM File manager<br />
# LXpanel system panel<br />
# LXSession session manager<br />
# LXAppearance GTK+ theme switcher<br />
# GPicView image viewer<br />
# Leafpad simple text editor<br />
# XArchiver: Lightweight, fast, and desktop-independent gtk+-based file archiver<br />
# LXNM (still under development): Lightweight network manager for LXDE supporting wireless connections<br />
These lightweight and versatile tools combine for quick setup, modularity and simplicity.<br />
<br />
Install LXDE with: <br />
# pacman -S lxde gamin openbox<br />
<br />
Add:<br />
exec startlxde<br />
*If you experience problems with Policykit or plan on running '''nm-applet''', the following command should be used instead<br />
exec ck-launch-session startlxde<br />
to your ~/.xinitrc and start with ''startx'' or ''xinit''<br />
<br />
{{Tip | Further information available at the [[LXDE]] wiki article.}}<br />
<br />
====*box====<br />
=====Fluxbox=====<br />
Fluxbox is yet another windowmanager for X.<br />
It's based on the Blackbox 0.61.1 code. Fluxbox looks like blackbox and handles styles, colors, window placement and similar things exactly like blackbox (100% theme/style compability).<br />
<br />
Install Fluxbox using <br />
# pacman -S fluxbox fluxconf<br />
<br />
If you use gdm/kdm a new fluxbox session will be automatically added. Otherwise, you should modify your user's .xinitrc and add this to it:<br />
exec startfluxbox <br />
<br />
More information is available in the [[Fluxbox]] article.<br />
<br />
=====Openbox=====<br />
Openbox is a standards compliant, fast, light-weight, extensible window manager.<br />
<br />
Openbox works with your applications, and makes your desktop easier to manage. This is because the approach to its development was the opposite of what seems to be the general case for window managers. Openbox was written first to comply with standards and to work properly. Only when that was in place did the team turn to the visual interface.<br />
<br />
Openbox is fully functional as a stand-alone working environment, or can be used as a drop-in replacement for the default window manager in the GNOME or KDE desktop environments. <br />
<br />
Install openbox using<br />
# pacman -S openbox<br />
Additional configuration tools are also available, if desired:<br />
# pacman -S obconf obmenu<br />
<br />
Once openbox is installed you will get a message to move menu.xml & rc.xml to ~/.config/openbox/ in your home directory:<br />
# su - ''yourusername''<br />
$ mkdir -p ~/.config/openbox/<br />
$ cp /etc/xdg/openbox/rc.xml ~/.config/openbox/<br />
$ cp /etc/xdg/openbox/menu.xml ~/.config/openbox/<br />
<br />
'''rc.xml''' is the main configuration file for OpenBox. It may be manually edited, (or you can use OBconf). '''menu.xml''' configures the right-click menu.<br />
<br />
You may log into OpenBox via graphical login using KDM/GDM, or from the shell using '''startx''', in which case you will need to edit your ~/.xinitrc (as non-root user) and add the following:<br />
<br />
exec openbox-session<br />
<br />
NOTE: If you plan on running dbus (which is required by hal) then make sure your ~/.xinitrc reads:<br />
<br />
exec dbus-launch --exit-with-session openbox-session<br />
<br />
You may also start OpenBox from the shell using '''xinit''':<br />
$ xinit /usr/bin/openbox-session<br />
* Openbox may also be used as the window manager for GNOME, KDE, and Xfce.<br />
For KDM there is nothing left to do; openbox is listed in the sessions menu in KDM.<br />
<br />
Some useful, lightweight programs for OpenBox are:<br />
* PyPanel, Tint2, or LXpanel if you want a panel<br />
* feh if you want to set the background<br />
* ROX if you want a simple file manager (also provides simple icons)<br />
* PcmanFM a lightweight but versatile file manager (also provides desktop icon functionality)<br />
* iDesk (available in [[AUR]]) for providing desktop icons<br />
* Graveman for burning CD's or DVD's<br />
<br />
{{Tip | More information is available in the [[Openbox]] article.}}<br />
<br />
====FVWM2====<br />
FVWM (F Virtual Window Manager) is an extremely powerful ICCCM-compliant multiple virtual desktop window manager for the X Window system. Development is active, and support is excellent. <br />
<br />
Install fvwm2 with<br />
# pacman -S fvwm <br />
<br />
It will install the official version of the WM. However, if you want/need to use some more features than it provides, you can install the patched version from archlinuxfr (see [[Unofficial user repositories]]) or [[AUR]]. To install it from AUR or archlinuxfr repesctively, execute:<br />
$ yaourt -S fvwm-patched<br />
or<br />
# pacman -S fvwm-patched<br />
<br />
fvwm will automatically be listed in kdm/gdm in the sessions menu. Otherwise, add <br />
exec fvwm 2 <br />
<br />
to your user's .xinitrc.<br />
<br />
When you start [[FVWM2]], you will get into the blank configuration. However, when you left-click on the desktop, you will be able to select to configure FVWM. chose wanted modules and you are ready to go. Check out the configs in the http://www.box-look.org. One should also consider checking FVWM forums at http://fvwm.lair.be<br />
<br />
[[SLiM]] is a very good login manager, that does not have many dependencies and acts well with FVWM. Common Applications are similar to those suggested for [[Openbox]] or [[Fluxbox]].<br />
<br />
==Common and Lightweight Applications==<br />
For a list of [[Common Applications]] and [[Lightweight Applications]], visit their respective articles.<br />
<!-- Maybe the beginners' guide shouldn't link to lightweight... --><br />
<br />
=Appendix=<br />
See the [[Beginners' Guide Appendix]]<br />
<!-- vim: set ft=Wikipedia: --></div>
Daenyth
https://wiki.archlinux.org/index.php?title=Beginners%27_guide_old&diff=86219
Beginners' guide old
2009-12-03T21:10:20Z
<p>Daenyth: /* USB stick */ Italics -> <code>. {{Filename}} stuff</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]][[Category:About Arch (English)]]<br />
[[Category:HOWTOs (English)]][[Category:Accessibility (English)]]<br />
{{Article summary start}}<br />
{{Article summary text|Provides a highly detailed, explanatory guide to installing, configuring and using a full-featured Arch Linux system.}}<br />
{{Article summary heading|Languages}}<br />
{{i18n_entry|Česky|Průvodce začátečníka (Česky)}}<br />
{{i18n_entry|简体中文|Arch 新手安装指南 (简体中文)}}<br />
{{i18n_entry|正體中文|Beginner's Guide 新手指南}}<br />
{{i18n_entry|Dansk|Dansk_Begynderguide}}<br />
{{i18n_entry|Deutsch|Beginners Guide (Deutsch)}}<br />
{{i18n_entry|English|Beginners Guide}}<br />
{{i18n_entry|Español|Guía para Principiantes (Español)}}<br />
{{i18n_entry|Français|Manuel_du_Débutant_(Français)}}<br />
{{i18n_entry|Italiano|Beginners Guide (Italiano)}}<br />
{{i18n_entry|Indonesia|Beginners_Guide_(Indonesia)}}<br />
{{i18n_entry|Lietuviškai|Pradedančiųjų gidas (Lietuviškai)}}<br />
{{i18n_entry|Nederlands|Beginners_Guide_(Nederlands)}}<br />
{{i18n_entry|Português Brasil|Guia do Iniciante(Português do Brasil)}}<br />
{{i18n_entry|Português|Guia para Principiantes(Português)}}<br />
{{i18n_entry|Русский|Руководство_для_новичков}}<br />
{{i18n_entry|Türkçe|Başlangıç Rehberi (Türkçe)}}<br />
{{i18n_entry|हिन्दी|नौसिखिया गाइड(हिन्दी)}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Official Arch Linux Install Guide}} (for a more general approach)<br />
{{Article summary wiki|Beginners' Guide Appendix}}<br />
{{Article summary wiki|Post Installation Tips}}<br />
{{Article summary end}}<br />
[http://wiki.archlinux.org/index.php/Category:Accessibility_(English) Accessibility resources available]<!-- Making this a note brakes the format --><br />
==Preface==<br />
=====Everything you ever wanted to know about Arch, but were afraid to ask=====<br />
Welcome. This document will guide you through the process of installing and configuring [[Arch Linux]]; a simple, agile and lightweight GNU/Linux distribution, and <tt>UNIX</tt>-like operating system targeted at competent users. <br />
* Arch Linux requires a certain level of intimate knowledge of its configuration process and of <tt>UNIX</tt>-like system methodology, and for this reason, extra explanatory information is included. <br />
* This guide is aimed at new Arch users, but strives to serve as a strong reference and informative base for all.<br />
<br />
'''Arch Linux distribution highlights:'''<br />
* '''[[The Arch Way | Simple]]''', <tt>UNIX</tt>-like design and philosophy<br />
* Independently Developed Community distro built from scratch and targeted at competent GNU/Linux users<br />
* All packages compiled for '''i686/x86-64'''<br />
* Highly customizable system assembled by the user from the ground up<br />
* '''[[The Arch boot process | BSD-style init]]''' scripts, featuring one centralized configuration file<br />
* '''mkinitcpio''': a simple and dynamic initramfs creator <br />
* '''Rolling Release''' model<br />
* '''[[Pacman]]''' package manager: is written in '''C''', and is fast, lightweight and agile, with a very modest memory footprint<br />
* '''[[ABS]]''': The '''A'''rch '''B'''uild '''S'''ystem, a ports-like package building system, makes it simple to create your own easily-installable Arch packages from source, to use and/or share with the community on the [[AUR]]<br />
* '''[[AUR]]''': The Arch User Repository, offering many thousands of build scripts for Arch from user-provided software packages<br />
<br />
=====License=====<br />
<br />
Arch Linux, pacman, documentation, and scripts are copyright<br />
©2002-2007 by Judd Vinet, ©2007-2009 by Aaron Griffin and are licensed under the GNU General Public License Version 2.<br />
<br />
=====DON'T PANIC !=====<br />
The Arch Linux system is assembled by the ''user'', from the shell, using basic command line tools. This is '''[[The Arch Way]].''' Unlike the more rigid structures of other distributions and installers, there are no default environments nor configurations chosen for you. From the command line, ''you'' will add packages from the Arch repositories using the [[pacman]] tool via your internet connection and manually configure your installation by editing text files until your system is customized to your requirements. You will also manually add non-root user(s) and manage groups and permissions. This method allows for maximum flexibility, choice, and system resource control ''from the base up''.<br />
<br />
Arch Linux is a distribution aimed at competent GNU/Linux users who desire a 'do-it-yourself' approach.<br />
<br />
=====[[The Arch Way]]=====<br />
<br />
'''''The design principles behind Arch are aimed at keeping it [[The Arch Way|simple]].'' '''<br />
<br />
'Simple', in this context, shall mean 'without unnecessary additions, modifications, or complications'. In short; an elegant, minimalist approach.<br />
<br />
'''Some thoughts to keep in mind as you consider simplicity:'''<br />
<br />
*''&quot; 'Simple' is defined from a technical standpoint, not a usability standpoint. It is better to be technically elegant with a higher learning curve, than to be easy to use and technically [inferior].&quot; -Aaron Griffin''<br />
*''Entia non sunt multiplicanda praeter necessitatem'' or &quot;Entities should not be multiplied unnecessarily.&quot; -Occam's razor. The term ''razor'' refers to the act of shaving away unnecessary complications to arrive at the simplest explanation, method or theory.<br />
*''&quot;The extraordinary part of [my method] lies in its simplicity..The height of cultivation always runs to simplicity.&quot;'' - Bruce Lee<br />
<br />
=====About This Guide=====<br />
<br />
The Arch wiki is an excellent resource and should be consulted for issues [http://wiki.archlinux.org/index.php/Main_Page first]. IRC (freenode #archlinux), and the [http://bbs.archlinux.org/ forums] are also available if the answer cannot be found elsewhere.<br />
<br />
{{Note|Following this guide closely is essential in order to successfully install a properly configured Arch Linux system, so ''please'' read it thoroughly. It is strongly recommended you read each section completely <u>before</u> carrying out the tasks contained.}}<br />
<br />
Since GNU/Linux Distributions are fundamentally 'modular' by design, the guide is logically divided into 4 main components of a desktop <tt>UNIX</tt>-like operating system: <br />
<br />
'''[[#Part I: Install the Base System|Part I: Installing the Base system]]'''<br />
<br />
'''[[#Part II: Configure & Update the New Arch Linux base system|Part II: Configure & Update the New Arch Linux base system]]'''<br />
<br />
'''[[#Part III: Install X and configure ALSA|Part III: Installing X and configuring ALSA]]'''<br />
<br />
'''[[#Part IV: Installing and configuring a Desktop Environment|Part IV: Installing a Desktop Environment]]'''<br />
<br />
<br />
'''''Welcome to Arch!'''''<br />
:'''''Enjoy the installation; take your time and have fun!'''''<br />
<br />
'''''Now, let's get started....'''''<br />
<br />
<br><br />
<br />
==Part I: Install the Base System==<br />
<br />
===Step 1: Obtain the latest Installation media ===<br />
<br />
You can obtain Arch's official installation media from [http://archlinux.org/download/ here]. The latest version is 2009.08 <br />
<br />
*Both the Core and the Netinstall images provide only the necessary packages to create an '''Arch Linux base system'''. ''Note that the Base System does not include a GUI. It is mainly comprised of the GNU toolchain (compiler, assembler, linker, libraries, shell, and utilities), the Linux kernel, and a few extra libraries and modules.''<br />
*Core images facilitate both installing from CD and Net. <br />
*Netinstall images are smaller and provide no packages themselves; the entire system is retrieved via internet.<br />
*The isolinux images are provided for people who experience trouble using the grub version. There are no other differences.<br />
* [[Arch64_FAQ|The Arch64 FAQ]] can help you choose between the 32- and 64-bit versions.<br />
<br />
====CD installer====<br />
Burn the .iso image file to a CD with your preferred CD burner drive and software, and continue with [[#Step 2: Boot Arch Linux Installer | Step 2: Boot Arch Linux Installer]]<br />
{{Note| The quality of optical drives, as well as the CD media itself, vary greatly. Generally, using a slow burn speed is recommended for reliable burns; Some users recommend speeds '''''as low as 4x or 2x.''''' If you are experiencing unexpected behavior from the CD, try burning at the minimum speed supported by your system. }}<br />
<br />
====USB stick====<br />
{{Warning|This will irrevocably destroy all data on your USB stick!}}<br />
<br />
'''<tt>UNIX</tt> Method:'''<br />
<br />
Insert an empty or expendable USB stick, determine its path, and write the .img to the USB stick with the <code>/bin/dd</code> program:<br />
dd if=archlinux-2009.08-''{core|netinstall}''-''{i686|x86_64}''.img of=/dev/sd''x''<br />
where <code>if=</code> is the path to the img file and <code>of=</code> is your USB device. Make sure to use {{Filename|/dev/sd'''x'''}} and not {{Filename|/dev/sd'''x1'''}}.<br />
<br />
'''Check md5sum (optional):'''<br />
<br />
Make a note of the number of records (blocks) read in and written out, then perform the following check:<br />
dd if=/dev/sd''x'' count=''number_of_records'' status=noxfer | md5sum<br />
The md5sum returned should match the md5sum of the downloaded archlinux image file; they both should match the md5sum of the image as listed in the md5sums file in the mirror distribution site.<br />
<br />
'''Windows Method:'''<br />
<br />
Download Disk Imager from https://launchpad.net/win32-image-writer/+download. Insert flash media. Start the Disk Imager and select the image file. Select the Drive letter associated with the flash drive. Click "write".<br />
<br />
Continue with [[#Step 2: Boot Arch Linux Installer | Step 2: Boot Arch Linux Installer]]<br />
<br />
===Step 2: Boot Arch Linux Installer===<br />
Insert the CD or USB stick and boot from it. You may have to<br />
change the boot order in your computer BIOS or press a key (usually DEL, F1, F2, F11 or F12) during the BIOS POST (Power On Self-Test) phase.<br />
<br />
{{Tip|The memory requirements for a basic install are:<br />
* Core : 128 MB RAM x86_64/i686 (all packages selected, with swap partition)<br />
* Netinstall : 128 MB RAM x86_64/i686 (all packages selected, with swap partition)}}<br />
<br />
The main menu should be displayed at this point. Select the preferred choice by using the arrow keys to highlight your choice, and then by pressing Enter.<br />
<br />
Usually, the first item, Boot Archlive, is the preferred selection. However, choose Boot Archlive [legacy IDE] if you have trouble with libata/PATA, or have no SATA (Serial ATA) drives.<br />
<br />
To change GRUB boot options, press '''e'''. Many users may wish to change the resolution of the framebuffer, for more readable console output. Append:<br />
vga=773<br />
to the kernel line, followed by <ENTER>, for a 1024x768 framebuffer. When done, press '''b''' to boot into that selection.<br />
<br />
The system will now boot and present a login prompt. Login as 'root', without the quotes.<br />
<br />
If your system has errors trying to boot from the live CD or there are other '''hardware''' errors, refer to the [[Installation Troubleshooting]] wiki page.<br />
<br />
====Changing the keymap====<br />
If you have a non-US keyboard layout you can interactively choose your keymap/console font with the command:<br />
# km<br />
or use the loadkeys command:<br />
# loadkeys ''layout''<br />
(replace ''layout'' with your keyboard layout such as &quot;<code>fr</code>&quot; or &quot;<code>be-latin1</code>&quot;)<br />
<br />
====Documentation====<br />
The official install guide is conveniently available right on the live system! To access it, change to vc/2 (virtual console #2) with <ALT>+F2, and then invoke <code>/usr/bin/less</code> by typing in the following at the # prompt:<br />
# less /arch/docs/official_installation_guide_en<br />
<code>less</code> will allow you to page through the document. Change back to vc/1 with <ALT>+F1 to follow the rest of the install process.<br />
<br />
Change back to vc/2 at any time if you need to reference the Official Guide as you go thru the installation process.<br />
<br />
{{tip|Please note that the official guide only covers installation and configuration of the base system. Once that is installed, it is strongly recommended that you come back here to the wiki to find out more about post-installation considerations and other related issues.}}<br />
<br />
===Step 3: Start the Installation===<br />
As root, run the installer script from vc/1:<br />
# /arch/setup<br />
<br />
===A: Select an installation source===<br />
After a welcome screen, you will be prompted for an installation source. Choose the appropriate source for the installer you are using.<br />
* If you chose the CORE installer, continue below with [[#B: Set Clock|B: Set Clock]].<br />
* Netinstall only: You shall be prompted to load ethernet drivers manually, if desired. Udev is quite effective at loading the required modules, so you may assume it has already done so. You may verify this by invoking ifconfig -a from vc/3. (Select OK to continue.)<br />
<br />
====Configure Network (Netinstall)====<br />
Available Interfaces will be presented. If an interface and HWaddr ('''H'''ard'''W'''are '''addr'''ess) is listed, then your module has already been loaded. If your interface is not listed, you may probe it from the installer, or manually do so from another virtual console.<br />
<br />
The following screen will prompt you to ''Select the interface, Probe,'' or ''Cancel''. Choose the appropriate interface and continue.<br />
<br />
The installer will then ask if you wish to use DHCP. Choosing Yes will run '''dhcpcd''' to discover an available gateway and request an IP address; Choosing No will prompt you for your static IP, netmask, broadcast, gateway DNS IP, HTTP proxy, and FTP proxy. Lastly, you will be presented with an overview to ensure your entries are correct.<br />
<br />
=====(A)DSL Quickstart for the Live Environment (If you have a pure modem (or router in bridge mode) to connect to your ISP) =====<br />
<br />
Switch to another virtual console (<Alt> + F2), login as root and invoke <br />
# pppoe-setup<br />
If everything is well configured in the end you can connect to your ISP with <br />
# pppoe-start<br />
<br />
Return to first virtual console with <ALT>+F1. Continue with [[#B: Set Clock|B: Set Clock]]<br />
<br />
=====Wireless Quickstart For the Live Environment (If you need wireless connectivity during the installation process)=====<br />
<br />
The wireless drivers and utilities are now available to you in the live environment of the installation media. A good knowledge of your wireless hardware will be of key importance to successful configuration. Note that the following quickstart procedure ''executed at this point in the installation'' will initialize your wireless hardware for use ''in the live environment''. These steps (or some other form of wireless management) must be repeated from the actual installed system after booting into it. <br />
<br />
Also note that these steps are optional if wireless connectivity is unnecessary at this point in the installation; wireless functionality may always be established later.<br />
<br />
The basic procedure will be:<br />
* Switch to a free virtual console, e.g.: <ALT>+F3<br />
* (Optional) Identify the wireless interface and driver module:<br />
# lsmod | grep -i net<br />
* Ensure udev has loaded the driver, and that the driver has created a usable wireless kernel interface with <code>/usr/sbin/iwconfig</code>:<br />
# iwconfig<br />
Example output:<br />
lo no wireless extensions.<br />
eth0 no wireless extensions.<br />
wlan0 unassociated ESSID:""<br />
Mode:Managed Channel=0 Access Point: Not-Associated <br />
Bit Rate:0 kb/s Tx-Power=20 dBm Sensitivity=8/0 <br />
Retry limit:7 RTS thr:off Fragment thr:off<br />
Power Management:off<br />
Link Quality:0 Signal level:0 Noise level:0<br />
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0<br />
Tx excessive retries:0 Invalid misc:0 Missed beacon:0<br />
<code>wlan0</code> is the available wireless interface in the example.<br />
* Bring the interface up with <code>/sbin/ifconfig <interface> up</code>.<br />
An example using the wlan0 interface:<br />
# ifconfig wlan0 up<br />
(Remember, your interface may be named something else, depending on your module (driver) and chipset: wlan0, eth1, etc.)<br />
* If the essid has been forgotten or is unknown, use <code>/sbin/iwlist <interface> scan</code> to scan for nearby networks.<br />
# iwlist wlan0 scan<br />
* Specify the id of the chosen wireless network with iwconfig <interface> essid &quot;<youressid>&quot; key <your_wep_key> (give the essid (the 'network name') of the network in quotes). <br />
* An example using WEP and a hexadecimal key:<br />
# iwconfig wlan0 essid &quot;linksys&quot; key 0241baf34c<br />
* An example using WEP and an ASCII passphrase:<br />
# iwconfig wlan0 essid "linksys" key s:pass1<br />
* An example using an unsecured network:<br />
# iwconfig wlan0 essid "linksys"<br />
* Request an IP address with <code>/sbin/dhcpcd <interface> </code>. e.g.:<br />
# dhcpcd wlan0<br />
* Ensure you can route using <code>/bin/ping</code>:<br />
# ping -c 3 www.google.com<br />
Done.<br />
* For connecting to a network using WPA, consult the [[WPA Supplicant]] article, and continue below.<br />
<br />
======Does the Wireless Chipset require Firmware?======<br />
A small percentage of wireless chipsets also require firmware, in addition to a corresponding driver. If unsure, invoke <code>/usr/bin/dmesg</code> to query the kernel log for a firmware request from the wireless chipset:<br />
# dmesg | grep firmware<br />
Example output from an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
{{Note | '''Wireless chipset firmware packages (for cards which require them) are pre-installed under /lib/firmware in the live environment, (on CD/USB stick) ''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!'' Package selection and installation is covered below. Ensure installation of both your wireless module and firmware during the package selection step! See [[Wireless Setup]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset. This is a very common error.'''}}<br />
<br />
After the initial Arch installation is complete, you may wish to refer to [[Wireless Setup]] to ensure a permanent configuration solution for your installed system.<br />
<br />
Return to vc/1 with <ALT>+F1. Continue with [[#B: Set Clock|B: Set Clock]]<br />
<br />
===B: Set Clock===<br />
* UTC - Choose UTC if running only <tt>UNIX</tt>-like operating system(s).<br />
<br />
* localtime - Choose local if multi-booting with a Microsoft Windows OS.<br />
<br />
===C: Prepare Hard Drive===<br />
<br />
{{Warning|Partitioning hard drives can destroy data. You are strongly cautioned and advised to backup your critical data if applicable.}}<br />
<br />
{{Note|Partitioning may be performed before initiating the Arch installation if desired, by utilizing [http://gparted.sourceforge.net/download.php GParted] or other available tools. If the installation drive has already been partitioned to the required specifications, continue with [[#Set Filesystem Mountpoints| Set Filesystem Mountpoints]]}}<br />
<br />
Verify current disk identities and layout by invoking <code>/sbin/fdisk</code> with the <code>-l</code> (lower-case L) switch.<br />
<br />
Open another virtual console (<ALT>+F3) and enter:<br />
# fdisk -l<br />
Take note of the disk(s)/partition(s) to utilize for the Arch installation.<br />
<br />
Switch back to the installation script with <ALT>+F1<br />
<br />
Select the first menu entry &quot;Prepare Hard Drive&quot;.<br />
* Option 1: Auto Prepare<br />
Auto-Prepare divides the disk into the following configuration:<br />
<br />
* ext2 /boot partition, default size 32MB. ''You will be prompted to modify the size to your requirement.''<br />
* swap partition, default size 256MB. ''You will be prompted to modify the size to your requirement.''<br />
* A Separate / and /home partition, (sizes can also be specified). Available filesystems include ext2, ext3, ext4, reiserfs, xfs and jfs, but note that ''both / and /home shall share the same fs type'' if choosing the Auto Prepare option.<br />
<br />
Be warned that Auto-prepare will completely erase the chosen hard drive. Read the <font color=&quot;red&quot;>warning</font> presented by the installer very carefully, and make sure the correct device is about to be partitioned.<br />
<br />
* Option 2: '''(Recommended)''' Partition Hard Drives (with cfdisk)<br />
<br />
This option will allow for the most robust and customized partitioning solution for your personal needs.<br />
<br />
''At this point, more advanced GNU/Linux users who are familiar and comfortable with manually partitioning may wish to skip down to '''[[#D: Select Packages|D: Select Packages]]''' below.''<br />
<br />
{{Note|If you are installing to a USB flash key, see "[[Installing Arch Linux on a USB key]]".}}<br />
<br />
====Partition Hard Drives====<br />
<br />
=====Partition Info=====<br />
<br />
Partitioning a hard disk drive defines specific areas (the partitions) within the disk, that will each appear and behave as a separate disk and upon which a filesystem may be created (formatted).<br />
*There are 3 types of disk partitions:<br />
#Primary<br />
#Extended<br />
#Logical<br />
'''Primary''' partitions can be bootable, and are limited to 4 partitions per disk or raid volume. If a partitioning scheme requires more than 4 partitions, an '''extended''' partition which will contain '''logical''' partitions will be required.<br />
<br />
Extended partitions are not usable by themselves; they are merely a &quot;container&quot; for logical partitions. If required, a hard disk shall contain only one extended partition; which shall then be sub-divided into logical partitions.<br />
<br />
When partitioning a disk, one can observe this numbering scheme by creating primary partitions sda1 through sda3 followed by creating an extended partition, sda4, and subsequently creating logical partition(s) within the extended partition; sda5, sda6, and so on.<br />
<br />
=====Swap Partition=====<br />
A swap partition is a place on the drive where virtual ram resides, allowing the kernel to easily use disk storage for data that does not fit into physical RAM.<br />
<br />
Historically, the general rule for swap partition size was 2x the amount of physical RAM. Over time, as computers have gained ever larger memory capacities, this rule has become increasingly deprecated. Generally, on machines with up to 512MB RAM, the 2x rule is usually quite sufficient. On machines with 1GB RAM, generally a 1x rule is adequate. If the installation machine provides gratuitous amounts of RAM (more than 1024 MB) it may be possible to completely forget a swap partition altogether, though this is not recommended (see note below). A 1 GB swap partition will be used in this example.<br />
{{Note|If using suspend-to-disk, (hibernate) a swap partition at least '''equal''' in size to the amount of physical RAM is required. Some Arch users even recommend oversizing it beyond the amount of physical RAM by 10-15%, to allow for possible bad sectors.}}<br />
<br />
=====Partition Scheme=====<br />
A disk partitioning scheme is a very personalized preference. Each user's choices will be unique to their own computing habits and requirements. If you would like to dual boot Arch Linux and a Windows operating systems please see [[Windows and Arch Dual Boot]].<br />
<br />
Filesystem candidates for separate partitions include:<br />
<br />
'''/''' (root) ''The root filesystem is the primary filesystem from which all other filesystems stem; the top of the hierarchy. All files and directories appear under the root directory &quot;/&quot;, 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. Therefore, certain directories under / are not themselves candidates for separate partitions. (See warning below).''<br />
<br />
'''/boot''' ''This directory contains 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. /boot is essential for booting, but is unique in that it may still be kept on its own separate partition (if required).''<br />
<br />
'''/home''' ''User data and user specific configuration files for applications are stored in each user's home directory in a file that starts with the '.' character (a &quot;dot file&quot;).''<br />
<br />
'''/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 update/upgrade. Any information that is host-specific or varies with time is stored elsewhere.''<br />
<br />
'''/tmp''' ''directory for programs that require temporary files''<br />
<br />
'''/var''' ''contains variable data; spool directories and files, administrative and logging data, pacman's cache, the ABS tree, etc.''<br />
{{Warning | Besides /boot, directories essential for booting are: ''''''/bin', '/dev', '/etc', '/lib', '/proc' and '/sbin'. Therefore, they must not reside on a separate partition from /.'''''}}<br />
'''''There are several advantages for using discrete filesystems, rather than combining all into one partition''''':<br />
<br />
* Security: Each filesystem may be configured in /etc/fstab as 'nosuid', 'nodev', 'noexec', 'readonly', etc.<br />
* Stability: A user, or malfunctioning program can completely fill a filesystem with garbage if they have write permissions for it. Critical programs, which reside on a different filesystem remain unaffected.<br />
* Speed: A filesystem which gets written to frequently may become somewhat fragmented. (An effective method of avoiding fragmentation is to ensure that each filesystem is never in danger of filling up completely.) Separate filesystems remain unaffected, and each can be defragmented separately as well.<br />
* Integrity: If one filesystem becomes corrupted, separate filesystems remain unaffected.<br />
* Versatility: Sharing data across several systems becomes more expedient when independent filesystems are used. Separate filesystem types may also be chosen based upon the nature of data and usage.<br />
In this example, we shall use separate partitions for /, /var, /home, and a swap partition.<br />
<br />
{{Note | /var contains many small files. This should be taken into consideration when choosing a filesystem type for it, (if creating its own separate partition).}}<br />
<br />
=====How big should my partitions be?=====<br />
This question is best answered based upon individual needs.<br />
You may wish to simply create '''one partition for root and one partition for swap or only one root partition without swap''' or refer to the following examples and consider these guidelines to provide a frame of reference:<br />
* The root filesystem (/) in the example will contain the /usr directory, which can become moderately large, depending upon how much software is installed. 15-20 GB should be sufficient for most users.<br />
<br />
* The /var filesystem will contain, among other data, the [[ABS]] tree and the pacman cache. Keeping cached packages is useful and versatile; it provides the ability to downgrade packages if needed. /var tends to grow in size; the pacman cache can grow large over long periods of time, but can be safely cleared if needed. If you are using an SSD, you may wish to locate your /var on an HDD and keep the / and /home partitions on your SSD to avoid needless read/writes to the SSD. 6-8 Gigs on a desktop system should be sufficient for /var. Servers tend to have extremely large /var filesystems.<br />
<br />
* The /home filesystem is typically where user data, downloads, and multimedia reside. On a desktop system, /home is typically the largest filesystem on the drive by a large margin. Remember that if you chose to reinstall Arch, all the data on your /home partition will be untouched (so long as you have a separate /home partition). <br />
<br />
* An extra 25% of space added to each filesystem will provide a cushion for unforeseen occurrence, expansion, and serve as a preventive against fragmentation.<br />
'''''From the guidelines above, the example system shall contain a ~15GB root (/) partition, ~7GB /var, 1GB swap, and a /home containing the remaining disk space.'''''<br />
<br />
=====Create Partition:cfdisk=====<br />
Start by creating the primary partition that will contain the '''root''', (/) filesystem.<br />
<br />
Choose '''N'''ew -> Primary and enter the desired size for root (/). Put the partition at the beginning of the disk.<br />
<br />
Also choose the '''T'''ype by designating it as '83 Linux'. The created / partition shall appear as sda1 in our example.<br />
<br />
Now create a primary partition for /var, designating it as '''T'''ype 83 Linux. The created /var partition shall appear as sda2<br />
<br />
Next, create a partition for swap. Select an appropriate size and specify the '''T'''ype as 82 (Linux swap / Solaris). The created swap partition shall appear as sda3.<br />
<br />
Lastly, create a partition for your /home directory. Choose another primary partition and set the desired size.<br />
<br />
Likewise, select the '''T'''ype as 83 Linux. The created /home partition shall appear as sda4.<br />
<br />
Example:<br />
<br />
Name Flags Part Type FS Type [Label] Size (MB)<br />
-------------------------------------------------------------------------<br />
sda1 Primary Linux 15440 #root<br />
sda2 Primary Linux 6256 #/var<br />
sda3 Primary Linux swap / Solaris 1024 #swap<br />
sda4 Primary Linux 140480 #/home<br />
<br />
Choose '''W'''rite and type ''''yes''''. Beware that this operation may destroy data on your disk. Choose '''Q'''uit to leave the partitioner.<br />
Choose Done to leave this menu and continue with &quot;Set Filesystem Mountpoints&quot;.<br />
<br />
{{Note | Since the latest developments of the Linux kernel which include the libata and PATA modules, all IDE, SATA and SCSI drives have adopted the sd''x'' naming scheme. This is perfectly normal and should not be a concern.}}<br />
<br />
====Set Filesystem Mountpoints====<br />
First you will be asked for your swap partition. Choose the appropriate partition (sda3 in this example). You will be asked if you want to create a swap filesystem; select yes. Next, choose where to mount the / (root) directory (sda1 in the example). At this time, you will be asked to specify the filesystem type.<br />
<br />
=====Filesystem Types=====<br />
Again, a filesystem type is a very subjective matter which comes down to personal preference. Each has its own advantages, disadvantages, and unique idiosyncrasies. Here is a very brief overview of supported filesystems:<br />
<br />
1. '''ext2''' ''Second Extended Filesystem''- Old, reliable GNU/Linux filesystem. Very stable, but ''without journaling support''. May be inconvenient for root (/) and /home, due to very long fsck's. ''An ext2 filesystem can easily be converted to ext3.'' Generally regarded as a good choice for /boot/.<br />
<br />
2. '''ext3''' ''Third Extended Filesystem''- Essentially the ext2 system, but with journaling support. ext3 is completely compatible with ext2. ''Extremely'' stable, mature, and by far the most widely used, supported and developed GNU/Linux FS.<br />
<br />
'''High Performance Filesystems:'''<br />
<br />
3. '''ext4''' ''Fourth Extended Filesystem''- Backward compatible with ext2 and ext3, Introduces support for volumes with sizes up to 1 exabyte and files with sizes up to 16 terabyte. Increases the 32,000 subdirectory limit in ext3 to 64,000. Offers online defragmentation ability. <br />
{{Note | ext4 is a new filesystem and may have some bugs.}}<br />
<br />
4. '''ReiserFS''' (V3)- Hans Reiser's high-performance journaling FS uses a very interesting method of data throughput based on an unconventional and creative algorithm. ReiserFS is touted as very fast, especially when dealing with many small files. ReiserFS is fast at formatting, yet comparatively slow at mounting. Quite mature and stable. ReiserFS is not actively developed at this time (Reiser4 is the new Reiser filesystem). Generally regarded as a good choice for /var/.<br />
<br />
5. '''JFS''' - IBM's '''J'''ournaled '''F'''ile'''S'''ystem- The first filesystem to offer journaling. JFS had many years of use in the IBM AIX® OS before being ported to Linux. JFS currently uses the least CPU resources of any GNU/Linux filesystem. Very fast at formatting, mounting and fsck's, and very good all-around performance, especially in conjunction with the deadline I/O scheduler. (See [[JFS]].) Not as widely supported as ext or ReiserFS, but very mature and stable.<br />
<br />
6. '''XFS''' - Another early journaling filesystem originally developed by Silicon Graphics for the IRIX OS and ported to Linux. XFS offers very fast throughput on large files and large filesystems. Very fast at formatting and mounting. Generally benchmarked as slower with many small files, in comparison to other filesystems. XFS is very mature and offers online defragmentation ability.<br />
* JFS and XFS filesystems cannot be ''shrunk'' by disk utilities (such as gparted or parted magic)<br />
<br />
===== A note on Journaling=====<br />
All above filesystems, except ext2, utilize [http://en.wikipedia.org/wiki/Journaling_file_system journaling]. Journaling file systems are fault-resilient file systems that use a journal to log changes before they are committed to the file system to avoid metadata corruption in the event of a crash. Note that not all journaling techniques are alike; specifically, only ext3 and ext4 offer ''data-mode journaling'', (though, not by default), which journals ''both'' data ''and'' meta-data (but with a significant speed penalty). The others only offer ''ordered-mode journaling'', which journals meta-data only. While all will return your filesystem to a valid state after recovering from a crash, ''data-mode journaling'' offers the greatest protection against file system corruption and data loss but can suffer from performance degradation, as all data is written twice (first to the journal, then to the disk). Depending upon how important your data is, this may be a consideration in choosing your filesystem type.<br />
<br />
'''''Moving on...'''''<br />
<br />
Choose and create the filesystem (format the partition) for / by selecting '''yes'''. You will now be prompted to add any additional partitions. In our example, sda2 and sda4 remain. For sda2, choose a filesystem type and mount it as /var. Finally, choose the filesystem type for sda4, and mount it as /home. <br />
{{Box Note |If you have not created and do not need a separate /boot partition, you may safely ignore the warning that it does not exist.}} Return to the main menu.<br />
<br />
===D: Select Packages===<br />
<br />
*Core ISO: Choose CD as source and select the appropriate CD drive if more than one exist on the installation machine.<br />
*Netinstall: Select an FTP/HTTP mirror. ''Note that archlinux.org is throttled to 50KB/s''.<br />
<br />
Package selection is split into two stages. First, select the package category:<br />
{{Note | For expedience, all packages in '''base''' are selected by default. Use the space-bar to select and de-select packages.}}<br />
* '''Base''': The minimal base environment. ''Always select it and only remove packages that will not be used.''<br />
* '''Base-devel''': Extra tools such as '''make''', '''automake''' and '''wireless-tools''' as well as wireless firmwares. ''Most beginners should choose to install it, and will probably need it later.<br />
''<br />
After category selection, you will be presented with the full lists of packages, allowing you to fine-tune your selections. Use the space bar to select and unselect.<br />
<br />
{{Note | If you are going to require connection to a wireless network with WPA encryption, consider installing netcfg2 (as well as wireless_tools), which will enable you to do so.}}<br />
<br />
Adter selecting the needed packages, leave the selection<br />
screen and continue to the next step, Install Packages.<br />
<br />
===E: Install Packages===<br />
Next, choose 'Install Packages'. You will be asked if you wish to keep the packages in the pacman cache. If you choose 'yes', you will have the flexibility to [[Downgrade packages|downgrade]] to previous package versions in the future, so this is recommended (you can always clear the cache in the future). The installer script will now install the selected packages, as well as the default Arch 2.6 kernel, to your system.<br />
*Netinstall: The [[Pacman]] package manager will now download and install your selected packages. (See vc/5 for output, vc/1 to return to the installer)<br />
*Core image: The packages will be installed from the CD/USB stick.<br />
<br />
===F: Configure the System===<br />
''Closely following and understanding these steps is of key importance to ensure a properly configured system.''<br />
<br />
*At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system.<br />
<br />
*Previous versions of the installer included [[Hwdetect|hwdetect]] to gather information for your configuration. This has been deprecated, and '''[[Udev|udev]]''' should handle most module loading automatically at boot.<br />
<br />
Now you will be asked which text editor you want to use; choose [[Nano|nano]], [http://joe-editor.sourceforge.net/ joe] or [[Vim|vi]], ('''nano''' is generally considered easiest of the 3). You will be presented with a menu including the main configuration files for your system. <br />
<br />
{{Note | ''It is very important at this point to edit, or at least verify by opening, every configuration file.'' The installer script relies on your input to create these files on your installation. A common error is to skip over these critical steps of configuration.}}<br />
<br />
=====Can the installer handle this more automatically?=====<br />
Hiding the process of system configuration is in direct opposition to '''''[[The Arch Way]]'''''. While it is true that recent versions of the kernel and hardware probing tools offer excellent hardware support and auto-configuration, Arch presents the user all pertinent configuration files during installation for the purposes of ''transparency and system resource control''. By the time you have finished modifying these files to your specifications, you will have learned the simple method of manual Arch Linux system configuration and become more familiar with the base structure, leaving you better prepared to use and maintain your new installation productively.<br />
<br />
'''''Moving on...'''''<br />
<br />
====/etc/rc.conf====<br />
Arch Linux uses the file '''/etc/rc.conf''' as the principal location for system configuration. This one file contains a wide range of configuration information, principally used at system startup. As its name directly implies, it also contains settings for and invokes the /etc/rc* files, and is, of course, sourced ''by'' these files.<br />
<br />
=====LOCALIZATION section=====<br />
* '''LOCALE'''=: This sets your system locale, which will be used by all i18n-aware applications and utilities. You can get a list of the available locales by running 'locale -a' from the command line. This setting's default is fine for US English users.<br />
* '''HARDWARECLOCK'''=: Specifies whether the hardware clock, which is synchronized on boot and on shutdown, stores '''UTC''' time, or '''localtime'''. UTC makes sense because it greatly simplifies changing timezones and daylight savings time. localtime is necessary if you dual boot with an operating system such as Windows, that only stores localtime to the hardware clock.<br />
* '''USEDIRECTISA'''=: Use direct I/O request instead of /dev/rtc for hwclock<br />
* '''TIMEZONE'''=: Specify your TIMEZONE. (All available zones are under /usr/share/zoneinfo/).<br />
* '''KEYMAP'''=: The available keymaps are in /usr/share/kbd/keymaps. Please note that this setting is only valid for your TTYs, not any graphical window managers or '''X'''.<br />
* '''CONSOLEFONT'''=: Available console fonts reside under /usr/share/kbd/consolefonts/ if you must change. The default (blank) is safe.<br />
* '''CONSOLEMAP'''=: Defines the console map to load with the setfont program at boot. Possible maps are found in /usr/share/kbd/consoletrans, if needed. The default (blank) is safe.<br />
* '''USECOLOR'''=: Select &quot;yes&quot; if you have a color monitor and wish to have colors in your consoles.<br />
LOCALE=&quot;en_US.utf8&quot;<br />
HARDWARECLOCK=&quot;localtime&quot;<br />
USEDIRECTISA=&quot;no&quot;<br />
TIMEZONE=&quot;US/Eastern&quot;<br />
KEYMAP=&quot;us&quot;<br />
CONSOLEFONT=<br />
CONSOLEMAP=<br />
USECOLOR=&quot;yes&quot;<br />
<br />
=====HARDWARE Section=====<br />
* '''MOD_AUTOLOAD'''=: Setting this to &quot;yes&quot; will use '''udev''' to automatically probe hardware and load the appropriate modules during boot, (convenient with the default modular kernel). Setting this to &quot;no&quot; will rely on the user's ability to specify this information manually, or compile their own custom kernel and modules, etc.<br />
* '''MOD_BLACKLIST'''=: This has become deprecated in favor of adding blacklisted modules directly to the '''MODULES=''' line below.<br />
* '''MODULES'''=: Specify additional MODULES if you know that an important module is missing. If your system has any floppy drives, add "floppy". If you will be using loopback filesystems, add "loop". Also specify any blacklisted modules by prefixing them with a bang (!). Udev will be forced NOT to load blacklisted modules. In the example, the IPv6 module as well as the annoying pcspeaker are blacklisted.<br />
# Scan hardware and load required modules at boot<br />
MOD_AUTOLOAD=&quot;yes&quot;<br />
# Module Blacklist - Deprecated<br />
MOD_BLACKLIST=()<br />
#<br />
MODULES=(!net-pf-10 !snd_pcsp !pcspkr loop)<br />
<br />
=====NETWORKING Section=====<br />
* '''HOSTNAME'''=:Set your HOSTNAME to your liking.<br />
* '''eth0'''=: 'Ethernet, card 0'. Adjust the interface IP address, netmask and broadcast address ''if'' you are using '''static IP'''. Set eth0=&quot;dhcp&quot; if you want to use '''DHCP'''<br />
* '''INTERFACES'''=: Specify all interfaces here. <br />
* '''gateway'''=: If you are using '''static IP''', set the gateway address. If using '''DHCP''', you can usually ignore this variable, though some users have reported the need to define it.<br />
* '''ROUTES'''=: If you are using static '''IP''', remove the '''!''' in front of 'gateway'. If using '''DHCP''', you can usually leave this variable commented out with the bang (!), but again, some users require the gateway and ROUTES defined. If you experience networking issues with pacman, for instance, you may want to return to these variables.<br />
<br />
====== Example, using a dynamically assigned IP address ('''DHCP''') ======<br />
<br />
HOSTNAME=&quot;arch&quot;<br />
#eth0=&quot;eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255&quot;<br />
eth0=&quot;dhcp&quot;<br />
INTERFACES=(eth0)<br />
gateway=&quot;default gw 192.168.0.1&quot;<br />
ROUTES=(!gateway)<br />
<br />
======Example, using a '''static''' IP address======<br />
<br />
HOSTNAME=&quot;arch&quot;<br />
eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"<br />
INTERFACES=(eth0)<br />
gateway="default gw 192.168.0.1"<br />
ROUTES=(gateway)<br />
<br />
Modify {{Filename|/etc/resolv.conf}} to contain the DNS servers of choice. Example:<br />
<br />
search my.isp.net.<br />
nameserver 4.2.2.1<br />
nameserver 4.2.2.2<br />
nameserver 4.2.2.3<br />
<br />
Various processes can overwrite the contents of {{filename|/etc/resolv.conf}}. For example, by default Arch Linux uses the '''dhcpcd''' DHCP client, which will overwrite the file when it starts. [[Resolv.conf|Various methods]] may be used to preserve the nameserver settings in {{filename|/etc/resolv.conf}}. For example, dhcpcd's configurations file may be edited to prevent the dhcpcd daemon from overwriting the file. To do this, you will need to modify the {{Filename|/etc/conf.d/dhcpcd}} configuration:<br />
<br />
# Arguments to be passed to the DHCP client daemon<br />
# DHCPCD_ARGS="-q"<br />
DHCPCD_ARGS="-C resolv.conf -q"<br />
<br />
{{tip|If using a non-standard MTU size (a.k.a. jumbo frames) is desired AND the installation machine hardware supports them, see the [[Jumbo Frames]] wiki article for further configuration.}}<br />
<br />
=====DAEMONS Section=====<br />
This array simply lists the names of those scripts contained in /etc/rc.d/ which are to be started during the boot process, and the order in which they start. <br />
DAEMONS=(network @syslog-ng netfs @crond)<br />
*If a script name is prefixed with a bang (!), it is not executed.<br />
*If a script is prefixed with an &quot;at&quot; symbol (@), it shall be executed in the background; the startup sequence will not wait for successful completion of each daemon before continuing to the next. (Useful for speeding up system boot). Do not background daemons that are needed by other daemons. For example "mpd" depends on "network", therefore backgrounding network may cause mpd to break.<br />
*Edit this array whenever new system services are installed, if starting them automatically during boot is desired.<br />
<br />
{{Note | This 'BSD-style' init, is the Arch way of handling what other distributions handle with various symlinks to an /etc/init.d directory.}}<br />
<br />
======About DAEMONS======<br />
The [[daemons]] line need not be changed at this time, but it is useful to explain what daemons are, as they will be addressed later in this guide.<br />
A ''daemon'' is a program that runs in the background, waiting for events to occur and offering services. A good example is a webserver that waits for a request to deliver a page (e.g.:httpd) or an SSH server waiting for a user login (e.g.:sshd). While these are full-featured applications, there are also daemons whose work is not that visible. Examples are a daemon which writes messages into a log file (e.g. syslog, metalog), a daemon which lowers the CPU frequency if the system has nothing to do (e.g.:cpufreq), and a daemon which provides a graphical login (e.g.: gdm, kdm). All these programs can be added to the daemons line and will be started when the system boots. Useful daemons will be presented during this guide.<br />
<br />
Historically, the term ''daemon'' was coined by the programmers of MIT's Project MAC. They took the name from ''Maxwell's demon'', an imaginary being from a famous thought experiment that constantly works in the background, sorting molecules. <tt>UNIX</tt> systems inherited this terminology and created the backronym '''d'''isk '''a'''nd '''e'''xecution '''mon'''itor.<br />
<br />
{{Tip|All Arch daemons reside under /etc/rc.d/}}<br />
<br />
====/etc/fstab====<br />
The '''fstab''' (for '''f'''ile '''s'''ystems '''tab'''le) is part of the system configuration listing all available disks and disk partitions, and indicating how they are to be initialized or otherwise integrated into the overall system's filesystem. The '''/etc/fstab''' file is most commonly used by the '''mount''' command. The mount command takes a filesystem on a device, and adds it to the main system hierarchy that you see when you use your system. '''mount -a''' is called from /etc/rc.sysinit, about 3/4 of the way through the boot process, and reads /etc/fstab to determine which options should be used when mounting the specified devices therein. If '''noauto''' is appended to a filesystem in /etc/fstab, '''mount -a''' will not mount it at boot.<br />
<br />
=====An example /etc/fstab=====<br />
# <file system> <dir> <type> <options> <dump> <pass><br />
none /dev/pts devpts defaults 0 0<br />
none /dev/shm tmpfs defaults 0 0<br />
#/dev/cdrom /media/cdrom auto ro,user,noauto,unhide 0 0<br />
#/dev/dvd /media/dvd auto ro,user,noauto,unhide 0 0<br />
#/dev/fd0 /media/fl auto user,noauto 0 0<br />
/dev/sda1 / jfs defaults,noatime 0 1<br />
/dev/sda2 /var reiserfs defaults,noatime,notail 0 2<br />
/dev/sda3 swap swap defaults 0 0<br />
/dev/sda4 /home jfs defaults,noatime 0 2<br />
{{Note | The 'noatime' option disables writing read access times to the metadata of files and may safely be appended to / and /home regardless of your specified filesystem type for increased speed, performance, and power efficiency (see [http://kerneltrap.org/node/14148 here] for more). 'notail' disables the ReiserFS tailpacking feature, for added performance at the cost of slightly less efficient disk usage.}}<br />
<br />
* '''<file system>''': describes the block device or remote filesystem to be mounted. For regular mounts, this field will contain a link to a block device node (as created by mknod which is called by udev at boot) for the device to be mounted; for instance, '/dev/cdrom' or '/dev/sda1'. <br />
{{Note | Rather than the sd''x'' naming scheme, you may choose to use UUID, or other persistent block device naming schemes for consistent device mapping. Due to active developments in the kernel and also udev, the ordering in which drivers for storage controllers are loaded may change randomly, yielding an unbootable system/kernel panic. Nearly every motherboard has several controllers (onboard SATA, onboard IDE), and due to the aforementioned development updates, /dev/sda may become /dev/sdb on the next reboot. (See [[Persistent block device naming| this wiki article]] for more information on persistent block device naming. )}}<br />
<br />
* '''<dir>''': describes the mount point for the filesystem. For swap partitions, this field should be specified as 'swap'; (Swap partitions are not actually mounted.)<br />
<br />
* '''<type>''': describes the type of the filesystem. The Linux kernel supports many filesystem types. (For the filesystems currently supported by the running kernel, see /proc/filesystems). An entry 'swap' denotes a file or partition to be used for swapping. An entry 'ignore' causes the line to be ignored. This is useful to show disk partitions which are currently unused.<br />
<br />
* '''<options>''': describes the mount options associated with the filesystem. It is formatted as a comma separated list of options with no intervening spaces. It contains at least the type of mount plus any additional options appropriate to the filesystem type. For documentation on the available options for non-nfs file systems, see mount(8).<br />
<br />
* '''<dump>''': used by the dump(8) command to determine which filesystems are to be dumped. dump is a backup utility. If the fifth field is not present, a value of zero is returned and dump will assume that the filesystem does not need to be backed up. ''Note that dump is not installed by default.''<br />
<br />
* '''<pass>''': used by the fsck(8) program to determine the order in which filesystem checks are done at boot time. The root filesystem should be specified with a <pass> of 1, and other filesystems should have a <pass> of 2 or 0. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.<br />
<br />
*If you plan on using '''hal''' to automount media such as DVDs, you may wish to comment out the cdrom and dvd entries in preparation for '''hal''', which will be installed later in this guide.<br />
<br />
Expanded information available in the [[Fstab]] wiki entry.<br />
<br />
===='''[[Configuring mkinitcpio | /etc/mkinitcpio]].conf'''====<br />
''Most users will not need to modify this file at this time, but please read the following explanatory information.''<br />
<br />
This file allows further fine-tuning of the initial ram filesystem, or initramfs, (also historically referred to as the initial ramdisk or &quot;initrd&quot;) for your system. The initramfs is a gzipped image that is read by the kernel during boot. 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 from a USB/FW drive). Once the initrramfs loads the proper modules, either manually or through udev, it passes control to the kernel and your boot continues. For this reason, the initramfs 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 common kernel modules will be loaded later on by udev, during the init process.<br />
<br />
'''mkinitcpio''' is the next generation of '''initramfs creation'''. It has many advantages over the old '''mkinitrd''' and '''mkinitramfs''' scripts.<br />
<br />
* It uses '''klibc''' and '''kinit''' which are developed by Linux kernel devs to provide a small and lightweight base for early userspace.<br />
* It can use '''udev''' for hardware autodetection at runtime, thus prevents you from having tons of unnecessary modules loaded.<br />
* Its hook-based init script is easily extendable with custom hooks, which can easily be included in pacman packages without having to modifiy mkinitcpio itself.<br />
* It already supports '''lvm2''', '''dm-crypt''' for both legacy and luks volumes, '''raid''', '''swsusp''' and '''suspend2''' resuming and booting from '''usb mass storage''' devices.<br />
* Many features can be configured from the kernel command line without having to rebuild the image.<br />
* The '''mkinitcpio''' script makes it possible to include the image in a kernel, thus making a self-contained kernel image is possible.<br />
* Its flexibility makes recompiling a kernel unnecessary in many cases.<br />
<br />
If using RAID or LVM on the root filesystem, the appropriate HOOKS must be configured. See the wiki pages for [[Installing with Software RAID or LVM| RAID]] and [[Configuring mkinitcpio | /etc/mkinitcpio]] for more info. If using a non-US keyboard. add the "<code>keymap</code>" hook to load your local keymap during boot. Add the "<code>usbinput</code>" hook if using a USB keyboard, e.g.:<br />
HOOKS="base udev autodetect pata scsi sata filesystems keymap usbinput"<br />
(Otherwise, if boot fails for some reason you will be asked to enter root's password for system maintenance but will be unable to do so.)<br />
<br />
If you need support for booting from USB devices, FireWire devices, PCMCIA devices, NFS shares, software RAID arrays, LVM2 volumes, encrypted volumes, or DSDT support, configure your HOOKS accordingly. <br />
<br />
If doing a CF or SD card install, you may need to add the <code>usbinput</code> HOOK for your system to boot properly. <br />
<br />
''If you are using a US keyboard, and have no need for any of the above HOOKS, editing this configuration should be unnecessary at this point.''<br />
<br />
'''mkinitcpio''' is an Arch innovation developed by Aaron Griffin and Tobias Powalowski with some help from the community.<br />
<br />
==== /etc/modprobe.d/modprobe.conf====<br />
<br />
This file can be used to set special configuration options for the kernel modules. It is unnecessary to configure this file at this time.<br />
<br />
====/etc/resolv.conf (for Static IP)====<br />
The ''resolver'' is a set of routines in the C library that provide access to the Internet Domain Name System (DNS). One of the main functions of DNS is to translate domain names into IP addresses, to make the Web a friendlier place. The resolver configuration file, or /etc/resolv.conf, contains information that is read by the resolver routines the first time they are invoked by a process.<br />
<br />
*''If you are using DHCP, you may safely ignore this file, as by default, it will be dynamically created and destroyed by the dhcpcd daemon. You may change this default behavior if you wish. (See [http://wiki.archlinux.org/index.php/Network#For_DHCP_IP Network]]).''<br />
<br />
If you use a static IP, set your DNS servers in /etc/resolv.conf (nameserver <ip-address>). You may have as many as you wish.<br />
An example, using OpenDNS:<br />
nameserver 208.67.222.222<br />
nameserver 208.67.220.220<br />
<br />
If you are using a router, you will probably want to specify your DNS servers in the router itself, and merely point to it from your '''/etc/resolv.conf''', using your router's IP (which is also your gateway from '''/etc/rc.conf'''), e.g.:<br />
nameserver 192.168.1.1<br />
<br />
If using '''DHCP''', you may also specify your DNS servers in the router, or allow automatic assignment from your ISP, if your ISP is so equipped.<br />
<br />
====/etc/hosts====<br />
This file associates IP addresses with hostnames and aliases, one line per IP address. For each host a single line should be present with the following information:<br />
<IP-address> <hostname> [aliases...]<br />
Add your ''hostname'', coinciding with the one specified in /etc/rc.conf, as an alias, so that it looks like this:<br />
127.0.0.1 localhost.localdomain localhost '''''yourhostname'''''<br />
{{Note |''This format, '''including the 'localhost' and your actual host name''', is required for program compatibility! So, if you have named your computer Archhost, then that line above should look like this:<br />
127.0.0.1 localhost.localdomain localhost Archhost<br />
Errors in this entry may cause poor network performance and/or certain programs to open very slowly, or not work at all. This is a very common error for beginners.''}}<br />
<br />
If you use a static IP, add another line using the syntax: <static-IP> <hostname.domainname.org> <hostname> e.g.:<br />
192.168.1.100 '''''yourhostname'''''.domain.org '''''yourhostname'''''<br />
<br />
{{Tip|For convenience, you may also use /etc/hosts aliases for hosts on your network, and/or on the Web, e.g.:<br />
64.233.169.103 www.google.com g<br />
192.168.1.90 media<br />
192.168.1.88 data<br />
The above example would allow you to access google simply by typing 'g' into your browser, and access to a media and data server on your network by name and without the need for typing out their respective IP addresses.}}<br />
<br />
====/etc/hosts.deny and /etc/hosts.allow====<br />
Modify these configurations according to your needs if you plan on using the [[SSH|ssh]] daemon. The default configuration will reject all incoming connections, not only ssh connections. Edit your '''/etc/hosts.allow '''file and add the appropriate parameters: <br />
<br />
* let everyone connect to you<br />
sshd: ALL<br />
<br />
* restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
* restrict it to your local LAN network (range 192.168.0.0 to 192.168.0.255)<br />
sshd: 192.168.0.<br />
<br />
* OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0<br />
<br />
If you do not plan on using the [[SSH|ssh]] daemon, leave this file at the default, (empty), for added security.<br />
<br />
====/etc/locale.gen====<br />
The '''/usr/sbin/locale-gen''' command reads from '''/etc/locale.gen''' to generate specific locales. They can then be used by '''glibc''' and any other locale-aware program or library for rendering text, correctly displaying regional monetary values, time and date formats, alphabetic idiosyncrasies, and other locale-specific standards. The ability to setup a default locale is a great built-in privilege of using a <tt>UNIX</tt>-like operating system.<br />
<br />
By default /etc/locale.gen is an empty file with commented documentation. Once edited, the file remains untouched. '''locale-gen''' runs on every '''glibc''' upgrade, generating all the locales specified in /etc/locale.gen.<br />
<br />
Choose the locale(s) you need (remove the # in front of the lines you want), e.g.:<br />
en_US ISO-8859-1<br />
en_US.UTF-8 <br />
<br />
The installer will now run the locale-gen script, which will generate the locales you specified. You may change your locale in the future by editing /etc/locale.gen and subsequently running 'locale-gen' as root.<br />
<br />
{{Note |'''''If you fail to choose your locale, this will lead to a &quot;The current locale is invalid...&quot; error. This is perhaps the most common mistake by new Arch users, and also leads to the most commonly asked questions on the forum.'''''}}<br />
<br />
====Pacman-Mirror====<br />
Choose a mirror repository for '''pacman'''. <br />
*''archlinux.org is throttled, limiting downloads to 50KB/s''<br />
<br />
====Root password====<br />
Finally, set a root password and make sure that you remember it later. Return to the main menu and continue with installing bootloader.<br />
<br />
===G: Install Bootloader===<br />
Because we have no secondary operating system in our example, we will need a bootloader. [http://www.gnu.org/software/grub/ GNU GRUB] is the recommended bootloader. Alternatively, you may choose [http://lilo.go.dyndns.org/ LILO].<br />
<br />
====GRUB====<br />
The provided '''GRUB''' configuration ('''/boot/grub/menu.lst''') should be sufficient, but verify its contents to ensure accuracy (specifically, ensure that the root (/) partition is specified by UUID on line 3). You may want to alter the resolution of the console by adding a vga=<number> kernel argument corresponding to your desired virtual console resolution. (A table of resolutions and the corresponding numbers is printed in the menu.lst.)<br />
<br />
Example: <br />
title Arch Linux (Main)<br />
root (hd0,0) <br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro vga=773<br />
initrd /boot/kernel26.img<br />
{{Note | ''The linux kernel, 'vmlinuz', is so named because it incorporated '''v'''irtual '''m'''emory capability early in its development. The '''z''' denotes a zipped (compressed) image.''}}<br />
<br />
Explanation:<br />
<br />
Line 1: '''title''': A printed menu selection. &quot;Arch Linux (Main)&quot; will be printed on the screen as a menu selection.<br />
<br />
Line 2: '''root''': '''GRUB''''s root; the drive and partition where the kernel (/boot) resides, according to system BIOS. (More accurately, where GRUB's stage2 file resides). '''NOT necessarily the root''' (/) file system, as they can reside on separate partitions. GRUB's numbering scheme starts at 0, and uses an hd''x,x'' format regardless of IDE or SATA, and enclosed within parentheses. <br />
<br />
The example indicates that /boot is on the first partition of the first drive, according to BIOS, or, (hd0,0).<br />
<br />
Line 3: '''kernel''': This line specifies:<br />
<br />
* The path and filename of the kernel '''''relative to GRUB's root'''''.<br />
In the example, /boot is merely a directory residing on the same partition as / and '''vmlinuz26''' is the kernel filename; '''/boot/vmlinuz26'''. ''If /boot were on a separate partition, the path and filename would be simply '''/vmlinuz26''', being relative to '''GRUB''''s root.'' <br />
<br />
* The root= argument to the kernel statement specifies the partition containing the root (/) directory in the booted system, (more accurately, the partition containing '''/sbin/init'''). <br />
<br />
*An easy way to distinguish the 2 appearances of 'root' in /boot/grub/menu.lst is to remember that the first root statement ''informs GRUB where the kernel resides'', whereas the second root= kernel argument ''tells the kernel where the root filesystem (/) resides''.<br />
<br />
* Kernel options. <br />
<br />
In our example, '''ro''' mounts the filesystem as read only during startup, (usually a safe default; you may wish to change this in case it causes problems booting) and the '''&quot;vga=773&quot;''' argument will give a 1024x768 framebuffer with 256 color depth.<br />
<br />
Line 4: '''initrd''': (For Initial RAM disk) The path and filename of the initial RAM filesystem '''relative to GRUB''''s root. Again, in the example, /boot is merely a directory residing on the same partition as / and '''kernel26.img''' is the initrd filename; '''/boot/kernel26.img'''. ''If /boot were on a separate partition, the path and filename would be simply '''/kernel26.img''', being relative to '''GRUB''''s root.'' <br />
<br />
Install the '''GRUB''' bootloader (to the master boot record, sda in our example).<br />
{{tip|For more details, see the [[GRUB]] wiki page.}}<br />
<br />
===H: Reboot===<br />
That's it; You have configured and installed your Arch Linux base system. Exit the install, and reboot:<br />
# reboot<br />
(Be sure to remove the installer CD)<br />
<br />
==Part II: Configure & Update the New Arch Linux base system==<br />
Your new Arch Linux system will boot up and finish with a login prompt (you may want to change the boot order in your '''BIOS''' back to booting from hard disk).<br />
<br />
'''Congratulations, and welcome to your new Arch Linux base system!'''<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready for customization. From here, you may build this elegant set of tools into whatever you wish or require for your purposes. <br />
<br />
Login with the root account. We will configure pacman and update the system as root, then add a normal user. <br />
{{Note |Virtual consoles 1-6 are available. You may switch between them with ALT+F1...F6}}<br />
<br />
===Step 1: Configuring the network (if necessary)===<br />
*''This section will assist you in configuring most types of networks, if your network configuration is not working for you.''<br />
<br />
If you properly configured your system, you should have a working network. Try to ping www.google.com to verify this.<br />
# ping -c 3 www.google.com<br />
<br />
''If you have successfully established a network connection, continue with '''[[#Step 2: Update, Sync and Upgrade the system with pacman|Update, Sync and Upgrade the system with pacman]]'''.''<br />
<br />
If, after trying to ping www.google.com, an &quot;unknown host&quot; error is received, you may conclude that your network is not properly configured. You may choose to double-check the following files for integrity and proper settings:<br />
<br />
'''/etc/rc.conf''' # Specifically, check your HOSTNAME= and NETWORKING section for typos and errors.<br />
<br />
'''/etc/hosts''' # Double-check your format. (See above.)<br />
<br />
'''/etc/resolv.conf''' # If you are using a static IP. If you are using DHCP, this file will be dynamically created and destroyed by default, but can be changed to your preference. (See [[Network]].)<br />
<br />
{{Tip|Advanced instructions for configuring the network can be found in the [[Network]] article.}}<br />
<br />
====Wired LAN====<br />
<br />
Check your Ethernet with<br />
# ifconfig -a<br />
All interfaces will be listed. You should see an entry for eth0, or perhaps eth1. <br />
*'''Static IP'''<br />
<br />
If required, you can set a new static IP with:<br />
# ifconfig eth0 <ip address> netmask <netmask> up <br />
and the default gateway with<br />
# route add default gw <ip address of the gateway><br />
Verify that /etc/resolv.conf contains your DNS server and add it if it is missing. <br />
Check your network again with ping www.google.com. If everything is working now, adjust /etc/rc.conf as described above for static IP. <br />
*'''DHCP'''<br />
If you have a DHCP server/router in your network try:<br />
# dhcpcd eth0<br />
If this is working, adjust /etc/rc.conf as described above, for dynamic IP.<br />
<br />
====Wireless LAN====<br />
* Ensure the driver has created a usable interface:<br />
# iwconfig<br />
* Bring the interface up with <code>ifconfig <interface> up</code>. e.g.:<br />
# ifconfig wlan0 up<br />
* (Optional) Scan for available access points:<br />
# iwlist wlan0 scan | less<br />
* Specify the id of the wireless network with <code>iwconfig <interface> essid <youressid></code>. Or, if using WEP; <code>iwconfig <interface> essid <youressid> key <yourwepkey></code>, e.g.:<br />
# iwconfig wlan0 essid linksys key ABCDEF01234<br />
* Request an IP address with <code>dhcpcd <interface></code>. e.g.:<br />
# dhcpcd wlan0<br />
* Ensure you can route:<br />
$ ping -c 3 www.google.com<br />
Done.<br />
<br />
Detailed setup guide: [[Wireless Setup]]<br />
<br />
====Analog Modem====<br />
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.<br />
Tip: Read [[Dialup without a dialer HOWTO]].<br />
<br />
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 [http://www.linmodems.org/ LinModem] homepage.<br />
<br />
====ISDN====<br />
<br />
Setting up ISDN is done in three steps:<br />
# Install and configure hardware<br />
# Install and configure the ISDN utilities<br />
# Add settings for your ISP <br />
<br />
The current Arch stock kernels include the necessary ISDN modules, meaning that you will not need to recompile your kernel unless you're about to use rather odd ISDN hardware. After physically installing your ISDN card in your machine or plugging in your USB ISDN-Box, you can try loading the modules with modprobe. Nearly all passive ISDN PCI cards are handled by the hisax module, which needs two parameters: type and protocol. You must set protocol to '1' if your country uses the 1TR6 standard, '2' if it uses EuroISDN (EDSS1), '3' if you're hooked to a so-called leased-line without D-channel, and '4' for US NI1.<br />
<br />
Details on all those settings and how to set them is included in the kernel documentation, more specifically in the isdn subdirectory, and available online. The type parameter depends on your card; a list of all possible types can be found in the README.HiSax kernel documentation. Choose your card and load the module with the appropriate options like this:<br />
<br />
# modprobe hisax type=18 protocol=2<br />
<br />
This will load the hisax module for my ELSA Quickstep 1000PCI, being used in Germany with the EDSS1 protocol. You should find helpful debugging output in your /var/log/everything.log file, in which you should see your card being prepared for action. Please note that you will probably need to load some USB modules before you can work with an external USB ISDN Adapter.<br />
<br />
Once you have confirmed that your card works with certain settings, you can add the module options to your /etc/modprobe.conf:<br />
<br />
alias ippp0 hisax<br />
options hisax type=18 protocol=2<br />
<br />
Alternatively, you can add only the options line here, and add hisax to your MODULES array in the rc.conf. It's your choice, really, but this example has the advantage that the module will not be loaded until it's really needed.<br />
<br />
That being done, you should have working, supported hardware. Now you need the basic utilities to actually use it!<br />
<br />
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.<br />
<br />
After you have 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.<br />
<br />
If you set up everything correctly, you should now be able to establish a dial-up connection with<br />
# isdnctrl dial ippp0<br />
as root. If you have any problems, remember to check the logfiles!<br />
<br />
====DSL (PPPoE)====<br />
<br />
These instructions are relevant to you only 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.<br />
<br />
Before you can use your DSL online connection, you will have to physically install the network card that is supposed to be connected to the DSL-Modem into your computer. After adding your newly installed network card to the modules.conf/modprobe.conf or the MODULES array, you should install the rp-pppoe package and run the pppoe-setup script to configure your connection. After you have entered all the data, you can connect and disconnect your line with<br />
<br />
# /etc/rc.d/adsl start<br />
<br />
and<br />
<br />
# /etc/rc.d/adsl stop<br />
<br />
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' at boot, add adsl to your DAEMONS array, and put a ! before the network entry, since the network is handled by adsl now.<br />
<br />
===Step 2: Update, Sync, and Upgrade the system with [[pacman]]===<br />
Now we will update the system using [[pacman]]. <br />
<br />
====What is pacman ?====<br />
[[Pacman]] is the '''pac'''kage '''man'''ager of Arch Linux. Pacman is written in ''C'' and is designed from the ground up to be lightweight with a very modest memory footprint, fast, simple, and versatile. It manages your entire package system and handles installation, removal, package downgrade (through cache), custom compiled package handling, automatic dependency resolution, remote and local searches and much more. Pacman's output is streamlined, very readable and provides ETA for each package download. Arch uses the .tar.gz package format, which further enhances pacman's speed; Gzipped tarballs, though slightly larger, are decompressed many times faster than their Bzipped counterparts, and are therefore installed much more expediently. <br />
<br />
We will use pacman to download software packages from remote repositories and install them onto your system.<br />
<br />
Pacman is the most important tool in your Arch Linux toolbox for building the base system into whatsoever you please.<br />
<br />
====Package Repositories and /etc/pacman.conf====<br />
Arch currently offers the following 4 repositories readily accessible through pacman:<br />
<br />
'''[core]'''<br />
<br />
The simple principle behind [core] is to provide only one of each necessary tool for a base Arch Linux system; The GNU toolchain, the Linux kernel, one editor, one command line browser, etc. (There are a few exceptions to this. For instance, both vi and nano are provided, allowing the user to choose one or both.) It contains all the packages that MUST be in perfect working order to ensure the system remains in a usable state. These are the absolute system-critical packages. <br />
* Developer maintained<br />
* All binary packages<br />
* pacman accessible <br />
*''The Core installation media simply contains an installer script, and a snapshot of the core repository at the time of release.''<br />
<br />
'''[extra]'''<br />
<br />
The [extra] repository contains all Arch packages that are not themselves necessary for a base Arch system, but contribute to a more full-featured environment. '''X''', KDE, and Apache, for instance, can be found here. <br />
* Developer maintained<br />
* All binary packages<br />
* pacman accessible<br />
'''[testing]'''<br />
<br />
The [testing] repository contains packages that are candidates for the [core] or [extra] repositories. New packages go into [testing] if:<br />
<br />
<nowiki>*</nowiki> they are expected to break something on update and need to be tested first.<br />
<br />
<nowiki>*</nowiki> they require other packages to be rebuilt. In this case, all packages that need to be rebuilt are put into [testing] first and when all rebuilds are done, they are moved back to the other repositories. <br />
* Developer maintained<br />
* All binary packages<br />
* pacman accessible<br />
{{Note|* [testing] is the only repository that can have name collisions with any of the other official repositories. Therefore, if enabled, [testing] must be the first repo listed in <code>pacman.conf</code>.}}<br />
<br />
{{Warning|Only experienced users should use [testing].}}<br />
<br />
'''[community]'''<br />
<br />
The [community] repository is maintained by the ''Trusted Users (TUs)'' and is simply the binary branch of the ''Arch User Repository ([[AUR]])''. It contains binary packages which originated as PKGBUILDs from ''AUR'' [unsupported] that have acquired enough votes and were adopted by a ''TU''. Like all repos listed above, [community] may be readily accessed by pacman.<br />
* TU maintained<br />
* All binary packages<br />
* pacman accessible<br />
<br />
'''AUR (unsupported)'''<br />
<br />
The '''[[AUR]]''' also contains the '''unsupported''' branch, which cannot be accessed directly by pacman*. '''AUR''' [unsupported] does not contain binary packages. Rather, it provides more than sixteen thousand PKGBUILD scripts for building packages from source, that may be unavailable through the other repos. When an AUR unsupported package acquires enough popular votes, it may be moved to the AUR [community] binary repo, if a TU is willing to adopt and maintain it there.<br />
* TU maintained<br />
* All PKGBUILD bash build scripts<br />
* '''''Not''''' pacman accessible by default<br />
<br />
<nowiki>*</nowiki> pacman wrappers ('''''[[AUR Helpers]]''''') can help you seamlessly access AUR.<br />
<br />
'''/etc/pacman.conf'''<br />
<br />
pacman will attempt to read /etc/pacman.conf each time it is invoked. This configuration file is divided into sections, or repositories. Each section defines a package [[Official Repositories|repository]] that pacman can use when searching for packages. The exception to this is the options section, which defines global options.<br />
<br />
Note that the defaults should work, so modifying at this point may be unnecessary, but verification is always recommended. Further info available in the [[Mirrors]] article.<br />
# nano /etc/pacman.conf<br />
Example:<br />
#<br />
# /etc/pacman.conf<br />
#<br />
# See the pacman.conf(5) manpage for option and repository directives<br />
<br />
#<br />
# GENERAL OPTIONS<br />
#<br />
[options]<br />
# The following paths are commented out with their default values listed.<br />
# If you wish to use different paths, uncomment and update the paths.<br />
#RootDir = /<br />
#DBPath = /var/lib/pacman/<br />
#CacheDir = /var/cache/pacman/pkg/<br />
#LogFile = /var/log/pacman.log<br />
HoldPkg = pacman glibc<br />
# If upgrades are available for these packages they will be asked for first<br />
SyncFirst = pacman<br />
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u<br />
#XferCommand = /usr/bin/curl %u > %o<br />
<br />
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup<br />
#IgnorePkg =<br />
#IgnoreGroup =<br />
<br />
#NoUpgrade =<br />
#NoExtract =<br />
<br />
# Misc options (all disabled by default)<br />
#NoPassiveFtp<br />
#UseSyslog<br />
#ShowSize<br />
#UseDelta<br />
#TotalDownload<br />
#<br />
# REPOSITORIES<br />
# - can be defined here or included from another file<br />
# - pacman will search repositories in the order defined here<br />
# - local/custom mirrors can be added here or in separate files<br />
# - repositories listed first will take precedence when packages<br />
# have identical names, regardless of version number<br />
# - URLs will have $repo replaced by the name of the current repo<br />
#<br />
# Repository entries are of the format:<br />
# [repo-name]<br />
# Server = ServerName<br />
# Include = IncludePath<br />
#<br />
# The header [repo-name] is crucial - it must be present and<br />
# uncommented to enable the repo.<br />
# <br />
<br />
# Testing is disabled by default. To enable, uncomment the following<br />
# two lines. You can add preferred servers immediately after the header,<br />
# and they will be used before the default mirrors.<br />
#[testing]<br />
#Include = /etc/pacman.d/mirrorlist<br />
<br />
[core]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
[extra]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist <br />
<br />
[community]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
# An example of a custom package repository. See the pacman manpage for<br />
# tips on creating your own repositories.<br />
#[custom]<br />
#Server = file:///home/custompkgs<br />
<br />
Enable all desired repositories (remove the # in front of the 'Include =' and '[repository]' lines).<br />
<br />
<br />
*'''''When choosing repos, be sure to uncomment both the repository header lines in [brackets] as well as the 'Include =' lines. Failure to do so will result in the selected repository being omitted! This is a very common error.'' '''<br />
<br />
====/etc/pacman.d/mirrorlist ====<br />
Defines pacman repo mirrors and priorities.<br />
<br />
'''Build a mirrorlist using the rankmirrors script'''<br />
<br />
<code>/usr/bin/rankmirrors</code> is a python script which will attempt to detect the mirrors which are closest to the installation machine based on the mirrors specified in /etc/pacman.d/mirrorlist. Faster mirrors will dramatically improve pacman performance, and the overall Arch Linux experience. This script may be run periodically, especially if the chosen mirrors provide inconsistent throughput and/or updates.<br />
<br />
First, use pacman to install python:<br />
# pacman -Sy python <br />
'''cd''' to the /etc/pacman.d/ directory:<br />
# cd /etc/pacman.d<br />
Backup the existing /etc/pacman.d/mirrorlist:<br />
# cp mirrorlist mirrorlist.backup<br />
Edit mirrorlist.backup and uncomment all mirrors on the same continent or within geographical proximity to test with rankmirrors.<br />
# nano mirrorlist.backup<br />
Run the script against the mirrorlist.backup with the -n switch and redirect output to a new /etc/pacman.d/mirrorlist file:<br />
# rankmirrors -n 6 mirrorlist.backup > mirrorlist<br />
'''-n 6''': rank the 6 fastest mirrors<br />
<br />
'''Force pacman to refresh the package lists'''<br />
<br />
After creating/editing /etc/pacman.d/mirrorlist, (manually or by <code>/usr/bin/rankmirrors</code>) issue the following command:<br />
# pacman -Syy<br />
Passing two --refresh or -y flags forces pacman to refresh all package lists even if they are considered to be up to date. Issuing pacman -Syy ''whenever a mirror is changed'', is good practice and will avoid possible headaches.<br />
<br />
====Mirrorcheck for up-to-date packages====<br />
Some of the official mirrors may contain packages that are out-of-date. [http://users.archlinux.de/~gerbra/mirrorcheck.html ArchLinux Mirrorcheck] reports various aspects about the mirrors such as, those experiencing network problems, data collection problems, reports the last time they have been synced, etc.<br />
<br />
One may wish to manually inspect the mirrors in the /etc/pacman.d/mirrorlist insuring that it only contains up-to-date mirrors if having the latest package versions is a priority.<br />
<br />
====Ignoring packages====<br />
After executing the command &quot;pacman -Syu&quot;, the entire system will be updated. It is possible to prevent a package from being upgraded. A typical scenario would be a package for which an upgrade may prove problematic for the system. In this case, there are two options; indicate the package(s) to skip in the pacman command line using the --ignore switch (do pacman -S --help for details) or permanently indicate the package(s) to skip in the /etc/pacman.conf file in the IgnorePkg array. List each package, with one intervening space :<br />
IgnorePkg = wine <br />
The typical way to use Arch is to use pacman to install all packages unless there is no package available, in which case [[ABS]] may be used. Many user-contributed package build scripts are also available in the [[AUR]]. <br />
<br />
The power user is expected to keep the system up to date with pacman -Syu, rather than selectively upgrading packages. You may diverge from this typical usage as you wish; just be warned that there is a greater chance that things will not work as intended and that it could break your system. The majority of complaints happen when selective upgrading, unusual compilation or improper software installation is performed. Use of '''IgnorePkg''' in /etc/pacman.conf is therefore discouraged, and should only be used sparingly, if you know what you are doing.<br />
<br />
====Ignoring Configuration Files====<br />
In the same vein, you can also &quot;protect&quot; your configuration/system files from being overwritten during &quot;pacman -Su&quot; using the following option in your /etc/pacman.conf<br />
<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
<br />
====Get familiar with pacman====<br />
pacman is the Arch user's best friend. It is highly recommended to study and learn how to use the pacman(8) tool. Try:<br />
$ man pacman<br />
<br />
For more information,please look up the [[pacman]] wiki entries at your leisure.<br />
<br />
====Powerpill, a pacman wrapper script====<br />
Before you continue, consider installing Xyne's powerpill (now in [community]) which is a pacman wrapper script that speeds up package retrieval by using aria2c (an external download helper) for concurrent/segmented downloads. In other words, powerpill pulls packages in parallel effectively speeding up your downloads. This is particularly advantageous on new installs when pulling down hundreds of megs of packages.<br />
<br />
# pacman -S powerpill<br />
<br />
Treat powerpill as pacman as you consider installations, for example, the following will update your system:<br />
<br />
# powerpill -Syu<br />
<br />
See the [[Powerpill]] wiki article for more.<br />
<br />
===Step 3: Update System===<br />
You are now ready to upgrade your entire system. Before you do, read through the [http://www.archlinux.org/news/ news] (and optionally the [http://archlinux.org/pipermail/arch-announce/ announce mailing list]). Often the developers will provide important information about required configurations and modifications for known issues. Consulting these pages before any upgrade is good practice. <br />
<br />
Sync, refresh, and upgrade your entire new system with:<br />
# pacman -Syu<br />
or:<br />
# pacman --sync --refresh --sysupgrade<br />
<br />
pacman will now download a fresh copy of the master package list from the server(s) defined in pacman.conf(5) and perform all available upgrades. (You may be prompted to upgrade pacman itself at this point. If so, say yes, and then reissue the pacman -Syu command when finished.) <br />
<br />
Reboot if a kernel upgrade has occurred. <br />
<br />
{{Note|Occasionally, configuration changes may take place requiring user action during an update; read pacman's output for any pertinent information.}}<br />
<br />
Pacman output is saved in /var/log/pacman.log.<br />
<br />
See [[Package_Management_FAQs|Package Management FAQs]] for answers to frequently asked questions regarding updating and managing your packages.<br />
<br />
=====The Arch rolling release model=====<br />
Keep in mind that Arch is a '''rolling release''' distribution. This means there is never a reason to reinstall or perform elaborate system rebuilds to upgrade to the newest version. Simply issuing '''pacman -Syu''' periodically keeps your entire system up-to-date and on the bleeding edge. At the end of this upgrade, your system is completely current. '''Reboot''' if a kernel upgrade has occurred.<br />
=====Network Time Protocol=====<br />
You may wish to set the system time now using OpenNTPD to sync the local clock to remote NTP servers. OpenNTPD may also be added to the DAEMONS= array in /etc/rc.conf to provide this service at each boot. (See the [[Network Time Protocol]] article.)<br />
<br />
===Step 4: Add a user and setup groups===<br />
<tt>UNIX</tt> is a multi-user environment. You should not do your everyday work using the root account. It is more than poor practice; it is dangerous. Root is for administrative tasks. Instead, add a normal, non-root user account using the <code>/usr/sbin/useradd</code> program:<br />
# useradd -m -G [groups] -s [login_shell] [username] <br />
* '''-m''' Creates user home directory as /home/'''username'''. Within their home directory, a user can write files, delete them, install programs, etc. Users' home directories shall 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 ''user'' (under /home/username) and ''global'' configuration files, (usually under /etc/) the settings in the ''user'' file will prevail. Dotfiles 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.<br />
* '''-G''' A list of supplementary groups which the user is also a member of. ''Each group is separated from the next by a comma, with no intervening spaces''. The default is for the user to belong only to the initial group (users). <br />
* '''-s''' The path and filename of the user´s default login shell.<br />
Useful groups for your non-root user include:<br />
*'''audio''' - for tasks involving sound card and related software<br />
*'''floppy''' - for access to a floppy if applicable<br />
*'''lp''' - for managing printing tasks<br />
*'''optical''' - for managing tasks pertaining to the optical drive(s)<br />
*'''storage''' - for managing storage devices<br />
*'''video''' - for video tasks and hardware acceleration<br />
*'''wheel''' - for using sudo<br />
*'''power''' - used w/ power options (e.g.: shutdown with power button) <br />
A typical desktop system example, adding a user named &quot;archie&quot; specifying bash as the login shell:<br />
# useradd -m -G users,audio,lp,optical,storage,video,wheel,power -s /bin/bash archie<br />
Next, add a password for your new user using <code>/usr/bin/passwd</code>.<br />
<br />
An example for our user, 'archie':<br />
# passwd archie<br />
(You will be prompted to provide the new <tt>UNIX</tt> password.)<br />
<br />
Your new non-root user has now been created, complete with a home directory and a login password.<br />
<br />
'''Alternative method, using <code>/usr/sbin/adduser</code>:'''<br />
<br />
Alternatively, you may use <code>adduser</code>, an interactive user adding program which will prompt you for the above data ''(recommended for beginners)'':<br />
# adduser<br />
'''Deleting the user account:'''<br />
<br />
In the event of error, or if you wish to delete this user account in favor of a different name or for any other reason, use <code>/usr/sbin/userdel</code>:<br />
# userdel -r [username]<br />
* '''-r ''' Files in the user´s home directory will be removed along with the home directory itself and the user´s mail spool.<br />
<br />
If you want to change the name of your user or any existing user, see the [[Change username]] page of the Arch wiki and/or the [[Groups]] and [[User Management]] articles for further information. You may also check the man pages for <code>usermod(8)</code> and <code>gpasswd(8)</code>.<br />
<br />
===Step 5: Install and setup Sudo (Optional)===<br />
There has been a recent update to the vi packages since the latest installation media (2009.08) was created. Therefore, before installing sudo, use the following command to remove the incompatible files:<br />
# rm /usr/bin/{view,rview}<br />
Install Sudo and vim:<br />
# pacman -S sudo vim<br />
To add a user as a sudo user (a &quot;sudoer&quot;), the visudo command must be run as root. If you do not know how to use vi, you may set the EDITOR environment variable to the editor of your choice before running visudo. e.g.:<br />
# EDITOR=nano visudo<br />
If you are comfortable using vi, issue the visudo command without the EDITOR=nano variable:<br />
# visudo<br />
This will open the file /etc/sudoers in a special session of vi. visudo copies the file to be edited to a temporary file, edits it with an editor, (vi by default), and subsequently runs a sanity check. If it passes, the temporary file overwrites the original with the correct permissions. <br />
<br />
{{Warning|Do not edit /etc/sudoers directly with an editor; Errors in syntax can cause annoyances (like rendering the root account unusable). You must use the ''visudo'' command to edit /etc/sudoers.}}<br />
<br />
To give the user full root privileges when he/she precedes a command with &quot;sudo&quot;, add the following line:<br />
USER_NAME ALL=(ALL) ALL<br />
where USER_NAME is the username of the individual.<br />
<br />
For more information, such as sudoer <TAB> completion, see [[Sudo]]<br />
<br />
==Part III: Install X and configure ALSA==<br />
<br />
<br />
===Step 1: Configure sound with alsamixer===<br />
The Advanced Linux Sound Architecture (known by the acronym '''ALSA''') is a Linux kernel component intended to replace the original Open Sound System (OSS) for providing device drivers for sound cards. Besides the sound device drivers, '''ALSA''' also bundles a user space library for application developers who want to use driver features with a higher level API than direct interaction with the kernel drivers.<br />
{{Note| Alsa is included in the Arch mainline kernel and udev will automatically probe your hardware at boot, loading the corresponding kernel module for your audio card. Therefore, your sound should already be working, but upstream sources mute all channels by default.}}<br />
{{Note| OSS4.1 has been released under a free license and is generally considered a significant improvement over older OSS versions. If you have issues with ALSA, or simply wish to explore another option, you may choose OSS4.1 instead. Instructions can be found in [[OSS]]}} <br />
<br />
The alsa-utils package contains the alsamixer userspace tool, which allows configuration of the sound device from the console or terminal.<br />
<br />
By default the upstream kernel sources ship with snd_pcsp, the alsa pc speaker module. snd_pcsp is usually loaded before your &quot;actual&quot; sound card module. In most cases, it will be more convenient if this module is loaded last, as it will allow alsamixer to correctly control the desired sound card.<br />
<br />
To have snd_pcsp load last, add the following to /etc/modprobe.d/modprobe.conf:<br />
options snd-pcsp index=2<br />
<br />
Alternatively, if you do not want snd_pcsp to load at all, blacklist it by adding the following to /etc/rc.conf:<br />
MODULES=(... !snd_pcsp)<br />
<br />
{{Note | You will need to unload all your sound modules and reload them for the changes to take effect. It might be easier to reboot. Your choice. }}<br />
<br />
Install the alsa-utils package:<br />
# pacman -S alsa-utils<br />
Also, you may want to install the alsa-oss package, which wraps applications written for [[OSS]] in a compatibility library, allowing them to work with [[ALSA]]. To install the alsa-oss package:<br />
# pacman -S alsa-oss <br />
Did you add your normal user to the audio group? If not, use <code>/usr/bin/gpasswd</code>. As root do:<br />
# gpasswd -a ''yourusername'' audio<br />
As '''''normal, non-root''''' user, invoke <code>/usr/bin/alsamixer</code>:<br />
# su - ''yourusername'' <br />
'''$''' alsamixer<br />
Unmute the Master and PCM channels by scrolling to them with cursor left/right and pressing '''M'''. Increase the volume levels with the cursor-up key. (70-90 Should be a safe range.) Some machines, (like the Thinkpad T61), have a '''Speaker''' channel which must be unmuted and adjusted as well. Leave alsamixer by pressing ESC. <br />
==== Sound test ====<br />
Ensure your speakers are properly connected, and test your sound configuration as normal user using <code>/usr/bin/aplay</code>:<br />
$ aplay /usr/share/sounds/alsa/Front_Center.wav<br />
You should hear a very eloquent woman say, &quot;Front, center.&quot;<br />
==== Saving the Sound Settings ====<br />
Exit your normal user shell and run <code>/usr/sbin/alsactl</code> as root:<br />
$ exit<br />
# alsactl store<br />
This will create the file '/etc/asound.state', saving the alsamixer settings. <br />
<br />
Also, add the alsa ''daemon'' to your DAEMONS section in /etc/rc.conf to automatically restore the mixer settings at boot.<br />
# nano /etc/rc.conf<br />
DAEMONS=(syslog-ng network crond '''alsa''')<br />
''Note that the alsa daemon merely restores your volume mixer levels on boot up by reading /etc/asound.state. It is separate from the alsa audio library (and kernel level API).''<br />
<br />
Expanded information available in the [[ALSA]] wiki entry.<br />
<br />
===Step 2: Install X===<br />
The '''X''' Window System version 11 (commonly '''X11''', or just simply '''X''') is a networking and display protocol which provides windowing on bitmap displays. It provides the standard toolkit and protocol to build graphical user interfaces (GUIs) on <tt>UNIX</tt>-like operating systems.<br />
<br />
'''X''' provides the basic framework, or primitives, for building GUI environments: drawing and moving windows on the screen and interacting with a mouse and/or keyboard. '''X''' does not mandate the user interface — individual client programs handle this. <br />
<br />
'''X''' is so named because it was preceded by the '''W''' Window System, originally developed at Stanford University. <br />
<br />
====A: The <code>X-Files</code>====<br />
Now we will install the base '''[[Xorg]]''' packages using pacman. This is the first step in building a GUI.<br />
If you plan on using an '''open-source''' video driver, and need 3d acceleration, install the libgl library before installing Xorg:<br />
# pacman -S libgl<br />
''(Proprietary video drivers provide their own gl library implementations.)''<br />
<br />
Install the base packages:<br />
# pacman -S xorg<br />
The 3d utilities glxgears and glxinfo are included in the '''mesa''' package:<br />
# pacman -S mesa<br />
<br />
====B: Install Video Driver Package====<br />
Now we have the base packages we need for running the '''X''' Server. You should add the driver for your graphics card now (e.g. xf86-video-<name>). The easiest way to configure X.org is by installing the correct driver packages first, and then generating /etc/X11/xorg.conf using an autoconfiguration script, like Xorg -configure.<br />
<br />
You will need knowledge of which video chipset your machine has. If you do not know, use the <code>/usr/sbin/lspci</code> program:<br />
# lspci | grep VGA<br />
<br />
If you need a list of all '''open-source''' video drivers, do: <br />
# pacman -Ss xf86-video | less<br />
Here is a list of '''open source''' drivers, and the corresponding video chipsets.<br />
*'''xf86-video-apm''' &mdash; Alliance ProMotion video driver<br />
*'''xf86-video-ark''' &mdash; ark video driver<br />
*'''xf86-video-ati''' &mdash; ATI(AMD) radeon video driver<br />
**'''xf86-video-r128''' &mdash; ATI(AMD) video driver for X.org ati Rage128 video<br />
**'''xf86-video-mach64''' &mdash; ATI(AMD) video driver for X.org mach64 video<br />
**'''xf86-video-radeonhd''' &mdash; ATI(AMD) radeonhd video driver<br />
*'''xf86-video-chips''' &mdash; Chips and Technologies video driver<br />
*'''xf86-video-cirrus''' &mdash; Cirrus Logic video driver<br />
*'''xf86-video-dummy''' &mdash; dummy video driver<br />
*'''xf86-video-fbdev''' &mdash; framebuffer video driver<br />
*'''xf86-video-glint''' &mdash; GLINT/Permedia video driver<br />
*'''xf86-video-i128''' &mdash; Number 0 i128 video driver<br />
*'''xf86-video-i740''' &mdash; Intel i740 video driver<br />
*'''xf86-video-i810''' &mdash; Intel i810/i830/i9xx video drivers (deprecated - use -intel)<br />
*'''xf86-video-intel''' &mdash; Newer Version of Intel i810/i830/i9xx video drivers<br />
*'''xf86-video-intel-legacy''' &mdash; Legacy-driver for older intel cards as 82865G (xf86-video-intel currently crashes with older cards)<br />
*'''xf86-video-imstt''' &mdash; Integrated Micro Solutions Twin Turbo video driver<br />
*'''xf86-video-mga''' &mdash; mga video driver (Matrox Graphics Adapter)<br />
*'''xf86-video-neomagic''' &mdash; neomagic video driver<br />
*'''xf86-video-nv''' &mdash; Nvidia nv video driver<br />
*'''xf86-video-nouveau''' &mdash; Open Source 3D acceleration driver for nVidia cards (experimental), check: [http://nouveau.freedesktop.org/wiki/] for Current Status<br />
*'''xf86-video-openchrome''' &mdash; VIA/S3G UniChrome, UniChrome Pro and Chrome9 video driver<br />
*'''xf86-video-rendition''' &mdash; Rendition video driver<br />
*'''xf86-video-s3''' &mdash; S3 video driver<br />
*'''xf86-video-s3virge''' &mdash; S3 Virge video driver<br />
*'''xf86-video-savage''' &mdash; savage video driver<br />
*'''xf86-video-siliconmotion''' &mdash; siliconmotion video driver<br />
*'''xf86-video-sis''' &mdash; SiS video driver<br />
*'''xf86-video-sisusb''' &mdash; SiS USB video driver<br />
*'''xf86-video-tdfx''' &mdash; tdfx video driver<br />
*'''xf86-video-trident''' &mdash; Trident video driver<br />
*'''xf86-video-tseng''' &mdash; tseng video driver<br />
*'''xf86-video-unichrome''' &mdash; VIA S3 Unichrome video drivers<br />
*'''xf86-video-v4l''' &mdash; v4l video driver<br />
*'''xf86-video-vesa''' &mdash; vesa video driver<br />
*'''xf86-video-vga''' &mdash; VGA 16 color video driver<br />
*'''xf86-video-vmware''' &mdash; vmware video driver<br />
*'''xf86-video-voodoo''' &mdash; voodoo video driver<br />
<br />
'''''Note''''': The '''vesa''' driver is the most generic, and should work with almost any modern video chipset. If you cannot find a suitable driver for your video chipset, vesa ''should'' work.<br />
<br />
Use pacman to install the appropriate video driver for your video card/onboard video. e.g.:<br />
# pacman -S xf86-video-savage<br />
(for the Savage driver.)<br />
<br />
*If you have an NVIDIA or ATI graphics card you may wish to install the proprietary NVIDIA or ATI drivers. '''Installing proprietary video drivers is covered below.'''.<br />
*If you do not want to install the proprietary drivers or do not have an NVIDIA or ATI graphics card, you should skip down to '''[[#Step 3: Configure X|Step 3: Configure X]]'''.<br />
<br />
-----<br />
<br />
<br />
=====NVIDIA Graphics Cards=====<br />
The NVIDIA proprietary drivers are generally considered to be of good quality, and offer 3D performance, whereas the open source '''nv''' driver offers only 2d support at this time. <br />
<br />
Before you configure your Graphics Card you will need to know which driver fits. Arch currently has several different driver packages that each match a certain subset of Cards: <br />
<br />
'''1. nvidia-96xx''' ''slightly newer cards up to the GF 4.''<br />
<br />
'''2. nvidia-173xx''' ''Geforce FX series cards''<br />
<br />
'''3. nvidia''' ''newest GPUs after the GF FX''<br />
<br />
{{Note| Nvidia-71xx series proprietary drivers, which are required by extremely old cards like TNT and TNT2, have been removed because they do not work with the new Xorg that Arch makes use of and nvidia has discontinued support for such. You should use the xf86-video-nv or xf86-video-vesa drivers instead.}}<br />
<br />
Consult the NVIDIA website to see which one is for you. The difference is only for the installation; Configuration works the same with every driver.<br />
<br />
Select and install the appropriate NVIDIA driver ''for your card'', e.g.: <br />
# pacman -S nvidia-96xx<br />
<br />
The NVIDIA package has a utility for updating your existing /etc/X11/xorg.conf for use with the NVIDIA driver:<br />
# nvidia-xconfig<br />
<br />
It also has several options which will further specify the contents and options of the xorg.conf file.<br />
For example,<br />
# nvidia-xconfig --composite --add-argb-glx-visuals<br />
<br />
For more detailed information, see nvidia-xconfig(1).<br />
<br />
Some useful tweaking options in the device section are (beware that these may not work on your system):<br />
Option &quot;RenderAccel&quot; &quot;true&quot;<br />
Option &quot;NoLogo&quot; &quot;true&quot;<br />
Option &quot;AGPFastWrite&quot; &quot;true&quot;<br />
Option &quot;EnablePageFlip&quot; &quot;true&quot;<br />
Make sure all instances of DRI are commented out:<br />
# Load &quot;dri&quot;<br />
Double check your /etc/X11/xorg.conf to make sure your default depth, horizontal sync, vertical refresh, and resolutions are acceptable.<br />
<br />
Update kernel module dependencies using <code>/sbin/depmod</code>:<br />
# depmod -a<br />
(A reboot may be necessary.)<br />
{{Tip|Advanced instructions for NVIDIA configuration can be found in the [[NVIDIA]] article.}}<br />
<br />
You may now continue with '''[[#Step 3: Configure X|Step 3: Configure X]]''' to familiarize yourself further, or continue the installation process with '''[[#C: Test X|Test X]]'''.<br />
<br />
=====ATI Graphics Cards=====<br />
ATI owners have multiple options for drivers. <br />
* The open source '''''radeon''''' driver provided by the '''xf86-video-ati''' package. <br />
** This is the original, reverse-engineered open source driver which fully supports Radeon chipsets up to X1950 (latest R500 chipsets). Cards up to the 9200 series are fully supported, stable, and provide full 2D and 3D acceleration. Cards from 9500 to X1950 feature full 2D acceleration, and stable 3D acceleration, but lack certain features provided by the proprietary driver, (for example, powersaving is still in a testing phase). Cards from HD2xxx (R6xx) to the newest are supported by xf86-video-ati, but only offer 2d support at this time.<br />
* The open source '''''radeonhd''''' driver provided by the '''xf86-video-radeonhd''' package.<br />
** This driver supports ATI R500 chipsets (Radeon X1000 series) and newer. It is written by Novell with specifications provided to the public by AMD. It supports RandR 1.2 and development is currently very active. Therefore, functionality may be inconsistent across the spectrum of cards supported. (Some users report excellent performance and reliability while others experience trouble.) It also supports HDMI, with sound.<br />
* The proprietary '''''fglrx''''' driver provided by the Catalyst package located in the AUR. The proprietary driver is covered below.<br />
The open-source drivers will usually suit most needs and are generally less problematic.<br />
<br />
Install the '''''radeon''''' ATI Driver with<br />
# pacman -S xf86-video-ati libgl ati-dri<br />
Install the '''''radeonhd''''' ATi Driver with<br />
# pacman -S xf86-video-radeonhd libgl ati-dri<br />
<br />
The proprietary ATI driver '''Catalyst''' was once a precompiled package offered by Arch in the <code>extra</code> repository, but as of March 2009, official support has been dropped because of dissatisfaction with the quality and speed of development of the proprietary driver.The catalyst driver is now available in [http://aur.archlinux.org/packages.php?ID=22899 AUR]. Installation information for Catalyst driver is available [[ATI#Proprietary_ATI_Catalyst_driver | here]]<br />
<br />
{{Warning| The proprietary ATI driver supports only R600 and newer devices (that means, HD2xxx and newer). Older series cards (X1xxx and older) are not supported.}}<br />
<br />
{{Tip|Advanced instructions for ATI configuration can be found in the [[ATI | ATI wiki article]].}}<br />
<br />
====C: Install Input Driver Packages====<br />
The latest X requires you to install drivers for your input devices, keyboard and mouse included. For a complete list of available input drivers,<br />
# pacman -Ss xf86-input | less<br />
<br />
For most users, xf86-input-keyboard and xf86-input-mouse should be sufficient for a basic setup. Use pacman to install your desired drivers for your input devices. e.g.:<br />
# pacman -S xf86-input-keyboard xf86-input-mouse<br />
<br />
===Step 3: Configure X===<br />
<br />
====A: The xorg.conf file====<br />
<br />
/etc/X11/xorg.conf is the main configuration file for your '''X''' Window System, the foundation of your '''G'''raphical '''U'''ser '''I'''nterface. It is a plain text file ordered into sections and subsections. Important sections are ''Files, InputDevice, Module, Monitor, Modes, Screen, Device, and ServerLayout''. Sections can appear in any order and there may be more than one section of each kind, for example, if you have more than one monitor, or if your laptop has a trackpoint as well as a mouse. <br />
<br />
Since X11R7.2 the X.Org X Server features autoconfiguration. Therefore, it can function without an xorg.conf file in many cases. ''If'' the autoconfiguration ''works satisfactorily'' and you do not need to specify special features such as aiglx, compositing and so forth, you may forgo creating an xorg.conf file and continue below with [[#B: Input hotplugging| Input hotplugging]].<br />
<br />
=====Standard xorg.conf generation=====<br />
<br />
Advanced users may wish to manually create their own xorg.conf file. You may also use the <code>/usr/bin/Xorg</code> program with the -configure option to generate a basic config file; As root, do:<br />
# Xorg -configure<br />
This will create a config file at /root/xorg.conf.new <br />
<br />
Copy the file to <code>/etc/X11/</code>:<br />
# cp /root/xorg.conf.new /etc/X11/xorg.conf<br />
<br />
=====Alternative xorg.conf generation=====<br />
<br />
Newer versions of the Xorg Server(>1.6) do not include the /usr/bin/xorgconfig or /usr/bin/xorgcfg scripts. If you run into problems generating/using an xorg.conf file, you might want to consider using this guide.<br />
<br />
See the [[Xorg#Without_xorg.conf|article on X.Org, section "Without xorg.conf"]].<br />
<br />
* Note that if you are in possession of a properly configured xorg.conf under another distribution and with the same Xorg version, you may easily copy it over to your current Arch system's <code>/etc/X11/</code> directory.<br />
<br />
<br />
{{Tip | For Intel graphics card, specific configuration may be necessary to get proper 2D or 3D performance, as stated in [[Intel_Graphics]] wiki article.}}<br />
<br />
====B: Input hotplugging====<br />
<br />
[[Xorg input hotplugging|Input hotplugging]] is supported since the 1.4 version of the X.Org X Server and enabled by default. When enabled, X will utilize hal to allow for the hotplugging and removal of human interface devices without having to restart X. <br />
<br />
{{Warning | Starting the '''X''' server using input hotplugging without the '''HAL''' daemon installed and running may result in the inability to use the mouse and/or keyboard, and the '''X''' server appearing to freeze as a result .}}<br />
<br />
You must decide whether you will use input hotplugging (enabled by default), or disable it. Input hotplugging is convenient for many users, especially those with mobile machines like laptops and netbooks. Other users may wish to disable it in favor of manual or more static device configuration within /etc/xorg.conf.<br />
<br />
{{Tip | See the article on [[Xorg input hotplugging]] for full details.}}<br />
<br />
=====Using input hotplugging=====<br />
<br />
Install HAL, dbus and the evdev input driver:<br />
# pacman -S hal dbus xf86-input-evdev<br />
<br />
Set the keyboard layout (if you do not use a standard US keyboard)<br />
# cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/<br />
# nano /etc/hal/fdi/policy/10-keymap.fdi<br />
Edit the &quot;input.xkb.layout&quot; key and possibly the &quot;input.xkb.variant&quot; key in this file.<br />
<br />
Laptop users will also need the synaptics package to allow X to configure the touchpad:<br />
# pacman -S xf86-input-synaptics<br />
<br />
{{Tip|For instructions on fine tuning or troubleshooting touchpad settings, see the [[Touchpad Synaptics]] article.}}<br />
<br />
<br />
'''The HAL daemon'''<br />
<br />
The hal daemon '''must''' be started '''before''' the '''X''' server:<br />
# /etc/rc.d/hal start<br />
Add the hal daemon to the DAEMONS array in /etc/rc.conf to start it at every boot.<br />
<br />
=====Disable input hotplugging=====<br />
Disabling input hotplugging will skip devices detected by hal and will use the keyboard/mouse configuration from xorg.conf:<br />
# nano /etc/X11/xorg.conf<br />
add the following:<br />
Section &quot;ServerFlags&quot;<br />
Option &quot;AutoAddDevices&quot; &quot;False&quot;<br />
EndSection<br />
<br />
======Set the keyboard layout if not using a standard US keyboard======<br />
Add option lines in the &quot;InputDevice&quot; section of the /etc/X11/xorg.conf file specifying the keyboard layout and variant:<br />
Option &quot;XkbLayout&quot; &quot;be&quot;<br />
Option &quot;XkbVariant&quot; &quot;&quot;<br />
<br />
Alternative method using the setxkbmap command:<br />
# setxkbmap pl <br />
(with the proper keyboard layout instead of <code>pl</code> of course) should switch your keyboard layout in x.<br />
To make this permanent, add this command to <code>/home/<youruser>/.xinitrc</code> before starting the window manager (before command like <code>exec startxfce4</code>).<br />
<br />
==== C: Test X ====<br />
<br />
First, read the warning about input hotplugging in the previous section. At this point, you should have xorg installed, with a suitable video driver and an /etc/X11/xorg.conf configuration file. If you want to test your configuration quickly, to ensure your ability to successfully start '''X''' from the command line before installing a complete desktop environment, you can do so by configuring ~/.xinitrc to invoke '''Xterm'''. Xterm is a very simple terminal emulator which runs in the '''X '''Server environment; it is installed as part of the base xorg packages.<br />
<br />
===== Prepare for the test by configuring ~/.xinitrc=====<br />
<br />
One of the main functions of this file is to dictate what '''X''' Window client is invoked with the '''/usr/bin/startx''' and/or '''/usr/bin/xinit''' program ''on a per-user basis''. (The '''startx''' script is merely a front end to the more versatile '''xinit''' command.) There are vast amounts of additional configurable specifications and commands that may also be added to ~/[[.xinitrc]] as you further customize your system. <br />
{{Note | '''[[.xinitrc]]''' is a so-called 'dot' (.) file. Files in a UNIX filesystem which are preceded with a dot (.) are 'hidden', and will not show up with a regular 'ls' command, usually for the sake of keeping directories tidy. Dot files may be seen by issuing '''ls -a'''. The 'rc' denotes ''Run Commands'' and simply indicates that it is a configuration file. Since it controls how a program runs, it is (although historically incorrect) also said to stand for &quot;Run Control&quot;.}}<br />
<br />
'''startx/xinit''' will start the '''X''' server and clients. To determine the client to run, '''startx/xinit''' will first look to parse a [[.xinitrc]] file in the user's home directory. In the absence of file ~/[[.xinitrc]], it defaults to the global xinitrc in the xinit library directory; /etc/X11/xinit/xinitrc, which defaults to using the TWM window manager. (Hence, if you invoke startx without a ~/[[.xinitrc]] file, a TWM session will start.) Further details in the [[.xinitrc]] wiki entry.<br />
<br />
Switch to your '''''normal, non-root''''' user:<br />
<br />
# su - ''yourusername''<br />
<br />
* /etc/skel/ contains files and directories to provide sane defaults for newly created user accounts. The name '''skel''' is derived from the word '''skeleton''', because the files it contains form the basic structure for users' home directories.<br />
<br />
* Sample .xinitrc provided [[Xinitrc#A_standard_.xinitrc | here]] <br />
Copy the sample xinitrc file from /etc/skel/ to your home directory: <br />
<br />
$ cp /etc/skel/[[.xinitrc]] ~/<br />
Edit the file: <br />
$ nano ~/.xinitrc<br />
and add &quot;<code>exec xterm</code>&quot; so that it looks like this:<br />
<br />
#!/bin/sh<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
#<br />
# exec wmaker<br />
# exec startkde<br />
# exec icewm<br />
# exec blackbox<br />
# exec fluxbox<br />
#<br />
exec xterm<br />
<br />
{{Note | ''Be sure to have only '''one''' uncommented '''exec''' line in ~/.xinitrc'' for now.}}<br />
<br />
Below, we shall edit this file again to specify the appropriate desktop environment/window manager of your choice.<br />
<br />
===== Perform the test =====<br />
<br />
Test your configurations by starting '''X''' as '''normal, non-root''' user, with:<br />
<br />
$ startx<br />
or<br />
$ xinit<br />
<br />
You should have an '''xterm''' session open up. You can test your keyboard and its layout in it. You may have to move your mouse around until it enters the xterm area before you see the mouse cursor or xterm responds to your keyboard.<br />
<br />
If you prove a properly configured /etc/X11/xorg.conf by successfully running the test, you can be assured that your DE/WM of choice will work smoothly.<br />
<br />
Exit Xterm with:<br />
$ exit<br />
{{Tip|Advanced instructions for Xorg configuration can be found in the [[Xorg]] article.}}<br />
<br />
<br />
{{Note| With Xorg 1.6 CTRL-Alt-Backspace has been deprecated and will not work to exit out of this test. A somewhat messy work around is to switch to a different virtual console (CTRL-Alt-F2, for example) and then switch back to the console the test is running in (probably CTRL-Alt-F1). You will then be able to use CTRL-C to kill the X test. You can enable CTRL-Alt-Backspace by editing xorg.conf, as described [http://wiki.archlinux.org/index.php/Xorg#Ctrl-Alt-Backspace_doesn.27t_exit_X here].}}<br />
If the screen goes black, you may still attempt to switch to a different virtual console (CTRL-Alt-F2, for example), and login blindly as root, followed by <Enter>, followed by root's password followed by <enter>. Finally, reboot blindly with:<br />
# reboot<br />
or <br />
# init 6<br />
<br />
=====In case of errors=====<br />
If you have problems starting '''X''', you can look for errors in the /var/log/Xorg.0.log file and on the console output of the virtual console you started '''X''' from. <br />
<br />
'''''If using /etc/X11/xorg.conf'''''<br />
<br />
Inspect the config file:<br />
<br />
# nano /etc/X11/xorg.conf<br />
<br />
The video driver may need to be specified. e.g.:<br />
Section &quot;Device&quot;<br />
<br />
...<br />
Driver &quot;savage&quot;<br />
...<br />
<br />
EndSection<br />
<br />
Horizontal sync and vertical refresh specs under section &quot;Monitor&quot; may need to be added:<br />
Section &quot;Monitor&quot;<br />
Identifier &quot;Monitor0&quot;<br />
VendorName &quot;Monitor Vendor&quot;<br />
ModelName &quot;Monitor Model&quot;<br />
HorizSync 30.0 - 130.0 # Safe for LCD's<br />
VertRefresh 50.0 - 100.0 # Safe for LCD's and most CRT's.<br />
EndSection<br />
(If these specs are unknown, consult the documentation of the computer monitor.)<br />
<br />
Color depth can be specified under section &quot;Screen&quot;:<br />
Section &quot;Screen&quot;<br />
Identifier &quot;Screen0&quot;<br />
Device &quot;Card0&quot;<br />
Monitor &quot;Monitor0&quot;<br />
DefaultDepth 24<br />
(Typically, this will be set to 24 for true color.)<br />
<br />
Also add desired Modes to the &quot;Display&quot; subsection, at least under the Depth 24 header, e.g.:<br />
SubSection &quot;Display&quot;<br />
Viewport 0 0<br />
Depth 24<br />
Modes &quot;1024x768&quot; &quot;800x600&quot; &quot;640x480&quot;<br />
Add the following section, if eye candy which requires the composite extension is desired: <br />
Section &quot;Extensions&quot;<br />
Option &quot;Composite&quot; &quot;Enable&quot;<br />
EndSection<br />
Try the config again, after modifying:<br />
# startx<br />
or<br />
# xinit<br />
'''''Still having trouble? Detailed instructions are in the [[Xorg]] article.'''''<br />
<br />
=====Need Help?=====<br />
<br />
If you are still having trouble after consulting the [[Xorg]] article and need assistance via the Arch forums, be sure to install and use wgetpaste:<br />
<br />
# pacman -S wgetpaste<br />
Use wgetpaste and provide links for the following files when asking for help in your forum post:<br />
* ~/.xinitrc<br />
* /etc/X11/xorg.conf<br />
* /var/log/Xorg.0.log.old<br />
Use wgetpaste like so:<br />
$ wgetpaste </path/to/file><br />
Post the corresponding links given within your forum post. Be sure to provide appropriate hardware and driver information as well.<br />
{{Warning| '''''It is very important to provide detail when troubleshooting X. Please provide all pertinent information as detailed above when asking for assistance on the Arch forums. '''''}}<br />
<br />
==Part IV: Installing and configuring a Desktop Environment ==<br />
While The '''X''' Window System provides the basic framework for building a ''graphical user interface'' (GUI), a '''Desktop Environment''' (DE), works atop and in conjunction with '''X''', to provide a completely functional and dynamic GUI. A DE typically provides a window manager, icons, applets, windows, toolbars, folders, wallpapers, a suite of applications and abilities like drag and drop. The particular functionalities and designs of each DE will uniquely affect your overall environment and experience. Therefore, choosing a DE is a very subjective and personal decision. Choose the best environment for ''your'' needs.<br />
<br />
If you desire a lighter, less demanding GUI to configure manually, you may choose to simply install a '''Window Manager''', or WM. A WM controls the placement and appearance of application windows in conjunction with the X Window System but does NOT include such features as panels, applets, icons, applications, etc., by default.<br />
* Lightweight floating WM's include: [[#Openbox|'''Openbox''']], [[#Fluxbox|'''Fluxbox''']], [[#fvwm2|'''fvwm2''']], [[PekWM|'''pekwm''']], [[Evilwm|'''evilwm''']], '''Windowmaker, and TWM'''.<br />
* If you need something completely different, try a tiling WM like [[Awesome|'''awesome''']], [[Ion3|'''ion3''']], [[Wmii|'''wmii''']], [[Dwm|'''dwm''']], [[Xmonad|'''xmonad''']], or [[Ratpoison|'''ratpoison''']].<br />
<br />
===Step 1: Install Fonts===<br />
At this point, you may wish to save time by installing visually pleasing, true type fonts, before installing a desktop environment/window manager. Dejavu and bitstream-vera are good, general-purpose font sets. You may also want to install the Microsoft font sets, which are especially popular on websites, and may be required for the proper function of Flash animations which feature text.<br />
<br />
Install with:<br />
# pacman -S ttf-ms-fonts ttf-dejavu ttf-bitstream-vera<br />
<br />
Refer to [[Xorg Font Configuration]] for how to configure fonts.<br />
<br />
===Step 2: ~/.xinitrc (again)===<br />
<br />
As '''non-root user''', edit your /home/username/.xinitrc to specify the DE you wish to use. This will allow you to use '''startx/xinit''' from the shell, in the future, to open your DE/WM of choice:<br />
<br />
$ nano ~/.xinitrc<br />
<br />
Uncomment or add the ''''exec''' ..' line of the appropriate desktop environment/window manager. Some examples are below:<br />
<br />
For the Xfce4 desktop environment:<br />
exec startxfce4 <br />
<br />
For the KDE desktop environment:<br />
exec startkde<br />
A '''startkde''' or '''startxfce4''' command starts the KDE or Xfce4 desktop environment. This is exactly the same as entering: <br />
$ xinit /usr/bin/startxfce4<br />
or<br />
$ xinit /usr/bin/starkde<br />
from the shell prompt. Note that such a command does not finish until you logout of the DE. Normally the shell would wait for KDE to finish, then run the next command. The &quot;exec&quot; prefix to this command within the ~/.xinitrc file tells the shell that this is the last command, so the shell does not need to wait to run a subsequent command.<br />
<br />
In the future, after the DE of choice is installed and if trouble with automounting is experienced, try using the following command in ~/.xinitrc instead. (Replace "startxfce4" with the command that is appropriate for your window manager/DE.)<br />
exec ck-launch-session startxfce4<br />
This will ensure the various environment variables are set correctly by starting a clean consolekit session. ConsoleKit is a framework for keeping track of the various users, sessions, and seats present on a system. It provides a mechanism for software to react to changes of any of these items or of any of the metadata associated with them. It works in conjunction with dbus, and other tools.<br />
<br />
Remember to have only one uncommented '''exec''' line in your ~/.xinitrc for now.<br />
<br />
===Step 3: Install a Desktop Environment===<br />
<br />
Continue below, installing the DE/WM of your choice.<br />
<br />
* [[#GNOME|'''GNOME''']]<br />
* [[#KDE|'''KDE''']]<br />
* [[#Xfce|'''Xfce''']]<br />
* [[#LXDE|'''LXDE''']]<br />
* [[#Openbox|'''Openbox''']]<br />
* [[#Fluxbox|'''Fluxbox''']]<br />
* [[#fvwm2|'''fvwm2''']]<br />
<br />
====GNOME====<br />
=====About GNOME=====<br />
The '''G'''NU '''N'''etwork '''O'''bject '''M'''odel '''E'''nvironment. The GNOME project provides two things: The GNOME desktop environment, an intuitive and attractive desktop for end-users, and the GNOME development platform, an extensive framework for building applications that integrate into the rest of the desktop.<br />
<br />
=====Installation=====<br />
Install the base GNOME environment with:<br />
# pacman -S gnome<br />
<br />
Additionally, you can install the extras:<br />
# pacman -S gnome-extra<br />
<br />
It's safe to choose all packages shown in the extra package.<br />
<br />
=====Useful DAEMONS for GNOME=====<br />
Recall from above that a daemon is a program that runs in the background, waiting for events to occur and offering services. Some users prefer to use the '''hal''' daemon. The '''hal''' daemon, among other things, will automate the mounting of disks, optical drives, and USB drives/thumbdrives for use in the GUI. The '''fam''' daemon will allow real-time representation of file alterations in the GUI, allowing instant access to recently installed programs, or changes in the file system. Both '''hal''' and '''fam''' can make life easier for the GNOME user. The hal and fam packages are installed when you install GNOME, but must be invoked to become useful.<br />
<br />
You may want to install a graphical login manager. For GNOME, the '''gdm''' daemon is a good choice. <br />
<br />
As root:<br />
# pacman -S gdm<br />
<br />
Start hal and fam:<br />
# /etc/rc.d/hal start<br />
<br />
# /etc/rc.d/fam start<br />
<br />
Add them to your /etc/rc.conf DAEMONS section, so they will be invoked at boot:<br />
# nano /etc/rc.conf<br />
<br />
DAEMONS=(syslog-ng network crond alsa '''hal fam gdm''')<br />
(If you prefer to log into the console and manually start X, leave out gdm.)<br />
<br />
Then edit your /etc/gdm/custom.conf and in the '''[servers]''' section add:<br />
0=Standard vt7<br />
<br />
As normal user, start X:<br />
$ startx<br />
or<br />
$ xinit<br />
If ~/.xinitrc is not configured for GNOME, you may always start it with '''xinit''', followed by the path to GNOME:<br />
$ xinit /usr/bin/gnome-session<br />
<br />
{{Tip|Advanced instructions for installing and configuring GNOME can be found in the [[Gnome]] article.}}<br />
<br />
Congratulations! Welcome to your GNOME desktop environment on your new Arch Linux system! You may wish to continue by viewing '''[[Beginners Guide Appendix#Tweaks.2FFinishing_touches|Tweaks and finishing touches]]''', or the rest of the information below. You may also be interested in the [[Post Installation Tips]] wiki article.<br />
<br />
=====Eye Candy=====<br />
By default, GNOME does not come with many themes and icons. You may wish to install some more attractive artwork for GNOME:<br />
<br />
A nice gtk (gui widget) theme engine (includes themes) is the murrine engine. Install with:<br />
# pacman -S gtk-engine-murrine<br />
<br />
Optional for more themes:<br />
# pacman -S murrine-themes-collection <br />
<br />
Once it has been installed, select it with System -> Preferences -> Appearance -> Theme tab.<br />
<br />
The Arch Linux repositories also have a few more nice themes and engines. Install the following to see for yourself:<br />
<br />
# pacman -S gtk-engines gtk-aurora-engine gtk-candido-engine gtk-rezlooks-engine<br />
<br />
You can find many more themes, icons, and wallpapers at [http://www.gnome-look.org GNOME-Look].<br />
<br />
====KDE====<br />
=====About KDE=====<br />
The '''K''' '''D'''esktop '''E'''nvironment. KDE is a powerful Free Software graphical desktop environment for GNU/Linux and <tt>UNIX</tt> workstations. It combines ease of use, contemporary functionality, and outstanding graphical design with the technological superiority of <tt>UNIX</tt>-like operating systems.<br />
<br />
=====Installation=====<br />
Choose one of the following, then continue below with '''[[#Useful KDE DAEMONS|Useful KDE DAEMONS]]''': <br />
<br />
1. The package '''kde''' is the official and complete vanilla KDE 4.2 residing under the Arch [extra] repo.<br />
<br />
Install base kde:<br />
# pacman -S kdebase-workspace<br />
Install the whole Desktop Environment: <br />
# pacman -S kde<br />
''or'' <br />
# pacman -S kde-meta<br />
<br />
2. Alternatively, another KDE project exists called '''KDEmod''', part of the Chakra distribution. It is an Arch Linux (and spinoff) exclusive, community-driven package set designed for modularity and offers a choice between KDE 3.5.10 or 4.x.x. KDEmod can be installed with pacman, after adding the proper repositories to /etc/pacman.conf. The project website, including complete installation instructions, can be found at [http://www.chakra-project.org/ http://www.chakra-project.org/].<br />
<br />
=====Useful KDE DAEMONS=====<br />
<br />
Recall from above that a daemon is a program that runs in the background, waiting for events to occur and offering services.<br />
<br />
KDE will require the '''hal''' ('''H'''ardware '''A'''bstraction '''L'''ayer) daemon for optimal functionality. The hal daemon, among other things, will facilitate the automatic mounting of disks, optical drives, and USB drives/thumbdrives for use in the GUI. The hal package is installed when you install xorg-server, but must be invoked to become useful.<br />
<br />
The '''kdm''' daemon is the '''K''' '''D'''isplay '''M'''anager, which provides a '''graphical login''', if desired.<br />
<br />
-----<br />
<br />
Start hal:<br />
# /etc/rc.d/hal start<br />
<br />
{{Note|The hal daemon relies on, and will automatically start, the dbus daemon.}}<br />
Edit your DAEMONS array in /etc/rc.conf:<br />
# nano /etc/rc.conf<br />
Add '''hal''' to your DAEMONS array, to invoke it on boot. If you prefer a graphical login, add '''kdm''' as well: <br />
DAEMONS=(syslog-ng '''hal''' network crond alsa '''kdm''')<br />
{{Note|If you installed KDEmod3 instead of normal KDE, use kdm3 instead of kdm.}}<br />
<br />
*This method will start the system at runlevel 3, (/etc/inittab default, multiuser mode), and then start KDM as a daemon. <br />
<br />
*Some users prefer an alternative method of starting a display manager like KDM on boot by utilizing the /etc/inittab method and starting the system at runlevel 5. See [[Adding a login manager (KDM, GDM, or XDM) to automatically boot on startup]] for more.<br />
<br />
*If you prefer to log into the '''console''' at runlevel 3, and manually start X, leave out kdm, or comment it out with a bang, ( ! ).<br />
<br />
Now try starting your X Server as normal user:<br />
$ startx<br />
or<br />
$ xinit<br />
{{Tip|Advanced instructions for installing and configuring KDE can be found in the [[KDE]] article.}}<br />
<br />
Congratulations! Welcome to your KDE desktop environment on your new Arch Linux system! You may wish to continue by viewing '''[[Beginners Guide Appendix|The Beginners Guide Appendix]]''', or the rest of the information below. You may also be interested in the [[Post Installation Tips]] wiki article.<br />
<br />
====Xfce====<br />
=====About Xfce=====<br />
Xfce is another free software desktop environment for Linux. It aims to be fast and lightweight, while still being visually appealing and easy to use. Xfce is modular and reusable. It consists of separately packaged components that together provide the full functionality of the desktop environment, but which can be selected in subsets to create the user's preferred personal working environment. Xfce is mainly used for its ability to run a modern desktop environment on relatively modest hardware. It is based on the GTK+ 2 toolkit (the same as GNOME). It uses the Xfwm window manager, described below. Its configuration is entirely mouse-driven, and the configuration files are hidden from the casual user.<br />
<br />
=====Installation=====<br />
Install Xfce: <br />
# pacman -S xfce4 <br />
You may also wish to install themes and extras:<br />
# pacman -S xfce4-goodies gtk2-themes-collection<br />
Note: '''xfce4-xfapplet-plugin''' (a plugin that allows the use of GNOME applets in the Xfce4 panel) is part of the '''xfce4-goodies''' group and depends on '''gnome-panel''', which in turn depends on '''gnome-desktop'''. You may wish to take this into consideration before installing, since it represents a significant number of extra dependencies.<br />
<br />
If you get errors about dbus-launch then you need to install dbus aswell:<br />
# pacman -S dbus<br />
<br />
If you wish to admire 'Tips and Tricks' on login, install the '''fortune-mod''' package:<br />
# pacman -S fortune-mod<br />
<br />
=====Useful DAEMONS=====<br />
Recall from above that a daemon is a program that runs in the background, waiting for events to occur and offering services. Some Xfce users prefer to use the '''hal''' daemon. The hal daemon, among other things, will automate the mounting of disks, optical drives, and USB drives/thumbdrives for use in the GUI. The fam daemon will allow real-time representation of file alterations in the GUI, allowing instant access to recently installed programs, or changes in the file system. The hal and fam packages are installed when you install Xfce, but must be invoked to become useful.<br />
<br />
Start hal and fam:<br />
<br />
# /etc/rc.d/hal start<br />
<br />
# /etc/rc.d/fam start<br />
{{Note|The hal daemon relies on, and will automatically start, the dbus daemon.}}<br />
Edit your DAEMONS array in /etc/rc.conf:<br />
# nano /etc/rc.conf<br />
Add '''hal''' and '''fam''' to your DAEMONS array, to invoke them at boot.<br />
<br />
{{Tip|Advanced instructions for installing and configuring Xfce can be found in the [[Xfce]] article.}}<br />
<br />
If you wish to install one, see [[Adding a login manager (KDM, GDM, or XDM) to automatically boot on startup]]. Otherwise you can login in via the console and run:<br />
<br />
$ startxfce4<br />
<br />
Congratulations! Welcome to your Xfce desktop environment on your new Arch Linux system! You may also be interested in the [[Post Installation Tips]] wiki article.<br />
<br />
====LXDE====<br />
=====About LXDE=====<br />
LXDE, (for ''L''ightweight ''X''11 ''D''esktop ''E''nvironment), is a new project focused on providing a modern desktop environment which aims to be lightweight, fast, intuitive and functional while keeping system resource usage low. LXDE is quite different from other desktop environments, since each component of LXDE is a discrete and independent application, and each can be easily substituted by other programs. This modular design eliminates all unnecessary dependencies and provides more flexibility. Details and screenshots available at: http://lxde.org/ <br />
<br />
LXDE provides:<br />
# The OpenBox windowmanager<br />
# PCManFM File manager<br />
# LXpanel system panel<br />
# LXSession session manager<br />
# LXAppearance GTK+ theme switcher<br />
# GPicView image viewer<br />
# Leafpad simple text editor<br />
# XArchiver: Lightweight, fast, and desktop-independent gtk+-based file archiver<br />
# LXNM (still under development): Lightweight network manager for LXDE supporting wireless connections<br />
These lightweight and versatile tools combine for quick setup, modularity and simplicity.<br />
<br />
Install LXDE with: <br />
# pacman -S lxde gamin openbox<br />
<br />
Add:<br />
exec startlxde<br />
*If you experience problems with Policykit or plan on running '''nm-applet''', the following command should be used instead<br />
exec ck-launch-session startlxde<br />
to your ~/.xinitrc and start with ''startx'' or ''xinit''<br />
<br />
{{Tip | Further information available at the [[LXDE]] wiki article.}}<br />
<br />
====*box====<br />
=====Fluxbox=====<br />
Fluxbox is yet another windowmanager for X.<br />
It's based on the Blackbox 0.61.1 code. Fluxbox looks like blackbox and handles styles, colors, window placement and similar things exactly like blackbox (100% theme/style compability).<br />
<br />
Install Fluxbox using <br />
# pacman -S fluxbox fluxconf<br />
<br />
If you use gdm/kdm a new fluxbox session will be automatically added. Otherwise, you should modify your user's .xinitrc and add this to it:<br />
exec startfluxbox <br />
<br />
More information is available in the [[Fluxbox]] article.<br />
<br />
=====Openbox=====<br />
Openbox is a standards compliant, fast, light-weight, extensible window manager.<br />
<br />
Openbox works with your applications, and makes your desktop easier to manage. This is because the approach to its development was the opposite of what seems to be the general case for window managers. Openbox was written first to comply with standards and to work properly. Only when that was in place did the team turn to the visual interface.<br />
<br />
Openbox is fully functional as a stand-alone working environment, or can be used as a drop-in replacement for the default window manager in the GNOME or KDE desktop environments. <br />
<br />
Install openbox using<br />
# pacman -S openbox<br />
Additional configuration tools are also available, if desired:<br />
# pacman -S obconf obmenu<br />
<br />
Once openbox is installed you will get a message to move menu.xml & rc.xml to ~/.config/openbox/ in your home directory:<br />
# su - ''yourusername''<br />
$ mkdir -p ~/.config/openbox/<br />
$ cp /etc/xdg/openbox/rc.xml ~/.config/openbox/<br />
$ cp /etc/xdg/openbox/menu.xml ~/.config/openbox/<br />
<br />
'''rc.xml''' is the main configuration file for OpenBox. It may be manually edited, (or you can use OBconf). '''menu.xml''' configures the right-click menu.<br />
<br />
You may log into OpenBox via graphical login using KDM/GDM, or from the shell using '''startx''', in which case you will need to edit your ~/.xinitrc (as non-root user) and add the following:<br />
<br />
exec openbox-session<br />
<br />
NOTE: If you plan on running dbus (which is required by hal) then make sure your ~/.xinitrc reads:<br />
<br />
exec dbus-launch --exit-with-session openbox-session<br />
<br />
You may also start OpenBox from the shell using '''xinit''':<br />
$ xinit /usr/bin/openbox-session<br />
* Openbox may also be used as the window manager for GNOME, KDE, and Xfce.<br />
For KDM there is nothing left to do; openbox is listed in the sessions menu in KDM.<br />
<br />
Some useful, lightweight programs for OpenBox are:<br />
* PyPanel, Tint2, or LXpanel if you want a panel<br />
* feh if you want to set the background<br />
* ROX if you want a simple file manager (also provides simple icons)<br />
* PcmanFM a lightweight but versatile file manager (also provides desktop icon functionality)<br />
* iDesk (available in [[AUR]]) for providing desktop icons<br />
* Graveman for burning CD's or DVD's<br />
<br />
{{Tip | More information is available in the [[Openbox]] article.}}<br />
<br />
====FVWM2====<br />
FVWM (F Virtual Window Manager) is an extremely powerful ICCCM-compliant multiple virtual desktop window manager for the X Window system. Development is active, and support is excellent. <br />
<br />
Install fvwm2 with<br />
# pacman -S fvwm <br />
<br />
It will install the official version of the WM. However, if you want/need to use some more features than it provides, you can install the patched version from archlinuxfr (see [[Unofficial user repositories]]) or [[AUR]]. To install it from AUR or archlinuxfr repesctively, execute:<br />
$ yaourt -S fvwm-patched<br />
or<br />
# pacman -S fvwm-patched<br />
<br />
fvwm will automatically be listed in kdm/gdm in the sessions menu. Otherwise, add <br />
exec fvwm 2 <br />
<br />
to your user's .xinitrc.<br />
<br />
When you start [[FVWM2]], you will get into the blank configuration. However, when you left-click on the desktop, you will be able to select to configure FVWM. chose wanted modules and you are ready to go. Check out the configs in the http://www.box-look.org. One should also consider checking FVWM forums at http://fvwm.lair.be<br />
<br />
[[SLiM]] is a very good login manager, that does not have many dependencies and acts well with FVWM. Common Applications are similar to those suggested for [[Openbox]] or [[Fluxbox]].<br />
<br />
==Common and Lightweight Applications==<br />
For a list of [[Common Applications]] and [[Lightweight Applications]], visit their respective articles.<br />
<!-- Maybe the beginners' guide shouldn't link to lightweight... --><br />
<br />
=Appendix=<br />
See the [[Beginners' Guide Appendix]]<br />
<!-- vim: set ft=Wikipedia: --></div>
Daenyth
https://wiki.archlinux.org/index.php?title=Beginners%27_guide_old&diff=86218
Beginners' guide old
2009-12-03T21:07:38Z
<p>Daenyth: /* Step 1: Obtain the latest Installation media */ Changed external link to internal wiki link.</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]][[Category:About Arch (English)]]<br />
[[Category:HOWTOs (English)]][[Category:Accessibility (English)]]<br />
{{Article summary start}}<br />
{{Article summary text|Provides a highly detailed, explanatory guide to installing, configuring and using a full-featured Arch Linux system.}}<br />
{{Article summary heading|Languages}}<br />
{{i18n_entry|Česky|Průvodce začátečníka (Česky)}}<br />
{{i18n_entry|简体中文|Arch 新手安装指南 (简体中文)}}<br />
{{i18n_entry|正體中文|Beginner's Guide 新手指南}}<br />
{{i18n_entry|Dansk|Dansk_Begynderguide}}<br />
{{i18n_entry|Deutsch|Beginners Guide (Deutsch)}}<br />
{{i18n_entry|English|Beginners Guide}}<br />
{{i18n_entry|Español|Guía para Principiantes (Español)}}<br />
{{i18n_entry|Français|Manuel_du_Débutant_(Français)}}<br />
{{i18n_entry|Italiano|Beginners Guide (Italiano)}}<br />
{{i18n_entry|Indonesia|Beginners_Guide_(Indonesia)}}<br />
{{i18n_entry|Lietuviškai|Pradedančiųjų gidas (Lietuviškai)}}<br />
{{i18n_entry|Nederlands|Beginners_Guide_(Nederlands)}}<br />
{{i18n_entry|Português Brasil|Guia do Iniciante(Português do Brasil)}}<br />
{{i18n_entry|Português|Guia para Principiantes(Português)}}<br />
{{i18n_entry|Русский|Руководство_для_новичков}}<br />
{{i18n_entry|Türkçe|Başlangıç Rehberi (Türkçe)}}<br />
{{i18n_entry|हिन्दी|नौसिखिया गाइड(हिन्दी)}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Official Arch Linux Install Guide}} (for a more general approach)<br />
{{Article summary wiki|Beginners' Guide Appendix}}<br />
{{Article summary wiki|Post Installation Tips}}<br />
{{Article summary end}}<br />
[http://wiki.archlinux.org/index.php/Category:Accessibility_(English) Accessibility resources available]<!-- Making this a note brakes the format --><br />
==Preface==<br />
=====Everything you ever wanted to know about Arch, but were afraid to ask=====<br />
Welcome. This document will guide you through the process of installing and configuring [[Arch Linux]]; a simple, agile and lightweight GNU/Linux distribution, and <tt>UNIX</tt>-like operating system targeted at competent users. <br />
* Arch Linux requires a certain level of intimate knowledge of its configuration process and of <tt>UNIX</tt>-like system methodology, and for this reason, extra explanatory information is included. <br />
* This guide is aimed at new Arch users, but strives to serve as a strong reference and informative base for all.<br />
<br />
'''Arch Linux distribution highlights:'''<br />
* '''[[The Arch Way | Simple]]''', <tt>UNIX</tt>-like design and philosophy<br />
* Independently Developed Community distro built from scratch and targeted at competent GNU/Linux users<br />
* All packages compiled for '''i686/x86-64'''<br />
* Highly customizable system assembled by the user from the ground up<br />
* '''[[The Arch boot process | BSD-style init]]''' scripts, featuring one centralized configuration file<br />
* '''mkinitcpio''': a simple and dynamic initramfs creator <br />
* '''Rolling Release''' model<br />
* '''[[Pacman]]''' package manager: is written in '''C''', and is fast, lightweight and agile, with a very modest memory footprint<br />
* '''[[ABS]]''': The '''A'''rch '''B'''uild '''S'''ystem, a ports-like package building system, makes it simple to create your own easily-installable Arch packages from source, to use and/or share with the community on the [[AUR]]<br />
* '''[[AUR]]''': The Arch User Repository, offering many thousands of build scripts for Arch from user-provided software packages<br />
<br />
=====License=====<br />
<br />
Arch Linux, pacman, documentation, and scripts are copyright<br />
©2002-2007 by Judd Vinet, ©2007-2009 by Aaron Griffin and are licensed under the GNU General Public License Version 2.<br />
<br />
=====DON'T PANIC !=====<br />
The Arch Linux system is assembled by the ''user'', from the shell, using basic command line tools. This is '''[[The Arch Way]].''' Unlike the more rigid structures of other distributions and installers, there are no default environments nor configurations chosen for you. From the command line, ''you'' will add packages from the Arch repositories using the [[pacman]] tool via your internet connection and manually configure your installation by editing text files until your system is customized to your requirements. You will also manually add non-root user(s) and manage groups and permissions. This method allows for maximum flexibility, choice, and system resource control ''from the base up''.<br />
<br />
Arch Linux is a distribution aimed at competent GNU/Linux users who desire a 'do-it-yourself' approach.<br />
<br />
=====[[The Arch Way]]=====<br />
<br />
'''''The design principles behind Arch are aimed at keeping it [[The Arch Way|simple]].'' '''<br />
<br />
'Simple', in this context, shall mean 'without unnecessary additions, modifications, or complications'. In short; an elegant, minimalist approach.<br />
<br />
'''Some thoughts to keep in mind as you consider simplicity:'''<br />
<br />
*''&quot; 'Simple' is defined from a technical standpoint, not a usability standpoint. It is better to be technically elegant with a higher learning curve, than to be easy to use and technically [inferior].&quot; -Aaron Griffin''<br />
*''Entia non sunt multiplicanda praeter necessitatem'' or &quot;Entities should not be multiplied unnecessarily.&quot; -Occam's razor. The term ''razor'' refers to the act of shaving away unnecessary complications to arrive at the simplest explanation, method or theory.<br />
*''&quot;The extraordinary part of [my method] lies in its simplicity..The height of cultivation always runs to simplicity.&quot;'' - Bruce Lee<br />
<br />
=====About This Guide=====<br />
<br />
The Arch wiki is an excellent resource and should be consulted for issues [http://wiki.archlinux.org/index.php/Main_Page first]. IRC (freenode #archlinux), and the [http://bbs.archlinux.org/ forums] are also available if the answer cannot be found elsewhere.<br />
<br />
{{Note|Following this guide closely is essential in order to successfully install a properly configured Arch Linux system, so ''please'' read it thoroughly. It is strongly recommended you read each section completely <u>before</u> carrying out the tasks contained.}}<br />
<br />
Since GNU/Linux Distributions are fundamentally 'modular' by design, the guide is logically divided into 4 main components of a desktop <tt>UNIX</tt>-like operating system: <br />
<br />
'''[[#Part I: Install the Base System|Part I: Installing the Base system]]'''<br />
<br />
'''[[#Part II: Configure & Update the New Arch Linux base system|Part II: Configure & Update the New Arch Linux base system]]'''<br />
<br />
'''[[#Part III: Install X and configure ALSA|Part III: Installing X and configuring ALSA]]'''<br />
<br />
'''[[#Part IV: Installing and configuring a Desktop Environment|Part IV: Installing a Desktop Environment]]'''<br />
<br />
<br />
'''''Welcome to Arch!'''''<br />
:'''''Enjoy the installation; take your time and have fun!'''''<br />
<br />
'''''Now, let's get started....'''''<br />
<br />
<br><br />
<br />
==Part I: Install the Base System==<br />
<br />
===Step 1: Obtain the latest Installation media ===<br />
<br />
You can obtain Arch's official installation media from [http://archlinux.org/download/ here]. The latest version is 2009.08 <br />
<br />
*Both the Core and the Netinstall images provide only the necessary packages to create an '''Arch Linux base system'''. ''Note that the Base System does not include a GUI. It is mainly comprised of the GNU toolchain (compiler, assembler, linker, libraries, shell, and utilities), the Linux kernel, and a few extra libraries and modules.''<br />
*Core images facilitate both installing from CD and Net. <br />
*Netinstall images are smaller and provide no packages themselves; the entire system is retrieved via internet.<br />
*The isolinux images are provided for people who experience trouble using the grub version. There are no other differences.<br />
* [[Arch64_FAQ|The Arch64 FAQ]] can help you choose between the 32- and 64-bit versions.<br />
<br />
====CD installer====<br />
Burn the .iso image file to a CD with your preferred CD burner drive and software, and continue with [[#Step 2: Boot Arch Linux Installer | Step 2: Boot Arch Linux Installer]]<br />
{{Note| The quality of optical drives, as well as the CD media itself, vary greatly. Generally, using a slow burn speed is recommended for reliable burns; Some users recommend speeds '''''as low as 4x or 2x.''''' If you are experiencing unexpected behavior from the CD, try burning at the minimum speed supported by your system. }}<br />
<br />
====USB stick====<br />
{{Warning|This will irrevocably destroy all data on your USB stick!}}<br />
<br />
'''<tt>UNIX</tt> Method:'''<br />
<br />
Insert an empty or expendable USB stick, determine its path, and write the .img to the USB stick with the <code>/bin/dd</code> program:<br />
dd if=archlinux-2009.08-''{core|netinstall}''-''{i686|x86_64}''.img of=/dev/sd''x''<br />
where ''if='' is the path to the img file and ''of='' is your USB device. Make sure to use /dev/sd''x'' and not /dev/sd''x1''.<br />
<br />
'''Check md5sum (optional):'''<br />
<br />
Make a note of the number of records (blocks) read in and written out, then perform the following check:<br />
dd if=/dev/sd''x'' count=''number_of_records'' status=noxfer | md5sum<br />
The md5sum returned should match the md5sum of the downloaded archlinux image file; they both should match the md5sum of the image as listed in the md5sums file in the mirror distribution site.<br />
<br />
'''Windows Method:'''<br />
<br />
Download Disk Imager from https://launchpad.net/win32-image-writer/+download. Insert flash media. Start the Disk Imager and select the image file. Select the Drive letter associated with the flash drive. Click "write".<br />
<br />
Continue with [[#Step 2: Boot Arch Linux Installer | Step 2: Boot Arch Linux Installer]]<br />
<br />
===Step 2: Boot Arch Linux Installer===<br />
Insert the CD or USB stick and boot from it. You may have to<br />
change the boot order in your computer BIOS or press a key (usually DEL, F1, F2, F11 or F12) during the BIOS POST (Power On Self-Test) phase.<br />
<br />
{{Tip|The memory requirements for a basic install are:<br />
* Core : 128 MB RAM x86_64/i686 (all packages selected, with swap partition)<br />
* Netinstall : 128 MB RAM x86_64/i686 (all packages selected, with swap partition)}}<br />
<br />
The main menu should be displayed at this point. Select the preferred choice by using the arrow keys to highlight your choice, and then by pressing Enter.<br />
<br />
Usually, the first item, Boot Archlive, is the preferred selection. However, choose Boot Archlive [legacy IDE] if you have trouble with libata/PATA, or have no SATA (Serial ATA) drives.<br />
<br />
To change GRUB boot options, press '''e'''. Many users may wish to change the resolution of the framebuffer, for more readable console output. Append:<br />
vga=773<br />
to the kernel line, followed by <ENTER>, for a 1024x768 framebuffer. When done, press '''b''' to boot into that selection.<br />
<br />
The system will now boot and present a login prompt. Login as 'root', without the quotes.<br />
<br />
If your system has errors trying to boot from the live CD or there are other '''hardware''' errors, refer to the [[Installation Troubleshooting]] wiki page.<br />
<br />
====Changing the keymap====<br />
If you have a non-US keyboard layout you can interactively choose your keymap/console font with the command:<br />
# km<br />
or use the loadkeys command:<br />
# loadkeys ''layout''<br />
(replace ''layout'' with your keyboard layout such as &quot;<code>fr</code>&quot; or &quot;<code>be-latin1</code>&quot;)<br />
<br />
====Documentation====<br />
The official install guide is conveniently available right on the live system! To access it, change to vc/2 (virtual console #2) with <ALT>+F2, and then invoke <code>/usr/bin/less</code> by typing in the following at the # prompt:<br />
# less /arch/docs/official_installation_guide_en<br />
<code>less</code> will allow you to page through the document. Change back to vc/1 with <ALT>+F1 to follow the rest of the install process.<br />
<br />
Change back to vc/2 at any time if you need to reference the Official Guide as you go thru the installation process.<br />
<br />
{{tip|Please note that the official guide only covers installation and configuration of the base system. Once that is installed, it is strongly recommended that you come back here to the wiki to find out more about post-installation considerations and other related issues.}}<br />
<br />
===Step 3: Start the Installation===<br />
As root, run the installer script from vc/1:<br />
# /arch/setup<br />
<br />
===A: Select an installation source===<br />
After a welcome screen, you will be prompted for an installation source. Choose the appropriate source for the installer you are using.<br />
* If you chose the CORE installer, continue below with [[#B: Set Clock|B: Set Clock]].<br />
* Netinstall only: You shall be prompted to load ethernet drivers manually, if desired. Udev is quite effective at loading the required modules, so you may assume it has already done so. You may verify this by invoking ifconfig -a from vc/3. (Select OK to continue.)<br />
<br />
====Configure Network (Netinstall)====<br />
Available Interfaces will be presented. If an interface and HWaddr ('''H'''ard'''W'''are '''addr'''ess) is listed, then your module has already been loaded. If your interface is not listed, you may probe it from the installer, or manually do so from another virtual console.<br />
<br />
The following screen will prompt you to ''Select the interface, Probe,'' or ''Cancel''. Choose the appropriate interface and continue.<br />
<br />
The installer will then ask if you wish to use DHCP. Choosing Yes will run '''dhcpcd''' to discover an available gateway and request an IP address; Choosing No will prompt you for your static IP, netmask, broadcast, gateway DNS IP, HTTP proxy, and FTP proxy. Lastly, you will be presented with an overview to ensure your entries are correct.<br />
<br />
=====(A)DSL Quickstart for the Live Environment (If you have a pure modem (or router in bridge mode) to connect to your ISP) =====<br />
<br />
Switch to another virtual console (<Alt> + F2), login as root and invoke <br />
# pppoe-setup<br />
If everything is well configured in the end you can connect to your ISP with <br />
# pppoe-start<br />
<br />
Return to first virtual console with <ALT>+F1. Continue with [[#B: Set Clock|B: Set Clock]]<br />
<br />
=====Wireless Quickstart For the Live Environment (If you need wireless connectivity during the installation process)=====<br />
<br />
The wireless drivers and utilities are now available to you in the live environment of the installation media. A good knowledge of your wireless hardware will be of key importance to successful configuration. Note that the following quickstart procedure ''executed at this point in the installation'' will initialize your wireless hardware for use ''in the live environment''. These steps (or some other form of wireless management) must be repeated from the actual installed system after booting into it. <br />
<br />
Also note that these steps are optional if wireless connectivity is unnecessary at this point in the installation; wireless functionality may always be established later.<br />
<br />
The basic procedure will be:<br />
* Switch to a free virtual console, e.g.: <ALT>+F3<br />
* (Optional) Identify the wireless interface and driver module:<br />
# lsmod | grep -i net<br />
* Ensure udev has loaded the driver, and that the driver has created a usable wireless kernel interface with <code>/usr/sbin/iwconfig</code>:<br />
# iwconfig<br />
Example output:<br />
lo no wireless extensions.<br />
eth0 no wireless extensions.<br />
wlan0 unassociated ESSID:""<br />
Mode:Managed Channel=0 Access Point: Not-Associated <br />
Bit Rate:0 kb/s Tx-Power=20 dBm Sensitivity=8/0 <br />
Retry limit:7 RTS thr:off Fragment thr:off<br />
Power Management:off<br />
Link Quality:0 Signal level:0 Noise level:0<br />
Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0<br />
Tx excessive retries:0 Invalid misc:0 Missed beacon:0<br />
<code>wlan0</code> is the available wireless interface in the example.<br />
* Bring the interface up with <code>/sbin/ifconfig <interface> up</code>.<br />
An example using the wlan0 interface:<br />
# ifconfig wlan0 up<br />
(Remember, your interface may be named something else, depending on your module (driver) and chipset: wlan0, eth1, etc.)<br />
* If the essid has been forgotten or is unknown, use <code>/sbin/iwlist <interface> scan</code> to scan for nearby networks.<br />
# iwlist wlan0 scan<br />
* Specify the id of the chosen wireless network with iwconfig <interface> essid &quot;<youressid>&quot; key <your_wep_key> (give the essid (the 'network name') of the network in quotes). <br />
* An example using WEP and a hexadecimal key:<br />
# iwconfig wlan0 essid &quot;linksys&quot; key 0241baf34c<br />
* An example using WEP and an ASCII passphrase:<br />
# iwconfig wlan0 essid "linksys" key s:pass1<br />
* An example using an unsecured network:<br />
# iwconfig wlan0 essid "linksys"<br />
* Request an IP address with <code>/sbin/dhcpcd <interface> </code>. e.g.:<br />
# dhcpcd wlan0<br />
* Ensure you can route using <code>/bin/ping</code>:<br />
# ping -c 3 www.google.com<br />
Done.<br />
* For connecting to a network using WPA, consult the [[WPA Supplicant]] article, and continue below.<br />
<br />
======Does the Wireless Chipset require Firmware?======<br />
A small percentage of wireless chipsets also require firmware, in addition to a corresponding driver. If unsure, invoke <code>/usr/bin/dmesg</code> to query the kernel log for a firmware request from the wireless chipset:<br />
# dmesg | grep firmware<br />
Example output from an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
{{Note | '''Wireless chipset firmware packages (for cards which require them) are pre-installed under /lib/firmware in the live environment, (on CD/USB stick) ''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!'' Package selection and installation is covered below. Ensure installation of both your wireless module and firmware during the package selection step! See [[Wireless Setup]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset. This is a very common error.'''}}<br />
<br />
After the initial Arch installation is complete, you may wish to refer to [[Wireless Setup]] to ensure a permanent configuration solution for your installed system.<br />
<br />
Return to vc/1 with <ALT>+F1. Continue with [[#B: Set Clock|B: Set Clock]]<br />
<br />
===B: Set Clock===<br />
* UTC - Choose UTC if running only <tt>UNIX</tt>-like operating system(s).<br />
<br />
* localtime - Choose local if multi-booting with a Microsoft Windows OS.<br />
<br />
===C: Prepare Hard Drive===<br />
<br />
{{Warning|Partitioning hard drives can destroy data. You are strongly cautioned and advised to backup your critical data if applicable.}}<br />
<br />
{{Note|Partitioning may be performed before initiating the Arch installation if desired, by utilizing [http://gparted.sourceforge.net/download.php GParted] or other available tools. If the installation drive has already been partitioned to the required specifications, continue with [[#Set Filesystem Mountpoints| Set Filesystem Mountpoints]]}}<br />
<br />
Verify current disk identities and layout by invoking <code>/sbin/fdisk</code> with the <code>-l</code> (lower-case L) switch.<br />
<br />
Open another virtual console (<ALT>+F3) and enter:<br />
# fdisk -l<br />
Take note of the disk(s)/partition(s) to utilize for the Arch installation.<br />
<br />
Switch back to the installation script with <ALT>+F1<br />
<br />
Select the first menu entry &quot;Prepare Hard Drive&quot;.<br />
* Option 1: Auto Prepare<br />
Auto-Prepare divides the disk into the following configuration:<br />
<br />
* ext2 /boot partition, default size 32MB. ''You will be prompted to modify the size to your requirement.''<br />
* swap partition, default size 256MB. ''You will be prompted to modify the size to your requirement.''<br />
* A Separate / and /home partition, (sizes can also be specified). Available filesystems include ext2, ext3, ext4, reiserfs, xfs and jfs, but note that ''both / and /home shall share the same fs type'' if choosing the Auto Prepare option.<br />
<br />
Be warned that Auto-prepare will completely erase the chosen hard drive. Read the <font color=&quot;red&quot;>warning</font> presented by the installer very carefully, and make sure the correct device is about to be partitioned.<br />
<br />
* Option 2: '''(Recommended)''' Partition Hard Drives (with cfdisk)<br />
<br />
This option will allow for the most robust and customized partitioning solution for your personal needs.<br />
<br />
''At this point, more advanced GNU/Linux users who are familiar and comfortable with manually partitioning may wish to skip down to '''[[#D: Select Packages|D: Select Packages]]''' below.''<br />
<br />
{{Note|If you are installing to a USB flash key, see "[[Installing Arch Linux on a USB key]]".}}<br />
<br />
====Partition Hard Drives====<br />
<br />
=====Partition Info=====<br />
<br />
Partitioning a hard disk drive defines specific areas (the partitions) within the disk, that will each appear and behave as a separate disk and upon which a filesystem may be created (formatted).<br />
*There are 3 types of disk partitions:<br />
#Primary<br />
#Extended<br />
#Logical<br />
'''Primary''' partitions can be bootable, and are limited to 4 partitions per disk or raid volume. If a partitioning scheme requires more than 4 partitions, an '''extended''' partition which will contain '''logical''' partitions will be required.<br />
<br />
Extended partitions are not usable by themselves; they are merely a &quot;container&quot; for logical partitions. If required, a hard disk shall contain only one extended partition; which shall then be sub-divided into logical partitions.<br />
<br />
When partitioning a disk, one can observe this numbering scheme by creating primary partitions sda1 through sda3 followed by creating an extended partition, sda4, and subsequently creating logical partition(s) within the extended partition; sda5, sda6, and so on.<br />
<br />
=====Swap Partition=====<br />
A swap partition is a place on the drive where virtual ram resides, allowing the kernel to easily use disk storage for data that does not fit into physical RAM.<br />
<br />
Historically, the general rule for swap partition size was 2x the amount of physical RAM. Over time, as computers have gained ever larger memory capacities, this rule has become increasingly deprecated. Generally, on machines with up to 512MB RAM, the 2x rule is usually quite sufficient. On machines with 1GB RAM, generally a 1x rule is adequate. If the installation machine provides gratuitous amounts of RAM (more than 1024 MB) it may be possible to completely forget a swap partition altogether, though this is not recommended (see note below). A 1 GB swap partition will be used in this example.<br />
{{Note|If using suspend-to-disk, (hibernate) a swap partition at least '''equal''' in size to the amount of physical RAM is required. Some Arch users even recommend oversizing it beyond the amount of physical RAM by 10-15%, to allow for possible bad sectors.}}<br />
<br />
=====Partition Scheme=====<br />
A disk partitioning scheme is a very personalized preference. Each user's choices will be unique to their own computing habits and requirements. If you would like to dual boot Arch Linux and a Windows operating systems please see [[Windows and Arch Dual Boot]].<br />
<br />
Filesystem candidates for separate partitions include:<br />
<br />
'''/''' (root) ''The root filesystem is the primary filesystem from which all other filesystems stem; the top of the hierarchy. All files and directories appear under the root directory &quot;/&quot;, 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. Therefore, certain directories under / are not themselves candidates for separate partitions. (See warning below).''<br />
<br />
'''/boot''' ''This directory contains 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. /boot is essential for booting, but is unique in that it may still be kept on its own separate partition (if required).''<br />
<br />
'''/home''' ''User data and user specific configuration files for applications are stored in each user's home directory in a file that starts with the '.' character (a &quot;dot file&quot;).''<br />
<br />
'''/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 update/upgrade. Any information that is host-specific or varies with time is stored elsewhere.''<br />
<br />
'''/tmp''' ''directory for programs that require temporary files''<br />
<br />
'''/var''' ''contains variable data; spool directories and files, administrative and logging data, pacman's cache, the ABS tree, etc.''<br />
{{Warning | Besides /boot, directories essential for booting are: ''''''/bin', '/dev', '/etc', '/lib', '/proc' and '/sbin'. Therefore, they must not reside on a separate partition from /.'''''}}<br />
'''''There are several advantages for using discrete filesystems, rather than combining all into one partition''''':<br />
<br />
* Security: Each filesystem may be configured in /etc/fstab as 'nosuid', 'nodev', 'noexec', 'readonly', etc.<br />
* Stability: A user, or malfunctioning program can completely fill a filesystem with garbage if they have write permissions for it. Critical programs, which reside on a different filesystem remain unaffected.<br />
* Speed: A filesystem which gets written to frequently may become somewhat fragmented. (An effective method of avoiding fragmentation is to ensure that each filesystem is never in danger of filling up completely.) Separate filesystems remain unaffected, and each can be defragmented separately as well.<br />
* Integrity: If one filesystem becomes corrupted, separate filesystems remain unaffected.<br />
* Versatility: Sharing data across several systems becomes more expedient when independent filesystems are used. Separate filesystem types may also be chosen based upon the nature of data and usage.<br />
In this example, we shall use separate partitions for /, /var, /home, and a swap partition.<br />
<br />
{{Note | /var contains many small files. This should be taken into consideration when choosing a filesystem type for it, (if creating its own separate partition).}}<br />
<br />
=====How big should my partitions be?=====<br />
This question is best answered based upon individual needs.<br />
You may wish to simply create '''one partition for root and one partition for swap or only one root partition without swap''' or refer to the following examples and consider these guidelines to provide a frame of reference:<br />
* The root filesystem (/) in the example will contain the /usr directory, which can become moderately large, depending upon how much software is installed. 15-20 GB should be sufficient for most users.<br />
<br />
* The /var filesystem will contain, among other data, the [[ABS]] tree and the pacman cache. Keeping cached packages is useful and versatile; it provides the ability to downgrade packages if needed. /var tends to grow in size; the pacman cache can grow large over long periods of time, but can be safely cleared if needed. If you are using an SSD, you may wish to locate your /var on an HDD and keep the / and /home partitions on your SSD to avoid needless read/writes to the SSD. 6-8 Gigs on a desktop system should be sufficient for /var. Servers tend to have extremely large /var filesystems.<br />
<br />
* The /home filesystem is typically where user data, downloads, and multimedia reside. On a desktop system, /home is typically the largest filesystem on the drive by a large margin. Remember that if you chose to reinstall Arch, all the data on your /home partition will be untouched (so long as you have a separate /home partition). <br />
<br />
* An extra 25% of space added to each filesystem will provide a cushion for unforeseen occurrence, expansion, and serve as a preventive against fragmentation.<br />
'''''From the guidelines above, the example system shall contain a ~15GB root (/) partition, ~7GB /var, 1GB swap, and a /home containing the remaining disk space.'''''<br />
<br />
=====Create Partition:cfdisk=====<br />
Start by creating the primary partition that will contain the '''root''', (/) filesystem.<br />
<br />
Choose '''N'''ew -> Primary and enter the desired size for root (/). Put the partition at the beginning of the disk.<br />
<br />
Also choose the '''T'''ype by designating it as '83 Linux'. The created / partition shall appear as sda1 in our example.<br />
<br />
Now create a primary partition for /var, designating it as '''T'''ype 83 Linux. The created /var partition shall appear as sda2<br />
<br />
Next, create a partition for swap. Select an appropriate size and specify the '''T'''ype as 82 (Linux swap / Solaris). The created swap partition shall appear as sda3.<br />
<br />
Lastly, create a partition for your /home directory. Choose another primary partition and set the desired size.<br />
<br />
Likewise, select the '''T'''ype as 83 Linux. The created /home partition shall appear as sda4.<br />
<br />
Example:<br />
<br />
Name Flags Part Type FS Type [Label] Size (MB)<br />
-------------------------------------------------------------------------<br />
sda1 Primary Linux 15440 #root<br />
sda2 Primary Linux 6256 #/var<br />
sda3 Primary Linux swap / Solaris 1024 #swap<br />
sda4 Primary Linux 140480 #/home<br />
<br />
Choose '''W'''rite and type ''''yes''''. Beware that this operation may destroy data on your disk. Choose '''Q'''uit to leave the partitioner.<br />
Choose Done to leave this menu and continue with &quot;Set Filesystem Mountpoints&quot;.<br />
<br />
{{Note | Since the latest developments of the Linux kernel which include the libata and PATA modules, all IDE, SATA and SCSI drives have adopted the sd''x'' naming scheme. This is perfectly normal and should not be a concern.}}<br />
<br />
====Set Filesystem Mountpoints====<br />
First you will be asked for your swap partition. Choose the appropriate partition (sda3 in this example). You will be asked if you want to create a swap filesystem; select yes. Next, choose where to mount the / (root) directory (sda1 in the example). At this time, you will be asked to specify the filesystem type.<br />
<br />
=====Filesystem Types=====<br />
Again, a filesystem type is a very subjective matter which comes down to personal preference. Each has its own advantages, disadvantages, and unique idiosyncrasies. Here is a very brief overview of supported filesystems:<br />
<br />
1. '''ext2''' ''Second Extended Filesystem''- Old, reliable GNU/Linux filesystem. Very stable, but ''without journaling support''. May be inconvenient for root (/) and /home, due to very long fsck's. ''An ext2 filesystem can easily be converted to ext3.'' Generally regarded as a good choice for /boot/.<br />
<br />
2. '''ext3''' ''Third Extended Filesystem''- Essentially the ext2 system, but with journaling support. ext3 is completely compatible with ext2. ''Extremely'' stable, mature, and by far the most widely used, supported and developed GNU/Linux FS.<br />
<br />
'''High Performance Filesystems:'''<br />
<br />
3. '''ext4''' ''Fourth Extended Filesystem''- Backward compatible with ext2 and ext3, Introduces support for volumes with sizes up to 1 exabyte and files with sizes up to 16 terabyte. Increases the 32,000 subdirectory limit in ext3 to 64,000. Offers online defragmentation ability. <br />
{{Note | ext4 is a new filesystem and may have some bugs.}}<br />
<br />
4. '''ReiserFS''' (V3)- Hans Reiser's high-performance journaling FS uses a very interesting method of data throughput based on an unconventional and creative algorithm. ReiserFS is touted as very fast, especially when dealing with many small files. ReiserFS is fast at formatting, yet comparatively slow at mounting. Quite mature and stable. ReiserFS is not actively developed at this time (Reiser4 is the new Reiser filesystem). Generally regarded as a good choice for /var/.<br />
<br />
5. '''JFS''' - IBM's '''J'''ournaled '''F'''ile'''S'''ystem- The first filesystem to offer journaling. JFS had many years of use in the IBM AIX® OS before being ported to Linux. JFS currently uses the least CPU resources of any GNU/Linux filesystem. Very fast at formatting, mounting and fsck's, and very good all-around performance, especially in conjunction with the deadline I/O scheduler. (See [[JFS]].) Not as widely supported as ext or ReiserFS, but very mature and stable.<br />
<br />
6. '''XFS''' - Another early journaling filesystem originally developed by Silicon Graphics for the IRIX OS and ported to Linux. XFS offers very fast throughput on large files and large filesystems. Very fast at formatting and mounting. Generally benchmarked as slower with many small files, in comparison to other filesystems. XFS is very mature and offers online defragmentation ability.<br />
* JFS and XFS filesystems cannot be ''shrunk'' by disk utilities (such as gparted or parted magic)<br />
<br />
===== A note on Journaling=====<br />
All above filesystems, except ext2, utilize [http://en.wikipedia.org/wiki/Journaling_file_system journaling]. Journaling file systems are fault-resilient file systems that use a journal to log changes before they are committed to the file system to avoid metadata corruption in the event of a crash. Note that not all journaling techniques are alike; specifically, only ext3 and ext4 offer ''data-mode journaling'', (though, not by default), which journals ''both'' data ''and'' meta-data (but with a significant speed penalty). The others only offer ''ordered-mode journaling'', which journals meta-data only. While all will return your filesystem to a valid state after recovering from a crash, ''data-mode journaling'' offers the greatest protection against file system corruption and data loss but can suffer from performance degradation, as all data is written twice (first to the journal, then to the disk). Depending upon how important your data is, this may be a consideration in choosing your filesystem type.<br />
<br />
'''''Moving on...'''''<br />
<br />
Choose and create the filesystem (format the partition) for / by selecting '''yes'''. You will now be prompted to add any additional partitions. In our example, sda2 and sda4 remain. For sda2, choose a filesystem type and mount it as /var. Finally, choose the filesystem type for sda4, and mount it as /home. <br />
{{Box Note |If you have not created and do not need a separate /boot partition, you may safely ignore the warning that it does not exist.}} Return to the main menu.<br />
<br />
===D: Select Packages===<br />
<br />
*Core ISO: Choose CD as source and select the appropriate CD drive if more than one exist on the installation machine.<br />
*Netinstall: Select an FTP/HTTP mirror. ''Note that archlinux.org is throttled to 50KB/s''.<br />
<br />
Package selection is split into two stages. First, select the package category:<br />
{{Note | For expedience, all packages in '''base''' are selected by default. Use the space-bar to select and de-select packages.}}<br />
* '''Base''': The minimal base environment. ''Always select it and only remove packages that will not be used.''<br />
* '''Base-devel''': Extra tools such as '''make''', '''automake''' and '''wireless-tools''' as well as wireless firmwares. ''Most beginners should choose to install it, and will probably need it later.<br />
''<br />
After category selection, you will be presented with the full lists of packages, allowing you to fine-tune your selections. Use the space bar to select and unselect.<br />
<br />
{{Note | If you are going to require connection to a wireless network with WPA encryption, consider installing netcfg2 (as well as wireless_tools), which will enable you to do so.}}<br />
<br />
Adter selecting the needed packages, leave the selection<br />
screen and continue to the next step, Install Packages.<br />
<br />
===E: Install Packages===<br />
Next, choose 'Install Packages'. You will be asked if you wish to keep the packages in the pacman cache. If you choose 'yes', you will have the flexibility to [[Downgrade packages|downgrade]] to previous package versions in the future, so this is recommended (you can always clear the cache in the future). The installer script will now install the selected packages, as well as the default Arch 2.6 kernel, to your system.<br />
*Netinstall: The [[Pacman]] package manager will now download and install your selected packages. (See vc/5 for output, vc/1 to return to the installer)<br />
*Core image: The packages will be installed from the CD/USB stick.<br />
<br />
===F: Configure the System===<br />
''Closely following and understanding these steps is of key importance to ensure a properly configured system.''<br />
<br />
*At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system.<br />
<br />
*Previous versions of the installer included [[Hwdetect|hwdetect]] to gather information for your configuration. This has been deprecated, and '''[[Udev|udev]]''' should handle most module loading automatically at boot.<br />
<br />
Now you will be asked which text editor you want to use; choose [[Nano|nano]], [http://joe-editor.sourceforge.net/ joe] or [[Vim|vi]], ('''nano''' is generally considered easiest of the 3). You will be presented with a menu including the main configuration files for your system. <br />
<br />
{{Note | ''It is very important at this point to edit, or at least verify by opening, every configuration file.'' The installer script relies on your input to create these files on your installation. A common error is to skip over these critical steps of configuration.}}<br />
<br />
=====Can the installer handle this more automatically?=====<br />
Hiding the process of system configuration is in direct opposition to '''''[[The Arch Way]]'''''. While it is true that recent versions of the kernel and hardware probing tools offer excellent hardware support and auto-configuration, Arch presents the user all pertinent configuration files during installation for the purposes of ''transparency and system resource control''. By the time you have finished modifying these files to your specifications, you will have learned the simple method of manual Arch Linux system configuration and become more familiar with the base structure, leaving you better prepared to use and maintain your new installation productively.<br />
<br />
'''''Moving on...'''''<br />
<br />
====/etc/rc.conf====<br />
Arch Linux uses the file '''/etc/rc.conf''' as the principal location for system configuration. This one file contains a wide range of configuration information, principally used at system startup. As its name directly implies, it also contains settings for and invokes the /etc/rc* files, and is, of course, sourced ''by'' these files.<br />
<br />
=====LOCALIZATION section=====<br />
* '''LOCALE'''=: This sets your system locale, which will be used by all i18n-aware applications and utilities. You can get a list of the available locales by running 'locale -a' from the command line. This setting's default is fine for US English users.<br />
* '''HARDWARECLOCK'''=: Specifies whether the hardware clock, which is synchronized on boot and on shutdown, stores '''UTC''' time, or '''localtime'''. UTC makes sense because it greatly simplifies changing timezones and daylight savings time. localtime is necessary if you dual boot with an operating system such as Windows, that only stores localtime to the hardware clock.<br />
* '''USEDIRECTISA'''=: Use direct I/O request instead of /dev/rtc for hwclock<br />
* '''TIMEZONE'''=: Specify your TIMEZONE. (All available zones are under /usr/share/zoneinfo/).<br />
* '''KEYMAP'''=: The available keymaps are in /usr/share/kbd/keymaps. Please note that this setting is only valid for your TTYs, not any graphical window managers or '''X'''.<br />
* '''CONSOLEFONT'''=: Available console fonts reside under /usr/share/kbd/consolefonts/ if you must change. The default (blank) is safe.<br />
* '''CONSOLEMAP'''=: Defines the console map to load with the setfont program at boot. Possible maps are found in /usr/share/kbd/consoletrans, if needed. The default (blank) is safe.<br />
* '''USECOLOR'''=: Select &quot;yes&quot; if you have a color monitor and wish to have colors in your consoles.<br />
LOCALE=&quot;en_US.utf8&quot;<br />
HARDWARECLOCK=&quot;localtime&quot;<br />
USEDIRECTISA=&quot;no&quot;<br />
TIMEZONE=&quot;US/Eastern&quot;<br />
KEYMAP=&quot;us&quot;<br />
CONSOLEFONT=<br />
CONSOLEMAP=<br />
USECOLOR=&quot;yes&quot;<br />
<br />
=====HARDWARE Section=====<br />
* '''MOD_AUTOLOAD'''=: Setting this to &quot;yes&quot; will use '''udev''' to automatically probe hardware and load the appropriate modules during boot, (convenient with the default modular kernel). Setting this to &quot;no&quot; will rely on the user's ability to specify this information manually, or compile their own custom kernel and modules, etc.<br />
* '''MOD_BLACKLIST'''=: This has become deprecated in favor of adding blacklisted modules directly to the '''MODULES=''' line below.<br />
* '''MODULES'''=: Specify additional MODULES if you know that an important module is missing. If your system has any floppy drives, add "floppy". If you will be using loopback filesystems, add "loop". Also specify any blacklisted modules by prefixing them with a bang (!). Udev will be forced NOT to load blacklisted modules. In the example, the IPv6 module as well as the annoying pcspeaker are blacklisted.<br />
# Scan hardware and load required modules at boot<br />
MOD_AUTOLOAD=&quot;yes&quot;<br />
# Module Blacklist - Deprecated<br />
MOD_BLACKLIST=()<br />
#<br />
MODULES=(!net-pf-10 !snd_pcsp !pcspkr loop)<br />
<br />
=====NETWORKING Section=====<br />
* '''HOSTNAME'''=:Set your HOSTNAME to your liking.<br />
* '''eth0'''=: 'Ethernet, card 0'. Adjust the interface IP address, netmask and broadcast address ''if'' you are using '''static IP'''. Set eth0=&quot;dhcp&quot; if you want to use '''DHCP'''<br />
* '''INTERFACES'''=: Specify all interfaces here. <br />
* '''gateway'''=: If you are using '''static IP''', set the gateway address. If using '''DHCP''', you can usually ignore this variable, though some users have reported the need to define it.<br />
* '''ROUTES'''=: If you are using static '''IP''', remove the '''!''' in front of 'gateway'. If using '''DHCP''', you can usually leave this variable commented out with the bang (!), but again, some users require the gateway and ROUTES defined. If you experience networking issues with pacman, for instance, you may want to return to these variables.<br />
<br />
====== Example, using a dynamically assigned IP address ('''DHCP''') ======<br />
<br />
HOSTNAME=&quot;arch&quot;<br />
#eth0=&quot;eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255&quot;<br />
eth0=&quot;dhcp&quot;<br />
INTERFACES=(eth0)<br />
gateway=&quot;default gw 192.168.0.1&quot;<br />
ROUTES=(!gateway)<br />
<br />
======Example, using a '''static''' IP address======<br />
<br />
HOSTNAME=&quot;arch&quot;<br />
eth0="eth0 192.168.0.2 netmask 255.255.255.0 broadcast 192.168.0.255"<br />
INTERFACES=(eth0)<br />
gateway="default gw 192.168.0.1"<br />
ROUTES=(gateway)<br />
<br />
Modify {{Filename|/etc/resolv.conf}} to contain the DNS servers of choice. Example:<br />
<br />
search my.isp.net.<br />
nameserver 4.2.2.1<br />
nameserver 4.2.2.2<br />
nameserver 4.2.2.3<br />
<br />
Various processes can overwrite the contents of {{filename|/etc/resolv.conf}}. For example, by default Arch Linux uses the '''dhcpcd''' DHCP client, which will overwrite the file when it starts. [[Resolv.conf|Various methods]] may be used to preserve the nameserver settings in {{filename|/etc/resolv.conf}}. For example, dhcpcd's configurations file may be edited to prevent the dhcpcd daemon from overwriting the file. To do this, you will need to modify the {{Filename|/etc/conf.d/dhcpcd}} configuration:<br />
<br />
# Arguments to be passed to the DHCP client daemon<br />
# DHCPCD_ARGS="-q"<br />
DHCPCD_ARGS="-C resolv.conf -q"<br />
<br />
{{tip|If using a non-standard MTU size (a.k.a. jumbo frames) is desired AND the installation machine hardware supports them, see the [[Jumbo Frames]] wiki article for further configuration.}}<br />
<br />
=====DAEMONS Section=====<br />
This array simply lists the names of those scripts contained in /etc/rc.d/ which are to be started during the boot process, and the order in which they start. <br />
DAEMONS=(network @syslog-ng netfs @crond)<br />
*If a script name is prefixed with a bang (!), it is not executed.<br />
*If a script is prefixed with an &quot;at&quot; symbol (@), it shall be executed in the background; the startup sequence will not wait for successful completion of each daemon before continuing to the next. (Useful for speeding up system boot). Do not background daemons that are needed by other daemons. For example "mpd" depends on "network", therefore backgrounding network may cause mpd to break.<br />
*Edit this array whenever new system services are installed, if starting them automatically during boot is desired.<br />
<br />
{{Note | This 'BSD-style' init, is the Arch way of handling what other distributions handle with various symlinks to an /etc/init.d directory.}}<br />
<br />
======About DAEMONS======<br />
The [[daemons]] line need not be changed at this time, but it is useful to explain what daemons are, as they will be addressed later in this guide.<br />
A ''daemon'' is a program that runs in the background, waiting for events to occur and offering services. A good example is a webserver that waits for a request to deliver a page (e.g.:httpd) or an SSH server waiting for a user login (e.g.:sshd). While these are full-featured applications, there are also daemons whose work is not that visible. Examples are a daemon which writes messages into a log file (e.g. syslog, metalog), a daemon which lowers the CPU frequency if the system has nothing to do (e.g.:cpufreq), and a daemon which provides a graphical login (e.g.: gdm, kdm). All these programs can be added to the daemons line and will be started when the system boots. Useful daemons will be presented during this guide.<br />
<br />
Historically, the term ''daemon'' was coined by the programmers of MIT's Project MAC. They took the name from ''Maxwell's demon'', an imaginary being from a famous thought experiment that constantly works in the background, sorting molecules. <tt>UNIX</tt> systems inherited this terminology and created the backronym '''d'''isk '''a'''nd '''e'''xecution '''mon'''itor.<br />
<br />
{{Tip|All Arch daemons reside under /etc/rc.d/}}<br />
<br />
====/etc/fstab====<br />
The '''fstab''' (for '''f'''ile '''s'''ystems '''tab'''le) is part of the system configuration listing all available disks and disk partitions, and indicating how they are to be initialized or otherwise integrated into the overall system's filesystem. The '''/etc/fstab''' file is most commonly used by the '''mount''' command. The mount command takes a filesystem on a device, and adds it to the main system hierarchy that you see when you use your system. '''mount -a''' is called from /etc/rc.sysinit, about 3/4 of the way through the boot process, and reads /etc/fstab to determine which options should be used when mounting the specified devices therein. If '''noauto''' is appended to a filesystem in /etc/fstab, '''mount -a''' will not mount it at boot.<br />
<br />
=====An example /etc/fstab=====<br />
# <file system> <dir> <type> <options> <dump> <pass><br />
none /dev/pts devpts defaults 0 0<br />
none /dev/shm tmpfs defaults 0 0<br />
#/dev/cdrom /media/cdrom auto ro,user,noauto,unhide 0 0<br />
#/dev/dvd /media/dvd auto ro,user,noauto,unhide 0 0<br />
#/dev/fd0 /media/fl auto user,noauto 0 0<br />
/dev/sda1 / jfs defaults,noatime 0 1<br />
/dev/sda2 /var reiserfs defaults,noatime,notail 0 2<br />
/dev/sda3 swap swap defaults 0 0<br />
/dev/sda4 /home jfs defaults,noatime 0 2<br />
{{Note | The 'noatime' option disables writing read access times to the metadata of files and may safely be appended to / and /home regardless of your specified filesystem type for increased speed, performance, and power efficiency (see [http://kerneltrap.org/node/14148 here] for more). 'notail' disables the ReiserFS tailpacking feature, for added performance at the cost of slightly less efficient disk usage.}}<br />
<br />
* '''<file system>''': describes the block device or remote filesystem to be mounted. For regular mounts, this field will contain a link to a block device node (as created by mknod which is called by udev at boot) for the device to be mounted; for instance, '/dev/cdrom' or '/dev/sda1'. <br />
{{Note | Rather than the sd''x'' naming scheme, you may choose to use UUID, or other persistent block device naming schemes for consistent device mapping. Due to active developments in the kernel and also udev, the ordering in which drivers for storage controllers are loaded may change randomly, yielding an unbootable system/kernel panic. Nearly every motherboard has several controllers (onboard SATA, onboard IDE), and due to the aforementioned development updates, /dev/sda may become /dev/sdb on the next reboot. (See [[Persistent block device naming| this wiki article]] for more information on persistent block device naming. )}}<br />
<br />
* '''<dir>''': describes the mount point for the filesystem. For swap partitions, this field should be specified as 'swap'; (Swap partitions are not actually mounted.)<br />
<br />
* '''<type>''': describes the type of the filesystem. The Linux kernel supports many filesystem types. (For the filesystems currently supported by the running kernel, see /proc/filesystems). An entry 'swap' denotes a file or partition to be used for swapping. An entry 'ignore' causes the line to be ignored. This is useful to show disk partitions which are currently unused.<br />
<br />
* '''<options>''': describes the mount options associated with the filesystem. It is formatted as a comma separated list of options with no intervening spaces. It contains at least the type of mount plus any additional options appropriate to the filesystem type. For documentation on the available options for non-nfs file systems, see mount(8).<br />
<br />
* '''<dump>''': used by the dump(8) command to determine which filesystems are to be dumped. dump is a backup utility. If the fifth field is not present, a value of zero is returned and dump will assume that the filesystem does not need to be backed up. ''Note that dump is not installed by default.''<br />
<br />
* '''<pass>''': used by the fsck(8) program to determine the order in which filesystem checks are done at boot time. The root filesystem should be specified with a <pass> of 1, and other filesystems should have a <pass> of 2 or 0. Filesystems within a drive will be checked sequentially, but filesystems on different drives will be checked at the same time to utilize parallelism available in the hardware. If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked.<br />
<br />
*If you plan on using '''hal''' to automount media such as DVDs, you may wish to comment out the cdrom and dvd entries in preparation for '''hal''', which will be installed later in this guide.<br />
<br />
Expanded information available in the [[Fstab]] wiki entry.<br />
<br />
===='''[[Configuring mkinitcpio | /etc/mkinitcpio]].conf'''====<br />
''Most users will not need to modify this file at this time, but please read the following explanatory information.''<br />
<br />
This file allows further fine-tuning of the initial ram filesystem, or initramfs, (also historically referred to as the initial ramdisk or &quot;initrd&quot;) for your system. The initramfs is a gzipped image that is read by the kernel during boot. 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 from a USB/FW drive). Once the initrramfs loads the proper modules, either manually or through udev, it passes control to the kernel and your boot continues. For this reason, the initramfs 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 common kernel modules will be loaded later on by udev, during the init process.<br />
<br />
'''mkinitcpio''' is the next generation of '''initramfs creation'''. It has many advantages over the old '''mkinitrd''' and '''mkinitramfs''' scripts.<br />
<br />
* It uses '''klibc''' and '''kinit''' which are developed by Linux kernel devs to provide a small and lightweight base for early userspace.<br />
* It can use '''udev''' for hardware autodetection at runtime, thus prevents you from having tons of unnecessary modules loaded.<br />
* Its hook-based init script is easily extendable with custom hooks, which can easily be included in pacman packages without having to modifiy mkinitcpio itself.<br />
* It already supports '''lvm2''', '''dm-crypt''' for both legacy and luks volumes, '''raid''', '''swsusp''' and '''suspend2''' resuming and booting from '''usb mass storage''' devices.<br />
* Many features can be configured from the kernel command line without having to rebuild the image.<br />
* The '''mkinitcpio''' script makes it possible to include the image in a kernel, thus making a self-contained kernel image is possible.<br />
* Its flexibility makes recompiling a kernel unnecessary in many cases.<br />
<br />
If using RAID or LVM on the root filesystem, the appropriate HOOKS must be configured. See the wiki pages for [[Installing with Software RAID or LVM| RAID]] and [[Configuring mkinitcpio | /etc/mkinitcpio]] for more info. If using a non-US keyboard. add the "<code>keymap</code>" hook to load your local keymap during boot. Add the "<code>usbinput</code>" hook if using a USB keyboard, e.g.:<br />
HOOKS="base udev autodetect pata scsi sata filesystems keymap usbinput"<br />
(Otherwise, if boot fails for some reason you will be asked to enter root's password for system maintenance but will be unable to do so.)<br />
<br />
If you need support for booting from USB devices, FireWire devices, PCMCIA devices, NFS shares, software RAID arrays, LVM2 volumes, encrypted volumes, or DSDT support, configure your HOOKS accordingly. <br />
<br />
If doing a CF or SD card install, you may need to add the <code>usbinput</code> HOOK for your system to boot properly. <br />
<br />
''If you are using a US keyboard, and have no need for any of the above HOOKS, editing this configuration should be unnecessary at this point.''<br />
<br />
'''mkinitcpio''' is an Arch innovation developed by Aaron Griffin and Tobias Powalowski with some help from the community.<br />
<br />
==== /etc/modprobe.d/modprobe.conf====<br />
<br />
This file can be used to set special configuration options for the kernel modules. It is unnecessary to configure this file at this time.<br />
<br />
====/etc/resolv.conf (for Static IP)====<br />
The ''resolver'' is a set of routines in the C library that provide access to the Internet Domain Name System (DNS). One of the main functions of DNS is to translate domain names into IP addresses, to make the Web a friendlier place. The resolver configuration file, or /etc/resolv.conf, contains information that is read by the resolver routines the first time they are invoked by a process.<br />
<br />
*''If you are using DHCP, you may safely ignore this file, as by default, it will be dynamically created and destroyed by the dhcpcd daemon. You may change this default behavior if you wish. (See [http://wiki.archlinux.org/index.php/Network#For_DHCP_IP Network]]).''<br />
<br />
If you use a static IP, set your DNS servers in /etc/resolv.conf (nameserver <ip-address>). You may have as many as you wish.<br />
An example, using OpenDNS:<br />
nameserver 208.67.222.222<br />
nameserver 208.67.220.220<br />
<br />
If you are using a router, you will probably want to specify your DNS servers in the router itself, and merely point to it from your '''/etc/resolv.conf''', using your router's IP (which is also your gateway from '''/etc/rc.conf'''), e.g.:<br />
nameserver 192.168.1.1<br />
<br />
If using '''DHCP''', you may also specify your DNS servers in the router, or allow automatic assignment from your ISP, if your ISP is so equipped.<br />
<br />
====/etc/hosts====<br />
This file associates IP addresses with hostnames and aliases, one line per IP address. For each host a single line should be present with the following information:<br />
<IP-address> <hostname> [aliases...]<br />
Add your ''hostname'', coinciding with the one specified in /etc/rc.conf, as an alias, so that it looks like this:<br />
127.0.0.1 localhost.localdomain localhost '''''yourhostname'''''<br />
{{Note |''This format, '''including the 'localhost' and your actual host name''', is required for program compatibility! So, if you have named your computer Archhost, then that line above should look like this:<br />
127.0.0.1 localhost.localdomain localhost Archhost<br />
Errors in this entry may cause poor network performance and/or certain programs to open very slowly, or not work at all. This is a very common error for beginners.''}}<br />
<br />
If you use a static IP, add another line using the syntax: <static-IP> <hostname.domainname.org> <hostname> e.g.:<br />
192.168.1.100 '''''yourhostname'''''.domain.org '''''yourhostname'''''<br />
<br />
{{Tip|For convenience, you may also use /etc/hosts aliases for hosts on your network, and/or on the Web, e.g.:<br />
64.233.169.103 www.google.com g<br />
192.168.1.90 media<br />
192.168.1.88 data<br />
The above example would allow you to access google simply by typing 'g' into your browser, and access to a media and data server on your network by name and without the need for typing out their respective IP addresses.}}<br />
<br />
====/etc/hosts.deny and /etc/hosts.allow====<br />
Modify these configurations according to your needs if you plan on using the [[SSH|ssh]] daemon. The default configuration will reject all incoming connections, not only ssh connections. Edit your '''/etc/hosts.allow '''file and add the appropriate parameters: <br />
<br />
* let everyone connect to you<br />
sshd: ALL<br />
<br />
* restrict it to a certain ip<br />
sshd: 192.168.0.1<br />
<br />
* restrict it to your local LAN network (range 192.168.0.0 to 192.168.0.255)<br />
sshd: 192.168.0.<br />
<br />
* OR restrict for an IP range<br />
sshd: 10.0.0.0/255.255.255.0<br />
<br />
If you do not plan on using the [[SSH|ssh]] daemon, leave this file at the default, (empty), for added security.<br />
<br />
====/etc/locale.gen====<br />
The '''/usr/sbin/locale-gen''' command reads from '''/etc/locale.gen''' to generate specific locales. They can then be used by '''glibc''' and any other locale-aware program or library for rendering text, correctly displaying regional monetary values, time and date formats, alphabetic idiosyncrasies, and other locale-specific standards. The ability to setup a default locale is a great built-in privilege of using a <tt>UNIX</tt>-like operating system.<br />
<br />
By default /etc/locale.gen is an empty file with commented documentation. Once edited, the file remains untouched. '''locale-gen''' runs on every '''glibc''' upgrade, generating all the locales specified in /etc/locale.gen.<br />
<br />
Choose the locale(s) you need (remove the # in front of the lines you want), e.g.:<br />
en_US ISO-8859-1<br />
en_US.UTF-8 <br />
<br />
The installer will now run the locale-gen script, which will generate the locales you specified. You may change your locale in the future by editing /etc/locale.gen and subsequently running 'locale-gen' as root.<br />
<br />
{{Note |'''''If you fail to choose your locale, this will lead to a &quot;The current locale is invalid...&quot; error. This is perhaps the most common mistake by new Arch users, and also leads to the most commonly asked questions on the forum.'''''}}<br />
<br />
====Pacman-Mirror====<br />
Choose a mirror repository for '''pacman'''. <br />
*''archlinux.org is throttled, limiting downloads to 50KB/s''<br />
<br />
====Root password====<br />
Finally, set a root password and make sure that you remember it later. Return to the main menu and continue with installing bootloader.<br />
<br />
===G: Install Bootloader===<br />
Because we have no secondary operating system in our example, we will need a bootloader. [http://www.gnu.org/software/grub/ GNU GRUB] is the recommended bootloader. Alternatively, you may choose [http://lilo.go.dyndns.org/ LILO].<br />
<br />
====GRUB====<br />
The provided '''GRUB''' configuration ('''/boot/grub/menu.lst''') should be sufficient, but verify its contents to ensure accuracy (specifically, ensure that the root (/) partition is specified by UUID on line 3). You may want to alter the resolution of the console by adding a vga=<number> kernel argument corresponding to your desired virtual console resolution. (A table of resolutions and the corresponding numbers is printed in the menu.lst.)<br />
<br />
Example: <br />
title Arch Linux (Main)<br />
root (hd0,0) <br />
kernel /boot/vmlinuz26 root=/dev/sda1 ro vga=773<br />
initrd /boot/kernel26.img<br />
{{Note | ''The linux kernel, 'vmlinuz', is so named because it incorporated '''v'''irtual '''m'''emory capability early in its development. The '''z''' denotes a zipped (compressed) image.''}}<br />
<br />
Explanation:<br />
<br />
Line 1: '''title''': A printed menu selection. &quot;Arch Linux (Main)&quot; will be printed on the screen as a menu selection.<br />
<br />
Line 2: '''root''': '''GRUB''''s root; the drive and partition where the kernel (/boot) resides, according to system BIOS. (More accurately, where GRUB's stage2 file resides). '''NOT necessarily the root''' (/) file system, as they can reside on separate partitions. GRUB's numbering scheme starts at 0, and uses an hd''x,x'' format regardless of IDE or SATA, and enclosed within parentheses. <br />
<br />
The example indicates that /boot is on the first partition of the first drive, according to BIOS, or, (hd0,0).<br />
<br />
Line 3: '''kernel''': This line specifies:<br />
<br />
* The path and filename of the kernel '''''relative to GRUB's root'''''.<br />
In the example, /boot is merely a directory residing on the same partition as / and '''vmlinuz26''' is the kernel filename; '''/boot/vmlinuz26'''. ''If /boot were on a separate partition, the path and filename would be simply '''/vmlinuz26''', being relative to '''GRUB''''s root.'' <br />
<br />
* The root= argument to the kernel statement specifies the partition containing the root (/) directory in the booted system, (more accurately, the partition containing '''/sbin/init'''). <br />
<br />
*An easy way to distinguish the 2 appearances of 'root' in /boot/grub/menu.lst is to remember that the first root statement ''informs GRUB where the kernel resides'', whereas the second root= kernel argument ''tells the kernel where the root filesystem (/) resides''.<br />
<br />
* Kernel options. <br />
<br />
In our example, '''ro''' mounts the filesystem as read only during startup, (usually a safe default; you may wish to change this in case it causes problems booting) and the '''&quot;vga=773&quot;''' argument will give a 1024x768 framebuffer with 256 color depth.<br />
<br />
Line 4: '''initrd''': (For Initial RAM disk) The path and filename of the initial RAM filesystem '''relative to GRUB''''s root. Again, in the example, /boot is merely a directory residing on the same partition as / and '''kernel26.img''' is the initrd filename; '''/boot/kernel26.img'''. ''If /boot were on a separate partition, the path and filename would be simply '''/kernel26.img''', being relative to '''GRUB''''s root.'' <br />
<br />
Install the '''GRUB''' bootloader (to the master boot record, sda in our example).<br />
{{tip|For more details, see the [[GRUB]] wiki page.}}<br />
<br />
===H: Reboot===<br />
That's it; You have configured and installed your Arch Linux base system. Exit the install, and reboot:<br />
# reboot<br />
(Be sure to remove the installer CD)<br />
<br />
==Part II: Configure & Update the New Arch Linux base system==<br />
Your new Arch Linux system will boot up and finish with a login prompt (you may want to change the boot order in your '''BIOS''' back to booting from hard disk).<br />
<br />
'''Congratulations, and welcome to your new Arch Linux base system!'''<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready for customization. From here, you may build this elegant set of tools into whatever you wish or require for your purposes. <br />
<br />
Login with the root account. We will configure pacman and update the system as root, then add a normal user. <br />
{{Note |Virtual consoles 1-6 are available. You may switch between them with ALT+F1...F6}}<br />
<br />
===Step 1: Configuring the network (if necessary)===<br />
*''This section will assist you in configuring most types of networks, if your network configuration is not working for you.''<br />
<br />
If you properly configured your system, you should have a working network. Try to ping www.google.com to verify this.<br />
# ping -c 3 www.google.com<br />
<br />
''If you have successfully established a network connection, continue with '''[[#Step 2: Update, Sync and Upgrade the system with pacman|Update, Sync and Upgrade the system with pacman]]'''.''<br />
<br />
If, after trying to ping www.google.com, an &quot;unknown host&quot; error is received, you may conclude that your network is not properly configured. You may choose to double-check the following files for integrity and proper settings:<br />
<br />
'''/etc/rc.conf''' # Specifically, check your HOSTNAME= and NETWORKING section for typos and errors.<br />
<br />
'''/etc/hosts''' # Double-check your format. (See above.)<br />
<br />
'''/etc/resolv.conf''' # If you are using a static IP. If you are using DHCP, this file will be dynamically created and destroyed by default, but can be changed to your preference. (See [[Network]].)<br />
<br />
{{Tip|Advanced instructions for configuring the network can be found in the [[Network]] article.}}<br />
<br />
====Wired LAN====<br />
<br />
Check your Ethernet with<br />
# ifconfig -a<br />
All interfaces will be listed. You should see an entry for eth0, or perhaps eth1. <br />
*'''Static IP'''<br />
<br />
If required, you can set a new static IP with:<br />
# ifconfig eth0 <ip address> netmask <netmask> up <br />
and the default gateway with<br />
# route add default gw <ip address of the gateway><br />
Verify that /etc/resolv.conf contains your DNS server and add it if it is missing. <br />
Check your network again with ping www.google.com. If everything is working now, adjust /etc/rc.conf as described above for static IP. <br />
*'''DHCP'''<br />
If you have a DHCP server/router in your network try:<br />
# dhcpcd eth0<br />
If this is working, adjust /etc/rc.conf as described above, for dynamic IP.<br />
<br />
====Wireless LAN====<br />
* Ensure the driver has created a usable interface:<br />
# iwconfig<br />
* Bring the interface up with <code>ifconfig <interface> up</code>. e.g.:<br />
# ifconfig wlan0 up<br />
* (Optional) Scan for available access points:<br />
# iwlist wlan0 scan | less<br />
* Specify the id of the wireless network with <code>iwconfig <interface> essid <youressid></code>. Or, if using WEP; <code>iwconfig <interface> essid <youressid> key <yourwepkey></code>, e.g.:<br />
# iwconfig wlan0 essid linksys key ABCDEF01234<br />
* Request an IP address with <code>dhcpcd <interface></code>. e.g.:<br />
# dhcpcd wlan0<br />
* Ensure you can route:<br />
$ ping -c 3 www.google.com<br />
Done.<br />
<br />
Detailed setup guide: [[Wireless Setup]]<br />
<br />
====Analog Modem====<br />
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.<br />
Tip: Read [[Dialup without a dialer HOWTO]].<br />
<br />
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 [http://www.linmodems.org/ LinModem] homepage.<br />
<br />
====ISDN====<br />
<br />
Setting up ISDN is done in three steps:<br />
# Install and configure hardware<br />
# Install and configure the ISDN utilities<br />
# Add settings for your ISP <br />
<br />
The current Arch stock kernels include the necessary ISDN modules, meaning that you will not need to recompile your kernel unless you're about to use rather odd ISDN hardware. After physically installing your ISDN card in your machine or plugging in your USB ISDN-Box, you can try loading the modules with modprobe. Nearly all passive ISDN PCI cards are handled by the hisax module, which needs two parameters: type and protocol. You must set protocol to '1' if your country uses the 1TR6 standard, '2' if it uses EuroISDN (EDSS1), '3' if you're hooked to a so-called leased-line without D-channel, and '4' for US NI1.<br />
<br />
Details on all those settings and how to set them is included in the kernel documentation, more specifically in the isdn subdirectory, and available online. The type parameter depends on your card; a list of all possible types can be found in the README.HiSax kernel documentation. Choose your card and load the module with the appropriate options like this:<br />
<br />
# modprobe hisax type=18 protocol=2<br />
<br />
This will load the hisax module for my ELSA Quickstep 1000PCI, being used in Germany with the EDSS1 protocol. You should find helpful debugging output in your /var/log/everything.log file, in which you should see your card being prepared for action. Please note that you will probably need to load some USB modules before you can work with an external USB ISDN Adapter.<br />
<br />
Once you have confirmed that your card works with certain settings, you can add the module options to your /etc/modprobe.conf:<br />
<br />
alias ippp0 hisax<br />
options hisax type=18 protocol=2<br />
<br />
Alternatively, you can add only the options line here, and add hisax to your MODULES array in the rc.conf. It's your choice, really, but this example has the advantage that the module will not be loaded until it's really needed.<br />
<br />
That being done, you should have working, supported hardware. Now you need the basic utilities to actually use it!<br />
<br />
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.<br />
<br />
After you have 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.<br />
<br />
If you set up everything correctly, you should now be able to establish a dial-up connection with<br />
# isdnctrl dial ippp0<br />
as root. If you have any problems, remember to check the logfiles!<br />
<br />
====DSL (PPPoE)====<br />
<br />
These instructions are relevant to you only 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.<br />
<br />
Before you can use your DSL online connection, you will have to physically install the network card that is supposed to be connected to the DSL-Modem into your computer. After adding your newly installed network card to the modules.conf/modprobe.conf or the MODULES array, you should install the rp-pppoe package and run the pppoe-setup script to configure your connection. After you have entered all the data, you can connect and disconnect your line with<br />
<br />
# /etc/rc.d/adsl start<br />
<br />
and<br />
<br />
# /etc/rc.d/adsl stop<br />
<br />
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' at boot, add adsl to your DAEMONS array, and put a ! before the network entry, since the network is handled by adsl now.<br />
<br />
===Step 2: Update, Sync, and Upgrade the system with [[pacman]]===<br />
Now we will update the system using [[pacman]]. <br />
<br />
====What is pacman ?====<br />
[[Pacman]] is the '''pac'''kage '''man'''ager of Arch Linux. Pacman is written in ''C'' and is designed from the ground up to be lightweight with a very modest memory footprint, fast, simple, and versatile. It manages your entire package system and handles installation, removal, package downgrade (through cache), custom compiled package handling, automatic dependency resolution, remote and local searches and much more. Pacman's output is streamlined, very readable and provides ETA for each package download. Arch uses the .tar.gz package format, which further enhances pacman's speed; Gzipped tarballs, though slightly larger, are decompressed many times faster than their Bzipped counterparts, and are therefore installed much more expediently. <br />
<br />
We will use pacman to download software packages from remote repositories and install them onto your system.<br />
<br />
Pacman is the most important tool in your Arch Linux toolbox for building the base system into whatsoever you please.<br />
<br />
====Package Repositories and /etc/pacman.conf====<br />
Arch currently offers the following 4 repositories readily accessible through pacman:<br />
<br />
'''[core]'''<br />
<br />
The simple principle behind [core] is to provide only one of each necessary tool for a base Arch Linux system; The GNU toolchain, the Linux kernel, one editor, one command line browser, etc. (There are a few exceptions to this. For instance, both vi and nano are provided, allowing the user to choose one or both.) It contains all the packages that MUST be in perfect working order to ensure the system remains in a usable state. These are the absolute system-critical packages. <br />
* Developer maintained<br />
* All binary packages<br />
* pacman accessible <br />
*''The Core installation media simply contains an installer script, and a snapshot of the core repository at the time of release.''<br />
<br />
'''[extra]'''<br />
<br />
The [extra] repository contains all Arch packages that are not themselves necessary for a base Arch system, but contribute to a more full-featured environment. '''X''', KDE, and Apache, for instance, can be found here. <br />
* Developer maintained<br />
* All binary packages<br />
* pacman accessible<br />
'''[testing]'''<br />
<br />
The [testing] repository contains packages that are candidates for the [core] or [extra] repositories. New packages go into [testing] if:<br />
<br />
<nowiki>*</nowiki> they are expected to break something on update and need to be tested first.<br />
<br />
<nowiki>*</nowiki> they require other packages to be rebuilt. In this case, all packages that need to be rebuilt are put into [testing] first and when all rebuilds are done, they are moved back to the other repositories. <br />
* Developer maintained<br />
* All binary packages<br />
* pacman accessible<br />
{{Note|* [testing] is the only repository that can have name collisions with any of the other official repositories. Therefore, if enabled, [testing] must be the first repo listed in <code>pacman.conf</code>.}}<br />
<br />
{{Warning|Only experienced users should use [testing].}}<br />
<br />
'''[community]'''<br />
<br />
The [community] repository is maintained by the ''Trusted Users (TUs)'' and is simply the binary branch of the ''Arch User Repository ([[AUR]])''. It contains binary packages which originated as PKGBUILDs from ''AUR'' [unsupported] that have acquired enough votes and were adopted by a ''TU''. Like all repos listed above, [community] may be readily accessed by pacman.<br />
* TU maintained<br />
* All binary packages<br />
* pacman accessible<br />
<br />
'''AUR (unsupported)'''<br />
<br />
The '''[[AUR]]''' also contains the '''unsupported''' branch, which cannot be accessed directly by pacman*. '''AUR''' [unsupported] does not contain binary packages. Rather, it provides more than sixteen thousand PKGBUILD scripts for building packages from source, that may be unavailable through the other repos. When an AUR unsupported package acquires enough popular votes, it may be moved to the AUR [community] binary repo, if a TU is willing to adopt and maintain it there.<br />
* TU maintained<br />
* All PKGBUILD bash build scripts<br />
* '''''Not''''' pacman accessible by default<br />
<br />
<nowiki>*</nowiki> pacman wrappers ('''''[[AUR Helpers]]''''') can help you seamlessly access AUR.<br />
<br />
'''/etc/pacman.conf'''<br />
<br />
pacman will attempt to read /etc/pacman.conf each time it is invoked. This configuration file is divided into sections, or repositories. Each section defines a package [[Official Repositories|repository]] that pacman can use when searching for packages. The exception to this is the options section, which defines global options.<br />
<br />
Note that the defaults should work, so modifying at this point may be unnecessary, but verification is always recommended. Further info available in the [[Mirrors]] article.<br />
# nano /etc/pacman.conf<br />
Example:<br />
#<br />
# /etc/pacman.conf<br />
#<br />
# See the pacman.conf(5) manpage for option and repository directives<br />
<br />
#<br />
# GENERAL OPTIONS<br />
#<br />
[options]<br />
# The following paths are commented out with their default values listed.<br />
# If you wish to use different paths, uncomment and update the paths.<br />
#RootDir = /<br />
#DBPath = /var/lib/pacman/<br />
#CacheDir = /var/cache/pacman/pkg/<br />
#LogFile = /var/log/pacman.log<br />
HoldPkg = pacman glibc<br />
# If upgrades are available for these packages they will be asked for first<br />
SyncFirst = pacman<br />
#XferCommand = /usr/bin/wget --passive-ftp -c -O %o %u<br />
#XferCommand = /usr/bin/curl %u > %o<br />
<br />
# Pacman won't upgrade packages listed in IgnorePkg and members of IgnoreGroup<br />
#IgnorePkg =<br />
#IgnoreGroup =<br />
<br />
#NoUpgrade =<br />
#NoExtract =<br />
<br />
# Misc options (all disabled by default)<br />
#NoPassiveFtp<br />
#UseSyslog<br />
#ShowSize<br />
#UseDelta<br />
#TotalDownload<br />
#<br />
# REPOSITORIES<br />
# - can be defined here or included from another file<br />
# - pacman will search repositories in the order defined here<br />
# - local/custom mirrors can be added here or in separate files<br />
# - repositories listed first will take precedence when packages<br />
# have identical names, regardless of version number<br />
# - URLs will have $repo replaced by the name of the current repo<br />
#<br />
# Repository entries are of the format:<br />
# [repo-name]<br />
# Server = ServerName<br />
# Include = IncludePath<br />
#<br />
# The header [repo-name] is crucial - it must be present and<br />
# uncommented to enable the repo.<br />
# <br />
<br />
# Testing is disabled by default. To enable, uncomment the following<br />
# two lines. You can add preferred servers immediately after the header,<br />
# and they will be used before the default mirrors.<br />
#[testing]<br />
#Include = /etc/pacman.d/mirrorlist<br />
<br />
[core]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
[extra]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist <br />
<br />
[community]<br />
# Add your preferred servers here, they will be used first<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
# An example of a custom package repository. See the pacman manpage for<br />
# tips on creating your own repositories.<br />
#[custom]<br />
#Server = file:///home/custompkgs<br />
<br />
Enable all desired repositories (remove the # in front of the 'Include =' and '[repository]' lines).<br />
<br />
<br />
*'''''When choosing repos, be sure to uncomment both the repository header lines in [brackets] as well as the 'Include =' lines. Failure to do so will result in the selected repository being omitted! This is a very common error.'' '''<br />
<br />
====/etc/pacman.d/mirrorlist ====<br />
Defines pacman repo mirrors and priorities.<br />
<br />
'''Build a mirrorlist using the rankmirrors script'''<br />
<br />
<code>/usr/bin/rankmirrors</code> is a python script which will attempt to detect the mirrors which are closest to the installation machine based on the mirrors specified in /etc/pacman.d/mirrorlist. Faster mirrors will dramatically improve pacman performance, and the overall Arch Linux experience. This script may be run periodically, especially if the chosen mirrors provide inconsistent throughput and/or updates.<br />
<br />
First, use pacman to install python:<br />
# pacman -Sy python <br />
'''cd''' to the /etc/pacman.d/ directory:<br />
# cd /etc/pacman.d<br />
Backup the existing /etc/pacman.d/mirrorlist:<br />
# cp mirrorlist mirrorlist.backup<br />
Edit mirrorlist.backup and uncomment all mirrors on the same continent or within geographical proximity to test with rankmirrors.<br />
# nano mirrorlist.backup<br />
Run the script against the mirrorlist.backup with the -n switch and redirect output to a new /etc/pacman.d/mirrorlist file:<br />
# rankmirrors -n 6 mirrorlist.backup > mirrorlist<br />
'''-n 6''': rank the 6 fastest mirrors<br />
<br />
'''Force pacman to refresh the package lists'''<br />
<br />
After creating/editing /etc/pacman.d/mirrorlist, (manually or by <code>/usr/bin/rankmirrors</code>) issue the following command:<br />
# pacman -Syy<br />
Passing two --refresh or -y flags forces pacman to refresh all package lists even if they are considered to be up to date. Issuing pacman -Syy ''whenever a mirror is changed'', is good practice and will avoid possible headaches.<br />
<br />
====Mirrorcheck for up-to-date packages====<br />
Some of the official mirrors may contain packages that are out-of-date. [http://users.archlinux.de/~gerbra/mirrorcheck.html ArchLinux Mirrorcheck] reports various aspects about the mirrors such as, those experiencing network problems, data collection problems, reports the last time they have been synced, etc.<br />
<br />
One may wish to manually inspect the mirrors in the /etc/pacman.d/mirrorlist insuring that it only contains up-to-date mirrors if having the latest package versions is a priority.<br />
<br />
====Ignoring packages====<br />
After executing the command &quot;pacman -Syu&quot;, the entire system will be updated. It is possible to prevent a package from being upgraded. A typical scenario would be a package for which an upgrade may prove problematic for the system. In this case, there are two options; indicate the package(s) to skip in the pacman command line using the --ignore switch (do pacman -S --help for details) or permanently indicate the package(s) to skip in the /etc/pacman.conf file in the IgnorePkg array. List each package, with one intervening space :<br />
IgnorePkg = wine <br />
The typical way to use Arch is to use pacman to install all packages unless there is no package available, in which case [[ABS]] may be used. Many user-contributed package build scripts are also available in the [[AUR]]. <br />
<br />
The power user is expected to keep the system up to date with pacman -Syu, rather than selectively upgrading packages. You may diverge from this typical usage as you wish; just be warned that there is a greater chance that things will not work as intended and that it could break your system. The majority of complaints happen when selective upgrading, unusual compilation or improper software installation is performed. Use of '''IgnorePkg''' in /etc/pacman.conf is therefore discouraged, and should only be used sparingly, if you know what you are doing.<br />
<br />
====Ignoring Configuration Files====<br />
In the same vein, you can also &quot;protect&quot; your configuration/system files from being overwritten during &quot;pacman -Su&quot; using the following option in your /etc/pacman.conf<br />
<br />
NoUpgrade = etc/lilo.conf boot/grub/menu.lst<br />
<br />
====Get familiar with pacman====<br />
pacman is the Arch user's best friend. It is highly recommended to study and learn how to use the pacman(8) tool. Try:<br />
$ man pacman<br />
<br />
For more information,please look up the [[pacman]] wiki entries at your leisure.<br />
<br />
====Powerpill, a pacman wrapper script====<br />
Before you continue, consider installing Xyne's powerpill (now in [community]) which is a pacman wrapper script that speeds up package retrieval by using aria2c (an external download helper) for concurrent/segmented downloads. In other words, powerpill pulls packages in parallel effectively speeding up your downloads. This is particularly advantageous on new installs when pulling down hundreds of megs of packages.<br />
<br />
# pacman -S powerpill<br />
<br />
Treat powerpill as pacman as you consider installations, for example, the following will update your system:<br />
<br />
# powerpill -Syu<br />
<br />
See the [[Powerpill]] wiki article for more.<br />
<br />
===Step 3: Update System===<br />
You are now ready to upgrade your entire system. Before you do, read through the [http://www.archlinux.org/news/ news] (and optionally the [http://archlinux.org/pipermail/arch-announce/ announce mailing list]). Often the developers will provide important information about required configurations and modifications for known issues. Consulting these pages before any upgrade is good practice. <br />
<br />
Sync, refresh, and upgrade your entire new system with:<br />
# pacman -Syu<br />
or:<br />
# pacman --sync --refresh --sysupgrade<br />
<br />
pacman will now download a fresh copy of the master package list from the server(s) defined in pacman.conf(5) and perform all available upgrades. (You may be prompted to upgrade pacman itself at this point. If so, say yes, and then reissue the pacman -Syu command when finished.) <br />
<br />
Reboot if a kernel upgrade has occurred. <br />
<br />
{{Note|Occasionally, configuration changes may take place requiring user action during an update; read pacman's output for any pertinent information.}}<br />
<br />
Pacman output is saved in /var/log/pacman.log.<br />
<br />
See [[Package_Management_FAQs|Package Management FAQs]] for answers to frequently asked questions regarding updating and managing your packages.<br />
<br />
=====The Arch rolling release model=====<br />
Keep in mind that Arch is a '''rolling release''' distribution. This means there is never a reason to reinstall or perform elaborate system rebuilds to upgrade to the newest version. Simply issuing '''pacman -Syu''' periodically keeps your entire system up-to-date and on the bleeding edge. At the end of this upgrade, your system is completely current. '''Reboot''' if a kernel upgrade has occurred.<br />
=====Network Time Protocol=====<br />
You may wish to set the system time now using OpenNTPD to sync the local clock to remote NTP servers. OpenNTPD may also be added to the DAEMONS= array in /etc/rc.conf to provide this service at each boot. (See the [[Network Time Protocol]] article.)<br />
<br />
===Step 4: Add a user and setup groups===<br />
<tt>UNIX</tt> is a multi-user environment. You should not do your everyday work using the root account. It is more than poor practice; it is dangerous. Root is for administrative tasks. Instead, add a normal, non-root user account using the <code>/usr/sbin/useradd</code> program:<br />
# useradd -m -G [groups] -s [login_shell] [username] <br />
* '''-m''' Creates user home directory as /home/'''username'''. Within their home directory, a user can write files, delete them, install programs, etc. Users' home directories shall 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 ''user'' (under /home/username) and ''global'' configuration files, (usually under /etc/) the settings in the ''user'' file will prevail. Dotfiles 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.<br />
* '''-G''' A list of supplementary groups which the user is also a member of. ''Each group is separated from the next by a comma, with no intervening spaces''. The default is for the user to belong only to the initial group (users). <br />
* '''-s''' The path and filename of the user´s default login shell.<br />
Useful groups for your non-root user include:<br />
*'''audio''' - for tasks involving sound card and related software<br />
*'''floppy''' - for access to a floppy if applicable<br />
*'''lp''' - for managing printing tasks<br />
*'''optical''' - for managing tasks pertaining to the optical drive(s)<br />
*'''storage''' - for managing storage devices<br />
*'''video''' - for video tasks and hardware acceleration<br />
*'''wheel''' - for using sudo<br />
*'''power''' - used w/ power options (e.g.: shutdown with power button) <br />
A typical desktop system example, adding a user named &quot;archie&quot; specifying bash as the login shell:<br />
# useradd -m -G users,audio,lp,optical,storage,video,wheel,power -s /bin/bash archie<br />
Next, add a password for your new user using <code>/usr/bin/passwd</code>.<br />
<br />
An example for our user, 'archie':<br />
# passwd archie<br />
(You will be prompted to provide the new <tt>UNIX</tt> password.)<br />
<br />
Your new non-root user has now been created, complete with a home directory and a login password.<br />
<br />
'''Alternative method, using <code>/usr/sbin/adduser</code>:'''<br />
<br />
Alternatively, you may use <code>adduser</code>, an interactive user adding program which will prompt you for the above data ''(recommended for beginners)'':<br />
# adduser<br />
'''Deleting the user account:'''<br />
<br />
In the event of error, or if you wish to delete this user account in favor of a different name or for any other reason, use <code>/usr/sbin/userdel</code>:<br />
# userdel -r [username]<br />
* '''-r ''' Files in the user´s home directory will be removed along with the home directory itself and the user´s mail spool.<br />
<br />
If you want to change the name of your user or any existing user, see the [[Change username]] page of the Arch wiki and/or the [[Groups]] and [[User Management]] articles for further information. You may also check the man pages for <code>usermod(8)</code> and <code>gpasswd(8)</code>.<br />
<br />
===Step 5: Install and setup Sudo (Optional)===<br />
There has been a recent update to the vi packages since the latest installation media (2009.08) was created. Therefore, before installing sudo, use the following command to remove the incompatible files:<br />
# rm /usr/bin/{view,rview}<br />
Install Sudo and vim:<br />
# pacman -S sudo vim<br />
To add a user as a sudo user (a &quot;sudoer&quot;), the visudo command must be run as root. If you do not know how to use vi, you may set the EDITOR environment variable to the editor of your choice before running visudo. e.g.:<br />
# EDITOR=nano visudo<br />
If you are comfortable using vi, issue the visudo command without the EDITOR=nano variable:<br />
# visudo<br />
This will open the file /etc/sudoers in a special session of vi. visudo copies the file to be edited to a temporary file, edits it with an editor, (vi by default), and subsequently runs a sanity check. If it passes, the temporary file overwrites the original with the correct permissions. <br />
<br />
{{Warning|Do not edit /etc/sudoers directly with an editor; Errors in syntax can cause annoyances (like rendering the root account unusable). You must use the ''visudo'' command to edit /etc/sudoers.}}<br />
<br />
To give the user full root privileges when he/she precedes a command with &quot;sudo&quot;, add the following line:<br />
USER_NAME ALL=(ALL) ALL<br />
where USER_NAME is the username of the individual.<br />
<br />
For more information, such as sudoer <TAB> completion, see [[Sudo]]<br />
<br />
==Part III: Install X and configure ALSA==<br />
<br />
<br />
===Step 1: Configure sound with alsamixer===<br />
The Advanced Linux Sound Architecture (known by the acronym '''ALSA''') is a Linux kernel component intended to replace the original Open Sound System (OSS) for providing device drivers for sound cards. Besides the sound device drivers, '''ALSA''' also bundles a user space library for application developers who want to use driver features with a higher level API than direct interaction with the kernel drivers.<br />
{{Note| Alsa is included in the Arch mainline kernel and udev will automatically probe your hardware at boot, loading the corresponding kernel module for your audio card. Therefore, your sound should already be working, but upstream sources mute all channels by default.}}<br />
{{Note| OSS4.1 has been released under a free license and is generally considered a significant improvement over older OSS versions. If you have issues with ALSA, or simply wish to explore another option, you may choose OSS4.1 instead. Instructions can be found in [[OSS]]}} <br />
<br />
The alsa-utils package contains the alsamixer userspace tool, which allows configuration of the sound device from the console or terminal.<br />
<br />
By default the upstream kernel sources ship with snd_pcsp, the alsa pc speaker module. snd_pcsp is usually loaded before your &quot;actual&quot; sound card module. In most cases, it will be more convenient if this module is loaded last, as it will allow alsamixer to correctly control the desired sound card.<br />
<br />
To have snd_pcsp load last, add the following to /etc/modprobe.d/modprobe.conf:<br />
options snd-pcsp index=2<br />
<br />
Alternatively, if you do not want snd_pcsp to load at all, blacklist it by adding the following to /etc/rc.conf:<br />
MODULES=(... !snd_pcsp)<br />
<br />
{{Note | You will need to unload all your sound modules and reload them for the changes to take effect. It might be easier to reboot. Your choice. }}<br />
<br />
Install the alsa-utils package:<br />
# pacman -S alsa-utils<br />
Also, you may want to install the alsa-oss package, which wraps applications written for [[OSS]] in a compatibility library, allowing them to work with [[ALSA]]. To install the alsa-oss package:<br />
# pacman -S alsa-oss <br />
Did you add your normal user to the audio group? If not, use <code>/usr/bin/gpasswd</code>. As root do:<br />
# gpasswd -a ''yourusername'' audio<br />
As '''''normal, non-root''''' user, invoke <code>/usr/bin/alsamixer</code>:<br />
# su - ''yourusername'' <br />
'''$''' alsamixer<br />
Unmute the Master and PCM channels by scrolling to them with cursor left/right and pressing '''M'''. Increase the volume levels with the cursor-up key. (70-90 Should be a safe range.) Some machines, (like the Thinkpad T61), have a '''Speaker''' channel which must be unmuted and adjusted as well. Leave alsamixer by pressing ESC. <br />
==== Sound test ====<br />
Ensure your speakers are properly connected, and test your sound configuration as normal user using <code>/usr/bin/aplay</code>:<br />
$ aplay /usr/share/sounds/alsa/Front_Center.wav<br />
You should hear a very eloquent woman say, &quot;Front, center.&quot;<br />
==== Saving the Sound Settings ====<br />
Exit your normal user shell and run <code>/usr/sbin/alsactl</code> as root:<br />
$ exit<br />
# alsactl store<br />
This will create the file '/etc/asound.state', saving the alsamixer settings. <br />
<br />
Also, add the alsa ''daemon'' to your DAEMONS section in /etc/rc.conf to automatically restore the mixer settings at boot.<br />
# nano /etc/rc.conf<br />
DAEMONS=(syslog-ng network crond '''alsa''')<br />
''Note that the alsa daemon merely restores your volume mixer levels on boot up by reading /etc/asound.state. It is separate from the alsa audio library (and kernel level API).''<br />
<br />
Expanded information available in the [[ALSA]] wiki entry.<br />
<br />
===Step 2: Install X===<br />
The '''X''' Window System version 11 (commonly '''X11''', or just simply '''X''') is a networking and display protocol which provides windowing on bitmap displays. It provides the standard toolkit and protocol to build graphical user interfaces (GUIs) on <tt>UNIX</tt>-like operating systems.<br />
<br />
'''X''' provides the basic framework, or primitives, for building GUI environments: drawing and moving windows on the screen and interacting with a mouse and/or keyboard. '''X''' does not mandate the user interface — individual client programs handle this. <br />
<br />
'''X''' is so named because it was preceded by the '''W''' Window System, originally developed at Stanford University. <br />
<br />
====A: The <code>X-Files</code>====<br />
Now we will install the base '''[[Xorg]]''' packages using pacman. This is the first step in building a GUI.<br />
If you plan on using an '''open-source''' video driver, and need 3d acceleration, install the libgl library before installing Xorg:<br />
# pacman -S libgl<br />
''(Proprietary video drivers provide their own gl library implementations.)''<br />
<br />
Install the base packages:<br />
# pacman -S xorg<br />
The 3d utilities glxgears and glxinfo are included in the '''mesa''' package:<br />
# pacman -S mesa<br />
<br />
====B: Install Video Driver Package====<br />
Now we have the base packages we need for running the '''X''' Server. You should add the driver for your graphics card now (e.g. xf86-video-<name>). The easiest way to configure X.org is by installing the correct driver packages first, and then generating /etc/X11/xorg.conf using an autoconfiguration script, like Xorg -configure.<br />
<br />
You will need knowledge of which video chipset your machine has. If you do not know, use the <code>/usr/sbin/lspci</code> program:<br />
# lspci | grep VGA<br />
<br />
If you need a list of all '''open-source''' video drivers, do: <br />
# pacman -Ss xf86-video | less<br />
Here is a list of '''open source''' drivers, and the corresponding video chipsets.<br />
*'''xf86-video-apm''' &mdash; Alliance ProMotion video driver<br />
*'''xf86-video-ark''' &mdash; ark video driver<br />
*'''xf86-video-ati''' &mdash; ATI(AMD) radeon video driver<br />
**'''xf86-video-r128''' &mdash; ATI(AMD) video driver for X.org ati Rage128 video<br />
**'''xf86-video-mach64''' &mdash; ATI(AMD) video driver for X.org mach64 video<br />
**'''xf86-video-radeonhd''' &mdash; ATI(AMD) radeonhd video driver<br />
*'''xf86-video-chips''' &mdash; Chips and Technologies video driver<br />
*'''xf86-video-cirrus''' &mdash; Cirrus Logic video driver<br />
*'''xf86-video-dummy''' &mdash; dummy video driver<br />
*'''xf86-video-fbdev''' &mdash; framebuffer video driver<br />
*'''xf86-video-glint''' &mdash; GLINT/Permedia video driver<br />
*'''xf86-video-i128''' &mdash; Number 0 i128 video driver<br />
*'''xf86-video-i740''' &mdash; Intel i740 video driver<br />
*'''xf86-video-i810''' &mdash; Intel i810/i830/i9xx video drivers (deprecated - use -intel)<br />
*'''xf86-video-intel''' &mdash; Newer Version of Intel i810/i830/i9xx video drivers<br />
*'''xf86-video-intel-legacy''' &mdash; Legacy-driver for older intel cards as 82865G (xf86-video-intel currently crashes with older cards)<br />
*'''xf86-video-imstt''' &mdash; Integrated Micro Solutions Twin Turbo video driver<br />
*'''xf86-video-mga''' &mdash; mga video driver (Matrox Graphics Adapter)<br />
*'''xf86-video-neomagic''' &mdash; neomagic video driver<br />
*'''xf86-video-nv''' &mdash; Nvidia nv video driver<br />
*'''xf86-video-nouveau''' &mdash; Open Source 3D acceleration driver for nVidia cards (experimental), check: [http://nouveau.freedesktop.org/wiki/] for Current Status<br />
*'''xf86-video-openchrome''' &mdash; VIA/S3G UniChrome, UniChrome Pro and Chrome9 video driver<br />
*'''xf86-video-rendition''' &mdash; Rendition video driver<br />
*'''xf86-video-s3''' &mdash; S3 video driver<br />
*'''xf86-video-s3virge''' &mdash; S3 Virge video driver<br />
*'''xf86-video-savage''' &mdash; savage video driver<br />
*'''xf86-video-siliconmotion''' &mdash; siliconmotion video driver<br />
*'''xf86-video-sis''' &mdash; SiS video driver<br />
*'''xf86-video-sisusb''' &mdash; SiS USB video driver<br />
*'''xf86-video-tdfx''' &mdash; tdfx video driver<br />
*'''xf86-video-trident''' &mdash; Trident video driver<br />
*'''xf86-video-tseng''' &mdash; tseng video driver<br />
*'''xf86-video-unichrome''' &mdash; VIA S3 Unichrome video drivers<br />
*'''xf86-video-v4l''' &mdash; v4l video driver<br />
*'''xf86-video-vesa''' &mdash; vesa video driver<br />
*'''xf86-video-vga''' &mdash; VGA 16 color video driver<br />
*'''xf86-video-vmware''' &mdash; vmware video driver<br />
*'''xf86-video-voodoo''' &mdash; voodoo video driver<br />
<br />
'''''Note''''': The '''vesa''' driver is the most generic, and should work with almost any modern video chipset. If you cannot find a suitable driver for your video chipset, vesa ''should'' work.<br />
<br />
Use pacman to install the appropriate video driver for your video card/onboard video. e.g.:<br />
# pacman -S xf86-video-savage<br />
(for the Savage driver.)<br />
<br />
*If you have an NVIDIA or ATI graphics card you may wish to install the proprietary NVIDIA or ATI drivers. '''Installing proprietary video drivers is covered below.'''.<br />
*If you do not want to install the proprietary drivers or do not have an NVIDIA or ATI graphics card, you should skip down to '''[[#Step 3: Configure X|Step 3: Configure X]]'''.<br />
<br />
-----<br />
<br />
<br />
=====NVIDIA Graphics Cards=====<br />
The NVIDIA proprietary drivers are generally considered to be of good quality, and offer 3D performance, whereas the open source '''nv''' driver offers only 2d support at this time. <br />
<br />
Before you configure your Graphics Card you will need to know which driver fits. Arch currently has several different driver packages that each match a certain subset of Cards: <br />
<br />
'''1. nvidia-96xx''' ''slightly newer cards up to the GF 4.''<br />
<br />
'''2. nvidia-173xx''' ''Geforce FX series cards''<br />
<br />
'''3. nvidia''' ''newest GPUs after the GF FX''<br />
<br />
{{Note| Nvidia-71xx series proprietary drivers, which are required by extremely old cards like TNT and TNT2, have been removed because they do not work with the new Xorg that Arch makes use of and nvidia has discontinued support for such. You should use the xf86-video-nv or xf86-video-vesa drivers instead.}}<br />
<br />
Consult the NVIDIA website to see which one is for you. The difference is only for the installation; Configuration works the same with every driver.<br />
<br />
Select and install the appropriate NVIDIA driver ''for your card'', e.g.: <br />
# pacman -S nvidia-96xx<br />
<br />
The NVIDIA package has a utility for updating your existing /etc/X11/xorg.conf for use with the NVIDIA driver:<br />
# nvidia-xconfig<br />
<br />
It also has several options which will further specify the contents and options of the xorg.conf file.<br />
For example,<br />
# nvidia-xconfig --composite --add-argb-glx-visuals<br />
<br />
For more detailed information, see nvidia-xconfig(1).<br />
<br />
Some useful tweaking options in the device section are (beware that these may not work on your system):<br />
Option &quot;RenderAccel&quot; &quot;true&quot;<br />
Option &quot;NoLogo&quot; &quot;true&quot;<br />
Option &quot;AGPFastWrite&quot; &quot;true&quot;<br />
Option &quot;EnablePageFlip&quot; &quot;true&quot;<br />
Make sure all instances of DRI are commented out:<br />
# Load &quot;dri&quot;<br />
Double check your /etc/X11/xorg.conf to make sure your default depth, horizontal sync, vertical refresh, and resolutions are acceptable.<br />
<br />
Update kernel module dependencies using <code>/sbin/depmod</code>:<br />
# depmod -a<br />
(A reboot may be necessary.)<br />
{{Tip|Advanced instructions for NVIDIA configuration can be found in the [[NVIDIA]] article.}}<br />
<br />
You may now continue with '''[[#Step 3: Configure X|Step 3: Configure X]]''' to familiarize yourself further, or continue the installation process with '''[[#C: Test X|Test X]]'''.<br />
<br />
=====ATI Graphics Cards=====<br />
ATI owners have multiple options for drivers. <br />
* The open source '''''radeon''''' driver provided by the '''xf86-video-ati''' package. <br />
** This is the original, reverse-engineered open source driver which fully supports Radeon chipsets up to X1950 (latest R500 chipsets). Cards up to the 9200 series are fully supported, stable, and provide full 2D and 3D acceleration. Cards from 9500 to X1950 feature full 2D acceleration, and stable 3D acceleration, but lack certain features provided by the proprietary driver, (for example, powersaving is still in a testing phase). Cards from HD2xxx (R6xx) to the newest are supported by xf86-video-ati, but only offer 2d support at this time.<br />
* The open source '''''radeonhd''''' driver provided by the '''xf86-video-radeonhd''' package.<br />
** This driver supports ATI R500 chipsets (Radeon X1000 series) and newer. It is written by Novell with specifications provided to the public by AMD. It supports RandR 1.2 and development is currently very active. Therefore, functionality may be inconsistent across the spectrum of cards supported. (Some users report excellent performance and reliability while others experience trouble.) It also supports HDMI, with sound.<br />
* The proprietary '''''fglrx''''' driver provided by the Catalyst package located in the AUR. The proprietary driver is covered below.<br />
The open-source drivers will usually suit most needs and are generally less problematic.<br />
<br />
Install the '''''radeon''''' ATI Driver with<br />
# pacman -S xf86-video-ati libgl ati-dri<br />
Install the '''''radeonhd''''' ATi Driver with<br />
# pacman -S xf86-video-radeonhd libgl ati-dri<br />
<br />
The proprietary ATI driver '''Catalyst''' was once a precompiled package offered by Arch in the <code>extra</code> repository, but as of March 2009, official support has been dropped because of dissatisfaction with the quality and speed of development of the proprietary driver.The catalyst driver is now available in [http://aur.archlinux.org/packages.php?ID=22899 AUR]. Installation information for Catalyst driver is available [[ATI#Proprietary_ATI_Catalyst_driver | here]]<br />
<br />
{{Warning| The proprietary ATI driver supports only R600 and newer devices (that means, HD2xxx and newer). Older series cards (X1xxx and older) are not supported.}}<br />
<br />
{{Tip|Advanced instructions for ATI configuration can be found in the [[ATI | ATI wiki article]].}}<br />
<br />
====C: Install Input Driver Packages====<br />
The latest X requires you to install drivers for your input devices, keyboard and mouse included. For a complete list of available input drivers,<br />
# pacman -Ss xf86-input | less<br />
<br />
For most users, xf86-input-keyboard and xf86-input-mouse should be sufficient for a basic setup. Use pacman to install your desired drivers for your input devices. e.g.:<br />
# pacman -S xf86-input-keyboard xf86-input-mouse<br />
<br />
===Step 3: Configure X===<br />
<br />
====A: The xorg.conf file====<br />
<br />
/etc/X11/xorg.conf is the main configuration file for your '''X''' Window System, the foundation of your '''G'''raphical '''U'''ser '''I'''nterface. It is a plain text file ordered into sections and subsections. Important sections are ''Files, InputDevice, Module, Monitor, Modes, Screen, Device, and ServerLayout''. Sections can appear in any order and there may be more than one section of each kind, for example, if you have more than one monitor, or if your laptop has a trackpoint as well as a mouse. <br />
<br />
Since X11R7.2 the X.Org X Server features autoconfiguration. Therefore, it can function without an xorg.conf file in many cases. ''If'' the autoconfiguration ''works satisfactorily'' and you do not need to specify special features such as aiglx, compositing and so forth, you may forgo creating an xorg.conf file and continue below with [[#B: Input hotplugging| Input hotplugging]].<br />
<br />
=====Standard xorg.conf generation=====<br />
<br />
Advanced users may wish to manually create their own xorg.conf file. You may also use the <code>/usr/bin/Xorg</code> program with the -configure option to generate a basic config file; As root, do:<br />
# Xorg -configure<br />
This will create a config file at /root/xorg.conf.new <br />
<br />
Copy the file to <code>/etc/X11/</code>:<br />
# cp /root/xorg.conf.new /etc/X11/xorg.conf<br />
<br />
=====Alternative xorg.conf generation=====<br />
<br />
Newer versions of the Xorg Server(>1.6) do not include the /usr/bin/xorgconfig or /usr/bin/xorgcfg scripts. If you run into problems generating/using an xorg.conf file, you might want to consider using this guide.<br />
<br />
See the [[Xorg#Without_xorg.conf|article on X.Org, section "Without xorg.conf"]].<br />
<br />
* Note that if you are in possession of a properly configured xorg.conf under another distribution and with the same Xorg version, you may easily copy it over to your current Arch system's <code>/etc/X11/</code> directory.<br />
<br />
<br />
{{Tip | For Intel graphics card, specific configuration may be necessary to get proper 2D or 3D performance, as stated in [[Intel_Graphics]] wiki article.}}<br />
<br />
====B: Input hotplugging====<br />
<br />
[[Xorg input hotplugging|Input hotplugging]] is supported since the 1.4 version of the X.Org X Server and enabled by default. When enabled, X will utilize hal to allow for the hotplugging and removal of human interface devices without having to restart X. <br />
<br />
{{Warning | Starting the '''X''' server using input hotplugging without the '''HAL''' daemon installed and running may result in the inability to use the mouse and/or keyboard, and the '''X''' server appearing to freeze as a result .}}<br />
<br />
You must decide whether you will use input hotplugging (enabled by default), or disable it. Input hotplugging is convenient for many users, especially those with mobile machines like laptops and netbooks. Other users may wish to disable it in favor of manual or more static device configuration within /etc/xorg.conf.<br />
<br />
{{Tip | See the article on [[Xorg input hotplugging]] for full details.}}<br />
<br />
=====Using input hotplugging=====<br />
<br />
Install HAL, dbus and the evdev input driver:<br />
# pacman -S hal dbus xf86-input-evdev<br />
<br />
Set the keyboard layout (if you do not use a standard US keyboard)<br />
# cp /usr/share/hal/fdi/policy/10osvendor/10-keymap.fdi /etc/hal/fdi/policy/<br />
# nano /etc/hal/fdi/policy/10-keymap.fdi<br />
Edit the &quot;input.xkb.layout&quot; key and possibly the &quot;input.xkb.variant&quot; key in this file.<br />
<br />
Laptop users will also need the synaptics package to allow X to configure the touchpad:<br />
# pacman -S xf86-input-synaptics<br />
<br />
{{Tip|For instructions on fine tuning or troubleshooting touchpad settings, see the [[Touchpad Synaptics]] article.}}<br />
<br />
<br />
'''The HAL daemon'''<br />
<br />
The hal daemon '''must''' be started '''before''' the '''X''' server:<br />
# /etc/rc.d/hal start<br />
Add the hal daemon to the DAEMONS array in /etc/rc.conf to start it at every boot.<br />
<br />
=====Disable input hotplugging=====<br />
Disabling input hotplugging will skip devices detected by hal and will use the keyboard/mouse configuration from xorg.conf:<br />
# nano /etc/X11/xorg.conf<br />
add the following:<br />
Section &quot;ServerFlags&quot;<br />
Option &quot;AutoAddDevices&quot; &quot;False&quot;<br />
EndSection<br />
<br />
======Set the keyboard layout if not using a standard US keyboard======<br />
Add option lines in the &quot;InputDevice&quot; section of the /etc/X11/xorg.conf file specifying the keyboard layout and variant:<br />
Option &quot;XkbLayout&quot; &quot;be&quot;<br />
Option &quot;XkbVariant&quot; &quot;&quot;<br />
<br />
Alternative method using the setxkbmap command:<br />
# setxkbmap pl <br />
(with the proper keyboard layout instead of <code>pl</code> of course) should switch your keyboard layout in x.<br />
To make this permanent, add this command to <code>/home/<youruser>/.xinitrc</code> before starting the window manager (before command like <code>exec startxfce4</code>).<br />
<br />
==== C: Test X ====<br />
<br />
First, read the warning about input hotplugging in the previous section. At this point, you should have xorg installed, with a suitable video driver and an /etc/X11/xorg.conf configuration file. If you want to test your configuration quickly, to ensure your ability to successfully start '''X''' from the command line before installing a complete desktop environment, you can do so by configuring ~/.xinitrc to invoke '''Xterm'''. Xterm is a very simple terminal emulator which runs in the '''X '''Server environment; it is installed as part of the base xorg packages.<br />
<br />
===== Prepare for the test by configuring ~/.xinitrc=====<br />
<br />
One of the main functions of this file is to dictate what '''X''' Window client is invoked with the '''/usr/bin/startx''' and/or '''/usr/bin/xinit''' program ''on a per-user basis''. (The '''startx''' script is merely a front end to the more versatile '''xinit''' command.) There are vast amounts of additional configurable specifications and commands that may also be added to ~/[[.xinitrc]] as you further customize your system. <br />
{{Note | '''[[.xinitrc]]''' is a so-called 'dot' (.) file. Files in a UNIX filesystem which are preceded with a dot (.) are 'hidden', and will not show up with a regular 'ls' command, usually for the sake of keeping directories tidy. Dot files may be seen by issuing '''ls -a'''. The 'rc' denotes ''Run Commands'' and simply indicates that it is a configuration file. Since it controls how a program runs, it is (although historically incorrect) also said to stand for &quot;Run Control&quot;.}}<br />
<br />
'''startx/xinit''' will start the '''X''' server and clients. To determine the client to run, '''startx/xinit''' will first look to parse a [[.xinitrc]] file in the user's home directory. In the absence of file ~/[[.xinitrc]], it defaults to the global xinitrc in the xinit library directory; /etc/X11/xinit/xinitrc, which defaults to using the TWM window manager. (Hence, if you invoke startx without a ~/[[.xinitrc]] file, a TWM session will start.) Further details in the [[.xinitrc]] wiki entry.<br />
<br />
Switch to your '''''normal, non-root''''' user:<br />
<br />
# su - ''yourusername''<br />
<br />
* /etc/skel/ contains files and directories to provide sane defaults for newly created user accounts. The name '''skel''' is derived from the word '''skeleton''', because the files it contains form the basic structure for users' home directories.<br />
<br />
* Sample .xinitrc provided [[Xinitrc#A_standard_.xinitrc | here]] <br />
Copy the sample xinitrc file from /etc/skel/ to your home directory: <br />
<br />
$ cp /etc/skel/[[.xinitrc]] ~/<br />
Edit the file: <br />
$ nano ~/.xinitrc<br />
and add &quot;<code>exec xterm</code>&quot; so that it looks like this:<br />
<br />
#!/bin/sh<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
#<br />
# exec wmaker<br />
# exec startkde<br />
# exec icewm<br />
# exec blackbox<br />
# exec fluxbox<br />
#<br />
exec xterm<br />
<br />
{{Note | ''Be sure to have only '''one''' uncommented '''exec''' line in ~/.xinitrc'' for now.}}<br />
<br />
Below, we shall edit this file again to specify the appropriate desktop environment/window manager of your choice.<br />
<br />
===== Perform the test =====<br />
<br />
Test your configurations by starting '''X''' as '''normal, non-root''' user, with:<br />
<br />
$ startx<br />
or<br />
$ xinit<br />
<br />
You should have an '''xterm''' session open up. You can test your keyboard and its layout in it. You may have to move your mouse around until it enters the xterm area before you see the mouse cursor or xterm responds to your keyboard.<br />
<br />
If you prove a properly configured /etc/X11/xorg.conf by successfully running the test, you can be assured that your DE/WM of choice will work smoothly.<br />
<br />
Exit Xterm with:<br />
$ exit<br />
{{Tip|Advanced instructions for Xorg configuration can be found in the [[Xorg]] article.}}<br />
<br />
<br />
{{Note| With Xorg 1.6 CTRL-Alt-Backspace has been deprecated and will not work to exit out of this test. A somewhat messy work around is to switch to a different virtual console (CTRL-Alt-F2, for example) and then switch back to the console the test is running in (probably CTRL-Alt-F1). You will then be able to use CTRL-C to kill the X test. You can enable CTRL-Alt-Backspace by editing xorg.conf, as described [http://wiki.archlinux.org/index.php/Xorg#Ctrl-Alt-Backspace_doesn.27t_exit_X here].}}<br />
If the screen goes black, you may still attempt to switch to a different virtual console (CTRL-Alt-F2, for example), and login blindly as root, followed by <Enter>, followed by root's password followed by <enter>. Finally, reboot blindly with:<br />
# reboot<br />
or <br />
# init 6<br />
<br />
=====In case of errors=====<br />
If you have problems starting '''X''', you can look for errors in the /var/log/Xorg.0.log file and on the console output of the virtual console you started '''X''' from. <br />
<br />
'''''If using /etc/X11/xorg.conf'''''<br />
<br />
Inspect the config file:<br />
<br />
# nano /etc/X11/xorg.conf<br />
<br />
The video driver may need to be specified. e.g.:<br />
Section &quot;Device&quot;<br />
<br />
...<br />
Driver &quot;savage&quot;<br />
...<br />
<br />
EndSection<br />
<br />
Horizontal sync and vertical refresh specs under section &quot;Monitor&quot; may need to be added:<br />
Section &quot;Monitor&quot;<br />
Identifier &quot;Monitor0&quot;<br />
VendorName &quot;Monitor Vendor&quot;<br />
ModelName &quot;Monitor Model&quot;<br />
HorizSync 30.0 - 130.0 # Safe for LCD's<br />
VertRefresh 50.0 - 100.0 # Safe for LCD's and most CRT's.<br />
EndSection<br />
(If these specs are unknown, consult the documentation of the computer monitor.)<br />
<br />
Color depth can be specified under section &quot;Screen&quot;:<br />
Section &quot;Screen&quot;<br />
Identifier &quot;Screen0&quot;<br />
Device &quot;Card0&quot;<br />
Monitor &quot;Monitor0&quot;<br />
DefaultDepth 24<br />
(Typically, this will be set to 24 for true color.)<br />
<br />
Also add desired Modes to the &quot;Display&quot; subsection, at least under the Depth 24 header, e.g.:<br />
SubSection &quot;Display&quot;<br />
Viewport 0 0<br />
Depth 24<br />
Modes &quot;1024x768&quot; &quot;800x600&quot; &quot;640x480&quot;<br />
Add the following section, if eye candy which requires the composite extension is desired: <br />
Section &quot;Extensions&quot;<br />
Option &quot;Composite&quot; &quot;Enable&quot;<br />
EndSection<br />
Try the config again, after modifying:<br />
# startx<br />
or<br />
# xinit<br />
'''''Still having trouble? Detailed instructions are in the [[Xorg]] article.'''''<br />
<br />
=====Need Help?=====<br />
<br />
If you are still having trouble after consulting the [[Xorg]] article and need assistance via the Arch forums, be sure to install and use wgetpaste:<br />
<br />
# pacman -S wgetpaste<br />
Use wgetpaste and provide links for the following files when asking for help in your forum post:<br />
* ~/.xinitrc<br />
* /etc/X11/xorg.conf<br />
* /var/log/Xorg.0.log.old<br />
Use wgetpaste like so:<br />
$ wgetpaste </path/to/file><br />
Post the corresponding links given within your forum post. Be sure to provide appropriate hardware and driver information as well.<br />
{{Warning| '''''It is very important to provide detail when troubleshooting X. Please provide all pertinent information as detailed above when asking for assistance on the Arch forums. '''''}}<br />
<br />
==Part IV: Installing and configuring a Desktop Environment ==<br />
While The '''X''' Window System provides the basic framework for building a ''graphical user interface'' (GUI), a '''Desktop Environment''' (DE), works atop and in conjunction with '''X''', to provide a completely functional and dynamic GUI. A DE typically provides a window manager, icons, applets, windows, toolbars, folders, wallpapers, a suite of applications and abilities like drag and drop. The particular functionalities and designs of each DE will uniquely affect your overall environment and experience. Therefore, choosing a DE is a very subjective and personal decision. Choose the best environment for ''your'' needs.<br />
<br />
If you desire a lighter, less demanding GUI to configure manually, you may choose to simply install a '''Window Manager''', or WM. A WM controls the placement and appearance of application windows in conjunction with the X Window System but does NOT include such features as panels, applets, icons, applications, etc., by default.<br />
* Lightweight floating WM's include: [[#Openbox|'''Openbox''']], [[#Fluxbox|'''Fluxbox''']], [[#fvwm2|'''fvwm2''']], [[PekWM|'''pekwm''']], [[Evilwm|'''evilwm''']], '''Windowmaker, and TWM'''.<br />
* If you need something completely different, try a tiling WM like [[Awesome|'''awesome''']], [[Ion3|'''ion3''']], [[Wmii|'''wmii''']], [[Dwm|'''dwm''']], [[Xmonad|'''xmonad''']], or [[Ratpoison|'''ratpoison''']].<br />
<br />
===Step 1: Install Fonts===<br />
At this point, you may wish to save time by installing visually pleasing, true type fonts, before installing a desktop environment/window manager. Dejavu and bitstream-vera are good, general-purpose font sets. You may also want to install the Microsoft font sets, which are especially popular on websites, and may be required for the proper function of Flash animations which feature text.<br />
<br />
Install with:<br />
# pacman -S ttf-ms-fonts ttf-dejavu ttf-bitstream-vera<br />
<br />
Refer to [[Xorg Font Configuration]] for how to configure fonts.<br />
<br />
===Step 2: ~/.xinitrc (again)===<br />
<br />
As '''non-root user''', edit your /home/username/.xinitrc to specify the DE you wish to use. This will allow you to use '''startx/xinit''' from the shell, in the future, to open your DE/WM of choice:<br />
<br />
$ nano ~/.xinitrc<br />
<br />
Uncomment or add the ''''exec''' ..' line of the appropriate desktop environment/window manager. Some examples are below:<br />
<br />
For the Xfce4 desktop environment:<br />
exec startxfce4 <br />
<br />
For the KDE desktop environment:<br />
exec startkde<br />
A '''startkde''' or '''startxfce4''' command starts the KDE or Xfce4 desktop environment. This is exactly the same as entering: <br />
$ xinit /usr/bin/startxfce4<br />
or<br />
$ xinit /usr/bin/starkde<br />
from the shell prompt. Note that such a command does not finish until you logout of the DE. Normally the shell would wait for KDE to finish, then run the next command. The &quot;exec&quot; prefix to this command within the ~/.xinitrc file tells the shell that this is the last command, so the shell does not need to wait to run a subsequent command.<br />
<br />
In the future, after the DE of choice is installed and if trouble with automounting is experienced, try using the following command in ~/.xinitrc instead. (Replace "startxfce4" with the command that is appropriate for your window manager/DE.)<br />
exec ck-launch-session startxfce4<br />
This will ensure the various environment variables are set correctly by starting a clean consolekit session. ConsoleKit is a framework for keeping track of the various users, sessions, and seats present on a system. It provides a mechanism for software to react to changes of any of these items or of any of the metadata associated with them. It works in conjunction with dbus, and other tools.<br />
<br />
Remember to have only one uncommented '''exec''' line in your ~/.xinitrc for now.<br />
<br />
===Step 3: Install a Desktop Environment===<br />
<br />
Continue below, installing the DE/WM of your choice.<br />
<br />
* [[#GNOME|'''GNOME''']]<br />
* [[#KDE|'''KDE''']]<br />
* [[#Xfce|'''Xfce''']]<br />
* [[#LXDE|'''LXDE''']]<br />
* [[#Openbox|'''Openbox''']]<br />
* [[#Fluxbox|'''Fluxbox''']]<br />
* [[#fvwm2|'''fvwm2''']]<br />
<br />
====GNOME====<br />
=====About GNOME=====<br />
The '''G'''NU '''N'''etwork '''O'''bject '''M'''odel '''E'''nvironment. The GNOME project provides two things: The GNOME desktop environment, an intuitive and attractive desktop for end-users, and the GNOME development platform, an extensive framework for building applications that integrate into the rest of the desktop.<br />
<br />
=====Installation=====<br />
Install the base GNOME environment with:<br />
# pacman -S gnome<br />
<br />
Additionally, you can install the extras:<br />
# pacman -S gnome-extra<br />
<br />
It's safe to choose all packages shown in the extra package.<br />
<br />
=====Useful DAEMONS for GNOME=====<br />
Recall from above that a daemon is a program that runs in the background, waiting for events to occur and offering services. Some users prefer to use the '''hal''' daemon. The '''hal''' daemon, among other things, will automate the mounting of disks, optical drives, and USB drives/thumbdrives for use in the GUI. The '''fam''' daemon will allow real-time representation of file alterations in the GUI, allowing instant access to recently installed programs, or changes in the file system. Both '''hal''' and '''fam''' can make life easier for the GNOME user. The hal and fam packages are installed when you install GNOME, but must be invoked to become useful.<br />
<br />
You may want to install a graphical login manager. For GNOME, the '''gdm''' daemon is a good choice. <br />
<br />
As root:<br />
# pacman -S gdm<br />
<br />
Start hal and fam:<br />
# /etc/rc.d/hal start<br />
<br />
# /etc/rc.d/fam start<br />
<br />
Add them to your /etc/rc.conf DAEMONS section, so they will be invoked at boot:<br />
# nano /etc/rc.conf<br />
<br />
DAEMONS=(syslog-ng network crond alsa '''hal fam gdm''')<br />
(If you prefer to log into the console and manually start X, leave out gdm.)<br />
<br />
Then edit your /etc/gdm/custom.conf and in the '''[servers]''' section add:<br />
0=Standard vt7<br />
<br />
As normal user, start X:<br />
$ startx<br />
or<br />
$ xinit<br />
If ~/.xinitrc is not configured for GNOME, you may always start it with '''xinit''', followed by the path to GNOME:<br />
$ xinit /usr/bin/gnome-session<br />
<br />
{{Tip|Advanced instructions for installing and configuring GNOME can be found in the [[Gnome]] article.}}<br />
<br />
Congratulations! Welcome to your GNOME desktop environment on your new Arch Linux system! You may wish to continue by viewing '''[[Beginners Guide Appendix#Tweaks.2FFinishing_touches|Tweaks and finishing touches]]''', or the rest of the information below. You may also be interested in the [[Post Installation Tips]] wiki article.<br />
<br />
=====Eye Candy=====<br />
By default, GNOME does not come with many themes and icons. You may wish to install some more attractive artwork for GNOME:<br />
<br />
A nice gtk (gui widget) theme engine (includes themes) is the murrine engine. Install with:<br />
# pacman -S gtk-engine-murrine<br />
<br />
Optional for more themes:<br />
# pacman -S murrine-themes-collection <br />
<br />
Once it has been installed, select it with System -> Preferences -> Appearance -> Theme tab.<br />
<br />
The Arch Linux repositories also have a few more nice themes and engines. Install the following to see for yourself:<br />
<br />
# pacman -S gtk-engines gtk-aurora-engine gtk-candido-engine gtk-rezlooks-engine<br />
<br />
You can find many more themes, icons, and wallpapers at [http://www.gnome-look.org GNOME-Look].<br />
<br />
====KDE====<br />
=====About KDE=====<br />
The '''K''' '''D'''esktop '''E'''nvironment. KDE is a powerful Free Software graphical desktop environment for GNU/Linux and <tt>UNIX</tt> workstations. It combines ease of use, contemporary functionality, and outstanding graphical design with the technological superiority of <tt>UNIX</tt>-like operating systems.<br />
<br />
=====Installation=====<br />
Choose one of the following, then continue below with '''[[#Useful KDE DAEMONS|Useful KDE DAEMONS]]''': <br />
<br />
1. The package '''kde''' is the official and complete vanilla KDE 4.2 residing under the Arch [extra] repo.<br />
<br />
Install base kde:<br />
# pacman -S kdebase-workspace<br />
Install the whole Desktop Environment: <br />
# pacman -S kde<br />
''or'' <br />
# pacman -S kde-meta<br />
<br />
2. Alternatively, another KDE project exists called '''KDEmod''', part of the Chakra distribution. It is an Arch Linux (and spinoff) exclusive, community-driven package set designed for modularity and offers a choice between KDE 3.5.10 or 4.x.x. KDEmod can be installed with pacman, after adding the proper repositories to /etc/pacman.conf. The project website, including complete installation instructions, can be found at [http://www.chakra-project.org/ http://www.chakra-project.org/].<br />
<br />
=====Useful KDE DAEMONS=====<br />
<br />
Recall from above that a daemon is a program that runs in the background, waiting for events to occur and offering services.<br />
<br />
KDE will require the '''hal''' ('''H'''ardware '''A'''bstraction '''L'''ayer) daemon for optimal functionality. The hal daemon, among other things, will facilitate the automatic mounting of disks, optical drives, and USB drives/thumbdrives for use in the GUI. The hal package is installed when you install xorg-server, but must be invoked to become useful.<br />
<br />
The '''kdm''' daemon is the '''K''' '''D'''isplay '''M'''anager, which provides a '''graphical login''', if desired.<br />
<br />
-----<br />
<br />
Start hal:<br />
# /etc/rc.d/hal start<br />
<br />
{{Note|The hal daemon relies on, and will automatically start, the dbus daemon.}}<br />
Edit your DAEMONS array in /etc/rc.conf:<br />
# nano /etc/rc.conf<br />
Add '''hal''' to your DAEMONS array, to invoke it on boot. If you prefer a graphical login, add '''kdm''' as well: <br />
DAEMONS=(syslog-ng '''hal''' network crond alsa '''kdm''')<br />
{{Note|If you installed KDEmod3 instead of normal KDE, use kdm3 instead of kdm.}}<br />
<br />
*This method will start the system at runlevel 3, (/etc/inittab default, multiuser mode), and then start KDM as a daemon. <br />
<br />
*Some users prefer an alternative method of starting a display manager like KDM on boot by utilizing the /etc/inittab method and starting the system at runlevel 5. See [[Adding a login manager (KDM, GDM, or XDM) to automatically boot on startup]] for more.<br />
<br />
*If you prefer to log into the '''console''' at runlevel 3, and manually start X, leave out kdm, or comment it out with a bang, ( ! ).<br />
<br />
Now try starting your X Server as normal user:<br />
$ startx<br />
or<br />
$ xinit<br />
{{Tip|Advanced instructions for installing and configuring KDE can be found in the [[KDE]] article.}}<br />
<br />
Congratulations! Welcome to your KDE desktop environment on your new Arch Linux system! You may wish to continue by viewing '''[[Beginners Guide Appendix|The Beginners Guide Appendix]]''', or the rest of the information below. You may also be interested in the [[Post Installation Tips]] wiki article.<br />
<br />
====Xfce====<br />
=====About Xfce=====<br />
Xfce is another free software desktop environment for Linux. It aims to be fast and lightweight, while still being visually appealing and easy to use. Xfce is modular and reusable. It consists of separately packaged components that together provide the full functionality of the desktop environment, but which can be selected in subsets to create the user's preferred personal working environment. Xfce is mainly used for its ability to run a modern desktop environment on relatively modest hardware. It is based on the GTK+ 2 toolkit (the same as GNOME). It uses the Xfwm window manager, described below. Its configuration is entirely mouse-driven, and the configuration files are hidden from the casual user.<br />
<br />
=====Installation=====<br />
Install Xfce: <br />
# pacman -S xfce4 <br />
You may also wish to install themes and extras:<br />
# pacman -S xfce4-goodies gtk2-themes-collection<br />
Note: '''xfce4-xfapplet-plugin''' (a plugin that allows the use of GNOME applets in the Xfce4 panel) is part of the '''xfce4-goodies''' group and depends on '''gnome-panel''', which in turn depends on '''gnome-desktop'''. You may wish to take this into consideration before installing, since it represents a significant number of extra dependencies.<br />
<br />
If you get errors about dbus-launch then you need to install dbus aswell:<br />
# pacman -S dbus<br />
<br />
If you wish to admire 'Tips and Tricks' on login, install the '''fortune-mod''' package:<br />
# pacman -S fortune-mod<br />
<br />
=====Useful DAEMONS=====<br />
Recall from above that a daemon is a program that runs in the background, waiting for events to occur and offering services. Some Xfce users prefer to use the '''hal''' daemon. The hal daemon, among other things, will automate the mounting of disks, optical drives, and USB drives/thumbdrives for use in the GUI. The fam daemon will allow real-time representation of file alterations in the GUI, allowing instant access to recently installed programs, or changes in the file system. The hal and fam packages are installed when you install Xfce, but must be invoked to become useful.<br />
<br />
Start hal and fam:<br />
<br />
# /etc/rc.d/hal start<br />
<br />
# /etc/rc.d/fam start<br />
{{Note|The hal daemon relies on, and will automatically start, the dbus daemon.}}<br />
Edit your DAEMONS array in /etc/rc.conf:<br />
# nano /etc/rc.conf<br />
Add '''hal''' and '''fam''' to your DAEMONS array, to invoke them at boot.<br />
<br />
{{Tip|Advanced instructions for installing and configuring Xfce can be found in the [[Xfce]] article.}}<br />
<br />
If you wish to install one, see [[Adding a login manager (KDM, GDM, or XDM) to automatically boot on startup]]. Otherwise you can login in via the console and run:<br />
<br />
$ startxfce4<br />
<br />
Congratulations! Welcome to your Xfce desktop environment on your new Arch Linux system! You may also be interested in the [[Post Installation Tips]] wiki article.<br />
<br />
====LXDE====<br />
=====About LXDE=====<br />
LXDE, (for ''L''ightweight ''X''11 ''D''esktop ''E''nvironment), is a new project focused on providing a modern desktop environment which aims to be lightweight, fast, intuitive and functional while keeping system resource usage low. LXDE is quite different from other desktop environments, since each component of LXDE is a discrete and independent application, and each can be easily substituted by other programs. This modular design eliminates all unnecessary dependencies and provides more flexibility. Details and screenshots available at: http://lxde.org/ <br />
<br />
LXDE provides:<br />
# The OpenBox windowmanager<br />
# PCManFM File manager<br />
# LXpanel system panel<br />
# LXSession session manager<br />
# LXAppearance GTK+ theme switcher<br />
# GPicView image viewer<br />
# Leafpad simple text editor<br />
# XArchiver: Lightweight, fast, and desktop-independent gtk+-based file archiver<br />
# LXNM (still under development): Lightweight network manager for LXDE supporting wireless connections<br />
These lightweight and versatile tools combine for quick setup, modularity and simplicity.<br />
<br />
Install LXDE with: <br />
# pacman -S lxde gamin openbox<br />
<br />
Add:<br />
exec startlxde<br />
*If you experience problems with Policykit or plan on running '''nm-applet''', the following command should be used instead<br />
exec ck-launch-session startlxde<br />
to your ~/.xinitrc and start with ''startx'' or ''xinit''<br />
<br />
{{Tip | Further information available at the [[LXDE]] wiki article.}}<br />
<br />
====*box====<br />
=====Fluxbox=====<br />
Fluxbox is yet another windowmanager for X.<br />
It's based on the Blackbox 0.61.1 code. Fluxbox looks like blackbox and handles styles, colors, window placement and similar things exactly like blackbox (100% theme/style compability).<br />
<br />
Install Fluxbox using <br />
# pacman -S fluxbox fluxconf<br />
<br />
If you use gdm/kdm a new fluxbox session will be automatically added. Otherwise, you should modify your user's .xinitrc and add this to it:<br />
exec startfluxbox <br />
<br />
More information is available in the [[Fluxbox]] article.<br />
<br />
=====Openbox=====<br />
Openbox is a standards compliant, fast, light-weight, extensible window manager.<br />
<br />
Openbox works with your applications, and makes your desktop easier to manage. This is because the approach to its development was the opposite of what seems to be the general case for window managers. Openbox was written first to comply with standards and to work properly. Only when that was in place did the team turn to the visual interface.<br />
<br />
Openbox is fully functional as a stand-alone working environment, or can be used as a drop-in replacement for the default window manager in the GNOME or KDE desktop environments. <br />
<br />
Install openbox using<br />
# pacman -S openbox<br />
Additional configuration tools are also available, if desired:<br />
# pacman -S obconf obmenu<br />
<br />
Once openbox is installed you will get a message to move menu.xml & rc.xml to ~/.config/openbox/ in your home directory:<br />
# su - ''yourusername''<br />
$ mkdir -p ~/.config/openbox/<br />
$ cp /etc/xdg/openbox/rc.xml ~/.config/openbox/<br />
$ cp /etc/xdg/openbox/menu.xml ~/.config/openbox/<br />
<br />
'''rc.xml''' is the main configuration file for OpenBox. It may be manually edited, (or you can use OBconf). '''menu.xml''' configures the right-click menu.<br />
<br />
You may log into OpenBox via graphical login using KDM/GDM, or from the shell using '''startx''', in which case you will need to edit your ~/.xinitrc (as non-root user) and add the following:<br />
<br />
exec openbox-session<br />
<br />
NOTE: If you plan on running dbus (which is required by hal) then make sure your ~/.xinitrc reads:<br />
<br />
exec dbus-launch --exit-with-session openbox-session<br />
<br />
You may also start OpenBox from the shell using '''xinit''':<br />
$ xinit /usr/bin/openbox-session<br />
* Openbox may also be used as the window manager for GNOME, KDE, and Xfce.<br />
For KDM there is nothing left to do; openbox is listed in the sessions menu in KDM.<br />
<br />
Some useful, lightweight programs for OpenBox are:<br />
* PyPanel, Tint2, or LXpanel if you want a panel<br />
* feh if you want to set the background<br />
* ROX if you want a simple file manager (also provides simple icons)<br />
* PcmanFM a lightweight but versatile file manager (also provides desktop icon functionality)<br />
* iDesk (available in [[AUR]]) for providing desktop icons<br />
* Graveman for burning CD's or DVD's<br />
<br />
{{Tip | More information is available in the [[Openbox]] article.}}<br />
<br />
====FVWM2====<br />
FVWM (F Virtual Window Manager) is an extremely powerful ICCCM-compliant multiple virtual desktop window manager for the X Window system. Development is active, and support is excellent. <br />
<br />
Install fvwm2 with<br />
# pacman -S fvwm <br />
<br />
It will install the official version of the WM. However, if you want/need to use some more features than it provides, you can install the patched version from archlinuxfr (see [[Unofficial user repositories]]) or [[AUR]]. To install it from AUR or archlinuxfr repesctively, execute:<br />
$ yaourt -S fvwm-patched<br />
or<br />
# pacman -S fvwm-patched<br />
<br />
fvwm will automatically be listed in kdm/gdm in the sessions menu. Otherwise, add <br />
exec fvwm 2 <br />
<br />
to your user's .xinitrc.<br />
<br />
When you start [[FVWM2]], you will get into the blank configuration. However, when you left-click on the desktop, you will be able to select to configure FVWM. chose wanted modules and you are ready to go. Check out the configs in the http://www.box-look.org. One should also consider checking FVWM forums at http://fvwm.lair.be<br />
<br />
[[SLiM]] is a very good login manager, that does not have many dependencies and acts well with FVWM. Common Applications are similar to those suggested for [[Openbox]] or [[Fluxbox]].<br />
<br />
==Common and Lightweight Applications==<br />
For a list of [[Common Applications]] and [[Lightweight Applications]], visit their respective articles.<br />
<!-- Maybe the beginners' guide shouldn't link to lightweight... --><br />
<br />
=Appendix=<br />
See the [[Beginners' Guide Appendix]]<br />
<!-- vim: set ft=Wikipedia: --></div>
Daenyth
https://wiki.archlinux.org/index.php?title=Talk:VMware/Install_Arch_Linux_as_a_guest&diff=86217
Talk:VMware/Install Arch Linux as a guest
2009-12-03T21:04:10Z
<p>Daenyth: This isn't the place for ancient bug reports.</p>
<hr />
<div></div>
Daenyth
https://wiki.archlinux.org/index.php?title=Qingy&diff=85926
Qingy
2009-12-02T00:30:10Z
<p>Daenyth: /* How to get qingy? */ Q does not work with KMS</p>
<hr />
<div>{{i18n_links_start}}<br />
{{i18n_entry|English|Qingy}}<br />
{{i18n_entry|Türkçe|Qingy (Türkçe)}}<br />
{{i18n_links_end}}<br />
[[Category:Boot process (English)]]<br />
[[Category:Display managers (English)]]<br />
[[Category:Eye candy (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
==What is qingy?==<br />
<br />
[http://qingy.sourceforge.net/ Qingy] is a replacement for getty and login-managers like slim, kdm gdm and so on, using [http://www.directfb.org DirectFB] to provide a fast, nice GUI without the overhead of the X Window System. It allows users to log in and start the session of their choice (text console, gnome, kde, wmaker, etc.). Running several X sessions is also possible.<br />
<br />
==How to get qingy?==<br />
<br />
First you need a working DirectFB.<br />
I'm recommending [http://wiki.archlinux.org/index.php/Uvesafb Uvesafb] but if you have some graphical issues with it use vesafb. Qingy does not work with KMS.<br />
<br />
A package is available in the [community] repo. To install:<br />
# pacman -S qingy <br />
<br />
Several extra themes are also available. In [community] repo, there is an Arch specific theme:<br />
# pacman -S qingy-theme-arch<br />
<br />
A package of several various themes is available in AUR:<br />
<br />
*[http://aur.archlinux.org/packages.php?do_Details=1&ID=5501 qingy-themes]<br />
<br />
==Replace *getty with qingy==<br />
To use qingy, you'll need to edit /etc/inittab.<br />
<br />
Replace:<br />
c1:2345:respawn:/sbin/agetty -8 38400 vc/1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 vc/2 linux<br />
c3:2345:respawn:/sbin/agetty -8 38400 vc/3 linux<br />
c4:2345:respawn:/sbin/agetty -8 38400 vc/4 linux<br />
c5:2345:respawn:/sbin/agetty -8 38400 vc/5 linux<br />
c6:2345:respawn:/sbin/agetty -8 38400 vc/6 linux<br />
<br />
by:<br />
c1:2345:respawn:/sbin/qingy tty1<br />
c2:2345:respawn:/sbin/qingy tty2<br />
c3:2345:respawn:/sbin/qingy tty3<br />
c4:2345:respawn:/sbin/qingy tty4<br />
c5:2345:respawn:/sbin/qingy tty5<br />
c6:2345:respawn:/sbin/agetty -8 38400 vc/6 linux<br />
<br />
Qingy's author suggest to keep agetty on a console (here on console 6) as a safety measure as qingy is still beta software.<br />
<br />
Because qingy uses tty0-9 insead of vc/1-6 so you need add tty to /etc/securetty (NOTE : this should no longer be necessary since vc/1-6 have been replaced by tty0-9 with the new version of agetty): <br />
#<br />
# /etc/securetty<br />
#<br />
console<br />
vc/1<br />
vc/2<br />
vc/3<br />
vc/4<br />
vc/5<br />
vc/6<br />
tty0<br />
tty1<br />
tty2<br />
tty3<br />
tty4<br />
tty5<br />
tty6<br />
tty7<br />
<br />
==Configuring qingy==<br />
<br />
You can configure qingy by editing /etc/qingy/settings.<br />
<br />
The default settings for X are fine so only edit them if you really know what you are doing.<br />
# Full path to the X server<br />
#x_server = "/usr/bin/Xorg"<br />
# Full path to the 'xinit' executable<br />
xinit = "/usr/bin/xinit"<br />
# Parameter we should pass to the X server<br />
x_args = "-nolisten tcp -br"<br />
<br />
I recommend to set <br />
log_facilities = console, file<br />
so you can look for errors in /var/log/qingy.log, too.<br />
<br />
All other options are well explained.<br />
<br />
==Starting X==<br />
<br />
If you want to start X with qingy you need to edit your .xsession.<br />
<br />
Here a default .xsession for qingy.<br />
#!/bin/sh<br />
exec <login-shell command> <window manager starter><br />
An example:<br />
#!/bin/sh<br />
exec bash --login -c 'openbox-session'<br />
<br />
The start of the window manager using a login shell is needed because qingy starts the X-session directly without the help of a shell.<br />
This causes issues like no umlauts in xterm and malfunction of control keys like "Home", "End", "Del" and so on in the terminal.<br />
<br />
==Adding a session entry==<br />
<br />
If you've changed the variable x_sessions or text_session in the config file of qingy replace the following paths with the path you've set.<br />
<br />
===Text mode session===<br />
<br />
Create a file /etc/qingy/sessions/<sessionname>.<br />
<br />
The file name is shown as entry in the session list.<br />
<br />
The file should be a shell script. For an example have a look into /etc/qingy/sessios/emacs.<br />
<br />
===X mode session===<br />
<br />
Create the folder /etc/X11/Sessions/ and save a new script file into it. (see Text mode session)<br />
<br />
The name of the file is shown in the session list.<br />
<br />
==Troubleshooting==<br />
<br />
=== Synaptic touchpad and keyboard issue ===<br />
<br />
Qingy (and quite possibly other DirectFB applicationss) has some issues using Synaptics touchpad. Also the keyboard can behave strangely (like if each keys were pressed twice).<br />
<br />
This can be solved by adding:<br />
disable-module=linux_input<br />
to /etc/directfbrc. If the file does not exist, create it. This will enable you to use your touchpad, however some extra functionality like tapping or tap-dragging might not work.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Bootchart&diff=85925
Bootchart
2009-12-02T00:29:17Z
<p>Daenyth: /* Grub */ Bolded relevent part of grub line.</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Bootchart}}<br />
{{i18n_entry|简体中文|Bootchart (简体中文)}}<br />
{{i18n_links_end}}<br />
<br />
= Introduction =<br />
<br />
Bootchart is a handy tool used for profiling the Linux boot sequence, generally used for making your computer boot faster. It consists of the bootchartd daemon and bootchart-render, which is used to generate the resulting chart.<br />
<br />
= Installing Bootchart =<br />
Install bootchart via your package manager.<br />
The package is called 'bootchart' in Arch Linux.<br />
<br />
= Running Bootchart =<br />
To make use of bootchart, you have to either set it as the init process in your boot loader or starting it manually from one of the init scripts (rc.sysinit preferrably). Note that if you start bootchartd manually, you have to stop it manually too. In general, be extra careful with this step.<br />
== Boot loader setup ==<br />
This generally involves making a copy of the boot option you want to profile and adding 'init=/sbin/bootchartd' to it. When started from the boot loader, bootchart will stop when you get to the login prompt.<br />
=== Grub ===<br />
Open up /boot/grub/menu.lst, and copy/paste the entry you want to log. Append "init=/sbin/bootchartd" to the kernel line. Generally, you'll want your entry to look something like this:<br />
<br />
# (1) Arch Linux Bootchart<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/disk/by-uuid/d531ff5b-de65-499a-9942-d18682375163 ro vga=37C '''init=/sbin/bootchartd'''<br />
initrd /kernel26.img<br />
<br />
=== Lilo ===<br />
TODO<br />
=== Grub 2 ===<br />
Open up /boot/grub/grub.cfg, copy the boot option you want to profile and edit it to look like this:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /boot/vmlinuz26 root=/dev/sda1 ro<br />
initrd /boot/kernel26.img<br />
}<br />
# (1) Arch Linux with Bootchart<br />
menuentry "Arch Linux with Bootchart" {<br />
set root=(hd0,1)<br />
linux /boot/vmlinuz26 root=/dev/sda1 ro init=/sbin/bootchartd<br />
initrd /boot/kernel26.img<br />
}<br />
<br />
Now you can reboot and choose the new bootcharting option.<br />
<br />
== rc.sysinit setup ==<br />
This one is dangerous (you can make your Arch Linux unbootable) - use it only when the first approach fails. When run in this way, not only you'll have to stop bootchartd manually after you boot up (or it will completely fill your harddrive) but it will start with every boot too. Also, any changes to /etc/rc.sysinit will be reverted next time you update the initscripts package.<br />
On the positive side, you'll end up with a bootchart that shows what happens after you log in.<br />
=== Edit /etc/rc.sysinit ===<br />
Now, we're going to add this line:<br />
/sbin/bootchartd start<br />
to /etc/rc.sysinit<br />
<br />
It can't be too high up, because that would render the system unbootable, but placing it too far into the script will hide anything that happened before from the bootchart.<br />
It should be safe to put this right before the section that brings up the system clock.<br />
Look for this line:<br />
stat_busy "Configuring System Clock"<br />
Put this:<br />
/sbin/bootchartd start<br />
before it.<br />
=== Stop bootchartd after login ===<br />
As stated previouslt, you have to stop bootchartd manually.<br />
Either run this as root:<br />
/sbin/bootchartd stop<br />
Or with sudo if you have that set up:<br />
sudo /sbin/bootchartd stop<br />
= Generating a chart =<br />
Generating a bootchart involves running:<br />
bootchart-render<br />
<br />
in a folder to which you have write access. This will generate a 'bootchart.png' image with your chart.<br />
You'll have to have a Java runtime installed and properly set up before you can do this.<br />
== Troubleshooting ==<br />
Bootchart-render cannot generate a 'bootchart.png' image and shows the error message:<br />
/var/log/bootchart.tgz not found<br />
It mostly means that boothartd was unable to detect when the booting process was finished. This can happen when you are using different login manager then [[KDM]] or GDM such as [[SLIM]] or entrance. You have to open /sbin/bootchartd script and append those applications to exit_proc variable, for example:<br />
# The processes we have to wait for<br />
local exit_proc="gdmgreeter gdm-binary kdm_greet kdm slim"<br />
<br />
== Example bootcharts ==<br />
=== Boot in 5 seconds ===<br />
[http://lwn.net/Articles/299483/ LWN Article on fast booting netbooks]<br />
<br />
This article is really awesome and along with a bunch of bootcharts provides some tips on how to boot faster. Some of those improvements are beyond reach of the ordinary user though (patching X.org, kernel, etc.).<br />
<br />
= Useful links =<br />
* [http://www.bootchart.org/ Bootchart home page]</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Talk:Intel_graphics&diff=85924
Talk:Intel graphics
2009-12-02T00:25:21Z
<p>Daenyth: /* KMS */</p>
<hr />
<div>I am going to remove the VideoRam calculation section soon as it is "no longer recommended"<br />
The following is the xorg.0.log from following that section: <br />
(WW) intel(0): VideoRam configuration found, which is no longer recommended.<br />
(II) intel(0): Continuing with default 0kB VideoRam instead of 261120 kB. <br />
--[[User:Sand Lee|Sand Lee]] 20:18, 2 June 2009 (EDT)<br />
<br />
Actually I just noticed that the above section should fall under the Hotplug Disabled section, so I won't remove it, I'll just make it clearer. --[[User:Sand Lee|Sand Lee]] 20:38, 2 June 2009 (EDT)<br />
<br />
== KMS ==<br />
<br />
In the KMS section, the 'early' start way of doing things states that the file /etc/modprobe.d/modprobe.conf should be edited and appended to the FILES= section of mkinitcpio.conf. However, isn't it easier to put "i915.modeset=1" on the kernel line in grub? When doing so you don't need to rebuild the initramfs each time you want to try KMS or to temporarily disable it. You can simply edit the kernel line on the grub screen when booting. --[[User:Big gie|Big gie]] 10:53, 15 October 2009 (EDT)<br />
<br />
::Thanks, I have added that to the wiki, so check that out whether it is OK. --[[User:Bubla|bubla]] 12:29, 20 October 2009 (EDT)<br />
<br />
::I've made some re-writting of the KMS part. I mainly re-arranged it in more structured way. Is it fine? [[User:Big gie|Big gie]] 23:18, 8 November 2009 (EST)<br />
<br />
::I think you still need to run mkinitcpio at least once after adding i915 to the modules in mkinitcpio.conf. --[[User:Grey|Grey]] 17:07, 21 November 2009 (EST)<br />
<br />
::You're absolutely right. But that information is present under [[Intel_Graphics#Note for both "Simplest" and "Alternative"]]. It might be confusing though as that information is later in the page. But that information applies to both methods, so it could be duplicatyed into each section, or only once after... [[User:Big gie|Big gie]] 01:03, 22 November 2009 (EST)<br />
<br />
:: My Eee when booting with that option gives me {{Codeline|Unknown boot option `i915.modeset=1': ignoring}}. KMS works though, as does plymouth. What gives? [[User:Daenyth|Daenyth]] 19:25, 1 December 2009 (EST)<br />
<br />
=="intel-legacy: ''Old and obsolete''?"==<br />
I realize that they are ''for'' old cards, but are the packages in the repo obsolete? This description might be misleading.<br><br />
--[[User:Pacmanz|Pacmanz]] 18:45, 31 October 2009 (EDT)</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Uvesafb&diff=85921
Uvesafb
2009-12-01T22:07:23Z
<p>Daenyth: /* The options for uvesafb */ {{Filename}}</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
A new framebuffer driver has been added to kernel 2.6.24. It has many more features than the standard vesafb, including:<br />
1) proper blanking and hardware suspension after delay;<br />
2) support for custom resolutions as in the system BIOS.<br />
It should support as much hardware as vesafb.<br />
<br />
=The virtualizing daemon=<br />
In contrast with other framebuffer drivers, uvesafb needs a userspace virtualizing daemon, called v86d. It may seem foolish to emulate x86 code on a x86, but this is important if one wants to use the framebuffer code on other architectures (notably non-x86 ones). The {{Package Official|v86d}} package includes an initcpio HOOK (called v86d), which load the uvesafb module and runs the virtualizing daemon when needed.<br />
<br />
You need to add the v86d in the HOOKS array in /etc/mkinitcpio.conf. It should be somewhere after base and before keymap (in the case you use the keymap hook). Then you need to regenerate your initramfs with mkinitcpio (adjust the following command to your setup):<br />
<br />
mkinitcpio -p kernel26<br />
<br />
PLEASE NOTE that v86d requires that klibc has been compiled against a kernel tree including uvesafb. So you need to update klibc to a recent version (the actual version in the core repo is fine).<br />
<br />
=Remove the kernel boot parameters=<br />
Remember to remove any framebuffer-related kernel boot parameter from the bootloader configuration: the vga=<foo> would force the old vesafb to load; the video=<foo> parameter would not be used when uvesafb is compiled as a module (as in the Arch Linux stock kernel).<br />
<br />
=The options for uvesafb=<br />
The options for uvesafb can be defined in {{Filename|/etc/modprobe.d/uvesafb.conf}} or in the general {{Filename|/etc/modprobe.d/modprobe.conf}}. The default file in the v86d package makes the syntax explicit and tells you where to look for further infos:<br />
<br />
# This file sets the parameters for uvesafb module.<br />
# The following format should be used:<br />
# options uvesafb mode=<xres>x<yres>[-<bpp>][@<refresh>] scroll=<ywrap|ypan|redraw> ...<br />
#<br />
# For more details see:<br />
# http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/fb/uvesafb.txt<br />
#<br />
options uvesafb mode=1280x800-32 scroll=ywrap<br />
<br />
From 2.6.27 and up you have to type:<br />
...<br />
options uvesafb mode_option=1280x800-32 scroll=ywrap<br />
<br />
=Uvesafb compiled into the kernel=<br />
If you compile your own kernel, then you can also compile uvesafb into the kernel and run v86d later, e.g. from /etc/rc.local. In this case, the options can be passed as kernel boot parameters in the format video=uvesafb:<options>. Please note that this solution is not viable in the case you want to combine uvesafb with 915resolution as suggested below.<br />
<br />
=The homepage of uvesafb=<br />
The home page of uvesafb is http://dev.gentoo.org/~spock/projects/uvesafb where you can find some detailed informations (you can ignore any information concerning patches for the kernel, because uvesafb is now in the vanilla kernel; moreover some informations in the site assume that uvesafb is compiled in the kernel, while it is a module in the archlinux stock binary kernel).<br />
<br />
=Uvesafb and 915resolution=<br />
In the following, we address a more complex scenario. Many intel video chipsets for widescreen laptops are known to have a buggish bios, which does not support the main, native resolution of the wide screen! For this reason, 915resolution was created to patch the bios at boot time and allowed the x server to use the widescreen resolution. Nowadays, the xserver is able to do this without the help of 915resolution. However, 915resolution can be combined with uvesafb in order to obtain a widescreen framebuffer, without any need to launch X at all. In this case, we need to load uvesafb after having run 915resolution, so that uvesafb can resort to the proper resolution.<br />
<br />
==915resolution-static==<br />
In this scenario, 915resolution needs to be compiled statically (since it is going to be in an initramfs, it can not be linked to external libraries). Thus you CAN NOT use the 915resolution package in the community repo. Look instead for 915resolution-static in AUR unsupported. It compiles 915 resolution statically and provides a 915 resolution hook, so you can run 915resolution before loading uvesafb and get the patched resolution. So install 915resolution-static via makepkg and pacman.<br />
<br />
==The resolution==<br />
You need to edit the 915resolution hook in order to define the BIOS mode you want to replace and and the resolution you want to get. You can get infos about all the options for 915resolution with:<br />
<br />
915resolution -h<br />
<br />
So edit /lib/initcpio/hooks/915resolution and modify the options for 915resolution:<br />
<br />
run_hook ()<br />
{<br />
msg -n ":: Patching the VBIOS..."<br />
/usr/sbin/915resolution 5c 1280 800<br />
msg "done."<br />
}<br />
<br />
In the default, 5c is the code of the BIOS mode to replace. You can get a list of the available BIOS video modes with '915resolution -l': NOTE that you want to choose the code of a mode that you DO NOT need (neither in the framebuffer nor in X), because 915resolution will replace it with a new user-defined mode. '1280 800' is the new desired resolution.<br />
<br />
==V86d==<br />
Install v86d via pacman.<br />
<br />
==Modify /etc/modprobe.d/uvesafb==<br />
Modify the options for uvesafb in /etc/modprobe.d/uvesafb, so that it uses the resolution you need, e.g.:<br />
<br />
options uvesafb mode=1280x800-32 scroll=ywrap<br />
<br />
From 2.6.27 and up you have to type:<br />
...<br />
options uvesafb mode_option=1280x800-32 scroll=ywrap<br />
<br />
<br />
==List the hooks==<br />
Add the 915resolution hook and, after it, the v86d hook to HOOKS in mkinitcpio.conf. Put them before the hooks for the keymap, the resume from suspension and the filesystems.<br />
HOOKS="base udev v86d ..."<br />
or if you need 915resolution<br />
HOOKS="base udev 915resolution v86d ..."<br />
<br />
==Finalize==<br />
Regenerate your initcpio (for example mkinitcpio -p kernel26), reboot and enjoy your widescreen framebuffer.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Uvesafb&diff=85920
Uvesafb
2009-12-01T22:02:18Z
<p>Daenyth: /* The virtualizing daemon */ {{Package}} and reword sentence</p>
<hr />
<div>[[Category:Laptops (English)]]<br />
[[Category:HOWTOs (English)]]<br />
A new framebuffer driver has been added to kernel 2.6.24. It has many more features than the standard vesafb, including:<br />
1) proper blanking and hardware suspension after delay;<br />
2) support for custom resolutions as in the system BIOS.<br />
It should support as much hardware as vesafb.<br />
<br />
=The virtualizing daemon=<br />
In contrast with other framebuffer drivers, uvesafb needs a userspace virtualizing daemon, called v86d. It may seem foolish to emulate x86 code on a x86, but this is important if one wants to use the framebuffer code on other architectures (notably non-x86 ones). The {{Package Official|v86d}} package includes an initcpio HOOK (called v86d), which load the uvesafb module and runs the virtualizing daemon when needed.<br />
<br />
You need to add the v86d in the HOOKS array in /etc/mkinitcpio.conf. It should be somewhere after base and before keymap (in the case you use the keymap hook). Then you need to regenerate your initramfs with mkinitcpio (adjust the following command to your setup):<br />
<br />
mkinitcpio -p kernel26<br />
<br />
PLEASE NOTE that v86d requires that klibc has been compiled against a kernel tree including uvesafb. So you need to update klibc to a recent version (the actual version in the core repo is fine).<br />
<br />
=Remove the kernel boot parameters=<br />
Remember to remove any framebuffer-related kernel boot parameter from the bootloader configuration: the vga=<foo> would force the old vesafb to load; the video=<foo> parameter would not be used when uvesafb is compiled as a module (as in the Arch Linux stock kernel).<br />
<br />
=The options for uvesafb=<br />
The options for uvesafb can be defined in /etc/modprobe.d/uvesafb.conf (this file is part of the above mentioned v86d package) or in the general /etc/modprobe.d/modprobe.conf. The default file in the v86d package makes the syntax explicit and tells you where to look for further infos:<br />
<br />
# This file sets the parameters for uvesafb module.<br />
# The following format should be used:<br />
# options uvesafb mode=<xres>x<yres>[-<bpp>][@<refresh>] scroll=<ywrap|ypan|redraw> ...<br />
#<br />
# For more details see:<br />
# http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/fb/uvesafb.txt<br />
#<br />
options uvesafb mode=1280x800-32 scroll=ywrap<br />
<br />
From 2.6.27 and up you have to type:<br />
...<br />
options uvesafb mode_option=1280x800-32 scroll=ywrap<br />
<br />
=Uvesafb compiled into the kernel=<br />
If you compile your own kernel, then you can also compile uvesafb into the kernel and run v86d later, e.g. from /etc/rc.local. In this case, the options can be passed as kernel boot parameters in the format video=uvesafb:<options>. Please note that this solution is not viable in the case you want to combine uvesafb with 915resolution as suggested below.<br />
<br />
=The homepage of uvesafb=<br />
The home page of uvesafb is http://dev.gentoo.org/~spock/projects/uvesafb where you can find some detailed informations (you can ignore any information concerning patches for the kernel, because uvesafb is now in the vanilla kernel; moreover some informations in the site assume that uvesafb is compiled in the kernel, while it is a module in the archlinux stock binary kernel).<br />
<br />
=Uvesafb and 915resolution=<br />
In the following, we address a more complex scenario. Many intel video chipsets for widescreen laptops are known to have a buggish bios, which does not support the main, native resolution of the wide screen! For this reason, 915resolution was created to patch the bios at boot time and allowed the x server to use the widescreen resolution. Nowadays, the xserver is able to do this without the help of 915resolution. However, 915resolution can be combined with uvesafb in order to obtain a widescreen framebuffer, without any need to launch X at all. In this case, we need to load uvesafb after having run 915resolution, so that uvesafb can resort to the proper resolution.<br />
<br />
==915resolution-static==<br />
In this scenario, 915resolution needs to be compiled statically (since it is going to be in an initramfs, it can not be linked to external libraries). Thus you CAN NOT use the 915resolution package in the community repo. Look instead for 915resolution-static in AUR unsupported. It compiles 915 resolution statically and provides a 915 resolution hook, so you can run 915resolution before loading uvesafb and get the patched resolution. So install 915resolution-static via makepkg and pacman.<br />
<br />
==The resolution==<br />
You need to edit the 915resolution hook in order to define the BIOS mode you want to replace and and the resolution you want to get. You can get infos about all the options for 915resolution with:<br />
<br />
915resolution -h<br />
<br />
So edit /lib/initcpio/hooks/915resolution and modify the options for 915resolution:<br />
<br />
run_hook ()<br />
{<br />
msg -n ":: Patching the VBIOS..."<br />
/usr/sbin/915resolution 5c 1280 800<br />
msg "done."<br />
}<br />
<br />
In the default, 5c is the code of the BIOS mode to replace. You can get a list of the available BIOS video modes with '915resolution -l': NOTE that you want to choose the code of a mode that you DO NOT need (neither in the framebuffer nor in X), because 915resolution will replace it with a new user-defined mode. '1280 800' is the new desired resolution.<br />
<br />
==V86d==<br />
Install v86d via pacman.<br />
<br />
==Modify /etc/modprobe.d/uvesafb==<br />
Modify the options for uvesafb in /etc/modprobe.d/uvesafb, so that it uses the resolution you need, e.g.:<br />
<br />
options uvesafb mode=1280x800-32 scroll=ywrap<br />
<br />
From 2.6.27 and up you have to type:<br />
...<br />
options uvesafb mode_option=1280x800-32 scroll=ywrap<br />
<br />
<br />
==List the hooks==<br />
Add the 915resolution hook and, after it, the v86d hook to HOOKS in mkinitcpio.conf. Put them before the hooks for the keymap, the resume from suspension and the filesystems.<br />
HOOKS="base udev v86d ..."<br />
or if you need 915resolution<br />
HOOKS="base udev 915resolution v86d ..."<br />
<br />
==Finalize==<br />
Regenerate your initcpio (for example mkinitcpio -p kernel26), reboot and enjoy your widescreen framebuffer.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Arch_Handbook&diff=85915
Arch Handbook
2009-12-01T19:56:15Z
<p>Daenyth: /* Installing software */ Put shell stuff in a code block and change to root prompt</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
{{stub}}<br />
<br />
== Notice ==<br />
This handbook has only just been started. It's currently a rather bare outline. Please edit it and make it better! Look at the [http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/ FreeBSD Handbook] as a style guide.<br />
<br />
Most sections should be a summary, with a link to the main article on the subject.<br />
<br />
== Getting Started ==<br />
<br />
=== Introduction ===<br />
Arch linux is a lightweight and flexible linux distribution that tries to Keep It Simple.<br />
There are official packages optimized for the i686 and x86-64 architectures. There is also a community-operated package repository.<br />
See the pages in [[:Category: About Arch (English)|this category]]<br />
<br />
=== Installing Arch Linux ===<br />
There are two types of install CD. The CORE CD holds the packages required to get a basic system running. The FTP CD pulls the latest packages from the repositories during the install. Both CDs have NCURSES installers. There are the following steps:<br />
#Loading a non-US Keymap<br />
#Running Setup<br />
#Configure Network (FTP Install only)<br />
#Prepare Hard Drive<br />
##Auto-Prepare<br />
##Partition Hard Drives<br />
##Set Filesystem Mountpoints<br />
#Select Packages<br />
#Install Packages<br />
#Configure System<br />
#Install Kernel<br />
#Install Bootloader<br />
#Exit Install<br />
<br />
The full install guide is [[Official Arch Linux Install Guide|here]] and the install CDs are available [http://www.archlinux.org/download/ here]. If you would like a more detailed installation guide, please see the [[Beginners Guide|Beginners' Guide]].<br />
<br />
=== Linux Basics ===<br />
A few basics on the file system and command line, for people starting Unix/Linux with Arch.<br />
<br />
=== Installing Software: Pacman ===<br />
Some basics on Pacman options, how repositories work, etc.<br />
<br />
Pacman is the Arch Linux package management tool. It is a command line tool which provides an easy way to install and manage applications, libraries and other software. It is extremely easy to use and powerful, and will be one of the main administrative tools you will use while running Arch Linux.<br />
The main operations are<br />
pacman -S app # install package named app<br />
pacman -Syu # update package database and upgrade any packages<br />
pacman -R app # remove package name app<br />
<br />
To get a full list of operations pacman can perform, open a terminal and type:<br />
<br />
pacman --help<br />
<br />
To get more detail on an operation, combine it with --help: <br />
<br />
pacman --help -S<br />
<br />
Or, for a more in-depth guide, consult the man page:<br />
<br />
man pacman<br />
<br />
See the wiki entry for [[pacman]] for a user-friendly guide.<br />
<br />
=== X11 and Graphical Desktop Environments ===<br />
Basics of X11 concepts, installation and configuration of Gnome, KDE, etc.<br />
====Xorg====<br />
<br />
[[Xorg]] is the public, open-source implementation of the X11 X Window System. Basically, if you want a GUI atop Arch, you will want xorg. It is installed by:<br />
pacman -S xorg<br />
Drivers for your video card are also needed. They are listed by this command:<br />
pacman -Ss xf86-video<br />
You also need a <code>/etc/X11/xorg.conf</code> file. This can be automatically generated by hwdetect:<br />
pacman -S hwdetect<br />
hwdetect -xa<br />
You may want to edit this slightly before proceeding. Then test Xorg by executing<br />
startx<br />
This should give the basic WM.<br />
<br />
====Window Managers and Desktop Environments====<br />
<br />
== Maintaining your system ==<br />
<br />
=== Introduction ===<br />
<br />
Installing, updating and removing software is a fairly common task and this chapter will<br />
introduce you to Pacman(8). Pacman is a package manager that will aid you in keeping your<br />
system up-to-date, installing new software and general house keeping. If this is your<br />
first time with Arch Linux you REALLY want to read this chapter at least once. Not reading<br />
it will severely impair your experience with Arch, so please read it carefully.<br />
<br />
After reading this chapter you will know...<br />
* ... how to install, remove and update software.<br />
* ... how to search for software in the package database.<br />
* ... how to update every single software package on your computer.<br />
* ... how to query the package database for information about installed packages.<br />
<br />
Let's get on with it shall we?<br />
<br />
=== Pacman introduction ===<br />
<br />
As mentioned previously Pacman(8) is a software utility that helps you keep your system<br />
up-to-date and install, remove or update software. Pacman will automatically resolve <br />
dependencies during installation of a software. A dependency is simply another software<br />
package required by the program you're trying to install. <br />
<br />
Let's us fire up Pacman and see what <br />
it can do. In a console type the following:<br />
<br />
sh$ pacman --help<br />
usage: pacman <operation> [...]<br />
options:<br />
pacman {-h --help}<br />
pacman {-V --version}<br />
pacman {-A --add} [options] <file><br />
pacman {-Q --query} [options] [package]<br />
pacman {-R --remove} [options] <package><br />
pacman {-S --sync} [options] [package]<br />
pacman {-U --upgrade} [options] <file><br />
<br />
use 'pacman --help' with other options for more syntax<br />
<br />
Functionality in Pacman is split into a main action and a sub-action. Each action usually<br />
requires an argument to specify exactly what you're trying to achieve. For example --query (or -Q)<br />
will allow you to query the package database to see installed packages and other types<br />
of information related to the software installed. Let's assume we wanted to find out which<br />
package owns the file /etc/rc.conf. In a console type the following:<br />
<br />
sh$ pacman --query --owns /etc/rc.conf<br />
/etc/rc.conf is owned by initscripts 2008.03-4<br />
<br />
As we can see here rc.conf is owned by initscripts 2008.03-4. Most actions can be abbreviated<br />
such that '--query --owns' becomes '-Qo' . For clarity we'll however continue to use the longer<br />
version.<br />
<br />
=== Searching for software ===<br />
<br />
Pacman comes with powerful searching capabilities and that allows you to do searches using<br />
regular expressions. If you're unfamiliar with regular expressions there is no reason for<br />
concern as you'll do just fine without them.<br />
<br />
Searching is done through the --sync (or -S) action and sub-action --search (or -s).<br />
Let's see if we can find a package called wpa_supplicant. In a console type the following:<br />
<br />
sh$ pacman --sync --search wpa_supplicant<br />
core/wpa_supplicant 0.5.10-1 (base)<br />
A utility providing key negotiation for WPA wireless networks<br />
extra/wpa_supplicant_gui 0.5.10-1<br />
A qt frontend to wpa_supplicant<br />
<br />
The results displays two matching packages one from the 'core' respository and another from<br />
'extra'. Should we want more detailed information about this package we can again use Pacman<br />
to query the database with --sync --info. In a console type the following:<br />
<br />
sh$ pacman --sync --info wpa_supplicant<br />
Repository : core<br />
Name : wpa_supplicant<br />
Version : 0.5.10-1<br />
URL : None<br />
Licences : None<br />
Groups : base <br />
Provides : None<br />
Depends On : openssl <br />
Optional Deps : None<br />
Conflicts With : None<br />
Replaces : None<br />
Download Size : 193.46 K<br />
Installed Size : 193.46 K<br />
Packager : None<br />
Architecture : None<br />
Build Date : None<br />
MD5 Sum : 91b2beebb2abea973c18eb672057f128<br />
Description : A utility providing key negotiation for WPA wireless networks<br />
<br />
=== Installing software ===<br />
<br />
Now that you've found a package it's time to install it. Choose any package you're interested<br />
in and type the following in your console:<br />
<br />
# pacman -S muparser<br />
resolving dependencies...<br />
looking for inter-conflicts...<br />
<br />
Targets: muparser-1.28-1 <br />
<br />
Total Download Size: 0.15 MB<br />
<br />
Proceed with installation? [Y/n]<br />
<br />
Pacman will check for dependencies and if all is good proceed to download required packages.<br />
Once all files are downloaded Pacman will proceed to install them. While installing the software<br />
Pacman might print messages during installation. It's VERY important that you read these<br />
messages as they usually contain important information about the software you're installing.<br />
<br />
(!) Note: Remember to read any messages printed by Pacman during installation, they are printed<br />
for a reason and should be considered essential reading. Please don't forget! (!)<br />
<br />
=== Removing software ===<br />
<br />
So you've decided to remove a package from the system. Again Pacman will happily do this for<br />
you and also remove any non-explicitly (dependencies) installed packages as well. Pacman will <br />
obviously not remove depdencies if they are required by other packages, but if you want that<br />
Pacman can do that as well.<br />
<br />
To remove a particular package and any dependencies no longer needed type the following in a <br />
console:<br />
<br />
sh$ pacman --remove --recursive muparser<br />
<br />
Pacman will remove any files belonging to the specified package and potential dependencies. It's<br />
important to understand that some files might remain on the system even after removing the<br />
package. There might for example be configuration files left in your home-folder and Pacman<br />
will NOT remove these files. <br />
<br />
=== Updating software ===<br />
<br />
Pacman will obviously not only install and remove software packages but also help you maintain<br />
the ones you have installed on your system. Keeping software up-to-date is useful for many<br />
reasons such as removing security vulnerabiltiies, bugs and perhaps even adding more<br />
functionality.<br />
<br />
Before proceeding with any package updating you should first ensure that you have the most<br />
recent snapshop of currently available packages. This is done through a simple command to<br />
Pacman. Type the following in your console:<br />
<br />
sh$ pacman --sync --refresh<br />
<br />
Pacman will connect to each repository and update, if necessary, information about available<br />
software packages. Once Pacman has updated your respositories it's time to check if you've<br />
got any outdated packages that may be upgraded to a later version.<br />
<br />
Generally you'll want to update the entire system in one go, but we'll first walk through the<br />
steps of updating just one package. To find out what packages may be updated we'll use Pacman<br />
to query the package database. In a console type the following:<br />
<br />
sh$ pacman --query --upgrades<br />
<br />
Choose a package you'd like to update and type the following in a console:<br />
<br />
sh$ pacman --sync <package_to_upgrade><br />
<br />
Confirm the procedure and Pacman will begin downloading new packages and any necessary<br />
dependencies. Should you want to avoid updating of dependencies you'd also want to add <br />
--nodeps (or -d).<br />
<br />
Clearly this is not a particularily quick and efficient way of updating your entire system,<br />
especially if you've got more than ten available package updates. Pacman does solve this<br />
problem as well so keep reading and you'll learn how you can update your entire system<br />
in just one command.<br />
<br />
=== Updating the entire system ===<br />
<br />
If you've not already run your repository update, please do so now. (In case you don't remember:<br />
pacman --sync --refresh) In a console type the following:<br />
<br />
sh$ pacman --sync --sysupgrade<br />
<br />
Pacman will now begin a possibly lengthy process of downloading and updating your entire<br />
system. Depending on things such as download speed, processor power it might take anything from<br />
a few seconds to a half an hour. Not too bad considering your entire system will be completely<br />
updated after it finishes.<br />
<br />
(!) Note: During installation Pacman might print messages on the screen. It's VERY important<br />
that you do not ignore these messages as they are printed for a reason. Read them, please! <br />
If you don't understand the meaning of them, write them down and use ask the forum for help. (!)<br />
<br />
Sometimes Pacman may update important packages that contain updates to some of your configuration<br />
files in for example /etc. It's important to always keep an eye out for .pacnew files in this<br />
folder. Pacman will only produce these files (.pacnew/.pacsave) if you've made any changes to<br />
the files being updated. If no changes have been made Pacman will automatically replace the old<br />
files with the new ones. We'll talk more about this in a later chapter.<br />
<br />
=== Summary ===<br />
<br />
This chapter introduced you to some of the basic functionality of Pacman. There is much more<br />
functionality in Pacman and we've only really scratched the surface. If you'd like a more<br />
thorough description of all the options Pacman provide we recommend reading the man pages for <br />
Pacman(8).<br />
<br />
Hopefully this chapter have demonstrated some of the Pacman power and why it makes Arch Linux<br />
a powerful, yet simple Linux distribution. In the next chapter we'll talk about how to various<br />
aspects of Arch Linux. See you there!<br />
<br />
== Common Tasks ==<br />
<br />
=== Desktop Applications ===<br />
Web browsers, office suites, etc.<br />
<br />
=== Multimedia ===<br />
Video players, music jukeboxes, photo management, how to get codecs.<br />
<br />
=== Printing ===<br />
CUPS installation and configuration, finding drivers.<br />
<br />
== System Administration ==<br />
<br />
=== Configuration and Tuning ===<br />
A lot of the configuration of Arch is done in /etc/rc.conf. This may sound daunting , but it is well commented and allows you to set modules for auto-loading and blacklisting, along with daemons and some network configuration.<br />
Details on some common configuration (init, cron).<br />
<br />
=== Users and Basic Account Management ===<br />
Creating and managing users with command-line utilities.<br />
<br />
Users are created with <code>adduser</code>. Users must also be added to [[groups]] to make them useful.<br />
<br />
== Networking ==<br />
<br />
=== Network Configuration ===<br />
How networks are set up in Arch.<br />
<br />
=== Servers ===<br />
Mail, web, SSH server installation and configuration.<br />
<br />
=== Firewalls ===<br />
Basic firewall concepts, how to use iptables.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Pkgtools&diff=85911
Pkgtools
2009-12-01T19:30:21Z
<p>Daenyth: /* About */ {{Package}} stuff</p>
<hr />
<div>{{stub}}<br />
<br />
==About==<br />
<br />
{{Package Official|Pkgtools}} is a package created by Daenyth that includes various useful package-related utilities. It is available in community, and the latest {{Package AUR|pkgtools-git}} release is available in AUR.<br />
<br />
===newpkg===<br />
<br />
A tool to simplify creating a new package.<br />
<br />
===pkgconflict===<br />
<br />
===pkgfile===<br />
{{Codeline|pkgfile}} is a tool that tells you which package owns a specific file. It also has some extra related features.<br />
<br />
===="Command not found" hook====<br />
pkgfile includes a "command not found" hook that will automatically search the official repositories if you enter a command that is not recognized. It can be enabled in {{Filename|/etc/pkgtools/pkgfile.conf}} or in {{Filename|~/.pkgtools/pkgfile.conf}}.<br />
<br />
===spec2arch===<br />
<br />
Converts an rpm .spec file into a [[PKGBUILD]]<br />
<br />
===whoneeds===</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Pkgtools&diff=85909
Pkgtools
2009-12-01T19:24:43Z
<p>Daenyth: </p>
<hr />
<div>{{stub}}<br />
<br />
==About==<br />
<br />
Pkgtools is a package created by Daenyth that includes various useful package-related utilities. It is available in community, and the latest git release is available in AUR.<br />
<br />
===newpkg===<br />
<br />
A tool to simplify creating a new package.<br />
<br />
===pkgconflict===<br />
<br />
===pkgfile===<br />
{{Codeline|pkgfile}} is a tool that tells you which package owns a specific file. It also has some extra related features.<br />
<br />
===="Command not found" hook====<br />
pkgfile includes a "command not found" hook that will automatically search the official repositories if you enter a command that is not recognized. It can be enabled in {{Filename|/etc/pkgtools/pkgfile.conf}} or in {{Filename|~/.pkgtools/pkgfile.conf}}.<br />
<br />
===spec2arch===<br />
<br />
Converts an rpm .spec file into a [[PKGBUILD]]<br />
<br />
===whoneeds===</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Pkgtools&diff=85908
Pkgtools
2009-12-01T19:22:02Z
<p>Daenyth: More info about tools</p>
<hr />
<div>{{stub}}<br />
{{toc}}<br />
==About==<br />
<br />
Pkgtools is a package created by Daenyth that includes various useful package-related utilities. It is available in community, and the latest git release is available in AUR.<br />
<br />
===newpkg===<br />
<br />
A tool to simplify creating a new package.<br />
<br />
===pkgconflict===<br />
<br />
===pkgfile===<br />
{{Codeline|pkgfile}} is a tool that tells you which package owns a specific file. It also has some extra related features.<br />
<br />
===="Command not found" hook====<br />
pkgfile includes a "command not found" hook that will automatically search the official repositories if you enter a command that is not recognized. It can be enabled in {{Filename|/etc/pkgtools/pkgfile.conf}} or in {{Filename|~/.pkgtools/pkgfile.conf}}.<br />
<br />
===spec2arch===<br />
<br />
Converts an rpm .spec file into a [[PKGBUILD]]<br />
<br />
===whoneeds===</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Talk:DVD_Ripping&diff=85907
Talk:DVD Ripping
2009-12-01T19:08:37Z
<p>Daenyth: Suggest some references</p>
<hr />
<div>hey,<br />
I normaly just do<br />
mplayer -dumpstream<br />
<br />
and write it to a .vob file.<br />
<br />
So the actual command could look like:<br />
mplayer dvd://1 -v -dumpstream -dumpfile film.vob<br />
<br />
Of course I get really big files this way. (3-8 gigabyte)<br />
But I think it's definitely the best quality, isn't it?<br />
And you can easily compress the vob-file anyway later if you want to.<br />
<br />
I don't really have much knowledge about mplayer and video in general, so I didn't just write it in the article.<br />
I only adopted it from [http://wiki.ubuntuusers.de/DVDs_manuell_rippen] (german language)<br />
<br />
If anyone knows a better method (for example make mplayer read the dvd more carefully, if quality matters more than time) please write.<br />
<br />
--[[User:Advocatusdiaboli|Advocatusdiaboli]] 15:40, 10 November 2009 (EST)<br />
<br />
--<br />
<br />
Maybe some of these links have useful info? [http://www.linux.com/archive/feature/140081] [http://www.linux.com/archive/feature/128105] [http://www.dedoimedo.com/computers/handbrake.html]</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Pacman/Rosetta&diff=85906
Pacman/Rosetta
2009-12-01T19:05:24Z
<p>Daenyth: pacman -Qm</p>
<hr />
<div>[[Category:Package management (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|:Pacman_rosetta}}<br />
{{i18n_entry|Español|:Pacman_rosetta_(Español)}}<br />
{{i18n_links_end}}<br />
<br />
Introduction:<br><br />
This page pulls heavily from http://en.opensuse.org/Software_Management_Command_Line_Comparison<br><br />
It has been simplified and has added Arch to the comparison, as well as modified the order in which each distribution exists for the benefit of Arch users.<br />
<br />
{| {{table}}<br />
| align="center" style="background:#f0f0f0;"|'''Action'''<br />
| align="center" style="background:#f0f0f0;"|'''arch'''<br />
| align="center" style="background:#f0f0f0;"|'''redhat/fedora'''<br />
| align="center" style="background:#f0f0f0;"|'''debian/ubuntu'''<br />
| align="center" style="background:#f0f0f0;"|'''old suse'''<br />
| align="center" style="background:#f0f0f0;"|'''opensuse'''<br />
| align="center" style="background:#f0f0f0;"|'''gentoo'''<br />
|-<br />
| Install a package(s) by name ||pacman -S||yum install ||apt-get install||rug install||zypper install zypper in|| emerge [-a]<br />
|- style="background:#e4e4e4"<br />
| Remove a package(s) by name ||pacman -R||yum remove/erase ||apt-get remove||rug remove/erase||zypper remove zypper rm ||emerge -C<br />
|-<br />
| Search for package(s) by searching the expression in name, description, short description. What exact fields are being searched by default varies in each tool. Mostly options bring tools on par. ||pacman -Ss||yum search ||apt-cache search||rug search||zypper search zypper se [-s]||emerge -S <br />
|- style="background:#e4e4e4"<br />
| Upgrade Packages - Install packages which have an older version already installed ||pacman -Syu||yum update ||apt-get upgrade||rug update||zypper update zypper up||emerge -u world<br />
|-<br />
| Upgrade Packages - Another form of the update command, which can perform more complex updates -- like distribution upgrades. When the usual update command will omit package updates, which include changes in dependencies, this command can perform those updates. ||pacman -Syu||yum upgrade ||apt-get dist-upgrade||||zypper dup||emerge -uDN world<br />
|- style="background:#e4e4e4"<br />
| Reinstall given Package - Will reinstall the given package without dependency hassle. ||pacman -S||||apt-get install --reinstall||||zypper install --force||emerge [-a]<br />
|-<br />
| Installs local package file, e.g. app.rpm and uses the installation sources to resolve dependencies ||pacman -U||yum localinstall ||dpkg -i && apt-get install -f||||zypper in /path/to/local.rpm||emerge<br />
|- style="background:#e4e4e4"<br />
| Updates package(s) with local packages and uses the installation sources to resolve dependencies ||pacman -U||yum localupdate ||||||n/a|| <br />
|-<br />
| Use some magic to fix broken dependencies in a system || pacman dep level - testdb, shared lib level - findbrokenpkgs or lddd||||apt-get --fix-broken||rug* solvedeps ||n/a ||revdep-rebuild<br />
|- style="background:#e4e4e4"<br />
| Only downloads the given package(s) without unpacking or installing them ||pacman -Sw||yumdownloader (found in yum-utils package)||apt-get --download-only||||n/a||emerge --fetchonly <br />
|-<br />
| Remove dependencies that are no longer needed, because e.g. the package which needed the dependencies was removed. ||pacman -Qdt||||apt-get autoremove ||||n/a||emerge --depclean <br />
|- style="background:#e4e4e4"<br />
| Downloads the corresponding source package(s) to the given package name(s) ||srcpac -Sw ? (third-party. Is there something better?)||||apt-get source ||||zypper source-install||emerge --fetchonly<br />
|-<br />
| Install/Remove packages to satisfy buid-dependencies. Uses information in the source package. ||automatic||||apt-get build-dep ||||zypper si -d||emerge -o <br />
|- style="background:#e4e4e4"<br />
| Add a package lock rule to keep its current state from being changed ||${EDITOR} /etc/pacman.conf<br/>modify IgnorePkg array||yum.conf <--”exclude” option (add/amend)||<nowiki>echo "$PKGNAME hold" | dpkg --set-selections</nowiki> ||rug* lock-add ||Put package name in /etc/zypp/locks||/etc/portage/package.mask<br />
|-<br />
| Delete a package lock rule ||remove package from IgnorePkg line in /etc/pacman.conf||yum.conf <--”exclude” option (remove/amend)||<nowiki>echo "$PKGNAME install" | dpkg --set-selections</nowiki> ||rug* lock-delete||Remove package name from /etc/zypp/locks||/etc/portage/package.mask (or package.unmask) <br />
|- style="background:#e4e4e4"<br />
| Show a listing of all lock rules ||cat /etc/pacman.conf||yum.conf (research needed)||/etc/apt/preferences ||rug* lock-list||View /etc/zypp/locks||cat /etc/portage/package.mask<br />
|-<br />
| Add a checkpoint to the package system for later rollback ||||||||rug* checkpoint-add ||n/a ||<br />
|- style="background:#e4e4e4"<br />
| Remove a checkpoint from the system ||N/A||||||rug* checkpoint-remove ||n/a ||<br />
|-<br />
| Provide a list of all system checkpoints ||N/A||||||rug* checkpoints ||n/a ||<br />
|- style="background:#e4e4e4"<br />
| Rolls entire packages back to a certain date or checkpoint. ||N/A||||||rug* rollback ||n/a ||<br />
|-<br />
| ||||||||||||<br />
|-<br />
| ||||||||||||<br />
|-<br />
| Package information management ||||||||||||<br />
|- style="background:#e4e4e4"<br />
| Get a dump of the whole system information - Prints, Saves or similar the current state of the package management system. Preferred output is text or XML. One version of rug dumps information as a sqlite database. (Note: Why either-or here? No tool offers the option to choose the output format.) ||(see /var/lib/pacman/local)||(see /var/lib/rpm/Packages)||apt-cache stats||rug dump||n/a ||emerge --info<br />
|-<br />
| Show all or most information about a package. The tools\' verbosity for the default command vary. But with options, the tools are on par with each other. ||pacman -[S<nowiki>|</nowiki>Q]i ||yum list or info ||apt-cache showpkg apt-cache show||rug info||zypper info zypper if||emerge -S; emerge -pv<br />
|- style="background:#e4e4e4"<br />
| Search for package(s) by searching the expression in name, description, short description. What exact fields are being searched by default varies in each tool. Mostly options bring tools on par. ||pacman -Ss ||yum search ||apt-cache search||rug search||zypper search zypper se [-s]||emerge -S <br />
|-<br />
| Lists packages which have an update available. Note: Some provide special commands to limit the output to certain installation sources, others use options. ||pacman -Qu ||yum list updates yum check-update ||apt-get upgrade -> n||rug list-updates rug summary||zypper list-updates zypper patch-check (just for patches) ||emerge -uDNp world<br />
|- style="background:#e4e4e4"<br />
| Display a list of all packages in all installation sources that are handled by the packages management. Some tools provide options or additional commands to limit the output to a specific installation source. ||pacman -Sl ||yum list available||apt-cache dumpavail apt-cache dump (Cache only) apt-cache pkgnames||rug packages||IN PROGRESS ||emerge -ep world<br />
|-<br />
| Displays packages which provide the given exp. aka reverse provides. Mainly a shortcut to search a specific field. Other tools might offer this functionality through the search command. ||pkgfile <filename>||yum whatprovides yum provides ||apt-file search <filename>||rug what-provides||zypper what-provides&nbsp;&nbsp;&nbsp; zypper wp|| equery belongs (only installed packages)<br />
|- style="background:#e4e4e4"<br />
| Display packages which require X to be installed, aka show reverse dependencies. rug\'s what-requires can operate on more than just package names. ||pacman -Qi||yum resolvedep ||apt-cache rdepends||rug what-requires||IN PROGRESS || equery depends<br />
|-<br />
| Display packages which conflict with given expression (often package). Search can be used as well to mimic this function. rug\'s what-conflicts function operates on more than just package names ||(none)||||||rug info-conflicts rug what-conflicts||IN PROGRESS ||<br />
|- style="background:#e4e4e4"<br />
| List all packages which are required for the given package, aka show dependencies. ||pacman -[S<nowiki>|</nowiki>Q]i||yum deplist ||apt-cache depends||rug info-requirements||IN PROGRESS || emerge -ep<br />
|-<br />
| List what the current package provides ||||yum provides ||||rug info-provides||IN PROGRESS||<br />
|- style="background:#e4e4e4"<br />
| List the files that the package holds. Again, this functionality can be mimicked by other more complex commands. ||pacman -Ql $pkgname <br/>pkgfile -l ||yum provides ||apt-file list||rug* file-list||IN PROGRESS ||equery files<br />
|-<br />
| Search all packages to find the one which holds the specified file. auto-apt is using this functionality. ||pkgfile -s||yum provides yum whatprovides ||apt-file search||rug* package-file rug what-provides||IN PROGRESS ||equery belongs<br />
|- style="background:#e4e4e4"<br />
| Display all packages that the specified packages obsoletes. ||||yum list obsoletes ||apt-cache / grep||rug info-obsoletes||IN PROGRESS|| <br />
|-<br />
| Verify dependencies of the complete system. Used if installation process was forcefully killed. ||N/A||yum deplist ||apt-get check ? apt-cache unmet||rug verify rug* dangling-requires||n/a || emerge -uDN world<br />
|- style="background:#e4e4e4"<br />
| Generates a list of installed packages ||pacman -Q||yum list installed ||apt-cache --installed||||n/a ||emerge -ep world<br />
|-<br />
| List packages that are installed but are not available in any installation source (anymore). ||pacman -Qm||yum list extras ||||||n/a||<br />
|- style="background:#e4e4e4"<br />
| List packages that were recently added to one of the installation sources, i.e. which are new to it. Note: Synaptic has this functionality, however apt doesn\'t seem to be the provider. ||(none)||yum list recent ||||||n/a||<br />
|-<br />
| Show a log of actions taken by the software management. ||cat /var/log/pacman.log ||||cat /var/log/dpkg.log||rug history ||n/a || located in /var/log/portage<br />
|- style="background:#e4e4e4"<br />
| Clean up all local caches. Options might limit what is actually cleaned. Autoclean removes only unneeded, obsolete information. ||pacman -Sc<br/>pacman -Scc ||yum clean ||apt-cache clean apt-cache autoclean||||n/a ||<br />
|-<br />
| Add a local package to the local package cache mostly for debugging purposes. ||cp $pkgname /var/cache/pacman/pkg/||||apt-cache add ||||n/a ||<br />
|- style="background:#e4e4e4"<br />
| Display the source package to the given package name(s) ||||||apt-cache showsrc ||||n/a||<br />
|-<br />
| Generates an output suitable for processing with dotty for the given package(s). ||||||apt-cache dotty ||||n/a ||<br />
|- style="background:#e4e4e4"<br />
| Set the priority of the given package to avoid upgrade, force downgrade or to overwrite any default behavior. Can also be used to prefer a package version from a certain installation source. ||${EDITOR} /etc/pacman.conf<br/>Modify HoldPkg and/or IgnorePkg arrays||yum-plugin-priorities and yum-plugin-protect-packages||/etc/apt/preferences smart priority –set||||n/a ||<br />
|-<br />
| Remove a previously set priority ||||||/etc/apt/preferences smart priority --remove ||||n/a ||<br />
|- style="background:#e4e4e4"<br />
| Show a list of set priorities. ||||||apt-cache policy /etc/apt/preferences smart priority --show ||||n/a ||<br />
|-<br />
| Ignores problems that priorities may trigger. ||||||||||n/a ||<br />
|-<br />
| ||||||||||||<br />
|-<br />
| ||||||||||||<br />
|- style="background:#e4e4e4"<br />
| Installation sources management ||${EDITOR} /etc/pacman.conf||||||||||<br />
|-<br />
| Add an installation source to the system. Some tools provide additional commands for certain sources, others allow all types of source URI for the add command. Again others, like apt and yum force editing a sources list. apt-cdrom is a special command, which offers special options design for CDs/DVDs as source. ||${EDITOR} /etc/pacman.conf||||apt-cdrom add||rug service-add rug mount /local/dir||zypper service-add ||layman, overlays<br />
|- style="background:#e4e4e4"<br />
| Refresh the information about the specified installation source(s) or all installation sources. ||pacman -Sy ||yum check-update ||apt-get update||rug refresh||zypper refresh zypper ref||layman -f<br />
|-<br />
| Prints a list of all installation sources including important information like URI, alias etc. ||cat /etc/pacman.d/mirrorlist||||||rug service-list||zypper service-list ||<br />
|- style="background:#e4e4e4"<br />
| Other commands ||||||||||||<br />
|-<br />
| Start a shell Start a shell to enter multiple commands in one session ||||yum shell ||apt-config shell||||zypper shell ||<br />
|-<br />
| ||||||||||||<br />
|-<br />
| ||||||||||||<br />
|- style="background:#e4e4e4"<br />
| Package Verification||||||||||||<br />
|-<br />
| Single package||||rpm -V <package>||debsums||rpm -V <package>||rpm -V <package>||equery check<br />
|- style="background:#e4e4e4"<br />
| All packages||||rpm -Va||debsums||rpm -Va||rpm -Va||equery check<br />
|-<br />
| ||||||||||||<br />
|-<br />
| ||||||||||||<br />
|-<br />
| Package Querying||||||||||||<br />
|- style="background:#e4e4e4"<br />
| List installed local packages along with version||pacman -Q||rpm -qa||dpkg-query -l||||||emerge -e world<br />
|-<br />
| Display package information: Name, version, description, etc.||pacman -Qi ||rpm -qi ||dpkg-query -p||||||emerge -pv and emerge -S<br />
|- style="background:#e4e4e4"<br />
| Display files provided by package||pacman -Ql ||rpm -ql ||dpkg-query -L||||||equery files<br />
|-<br />
| Query the package which provides FILE ||pacman -Qo ||rpm -qf ||dpkg-query -S||||||<br />
|- style="background:#e4e4e4"<br />
| Query a package supplied on the command line rather than an entry in the package management database||pacman -Qp||rpm -qp||dpkg-deb -I||||||<br />
|-<br />
| Show the changelog of a package||pacman -Qc||rpm -q --changelog||||||||||<br />
|}</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Powerpill&diff=85778
Powerpill
2009-11-30T12:25:58Z
<p>Daenyth: /* Using Reflector */ {{Codeline}} gave {{{1}}} for some reason.</p>
<hr />
<div>[[Category:Package management (English)]]<br />
=Introduction=<br />
Powerpill is a wrapper script written by Xyne for [[pacman]] that speeds up package retrieval by using aria2c for concurrent/segmented downloads. It determines the target packages of requested synchronization operation and then uses the mirrorlist to create a comprehensive metalink. This metalink is then piped to the download manager aria2 for package retrieval. Significant reductions in download times are often possible due to the combined effects of simultaneous and segmented downloads.<br />
<br />
Example: One wants to update and issues a ''pacman -Syu'' which returns a list of 20 packages that are available for update totally 200 megs. If the user downloads them via pacman, they will come down one-at-a-time. If the user downloads them via powerpill, they will come down simultaneously in many cases several times faster (depending on one's connection speed, the availability of packages on servers, and speed from server/load, etc.)<br />
<br />
A test of pacman vs. powerpill on one system revealed a 4x speed up in the above scenario where the pacman downloads averages 300 kB/sec and the powerpill downloads averaged 1.2 MB/sec.<br />
<br />
=Installation=<br />
Powerpill and its deps reside in [community] for your convenience. Installation of powerpill is trivial:<br />
<br />
# pacman -S powerpill<br />
<br />
=Configuration=<br />
Powerpill has a single configure file {{Filename|/etc/powerpill.conf}} you can edit to your liking. Most of it is well commented and obvious to the user.<br />
== Using Reflector ==<br />
By default, Powerpill is configured to use [[Reflector]] to append a list of the 45 most recently updated servers to its internal server list. This is to make sure that there are enough servers in the list for significant speed improvements. As this does not take server speed into account, the user may wish to set a aria2's lowest-speed-limit option in the aria2_options section of /etc/powerpill.conf:<br />
<br />
#lowest-speed-limit=10K<br />
<br />
It is also possible to change the "Reflect = -l 45" to get the fastest mirrors instead of the most recent but this is not recommended as the time it takes to rank the mirrors will be greater than the time it takes to download the packages in most cases.<br />
<br />
The user may also simply comment out the "Reflect" line but in that case the user should have as many mirrors in their {{Filename|/etc/powerpill.d/mirrorlist}} as the maximum number of connections in /etc/powerpill.conf. Powerpill relies on access to multiple mirrors to speed up downloads.<br />
<br />
=Basic Usage=<br />
For most operations, powerpill works just like pacman since it is a wrapper script for pacman.<br />
<br />
==System Updating==<br />
To update your system (sync and update installed packages) using powerpill, simply pass the -Syu options to it as you would with pacman:<br />
<br />
# powerpill -Syu<br />
<br />
==Installation of packages==<br />
To install a package and its deps, simply use powerpill with the -S option as you would with pacman:<br />
<br />
# powerpill -S package<br />
<br />
You may also install multiple packages with it the same way you would with pacman:<br />
<br />
# powerpill -S package1 package2 package3<br />
<br />
=External Links=<br />
[http://xyne.archlinux.ca/info/powerpill Official Powerpill Page]</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Powerpill&diff=85777
Powerpill
2009-11-30T12:23:11Z
<p>Daenyth: /* Configuration */ {{Filename}}, etc</p>
<hr />
<div>[[Category:Package management (English)]]<br />
=Introduction=<br />
Powerpill is a wrapper script written by Xyne for [[pacman]] that speeds up package retrieval by using aria2c for concurrent/segmented downloads. It determines the target packages of requested synchronization operation and then uses the mirrorlist to create a comprehensive metalink. This metalink is then piped to the download manager aria2 for package retrieval. Significant reductions in download times are often possible due to the combined effects of simultaneous and segmented downloads.<br />
<br />
Example: One wants to update and issues a ''pacman -Syu'' which returns a list of 20 packages that are available for update totally 200 megs. If the user downloads them via pacman, they will come down one-at-a-time. If the user downloads them via powerpill, they will come down simultaneously in many cases several times faster (depending on one's connection speed, the availability of packages on servers, and speed from server/load, etc.)<br />
<br />
A test of pacman vs. powerpill on one system revealed a 4x speed up in the above scenario where the pacman downloads averages 300 kB/sec and the powerpill downloads averaged 1.2 MB/sec.<br />
<br />
=Installation=<br />
Powerpill and its deps reside in [community] for your convenience. Installation of powerpill is trivial:<br />
<br />
# pacman -S powerpill<br />
<br />
=Configuration=<br />
Powerpill has a single configure file {{Filename|/etc/powerpill.conf}} you can edit to your liking. Most of it is well commented and obvious to the user.<br />
== Using Reflector ==<br />
By default, Powerpill is configured to use [[Reflector]] to append a list of the 45 most recently updated servers to its internal server list. This is to make sure that there are enough servers in the list for significant speed improvements. As this does not take server speed into account, the user may wish to set a aria2's lowest-speed-limit option in the aria2_options section of /etc/powerpill.conf:<br />
<br />
#lowest-speed-limit=10K<br />
<br />
It is also possible to change the {{Codeline|Reflect = -l 45}} to get the fastest mirrors instead of the most recent but this is not recommended as the time it takes to rank the mirrors will be greater than the time it takes to download the packages in most cases.<br />
<br />
The user may also simply comment out the "Reflect" line but in that case the user should have as many mirrors in their {{Filename|/etc/powerpill.d/mirrorlist}} as the maximum number of connections in /etc/powerpill.conf. Powerpill relies on access to multiple mirrors to speed up downloads.<br />
<br />
=Basic Usage=<br />
For most operations, powerpill works just like pacman since it is a wrapper script for pacman.<br />
<br />
==System Updating==<br />
To update your system (sync and update installed packages) using powerpill, simply pass the -Syu options to it as you would with pacman:<br />
<br />
# powerpill -Syu<br />
<br />
==Installation of packages==<br />
To install a package and its deps, simply use powerpill with the -S option as you would with pacman:<br />
<br />
# powerpill -S package<br />
<br />
You may also install multiple packages with it the same way you would with pacman:<br />
<br />
# powerpill -S package1 package2 package3<br />
<br />
=External Links=<br />
[http://xyne.archlinux.ca/info/powerpill Official Powerpill Page]</div>
Daenyth
https://wiki.archlinux.org/index.php?title=PKGBUILD&diff=85776
PKGBUILD
2009-11-30T12:15:43Z
<p>Daenyth: /* Variables */ typo</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:Package development (English)]]<br />
[[Category:Guidelines (English)]]<br />
{{Article summary start}}<br />
{{Article summary text|An explanation of PKGBUILD variables used for [[Building Packages]].}}<br />
{{Article summary heading|Available in languages}}<br />
{{i18n entry|English|PKGBUILD Variables}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|Building Packages}}<br />
{{Article summary wiki|ABS - The Arch Build System}}<br />
{{Article summary wiki|VCS PKGBUILD guidelines}}<br />
{{Article summary wiki|PKGBUILD Tricks}}<br />
{{Article summary end}}<br />
<br />
A {{Filename|PKGBUILD}} is an Arch Linux package build description file used for [[Building Packages]]. This article describes possible {{Filename|PKGBUILD}} variables.<br />
<br />
==Building packages==<br />
<br />
Packages in Arch Linux are built using the [[makepkg]] utility and information stored in a {{Filename|PKGBUILD}} file. When {{Codeline|makepkg}} is run, it searches for a {{Filename|PKGBUILD}} in the current directory and follows the instructions therein to either compile or otherwise acquire the required files to be packaged within a package file ({{Filename|pkgname.pkg.tar.gz}}). The resulting package contains binary files and installation instructions; readily installed with [[pacman]].<br />
<br />
See [[Building Packages]] for more information.<br />
<br />
==Variables==<br />
<br />
The following are variables that can be filled out in the {{Filename|PKGBUILD}} file:<br />
<br />
; {{Codeline|pkgname}} : The name of the package. It should consist of '''alphanumeric characters only''' and all letters should be '''lowercase'''. For the sake of consistency, {{Codeline|pkgname}} should match the name of the source tarball of the software you are packaging. For instance, if the software is in {{Filename|foobar-2.5.tar.gz}}, the {{Codeline|pkgname}} value should be ''foobar''. The present working directory the {{Filename|PKGBUILD}} file is in should also match the {{Codeline|pkgname}}.<br />
<br />
; {{Codeline|pkgver}} : The version of the package. The value should be the same as the version released by the author of the package. It can contain letters, numbers and periods but '''CANNOT''' contain a hyphen. If the author of the package uses a hyphen in their version numbering scheme, replace it with an underscore. For instance, if the version is ''0.99-10'', it should be changed to ''0.99_10''. <br />
<br />
; {{Codeline|pkgrel}} : The release number of the package specific to Arch Linux. This value allows users to differentiate between consecutive builds of the same version of a package. When a new package version is first released, the '''release number starts at 1'''. As fixes and optimizations are made to the {{Filename|PKGBUILD}} file, the package will be '''re-released''' and the '''release number''' will increment by 1. When a new version of the package comes out, the release number resets to 1.<br />
<br />
; {{Codeline|pkgdesc}} : The description of the package. The description should be about 80 characters or less and should not include the package name in a self-referencing way. For instance, "Nedit is a text editor for X11" should be written as "A text editor for X11."<br />
<br />
; {{Codeline|arch}} : An array of architectures that the {{Filename|PKGBUILD}} file is known to build and work on. Currently, it should contain '''i686''' and/or '''x86_64''', {{Codeline|<nowiki>arch=('i686' 'x86_64')</nowiki>}}. The value '''any''' can also be used for architechture-independent packages. You can access this value with the variable {{Codeline|$CARCH}} during the build.<br />
<br />
; {{Codeline|url}} : The URL of the official site of the software being packaged.<br />
<br />
; {{Codeline|license}} : The license under which the software is distributed. A {{Package Official|licenses}} package has been created in {{Codeline|[core]}} that stores common licenses in {{Filename|/usr/share/licenses/common}}, i.e. {{Filename|/usr/share/licenses/common/GPL}}. If a package is licensed under one of these licenses, the value should be set to the directory name, e.g. {{Codeline|<nowiki>license=('GPL')</nowiki>}}. If the appropriate license is not included in the official {{Package Official|licenses}} package, several things must be done:<br />
# The license file(s) should be included in: {{Filename|/usr/share/licenses/'''pkgname'''/}}, e.g. {{Filename|/usr/share/licenses/foobar/LICENSE}}.<br />
# If the source tarball does '''NOT''' contain the license details and the license is only displayed elsewhere, e.g. a website, then you need to copy the license to a file and include it.<br />
# Add '''custom''' to the {{Codeline|license}} array. Optionally, you can replace '''custom''' with '''custom:name of license'''. Once a license is used in two or more packages in an official repository (including {{Codeline|[community]}}), it becomes a part of the {{Package Official|licenses}} package.<br />
* The [[Wikipedia:BSD License|BSD]], [[Wikipedia:MIT License|MIT]], [[Wikipedia:ZLIB license|zlib/png]] and [[Wikipedia:Python License|Python]] licenses are special cases and could not be included in the {{Package Official|licenses}} package. For the sake of the {{Codeline|license}} array, it is treated as a common license ({{Codeline|<nowiki>license=('BSD')</nowiki>}}, {{Codeline|<nowiki>license=('MIT')</nowiki>}}, {{Codeline|<nowiki>license=('ZLIB')</nowiki>}} and {{Codeline|<nowiki>license=('Python')</nowiki>}}) but technically each one is a custom license because each one has its own copyright line. Any packages licensed under these four should have its own unique license stored in {{Filename|/usr/share/licenses/'''pkgname'''}}. Some packages may not be covered by a single license. In these cases, multiple entries may be made in the license array, e.g. {{Codeline|<nowiki>license=('GPL' 'custom:name of license')</nowiki>}}.<br />
* Additionally, the (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:<br />
** (L)GPL - (L)GPLv2 or any later version<br />
** (L)GPL2 - (L)GPL2 only<br />
** (L)GPL3 - (L)GPL3 or any later version<br />
<br />
; {{Codeline|groups}} : The group the package belongs in. For instance, when you install the {{Package Official|kdebase}} package, it installs all packages that belong in the ''kde'' group.<br />
<br />
; {{Codeline|depends}} : An array of package names that must be installed before this software can be run. If a software requires a minimum version of a dependency, the '''>=''' operator should be used to point this out, e.g. {{Codeline|<nowiki>depends=('foobar>=1.8.0')</nowiki>}}. You do not need to list packages that your software depends on if other packages your software depends on already have those packages listed in their dependency. For instance, ''gtk2'' depends on ''glib2'' and ''glibc''. However, ''glibc'' does not need to be listed as a dependency for ''gtk2'' because it is a dependency for ''glib2''.<br />
<br />
; {{Codeline|makedepends}} : An array of package names that must be installed to build the software but unnecessary for using the software after installation. You can specify the minimum version dependency of the packages in the same format as the {{Codeline|depends}} array.<br />
<br />
{{Warning|The "base" group is assumed already installed in all Arch setups . The group "base-devel" is assumed already installed when building with makepkg . Members of "base" or "base-devel" '''should not''' be included in (make)depends arrays.}}<br />
<br />
; {{Codeline|optdepends}} : An array of package names that are not needed for the software to function but provides additional features. A short description of what each package provides should also be noted. An {{Codeline|optdepends}} may look like this:<br />
optdepends=('cups: printing support'<br />
'sane: scanners support'<br />
'libgphoto2: digital cameras support'<br />
'alsa-lib: sound support'<br />
'giflib: GIF images support'<br />
'libjpeg: JPEG images support'<br />
'libpng: PNG images support')<br />
<br />
; {{Codeline|provides}} : An array of package names that this package provides the features of (or a virtual package such as ''cron'' or ''sh''). If you use this variable, you should add the version ({{Codeline|pkgver}} and perhaps the {{Codeline|pkgrel}}) that this package will provide if dependencies may be affected by it. For instance, if you are providing a modified ''qt'' package named ''qt-foobar'' version 3.3.8 which provides ''qt'' then the {{Codeline|provides}} array should look like {{Codeline|<nowiki>provides=('qt=3.3.8')</nowiki>}}. Putting {{Codeline|<nowiki>provides=('qt')</nowiki>}} will cause to fail those dependencies that require a specific version of ''qt''. Do not add {{Codeline|pkgname}} to your provides array, this is done automatically.<br />
<br />
{{Note|This functionality is slightly broken in pacman 3.1.0 and will be fixed in 3.1.1. This documentation refers to the 3.1.1 syntax which will soon be in use.}}<br />
<br />
; {{Codeline|conflicts}} : An array of package names that may cause problems with this package if installed. You can also specify the version properties of the conflicting packages in the same format as the {{Codeline|depends}} array.<br />
<br />
; {{Codeline|replaces}} : An array of obsolete package name that are replaced by this package, e.g. {{Codeline|<nowiki>replaces=('ethereal')</nowiki>}} for the {{Package Official|wireshark}} package. After syncing with {{Codeline|pacman -Sy}}, it will immediately replace an installed package upon encountering another package with the matching {{Codeline|replaces}} in the repositories. If you are providing an alternate version of an already existing package, use the {{Codeline|conflicts}} variable which is only evaluated when actually installing the conflicting package.<br />
<br />
; {{Codeline|backup}} : An array of files to be backed up as {{Filename|file.pacsave}} when the package is removed. This is commonly used for packages placing configuration files in {{Filename|/etc}}. The file paths in this array should be relative paths (e.g. {{Filename|etc/pacman.conf}}) not absolute paths (e.g. {{Filename|/etc/pacman.conf}}).<br />
<br />
; {{Codeline|options}} : This array allows you to override some of the default behavior of {{Codeline|makepkg}}. To set an option, include the option name in the array. To reverse the default behavior, place an '''!''' at the front of the option. The following options may be placed in the array:<br />
* '''''strip''''' - Strips symbols from binaries and libraries.<br />
* '''''docs''''' - Save {{Filename|/doc}} directories.<br />
* '''''libtool''''' - Leave ''libtool'' ({{Filename|.la}}) files in packages.<br />
* '''''emptydirs''''' - Leave empty directories in packages.<br />
* '''''zipman''''' - Compress ''man'' and ''info'' pages with ''gzip''.<br />
* '''''ccache''''' - Allow the use of {{Codeline|ccache}} during build. More useful in its negative form {{Codeline|!ccache}} with select packages that have problems building with {{Codeline|ccache}}.<br />
* '''''distcc''''' - Allow the use of {{Codeline|distcc}} during build. More useful in its negative form {{Codeline|!distcc}} with select packages that have problems building with {{Codeline|distcc}}.<br />
* '''''makeflags''''' - Allow the use of user-specific {{Codeline|makeflags}} during build. More useful in its negative form {{Codeline|!makeflags}} with select packages that have problems building with custom {{Codeline|makeflags}}.<br />
* '''''force''''' - Force the package to be upgraded by a ''pacman'' system upgrade operation, even if the version number would normally not trigger such an upgrade. This is useful when the version numbering scheme of a package changes (or is alphanumeric).<br />
<br />
; {{Codeline|install}} : The name of the {{Filename|.install}} script to be included in the package. ''pacman'' has the ability to store and execute a package-specific script when it installs, removes or upgrades a package. The script contains the following functions which run at different times:<br />
* '''''pre_install''''' - The script is run right before files are extracted. One argument is passed: new package version.<br />
* '''''post_install''''' - The script is run right after files are extracted. One argument is passed: new package version.<br />
* '''''pre_upgrade''''' - The script is run right before files are extracted. Two arguments are passed in the following order: new package version, old package version.<br />
* '''''post_upgrade''''' - The script is run after files are extracted. Two arguments are passed in the following order: new package version, old package version.<br />
* '''''pre_remove''''' - The script is run right before files are removed. One argument is passed: old package version.<br />
* '''''post_remove''''' - The script is run right after files are removed. One argument is passed: old package version.<br />
<br />
{{Tip|A prototype {{Filename|.install}} is provided at {{Filename|/usr/share/pacman/proto.install}}.}}<br />
<br />
; {{Codeline|source}} : An array of files which are needed to build the package. It must contain the location of the software source, which in most cases is a full HTTP or FTP URL. The previously set variables {{Codeline|pkgname}} and {{Codeline|pkgver}} can be used effectively here (e.g. {{Codeline|<nowiki>source=(http://example.com/$pkgname-$pkgver.tar.gz)</nowiki>}})<br />
<br />
{{Note|If you need to supply files which are not downloadable on the fly, e.g. self-made patches, you simply put those into the same directory where your {{Filename|PKGBUILD}} file is in and add the filename to this array. Any paths you add here are resolved relative to the directory where the {{Filename|PKGBUILD}} lies. Before the actual build process is started, all of the files referenced in this array will be downloaded or checked for existence, and {{Codeline|makepkg}} will not proceed if any are missing.}}<br />
<br />
; {{Codeline|noextract}} : An array of files listed under the {{Codeline|source}} array which should not be extracted from their archive format by {{Codeline|makepkg}}. This most commonly applies to certain zip files which cannot be handled by ''bsdtar'' because ''libarchive'' processes all files as streams rather than random access as ''unzip'' does. In these situations ''unzip'' should be added in the {{Codeline|makedepends}} array and the first line of the {{Codeline|build()}} function should contain:<br />
cd $srcdir/$pkgname-$pkgver<br />
unzip [source].zip<br />
<br />
; {{Codeline|md5sums}} : An array of MD5 checksums of the files listed in the {{Codeline|source}} array. Once all files in the {{Codeline|source}} array are available, an MD5 hash of each file will be automatically generated and compared with the values of this array in the same order they appear in the {{Codeline|source}} array. While the order of the source files itself does not matter, it is important that it matches the order of this array since {{Codeline|makepkg}} cannot guess which checksum belongs to what source file. You can generate this array quickly and easily using the command {{Codeline|makepkg -g}} in the directory that contains the {{Filename|PKGBUILD}} file.<br />
<br />
It is common practice to preserve the order of the {{Filename|PKGBUILD}} variables as shown above. However, this is not mandatory, as the only requirement in this context is correct [[Wikipedia:Bash|Bash]] syntax.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=PKGBUILD&diff=85775
PKGBUILD
2009-11-30T12:15:17Z
<p>Daenyth: /* Variables */ -any is supported</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:Package development (English)]]<br />
[[Category:Guidelines (English)]]<br />
{{Article summary start}}<br />
{{Article summary text|An explanation of PKGBUILD variables used for [[Building Packages]].}}<br />
{{Article summary heading|Available in languages}}<br />
{{i18n entry|English|PKGBUILD Variables}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|Building Packages}}<br />
{{Article summary wiki|ABS - The Arch Build System}}<br />
{{Article summary wiki|VCS PKGBUILD guidelines}}<br />
{{Article summary wiki|PKGBUILD Tricks}}<br />
{{Article summary end}}<br />
<br />
A {{Filename|PKGBUILD}} is an Arch Linux package build description file used for [[Building Packages]]. This article describes possible {{Filename|PKGBUILD}} variables.<br />
<br />
==Building packages==<br />
<br />
Packages in Arch Linux are built using the [[makepkg]] utility and information stored in a {{Filename|PKGBUILD}} file. When {{Codeline|makepkg}} is run, it searches for a {{Filename|PKGBUILD}} in the current directory and follows the instructions therein to either compile or otherwise acquire the required files to be packaged within a package file ({{Filename|pkgname.pkg.tar.gz}}). The resulting package contains binary files and installation instructions; readily installed with [[pacman]].<br />
<br />
See [[Building Packages]] for more information.<br />
<br />
==Variables==<br />
<br />
The following are variables that can be filled out in the {{Filename|PKGBUILD}} file:<br />
<br />
; {{Codeline|pkgname}} : The name of the package. It should consist of '''alphanumeric characters only''' and all letters should be '''lowercase'''. For the sake of consistency, {{Codeline|pkgname}} should match the name of the source tarball of the software you are packaging. For instance, if the software is in {{Filename|foobar-2.5.tar.gz}}, the {{Codeline|pkgname}} value should be ''foobar''. The present working directory the {{Filename|PKGBUILD}} file is in should also match the {{Codeline|pkgname}}.<br />
<br />
; {{Codeline|pkgver}} : The version of the package. The value should be the same as the version released by the author of the package. It can contain letters, numbers and periods but '''CANNOT''' contain a hyphen. If the author of the package uses a hyphen in their version numbering scheme, replace it with an underscore. For instance, if the version is ''0.99-10'', it should be changed to ''0.99_10''. <br />
<br />
; {{Codeline|pkgrel}} : The release number of the package specific to Arch Linux. This value allows users to differentiate between consecutive builds of the same version of a package. When a new package version is first released, the '''release number starts at 1'''. As fixes and optimizations are made to the {{Filename|PKGBUILD}} file, the package will be '''re-released''' and the '''release number''' will increment by 1. When a new version of the package comes out, the release number resets to 1.<br />
<br />
; {{Codeline|pkgdesc}} : The description of the package. The description should be about 80 characters or less and should not include the package name in a self-referencing way. For instance, "Nedit is a text editor for X11" should be written as "A text editor for X11."<br />
<br />
; {{Codeline|arch}} : An array of architectures that the {{Filename|PKGBUILD}} file is known to build and work on. Currently, it should contain '''i686''' and/or '''x86_64''', {{Codeline|<nowiki>arch=('i686' 'x86_64')</nowiki>}}. The value '''any''' can also be used for independent packages. You can access this value with the variable {{Codeline|$CARCH}} during the build.<br />
<br />
; {{Codeline|url}} : The URL of the official site of the software being packaged.<br />
<br />
; {{Codeline|license}} : The license under which the software is distributed. A {{Package Official|licenses}} package has been created in {{Codeline|[core]}} that stores common licenses in {{Filename|/usr/share/licenses/common}}, i.e. {{Filename|/usr/share/licenses/common/GPL}}. If a package is licensed under one of these licenses, the value should be set to the directory name, e.g. {{Codeline|<nowiki>license=('GPL')</nowiki>}}. If the appropriate license is not included in the official {{Package Official|licenses}} package, several things must be done:<br />
# The license file(s) should be included in: {{Filename|/usr/share/licenses/'''pkgname'''/}}, e.g. {{Filename|/usr/share/licenses/foobar/LICENSE}}.<br />
# If the source tarball does '''NOT''' contain the license details and the license is only displayed elsewhere, e.g. a website, then you need to copy the license to a file and include it.<br />
# Add '''custom''' to the {{Codeline|license}} array. Optionally, you can replace '''custom''' with '''custom:name of license'''. Once a license is used in two or more packages in an official repository (including {{Codeline|[community]}}), it becomes a part of the {{Package Official|licenses}} package.<br />
* The [[Wikipedia:BSD License|BSD]], [[Wikipedia:MIT License|MIT]], [[Wikipedia:ZLIB license|zlib/png]] and [[Wikipedia:Python License|Python]] licenses are special cases and could not be included in the {{Package Official|licenses}} package. For the sake of the {{Codeline|license}} array, it is treated as a common license ({{Codeline|<nowiki>license=('BSD')</nowiki>}}, {{Codeline|<nowiki>license=('MIT')</nowiki>}}, {{Codeline|<nowiki>license=('ZLIB')</nowiki>}} and {{Codeline|<nowiki>license=('Python')</nowiki>}}) but technically each one is a custom license because each one has its own copyright line. Any packages licensed under these four should have its own unique license stored in {{Filename|/usr/share/licenses/'''pkgname'''}}. Some packages may not be covered by a single license. In these cases, multiple entries may be made in the license array, e.g. {{Codeline|<nowiki>license=('GPL' 'custom:name of license')</nowiki>}}.<br />
* Additionally, the (L)GPL has many versions and permutations of those versions. For (L)GPL software, the convention is:<br />
** (L)GPL - (L)GPLv2 or any later version<br />
** (L)GPL2 - (L)GPL2 only<br />
** (L)GPL3 - (L)GPL3 or any later version<br />
<br />
; {{Codeline|groups}} : The group the package belongs in. For instance, when you install the {{Package Official|kdebase}} package, it installs all packages that belong in the ''kde'' group.<br />
<br />
; {{Codeline|depends}} : An array of package names that must be installed before this software can be run. If a software requires a minimum version of a dependency, the '''>=''' operator should be used to point this out, e.g. {{Codeline|<nowiki>depends=('foobar>=1.8.0')</nowiki>}}. You do not need to list packages that your software depends on if other packages your software depends on already have those packages listed in their dependency. For instance, ''gtk2'' depends on ''glib2'' and ''glibc''. However, ''glibc'' does not need to be listed as a dependency for ''gtk2'' because it is a dependency for ''glib2''.<br />
<br />
; {{Codeline|makedepends}} : An array of package names that must be installed to build the software but unnecessary for using the software after installation. You can specify the minimum version dependency of the packages in the same format as the {{Codeline|depends}} array.<br />
<br />
{{Warning|The "base" group is assumed already installed in all Arch setups . The group "base-devel" is assumed already installed when building with makepkg . Members of "base" or "base-devel" '''should not''' be included in (make)depends arrays.}}<br />
<br />
; {{Codeline|optdepends}} : An array of package names that are not needed for the software to function but provides additional features. A short description of what each package provides should also be noted. An {{Codeline|optdepends}} may look like this:<br />
optdepends=('cups: printing support'<br />
'sane: scanners support'<br />
'libgphoto2: digital cameras support'<br />
'alsa-lib: sound support'<br />
'giflib: GIF images support'<br />
'libjpeg: JPEG images support'<br />
'libpng: PNG images support')<br />
<br />
; {{Codeline|provides}} : An array of package names that this package provides the features of (or a virtual package such as ''cron'' or ''sh''). If you use this variable, you should add the version ({{Codeline|pkgver}} and perhaps the {{Codeline|pkgrel}}) that this package will provide if dependencies may be affected by it. For instance, if you are providing a modified ''qt'' package named ''qt-foobar'' version 3.3.8 which provides ''qt'' then the {{Codeline|provides}} array should look like {{Codeline|<nowiki>provides=('qt=3.3.8')</nowiki>}}. Putting {{Codeline|<nowiki>provides=('qt')</nowiki>}} will cause to fail those dependencies that require a specific version of ''qt''. Do not add {{Codeline|pkgname}} to your provides array, this is done automatically.<br />
<br />
{{Note|This functionality is slightly broken in pacman 3.1.0 and will be fixed in 3.1.1. This documentation refers to the 3.1.1 syntax which will soon be in use.}}<br />
<br />
; {{Codeline|conflicts}} : An array of package names that may cause problems with this package if installed. You can also specify the version properties of the conflicting packages in the same format as the {{Codeline|depends}} array.<br />
<br />
; {{Codeline|replaces}} : An array of obsolete package name that are replaced by this package, e.g. {{Codeline|<nowiki>replaces=('ethereal')</nowiki>}} for the {{Package Official|wireshark}} package. After syncing with {{Codeline|pacman -Sy}}, it will immediately replace an installed package upon encountering another package with the matching {{Codeline|replaces}} in the repositories. If you are providing an alternate version of an already existing package, use the {{Codeline|conflicts}} variable which is only evaluated when actually installing the conflicting package.<br />
<br />
; {{Codeline|backup}} : An array of files to be backed up as {{Filename|file.pacsave}} when the package is removed. This is commonly used for packages placing configuration files in {{Filename|/etc}}. The file paths in this array should be relative paths (e.g. {{Filename|etc/pacman.conf}}) not absolute paths (e.g. {{Filename|/etc/pacman.conf}}).<br />
<br />
; {{Codeline|options}} : This array allows you to override some of the default behavior of {{Codeline|makepkg}}. To set an option, include the option name in the array. To reverse the default behavior, place an '''!''' at the front of the option. The following options may be placed in the array:<br />
* '''''strip''''' - Strips symbols from binaries and libraries.<br />
* '''''docs''''' - Save {{Filename|/doc}} directories.<br />
* '''''libtool''''' - Leave ''libtool'' ({{Filename|.la}}) files in packages.<br />
* '''''emptydirs''''' - Leave empty directories in packages.<br />
* '''''zipman''''' - Compress ''man'' and ''info'' pages with ''gzip''.<br />
* '''''ccache''''' - Allow the use of {{Codeline|ccache}} during build. More useful in its negative form {{Codeline|!ccache}} with select packages that have problems building with {{Codeline|ccache}}.<br />
* '''''distcc''''' - Allow the use of {{Codeline|distcc}} during build. More useful in its negative form {{Codeline|!distcc}} with select packages that have problems building with {{Codeline|distcc}}.<br />
* '''''makeflags''''' - Allow the use of user-specific {{Codeline|makeflags}} during build. More useful in its negative form {{Codeline|!makeflags}} with select packages that have problems building with custom {{Codeline|makeflags}}.<br />
* '''''force''''' - Force the package to be upgraded by a ''pacman'' system upgrade operation, even if the version number would normally not trigger such an upgrade. This is useful when the version numbering scheme of a package changes (or is alphanumeric).<br />
<br />
; {{Codeline|install}} : The name of the {{Filename|.install}} script to be included in the package. ''pacman'' has the ability to store and execute a package-specific script when it installs, removes or upgrades a package. The script contains the following functions which run at different times:<br />
* '''''pre_install''''' - The script is run right before files are extracted. One argument is passed: new package version.<br />
* '''''post_install''''' - The script is run right after files are extracted. One argument is passed: new package version.<br />
* '''''pre_upgrade''''' - The script is run right before files are extracted. Two arguments are passed in the following order: new package version, old package version.<br />
* '''''post_upgrade''''' - The script is run after files are extracted. Two arguments are passed in the following order: new package version, old package version.<br />
* '''''pre_remove''''' - The script is run right before files are removed. One argument is passed: old package version.<br />
* '''''post_remove''''' - The script is run right after files are removed. One argument is passed: old package version.<br />
<br />
{{Tip|A prototype {{Filename|.install}} is provided at {{Filename|/usr/share/pacman/proto.install}}.}}<br />
<br />
; {{Codeline|source}} : An array of files which are needed to build the package. It must contain the location of the software source, which in most cases is a full HTTP or FTP URL. The previously set variables {{Codeline|pkgname}} and {{Codeline|pkgver}} can be used effectively here (e.g. {{Codeline|<nowiki>source=(http://example.com/$pkgname-$pkgver.tar.gz)</nowiki>}})<br />
<br />
{{Note|If you need to supply files which are not downloadable on the fly, e.g. self-made patches, you simply put those into the same directory where your {{Filename|PKGBUILD}} file is in and add the filename to this array. Any paths you add here are resolved relative to the directory where the {{Filename|PKGBUILD}} lies. Before the actual build process is started, all of the files referenced in this array will be downloaded or checked for existence, and {{Codeline|makepkg}} will not proceed if any are missing.}}<br />
<br />
; {{Codeline|noextract}} : An array of files listed under the {{Codeline|source}} array which should not be extracted from their archive format by {{Codeline|makepkg}}. This most commonly applies to certain zip files which cannot be handled by ''bsdtar'' because ''libarchive'' processes all files as streams rather than random access as ''unzip'' does. In these situations ''unzip'' should be added in the {{Codeline|makedepends}} array and the first line of the {{Codeline|build()}} function should contain:<br />
cd $srcdir/$pkgname-$pkgver<br />
unzip [source].zip<br />
<br />
; {{Codeline|md5sums}} : An array of MD5 checksums of the files listed in the {{Codeline|source}} array. Once all files in the {{Codeline|source}} array are available, an MD5 hash of each file will be automatically generated and compared with the values of this array in the same order they appear in the {{Codeline|source}} array. While the order of the source files itself does not matter, it is important that it matches the order of this array since {{Codeline|makepkg}} cannot guess which checksum belongs to what source file. You can generate this array quickly and easily using the command {{Codeline|makepkg -g}} in the directory that contains the {{Filename|PKGBUILD}} file.<br />
<br />
It is common practice to preserve the order of the {{Filename|PKGBUILD}} variables as shown above. However, this is not mandatory, as the only requirement in this context is correct [[Wikipedia:Bash|Bash]] syntax.</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Talk:Arch_User_Repository&diff=85740
Talk:Arch User Repository
2009-11-30T01:10:30Z
<p>Daenyth: </p>
<hr />
<div>move to AUR (English)<br>[[User:Gog|Gog]] 00:51, 19 October 2009 (EDT)<br />
<br />
== Request, tar.gz instructions ==<br />
<br />
Would you please add<br />
<br />
tar cfvz PKG.tar.gz PKG/<br />
<br />
to http://wiki.archlinux.org/index.php/AUR_User_Guidelines#Submitting_Packages_to_UNSUPPORTED ? In the age of aunpack, who cares about tar commands? :| Make it easier for people who are sane enough to write PKGBUILD files but too sane to remember legacy compression commands (7z anyone?)--[[User:Qubodup|Qubodup]] 18:25, 26 October 2009 (EDT)<br />
<br />
== Using fakeroot part of article editing ==<br />
<br />
It says "By default export USE_FAKEROOT="y" is included in /etc/makepkg.conf, so unless you have switched it off it is already enabled." Newer Arch systems are using BUILDENV directive and user should set ! right before the fakeroot to disable it or delete ! before fakeroot to enable it.--[[User:Jazz1303|Jazz1303]] 13:15, 3 November 2009 (EST)<br />
<br />
== Removing / changing the part about [community] ==<br />
<br />
IMO this whole part should just be removed now that community have been seperated from aur.<br />
But as a minimum it should be cleaned up, since there have been cases where it have confused users rather than help them:<br />
<br />
Perhaps something like:<br><br />
...<br><br />
The [community] repo is enabled by default in <tt>pacman.conf</tt>. If disabled/removed, it can be enabled by uncommenting/adding these two lines:<br />
{{File|name=/etc/pacman.conf|content=<br />
<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki><br />
}}<br />
...<br> <br />
Any typos would have to be fixed of course :p <br><br />
Is community still disabled by default in abs.conf btw?<br />
<br />
[[User:Mr.Elendig|Mr.Elendig]] 21:37, 21 November 2009 (EST)<br />
<br />
== JSON ==<br />
There should be some sort of info on the JSON interface [[User:Daenyth|Daenyth]] 20:10, 29 November 2009 (EST)</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Talk:Arch_User_Repository&diff=85739
Talk:Arch User Repository
2009-11-30T01:10:16Z
<p>Daenyth: moar json plox</p>
<hr />
<div>move to AUR (English)<br>[[User:Gog|Gog]] 00:51, 19 October 2009 (EDT)<br />
<br />
== Request, tar.gz instructions ==<br />
<br />
Would you please add<br />
<br />
tar cfvz PKG.tar.gz PKG/<br />
<br />
to http://wiki.archlinux.org/index.php/AUR_User_Guidelines#Submitting_Packages_to_UNSUPPORTED ? In the age of aunpack, who cares about tar commands? :| Make it easier for people who are sane enough to write PKGBUILD files but too sane to remember legacy compression commands (7z anyone?)--[[User:Qubodup|Qubodup]] 18:25, 26 October 2009 (EDT)<br />
<br />
== Using fakeroot part of article editing ==<br />
<br />
It says "By default export USE_FAKEROOT="y" is included in /etc/makepkg.conf, so unless you have switched it off it is already enabled." Newer Arch systems are using BUILDENV directive and user should set ! right before the fakeroot to disable it or delete ! before fakeroot to enable it.--[[User:Jazz1303|Jazz1303]] 13:15, 3 November 2009 (EST)<br />
<br />
== Removing / changing the part about [community] ==<br />
<br />
IMO this whole part should just be removed now that community have been seperated from aur.<br />
But as a minimum it should be cleaned up, since there have been cases where it have confused users rather than help them:<br />
<br />
Perhaps something like:<br><br />
...<br><br />
The [community] repo is enabled by default in <tt>pacman.conf</tt>. If disabled/removed, it can be enabled by uncommenting/adding these two lines:<br />
{{File|name=/etc/pacman.conf|content=<br />
<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki><br />
}}<br />
...<br> <br />
Any typos would have to be fixed of course :p <br><br />
Is community still disabled by default in abs.conf btw?<br />
<br />
[[User:Mr.Elendig|Mr.Elendig]] 21:37, 21 November 2009 (EST)<br />
<br />
== JSON ==<br />
There should be some sort of info on the JSON interface</div>
Daenyth
https://wiki.archlinux.org/index.php?title=KDE_Packages&diff=85737
KDE Packages
2009-11-30T00:13:22Z
<p>Daenyth: Category: Desktop Environments.</p>
<hr />
<div>[[Category:Arch development (English)]]<br />
[[Category:Desktop Environments (English)]]<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|KDE Packages}}<br />
{{i18n_entry|简体中文|KDE的软件包 (简体中文)}}<br />
{{i18n_links_end}}<br />
<br />
With KDE 4.3 separate packages for each application are provided. This article describes the concept about groups and meta packages.<br />
<br />
==Naming==<br />
* '''module''': KDE's source code is organized into several categories called ''modules''. The project releases one source archive per module. See http://techbase.kde.org/Projects/Release_Team#Coordinator_List<br />
* '''group''': Packages can be put into a package group. [[Pacman]] is able to select packages by groups on install or uninstall. This meta information does not imply any hard dependencies.<br />
* '''meta package''': An empty package which just connects several packages by using dependencies.<br />
<br />
==Package groups==<br />
There are groups for each KDE module. In addition to this there is the '''kde''' group which includes the whole KDE distribution.<br />
<br />
Using groups makes it easier to install and maintain a set of packages. There is no hard dependency between a group and its packages. That means there is no need to install all packages of a group for example. On the other hand pacman wont install any packages new to a certain group on its own.<br />
<br />
Just type <br />
pacman -S kdebase kdeutils ...<br />
to install some groups or<br />
pacman -S kde<br />
to install all of them.<br />
<br />
==Meta packages==<br />
There are meta packages for each KDE module. Each of those replace and provide one of the previous packages that were used before KDE 4.3. This also ensures a smooth update to the new split packages.<br />
<br />
In contrast to groups meta packages have a hard dependency to all its KDE modules. So, you cannot remove any sub packages without removing the meta package itself. If there are new modules available the use of meta packages ensures that pacman will install those automatically.<br />
<br />
All meta packages are member of the '''kde-meta''' group and thus can be easily installed or removed.<br />
<br />
You can remove or install meta packages at any time in order to use modular packages or emulate the previous monolithic set of packages.<br />
<br />
To remove those groups use<br />
pacman -R kde-meta<br />
This wont remove any KDE packages but only the meta packages!<br />
<br />
==Overview==<br />
{|border="1"<br />
|style="width:20%;background-color:#E5E5E5"|'''package group'''<br />
|style="width:20%;background-color:#E5E5E5"|'''meta package'''<br />
|style="width:30%;background-color:#E5E5E5"|'''packages'''<br />
|style="width:30%;background-color:#E5E5E5"|'''description'''<br />
|-<br />
|kdeaccessibility<br />
|kde-meta-kdeaccessibility<br />
|<br />
* kdeaccessibility-colorschemes<br />
* kdeaccessibility-iconthemes<br />
* kdeaccessibility-kmag<br />
* kdeaccessibility-kmousetool<br />
* kdeaccessibility-kmouth<br />
* kdeaccessibility-kttsd<br />
|Accessibility applications<br />
|-<br />
|kdeadmin<br />
|kde-meta-kdeadmin<br />
|<br />
* kdeadmin-kcron<br />
* kdeadmin-ksystemlog<br />
* kdeadmin-kuser<br />
* kdeadmin-system-config-printer-kde<br />
|Tools for system administration<br />
|-<br />
|kdeartwork<br />
|kde-meta-kdeartwork<br />
|<br />
* kdeartwork-colorschemes<br />
* kdeartwork-desktopthemes<br />
* kdeartwork-emoticons<br />
* kdeartwork-iconthemes<br />
* kdeartwork-kscreensaver<br />
* kdeartwork-sounds<br />
* kdeartwork-styles<br />
* kdeartwork-wallpapers<br />
* kdeartwork-weatherwallpapers<br />
|Additional icons, styles, etc.<br />
|-<br />
|kdebase<br />
|kde-meta-kdebase<br />
|<br />
* kdebase-dolphin<br />
* kdebase-kappfinder<br />
* kdebase-kdepasswd<br />
* kdebase-kdialog<br />
* kdebase-kfind<br />
* kdebase-kinfocenter<br />
* kdebase-konqueror<br />
* kdebase-konsole<br />
* kdebase-kwrite<br />
* kdebase-plasma<br />
|Essential apps needed to complement a desktop shell for basic functionality (web browser, file manager, ...)<br />
|-<br />
|kdebindings<br />
|kde-meta-kdebindings<br />
|<br />
* kdebindings-csharp<br />
* kdebindings-python<br />
* kdebindings-ruby<br />
* kdebindings-smoke<br />
|Bindings to programming languages<br />
|-<br />
|kdeedu<br />
|kde-meta-kdeedu<br />
|<br />
* kdeedu-blinken<br />
* kdeedu-kalgebra<br />
* kdeedu-kalzium<br />
* kdeedu-kanagram<br />
* kdeedu-kbruch<br />
* kdeedu-kgeography<br />
* kdeedu-khangman<br />
* kdeedu-kig<br />
* kdeedu-kiten<br />
* kdeedu-klettres<br />
* kdeedu-kmplot<br />
* kdeedu-kstars<br />
* kdeedu-ktouch<br />
* kdeedu-kturtle<br />
* kdeedu-kwordquiz<br />
* kdeedu-marble<br />
* kdeedu-parley<br />
* kdeedu-step<br />
|Applications with educational content<br />
|-<br />
|kdegames<br />
|kde-meta-kdegames<br />
|<br />
* kdegames-bomber<br />
* kdegames-bovo<br />
* kdegames-kapman<br />
* kdegames-katomic<br />
* kdegames-kbattleship<br />
* kdegames-kblackbox<br />
* kdegames-kblocks<br />
* kdegames-kbounce<br />
* kdegames-kbreakout<br />
* kdegames-kdiamond<br />
* kdegames-kfourinline<br />
* kdegames-kgoldrunner<br />
* kdegames-killbots<br />
* kdegames-kiriki<br />
* kdegames-kjumpingcube<br />
* kdegames-klines<br />
* kdegames-kmahjongg<br />
* kdegames-kmines<br />
* kdegames-knetwalk<br />
* kdegames-kolf<br />
* kdegames-kollision<br />
* kdegames-konquest<br />
* kdegames-kpat<br />
* kdegames-kreversi<br />
* kdegames-ksame<br />
* kdegames-kshisen<br />
* kdegames-ksirk<br />
* kdegames-kspaceduel<br />
* kdegames-ksquares<br />
* kdegames-ksudoku<br />
* kdegames-ktron<br />
* kdegames-ktuberling<br />
* kdegames-kubrick<br />
* kdegames-lskat<br />
|Entertainment<br />
|-<br />
|kdegraphics<br />
|kde-meta-kdegraphics<br />
|<br />
* kdegraphics-gwenview<br />
* kdegraphics-kamera<br />
* kdegraphics-kcolorchooser<br />
* kdegraphics-kgamma<br />
* kdegraphics-kolourpaint<br />
* kdegraphics-kruler<br />
* kdegraphics-ksnapshot<br />
* kdegraphics-okular<br />
|Graphics viewing and editing<br />
|-<br />
|kdemultimedia<br />
|kde-meta-kdemultimedia<br />
|<br />
* kdemultimedia-dragonplayer<br />
* kdemultimedia-juk<br />
* kdemultimedia-kioslave<br />
* kdemultimedia-kmix<br />
* kdemultimedia-kscd<br />
* kdemultimedia-mplayerthumbs<br />
|Audio and video applications<br />
|-<br />
|kdenetwork<br />
|kde-meta-kdenetwork<br />
|<br />
* kdenetwork-filesharing<br />
* kdenetwork-kdnssd<br />
* kdenetwork-kget<br />
* kdenetwork-kopete<br />
* kdenetwork-kppp<br />
* kdenetwork-krdc<br />
* kdenetwork-krfb<br />
|Network-centric apps (IM, remote desktop, etc)<br />
|-<br />
|kdepim<br />
|kde-meta-kdepim<br />
|<br />
* kdepim-akregator<br />
* kdepim-console<br />
* kdepim-kaddressbook<br />
* kdepim-kalarm<br />
* kdepim-kjots<br />
* kdepim-kleopatra<br />
* kdepim-kmail<br />
* kdepim-knode<br />
* kdepim-knotes<br />
* kdepim-kontact<br />
* kdepim-korganizer<br />
* kdepim-kpilot<br />
* kdepim-kresources<br />
* kdepim-ktimetracker<br />
* kdepim-wizards<br />
|Groupware<br />
|-<br />
|kdeplasma-addons<br />
|kde-meta-kdeplasma-addons<br />
|<br />
* kdeplasma-addons-applets-bball <br />
* kdeplasma-addons-applets-binary-clock <br />
* kdeplasma-addons-applets-bubblemon <br />
* kdeplasma-addons-applets-calculator <br />
* kdeplasma-addons-applets-charselect <br />
* kdeplasma-addons-applets-comic <br />
* kdeplasma-addons-applets-dict <br />
* kdeplasma-addons-applets-eyes <br />
* kdeplasma-addons-applets-fifteenpuzzle <br />
* kdeplasma-addons-applets-filewatcher <br />
* kdeplasma-addons-applets-frame <br />
* kdeplasma-addons-applets-fuzzy-clock <br />
* kdeplasma-addons-applets-incomingmsg<br />
* kdeplasma-addons-applets-kolourpicker<br />
* kdeplasma-addons-applets-konqprofiles<br />
* kdeplasma-addons-applets-konsoleprofiles<br />
* kdeplasma-addons-applets-lancelot<br />
* kdeplasma-addons-applets-leavenote<br />
* kdeplasma-addons-applets-life<br />
* kdeplasma-addons-applets-luna<br />
* kdeplasma-addons-applets-magnifique<br />
* kdeplasma-addons-applets-mediaplayer<br />
* kdeplasma-addons-applets-microblog<br />
* kdeplasma-addons-applets-news<br />
* kdeplasma-addons-applets-notes<br />
* kdeplasma-addons-applets-nowplaying<br />
* kdeplasma-addons-applets-opendesktop<br />
* kdeplasma-addons-applets-paste<br />
* kdeplasma-addons-applets-pastebin<br />
* kdeplasma-addons-applets-previewer<br />
* kdeplasma-addons-applets-rememberthemilk<br />
* kdeplasma-addons-applets-rssnow<br />
* kdeplasma-addons-applets-showdashboard<br />
* kdeplasma-addons-applets-showdesktop<br />
* kdeplasma-addons-applets-systemloadviewer<br />
* kdeplasma-addons-applets-timer<br />
* kdeplasma-addons-applets-unitconverter<br />
* kdeplasma-addons-applets-weather<br />
* kdeplasma-addons-applets-weatherstation<br />
* kdeplasma-addons-runners-browserhistory<br />
* kdeplasma-addons-runners-contacts<br />
* kdeplasma-addons-runners-converter<br />
* kdeplasma-addons-runners-katesessions<br />
* kdeplasma-addons-runners-konquerorsessions<br />
* kdeplasma-addons-runners-konsolesessions<br />
* kdeplasma-addons-runners-spellchecker<br />
* kdeplasma-addons-wallpapers-mandelbrot<br />
* kdeplasma-addons-wallpapers-marble<br />
* kdeplasma-addons-wallpapers-pattern<br />
* kdeplasma-addons-wallpapers-virus<br />
* kdeplasma-addons-wallpapers-weather<br />
|Plasma applets<br />
|-<br />
|kdesdk<br />
|kde-meta-kdesdk<br />
|<br />
* kdesdk-cervisia<br />
* kdesdk-kapptemplate<br />
* kdesdk-kate<br />
* kdesdk-kbugbuster<br />
* kdesdk-kcachegrind<br />
* kdesdk-kdeaccounts-plugin<br />
* kdesdk-kdepalettes<br />
* kdesdk-kioslave<br />
* kdesdk-kmtrace<br />
* kdesdk-kompare<br />
* kdesdk-kpartloader<br />
* kdesdk-kprofilemethod<br />
* kdesdk-kstartperf<br />
* kdesdk-kuiviewer<br />
* kdesdk-lokalize<br />
* kdesdk-poxml<br />
* kdesdk-scripts<br />
* kdesdk-strigi-analyzer<br />
* kdesdk-umbrello<br />
|Tools for software development<br />
|-<br />
|kdetoys<br />
|kde-meta-kdetoys<br />
|<br />
* kdetoys-amor<br />
* kdetoys-kteatime<br />
* kdetoys-ktux<br />
* kdetoys-kweather<br />
|Fun distractions<br />
|-<br />
|kdeutils<br />
|kde-meta-kdeutils<br />
|<br />
* kdeutils-ark<br />
* kdeutils-kcalc<br />
* kdeutils-kcharselect<br />
* kdeutils-kdelirc<br />
* kdeutils-kdessh<br />
* kdeutils-kdf<br />
* kdeutils-kfloppy<br />
* kdeutils-kgpg<br />
* kdeutils-ktimer<br />
* kdeutils-kwallet<br />
* kdeutils-okteta<br />
* kdeutils-printer-applet<br />
* kdeutils-superkaramba<br />
* kdeutils-sweeper<br />
|Miscellaneous utilities<br />
|-<br />
|kdewebdev<br />
|kde-meta-kdewebdev<br />
|<br />
* kdewebdev-kfilereplace<br />
* kdewebdev-kimagemapeditor<br />
* kdewebdev-klinkstatus<br />
* kdewebdev-kommander<br />
* kdewebdev-kxsldbg<br />
|Web development tool suite<br />
|}</div>
Daenyth
https://wiki.archlinux.org/index.php?title=Creating_packages&diff=85289
Creating packages
2009-11-26T12:22:35Z
<p>Daenyth: Added some {{Filename}} and {{Codeline}}</p>
<hr />
<div>[[Category:About Arch (English)]]<br />
[[Category:Package development (English)]]<br />
[[Category:Guidelines (English)]]<br />
{{Article summary start}}<br />
{{Article summary text|A detailed HOWTO covering the entire package building process.}}<br />
{{Article summary heading|Available in languages}}<br />
{{i18n entry|English|Building Packages in Arch Linux}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|ABS - The Arch Build System}}<br />
{{Article summary wiki|Arch Linux User-Community Repository (AUR)}}<br />
{{Article summary wiki|makepkg}}<br />
{{Article summary wiki|pacman}}<br />
{{Article summary wiki|PKGBUILD Tricks}}<br />
{{Article summary wiki|PKGBUILD Variables}}<br />
{{Article summary wiki|VCS PKGBUILD guidelines}}<br />
{{Article summary end}}<br />
<br />
All information for creating a package is placed in a {{Filename|PKGBUILD}} file. When you run {{Codeline|makepkg}}, it will look for a {{Filename|PKGBUILD}} file in the current working directory, and compile the software's source code according to the instructions in the {{Filename|PKGBUILD}} file. After successfully finishing the compilation, the resulting binaries, as well as all available meta-information like package version and dependencies, are packed in the {{Filename|name.pkg.tar.gz}} package file that can be cleanly installed with {{Codeline|pacman -U <package file>}}.<br />
<br />
== Setting up ==<br />
<br />
First, verify that you have the necessary tools installed. You need the following packages:<br />
*'''base-devel''' (a package group): Contains ''make'' and additional tools for compiling from the source.<br />
*'''fakeroot''' (part of 'base-devel'): Allows a normal user the necessary root permissions to create packages in the build environment without being able to alter the wider system. If the build process attempts to alter files outside of the build environment, errors are produced and the build fails. This is very useful for checking the quality, safety and integrity of the packages for distribution.<br />
<br />
If you do not have them, install them using ''pacman'':<br />
# pacman -S base-devel fakeroot<br />
<br />
One of the key tools for building packages is ''makepkg''. It does the following:<br />
#Checks if package dependencies are installed.<br />
#Downloads the source file(s) from the specified server(s).<br />
#Unpacks the source file(s).<br />
#Compiles the software and installs it under a fakeroot environment.<br />
#Strips symbols from binaries and libraries.<br />
#Generates the package meta file which is included with each package.<br />
#Compress the fakeroot environment into a package file.<br />
#Stores the package file in the configured destination directory, which is the present working directory by default.<br />
<br />
=== ABS ===<br />
<br />
If you want to rebuild binary packages from the official Arch Linux repositories, you should also install the [[Arch Build System]], ''abs'':<br />
# pacman -S abs<br />
<br />
The ''abs'' package will install all of the PKGBUILDs and local source files used to build the official packages. You do not need ''abs'' to use ''makepkg'' and if you only need a few PKGBUILDs, you can retrieve the latest versions from the web interface directly or via other available tools such as [http://xyne.archlinux.ca/info/pbget pbget]<br />
<br />
''abs'' also helps you keep all of your ''PKGBUILD'' files, both official and unofficial in a centralized location. You can specify which repositories to include in your ABS tree in the {{Filename|/etc/abs.conf}} file. To obtain the ABS tree which contains all of the ''PKGBUILD'' files, just run the ''abs'' command as root:<br />
# abs<br />
Create an ABS build directory under the {{Filename|/home}} of your non-root user, if you have not done so already: <br />
$ mkdir ~/abs<br />
<br />
== Package file ==<br />
<br />
An Arch package is, in fact, no more than a gzipped tar archive or 'tarball' which contains:<br />
<br />
* The files to install<br />
<br />
*.PKGINFO: contains all the metadata needed by pacman to deal with packages, dependencies, etc.<br />
<br />
*.INSTALL: a file used to execute commands after the install/upgrade/remove stage. (This file is present only if specified in the PKGBUILD.)<br />
<br />
*.Changelog: A file kept by the package maintainer documenting the changes of the package. It is not present in all packages.<br />
<br />
== Preparing the files ==<br />
<br />
Download the source tarball of the software you want to package, extract it, and note all commands needed to compile and install it. You will be repeating the same commands in the ''PKGBUILD'' file. Most software authors stick to the 3-step build cycle:<br />
./configure<br />
make<br />
make install<br />
When you run {{Codeline|makepkg}}, it will look for a {{Filename|PKGBUILD}} file in the present working directory. If a {{Filename|PKGBUILD}} file is found it will download the software's source code and compile it according to the instructions specified in the {{Filename|PKGBUILD}} file. The instructions must be fully interpretable by [[Wikipedia:Bash|Bash]]. After successful compilation, the resulting binaries and metadata of the package, i.e. package version and dependencies, are packed in a {{Filename|pkgname.pkg.tar.gz}} package file that can be cleanly installed with {{Codeline|pacman -U [package file]}}.<br />
To start out with a new package, you should first create an empty working directory, preferably named {{Filename|~/abs/'''pkgname'''}}. Once you make the directory and change into it, create a {{Filename|PKGBUILD}} file to work with either by copying the prototype from {{Filename|/usr/share/pacman/PKGBUILD.proto}} or by copying a {{Filename|PKGBUILD}} from another package. The latter is quite useful if you want to modify compilation options of a package instead of creating an entirely new one.<br />
<br />
== Defining PKGBUILD variables ==<br />
<br />
The {{Filename|PKGBUILD}} file contains metadata about a package. It is a plain text file. The following is a prototype PKGBUILD. It can be found in {{Filename|/usr/share/pacman}} along with other templates.<br />
<br />
<pre><br />
# This is an example PKGBUILD file. Use this as a start to creating your own,<br />
# and remove these comments. For more information, see 'man PKGBUILD'.<br />
# Note: Please fill out the license field for your package. If it is unknown,<br />
# then please put 'unknown'.<br />
<br />
# Contributor: Your Name <youremail@domain.com><br />
pkgname=NAME<br />
pkgver=VERSION<br />
pkgrel=1<br />
pkgdesc=""<br />
arch=()<br />
url=""<br />
license=('GPL')<br />
groups=()<br />
depends=()<br />
makedepends=()<br />
provides=()<br />
conflicts=()<br />
replaces=()<br />
backup=()<br />
install=<br />
source=($pkgname-$pkgver.tar.gz)<br />
noextract=()<br />
md5sums=() #generate with 'makepkg -g'<br />
<br />
build() {<br />
cd "$srcdir/$pkgname-$pkgver"<br />
<br />
./configure --prefix=/usr<br />
make || return 1<br />
make DESTDIR="$pkgdir/" install<br />
}<br />
</pre><br />
<br />
A listing of possible PKGBUILD variables and their meaning can be found on [[PKGBUILD Variables]] page.<br />
<br />
== The build() function ==<br />
<br />
Now you need to implement the ''build()'' function in the ''PKGBUILD'' file. This function uses common shell commands in the [http://en.wikipedia.org/wiki/Bash Bash] syntax to automatically compile software and create a ''pkg/'' directory to install the software to. This allows ''makepkg'' to pack it up without having to pick all the necessary files from your actual filesystem.<br />
The first step in the ''build()'' function is to change into the directory created by uncompressing the source tarball. In most common cases the first command will look like this:<br />
cd $srcdir/$pkgname-$pkgver<br />
<br />
Now, you need to list the same commands you used when you manually compiled the software. The ''build()'' function in essence automates everything you did by hand and compiles the software in the fakeroot build environment. If the software you are packaging uses a configure script, it is good practice to use ''--prefix=/usr'' when building packages for ''pacman''. A lot of software install their files relative to the ''/usr/local'' directory, which should only be done if you are manually building from source. All Arch Linux packages should use the ''/usr'' directory. As seen in the ''/usr/share/pacman/PKGBUILD.proto'' file, the next two lines should look like this:<br />
./configure --prefix=/usr<br />
make || return 1<br />
<br />
The final step in the ''build()'' funciton is to put the compiled files in a directory where ''makepkg'' can retrieve to create a package. This by default is the ''pkg/'' directory - a simple fakeroot environment. It imitates the root of your filesystem to the software's installation procedure. If you have to manually install files under the root of your filesystem, you should instead install it in the ''pkg/'' directory under the same directory structure, e.g. if you want to install a file to ''/usr/bin'', it should instead be placed under ''$pkgdir/usr/bin''. Very few software require the user to copy dozens of files manually, and you usually will not have to worry about this. Instead, for most software you will have to call ''make install''. The final line should look like the following in order to correctly install the software in the ''pkg/'' directory:<br />
make DESTDIR=$pkgdir install || return 1<br />
<br />
'''Note''': It is sometimes the case where <code>DESTDIR</code> is not used in the <code>Makefile</code>; you may need to use <code>prefix</code> instead. If the package is built with autoconf/automake, use <code>DESTDIR</code>; this is what is [http://sources.redhat.com/automake/automake.html#Install documented] in the manuals. If <code>DESTDIR</code> does not work, try building with <code>make prefix="$pkgdir/usr/" install</code>. If that does not work, you'll have to look further into the install commands that are executed by "<code>make <...> install</code>".<br />
<br />
In some odd cases, the software expects to be run from a single directory. In such cases it is wise to simply copy these to ''$pkgdir/opt''.<br />
More often than not the installation process of the software will create any subdirectories below the ''pkg/'' directory. If it does not, however, ''makepkg'' will generate a lot of errors and you will need to manually create subdirectories by adding the appropriate ''mkdir -p'' commands in the ''build()'' function before the installation procedure is run.<br />
Also, ''makepkg'' defines three variables that you should use as part of the build and install process:<br />
*'''''startdir''''' - This contains the absolute path to the directory where the ''PKGBUILD'' file is located, which is the present working directory. This variable is almost always used in combination with ''/src'' or ''/pkg'' postfixes, but the use of ''srcdir'' and ''pkgdir'' variables is preferred.<br />
*'''''srcdir''''' - This points to the directory where ''makepkg'' extracts or copies all source files. It is currently an alias for ''$startdir/src''.<br />
*'''''pkgdir''''' - This points to the directory where ''makepkg'' bundles the installed package, which becomes the root directory of your built package. It is currently an alias for ''$startdir/pkg''.<br />
<br />
'''Note:''' makepkg, and thus the build() function, is intended to be non-interactive. Interactive utilities or scripts called in the build() function may break makepkg, particularly if it is invoked with build-logging enabled (-l). (see [http://bugs.archlinux.org/task/13214 Arch Linux Bug #13214].)<br />
<br />
== Additional guidelines ==<br />
<br />
Here are some additional guidelines that you should adhere to:<br />
*All elements in an array variable '''must be separated by spaces'''.<br />
*If possible, remove empty lines from the ''PKGBUILD'' including fields that have empty values.<br />
*Wherever possible, use ''|| return 1'' for critical build functions: make || return 1 make DESTDIR=$pkgdir install || return 1 <br />
*'''Do not introduce new variables''' into your ''PKGBUILD'' file 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''': _customvariable= <br />
*'''Avoid''' using ''/usr/libexec/'' for anything. Use ''/usr/lib/pkgname'' instead.<br />
*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="Your Name &lt;email@domain.com&gt;" <br />
* '''Configuration files''' should be placed in the ''/etc'' directory. If there is more than one configuration file, it is customary to use a subdirectory in order to keep the ''/etc'' area as clean as possible. Use ''/etc/'''pkgname''''' or a suitable alternative, e.g., [http://httpd.apache.org/ Apache] uses ''/etc/httpd/''. <br />
*Package files should follow these '''general directory guidelines''': <br />
**''/etc/'' - System essential configuration files<br />
**''/usr/bin'' - Application binaries<br />
**''/usr/sbin'' - System binaries<br />
**''/usr/lib'' - Libraries<br />
**''/usr/include'' - Header files<br />
**''/usr/lib/pkgname'' - Modules, plugins, etc.<br />
**''/usr/share/man'' - Manpages<br />
**''/usr/share/pkgname'' - Application data<br />
**''/usr/share/licenses/pkgname'' - Package license, if not included under common<br />
**''/etc/pkgname'' - Configuration files<br />
**''/opt'' - Large self-contained packages such as Java, etc.<br />
<br />
*Packages should not contain the following directories: <br />
**''/dev''<br />
**''/home''<br />
**''/media''<br />
**''/mnt''<br />
**''/proc''<br />
**''/root''<br />
**''/selinux''<br />
**''/sys''<br />
**''/tmp''<br />
**''/var/tmp''<br />
<br />
== Testing the PKGBUILD ==<br />
<br />
As you are writing the ''build()'' function, you will want to test your changes frequently to ensure there are no bugs. You can do this using the ''makepkg'' command in the directory containing the ''PKGBUILD'' file. With a properly formatted ''PKGBUILD'', this will create a package, but with a broken or unfinished one it will throw an error.<br />
If ''makepkg'' finishes successfully, it will place a file named ''pkgname-pkgver.pkg.tar.gz'' in your working directory. This is package that can be installed with the ''pacman -U'' command. However, just because a package file was built does not imply that it is fully functional. It might conceivably contain only the directory and no files whatsoever if, for example, a prefix was specified improperly. You can use ''pacman'''s query functions to display a list of files contained in the package and the dependencies it requires with ''pacman -Qlp [package file]'' and ''pacman -Qip [package file]'' respectively.<br />
If the package looks sane, then you are done! However, if you plan on release the ''PKGBUILD'' file, it is imperative that you check and double check the contents of the ''depends'' array. <br />
<br />
== {{Codeline|ldd}} and {{Codeline|namcap}} ==<br />
<br />
Dependencies are the most common packaging error. There are two excellent tools you can use to check dependencies. The first one is ''ldd'', which will show you the shared library dependencies of dynamic executables:<br />
$ ldd gcc<br />
linux-gate.so.1 => (0xb7f33000)<br />
libc.so.6 => /lib/libc.so.6 (0xb7de0000)<br />
/lib/ld-linux.so.2 (0xb7f34000)<br />
<br />
The other tool is ''namcap'' which not only checks for dependencies but the overall sanity of your package. It can be used on both the ''PKGBUILD'' file to check for things like missing tags or variables, and the ''pkg.tar.gz'' packages to verify dependencies or permissions. You can install ''namcap'' via ''pacman'':<br />
$ pacman -S namcap<br />
<br />
To check a PKGBUILD file with ''namcap'', simply supply a ''PKGBUILD'' file as the argument:<br />
$ namcap PKGBUILD<br />
Similarly, to check a package do:<br />
$ namcap pkgname.tar.gz<br />
<br />
Although ''namcap'' can help detect dependencies, it is not always correct. Verify dependencies by looking at the documentation of the software.<br />
<br />
=== Testing the package ===<br />
<br />
Also make sure that the package binaries actually ''run'' flawlessly! It's really annoying to release a package that contains all necessary files, but dumps core because of some obscure configuration option that doesn't quite work well with the rest of the system. If you're only going to compile packages for your own system, though, you don't need to worry too much about this quality assurance step, as you're the only person suffering from mistakes after all.<br />
<br />
== Submitting packages to the AUR ==<br />
<br />
Follow these steps to submit a package into the AUR:<br />
#Register a new account if you do not already have one.<br />
#Check all of the official repositories (''[core]'', ''[extra]'', and ''[community]'') and see if the package already exists. If it is inside any of those repositories, '''DO NOT''' submit the package. If the package is broken, file a bug report.<br />
#Check the ''[unsupported]'' repository for the package. If it is currently maintained, changes can be submitted in a comment for the maintaner's attention. If it is unmaintained, the package can be adopted and updated.<br />
#To upload the package to the AUR, the directory containing the ''PKGBUILD'' file and any other required files must be compressed as a tarball. The archive name should contain the name of the package, e.g. ''foo.tar.gz.''. You can easily build a tarball by using ''makepkg --source'' in the directory. This makes a tarball named ''pkgname-pkver-pkrel.src.tar.gz'', which you can then upload to the AUR. The tarball '''cannot''' contain the binary tarball created by ''makepkg'' or the source tarball of the software. Packages that contain binaries or that are very poorly written will be deleted without warning.<br />
#Click the '''Submit''' link by the menu in the AUR. Choose the appropriate category for your package and upload.<br />
<br />
== Summary ==<br />
#Download the source tarball of the software you want to package.<br />
#Try compiling the package and installing it into an arbitrary directory.<br />
#Copy over the prototype ''/usr/share/pacman/PKGBUILD.proto'' and rename it to ''PKGBUILD'' in a temporary working directory - preferably ''~/abs/''.<br />
#Edit the ''PKGBUILD'' according to the needs of your package.<br />
#Run ''makepkg'' and see whether the resulting package is built correctly.<br />
#If not, repeat the last two steps.<br />
<br />
=== Warnings ===<br />
* Before you can automate the package building process, you should have done it manually at least once unless you know ''exactly'' what you're doing ''in advance'', in which case you would not be reading this in the first place. Unfortunately, although a good bunch of program authors stick to the 3-step build cycle of "./configure; make; make install", this is not always the case, and things can get real ugly if you have to apply patches to make everything work at all. Rule of thumb: If you can't get the program to compile from the source tarball, and make it install itself to a defined, temporary subdirectory, you don't even need to try packaging it. There isn't any magic pixie dust in <code>makepkg</code> that makes source problems go away.<br />
* In a few cases, the packages are not even available as source and you have to use something like <code>sh installer.run</code> to get it to work. You will have to do quite a bit of research (read READMEs, INSTALL instructions, man pages, perhaps ebuilds from gentoo or other package installers, possibly even the MAKEFILEs or source code) to get it working. In some really bad cases, you have to edit the source files to get it to work at all. However, <code>makepkg</code> needs to be completely autonomous, with no user input. Therefore if you need to edit the Makefiles, you may have to bundle a custom patch with the <code>PKGBUILD</code> and install it from inside the <code>build()</code> function, or you might have to issue some <code>sed</code> commands from inside the <code>build()</code> function.</div>
Daenyth