Talk:Installation guide

From ArchWiki
(Redirected from Talk:Beginners' guide)

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)

HiDPI on the console

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

It could be added as an example for setfont in Installation_guide#Set_the_keyboard_layout. The issue I have is that HiDPI#Linux_console mentions that tty2-6 may be unusable, while the Installation guide specifically instructs to change ttys as required in Installation_guide#Boot_the_live_environment. -- Alad (talk) 13:07, 7 September 2019 (UTC)
May be as an example for the line "See README.bootparams for a list of boot parameters" Installation_guide#Boot_the_live_environment, it could be specified to hit e button to edit the boot entry and add the following parameters to the boot line, like video=1920x1080 if you have HiDPI display. -- Xzorg6 (talk) 22:41, 15 December 2019 (UTC)
video= will just change the resolution. To get a bigger font on the console, you need CONFIG_FONT_TER16x32=y in the kernel config and fbcon=font:TER16x32 in the kernel command line. Since the official kernels don't enable CONFIG_FONT_TER16x32, someone will need to open a bug report asking for it. After that, the instructions for setting the fbcon=font:TER16x32 kernel parameter could be added to the wiki. -- nl6720 (talk) 06:52, 16 December 2019 (UTC)
linux 5.5.6.arch1-1 (currently in testing) has CONFIG_FONT_TER16x32=y (FS#64861). If if gets move to core before March, then the March iso will have it. It's probably a good idea to start drafting a tip to place in Installation guide#Boot the live environment. -- nl6720 (talk) 11:12, 26 February 2020 (UTC)
And just after I wrote this, the package was moved to core. -- nl6720 (talk) 11:27, 26 February 2020 (UTC)
I'm seeing multiple claims[13][14][15] that people with HiDPI screens are getting the TER16x32 font. I was not aware that the kernel chooses a font depending on screen size. Can anyone confirm that this really is the case? If it really works that way and unless FS#65680 messes this up, then there's nothing to add to the Installation guide about this topic. -- nl6720 (talk) 06:02, 11 March 2020 (UTC)
As per https://lore.kernel.org/lkml/20190618203425.10723-4-tiwai@suse.de/ the decision to use ter16x32 is not based on screen size but only resolution.So even though a 1080p screen may be hidpi it does not use ter16x32 M.Srikanth (talk) 10:17, 11 May 2020 (UTC)
At least that part is now clear, thanks. The first step should be to get HiDPI#Linux console up to date. After that, as I've said before, a tip for the installation guide can be drafted. -- nl6720 (talk) 11:04, 11 May 2020 (UTC)
I fixed the page and removed the template M.Srikanth (talk) 12:25, 11 May 2020 (UTC)
It looks like HiDPI#Linux console (tty) is in good enough shape to link to it, here's a draft, which could be inserted after we talk about setfont(8). --Erus Iluvatar (talk) 21:49, 20 December 2022 (UTC)
Tip: To help with readability on HiDPI screens — if they are not already recognized as such — manually increasing the font size using fbcon=font:TER16x32 in the kernel command line can help. See HiDPI#Linux console (tty) for a detailed explanation.
HiDPI#Linux console (tty) should state how the kernel decides to use TER16x32; "accordingly based on the resolution of the display and not its pixel density" is very vague. Both that section and the tip should also mention on which resolutions should one expect to see the bigger font. ❄️❄️ nl6720 (talk) 09:16, 24 December 2022 (UTC)
I've changed the wording on HiDPI#Linux console (tty), is it clearer or should I dig into the exact formula? The issue here is that it's based on the vertical and horizontal pixel count of the display in relationship with the available fonts, and not the real resolution (i.e. PPI). Given that a 1080p screen can be considered HiDPI when used on a small enough physical display, explaining at which point the cut-off is automatic will not help users which need to manually set a bigger font --Erus Iluvatar (talk) 10:54, 24 December 2022 (UTC)
The tip is supposed to land in Installation guide#Boot the live environment (because of the supposed issues with VT switching), so I was thinking it should mention fbcon=font:TER16x32 explicitly. ❄️❄️ nl6720 (talk) 13:49, 28 December 2022 (UTC)
My bad, I failed to answer to that part: is the updated draft better ?I'll rewrite the tip properly tonight with its intended placement in mind.--Erus Iluvatar (talk) 14:03, 28 December 2022 (UTC)
Looks good! ❄️❄️ nl6720 (talk) 15:01, 1 January 2023 (UTC)
Here's the promised updated draft a few days late (now that I'm back from a quick family trip) /o\ --Erus Iluvatar (talk) 19:17, 1 January 2023 (UTC)
Tip:
  • The installation image uses GRUB for UEFI and syslinux for BIOS booting.
  • Use respectively e or Tab to enter the boot parameters, 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.

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)

