I have found two errors in the section "Configuring the network", there are two missing "_" in the followed sections:
Static IP definition:
routes eth0="default via 192.168.0.1" should be routes_eth0="default via 192.168.0.1"
config eth0="dhcp" should be config_eth0="dhcp"
The printable version is OK.
- Um. Maybe you're using a weird monospaced font. Looks alright here: http://puu.sh/jGXzu/dc264e238b.png —a3li 14:09, 19 August 2015 (UTC)
We need an example with partition labels
I tried to follow the handbook, but I messed up here when I tried to use partition labels. It turns out that fstab will let you use either FSA labels or partition labels. You use LABEL= for an FS label, or PARTLABEL= for a partition label. Since this page recommends the use of partition labels, it should provide an example. -Arch dude (talk) 04:38, 9 March 2017 (UTC)
- You may not (yet!) have noticed, but the new stage3 tarball contains a new set of examples how these should be implemented, but I would agree that some more information in the Handbook would be helpful. I know the Wiki team have this section on their TODO list, so hopefully you will see changes in the coming weeks/months :) -- veremit (talk) 14:36, 9 March 2017 (UTC)
The network section is not valid anymore
By default the new system uses predictable network interface names so the section should be updated to show the command that retrieves the predictable name and the config file modification and init file should be updated accordingly. --fordfrog 11:02, 19 December 2017 (UTC)
Indicate numpad support under "Init and boot configuration"
On multiple installs that I have done, I ended up with systems that didn't support the numerical keypad. I recently learned that this can be enabled by editing the /etc/conf.d/keypads file. The change is to add the keypad option to the extended_keymaps variable. Perhaps the handbook should call attention to this.
- Did you mean to edit the /etc/conf.d/keymaps file instead?--Charles17 (talk) 07:13, 2 February 2018 (UTC)
Use a more direct language to clarify mount option (minor)
This is also recommended for solid state drive (SSD) users to enable the discard mount option (ext4 and btrfs only for now) which makes the TRIM command work.
- This is actually a user preference as it can impact performance. A user may elect to run fstrim by hand or in a cron jobs. It is also not limited to ext4 and btrfs. --Grknight (talk) 18:36, 27 October 2018 (UTC)
- After I posted the above, I noticed the text already includes this. --Grknight (talk) 18:39, 27 October 2018 (UTC)
The Gentoo Handbook is excellent! Thanks. While installing Gentoo, I am just following the handbook step by step, and didn't have to take any notes! The only point of confusion upto this point is this: For the hostname and domainname, the Handbook suggests editing /etc/conf.d/hostname and /etc/conf.d/net. Is that sufficient? Other sites (elsewhere) say that you should edit /etc/hostname too. (/etc/hostname has not been mentioned anywhere in the Handbook till now.) Niku (talk) 06:28, 17 December 2018 (UTC)
- Gentoo's default OpenRC install does not use /etc/hostname which is what the handbook covers. It is true that a systemd install would use it but there is hostnamectl to easily edit it and signal systemd --Grknight (talk) 13:42, 17 December 2018 (UTC)
Wrong description of 'filesystem type' field
In section ' Creating the fstab file':
'# The third field shows the filesystem used by the partition.'
'# The third field shows the type of the filesystem used by the partition.'
Section about Filesystem/Partition Labels/UUIDs needs some loving
1) It's confusing that the two sections about Filesystem/Partition Labels/UUIDs start with the sentence:
'In the remainder of the text, we use the default /dev/sd* block device files as partition.'
2) 'Both MBR (BIOS) and GPT include support for filesystem labels and filesystem UUIDs.'
MBR surely does not include support for filesystem labels and filesystem UUIDs.
Maybe something like:
Filesystem labels and filesystem UUIDs can be used with MBR (BIOS) partition tables as well as with GPT partition tables.
3) 'Filesystem labels and UUIDs are identified by the LABEL and UUID prefix'
I don't know. Im wouldn't call it 'prefix', because that would mean something like 'LABEL39542764-01'. But it's 'LABEL=39542764-01' in /etc/fstab and 'LABEL="39542764-01"' in the output of blkid. So we talk about AV-pairs - and the attribute name is 'LABEL' or 'UUID'.
We should probably tell users that they must remove the quotes if they copy the LABEL or UUID from the output of blkid to /etc/fstab.
An example would be nice. :-)
Please look at https://wiki.archlinux.org/index.php/fstab, section 'Identifying filesystems'. Much better (sorry!).
Inaccurate recommendation about TRIM
'... for solid state drive (SSD) users, who should also enable the
discard mount option (ext4 and btrfs only for now) which makes the
TRIM command work.'
1) Many more filesystems than ext4 and btrfs support TRIM nowadays. See: https://wiki.archlinux.org/index.php/Solid_state_drive#TRIM
2) I don't think we should recommend the 'discard' option. First of all, option 'discard' enables continuous TRIM, but it's not required for periodic TRIM. So TRIM works without the 'discard' option.
3) It seems that many experts prefer periodic TRIM over continuous TRIM. And if a user uses periodic TRIM, he should NOT set option 'discard' to enable continous TRIM.
Please look at https://wiki.archlinux.org/index.php/Solid_state_drive for a good description.
Trim is supposed to be implemented as advice to a solid state storage device, not a command. Its up to the drive to take notes and actually do the erase when it judges the time is right.
However, poor implementations of trim treat it as a command and do the erase immediately. This leads to write amplification that is not actually required.
Its not clear if the extra erase cycles actually matter to the useful lives of SSDs. They may well be discarded themselves before they wear out. Its safer to use fstrim in a cron job than the discard option is /etc/fstab.
Handbook:AMD64/Installation/System#Optional:_Get_PCMCIA_working Did PCMCIA ever exist on amd64?
First there was PCMCIA, then Cardbus, then Cardbus went away in favour of USB2. Keep this in x86 but remove it from the AMD64 handbook.
- Cardbus was around during the early days of x86_64 but didn't stick around too long. One quick sample of this can be seen in a kernel bug. It is really debatable how useful it is. In addition, this text is for every arch so not very easy to remove without a whole page restructure. --Grknight (talk) 16:21, 9 July 2020 (UTC)
Unnecessarily verbose neutral pronouns
his/her is used, which should be replaced by thier. This change doubles as more inclusive as well as more concise. I can't edit this because of how the handbook namespace works. This problems is also on a bunch of other handbook pages - I'd try to mass edit them but yeah, handbook namespace.
nano -w is no longer required
From the nano man page:
NOTICE Since version 4.0, nano by default: * does not automatically hard-wrap lines that become overlong. * ... ... OPTIONS -w, --nowrap Do not automatically hard-wrap the current line when it becomes overlong. This is the default
Use of this option could be removed from the examples make them more succinct and less confusing.
- Thanks! I had actually added back the -w option in at least one place because, though it didn't seem to be required, it would be _so_ bad if it did mess up a file o_O. Seems pretty unequivocal that the -w switch is not needed :).
- Looking here, seems nano 4.0 is three years old, so not sure if there should be some sort of warning for anyone using an older nano...