Talk:Beginners' guide

README

1. Make all editing suggestions here.
2. Keep discussions civil and productive.
3. Add the <s> </s> tag to the specific discussion subtitle when it is closed and (if possible) add it to the bottom of the page.
4. Keep the KISS principle in mind.

-- Misfit138 15:23, 22 October 2009 (EDT)

-- wget 17:10, 04 August 2013 (UTC)

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

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)

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)

Unification Status?

Hello,

Is there any forward motion on unifying or cleaning up the Installation Guides? I would like to lend my hand if or when I earn that ability.

Both my fiancee and I have recently completed installs of Arch Linux and found ourselves hopping back and forth between the official installation guide and this Beginners Guide. Short of unification, synchronizing the steps would be a huge boon for those that utilize the resources in a similar manner.

Cheers, AdamT (talk) 03:35, 24 July 2013 (UTC)

While it's more work and kind of a mess sometimes with 2 Guides, if those 2 are well maintained it has the advantage to serve distinct target groups well. If you where to merge into one, i fear you'd either annoy the expierienced Users with unnecessary fluff, or if you cut too much info out of it you'd leave the newbies with open questions.

Another system would be, have one guide, and on specific topics links to article which will explain those well. But then you would have to but all the verbose-newbiew "explain everything" information into those subarticles. I don't think it would be a better system.

One thing which i don't like about current state of the Beginners Guide, in some places there is some quite advanced info/adviced included which is only relevant in niche-scenarious. I think those should be moved into the specialized articles on a case by case basis.

What do you mean when you say "synchronizing the steps"? How would this look like?

Bwid (talk) 08:22, 24 July 2013 (UTC)

Hi Bwid,

I should have clarified with regards to synchronizing the steps between the Beginners' Guide and the official Installation Guide. Simply put, the Beginners' Guide completes the installation with steps ordered differently than the Installation Guide.

Examples:

• Connecting to the internet
  • Beginners' Guide Section 2.2
  • Installation Guide Section 2.5
• Configure the System
  • Installation Guide Section 2.7
  • Beginner's Guide Section 2.8
    • Under which the steps are differently ordered compared to the installation guide.

Going back over this, it does seem a little trite, but if we are going to maintain two separate guides keeping them as close as possible in terms of process seems to be the simpler choice. I am not saying they need to have the same section numbers (though where feasible, that would be ideal I should think), just flow in the same order from start to finish.

There is something that strikes me as being distinctly not in keeping with The Arch Way with regards to keeping two separate guides. With that said, assuming for a moment that two guides are a necessary evil, it further seems to go against simplicity by keeping redundant information in the Beginners' Guide that could otherwise be put (and should be put or at least duplicated in my view) in the subject specific Arch Wiki articles so that people that are not just installing, or that may not consider themselves beginners might benefit from the information as well.

It does not need to be novice user centric, it does not need to be verbose. The sub-articles just need to provide the information that is necessary to properly address a given subject with regards to Arch Linux, which is the point of the subject specific articles as it is. Comprehensiveness is listed as a goal for the Arch Wiki so this should not be something that is feared (ArchWiki:About#Comprehensive).

This linking to relevant articles is exactly what the official Installation Guide does, and finding subject specific articles is a skill needed post-install for anyone that continues to use Arch Linux.

Anyway, I do not intend to talk this to death or to become hyperbolic, this just seemed to have fizzled and I was curious as to its current state. If people are happy with the current state of things regarding the installation guides that works for me I shall focus on other articles! : )

Cheers!

AdamT (talk) 18:20, 24 July 2013 (UTC)

Actually i think its good that you brought the topic up again. I was wondering along the same lines a while again. Is it worth it spending time working on restructuring the guide when the the thing might be done away with soon? Also don't take my rationalization of the 2 Guides as some sort of common opinion, i am sure there are many who agree that the Beginners Guide shouldnt duplicate Install guide, and even I am not sure about if what I wrote above is true. If the decission is that the BG should be repurposed, and instead the articles which are linked from IG improved then i would be fine with it.

