Talk:Installation guide
- 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], [4] and [5] for some past discussions about this issue.
- Due to the wide variety of available boot loaders, the installation guide refers to Arch boot process#Boot loader instead of making a specific recommendation for the installed system. See [6], [7], [8], [9], [10] for some past discussions on this topic.
- While Category:Installation process lists additional installation methods (e.g. archinstall or systemd-firstboot), the installation guide does not reference them due to their specific nature. Install Arch Linux with accessibility options is an exception. See [11] for a past discussion on this topic.
Update arch-chroot step
The last release of arch-install-scripts has introduced a cleaner way to handle mounts in the arch-chroot step. Since the installation medium provides the right version of systemd , I think there's no downsides to switch to using the -S flag in the guide?
-- Erus Iluvatar (talk) 11:51, 1 November 2025 (UTC) Reply
- π -- nl6720 (talk) 05:47, 2 November 2025 (UTC) Reply
- I'll wait until the next release to be extra cautious, there's an edge case that we should not hit as the guide does not show it being used with relative paths, but I'd rather be safe. Erus Iluvatar (talk) 18:12, 15 November 2025 (UTC) Reply
- May we close this topic? At least, I can't find anything related... β Andrei Korshikov (talk) 19:29, 13 February 2026 (UTC) Reply
- I'll wait until the next release to be extra cautious, there's an edge case that we should not hit as the guide does not show it being used with relative paths, but I'd rather be safe. Erus Iluvatar (talk) 18:12, 15 November 2025 (UTC) Reply
- I'd like to keep this open until there is a new release cut for arch-install-scripts .
- --Erus Iluvatar (talk) 09:45, 14 February 2026 (UTC) Reply
Boot the live environment Note grammar
Current state: "You will need to disable Secure Boot to boot the installation medium."
Proposed state: "You have to disable Secure Boot to boot the installation medium."
"need to" β kind of personal necessity
"have to" β external obligation (there is no choice) Aaaand... there is no choice indeed.
Well, English is not my native language: I'm not sure about "will have to" vs just "have to", but "need to" vs "have to" is quite obvious for me.
β Andrei Korshikov (talk) 18:21, 3 May 2026 (UTC) Reply
- IMO the "need" can also apply to obligation, e.g. "you need to eat to survive" feels right while "you have to eat to survive" rings weird for some reason. Digging a little deeper, I'd say "have to" sounds more familiar than "need to", which would answer our question as we're aiming for a "formal, professional, and concise language". Not a native speaker either, so I'll let others chime in just in case.
- -- Erus Iluvatar (talk) 16:30, 22 May 2026 (UTC) Reply
"installation medium" vs "installation image"
Inspired by Special:Diff/872738 by @Nl6720.
(1) / Introductory section / "The installation medium provides accessibility features"... β IMO, installation image does.
(2) Installation guide#Boot the live environment: "See pkglist.x86_64.txt for a list of the packages included in the installation medium."
Packages are included in the installation image, medium is just a flash drive (or so). At least, to my understanding.
β Andrei Korshikov (talk) 18:59, 3 May 2026 (UTC) Reply
- The installation medium is a medium to which the installation image has been written. In these sentences, IMO, "installation medium" is fine. Since there's also the netboot image, "installation image" wouldn't be entirely correct either for 2., since there are no packages in it. "Live environment" would be more correct there.
- Special:Diff/872738 is a special case, because you can write the ISO in different ways and the tip doesn't apply to all of them.
- -- nl6720 (talk) 07:57, 4 May 2026 (UTC) Reply
- While appeciating the thoughts to refine accuracy, my solution for (1) would be to replace "The installation medium provides .." with "It provides ..". Simpler and less repetitive.
- For (2) I agree "Live environment" gives better direction, i.e. there is nothing else to do to use the included set.
- --Indigo (talk) 20:42, 24 June 2026 (UTC) Reply
Suggest a repo sync before pacstrap?
Recently I've seen several people have pacstrap fail during installation due to a failure to retrieve files. I have also ran into this issue myself several times in the past. Running pacman -Syy to sync the repos usually fixes this. Should we include an optional step to sync the repos before running pacstrap? Or at least mention that if you get the error failed to retrieve some files to try syncing the repos first? Caviarcbr (talk) 11:04, 20 June 2026 (UTC) Reply
- pacstrap already does this: https://gitlab.archlinux.org/archlinux/arch-install-scripts/-/blob/v31/pacstrap.in?ref_type=tags#L19
- Your mirror was probably out of sync.
- β andreymal (talk) 11:47, 20 June 2026 (UTC) Reply
- Chapter "2.1 Select the mirrors" - because: "On the live system, all HTTPS mirrors are enabled" Ua4000 (talk) 11:53, 20 June 2026 (UTC) Reply
- Maybe it's worth mentioning in this chapter that not updating the mirrorlist can cause errors when running pacstrap. As it's worded now, it makes it seem like it's only to increase download speed. I know it's not listed as an optional step, so people should be doing it anyway, but it seems the importance of this step isn't properly conveyed, and it's causing issues for people. Caviarcbr (talk) 12:00, 20 June 2026 (UTC) Reply
- Chapter "2.1 Select the mirrors" - because: "On the live system, all HTTPS mirrors are enabled" Ua4000 (talk) 11:53, 20 June 2026 (UTC) Reply