Talk:Installation guide

From ArchWiki

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].
  • 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 past discussion on this topic.

-- 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: [12]. 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)
Apparently since last year the translation has been halved in size, but its scope is still much larger than the Install guide (or even the old Beginners' guide). -- Alad (talk) 09:42, 9 May 2021 (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)
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)
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)

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)

I would expect this to be mentioned in General_troubleshooting... -- Alad (talk) 09:43, 31 October 2021 (UTC)

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)

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)
It has been filed under nice to have. -- nl6720 (talk) 17:19, 4 August 2020 (UTC)
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)
I'd prefer simply removing some of the links.
-- nl6720 (talk) 09:30, 4 November 2021 (UTC)
Alright, I've removed those links. (Special:Diff/700696, Special:Diff/700693) -- Alad (talk) 11:39, 4 November 2021 (UTC)
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)
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)

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)

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)

Remove parted

Due to parted not aligning the partition size (and with no patch in sight) which prevents using 4096 byte sectors with dm-crypt/LUKS unless explicitly planned before, I'd like to remove the "parted" link from Installation guide#Partition the disks. An alternative would be to change all examples in Parted to not use percentages and warn against using them. -- nl6720 (talk) 07:21, 7 April 2022 (UTC)

I prefer to change the examples in Parted. Just removing the link from installation guide won't stop people from using the tool. -- Alad (talk) 10:52, 7 April 2022 (UTC)

Note on Network Setup

One of the most common installation issues that comes up on Reddit, Forums, and other discussion areas is not having done any sort of network setup. While the Installation Guide explicitly call out Network Setup as a required step, I suspect people are mistakenly believing the setup steps they did already to establish a connection on the installer will carry over to their installed system.

I propose adding a note such as (example content):

Note: Configuring your network connection above only established your network for the installer. This section will configure the network for your installed Arch system. Failure to do so may leave you without network access after completing installation.

Nalthien (talk) 17:40, 15 May 2022 (UTC)

Such a thing does not warrant a warning since there's nothing dangerous about being offline. It may even be the safest state the system will ever be. -- nl6720 (talk) 10:24, 18 May 2022 (UTC)
I can agree that it doesn't warrant a Warning given the style guide; however, I do think a Note would be appropriate to "highlight information easily overlooked." It's clearly overlooked quite often. Nalthien (talk) 17:36, 20 May 2022 (UTC)
Installation guide#Connect to the internet already explains (or tries to, at least) that the live environment's network setup has nothing to do with the installed system. Perhaps the list items in Installation guide#Install essential packages could be made a little more verbose to explain why someone may want to install those things. -- nl6720 (talk) 10:24, 18 May 2022 (UTC)

I propose adding something like the following:

To configure the freshly installed system's network for out-of-the-box ethernet DHCP functionality as on the installation image, create a simple /etc/systemd/network/20-wired.network file for your adapter Name, eg:

[Match]

Name=enp1s0

[Network]

DHCP=yes

Also, enable both systemd-networkd.service and systemd-resolved.service

