Talk:Installation guide

From ArchWiki
Revision as of 12:38, 17 February 2019 by LinuxPhreak (talk | contribs) (→‎Rewrite Proposal: new section)
Jump to navigation Jump to search

Read this first before adding new suggestions

  • systemd tools such as hostnamectl, timedatectl and localectl do not work in the installation chroot environment, so please do not propose to use them in the guide unless you can prove that they have been made to work also in that case. See [1], [2], [3] and [4] for some past discussions about this issue.
  • localectl list-keymaps does not work due to bug FS#46725. For the chosen replacement command, see [5].
  • localhost must be set explicitely in /etc/hosts, as it is otherwise resolved over the network. See FS#56684.

-- The ArchWiki Administrators 22:17, 2 September 2016 (UTC)

pacman-key --populate

[Moved from Talk:Beginners' guide. -- Alad (talk) 20:38, 12 July 2016 (UTC)]

Reference: I tried to install Archlinux on my new computer and got stuck. Only using the pacman-key --populate archlinux helped me. I think I am not the only one having this problem. But why did you undo it? —This unsigned comment is by Sandstorm (talk) 20:38, 12 December 2015‎. Please sign your posts with ~~~~!

This command is already run for the new system (by installation of archlinux-keyring), so running it by hand shouldn't be required for most users. Of course, things can go wrong (how old was the ISO you used to install the system?), but that belongs in Troubleshooting sections of the respective articles, which are linked at the beginning of the guide. -- Alad (talk) 19:52, 12 December 2015 (UTC)
I had downloaded the ISO just yesterday, minutes before the install. Only that command installed the keys. Probably I should open a bug if you can confirm the issue?
Did you have to run pacman-key after, or before pacstrap? And do you recall what the error messages said exactly? (See also FS#31286) -- Alad (talk) 20:15, 12 December 2015 (UTC)
I had to run after pacstrap. As far as I remember, pacstrap stopped after trying to download the keys. The error message was something like shown in this forum post:
Well then, as you suggested, I'd open a bug report. -- Alad (talk) 20:34, 12 December 2015 (UTC)
Done. Could you check if the description is good. I could not find an appropriate category, so I though Packages:Core might be the closest one. --Sandstorm (talk) 20:48, 12 December 2015 (UTC)
Thanks, the description looks OK. If the category e.a is not right, User:Scimmia should fix it. :P -- Alad (talk) 13:59, 13 December 2015 (UTC)
Hmm, looks like it was closed with "Works for me" ... not very enlightening. All I can suggest is to further improve on Pacman/Package signing and related articles, and recheck if they're accessible enough from the Beginners' guide. -- Alad (talk) 21:59, 12 February 2016 (UTC)

Link to the German version

Instead of de:Arch Install Scripts you could choose de:Anleitung für Einsteiger it means "Beginner's Guid" and is a very detailed artikel for very new arch users and the future experts.

Thank you, done. -- Kynikos (talk) 16:31, 6 February 2018 (UTC)
This was already proposed last year and rejected: [6]. I don't see what has changed since then. If someone adds me as admin to the german wiki or changes the protection settings, I can update de:Arch Install Scripts as required. -- Alad (talk) 18:13, 6 February 2018 (UTC)
I see, I didn't remember that discussion so I've reverted the change, hopefully you'll make it to update the translation, let's leave this open until the problem is solved, otherwise this kind of suggestion will keep appearing recurrently. -- Kynikos (talk) 17:53, 7 February 2018 (UTC)

Network configuration

The newly installed environment has no network connection activated by default. See Network configuration#Network management.
For Wireless configuration, install the iw and wpa_supplicant packages, as well as needed firmware packages. Optionally install dialog for usage of wifi-menu.

The Network configuration section is rubbish. It doesn't explain that wifi-menu is part of netctl and telling users to install both iw and wpa_supplicant is plainly wrong. I would replace it with a DRY "See Network configuration." but maintainers aren't trusted to edit the Installation guide. --Larivact (talk) 17:09, 18 May 2018 (UTC)

If maintainers go on the talk page and plainly state "this section is rubbish" while indicating they would push their change without discussion, then no, I wouldn't trust maintainers with editing this central article. -- Alad (talk) 21:09, 18 May 2018 (UTC)
Nah, Larivact is right. I had to go to a completely different site to figure out that wifi-menu even exists. It should include the line: "For supported wireless devices run wifi-menu to set up the network". Would have saved me a couple hours. I genuinely don't understand why you would include the tool, but have no reference to it (and please don't take this as an indication that you should just remove the tool). Klaymen (talk) 02:38, 24 December 2018 (UTC)
I would agree linking appropriate article would suit more than current section, given deprecation of Beginners' Guide for similar reasons.
It is not that maintainers aren't trusted, but that MediaWiki doesn't allow specifying what user groups can perform edits, the choice is only among all, only auto-confirmed or only admins [7], plus we need to discuss edits to central wiki articles beforehand anyway [8]. -- Svito (talk) 20:03, 18 May 2018 (UTC)
I've wanted to create additional groups for a while now (should be simple with LocalSettings.php published). Anyone interested should be able to write a patch and send it to the admins. -- Alad (talk) 21:09, 18 May 2018 (UTC)
Indeed "rubbish" wasn't a very wise choice of a word, a lot of volunteer effort has been put to get to the current state of the wiki, of course everything can always be improved.
In particular, the history of that section basically is Beginners' guide#Network configuration > [9] > [10].
I'd be in favor of simply restoring a similar state to [11], i.e. I'd link Network configuration but also Wireless network configuration directly, and drop the rest of the details.
-- Kynikos (talk) 16:19, 20 May 2018 (UTC)
[12] With the recent changes to Network configuration article, we may make similar changes to Installation guide#Connect to the Internet. Even a specific link to Wireless network configuration should no longer be required, since you need to follow Network configuration#DHCP anyway and Wireless is linked from Network configuration#Setup. Proposed wording:
The installation image enables the dhcpcd daemon on boot for wired network devices. The connection may be checked with:
# ping
If no connection is available, stop the dhcpcd service:
# systemctl stop dhcpcd@<TAB>
Proceed with instructions in Network configuration.
If that's a bit too short we might expand the ping(8) example, compare expansion template in Network_configuration#Ping. --Alad (talk) 16:38, 20 May 2018 (UTC)
I actually prefer the current style with the systemctl example, using the ic template and a spelled-out instruction to press Tab. I don't see the need to expand further on ping directly in this page.
On a second thought with respect to my previous post, I'm fine with dropping direct links to Wireless network configuration and only point to Network configuration as proposed in OP, i.e. also in Installation guide#Network configuration (I think we should be consistent between the two network-configuration sections).
Another idea, we could merge Installation guide#Hostname into Installation guide#Network configuration now, since Hostname lands in Network configuration anyway, and even if that section is moved to DNS configuration, it's still all network setup.
-- Kynikos (talk) 15:08, 21 May 2018 (UTC)
I've removed the Wireless network configuration link from both sections. As it stands it cannot be used independently of Network configuration anyway. It's the devil or the blue sea - when configuring a simple wireless connection, users have to wade through pages of possibly unrelated information in Network configuration or be confused by missing steps in Wireless network configuration. Sometimes I believe that things would be much easier if our user base didn't value "choice" as much.
About the systemctl example, after all this time I'm still not sure on the Tab instructions. We never finished the relevant discussion in Help_talk:Reading and the steps to fill in (choosing the right ethernet adapter, tab-completing it and pressing return) are not necessarily obvious.
About Installation guide#Hostname, I'm fine with moving this section under Installation guide#Network configuration. -- Alad (talk) 23:22, 25 May 2018 (UTC)
I've merged #Hostname into #Network_configuration.
I hear you about the complexity of the network configuration pages, but it's a huge topic, I'll leave it to Talk:Network configuration.
I'm going to reply to Help talk:Reading#Mention tab completion.3F, but regarding this instance I propose the following:
If no connection is available, stop the dhcpcd service with systemctl stop dhcpcd@interface; you can tab-complete the interface name. Then proceed to configure the network as described in Network configuration.
-- Kynikos (talk) 15:49, 26 May 2018 (UTC)
I'd like "where the interface name can be tab-completed" better, but that's just a detail. -- Lahwaacz (talk) 16:33, 26 May 2018 (UTC)
Implemented [13] -- Alad (talk) 16:50, 26 May 2018 (UTC)
How about we add a sentence to Installation_guide#Network_configuration describing how to restore use of dhcpcd as done on the installation medium? That way if the connection already worked on installation people only need a brief look at dhcpcd. -- Alad (talk) 15:48, 27 May 2018 (UTC)
I think that would just hide the possibility of choice from users. Maybe just say that dhcpcd is not enabled on the installed system without recommending anything. -- Lahwaacz (talk) 17:34, 27 May 2018 (UTC)
May I suggest the following edit to this section:
If no connection is available, or you are using a wireless device, stop the dhcpcd service with ... Tourian (talk) 04:45, 28 May 2018 (UTC)
That's already mentioned in the relevant section: Installation_guide#Connect_to_the_Internet. dhcpcd is not enabled by default in the installed system so there is nothing to stop in Installation_guide#Network_configuration. -- Lahwaacz (talk) 06:33, 28 May 2018 (UTC)
I guess the proposed wording is indeed for Installation_guide#Connect_to_the_Internet, which as it stands has no mention of wireless devices (only implied through lack of connection) -- Alad (talk) 10:05, 28 May 2018 (UTC)
Yes, it is not explicit. The wording on 20 May 2018 at the end of Installation_guide#Connect_to_the_Internet was "Proceed with Network configuration for wired devices or Wireless network configuration for wireless devices", with the reference to wireless devices removed after the decision to send those on wireless connections to Network configuration. Therefore, how about starting this section with, "If you are using a wireless network device, proceed with Network Configuration. For wired devices, the installation image enables the dhcpcd daemon on boot. The connection..." and leave the rest as it is. -- Tourian (talk) 14:04, 28 May 2018 (UTC)
I perhaps prefer the first wording you suggested, since we've always told people to disable the wired dhcpcd even when using a wireless connection, to rule out any possible conflicts. I don't feel strongly about this however.. -- Alad (talk) 16:03, 28 May 2018 (UTC)
In Installation_guide#Network_configuration, can we append the introduction of Network_configuration#Network_management? Currently new users are pointed to a page that is comprehensive, but unhelpful as a part of the installation guide. --Mpan (talk) 00:38, 8 February 2019 (UTC)

Why should a static IP be preferred over in /etc/hosts?

"If the system has a permanent IP address, it should be used instead of"

I think the ArchWiki should not just say do X but also why. Alad as you added this, perhaps you can explain?--Larivact (talk) 15:14, 21 May 2018 (UTC)

In Network_configuration#Local hostname resolution: "For a system with a permanent IP address, that permanent IP address should be used instead of" -- Lahwaacz (talk) 06:48, 22 May 2018 (UTC)
First appearance in our wiki, cited source, also discussion. -- Kynikos (talk) 10:26, 22 May 2018 (UTC)

Add a TIP under Post-installation

Under Installation_guide#Post-installation, it may be a good idea to add a TIP like this for new (or even existing) users:

Tip: Create an account at ArchWiki and add General recommendations page to your Watchlist to automatically get alerts for new recommendation or changes to existing recommendations. You may also add other Wiki pages of your liking to the Watchlist so as to always stay up-to-date with them.

-- Amish (talk) 01:19, 10 June 2018 (UTC)

It's certainly an interesting suggestion. I'm not sure if it's in the scope of the installation guide however; maybe Help:Reading is better suited? -- Alad (talk) 21:26, 10 June 2018 (UTC)
Installation guide would always be read by those installing Arch Linux. But not necessarily Help:Reading (today is first time I read it in 4-5 years with Arch Linux). So Installation guide will bring in more awareness and more involvement of users.
That's a bit of an issue since the Installation guide assumes users have read Help:Reading... though I'm not unaware of this, see e.g. [14] -- Alad (talk) 09:55, 11 June 2018 (UTC)
Actually the purpose of Help:Reading is to tell users how to read the page / article but not what can be done after Installation. Here Tip is intended to suggest what to do after installation. i.e. Post-installation.
Amish (talk) 12:15, 11 June 2018 (UTC)
I'd word it less imperatively:
Tip: You can stay up to date with ArchWiki articles by creating an account and adding articles of interest to your Watchlist.
--Larivact (talk) 04:47, 11 June 2018 (UTC)
Sounds good to me. -- Alad (talk) 09:55, 11 June 2018 (UTC)
My intention was to highlight General recommendations for Watchlist because thats a page every Arch user must follow to keep their Arch Linux well maintained. Other important page that I feel must be highlighted to be added in Watchlist is System maintenance.
OR we can have Tip like this:
Tip: You can stay up to date with ArchWiki articles by creating an account and adding articles of interest to your Watchlist. Few articles you may want start with are at Main Page
-- Amish (talk) 12:32, 11 June 2018 (UTC)
What is the current state of this suggestion, because I believe it is very interesting. I have a preference for the first proposed TIP.
-- Apollo22 (talk) 19:23, 12 August 2018 (UTC)
Why not just use bookmarks? Creating an account to follow changes seems more tedious, it's meant for editors. --Ubone (talk) 16:34, 22 September 2018 (UTC)

Network Configuration -- WiFi discussion

I'm starting a new thread seeing as the last one took a different direction and never really got resolved.

As it stands, the current instructions for the installation guide make it challenging for users who need to connect to the internet via a Wireless connection rather than wired. The Installation_guide#Connect_to_the_Internet section essentially assumes the users are using a wired connection, and to test it with a ping. Otherwise, they are directed to the Network_configuration page. Unfortunately, that page does not provide clear instructions for new users (or even those who just want to do a quick connection) to establish a connection via wireless. Equally so, should users find their way to the Wireless_network_configuration page, there is some digging to do there in order to find instructions to setup a connection. These are currently using the iw command, which may prove to be challenging to some. I see a few different possible solutions to improve the user experience:

  • Add explicit instructions to the installation guide
    • This is not ideal, as it adds another place to maintain likely duplicate information
  • Add a reference to the Wireless_network_configuration page
    • This is better, though the page would likely need a new section, or some tweaking to allow users to more easily find the information they need to get setup
  • Add new/better instructions to the Network_configuration page
    • This may also prove to be tricky, seeing as that page is already fairly monolithic, and focuses mostly on wired connections

One other consideration (of which I also don't see any progress) is the discussions revolving around moving and breaking down the Network Configuration guides, to separate Wired and Wireless content. With this move I could see such instructions being provided there. In any case, the guide should provide instructions that are:

  • Easy to follow, particularly for new users
  • Puts no emphasis on persisting configurations, as this is not applicable during the install phase
  • Offers options (choice is King)

--CubeTheThird (talk) 23:47, 26 August 2018 (UTC)

The Wireless network configuration link was removed because it cannot be used independently of Network configuration. I propose the following:
  1. Implement Talk:Network configuration#Moving Ethernet-specific sections to Wired subpage. Network configuration currently isn't straightforward. The actual setup instructions are hidden in the Network management section and it's confusing that wireless has a subpage but wired and medium-agnostic configuration are mixed together. See my demo.
  2. Have the Connect to the Internet section only link Network configuration and move the dhcpcd udev rule note there.
  3. Move Wireless network configuration to Network configuration/Wireless and move its iw section to a dedicated article because since recently we also have iwd.
The result should be more user-friendly without duplicating content.
--Larivact (talk) 07:13, 27 August 2018 (UTC)
As for your demo, note that in Talk:Network_configuration#Ongoing_rewrite, Alad said: "ping is one of the very first commands a new user has to run on installation to verify the availability of an internet connection". So unless you intend to direct users from the installation guide directly to the Network configuration#Troubleshooting section, there is still some more thinking to be done... -- Lahwaacz (talk) 07:21, 28 August 2018 (UTC)
Well then let's keep Connect to the Internet and revise it:

The installation image has a udev rule that enables the dhcpcd service for Ethernet network interfaces on boot. If you use Ethernet, verify the connection with ping:

# ping

If the ping fails see Network configuration#Troubleshooting. If you want to use Wi-Fi or a static IP address, stop the dhcpcd service with systemctl stop dhcpcd@interface where the interface name can be tab-completed and proceed with Network configuration.

--Larivact (talk) 08:41, 28 August 2018 (UTC)
That looks good to me. -- Lahwaacz (talk) 14:57, 28 August 2018 (UTC)

ArchWiki link

special:diff/542917 shouldn't that link go Table_of_contents or similar? --Ubone (talk) 13:20, 26 September 2018 (UTC)

Why would it? That link is supposed to specifically explain what ArchWiki is. -- Alad (talk) 13:38, 26 September 2018 (UTC)
isn't the context of the sentence about the tools used in the article and their wiki pages? --Ubone (talk) 14:39, 26 September 2018 (UTC)

/etc/locale.conf needs to be created

The area needing a correction is Installation guide#Localization.

The instructions tell you to set variables in the /etc/locale.conf file, but the file doesn't exist unless the user creates it. If the user needs to create the file, it should be explicitly explained with that language just as it is explained for the hostname file in Installation guide#Network configuration area. "Create the hostname file:"

For Localization, I propose we add the verbiage Create the locale.conf file: /etc/locale.conf Schlitzkrieg (talk) 18:52, 28 September 2018 (UTC)


The section about generating the fstab with genfstab mentions -U and -L options but not the possibility to use GPT identifiers PARTUUID and PARTLABEL with the '-t' option. Those are described in Persistent block device naming and are a better choice for some users. genfstab itself doesn't explicitly list the GPT options either so IMHO it would be helpful to add this info here.

—This unsigned comment is by Grmat (talk) 15:12, 9 October 2018‎. Please sign your posts with ~~~~!

Wording in example layout table and size of EFI partition

Regarding Installation_guide#Example_layouts:

  1. even if many users will understand remainder of the device as what is left after size of /dev/sdx1 and /dev/sdx3 are subtsructed from the size of the device, I think the order of the table might be confusing for some. Some people might set /dev/sdx2 to the size of the device minus size of /dev/sdx1, and then stumbled at where from 512 MiB, or larger, are to be found for /dev/sdx3. Either suggest the swap space as /dev/sdx2 and / as /dev/sdx3, or better explain the meaning of the remainder of the device for sdx2.
  2. As for the size of sdx1 for UEFI+GPT, I think 260-550 MiB are better than 260-512 MiB, as per EFI system partition#Create the partition, which is referenced by partition#/boot.

Regid (talk) 14:05, 29 December 2018 (UTC)

I would like to propose an ESP size of 5 MiB (requires fat12 filesystem format), which works fine on any well-designed implementation of the UEFI spec, like my laptop, and elegantly covers the case where the EFI contains only a capable bootloader, which loads the kernel from another (ext4/btrfs/whatever) partition.
Anyway the page you linked makes it quite clear that 512 MiB is fine for any UEFI implementation, and "avoiding confusion" seems to be rather inferior compared to just instructing people to use mkfs.fat -F 32. -- Eschwartz (talk) 23:44, 29 December 2018 (UTC)
I'm not sure I understand your comment. Do you propose to add an mkfs.fat line to Installation guide#Format the partitions for a /boot partition? -- Alad (talk) 08:55, 30 December 2018 (UTC)
I'm saying we already do do so, in EFI system partition#Format the partition where we go into lots of detail about the best way to set up an ESP, why fat32 is not necessary but nevertheless is recommended, and the optimal size for one. None of this elaboration is suitable for the Installation guide, which does not even mention which filesystem type any of the example layouts uses. But we do explicitly state it "must" be fat32 in File systems#Create a file system which we link to immediately after the example layouts. -- Eschwartz (talk) 16:35, 30 December 2018 (UTC)
Yes, but just because of that content Regid has a point that the 260-512 example is confusing. I'd say, match it now by switching to a 550MiB example as per #Example layouts section draft below, which in the end only carries the recommendation from the subject articles into the installation guide. --Indigo (talk) 21:33, 3 February 2019 (UTC)
But the primary recommendation there is to use 512, and as I said I think it makes more sense to stick with what we already say, and recommend the use of mkfs.fat -F 32. I'm unclear why the article seems to be recommending the use of specific sizes merely to trick the mkfs.vfat command into selecting the right vfat version. -- Eschwartz (talk) 21:41, 3 February 2019 (UTC)
You paraphrased your reply to the last question very much; I did not get that you recommend that. In the linked subject articles I found mentions along the lines of " least 512 MiB. 550 MiB is recommended..". Hence, I restate my main point: this article should subsume recommendations from the other articles (and this is the wrong place to start discussing them), not make different ones. --Indigo (talk) 22:39, 3 February 2019 (UTC)
The 550 MiB recommendation is useful in case someone is creating and formatting the partitions with gparted or a similar tool, instead of doing it from the command line. Who knows what automagic those tools use... -- nl6720 (talk) 10:48, 4 February 2019 (UTC)
I also question the usefulness of 550MB to trick mkfs. I noticed that approximately half-year ago several wiki articles related to this issue has switched to recommend 550MB, but i didn't bother to argue. Wiki should be helpful, but not assuming users cannot understand the -F 32 option and should not revert to give advices to fool utilities. Regarding other points. 1) This discussion page is no worse than other places to discuss this issue. 2) The wiki everywhere discusses partitioning by command line tools, at least at core articles related to installation and partitions. If someone decided to use automatic tools and by mistake created FAT16 EFI partition he can easily undo his mistake. --Mxfm (talk) 04:54, 5 February 2019 (UTC)
Using /dev/sdx2 for swap is questionable, it doesn't emphasize that swap is optional nor is it consistent with other articles like dm-crypt/Encrypting an entire system. If you have some better explanation for "remainder of the device" feel free to propose it. -- Alad (talk) 08:55, 30 December 2018 (UTC)
I was trying to say that a user that patitions his HD by following the table might do the following: look at first row in the table, and creates the EFI partition. Than continue with the 2nd row. So he creates a partition at the remainder of his HD. Now he comes to the 3rd row: where will he get 512 MiB, or larger? As for dm-crypt/Encrypting an entire system, I might be wrong thinking that each partition is considered a separate device, so it doesn't matter if the swap space is before, or after, the / partition. Regid (talk) 12:41, 30 December 2018 (UTC)
Perhaps call it "Principal part of the device" instead. NB the term "remainder of the device" is often used for a separate /home in other articles. --Indigo (talk) 21:33, 3 February 2019 (UTC)


Moved from #Read this first before adding new suggestions. -- Alad (talk) 04:10, 2 January 2019 (UTC)

I think this list of systemctl commands, perhaps the whole paragraph, should be stated in the installation guide itself, not only here. Also, the fact the some systemctl commands do work, according to github reference above, also worth explicit mention. Otherwise, users that do read pages of the wiki might not understand when to expect systemctl control commands, that are spread all over the wiki, to actually work within the chroot environment.

Another point that worth mentioning, in my opinion, is that systemctl notices it is running in a chroot environmnet, and refuses, or can not, carry on some actions. For example, it will enable units within the chroot environment. But it will not start them.

Regid (talk) 21:43, 31 December 2018 (UTC)

Note that the section #Read this first before adding new suggestions does not mention systemctl at all. -- Lahwaacz (talk) 21:29, 7 February 2019 (UTC)

Example layouts section

There are several things I don't like in the current Installation guide#Example layouts section.

  • BIOS/GPT & BIOS/MBR is merged in one example. This is bound to lead to unnecessary confusion, since, for example, there is no BIOS boot partition for MBR. I suggest omitting BIOS/GPT since not all firmware support it (due to being unsupported by Windows). Then the GRUB-specific partition doesn't need to be listed.
  • Column title "Partition type (GUID)". If the GUIDs (and IDs for MBR) are omitted for simplicity, then the column should not mention them.
  • The Discoverable Partitions Specification is not used on GPT.
  • The suggested size for /, "Remainder of the device", could be replaced with the required minimum. Partitioning suggests 23-32 GiB, so how about 32 GiB.
  • The suggested size of ESP doesn't match the recommended size from EFI system partition#Create the partition.
  • gdisk is not mentioned or linked (it doesn't share an wiki article with fdisk anymore) even once in the Installation guide. It could be added to the note below the tables.
  • Without Template:ic around the mount points and partitions, they look awful.

I presume that, unlike Partitioning#Example layouts, the examples should be as simple as possible, so, I propose the following examples.

-- nl6720 (talk) 07:37, 28 January 2019 (UTC)

I guess /dev/sdX2 being root in both examples is the reason for keeping the current "BIOS with MBR or GPT" example. I don't really have a solution for this. The wiki's usage of /dev/sdXY will need to be addressed sooner or later due to the naming scheme of NVME disks.
Re Special:Diff/565508: There's no maximum for the ESP, so how about "At least 256 MiB". -- nl6720 (talk) 09:00, 2 February 2019 (UTC)
I agree with the simpler examples. To make the numbering work out I propose to simplify the example commands in Installation guide#Format the partitions, it's hard to cater to users who have never mounted a drive or created a directory anyway.
Regarding the partition sizes, note that the column says "suggested size" instead of "maximum" or "minimum" size. (256 MiB is not the strict minimum either, especially for /efi as mount point.) As such the existing 256-512 MiB suggestion for ESP looks reasonable to me. -- Alad (talk) 18:54, 2 February 2019 (UTC)
[15] -- Alad (talk) 19:06, 2 February 2019 (UTC)
My issue with "256–512 MiB" is that the EFI system partition#Create the partition recommendation "550 MiB" is outside that range. -- nl6720 (talk) 19:39, 2 February 2019 (UTC)
This was (is?) discussed in #Wording_in_example_layout_table_and_size_of_EFI_partition -- Alad (talk) 19:43, 2 February 2019 (UTC)
Hmm, I see. FAT32 & 512+ MiB are used due to to firmware bugs, but the example suggests a range that includes a size smaller than 512 MiB so it's ineffective for that purpose. The main issue for me is that readers will see "conflicting information" with 256–512 MiB in the Installation guide and 550 MiB in other articles (just in case, I'm not suggesting to change the other articles). No one is going to think that the "Suggested size" is just a suggestion and not a hard limit. -- nl6720 (talk) 20:10, 2 February 2019 (UTC)

Example layouts section draft

Mount point Partition Partition type Suggested size
/mnt /dev/sdX1 Linux At least 32 GiB
[SWAP] /dev/sdX2 Linux swap More than 512 MiB
Mount point Partition Partition type Suggested size
/boot or /mnt/efi /dev/sdX1 EFI system partition 550 MiB
/mnt /dev/sdX2 Linux x86-64 root (/) At least 32 GiB
[SWAP] /dev/sdX3 Linux swap More than 512 MiB
  • Use fdisk or parted, or gdisk (GPT only) to modify partition tables. For example fdisk /dev/sdX.
  • Swap space can be set on a swap file for file systems supporting it.

See Partitioning#Example layouts for more detailed and advanced examples.

Table CSS

style="width: 70%;" introduced by Alad does not only look weird at 1080p but also unnecessarily squishes the table at smaller screen sizes. --Larivact (talk) 15:47, 2 February 2019 (UTC)

[16] -- Alad (talk) 18:55, 2 February 2019 (UTC)

Reword locale section that it is clear that not uncommenting en_US will lead to issues

In the unofficial Telegram group we get people at least weekly that have some issue that goes back to not uncommenting en_US.

There needs to be added emphasis on the AND or simply explained that en_US is the default that apps expect, and will otherwise crash or malfunction.

Current: Uncomment en_US.UTF-8 UTF-8 and other needed locales in /etc/locale.gen, and generate them with:

Proposed: Uncomment en_US.UTF-8 UTF-8, which is needed for many programs to work, and also other needed locales in /etc/locale.gen, and generate them with:

C0rn3j (talk) 13:53, 11 February 2019 (UTC)

Uncommenting locales which will never be used does not make sense. Obviously, it is the point of locales to let users configure something else than en_US, so if something crashes without en_US, it is not a configuration problem.
In any case, the installation guide will not change based on some vague claims which others cannot read on.
-- Lahwaacz (talk) 20:43, 12 February 2019 (UTC)

Rewrite Proposal

I'm proposing a rewrite of the Installation guide. I've provided a rough draft of this proposal. My reasoning for proposing such a rewrite is to make it more inviting for new comers of all platforms and all experience levels. The article will consist of screenshots.


This document is a guide for installing Arch Linux from the live system booted with the official installation image. Before installing, it would be advised to view the FAQ. For conventions used in this document, see Help:Reading. In particular, code examples may contain placeholders (formatted in italics) that must be replaced manually.

For more detailed instructions, see the respective ArchWiki articles or the various programs' man pages, both linked from this guide. For interactive help, the IRC channel and the forums are also available.

Arch Linux should run on any x86_64-compatible machine with a minimum of 512 MB RAM. A basic installation with all packages from the base group should take less than 800 MB of disk space. As the installation process needs to retrieve packages from a remote repository, this guide assumes a working internet connection is available.


The installation media and their GnuPG signatures can be acquired from the Download page.

Verify signature

It is recommended to verify the image signature before use, especially when downloading from an HTTP mirror, where downloads are generally prone to be intercepted to serve malicious images.

On a system with GnuPG installed, do this by downloading the PGP signature (under Checksums) to the ISO directory, and verifying it with:

$ gpg --keyserver --keyserver-options auto-key-retrieve --verify archlinux-version-x86_64.iso.sig

Alternatively, from an existing Arch Linux installation run:

$ pacman-key -v archlinux-version-x86_64.iso.sig

Windows Users

Can verify the signature using the GnuPG tool for Windows.


Instructions with screenshots will be added when article is approved by the community.

Mac Users

Mac OS users can verify their downloads using the Mac version of GnuPG found here


Instructions with screenshots will be added when article is approved by the community.

  • The signature itself could be manipulated if it is downloaded from a mirror site, instead of from as above. In this case, ensure that the public key, which is used to decode the signature, is signed by another, trustworthy key. The gpg command will output the fingerprint of the public key.
  • Another method to verify the authenticity of the signature is to ensure that the public key's fingerprint is identical to the key fingerprint of the Arch Linux developer who signed the ISO-file. See Wikipedia:Public-key_cryptography for more information on the public-key process to authenticate keys.

Boot the live environment

The live environment can be booted from a USB flash drive, an optical disc or a network with PXE. For alternative means of installation, see Category:Installation process.

  • Pointing the current boot device to a drive containing the Arch installation media is typically achieved by pressing a key during the POST phase, as indicated on the splash screen. Refer to your motherboard's manual for details.
  • When the Arch menu appears, select Boot Arch Linux and press Enter to enter the installation environment.
  • See README.bootparams for a list of boot parameters, and packages.x86_64 for a list of included packages.
  • You will be logged in on the first virtual console as the root user, and presented with a Zsh shell prompt.

To switch to a different console—for example, to view this guide with ELinks alongside the installation—use the Alt+arrow shortcut. To edit configuration files, nano, vi and vim are available.

Set the keyboard layout

The default console keymap is US. Available layouts can be listed with:

# ls /usr/share/kbd/keymaps/**/*.map.gz

To modify the layout, append a corresponding file name to loadkeys(1), omitting path and file extension. For example, to set a German keyboard layout:

# loadkeys de-latin1

Console fonts are located in /usr/share/kbd/consolefonts/ and can likewise be set with setfont(8).

Verify the boot mode

If UEFI mode is enabled on an UEFI motherboard, Archiso will boot Arch Linux accordingly via systemd-boot. To verify this, list the efivars directory:

# ls /sys/firmware/efi/efivars

If the directory does not exist, the system may be booted in BIOS or CSM mode. Refer to your motherboard's manual for details.

Connect to the Internet

The installation image enables the dhcpcd daemon for wired network devices on boot. The connection may be verified with ping:

# ping

If no connection is available or your required to install using a wireless connection. You can use one of the following methods to connect wirelessly.


Using the built in wifi-menu tool you can see a list of all non hidden wireless networks you can connect to.

  1. wifi-menu

Alternatively you can use wpa_supplicant and netctl tool. In order to use this tool you will need to make a configuration file. A sample file has been provided below.










Update the system clock

Use timedatectl(1) to ensure the system clock is accurate:

# timedatectl set-ntp true

To check the service status, use timedatectl status.

Partition the disks

When recognized by the live system, disks are assigned to a block device such as /dev/sda or /dev/nvme0n1. To identify these devices, use lsblk or fdisk.

# fdisk -l

Results ending in rom, loop or airoot may be ignored.

The following partitions are required for a chosen device:

If you want to create any stacked block devices for LVM, system encryption or RAID, do it now.

Example layouts

Mount point Partition Partition type Suggested size
/mnt /dev/sdX1 Linux Remainder of the device
[SWAP] /dev/sdX2 Linux swap More than 512 MiB
Mount point Partition Partition type Suggested size
/mnt/boot or /mnt/efi /dev/sdX1 EFI system partition 256–512 MiB
/mnt /dev/sdX2 Linux x86-64 root (/) Remainder of the device
[SWAP] /dev/sdX3 Linux swap More than 512 MiB

See also Partitioning#Example layouts.

  • Use fdisk or parted to modify partition tables, for example fdisk /dev/sdX.
  • Swap space can be set on a swap file for file systems supporting it.

Paritioning with parted tool

Parted information will go here

Partitioning with fdisk

Partitioning with fdisk will go here.

Partitioning with CFDISK

CFDISK info will go here along with screenshots of examples.

Format the partitions

Once the partitions have been created, each must be formatted with an appropriate file system. For example, if the root partition is on /dev/sdX1 and will contain the ext4 file system, run:

# mkfs.ext4 /dev/sdX1

If you created a partition for swap, initialize it with mkswap:

# mkswap /dev/sdX2
# swapon /dev/sdX2

See File systems#Create a file system for details.

Mount the file systems

Mount the file system on the root partition to /mnt, for example:

# mount /dev/sdX1 /mnt

Create any remaining mount points (such as /mnt/efi) and mount their corresponding partitions.

genfstab will later detect mounted file systems and swap space.


Select the mirrors

Packages to be installed must be downloaded from mirror servers, which are defined in /etc/pacman.d/mirrorlist. On the live system, all mirrors are enabled, and sorted by their synchronization status and speed at the time the installation image was created.

The higher a mirror is placed in the list, the more priority it is given when downloading a package. You may want to edit the file accordingly, and move the geographically closest mirrors to the top of the list, although other criteria should be taken into account.

This file will later be copied to the new system by pacstrap, so it is worth getting right.

Install the base packages

Use the pacstrap script to install the base package group:

# pacstrap /mnt base

This group does not include all tools from the live installation, such as btrfs-progs or specific wireless firmware; see packages.x86_64 for comparison.

To install packages and other groups such as base-devel, append the names to pacstrap (space separated) or to individual pacman commands after the #Chroot step.

Configure the system


Generate an fstab file (use -U or -L to define by UUID or labels, respectively):

# genfstab -U /mnt >> /mnt/etc/fstab

Check the resulting file in /mnt/etc/fstab afterwards, and edit it in case of errors.


Change root into the new system:

# arch-chroot /mnt

Time zone

Set the time zone:

# ln -sf /usr/share/zoneinfo/Region/City /etc/localtime

Run hwclock(8) to generate /etc/adjtime:

# hwclock --systohc

This command assumes the hardware clock is set to UTC. See System time#Time standard for details.


Uncomment en_US.UTF-8 UTF-8 and other needed locales in /etc/locale.gen, and generate them with:

# locale-gen

Set the LANG variable in locale.conf(5) accordingly, for example:


If you set the keyboard layout, make the changes persistent in vconsole.conf(5):


Network configuration

Create the hostname file:


Add matching entries to hosts(5):

/etc/hosts	localhost
::1		localhost	myhostname.localdomain	myhostname

If the system has a permanent IP address, it should be used instead of

Complete the network configuration for the newly installed environment.


Creating a new initramfs is usually not required, because mkinitcpio was run on installation of the linux package with pacstrap.

For LVM, system encryption or RAID, modify mkinitcpio.conf(5) and recreate the initramfs image:

# mkinitcpio -p linux

Root password

Set the root password:

# passwd

Boot loader

See Arch boot process#Boot loader for a list of Linux-capable boot loaders.

Note: If you have an Intel or AMD CPU, enable microcode updates.


Exit the chroot environment by typing exit or pressing Ctrl+D.

Optionally manually unmount all the partitions with umount -R /mnt: this allows noticing any "busy" partitions, and finding the cause with fuser(1).

Finally, restart the machine by typing reboot: any partitions still mounted will be automatically unmounted by systemd. Remember to remove the installation media and then login into the new system with the root account.


See General recommendations for system management directions and post-installation tutorials (like setting up a graphical user interface, sound or a touchpad).

For a list of applications that may be of interest, see List of applications.