Beginners' Guide/Installation (한국어)

From ArchWiki
Revision as of 18:07, 19 March 2012 by Kynikos (Talk | contribs) (fix template)

Jump to: navigation, search

This template has only maintenance purposes. For linking to local translations please use interlanguage links, see Help:i18n#Interlanguage links.


Local languages: Català – Dansk – English – Español – Esperanto – Hrvatski – Indonesia – Italiano – Lietuviškai – Magyar – Nederlands – Norsk Bokmål – Polski – Português – Slovenský – Česky – Ελληνικά – Български – Русский – Српски – Українська – עברית – العربية – ไทย – 日本語 – 正體中文 – 简体中文 – 한국어


External languages (all articles in these languages should be moved to the external wiki): Deutsch – Français – Română – Suomi – Svenska – Tiếng Việt – Türkçe – فارسی

Tip: This is part of a multi-page article for The Beginners' Guide. Click here if you would rather read the guide in its entirety.

설치하기

Note: 만약 여러분이 HTTP나 FTP 프록시를 통해 인터넷을 접속하고 네트워크 인터페이스를 설정하기 위해 DHCP를 사용하고 있다면, 여러분은 /arch/setup을 실행시키기 전에 아래에 표시된 것처럼 http_proxyftp_proxy의 환경변수를 설정해줘야만 할지 모릅니다.
export http_proxy=http://<http_proxy_address>:<proxy_port>
export ftp_proxy=ftp://<ftp_proxy_address>:<proxy_port>

root 권한으로, tty1에서 설치도구 스크립트를 실행시킵니다:

# /arch/setup

여러분은 화면으로 아치리눅스 프레임워크 스크린을 보게 될 것입니다.

설치할 소스 선택하기

여러분을 환영한다는 첫 화면 이후, 여러분은 곧바로 설치할 소스를 선택하게 될 것입니다.

소스를 선택하는 화면은 여러분에게 여러분이 사용하고 싶은 리포지토리를 선택할 것인지 묻을 것입니다.

넷인스톨
만약 넷인스톨 이미지를 사용한다면, 여러분은 단지 remote 리포지토리만을 사용할 수 있을 것입니다.
코어
만약 코어 설치도구를 사용하고 CD에서 패키지를 사용한다면, core-local을 선택하십시오.
Warning: 여러분은 다른 remote 리포지토리도 선택할 수 있습니다만, 설치도구의 메세지를 기억하십시오: "만약 여러분이 하고 있는 일이 무엇인지 알고 있다면(이것은 패키지를 망가트릴 것입니다) 로컬 리포지토리와 원격의 미러 리포지토리를 함께 사용하지 마십시오!"

만약 여러분이 무엇을 사용해야 할 지 모르겠다면, 'core'에 추가로 'extra'와 community를 선택하십시오. 만약 여러분이 64비트 아치리눅스를 설치하고 있다면, 여러분은 또한 'multilib'도 원할지도 모릅니다.그러나 이런 셋팅들은 실치 과정 후반에 설치중인 시스템을 위해 만들어질 것입니다.

Warning: 만약 여러분이 리포지토리를 테스트하고 있다면, 여러분은 arch-dev-public 메일링리스트를 읽고 있을지도 모르겠습니다.여러분은 어떻게 패키지 다운그레이드를 하는지와 문제점을 고치기 위해 아치리눅스 설치에서 어떻게 권한변경을 해야하는지 반드시 알아야 합니다.

Setup network

Note: ftp.archlinux.org is throttled to 50KB/s.

You will be given a list to select an additional FTP or HTTP mirror.

Tip: To achieve the best download speed possible, you should choose mirrors that preferably reside in your country, and are hosted by hosting providers you know to be reliable (eg. universities). Relative speed and update status of source repository mirrors may be checked here.

If you chose core-local as well as remote repositories, you will now be given the choice either to consult remote sources only for packages unavailable locally, or the converse.

At the next screen, select Yes to set up the network. 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 pressing Template:Keypress and invoking ip addr. When done, return to tty1 by pressing Template:Keypress.

Available interfaces will be presented. If an interface and HWaddr (HardWare address) 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. Select your interface to continue.

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 address, netmask, broadcast (optional), gateway, DNS server, HTTP proxy (optional), and FTP proxy (optional).

Afterwards, you will be returned to the Main Menu

Setup ADSL bridging in the live environment (optional)

(If you have a modem or router in bridge mode to connect to your ISP)

Switch to another virtual console (Template:Keypress), login as root and invoke:

# pppoe-setup

If everything is well configured in the end you can connect to your ISP with:

# pppoe-start

Return to first virtual console (Template:Keypress) and continue with Set editor.

Setup wireless in the live environment (optional)

(If you need wireless connectivity during the installation process)

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 quick-start procedure executed at this point in the installation will initialize your wireless hardware for use in the live environment of the installation media. These steps (or some other form of wireless management) must be repeated from the actual installed system after booting into it.

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.

Note: The following examples use wlan0 for the interface and linksys for the ESSID. Remember to change these values according to your setup.

The basic procedure will be:

  • Switch to a free virtual console, e.g.: Template:Keypress
  • Login as root
  • (optional) Identify the wireless interface:
