Talk:Installation guide

From ArchWiki

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.
  • localectl list-keymaps does not work due to bug FS#46725. For the chosen replacement command, see [5].
  • 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 [6], [7], [8], [9], [10] 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 [11] for past discussion on this topic.

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

Link to the German version

Instead of de:Arch Install Scripts you could choose de:Anleitung für Einsteiger it means "Beginner's Guid" and is a very detailed artikel for very new arch users and the future experts.

Thank you, done. -- Kynikos (talk) 16:31, 6 February 2018 (UTC)
This was already proposed last year and rejected: [12]. I don't see what has changed since then. If someone adds me as admin to the german wiki or changes the protection settings, I can update de:Arch Install Scripts as required. -- Alad (talk) 18:13, 6 February 2018 (UTC)
I see, I didn't remember that discussion so I've reverted the change, hopefully you'll make it to update the translation, let's leave this open until the problem is solved, otherwise this kind of suggestion will keep appearing recurrently. -- Kynikos (talk) 17:53, 7 February 2018 (UTC)
Apparently since last year the translation has been halved in size, but its scope is still much larger than the Install guide (or even the old Beginners' guide). -- Alad (talk) 09:42, 9 May 2021 (UTC)

First mention of /mnt in example partition layout

/mnt is mentioned at mount point in Installation_guide#Partition_the_disks, while /mnt is made explicit two sections later in Installation_guide#Mount_the_file_systems. As I recall it, this was changed because some users blindly copy pasted commands and mounted /boot on the live system, instead of /mnt/boot. Some options:

  • Introduce another column describing the mount point on the installed system.
  • Actually explain /mnt early.
  • Revert the "mount point" to not include /mnt.

-- Alad (talk) 13:03, 7 September 2019 (UTC)

I don't understand what's the actual problem here... -- Lahwaacz (talk) 09:36, 8 September 2019 (UTC)
From what I read on #archlinux-wiki, this comes from https://www.reddit.com/r/archlinux/comments/d0v0j3/is_it_just_me_or_is_the_prospect_of_installing/ where the user was confused by the lack of root mountpoint (i.e. /mnt vs /). A question could be raised, if we should concern ourselves with users who have strong opinions about the wiki content yet can't be bothered to propose improvements in the talk pages...
About Alad's proposed options: I disagree with the first option, I think it will just complicate things even further. I support the third option and maybe adjusting the column header like in Special:Diff/581800.
I'd actually would like to go even further and change the commands run from outside chroot to be visually distinct, e.g.: 
root@archiso # mount /dev/sdX1 /mnt
I think it would better solve the underlying issue.
-- nl6720 (talk) 15:26, 8 September 2019 (UTC)
I'm not overly fond of the longer column name. For the last proposed option, I may agree if this is formalized in Help:Style, so that it is not specfic to the Installation guide. -- Alad (talk) 11:20, 10 September 2019 (UTC)
Adding it Help:Style was my intention, since other articles, too, will need to use that style for some commands. I'm thinking of creating a template for it: Special:Permalink/581945. -- nl6720 (talk) 10:19, 11 September 2019 (UTC)
Sounds good to me, I'd just prefer the regular (non-bold) font for the prompt as above. -- Alad (talk) 21:54, 13 September 2019 (UTC)
Special:Permalink/582327. Are there any other opinions about creating such a template? Or should I take this discussion to Help talk:Template per Help:Template#Creation? -- nl6720 (talk) 18:31, 14 September 2019 (UTC)
  1. How are you going to call the template? This template would probably add to the Help:Template#Code formatting templates series, should it be named in a consistent fashion?
  2. Should this template support custom prompts, and if so, should it be called "pc" (from "(custom) prompted" code)?
  3. I don't like the red color too much, if bold is not an option maybe we can go green|purple|blue, something that recalls less a warning of some kind? Or can we just leave it with the default font color? Or a slightly fainter black?
  4. I haven't looked well into it, but maybe we can instead add an optional argument to Template:bc and Template:hc that prefixes a custom (colored) prompt? I wouldn't see a problem with repeating "root@archiso #" in every instance, or we may derive the new template from those two at that point.
  5. The template should probably be derived from Template:bc in any case, for simpler code, see User:Kynikos/Template:Sandbox2.
-- Kynikos (talk) 17:36, 16 September 2019 (UTC)
  1. Initially I was going to call it Template:Archiso since it would be Archiso-specific, but I'm starting to think that creating a more general-purpose template would be better. It could then be used in PostgreSQL and the [postgres]$ convention would get formalized in Help:Style. Now the issue is the [user@peer-a]# in Template:hc used in WireGuard. I'd rather not create two new templates, but I'm having trouble getting Template:Sandbox to work :(
  2. I like your "Template:pc" suggestion.
  3. Be glad I didn't post my first draft that was slightly more colorful. From your offered colors, I'd choose purple.
  4. I'd rather not mess with the established templates just for this change, so I'd prefer creating a new template.
  5. I didn't even think about using Template:bc. Is it a good idea to do that? The new template might need to be updated if Template:bc is ever changed in an incompatible way.
-- nl6720 (talk) 07:33, 17 September 2019 (UTC)
Yeah, after viewing your attempts and looking into it myself, I think modifying bc/hc is out of discussion, it would add too much code/style for so little use.
Thinking about this again one day after, I feel I'm realizing that my concerns in general may descend from the fact that we're going to create a template to represent (block) code, even though we already have 2 which basically do the same thing, including allowing to include a prompt; the only addition of this "Archiso" or "pc" template would be the formatting around the prompt, so why not keep it simple (I know, "simplicity" is often subjective and controversial) and instead either make a Template:Archiso to be used like {{bc|{{Archiso}} mount /dev/sdX1 /mnt}} or Template:ps (or Template:PS) to be used like {{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}? They also work with Template:hc and space-prefixed code blocks!
Putting the choice of color aside, if the above idea of a standalone prompt template isn't welcome, I think my second choice would be to make two Template:pbc and Template:phc that work like {{pbc|$|ls}} and {{phc|$|ls|...}}, with the style rule to use them only in case of complex prompts. I'd still derive them from bc/hc to inherit any changes that we'd decide to make to them, and avoid repeating that ugly <pre> hack even more.
Otherwise I give up and accept the Template:Archiso that works like {{Archiso|mount /dev/sdX1 /mnt}}, in the hope that one day we won't need an analogous "hc" version.
-- Kynikos (talk) 14:24, 17 September 2019 (UTC)
I can't say I really like the idea of {{bc|{{Archiso}} mount /dev/sdX1 /mnt}} or {{hc|{{ps|root@archiso #}} mount /dev/sdX1 /mnt}}. I'd prefer creating Template:pbc and Template:phc.
I still don't get what's wrong with Template:Sandbox. It should just work:
prompt # command
code
-- nl6720 (talk) 04:43, 18 September 2019 (UTC)
FWIW (and a bit of fun) I've fixed Template:Sandbox, although I'm not sure if we really need that level of automation ^^ I stick to my position above, is there a third (or more) opinion? -- Kynikos (talk) 15:48, 18 September 2019 (UTC)
I think you like the #800080 shade of purple, right? ;-) Lahwaacz (talk) 11:39, 21 September 2019 (UTC)
Yes, I do like that one :D but I think it would be too bright for this template. -- nl6720 (talk) 11:52, 21 September 2019 (UTC)
Any news on this one? If not, I haven't seen this kind of issue or confusion occur since. -- Alad (talk) 09:37, 31 October 2021 (UTC)
I don't think I want to create such a template anymore, since it would require updating other installation related pages. To go back to your originally proposed options, I'm for explaining /mnt early. -- nl6720 (talk) 09:42, 4 November 2021 (UTC)

Buggy graphics driver

Can there be a hint that nomodeset parameter could be used if the graphics driver is buggy (I've heard nouveau may be buggy sometimes) M.Srikanth (talk) 04:47, 12 May 2020 (UTC)

I would expect this to be mentioned in General_troubleshooting... -- Alad (talk) 09:43, 31 October 2021 (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:
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.
-- 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)

Remove parted

Due to parted not aligning the partition size (and with no patch in sight) which prevents using 4096 byte sectors with dm-crypt/LUKS unless explicitly planned before, I'd like to remove the "parted" link from Installation guide#Partition the disks. An alternative would be to change all examples in Parted to not use percentages and warn against using them. -- nl6720 (talk) 07:21, 7 April 2022 (UTC)

I prefer to change the examples in Parted. Just removing the link from installation guide won't stop people from using the tool. -- Alad (talk) 10:52, 7 April 2022 (UTC)

Note on Network Setup

One of the most common installation issues that comes up on Reddit, Forums, and other discussion areas is not having done any sort of network setup. While the Installation Guide explicitly call out Network Setup as a required step, I suspect people are mistakenly believing the setup steps they did already to establish a connection on the installer will carry over to their installed system.

I propose adding a note such as (example content):

Note: Configuring your network connection above only established your network for the installer. This section will configure the network for your installed Arch system. Failure to do so may leave you without network access after completing installation.

Nalthien (talk) 17:40, 15 May 2022 (UTC)

Such a thing does not warrant a warning since there's nothing dangerous about being offline. It may even be the safest state the system will ever be. -- nl6720 (talk) 10:24, 18 May 2022 (UTC)
I can agree that it doesn't warrant a Warning given the style guide; however, I do think a Note would be appropriate to "highlight information easily overlooked." It's clearly overlooked quite often. Nalthien (talk) 17:36, 20 May 2022 (UTC)
Installation guide#Connect to the internet already explains (or tries to, at least) that the live environment's network setup has nothing to do with the installed system. Perhaps the list items in Installation guide#Install essential packages could be made a little more verbose to explain why someone may want to install those things. -- nl6720 (talk) 10:24, 18 May 2022 (UTC)

I propose adding something like the following:

To configure the freshly installed system's network for out-of-the-box ethernet DHCP functionality as on the installation image, create a simple /etc/systemd/network/20-wired.network file for your adapter Name, eg:

[Match]

Name=enp1s0

[Network]

DHCP=yes

Also, enable both systemd-networkd.service and systemd-resolved.service

1. It will only take up a few lines; it is succinct, effective and informative. 2. Further, the functionality on reboot will mimic functionality in the installation image. 3. It uses simple built-in services without installing anything extra. 4. It will also cut down on forum noise immensely. Misfit138 (talk 11:11 21 March 2023 (UTC-5)

It's also incomplete, as systemd-resolved takes some setup. And it would cause more problems on the forums when people then enable NM or whatever and have both. There's a reason the network configuration page is linked. Scimmia (talk) 15:14, 21 March 2023 (UTC)
systemd-resolved setup is optional according to the network configuration page, and I can confirm this to be the case on a bare-metal workstation as well as a VM. Doing the above minimal steps results in full functionality for a simple dhcp setup and mimics the ootb install image function. Further, installing NM as you indicated would result in a chicken or egg problem before reading a wall of text and realizing they have to setup a trivial and perhaps temporary dhcp solution in order to install a more permanent one anyway. The user has the ability to install packages in the chrooted environment, yes, but the expectation of a functional network in a freshly booted system is reasonable. One explanatory sentence or phrase can inform users that only one network config scheme is needed, as well as a brief warning to avoid conflicts (such warnings already exist elsewhere). The net conf. page can and should still be linked, but it is a monstrous page for something so trivial that can be suggested so succinctly. sent from my phone, will clean up formatting. -- Misfit138 (talk) 11:37 22 March 2023 (UTC-5)
systemd-networkd only supports using systemd-resolved for DNS. A network connection without working DNS is not something most people would want. I think the best we could do is to explicitly link to systemd-networkd as an example in Installation guide#Install essential packages. -- nl6720 (talk) 16:16, 22 March 2023 (UTC)
With just the /etc/systemd/network/20-wired.network file, and no other network tools, and after starting networkd and resolved, I can ping sites and visit urls with links and lynx; ostensibly, something is resolving DNS for me(?) (Confirmed on VM and bare-metal.) However, I must regretfully admit that I am not likely to compel you with the principles I have set forth. Thank you for your time and for considering this. -- Misfit138 (talk) 13:35 22 March 2023 (UTC-5)
I missed that you suggested to also enable systemd-resolved.service. In that case, just as systemd-resolved#DNS says, DNS will only work for software that do not parse /etc/resolv.conf themselves. -- nl6720 (talk) 17:44, 22 March 2023 (UTC)
Perhaps the "software necessary for networking" bullet point in Installation guide#Install essential packages could be extended with a tip that suggests using systemd-networkd + systemd-resolved and copying /etc/systemd/network/20-ethernet.network from the live environment. -- nl6720 (talk) 09:18, 28 April 2023 (UTC)
The crosslinked article already has a note, that could be added there instead, similar to Special:diff/773727.
While I see the point of this item, the systemd- tools are probably not the most beginner-friendly ones to configure networking anyway (for some use-cases ok, not for the scope of this guide. Other tools like netctl are arguably simpler to use). The skill to configure networking is important and that's not triggered by copying an autogenerated file. What's the general state of archinstall? Could it be a solution to add a tip for Arch newcomers at the beginning of the guide to it instead?
--Indigo (talk) 07:45, 29 April 2023 (UTC)
My idea was to somehow replace the note in Installation guide#Connect to the internet with a tip in Installation guide#Install essential packages. If there's no good way to do it, then let's keep things as is.
archinstall would probably warrant an entirely separate discussion.
-- nl6720 (talk) 13:02, 30 April 2023 (UTC)

Partitioning tools

Is there any reason gdisk is not listed as an option? If we include parted, despite problems with alignment, I don't see why gdisk is excluded. The wiki page for fdisk actually suggests gdisk as an alternative. I'm probably not the only one who learnt to use gdisk for GPT and it is nice to use a familiar tool if there's no reason not to. But I don't want to add it if it's omitted for a reason. --cfr (talk) 01:29, 20 August 2022 (UTC)

fdisk linking to gdisk is the result of a previous discussion about this.
Personally, I agree that Installation guide#Partition the disks should mention gdisk. My suggestion would be: "Use fdisk, parted or gdisk (GPT only) to modify partition tables".
-- nl6720 (talk) 10:16, 20 August 2022 (UTC)
By the same argument, we should then mention cfdisk, cgdisk and any other partition tools. As such I'd suggest the following instead: "Use a partitioning tool like fdisk or parted to modify partition tables". -- Alad (talk) 13:32, 24 August 2022 (UTC)
Your suggestion is better than the current text at least. -- nl6720 (talk) 08:44, 25 August 2022 (UTC)
In the end the situation is quite similar to the one for boot loaders and network managers. I wouldn't mind listing more alternatives (or even tables) in the installation guide, but then the reasoning has to be applied equally to other sections. -- Alad (talk) 15:08, 25 August 2022 (UTC)
I hope it's nothing like this sorry excuse for a table.
The thing with partitioning tools, compared to e.g. network managers, is that there are not that many of them. There's basically just fdisk, gdisk and parted. fdisk & gdisk additionally have scriptable and text user interfaces. And there are GUI ones based on parted.
I'd say let's go with your suggested text for now. We'll get to the greater goal eventually :D
-- nl6720 (talk) 15:22, 25 August 2022 (UTC)
The table in Partitioning#Partitioning tools got better, so IMHO it should be fine to link to it now. -- nl6720 (talk) 16:04, 28 August 2022 (UTC)
The "old" beginners' guide had a similar table included: User:Alad/Beginners'_guide#Partition_the_devices. Considering the small size, it could make sense to include the one from Partitioning#Partitioning tools in the installation guide directly. The downside is the GUI wrappers don't apply to the live environment. -- Alad (talk) 16:36, 28 August 2022 (UTC)
If there's a problem with parted not aligning, it strikes me as perverse to mention fdisk and parted by name, but nothing else. Surely the example tools should be ones which don't need special warnings (if at all possible)? Maybe fdisk should be the only example? (Unless it has changed, gdisk isn't on the ISO, so that's a good reason not to pick it out, but steering people away from parted seems warranted if it is problematic.) --cfr (talk) 03:13, 30 October 2022 (UTC)
Is everyone OK with "Use a partitioning tool like fdisk to modify partition tables"? That way we point to the resources while keeping only the tool used in the following examples. --Erus Iluvatar (talk) 21:34, 20 December 2022 (UTC)

Missing pacman-key steps ?

I just tried (using archlinux-2022.11.01-x86_64.iso) the standard archlinux installation (pacstrap) following the guide, and once the packages were downloaded, they failed to install with errors like:

  • "signature from <maintainer> is unknown trust"

I found on the web the following commands to solve the issue: (https://bbs.archlinux32.org/viewtopic.php?id=2900)

  • pacman-key --init
  • pacman-key --populate archlinux

After those two commands, the pacstrap installation works fine.

If those two commands are needed, shouldn't we document them in the Installation guide ?

(note that the same problem/solution is applicable to archinstall method too)

—This unsigned comment is by Nsauzede (talk) 23:02, 3 November 2022 (UTC). Please sign your posts with ~~~~!

This is already done by pacman-init.service. Scimmia (talk) 23:38, 3 November 2022 (UTC)
I hit the exact same problem with same installation iso. I got the solution from https://wiki.archlinux.org/title/Pacman/Package_signing
—This unsigned comment is by Roblaing (talk) 2022-12-02T07:53:41. Please sign your posts with ~~~~!
This is caused by out of date keyring, what really should be added to the installation guide is starting the keyring sync service systemctl start archlinux-keyring-wkd-sync before the pacstrap step, with a warning to check that it has finished running before continuing. This will allow both older ISOs to work and even current ISOs to work. December ISO is once again broken right now as openssl has too new a key. C0rn3j (talk) 23:21, 24 December 2022 (UTC)
archlinux-keyring-wkd-sync doesn't 'sync' the keyring, it refreshes it which is only helpful in a limited set of circumstances. Most of the time, it won't help these errors. Scimmia (talk) 03:21, 25 December 2022 (UTC)
It however helps with the current issue and am sure the previous issues too, as they were fixable with partially installing archlinux-keyring on the ISO before. I am not aware of a better solution, unless reinitializing and populating the keyring as per OP is actually preferred? C0rn3j (talk) 11:05, 25 December 2022 (UTC)
Reinitializing and populating the keyring is a solution for a completely different problem. Scimmia (talk) 13:32, 25 December 2022 (UTC)

Add tip for easily booting iPXE-arch.efi file from almost all hardware

For most scenarios (I assume) it isn't necessary to flash an USB drive or burn a disk. You can simply put the PXE EFI binary on a drive and boot it from "BIOS" directly (works e.g. on Dell hardware). If your BIOS does not support loading arbitrary files directly, you can use the UEFI shell to do so if available. Otherwise you can simply put the image under /EFI/BOOT/ and name it bootx64.efi and select this drive from the boot menu. The drive might even be the boot partition, if you are going to do a reinstall. (Tested on Lenovo and Fujitsu notebooks) Flacer (talk) 14:06, 26 January 2023 (UTC)

Installation guide#Acquire an installation image already mentions the netboot image. And yes, it should work just fine on any system with an Ethernet connection. -- nl6720 (talk) 14:13, 26 January 2023 (UTC)
That is true, but in my opinion it would be beneficial to emphasize this because esp. new users think of setting up a server etc. (me too, although I'm not quite a new user; discovered this by accident).
So it would be better to put it under Netboot? Anyway it would be helpful to place a link to that page, most appropriately under 1.3. -- Flacer (talk) 15:42, 26 January 2023 (UTC)
I could be wiki-linked from 1.1 and somehow mentioned in 1.3. Just need to find the right words for it. -- nl6720 (talk) 14:55, 1 February 2023 (UTC)
I think an additional link in 1.1 is too early. Currently, the downloads landing page links a dedicated netboot page, which at the end leads to the wiki article. Linking it earlier may mislead to users skipping the gpg steps in 1.2. and the landing page.
In 1.3 we could replace "or a network with PXE:" with "or an appropriate PXE" for starters. And complement that by adding to the last intro sentence in PXE "This works well when you already have a server set up, but may (for installation purposes) also load the image directly from an official Arch mirror."
--Indigo (talk) 22:52, 3 February 2023 (UTC)
I'm not too sure about "or an appropriate PXE". I assume most people would just place the netboot EFI binary in a USB flash drive and boot it directly. The fact that the images are iXPE builds is not that relevant. Perhaps 1.3 needs to explicitly differentiate the deployment methods of the ISO and netboot images since the links in the section are ISO specific. -- nl6720 (talk) 10:02, 4 February 2023 (UTC)
True, like two bullet points for ISO and iPXE in 1.3. I proposed "appropriate PXE", because (as Flacer mentions) current "network PXE" does indeed sound like you need to set up a server when you visit the article. How about switching PXE links to netboot?
--Indigo (talk) 19:23, 5 February 2023 (UTC)
Well, you can still PXE-boot the ISO contents as the PXE article describes, so I don't think it's correct to remove the links.
I would probably be best if Netboot had instructions on how to create a bootable medium from the image. At least for UEFI, since that's dead simple. IMHO 1.3. could then be turned into two sentences, one for the ISO deployment, one for netboot.
-- nl6720 (talk) 09:52, 6 February 2023 (UTC)
Sure, it can; see the sentence I proposed above for PXE. I agree it is more important to edit both articles first. The simple method proposed by Flacer can be turned into a tip in the Netboot section you suggest. Afterwards we can see what changes are still useful in this main guide. Perhaps this item should be moved to Talk:Netboot for implementation first. --Indigo (talk) 18:44, 16 February 2023 (UTC)
There's Netboot#Boot from a USB flash drive that can be linked now. -- nl6720 (talk) 16:10, 26 March 2023 (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 :

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

Make LVM Link More Relevant to Partitioning Disks

In Installation_guide#Partition_the_disks, where it briefly mentions LVM and to "do it now", the link should redirect the user to Install_Arch_Linux_on_LVM instead of LVM because it does not explain in detail to use the Linux LVM partition type, and other necessary commands to activate it.

Xulingo (talk) 06:34, 12 May 2023 (UTC)

Retrieved from "https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=779593"