Talk:Installation guide

From ArchWiki

Read this first before adding new suggestions

-- The ArchWiki Administrators 22:17, 2 September 2016 (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)Reply[reply]

I don't understand what's the actual problem here... -- Lahwaacz (talk) 09:36, 8 September 2019 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
  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)Reply[reply]
  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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
I think you like the #800080 shade of purple, right? ;-) Lahwaacz (talk) 11:39, 21 September 2019 (UTC)Reply[reply]
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)Reply[reply]
Any news on this one? If not, I haven't seen this kind of issue or confusion occur since. -- Alad (talk) 09:37, 31 October 2021 (UTC)Reply[reply]
I don't think I want to create such a template anymore, since it would require updating other installation related pages. To go back to your originally proposed options, I'm for explaining /mnt early. -- nl6720 (talk) 09:42, 4 November 2021 (UTC)Reply[reply]

GitLab blobs in Lynx

Links to files (blobs) on gitlab.archlinux.org are not readable in Lynx (or any other console web browser); see https://gitlab.com/gitlab-org/gitlab/-/issues/26567.

Should the Installation guide link to raw files instead?

-- nl6720 (talk) 12:29, 4 August 2020 (UTC)Reply[reply]

Maybe you could ask svenstaro to add it to https://gitlab.com/gitlab-org/gitlab/-/issues/232073... -- Lahwaacz (talk) 12:36, 4 August 2020 (UTC)Reply[reply]
It has been filed under nice to have. -- nl6720 (talk) 17:19, 4 August 2020 (UTC)Reply[reply]
Instead of using raw links we should perhaps consider if we need links to gitlab at all. The guide has:
Notice how all but one of these share the common path archiso/-/blob/master/configs/releng. Unless this level of specificity is really required, we could link to this path "for an overview of configuration files shipped with archiso" instead. -- Alad (talk) 09:35, 31 October 2021 (UTC)Reply[reply]
I'd prefer simply removing some of the links.
-- nl6720 (talk) 09:30, 4 November 2021 (UTC)Reply[reply]
Alright, I've removed those links. (Special:Diff/700696, Special:Diff/700693) -- Alad (talk) 11:39, 4 November 2021 (UTC)Reply[reply]
Now that mirrors provide a symlink to the latest ISO version, it's possible to link to pkglist.x86_64.txt. I replaced packages.x86_64 with it. -- nl6720 (talk) 07:31, 21 May 2022 (UTC)Reply[reply]
Is Lynx (un)readability such a big problem in this case? People using Lynx from the archiso can open up the relevant file in the live system itself... — Lahwaacz (talk) 18:05, 31 October 2021 (UTC)Reply[reply]

Post-installation

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Missing pacman-key steps ?

I just tried (using archlinux-2022.11.01-x86_64.iso) the standard archlinux installation (pacstrap) following the guide, and once the packages were downloaded, they failed to install with errors like:

  • "signature from <maintainer> is unknown trust"

