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)

Mention zram

In Installation guide#Partition the disks, The note mentions:

• Swap space can be set on a swap file for file systems supporting it.

Should it be updated to add reference to zram as well ? Something like :

• As an alternative to a swap partition, Swap space can be set on a swap file for file systems supporting it, or in a compressed block device in ram.

-- Cvlc (talk) 23:04, 30 January 2023 (UTC)

I do not think zram is essential enough (compared to the defaults) for it to be mentioned in the Installation guide, or even in General recommendations. The snake oil article references it and IMHO that's enough. -- nl6720 (talk) 10:22, 31 January 2023 (UTC)

(Re-opened, hope that's ok)

Certainly not essential, but it's one possible reason not to plan for a swap partition during the partitioning step. Distros like Fedora provide that by default, it's a reasonable way to set up a system, I don't see any harm in mentioning it. People often read the installation guide many times before actually installing Arch, it's a perfect way to learn about possibilities, whereas Improving performance is probably most often read after installation on a running system. Swap files are already mentioned, so it doesn't require any extra note or clutter, just modifying a sentence, which is nice.

-- Cvlc (talk) 16:16, 31 January 2023 (UTC)

If it were to be added to the installation guide, I want it to contain the phrase "swap on zram" instead of obfuscating it with "compressed block device in ram" or similar.

I don't think we can link to Zram#Usage as swap unless it has a suggested size for the swap space.

-- nl6720 (talk) 10:13, 22 June 2023 (UTC)

I was about to say, we can just link to the suggested size from the swap article but... there is no suggested size there either :)

-- Cvlc (talk) 15:09, 22 June 2023 (UTC)

There's Partitioning#Swap, which IMO should be linked from Swap#Swap file, but it doesn't actually say anything specific. Instead the recommended size is only listed in the Partitioning#Example layouts table.

Still, does the general swap size recommendation apply to swap on zram? Is wasting 512 MiB of RAM enough?

-- nl6720 (talk) 16:24, 22 June 2023 (UTC)

No you're right, the general swap size recommendation does not really apply to zram. A percentage of available RAM makes more sense. zram-generator has a default of zram-size = min(ram / 2, 4096), Fedora uses 100% of RAM. I've been using 100% without problems for quite a while. I would suggest 100% for regular desktop/laptop use, and 50% if having to deal with specific non compressible workloads (not sure what this would be though, I've had no problem with encoding of large video files, or such).

-- Cvlc (talk) 16:50, 22 June 2023 (UTC)

Fedora:Changes/Scale ZRAM to full memory size says that it's 8 GiB max, so not "100%". And we shouldn't blindly follow Fedora either, their change reasoning is not always properly documented. -- nl6720 (talk) 15:05, 24 June 2023 (UTC)

Given that zswap is enabled by default, and the example partition layout shows the use of swap, what benefit is there to mention zram?

If it's simply to allows users to get rid of swap (be it a file or a partition), please take the time to look at https://chrisdown.name/2018/01/02/in-defence-of-swap.html.

From what I understand, while zram is more configurable than zswap and does not need a backing swap device, it needs additional configuration (i.e. disabling zswap) for little benefits over the existing suggested layout.

-- Erus Iluvatar (talk) 09:21, 29 June 2024 (UTC)

I don't think the "In defence of swap" article applies here. You still have a swap space when using swap on zram, it's simply not disk-based. You can achieve the same thing with zswap by disabling writeback, but creating 8+ drop-in files is a pain. -- nl6720 (talk) 09:36, 29 June 2024 (UTC)

That make total sense.

While I maintain this feels more complicated to set up for new users than the existing partitioning layouts, I've updated Zram#Usage as swap with a suggested size of "half of the total system memory" which is probably a conservative and universal enough starting point, we should be OK to link there now? How about:

Swap space can alternatively be set on a swap file (for file systems supporting it) or through swap on zram.

-- Erus Iluvatar (talk) 12:53, 29 June 2024 (UTC)

Any size is good enough as long as it placates the kernel's "need" for swap, but I can't say half of the total system memory doesn't feel excessive. Perhaps there should be an upper limit. E.g. 16 GiB which would be twice that of Fedora's limit.

IMO the addition would look better as a separate sentence highlighting its advantage:

Alternatively, disk based swap can be avoided entirely by setting up swap on zram after installing the system.

-- nl6720 (talk) 13:10, 29 June 2024 (UTC)

Unless I misunderstood, zram will not reserve the memory in advance so I did not see the need to set an upper bound. Is there something I'm not thinking about that would need us to explicitly limit the size?

👍️ for the separate sentence :)

