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
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 trueenablessystemd-timesyncdservice if available. If not, it allowsntpdorchronydto handle the synchronization. This info was hard to come by. Managor (talk) 23:12, 16 January 2025 (UTC)
- It seems
- 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
Areais a continent or ocean, andLocationis 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)
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)
- That changes a lot, yeah, can't believe I just realized that. Have a good day, and sorry for my idiocity. I use Arch BTW (talk) 16:09, 8 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)
- 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)
- 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)
- I've re-read this discussion and I think this might be a good candidate for a third bullet point in the tip at the end, how about:
- This initial selection of packages in pacstrap only needs to ensure a bootable system; everything else can be changed post-installation.
- --Erus Iluvatar (talk) 13:30, 10 October 2025 (UTC)
- how about
- > This initial package selection in pacstrap only needs to include what’s required for the system to boot; all other software can be added or replaced later. Cvlc (talk) 20:55, 10 October 2025 (UTC)
- I really like the "post-installation" wording, as that's what we titled the last section of the guide. That would leave us with something like:
- This initial package selection in pacstrap only needs to include what is required for the system to boot; all other software can be added or replaced post-installation.
- -- Erus Iluvatar (talk) 07:20, 11 October 2025 (UTC)
- I'd replace "added" with "installed". Otherwise, 👍 -- nl6720 (talk) 07:26, 11 October 2025 (UTC)
- Sounds great Cvlc (talk) 21:46, 11 October 2025 (UTC)
- Sounds like we have a consensus, I've updated the guide: closing :) --Erus Iluvatar (talk) 09:07, 12 October 2025 (UTC)
- I really like the "post-installation" wording, as that's what we titled the last section of the guide. That would leave us with something like:
- I've re-read this discussion and I think this might be a good candidate for a third bullet point in the tip at the end, how about:
- 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)
- Just realized that, nevermind the thread, seems the problem was me lol. I use Arch BTW (talk) 16:10, 8 October 2025 (UTC)
- Don't sweat it, closing :) --Erus Iluvatar (talk) 20:28, 8 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)
- Every one of those points has links in them that already do exactly that. Scimmia (talk) 05:49, 6 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)
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)
- 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)
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)
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 |
Replace fdisk!
cfdisk is more better and friendly to new user! It has interface unlike fdisk. BSOD (talk) 17:41, 15 October 2025 (UTC)
- This has already been discussed recently and no new argument is being presented. Closing. --Erus Iluvatar (talk) 07:38, 16 October 2025 (UTC)