# lspci | grep -i net
  • Ensure udev has loaded the driver, and that the driver has created a usable wireless kernel interface with /usr/sbin/iwconfig:
# iwconfig
 lo no wireless extensions.
 eth0 no wireless extensions.
 wlan0    unassociated  ESSID:""
          Mode:Managed  Channel=0  Access Point: Not-Associated
          Bit Rate:0 kb/s   Tx-Power=20 dBm   Sensitivity=8/0
          Retry limit:7   RTS thr:off   Fragment thr:off
          Power Management:off
          Link Quality:0  Signal level:0  Noise level:0
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

wlan0 is the available wireless interface in this example.

Note: If you do not see output similar to this, then your wireless driver has not been loaded. If this is the case, you must load the driver yourself. Please see Wireless Setup for more detailed information.
  • Bring the interface up with:
# ip link set wlan0 up

A small percentage of wireless chipsets also require firmware, in addition to a corresponding driver. If the wireless chipset requires firmware, you are likely to receive this error when bringing the interface up:

# ip link set wlan0 up
SIOCSIFFLAGS: No such file or directory

If unsure, invoke /usr/bin/dmesg to query the kernel log for a firmware request from the wireless chipset. Example output from an Intel chipset which requires and has requested firmware from the kernel at boot:

$ dmesg | grep firmware
firmware: requesting iwlwifi-5000-1.ucode

If there is no output, it may be concluded that the system's wireless chipset does not require firmware.

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 later in this guide. 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.
  • If the ESSID has been forgotten or is unknown, use /sbin/iwlist <interface> scan to scan for nearby networks:
# iwlist wlan0 scan
Cell 01 - Address: 04:25:10:6B:7F:9D
                    Channel:2
                    Frequency:2.417 GHz (Channel 2)
                    Quality=31/70  Signal level=-79 dBm  
                    Encryption key:off
                    ESSID:"dlink"
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
                    Bit Rates:6 Mb/s; 9 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s
                              36 Mb/s; 48 Mb/s; 54 Mb/s
  • If using WPA encryption:

Using WPA encryption requires that the key be encrypted and stored in a file, along with the ESSID, to be used later for connection via wpa_supplicant. Thus, a few extra steps are required:

For the purpose of simplifying and backup, rename the default wpa_supplicant.conf file:

# mv /etc/wpa_supplicant.conf /etc/wpa_supplicant.conf.original

Using wpa_passphrase, provide your wireless network name and WPA key to be encrypted and written to /etc/wpa_supplicant.conf.

The following example encrypts the key "my_secret_passkey" of the "linksys" wireless network, generates a new configuration file (/etc/wpa_supplicant.conf), and subsequently redirects the encrypted key, writing it to the file:

# wpa_passphrase linksys "my_secret_passkey" > /etc/wpa_supplicant.conf
Note: If the above fails with a bash: event not found error, it may be due to special characters (e.g. !) used in your wireless network name. In that case try the following:
# sh -c 'wpa_passphrase linksys "my_secret_passkey" > /etc/wpa_supplicant.conf'

Check WPA Supplicant for more information and troubleshooting.

Note: /etc/wpa_supplicant.conf is stored in plain text format. This is not risky in the installation environment, but when you reboot into your new system and reconfigure WPA, remember to change the permissions on /etc/wpa_supplicant.conf (e.g. chmod 0600 /etc/wpa_supplicant.conf to make it readable by root only).
  • Associate your wireless device with the access point you want to use. Depending on the encryption (none, WEP, or WPA), the procedure may differ. You need to know the name of the chosen wireless network (ESSID).
Encryption Command
No Encryption iwconfig wlan0 essid "linksys"
WEP w/ Hex Key iwconfig wlan0 essid "linksys" key "0241baf34c"
WEP w/ ASCII passphrase iwconfig wlan0 essid "linksys" key "s:pass1"
WPA wpa_supplicant -B -Dwext -i wlan0 -c /etc/wpa_supplicant.conf
Note: The network connection process may be automated later by using the default Arch network daemon, netcfg, wicd, or another network manager of your choice.
  • After utilizing the appropriate association method outlined above, wait a few moments and confirm you have successfully associated to the access point before continuing, e.g.:
# iwconfig wlan0

Output should indicate the wireless network is associated with the interface.

  • Request an IP address with /sbin/dhcpcd <interface>, e.g.:
# dhcpcd wlan0
  • Lastly, ensure you can route using /bin/ping:
# ping -c 3 www.google.com
PING www.l.google.com (74.125.224.146) 56(84) bytes of data.
64 bytes from 74.125.224.146: icmp_req=1 ttl=49 time=87.7 ms
64 bytes from 74.125.224.146: icmp_req=2 ttl=49 time=87.0 ms
64 bytes from 74.125.224.146: icmp_req=3 ttl=49 time=94.6 ms

--- www.l.google.com ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2002ms
rtt min/avg/max/mdev = 87.052/89.812/94.634/3.430 ms

Hopefully you should have a working network connection. For troubleshooting, check the detailed Wireless Setup page.

Return to tty1 with (Template:Keypress) and continue with Set editor.

에디터 정하기