Add a check for "native sector size" before/during partitioning step

Some pages like Solid state drive are nearly impossible to get to from just following the Installation Guide. This is problematic as some recommendations from these pages are only relevant before installation, as it is too late afterwards (notably for setting native sector size as in Solid state drive#Native sector size. I believe there should be a note in the partitioning step, something like modifying this line:

to

As an alternative, this could be added to Partitioning, but it's already quite big... -- Cvlc (talk) 15:47, 29 August 2021 (UTC)

Linking both Improving_performance#Partitioning (which needs improvements) and Solid state drive seems excessive. Also, it's unclear if the improvement is tangible enough to make users work through yet another wiki article for their basic setup. -- Alad (talk) 09:28, 31 October 2021 (UTC)
An alternative could be to add :
Tip: Check that your disk reports the correct sector size
at the beginning of partitioning. It's an important optimization step and currently not addressed. On a brand new nvme SSD, strictly following the wiki, I ended up with a wrongly set up LUKS volume because the drive reports 512 byte sectors as the active option, and I only found out after installing.
-- Cvlc (talk) 16:15, 23 November 2021 (UTC)
Seeing as the "native sector size" is the only issue that can't be simply fixed after the fact (unlike e.g. TRIM), it should be fine to link it (after Talk:Advanced Format#Rewrite Advanced Format to a new Sector Sizes page is done). As for linking to Solid state drive in general, IMHO there's no need. It's already linked from General recommendations#Solid state drives. -- nl6720 (talk) 09:53, 25 November 2021 (UTC)
Agreed, the sector size issue was the one that really bothered me. I corrected the title.
-- Cvlc (talk) 11:05, 25 November 2021 (UTC)
Now that Talk:Advanced Format#Rewrite Advanced Format to a new Sector Sizes page is done, I suggest adding
Tip: Check that your disk reports the correct sector size
before the partitioning step
-- Cvlc (talk) 03:42, 4 December 2021 (UTC)
As I already mentioned, there's a lot of steps involved in that article for unknown gains. Presumably, most people will think it's a requirement (due to the general nature of the article) even when formatted as a tip. Only Advanced_Format#Alignment is straightforward and already handled by fdisk. -- Alad (talk) 09:51, 9 January 2022 (UTC)
It's true that it's not a very simple article, but it's actually not that bad since people will skip to either HDDs or SSDs sections which are much more to the point. What do you think would be a better way to address this? formatting the disk to the correct sector size cannot be done at a later point in time. Again, all of this stems from the fact that it happened to me, and it's going to happen to anyone with a similar setup (most hardware with recent SSDs). What if I try simplifying the Advanced format article further ? --Cvlc (talk) 20:43, 9 January 2022 (UTC)
Perhaps something like "Tip: adjusting the storage device's sector size before partitioning it might be beneficial for performance." Neven (talk) 00:20, 6 May 2022 (UTC)
I'd omit the "for performance" part, since such claims would need references. And since not every drive can change its logical sector size, IMHO it would be better to explicitly mention to who the tip applies to. From what I understand, that would be a large part of NVMe drives and some "enterprise" SATA HDDs. Despite what Advanced Format says, I couldn't find anything about SATA SSDs that support changing their sector size.
-- nl6720 (talk) 13:18, 6 May 2022 (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)

Clarify root mount

Without having perused history, I suggest to change Installation guide#Mount the file systems slightly from

Create any remaining mount points (such as /mnt/efi) and mount their corresponding volumes.

to

After the root volume is mounted, create any remaining mount points (such as /mnt/efi) and mount their corresponding volumes.

an alternative may be to add to the following tip (e.g. "Alternatively, create it using mkdir(1) beforehand, but only after mounting the root volume.")

Reason: lsblk will happily show a /mnt/boot, even if it was mounted too early, potentially messing up pacstrap and genfstab. It will work, if /mnt/boot is mounted twice (once before and after root), but it is simpler to explicitly address mount order.

--Indigo (talk) 17:01, 2 June 2022 (UTC)

As the previous instruction is "Mount the root volume...", this seems pretty redundant. Scimmia (talk) 18:14, 2 June 2022 (UTC)
Frankly, I don't remember how the ISO behaves regarding pkg-cache: Will a repeated pacstrap download updates again? --Indigo (talk) 19:29, 2 June 2022 (UTC)
pacstrap(8) uses the target's package cache by default. If the target was correct, then there will be no re-downloading on repeated runs. -- nl6720 (talk)
Ok, thanks. --Indigo (talk) 19:00, 3 June 2022 (UTC)
I think all the confusion comes from new users not understanding the hierarchical structure. How about something like : "Create any remaining mount points (such as /mnt/efi) and mount their corresponding volumes in a hierarchical order." -- nl6720 (talk) 07:27, 3 June 2022 (UTC)
That's clearer for the rest, yes. I'd make that suggestion "Create any remaining mount points (such as /mnt/efi) and mount the volumes in their corresponding hierarchical order."
Regarding the root mount, I do understand the resentment to deviate from the established and proven form, fine.
This escapes the topic a little, but perhaps a catch-all procedural sentence is what it needs instead. For example, to the third intro paragraph: "This guide is deliberately kept concise and you are advised to follow the instructions in the presented order per section. For more detailed instructions, see the respective ArchWiki article or the various programs' man pages, both linked from this guide.".
--Indigo (talk) 19:00, 3 June 2022 (UTC)
Yes, "their corresponding hierarchical order" sounds a lot better.
I don't think the resistance to change is that bad. :) We could alter the root mount text if there's some consensus about it.
IMHO "deliberately kept concise" gives off a negative connotation. I can't think of any better suggestions at the moment, though.
-- nl6720 (talk) 11:17, 4 June 2022 (UTC)
How about "intentionally concise and you are advised ..."? --Indigo (talk) 15:38, 8 June 2022 (UTC)
That sounds better to me. 👍 -- nl6720 (talk) 05:11, 9 June 2022 (UTC)
Or since "intentionally concise" is not concise, "This guide is kept concise and ..." :) -- Alad (talk) 13:10, 12 June 2022 (UTC)
Ok. To summarise, we'd add:
"This guide is kept concise and you are advised to follow the instructions in the presented order per section." to start the third para intro,
and change corresponding sentence in Installation guide#Mount the file systems to
"Create any remaining mount points (such as /mnt/efi) and mount the volumes in their corresponding hierarchical order."
if no further objections arise.
--Indigo (talk) 16:54, 15 June 2022 (UTC)
A month has passed with no objections. I think you can update the page now :) -- nl6720 (talk) 13:56, 15 July 2022 (UTC)

