Talk:Installation guide

From ArchWiki
(Redirected from Talk:Beginners' guide)
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)

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)

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)
Clear enough, close. -- Blackteahamburger (talk) 01:58, 10 August 2020 (UTC)
This should be explained in the guide or at least in Network_configuration#Local hostname resolution. Explaining stuff in the edit summary or on talk pages is not enough. -- Lahwaacz (talk) 09:43, 10 August 2020 (UTC)

Wording in example layout table and size of EFI partition

Formatting the ESP

I believe myself that the partition table should be modified. When Going through the install, it was confusing how swap was the last partition, usually suppose to be the partition before Root, as if the computer loads up swap before user login. Didn't realize that a GPT disk needed to be formatted until reading this guide: . Would recommend at least linking to this section of the document or even input Format partition section within the Wiki. Shaggy (talk) 20:15, 29 June 2020 (UTC)Shaggy

The order of partitions is irrelevant and it has (mostly) no effect on booting. The fact that the ESP needs to formatted after its creation cannot be simply stated, as it could be misinterpreted as requiring to always format it, even if is an existing partition that already has a file system.
After reading an anecdote, I think moving swap before root should be considered :D
-- nl6720 (talk) 09:39, 1 July 2020 (UTC)
I've been thinking, how about placing the mkfs.fat -F32 /dev/sdxY command in Installation guide#Format the partitions. EFI system partition#Format the partition could instead be modified to omit the FAT type (i.e mkfs.fat /dev/sdxY). FAT32 is a recommendation, but not mandatory, thus it's more appropriate for the Installation guide, and this would allow to document the 2 MiB FAT12 formatted ESP, used by User:Eschwartz and others, in the EFI system partition article. -- nl6720 (talk) 11:14, 13 August 2020 (UTC)
I guess that's reasonable, if you add the note that an existing EFI partition may have to be preserved. (cf. User:Alad/Beginners'_guide#Format_the_partitions) -- Alad (talk) 20:10, 14 April 2021 (UTC)

HiDPI on the console

With an ever increasing number of HiDPI displays, including at the begging of the article a section about adjusting the scaling factor or changing the font can be helpful, see HiDPI#Linux_console. Goetzc (talk) 02:21, 8 August 2019 (UTC)

