Talk:Beginners' guide

From ArchWiki
Jump to: navigation, search

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.

Unification

A single, unified official install guide

Note: This is based on talk/consensus in #archlinux. The official Installation Guide page is going to be expanded (or this guide could be protected, cleaned up and replace it - either works, that could be decided here).

Previously, there has been talk here about merging with the old official install guide, and just having a single official Installation Guide. However, that didn't happen when the old guide was removed because the Beginners' Guide was (and is) too long, with too much duplication of other pages after the point where it's necessary (getting the initial network access). In order to be an "official" document, it would also have to be protected - edits by regular users would be proposed on the talk page.

The installation process now always requires network access, and the ISO ships with both a browser and an IRC client, so it's not necessary to keep so much information on this page, since we have very good coverage elsewhere that surpasses the duplication here. For example, there's no need for the Beginners' Guide to explain how to do an upgrade as Pacman#Upgrading packages has much better coverage of the gritty details, and the initial install is already fully upgraded.

-- thestinger (talk) 21:52, 28 October 2012 (UTC)

Yes, the ISO comes with a browser (elinks), but it's not very good with formatting. Some people may prefer to actually print the guide (which is a waste of paper, if you ask me, but old timers may feel differently), or save it as a PDF/HTML and read it on whatever device they own (smartphone, tablet, etc).

No need to create a section for this, just reminding that the unification would affect FS#36111. -- Kynikos (talk) 06:57, 18 August 2013 (UTC)

Define scope of the guide

I'd like to define the scope of the guide(s) better and whether it's OK to remove certain things from the wiki instead of marking them as 'the old way' and maybe moving them to a separate article, if needed. Currently the beginners' guide still has info related to initscripts, like setting the timezone, but the article on time has not. -- Karol (talk) 09:56, 30 October 2012 (UTC)

Right now the Beginner's Guide is "A page where user can get their system installed without reading other pages". This is where the duplications come from. Maybe we can redefine it. So we can:
# Improve Help:Reading. Add some guide about Navigation, Searching, Category and Table of Contents. So users can reach the information they want more easily.
# Reduce long duplication texts. The two network configuration part is a candicate. -- Fengchao (talk) 07:46, 31 October 2012 (UTC)
The reason for using the manual way of configuring is actually because timedatectl and friends won't work from inside a chroot. We could avoid that by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all) but that would require some minor restructuring, so it's something worth discussing. thestinger (talk) 17:28, 3 November 2012 (UTC)
[This comment was pasted here from a different, now deleted discussion]
I think that the goal of the Beginners' Guide is not only to let an Arch novice install the system successfully, but also to introduce him to how an Arch Linux system is structured and the technologies it's based on: we shouldn't think of the Beginners' Guide (or any other article) as a simple howto or step-by-step guide, but as something more formative. -- Kynikos (talk) 15:40, 19 September 2012 (UTC)

Plan

If someone was interested and had the time to lay out here a detailed plan with indications on where to merge every section of the guide and a report of all the problems that could be encountered in the process, it would definitely be the final step before announcing the unification on the forums with full support from the admins, which would mean that at that point only strong and reasonable objections could prevent the unification. -- Kynikos (talk) 06:44, 18 August 2013 (UTC)

Here is a list of sections that should be merged. Feel free to expand, comment in #Comments. -- Lahwaacz (talk) 18:26, 31 August 2013‎ (UTC)

General problems

  • Make effective use of links so that at most two clicks are required to find the right section.
  • Swap is recommended in most cases. [5]
  • Use Tab more in instructions?

Comments

Installation template

Another alternative way to unify the two main guides would be to follow the same philosophy we used to write the scenarios in Dm-crypt_with_LUKS/Encrypting_an_entire_system, originally discussed in Talk:Dm-crypt#New_idea: the new installation guide could be a bare, though complete, list of commands and simple instructions needed to install the system in one example scenario, with links to the various relevant articles for detailed information and adaptations to specific cases. -- Kynikos (talk) 21:18, 27 March 2014 (UTC)