-- Erus Iluvatar (talk) 13:31, 29 June 2024 (UTC)

"2.2 Install essential packages" needs more specific suggestions for absolute beginners.

I personally had a lot of problems with the installation and had to resort to "walk-throughs" that just caused hours of headaches. I will point out some of the problems I had with this section.

"userspace utilities for the management of file systems that will be used on the system" is wordy and vague. It is unhelpful to someone completely new. The hyperlink points to types of file systems which is not intuitive to the statements suggestion. At the very least, "userspace utilities" should be hyperlinked to a section of programs the statement is suggesting. Several months on, I still am unsure of what they are eluding to.

"specific firmware for other devices not included in linux-firmware (e.g. sof-firmware for sound cards)" An absolute beginner does not know what specific firmware are not included in linux-firmware. The suggestion of sound cards is extremely outdated, and frankly makes it seem like linux-firmware is going to leave you needing a lot of drivers if it cannot even operate your sound card out of the box. This confusion led me down a rabbit hole of installing(or trying to find) CPU microcode updates, nvidia drivers, wired or wireless drivers, motherboard drivers, and so on.

"software necessary for networking (e.g. a network manager or a standalone DHCP client, authentication software for Wi-Fi, ModemManager for mobile broadband connections)" My first problem was I was unaware of the need to systemctl enable the networking software, which led me to installing multiple DHCP clients and causing issues further down the road. I am now aware that if I had read more into the software. I believe a simple reminder to systemctl enable the networking software could save a lot of people problems.

"a text editor," The hyperlink just throws a list of 70 or so text editors at you. This is quite needlessly daunting to someone new. Even something as basic as "e.g. vim" would have spared me from being so overwhelmed this far into my troubles with this section.

"packages for accessing documentation in man and info pages: man-db, man-pages and texinfo." This should take priority above all by being placed first in this list.

I would recommend a section "2.2.1 Example(s) of essential packages" be created that shows at least one example of a typical users desktop computer, and what they would install on this step.

—This unsigned comment is by Todd the king (talk) 21:12, 12 June 2023 (UTC). Please sign your posts with ~~~~!

I would refer you to https://wiki.archlinux.org/title/Arch_Linux#User_centrality. Arch's target audience isn't absolute beginners, it's experienced Linux users that know what they want and how they want their system set up. Scimmia (talk) 22:37, 12 June 2023 (UTC)

It 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. —This unsigned comment is by Todd the king (talk) 21:12, 12 June 2023 (UTC). Please sign your posts with ~~~~!

And your argument is that you don't want to read the documentation. Arch dosen't make these decisions for you, you need to either know what you want or be willing to figure out what you want. Scimmia (talk) 22:49, 12 June 2023 (UTC)

I did read the documentation, and I did figure out what I wanted. It took much longer than it should have because the instructions were hazy on this section. Why give any examples of software or suggestions of configuration to use in the article at all if this is the mindset of the guide? Where is the line and why? Todd the king (talk) 23:09, 12 June 2023 (UTC)

First of all, welcome :)

Now, I'm sorry but:

"userspace utilities for the management of file systems that will be used on the system"

is wordy and vague. It is unhelpful to someone completely new. The hyperlink points to types of file systems which is not intuitive to the statements suggestion. At the very least, "userspace utilities" should be hyperlinked to a section of programs the statement is suggesting. Several months on, I still am unsure of what they are eluding to.