It could be added as an example for setfont in Installation_guide#Set_the_keyboard_layout. The issue I have is that HiDPI#Linux_console mentions that tty2-6 may be unusable, while the Installation guide specifically instructs to change ttys as required in Installation_guide#Boot_the_live_environment. -- Alad (talk) 13:07, 7 September 2019 (UTC)
May be as an example for the line "See README.bootparams for a list of boot parameters" Installation_guide#Boot_the_live_environment, it could be specified to hit e button to edit the boot entry and add the following parameters to the boot line, like video=1920x1080 if you have HiDPI display. -- Xzorg6 (talk) 22:41, 15 December 2019 (UTC)
video= will just change the resolution. To get a bigger font on the console, you need CONFIG_FONT_TER16x32=y in the kernel config and fbcon=font:TER16x32 in the kernel command line. Since the official kernels don't enable CONFIG_FONT_TER16x32, someone will need to open a bug report asking for it. After that, the instructions for setting the fbcon=font:TER16x32 kernel parameter could be added to the wiki. -- nl6720 (talk) 06:52, 16 December 2019 (UTC)
linux 5.5.6.arch1-1 (currently in testing) has CONFIG_FONT_TER16x32=y (FS#64861). If if gets move to core before March, then the March iso will have it. It's probably a good idea to start drafting a tip to place in Installation guide#Boot the live environment. -- nl6720 (talk) 11:12, 26 February 2020 (UTC)
And just after I wrote this, the package was moved to core. -- nl6720 (talk) 11:27, 26 February 2020 (UTC)
I'm seeing multiple claims[7][8][9] that people with HiDPI screens are getting the TER16x32 font. I was not aware that the kernel chooses a font depending on screen size. Can anyone confirm that this really is the case? If it really works that way and unless FS#65680 messes this up, then there's nothing to add to the Installation guide about this topic. -- nl6720 (talk) 06:02, 11 March 2020 (UTC)
As per the decision to use ter16x32 is not based on screen size but only resolution.So even though a 1080p screen may be hidpi it does not use ter16x32 M.Srikanth (talk) 10:17, 11 May 2020 (UTC)
At least that part is now clear, thanks. The first step should be to get HiDPI#Linux console up to date. After that, as I've said before, a tip for the installation guide can be drafted. -- nl6720 (talk) 11:04, 11 May 2020 (UTC)
I fixed the page and removed the template M.Srikanth (talk) 12:25, 11 May 2020 (UTC)

First mention of /mnt in example partition layout

/mnt is mentioned at mount point in Installation_guide#Partition_the_disks, while /mnt is made explicit two sections later in Installation_guide#Mount_the_file_systems. As I recall it, this was changed because some users blindly copy pasted commands and mounted /boot on the live system, instead of /mnt/boot. Some options:

  • Introduce another column describing the mount point on the installed system.
  • Actually explain /mnt early.
  • Revert the "mount point" to not include /mnt.

-- Alad (talk) 13:03, 7 September 2019 (UTC)

I don't understand what's the actual problem here... -- Lahwaacz (talk) 09:36, 8 September 2019 (UTC)
From what I read on #archlinux-wiki, this comes from where the user was confused by the lack of root mountpoint (i.e. /mnt vs /). A question could be raised, if we should concern ourselves with users who have strong opinions about the wiki content yet can't be bothered to propose improvements in the talk pages...
About Alad's proposed options: I disagree with the first option, I think it will just complicate things even further. I support the third option and maybe adjusting the column header like in Special:Diff/581800.
I'd actually would like to go even further and change the commands run from outside chroot to be visually distinct, e.g.:
root@archiso # mount /dev/sdX1 /mnt
I think it would better solve the underlying issue.
-- nl6720 (talk) 15:26, 8 September 2019 (UTC)
I'm not overly fond of the longer column name. For the last proposed option, I may agree if this is formalized in Help:Style, so that it is not specfic to the Installation guide. -- Alad (talk) 11:20, 10 September 2019 (UTC)
Adding it Help:Style was my intention, since other articles, too, will need to use that style for some commands. I'm thinking of creating a template for it: Special:Permalink/581945. -- nl6720 (talk) 10:19, 11 September 2019 (UTC)
Sounds good to me, I'd just prefer the regular (non-bold) font for the prompt as above. -- Alad (talk) 21:54, 13 September 2019 (UTC)
Special:Permalink/582327. Are there any other opinions about creating such a template? Or should I take this discussion to Help talk:Template per Help:Template#Creation? -- nl6720 (talk) 18:31, 14 September 2019 (UTC)
  1. How are you going to call the template? This template would probably add to the Help:Template#Code formatting templates series, should it be named in a consistent fashion?
  2. Should this template support custom prompts, and if so, should it be called "pc" (from "(custom) prompted" code)?
  3. I don't like the red color too much, if bold is not an option maybe we can go green|purple|blue, something that recalls less a warning of some kind? Or can we just leave it with the default font color? Or a slightly fainter black?
  4. I haven't looked well into it, but maybe we can instead add an optional argument to Template:bc and Template:hc that prefixes a custom (colored) prompt? I wouldn't see a problem with repeating "root@archiso #" in every instance, or we may derive the new template from those two at that point.
  5. The template should probably be derived from Template:bc in any case, for simpler code, see User:Kynikos/Template:Sandbox2.
-- Kynikos (talk) 17:36, 16 September 2019 (UTC)
  1. Initially I was going to call it Template:Archiso since it would be Archiso-specific, but I'm starting to think that creating a more general-purpose template would be better. It could then be used in PostgreSQL and the [postgres]$ convention would get formalized in Help:Style. Now the issue is the [user@peer-a]# in Template:hc used in WireGuard. I'd rather not create two new templates, but I'm having trouble getting Template:Sandbox to work :(
  2. I like your "Template:pc" suggestion.
  3. Be glad I didn't post my first draft that was slightly more colorful. From your offered colors, I'd choose purple.
  4. I'd rather not mess with the established templates just for this change, so I'd prefer creating a new template.
  5. I didn't even think about using Template:bc. Is it a good idea to do that? The new template might need to be updated if Template:bc is ever changed in an incompatible way.
-- nl6720 (talk) 07:33, 17 September 2019 (UTC)
Yeah, after viewing your attempts and looking into it myself, I think modifying bc/hc is out of discussion, it would add too much code/style for so little use.
Thinking about this again one day after, I feel I'm realizing that my concerns in general may descend from the fact that we're going to create a template to represent (block) code, even though we already have 2 which basically do the same thing, including allowing to include a prompt; the only addition of this "Archiso" or "pc" template would be the formatting around the prompt, so why not keep it simple (I know, "simplicity" is often subjective and controversial) and instead either make a Template:Archiso to be used like {{bc|{{Archiso}} mount /dev/sdX1 /mnt}} or Template:ps (or Template:PS) to be used like {{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}? They also work with Template:hc and space-prefixed code blocks!
Putting the choice of color aside, if the above idea of a standalone prompt template isn't welcome, I think my second choice would be to make two Template:pbc and Template:phc that work like {{pbc|$|ls}} and {{phc|$|ls|...}}, with the style rule to use them only in case of complex prompts. I'd still derive them from bc/hc to inherit any changes that we'd decide to make to them, and avoid repeating that ugly <pre> hack even more.
Otherwise I give up and accept the Template:Archiso that works like {{Archiso|mount /dev/sdX1 /mnt}}, in the hope that one day we won't need an analogous "hc" version.
-- Kynikos (talk) 14:24, 17 September 2019 (UTC)
I can't say I really like the idea of {{bc|{{Archiso}} mount /dev/sdX1 /mnt}} or {{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}. I'd prefer creating Template:pbc and Template:phc.
I still don't get what's wrong with Template:Sandbox. It should just work:
prompt # command
-- nl6720 (talk) 04:43, 18 September 2019 (UTC)
FWIW (and a bit of fun) I've fixed Template:Sandbox, although I'm not sure if we really need that level of automation ^^ I stick to my position above, is there a third (or more) opinion? -- Kynikos (talk) 15:48, 18 September 2019 (UTC)
I think you like the #800080 shade of purple, right? ;-) Lahwaacz (talk) 11:39, 21 September 2019 (UTC)
Yes, I do like that one :D but I think it would be too bright for this template. -- nl6720 (talk) 11:52, 21 September 2019 (UTC)

Changes for the base package

Installations without base

The base group was replaced with the base package: [10] This change was reflected in Installation_guide#Install_the_base_packages with [11]

With [12], I removed the sentence "We only officially support installations that have the base package installed." because it opens a new rabbit-hole when something is "officially supported" in the installation guide, is not. With this sentence included, pretty much anything (including "installations" that are not, or only partially, followed from the Installation guide) may be supported merely from having the base package installed.

On the other hand, some notion that removing the base package results in an installation that is "not Arch" makes sense, but we should discuss on the best approach on doing this. -- Alad (talk) 10:22, 6 October 2019 (UTC)

Haven't seen a big impact from this. Closing this discussion. -- Alad (talk) 19:48, 14 April 2021 (UTC)

Buggy graphics driver

Can there be a hint that nomodeset parameter could be used if the graphics driver is buggy (I've heard nouveau may be buggy sometimes) M.Srikanth (talk) 04:47, 12 May 2020 (UTC)

Add a reference to btrfs snapshots in <#Partition the disks>

new users may be unfamiliar with subvolumes, providing links to btrfs and snapper will point them in the right direction.

this is important because moving to btrfs snapshots afterwards will involve reformatting.

—This unsigned comment is by Edgeworth (talk) 02:12, 4 July 2020‎. Please sign your posts with ~~~~!

All file systems, including btrfs and its subvolumes, are unrelated to partitioning. The example layouts in the installation guide cover only swap [+ ESP] + the root partition, so if you decide later that you want to use a btrfs subvolume for e.g. /var, there is no need to change the partitions. -- Lahwaacz (talk) 08:39, 4 July 2020 (UTC)

but what if you wanted to have / be a subvolume? So a use case i could envision is:

  • creating a snapshot called @ and mounting it at /
  • another called @home and mounting that at /home
  • Another called @snapshots and mounting that at /.snapshots

this way you could use ‘’Timeshift’’ and ‘’Snapper’’

but, I may be mistaken, wouldn’t this be significantly easier to do before hand rather than after the fact? Maybe just a little bubble pointing users in the right direction, I say this because I only recently discovered btrfs and timeshift and I just never stumbled accross it, so making it more visible would have been very helpful.

Edgeworth (talk) 01:38, 5 July 2020 (UTC)Edgeworth

Btrfs subvolumes are created after formatting the file system not during disk partitioning. "Installation guide#Format the partitions" links to "File systems" which has a link to "Btrfs". If you want to recommend using subvolumes, add a tip to Btrfs#File system creation. -- nl6720 (talk) 14:09, 5 July 2020 (UTC)
ok that stands to reason, but the example in "Installation guide#Format the partitions" is ext4 and if a new user just has no idea about COW file systems like btrfs/zfs there’s a good chance that they will never discover it, atleast until after they’ve installed the system.
Perhaps a tip box near that example to suggest researching btrfs subvolumes and snapshots could be helpful? ideally with a link to Snapper#Suggested_filesystem_layout.
Snapshots are really helpful with a rolling release so i’d argue they should be encouraged.
Edgeworth (talk) 01:02, 6 July 2020 (UTC)Edgeworth
If the new user has no idea about COW file systems, there is a good chance that they have no idea about any type of file systems, so they should review the File systems page (which is linked from the section before showing the example with ext4) and select the file system they like. Adding file system-specific notes or even recommendations to the installation guide does not make sense - they should be placed in sections related to the subject, so that users of other file systems are not bothered with them. As noted, that's Btrfs#File system creation in this case - everybody who had initially no idea about COW file systems and who decides to use Btrfs must go through that section before installing their system. -- Lahwaacz (talk) 07:27, 6 July 2020 (UTC)
I agree that the bulk of the material should be on a dedicated page but there are many pages to read and only so much time in the day, perhaps a stronger recommendation to review the file system page then? perhaps saying something to the effect of “file systems such as ext4, btrfs, zfs and so on have various strengths and weaknesses, users are advised to read the file systems page before proceeding.”
the idea being that users new to linux, or just arch, get exposed to as many helpful things as possible just by going through the installation guide
Im sure there are users who know enough to get going that simply don’t realise that snapshots are a thing (i.e. there not on windows), but I wouldn’t say it’s fair to suggest they don’t know anything about file systems either.
anecdotally ive been using linux for nearly 10 years (arch for 3) and btrfs just never really came up on my radar until last year, i’m not a computer scientist so i never really went looking because I didn’t know it bought anything to the table and so if the installation guide pushed me in that direction I could have avoided a lot of grief by using snapshots.
Edgeworth (talk) 07:41, 6 July 2020 (UTC)Edgeworth
There's no reason the install guide would specifically advocate on type of file system, and ext4 is merely an example (the simplest and most common one). It's up to the user to decide to how far they want to further investigate. Closing -- Alad (talk) 19:50, 14 April 2021 (UTC)

GitLab blobs in Lynx

Links to files (blobs) on are not readable in Lynx (or any other console web browser); see

Should the Installation guide link to raw files instead?

-- nl6720 (talk) 12:29, 4 August 2020 (UTC)

Maybe you could ask svenstaro to add it to -- Lahwaacz (talk) 12:36, 4 August 2020 (UTC)
It has been filed under nice to have. -- nl6720 (talk) 17:19, 4 August 2020 (UTC)

RAM usage

Attempting to boot the ISO with 532MB RAM (VM) and it hangs at attempting to mount the ISO. Changing RAM to 544MB allows the Arch ISO to boot, so I suspect the amount of RAM needed on the page isn't accurate. Beepboo (talk) 14:11, 17 August 2020 (UTC)

Updated again. Note that after installation the system can still easily get under 512 MB. -- Lahwaacz (talk) 14:05, 17 August 2020 (UTC)
Lahwaacz, it's missing fullstop "." in the end of this sentence. -- Josephgbr (talk) 23:49, 17 August 2020 (UTC)
Actually not missing (found it just now), but should it be after the reference link? -- Josephgbr (talk) 23:51, 17 August 2020 (UTC)
It's used the same way also in Installation guide#Select the mirrors. -- Lahwaacz (talk) 07:01, 18 August 2020 (UTC)
From what I've seen, most wiki pages use it the same way. -- nl6720 (talk) 07:52, 19 August 2020 (UTC)
There is actually an open discussion about this: Help talk:Style/Formatting and punctuation#Reference links before or after punctuation marks? -- Lahwaacz (talk) 08:05, 19 August 2020 (UTC)

Boot issues faced when installing on modern machines.

One may encounter "Invalid signature" when trying to boot from the installation media on a machine with secure boot on and keys not cleared.

Also, after installing on a NVME SSD, one need to set the drive to AHCI mode instead of Intel Optimized (in bios configuring panel), otherwise you just can't boot into the system.

Sffred (talk) 00:05, 24 September 2020 (UTC) Sffred 1600905886

AHCI is a SATA controller operation mode, it shouldn't have anything to do with NVMe. You can add a section to Partitioning#Troubleshooting about changing the SATA mode if Linux doesn't see SATA disks, but make sure you're using the correct terms. -- nl6720 (talk) 06:27, 25 September 2020 (UTC)
Some motherboards support SATA over the M.2 port, which may be the source of this confusion. -- Lahwaacz (talk) 07:33, 25 September 2020 (UTC)
w:M.2#Storage interfaces lists "PCI Express using AHCI" as an option, but it's unclear if such a mode is actually implemented by any firmware, and even if it was, it should not be recommended as it would drastically reduce the drive's speed. From what I could find[13][14][15], it looks like manufacturers simply interpret "SATA mode" being set to "AHCI" on NVMe controllers to mean "use native operating mode without firmware RAID". -- nl6720 (talk) 08:33, 25 September 2020 (UTC)
While on the topic of SATA (and non-SATA) operating modes, any thoughts about the backup GPT header corruption warning in GPT fdisk#Convert between MBR and GPT? -- nl6720 (talk) 08:37, 25 September 2020 (UTC)
Sorry, I have no idea... -- Lahwaacz (talk) 10:57, 26 September 2020 (UTC)
I added a note about Secure Boot to Installation guide#Boot the live environment. If anyone's wondering why it says "installation images" then that's because of ipxe.efi (the EFI binary for Netboot). -- nl6720 (talk) 06:52, 28 September 2020 (UTC)

Expand Boot loader section

All commands in this article are simple and self-explanatory, they can be followed one by one from this one page. However, a more difficult process of creating a boot loader is not documented here. The details are scattered (I needed to use at least and

I propose to expand this section and write an 'official' or 'most used' example of the configuration. If there are two such variants (say grub2 and efibootmgr), write for both of them. Content duplication is not good, but on this page we can give the basic options for boot loader creation (as for other commands), while on the dedicated pages there are more details.

Ynikitenko (talk) 17:51, 14 November 2020 (UTC)

There is no 'official' or 'most used' example. You make your choice and follow the directions on the page for that setup.
Scimmia (talk) 21:54, 14 November 2020 (UTC)
Well, it seems there is some. On the first link I mentioned there are exactly two Typical mount points. On the second link in the beginning it's said that "Using a boot loader is recommended if you have multiple kernel/initramfs pairs and your motherboard's UEFI boot menu is not easy to use. " Some installations are more or less connected to the whole system. On the ESP page there is a phrase "This allows pacman to update the kernel directly". Even if one really needs to follow another page for the boot, it would be useful to present the basic choices on the installation page. The other pages are much bigger than the installation page and thus less productive to use (you have to carefully read lot of text, which is not necessary, because only small pieces of that are relevant to most users). Ynikitenko (talk) 08:31, 15 November 2020 (UTC)
Even on the mount points there have been large discussions in the past on which should be the "typical" choice. With a complex, user-facing software such as the boot loader I'd say finding any agreement on the "typical" choice (even amongst editors) is highly unlikely. Besides that pointing out which pieces are "relevant to most users" is anything but trival.
That said, if you have a concrete wording in mind for the boat loader section feel free to write it here. -- Alad (talk) 17:08, 15 November 2020 (UTC)
I think the boot loader section appears too late in the guide, especially considering that if you're using GRUB (like most distros), you need to create a partition but the boot loader section is further down the guide, well after you've done some setup of the system. By that time, you're already chrooted into your drive. Of course, this requires you to have read ahead in the guide but you can't assume everyone will do this. Plus to me, the boot loader needs some consideration early on in the setup.
The simplest solution would be to have a note before the "Example layouts" table here Installation guide#Partition the disks. The main thing to add is that if using GRUB as a boot loader, it's required to create a 1MB partition for it. In my case, by the time I reached the boot loader part, I'd already allocated all of my hard drive space across the EFI, swap and root partitions and would've had to start again knowing that I had to set up the partitions with the boot loader (GRUB) in mind. Maybe something like the below would work:
Note: At this point, you might need to start thinking about the kind of boot loader you intend to use. If you intend to use GRUB, you will need to create the partition for it. See the instructions in GRUB#GUID Partition Table (GPT) specific instructions on how to do so.
-- Phanatik (talk) 21:35, 02 December 2020 (UTC)
This only applies when the boot mode is BIOS, but UEFI is becoming more and more common. The Installation guide#Partition the disks section already includes the most common partition layouts and has a link to even more examples (including one with a so-called BIOS boot partition for GRUB). -- Lahwaacz (talk) 22:58, 2 December 2020 (UTC)
I think this discussion is a separate one from what I started, and probably should be moved out for clarity. However, I can see that the "example layouts" here are incomplete and inconsistent. For example, /dev/swap_partition is included twice in BIOS and UEFI setups, though it's common to both of them. The partition for / is missing in both examples though. There is definitely some room for improvements. -- Ynikitenko (talk) 16:19, 30 December 2020 (UTC)

Expand the list in 'Install essential packages'

I suggest adding as the first (or second) bullet item

Rationale: Arch installation doesn't include them by default (even the archiso doesn't include a 'grub' package). But it is no less important than a special file system or LVM/RAID in that list.

Ynikitenko (talk) 15:35, 16 November 2020 (UTC)

That has it's own section already. Scimmia (talk) 15:58, 16 November 2020 (UTC)
I think that it's more convenient to install all packages at once with pacman, and not call it several times disrupting the workflow (and I agree that in the section "Boot loader" it's written "Choose and install a Linux-capable boot loader."). For example, I had a long time of installing and selecting the boot loader (many people also report that to install Arch takes several days from them). I was a bit surprised that I had to install grub package when I reached that point. I didn't use internet at all at that time and it took a small time to start wifi to download one package.
Besides, I think that "install bootloader" in that section means a whole installation (the recipe for which we discussed in a previous talk section), while here I mean exclusively "install a bootloader package". Ynikitenko (talk) 16:51, 16 November 2020 (UTC)
Obviously "install a Linux-capable boot loader" includes installing a package for whatever boot loader the user chooses. If we included a statement like "install a boot loader package" close to the pacstrap command, many people would think that they have already installed a boot loader and don't have to do that later on. It is handled much better as it is now. -- Lahwaacz (talk) 19:03, 16 November 2020 (UTC)
Maybe you are right that the current situation is better, but I think that the reasonment "If we included a statement like "install a boot loader package" close to the pacstrap command, many people would think that they have already installed a boot loader and don't have to do that later on. " is wrong, because
a) Arch Linux potential users can distinguish between a package installation and a boot installation
b) we can reword the second instruction as "Make system bootable" or similar, if there appears confusion.
I proposed to expand the "Boot loader" section, so the exact wording there at the moment may not be essential, but still. Ynikitenko (talk) 19:20, 16 November 2020 (UTC)
P.S. If we think about the wording, then the first section "Install essential packages" looks like we install all essential packages there, which is not the case. I think to add a line there would be more coherent and make no harm. Ynikitenko (talk) 19:23, 16 November 2020 (UTC)
There's no harm in installing packages while in chroot instead of the pacstrap step. In fact it makes it slightly easier to see the pacman output and catch any mentions of optional dependencies.
Regarding your "a)", it is not always true. The structure of boot loader articles have caused confusion in the past. IMHO all boot loader articles should follow what was done in rEFInd and split the installation of the package and boot loader into separate sections.
-- nl6720 (talk) 11:03, 18 November 2020 (UTC)
I can't be sure now, but I think that internet was unavailable in arch-chroot (that's why there exists pacstrap, which installs into the given directory). I'm not sure optional dependencies are important here. I remember well, however, that my installation involved several days, and when I got to 'install booloader', I had to reconnect to the internet (which took some minutes more), and also it surprised me (I thought that "essential packages" are all installed, as it's worded in this guide).
"split the installation of the package and boot loader into separate sections" - this is what I propose in this wiki. If there remains a slight confusion - add several words to explain. Ynikitenko (talk) 13:04, 18 November 2020 (UTC)
You're wrong about having to reconnect to the network.
Essential packages *were* all installed, the kernel already includes a bootloader that can be used. If you chose something else, that's fine, but it's not essential.
They were talking about the individual bootloader pages being split more, not any changes here.
Scimmia (talk) 13:44, 18 November 2020 (UTC)
"the kernel already includes a bootloader that can be used" - if that were the major case, this page would reference just EFISTUB, not all possible boot loaders. However, I already proposed to select one boot loader as the major case, and you objected there with the words "There is no 'official' or 'most used' example." Now you say that other boot loaders not in the kernel are optional, "not essential". IMHO, a boot loader is an essential thing for the system, because Linux won't be able to boot without that.
Sure, after I rebooted and booted the archiso again, I had to re-enter my wifi credentials and run a handful of commands for that. Moreover, I connect to WiFi from a smartphone, and I initialize an access point every time there. "They were talking about the individual bootloader pages" - I think the same logic applies here. Ynikitenko (talk) 14:47, 18 November 2020 (UTC)