1. It will only take up a few lines; it is succinct, effective and informative. 2. Further, the functionality on reboot will mimic functionality in the installation image. 3. It uses simple built-in services without installing anything extra. 4. It will also cut down on forum noise immensely. Misfit138 (talk 11:11 21 March 2023 (UTC-5)

It's also incomplete, as systemd-resolved takes some setup. And it would cause more problems on the forums when people then enable NM or whatever and have both. There's a reason the network configuration page is linked. Scimmia (talk) 15:14, 21 March 2023 (UTC)
systemd-resolved setup is optional according to the network configuration page, and I can confirm this to be the case on a bare-metal workstation as well as a VM. Doing the above minimal steps results in full functionality for a simple dhcp setup and mimics the ootb install image function. Further, installing NM as you indicated would result in a chicken or egg problem before reading a wall of text and realizing they have to setup a trivial and perhaps temporary dhcp solution in order to install a more permanent one anyway. The user has the ability to install packages in the chrooted environment, yes, but the expectation of a functional network in a freshly booted system is reasonable. One explanatory sentence or phrase can inform users that only one network config scheme is needed, as well as a brief warning to avoid conflicts (such warnings already exist elsewhere). The net conf. page can and should still be linked, but it is a monstrous page for something so trivial that can be suggested so succinctly. sent from my phone, will clean up formatting. -- Misfit138 (talk) 11:37 22 March 2023 (UTC-5)
systemd-networkd only supports using systemd-resolved for DNS. A network connection without working DNS is not something most people would want. I think the best we could do is to explicitly link to systemd-networkd as an example in Installation guide#Install essential packages. -- nl6720 (talk) 16:16, 22 March 2023 (UTC)
With just the /etc/systemd/network/20-wired.network file, and no other network tools, and after starting networkd and resolved, I can ping sites and visit urls with links and lynx; ostensibly, something is resolving DNS for me(?) (Confirmed on VM and bare-metal.) However, I must regretfully admit that I am not likely to compel you with the principles I have set forth. Thank you for your time and for considering this. -- Misfit138 (talk) 13:35 22 March 2023 (UTC-5)
I missed that you suggested to also enable systemd-resolved.service. In that case, just as systemd-resolved#DNS says, DNS will only work for software that do not parse /etc/resolv.conf themselves. -- nl6720 (talk) 17:44, 22 March 2023 (UTC)
Perhaps the "software necessary for networking" bullet point in Installation guide#Install essential packages could be extended with a tip that suggests using systemd-networkd + systemd-resolved and copying /etc/systemd/network/20-ethernet.network from the live environment. -- nl6720 (talk) 09:18, 28 April 2023 (UTC)
The crosslinked article already has a note, that could be added there instead, similar to Special:diff/773727.
While I see the point of this item, the systemd- tools are probably not the most beginner-friendly ones to configure networking anyway (for some use-cases ok, not for the scope of this guide. Other tools like netctl are arguably simpler to use). The skill to configure networking is important and that's not triggered by copying an autogenerated file. What's the general state of archinstall? Could it be a solution to add a tip for Arch newcomers at the beginning of the guide to it instead?
--Indigo (talk) 07:45, 29 April 2023 (UTC)
My idea was to somehow replace the note in Installation guide#Connect to the internet with a tip in Installation guide#Install essential packages. If there's no good way to do it, then let's keep things as is.
archinstall would probably warrant an entirely separate discussion.
-- nl6720 (talk) 13:02, 30 April 2023 (UTC)

Partitioning tools

Is there any reason gdisk is not listed as an option? If we include parted, despite problems with alignment, I don't see why gdisk is excluded. The wiki page for fdisk actually suggests gdisk as an alternative. I'm probably not the only one who learnt to use gdisk for GPT and it is nice to use a familiar tool if there's no reason not to. But I don't want to add it if it's omitted for a reason. --cfr (talk) 01:29, 20 August 2022 (UTC)

fdisk linking to gdisk is the result of a previous discussion about this.
Personally, I agree that Installation guide#Partition the disks should mention gdisk. My suggestion would be: "Use fdisk, parted or gdisk (GPT only) to modify partition tables".
-- nl6720 (talk) 10:16, 20 August 2022 (UTC)
By the same argument, we should then mention cfdisk, cgdisk and any other partition tools. As such I'd suggest the following instead: "Use a partitioning tool like fdisk or parted to modify partition tables". -- Alad (talk) 13:32, 24 August 2022 (UTC)
Your suggestion is better than the current text at least. -- nl6720 (talk) 08:44, 25 August 2022 (UTC)
In the end the situation is quite similar to the one for boot loaders and network managers. I wouldn't mind listing more alternatives (or even tables) in the installation guide, but then the reasoning has to be applied equally to other sections. -- Alad (talk) 15:08, 25 August 2022 (UTC)
I hope it's nothing like this sorry excuse for a table.
The thing with partitioning tools, compared to e.g. network managers, is that there are not that many of them. There's basically just fdisk, gdisk and parted. fdisk & gdisk additionally have scriptable and text user interfaces. And there are GUI ones based on parted.
I'd say let's go with your suggested text for now. We'll get to the greater goal eventually :D
-- nl6720 (talk) 15:22, 25 August 2022 (UTC)
The table in Partitioning#Partitioning tools got better, so IMHO it should be fine to link to it now. -- nl6720 (talk) 16:04, 28 August 2022 (UTC)
The "old" beginners' guide had a similar table included: User:Alad/Beginners'_guide#Partition_the_devices. Considering the small size, it could make sense to include the one from Partitioning#Partitioning tools in the installation guide directly. The downside is the GUI wrappers don't apply to the live environment. -- Alad (talk) 16:36, 28 August 2022 (UTC)
If there's a problem with parted not aligning, it strikes me as perverse to mention fdisk and parted by name, but nothing else. Surely the example tools should be ones which don't need special warnings (if at all possible)? Maybe fdisk should be the only example? (Unless it has changed, gdisk isn't on the ISO, so that's a good reason not to pick it out, but steering people away from parted seems warranted if it is problematic.) --cfr (talk) 03:13, 30 October 2022 (UTC)
Is everyone OK with "Use a partitioning tool like fdisk to modify partition tables"? That way we point to the resources while keeping only the tool used in the following examples. --Erus Iluvatar (talk) 21:34, 20 December 2022 (UTC)

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 ~~~~!

This is already done by pacman-init.service. Scimmia (talk) 23:38, 3 November 2022 (UTC)
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)
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)
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)
Reinitializing and populating the keyring is a solution for a completely different problem. Scimmia (talk) 13:32, 25 December 2022 (UTC)

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)

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)
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)
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)
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)
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)
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)
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)
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)
There's Netboot#Boot from a USB flash drive that can be linked now. -- nl6720 (talk) 16:10, 26 March 2023 (UTC)
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)

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.

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)

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)
(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)
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)
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)
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)
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)
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)