이제 여러분은 설정 파일을 수정하기 위해 사용고 싶은 에디터를 정하게 될 것입니다.선택지는 nano 혹은 vi입니다. nano는 그 작동상태가 그래픽 워드프로세서를 닮았고 보다 직관적이기 때문에 일반적으로 초심자들에게 더 쉽다고 알려져있습니다. 예를 들어, 키보드의 화살표, 백스페이스, 그리고 딜리트 키는 예상대로 작동합니다. 대부분의 공통 명령어를 위한 메뉴(예를 들면, 잘라내기는 Template:Keypress, 붙여넣기는 Template:Keypress, 종료는 Template:Keypress)는 nano 터미널 화면의 아래쪽에 보입니다. 보다 세세한 내용은 wiki 페이지 NanoVi를 읽어주시기 바랍니다.

Set clock

지역과 표준시간대 정하기

위아래 화살표 키를 사용하거나 첫 글자를 쳐서 색션 이동을 해서 여러분의 지역과 표준시간대를 선택한 다음, 엔터키를 눌러주세요.

시간과 날짜 정하기

Set the hardware clock mode. If this does not match the setting of your other operating systems, they will overwrite the time and cause clock shifts (which can cause time drift correction to be miscalibrated).

  • UTC (recommended)
Note: Using UTC for the hardware clock does not mean time will be displayed in UTC in software.
  • localtime (discouraged) - Used by default in Windows. If time is set to localtime, DST shifts will not be made by Linux.
Warning: Using localtime may lead to several known and unfixable bugs. However, there are no plans to drop support for localtime.
Note: Any other value will result in the hardware clock being left untouched (useful for virtualization).
윈도우즈와 듀얼 부팅 설치에서 시간 정하기

If you are setting up a dual-boot with Windows on your system, you have two options:

  • Recommended: Set Arch Linux to UTC and make Windows use UTC too (a quick registry fix is needed, see this page for instructions). Also, be sure to prevent Windows from synchronizing the time with the Internet, as it will make the hardware clock use localtime again. If you want such functionality (NTP sync), you should use ntpd on your Arch Linux installation instead.
  • Not recommended: Set Arch Linux to localtime and later (in Configure the system) remove hwclock from the DAEMONS array in /etc/rc.conf (Windows will take care of hardware clock corrections).

Prepare hard drive

Warning: Partitioning hard drives can destroy data. You are strongly cautioned and advised to backup your critical data if applicable.
Note: Partitioning may be performed before initiating the Arch installation if desired, by utilizing GParted or other available tools. If the installation drive has already been partitioned to the required specifications, continue with #Option 3: Manually configure block devices, filesystems and mountpoints.

Verify current disk identities and layout by invoking /sbin/fdisk with the -l (lower-case L) switch.

Open another virtual console (Template:Keypress) and enter:

# fdisk -l

Take note of the disk(s) and/or partition(s) to utilize for the Arch installation.

Switch back to the installation script with Template:Keypress.

Select the menu entry "Prepare Hard Drive". A list of four options is presented:

This will erase the ENTIRE hard drive and set up partitions automatically. Some customization is available.

Recommended. This option uses the cfdisk utility and allows for the most robust and customized partitioning. After the partitions are setup, proceed to Option 3.

You can skip directly to this option if the hard drive has already been partitioned to your liking. Option 3 is also the next step of disk preparation that follows Option 2. The system will list what filesystems and mountpoints it has found and ask you if you wish to use them. You will be given a choice to select the desired method of identification, i.e. by dev, label, or uuid.

  • Option 4: Rollback last filesystem changes

Reverts back to previous set of changes.

Options 1, 2, and 3 are explained in more detail below. To understand what is involved in these options, a short discussion on Linux partitions and filesystems is presented next. Advanced GNU/Linux users who are familiar and comfortable with manual partitioning may wish to skip down to Select packages below.

Note: If you are installing to a USB flash key, see Installing Arch Linux on a USB key.

Partitioning hard disks: General information

Partition type

Partitioning a hard disk drive defines specific memory storage areas. These are called partitions. Each partition behaves as a separate disk and is formatted with a specific filesystem type (see below).

There are 3 types of disk partitions:

  • Primary
  • Extended
    • Logical

Primary partitions can be bootable and are limited to four partitions per disk or RAID volume. If a partitioning scheme requires more than four partitions, an extended partition containing logical partitions is used. Extended partitions can be thought of as containers for logical partitions. A hard disk can contain no more than one extended partition. The extended partition is also counted as a primary partition so if the disk has an extended partition, only three additional primary partitions are possible (i.e. three primary partitions and one extended partition). The number of logical partitions residing in an extended partition is unlimited. A system that dual boots with Windows will require that Windows reside in a primary partition.

The customary numbering scheme is to create primary partitions sda1 through sda3 followed by an extended partition sda4. The logical partitions on sda4 are numbered sda5, sda6, etc.

Swap partition

A swap partition is a place on the drive for virtual RAM. This allows the kernel to access disk space for data that does not fit into physical RAM.