Consider warning users about the additional steps required when selecting a partition other than /boot as their ESP

I understand that I have a responsibility to read through documentation other than just the install page, but the example layouts section implies that /efi and /boot can be used interchangeably. This is not the case and I think users would benefit from a more explicit statement of the importance of /boot:

  • the built kernel always goes there unless you build the kernel yourself
  • the microcode goes there
  • all (?) bootloaders can access these files if the ESP is set as /boot, not necessarily true when selecting a different ESP

I chose systemd-boot and, from the outside looking in, it was not clear that "Cannot launch binaries from partitions other than the ESP or the Extended Boot Loader Partition (XBOOTLDR partition)" would be a problem until I had to chroot back in from a failed boot and copy the files from /boot.

I think other users would benefit from being told explicitly to be careful about which bootloader to choose if they choose an ESP other than /boot right there on the install page.


Dedushka (talk) 20:19, 15 December 2020 (UTC)

What about the warning was unclear? Scimmia (talk) 14:36, 16 December 2020 (UTC)
Thanks for the notice. My thought about that was to propose a "default" way or two to install boot loaders on this page (I did that in a separate talk section above). -- Ynikitenko (talk) 16:24, 30 December 2020 (UTC)

Swap partition vs swap file

Would it be reasonable to stop suggesting using swap partitions and instead recommend creating a swap file? Will genfstab work in a chroot environment to create a correct fstab? Managor (talk) 12:50, 3 February 2021 (UTC)