I found on the web the following commands to solve the issue: (https://bbs.archlinux32.org/viewtopic.php?id=2900)

  • pacman-key --init
  • pacman-key --populate archlinux

After those two commands, the pacstrap installation works fine.

If those two commands are needed, shouldn't we document them in the Installation guide ?

(note that the same problem/solution is applicable to archinstall method too)

—This unsigned comment is by Nsauzede (talk) 23:02, 3 November 2022 (UTC). Please sign your posts with ~~~~!Reply[reply]

This is already done by pacman-init.service. Scimmia (talk) 23:38, 3 November 2022 (UTC)Reply[reply]
I hit the exact same problem with same installation iso. I got the solution from https://wiki.archlinux.org/title/Pacman/Package_signing
—This unsigned comment is by Roblaing (talk) 2022-12-02T07:53:41. Please sign your posts with ~~~~!
This is caused by out of date keyring, what really should be added to the installation guide is starting the keyring sync service systemctl start archlinux-keyring-wkd-sync before the pacstrap step, with a warning to check that it has finished running before continuing. This will allow both older ISOs to work and even current ISOs to work. December ISO is once again broken right now as openssl has too new a key. C0rn3j (talk) 23:21, 24 December 2022 (UTC)Reply[reply]
archlinux-keyring-wkd-sync doesn't 'sync' the keyring, it refreshes it which is only helpful in a limited set of circumstances. Most of the time, it won't help these errors. Scimmia (talk) 03:21, 25 December 2022 (UTC)Reply[reply]
It however helps with the current issue and am sure the previous issues too, as they were fixable with partially installing archlinux-keyring on the ISO before. I am not aware of a better solution, unless reinitializing and populating the keyring as per OP is actually preferred? C0rn3j (talk) 11:05, 25 December 2022 (UTC)Reply[reply]
Reinitializing and populating the keyring is a solution for a completely different problem. Scimmia (talk) 13:32, 25 December 2022 (UTC)Reply[reply]

Add tip for easily booting iPXE-arch.efi file from almost all hardware

For most scenarios (I assume) it isn't necessary to flash an USB drive or burn a disk. You can simply put the PXE EFI binary on a drive and boot it from "BIOS" directly (works e.g. on Dell hardware). If your BIOS does not support loading arbitrary files directly, you can use the UEFI shell to do so if available. Otherwise you can simply put the image under /EFI/BOOT/ and name it bootx64.efi and select this drive from the boot menu. The drive might even be the boot partition, if you are going to do a reinstall. (Tested on Lenovo and Fujitsu notebooks) Flacer (talk) 14:06, 26 January 2023 (UTC)Reply[reply]

Installation guide#Acquire an installation image already mentions the netboot image. And yes, it should work just fine on any system with an Ethernet connection. -- nl6720 (talk) 14:13, 26 January 2023 (UTC)Reply[reply]
That is true, but in my opinion it would be beneficial to emphasize this because esp. new users think of setting up a server etc. (me too, although I'm not quite a new user; discovered this by accident).
So it would be better to put it under Netboot? Anyway it would be helpful to place a link to that page, most appropriately under 1.3. -- Flacer (talk) 15:42, 26 January 2023 (UTC)Reply[reply]
I could be wiki-linked from 1.1 and somehow mentioned in 1.3. Just need to find the right words for it. -- nl6720 (talk) 14:55, 1 February 2023 (UTC)Reply[reply]
I think an additional link in 1.1 is too early. Currently, the downloads landing page links a dedicated netboot page, which at the end leads to the wiki article. Linking it earlier may mislead to users skipping the gpg steps in 1.2. and the landing page.
In 1.3 we could replace "or a network with PXE:" with "or an appropriate PXE" for starters. And complement that by adding to the last intro sentence in PXE "This works well when you already have a server set up, but may (for installation purposes) also load the image directly from an official Arch mirror."
--Indigo (talk) 22:52, 3 February 2023 (UTC)Reply[reply]
I'm not too sure about "or an appropriate PXE". I assume most people would just place the netboot EFI binary in a USB flash drive and boot it directly. The fact that the images are iXPE builds is not that relevant. Perhaps 1.3 needs to explicitly differentiate the deployment methods of the ISO and netboot images since the links in the section are ISO specific. -- nl6720 (talk) 10:02, 4 February 2023 (UTC)Reply[reply]
True, like two bullet points for ISO and iPXE in 1.3. I proposed "appropriate PXE", because (as Flacer mentions) current "network PXE" does indeed sound like you need to set up a server when you visit the article. How about switching PXE links to netboot?
--Indigo (talk) 19:23, 5 February 2023 (UTC)Reply[reply]
Well, you can still PXE-boot the ISO contents as the PXE article describes, so I don't think it's correct to remove the links.
I would probably be best if Netboot had instructions on how to create a bootable medium from the image. At least for UEFI, since that's dead simple. IMHO 1.3. could then be turned into two sentences, one for the ISO deployment, one for netboot.
-- nl6720 (talk) 09:52, 6 February 2023 (UTC)Reply[reply]
Sure, it can; see the sentence I proposed above for PXE. I agree it is more important to edit both articles first. The simple method proposed by Flacer can be turned into a tip in the Netboot section you suggest. Afterwards we can see what changes are still useful in this main guide. Perhaps this item should be moved to Talk:Netboot for implementation first. --Indigo (talk) 18:44, 16 February 2023 (UTC)Reply[reply]
There's Netboot#Boot from a USB flash drive that can be linked now. -- nl6720 (talk) 16:10, 26 March 2023 (UTC)Reply[reply]
I drafted something below. Installation guide#Boot the live environment will need adjustment too, so suggestions welcome. -- nl6720 (talk) 14:59, 24 June 2023 (UTC)Reply[reply]
I added an draft for Installation guide#Boot the live environment below. -- nl6720 (talk) 10:05, 16 November 2023 (UTC)Reply[reply]

Prepare an installation medium (draft)

The ISO can be supplied to the target machine via a USB flash drive, an optical disc or a network with PXE: follow the appropriate article to prepare yourself an installation medium from the ISO file.

For the netboot image, follow Netboot#Boot from a USB flash drive to prepare a USB flash drive for UEFI booting.

Boot the live environment (draft)

Note: Arch Linux installation images do not support Secure Boot. You will need to disable Secure Boot to boot the installation medium. If desired, Secure Boot can be set up after completing the installation.
  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,
    • if you used the ISO, select Arch Linux install medium and press Enter to enter the installation environment.
    • if you used the Netboot image, choose a geographically close mirror from Mirror menu, then select Boot Arch Linux and press Enter.
      Tip:
      • The ISO uses GRUB for UEFI and syslinux for BIOS booting. Use respectively e or Tab to enter the boot parameters. The Netboot image uses iPXE and the boot parameters can be specified in the Boot options menu. See README.bootparams for a list.
      • A common example of manually defined boot parameter would be the font size. For better readability on HiDPI screens—when they are not already recognized as such—using fbcon=font:TER16x32 can help. See HiDPI#Linux console (tty) for a detailed explanation.
  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 Lynx alongside the installation—use the Alt+arrow shortcut. To edit configuration files, mcedit(1), nano and vim are available. See pkglist.x86_64.txt for a list of the packages included in the installation medium.

Mention zram

In Installation guide#Partition the disks, The note mentions:

  • Swap space can be set on a swap file for file systems supporting it.

Should it be updated to add reference to zram as well ? Something like :

-- Cvlc (talk) 23:04, 30 January 2023 (UTC)Reply[reply]

I do not think zram is essential enough (compared to the defaults) for it to be mentioned in the Installation guide, or even in General recommendations. The snake oil article references it and IMHO that's enough. -- nl6720 (talk) 10:22, 31 January 2023 (UTC)Reply[reply]
(Re-opened, hope that's ok)
Certainly not essential, but it's one possible reason not to plan for a swap partition during the partitioning step. Distros like Fedora provide that by default, it's a reasonable way to set up a system, I don't see any harm in mentioning it. People often read the installation guide many times before actually installing Arch, it's a perfect way to learn about possibilities, whereas Improving performance is probably most often read after installation on a running system. Swap files are already mentioned, so it doesn't require any extra note or clutter, just modifying a sentence, which is nice.
-- Cvlc (talk) 16:16, 31 January 2023 (UTC)Reply[reply]
If it were to be added to the installation guide, I want it to contain the phrase "swap on zram" instead of obfuscating it with "compressed block device in ram" or similar.
I don't think we can link to Zram#Usage as swap unless it has a suggested size for the swap space.
-- nl6720 (talk) 10:13, 22 June 2023 (UTC)Reply[reply]
I was about to say, we can just link to the suggested size from the swap article but... there is no suggested size there either :)
-- Cvlc (talk) 15:09, 22 June 2023 (UTC)Reply[reply]
There's Partitioning#Swap, which IMO should be linked from Swap#Swap file, but it doesn't actually say anything specific. Instead the recommended size is only listed in the Partitioning#Example layouts table.
Still, does the general swap size recommendation apply to swap on zram? Is wasting 512 MiB of RAM enough?
-- nl6720 (talk) 16:24, 22 June 2023 (UTC)Reply[reply]
No you're right, the general swap size recommendation does not really apply to zram. A percentage of available RAM makes more sense. zram-generator has a default of zram-size = min(ram / 2, 4096), Fedora uses 100% of RAM. I've been using 100% without problems for quite a while. I would suggest 100% for regular desktop/laptop use, and 50% if having to deal with specific non compressible workloads (not sure what this would be though, I've had no problem with encoding of large video files, or such).
-- Cvlc (talk) 16:50, 22 June 2023 (UTC)Reply[reply]
Fedora:Changes/Scale ZRAM to full memory size says that it's 8 GiB max, so not "100%". And we shouldn't blindly follow Fedora either, their change reasoning is not always properly documented. -- nl6720 (talk) 15:05, 24 June 2023 (UTC)Reply[reply]

"2.2 Install essential packages" needs more specific suggestions for absolute beginners.

I personally had a lot of problems with the installation and had to resort to "walk-throughs" that just caused hours of headaches. I will point out some of the problems I had with this section.

"userspace utilities for the management of file systems that will be used on the system" is wordy and vague. It is unhelpful to someone completely new. The hyperlink points to types of file systems which is not intuitive to the statements suggestion. At the very least, "userspace utilities" should be hyperlinked to a section of programs the statement is suggesting. Several months on, I still am unsure of what they are eluding to.

"specific firmware for other devices not included in linux-firmware (e.g. sof-firmware for sound cards)" An absolute beginner does not know what specific firmware are not included in linux-firmware. The suggestion of sound cards is extremely outdated, and frankly makes it seem like linux-firmware is going to leave you needing a lot of drivers if it cannot even operate your sound card out of the box. This confusion led me down a rabbit hole of installing(or trying to find) CPU microcode updates, nvidia drivers, wired or wireless drivers, motherboard drivers, and so on.

"software necessary for networking (e.g. a network manager or a standalone DHCP client, authentication software for Wi-Fi, ModemManager for mobile broadband connections)" My first problem was I was unaware of the need to systemctl enable the networking software, which led me to installing multiple DHCP clients and causing issues further down the road. I am now aware that if I had read more into the software. I believe a simple reminder to systemctl enable the networking software could save a lot of people problems.

"a text editor," The hyperlink just throws a list of 70 or so text editors at you. This is quite needlessly daunting to someone new. Even something as basic as "e.g. vim" would have spared me from being so overwhelmed this far into my troubles with this section.

"packages for accessing documentation in man and info pages: man-db, man-pages and texinfo." This should take priority above all by being placed first in this list.

I would recommend a section "2.2.1 Example(s) of essential packages" be created that shows at least one example of a typical users desktop computer, and what they would install on this step.

—This unsigned comment is by Todd the king (talk) 21:12, 12 June 2023 (UTC). Please sign your posts with ~~~~!Reply[reply]

I would refer you to https://wiki.archlinux.org/title/Arch_Linux#User_centrality. Arch's target audience isn't absolute beginners, it's experienced Linux users that know what they want and how they want their system set up. Scimmia (talk) 22:37, 12 June 2023 (UTC)Reply[reply]
It is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems. —This unsigned comment is by Todd the king (talk) 21:12, 12 June 2023 (UTC). Please sign your posts with ~~~~!Reply[reply]
And your argument is that you don't want to read the documentation. Arch dosen't make these decisions for you, you need to either know what you want or be willing to figure out what you want. Scimmia (talk) 22:49, 12 June 2023 (UTC)Reply[reply]
I did read the documentation, and I did figure out what I wanted. It took much longer than it should have because the instructions were hazy on this section. Why give any examples of software or suggestions of configuration to use in the article at all if this is the mindset of the guide? Where is the line and why? Todd the king (talk) 23:09, 12 June 2023 (UTC)Reply[reply]
First of all, welcome :)
Now, I'm sorry but:
"userspace utilities for the management of file systems that will be used on the system"
is wordy and vague. It is unhelpful to someone completely new. The hyperlink points to types of file systems which is not intuitive to the statements suggestion. At the very least, "userspace utilities" should be hyperlinked to a section of programs the statement is suggesting. Several months on, I still am unsure of what they are eluding to.
The very first section of the linked page (i.e. File systems#Types of file systems has a table which helpfully has a "Userspace utilities" column, I fail to see how skipping the page introduction would make this more obvious.
"specific firmware for other devices not included in linux-firmware (e.g. sof-firmware for sound cards)"
An absolute beginner does not know what specific firmware are not included in linux-firmware. The suggestion of sound cards is extremely outdated, and frankly makes it seem like linux-firmware is going to leave you needing a lot of drivers if it cannot even operate your sound card out of the box. This confusion led me down a rabbit hole of installing(or trying to find) CPU microcode updates, nvidia drivers, wired or wireless drivers, motherboard drivers, and so on.
An absolute beginner's encouraged to seek help if he's unsure of what advice is applicable to its hardware. As shown in the tables in Laptop/Lenovo, various recent laptops do require ALSA firmware, while some models require specific drivers (and its respective firmware) for wireless networking: Broadcom wireless, or even some USB3 chipsets on the motherboard with upd72020x-fwAUR for example.
"software necessary for networking (e.g. a network manager or a standalone DHCP client, authentication software for Wi-Fi, ModemManager for mobile broadband connections)" My first problem was I was unaware of the need to systemctl enable the networking software, which led me to installing multiple DHCP clients and causing issues further down the road. I am now aware that if I had read more into the software. I believe a simple reminder to systemctl enable the networking software could save a lot of people problems.
Someone manually configuring a static ip connection would not need that step, while every dedicated network manager page explains the need for enabling their respective systemd unit.
"a text editor,"
The hyperlink just throws a list of 70 or so text editors at you. This is quite needlessly daunting to someone new. Even something as basic as "e.g. vim" would have spared me from being so overwhelmed this far into my troubles with this section.
Not picking a default text editor is a feature and not a bug: every choice made of a "sane default" would create endless bikeshedding (see Wikipedia:Editor war), although a popular beginner friendly one has been used as an example in Help:Reading#Append, add, create, edit.
"packages for accessing documentation in man and info pages: man-db, man-pages and texinfo."
This should take priority above all by being placed first in this list.
Man pages can be accessed with man.archlinux.org instead of wasting bandwidth and disk space by installing and updating a local version.
I would recommend a section "2.2.1 Example(s) of essential packages" be created that shows at least one example of a typical users desktop computer, and what they would install on this step.
This guide is not specific to desktop users, a dedicated section is out of scope.
As a general answer, our aim is to provide readers with the information they need to make an educated decision at every step, not rubber stamping the popularity of various software solutions.
While a little overwhelming at first, this approach has proven itself to be the best working on the long term: Help:Reading#Organization.
--Erus Iluvatar (talk) 00:07, 13 June 2023 (UTC)Reply[reply]
I replaced "sound cards" with "onboard audio" which will hopefully get the message across better. -- nl6720 (talk) 05:56, 13 June 2023 (UTC)Reply[reply]
After a bit of staring at Installation guide#Install essential packages, I can confidentially say I can find some fault in each and any bullet point. So, starting from the top, I propose changing the first one to:
userspace utilities for file systems that will be used on the system—for the purposes of e.g. file system creation and fsck,
It gets rid of the vague "for the management" and adds actual reasons for wanting the userspace utilities.
-- nl6720 (talk) 06:37, 13 June 2023 (UTC)Reply[reply]
Since no one objected, and I finally remembered this discussion, I updated the page per my suggestion above. -- nl6720 (talk) 10:06, 22 June 2023 (UTC)Reply[reply]
"utilities for accessing RAID or LVM partitions" could be replaced with something like:
utilities for accessing and managing RAID or LVM if they will be used on the system,
These things can actually be managed, and they are not limited to partitions. Also IMO it's better to directly link to the section that lists the packages to install.
-- nl6720 (talk) 10:48, 22 June 2023 (UTC)Reply[reply]
Done. -- nl6720 (talk) 09:23, 30 June 2023 (UTC)Reply[reply]
On to the next one:
specific firmware for other devices not included in linux-firmware (e.g. sof-firmware for onboard audio, linux-firmware-marvell for Marvell wireless and any of the multiple firmware packages for Broadcom wireless),
It lists the only split-package of linux-firmware that I've heard anyone actually need and also the dreaded Broadcom wireless.
-- nl6720 (talk) 09:23, 30 June 2023 (UTC)Reply[reply]
Since no one has stopped me yet: Special:Diff/782857. -- nl6720 (talk) 10:20, 9 July 2023 (UTC)Reply[reply]
I do not think the "software necessary for networking" bullet point lacks anything. Instead, Installation guide#Network configuration could be improved to avoid giving the impression that installing a piece of software is enough to make it operational. Unfortunately I can't think of a good, easily digestible phrase that accomplishes that. -- nl6720 (talk) 10:27, 9 July 2023 (UTC)Reply[reply]
Best I can come up for Installation guide#Network configuration is:
That may include installing suitable network management software, configuring it if necessary and enabling its systemd unit so that it starts at boot.
Thoughts?
-- nl6720 (talk) 10:04, 15 August 2023 (UTC)Reply[reply]
I would slightly alter the order of the words:
That may include installing suitable network management software, configuring it and enabling its systemd unit so that it starts at boot if necessary.
Outside of that minor nitpick, it is probably beneficial to be explicitly pointing out commons steps instead of hoping people will read the Wiki page of every software they install :P --Erus Iluvatar (talk) 10:38, 15 August 2023 (UTC)Reply[reply]
The thought was that you need to install the package and enable the unit, but configuring is not always required. E.g. NetworkManager & dhcpcd can be simply be used as is for Ethernet connections with no prior configuration. -- nl6720 (talk) 10:42, 15 August 2023 (UTC)Reply[reply]
👍 --Erus Iluvatar (talk) 11:02, 15 August 2023 (UTC)Reply[reply]
Done. -- nl6720 (talk) 14:04, 30 August 2023 (UTC)Reply[reply]
I think it would be better if "a text editor" would instead say "a console text editor", since you won't be able to use graphical ones in the tty. The issue with that text is that List of applications#Vi-style text editors and List of applications#Emacs-style text editors are separate sections on the same level as "console" and "graphical". -- nl6720 (talk) 11:35, 23 October 2023 (UTC)Reply[reply]
And linking to List of applications#Console 23 would skip the vi/emacs-style editors so it's not an option either :/ -- Erus Iluvatar (talk) 11:41, 23 October 2023 (UTC)Reply[reply]

Mention that partitionning is more-or-less permanent

While there are solutions to reformat/repartition drives after the fact, it should be made obvious (warning/info box?) that changing partitions after a system is installed can be a major PITA. I've seen too many reddit support posts about wanting to add more space to the root partition or encrypting everything after the fact.

Therefore, I suggest adding in section 1.9:

Warning: Re-partitioning disks after the fact is difficult and involves moving data and system around. It is therefore recommended to properly size and format disks, according to: Partitioning. If you need disk encryption, now is the time to look into Data-at-rest_encryption.

Moviuro (talk) 18:05, 5 December 2023 (UTC)Reply[reply]

Yeah, for once this probably deserves a warning instead of a note since it's "reasonably difficult" to fully reinstall a system to add encryption after the fact.
Maybe we could simply expand on the existing
"If you want to create any stacked block devices for LVM, system encryption or RAID, do it now." sentence?
-- Erus Iluvatar (talk) 06:20, 6 December 2023 (UTC)Reply[reply]
If the issue in an under-provisioned root partition, then we can simply add the recommended size (32 GiB) to the tables in Installation guide#Example layouts. -- nl6720 (talk) 09:45, 6 December 2023 (UTC)Reply[reply]
This only solves part of the issue. The part about encrypting the device/partitions after the fact is still not covered. Moviuro (talk) 10:11, 6 December 2023 (UTC)Reply[reply]
Repartitioning is not impossible, just tedious, so IMO it does not warrant a warning.
Installation guide#Partition the disks already has "If you want to create any stacked block devices for LVM, system encryption or RAID, do it now." What's wrong with the current text?
❄️❄️ nl6720 (talk) 15:02, 16 December 2023 (UTC)Reply[reply]
Maybe just using a Template:Note for the existing sentence then?
Installation guide#Partition the disks is already sprinkled with template though :/
We already have emphasis on other similarly tedious stuff (e.g. the note at the beginning of Installation guide#Install essential packages).
-- Erus Iluvatar (talk) 07:00, 17 December 2023 (UTC)Reply[reply]
I guess it should be fine to make it into a note, be we should definitely strive to avoid the 🎄 look. ❄️❄️ nl6720 (talk) 13:49, 17 December 2023 (UTC)Reply[reply]
Maybe merging the last note from the section into the first one, while adding into it the sentence about creating block device and an explanation about not being able to encrypt after the fact without a full re-installation? Something kinda like:
Note:
-- Erus Iluvatar (talk) 15:30, 18 January 2024 (UTC)Reply[reply]
"converting an existing system will require re-partitioning" is not necessarily true. E.g. dm-crypt/Device encryption#Encrypt an existing unencrypted file system. -- nl6720 (talk) 11:02, 23 January 2024 (UTC)Reply[reply]
"converting an existing system usually requires re-partitioning" ?
-- Erus Iluvatar (talk) 12:41, 23 January 2024 (UTC)Reply[reply]
The creation of mappers only follows the partitioning, i.e. the "..do it now." strictly is not logical to come before fdisk anyway, moving it up into the first note makes it less logical. How about
"Take time to plan a long-term partitioning to avoid complicated conversion procedures or even re-partitioning in the future."?
and leave the "do it now." sentence where it is; there it is more a quicklink reminder to consider what's needed.
--Indigo (talk) 23:13, 23 January 2024 (UTC)Reply[reply]
👍 Erus Iluvatar (talk) 06:11, 24 January 2024 (UTC)Reply[reply]
I'm looking at where to add the sentence in the section, what did you have in mind? Erus Iluvatar (talk) 07:28, 20 February 2024 (UTC)Reply[reply]

Clarify pre-installation time zone

Special:PermanentLink/800213#Update the system clock instructs the user to verify that "the system clock is accurate," using timedatectl. A this point, a time zone hasn't been (and needn't yet be), but the output of the command will include Time zone: UTC. Would it be worth mentioning that this'll get handled later? e.g.

Use timedatectl(1) to ensure the system clock is accurate for UTC (the time zone may be adjusted later during installation):

CodingKoopa (talk) 04:19, 4 March 2024 (UTC)Reply[reply]

I'd skip on referring to later instructions (it's written as step-by-step), but you're right it should mention UTC, e.g. "...and time will be synced to UTC automatically" in the sentence above. Also, I'd replace "ensure the system clock is accurate:" with "ensure the system clock is synchronized:".
--Indigo (talk) 22:10, 5 March 2024 (UTC)Reply[reply]

Move microcode updates to "Install essential packages"

mkinitcpio now packs microcode initramfs together with the main initramfs in one file and does so by default.

This allows to remove any mention of microcode from Installation guide#Boot loader and simply list the two packages in Installation guide#Install essential packages.

I propose adding something like this as the first bullet point:

-- nl6720 (talk) 08:42, 18 March 2024 (UTC)Reply[reply]

👍 Erus Iluvatar (talk) 08:51, 18 March 2024 (UTC)Reply[reply]