Historically, the general rule for swap partition size was to allocate twice the amount of physical RAM. As computers have gained ever larger memory capacities, this rule has become deprecated. On machines with up to 512MB RAM, the 2x rule is usually adequate. If a sufficient amount of RAM (more than 1024MB) is available, it may be possible to have a smaller swap partition or even eliminate it. With more than 2 GB of physical RAM, one can generally expect good performance without a swap partition. There is always an option to create a swap file after the system is setup.

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.
Selecting a partitioning scheme

There are no strict rules for partitioning a hard drive, although one may follow the general guidance given below. A disk partitioning scheme is determined by various issues such as desired flexibility, speed, security, as well as the limitations imposed by available disk space. It is essentially personal preference. Two simple possibilities are: i) one partition for root and one partition for swap or ii) just a single root partition without swap. Read through the following discussion and examples to understand the benefits and tradeoffs in making the decision. If you would like to dual boot Arch Linux and a Windows operating system please see Windows and Arch Dual Boot.

The following mountpoints are possible choices for separate partitions:

/ (root)
The root directory is the top of the hierarchy, the point where the primary filesystem is mounted and from which all other filesystems stem. All files and directories appear under the root directory /, even if they are stored on different physical devices. The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Therefore, certain directories under / are not candidates for separate partitions (See warning below).
/boot
This directory contains the kernel and ramdisk images as well as the bootloader configuration file and bootloader stages. It also stores data that is used before the kernel begins executing user-space programs. This may include saved master boot sectors and sector map files. This directory is essential for booting, but is unique in that it may still be kept on its own optional partition.
Warning: In addition to /boot, the directories essential for booting are: /bin, /etc, /lib, and /sbin. Unlike /boot, these directories cannot reside in separate partitions and must be on /.
/home
Provides subdirectories for each system user. It holds miscellaneous personal data as well as user-specific configuration files for applications.
/tmp
Directory for programs that require temporary storage of files such as .lck , which can be used to prevent multiple instances of their respective program until a task is completed. Upon completion, the .lck file will be automatically removed. Programs must not assume that any files or directories in /tmp are preserved between invocations of the program and files and directories located under /tmp will typically be deleted whenever the system is booted.
/var
Contains variable data such as spool directories and files, administrative and logging data, pacman's cache, the ABS tree, etc. It exists to make it possible to mount /usr as read-only. Everything that historically went into /usr that is written to during system operation (as opposed to installation and software maintenance) must reside under /var.
Note: /var contains many small files. The choice of filesystem type (see below) should consider this fact if a separate partition is used.

There are several advantages for using discrete filesystems as opposed to placing everything in one partition:

  • Security: Each filesystem may be configured in /etc/fstab as 'nosuid', 'nodev', 'noexec', 'readonly', etc.
  • Stability: A user, or malfunctioning program can completely fill a filesystem with garbage if they have write permissions for it. Critical programs residing on a different filesystem remain unaffected.
  • Speed: A filesystem that gets re-written too frequently may become fragmented. Separate filesystems remain unaffected and each can be defragmented separately. Fragmentation can be avoided by ensuring that each filesystem is never in danger of filling up completely.
  • Integrity: If one filesystem becomes corrupted, separate filesystems remain unharmed.
  • 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.
How big should my partitions be?

The size of the partitions depends on personal preference, but the following information may be helpful:

  • The root filesystem (/) will contain the /usr directory, which can grow significantly depending upon how much software is installed. 15-20 GB should be sufficient for most users with modern hard disks.
  • The /var filesystem will contain, among other data, the ABS tree and the pacman cache. Keeping cached packages is useful and versatile as it provides the ability to downgrade. As a result, /var tends to grow in size. The pacman cache in particular will grow as the system is expanded and updated. It can, however, be safely cleared if space becomes an issue. 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. 8-12 GB on a desktop system should be sufficient for /var, depending on how much software will be installed. Servers tend to have relatively larger /var filesystems.
  • 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. If it becomes necessary to reinstall Arch, all the data on your /home partition will be retained if it is setup on its own partition.
  • A /boot partition requires only about 100MB.
  • If available, an extra 25% of space added to each filesystem will provide a cushion for future expansion and help protect against fragmentation.

Creating filesystems: General information

Filesystem types