Bwid (talk) 19:02, 24 July 2013 (UTC)

Technically yes, having only one slim installation guide that links to specific articles is the solution supported by thestinger and me (although with slightly different opinions on some things like protection of the article), and IIRC I've never read a word against the idea from other admins.

IMO the only big problem that's still holding us back is that we're playing with what's arguably the most visited article of the wiki, which is sometimes seen as kind of a trademark from outside, so everybody (including me) is hesitant about making the final decision that will definitively kill it. Maybe, and I say maybe, we should discuss this on the forums, where we would get many more responses, although a big part of them would probably be against the merge, as many new users do like having as much information as possible in one article without having to click on links. -- Kynikos (talk) 13:02, 25 July 2013 (UTC)

Bwid & Kynikos,

I appreciate both of your well reasoned responses. If the time is worth investing, perhaps putting together a third, unified option and then presenting the three on the forums (or however the admins would like) would provide a concise comparison which the community at large could form an educated opinion and decision from?

AdamT (talk) 21:47, 25 July 2013 (UTC)

Sorry I'm not following, what would be the third option? :) -- Kynikos (talk) 04:54, 27 July 2013 (UTC)

Kynikos,

No worries. The third option would be a "unified guide" that we could create without removing the existing two (the official Installation Guide and the Beginners' Guide) so that a direct comparison could be made between the existing guides and our proposed unified guide. This would allow the admins to bring the guides before the greater community for a vote on which to use (the current two guides or a singular unified replacement). The risk with this plan is the potential for wasted time in creating a guide that may not ultimately be used. We should also probably commit to deleting the third guide if the community votes against it so as not to make the current situation worse with a third unofficial guide. :)

I hope this makes my idea clearer.

Take care,

AdamT (talk) 18:55, 27 July 2013 (UTC)

I don't think this third option is feasible without affecting the other two guides, in fact the big part of this whole unification is moving content from the Beginners' Guide to the various specific articles, and the third option wouldn't make sense if we don't do that. -- Kynikos (talk) 11:14, 29 July 2013 (UTC)

The transclusion way

I agree with the idea to create a guide for all users. For newbies, the fastest way to achieve the installation step should be written explicitly. Alternative/advanced ways (e.g. other bootloaders instead of the default proposed gummiboot for uefi bootloader) should be put in a dedicated article (to take the same example, the Bootloader article --> this article could even integrate the introduction section of grub for example. --> We will have recursive inclusions).

In order to avoid duplication and avoid too much maintenance efforts, we could use the MediaWiki's transclusion method, which embeds section of internal wiki pages into the current one (a dedicated extension exists to provide even more advanced inclusions possibilities). In that way, we maintain all the dedicated pages and include some of their sections to the unified install guide. Pay attention to don't broke the links when editing the dedicated articles. In that way, we will satisfy both kind of users: the advanced ones and the newbies.

• The advanced ones will check the advanced pages when skimming the unified installation guide. For these users the guide will be like a memento (the current Installation Guide is thus not needed any more).
• For newbies, it will be a beginner guide which will offer the availability to learn further by reading the linked pages.

Example:

Install guide

5. Add a bootloader
<Include introduction section of the bootloader article: what is a bootloader>

Use the recommended one for UEFI:
<Include standard/easy install section gummiboot install>

etc.

-- wget (talk) 17:57, 4 August 2013 (UTC)

Um I thought of this possibility myself a while ago, but then discarded it because it would make maintenance even more difficult, as when editing one of the transcluded articles it should always be taken into account any consequence on the "long" article; in the end, it looks too complicated to me. -- Kynikos (talk) 11:50, 5 August 2013 (UTC)

This is the reason I wrote "Pay attention to don't broke the links when editing the dedicated articles.". But I think applying this method is the best way to avoid duplication efforts. Take the following example. A guy: "It would be great if we add this new useful tool to establish a wi-fi connection to the beginner guide", another guy checking/watching the network page won't be informed and cannot bring its experience as he won't be informed about these changes written in the install guide.

If you're a developer you know what I mean when I say page inclusion is the BEST way to avoid duplication ;-)

- wget (talk) 12:52, 5 August 2013 (UTC)

One big problem I foresee with this method is that we still should maintain two separate installation guides: they should contain the same instructions, but one should contain links to the relevant articles, while the other should transclude the needed article sections; this means this method wouldn't avoid duplication completely :) I still think the "links" way is the simplest and most efficient. -- Kynikos (talk) 14:27, 6 August 2013 (UTC)

+1 for links. Based on my old experience, inclusion increase maintenance efforts, you need to consider both pages when editing. And what is worse, it make it harder for new users to contribute because change in one place may influence another page they do not know well. Let us keep it simple :) -- Fengchao (talk) 13:23, 11 August 2013 (UTC)