Wouldn't be better to tell users to go with /mnt/efi (or /mnt/boot/efi)? Mounting /mnt/boot as ESP (FAT32) could lead to some confusion for newbies.
Besides, I think it's better native Linux files to be on Linux native Filesystems.
What do you think guys? --D.ALT (talk) 09:46, 5 January 2023 (UTC)

/mnt/boot/efi is a relic of the past. I don't see how mounting the ESP to /mnt/boot "could lead to some confusion for newbies". What's there to be confused about exactly? It's the only mountpount that's guaranteed to work in all setups -- nl6720 (talk) 09:50, 5 January 2023 (UTC)
Yup, good point about /mnt/boot/efi (I forgot about this one indeed). Confusion: newbies may think about /mnt/boot being the Boot Partition (only) and don't know what to do for the ESP one. Or, another solution would be stop mentioning /mnt/efi as an ESP without specifing meaning and/or explanation (here there are ESP's references to both /mnt/efi and /mnt/boot) --D.ALT (talk) 10:27, 5 January 2023 (UTC)
Mone of this has anythign to do with the topic. It also completely ignores how UEFI works. Scimmia (talk) 12:49, 5 January 2023 (UTC)
So, picking up the strings of the change agreed above, we'd change existing sentence with "(such as /mnt/efi" to:
"Create any remaining mount points (such as /mnt/boot) and mount the volumes in their corresponding hierarchical order."
to close this. --Indigo (talk) 22:08, 3 February 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)

Consider adding link to Ext4

In Section 1.10 - Format the partitions, consider adding a link to Ext4 article (https://wiki.archlinux.org/title/Ext4).

The reason is simple - that's what I wanted and expected to be there, but it wasn't, and so I had to google it.

One deeper reason is that for a beginner, the fact that the "recommended" file system for root partition is called Ext4, might not be intuitive, and it might provoke questions like "Why ext4? What is it? What are the alternatives?".

Green Day (talk) 20:00, 8 October 2022 (UTC)

There is no recommended file system for root. The section already has a link to File systems, you can find Ext4 there. — Lahwaacz (talk) 08:18, 9 October 2022 (UTC)
If we leave out the deeper discussion on what's recommended or not, I'd say nothing speaks against replacing ext4 with ext4 in the installation guide. -- Alad (talk) 15:32, 25 October 2022 (UTC)
Given the wording of the section, link-ifying Ext4 is probably without downsides? --Erus Iluvatar (talk) 21:29, 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)