There's no reason why swap files should be given preference over swap volumes, using one or the other (or both) is a choice left to the user. Installation guide#Example layouts already mentions swap files, although, maybe some reference to them could also be added to Installation guide#Format the partitions and Installation guide#Mount the file systems. -- nl6720 (talk) 14:51, 4 February 2021 (UTC)

/etc/hosts: dual ip4/ip6 localhost prevents ip4 from working

I recently set up a new system with /etc/hosts copied from the guide:	localhost
::1		localhost	myhostname.localdomain	myhostname

I found localhost did not resolve to which caused some docker comms to fail etc.

Removing or renaming the ip6 binding allowed ip4 localhost to work again, so perhaps the following should be used in the guide instead:	localhost
::1		ip6-localhost	myhostname.localdomain	myhostname

—This unsigned comment is by Alexheretic (talk) 09:18, 19 February 2021‎. Please sign your posts with ~~~~!

Explain howto adjust the size of root partition

It would be useful to add a note, under "Install essential packages", on how to extend the size of root partition e.g. `mount -o remount,size=1G /run/archiso/cowspace`. The reason is that depending on what one considers "essential" for their system, they may run out of airootfs COW space when running `pacstrap`. Examples: installing ZFS alongside with kernel; installing more than one version of kernel (e.g. linux and linux-lts), installing a non-base text editor. —This unsigned comment is by Bronekk (talk) 10:43, 28 March 2021 (UTC). Please sign your posts with ~~~~!

