Talk:Installation guide

From ArchWiki
Jump to navigation Jump to search

Read this first before adding new suggestions

  • systemd tools such as hostnamectl, timedatectl and localectl do not work in the installation chroot environment, so please do not propose to use them in the guide unless you can prove that they have been made to work also in that case. See [1], [2], [3] and [4] for some past discussions about this issue.
  • localectl list-keymaps does not work due to bug FS#46725. For the chosen replacement command, see [5].
  • localhost must be set explicitely in /etc/hosts, as it is otherwise resolved over the network. See FS#56684.
  • 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.

-- 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: [11]. 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)

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

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

I think the ArchWiki should not just say do X but also why. Alad as you added this, perhaps you can explain?--Larivact (talk) 15:14, 21 May 2018 (UTC)

In Network_configuration#Local hostname resolution: "For a system with a permanent IP address, that permanent IP address should be used instead of 127.0.1.1." -- Lahwaacz (talk) 06:48, 22 May 2018 (UTC)
First appearance in our wiki, cited source, also discussion. -- Kynikos (talk) 10:26, 22 May 2018 (UTC)
Clear enough, close. -- Blackteahamburger (talk) 01:58, 10 August 2020 (UTC)
This should be explained in the guide or at least in Network_configuration#Local hostname resolution. Explaining stuff in the edit summary or on talk pages is not enough. -- Lahwaacz (talk) 09:43, 10 August 2020 (UTC)

Wording in example layout table and size of EFI partition

Formatting the ESP

I believe myself that the partition table should be modified. When Going through the install, it was confusing how swap was the last partition, usually suppose to be the partition before Root, as if the computer loads up swap before user login. Didn't realize that a GPT disk needed to be formatted until reading this guide: https://wiki.archlinux.org/index.php/EFI_system_partition . Would recommend at least linking to this section of the document or even input Format partition section within the Wiki. Shaggy (talk) 20:15, 29 June 2020 (UTC)Shaggy

The order of partitions is irrelevant and it has (mostly) no effect on booting. The fact that the ESP needs to formatted after its creation cannot be simply stated, as it could be misinterpreted as requiring to always format it, even if is an existing partition that already has a file system.
After reading an anecdote, I think moving swap before root should be considered :D
-- nl6720 (talk) 09:39, 1 July 2020 (UTC)
I've been thinking, how about placing the mkfs.fat -F32 /dev/sdxY command in Installation guide#Format the partitions. EFI system partition#Format the partition could instead be modified to omit the FAT type (i.e mkfs.fat /dev/sdxY). FAT32 is a recommendation, but not mandatory, thus it's more appropriate for the Installation guide, and this would allow to document the 2 MiB FAT12 formatted ESP, used by User:Eschwartz and others, in the EFI system partition article. -- nl6720 (talk) 11:14, 13 August 2020 (UTC)
I guess that's reasonable, if you add the note that an existing EFI partition may have to be preserved. (cf. User:Alad/Beginners'_guide#Format_the_partitions) -- Alad (talk) 20:10, 14 April 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[12][13][14] that people with HiDPI screens are getting the TER16x32 font. I was not aware that the kernel chooses a font depending on screen size. Can anyone confirm that this really is the case? If it really works that way and unless FS#65680 messes this up, then there's nothing to add to the Installation guide about this topic. -- nl6720 (talk) 06:02, 11 March 2020 (UTC)
As per https://lkml.org/lkml/2019/6/18/966 the decision to use ter16x32 is not based on screen size but only resolution.So even though a 1080p screen may be hidpi it does not use ter16x32 M.Srikanth (talk) 10:17, 11 May 2020 (UTC)
At least that part is now clear, thanks. The first step should be to get HiDPI#Linux console up to date. After that, as I've said before, a tip for the installation guide can be drafted. -- nl6720 (talk) 11:04, 11 May 2020 (UTC)
I fixed the page and removed the template M.Srikanth (talk) 12:25, 11 May 2020 (UTC)

First mention of /mnt in example partition layout

/mnt is mentioned at mount point in Installation_guide#Partition_the_disks, while /mnt is made explicit two sections later in Installation_guide#Mount_the_file_systems. As I recall it, this was changed because some users blindly copy pasted commands and mounted /boot on the live system, instead of /mnt/boot. Some options:

  • Introduce another column describing the mount point on the installed system.
  • Actually explain /mnt early.
  • Revert the "mount point" to not include /mnt.