Merge two network config sections

In my opinion the network configuration section is no longer correct and it should be replaced with the correct section from this page. At least, the static IP configuration section does not work for me. This is probably caused by the switch to systemd. --Doru001 (talk) 16:49, 29 January 2013 (UTC)

Most of this section is a repeat of info already presented earlier in the guide (most notably in 3.1.1).

I understand that directing users to 3.1.1 when they've already got a system up and running isn't that great of an idea since they are no longer in the live environment and some things are different (but not much!), but surely something can be done to reduce the redunancy (especially on the 4.1.2 Wireless LAN section, which is basically a 1:1 copy of 3.1.1.2) Xgamer99 19:49, 8 January 2011 (EST)

Went ahead and made the edit, as I can't see anything wrong with it. Please let me know if you disagree. However, I still believe that 4.1 should be re-worked and merged with 3.1.1, and just have 4.1 direct users to it. The only thing that would need to be added is the Proxy settings and manual wired connection (installer handles wired connections flawlessly, so manual activation isn't covered in 3.1.1). Xgamer99 04:00, 9 January 2011 (EST)

Reopen this discuss. Those two network configuration section still exist. They should be merged. -- Fengchao (talk) 10:16, 1 August 2012 (UTC)

There are Beginners'_Guide#Establish_an_internet_connection and Beginners'_Guide#Configure_the_network sections. Though they are not 1:1 copy, I agree that they should be merged. -- Lahwaacz (talk) 14:34, 4 August 2013 (UTC)

Just to make sure it is clear, there are two sections because one configures the network in the live environment, the other does it in the chroot environment; for example in the first section it's not needed to enable services or netctl profiles. -- Kynikos (talk) 11:43, 5 August 2013 (UTC)

I disagree, they should not be merged. The first one is just a quick and dirty one-time setup. (As it should be.) The second one is about how to setup a network manager that provides a persistent connection. I think that merging these two will lead to more confusion. (I've already seen lots of people who do not understand that the network has to be configured twice; I think that we should explain the difference more clearly.) --Lonaowna (talk) 11:53, 5 August 2013 (UTC)

What about put this into another form: Merge common parts into Network Configuration and leave just a link here. -- Fengchao (talk) 13:25, 11 August 2013 (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)

Reloading font and keymap after arch-chroot

In the beginner's guide, after "arch-chroot /mnt" it says that we need to load keymap (loadkeys) and font (setfont) because the environment has changed... I installed Arch on a few computers so far and never did that, the keymap and font persisted even in the chroot. So maybe it isn't necessary and someone should remove that from the guide ? -- Unifiedlinux (talk) 19:00, 2 November 2012 (UTC)

Blacklisting radeon module

Installed Arch on my laptop, during pacstrap the screen went blank, pressing SPACE, CTL+C ... didn't helped only modprobe.blacklist=radeon enabled me to go through the whole installation process. My graphic card is ATI M96 aka Mobility Radeon HD 4650. I believe this info and similar problems should be added to the beginner's guide on a Installation's Issues Troubleshooting section. I believe this is important enough to dual post and separate it from the Removing "Kernel modules" talk. p.s. I may add that this is my first desktop Linux experience--Dhead (talk) 06:20, 4 March 2013 (UTC)

User management

The 'User management' section has been changed in a really bad way: The 'archie' example was removed. Now there is just a link to [user management] like in the experts guide. A newbie now is left to guess which groups he should put his user to (wheel, power i.e.) and has to search deeper before he can proceed. The old entry was much better for beginners.

Blindly telling "Newbie" to create user using -G wheel create security risk. This guide require "Newbie" to choose and install their own bootloader. Basic user and group knowledge is much easier than that. And every Arch user should have no difficulty to grasp them. -- Fengchao (talk) 02:24, 7 March 2013 (UTC)

I second the first comment in a sense. The beginner's guide should hold everything related to the installation of Arch Linux through the command line right after they (the beginner's or "newbies") have successfully booted the OS up to configuring their regular user account. And it should also include, or at least point out another page in the wiki, basic commands such as "su" and/or installing and configuring "sudo" for handling administrative tasks - CodingThoughts 20:58, 14 March 2013 (UTC)