Individual drive partitions can be setup using one of the many different available filesystems. Each has its own advantages, disadvantages, and unique idiosyncrasies. A brief overview of supported filesystems follows; the links are to wikipedia pages that provide much more information.

  1. ext2 Second Extended Filesystem is an established, mature GNU/Linux filesystem that is very stable. A drawback is that it does not have journaling support (see below) or barriers. Lack of journaling can result in data loss in the event of a power failure or system crash. It may also be inconvenient for root (/) and /home partitions because file-system checks can take a long time. An ext2 filesystem can be converted to ext3.
  2. ext3 Third Extended Filesystem is essentially the ext2 system with journaling support and write barriers. It is backward compatible with ext2, well tested, and extremely stable.
  3. ext4 Fourth Extended Filesystem is a newer filesystem that is also compatible with ext2 and ext3. It provides support for volumes with sizes up to 1 exabyte (i.e. 1,048,576 terabytes) and files sizes up to 16 terabytes. It increases the 32,000 subdirectory limit in ext3 to 64,000. It also offers online defragmentation capability.
  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 (V3) is not being actively developed at this time. Generally regarded as a good choice for /var.
  5. JFS IBM's Journaled File System was the first filesystem to offer journaling. It had many years of development in the IBM AIX® operating system before being ported to GNU/Linux. JFS makes the smallest demand on CPU resources of any GNU/Linux filesystem. It is very fast at formatting, mounting, and filesystem checks (fsck). JFS offers very good all-around performance especially in conjunction with the deadline I/O scheduler. It is not as widely supported as the ext series or ReiserFS, but still very mature and stable.
  6. XFS is another early journaling filesystem originally developed by Silicon Graphics for the IRIX operating system and ported to GNU/Linux. It provides very fast throughput on large files and filesystems and is very fast at formatting and mounting. Comparative benchmark testing has shown it to be slower when dealing with many small files. XFS is very mature and offers online defragmentation capability.
    Note: The JFS and XFS filesystems cannot be shrunk by disk utilities such as gparted or parted magic.
  7. vfat or Virtual File Allocation Table is technically simple and supported by virtually all existing operating systems. This makes it a useful format for solid-state memory cards and a convenient way to share data between operating systems. VFAT supports long file names.
  8. Btrfs Also known as "Better FS", Btrfs is a new filesystem with powerful features similar to Sun/Oracle's excellent ZFS. These include snapshots, multi-disk striping and mirroring (software RAID without mdadm), checksums, incremental backup, and on-the-fly compression that can give a significant performance boost as well as save space. As of January 2011, Btrfs is considered unstable although it has been merged into the mainline kernel with an experimental status. Btrfs appears to be the future of GNU/Linux filesystems and is offered as a root filesystem option in all major distribution installers.
    Warning: Btrfs has not yet implemented a fsck utility. The filesystem cannot be repaired if corruption occurs.
  9. nilfs2 New Implementation of a Log-structured File System was developed by NTT. It records all data in a continuous log-like format that is only appended to and never overwritten. It is designed to reduce seek times and minimize the type of data loss that occurs after a crash with conventional Linux filesystems.
Journaling

All the above filesystems with the exception of ext2 use journaling. Journaling provides fault-resilience by logging changes before they are committed to the filesystem. In the event of a system crash or power failure, such file systems are faster to bring back online and less likely to become corrupted. The logging takes place in a dedicated area of the filesystem.

Not all journaling techniques are the same. Only ext3 and ext4 offer data-mode journaling, which logs both data and meta-data. Data-mode journaling comes with a speed penalty and is not enabled by default. The other filesystems provide ordered-mode journaling, which only logs meta-data. While all journaling will return a filesystem to a valid state after a crash, data-mode journaling offers the greatest protection against corruption and data loss. There is a compromise in system performance, however, because data-mode journaling does two write operations: first to the journal and then to the disk. The trade-off between system speed and data safety should be a considered when choosing the filesystem type.

Option 1: Auto prepare

Auto-Prepare erases the entire drive and divides it into the following four partitions:

  • A /boot partition formatted ext2. The default size of 100MB can be changed.
  • A /swap partition of default size of 256MB (adjustable).
  • Separate / and /home partitions with adjustable sizes and filesystems. Available filesystems include ext2, ext3, ext4, reiserfs, xfs, jfs, vfat, nilfs2 (experimental), and btrfs (experimental). Both / and /home will have the same filesystem type when using the Auto Prepare option.

Be warned that Auto-Prepare will completely format the entire hard drive. Read the warning presented by the installer very carefully and make sure the correct device is about to be partitioned.

If you do not wish to use the default configuration of Auto prepare, you can setup the partitions manually. This will be necessary if, for example, you are configuring a dual-boot system with an existing Windows partition. Manual partitioning can be accomplished with Option 2 (followed by Option 3) or by using a live media utility such as GParted.

Option 2: Manually partition hard drives

Choosing the target disk will open cfdisk for manual partitioning (if you have an SSD drive other choices like gdisk or GNU Parted may be preferable). Its operation can be understood with an example where four partitions are made on a 160 GB drive for root, var, swap, and home. Following the guidelines above, the example system will contain a 15GB root (/) partition, a 10GB /var partition, a 1GB swap partition, and a /home partition for the remaining disk space. It is emphasized again that partitioning is a personal choice and this example is only for illustration.

Choose New -> 'Primary' and enter the desired size (15.44 GB in this example) for the root (/) filesystem. The partition will be put at the beginning of the disk. Select the Type and designate it as 83 Linux. The created / partition will appear as sda1.

In a similar manner, create a second primary partition of size 10.256 GB for /var, designating it as Type 83 Linux. The created /var partition will appear as sda2.

Next, create a third partition for swap. Select an appropriate size (~1 GB here) and specify the Type as 82 (Linux swap / Solaris). The created swap partition will appear as sda3.

The remaining space is used to create a fourth partition for the /home directory. Identify it as a primary partition and set the size. Select the Type as 83 Linux. The created /home partition will appear as sda4.

This is how the example will look:

Name    Flags     Part Type    FS Type           [Label]         Size (MB)
-------------------------------------------------------------------------
sda1               Primary     Linux                             15440 #root
sda2               Primary     Linux                             10256 #/var
sda3               Primary     Linux swap / Solaris              1024  #swap
sda4               Primary     Linux                             133000 #/home