pacstrap places the package cache on the target (i.e. the mounted future root file system). Why would you run out of space? -- nl6720 (talk) 10:56, 28 March 2021 (UTC)
thank you for explaining how this is supposed to work - I was really puzzled. This has broken for me when I used -C for custom pacman.conf ; I guess I would have to make the pacman.conf refer to /mnt as cache ... —This unsigned comment is by Bronekk (talk) 09:09, 29 March 2021 (UTC). Please sign your posts with ~~~~!
You can simply remove/comment-out any CacheDir in your pacman.conf and it should use the default. -- nl6720 (talk) 09:53, 29 March 2021 (UTC)
I quite agree, this should be on this page. I also ran out of disk space.
I wrote the article for you so you can just copy & paste it:

Adjusting the size of root partition

If you get the following error message, you may need to adjust the size of the root partition of the Archiso.

error: partition / too full: 63256 blocks needed, 61450 blocks free
error: not enough free disk space
error: failed to commit transaction (not enough free disk space) 
Errors occurred: no packages were upgraded.

To adjust the size of the root partition on the live Archlinux system, hit the TAB key to edit the kernel parameters. Append cow_spacesize=2G at the end to get 2G size for the root partition. Press Enter to continue booting into the live system. You can check the size of the filesystems by running:

$ df -h