Well, the Beginners' guide suffers from issues related to both content and style, and I really think they need to be addressed at the same time. Every suggestion so far deals only with one problem.
Content: I agree that the purpose of the guide (be it Beginners' or Installation) should be to describe only one scenario and provide links to other articles describing the alternatives. I really like this part of your suggestion, but it solves only half of the problem.
Style: The biggest problem is that Beginners' guide is unique mixture of introduction to reading ArchWiki and introduction to installing and using Arch Linux, which are simply inseparable in the context of BG - you just can't expect newcomers to first read Help:Reading and only then start installing their system. So, there is a little bit of anarchy, as the BG is mostly excused from the style guidelines and there are no guidelines specifically for the BG. Unifying the two guides would necessarily mean a compromise regarding style, which would not be the best for either beginners or gurus.
Also, I think that it is a good thing that BG is readable without reading other pages (as defined in #Define scope of the guide), because it implies that the most important things have been collected and the readers don't have to click-and-search too much. This is really important for the newcomers, because the orientation in the graph of internal links (I wanted to visualize the graph, but it's just too big) is really difficult - they would need to read dozens of pages (with some alien style applied) before they had the basic system running. On the other hand, one of the main points of BG should be to prepare the readers for other ArchWiki articles, but sometimes the readers are too spoiled.
Well, that is my defence of keeping both IG and BG. In my opinion it is enough to just properly define the scope of BG and trim it down to ease the maintenance, addressing the content part. But of course if there is a suggestion on merging the two guides addressing the style issues, let's hear it!
-- Lahwaacz (talk) 11:16, 30 March 2014 (UTC)
About the style issue, I don't think experienced users would be so bothered by some pacman, systemctl or nano examples, and the unified guide should probably explicitly warn users that they won't find similar examples in the other articles, which would be a perfect way to invite them to become familiar with pacman, systemd, Help:Reading... Besides, if the guide will be properly structured, experienced users who don't have their own custom installation notes will be able to just follow the automatic ToC as a memory refresher.
I disagree that the fact that the "BG is readable without reading other pages" is a good thing, as that's exactly the reason that makes it hard to maintain and encourages duplication of information; if users were used to follow links instead, most of the efforts now spent in improving the BG would be instead spent in properly improving the linked articles, which would then become as easy to follow as the BG is now.
Anyway, I've proposed a change in #Comments (under #Plan) that I think should be more likely to reach general consensus, and that would already be a good step forward.
-- Kynikos (talk) 03:35, 31 March 2014 (UTC)
I'm beginning to understand the need for merging. After the BG is slimmed down to cover only one example scenario, the title will be just wrong and the scope will be exactly the same as for IG. It all depends on whether different target audience and related style differences are enough to justify two guides.
I hate being the blocker, so let's slim down BG and when it comes to the point of merging with IG, at least it will not be so shocking. I can't help but to think about it as simple redirecting of BG to IG, which will be (more or less) the eventual outcome, so I will need some time to absorb.
Finally, we should also look at ArchWiki:Requests#Cleanup: installation category, so that Category:Getting and installing Arch is actually useful for providing alternative scenarios, and to ensure there is a place where to move excessive information from the BG.
-- Lahwaacz (talk) 07:35, 7 April 2014 (UTC)
You are not "the blocker", every opinion is as valuable as the others if well argumented, be it for or against the proposal. Especially in this case where we seem to be the only 2 people interested in discussing...
If the unification will eventually be completed, of course the BG will become a redirect to the IG, and the latter will be unprotected (and well watched so it's not turned again into a BG).
Let's go on with the change very gradually, that's definitely the best way to let everyone successfully and happily adapt to the new way of following the document, which, if done properly, will be even easier and clearer (no need to compare two guides anymore, just to mention an advantage).
Of course ArchWiki:Requests#Cleanup: installation category is strictly linked to all this, I'll try to get there too.
-- Kynikos (talk) 05:26, 9 April 2014 (UTC)
Just as a note, Category:Getting and installing Arch has since made great progress, and replaced most of the "introductory" content in the BG. :) [6] [7] -- Alad (talk) 00:21, 18 September 2015 (UTC)

Page protection

I personally would suggest leaving the Installation guide locked after the merger (even if that would lock me out also :). Thing is, if someone went through the effort of researching an addition to the guide, it would be easy for them to bring it up here, in the talk page, and easier for the community to discuss (and implement, if applicable).

Leaving the Installation guide unprotected however would make it open to hasty edits. Even if the IG were well watched as said, a made edit's context may not be sufficiently clear to "judge" it on the spot (confirmed by ArchWiki:Reports). Having contested content remain (however short) on the main, "official" installation reference is less than ideal.

A compromise may be similar to the IRC page, which is not protected in the technical sense, but has a warning urging users not to edit the page without prior consensus. -- Alad (talk) 23:30, 19 February 2015 (UTC)

Once upon a time, I absolutely don't even remember where, we even discussed the option of keeping the guide in a protected page, but do all the modifications in a separate open page (as if they were two "master" and "devel" branches), with the admins periodically approving and merging the unstable page into the official one. Thanks to the recently introduced Special:MergeHistory tool, this job could be easier nowadays. — Kynikos (talk) 14:06, 20 February 2015 (UTC)
That sounds like a good option. Working hypothesis: to make users accustomed to the idea, we could now add a note at the top of the BG, suggesting to first discuss changes on the talk page. After the merger this note would then point to the "development" page. -- Alad (talk) 20:39, 16 March 2015 (UTC)
I think that Special:MergeHistory is too primitive tool for this, AFAIK its only way of operation is "merge all revisions up to specified one", i.e. there is no cherry-picking of feasible revisions. -- Lahwaacz (talk) 20:50, 16 March 2015 (UTC)
@Alad I'm still thinking about it, I'm not sure whether having 2 protected installation guides would be too confusing. The branch method would certainly be well suited if we really ended up merging the guides into one.
@Lahwaacz The way it would work would be (master is protected, contains the whole revisions history and will not receive direct edits by anyone, including admins):
  1. develop is initialized with a simple copy of the latest revision of master
  2. Some users make some edits to develop
  3. The wiki staff amends/undos develop as necessary with additional edits (like it happens now in the only branch)
  4. Once develop is considered in a good state, Special:MergeHistory can be used safely, no need for cherry-picking
  5. Go back to 1 (at this step develop is a redirect to master)
Kynikos (talk) 13:09, 17 March 2015 (UTC)
A simpler alternative with the same effect would be maintaining a link that points to the latest officially approved revision in the history of the article, for example in a Note in the intro. — Kynikos (talk) 13:13, 17 March 2015 (UTC)
Take your time, it will take a lot more work to get the BG anywhere near ready for merging. A link with note sounds viable as well; we could add a table with different options below. -- Alad (talk) 22:08, 17 March 2015 (UTC)
To add another suggestion, the Talk page of both guides works well in implementing and discussing changes, when used. Often, you see remarks scattered throughout IRC and the forums. As such, we could expand the scope by opening a new thread in the forums, e.g "The Installation Guide thread" and ask it to be made sticky. -- Alad (talk) 17:25, 27 August 2015 (UTC)
We could even suggest users to make a (partial) copy in their user pages to propose their changes. -- Alad (talk) 10:11, 31 August 2015 (UTC)
"Everyone could edit the page" defines Wiki/ArchWiki. Be very careful when we want to change that.
If random edits become maintaince burden, then we could protect it. But keep in mind the protection will definitely prevent some contributions to happen. Installation guide is protected and sometime it got out of date.
So my suggestion is adding a note like: This is a highly visited page so please discuss any change in talk page first. If it does not work, we could change to a more strict method.--Fengchao (talk) 10:32, 23 January 2016 (UTC)
We've tried something similar (albeit in a weaker form) in AUR#Sharing_and_maintaining_packages, and it didn't turn out as well as expected: [8], e.g. [9] -- Alad (talk) 10:56, 23 January 2016 (UTC)

Linked to 'parted' Manual doesn't list ext3 or ext4 for fs-type

Hi guys. Recent Arch convert here. Loving it. No bloat! Noticed this during Beginners Guid install though:

In the section on using parted ( Beginners'_guide#Partition_schemes ), it links to the Gnu parted manual at http://www.gnu.org/software/parted/manual/parted.html#mkpart for fs-types, but the (rather dated?) manual doesn't list ext3 or ext4. At this point I 'guessed' ext2 was the right choice... Only to find that LATER in the 'Beginners Guide' page it recommended ext4. Damn! Wasn't sure if I had to go back and re-do. Seemed not. But anyway, confusing for 'Beginners'. Anyway, dare not edit the wiki being an Arch noob at this point. Keep up the good work! Cheers. -- Peterg4000 (talk) 00:53, 7 April 2015 (UTC)

Yes, this is a rather confusing concept: the file system type associated to a partition is a different thing from the file system that you later use to format that partition... It's explained in a bit clearer way in Wikipedia:Disk_partitioning#PC_partition_types, but we should probably explain it better here too.
In theory, using "ext2", "ext3" or "ext4" when you use (parted) mkpart shouldn't make any difference at all, as they all set the same partition type code. What does make a difference is the file system you choose when you actually format the partition in Beginners'_guide#Create_filesystems.
Of course it's wise to make sure the fs-type corresponds to the file system that is going to be used, but even though I've never tested it, I guess you could use e.g. "NTFS" for fs-type and still be able to format the partition with ext4 or whatever file system you want.
Kynikos (talk) 13:49, 7 April 2015 (UTC)
Oh, so for ext3/4 one should just set fs-type to ext2 in parted (etc). Lesson learnt. A one liner would be good saying something like "If you don't know any better, set fs-type to ext2 (Which is the correct option for ext2/3/4), and then format with ext4 below." -- Peterg4000 (talk) 23:32, 7 April 2015 (UTC)
We needed something more generic and educational, I've added [10], I hope it's clear enough, please re-open the discussion if it's not :) — Kynikos (talk) 07:17, 8 April 2015 (UTC)
Looks great. Loving the Arch way, community, Wiki etc. Cheers. -- Peterg4000 (talk) 08:49, 8 April 2015 (UTC)
Actually, parted 3.2 has an explicit label for ext4:
(parted) help mkpart                                                      
  mkpart PART-TYPE [FS-TYPE] START END     make a partition
...
        FS-TYPE is one of: btrfs, nilfs2, ext4, ext3, ext2, fat32, fat16, hfsx, hfs+, hfs, jfs, swsusp, linux-swap(v1), linux-swap(v0),
        ntfs, reiserfs, hp-ufs, sun-ufs, xfs, apfs2, apfs1, asfs, amufs5, amufs4, amufs3, amufs2, amufs1, amufs0, amufs, affs7, affs6,
        affs5, affs4, affs3, affs2, affs1, affs0, linux-swap, linux-swap(new), linux-swap(old)
...
If they are all mapped to the same partition code is another matter, so I'm fine with the current wording. Alternatively we could leave out FS-TYPE completely, after all it is optional (but this is not reflected in the BG).
-- Lahwaacz (talk) 14:41, 8 April 2015 (UTC)
Do we want to reopen and investigate this further? Thanks for reminding of the help command, however I can find many sources that seem to confirm that many Linux native file systems (but not all of the above!) map to 0x83: [11] [12] [13] [14] [15]. Unfortunately, as Wikipedia:Partition_type#Overview says, these codes are not standardized, so we won't be able to find an official reference. Last thing, quoting the manual, " fs-type is required for data partitions (i.e., non-extended partitions)", so I wouldn't leave it out as optional. — Kynikos (talk) 09:46, 9 April 2015 (UTC)
The clearest would either be mkpart primary linux or mkpartfs ext4 but I doubt either is supported... -- Alad (talk) 12:47, 9 April 2015 (UTC)
I doubt too, I've replaced the link to the manual with "help mkpart". — Kynikos (talk) 13:21, 10 April 2015 (UTC)
I wasn't sure where to put this as I'm also new and it's really minor, but also in the parted section when making partitions it says to put 'm' for MiB, this should probably be updated as in my install just 'm' set my sizes to MB not MiB. Suggest updating or preferably instructing the user to define units when entering parted: so set units MiB or GiB or whatever so that just numbers can be used afterwards in creating partitions.Jjex22 (talk) 05:04, 27 August 2015 (UTC)

Replace parted with cfdisk/cgdisk

So, just wanna throw this out there for discussion. I've always found cfdisk/cgdisk to be much more beginner-friendly and intuitive than parted. Since this is the "Beginner's Guide" wouldn't it make sense to recommend using these tools? At the very least, it might be good to mention that they are visual partitioning tools when they are listed in the "partitioning tools" section. Thoughts? -- A Future Pilot (talk) 14:21, 13 July 2015 (UTC)

Related: [16]
I personally wouldn't mind revisiting the topic on fdisk vs. parted (unsure on the benefits of cfdisk or cgdisk - they're not "visual" besides a more-or-less clunky table format, and fdisk has a print switch). This however implies merging Parted content to parted as mentioned in #Plan. -- Alad (talk) 14:53, 13 July 2015 (UTC)
This could be done. The recommendations were different in the past:
are just a couple of examples. -- Chazza (talk) 15:17, 13 July 2015 (UTC)
I personally also favor (c)fdisk. I think it both are very clear for beginners, and they can handle both MBR and GPT (no need for (c)gdisk).
In any case, I think we should choose a tool which can handle both GPT and MBR partitioning schemes, because otherwise things will get messy again. This is one of the reasons why we changed to parted: it supports both (and back then, there was some question about the stability of fdisk's GPT support, but I'm sure it is fine now; I've personally never has issues). Lonaowna (talk) 17:14, 13 July 2015 (UTC)
This is obviously too subjective from those being used to one specific tool. I personally find parted to be easier to understand because you write the whole commands instead of just a couple of meaningless letters. Granted, all tools have a help page built in, provide a detailed man page and there is a bunch of "tutorials" for every possible scenario. So, is it even possible to select the "most beginner-friendly" tool or should we decide based on different factor? In any case, there should be only one tool described in detail in the BG and alternatives should be linked to. -- Lahwaacz (talk) 17:23, 13 July 2015 (UTC)
I agree with your last point, that there should only be one tool described in the BG.
But I cannot see how we can choose one on other criteria than "beginner-friendly", as all candidates should be able to provide the same functionality. What other factors are there to decide on?
The only I can think of is that fdisk (util-linux) is in [core] and base, and parted is not. But both are on the installation ISO, so I'm not sure if that matters at all.
I am afraid that there is no real criterion to decide by, except for "beginner/user-friendliness", which is indeed subjective. Lonaowna (talk) 21:22, 13 July 2015 (UTC)
We could circumvent the issue by adding detailed examples to the articles in question, rather than describing one particular tool in the BG. In addition, we could add a few sentences outlining basic differences between the tools. -- Alad (talk) 10:09, 14 July 2015 (UTC)
As said, the BG switched from fdisk to parted only a few months ago (which in wiki terms means "yesterday"), so we can't keep going back and forth like in a loop. At this point, I support Alad's proposal above to move the examples to the specialized articles, which also goes in the #Unification direction (and this discussion itself is yet another argument in support of that plan). — Kynikos (talk) 11:49, 15 July 2015 (UTC)
I would like to concur with Alad and Kynikos on this. It should be up to the user to choose the appropriate tool, and the information from the BG should be merged into the GNU Parted article, which keeps the BG moving towards #Unification. Pid1 (talk) 22:50, 25 July 2015 (UTC)
As proposed in Talk:Partitioning#remove_gdisk_instructions_for_install_medium_2013-11, I've split fdisk: if the BG will become partitioning-tool-agnostic, that article will have to be improved as well. — Kynikos (talk) 04:13, 29 July 2015 (UTC)
A restructuring of fdisk is being discussed in Talk:fdisk#Plan. — Kynikos (talk) 03:00, 2 March 2016 (UTC)

"See foo" vs "See the foo article"

This revision [17] added a new mention of "See the foo article", rather than the more common "See foo". I'd argue former is the better form, and when the guide is viewed from a .txt (if the BG/IG merge completes), the longer wording makes sense as well. Are there opinions against using the longer form throughout the BG? -- Alad (talk) 00:13, 18 September 2015 (UTC)

I'm neutral, so that doesn't count as an opinion against ^^ That said, the long form can only be used with links to entire articles, but more difficultly with links to specific sections such as "See also Pacman#pacman crashes the official installation media", since in those cases a more natural-sounding long form should be something like "See also the 'pacman crashes the official installation media' section of the Pacman article", I think, which is clearly ugly to see and use, so consistency is a bit hard to reach. — Kynikos (talk) 16:13, 18 September 2015 (UTC)
I guess the proper solution would be to incorporate links in the article text where possible. "See X" gets repetitive fast, anyway. -- Alad (talk) 14:44, 29 September 2015 (UTC)

General troubleshooting

Perhaps we should reword:

The community-maintained ArchWiki is the primary resource that should be consulted if issues arise.

to include a link to General troubleshooting? It's already in the related articles, but it can't hurt to feature it even more prominently. -- Alad (talk) 20:30, 12 December 2015 (UTC)

I wouldn't have particular problems with that, however if we could trust people to actually follow links, that whole second paragraph in the BG intro could be moved into General troubleshooting, and replaced with a link to it. Also, I've proposed some modifications with status templates in that article. — Kynikos (talk) 04:04, 13 December 2015 (UTC)
Edit: I didn't notice that you had just moved part of Boot debugging into General troubleshooting: as that does go in the direction of reducing the number of links to follow to find info, I think linking to General troubleshooting from the intro of the BG is consistent with it, although I don't know how much it is in the spirit of #Unification. — Kynikos (talk) 04:20, 13 December 2015 (UTC)

Warning about mounting efivars writable

I feel that there should be a warning about making efivars mounted as writable by default, that warning should be exactly as given in the [18] and then a link to the [19]. I'm not sure exactly where should the post go though. —This unsigned comment is by Jayeshbadwaik (talk) 18:13, 1 February 2016‎. Please sign your posts with ~~~~!

Making your efivars partition read-only, when you have to write to it for the installation, is not an installation instruction. This article is strictly limited to latter (it doesn't even instruct to create a regular user account).
Also, UEFI#UEFI variables is linked right at the beginning of the guide - the warning is just a few paragraphs down. No point in duplicating it here. -- Alad (talk) 17:37, 1 February 2016 (UTC)
Perhaps not, but the edit I made did provide some context in the warning box which given the potential severity of the situation, should be noted. Do you disagree? Graysky (talk) 20:52, 1 February 2016 (UTC)
This isn't the only thing that can go wrong with UEFI systems, as indicated by the warning at the very top of UEFI. If anything, we can add a sentence right below Beginners' guide#UEFI mode, saying that people with UEFI systems should investigate the potential risks involved. And preferably as part of the regular text. -- Alad (talk) 20:55, 1 February 2016 (UTC)

localectl

I like [20] plus references, but maybe we should think on replacing the localectl command, the Installation guide doesn't have it either. -- Alad (talk) 01:02, 7 March 2016 (UTC)

I agree with replacing it. To make it more readily usable, what about find /usr/share/kbd/keymaps/ -type f -iname "*.map.gz" -printf "%f\n" | sort | less? — Kynikos (talk) 02:39, 7 March 2016 (UTC)
Eh.. that's a bit long to type, isn't it? :) Maybe just find /usr/share/kbd/keymaps/, and mention files end in .map.gz. -- Alad (talk) 10:12, 7 March 2016 (UTC)
The sort would be nice to at least have the list in an alphanumerical order, right? --Dettalk 20:09, 7 March 2016 (UTC)
In order for sort to work, you should leave also the printf option, but then we're back to the hard-to-type one-liner ^^ (even though the -type f could be omitted in any case)
I was actually thinking of scenarios where copy-pasting is possible, but Alad is right, we can't assume that, so I agree with suggesting the plain find command.
If possible I'd like to keep a reminder about the localectl alternative though, with a link to an active bug report, that's why I've asked on FS#46725 if the bug has been reported to the overlayfs devs, as Lennart said it's their problem.
Kynikos (talk) 07:32, 8 March 2016 (UTC)
Why not find /usr/share/kbd/keymaps/ | grep "map.gz"?--nTia89 (talk) 18:15, 8 March 2016 (UTC)
Why not ls /usr/share/kbd/keymaps/**/*.map.gz? The full path might be more useful than sorting by base name, because it provides basic categorization which is not always clear from the base name (i386/mac/sun, qwertz/qwerty/dvorak etc). -- Lahwaacz (talk) 19:31, 8 March 2016 (UTC)
The zsh globbing way is better indeed, my vote shifts there. — Kynikos (talk) 03:09, 10 March 2016 (UTC)
So, the bug has been reported to the kernel developers, linked from FS#46725.
The idea to update the command wasn't mine, but after 10 days I thought I'd implement it :)
Closing. — Kynikos (talk) 02:36, 20 March 2016 (UTC)

pacman-key --populate

Moved from User_talk:Alad. -- Alad (talk) 21:03, 11 March 2016 (UTC)

Reference: https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=next&oldid=411670 I tried to install Archlinux on my new computer and got stuck. Only using the pacman-key --populate archlinux helped me. I think I am not the only one having this problem. But why did you undo it? —This unsigned comment is by Sandstorm (talk) 20:38, 12 December 2015‎. Please sign your posts with ~~~~!

This command is already run for the new system (by installation of archlinux-keyring), so running it by hand shouldn't be required for most users. Of course, things can go wrong (how old was the ISO you used to install the system?), but that belongs in Troubleshooting sections of the respective articles, which are linked at the beginning of the guide. -- Alad (talk) 19:52, 12 December 2015 (UTC)
I had downloaded the ISO just yesterday, minutes before the install. Only that command installed the keys. Probably I should open a bug if you can confirm the issue?
Did you have to run pacman-key after, or before pacstrap? And do you recall what the error messages said exactly? (See also FS#31286) -- Alad (talk) 20:15, 12 December 2015 (UTC)
I had to run after pacstrap. As far as I remember, pacstrap stopped after trying to download the keys. The error message was something like shown in this forum post: https://bbs.archlinux.org/viewtopic.php?id=165367
Well then, as you suggested, I'd open a bug report. -- Alad (talk) 20:34, 12 December 2015 (UTC)
Done. Could you check if the description is good. I could not find an appropriate category, so I though Packages:Core might be the closest one. https://bugs.archlinux.org/task/47351 --Sandstorm (talk) 20:48, 12 December 2015 (UTC)
Thanks, the description looks OK. If the category e.a is not right, User:Scimmia should fix it. :P -- Alad (talk) 13:59, 13 December 2015 (UTC)
Hmm, looks like it was closed with "Works for me" ... not very enlightening. All I can suggest is to further improve on Pacman/Package signing and related articles, and recheck if they're accessible enough from the Beginners' guide. -- Alad (talk) 21:59, 12 February 2016 (UTC)

setting root password

It's currently under "Unmount the partitions and reboot". Maybe it should be under "Configuration"? — User:Rdeckard

This is the edit that moved it there. In the Installation guide it's under #Configure_the_system though, so for consistency I vote for moving it back until #Unification finally takes care of it. — Kynikos (talk) 02:53, 20 March 2016 (UTC)
I'm not fond of the extra header, but that's not a very good reason. Reverted with [21] -- Alad (talk) 12:32, 20 March 2016 (UTC)
Thanks, closed. — Rdeckard (talk) 13:16, 20 March 2016 (UTC)

Confusing part about mounting EFI partition

I'm a beginner and the very last part of section Format the file systems and enable swap is really confusing. Do I have to mount EFI partition? If I made EFI fat32 boot partition on sda1 then something like this?

mkdir -p /mnt/boot

mount /dev/sda1 /mnt/boot

If this is not the case. Could someone more knowledgeable than me add a sentence or two that this is not needed. It's really confusing for beginner. skmlcd (talk) April 14, 2016 (UTC)

Yes you do have to mount it, and you can mount it at /boot just as you indicated. Rdeckard (talk) 01:07, 15 April 2016 (UTC)
Added [22]. Not pointing to /mnt/boot was creating the confusion I think, since the iso itself has a /boot mount. --Indigo (talk) 06:53, 15 April 2016 (UTC)
Thanks for edit. It is much more clear now. skmlcd (talk) 8:01, April 15, 2016 (UTC)
Closing. Feel free to re-open if there is more discussion. -- Rdeckard (talk), Maintainer 14:59, 19 April 2016 (UTC)

Wouldn't it be easier to use nmtui right away for wireless configuration?

So far seem like most straight forward choice for a newbie. It simulate a GUI and steps are self evident. JustLikeATree (talk) 00:50, 24 April 2016 (UTC)

nmtui (from networkmanager) isn't on the ISO. -- Alad (talk) 01:02, 24 April 2016 (UTC)