Choose Write and type yes. Beware that this operation may destroy data on your disk. Choose Quit to leave the partitioner.

Familiarize yourself with the various filesystems discussed above and then proceed to Option 3.

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 sdx naming scheme. This is perfectly normal and should not be a concern.

Option 3: Manually configure block devices, filesystems, and mountpoints

This option requires the presence of existing partitions (generated in Option 2, for example) and is implemented as dev, label, or UUID. The list of recognized partitions will be shown. Each partition is identified with a number suffix. Example: sda1 specifies the first partition of a drive while sda designates the entire drive.

Format each partition with the desired filesystem and specify the mountpoints. You can choose a label and additional options for mkfs.

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.

Select packages

All software packages available during installation are from the [core] repository. They are further divided into base (i686|x86_64), and base-devel (i686|x86_64) groups. Package information and brief descriptions for [core] are available here.

Bootloader

You will be prompted to select either GRUB or syslinux as a bootloader.

Package groups

Now select the package category:

Note: For expedience, all packages in base are selected by default. Use the space-bar to select and de-select packages.
  • base: Software packages from the [core] repo to provide the minimal base environment. Always select this and do not remove any packages from it, as all packages in Arch Linux assume that base is installed.
  • base-devel: Extra tools from [core] such as make, and automake. Most beginners should choose to install it, as it will likely be needed to expand your new system. The base-devel group will be required to install software from the Arch User Repository.

After category selection, you will be presented with lists of available packages, allowing you to fine-tune your selections. Use the space bar to select and un-select. If you are uncertain about which additional packages to install at this point, you can skip this step and add them later using pacman.

Note: If connection to a wireless network is required, remember to select and install the wireless_tools package. Some wireless interfaces also need ndiswrapper and/or a specific firmware. If you plan to use WPA encryption, you will need wpa_supplicant. The Wireless Setup page will help you choose the correct packages for your wireless device. Also strongly consider installing netcfg, which will help you set up your network connection and profiles after you reboot into your new system.

After selecting the desired packages, leave the selection screen and continue to the next step, Install Packages.

Install packages

Install Packages will install the selected packages to your new system. If you selected local sources, package versions from the CD-ROM/USB will be installed. If you opted for remote sources, the most currently available packages will be downloaded from the Internet and installed by pacman.

Note: In some installers, you will be asked if you wish to keep the packages in the pacman cache, which is located at /var/cache/pacman/pkg. If you choose "yes", you will have the flexibility to downgrade packages to previous versions. This is recommended if there is sufficient drive space available. The cache will grow over time as the system is updated, but can be cleared as needed using pacman

Configure the system

Tip: Closely following and understanding these steps is of key importance to ensure a properly configured system.

At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system.

You will be presented with a menu including the main configuration files for your system.

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.

Can the installer handle this more automatically?

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.

/etc/rc.conf

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 such as timezone, keymap, kernel modules, networking, and startup daemons. It also contains settings that are sourced by the various /etc/rc* files.

LOCALIZATION section
LOCALE
This sets your location environment, 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 default is usually fine for US English users. If you experience problems such as alpha-numeric characters being replaced by squares you may want to replace "en_US.utf8" with "en_US".
DAEMON_LOCALE
Set to yes to use the daemon locale with the environmental variable $LOCALE. Setting to no will use the C locale (default).
HARDWARECLOCK
Specifies whether the hardware clock, which is synchronized on boot and on shutdown, stores UTC time, or local time. See Set clock.
TIMEZONE
Specify your time zone. (All available zones are under /usr/share/zoneinfo/).
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.
CONSOLEFONT 
Available alternate console fonts reside in /usr/share/kbd/consolefonts/. The default (blank) is safe.
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.
USECOLOR 
Select "yes" if you have a color monitor and wish to have colors in your consoles.

Example for LOCALIZATION:

LOCALE="en_US.utf8"
DAEMON_LOCALE="no"
HARDWARECLOCK="UTC"
TIMEZONE="US/Eastern"
KEYMAP="us"
CONSOLEFONT=
CONSOLEMAP=
USECOLOR="yes"
HARDWARE section
MODULES 
If you know a module is missing, it can be specified here. For example, if you will be using loopback filesystems, add "loop".
Note: Normally all needed modules are automatically loaded by udev, so you will rarely need to add something here.

Example for HARDWARE:

# Scan hardware and load required modules at boot
MODULES=()
NETWORKING section
HOSTNAME
Set your hostname to your liking. This is the name of your computer. Whatever you put here, also put it in /etc/hosts.

Example:

HOSTNAME="arch"
interface
Specify the ethernet interface you want to be used for connecting to your local network.
address
If you want to use a static IP for your computer, specify it here. Leave this blank for DHCP.
netmask
Optional, defaults to 255.255.255.0. If you want to use a custom netmask, specify it here. Leave this blank for DHCP.
broadcast
Optional. If you want to use a custom broadcast address, specify it here. Leave this blank for DHCP.
gateway
If you set a static IP in "address", enter the IP address of the default gateway (eg. your modem/router) here. Leave this blank for DHCP.
NETWORK_PERSIST 
Setting this to "yes" will enable graceful logouts if users are ssh'ed into the box and the box is being restarted or shutdown. This is required if the root device is on NFS.
NETWORKS
This is an optional setting to be enabled only if using the netcfg package with optional dialog package. Enable these netcfg profiles at boot-up. These are useful if you happen to need more advanced network features than the simple network service supports, such as multiple network configurations (ie, laptop users).