-- Alad (talk) 13:03, 7 September 2019 (UTC)

I don't understand what's the actual problem here... -- Lahwaacz (talk) 09:36, 8 September 2019 (UTC)
From what I read on #archlinux-wiki, this comes from https://www.reddit.com/r/archlinux/comments/d0v0j3/is_it_just_me_or_is_the_prospect_of_installing/ where the user was confused by the lack of root mountpoint (i.e. /mnt vs /). A question could be raised, if we should concern ourselves with users who have strong opinions about the wiki content yet can't be bothered to propose improvements in the talk pages...
About Alad's proposed options: I disagree with the first option, I think it will just complicate things even further. I support the third option and maybe adjusting the column header like in Special:Diff/581800.
I'd actually would like to go even further and change the commands run from outside chroot to be visually distinct, e.g.:
root@archiso # mount /dev/sdX1 /mnt
I think it would better solve the underlying issue.
-- nl6720 (talk) 15:26, 8 September 2019 (UTC)
I'm not overly fond of the longer column name. For the last proposed option, I may agree if this is formalized in Help:Style, so that it is not specfic to the Installation guide. -- Alad (talk) 11:20, 10 September 2019 (UTC)
Adding it Help:Style was my intention, since other articles, too, will need to use that style for some commands. I'm thinking of creating a template for it: Special:Permalink/581945. -- nl6720 (talk) 10:19, 11 September 2019 (UTC)
Sounds good to me, I'd just prefer the regular (non-bold) font for the prompt as above. -- Alad (talk) 21:54, 13 September 2019 (UTC)
Special:Permalink/582327. Are there any other opinions about creating such a template? Or should I take this discussion to Help talk:Template per Help:Template#Creation? -- nl6720 (talk) 18:31, 14 September 2019 (UTC)
  1. How are you going to call the template? This template would probably add to the Help:Template#Code formatting templates series, should it be named in a consistent fashion?
  2. Should this template support custom prompts, and if so, should it be called "pc" (from "(custom) prompted" code)?
  3. I don't like the red color too much, if bold is not an option maybe we can go green|purple|blue, something that recalls less a warning of some kind? Or can we just leave it with the default font color? Or a slightly fainter black?
  4. I haven't looked well into it, but maybe we can instead add an optional argument to Template:bc and Template:hc that prefixes a custom (colored) prompt? I wouldn't see a problem with repeating "root@archiso #" in every instance, or we may derive the new template from those two at that point.
  5. The template should probably be derived from Template:bc in any case, for simpler code, see User:Kynikos/Template:Sandbox2.
-- Kynikos (talk) 17:36, 16 September 2019 (UTC)
  1. Initially I was going to call it Template:Archiso since it would be Archiso-specific, but I'm starting to think that creating a more general-purpose template would be better. It could then be used in PostgreSQL and the [postgres]$ convention would get formalized in Help:Style. Now the issue is the [user@peer-a]# in Template:hc used in WireGuard. I'd rather not create two new templates, but I'm having trouble getting Template:Sandbox to work :(
  2. I like your "Template:pc" suggestion.
  3. Be glad I didn't post my first draft that was slightly more colorful. From your offered colors, I'd choose purple.
  4. I'd rather not mess with the established templates just for this change, so I'd prefer creating a new template.
  5. I didn't even think about using Template:bc. Is it a good idea to do that? The new template might need to be updated if Template:bc is ever changed in an incompatible way.
