About

Merge two network config section

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)

wireless set up for wpa

1.) One needs in addition the global option for wpa_supplicant configuration file:

here is the quote for original wpa_supplicant wiki

Global options

Lastly, you will need to specify some global options.
Specify these additional lines at the top of /etc/wpa_supplicant.conf, with your editor of choice. The following is mandatory.

ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=wheel

Note: For use with netcfg-2.6.1-1 in [testing] (as of 2011-06-25), this should be /run/wpa_supplicant (note: not/var/...). This will, however, break the default for wpa_cli (use the -p option to override). If this is not changed, one gets errors like "Failed to connect to wpa_supplicant - wpa_ctrl_open: no such file or directory".

There is a lot of optional parameters (have a look at /etc/wpa_supplicant/wpa_supplicant.conf). For example:

ap_scan=0
fast_reauth=1

Note: Your network information will be stored in plain text format; therefore, it may be desirable to change permissions on the newly created /etc/wpa_supplicant.conf file (e.g. chmod 0600 /etc/wpa_supplicant.conf to make it readable by root only), depending upon how security conscious you are.

I do not want to impose anything here, but in order to discuss the guide content, I think it would be easier to work on the table content first. So what do you think? How do you think we should move parts around? Present state:http://sprunge.us/cRfH --zeb (talk) 11:11, 21 September 2012 (UTC)

Sorry, I had to edit your post, zeb. It was way too long. I created a TOC on my user page. Basically I merged Post-Instalation into Instalation, and didn't touch the Extra or any of other sections. The changes are:

Please post in the sub-discussions for discussing specific points. Reply here only to introduce new possible modifications or to link to other proposed ToC plans (like the one in User:DSpider). -- Kynikos (talk) 09:45, 22 September 2012 (UTC)

Removing "Kernel modules" and "Daemons"

I don't know of any kernel module that's required for a successful install (Guest Additions are also mentioned in the Extra section), and you don't really need to explain what daemons are, do you? Every instruction I have seen on the Arch Wiki, that mentions daemons, (Deluge, Iptables, MPD, SLiM, etc) tells you to add somedaemon on the DAEMONS line from /etc/rc.conf. --DSpider (talk) 12:30, 18 September 2012 (UTC)

The other aspect is the switch to systemd: in a pure systemd, the DAEMON array and the rc.conf file are not used anymore anyway. Thus it is up to the user to use initscripts/DAEMON or systemd/systemctl enable to activate the daemons. This is already covered in the Daemon page, which could be given more importance for the initscripts to systemd transition. However using rc.conf and DAEMONS is still the official way to activate a wired Ethernet network (although again this is deprecated with systemd). So maybe this could be the place to mention Daemons? Regarding Kernel modules, I do not know. Are there instances where they are required? --Zeb (talk) 13:42, 18 September 2012 (UTC)

VirtualBox Guest Additions are optional. You can get through the whole install process without them. Please remember to add a signature to the posts. It's easier to follow the conversation this way (else people would have to look at the history page to see which said what). I've added one for you this time. --DSpider (talk) 15:16, 18 September 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.

In my view the best solution would be not to completely remove those sections, but summarise them further and leave them as a very brief introduction to kernel modules with a link to Kernel modules (currently missing btw) and a brief intro to initscripts/daemons with a link to Daemon (perhaps also directly linking to rc.conf and mentioning the progressive move to systemd).

They definitely don't need to be in the "Install" section. This section is long enough as it is. Maybe in Extra. Notice how sudo is mentioned there? --DSpider (talk) 17:55, 19 September 2012 (UTC)

The "kernel Modules" section should remain in the Installation page. If an users needs of a particular module, it's right who knows how to set it here. While the "daemons" section may be moved in the "Extra" page, but all system configuration base file are mentioned here. Moved a part of these may not be the right choice. just my thought.Veleno (talk) 18:46, 19 September 2012 (UTC)