Microcode

Should microcode not be mentioned at some point? Right now it is buried in 'General Recommendations' with details via a further link, but it is surely more important than that suggests. If all users of Intel and AMD CPUs need it 'to ensure system stability' as the Microcode page says, it should be mentioned here. This is especially true since it naturally goes along with installing the kernel and configuring the bootloader. Otherwise, the bootloader config just has to be done again. I was sure it had a more prominent mention but either I've forgotten or it has been relegated. --cfr (talk) 04:53, 10 December 2022 (UTC)

The point where it is mentioned is General recommendations#Microcode. — Lahwaacz (talk) 07:27, 10 December 2022 (UTC)
I think it would be ok to list microcode in Installation guide#Install essential packages. Setting it up post-installation may be too late for "CPUs with severe hardware bugs". -- nl6720 (talk) 09:01, 10 December 2022 (UTC)
I think that's too early as the boot loader is not set up at that point. Hmm, it's already mentioned in Installation guide#Boot loader too... — Lahwaacz (talk) 09:14, 10 December 2022 (UTC)
The first step is to install the package(s). -- nl6720 (talk) 09:19, 10 December 2022 (UTC)
Yes but it can be installed later, along with the boot loader. The instruction to install a boot loader is in Installation guide#Boot loader. — Lahwaacz (talk) 09:25, 10 December 2022 (UTC)
Sooo, do we want to move the link from Installation guide#Boot loader to Installation guide#Install essential packages or simply add it? We already fit a few things in there, in particular ALSA firmware. --Erus Iluvatar (talk) 21:27, 20 December 2022 (UTC)
I think Lahwaacz is right. Installation guide#Boot loader is the correct place for it, since you'll only need microcode if you boot Arch on bare metal. -- nl6720 (talk) 10:57, 20 January 2023 (UTC)

Recommended minimum size of ESP is becoming cramped for certain popular installations (kernel & initcpio on ESP + Nvidia and/or KMS)

The recommended size for the ESP in https://wiki.archlinux.org/title/Installation_guide#Example_layouts is a very uninformative "At least 300 MiB". This, if followed naively, used to comfortably fit systemd-boot, two kernels with fallback images, a Windows bootloader, and some additional utilities like memtest86. However, we're seeing quite a few people on IRC running Nvidia and KMS for whom this is no longer sufficient, and they run into space limitations, either when upgrading their systems or at initial install. Obviously there's nothing we can do for people upgrading, but we can try to prevent people installing new systems running into this issue.

If you click through to https://wiki.archlinux.org/title/EFI_system_partition, and then go to https://wiki.archlinux.org/title/EFI_system_partition#Create_the_partition (note the link in the "Example layouts" table does not go directly there), there's a single sentence stating "The partition size should provide adequate space for storing boot loaders and other files required for booting.". We don't provide any indication of how large the initcpio and fallback initcpio for a single kernel might get, and many people going through the install guide likely never consciously see this sentence at all, or not until it's far too late (i.e. they've partitioned, pacstrapped, installed systemd-boot, and find their ESP doesn't fit their kernels; at this point, most are forced to restart the process from scratch or shrink some partitions and move stuff around).

