Talk:Installation guide

From ArchWiki
(Redirected from Talk:Beginners' 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.
  • 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.

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

HiDPI on the console

With an ever increasing number of HiDPI displays, including at the begging of the article a section about adjusting the scaling factor or changing the font can be helpful, see HiDPI#Linux_console. Goetzc (talk) 02:21, 8 August 2019 (UTC)

It could be added as an example for setfont in Installation_guide#Set_the_keyboard_layout. The issue I have is that HiDPI#Linux_console mentions that tty2-6 may be unusable, while the Installation guide specifically instructs to change ttys as required in Installation_guide#Boot_the_live_environment. -- Alad (talk) 13:07, 7 September 2019 (UTC)
May be as an example for the line "See README.bootparams for a list of boot parameters" Installation_guide#Boot_the_live_environment, it could be specified to hit e button to edit the boot entry and add the following parameters to the boot line, like video=1920x1080 if you have HiDPI display. -- Xzorg6 (talk) 22:41, 15 December 2019 (UTC)
video= will just change the resolution. To get a bigger font on the console, you need CONFIG_FONT_TER16x32=y in the kernel config and fbcon=font:TER16x32 in the kernel command line. Since the official kernels don't enable CONFIG_FONT_TER16x32, someone will need to open a bug report asking for it. After that, the instructions for setting the fbcon=font:TER16x32 kernel parameter could be added to the wiki. -- nl6720 (talk) 06:52, 16 December 2019 (UTC)
linux 5.5.6.arch1-1 (currently in testing) has CONFIG_FONT_TER16x32=y (FS#64861). If if gets move to core before March, then the March iso will have it. It's probably a good idea to start drafting a tip to place in Installation guide#Boot the live environment. -- nl6720 (talk) 11:12, 26 February 2020 (UTC)
And just after I wrote this, the package was moved to core. -- nl6720 (talk) 11:27, 26 February 2020 (UTC)
I'm seeing multiple claims[12][13][14] that people with HiDPI screens are getting the TER16x32 font. I was not aware that the kernel chooses a font depending on screen size. Can anyone confirm that this really is the case? If it really works that way and unless FS#65680 messes this up, then there's nothing to add to the Installation guide about this topic. -- nl6720 (talk) 06:02, 11 March 2020 (UTC)
As per the decision to use ter16x32 is not based on screen size but only resolution.So even though a 1080p screen may be hidpi it does not use ter16x32 M.Srikanth (talk) 10:17, 11 May 2020 (UTC)
At least that part is now clear, thanks. The first step should be to get HiDPI#Linux console up to date. After that, as I've said before, a tip for the installation guide can be drafted. -- nl6720 (talk) 11:04, 11 May 2020 (UTC)
I fixed the page and removed the template M.Srikanth (talk) 12:25, 11 May 2020 (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 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
-- 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 are not readable in Lynx (or any other console web browser); see

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

Swap partition vs swap file

Would it be reasonable to stop suggesting using swap partitions and instead recommend creating a swap file? Will genfstab work in a chroot environment to create a correct fstab? Managor (talk) 12:50, 3 February 2021 (UTC)

There's no reason why swap files should be given preference over swap volumes, using one or the other (or both) is a choice left to the user. Installation guide#Example layouts already mentions swap files, although, maybe some reference to them could also be added to Installation guide#Format the partitions and Installation guide#Mount the file systems. -- nl6720 (talk) 14:51, 4 February 2021 (UTC)
If we add a reference the pseudo-text /dev/swap_partition might be confusing. Then again I don't want another cludge like path_to_swap_space in the guide. -- Alad (talk) 09:30, 31 October 2021 (UTC)


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)

Add link to ALSA firmware in the Install essentials packages section

With sof-firmware gaining more and more traction on newer systems it might be useful to add a link or piece of information that this might be necessary for newer laptops/cards, see Advanced_Linux_Sound_Architecture#ALSA_firmware. We currently get pretty much daily reports on the BBS where someone wonders where their sound card has gone. I know this is "technically" included in the "install additional firmware not included in linux-firmware" line, but since this is something that hasn't really been necessary for years this is potentially something not everyone is immediately aware of. V1del (talk) 17:15, 13 August 2021 (UTC)

Even with a link to Advanced_Linux_Sound_Architecture#ALSA_firmware, it might be confusing that it applies based on the hardware, even when the user wants to use PulseAudio or Pipewire. Is there a better place where audio firmware could be described? — Lahwaacz (talk) 20:00, 13 August 2021 (UTC)
I tried to have some sort of "standardized" snippet on laptop pages when it needs ALSA firmware, but the ArchWiki is not a hardware db and we cannot document all pieces of hardware. Audio is not essential for some users but a few depend on screenreaders, which is crucial to accessibility.
In the end it might not cause harm to install sof-firmware when in doubt.
-- NetSysFire (talk) 01:17, 14 August 2021 (UTC)
I mean if we cover firmware in e.g. Sound system and link to that instead of ALSA, it would seem much more general. — Lahwaacz (talk) 06:19, 14 August 2021 (UTC)
Well for this particular case you can fairly easily identify whether you have a need for sof-firmware with an lsmod | grep snd_sof or a dmesg | grep -i sof, but yes might be helpful to move that somewhere else if we want to ensure to have hardware based separation here. V1del (talk) 12:04, 14 August 2021 (UTC)
I added sof-firmware as an example (and the aforementioned link) so that there's at least something for now. -- nl6720 (talk) 10:20, 25 August 2021 (UTC)

Add a check for "native sector size" before/during partitioning step

Some pages like Solid state drive are nearly impossible to get to from just following the Installation Guide. This is problematic as some recommendations from these pages are only relevant before installation, as it is too late afterwards (notably for setting native sector size as in Solid state drive#Native sector size. I believe there should be a note in the partitioning step, something like modifying this line:


As an alternative, this could be added to Partitioning, but it's already quite big... -- Cvlc (talk) 15:47, 29 August 2021 (UTC)

Linking both Improving_performance#Partitioning (which needs improvements) and Solid state drive seems excessive. Also, it's unclear if the improvement is tangible enough to make users work through yet another wiki article for their basic setup. -- Alad (talk) 09:28, 31 October 2021 (UTC)
An alternative could be to add :
Tip: Check that your disk reports the correct sector size
at the beginning of partitioning. It's an important optimization step and currently not addressed. On a brand new nvme SSD, strictly following the wiki, I ended up with a wrongly set up LUKS volume because the drive reports 512 byte sectors as the active option, and I only found out after installing.
-- Cvlc (talk) 16:15, 23 November 2021 (UTC)
Seeing as the "native sector size" is the only issue that can't be simply fixed after the fact (unlike e.g. TRIM), it should be fine to link it (after Talk:Advanced Format#Rewrite Advanced Format to a new Sector Sizes page is done). As for linking to Solid state drive in general, IMHO there's no need. It's already linked from General recommendations#Solid state drives. -- nl6720 (talk) 09:53, 25 November 2021 (UTC)
Agreed, the sector size issue was the one that really bothered me. I corrected the title.
-- Cvlc (talk) 11:05, 25 November 2021 (UTC)
Now that Talk:Advanced Format#Rewrite Advanced Format to a new Sector Sizes page is done, I suggest adding
Tip: Check that your disk reports the correct sector size
before the partitioning step
-- Cvlc (talk) 03:42, 4 December 2021 (UTC)
As I already mentioned, there's a lot of steps involved in that article for unknown gains. Presumably, most people will think it's a requirement (due to the general nature of the article) even when formatted as a tip. Only Advanced_Format#Alignment is straightforward and already handled by fdisk. -- Alad (talk) 09:51, 9 January 2022 (UTC)
It's true that it's not a very simple article, but it's actually not that bad since people will skip to either HDDs or SSDs sections which are much more to the point. What do you think would be a better way to address this? formatting the disk to the correct sector size cannot be done at a later point in time. Again, all of this stems from the fact that it happened to me, and it's going to happen to anyone with a similar setup (most hardware with recent SSDs). What if I try simplifying the Advanced format article further ? --Cvlc (talk) 20:43, 9 January 2022 (UTC)

Wording of the "Set the console keyboard layout" section

As everyone knows, I'm no English expert, but the sentence "To modify the layout, append a corresponding file name to loadkeys(1), omitting path and file extension." (emphasis mine) in Installation guide#Set the console keyboard layout, looks somewhat odd to me.

Despite the fact that "the main function of loadkeys is to load or modify the keyboard driver's translation tables", IMHO it's more common to refer to it as switching the keyboard layout not modifying it. I don't see any benefit in being technically correct here, if that even applies with the current wording. Since the next sentence contains "set a German keyboard layout", it makes it even more confusing.

Using "append" doesn't feel right, too. I think "pass" is more common and clearer. E.g. "pass a corresponding file name to the loadkeys(1) command, omitting path and file extension" or "pass a corresponding file name, omitting path and file extension, to the loadkeys(1) command".

-- nl6720 (talk) 11:38, 23 November 2021 (UTC)

New User Friendliness

I have my own installation guide at <redacted> which has gotten more and more out of date, yet I've been reluctant to take it down because, imho, there are some real "failings" of the official guide here.

Some of these "failings" (for lack of a better way to put it) are part of the Arch ethos and I understand the reasons: 1. Arch is inherently a DIY distro that you make yourself, so we shouldn't go around making default recommendations more that necessary and 2. We can't make to many assumptions about the users current hardware/OS situation. The conflicts with these and the installation guide are pretty obvious and somewhat documented in past discussions. Still, I think a better middle ground could be reached

So, first, let me provide some concrete recommendations:

Verify signature → Immediately assumes you have a system with gpg installed, or know how to install it and use it, but doesn't mention torrents will verify this for you (I think?)

Prepare install medium → lists USB, Disc, or PXE as options, doesn't indicate that USB is typical -> in USB install, most of the tools recommended for Windows are... meh. With the easiest to use option for noobs, Etcher, not being listed, and Rufus being multiple options down. I think it's safe to assume many new users will be coming from Windows, and not have tons of prior experience with the more advanced tools.

Verify the boot mode → doesn't explain why UEFI might be prefered / better if on newer hardware/living along side Windows

Connect to the internet → Sort of implies `ip link` enables the network interface

Partition the disks → doesn't include any information about making Arch live along side other OS's (which, again, a lot of users are going to want to do). Also doesn't recommend users do a backup first, if they're using a disk with data on it

Install essential packages → doesn't clarify that still aren't enough to have a graphical environment

Boot loader → Even if we don't directly provide instructions for one option, it's probably worth saying systemd-boot and grub are the most common two options, for UEFI and BIOS respectively. This could be either here or in the boot

On that note, the page isn't even linked in the installation guide, nor is - both of which provide pretty vital information.

Generally, it just seems weird to call this an installation guide when for many users it reads more like an installation meander-through-a-forest-of-links

Vega (talk) 20:09, 29 December 2021 (UTC)

The thing is, if you want to do it yourself and understand what you are doing, you're going to have to follow this forest of links and you're going to have to read all those articles... I do agree though that on my first install, I missed having some friendly recommendations.. I think a middle way could be to keep the Installation guide as is, but add new articles with example setups. A little bit like the examples in Dm-crypt/Encrypting_an_entire_system. Except I believe those examples should strictly follow the Installation guide and do things in the exact same order, keeping the chapter numbers etc.. so that it's easy to understand which step we are at and why we are doing stuff. Could be a reason to rewrite and merge the Dm-crypt examples page. I've been working on something like this (notes for my setup mostly), still a draft but can help to show what I mean : User:Cvlc/Notes/Installation guide.
One could dream of some kind of interactive menu where you define your setup with prompts at the beginning (laptop/server, encryption?, filesystem, DE, etc...) and then the install guide gets updated with your choices :) but I cannot see any simple way of doing that without restricting choices, which would make Arch very poor.
-Cvlc (talk) 21:24, 29 December 2021 (UTC)
I think the example setups recommendation is a very good one. Especially if it provided running commentary about why the choices were being made and common pitfalls. This would probably largely help with following the mess of steps required for a dual-boot Windows/Mac setup too. It would probably end up being quite stylistically different than the majority of the Wiki, but I think a friendly welcoming tone would be a good thing to contrast the sterile wiki tone (which is usually ideal)
Vega (talk)
I've redacted the link per [15]. Anyway, going by your guide you seem to aim for a comprehensive wiki-in-one-page. That kind of approach was done many years back (still done in some translations, namely the German one) and is unmaintainable. While the current guide certainly has its pitfalls, I for one am also very glad it is a short document with branches I can follow as needed, instead of having to wade through a 40-page document just to achieve a basic installation.
Regarding the "example setups", as their respective maintainers lose interest, they will eventually diverge from the Installation guide and the rest of the wiki. In that sense they are little different from unsupported user guides. If someone wants to make some concrete drafts, though, by all means, propose them. -- MrX (talk) 01:48, 30 December 2021 (UTC)
The link is not Spam, advertising, or solicitation. It is directly related to arch as a project. So, again, that link is <redacted> for anyone following along. Vega (talk) 05:58, 30 December 2021 (UTC)
It's spam, it even asks for donations (link to Patreon account). Since you have no interest in following the community guidelines, I've suspended your account. -- Alad (talk) 22:37, 30 December 2021 (UTC)
So a mod redacts your link, and you think the best response is to post it again? Smart. Scimmia (talk) 18:57, 30 December 2021 (UTC)
We already have a category for these "different setups": Category:Installation process. It is linked from the first paragraph of the Installation guide and contains even Dm-crypt/Encrypting_an_entire_system. — Lahwaacz (talk) 08:32, 30 December 2021 (UTC)
Indeed, even the proposed interactive menu with prompts is already available in that category, see Archboot. Closing -- Alad (talk) 09:34, 9 January 2022 (UTC)

Why Google Ping?

Cloudflare has worlwide ping responding to or (no DNS needed) Why ping google but not ping disgrace

—This unsigned comment is by ForsakenCommander (talk) 2022-01-12T15:09:11. Please sign your posts with ~~~~!

Not sure what you are talking about, the ping command on the page uses as the target. --Erus Iluvatar (talk) 17:07, 12 January 2022 (UTC)