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)

Network configuration

once chrooted, one has to configure again

One chrooted, configuration file edited in the previous steps, will have to be redone in the chrooted environment (/etc/systemd/network/ files). This is the same for ntp configuration (/etc/systemd/timesyncd.conf).

This should be worth noting.

—This unsigned comment is by Mrechte (talk) 12:27, 14 May 2019‎. Please sign your posts with ~~~~!

The guide does not say to edit anything under /etc/systemd/ in the first place, so there is nothing to be redone. Furthermore, Installation guide#Network configuration says to "Complete the network configuration for the newly installed environment." -- Lahwaacz (talk) 17:27, 17 May 2019 (UTC)

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

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

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

Wording in example layout table and size of EFI partition

Wording in example layout table

Regarding Installation_guide#Example_layouts:

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. Regid (talk) 14:05, 29 December 2018 (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)
Partioning disks mentions fdisk but better is gdisk /dev/sdX (x representing your drive. mine is sda) then running commands x, z, y, y after that run cgdisk Drillsar (talk) 01:04, 16 May 2019 (UTC)
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: https://wiki.archlinux.org/index.php/EFI_system_partition . 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)

Confusing partition numbers

The partition numbers on this page are confusing. The table calls the root partition /dev/sdX2, while the text below calls it /dev/sdX1. It should be matched for consistency. Sabinscabin (talk) 20:29, 13 April 2019 (UTC)