You can also adjust the root partition size on the fly by running this command:

# mount -o remount,size=2G /run/archiso/cowspace

—This unsigned comment is by Promike (talk) 14:50, 14 April 2021 (UTC). Please sign your posts with ~~~~!

Sounds like you were trying to update the system? Simpler solution: don't do that.
Scimmia (talk) 15:54, 14 April 2021 (UTC)
This is a wrong assumption. I was trying to use other programs beside the ones that archiso provides.
There are only a limited number of programs available on the ISO.
Maybe they suit some people needs, but they certainly don't suit mine.
(And since it wasn't me who created this talk, I'm sure many people agree with me)
—This unsigned comment is by Promike (talk) 16:07, 14 April 2021 (UTC). Please sign your posts with ~~~~!
Does this have anything to do with installing Arch? And please start signing your posts.
Scimmia (talk) 16:23, 14 April 2021 (UTC)
Not much.It's about temporary dealing with the live system (or testing it).
Let me know if there were a better place for my description. I haven't found any.
—This unsigned comment is by Promike (talk) 16:59, 14 April 2021 (UTC). Please sign your posts with ~~~~!
So it comes down to one person with a bad config, and another completely off-topic. I think this can be safely closed.
Scimmia (talk) 18:25, 14 April 2021 (UTC)
You still have forgotten to say where you think my description would be more appropriate than here.
The info is nowhere available in the Wiki!
—This unsigned comment is by Promike (talk) 18:56, 14 April 2021 (UTC). Please sign your posts with ~~~~!
System installation is already provided by the existing ISO; other purposes are off-topic for this article. Even so, if you really want more packages on the ISO the guide links README.bootparms already, or you can create your own ISO following instructions in archiso.
Side note: posts are signed with ~~~~, not Template:Unsigned. -- Alad (talk) 19:32, 14 April 2021 (UTC)
I accept that this description may belong to somewhere else. I wouldn't say it's completely offtopic, though.
Users may need further programs (e.g. different text editors) to install Archlinux. If they run out of disk space, they cannot do that.
I'm also aware of the archiso page but my description solves a different issue. I personally don't want to create a custom live Arch that I will regularly use.
I use the vanilla Archiso to maintain my system when it breaks, or temporary use it when no archlinux is available.
It took me hours to gather up all this information that was scattered all over the internet. I wish somebody had already written for me.
Creating a custom archiso is a long time, while modifying just the size of the root partition is less than a second. I think it fully fulfills the KISS principle.
Promike (talk) 20:26, 14 April 2021 (UTC)
As mentioned above, README.bootparms documents the cow_spacesize parameter. tmpfs online resizing is covered in tmpfs#Examples.
If some essential package really needs be available in the installation environment, then it could be added to future ISOs.
-- nl6720 (talk) 06:51, 15 April 2021 (UTC)
Everything is in the manuals somewhere, therefore the whole Archwiki is superfluous.
Promike (talk) 08:16, 15 April 2021 (UTC)
Exactly, we're going to shut it down. -- Lahwaacz (talk) 08:26, 15 April 2021 (UTC)

