Talk:Installation 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.
• 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 [5], [6], [7], [8], [9] 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 [10] for past discussion on this topic.

-- The ArchWiki Administrators 22:17, 2 September 2016 (UTC)

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)

Install helpers are not recommended for new users

Add a warning box at the top of the install guide, which would more or less hold the following:

Warning while some installation helpers (such as archinstall) are available on the installation ISO, their use is only intended for experienced administrators who can handle opinionated installs. Installing Archlinux manually is the only way to acquire enough experience and understanding of your new system to be able to fix it.

Hopefully, this can reduce the number of "I fucked up my machine by using archinstall and have no idea what I'm doing" category of posts on the forums & subreddit. Moviuro (talk) 21:34, 15 July 2025 (UTC)

I'm not sure the warning will be read or followed by the crowd who opts to use archinstall blindly :/

-- Erus Iluvatar (talk) 03:21, 16 July 2025 (UTC)

No answer, closing. --Erus Iluvatar (talk) 17:07, 23 August 2025 (UTC)

Suggestion - call out that a network manager is needed

A common pain point for new Arch users is that on first boot, they haven't installed/enabled a network manager (e.g. NetworkManager, systemd-networkd) and/or a resolver (systemd-resolved). At the moment, the only reference to this is a single bullet point among seven, but this should really be more prominent - not having a network manager installed is the one single issue you can't resolve after booting into the new system for the first time without having to boot up the ISO again. Everything else, you can fix within the new system, but this you can't, because you can't download a network manager without a network manager already being installed.

The bullet point doesn't make this as clear as it could be, and given Arch is rolling-release the number of people who are going to set-and-forget an Arch box without connecting it to a network ever is minimal if not actually none - and those people are going to have a specific use case and will already know they don't want or need a network manager.

I'd propose that a specific call-out be made as a note underneath the "Install essential packages":

Warning You will not have Internet access after rebooting into your new Arch system if you have not installed, configured and enabled a network manager and any other necessary networking packages first.

This will hopefully reduce support requests and ease things for new users. --BloodNinjasPinwheel (talk) 05:26, 24 July 2025 (UTC)

If booting the ISO after installation is not an option, you can just use an Ethernet connection with systemd-networkd. This does not warrant adding a warning; I suggest thinking about how to rephrase the bullet point instead. -- nl6720 (talk) 13:00, 24 July 2025 (UTC)

Given how common Wi-Fi only devices are at this point, it's not a given that someone will be able to just hook up to an Ethernet connection (e.g. they may be installing on a laptop without any Ethernet port, or even may just not have an Ethernet cable). There's also not really a way of rewording the bullet point to signal this without effectively just putting in the text I wrote anyway.

I understand not wanting to not do too much hand-holding (e.g. if they boot into a terminal rather than a full graphical shell because they never installed or enabled one, that's on them) but it feels like not explicitly mentioning that no network manager = no WiFi is crossing the line between expecting the user to do their due diligence, and being obtuse. Yeah, they can reboot into the ISO and chroot again, but that's a rigmarole we could save them from having to do. --BloodNinjasPinwheel (talk) 07:45, 31 July 2025 (UTC)

I don't think a warning is adequate, we use big scary red text when there's something that is "reasonably difficult [...] or resulting in damage to the system", which rebooting on the ISO and re-chrooting is not.

Installation guide#Install essential packages starts with a Template:Note reminding readers that "No software or configuration (except for /etc/pacman.d/mirrorlist) gets carried over", and lists networking as one of the major needed point later.

I agree with @nl6720 here: finding a way to improve the existing section is better in the long run than fatiguing readers with warnings sprinkled all over. Erus Iluvatar (talk) 07:59, 31 July 2025 (UTC)

I tried something in #Draft.

The first idea was to put the command at the end, so that people don't end up skipping the list of what most would consider necessities.

The second one was to word it as an example command (same as Installation guide#Format the partitions) so that it hints it should not be copied verbatim.

The rest is various attempts at making existing sentences less ambiguous. I'm quite sure it can be improved, but it already feels clearer to me.

--Erus Iluvatar (talk) 17:50, 23 August 2025 (UTC)

Draft

No configuration (except for /etc/pacman.d/mirrorlist) gets carried over from the live environment to the installed system. The only mandatory package to install is base, which does not include all tools from the live installation, so installing more packages is frequently necessary.

In particular, consider installing:

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

For comparison, packages available in the live system can be found in pkglist.x86_64.txt.

To install more packages or package groups, append the names to the pacstrap(8) command below (space separated) or use pacman to install them while chrooted into the new system.

For example, a basic installation with the Linux kernel and firmware for common hardware:

# pacstrap -K /mnt base linux linux-firmware

Tip

• You can substitute linux with a kernel package of your choice, or you could omit it entirely when installing in a container.
• You could omit the installation of the firmware package when installing in a virtual machine or container.

Link to the "Linux firmware" article

Now that there's a Linux firmware article, I think we should link to it from Installation guide#Install essential packages. Unless someone has a better suggestion, I think a simple "specific firmware for other devices not included in linux-firmware..." will do for now. -- nl6720 (talk) 13:49, 4 August 2025 (UTC)

👍, sounds good to me :) Erus Iluvatar (talk) 14:03, 4 August 2025 (UTC)

I think better use redirect

specific firmware for other devices not included in linux-firmware,

And linkify it in the tip above too

You could omit the installation of the firmware package when installing in a virtual machine or container.

Hanabishi (talk) 15:16, 4 August 2025 (UTC)

Agreed on the first one, but I don't think there needs to be a link in the tip. -- nl6720 (talk) 11:20, 5 August 2025 (UTC)

If we only linkify firmware, the redirect already points to the new page :)

-- Erus Iluvatar (talk) 11:56, 5 August 2025 (UTC)

Done. --nl6720 (talk) 12:00, 5 August 2025 (UTC)

If it wasn't clear, in my edit I also proposed to remove the "e.g." part. As the linked article already covers details.

Hanabishi (talk) 12:06, 5 August 2025 (UTC)

Oh. I don't mind either way. Let's see what others think. --nl6720 (talk) 12:13, 5 August 2025 (UTC)

We add a short explanation or example for all the other items in the list, I think it's fine as is. Erus Iluvatar (talk) 12:24, 5 August 2025 (UTC)

Ok then. Hanabishi (talk) 12:43, 5 August 2025 (UTC)

Did you mean just "e.g." literally or the whole list in parentheses? Interestingly the firmware page does not mention the Broadcom wireless firmware packages. Technically it is not the Linux firmware project but since it is mentioned from the installation guide, adding a link to the page might make sense. — Lahwaacz (talk) 10:59, 6 August 2025 (UTC)

I mean the whole thing in the parentheses.

The article does mention it:

• linux-firmware-broadcom — Broadcom and Cypress network adapters,

Hanabishi (talk) 13:27, 6 August 2025 (UTC)

IMO dishing the whole parenthesis is too much, in particular the mention of sof-firmware seems important for newcomers.

-- Erus Iluvatar (talk) 07:50, 18 August 2025 (UTC)

Actually instead of the tip, better linkify it in the paragraph above

Use the pacstrap(8) script to install the base package, Linux kernel and firmware for common hardware:

It makes much more sense here IMO.

Hanabishi (talk) 13:32, 6 August 2025 (UTC)

I agree with this small change, it's the first instance of mentioning firmware in the section. Erus Iluvatar (talk) 07:50, 18 August 2025 (UTC)

I'd like to close this, there's a whole section rewrite above. --Erus Iluvatar (talk) 12:17, 29 August 2025 (UTC)