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

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)

Make a note that systemd tools are available via the systemd-nspawn container

Apparently, the systemd tools seems to work in a systemd-nspawn environment instead of arch-chroot. I tested this in a VM (KVM/QEMU, libvirt, virt-manager).

Below is an excerpt of the steps taken.

EDIT: As I just noticed, arch-chroot may get a systemd-run mode, see: https://gitlab.archlinux.org/archlinux/arch-install-scripts/-/merge_requests/70 --Spaks (talk) 12:08, 21 September 2025 (UTC)

So, hmm, I sympathize with the idea (Foxboron and I initially came up with this after all). But nowadays I've mostly given up pursuing this path and instead resorted to systemd-run for a saner chroot(8). The essential reason is that device management can never work in a full-blown container as Linux kernel simply doesn't do device namespacing. Note that binding in device nodes is NOT device management. The isolated environment must be able to maintain its own /dev/ and sysfs, plus running separate udev instance inside. Normal chroots are less isolated and get away with binding the whole /dev/ and /sys/ in.

Now, systemd-nspawn could well function if you don't need device management to begin with. But that's more often than not undesirable as soon as boot loader is involved. And in the case of system rescue you'd really want that to work.

Overall I think as long as devtmpfs/sysfs namespace support from kernel is still in limbo it's way more reasonable for users to either stick to status quo or utilize systemd-firstboot as a third way out. Arguably it helps newcomers to understand their system better if the underlying config files are presented rather than high-level systemd commands.

-- YHNdnzj (talk) 17:22, 27 September 2025 (UTC)

Thanks for the explanation. I'm uncertain which commands or bootloaders need device management (separate udev, dynamic /dev/) during the installation process where explicit bind mounts wouldn't be sufficient. Could you provide specific examples?

For system rescue scenarios where device requirements are unpredictable, I agree arch-chroot's comprehensive access makes more sense.

I understand the systemd-nspawn command with all the bind mounts is verbose. However, the systemd commands provide user input validation that improves the user experience, especially for newcomers. While users can validate configuration with timedatectl/localectl/hostnamectl after reboot, these are additional troubleshooting steps. I also think encouraging users to use the recommended tools (with notes explaining what they do) is pedagogically better than manual file editing.

The issues I've encountered with systemd-firstboot are that user input isn't validated and the interactive UI needs improvement. Spaks (talk) 10:08, 29 September 2025 (UTC)

"I also think encouraging users to use the recommended tools"

Recommended by who? Maybe that's the root of this. Personally, I see those tools as harmful to users understanding their system, abstracting things out like this isn't helpful. If a user isn't able to edit a text file, why in the world are they using Arch in the first place? Scimmia (talk) 04:00, 30 September 2025 (UTC)

You're right that 'recommended' was too strong. The Arch Wiki already documents these tools (e.g., timedatectl set-timezone, localectl set-locale). If they're considered harmful abstractions, why are they included?

I'd argue there's value in e.g. # localectl set-locale LANG=de_DE.UTF-8 (with a note explaining it writes to /etc/locale.conf) compared to manually appending text. The command validates input, prevents syntax errors, and users learn the tool they'll potentially use post-installation. Manual file editing is still necessary in plenty of other areas during & after installation.

The validation benefit seems worth offering as an option for users who want it. Spaks (talk) 11:27, 30 September 2025 (UTC)

I think using localectl is fine -- provided it works with arch-chroot -- because of the mentioned validation, and the fact it modifies /etc/locale.conf and /etc/vconsole.conf in one step. A man page reference to both pages still be added. I oppose use of other systemd-related commands in the installation guide, since they add a layer of abstraction with no tangible benefits.

Furthermore, if localectl only works with systemd-nspawn this discussion can be closed directly, see #Read this first before adding new suggestion. Expecting users to type a 200 character systemd-nspawn command for some minor benefits, instead of arch-chroot, is hardly reasonable.-- Alad (talk) 12:43, 30 September 2025 (UTC)

edit: looking at the above MR, localctl might work with arch-chroot for ISOs made after 1 october 2025. Considering this would invalidate the installation guide for any and all previous ISOs, switching from two file edits to localectl seems like a poor trade-off, with the relatively minor benefits that localectl offers. -- Alad (talk) 12:48, 30 September 2025 (UTC)