Edit installation guide: lynx, boot loader

In the section software to install with pacstrap, add lynx to the documentation subsection. And add boot loader to a separate subsection. These are more important packages, than LLVM (what's this?) and RAID, and are used in personal laptops. If one forgets to install them with the base system, then one has to install grub in arch-chroot; and lynx after booting the installed system. Admh (talk) 21:08, 28 March 2021 (UTC)

How is lynx so important? It's certainly not more important than LVM (notice this is not LLVM) and RAID tools for those that use those things.
The bootloader already has it's own separate subsection.
Scimmia (talk) 13:35, 29 March 2021 (UTC)
lynx serves a special purpose in the install guide to browse the wiki, in the installed system people can use whatever browser they prefer. Closing -- Alad (talk) 19:36, 14 April 2021 (UTC)


I skipped steps in the guide so I faced a weird crash in gnome without any explanations. I suggest a note.

Note: Many of them assume that you have your timezone or locales set up. Make sure you have followed all the steps.

Escope (talk) 10:11, 2 April 2021 (UTC)

The reader is supposed to follow all the steps. If we apply that to other pages, the pages need a boatload of notes to make sure the reader did not skip any steps. A common functional system has properly configured locales and timezones.
Since this is GNOME-specific however I would at most add a section into GNOME/Troubleshooting or even General troubleshooting, but I still think this is out of scope to be honest. Many applications may not work properly when the timezones or locales are not correctly configured.
-- NetSysFire (talk) 15:30, 2 April 2021 (UTC)
The reader is not supposed to follow all the steps in case one doesn't worthy of attention. In my humble opinion, that's why it has huge advantage over the "Next-Next-Finish" approach. Unconfigured locales or timezones are obvious to many people, but my inexperience made me spend some time to sorting out. The other pages are highly deep and clear about the steps and why they are needed, my eyes enjoy such notes, pages are boatloaded already and I like it a lot =D. Thank you for your attention to this little change.
-- Escope (talk) 00:23, 3 April 2021 (UTC)
If you're inexperienced, what makes you think you can judge if a step is necessary or not? You thought you knew better than the people that wrote the guide and found out that you didn't. Not something that needs changed here IMO.
Scimmia (talk) 01:57, 3 April 2021 (UTC)
The ArchWiki should also be about the why-aspect. I am in favor of adding e.g a note about why they are needed and why some applications may crash or behave strangely without properly configured timezones/locales. If you know e.g a nice blog post about this topic, why not add something like this?
Note: Some applications may behave in strange ways or even crash when the timezones and/or locales are not properly configured. See this informative blog post to know why that is.
The note needs obviously some rewording, but something like this would fit in well in my opinion.
-- NetSysFire (talk) 02:02, 3 April 2021 (UTC)
Adding a brief "why" would be ok, but using Template:Note would be too much. I've also always wanted to emphasize the "and" in Installation guide#Localization, since it's easy to miss (even some of the translated installation guides do not mention en_US.UTF-8 UTF-8). --- nl6720 (talk) 08:48, 3 April 2021 (UTC)
People who want to know the "why" can already consult the relevant articles. That said, consistency is lacking: some sections explain in detail why a step should be performed (such as Installation_guide#Verify_signature), whereas Installation_guide#Configure_the_system is mostly a checklist of steps with brief instructions how. The solution isn't obvious: adding notes all over would likely more distract than clarify. -- Alad (talk) 19:41, 14 April 2021 (UTC)
I'm definitely apposed to adding notes, but I don't see why we couldn't add brief "why"s without them. -- nl6720 (talk) 06:55, 15 April 2021 (UTC)

Network Configurarion localdomain


Is ".localdomain" string to be added as it is? Isn't localdomain supposed to be set by user like myhostname?

If yes, then that should be reflected in the Installation Guide as:


Add matching entries to hosts(5):

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


Rootkea (talk) 04:42, 9 April 2021 (UTC)

w:.local serves a special purpose, but .localdomain indeed seems a placeholder with no special meaning. I'll make the change, thanks. -- Alad (talk) 19:44, 14 April 2021 (UTC)
The question now is, if it's a placeholder, what do you replace it with? Not every system has (or needs) a real domain name. -- nl6720 (talk) 07:00, 15 April 2021 (UTC)

Commands showing how to do instead of/along with text saying what to do


As I have mentioned previously on this talk page I really like Installation guide for being consice and to the point! Instead of just telling what to do it provides commands showing how to do it. e.g. instead of just telling "Mount the root volume to /mnt" it accompanies that text with the command mount /dev/root_partition /mnt showing how to do it. The whole installation guide follows this format and it's very good!

But 2 sections namely "Localization" and "Network configuration" violate this format. I would like to humbly suggest the following changes:

"Localization" (3 suggestions)


Edit /etc/locale.gen and uncomment en_US.UTF-8 UTF-8 and other needed locales. E.g.

# sed -i 's/#en_US.UTF-8/en_US.UTF-8/' /etc/locale.gen

Generate the locales by running:

# locale-gen

Create the locale.conf(5) file, and set the LANG variable accordingly:

# echo "LANG=en_US.UTF-8" > /etc/locale.conf

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

# echo "KEYMAP=de-latin1" > /etc/vconsole.conf


"Network configuration" (2 suggestions)


Create the hostname file:

# echo myhostname > /etc/hostname

Add matching entries to hosts(5):

# cat >> /etc/hosts	localhost
::1		localhost	myhostname.localdomain	myhostname

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


The installation guide should provide direct commands showing how to do instead of/along with the text telling what to do. Precise and to-the-point! The goal is that user should be able to install Arch by having to read the text as less as possible and as far as possible simply executing the commands from Installation guide.

Thanks! :)

—This unsigned comment is by Rootkea (talk) 05:23, 9 April 2021 (UTC). Please sign your posts with ~~~~!

The topic of file editing is already covered in Help:Reading#Append, add, create, edit. There's no need to give preference to one or another way to edit text files. -- nl6720 (talk) 09:19, 9 April 2021 (UTC)
Sorry, didn't read that page. Closing this one. And thank you for adding links to that page. :) Rootkea (talk) 10:20, 9 April 2021 (UTC)

Adding ordinary user should be part of Arch installation


Currently, Installation Guide has link to "General recommendations" page under "Post-installation" section. The "General recommendations" page has recommendations regarding GUI, console improvements, user management, appearance, font etc. All these recommendations are optional to use Arch Linux. User doesn't have to use GUI or set up tab-complete enhancements as recommended to use Arch as these are "General recommendations" but using root account only is like walking with chaninsaw and Flopsy, an adorable rabbit as per the linked SE answer on that page.

Creating and using ordinary user account is not optional. No wonder many distros have ordinary user creation in Installation flow. I would like to request to include adding ordinary user acccount as part of Arch installtion.

Perhaps under "Configure the system" above the "Boot loader" section?

Anyways, Feel free to close/strikeout this issue if you think this is not necessary. :) Rootkea (talk) 10:53, 9 April 2021 (UTC)