"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 ~~~~!

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)
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 ~~~~!
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)
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)
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)
I replaced "sound cards" with "onboard audio" which will hopefully get the message across better. -- nl6720 (talk) 05:56, 13 June 2023 (UTC)
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)
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)
"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)
Done. -- nl6720 (talk) 09:23, 30 June 2023 (UTC)
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)
Since no one has stopped me yet: Special:Diff/782857. -- nl6720 (talk) 10:20, 9 July 2023 (UTC)
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)
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)
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)
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)
👍 --Erus Iluvatar (talk) 11:02, 15 August 2023 (UTC)
Done. -- nl6720 (talk) 14:04, 30 August 2023 (UTC)

Add eMMC ignorable block devices

As seen in Special:Diff/786453, parts of eMMC devices can show up with fdisk but should be ignored.

Here's a rough translation of what's been added to the french translation:

Results ending in rom, loop, airoot, mmcblkXrpbm, mmcblkXboot0 and mmcblkXboot1 can be ignored. These last two partitions correspond respectively to the first and last four megabytes of the MMC disk, and are necessary for the operation of the technology supporting this type of disk. As such, they should not be modified - or modifiable. [13]

--Erus Iluvatar (talk) 13:32, 30 August 2023 (UTC)

We can add something of the sort to Installation guide#Partition the disks. Mind that the device name won't necessary be mmcblk0boot0 & mmcblk0boot1, and there's also mmcblkXrpmb. Perhaps we can add boot0, boot1 and rpmb to the suffix list. -- nl6720 (talk) 13:52, 30 August 2023 (UTC)
If there are too many variants to list on our side, is there a resource we should be pointing to instead? --Erus Iluvatar (talk) 14:20, 30 August 2023 (UTC)
I don't think there is one and some of them (airoot) are Arch-specific anyway. For MMC, there's only those three special devices, so the list wouldn't get too bloated. -- nl6720 (talk) 14:24, 30 August 2023 (UTC)
I've updated the "translation" which can serve as a draft :) --Erus Iluvatar (talk) 14:27, 30 August 2023 (UTC)
IMO any explanation on what those special devices are or do should be in Device file#MMC (it's been flagged for expansion for a while) instead of the installation guide. -- nl6720 (talk) 14:29, 30 August 2023 (UTC)
How about moving them to a separate sentence? E.g. "mmcblk* devices ending in rpbm, boot0 and boot1 can be ignored." -- nl6720 (talk) 06:14, 20 September 2023 (UTC)
Sorry I did not answer on your previous remark: splitting the what/why to the dedicated page and using a separate sentence like the one you suggested are both good suggestions I'm happy to get behind :) --Erus Iluvatar (talk) 06:29, 20 September 2023 (UTC)