I agree with Veleno. The Beginner's guide is more than an installation guide. Indeed it has to cover all installation and configuration steps, which means moving these to Extra may be a stopper for people who need a kernel module during the install process. People can skip parts that are not relevant to thm (e.g. the manual network config for DHCP users). A good example of documentation is the Gentoo handbook. It is more than just an install guide, it covers everything related to configuration, inculding things that concern 1% of users. It has to stay "generic".--zeb (talk) 10:35, 20 September 2012 (UTC)

All right. Can you give an example of a kernel module that even 1% of users would actually need for a successful installation?

I cannot. But this is not the point. The point is: what is the purpose of this guide? The official install guide is too concise and this one has never been really a guide for beginners but for everybody, helping them in the installation process. Actually, even its name "Beginner's Guide" is not appropriate anymore and I would support renaming it "Archlinux Handbook". Even for an experienced Linux user, this is the central point of information on how Arch is built and administered. Back to the specific kernel modules: being able to load them and the way to do this may be important to some, and may be critical for them to install Arch on their machines. Other opinions?--zeb (talk) 14:05, 20 September 2012 (UTC)

This guide is full of fluff as it is. It should stay named as Beginners' Guide, because it's written for beginners (not for everybody, as you point it out). Anyway, these two sections ("Kernel modules" and "Daemons") are more about information than actual instructions, and they shouldn't be in the Install section. If this information doesn't help you install Arch Linux, what is the point? Then it should be in Extra, or even General Recommendations. --DSpider (talk) 06:32, 21 September 2012 (UTC)

Well, I disagree the guide is full of fluff, it contains the strict minimum for a full install (and you did an excellent job trimming it down). Despite the view differences, we have to find a solution. Maybe at this stage we need to discuss reorganising it, especially with the Post-Installation and Extra pages, which are not very cohesive. In Extra we have Sudo-Sound-X, what sense it would make to have kernel modules there? It would make Extra a placeholder for every bits unwanted in Installation, and it is not godd either. Also, Daemons as it is written will be obsolete when systemd is the official init system in Arch. rc.conf is removed in a pure systemd system, and daemons have to be enabled with systemctl. To summarise, I think that the problem is not only specific parts, but that the guide needs restructuring. What do you think? Would you like to propose a new structure for the guide so that we can discuss it?--zeb (talk) 10:28, 21 September 2012 (UTC)

Do I need to restate the fact that these do not belong in the INSTALLATION section? --DSpider (talk) 19:23, 1 October 2012 (UTC)

Ok, how about this: we rename them "Unnecessary at this point: Kernel modules" and "Unnecessary at this point: Daemons" :| --DSpider (talk) 12:46, 5 October 2012 (UTC)

Recently this FS#30235 has been reported, showing that for some instances, a network card module has to be loaded so that dhcp can correctly activate the ethernet adapter. Since the installer is now entirely dependent on internet connection, this is quite an important feature for achieving installation of a working system and may not be unneccessary after all. However, I reckon this may be moved to a later section. Another thing: kernel modules has its own page, could be worth mentioning it if we keep a kernel module comment. See also below for my proposal for refactoring the guide (2 parts: Installation and Maintenance), so that non-Installation related stuff, but important for administering the machine, have their place.--zeb (talk) 14:50, 5 October 2012 (UTC)

Troubleshooting boot problems

nomodeset and video=SVIDEO-1:d dindn't solve my blank screen problem with that board. The video= setting depends on the port, the display is connected. I have my display connected via VGA, so video=VGA-1:1280x800 did do it for me. I don't know if this will solve the problem for the majority of the users. I don't need to care about the display, because I just want to setup SSH and then never need a Display for that box anymore.

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.

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

Seperate pages

What I would like to see instead is a unified Beginners' Guide. Because currently, it's segmented into Preface, Preparation, Installation and Extra. Seriously, does anyone actually read it this way?

