Talk:Installation guide

Make explicit systemd tools will not work in the chroot

A lot of the installation guide before and after chrooting is composed of "Follow this link and follow instructions on the linked page", e.g. preparing the installation medium, network configuration, initramfs, etc.

Things have settled on not getting the systemd tools in a usable state and instead relying on the manual process (see the note at the top of this page).

However, the fact systemd tools are never expected to work in the chroot is not explicitly communicated on this page. This is apparently confusing to some* users when they encounter the sections on Time and Localization, that link to pages that open with instructions like "To check the current zone defined for the system: $ timedatectl status". This of course fails (because they're in the chroot), but unless they read the "Usage" section of the chroot page they do not know this is expected to fail. This is probably obvious to any experienced user, but the installation guide is targeting new users as well.

* n=1 on IRC, and I understand their thought process.

I would suggest simply replicating a version of the note about *ctl tools not working in the chroot on the main Installation guide page, in the chroot section where it becomes relevant. E.g.

Change root into the new system:

# arch-chroot /mnt

Note Some systemd tools such as hostnamectl, localectl and timedatectl, referenced in linked wiki pages below, cannot be used inside the chroot.

MacGyver (talk) 19:17, 8 January 2025 (UTC)

A link to a guide to do what timedatectl does manually would be great

Managor (talk) 13:47, 10 January 2025 (UTC)

It seems timedatectl set-ntp true enables systemd-timesyncd service if available. If not, it allows ntpd or chronyd to handle the synchronization. This info was hard to come by. Managor (talk) 23:12, 16 January 2025 (UTC)

While I get your notion, the topic is discussed in detail #Reference troubleshooting_page, changing the order of some steps. To sum it, your suggestion fails short of elaborating that an enable does work, while a start does not. Doing so complicates it.

I think what might be useful instead is add a similar note to the end of the crosslinked Help:Reading#Control of systemd units. This way we keep this guide to its structure, but help new readers/users. How about that? --Indigo (talk) 12:40, 12 January 2025 (UTC)

Replace Region/City with Area/Location

I replaced Zone/SubZone with Area/Location in System time#Time zone so that it uses the terms from https://data.iana.org/time-zones/theory.html#naming.

I think Installation guide#Time should be changed to match.

I'd also like add an explanation for the pseudo-variables (copied from the aforementioned website):

Where Area is a continent or ocean, and Location is a specific location within the area. North and South America share the same area—America.[12]

But I'm not sure if it better belongs in System time#Time zone or Installation guide#Time. Thoughts?

-- nl6720 (talk) 08:09, 13 September 2025 (UTC)

I agree with that change. IMO the names are self-explanatory and the explanation is a better fit for the dedicated page instead of this guide. Erus Iluvatar (talk) 08:13, 13 September 2025 (UTC)

Update the system clock should explain the reasoning

I've stumbled upon a reddit threat commenting each section from the point of view of someone technically minded but new to Linux. I think they have a good point on Installation guide#Update the system clock: we don't explain _why_ this is needed. I think the tweaked sentence below is better than what we have:

To prevent package signature verification failures and SSL certificate errors, use timedatectl(1) to ensure the system clock is synchronized

-- Erus Iluvatar (talk) 09:36, 12 October 2025 (UTC)

Those are the two most common issues encountered with a non-synchronized clock, but not the only ones (build systems, audio/video streaming, etc.)

IMO the installation guide outlines a basic set of requirements for a supported Arch Linux installation - not every step needs to be "sold" to a potential user. If anything we should clarify the latter. -- Alad (talk) 14:04, 16 October 2025 (UTC)

I don't think audio/video streaming is relevant during the installation, and I hope building packages from the live ISO is not frequent enough that it needs mentioning.

I did not intend for the addition to be exhaustive: while we don't need to "sell" anything, giving a short reason of why a step is included is IMO a good thing, which we already did recently for other sections.

-- Erus Iluvatar (talk) 15:51, 16 October 2025 (UTC)

The boot loader section

Ugh. We're at the umpteenth discussion on this section, so I'll just suggest a little more verbose alternative that I feel might be better understood by beginners.

Last−but not least−picking a Linux-capable boot loader and installing it. See the explanations (and the comparison table) in Arch boot process#Boot loader to make your choice, then follow the installation instructions on its dedicated page.

-- Erus Iluvatar (talk) 10:00, 12 October 2025 (UTC)

Even better would be to just provide commands for installing some popular bootloader, like GRUB or systemd-boot, it will not only stop confusing first-time users with a big table of bootloaders, but will also make the bootloader section stand out, as for example me and some other people that I know missed this section entirely while installing Arch Linux

The same can be done with step 2.2, also provide command to install popular tools like nano and network-manager Sanic (talk) 12:24, 16 October 2025 (UTC)

ah, just read the previous thread, well I guess better to just stop recommending Arch to newcomers altogether. Sanic (talk) 12:44, 16 October 2025 (UTC)

Not sure why you were recommending it to them in the first place.

Anyway, I agree the wording could be improved - right now it's a cut-off sentence. Years ago I suggested to directly link GRUB and systemd-boot, with these being the most common choices by an order of magnitude (pkgstats and use in archiso). More than that is pointless though - there is no universal command and nobody wants to maintain two sets of instructions for basically the same thing. -- Alad (talk) 13:55, 16 October 2025 (UTC)

I'm not happy with rubber-stamping popularity into the guide, especially for a bloat-loader like GRUB.

-- Erus Iluvatar (talk) 16:00, 16 October 2025 (UTC)

That was more or less the exact reason people didn't like it. :) -- Alad (talk) 16:38, 16 October 2025 (UTC)

Much of that is covered by General recommendations, specifically linked to in Installation guide#Post-installation. NetSysFire (talk) 12:59, 16 October 2025 (UTC)

A tweak on Install essential packages

After a night of sleep, I feel we can improve Installation guide#Install essential packages slightly by putting more emphasis on "In particular, consider installing". I don't have a proper sentence to suggest, but I hope the general idea of "unless you know why you don't need it, pick one of each in the following" would alleviate the frequent issues encountered by newcomers? -- Erus Iluvatar (talk) 09:07, 13 October 2025 (UTC)

I think there is a bias here - the so-called frequent issues are expressed by a vocal minority. People not having issues - the majority - will not write about it on social media. -- Alad (talk) 13:57, 16 October 2025 (UTC)

Reddit thread excluded, this is a topic that has been frequently raised in this very talk page, the most recent one being #Add an example pacstrap command for a common desktop install.

-- Erus Iluvatar (talk) 16:02, 16 October 2025 (UTC)

How about using a table instead of a bullet list? 2 columns (Description + example packages) should at least help with readability. -- Alad (talk) 16:39, 16 October 2025 (UTC)

I've drafted something, I'm not sure it's more readable but I think I found a sentence that looks kinda like what I was thinking about. --Erus Iluvatar (talk) 18:18, 16 October 2025 (UTC)

A 👎 for a table from me. We may as well create a flowchart at that point...

The only difference is the explicit listing of mdadm and lvm2 which could be added to the current list items too.

-- nl6720 (talk) 06:15, 17 October 2025 (UTC)

I've tried an other take at more "air" around the content with a second draft using a definition list, it still looks meh to my eyes. --Erus Iluvatar (talk) 09:24, 17 October 2025 (UTC)

Yeah, the definition list is hard to read. Flowchart it is then! 😆 -- nl6720 (talk) 11:27, 17 October 2025 (UTC)

If we can't come up with something better than the existing list, can we at least see if "Unless they are not needed, install one of each" feels like an improvement for everyone?

-- Erus Iluvatar (talk) 12:07, 17 October 2025 (UTC)

I can't say I like that sentence. I find it more likely that people would know what they need instead of knowing what they don't need. -- nl6720 (talk) 05:54, 21 October 2025 (UTC)

Yeah, the double negative irks me too, but I don't see an other way to put an emphasis on the importance of picking items into the list, instead of merely "considering". "In particular, review and install" maybe? Erus Iluvatar (talk) 06:01, 21 October 2025 (UTC)

"In particular, review and install the following software if needed" perhaps? -- nl6720 (talk) 06:05, 21 October 2025 (UTC)

A bit longer, but I think it avoids the caveat of the current sentence being misread? If no one comes with something better I'd be okay to roll with it. Erus Iluvatar (talk) 06:10, 21 October 2025 (UTC)

Actually I worded it terribly. Here's a slightly better one (I hope):

"In particular, review the following software and install everything that you need"

-- nl6720 (talk) 06:14, 21 October 2025 (UTC)

I prefer this version even if it's still more verbose, the intent is clear with researching through options first then installing once clear on one's needs. Erus Iluvatar (talk) 06:17, 21 October 2025 (UTC)

As someone who started using Arch Linux as their first Linux distribution about a year ago, I think providing example packages would distract from understanding why you need them.

For instance, I don't use RAID or LVM, and providing examples might encourage someone to simply install one of them without questioning why.

The same applies to the documentation. You don't need any of those; they're IMHO just QOL features if you want to use them.

I also never posted about Linux online ever... I just bug people IRL to try Linux, because I like it so much ':D Tigockel (talk) 11:08, 17 October 2025 (UTC)

Draft

Unless they are not needed, install one of each:

Description	Example packages
CPU microcode updates for hardware bug and security fixes	amd-ucode or intel-ucode
userspace utilities for file systems that will be used on the system for the purposes of e.g. file system creation and fsck	btrfs-progs or e2fsprogs
Utilities for accessing and managing RAID or LVM	mdadm or lvm2
Specific firmware for other devices not included in linux-firmware	sof-firmware for onboard audio, linux-firmware-marvell for Marvell wireless and any of the multiple firmware packages for Broadcom wireless
Software necessary for networking	a network manager or a standalone DHCP client, authentication software for Wi-Fi, ModemManager for mobile broadband connections
A console text editor to allow editing configuration files from the console	nano
Packages for accessing documentation in man and info pages	man-db, man-pages and texinfo

Draft 2

Unless they are not needed, install one of each:

Microcode

Most CPU receive updates for hardware bug and security fixes with the amd-ucode or intel-ucode packages.

Userspace utilities for file systems

Once using the installed system, fsck or new file system creation needs the relevant packages, for example btrfs-progs or e2fsprogs.

RAID or LVM

For the system installed using them, utilities for their access and management are needed, that is mdadm or lvm2.

Specific firmware

For other devices not included in linux-firmware, like sof-firmware for onboard audio, linux-firmware-marvell for Marvell wireless and any of the multiple firmware packages for Broadcom wireless.

Software necessary for networking

A network manager or a standalone DHCP client, authentication software for Wi-Fi, ModemManager for mobile broadband connections.

A console text editor

To allow editing configuration files from the console, for example nano.

Packages for accessing documentation

For man and info pages, the man-db, man-pages and texinfo packages.