-- nl6720 (talk) 07:33, 17 September 2019 (UTC)
Yeah, after viewing your attempts and looking into it myself, I think modifying bc/hc is out of discussion, it would add too much code/style for so little use.
Thinking about this again one day after, I feel I'm realizing that my concerns in general may descend from the fact that we're going to create a template to represent (block) code, even though we already have 2 which basically do the same thing, including allowing to include a prompt; the only addition of this "Archiso" or "pc" template would be the formatting around the prompt, so why not keep it simple (I know, "simplicity" is often subjective and controversial) and instead either make a Template:Archiso to be used like {{bc|{{Archiso}} mount /dev/sdX1 /mnt}} or Template:ps (or Template:PS) to be used like {{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}? They also work with Template:hc and space-prefixed code blocks!
Putting the choice of color aside, if the above idea of a standalone prompt template isn't welcome, I think my second choice would be to make two Template:pbc and Template:phc that work like {{pbc|$|ls}} and {{phc|$|ls|...}}, with the style rule to use them only in case of complex prompts. I'd still derive them from bc/hc to inherit any changes that we'd decide to make to them, and avoid repeating that ugly <pre> hack even more.
Otherwise I give up and accept the Template:Archiso that works like {{Archiso|mount /dev/sdX1 /mnt}}, in the hope that one day we won't need an analogous "hc" version.
-- Kynikos (talk) 14:24, 17 September 2019 (UTC)
I can't say I really like the idea of {{bc|{{Archiso}} mount /dev/sdX1 /mnt}} or {{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}. I'd prefer creating Template:pbc and Template:phc.
I still don't get what's wrong with Template:Sandbox. It should just work:
prompt # command
code
-- nl6720 (talk) 04:43, 18 September 2019 (UTC)
FWIW (and a bit of fun) I've fixed Template:Sandbox, although I'm not sure if we really need that level of automation ^^ I stick to my position above, is there a third (or more) opinion? -- Kynikos (talk) 15:48, 18 September 2019 (UTC)
I think you like the #800080 shade of purple, right? ;-) Lahwaacz (talk) 11:39, 21 September 2019 (UTC)
Yes, I do like that one :D but I think it would be too bright for this template. -- nl6720 (talk) 11:52, 21 September 2019 (UTC)

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)

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)

RAM usage

Attempting to boot the ISO with 532MB RAM (VM) and it hangs at attempting to mount the ISO. Changing RAM to 544MB allows the Arch ISO to boot, so I suspect the amount of RAM needed on the page isn't accurate. Beepboo (talk) 14:11, 17 August 2020 (UTC)


Updated again. Note that after installation the system can still easily get under 512 MB. -- Lahwaacz (talk) 14:05, 17 August 2020 (UTC)
Lahwaacz, it's missing fullstop "." in the end of this sentence. -- Josephgbr (talk) 23:49, 17 August 2020 (UTC)
Actually not missing (found it just now), but should it be after the reference link? -- Josephgbr (talk) 23:51, 17 August 2020 (UTC)
It's used the same way also in Installation guide#Select the mirrors. -- Lahwaacz (talk) 07:01, 18 August 2020 (UTC)
From what I've seen, most wiki pages use it the same way. -- nl6720 (talk) 07:52, 19 August 2020 (UTC)
There is actually an open discussion about this: Help talk:Style/Formatting and punctuation#Reference links before or after punctuation marks? -- Lahwaacz (talk) 08:05, 19 August 2020 (UTC)

Boot issues faced when installing on modern machines.

One may encounter "Invalid signature" when trying to boot from the installation media on a machine with secure boot on and keys not cleared.

Also, after installing on a NVME SSD, one need to set the drive to AHCI mode instead of Intel Optimized (in bios configuring panel), otherwise you just can't boot into the system.

Sffred (talk) 00:05, 24 September 2020 (UTC) Sffred 1600905886

AHCI is a SATA controller operation mode, it shouldn't have anything to do with NVMe. You can add a section to Partitioning#Troubleshooting about changing the SATA mode if Linux doesn't see SATA disks, but make sure you're using the correct terms. -- nl6720 (talk) 06:27, 25 September 2020 (UTC)
Some motherboards support SATA over the M.2 port, which may be the source of this confusion. -- Lahwaacz (talk) 07:33, 25 September 2020 (UTC)
w:M.2#Storage interfaces lists "PCI Express using AHCI" as an option, but it's unclear if such a mode is actually implemented by any firmware, and even if it was, it should not be recommended as it would drastically reduce the drive's speed. From what I could find[15][16][17], it looks like manufacturers simply interpret "SATA mode" being set to "AHCI" on NVMe controllers to mean "use native operating mode without firmware RAID". -- nl6720 (talk) 08:33, 25 September 2020 (UTC)
While on the topic of SATA (and non-SATA) operating modes, any thoughts about the backup GPT header corruption warning in GPT fdisk#Convert between MBR and GPT? -- nl6720 (talk) 08:37, 25 September 2020 (UTC)
Sorry, I have no idea... -- Lahwaacz (talk) 10:57, 26 September 2020 (UTC)
I added a note about Secure Boot to Installation guide#Boot the live environment. If anyone's wondering why it says "installation images" then that's because of ipxe.efi (the EFI binary for Netboot). -- nl6720 (talk) 06:52, 28 September 2020 (UTC)