localectl has the advantage that it writes the XKB* options to /etc/vconsole.conf which could matter some day.

I don't think old ISOs should hold us back. Since the mirrors offer the last 3 ISOs and if we assume that that's what we support, then in the worst case we can just delay the change until December.

-- nl6720 (talk) 06:04, 1 October 2025 (UTC)

This would also not be the first time the installation guide gets invalidated for previous ISOs. The same thing happened when I changed it to use the -K option of pacstrap. -- nl6720 (talk) 06:09, 1 October 2025 (UTC)

Then (assuming it works) let's add localectl to the guide in December and leave it at that. -- Alad (talk) 10:53, 6 October 2025 (UTC)

Set root password using systemd-nspawn

See systemd-nspawn and arch-install-scripts issue #35.

Tip Press Ctrl-] three times within 1s to kill the container.

# systemd-nspawn -D /mnt passwd

Boot into the container

Comment

• An init program is automatically searched for and run as PID 1 in the container. The systemd commands are available in this container.
• The used parameters are for # efibootmgr --create, # hwclock --systohc & # timedatectl set.
• /dev/rtc is usually a symlink to the Real-Time Clock /dev/rtc0.
• An error message appears "[FAILED] Failed to start Remount Root and Kernel File Systems" which you can ignore.

# systemd-nspawn -b -D /mnt --bind /dev/nvme0n1 --bind /dev/nvme0n1p1 --bind /dev/nvme0n1p2 --bind /sys/firmware/efi --bind /dev/rtc --bind /dev/rtc0 --timezone=off --capability=all

Login as root:

• mnt login: root
• Password: root_password

Tested useful commands (selection)

• # timedatectl set-timezone Europe/Berlin;
• # hwclock --systohc;
• # localectl set-locale LANG=de_DE.UTF-8;
• # localectl set-locale LC_MESSAGES=en_US.UTF-8;
• # localectl set-x11-keymap de pc105 nodeadkeys;
• # hostnamectl hostname hostname;
• # btrfs filesystem mkswapfile --size 4g --uuid clear /swap/swapfile;
• # efibootmgr --create --disk /dev/nvme0n1 --part 1 --label "ArchLinux-zen" --loader EFI/Linux/archlinux-zen.efi --unicode;

Power off the systemd-nspawn container

$ systemctl poweroff Spaks (talk) 11:00, 21 September 2025 (UTC)

But why? How is it better to use localectl (for example) to edit a text file rather than just editing the text file? Scimmia (talk) 15:21, 21 September 2025 (UTC)

localectl checks whether the desired locale change can be applied. E.g.:

• # localectl set-locale LANG=de_DS.UTF-8 returns the error "Failed to issue method call: Cannot enable locale generation for invalid locale: de_DS.UTF-8"
• # localectl set-x11-keymap de pc105 nodeadkeyz returns the error "Failed to set keymap: Specified keymap cannot be compiled, refusing as invalid."

Furthermore, e.g.

• # localectl set-locale LANG=de_DE.UTF-8 also uncomments "#de_DE.UTF-8 UTF-8" in /etc/locale.gen, if it has not already been uncommented. # locale-gen should no longer be needed either.

Spaks (talk) 09:16, 22 September 2025 (UTC)

Add an example pacstrap command for a common desktop install

One of the main difficulties I had when first installing Arch Linux was not knowing what to install when running pacstrap. I think it would be great if there was a basic example command that people could use to install most of the software needed (listed in "In particular, consider installing:" of the 2.2 section of the page) for a common desktop installation.

I do very much understand that part of the philosophy of Arch Linux is that it is intended for people with a rather extensive knowledge about Linux, and therefore that the user is expected to have said amount of knowledge, and I'm definitely not against that, but I still think that including said list of packages could be very beneficial in many ways. For example, when I was first installing Arch Linux (in a VM) part of the reason why I was doing so was to obtain said knowledge necessary for actually using Arch Linux as my main desktop OS. But it was way too much work to search for each package, so I just ended up copying from a video guide (I sincerely apologize for this horrible sin against the Arch Wiki). Or maybe it would be good to have an example command just for quick reference, even for advanced users, especially just in case they forget something.