The very first section of the linked page (i.e. File systems#Types of file systems has a table which helpfully has a "Userspace utilities" column, I fail to see how skipping the page introduction would make this more obvious.

"specific firmware for other devices not included in linux-firmware (e.g. sof-firmware for sound cards)"

An absolute beginner does not know what specific firmware are not included in linux-firmware. The suggestion of sound cards is extremely outdated, and frankly makes it seem like linux-firmware is going to leave you needing a lot of drivers if it cannot even operate your sound card out of the box. This confusion led me down a rabbit hole of installing(or trying to find) CPU microcode updates, nvidia drivers, wired or wireless drivers, motherboard drivers, and so on.

An absolute beginner's encouraged to seek help if he's unsure of what advice is applicable to its hardware. As shown in the tables in Laptop/Lenovo, various recent laptops do require ALSA firmware, while some models require specific drivers (and its respective firmware) for wireless networking: Broadcom wireless, or even some USB3 chipsets on the motherboard with upd72020x-fw^AUR for example.

"software necessary for networking (e.g. a network manager or a standalone DHCP client, authentication software for Wi-Fi, ModemManager for mobile broadband connections)" My first problem was I was unaware of the need to systemctl enable the networking software, which led me to installing multiple DHCP clients and causing issues further down the road. I am now aware that if I had read more into the software. I believe a simple reminder to systemctl enable the networking software could save a lot of people problems.

Someone manually configuring a static ip connection would not need that step, while every dedicated network manager page explains the need for enabling their respective systemd unit.

"a text editor,"

The hyperlink just throws a list of 70 or so text editors at you. This is quite needlessly daunting to someone new. Even something as basic as "e.g. vim" would have spared me from being so overwhelmed this far into my troubles with this section.

Not picking a default text editor is a feature and not a bug: every choice made of a "sane default" would create endless bikeshedding (see Wikipedia:Editor war), although a popular beginner friendly one has been used as an example in Help:Reading#Append, add, create, edit.

"packages for accessing documentation in man and info pages: man-db, man-pages and texinfo."

This should take priority above all by being placed first in this list.

Man pages can be accessed with man.archlinux.org instead of wasting bandwidth and disk space by installing and updating a local version.

I would recommend a section "2.2.1 Example(s) of essential packages" be created that shows at least one example of a typical users desktop computer, and what they would install on this step.

This guide is not specific to desktop users, a dedicated section is out of scope.

As a general answer, our aim is to provide readers with the information they need to make an educated decision at every step, not rubber stamping the popularity of various software solutions.

While a little overwhelming at first, this approach has proven itself to be the best working on the long term: Help:Reading#Organization.

--Erus Iluvatar (talk) 00:07, 13 June 2023 (UTC)

I replaced "sound cards" with "onboard audio" which will hopefully get the message across better. -- nl6720 (talk) 05:56, 13 June 2023 (UTC)

After a bit of staring at Installation guide#Install essential packages, I can confidentially say I can find some fault in each and any bullet point. So, starting from the top, I propose changing the first one to:

userspace utilities for file systems that will be used on the system—for the purposes of e.g. file system creation and fsck,

It gets rid of the vague "for the management" and adds actual reasons for wanting the userspace utilities.

-- nl6720 (talk) 06:37, 13 June 2023 (UTC)

Since no one objected, and I finally remembered this discussion, I updated the page per my suggestion above. -- nl6720 (talk) 10:06, 22 June 2023 (UTC)

"utilities for accessing RAID or LVM partitions" could be replaced with something like:

utilities for accessing and managing RAID or LVM if they will be used on the system,

These things can actually be managed, and they are not limited to partitions. Also IMO it's better to directly link to the section that lists the packages to install.

-- nl6720 (talk) 10:48, 22 June 2023 (UTC)

Done. -- nl6720 (talk) 09:23, 30 June 2023 (UTC)

On to the next one:

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),

It lists the only split-package of linux-firmware that I've heard anyone actually need and also the dreaded Broadcom wireless.