Consider warning users about the additional steps required when selecting a partition other than /boot as their ESP

I understand that I have a responsibility to read through documentation other than just the install page, but the example layouts section implies that /efi and /boot can be used interchangeably. This is not the case and I think users would benefit from a more explicit statement of the importance of /boot:

  • the built kernel always goes there unless you build the kernel yourself
  • the microcode goes there
  • all (?) bootloaders can access these files if the ESP is set as /boot, not necessarily true when selecting a different ESP

I chose systemd-boot and, from the outside looking in, it was not clear that "Cannot launch binaries from partitions other than the ESP or the Extended Boot Loader Partition (XBOOTLDR partition)" would be a problem until I had to chroot back in from a failed boot and copy the files from /boot.

I think other users would benefit from being told explicitly to be careful about which bootloader to choose if they choose an ESP other than /boot right there on the install page.

Thoughts?

Dedushka (talk) 20:19, 15 December 2020 (UTC)

What about the warning was unclear? Scimmia (talk) 14:36, 16 December 2020 (UTC)
I think it lacks the detail that packages install to /boot and not /efi.
What if we removed "or /mnt/efi" from the table on this page? Both linked articles on partitioning and the ESP describe fully the details of ESP mount points and their caveats. Additionally it seems /boot and /efi are not the only choices. Hence: what does any reader gain from seeing the option here? If they want to do something else the information is readily linked and available, yet /boot alone seems perfectly adequate to me for an example layout. Tme5 (talk) 17:53, 11 May 2021 (UTC)
Thanks for the notice. My thought about that was to propose a "default" way or two to install boot loaders on this page (I did that in a separate talk section above). -- Ynikitenko (talk) 16:24, 30 December 2020 (UTC)

Swap partition vs swap file

Would it be reasonable to stop suggesting using swap partitions and instead recommend creating a swap file? Will genfstab work in a chroot environment to create a correct fstab? Managor (talk) 12:50, 3 February 2021 (UTC)

There's no reason why swap files should be given preference over swap volumes, using one or the other (or both) is a choice left to the user. Installation guide#Example layouts already mentions swap files, although, maybe some reference to them could also be added to Installation guide#Format the partitions and Installation guide#Mount the file systems. -- nl6720 (talk) 14:51, 4 February 2021 (UTC)

/etc/hosts: dual ip4/ip6 localhost prevents ip4 from working

I recently set up a new system with /etc/hosts copied from the guide:

127.0.0.1	localhost
::1		localhost
127.0.1.1	myhostname.localdomain	myhostname

I found localhost did not resolve to 127.0.0.1 which caused some docker comms to fail etc.

Removing or renaming the ip6 binding allowed ip4 localhost to work again, so perhaps the following should be used in the guide instead:

127.0.0.1	localhost
::1		ip6-localhost
127.0.1.1	myhostname.localdomain	myhostname

—This unsigned comment is by Alexheretic (talk) 09:18, 19 February 2021‎. Please sign your posts with ~~~~!

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)

Network Configurarion localdomain

Hello!

Is ".localdomain" string to be added as it is? Isn't localdomain supposed to be set by user like myhostname?

If yes, then that should be reflected in the Installation Guide as:

...

Add matching entries to hosts(5):

/etc/hosts
127.0.0.1	localhost
::1		localhost
127.0.1.1	myhostname.localdomain	myhostname

...

Rootkea (talk) 04:42, 9 April 2021 (UTC)

w:.local serves a special purpose, but .localdomain indeed seems a placeholder with no special meaning. I'll make the change, thanks. -- Alad (talk) 19:44, 14 April 2021 (UTC)
The question now is, if it's a placeholder, what do you replace it with? Not every system has (or needs) a real domain name. -- nl6720 (talk) 07:00, 15 April 2021 (UTC)
So I don't need a hostname, I can just put localhost , right? Highfrequencyhertz (talk) 19:18, 10 June 2021 (UTC)
FWIW, I don't have anything related to localhost in my /etc/hosts on a laptop... — Lahwaacz (talk) 19:39, 10 June 2021 (UTC)
Should a note be added to the wiki explaining that it is optional or not needing to be substituted by anything? I think that leaving it as is could be confusing. Highfrequencyhertz (talk) 02:41, 12 June 2021 (UTC)
Indeed, this confused me while updating this section in Installation guide (Français). I think this needs to be expanded to explain why one should fill it or not (but nothing more in the "Installation guide" IMO). Maybe this could link to Network configuration#Local hostname resolution have it explained there. Nophke (talk) 07:29, 9 July 2021 (UTC)