I also understand that the example command could possibly be opinionated (e.g. using vim instead of nano), but I think that's still better than the alternative. To clarify, I'm not talking about including software like a DE in the example command (listing numerous examples in a separate section could be considered though), there is simply too much room for debate for that, but rather things like sudo, a network manager, a text editor, and other such things. Furthermore, I think that it's possible to minimize opinionation enough (for example, most people would agree that networkmanager is the go-to for networking software, and nano is part of GNU, so it would likely be reasonable to use that as the text editor) so that it's not too much of a problem. Also, alternatives of some programs may also be listed.

If not a full command, perhaps at least some example packages for every category in the "In particular, consider installing:" section in 2.2 would be great.

Unrelated, but I thought opening an entire topic for this was unnecessary; I think it would be great to give some examples of bootloaders (e.g. grub or systemd-boot) and link them in 3.8, why not after all, it's a good quick link to the pages, even for a knowledged user who doesn't have bootloader installation commands by memory.

I apologize if this topic was discussed before and rejected, or that it is against any wiki conventions, or anything like that, this is my first contribution to the Arch Wiki. I use Arch BTW (talk) 12:22, 4 October 2025 (UTC)

There is no common desktop installation. Any recommendation is bound to make it opinionated. For example: I disagree that NetworkManager is "the go-to for networking software"; IMO it's bloat for a desktop PC that only uses an Ethernet connection. And there's no way I would ever agree to GRUB being recommended.

-- nl6720 (talk) 12:32, 4 October 2025 (UTC)

That makes sense, but perhaps only some example packages and their use cases (such as networkmanager not being needed for a PC that only uses ethernet) for all the categories listed in 2.2 could be added so that it's easier for people to make their own pacstrap for their specific use case? I use Arch BTW (talk) 08:57, 5 October 2025 (UTC)

Each bullet point either lists a package or links to a page that does. I do not think providing pacstrap command examples with random suggested packages will help anyone. -- nl6720 (talk) 11:59, 5 October 2025 (UTC)

Same sentiment from my side: each Arch user will have their prefered color for the bikeshed, making each installation nearly unique.

I get wanting a more detailed command, but our documentation style is designed to encourages the learning process: having to investigate options (emacs or vim, NetworkManager or systemd-networkd) builds the understanding needed to maintain an install long-term.

On the philosophical side of things, I'll quote Arch Linux#User centrality: "[Arch] is targeted at the proficient GNU/Linux user, or anyone with a do-it-yourself attitude who is willing to read the documentation, and solve their own problems". No one is expected to be proficient with Linux before joining, and following a video guide is far from a sin, so long as knowledge was gained in the process rather then copy-pasting.

No apologies needed, and a sincere thank you for aspiring to improve the Wiki :)

-- Erus Iluvatar (talk) 20:23, 4 October 2025 (UTC)

That does make sense, I understand. Still, perhaps some pointers to numerous options would still encourage investigating (since there would be many, and you'd have to find out which one you'd like) while not making it as daunting as it was for me? It was just kind of annoying to find everything to install. Like I said, if not a full command, perhaps at least some example packages for every category in the "In particular, consider installing:" section in 2.2 would be great. I use Arch BTW (talk) 08:49, 5 October 2025 (UTC)

Every one of those points has links in them that already do exactly that. Scimmia (talk) 05:49, 6 October 2025 (UTC)

One thing which may be hard to guess or interpret from only reading the wiki, is how popular some software is compared to other similar software. You can use https://pkgstats.archlinux.de/fun for this. Whether it can be useful to link to this in the pacstrap section I don't know. Why not. But it still somehow goes against trial and error from which you learn lots. Cvlc (talk) 10:43, 6 October 2025 (UTC)

It's also important to understand that the pacstrap command is only important to get right in the sense of not missing anything strictly required for your next reboot. You're free to install and uninstall anything you want after that. Or change to other software. As long as your system boots, there's nothing here which is definite. Maybe if this was stressed out a little better people wouldn't always seek guidance at this step ? Cvlc (talk) 10:49, 6 October 2025 (UTC)