It still covers the whole installation process, it just doesn't make assumptions about what kind of user setup you want. The guide is for all kinds of installs - servers, single-user desktops, multi-user laptops, shared workstations, thin clients, etc.

You definitely don't want to be in any groups like power or audio for a regular desktop install without a special use case. You don't need to be in a single group for using audio, video acceleration, suspending, mounting external drives, etc.

-- thestinger (talk) 02:47, 15 March 2013 (UTC)

Yes, you are completely right, I was assuming stuff. Still, I'm going to add references to su and sudo later on. I don't see how that could hurt the Post-Installation part of the guide. - CodingThoughts 11:39, 17 March 2013 (UTC)

I do remember there used to be one short introduction of sudo in post-installation. I can not recall why it is removed. However, please only add link and short introduction. Duplication of Wiki text is just like duplication of code, both of them make wiki/code harder to maintain. -- Fengchao (talk) 14:37, 18 March 2013 (UTC)

Got it. - CodingThoughts 16:31, 18 March 2013 (UTC)

Setting hostname

Why don't we use hostnamectl set-hostname <hostname> for setting the hostname? I'm not sure what the advantages are but I guess the program exists for a reason. -- Lonaowna (talk) 17:48, 13 April 2013 (UTC)

hostnamectl differentiates pretty hostname and static hostname - basically handles special characters, see hostnamectl(1). I think the hostnamectl method is much more suitable for use in Beginners' Guide as it avoids unintentional problems (e.g. spaces in hostname). I'll change it, thanks for pointing this out. -- Lahwaacz (talk) 14:21, 4 August 2013 (UTC)

Maybe is it worth to make a dedicated page about the hostname. Indeed we can define several type of hostname in the Unix world: the static kernel one (this one), a fancy one, a dedicated to network hosts that will be used when communicating between machines.

As the install guide will be rewritten/reorganized, we could point a link to this new hostname page and add just the hostnamectl command you described below that link for newbies which don't want (or doesn't want) fancy hostname for example. -- wget (talk) 17:22, 4 August 2013 (UTC)

I justed tested this and hostnamectl doesn't work at all in a chroot... So I've reverted the edit. Sorry for not researching before posting! --Lonaowna (talk) 19:43, 5 August 2013 (UTC)

catalyst-dkms and lib32-catalyst-utils are in the AUR

Should we remove them from the guide? -- Karol (talk) 09:00, 20 May 2013 (UTC)

Well, being really extra fussy, I point out they wouldn't be the first AUR packages on the guide, see the end of Beginners' Guide/Installation#EFISTUB. I'm not even really sure if we need that table at all, which could even be considered duplicating the various linked articles.

In the end I don't have a position on this (yet), I just wanted to add some notes :P

-- Kynikos (talk) 14:29, 22 May 2013 (UTC)

Unless you want to add/merge/duplicate Arch User Repository#Installing packages into Beginners' Guide, I think it's best to avoid AUR packages. -- Lahwaacz (talk) 15:07, 4 August 2013 (UTC)

Ok, to fix this one I'd say just merge the table to Xorg#Driver installation and replace it with a link where it is now. -- Kynikos (talk) 06:26, 18 August 2013 (UTC)