Adding ordinary user should be part of Arch installation

Hello!

Currently, Installation Guide has link to "General recommendations" page under "Post-installation" section. The "General recommendations" page has recommendations regarding GUI, console improvements, user management, appearance, font etc. All these recommendations are optional to use Arch Linux. User doesn't have to use GUI or set up tab-complete enhancements as recommended to use Arch as these are "General recommendations" but using root account only is like walking with chaninsaw and Flopsy, an adorable rabbit as per the linked SE answer on that page. https://apple.stackexchange.com/questions/192365/is-it-ok-to-use-the-root-user-as-a-normal-user/192422#192422

Creating and using ordinary user account is not optional. No wonder many distros have ordinary user creation in Installation flow. I would like to request to include adding ordinary user acccount as part of Arch installtion.

Perhaps under "Configure the system" above the "Boot loader" section?

Anyways, Feel free to close/strikeout this issue if you think this is not necessary. :) Rootkea (talk) 10:53, 9 April 2021 (UTC)

That's more about system management than it is about getting the system up and running IMO.
Scimmia (talk) 14:12, 9 April 2021 (UTC)
I wouldn't add an explicit section either, but a link in the last section (Installation guide#Post-installation) might be a good idea. Something like:
See General recommendations for system management directions and post-installation tutorials (like unprivileged user accounts, setting up a graphical user interface, sound or a touchpad).
-- Alad (talk) 09:24, 10 April 2021 (UTC)

fstab is optional in some cases

When using a GPT-partitioned disk, partition with the right partition types, and booting with systemd, creating fstab is optional.

Could a hint on this be added to the fstab section? Hugo Osvldo Barrera (talk) 19:23, 8 July 2021 (UTC)

This is a very specific case (for systemd-boot), while an explicitly generated fstab works with any boot loader. -- Alad (talk) 10:43, 9 July 2021 (UTC)
It seems that Refind can set the LoaderDevicePartUUID variable too, so should work as well. It's only optional for those boot loaders though, you're right. What I have in mind is a note with a link to the above link, so that readers can figure out if it's optional for them or not, not an actual statement that it's always optional, since that would not be accurate. WhyNotHugo (talk) 11:51, 9 July 2021 (UTC)

Make the Boot Loader Section slightly more detailed to provide a high level overview for new users

Boot Loader

A boot loader is a program which takes control for booting into the system after the firmware(BIOS/UEFI) of the machine has loaded. For most use cases GRUB should be the best choice GRUB is the most popular boot loader across most Linux distributions and usually officially supported for most purposes. However it needs to be separately installed in Arch Linux.

Systemd-boot is a bootloader included with Arch Linux which is a part of Systemd. Systemd is included in the Arch Linux base meta package installed by default . However it supports only UEFI systems while GRUB supports both UEFI and BIOS.

If you have an Intel or AMD CPU you may want to enable microcode updates in addition to having a boot loader.

New users and those who wish to boot multiple Operating Systems easily should may wish to use GRUB as it is very relatively easy to setup and works out of the box with minimal setup configure for most use cases. Using GRUB will mean you will be using software that is widely documented and supported officially by nearly every Linux distribution and hence getting support may be easier.

--Kibybyte (talk) 10:34, 14 July 2021 (UTC)