That's more about system management than it is about getting the system up and running IMO.
Scimmia (talk) 14:12, 9 April 2021 (UTC)
I wouldn't add an explicit section either, but a link in the last section (Installation guide#Post-installation) might be a good idea. Something like:
See General recommendations for system management directions and post-installation tutorials (like unprivileged user accounts, setting up a graphical user interface, sound or a touchpad).
-- Alad (talk) 09:24, 10 April 2021 (UTC)

Expand Boot loader section to include example commands


I suggest that we expand the "Boot loader" section a bit. Currently, it just tells to install a boot loader and enable microcode updates for Intel/AMD cpu.

Now I understand that there are many different boot loaders and each boot loader in turn has different commands for installation depending on disk partitioning. But I think we should follow "Partition the disks" section which list outs 2 example layouts even if there are n number of different custom partitioning schemes possible.

IMHO An installton guide should be such that user should be able to install that partiular piece of software (at least the basic simple set up) just by following the installation guide. Without having to follow the links to other pages, then read those pages to figure out the commands to be executed.

Yes there are many bootloaders but still we should add example commands for at least any one of them (idealy the one which is most widely used but doesn't matter to me personally. Just pick any one of 'em). It does't mean enforcing a particular choice but to document one possible example exactly like "Partitioning the disks" section is doing.

I would even argue that we should assume the example disk partitions mentioned in "partitioning the disks" section (BIOS with MBR, UEFI with GPT) and provide appropriate commands.

Here is the draft I humbly submit:

Boot loader

Choose and install a Linux-capable boot loader.

For example, to install GRUB on BIOS with MBR set-up:

# pacman -S grub
# grub-install --target=i386-pc /dev/sdX
# grub-mkconfig -o /boot/grub/grub.cfg

where /dev/sdX is the disk (not a partition).

If you have an Intel or AMD CPU, enable microcode updates in addition.

For example, to enable AMD microcode updates for GRUB early loading:

# pacman -S amd-ucode
# grub-mkconfig -o /boot/grub/grub.cfg

As always, my only intention is to make Installation guide as succint as to-the-point as possible for users installing Arch without having to read other wiki pages (at least for basic simple set up). That being said, feel free to close/strikeout this issue if you think the change suggested is not necessary. :)

Rootkea (talk) 11:11, 11 April 2021 (UTC)

'IMHO An installton guide should be such that user should be able to install that partiular piece of software (at least the basic simple set up) just by following the installation guide. Without having to follow the links to other pages, then read those pages to figure out the commands to be executed.'
This is not right. The Installation Guide is specifically NOT that; that was the Beginner's Guide which was removed.
Scimmia (talk) 13:28, 11 April 2021 (UTC)
The problem with using a specific boot loader is the amount of steps preceding it that it must support or cover. The table in Arch_boot_process#Boot_loader should give you a pretty good idea. Since the guide supports MBR, UEFI and all kinds of file systems, you'd realistically have to either have one section for UEFI and one for MBR, or a catch-all section with something like GRUB. This would in turn lead to possible updates in other parts of the installation guide, such as adding an example layout for the special case of GRUB+GPT+BIOS.
In short, covering a "basic" boot loader setup would lead to a more complex installation guide, both in layout (more hard to follow) and maintenance (having to keep information up-to-date over multiple articles). That's precisely why the beginners' guide was abolished, as pointed out above. -- Alad (talk) 20:06, 14 April 2021 (UTC)