Talk:Installation guide

From ArchWiki
(Redirected from Talk:Beginners' Guide)
Latest comment: 1 hour ago by Erus Iluvatar in topic First mention of /mnt in example partition layout

Read this first before adding new suggestions

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

First mention of /mnt in example partition layout

Latest comment: 1 hour ago22 comments5 people in discussion

/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)Reply[reply]

I don't understand what's the actual problem here... -- Lahwaacz (talk) 09:36, 8 September 2019 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
  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)Reply[reply]
  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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
I think you like the #800080 shade of purple, right? ;-) Lahwaacz (talk) 11:39, 21 September 2019 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
I'm super late to the party, but why don't we simply get rid of the Mount point column in Installation guide#Example layouts?
An other option would be to "revert" to match what's used in Partitioning#Example layouts, i.e. no prefixing /mnt.
Erus Iluvatar (talk) 20:11, 16 April 2024 (UTC)Reply[reply]
IMO getting rid of the column would just confuse readers. I support removing the /mnt prefix provided we rename the column to "Mount point on the installed system" and mention the need to add the prefix in Installation guide#Mount the file systems. -- nl6720 (talk) 14:12, 17 April 2024 (UTC)Reply[reply]
I've made a draft for the example layout. For Installation guide#Mount the file systems, it already starts with "Mount the root volume to /mnt": I think the command line examples that follow are already self-explanatory? Or did you have something like "Create any remaining mount points for the installed system in the /mnt directory (i.e. prefixing them with /mnt, such as /mnt/boot for /boot) and mount the volumes in their corresponding hierarchical order." in mind?
--Erus Iluvatar (talk) 15:32, 17 April 2024 (UTC)Reply[reply]
The comment that started this discussion mentions that it's not as self-explanatory as we'd like :)
I did mean explicitly mentioning the need to prefix /mnt in Installation guide#Mount the file systems. I'm not sure about the best way to phrase it, but how about something like: "Create any remaining mount points under /mnt (such as /mnt/boot for /boot) and mount the volumes in their corresponding hierarchical order."
-- nl6720 (talk) 11:08, 18 April 2024 (UTC)Reply[reply]
True :D
Your wording sounds better than what I had tried to do, let's go with it.
-- Erus Iluvatar (talk) 12:14, 18 April 2024 (UTC)Reply[reply]
👍 Lahwaacz (talk) 21:33, 17 April 2024 (UTC)Reply[reply]

Draft

Example layouts

UEFI with GPT
Mount point on the installed system Partition Partition type Suggested size
/boot1 /dev/efi_system_partition EFI system partition 1 GiB
[SWAP] /dev/swap_partition Linux swap At least 4 GiB
/ /dev/root_partition Linux x86-64 root (/) Remainder of the device. At least 23–32 GiB.
  1. Other mount points, such as /efi, are possible, provided that the used boot loader is capable of loading the kernel and initramfs images from the root volume. See the warning in Arch boot process#Boot loader.
BIOS with MBR
Mount point on the installed system Partition Partition type Suggested size
[SWAP] /dev/swap_partition Linux swap At least 4 GiB
/ /dev/root_partition Linux Remainder of the device. At least 23–32 GiB.

See also Partitioning#Example layouts.

GitLab blobs in Lynx

Latest comment: 21 May 20228 comments3 people in discussion

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)Reply[reply]

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)Reply[reply]
It has been filed under nice to have. -- nl6720 (talk) 17:19, 4 August 2020 (UTC)Reply[reply]
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)Reply[reply]
I'd prefer simply removing some of the links.
-- nl6720 (talk) 09:30, 4 November 2021 (UTC)Reply[reply]
Alright, I've removed those links. (Special:Diff/700696, Special:Diff/700693) -- Alad (talk) 11:39, 4 November 2021 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Post-installation

Latest comment: 15 April 20218 comments5 people in discussion

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)Reply[reply]

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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Missing pacman-key steps ?

Latest comment: 25 December 20226 comments3 people in discussion

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 ~~~~!Reply[reply]

This is already done by pacman-init.service. Scimmia (talk) 23:38, 3 November 2022 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
Reinitializing and populating the keyring is a solution for a completely different problem. Scimmia (talk) 13:32, 25 December 2022 (UTC)Reply[reply]

Mention zram

Latest comment: 24 June 20238 comments2 people in discussion

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)Reply[reply]

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)Reply[reply]
(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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]

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

Latest comment: 23 October 202321 comments4 people in discussion

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 ~~~~!Reply[reply]

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)Reply[reply]
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 ~~~~!Reply[reply]
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)Reply[reply]
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)Reply[reply]
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-fwAUR 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)Reply[reply]
I replaced "sound cards" with "onboard audio" which will hopefully get the message across better. -- nl6720 (talk) 05:56, 13 June 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
"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)Reply[reply]
Done. -- nl6720 (talk) 09:23, 30 June 2023 (UTC)Reply[reply]
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)Reply[reply]
Since no one has stopped me yet: Special:Diff/782857. -- nl6720 (talk) 10:20, 9 July 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
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)Reply[reply]
👍 --Erus Iluvatar (talk) 11:02, 15 August 2023 (UTC)Reply[reply]
Done. -- nl6720 (talk) 14:04, 30 August 2023 (UTC)Reply[reply]
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)Reply[reply]
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)Reply[reply]

Clarify pre-installation time zone

Latest comment: 5 March2 comments2 people in discussion

Special:PermanentLink/800213#Update the system clock instructs the user to verify that "the system clock is accurate," using timedatectl. A this point, a time zone hasn't been (and needn't yet be), but the output of the command will include Time zone: UTC. Would it be worth mentioning that this'll get handled later? e.g.

Use timedatectl(1) to ensure the system clock is accurate for UTC (the time zone may be adjusted later during installation):

CodingKoopa (talk) 04:19, 4 March 2024 (UTC)Reply[reply]

I'd skip on referring to later instructions (it's written as step-by-step), but you're right it should mention UTC, e.g. "...and time will be synced to UTC automatically" in the sentence above. Also, I'd replace "ensure the system clock is accurate:" with "ensure the system clock is synchronized:".
--Indigo (talk) 22:10, 5 March 2024 (UTC)Reply[reply]
Retrieved from "https://wiki.archlinux.org/index.php?title=Talk:Installation_guide&oldid=806364"