"included with Arch Linux" is highly ambiguous, the same thing could be said about all other boot loaders which have a package in the official repositories. — Lahwaacz (talk) 10:56, 14 July 2021 (UTC)
Dear Lahwaacz, what I meant was systemd-boot comes with the Arch Linux base meta package, it isn't too hard to set up (certainly harder than GRUB) and works well with the rest of the system. I have edited my original entry to include this.--Kibybyte (talk) 12:15, 14 July 2021 (UTC)
There are no packages that are "installed by default". You install whatever you specify on the pacstrap command line. There's also no "best choice" for a boot loader. See one of the many past discussions on this topic: [18], [19], [20], [21], etc. -- Alad (talk) 15:35, 14 July 2021 (UTC)
Dear Alad, in the links you have sent people have tried forcing a boot loader. They have included commands. I on the other hand have only included a brief theoretical overview which(I hope) would be helpful and pragmatic.--Kibybyte (talk) 03:18, 15 July 2021 (UTC)
This is all already on the page, or on the linked bootloader page, minus your personal recommendations. Scimmia (talk) 11:16, 14 July 2021 (UTC)
It's a critical step and the linked table is very informative but not very helpful. Making a recommendation here is important, I think. We should at least steer newbies towards GRUB or systemd-boot. — Heftig (talk) 12:07, 14 July 2021 (UTC)
There was [22] which was removed with an unhelpful edit summary. I don't really mind examples like that. Specifically singling out one boot-loader as "the best choice" or "very easy" as in the draft above is too much however. -- Alad (talk) 15:45, 14 July 2021 (UTC)
Dear Alad, I have struck out the portion you mentioned and updated it. The important thing to note is GRUB/systemd-boot satisfies most use cases and hence at least a recommendation in the Installation Guide would be a good, pragmatic step towards usability, just like how ext4 and the linux package are recommended. --Kibybyte (talk) 03:18, 15 July 2021 (UTC)
No. These are not even comparable. Your paragraph is a long-winded dialog on why a particular approach is preferable over another. ext4 is mentioned as an example (using the wording "for example, to create an ext4 file system") and linux has a tip right next to it it can be replaced with a different kernel package, or omitted for containers.
What would be comparable is the sentence "For example, set up the boot loader with systemd-boot if your system supports UEFI, and GRUB when not" mentioned above. Something like "Use GRUB for all systems, because GRUB is the most easy and most widely supported" will never be accepted. -- Alad (talk) 09:26, 20 July 2021 (UTC)
Dear Scimmia, while all the details are available on the pages linked in great depth, I think it would be of much help to have a brief, high level overview of boot loaders in the Installation guide, especially to new users. --Kibybyte (talk) 12:15, 14 July 2021 (UTC)
Arch_boot_process#Boot_loader is already a high-level overview. What are you missing there precisely? -- Alad (talk) 15:45, 14 July 2021 (UTC)
Dear Alad, I feel having an overview in the Installation Guide would be very helpful since it is a Guide after all. --Kibybyte (talk) 03:18, 15 July 2021 (UTC)
Being a guide does not mean it is complete. Users will never be done after reading just the installation guide, we expect they will always read other pages, especially those that are linked from the installation guide. So, what are you missing on the linked page precisely? — Lahwaacz (talk) 05:42, 15 July 2021 (UTC)
I strongly disagree that GRUB is be "the best choice". GRUB is probably the most complex of them all, with most of the other contenders out there being far simpler in design and operation. IMHO, its the one that strays further from Arch's KISS principle. GRUB is also pretty tricky to really set up with SecureBoot, since signing all the files is non-trivial. Pointing users to Arch_boot_process#Boot_loader is good enough. The purpose of the wiki is to assist in making an informed decision, not reflecting opinions. If you feel objective data is missing on that page, do point it out though. —This unsigned comment is by Hobarrera (talk) 17:56, 14 July 2021 (UTC). Please sign your posts with ~~~~!
Dear Hobarrera, the reason I called GRUB as the "best choice" was because it is the most popular boot loader across distros and there might be use cases (might I'm not saying there will be or are) where documentation of another project will be of use to a new user. Further it will be familiar. Further, it requires only a grub-mkconfig command to auto-load microcode updates and only change one line to detect other installed OS. Most other boot loaders require more steps and manual intervention which has the potential of negatively affecting an install or boot loader options due to something as trivial as a spelling mistake. I have since updated my proposed change by striking out "the best choice".--Kibybyte (talk) 03:18, 15 July 2021 (UTC)
You make the perfect example of why the installation guide avoids recommending specific tools. If it does, there will always be someone to loudly proclaim the recommendation is bad. -- Alad (talk) 18:40, 14 July 2021 (UTC)
I would like to point out that GRUB and systemd-boot satisfy most use cases. Most of the time using another boot loader boils down to preference over pragmatism. The prime reason of suggesting this addition is to provide a practically feasible solution for users.--Kibybyte (talk) 03:20, 15 July 2021 (UTC)