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)

GitLab blobs in Lynx

Links to files (blobs) on gitlab.archlinux.org are not readable in Lynx (or any other console web browser); see https://gitlab.com/gitlab-org/gitlab/-/issues/26567.

Should the Installation guide link to raw files instead?

-- nl6720 (talk) 12:29, 4 August 2020 (UTC)

Maybe you could ask svenstaro to add it to https://gitlab.com/gitlab-org/gitlab/-/issues/232073... -- Lahwaacz (talk) 12:36, 4 August 2020 (UTC)

It has been filed under nice to have. -- nl6720 (talk) 17:19, 4 August 2020 (UTC)

Instead of using raw links we should perhaps consider if we need links to gitlab at all. The guide has:

• README.bootparams
• Ethernet
• WLAN
• WWAN
• reflector.conf
• packages.x86_64

Notice how all but one of these share the common path archiso/-/blob/master/configs/releng. Unless this level of specificity is really required, we could link to this path "for an overview of configuration files shipped with archiso" instead. -- Alad (talk) 09:35, 31 October 2021 (UTC)

I'd prefer simply removing some of the links.

• Ethernet, WLAN and WWAN don't provide much value here, so they can be moved to systemd-networkd#Configuration examples.
• reflector.conf is there just for citation purposes. The reflector article already explains how the software works.

-- nl6720 (talk) 09:30, 4 November 2021 (UTC)

Alright, I've removed those links. (Special:Diff/700696, Special:Diff/700693) -- Alad (talk) 11:39, 4 November 2021 (UTC)

Now that mirrors provide a symlink to the latest ISO version, it's possible to link to pkglist.x86_64.txt. I replaced packages.x86_64 with it. -- nl6720 (talk) 07:31, 21 May 2022 (UTC)

Is Lynx (un)readability such a big problem in this case? People using Lynx from the archiso can open up the relevant file in the live system itself... — Lahwaacz (talk) 18:05, 31 October 2021 (UTC)

Post-installation

I skipped steps in the guide so I faced a weird crash in gnome without any explanations. I suggest a note.

Note: Many of them assume that you have your timezone or locales set up. Make sure you have followed all the steps.

Escope (talk) 10:11, 2 April 2021 (UTC)

The reader is supposed to follow all the steps. If we apply that to other pages, the pages need a boatload of notes to make sure the reader did not skip any steps. A common functional system has properly configured locales and timezones.

Since this is GNOME-specific however I would at most add a section into GNOME/Troubleshooting or even General troubleshooting, but I still think this is out of scope to be honest. Many applications may not work properly when the timezones or locales are not correctly configured.

-- NetSysFire (talk) 15:30, 2 April 2021 (UTC)

The reader is not supposed to follow all the steps in case one doesn't worthy of attention. In my humble opinion, that's why it has huge advantage over the "Next-Next-Finish" approach. Unconfigured locales or timezones are obvious to many people, but my inexperience made me spend some time to sorting out. The other pages are highly deep and clear about the steps and why they are needed, my eyes enjoy such notes, pages are boatloaded already and I like it a lot =D. Thank you for your attention to this little change.

-- Escope (talk) 00:23, 3 April 2021 (UTC)

If you're inexperienced, what makes you think you can judge if a step is necessary or not? You thought you knew better than the people that wrote the guide and found out that you didn't. Not something that needs changed here IMO.

Scimmia (talk) 01:57, 3 April 2021 (UTC)

The ArchWiki should also be about the why-aspect. I am in favor of adding e.g a note about why they are needed and why some applications may crash or behave strangely without properly configured timezones/locales. If you know e.g a nice blog post about this topic, why not add something like this?

Note: Some applications may behave in strange ways or even crash when the timezones and/or locales are not properly configured. See this informative blog post to know why that is.

The note needs obviously some rewording, but something like this would fit in well in my opinion.

-- NetSysFire (talk) 02:02, 3 April 2021 (UTC)

Adding a brief "why" would be ok, but using Template:Note would be too much. I've also always wanted to emphasize the "and" in Installation guide#Localization, since it's easy to miss (even some of the translated installation guides do not mention en_US.UTF-8 UTF-8). --- nl6720 (talk) 08:48, 3 April 2021 (UTC)

