Jump to content

Talk:Installation guide

From ArchWiki
Latest comment: 29 March by Erus Iluvatar in topic Add a Note Regarding Partition Labels to § 1.10
Notice for editors -- The ArchWiki Administrators 22:17, 2 September 2016 (UTC)

Update arch-chroot step

The last release of arch-install-scripts has introduced a cleaner way to handle mounts in the arch-chroot step. Since the installation medium provides the right version of systemd, I think there's no downsides to switch to using the -S flag in the guide?

-- Erus Iluvatar (talk) 11:51, 1 November 2025 (UTC)Reply

👍 -- nl6720 (talk) 05:47, 2 November 2025 (UTC)Reply
I'll wait until the next release to be extra cautious, there's an edge case that we should not hit as the guide does not show it being used with relative paths, but I'd rather be safe. Erus Iluvatar (talk) 18:12, 15 November 2025 (UTC)Reply
May we close this topic? At least, I can't find anything related… — Andrei Korshikov (talk) 19:29, 13 February 2026 (UTC)Reply
I'd like to keep this open until there is a new release cut for arch-install-scripts.
--Erus Iluvatar (talk) 09:45, 14 February 2026 (UTC)Reply

Add a Note Regarding Partition Labels to § 1.10

As § 3.1 discusses generating the file systems table (fstab) by UUIDs or labels, it makes sense to inform users about file system labels in § 1.10 when they are formatting their partitions.

Although § 1.10 links to File_systems#Create_a_file_system, which contains a Tip: "Use the -L flag of mkfs.ext4 to specify a file system label," abstracting this information via reference is incongruent with § 3.1, wherein non-abstracted instructions to generate the fstab using genfstab(1) by UUIDs or labels via the -U or -L flags are provided.

My concern with this addition is that it requires the user to bear the burden of understanding the fstab, as well as genfstab(1), before their relevance in § 3.1. Although this information is helpful for the user to know in advance for preparatory purposes, I'm unsure how to format a note that provides this information without requiring the user to reference § 3.1.

An alternative suggestion may be adding a note to § 3.1 regarding the -L flag for genfstab(1), linking users to Persistent_block_device_naming#by-label for information regarding adding or changing file system labels. This comes with the caveat that there is a minuscule, but non-zero chance that a user selects a file system in § 1.10 for which a label cannot added or modified after its creation; this concern is based on the wording used in Persistent_block_device_naming#by-label: "For some file systems it is also possible to change the labels," which implies there are file systems for which this is not possible. Chloe (talk) 05:40, 7 March 2026 (UTC)Reply

I'm tempted to adjust Installation guide#Fstab instead of giving even more reading in Installation guide#Partition the disks as it's already one of the longest sections in the guide.
The intent of each step is to have examples to be adjusted by the reader with a short explanation of why the step is needed in the installation process. How about:
To get needed file systems (like the one used for the boot directory /boot) mounted on startup, generate an fstab file. To keep consistency across hardware changes, use persistent block device naming, for example by referencing file systems by their UUID with -U:
Edit: I'm not too worried about the order in which readers will learn about labels, as most common file systems support adding one after file system creation.
-- Erus Iluvatar (talk) 09:21, 7 March 2026 (UTC)Reply
After thinking about it again, I agree with the idea of modifying § 3.1 instead. One would hope that if someone's purposefully selecting an esoteric file system that does not support adding or modifying a label after its creation, they would know what they're getting into before it becomes an issue. Here's my modified version of the proposed change:
To get needed file systems (like the one used for the boot directory /boot) mounted on startup, generate an fstab file. To keep consistency across hardware changes, use persistent block device naming; for example, reference file systems by their UUIDs or labels with -U or -L, respectively:
I aimed to maintain the wording of the guide as-is, restored the link to UUID (and added one for labels), and mended a pedantic English grammatical issue between two independent clauses with a semicolon. -- Chloe (talk) 15:24, 7 March 2026 (UTC)Reply
The UUID redirect and the link to the label subsection feel redundant with the link in the start of the sentence to the same page.
I had voluntarily removed the reference to labels, otherwise the end of the sentence seems awkward with the "for example" part as we're mentioning two options but only showing a single one.
Thanks for fixing the comma splice :)
-- Erus Iluvatar (talk) 08:35, 10 March 2026 (UTC)Reply
I don't think we need to justify the usage of persistent block device naming.
To get needed file systems (like the one used for the boot directory /boot) mounted on startup, generate an fstab file with persistent block device naming. For example, reference file systems by their UUIDs or labels with -U or -L, respectively:
-- nl6720 (talk) 10:41, 10 March 2026 (UTC)Reply
Sounds like a good middle ground, 👍️ Erus Iluvatar (talk) 10:45, 10 March 2026 (UTC)Reply
New phrasing looks good. Since the example provided by the guide uses -U, and the text links to persistent block device naming, the text can be further modified to:
To get needed file systems (like the one used for the boot directory /boot) mounted on startup, generate an fstab file with persistent block device naming using genfstab(8). For example, reference file systems by their UUIDs with -U:
This provides a manual page reference to genfstab(8), as well. Chloe (talk) 12:53, 10 March 2026 (UTC)Reply
It's missing the -L option for LABELs, though -- nl6720 (talk) 14:04, 17 March 2026 (UTC)Reply
As we don't use it in the example and it's just above UUIDs in the dedicated page, I think it's probably a good simplification.
If no one is against it, I'll go with that version in a week :)
-- Erus Iluvatar (talk) 16:44, 19 March 2026 (UTC)Reply
No one yelled, page updated, closing :) --Erus Iluvatar (talk) 07:36, 29 March 2026 (UTC)Reply

Add a note at § 1.10 to mention Dm-crypt/Encrypting_an_entire_system#Preparing_non-boot_partitions.

Dm-crypt/Encrypting an entire system#Preparing non-boot partitions already mentions our page's 1.10, but if we could mention at our 1.10 that "if you would like to encrypt the root partition at this stage, see this page" etc etc. » Like an autumn leaf, her fading golden grace as the tree withered. « — NinetailedTori (talk) 18:06, 28 March 2026 (UTC)Reply