Example with Static IP:

HOSTNAME=arch
interface=eth0
address=192.168.1.100
netmask=255.255.255.0
broadcast=192.168.1.255
gateway=192.168.1.1
#NETWORKS=(main)

Example with Dynamic IP (DHCP):

HOSTNAME=arch
interface=eth0
address=
netmask=
broadcast=
gateway=
#NETWORKS=(main)

Other notes

When using a static IP, modify /etc/resolv.conf to specify the DNS servers of choice. Please see the section below regarding this file.

Note: Connecting to a wireless network automatically requires a few more steps and may require you to set up a network manager such as netcfg or wicd. Please see the Wireless Setup page for more information
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.
DAEMONS section

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. Asynchronous initialization by backgrounding is also supported and useful for speeding up boot:

DAEMONS=(network @syslog-ng netfs @crond)
  • If a script name is prefixed with a bang (!), it is not executed.
  • If a script is prefixed with an "at" 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.
  • Edit this array whenever new system services are installed, if starting them automatically during boot is desired.
Note: This "BSD-style" init, is the Arch way of handling what other distributions handle with various symlinks to an /etc/init.d/ directory.
General information

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.

A daemon is a program that runs in the background, waiting for events to occur and offering services. A good example is a web server 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), 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.

Tip: All Arch daemon scripts reside under /etc/rc.d/

/etc/fstab

The fstab (for file systems table) 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.

An example of /etc/fstab

# <file system>                            <dir>     <type>  <options>            <dump> <pass>
tmpfs                                      /tmp      tmpfs   nodev,nosuid         0      0
UUID=0ddfbb25-9b00-4143-b458-bc0c45de47a0  /         ext4    defaults             0      1
UUID=da6e64c6-f524-4978-971e-a3f5bd3c2c7b  /var      ext4    defaults             0      2
UUID=440b5c2d-9926-49ae-80fd-8d4b129f330b  none      swap    defaults             0      0
UUID=95783956-c4c6-4fe7-9de6-1883a92c2cc8  /home     ext4    defaults             0      2
Note: See the fstab article for more information and performance tweaks such as "noatime" or "relatime".
<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.
Note: If your system has more than one hard drive, the installer will default to using UUID rather than the sdx naming scheme, for consistent device mapping. Utilizing UUID has several advantages and may also be preferred to avoid issues if hard disks are added to the system in the future. 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. For more information, see Persistent block device naming.
<dir>
Describes the mount point for the filesystem. For swap partitions, this field should be specified as 'none'; (Swap partitions are not actually mounted.)
<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.
<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).
<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.
<pass>
Used by the fsck(8) program to determine the order in which filesystem checks are done at boot time. The root filesystem should have the highest priority with <pass> of 1, and other filesystems you want to have checked should have a <pass> of 2. Filesystems with 0 <pass> will not be checked. 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.
  • For more information, see fstab.

/etc/mkinitcpio.conf

Note: Most users will not need to modify this file at this time, but please read the following explanatory information.

This file allows further fine-tuning, through mkinitcpio, of the initial ram filesystem, or initramfs, (also historically referred to as the initial ramdisk or "initrd") 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.

mkinitcpio is the next generation of initramfs creation. It has many advantages over the old mkinitrd and mkinitramfs scripts.

  • It uses glibc and busybox to provide a small and lightweight base for early userspace.
  • It can use udev for hardware autodetection at runtime, thus preventing numerous unnecessary modules from being loaded.
  • 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.
  • It already supports lvm2, dm-crypt for both legacy and luks volumes, raid, swsusp and TuxOnIce resuming and booting from usb mass storage devices.
  • Many features can be configured from the kernel command line without having to rebuild the image.
  • The mkinitcpio script makes it possible to include the image in a kernel, thus making a self-contained kernel image is possible.
  • Its flexibility makes recompiling a kernel unnecessary in many cases.

If using RAID or LVM on the root filesystem, the appropriate HOOKS must be configured. See the wiki pages for LVM/RAID and Configuring mkinitcpio for more information. If using a non-US keyboard. add the keymap hook to load your local keymap during boot. Add the usbinput hook if using a USB keyboard (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). Remember to add the usb hook when installing arch on an external hard drive, Comfact Flash, or SD card, which is connected via usb, e.g.:

HOOKS="base udev autodetect pata scsi sata usb filesystems keymap usbinput"

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.

/etc/modprobe.d/modprobe.conf

This file can be used to set special configuration options for the kernel modules. It is unnecessary to configure this file in the example. The article on kernel modules has more information.

/etc/resolv.conf

Note: 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 the network and resolv.conf pages for more information.

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.

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.

An example, using OpenDNS:

nameserver 208.67.222.222
nameserver 208.67.220.220

If you are using a router, you may 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). Example:

nameserver 192.168.1.1

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.

/etc/hosts

This file associates IP addresses with hostnames and aliases. Each host is represented by a single line.

