This thing has been on my mind for a while. Arch is usually considered a difficult distro to install among most linux users probably only rivalled by Gentoo. There are those who praise the " Keep it Simple stupid " principle and there are others who think that Arch and Simple existing in the same sentence is an example of oxymoron. My own experience is somewhat on the former but there have been moments where i was inclined with the latter. By no means do i consider myself an arch expert but more along the lines of a bit above an intermediate archer. Having said that, the main purpose of this post would be more of a reminder to myself on the list of thing that i should not forget when i do a fresh install of arch on a physical device (PC, laptops) and also for the benefit of those who might follow the KISS path.
Once the base system is installed and you have the X configured, the display managed and DE is installed and you see a graphic user login and this is the point where you take a break and say, "yes now my installation is done. I can get along to personalisation/project migration/other stuff". Wait. Hold on. there are certain other stuff to complete. How do i know that? I have done the same mistake over the couple of years. So learn from my fail.
Pay Attention to Your Hard Disk
Unless you have a pressing need or specify reason, there is no need to let the hard drive spin 24/7 when the system is powered on. Use hdparm or sdparm , depending on you system configuration and let the hard drive spin down when not needed. If there is not much expected IO operations, then it is preferable to let the spin parameter to 127 or a bit lesser. The key note is to let it have a value less than 128, since anything about 128 is a spin up. Next is to set the standby timer to a value of 2-3 mins. So the corresponding commands to issue, assuming the drive in question is sda,
hdparm -B 127 -S 36 /dev/sda
In the above 36 corresponds to 3 mins, since the counting unit goes in multiples of 5 second till a 240 is reached. Naturally, to make the above persistent across boot, creating a udev rule is ideal. Since that process is well explained in the archwiki (and also my aim was to bring certain salient but often forgotten points to highlight rather than regurgle the archwiki) i will refrain from posting the udev rules.
Cpu frequency tools
Since two of my previous machines were AMD, i had been perplexed when i installed arch and i found the laptop generating enough heat to be used as a replacement for kitchen heating plate. A bit of "background search" revealed that the installation was set at performance mode for cpu frequency. (read background search in the above sentence as `cat /proc/cpuinfo`). Since then, unless i am assured that i need the computing power, i set the frequency parameter to powersave. The easiest way to acheive is to install cpupower along with acpi and laptop mode tools (if it is a laptop in question) and use
cpupower frequency-set -g powersave
or alternatively , to write this to /etc/default/cpupower to acheive persistency across reboots. There are quiet a few options that one can do with the combination of cpu frequency control and acpid (especially for laptops). Another reminder to visit the wiki.
Control the Fan .
There is nothing more annoying than taking your fresh laptop to work and receive complaints from coworkers on how annoying the fan sounds. If have not received similar criticism, then consider yourself lucky or cautious, but for the rest of us who have had this bad experience, there is a likely possibility that you have missed the following step. (emphasis is on the work `likely possibility`). Following the wiki, the process is to let lm_sensors take care of the detection, followed by pwmconfig to set up the fan control. Except on occasions where this fails, which has been like 70% of my experience. It's either that or i have been working with really exotic products.
To begin with, cpu fans are a bit nifty since on the onset it is never clear who gets to control how much of the fan. Here is a brief diagnostic method that i usually do when i run into fan issues.
- Obviously, the first area to check is to look for the presence of fanX_input or pwnX_enable in /sys/class/hwmon/hwmonX/device/. where X could be a number depending on your hardware configuration.
- If no such files exist, then the second option is to see if the bios has relinquished control for the fan. Time to reboot and poke in the bios. This should sort the problem normally, but in cases where this is not viable, either the bios has given control or there is no such options available in the bios.
- The third option would be to pass acpi_enforce_resources=lax as a kernel parameter during boot
- If all the above failed, the final option would be to try loading an appropriate module for the chipset manually, (Eg it87 etc)
- In failure of all the above, it is worthwhile to open and see if the fan has a 3 pin or a 4 pin connectors. Most likely the chipset uses 3 pin connectors at which point i congratulate myself for all the google searches and knowledge gained and let he fan run at full speed.
There a still a few more stuff left, including sound cards, wlan , backlight and brightness and response to acpid events. Hopefully, i will either append them here or add them as a part 2 blog. Untill then.