The only indication we give that you might want more than 300MiB is on that same page, "To prevent interoperability issues with other operating systems" (but we don't really say what those might be) and "For early and/or buggy UEFI implementations the size of at least 512 MiB might be needed". Judging from IRC, these are no longer the primary reason you might want more than 300MiB.

W.r.t. the compatibility reasons, Rod Smith (who wrote gdisk) always suggested 550MiB for new ESPs on https://www.rodsbooks.com/efi-bootloaders/principles.html. It's unclear to me why we only recommended 300MiB.

It is my opinion that for people who do not understand all the nuances up front, it is much less of a problem to accidentally create an ESP that is a few hundred MiBs too large than a few hundred MiBs too small, with the mantra "it's 2023, disk space is cheap" in mind.

There's three options on the table:

  1. Leave as-is.
  2. Leave "at least 300MiB" but add a clear warning on this page that if you're planning to run more than one kernel and keep the kernels on the ESP, factor in a comfortable somewhat future-proof 150MiB per kernel; more if you're planning to use Nvidia and KMS.
  3. Up the number to "at least 550MiB" and add a note (not a warning) that you can have a smaller ESP, but should read the information on https://wiki.archlinux.org/title/EFI_system_partition to determine whether you should.

Option 1 is undesirable to me (I'm writing this proposal after all). Option 2 is okay-ish but puts a lot of additional reading and deciding on people before even starting partitioning. I prefer option 3: people who don't yet know all the nuances of what they're doing are less likely to be bitten by any issues, including the interoperability ones; and people who do know what they're doing are free to deviate.

If option 3 is chosen, we might want to separately improve some of the information about sizing in https://wiki.archlinux.org/title/EFI_system_partition

MacGyver (talk) 12:47, 6 January 2023 (UTC)

The only other thing I'll point out is that the kms mkinitcpio hook is now default, which is why this is becoming an issue. In some limited testing, the kms hook adds about 20.5M to the standard initramfs, and about 30.5M to the fallback (amdgpu system). It effectively doubles the space each kernel needs, even before adding nvidia to the mix, which would add another 42M to each initramfs, assuming an integrated gpu.
Scimmia (talk) 14:05, 6 January 2023 (UTC)
NVIDIA#Installation has a note to "Remove kms from the HOOKS array in /etc/mkinitcpio.conf." Or is this about nouveau? — Lahwaacz (talk) 07:35, 7 January 2023 (UTC)
The wiki recommends 300 MiB because that's what Windows uses on 4Kn disks (see Special:Permalink/703297#Bump the recommended ESP size to 300 MiB), what's why the "To prevent interoperability issues with other operating systems" phrase is there. It nicely matches with the 200 MiB suggested size for /boot while leaving enough space for other stuff.
[16] explains why it recommends 550 MiB. It's 512 MiB for early UEFI, to ensure mkfs.fat creates FAT32 and because people confuse MiB and MB.
For multiple kernels, Partitioning#/boot recommends 1 GiB. I would guess that most people don't install more than one kernel, so I don't think this is an issue to highlight in the installation guide. IMHO this topic could be solved if EFI system partition#Create the partition would link to Partitioning#/boot. E.g. something like: "The partition may need to be larger if it will be mounted to /boot and you plan to install multiple kernels. See Partitioning#/boot."
-- nl6720 (talk) 09:13, 7 January 2023 (UTC)
It's hard to say if people installing more than one kernel is more than a guess, e.g. pkgstats claims a 33% install rate of linux-lts. In any case, having to potentially extend a /boot partition (likely leading to a repeat installation in most cases) is a nuisance, and the proposed example sentence is quite small. I propose to add it as a footnote in Installation_guide#Example_layouts. -- Alad (talk) 18:40, 7 January 2023 (UTC)
I updated EFI system partition#Create the partition to suggest 1 GiB for multiple kernels. For Installation guide#Example layouts, how about adding something to the "Suggested size" column instead of a footnote? -- nl6720 (talk) 11:58, 8 January 2023 (UTC)
How about "At least 300 MiB. If multiple kernels will be installed, then no less than 1 GiB."? -- nl6720 (talk) 10:37, 20 January 2023 (UTC)
Sounds good to me; although maybe "If multiple kernels or operating systems will be installed..."? MacGyver (talk) 23:42, 30 January 2023 (UTC)
IMHO that would be too vague. "Multiple operating systems" can easily live with a shared 300 MiB ESP, there should be no issue if that other operating system is Windows. If it's about Linux distros that, just like Arch, suggest using the ESP for /boot, then we can't really make any good recommendations. A "4 GiB should be enough." could work, though it wouldn't sound very serious or convincing. -- nl6720 (talk) 10:31, 31 January 2023 (UTC)
I updated the suggested size column to match Partitioning#UEFI/GPT layout example. I'm not too sure if people who first install Arch will be able to evaluate if they should plan for multiple kernels, but I don't see a better way to handle this. Reopen if something still needs adjusting. -- nl6720 (talk) 15:08, 1 February 2023 (UTC)
+1 for either increasing the 300 MiB number, or adding a note that encourages the user to leave room for expansion. I heeded that figure for my current installation, and have been paying the price; I dual-boot with Windows, sometimes use a different kernel for gaming, and then recently I found myself needing Memtest86 (which is what pushed it over the edge). Plus, storage has gotten cheaper :) -- CodingKoopa (talk) 04:52, 8 January 2023 (UTC)

Expand on networking in Install essential packages

Reading [17] made me think that perhaps Installation guide#Install essential packages should explicitly mention wireless stuff (botht Wi-Fi and WWAN) in the "software necessary for networking (e.g. a network manager or DHCP client)," line.

I can't think of a good way to phrase it, though :/

-- nl6720 (talk) 10:51, 20 January 2023 (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)

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)

timedatectl status --> timedatectl

Is timedatectl status redundant? Or is there a specific reason for including it?

--AvidSeeker (talk) 16:03, 31 January 2023 (UTC)

There's probably no specific reason. I'm fine with removing status from the command. -- nl6720 (talk) 14:51, 1 February 2023 (UTC)