Probably better to do it as [7] -- Alad (talk) 18:53, 1 May 2019 (UTC)
I propose using a letter with an implied meaning as the partition number. For example, ESP: /dev/sdXE; swap: /dev/sdXS; root: /dev/sdXR. -- nl6720 (talk) 09:05, 4 July 2020 (UTC)
Building on idea from above comments I propose to make whole replaceable part of string a variable denoting purpose of the partition such as /dev/root_partition, /dev/swap_partition and /dev/efi_partition. -- Svito (talk) 09:51, 4 July 2020 (UTC)
This would also be a good place to show a tip that users can also use /dev/disk/by-partlabel/root etc. if they assigned the corresponding PARTLABEL. -- Lahwaacz (talk) 10:18, 4 July 2020 (UTC)
PARTLABEL could trip up those who set up LVM, dm-crypt or RAID (i.e. the cases where the file system is not directly on the partition). -- nl6720 (talk) 10:52, 4 July 2020 (UTC)
/dev/*_partition is not a bad idea. It doesn't assume the type of block device or that all the partition are on the same block device. Although, I don't know how understandable these would be to readers. The naming scheme might need to be explained in a sentence or two. -- nl6720 (talk) 10:52, 4 July 2020 (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[8][9][10] 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 https://lkml.org/lkml/2019/6/18/966 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 https://www.reddit.com/r/archlinux/comments/d0v0j3/is_it_just_me_or_is_the_prospect_of_installing/ 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
code
-- 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: [11] This change was reflected in Installation_guide#Install_the_base_packages with [12]

With [13], 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)

How to write the image to a USB stick?

This is something the wiki page is silent about.

Only https://www.archlinux.org/download/ mention that "The image can be burned to a CD, mounted as an ISO file, or be directly written to a USB stick using a utility like dd." But this is still little information.

I must admit I've never learned the details of writing images to USB sticks. I always used high level tools for that. I thought there was no philosophy - simply write the image, that's all - so in Linux Mint I was always using their tool to write iso images to USB sticks.

Then I tried using this tool to write the Windows installer to USB. This suddenly didn't work. I learned that, contrary to what I had been believing, there were MANY ways an image could be written to USB and the Mint tool was only supposed to support writing Mint installers to USB, not other kinds of images. I ended up using Rufus to write the Windows installer which finally worked, although I did not learn which precise parameters were supposed to be set to which precise values and why. All I know is that *writing images to USBs is more complicated than I thought and that it seemed*.

For this reason, I find the recommendation to 'directly write the image to a USB stick using a utility like dd' confusing. Will it be valid if I type dd if=path/to/arch/installer.archlinux-2020.02.01-x86_64.iso of=/def/sdb, assuming that /dev/sdb is the USB stick? Or should I set some other parameters to something else?

I think that for the sake of completeness the wiki page should include an example of the dd command.

Kind regards, Kmph (talk) 14:12, 12 February 2020 (UTC)

The guide already links to USB flash drive, which shows a lot of the ways to write the iso to an USB, including dd, and covers much more than a simple dd example would. Grazzolini (talk) 14:31, 12 February 2020 (UTC)
IMHO the sentence that links to it is not constructed in the best way. It just lists possible booting options without telling the reader that they need to use any of them.
I think that we should add a "Prepare an installation medium" section between Verify signature and Boot the live environment. And explicitly state that a installation medium needs to be prepared using one of the available methods. Or maybe "medium" would not be the best choice, if PXE is listed among the options...
-- nl6720 (talk) 07:23, 13 February 2020 (UTC)
You can make such a section arbitrarily long and I see no need to duplicate existing articles. -- Alad (talk) 21:36, 30 June 2020 (UTC)
It doesn't have to be long or duplicate other articles. A simple 2–3 sentence paragraph (or a bullet list) should suffice. The first sentence from Installation guide#Boot the live environment could be used as a staring point. -- nl6720 (talk) 06:26, 1 July 2020 (UTC)
See draft below. -- nl6720 (talk) 12:14, 7 July 2020 (UTC)

Draft: Prepare an installation medium & Boot the live environment

Prepare an installation medium

The live environment can be booted from a USB flash drive, an optical disc or a network with PXE. Follow the appropriate article to prepare yourself an installation medium.

Boot the live environment

  1. Point the current boot device to the one which has the Arch Linux installation medium. Typically it is achieved by pressing a key during the POST phase, as indicated on the splash screen. Refer to your motherboard's manual for details.
  2. When the installation medium's boot loader menu appears, select Arch Linux install medium and press Enter to enter the installation environment.
    Tip: The installation medium uses systemd-boot for booting in UEFI mode and syslinux for booting in BIOS mode. See README.bootparams for a list of boot parameters.
  3. 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 and vim are available. See packages.x86_64 for a list of the packages included in the installation medium.

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 in <#Partition the disks> to EFI formatting

As is, there's no hint as to how to format the EFI partition in this section or in the links, so I suggest we add that this line, See EFI system partition#Format the partition. —This unsigned comment is by Ttoirrah (talk) 07:03, 15 May 2020 UTC. Please sign your posts with ~~~~!

Installation guide#Partition the disks has two links to the EFI system partition article. Did you perhaps mean Installation guide#Format the partitions? -- nl6720 (talk) 09:42, 15 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.

https://wiki.archlinux.org/index.php/Installation_guide#Partition_the_disks

—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

Suggest using Reflector to automate Pacman mirrorlist

It's somewhat tedious on a bare-bones system to use nano or other editors to manually move around the supplied mirrorlist such that one's own countries are higher in the list, but doing so has a huge effect on the installation experience. Since reflector is in the main repository, and this is not the first or only time a package install is required for system setup (EFI_system_partition#Format_the_partition dosfstools), I propose we suggest that users use the reflector to update the mirrorlist prior to pacstrap:

...so it is worth getting right. Reflector may be used to automate this process. The following example selects the 50 most recently synchronized mirrors offering HTTPS and sorts them by download speed.

# reflector --verbose --latest 50 --protocol https --sort rate --save /etc/pacman.d/mirrorlist

Froze-midden (talk) 02:45, 9 June 2020 (UTC)

Another consideration for inclusion -- sometimes even when you manually select your country's servers you may get unlucky and hit a slow one. It caught me a couple of times and it was a bit annoying to wait for all the packages to download. I know that it is generally against the spirit of the guide to include a somewhat optional dependency on a tool that introduces another point of failure into the installation process, but it would be nice to mention that if one wants to find the fastest available mirrors -- tools like reflector are out there to help. Romstor (talk) 03:08, 9 June 2020 (UTC)
dosfstools is present on the official archiso image, whereas reflector is not. The installation guide should not rely on installing packages in the live environment itself. Besides, this is indirectly pointed out via General recommendations#MirrorsMirrors#Server-side ranking. -- Lahwaacz (talk) 08:21, 9 June 2020 (UTC)
Installing inside the live environment could result in a partial upgrade (in the live environment), which could break the install process. A better idea would be asking for reflector's inclusion in archiso and having it run after the network is online. -- nl6720 (talk) 10:36, 9 June 2020 (UTC)
archlinux-2020.07.01-x86_64.iso will have reflector.service that updates the mirrorlist in the live system. Maybe tomorrow the whole Installation guide#Select the mirrors section can be removed? -- nl6720 (talk) 17:21, 30 June 2020 (UTC)
I dislike relying on reflector entirely and removing the section on mirrors. reflector is a complex tool and can fail, in which case without a mirror section the user is stuck. -- Alad (talk) 21:30, 30 June 2020 (UTC)
You are right, there are cases where reflector can fail. Luckily it doesn't overwrite the mirrorlist file when it can't find any mirrors, so the default from pacman-mirrorlist (with all mirrors uncommented) remains. The Installation guide#Select the mirrors section will need updating nonetheless. -- 06:19, 1 July 2020 (UTC)
I updated Installation guide#Select the mirrors to match the current behavior of archiso. The second paragraph still needs some editing, there's little need to edit the file manually if reflector did its job correctly. -- nl6720 (talk) 10:02, 1 July 2020 (UTC)