<IP-address> <hostname> [aliases...]

Add your hostname, coinciding with the one specified in /etc/rc.conf, as an alias, so that it looks like this:

127.0.0.1   localhost.localdomain   localhost yourhostname
Warning: This format, including the "localhost" and your actual host name, is required for program compatibility! So, if you have named your computer "arch", then that line above should look like this:
127.0.0.1   localhost.localdomain   localhost arch
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.
Note: Recent versions of the Arch Linux Installer automatically add your hostname to this file once you edit /etc/rc.conf with such information. If, for whatever reason, this is not the case, you may add it yourself with the given instructions.

If you use a static IP, add another line using the syntax: <static-IP> <hostname.domainname.org> <hostname> e.g.:

192.168.1.100 yourhostname.domain.org  yourhostname
Tip: For convenience, you may also use /etc/hosts aliases for hosts on your network, and/or on the Web, e.g.:
192.168.1.90 media
192.168.1.88 data
The above example would allow you access a media and data server on your network by name and without the need for typing out their respective IP addresses.

/etc/locale.gen

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.

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.

Choose the locale(s) you need by removing the # in front of the lines you want, e.g.:

en_US ISO-8859-1
en_US.UTF-8

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.

Note: If you fail to choose your locale, this will lead to a "The current locale is invalid..." error. This is perhaps the most common mistake by new Arch users.

/etc/pacman.conf

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 repository that pacman can use when searching for packages. The exception to this is the options section, which defines global options.

Enable all desired repositories by removing the # in front of the 'Include =' and '[repository]' lines.

Note:
  • The defaults should work, so modifying at this point may be unnecessary, but verification is always recommended. Further info available in the Official Repositories article.
  • If you are using a 64-bit installation, you should consider enabling the multilib repository to allow access to 32-bit software. All 32-bit software is in the multilib repository for 64-bit installations. Enabling multilib is not necessary for proper functioning, but it must be enabled to access 32-bit software.
  • 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.

/etc/pacman.d/mirrorlist

Mirror sites are Internet locations where exact copies of data reside. Multiple mirrors provide reliability, redundancy, and allow for faster data transfer depending on geographic location. Closer sites generally give faster data rates. Choose a mirror repository for pacman by uncommenting the desired mirror locations in this file. Remember that ftp.archlinux.org is throttled, limiting downloads to 50 kB/s. Read the Mirrors wiki page for more details about setting up pacman mirrors. Note that the mirrors chosen here will carry over into your installation.

Root password

Finally, set a root password and make sure that you remember it later. Return to the Main Menu and continue with Installing Bootloader.

Done

When you select "Done", the system will rebuild the images and put you back to the Main Menu. This may take some time.

Install bootloader

Because we have no secondary operating system in our example, we will need a bootloader. GRUB (GRand Unified Bootloader) will be used in the following examples. Alternatively, you may choose LILO, Syslinux or GRUB2. Please see the related wiki and documentation pages if you choose to use a bootloader other than GRUB.

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.)

Explanation:

title
A printed menu selection. "Arch Linux (Main)" will be printed on the screen as a menu selection.
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 hdx,x format regardless of IDE or SATA, and enclosed within parentheses. The example indicates that /boot is on the first partition of the first drive, according to the BIOS, so (hd0,0).
kernel
This line specifies:
  • The path and filename of the kernel relative to GRUB's root. In the example, /boot is merely a directory residing on the same partition as / and vmlinuz-linux is the kernel filename; /boot/vmlinuz-linux. If /boot were on a separate partition, the path and filename would be simply /vmlinuz-linux, being relative to GRUB's root.
  • 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). 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.
  • Kernel options: In our example, ro mounts the filesystem as read-only during startup, which is usually a safe default; you may wish to change this in case it causes problems booting. quiet sets the default kernel log level so that all messages during boot are suppressed except serious ones. Depending on hardware, rootdelay=8 may need to be added to the kernel options in order to be able to boot from an external usb hard drive.
initrd
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 initramfs-linux.img is the initrd filename; /boot/initramfs-linux.img. If /boot were on a separate partition, the path and filename would be simply /initramfs-linux.img, being relative to GRUB's root.

Example:

title  Arch Linux (Main)
root   (hd0,0)
kernel /boot/vmlinuz-linux root=/dev/sda1 ro quiet
initrd /boot/initramfs-linux.img

Example for /boot on a separate partition:

title  Arch Linux (Main)
root   (hd0,0)
kernel /vmlinuz-linux root=/dev/sda3 ro quiet
initrd /initramfs-linux.img

Install the GRUB bootloader to the Master Boot Record (/dev/sda in our example).

Note: Arch Linux installers prior to the 2011.08.19 release included an option to install the bootloader to either a partition or the MBR. This option has been removed and so it is no longer possible to install the bootloader to a partition using AIF (see FS#25726). If you wish to install the bootloader to a partition boot record, simply exit AIF without invoking the "Install bootloader" step and install the bootloader manually.

Reboot

That is it; You have configured and installed your Arch Linux base system. Exit the install, and reboot:

# reboot
Tip: Be sure to remove the installation media and perhaps change the boot preference in your BIOS; otherwise you may boot back into the installation!

Template:Beginners' Guide navigation