People who want to know the "why" can already consult the relevant articles. That said, consistency is lacking: some sections explain in detail why a step should be performed (such as Installation_guide#Verify_signature), whereas Installation_guide#Configure_the_system is mostly a checklist of steps with brief instructions how. The solution isn't obvious: adding notes all over would likely more distract than clarify. -- Alad (talk) 19:41, 14 April 2021 (UTC)

I'm definitely apposed to adding notes, but I don't see why we couldn't add brief "why"s without them. -- nl6720 (talk) 06:55, 15 April 2021 (UTC)

Reference troubleshooting page, changing the order of some steps

Before I begin, I want to thank everyone responsible for creating or maintaining the installation guide. Ok, here are my suggestions. I don't mind if we can't do it, but I would like to understand the reason, if possible.

Can we please add a reference to the troubleshooting page, in case if things go wrong?

Can we move the bootloader step above some of the other steps in section #3? It doesn't seem like half the steps in section #3 would affect step 3.8.

Regarding the steps about setting the time and the root password, can we do those after the reboot section? If not, can we at least move the part about time synchronization to a place after the reboot, since it relies on commands that doesn't work with chroot?

Can we move the installation of some of the additional packages in step 2.2 after the reboot? ThoughtBubble (talk) 16:00, 9 July 2024 (UTC)

AFAIK, nearly the entire troubleshooting page refers to already-installed systems, it's not going to help much during installation. Maybe as part of the General Recommendations?

A number of them do affect the bootloader installation. What would be gained by moving it earlier?

The root password must be done now or you can't log in. The time really needs to be correct as well to prevent wierd time jumps, and this is all part of setting up the system, there's no reason not to do it now. As for syncronization, it's a simple note with links, it doens't rely on command that don't work in chroot.

The only thing I see in 2.2 that isn't strictly required for a basic, functional system you can build from would be the man pages, and that's somewhat important for setting things up. What do you think can be put off?

Scimmia (talk) 16:16, 9 July 2024 (UTC)

Those are fair points, and I guess maybe it was just me. I did have some unpleasant experiences and maybe what I suggested might not be the solution for it.

I'll describe the issues that I faced and then maybe we can think of a solution together to avoid it.

-- I had issues with running the pacstrap command on step 2.2. I don't remember the exact error mesage, but it didn't work due to issues with keyring/certificates. It was not an issue that was described in the installation guide, so I tried to find whatever information I could on a search engine. I've tried "pacman-key --init" but the message indicated that it was not able to generate the key. I've tried removing certain files based on the forum suggestions, but it said that those files were in use. After trying various commands, I ran pgp --generate-keys and it worked. But the entire ordeal took a lot of time when I don't even have a bootloader to use.

-- I spent a lot of time trying to find out what packages I needed and the differences between them. I felt like I should be informed about it before partitioning my disks or after I am able to reboot. It doesn't put me at ease knowing that my computer might crash if I make a mistake and I don't have a bootloader to use.

-- I didn't know how to setup time synchronization while I had chroot on. After exiting chroot, I still wasn't sure if I got time synchronization setup. After spending too much time, I gave up on that specific part of step 3.3 and simply moved to the next step.

-- The prompts for pacman and passwd were broken. The enter key did not work at all. Ctrl + C did not work for passwd. I got to I had to use Ctrl + D to break out of it. I shouldn't have to press random keys to figure out how to break out of passwd, especially when I don't have the bootloader

-- For some reason, the journal was empty. I know that was not the case before the partition step. I may have broke it when I tried to unmount my drive to fix the issues I got in step 2.2.

Please don't take any of this in a negative way. Maybe it is just me, but I really wish I could have avoided this experience. I was able to successfully install, but I feel like the process could have went more smoothly. I just don't want other people to experience the same issues I had ThoughtBubble (talk) 19:07, 10 July 2024 (UTC)

The keyring issue is probably the one where you try to use pacman or pacstrap before pacman-init.service has exited. There isn't really a good solution for this besides explicitly warning about it or adding some message about it to the live environment. Thankfully most people partition slowly enough that they don't trigger it.

If you don't know which software to choose, unfortunately you just have to take the time to figure out which one you prefer. We already have a lot more recommendations/suggestions in the installation guide than in the past. I think @Alad once suggested listing the boot loaders that the ISO uses as examples. Now that the ISO doesn't use that one anymore, this can probably be discussed.

While timedatectl set-ntp true won't work in a chroot, systemd-timesyncd#Enable and start has instruction on how to enable the service while chrooted.

I have no idea about your last two issues.

-- nl6720 (talk) 11:24, 13 July 2024 (UTC)

Adding a message would definitely help. But more importantly, if I encounter the issue, I need a solution to recover from it. How long would it take for pacman-init.service to exit? Anyways, do I need to go to the arch linux repo and submit an issue regarding creating a message for the pacman-init.service issue? Or is this already brought up?

I don't mind taking the time to figure out what software I need. It's just that I wanted the wiki to tell me what to research ahead of time, so that I don't spend so much time deciding after partitioning/formatting the drive and before installing the bootloader.

The systemctl command did not work while being chrooted, which was necessary to start/stop the services. The only thing I remember about the message I got was about systemctl ignoring options/flags that I never entered. ThoughtBubble (talk) 01:03, 14 July 2024 (UTC)

So the misunderstanding here is using systemd/systemctl. You don't start or stop services to set them up, you enable or disable them starting at boot. Scimmia (talk) 01:06, 14 July 2024 (UTC)

I tried doing that by exiting chroot,. Then I went back to chroot, and tried to verify whether the time synchronization was configured. The timedatectl command still did not work. I exited chroot again and verified if time synchronization was configured again. The output did not reflect my configuration file I had in chroot. ThoughtBubble (talk) 01:10, 14 July 2024 (UTC)

Absolutely every word of this reply is nonsense. It all comes down to basic systemctl usage, again, you enable, you do not start, exit chroot, timedatectl, etc. Scimmia (talk) 01:15, 14 July 2024 (UTC)

Well, you don't have to say it like that. I did not understand systemctl.

Isn't this the command to enable a service?

systemctl start example.service? ThoughtBubble (talk) 01:56, 14 July 2024 (UTC)

No, that is starting a service. Enable means systemctl enable example.service. — Lahwaacz (talk) 06:35, 14 July 2024 (UTC)

Ah, I understand now. Thank you so much. I wish I could have interpreted the wiki properly. ThoughtBubble (talk) 17:08, 14 July 2024 (UTC)

In addition to what nl6720 said, you seem to be under the impression that a bootloader would give you a safety net, hence the suggestion to install it earlier? It doesn't, though, booting into an incomplete or broken OS doesn't gain you anything. Your safety net is the ISO that you're on now.

Were you doing this over ssh? That could explain your issues with passwd and pacman, if terminfo isn't there for whatever TE you were using.

There would be no journal on the new system, it hasn't been booted yet, so that seems normal. You're expecting journal files to survive partitioning/formatting?

Scimmia (talk) 14:29, 13 July 2024 (UTC)

I used a flash drive. I realize the issue might be from the fact that I prepared the installation medium many months ago, before completing the rest of the steps. Ok, I accept that we cannot move the bootloader step earlier. Your reasons are valid.

I thought the journal files would be stored in ram before the OS is installed, to help users troubleshoot any issues during this process. But I'm glad to know that I didn't break anything with the journal during that process. I kind of wish I knew what wouldn't work ahead of time, so that I don't get too distressed.

Can you elaborate what you mean by the ISO being my safety net? I used a Windows bootloader to load Arch Linux from my flash drive, then I created a new partition table and formatted it. Wouldn't this effectively delete the Windows bootloader and therefore prevent me from booting from my flash drive? ThoughtBubble (talk) 00:11, 14 July 2024 (UTC)

How, and why, would you make the Windows bootloader do that? There's a bootloader on the ISO/flash drive, you just tell your system firmware to boot that, no involvement from the Windows bootloader at all. Scimmia (talk) 00:56, 14 July 2024 (UTC)

Interesting. I did not know that was an option. How do I tell the system firmware to boot from the flash drive though? Let's assume the computer is powered off, the hard drive is erased, and I have the flash drive attached. ThoughtBubble (talk) 01:07, 14 July 2024 (UTC)

Usually by hitting F1, F2, ESC, etc. It'll often say right on the screen how to enter the boot menu. Scimmia (talk) 01:08, 14 July 2024 (UTC)

Ah. I think I confused the Windows bootloader with the system firmware. That explains everything. I feel silly now ThoughtBubble (talk) 01:14, 14 July 2024 (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)

After section 1.4 (Boot the live media), there should be a mention of archinstall

Something like:

Note:

If you prefer the simplicity of an installation script over the DIY-nature of manual installation, consider using the archinstall installation script.

QwertyChouskie (talk) 22:36, 20 February 2025 (UTC)

archinstall is mentioned in #Read this first before adding new suggestions — andreymal (talk) 22:40, 20 February 2025 (UTC)

The Category:Installation process is linked right in the first paragraph. We can use the category description to differentiate the included articles a little more. Also, we could add a Install Arch Linux with menu-guided archinstall crosslink to archinstall. Doing so would group it among the articles with analogous titles. How about that? --Indigo (talk) 21:50, 16 March 2025 (UTC)

Add mention of cfdisk

Would be nice to have cfdisk mentioned alongside fdisk like this:

Use a partitioning tool like fdisk (cfdisk for TUI) to modify partition tables. For example:

I know it's mentioned in the partitioning tools page and fdisk page, but it would be nice to have it mentioned in the installation guide itself. It shouldn't be a big deal. Damglador (talk) 16:44, 5 April 2025 (UTC)