-- nl6720 (talk) 09:23, 30 June 2023 (UTC)

Since no one has stopped me yet: Special:Diff/782857. -- nl6720 (talk) 10:20, 9 July 2023 (UTC)

I do not think the "software necessary for networking" bullet point lacks anything. Instead, Installation guide#Network configuration could be improved to avoid giving the impression that installing a piece of software is enough to make it operational. Unfortunately I can't think of a good, easily digestible phrase that accomplishes that. -- nl6720 (talk) 10:27, 9 July 2023 (UTC)

Best I can come up for Installation guide#Network configuration is:

That may include installing suitable network management software, configuring it if necessary and enabling its systemd unit so that it starts at boot.

Thoughts?

-- nl6720 (talk) 10:04, 15 August 2023 (UTC)

I would slightly alter the order of the words:

That may include installing suitable network management software, configuring it and enabling its systemd unit so that it starts at boot if necessary.

Outside of that minor nitpick, it is probably beneficial to be explicitly pointing out commons steps instead of hoping people will read the Wiki page of every software they install :P --Erus Iluvatar (talk) 10:38, 15 August 2023 (UTC)

The thought was that you need to install the package and enable the unit, but configuring is not always required. E.g. NetworkManager & dhcpcd can be simply be used as is for Ethernet connections with no prior configuration. -- nl6720 (talk) 10:42, 15 August 2023 (UTC)

👍 --Erus Iluvatar (talk) 11:02, 15 August 2023 (UTC)

Done. -- nl6720 (talk) 14:04, 30 August 2023 (UTC)

I think it would be better if "a text editor" would instead say "a console text editor", since you won't be able to use graphical ones in the tty. The issue with that text is that List of applications#Vi-style text editors and List of applications#Emacs-style text editors are separate sections on the same level as "console" and "graphical". -- nl6720 (talk) 11:35, 23 October 2023 (UTC)

And linking to List of applications#Console 23 would skip the vi/emacs-style editors so it's not an option either :/ -- Erus Iluvatar (talk) 11:41, 23 October 2023 (UTC)

I've re-ordered the sections in List of applications/Documents#Text editors: we can link to List of applications/Documents#Console now :)

-- Erus Iluvatar (talk) 08:32, 27 April 2024 (UTC)

Thanks! So here goes something:

a console text editor to allow to, e.g., edit configuration files from the console,

I can't think of a good way to word the reason of why one may need a console text editor. Suggestions welcome!

-- nl6720 (talk) 08:28, 6 May 2024 (UTC)

I can't think of a better example than editing configuration files, I doubt people would like to do so with sed :P Erus Iluvatar (talk) 13:23, 6 May 2024 (UTC)

In the worst case there's a hidden vi (/usr/lib/initcpio/busybox vi). On that note, should we give a suggestion, e.g. nano? -- nl6720 (talk) 13:30, 6 May 2024 (UTC)

Both nano and vi are part of core so we could mention both? I just don't want to have the chosen example being bikeshed material. Erus Iluvatar (talk) 13:35, 6 May 2024 (UTC)

AFAIK no one likes vi (as apposed to vim). Those that prefer vi/vim style editors would know what they want already. Let's just go with nano, since as you said in #archlinux-wiki, it's the example used in Help:Reading#Append, add, create, edit. -- nl6720 (talk) 13:50, 6 May 2024 (UTC)

👍️ Erus Iluvatar (talk) 14:22, 6 May 2024 (UTC)

The adjusted draft:

a console text editor (e.g nano) to allow editing configuration files from the console,

-- nl6720 (talk) 14:26, 6 May 2024 (UTC)

👍️ Erus Iluvatar (talk) 14:38, 6 May 2024 (UTC)

Done: Special:Diff/808532. After making the edit, I'm now thinking if "to allow editing" is grammatically correct. "to edit"? nl6720 (talk) 13:24, 17 May 2024 (UTC)

The wording does not sound offending to me, but I'm not a native speaker :D

-- Erus Iluvatar (talk) 13:28, 17 May 2024 (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)