The Beginners' Guide is segmented in different subpages for ease of maintenance: if you want to read it in a single page, you can do it easily anyway. -- Kynikos (talk) 14:38, 29 October 2012 (UTC)

Ease of aintenance? How so? Personally I think it just complicates things. --DSpider (talk) 07:11, 30 October 2012 (UTC)

i18n is an example. A single big page is much harder to check for diff. -- Fengchao (talk) 07:46, 31 October 2012 (UTC)

Protect the page

I haven't been able to follow the discussion in #archlinux, so I'm not acquainted at all with the reasoning that has led to this idea, but my position can be in favour of a unified guide only if it's not protected: I think the strength of the ArchWiki, and of the Beginners' Guide itself, which has been kind of a trademark during all these years, is based on the fact that it's been open to be edited by the community; any other method of updating an article, be it through git like the old Official Installation Guide or through discussions in the talk page like the current Installation Guide is simply too slow and inefficient. This is a wiki, and we should use it the way it was designed to be used.

An alternative solution could be to maintain the installation guide as two "branches" (represented by two regular, distinct articles), one stable (officially approved by the Developers) and one open or unstable (freely editable): once the unstable guide is good enough, the Developers can just merge it to the stable branch. Something similar could be obtained with only one article, with the Devs only updating a link to their officially supported revision of the article itself, chosen in its history.

That could actually work well - leaving this guide as an unprotected, unofficial guide and then reviewing/copying changes to the officially endorsed protected page. -- thestinger (talk) 18:07, 29 October 2012 (UTC)

Include arch-wiki-lite to ISO

I'm also going to see if arch-wiki-lite can be included on the ISO instead of the current little overview of the install process in /root. -- thestinger (talk) 18:07, 29 October 2012 (UTC)

You said it yourself that you need an internet connection anyway. The arch-wiki-lite package contains an older snapshot of the wiki, and if someone were to read it at the end of the month before a new release, they could essentially be reading outdated information. --DSpider (talk) 07:11, 30 October 2012 (UTC)

It's true at the moment that it's not always kept up-to-date, but it could be generated every month with the new installation image if it was a more important package, which as you point out isn't perfect either. The need for including it is that there are other pages needed to even obtain an internet connection for many users. It makes me sad to think that people are printing out this whole long guide when there's a computer in front of them :). thestinger (talk) 17:26, 3 November 2012 (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 ?

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)

Swap partition removed: is that a good idea?

The swap partition creation has been removed entirely from this guide, with a link to the swap page and suggestion to use a swap file instead of a dedicated partition. I am very uncomfortable with this idea for several reasons:

the beginner's guide is supposed to be a guide that does not require reading other pages. As it is written (not reading the Swap page) the install process ends without creating any swap space. There is not even a reminder that Swap should be created after reboot. Although a Linux system can work without a swap, performance can be affected and it is not considered a good practice.

more importantly, the way it is written makes it heavily biased in favour of a Swap file instead of a partition. There are many reasons partitions should be preferred to a file for a swap space. Partition is considered more reliable and efficient than a file. Furthermore, suspend on disk does not work straight away with a file, it requires adding some kernel parameter which makes it more complicated than using a partition. Also, it is not compatible with Btrfs.

Don't get me wrong: I am not against the idea of using a swap file, it may be more flexible - the biggest advantage being the resizing capability - but the guide should be more explicit about the disadvantages and limitations of using a file, considering that partition design is very important because it can hardly be changed a posteriori on a working system.--zeb (talk) 11:04, 8 November 2012 (UTC)

Note about removing /tmp as a tmpfs filesystem from /etc/fstab on systemd-enabled systems

In section Generate an fstab there is a note that states: For machines with less than 384 MB RAM, the tmpfs entry should also be removed, because by default it uses half of the available RAM. Based on this thread it seems that masking tmp.mount in systemd with systemctl mask tmp.mount is also necessary for all systemd-enabled systems. Should we add this? -- Techstone (talk) 16:45, 21 November 2012 (UTC)