Handbook Talk:Parts/Installation/Stage

Update time server URL
Why not use the same (non-governmental) time server as in the ntp article?--Charles17 (talk) 06:28, 5 October 2016 (UTC)


 * Your question could be asked another way around as well: why isn't the NTP article using the time server defined in the handbook? :P I'm not sure why the original author used the US gov's national time server. Perhaps one reason I can think of is reliability.


 * It is important to have an accurate system time in order to update the system and keep it secure. I'm not opposed to changing the server mentioned in the Handbook to pool.ntp.org as long as it's reliable. Is there a specific advantage you can think of as to why it would be better to use pool.ntp.org? Perhaps even better, I checked locally and found a few Gentoo specific time servers:


 * 0.gentoo.pool.ntp.org
 * 1.gentoo.pool.ntp.org
 * 2.gentoo.pool.ntp.org
 * 3.gentoo.pool.ntp.org


 * I'm not sure how reliable these servers are, but they also could perhaps be used in the Handbook and the NTP article as well since they seem to be tailored just for us. All this being said, I'd like some other Gentoo peoples to weigh in on this change before changing this long standing part of the Handbook. Kind regards, --Maffblaster (talk) 17:12, 5 October 2016 (UTC)


 * After a discussion in the and  channels on Freenode, I discovered upstream documentation states  is on its way out. Who knows when it will be removed from the package, but that's the plan at some point in the future. I'm convinced will be safest (for now) to use the  command passing the   options. As far as I can see,  does not support passing an arbatrary server on the command-line, which is all right for our case since it will reference the ${N}.gentoo.pool.ntp.org servers listed above (which should be in  on the official Gentoo install media). --Maffblaster (talk) 20:00, 5 October 2016 (UTC)


 * works on official Gentoo installation media (Minimal and Admin ISOs for ), but not on SystemRescueCD. I'm guessing it is intentionally removed because the daemon is not deemed necessary for the live environment. I'm unwilling to test anything outside those scopes. :) --Maffblaster (talk) 20:38, 5 October 2016 (UTC)


 * I've concluded that we'll be switching to in the handbook instead of using  since it's been over a month since this discussion was first opened and we've gotten no objections.  is supported by all Gentoo live media. --Maffblaster (talk) 19:40, 16 November 2016 (UTC)

Typo
(...) the  for Decompress with bzip2, the  for Preserve permissions and (...)

There is a missing space before the, which is especially visible when using a text browser like links.

--FabianP (talk) 08:37, 18 November 2016 (UTC)


 * Fixed! Thank you! --Maffblaster (talk) 18:13, 18 November 2016 (UTC)

Add --numeric-owner to stage3 extraction
Installation alternatives for installing from other distro LiveUSB pass  to the tar command for the stage3 extraction, in case the other distro has different UID/GID in its /etc/passwd or /etc/groups for something in the tarball. We should just tell to always use it, to minimize the difference and it gives extra safety for gentoo install mediums too, and doesn't hurt.

--Leio (talk) 02:35, 31 December 2016 (UTC)


 * Thanks for the tip and I agree, we could add the  to the stage3 extraction. It should protect those running the installation steps from non-official media. Right now it is very possible that UID/GUIs could get screwed up in the chroot destination. I'll test in a VM and if all goes well I'll add the option to the tar command and close this discussion. --Maffblaster (talk) 03:30, 31 December 2016 (UTC)


 * Tests succeeded! Making adjustment. --Maffblaster (talk) 23:58, 23 February 2017 (UTC)

Emphasize the stage tarball location more
If an upcoming user is using an alternative install via some other distributions LiveUSB (gives nicer browser, etc), then all this talk of command line browser links/lynx is shadowing what matters - where the stage tarball actually is. The releases/$ARCH/autobuilds/ subdir is mentioned without any emphasis below many blocks of commands about some ugly text mode browsers and proxies, that it doesn't get noticed nicely where to actually browse. Alternatively (or even better) there could be some direct links somehow, e.g geoip supported DNS round robin link directly to the architectures autobuilds folder or something. Or just direct links to each arch "stage3 tarballs" in the mirrors list.

--Leio (talk) 02:35, 31 December 2016 (UTC)


 * I'll add something to fix this up. There are links to current tarballs on the www.g.o downloads page. I'll link to the #other-arches ID. --Maffblaster (talk) 21:24, 21 April 2017 (UTC)


 * The links under #other-arches doesn't include the "regular" Stage 3 listed above that section under "Stage Archives" (unless I'm not reading things right). This could be confusing to users who want the default Stage 3. - dcljr (talk) 03:30, 25 April 2017 (UTC)


 * Hmm...Looks like you're correct. Good catch! It turns out to be harder than I want to link our readers to all the stage choices in a single, easy to navigate location using a modern web browser. My intent here is to modernize the Handbook and help our readers avoid mirror navigation. Perhaps I'll rework the website's download page to make the 'advanced' downloads spot include the normal stage3 listed in the section above. What do you think about that? Could you open a bug on our Bugzilla describing this dilemma and link it here? --Maffblaster (talk) 18:14, 25 April 2017 (UTC)


 * Adding a normal Stage 3 to the "advanced" choices seems like the easiest solution — although maybe "advanced" isn't really the right label for that list. As for the bug report, I only do those if I absolutely have to (hate the user interface). If I'm going to do it, it'll have to wait a few days, as I am busy with other things at the moment. - dcljr (talk) 07:16, 27 April 2017 (UTC)


 * Works for me. There are quite a few changes I'd like to make to www.g.o around this weekend or sooner, so I can wait a few days... Can we close this discussion now? I'm getting close to closing out all the open Handbook discussions. :) --Maffblaster (talk) 07:24, 27 April 2017 (UTC)

Graphical browsers can download files from a link
Why recommend pasting the URL of a tarball into a command? All graphical browsers should be able to download a file directly from a link (using, e.g., and then spefcifying the destination directory). I think nowadays all of them will even save it in the right format. [wink] - dcljr (talk) 03:17, 25 April 2017 (UTC)


 * Mainly because it eliminates permissions complications. Readers should already have a root terminal open to the correct location. It's much simpler to have readers copy/paste and allow to do the download in the existing root terminal. As a side note - most live graphical environments that I'm aware of do not start the web browser as the root user.  is owned by root. Chromium, which I mention, even refuses to run as root. Firefox can run as root, but I'd rather not have the reader open second terminal, gain root privileges, then start Firefox (or another browser) or run extra / commands. We'll just work with what we have already available in the simplest, most convenient way for me as the author and them as the readers. --Maffblaster (talk) 18:04, 25 April 2017 (UTC)

Nowiki on URLs
Please add tags to the URLs in the  and  commands in the Command-line browsers section, as was done in this edit for the  commands, so the little (potentially confusing) "external link" icons will be suppressed. - dcljr (talk) 03:23, 25 April 2017 (UTC)


 * Done. Somehow I overlooked those links when I made the first change. :) --Maffblaster (talk) 17:58, 25 April 2017 (UTC)

GCC, the GNU Compiler Collection
Small note. GCC is already GNU. --Cronolio (talk) 16:12, 7 May 2017 (UTC)
 * Removed redundant reference to GNU. It just says "GCC" now. Thanks! --Maffblaster (talk) 17:23, 15 May 2017 (UTC)