Newbie here offering thoughts on what could be changed in guide

Hey everyone, I finally successfully installed arch. I know this is easy for most people, but for me it was surprisingly more than just a weekend's worth of late nights. The number one thing that I would love to propose is Archboot. I understand that this may not be eligible for the wiki since it's not an official repository. However, it did make things ridiculously easy.

Apart from that there should be a section at the very beginning explaining how to troubleshoot your own problems. Learning dmesg -HLkd and journalctl -b etc were helpful tools for me. I also appreciated learning lsblk, lsmod, ls etc from the various articles, but a quick over view of these helpful commands on this page would help newbies like myself.

Also some of the methods described can be done in multiple ways, explaining that one version of live USB / Archboot uses iw instead of iwconfig or iwlist etc is not helpful if the user is confused about whether/how they can still use the old methods and how to check which they have loaded. I finally figured all this stuff out on my own (which I probably should've! no hard feelings at all).

And lastly, the surprisingly tricky bit about "mounting" partitions that do not belong to you on a dual boot system. Ultimately for me what ended up working was knowing which file systems the others could read (esp in a UEFI system). These things can't just be "linked" to because even the pages linked to don't have the information. I got quite a bit of help from friends and google.

Just wanted to lend my first time experience. I personally was installing on a macbook air, so perhaps this might be better suited for that discussion page. However, I can honestly say that most of it can be merged together with this page. I barely (and I mean barely.) deviated from the usual archboot install for a mac. And I did it three times to make sure it was do-able.

Considering the archboot is basically the live usb wrapped in a gui (I believe?) it probably means that the two would've been quite similar for installing on a mba, and thus for macs in general. (The issues of xorg, wifi, etc, are real problems for macbooks, but I meant the general install should not require two wiki pages) Victoroux (talk) 14:01, 7 June 2013 (UTC)

Sorry! Just reading over again, and realizing that I could've saved a tonne of time if I knew the problem of "a bunch of white letters clustered on my screen" was an error I could check. It usually happened when the firmware didn't support something (in my case) but telling the user what he can do when this happens helps ease the wiki hopping. I finally, finally figured out how to debug most of my own problems and I think that is the number one thing this guide should do. No offense, but it would also lessen the load on the "newbie corner" on the forums (not that I know it's loaded or not, but less is better, right?). That way no matter what's written in the guide, if it's incorrect or leads to a bad result, the user can figure out why and what to do.. Victoroux (talk) 14:05, 7 June 2013 (UTC)

Another useful article that could be mentioned (rebooting from black screens, yay!) Victoroux (talk) 00:27, 8 June 2013 (UTC)

Edits to UEFI booting

The section on UEFI booting had been edited to exclude all mention of other boot managers and of the possibility of using a boot loader. In addition to deleting significant parts of the original explanation, the guide was not only misleading but made patently false claims. For example, it claimed that there were two options for UEFI booting when there are many. It claimed that the ESP must be mounted at /boot although this is only true if using gummiboot. (It is not even necessary to sync the kernel etc. if one uses rEFInd despite the claim above. Recent versions of rEFInd can read the kernel and initramfs from a separate boot partition.) I have corrected these claims but I have not restored the earlier coverage of grub, rEFInd etc. I have, however, mentioned that using a boot manager such a grub may work around issues with recent kernels on some machines. These changes should not be reverted. The misinformation here is creating confusion and this is coming out in the forums. See e.g. https://bbs.archlinux.org/viewtopic.php?pid=1297790.

I am also not at all in favour of the way this section has been edited. Whereas the earlier version gave an overview of the options and set up for grub and rEFInd, with links to further information clearly indicated, the current version systematically excluded mention of possibilities other than direct EFI menu entry and gummiboot. The history of the page tells its own story. Every time somebody added a pointer to alternatives in, it has been deleted. Very particular issues are now covered in great detail with no mention at all of other work arounds e.g. EFI/Microsoft/Boot/bootmgfw.efi is covered but not EFI/boot/bootx64.efi. As far as I can tell, there is no principled reason for including information about particular work arounds and hardware but excluding others. I think very specific issues should be covered elsewhere and that this page should give an overview. What it should not do is distort the presentation of the options available. I have not fully addressed this as there is obviously an issue with the way this section is being edited and that probably needs to be addressed and discussed before further work is done. For now, my edits at least indicate where on the wiki further information can be obtained and they correct the misinformation of which I am aware.

--cfr (talk) 00:31, 8 July 2013 (UTC)

I agree that the section was misleading, but it was still an improvement over the old situation. The rEFInd guide was way too complex for the beginners' guide and very error-prone. It is also almost never necessary to use a full-blown boot loader such as GRUB. While I completely agree that other bootloaders should be mentioned, I think that the two currently advertised options are enough for the beginners' guide.

I have made made a small edit to your text, as the EFISTUB example also requires the ESP to be mounted at /boot.

--Lonaowna (talk) 09:34, 8 July 2013 (UTC)

I can't really follow this discussion closely, but I've invited User:Dislikeyou to participate here. In any case from now on I want to see whoever edits the article use the Edit Summary field (the text field just above the "Save page" button): you are supposed to write there briefly what you've done and, even more importantly, why.

That said, my opinion is that the guide should only give an overview of which methods are available for booting on UEFI mobos, and link to the proper articles instead of duplicating content. At most, a couple of very quick and easy methods (beginners friendly) could be expanded just to get new users started without too much hassle, but any in-depth observations, like special cases and workarounds, should be described in that method's main article, not in the Beginners' Guide.

-- Kynikos (talk) 11:57, 8 July 2013 (UTC)

As I say in the linked thread, I really don't know how common the need for a boot loader (as opposed to a boot manager) is. Certainly I need it and certainly users show up on the forums needing it.

One view is that grub and gummiboot should be described briefly here with a link to rEFInd. This seems reasonable to me.

Another reasonable option, I think, would be to just describe the various options here and rely on links to instructions elsewhere on the wiki. I think that would also be very reasonable (and possibly most reasonable).

Either gummiboot or a direct EFI menu entry is likely to work for people not bitten by the bug but gummiboot offers more flexibility so I think it makes sense to highlight/recommend gummiboot as a first choice.

People bitten by the bug need a boot loader rather than a mere manager and I think it makes sense to recommend grub as a second choice for that reason. (None of the other options are currently considered sufficiently robust or reliable. grub is complex but it has the advantage of working fairly reliably. Most threads on the forums about EFI booting which involve the bug end up with the user succeeding with grub. If there is a less complex alternative which will work in these cases, I would definitely like to know about it.)

--cfr (talk) 23:06, 8 July 2013 (UTC)

I agree. Lets add a link to rEFInd, leave the current sections like they are and put back the GRUB section. I'll gladly do it if you agree.

--Lonaowna (talk) 09:08, 9 July 2013 (UTC)

Sounds good to me. If the result is on the long side, I think some of the special cases in the coverage of gummiboot could be moved to the relevant wiki page. I'm not sure that hardware specific work arounds should be included in the Beginners' Guide. On the other hand, if they are very common issues then it seems reasonable to include them. (I just have no idea of the proportion of readers likely to need them.)

I cannot tell from the bug report on the update of nvram entries whether that bug in gummiboot is fixed or not. I don't use gummiboot (being bitten by the EFI stub loader bug and all) so I don't know if it is a live issue still or not. (The bug was reopened but the comments suggest a configuration error was confused with the bug in that case. I'm not completely clear about it, though.)

--cfr (talk) 01:01, 10 July 2013 (UTC)

Done, GRUB is restored. The large troubleshooting note still has to be moved to a more appropriate place such as UEFI Bootloaders, but I'm not sure where to put it. Any help would be appreciated.

--Lonaowna (talk) 10:00, 10 July 2013 (UTC)

Alternatively there's Unified Extensible Firmware Interface#Troubleshooting; you may even create UEFI Bootloaders#Troubleshooting. -- Kynikos (talk) 07:06, 11 July 2013 (UTC)