https://wiki.archlinux.org/api.php?action=feedcontributions&user=TaylanUB&feedformat=atomArchWiki - User contributions [en]2024-03-29T08:25:11ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=GRUB&diff=121171GRUB2010-11-12T12:59:37Z<p>TaylanUB: s/Uniform/Unified/</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|GRUB2}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Covers various aspects of the next generation of the GRand Unified Bootloader (GRUB2).}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GRUB}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary link|GNU GRUB -- GNU Project|http://www.gnu.org/software/grub/}}<br />
{{Article summary link|GNU GRUB Wiki|http://grub.enbug.org/}}<br />
{{Article summary end}}<br />
<br />
[http://www.gnu.org/software/grub/grub-2.en.html GRUB2] is the next generation of the GRand Unified Bootloader (GRUB). GRUB2 is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to investigate the next generation of GRUB. GRUB 2 has been rewritten from scratch to clean up everything and provide modularity and portability [http://www.gnu.org/software/grub/grub-2-faq.en.html#q1].<br />
<br />
Briefly, the ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system.<br />
<br />
Currently, [[GRUB]] (i.e. version 0.9x) is the de facto standard bootloader of Linux, and is expected to be superseded by GRUB2 in the near future. When this happens, "GRUB" will become "GRUB Legacy". Even though Grub2 has been worked on since February 2005 and Grub (version 0.9x) is referred to as grub-legacy in some places over the internet, this is *not* yet the case. The new Grub2 still isn't fully implemented.<br />
<br />
== Preface ==<br />
<br />
GRUB2 is still under development and therefore caution should be observed. '''Consider yourself warned!''' GRUB2 may not behave as expected, features may be missing, and functionality may change. Without any specific reason to use GRUB2, users should consider installing the more stable [[GRUB]] instead.<br />
<br />
=== Notes for current GRUB users ===<br />
<br />
* There are differences in the commands of GRUB and GRUB2. Familiarize yourself with [http://grub.enbug.org/CommandList GRUB2 commands] before proceeding (e.g. "find" has been replaced with "search").<br />
<br />
* GRUB2 is now ''modular'' and no longer requires "stage 1.5". As a result, the bootloader itself is limited -- modules are loaded from the hard drive as needed to expand functionality (e.g. for [[LVM]] or RAID support).<br />
<br />
* Device naming has changed between GRUB and GRUB2. Partitions are numbered from 1 instead of 0 while drives are still numbered from 0. For example, {{Filename|/dev/sda1}} would be referred to as {{Codeline|(hd0,1)}} using GRUB2.<br />
<br />
== Installation ==<br />
<br />
The GRUB2 package can be installed with pacman (and will replace {{Package Official|grub}}, if it is installed):<br />
# pacman -S grub2<br />
<br />
Additionally, GRUB2 must be installed to the boot sector of a drive or partition to serve as a bootloader. This is covered in the [[#Bootloader Installation]] section.<br />
<br />
=== Installing GRUB2 during Arch Linux installation ===<br />
<br />
* Skip the '''Install Bootloader''' step and exit the installer. <br />
* Configure the network:<br />
# aif -p partial-configure-network<br />
* If you did not configure the installed system's /etc/resolv.conf file during installation (for instance, if you plan to let DHCP generate it later), you will need to copy the one generated by AIF when it configured the network:<br />
# cp /etc/resolv.conf /mnt/etc/resolv.conf<br />
* From the installer's live shell, chroot to the installed system:<br />
# mount -o bind /dev /mnt/dev<br />
# chroot /mnt bash<br />
* Install the GRUB2 package:<br />
# pacman -Sy grub2<br />
<br />
=== Bootloader Installation ===<br />
<br />
GRUB2 may be installed from a live environment, or directly from a running Arch install.<br />
<br />
In most cases, installing GRUB2 is as easy as running the '''grub-install''' command as root:<br />
# grub-install /dev/sda --no-floppy<br />
<br />
Where the <code>--no-floppy</code> tells to not search for floppy devices which will vastly improve the command's overall execution time on many systems (it will also prevent the issue below from occuring) and where {{Filename|/dev/sda}} is the destination of the installation (in this case the MBR of the first SATA disk). If you use [[LVM]] for your {{Filename|/boot}}, you can install GRUB2 on multiple physical disks. <br />
<br />
Executing grub-install without the <code>--no-floppy</code> flag can also lead to this when there is a problem detecting the path of the floppy device:<br />
<br />
grub-probe: error: Cannot get the real path of '/dev/fd0'<br />
Auto-detection of a filesystem module failed.<br />
Please specify the module with the option '--modules' explicitly.<br />
<br />
Thus it is recommended to use the <code>--no-floppy</code> switch, if you don't want to have your MBR on a floppy. If you do, you also want to set floppy as the first boot device in BIOS.<br />
<br />
== Configuration ==<br />
<br />
The configuration files are <code>/etc/default/grub</code> and <code>/etc/grub.d/*</code>. These files are used to generate the <code>/boot/grub/grub.cfg</code> file. You can also choose to manually edit <code>grub.cfg</code>.<br />
<br />
=== grub-mkconfig ===<br />
<br />
The grub-mkconfig script can be used to generate a {{Filename|grub.cfg}} file. By default the script outputs to stdout. Note that gettext ― an optional dependency of the GRUB2 package ― is required by the grub-mkconfig script. To generate a {{Filename|grub.cfg}} file run the command:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== grub.cfg ===<br />
<br />
A basic grub file uses the following options<br />
* {{Codeline|(hdX,Y)}} is the partition {{Codeline|Y}} on disk {{Codeline|X}}, partition numbers starting at 1, disk numbers starting at 0<br />
* {{Codeline|1=set default=N}} is the default boot entry that is chosen after timeout for user action<br />
* {{Codeline|1=set timeout=M}} is the time {{Codeline|M}} to wait in seconds for a user selection before default is booted<br />
* {{Codeline|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{Codeline|title}}<br />
* {{Codeline|1=set root=(hdX,Y)}} sets the boot partition, where the kernel and GRUB modules are stored (boot need not be a separate partition, and may simply be a directory under the "root" partition ({{Filename|/}})<br />
<br />
An example configuration:<br />
<br />
{{File<br />
|name=/boot/grub/grub.cfg<br />
|content=<nowiki><br />
# Config file for GRUB2 - The GNU GRand Unified Bootloader<br />
# /boot/grub/grub.cfg<br />
<br />
# DEVICE NAME CONVERSIONS<br />
#<br />
# Linux Grub<br />
# -------------------------<br />
# /dev/fd0 (fd0)<br />
# /dev/sda (hd0)<br />
# /dev/sdb2 (hd1,2)<br />
# /dev/sda3 (hd0,3)<br />
#<br />
<br />
# Timeout for menu<br />
set timeout=5<br />
<br />
# Set default boot entry as Entry 0<br />
set default=0<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
#set root=(hd0,3)<br />
#chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
If you choose to modify <code>grub.cfg</code> completely manually and won't even generate the first <code>grub.cfg</code>, you should know that if you do not have a separate boot partition, <code>/boot</code> must prefix entries in <code>grub.cfg</code>. Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
set root=(hd0,1)<br />
linux '''/boot/'''vmlinuz26 root=/dev/sda1 ro<br />
initrd '''/boot/'''kernel26.img<br />
}<br />
<br />
=== Dual-booting ===<br />
<br />
<br />
==== Using grub-mkconfig ====<br />
The best way to add other entries is editing the {{Filename|/etc/grub.d/40_custom}}. The entries in this file will be automatically added when running '''grub-mkconfig'''.<br />
After adding the new lines, run <br />
# grub-mkconfig -o /boot/grub/grub.cfg <br />
to generate an updated {{Filename|grub.cfg}}.<br />
<br />
===== With GNU/Linux =====<br />
<br />
Assuming that the other distro is on partition {{Filename|sda2}}:<br />
<br />
menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}<br />
<br />
===== With Windows =====<br />
<br />
This assumes that your Windows partition is {{Filename|sda3}}.<br />
<br />
# (2) Windows XP<br />
menuentry "Windows XP" {<br />
set root=(hd0,3)<br />
chainloader (hd0,3)+1<br />
}<br />
<br />
If the windows bootloader is on an entirely different harddrive than grub, it may be neccessary to trick windows into believing that it is in fact the first harddrive. This was possible in the old grub with <code>map</code> and is now done with <code>drivemap</code>. Assume grub is on hd0 and windows on hd2, you need to add the following after <code>set root</code><br />
<br />
drivemap -s hd0 hd2<br />
<br />
==== With Windows via EasyBCD and NeoGRUB ====<br />
<br />
Since EasyBCD's NeoGRUB currently does not understand the GRUB2 menu format, chainload to it by replacing the contents of your {{Filename|C:\NST\menu.lst}} file with lines similar to the following:<br />
<br />
default 0<br />
timeout 1<br />
<br />
title Chainload into GRUB v2<br />
root (hd0,7)<br />
kernel /boot/grub/core.img<br />
<br />
===Visual Configuration===<br />
<br />
In GRUB2 it is possible, by default, to change the look of the menu.<br />
<br />
====Background image and bitmap fonts====<br />
<br />
GRUB2 comes with support for background images and bitmap fonts in pf2 format. The unifont font is included in the grub2 package under the filename {{Filename|unicode.pf2}}, or, as only ascii characters under the name {{Filename|ascii.pf2}}. Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware. There are two ways of setting a tga file as background. Two sample configurations are shown below.<br />
<br />
=====The new über method=====<br />
<br />
Edit <code>/etc/default/grub</code> like this:<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
GRUB_BACKGROUND="/boot/grub/archlinux.tga"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
<br />
To generate the changes, run: <br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=====The deprecated method=====<br />
<br />
This is the piece of text that would be generated. You can choose to add it manually to grub.cfg:<br />
if loadfont /usr/share/grub/unicode.pf2 ; then<br />
set gfxmode="1024x768x32"<br />
set gfxpayload=keep<br />
insmod gfxterm<br />
insmod vbe<br />
terminal_output gfxterm<br />
if terminal_output gfxterm; then true ; else<br />
terminal gfxterm<br />
fi<br />
fi<br />
insmod tga<br />
background_image /boot/grub/archlinux.tga<br />
<br />
{{Note|If this example doesn't work for you try to replace {{Codeline|1=gfxmode="1024x768x32"}} by {{Codeline|1=vbemode="0x105"}}.}}<br />
{{Note|To show all the modes you can use the {{Codeline|1=vbeinfo}} command at grub2 prompt (you need to load the vbe module before).}}<br />
{{Note|If you have installed Grub on a separate partition, /boot/grub/archlinux.tga becomes /grub/archlinux.tga.}}<br />
<br />
====Menu colors====<br />
<br />
As in Grub (0.9x), you can change the menu colors in Grub2. The available colors for GRUB2 are at http://www.gnu.org/software/grub/manual/html_node/color.html. <br />
Here's an example:<br />
<br />
=====The new über method=====<br />
Edit <code>/etc/default/grub</code>:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
Execute:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=====The deprecated method=====<br />
<br />
### BEGIN /etc/grub.d/00_header ###<br />
....<br />
'''set menu_color_normal=light-blue/black'''<br />
'''set menu_color_highlight=light-cyan/blue'''<br />
....<br />
### END /etc/grub.d/00_header ###<br />
<br />
====Hidden menu====<br />
<br />
One of the unique features of Grub2 is hiding/skipping the menu and showing it by holding "Shift" when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
=====The new über method=====<br />
<br />
Edit <code>/etc/default/grub</code> as you wish. Here's an example where the comments from the beginning of the two lines have been removed to enable the feature, the timeout has been set to five seconds and to be shown to the user:<br />
GRUB_HIDDEN_TIMEOUT=5<br />
GRUB_HIDDEN_TIMEOUT_QUIET=false<br />
<br />
And run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=====The deprecated method=====<br />
<br />
Once again, you can choose to be an exception and do this manually as shown here:<br />
<br />
....<br />
set locale_dir=($root)/boot/grub/locale<br />
set lang=en<br />
'''insmod gettext'''<br />
''''if sleep --interruptible 5 ; then'''<br />
'''set timeout=0'''<br />
'''fi'''<br />
### END /etc/grub.d/00_header ###<br />
....<br />
<br />
====Setting the framebuffer resolution ====<br />
<br />
===== The new über method =====<br />
<br />
Grub2 can set the framebuffer for both grub2 itself and the kernel. The old ''vga='' way is deprecated. The preferred method is editing <code>/etc/default/grub</code> as the following sample:<br />
<br />
GRUB_GFXMODE=1024x768x32<br />
GRUB_GFXPAYLOAD_LINUX=keep<br />
<br />
To generate the changes, run: <br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
The gfxpayload property will make sure the kernel keeps the resolution.<br />
<br />
If this method does not work for you, the deprecated vga= method will still work. Just<br />
add the vga= setting next to the "GRUB_CMDLINE_LINUX_DEFAULT=" line in "/etc/default/grub"<br />
for eg: "GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792" will give you a 1024x768 resolution.<br />
<br />
You can choose one of these resolutions: 640×480, 800×600, 1024×768, 1280×1024, 1600×1200<br />
<br />
===== The deprecated method =====<br />
<br />
Again, you can add the configuration manually to grub.cfg as shown below.<br />
<br />
if loadfont /usr/share/grub/unicode.pf2 ; then<br />
set gfxmode="1024x768x32" <br />
set gfxpayload=keep<br />
insmod gfxterm<br />
insmod vbe<br />
terminal_output gfxterm<br />
if terminal_output gfxterm; then true ; else<br />
terminal gfxterm<br />
fi<br />
fi<br />
<br />
=== Other Options ===<br />
<br />
==== LVM ====<br />
<br />
If you use [[LVM]] for your {{Filename|/boot}}, add the following before menuentry lines:<br />
<br />
insmod lvm<br />
<br />
and specify your root in the menuentry as:<br />
<br />
set root=(''lvm_group_name''-''lvm_logical_boot_partition_name'')<br />
<br />
Example:<br />
<br />
# (0) Arch Linux<br />
menuentry "Arch Linux" {<br />
insmod lvm<br />
set root=(VolumeGroup-lv_boot)<br />
# you can only set following two lines<br />
linux /vmlinuz26 root=/dev/mapper/VolumeGroup-root ro<br />
initrd /kernel26.img<br />
}<br />
<br />
==== Raid ====<br />
<br />
Grub2 provides convenient handling of raid-volumes. You need to add<br />
<br />
insmod raid<br />
<br />
which allows you to address the volume natively. E.g. {{Filename|/dev/md0}} becomes<br />
<br />
set root=(md0)<br />
<br />
whereas a partitioned raid-volume (e.g. {{Filename|/dev/md0p1}}) becomes <br />
<br />
set root=(md0,1)<br />
<br />
==== Persistent block device naming ====<br />
You can use UUIDs to detect partitions instead of the "old" '''/dev/sd*''' and '''/dev/hd*''' scheming. It has the advantage of detecting partitions by their unique UUIDs, which is needed by some people booting with complicated partition setups.<br />
<br />
UUIDs are used by default in the recent versions of grub2 - there's no downside in it anyway except that you need to re-generate the grub.cfg file every time you resize or reformat your partitions. Remember this when modifying partitions with Live-CD.<br />
<br />
===== The new über method =====<br />
<br />
The recent versions of grub2 use UUIDs by default. You can re-enable the use of UUIDS by simply commenting the UUID line (this is also what it looks like by default):<br />
#GRUB_DISABLE_LINUX_UUID=true<br />
you can also just set the value as <code>false</code> as shown here:<br />
GRUB_DISABLE_LINUX_UUID=false<br />
<br />
Either way don't forget to generate the changes:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== The deprecated method =====<br />
<br />
To list UUIDs, from a running system:<br />
# blkid<br />
<br />
Replace the value of the {{Codeline|root}} pointer on the linux line with the following:<br />
<br />
linux /vmlinuz26 root='''/dev/disk/by-uuid/<UUID>''' ro<br />
<br />
However, you still have to set Grub2's notion of a root partition. In order to do that, use the {{Codeline|search}} command:<br />
<br />
search --no-floppy --fs-uuid <UUID> --set root<br />
<br />
What the <code>--no-floppy</code> flag does has already been explained. An example boot entry using Persistent block device naming would look like:<br />
<br />
menuentry "Arch Linux" {<br />
'''search --no-floppy --fs-uuid 355ccb5c-99e1-400d-b612-451f9247e35e --set root'''<br />
linux /boot/vmlinuz26 '''root=/dev/disk/by-uuid/355ccb5c-99e1-400d-b612-451f9247e35e''' ro<br />
initrd /boot/kernel26.img<br />
}<br />
<br />
==== Using Labels ====<br />
<br />
It is possible to use labels, human-readable strings attached to filesystems, by using the {{Codeline|--label}} option to {{Codeline|search}}. First of all, label your existing partition:<br />
<br />
# tune2fs -L a <LABEL> <PARTITION><br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label archroot --set root<br />
linux /boot/vmlinuz26 root=/dev/disk/by-label/archroot ro<br />
initrd /boot/kernel26.img<br />
}<br />
<br />
==== Recall previous entry ====<br />
<br />
Grub2 can remember the last entry you booted from and use this as the default entry to boot from next time. This is useful if you have multiple kernels (i.e., the current Arch one and the LTS kernel as a fallback option) or operating systems. To do this, edit {{Codeline|/etc/default/grub}} and change the setting of {{Codeline|GRUB_DEFAULT}}:<br />
<br />
GRUB_DEFAULT=saved<br />
<br />
This ensures that grub will default to the saved entry. To enable saving the selected entry, add the following line to {{Codeline|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
Remember to regenerate your configuration file.<br />
<br />
== Using the command shell ==<br />
<br />
Since the MBR is too small to store all GRUB2 modules, only the menu and a few basic commands reside there. The majority of GRUB2 functionality remains in modules in {{Filename|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB2 may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB2 offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
<br />
sh:grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/normal.mod<br />
rescue:grub> normal<br />
<br />
====parttool or legacy hide/unhide====<br />
If you have a win9x paradigm with hidden C disks GRUB legacy had the hide/unhide feature. In GRUB2 this has been replaced by parttool. For example, to boot the third C disk of three win9x installations on the CLI enter the CLI and:<br />
parttool hd0,1 hidden+ boot-<br />
parttool hd0,2 hidden+ boot-<br />
parttool hd0,3 hidden- boot+<br />
set root=hd0,3<br />
chainloader +1<br />
boot<br />
<br />
== Using the rescue console ==<br />
<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include "insmod", "ls", "set", and "unset". This example uses "set" and "insmod". "set" modifies variables and "insmod" inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{Filename|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
To expand console capabilities, insert the "linux" module:<br />
<br />
grub rescue> insmod (hdX,Y)/boot/grub/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{Filename|/boot}} from the path, (i.e. type {{Codeline|1=set prefix=(hdX,Y)/grub}} and {{Codeline|insmod (hdX,Y)/grub/linux.mod}}).}}<br />
<br />
This introduces the "linux" and "initrd" commands, which should be familiar (see [[#Configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz26 root=/dev/sda5<br />
initrd /boot/kernel26.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
<br />
set root=(hd0,5)<br />
linux /vmlinuz26 root=/dev/sda6<br />
initrd /kernel26.img<br />
boot<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{Filename|grub.cfg}} as needed and then run:<br />
<br />
# grub-install /dev/sda --no-floppy<br />
<br />
to reinstall GRUB2 and fix the problem completely, changing {{Filename|/dev/sda}} if needed. See [[#Bootloader installation]] for details.<br />
<br />
== Combining the use of UUID's and basic scripting ==<br />
--[[User:Celilo|Celilo]] 06:04, 19 March 2010 (EDT)<br />
<br />
If you like the idea of using UUID's to avoid unreliable bios mappings or are struggling with grub syntax, here is an example boot menu item that uses UUID's and a small script to direct grub to the proper disk partitions for your system. All you need to do is replace the UUID's in the sample with the correct UUID's for your system. (The example applies to a system with a boot and root partition. You will obviously need to modify the grub configuration if you have additional partitions.)<br />
<br />
menuentry "Arch Linux 64" {<br />
set uuid_grub_boot=ece0448f-bb08-486d-9864-ac3271bd8d07 #Enter the UUID of your boot partition (this is where grub and your kernel reside) <br />
set uuid_os_root=c55da16f-e2af-4603-9e0b-03f5f565ec4a #Enter the UUID of the partition containing the root partition of your Arch Linux installation. <br />
#(Note: this may be the same as your boot partition) <br />
search --no-floppy --fs-uuid $uuid_os_root --set=root #Here we set the grub "root" variable by locating the uuid of the root partition identified above<br />
search --no-floppy --fs-uuid $uuid_grub_boot --set=grub_boot #Here we set a custom variable grub_boot by locating the uuid of the boot partition identified above<br />
#Here's the magic. We test to see if the boot and root partitions have the same UUID. If they do we append /boot to the $grub_boot variable. For ex. (hd0,1) becomes (hd0,1)/boot. <br />
if [ $uuid_grub_boot == $uuid_os_root ] ; then <br />
set grub_boot=$grub_boot/boot<br />
fi<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux ($grub_boot)/vmlinuz26 root=/dev/disk/by-uuid/$uuid_os_root ro<br />
initrd ($grub_boot)/kernel26.img<br />
}<br />
<br />
== Troubleshooting ==<br />
<br />
Any troubleshooting should be added here.<br />
<br />
=== msdos-style error message ===<br />
<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding won't be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB2 in a VMware container. Read more about it [http://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. Hopefully a fix will be provided soon.<br />
<br />
It also happens when the first partition starts just after the MBR, without the usual space of 60-something block before the first partition.<br />
<br />
=== Other ===<br />
I couldn't figure out how to uninstall grub1, and install grub2 to the MBR, as it isn't being booted by default. It is still booting grub1. So, an easy work-around, is rename {{Filename|menu.lst.pacsave}} or whatever, to {{Filename|menu.lst}} (in /boot/grub/) and for each menu entry that you would like to use grub2, at the end type {{Codeline|"chainloader +1"}}. This will tell grub1 to forward control to grub2. This is an ugly hack though, so I advise setting the {{Filename|menu.lst}}'s timout as 0, otherwise the total timeout would be grub1's time out + grub2's which, for me would equal more than 18 seconds, which is quite a bit.<br />
<br />
P.S. hopefully someone figures out how to pry grub1's dead fingers off of my MBR, and place grub2 on it :) .<br />
<br />
In my case it had to do with my boot partition. Say boot-partition is {{Codeline|(hd0,1)}} and your root is {{Codeline|(hd0,3)}} (grub2 naming). grub-setup searches for {{Filename|(hd0,3)/boot/grub/core.img}}. Just because it's on {{Filename|(hd0,1)/grub/core.img}}, it is unable to find it. So I copied the grub-folder to my root partition and everything worked fine:<br />
<br />
E.g. (as root:)<br />
# mount /boot<br />
# cp -a /boot/grub /<br />
# umount /boot<br />
# mv /grub /boot/<br />
# grub-install /dev/sda</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=ASUS_Eee_PC_1001px&diff=116113ASUS Eee PC 1001px2010-08-31T20:07:53Z<p>TaylanUB: /* Laptop Mode Tools & powersaving */</p>
<hr />
<div>[[Category:ASUS (English)]]<br />
<br />
==Introduction==<br />
How to install Archlinux on the [http://commercial.asus.com/product/detail/52 Asus Eee PC 1001px]. <br />
<br />
This article was written for the stock kernel 2.6.34-ARCH. The netbook runs absolutely fine after little configuration.<br />
<br />
The same model was sold in Germany under the name [http://www.notebooksbilliger.de/asus+eee+pc+r101+win7+schwarz Eee PC R101].<br />
<br />
==Installation==<br />
The netbook probably comes with a 32bit-Windows installed. The Intel Atom 450N however supports x86_64-instructions and 64bit-Arch runs perfectly fine.<br />
<br />
To boot from an USB stick it is neccessary to deactivate the "Boot Booster"-option in the BIOS or otherwise the Asus seems to skip all detection scans and will just boot from harddisk. Press F2 repeatedly during the fortunately short POST to enter the BIOS. Deactivate "Boot Booster" and select your USB stick as the first HDD in the HDD list. (The "Removable Device" in the main boot devices list is something different.) <br />
<br />
When partitioning you may want to keep the EFI-partition (usually the last, smallest partition). It allows to use the "Boot Booster"-Feature and to jump over certain tests before booting. Don't panic however if you deleted it, the partition may be restored. Look on the eeePC-Forum for it.<br />
<br />
==Sound==<br />
<br />
The soundcard is correctly recognized but alsa does not feature the correct model-option (yet) to setup the rather interesting pin connections. What works mostly is adding<br />
<br />
options indel-hda-snd model=lifebook<br />
<br />
to your <code>/etc/modprobe/modprobe.conf</code>. I did not however get the internal microphone working. The external microphone over the combined audio jack was not tested.<br />
<br />
==Laptop Mode Tools & powersaving==<br />
<br />
The powersaving-mechanisms provided by [[Laptop Mode Tools]] seem to work. <br />
<br />
Standby (Suspend-to-ram) works perfectly fine with hotkey. Hibernate (Suspend-to-disk) was not tested.<br />
<br />
CPU frequency scaling works. After installing [[Cpufrequtils]] and adding <code>acpi-cpufreq</code> to your MODULES in <code>/etc/rc.conf</code> laptop-mode does a perfectly fine job taking care of your frequencies.<br />
<br />
Spinning down the harddrive works.<br />
<br />
Adjusting the brightness of the display works with hotkeys after adding the following to your kernel-boot-options<br />
acpi_osi=Linux acpi_backlight=vendor<br />
To adjust the brightness from the command line, you can write values 0 to 10 (inclusive) to /sys/devices/virtual/backlight/acpi_video0/brightness .<br />
<br />
Personal Remark: The overall endurance seems good. While I never actually reached the promised 10h, 8h-9h are possible with dimmed display, 4h while really working with it. The power-saving-support is probably not worse than on windows.<br />
<br />
==Issueless hardware==<br />
===Graphics===<br />
<br />
The integrated GPU (Pineview) is supported with KMS by <code>i915</code> meaning xf86-video-intel.<br />
<br />
===(W)LAN===<br />
<br />
The WLAN-chip is fully supported by <code>ath9k</code> in all three modes of operation (b/g/n).<br />
Ethernet works fine.<br />
<br />
===Input===<br />
<br />
Webcam and Touchpad work. <br />
<br />
Keyboard also does its job.<br />
<br />
SD Card reader works.<br />
<br />
==Hardware information==<br />
<br />
===lspci===<br />
00:00.0 Host bridge: Intel Corporation Pineview DMI Bridge<br />
00:02.0 VGA compatible controller: Intel Corporation Pineview Integrated Graphics Controller<br />
00:02.1 Display controller: Intel Corporation Pineview Integrated Graphics Controller<br />
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)<br />
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)<br />
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)<br />
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)<br />
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)<br />
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)<br />
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) <br />
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)<br />
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)<br />
00:1f.0 ISA bridge: Intel Corporation Tigerpoint LPC Controller (rev 02)<br />
00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) SATA AHCI Controller (rev 02)<br />
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)<br />
01:00.0 Ethernet controller: Atheros Communications Atheros AR8132 / L1c Gigabit Ethernet Adapter (rev c0)<br />
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)<br />
<br />
===lsusb===<br />
Bus 005 Device 002: ID 0b05:1788 ASUSTek Computer, Inc. <br />
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub<br />
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub<br />
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub<br />
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub<br />
Bus 001 Device 002: ID 13d3:5119 IMC Networks <br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=ASUS_Eee_PC_1001px&diff=116112ASUS Eee PC 1001px2010-08-31T19:58:31Z<p>TaylanUB: /* Installation */</p>
<hr />
<div>[[Category:ASUS (English)]]<br />
<br />
==Introduction==<br />
How to install Archlinux on the [http://commercial.asus.com/product/detail/52 Asus Eee PC 1001px]. <br />
<br />
This article was written for the stock kernel 2.6.34-ARCH. The netbook runs absolutely fine after little configuration.<br />
<br />
The same model was sold in Germany under the name [http://www.notebooksbilliger.de/asus+eee+pc+r101+win7+schwarz Eee PC R101].<br />
<br />
==Installation==<br />
The netbook probably comes with a 32bit-Windows installed. The Intel Atom 450N however supports x86_64-instructions and 64bit-Arch runs perfectly fine.<br />
<br />
To boot from an USB stick it is neccessary to deactivate the "Boot Booster"-option in the BIOS or otherwise the Asus seems to skip all detection scans and will just boot from harddisk. Press F2 repeatedly during the fortunately short POST to enter the BIOS. Deactivate "Boot Booster" and select your USB stick as the first HDD in the HDD list. (The "Removable Device" in the main boot devices list is something different.) <br />
<br />
When partitioning you may want to keep the EFI-partition (usually the last, smallest partition). It allows to use the "Boot Booster"-Feature and to jump over certain tests before booting. Don't panic however if you deleted it, the partition may be restored. Look on the eeePC-Forum for it.<br />
<br />
==Sound==<br />
<br />
The soundcard is correctly recognized but alsa does not feature the correct model-option (yet) to setup the rather interesting pin connections. What works mostly is adding<br />
<br />
options indel-hda-snd model=lifebook<br />
<br />
to your <code>/etc/modprobe/modprobe.conf</code>. I did not however get the internal microphone working. The external microphone over the combined audio jack was not tested.<br />
<br />
==Laptop Mode Tools & powersaving==<br />
<br />
The powersaving-mechanisms provided by [[Laptop Mode Tools]] seem to work. <br />
<br />
Standby (Suspend-to-ram) works perfectly fine with hotkey. Hibernate (Suspend-to-disk) was not tested.<br />
<br />
CPU frequency scaling works. After installing [[Cpufrequtils]] and adding <code>acpi-cpufreq</code> to your MODULES in <code>/etc/rc.conf</code> laptop-mode does a perfectly fine job taking care of your frequencies.<br />
<br />
Spinning down the harddrive works.<br />
<br />
Adjusting the brightness of the display works with hotkeys after adding the following to your kernel-boot-options<br />
acpi_osi=Linux acpi_backlight=vendor<br />
I did however not find out how to adjust the brightness manually, eg. per command-line.<br />
<br />
Personal Remark: The overall endurance seems good. While I never actually reached the promised 10h, 8h-9h are possible with dimmed display, 4h while really working with it. The power-saving-support is probably not worse than on windows.<br />
<br />
==Issueless hardware==<br />
===Graphics===<br />
<br />
The integrated GPU (Pineview) is supported with KMS by <code>i915</code> meaning xf86-video-intel.<br />
<br />
===(W)LAN===<br />
<br />
The WLAN-chip is fully supported by <code>ath9k</code> in all three modes of operation (b/g/n).<br />
Ethernet works fine.<br />
<br />
===Input===<br />
<br />
Webcam and Touchpad work. <br />
<br />
Keyboard also does its job.<br />
<br />
SD Card reader works.<br />
<br />
==Hardware information==<br />
<br />
===lspci===<br />
00:00.0 Host bridge: Intel Corporation Pineview DMI Bridge<br />
00:02.0 VGA compatible controller: Intel Corporation Pineview Integrated Graphics Controller<br />
00:02.1 Display controller: Intel Corporation Pineview Integrated Graphics Controller<br />
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)<br />
00:1c.0 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 1 (rev 02)<br />
00:1c.1 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 2 (rev 02)<br />
00:1c.3 PCI bridge: Intel Corporation 82801G (ICH7 Family) PCI Express Port 4 (rev 02)<br />
00:1d.0 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #1 (rev 02)<br />
00:1d.1 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #2 (rev 02)<br />
00:1d.2 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #3 (rev 02) <br />
00:1d.3 USB Controller: Intel Corporation 82801G (ICH7 Family) USB UHCI Controller #4 (rev 02)<br />
00:1d.7 USB Controller: Intel Corporation 82801G (ICH7 Family) USB2 EHCI Controller (rev 02)<br />
00:1e.0 PCI bridge: Intel Corporation 82801 Mobile PCI Bridge (rev e2)<br />
00:1f.0 ISA bridge: Intel Corporation Tigerpoint LPC Controller (rev 02)<br />
00:1f.2 SATA controller: Intel Corporation 82801GR/GH (ICH7 Family) SATA AHCI Controller (rev 02)<br />
00:1f.3 SMBus: Intel Corporation 82801G (ICH7 Family) SMBus Controller (rev 02)<br />
01:00.0 Ethernet controller: Atheros Communications Atheros AR8132 / L1c Gigabit Ethernet Adapter (rev c0)<br />
02:00.0 Network controller: Atheros Communications Inc. AR9285 Wireless Network Adapter (PCI-Express) (rev 01)<br />
<br />
===lsusb===<br />
Bus 005 Device 002: ID 0b05:1788 ASUSTek Computer, Inc. <br />
Bus 005 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub<br />
Bus 004 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub<br />
Bus 003 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub<br />
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub<br />
Bus 001 Device 002: ID 13d3:5119 IMC Networks <br />
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Talk:ASUS_Eee_PC_1001px&diff=116111Talk:ASUS Eee PC 1001px2010-08-31T19:55:49Z<p>TaylanUB: Created page with "From the article, before i edited it: ``... Deactivate "Boot Booster" and select "Removable Dev." as 1st boot device. Personal Remark: For me it still was neccessary to press ..."</p>
<hr />
<div>From the article, before i edited it:<br />
<br />
``... Deactivate "Boot Booster" and select "Removable Dev." as 1st boot device. <br />
<br />
Personal Remark: For me it still was neccessary to press Esc during POST and manually select the USB stick to boot from it. This may be a BIOS-bug (ver. 0403)''<br />
<br />
'Removable Device' does not include USB sticks. This is the case with a lot (most? all?) BIOSes capable of booting from a flash stick; they recognize it as a HDD.</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Extra_keyboard_keys/Xorg&diff=109556Extra keyboard keys/Xorg2010-06-25T16:20:13Z<p>TaylanUB: </p>
<hr />
<div>[[Category:Input devices (English)]][[Category:X Server (English)]][[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Extra Keyboard Keys in Xorg}}<br />
{{i18n_entry|Türkçe|Xorg için ekstra klavye tuşları}}<br />
{{i18n_links_end}}<br />
<br />
=Introduction=<br />
When we are in a graphical environment we may want a key to print a special character or execute a command. There are some ways of doing that and they are covered in this HOWTO.<br />
<br />
{{Box Note |This article assumes that your keys already have keycodes and that you know these codes, if not, see the [[Extra Keyboard Keys]] article where it is explained.}}<br />
<br />
=Map keycodes to symbols=<br />
==Introduction==<br />
The most traditional and proficient way to make a key output a character when you are in X is to use xmodmap. Xmodmap is roughly the X equivalent of ''loadkeys'': it reads a file containing some directives. As ''loadkeys'', it can be used to modify many aspects of the behaviour of your keyboard (such as modifiers, etc.), but I will not cover these aspects in this article. The only kind of directive I am interested in here associates an X keycode to a keysym. ''xmodmap'' is included in the ''xorg-server-utils'' package.<br />
# pacman -S xorg-server-utils<br />
<br />
==Step 1: Create the xmodmap file==<br />
In this file, you have to list the keycode directives, with the following syntax:<br />
keycode <Xkeycode> = <keysym><br />
The list of X keysyms can be read in {{Filename|/usr/include/X11/keysymdef.h}}. Anyway, most of them are intuitive. Let us say that the X keycode of my hotkey is 239. If I want it to output a literal 'e', I will write the following directive:<br />
keycode 239 = e<br />
If I want it to output the symbol of the American currency, I will write the following directive:<br />
keycode 239 = dollar<br />
<br />
This can also be used to assign functions to multimedia keys. Special functions can be found in {{Filename|/usr/share/X11/XKeysymDB}}.<br />
<br />
An example {{Filename|~/.Xmodmap}}:<br />
keycode 160 = XF86AudioMute<br />
keycode 176 = XF86AudioRaiseVolume<br />
keycode 174 = XF86AudioLowerVolume<br />
<br />
Multimedia programs such as Rhythmbox and Exaile are designed to work with keys assigned to XF86 Symbols out-of-the-box, without the need to configure a third-party application.<br />
<br />
==Step 2: Testing==<br />
Finally I have to source the file with xmodmap:<br />
$ xmodmap ~/.Xmodmap<br />
<br />
==Step 3: Making it permanent==<br />
Obviously, this will work only for the current X session so we have to put this command somewhere. You may put it in your {{Filename|~/.xinitrc}} or {{Filename|~/.xprofile}} file.<br />
<br />
=Map keycodes to actions=<br />
==Using xbindkeys==<br />
''xbindkeys'' (available in the extra repository) allows advanced mapping of keycodes to actions independently of the Desktop Environment.<br />
<br />
A GUI called ''xbindkeys_config'' is available in [[AUR]].<br />
<br />
==Using actkbd==<br />
From [http://users.softlab.ece.ntua.gr/~thkala/projects/actkbd/ actkbd home page]:<br />
<blockquote><br />
'''actkbd''' (available [http://aur.archlinux.org/packages.php?ID=8056 in AUR]) is a simple daemon that binds actions to keyboard events. It recognises key combinations and can handle press, repeat and release events. Currently it only supports the linux-2.6 evdev interface. It uses a plain-text configuration file which contains all the bindings.<br />
</blockquote><br />
<br />
==Using your Desktop Environment tools==<br />
===Gnome===<br />
Gnome Control Center is quite complete for the extra keyboard keys management. In fact it can directly detect scancodes which means that he can map any key seen by the kernel.<br />
<br />
===KDE===<br />
In KDE 4.1, Input Actions use the ''KHotKeys'' daemon but it doesn't work.<br />
<br />
In KDE 4.2, Input Actions are configurable from the ''systemsettings'' program.<br />
<br />
===Xfce4===<br />
You can change the keyboard shortcuts in Keyboard Settings, which can be run using {{Codeline|xfce-setting-show keyboard}}.<br />
<br />
===Openbox===<br />
You can set keyboard shortcuts and actions in the keyboard section of your {{Filename|~/.config/openbox/rc.xml}} file. For example, the following will lower the volume with a media key:<br />
<keybind key="XF86AudioLowerVolume"><br />
<action name="Execute"><br />
<execute>amixer set Master 5- unmute</execute><br />
</action><br />
</keybind><br />
For more information, please visit [http://urukrama.wordpress.com/openbox-guide/#Key_mouse urukrama's Openbox Guide] or the [http://icculus.org/openbox/index.php/Help:Actions#Execute Openbox Wiki].<br />
<br />
===PekWM===<br />
Setting keys in PekWM is accomplished by editing your {{Filename|~/.pekwm/keys}} file. For example, adding the following at the bottom of the Global section will lower the volume with a media key:<br />
KeyPress = "XF86AudioLowerVolume" { Actions = "exec amixer set Master 5- unmute &" }</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Extra_keyboard_keys/Console&diff=109555Extra keyboard keys/Console2010-06-25T16:03:36Z<p>TaylanUB: </p>
<hr />
<div>[[Category:Input devices (English)]][[Category:HOWTOs (English)]]<br />
<br />
When we are in console, we can use our hotkeys to print a certain character. Moreover we can also print a sequence of characters and some escape sequences. Thus, if we print the sequence of characters constituting a command and afterwards an escape character for a new line, that command will be executed!<br />
<br />
In order to do this, we could modify our console keymap. However, I suggest not to do this, since that is a delicate file and since it will be rewritten anytime we update the package it belongs to. It is better to integrate the existing keymap with a personal keymap. The utility 'loadkeys' can do this. <br />
<br />
First of all, we need to write down this file. You can put it as you prefer, but I prefer to mimic partially the hierarchy of the default keymaps into /usr/local. So:<br />
# mkdir -p /usr/local/share/kbd/keymaps<br />
# vim /usr/local/share/kbd/keymaps/personal.map<br />
As a side note, it is worth noting that such a personal keymap is useful also to redefine the behavior of keys already treated by the default keymap: in fact, when we load it with 'loadkeys' the directives in the default keymap will be replaced when they conflict with the new directives and conserved otherwise. <br />
<br />
Anyway, we need two kinds of directives in our personal keymaps. First of all, the keycode directives, with the format we have seen above in the default keymaps. These directives associate a keycode with a keysym. Keysyms represent keyboard actions. The actions available include outputting character codes or character sequences, switching consoles or keymaps, booting the machine etc. (The complete list can be obtained with <br />
$ dumpkeys -l<br />
Anyway, most of them are intuitive. If we want our key to output an 'e', the directive will be:<br />
keycode 112 = e<br />
If we want our hotkey to output the symbol of the euro currency, the directive will be:<br />
keycode 112 = euro<br />
Some keysym are not immediately connected to a keyboard actions. In particular the keysyms constituted by a capital F and one to three digits (F1-F246) constituting a number greater than 30 are always free. This is useful for us if we want our hotkey to output a sequence of characters and other actions. In fact we can first of all bind our character to such a keysym:<br />
keycode 112 = F70<br />
Then we use another kind of directive, which binds the keysym to an action. E.g., if we want our hotkey to output a literal "Hello":<br />
string F70 = "Hello"<br />
This can seem not very useful. But we can use it to print and execute commands. In order to execute the printed command, I need to use an escape sequence corresponding to a new line. E.g., I can want an hotkey to hibernate my laptop also when I am a user (through sudo). In this case I write the following directive in my personal keymap.<br />
string F70 = "sudo /usr/sbin/hibernate\n"<br />
In order to take profit of my personal keymap, I have to load it with 'loadkeys':<br />
$ loadkeys /usr/local/share/kbd/keymaps/personal.map<br />
Also in this case, this is valid only for the current session. In order to accomplish the same result each time I boot my machine, I have to insert another line in /etc/rc.local. This line should come after the occurrences of 'setkeycodes' discussed in section 2, since the personal keymap resorts to the keycodes assigned through 'setkeycodes':<br />
loadkeys -q /usr/local/share/kbd/keymaps/personal.map&<br />
The '-q' option is simply to suppress the confirmation message that is normally printed.</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=107582Improving performance2010-05-29T15:18:28Z<p>TaylanUB: /* Mkinitcpio */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009], and [http://bbs.archlinux.org/viewtopic.php?id=88515 2010].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage.<br />
*Btrfs: Great overall performance (better than ext4), reliable (once it becomes stable). Lots of features. Still in heavy development and considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
Btrfs is a new filesystem offering online defragmentation, optimized mode for SSDs, writable snapshots, changing size of partition without data loss and many other features. Btrfs is still in active development, and is available in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===== mkinitcpio.conf for btrfs =====<br />
<br />
There is an undocumented dependency of the libcrc32c module required by btrfs. You need to add crc32c to the modules line of /etc/mkinitcpio.conf like so:<br />
<br />
MODULES="atl2 eeepc_laptop squashfs aufs crc32c libcrc32c zlib_deflate btrfs"<br />
<br />
This avoids pitfalls like "unknown symbol" errors when loading the btrfs modules.<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
$ pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of /usr as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
$ mkdir /squashed<br />
$ mkdir /squashed/usr<br />
$ cd /squashed/usr<br />
$ mkdir ro<br />
$ mkdir rw<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in /usr after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress /usr:<br />
$ mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit fstab:<br />
$ nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of /usr, but this might cause some problems if anything goes wrong during some later re-compression. It is more safe to leave the old files in place just to be on the safe side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing (read updating) the archive since the tutorial is meant for Gentoo and some options don't correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. But you should keep in mind that the one tip that suggests to mount /tmp within RAM is really usefull as long as you don't compile stuff like games or don't watch long flash videos within your browser. Yaourt uses /tmp for storing everything that it compiles and might abort due to insufficient amount of disk space which means in this case not enough RAM. You can do the following to let Yaourt use another directory for its temporary files:<br />
nano /etc/yaourtrc<br />
and now uncomment the line:<br />
# TmpDirectory /what/ever/you/want/<br />
and change it to something like:<br />
TmpDirectory /home/arch/.tmp/<br />
Just make sure that this directory is not on your SSD; that's what we're trying to prevent in first place!<br />
<br />
See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
See this [http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/ guide] for information on the introduction of online SSD TRIM support in the 2.6.33 kernel.<br />
<br />
If you have the latest Kernel and use ext4 you can simply activate SSD live TRIM support by adding one mount option to your fstab.<br />
discard<br />
example:<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
{{warning| Make sure you have a Kernel and a SSD with latest firmware which are known to support TRIM !<br />
Otherwise you could lose your data, so be sure to always backup beforehand!}}<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
To install a kernel that contains the ck patchset from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
Or a kernel that contains just BFS patch:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
Other kernels that have the BFS patch included or as an option:<br />
<br />
$ yaourt -S kernel26-ice<br />
$ yaourt -S kernel26-zen<br />
$ yaourt -S kernel26zen-git<br />
<br />
{{Note|The PKGBUILD bust be edited to enable BFS in kernel26-ice.}}<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
====Preload====<br />
A more automated, albeit less KISS, approach is used by [[Preload]]. All you have to do is add it to your DAEMONS array in {{Filename|/etc/rc.conf}}. It will monitor the most used files on your system, and with time build its own list of files to preload at boot.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum has made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=107581Improving performance2010-05-29T15:08:27Z<p>TaylanUB: /* Tuning for an SSD */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009], and [http://bbs.archlinux.org/viewtopic.php?id=88515 2010].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage.<br />
*Btrfs: Great overall performance (better than ext4), reliable (once it becomes stable). Lots of features. Still in heavy development and considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
Btrfs is a new filesystem offering online defragmentation, optimized mode for SSDs, writable snapshots, changing size of partition without data loss and many other features. Btrfs is still in active development, and is available in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===== mkinitcpio.conf for btrfs =====<br />
<br />
There is an undocumented dependency of the libcrc32c module required by btrfs. You need to add crc32c to the modules line of /etc/mkinitcpio.conf like so:<br />
<br />
MODULES="atl2 eeepc_laptop squashfs aufs crc32c libcrc32c zlib_deflate btrfs"<br />
<br />
This avoids pitfalls like "unknown symbol" errors when loading the btrfs modules.<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
$ pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of /usr as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
$ mkdir /squashed<br />
$ mkdir /squashed/usr<br />
$ cd /squashed/usr<br />
$ mkdir ro<br />
$ mkdir rw<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in /usr after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress /usr:<br />
$ mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit fstab:<br />
$ nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of /usr, but this might cause some problems if anything goes wrong during some later re-compression. It is more safe to leave the old files in place just to be on the safe side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing (read updating) the archive since the tutorial is meant for Gentoo and some options don't correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. But you should keep in mind that the one tip that suggests to mount /tmp within RAM is really usefull as long as you don't compile stuff like games or don't watch long flash videos within your browser. Yaourt uses /tmp for storing everything that it compiles and might abort due to insufficient amount of disk space which means in this case not enough RAM. You can do the following to let Yaourt use another directory for its temporary files:<br />
nano /etc/yaourtrc<br />
and now uncomment the line:<br />
# TmpDirectory /what/ever/you/want/<br />
and change it to something like:<br />
TmpDirectory /home/arch/.tmp/<br />
Just make sure that this directory is not on your SSD; that's what we're trying to prevent in first place!<br />
<br />
See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
See this [http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/ guide] for information on the introduction of online SSD TRIM support in the 2.6.33 kernel.<br />
<br />
If you have the latest Kernel and use ext4 you can simply activate SSD live TRIM support by adding one mount option to your fstab.<br />
discard<br />
example:<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
{{warning| Make sure you have a Kernel and a SSD with latest firmware which are known to support TRIM !<br />
Otherwise you could lose your data, so be sure to always backup beforehand!}}<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
To install a kernel that contains the ck patchset from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
Or a kernel that contains just BFS patch:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
Other kernels that have the BFS patch included or as an option:<br />
<br />
$ yaourt -S kernel26-ice<br />
$ yaourt -S kernel26-zen<br />
$ yaourt -S kernel26zen-git<br />
<br />
{{Note|The PKGBUILD bust be edited to enable BFS in kernel26-ice.}}<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
====Preload====<br />
A more automated, albeit less KISS, approach is used by [[Preload]]. All you have to do is add it to your DAEMONS array in {{Filename|/etc/rc.conf}}. It will monitor the most used files on your system, and with time build its own list of files to preload at boot.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Improving_performance&diff=107580Improving performance2010-05-29T15:04:09Z<p>TaylanUB: /* Compressing /usr */</p>
<hr />
<div>[[Category: Other desktop user's resources (English)]]<br />
[[Category: HOWTOs (English)]]<br />
This article is a retrospective analysis and basic rundown about gaining performance in Arch Linux.<br />
<br />
==The basics==<br />
<br />
===Know your system===<br />
The best way to tune a system is to target the bottlenecks, that is the subsystems that limit the overall speed. They usually can be identified by knowing the specifications of the system, but there are some basic indications:<br />
* If the computer becomes slow when big applications, like openoffice and firefox, are running at the same time, then there is a good chance the amount of RAM is insufficient. To verify available RAM, use this command, and check for the line beginning with -/+buffers:<br />
$ free -m<br />
* If boot time is really slow, and if applications take a lot of time to load the first time they are launched, but run fine afterwards, then the hard drive is probably too slow. The speed of a hard drive can be measured using the hdparm command:<br />
$ hdparm -t /dev/harddrive<br />
This is only the pure read speed of the hard drive, and is not a valid benchmark, but a value superior to 40mb/s can be considered decent on an average system.<br />
* If the CPU load is consistently high even when RAM is available, then lowering CPU usage should be a priority. CPU load can be monitored in many ways, like using the top command:<br />
$ top<br />
* If the only applications lagging are the ones using direct rendering, meaning they use the graphic card, like video players and games, then improving the graphic performance should help. To verify this, try running this command for 20 seconds:<br />
$ glxgears<br />
This also isn't a valid benchmark, but a value of 300fps or less can be considered very low on an average system. If that is the case, then maybe direct rendering simply isn't enabled. This is indicated by the glxinfo command:<br />
$ glxinfo | grep direct<br />
<br />
===The first thing to do===<br />
The simplest and most efficient way of improving overall performance is to run less and lighter applications. This can be achieved by:<br />
* Changing the desktop environment to a lighter one. Good choices are [[LXDE]], [[Xfce]], or a standalone window manager like [[Openbox]].<br />
* Using lightweight applications. See [[Lightweight Software]] and the Light and Fast Applications Awards threads in the forum: [http://bbs.archlinux.org/viewtopic.php?id=41168 2007], [http://bbs.archlinux.org/viewtopic.php?id=67951 2008], [http://bbs.archlinux.org/viewtopic.php?id=78490 2009], and [http://bbs.archlinux.org/viewtopic.php?id=88515 2010].<br />
* Removing unnecessary daemons in rc.conf.<br />
<br />
===Compromise===<br />
Almost all tuning brings drawbacks. Lighter applications usually come with less features and some tweaks may make a system unstable, or simply require time to implement and maintain. This page tries to highlight those drawbacks, but the final judgment rests on the user.<br />
<br />
===Benchmarking===<br />
The effects of optimization are often difficult to judge. They can however be measured by [[benchmarking]] tools<br />
<br />
==Storage devices==<br />
===Choosing and tuning your filesystem===<br />
Choosing the best filesystem for a specific system is very important because each has its own strengths. The [[Beginner's Guide#Filesystem Types|beginner's guide]] provides a short summary of the most popular ones. You can also find relevant articles [http://wiki.archlinux.org/index.php/Category:File_systems_%28English%29 here].<br />
<br />
====Summary====<br />
*XFS: Excellent performance with large files. Low speed with small files. A good choice for /home.<br />
*Reiserfs: Excellent performance with small files. A good choice for /var.<br />
*Ext3: Average performance, reliable.<br />
*Ext4: Great overall performance, reliable, has performance issues with sqlite and some other databases.<br />
*JFS: Good overall performance, very low CPU usage.<br />
*Btrfs: Great overall performance (better than ext4), reliable (once it becomes stable). Lots of features. Still in heavy development and considered as unstable. Do not use this filesystem yet unless you know what you are doing and are prepared for potential data loss.<br />
<br />
====Mount options====<br />
Mount options offer an easy way to improve speed without reformatting. They can be set using the mount command:<br />
$ mount -o option1,option2 /dev/partition /mnt/partition<br />
To set them permanently, you can modify /etc/fstab to make the relevant line look like this:<br />
/dev/partition /mnt/partition partitiontype option1,option2 0 0<br />
A couple of mount options improving performance on almost all file-systems is {{Codeline|noatime,nodiratime}}. In rare cases, for example if you use mutt, it can cause minor problems. You can instead use the {{Codeline|relatime}} option.<br />
<br />
====Ext3====<br />
See [[Ext3 Filesystem Tips]].<br />
<br />
====JFS====<br />
See [[JFS Filesystem#Optimizations| JFS Filesystem]].<br />
<br />
====XFS====<br />
For optimal speed, create an XFS file-system with:<br />
$ mkfs.xfs -l internal,size=128m -d agcount=2 /dev/thetargetpartition<br />
An XFS specific mount option that may increase performance is {{Codeline|<nowiki>logbufs=8</nowiki>}}. As its speed when dealing with small files is poor, you should definitely consider using [[Maximizing Performance#Pacman-cage|pacman-cage]]. For defragmentation, see [[Defragmentation XFS]].<br />
<br />
==== Reiserfs ====<br />
<br />
The {{Codeline|<nowiki>data=writeback</nowiki>}} mount option improves speed, but may corrupt data during power loss. The {{Codeline|notail}} mount option increases the space used by the filesystem by about 5%, but also improves overall speed. You can also reduce disk load by putting the journal and data on separate drives. This is be done when creating the filesystem: <br />
<br />
$ mkreiserfs –j /dev/hda1 /dev/hdb1<br />
<br />
Replace /dev/hda1 with the partition reserved for the journal, and /dev/hdb1 with the partition for data. You can learn more about reiserfs with this [http://www.funtoo.org/en/articles/linux/ffg/2/ article].<br />
<br />
====BTRFS====<br />
Btrfs is a new filesystem offering online defragmentation, optimized mode for SSDs, writable snapshots, changing size of partition without data loss and many other features. Btrfs is still in active development, and is available in the kernel (marked experimental). See more info on the [http://btrfs.wiki.kernel.org/index.php/Main_Page Btrfs homepage].<br />
<br />
===== mkinitcpio.conf for btrfs =====<br />
<br />
There is an undocumented dependency of the libcrc32c module required by btrfs. You need to add crc32c to the modules line of /etc/mkinitcpio.conf like so:<br />
<br />
MODULES="atl2 eeepc_laptop squashfs aufs crc32c libcrc32c zlib_deflate btrfs"<br />
<br />
This avoids pitfalls like "unknown symbol" errors when loading the btrfs modules.<br />
<br />
===Compressing /usr===<br />
A way to speed up reading from the hard drive is to compress the data, because there is less data to be read. It must however be decompressed, which means a greater CPU load. Some filesystems support transparent compression, most notably btrfs and reiserfs4, but their compression ratio is limited by the 4k block size. A good alternative is to compress /usr in a squashfs file, with a 64k(128k) block size, as instructed in this [http://forums.gentoo.org/viewtopic-t-646289.html Gentoo forums thread]. What this tutorial does is basically to compress the /usr folder into a compressed squashfs file-system, then mounts it with aufs. A lot of space is saved, usually two thirds of the original size of /usr, and applications load faster. However, each time an application is installed or reinstalled, it is written uncompressed, so /usr must be re-compressed periodically.Squashfs is already in the kernel, and aufs2 is in the extra repository, so no kernel compilation is needed if using the stock kernel.<br />
Since the linked guide is for Gentoo the next commands outline the steps especially for Arch. Basically we have got install two packages to get it working:<br />
$ pacman -S aufs2 squashfs-tools<br />
This command installs the aufs-modules and some userspace-tools for the squash-filesystem.<br />
Now we need some extra directories where we can store the archive of /usr as read-only and another folder where we can store the data changed after the last compression as writeable:<br />
$ mkdir /squashed<br />
$ mkdir /squashed/usr<br />
$ cd /squashed/usr<br />
$ mkdir ro<br />
$ mkdir rw<br />
Now that we got a rough setup you should perform a complete system-upgrade since every change of content in /usr after the compression will be excluded from this speedup. If you use prelink you should also perform a complete prelink before creating the archive. Now it is time to invoke the command to compress /usr:<br />
$ mksquashfs /usr /squashed/usr/usr.sfs -b 65536<br />
These parameters/options are the ones suggested by the Gentoo link but there might be some room for improvement using some of the options described [http://www.tldp.org/HOWTO/SquashFS-HOWTO/mksqoverview.html#mksqusing here].<br />
Now to get the archive mounted together with the writeable folder it is necessary to edit fstab:<br />
$ nano /etc/fstab<br />
Add the following lines:<br />
/squashed/usr/usr.sfs /squashed/usr/ro squashfs loop,ro 0 0 <br />
usr /usr aufs udba=reval,br:/squashed/usr/rw:/squashed/usr/ro 0 0<br />
Now you should be done and able to reboot. The original Author suggests to delete all the old content of /usr, but this might cause some problems if anything goes wrong during some later re-compression. It is more safe to leave the old files in place just to be on the safe side.<br />
<br />
A [http://bbs.archlinux.org/viewtopic.php?pid=714052 bash script] has been created that will automate the process of re-compressing (read updating) the archive since the tutorial is meant for Gentoo and some options don't correlate to what they should be in Arch.<br />
<br />
===Tuning for an SSD===<br />
This [http://tombuntu.com/index.php/2008/09/04/four-tweaks-for-using-linux-with-solid-state-drives/ tutorial] has some very simple tricks to fully harness the power of an SSD and to reduce disk read/write cycles to prolong its life. But you should keep in mind that the one tip that suggests to mount /tmp within RAM is really usefull as long as you don't compile stuff like games or don't watch long flash videos within your browser. Yaourt uses /tmp for storing everything that it compiles and might abort due to insufficient amount of disk space which means in this case not enough RAM. You can do the following to let Yaourt use another directory for its temporary files:<br />
nano /etc/yaourtrc<br />
and now uncomment the line:<br />
# TmpDirectory /what/ever/you/want/<br />
and change it to something like:<br />
TmpDirectory /home/arch/.tmp/<br />
Just make sure that this directory is not on your SSD because this but be the right opposite of what this trick want to achieve!<br />
<br />
See also [[Tuning Arch for Speed#Compcache|compcache]].<br />
<br />
See this [http://cptl.org/wp/index.php/2010/03/30/tuning-solid-state-drives-in-linux/ guide] for information on the introduction of online SSD TRIM support in the 2.6.33 kernel.<br />
<br />
If you have the latest Kernel and use ext4 you can simply activate SSD live TRIM support by adding one mount option to your fstab.<br />
discard<br />
example:<br />
/dev/sda1 / ext4 defaults,noatime,discard 0 1<br />
{{warning| Make sure you have a Kernel and a SSD with latest firmware which are known to support TRIM !<br />
Otherwise you could lose your data, so be sure to always backup beforehand!}}<br />
<br />
==CPU==<br />
The only way to directly improve CPU speed is overclocking. As it is a complicated and risky task, it is not recommended for anyone except experts. The best way to overclock is through the BIOS. When purchasing your system, keep in mind that most Intel motherboards are notorious for disabling the capacity to overclock.<br />
<br />
Another way to improve CPU performance is to use Con Kolivas' desktop-centric kernel patchset, which, among other things, replaces the Completely Fair Scheduler (CFS) with the Brain Fuck Scheduler (BFS).<br />
<br />
To install a kernel that contains the ck patchset from the AUR using [[yaourt]]:<br />
<br />
$ yaourt -S kernel26-ck<br />
<br />
Or a kernel that contains just BFS patch:<br />
<br />
$ yaourt -S kernel26-bfs<br />
<br />
Other kernels that have the BFS patch included or as an option:<br />
<br />
$ yaourt -S kernel26-ice<br />
$ yaourt -S kernel26-zen<br />
$ yaourt -S kernel26zen-git<br />
<br />
{{Note|The PKGBUILD bust be edited to enable BFS in kernel26-ice.}}<br />
<br />
{{Note|BFS/CK are designed for desktop/laptop use and not servers. They provide low latency and work well for 16 CPUs or less. Also, Con Kolivas suggests setting HZ to 1000. For more information, see the [http://ck.kolivas.org/patches/bfs/bfs-faq.txt BFS FAQ] and [http://www.kernel.org/pub/linux/kernel/people/ck/patches/2.6/2.6.32/2.6.32-ck1/patches/ ck patches].}}<br />
<br />
===Verynice===<br />
[http://thermal.cnde.iastate.edu/~sdh4/verynice/ Verynice] is a daemon, available on [http://aur.archlinux.org/packages.php?ID=6403 AUR], for dynamically adjusting the nice levels of executables. The nice level represent the priority of the executable when allocating CPU resources. Simply define executables for which responsiveness is important, like X or multimedia applications, as ''goodexe'' in {{filename|/etc/verynice.conf}}. Similarly, CPU-hungry executables running in the background, like make, can be defined as ''badexe''. This prioritisation greatly improves system responsiveness under heavy load.<br />
<br />
==Network==<br />
See relevant section in [[General Recommendations#Networking|General Recomendations]].<br />
<br />
==Graphics==<br />
<br />
===Xorg.conf configuration===<br />
Graphic performance heavily depends on the settings in {{Filename|/etc/X11/xorg.conf}}. There are tutorials for [[Nvidia]], [[ATI]] and [[Intel]] cards. Improper settings may stop Xorg from working, so caution is advised.<br />
<br />
===Driconf===<br />
Driconf is a small utility that allows you to change the direct rendering settings for open source drivers. Enabling HyperZ can drastically improve performance.<br />
<br />
===GPU Overclocking===<br />
Overclocking a graphics card is typically more expedient than with a CPU, since there are readily accessible software packages which allow for on-the-fly GPU clock adjustments. For ATI users, get [http://aur.archlinux.org/packages.php?ID=2128 rovclock], and Nvidia users should get nvclock in the extra repository. <br />
<br />
The changes can be made permanent by running the appropriate command after X boots, for example by adding it to {{Filename|~/.xinitrc}}. A safer approach would be to only apply the overclocked settings when needed.<br />
<br />
==RAM and swap==<br />
<br />
=== Swappiness ===<br />
<br />
The swappiness represent how much the kernel prefers swap to RAM. Setting it to a very low value, meaning the kernel will almost always use RAM, is known to improve responsiveness on many systems. To do that, simply add those line to {{Filename|/etc/sysctl.conf}}:<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
To test and more on why this may work, take a look at this [http://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that article].<br />
<br />
===Compcache===<br />
[http://code.google.com/p/compcache/ Compcache] is a kernel module that creates a swap into the RAM and compresses it. That means that part of the RAM can hold much more information, but uses more CPU. Still, is it much quicker than a hard drive swap. If a system often falls back to swap, this could improve responsiveness. Compcache is available on [http://aur.archlinux.org/packages.php?ID=19248 AUR], should be added to the DAEMONS array, and needs to be recompiled after each kernel upgrade. It is also possible tell compcache to fall back on the hard drive swap when full. This is also a good way to reduce disk read/write cycles on SSDs.<br />
<br />
===Mounting /tmp to RAM===<br />
This will make your system a tiny bit faster, but will take up some of your RAM. It also reduces disk read/write cycles, and is therefore a good choice if using an SSD or if you have RAM to spare. Simply add this line to {{Filename|/etc/fstab}} and reboot:<br />
tmpfs /tmp tmpfs defaults,noatime,mode=1777 0 0<br />
<br />
===Using the graphic card's RAM===<br />
In the unlikely case that you have very little RAM and a surplus of video RAM, you can use the latter as swap. See [[Swap on video ram]].<br />
<br />
=== Preloading ===<br />
Preloading is the action of of putting and keeping target files into the RAM. The practical use is that preloaded applications always start very quickly, because reading from the RAM is always quicker than from the hard drive. However, part of your RAM will be dedicated to this task, but no more than if you kept the application open. Therefore, preloading is best used with heavy, often-used applications, like firefox and openoffice.<br />
==== Go-preload ====<br />
[http://aur.archlinux.org/packages.php?ID=34207 Go-preload] is a small daemon created in the [http://forums.gentoo.org/viewtopic-t-789818-view-next.html?sid=5457cff93039fc7d4a3e445ef90f9821 gentoo forum]. To use it, first run this command in a terminal for each program you want to preload at boot:<br />
# gopreload-prepare program<br />
Then, as instructed, press enter when the program is fully loaded. This will add a list of files needed by the program in {{Filename|/usr/share/gopreload/enabled}}. To load all lists at boot, simply add gopreload to your DAEMONS array in {{Filename|/etc/rc.conf}}. To disable the loading of a program, remove the appropriate list in {{Filename|/usr/share/gopreload/enabled}}, or move it to {{Filename|/usr/share/gopreload/disabled}}.<br />
====Preload====<br />
A more automated, albeit less KISS, approach is used by [[Preload]]. All you have to do is add it to your DAEMONS array in {{Filename|/etc/rc.conf}}. It will monitor the most used files on your system, and with time build its own list of files to preload at boot.<br />
<br />
==Boot time==<br />
You can find tutorials with good tips [[Tweaking for a faster boot time|here]] and [[Speedup boot|here]].<br />
<br />
===Suspend to ram===<br />
The best way to reduce boot time is not booting at all. Consider [[Suspend to RAM|suspending your system to ram]] instead.<br />
<br />
===Kernel boot options===<br />
Some boot options can decrease kernel boot time. The {{Codeline|fastboot}} option usually can take off one second or so. Also, if you see a message saying "Waiting 8s for device XXX" at boot, adding {{Codeline|<nowiki>rootdelay=1</nowiki>}} can reduce the waiting time, but be careful, as it may break the booting process. Those options are set in {{Filename|/boot/grub/menu.lst}} or {{Filename|/etc/lilo.conf}}, depending on which bootloader you use.<br />
<br />
===Custom kernel===<br />
Compiling a custom kernel will reduce boot time and memory usage, but can be long, complicated and even painful. It usually is not worth the effort, but can be very interesting and a great learning experience. If you really know what you are doing, start [[Kernel Compilation|here]].<br />
<br />
==Application-specific tips==<br />
===Firefox===<br />
The [[Firefox]] article offers good tips; most notably [[Firefox#Speed up rendering by disabling pango |disabling pango]], [[Firefox#Speed-Up Firefox by Defragmenting the Profile's SQLite Databases|cleaning the sqlite database]], and using [[Firefox#Firefox customized for Speed|firefox-pgo]]. See also: [[Speed-up Firefox using tmpfs]], and [[Firefox Tips and Tweaks#Turning off anti-phishing to speedup Firefox|Turning off anti-phishing]].<br />
<br />
===Gcc/Makepkg===<br />
See [[Ccache]].<br />
<br />
===Mkinitcpio===<br />
User josh_ from the forum as made impressive changes to the mkinitcpio script, making it two or three times faster. While waiting for these changes to be implemented, you can get them [http://bbs.archlinux.org/viewtopic.php?id=79898 here].<br />
<br />
===OpenOffice===<br />
See [[OpenOffice#Speed up OpenOffice|Speed up OpenOffice]].<br />
<br />
===Pacman===<br />
See [[Improve Pacman Performance]].<br />
<br />
===SSH===<br />
See [[SSH#Speed up SSH|Speed up SSH]].</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Lighttpd_for_SSL_and_non-SSL&diff=106503Lighttpd for SSL and non-SSL2010-05-17T17:50:26Z<p>TaylanUB: /* Step 2: Add a user */</p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{accuracy}}<br />
<br />
==What is Lighttpd?==<br />
The lighttpd website gives a good definition.<br />
<br />
<pre><br />
"lighttpd a secure, fast, compliant and very flexible web-server which has been optimized<br />
for high-performance environments. It has a very low memory footprint compared to other<br />
webservers and takes care of cpu-load. Its advanced feature-set (FastCGI, CGI, Auth,<br />
Output-Compression, URL-Rewriting and many more) make lighttpd the perfect<br />
webserver-software for every server that is suffering load problems."<br />
-- http://www.lighttpd.net/<br />
</pre><br />
<br />
==Goals==<br />
The goal of this how to is to setup lighttpd for servicing both ssl and non-ssl connections. php will be setup via a fastcgi prespawn, that will service both ssl and non-ssl connections. The php-fcgi instances will be run as a different user than the lighttpd daemon. eaccelerator will also be setup to increase the efficiency of our php scripts.<br />
<br />
===Required packages:===<br />
*lighttpd (compiled for mysql support)<br />
*php-cgi (compiled for cgi/fcgi support)<br />
*fast-cgi<br />
*eaccelerator<br />
*ssl<br />
<br />
If you have trouble finding a package specific to this How-To, try the resources link at the bottom.<br />
<br />
==Lighttpd Installation==<br />
===Step 1: Install the lighttpd package===<br />
I have lighttpd in my repository, and there is also a version in the AUR, courtesy of klapmuetz. The one in my repository currently contains a few extra things that we will be utilizing for this how to, but they can be obtained individually from my subversion repository if needed. The compiled binaries are the same in the two packages. Just a few different scripts and helper files.<br />
# pacman -S lighttpd<br />
<br />
===Step 2: Add a user===<br />
We are going to be running lighttpd as a non-root user. So, we first need to create a user for this purpose, and a home directory. We will create a group too.<br />
# groupadd lighttpd<br />
# useradd -g lighttpd -d /home/lighttpd -s /bin/false lighttpd<br />
<br />
{{Note|lighttpd uses the user 'http' on default.}}<br />
<br />
===Step 3: Ensure permissions are properly set.===<br />
# chown -R lighttpd.lighttpd /home/lighttpd<br />
<br />
===Step 4: Edit the lighttpd.conf file located at /etc/lighttpd/lighttpd.conf===<br />
*Uncomment mod_fastcgi and mod_compress.<br />
*Uncomment and change server.username to "lighttpd"<br />
*Uncomment and change server.groupname to "lighttpd"<br />
*Uncomment compress.cache-dir and compress.filetype<br />
Save your changes<br />
<br />
===Step 5: Change logfile permissions===<br />
Since we are running the daemon as lighttpd user, we need to change the logfile permissions.<br />
# chown lighttpd /var/log/lighttpd/*.log<br />
<br />
'''Edit:''' You also need to edit the /etc/logrotate.d/lighttpd file, line 2. Change the user's 'nobody nobody' to lighttpd. This has to be done or the next time the log is rotated the permissions will be reset and the dameon will not start.<br />
<br />
From:<br />
<pre><br />
/var/log/lighttpd/*log {<br />
create 644 nobody nobody<br />
compress<br />
postrotate<br />
/bin/kill -HUP `cat /var/run/lighttpd.pid 2>/dev/null` 2> /dev/null || true<br />
endscript<br />
}<br />
</pre><br />
To:<br />
<pre><br />
/var/log/lighttpd/*log {<br />
create 644 lighttpd lighttpd<br />
compress<br />
postrotate<br />
/bin/kill -HUP `cat /var/run/lighttpd.pid 2>/dev/null` 2> /dev/null || true<br />
endscript<br />
}<br />
</pre><br />
<br />
===Step 6: Start the daemon.===<br />
# /etc/rc.d/lighttpd start<br />
Check /var/log/lighttpd/error.log for any errors. Try bringing up a web page on the server. The default index page should come up. Hooray! You got lighttpd running as a user.<br />
<br />
It is currently only servicing port 80 (non-ssl), so next we add ssl to the mix.<br />
<br />
==Lighttpd SSL==<br />
===Step 1: First things first===<br />
Lighttpd can only service either ssl or non-ssl at one time. No problem. We can easily run two daemons. We need to do a little maintenance work in the lighttpd user directory first.<br />
<br />
'''Update:''' This is no longer true. The version of lighttpd currently in the repositories can handle both ssl and nonssl in the same daemon. Most of what follows is not neccessary, although you may want to have separate directories for SSL and nonSSL data so that you do not serve up secure content unsecured by accident. See "SSL: Alternative Method" below. '''End Update'''<br />
<br />
# /etc/rc.d/lighttpd stop<br />
# mkdir -p /home/lighttpd/ssl/html /home/lighttpd/ssl/cache<br />
# mkdir /home/lighttpd/nonssl<br />
# mv /home/lighttpd/html /home/lighttpd/nonssl<br />
# mv /home/lighttpd/cache /home/lighttpd/nonssl<br />
# cp /home/lighttpd/nonssl/html/index.html /home/lighttpd/ssl/html<br />
# chown -R lighttpd.lighttpd /home/lighttpd<br />
<br />
===Step 2: Copy things===<br />
Now we need to setup a separate config script, and init script for the ssl version.<br />
# cp /usr/sbin/lighttpd /usr/sbin/lighttpd-ssl<br />
# cp /etc/rc.d/lighttpd /etc/rc.d/lighttpd-ssl<br />
# cp /etc/conf.d/lighttpd /etc/conf.d/lighttpd-ssl<br />
# cp /etc/lighttpd/lighttpd.conf /etc/lighttpd/lighttpd-ssl.conf<br />
<br />
===Step 3: Edit /etc/conf.d/lighttpd-ssl===<br />
Change to the following:<br />
DAEMON_NAME="lighttpd-ssl"<br />
DAEMON_CONF="/etc/lighttpd/lighttpd-ssl.conf"<br />
DAEMON_PATH="/usr/sbin/lighttpd-ssl"<br />
<br />
===Step 4: Edit /etc/rc.d/lighttpd-ssl===<br />
Change to the following:<br />
[ -f /etc/conf.d/lighttpd-ssl ] && . /etc/conf.d/lighttpd-ssl<br />
<br />
===Step 5: Edit /etc/lighttpd/lighttpd-ssl.conf===<br />
Change to the following:<br />
server.document-root = "/home/lighttpd/ssl/html"<br />
server.errorlog = "/var/log/lighttpd/error-ssl.log"<br />
accesslog.filename = "/var/log/lighttpd/access-ssl.log"<br />
server.pid-file = "/var/run/lighttpd-ssl.pid"<br />
compress.cache-dir = "/home/lighttpd/ssl/cache"<br />
ssl.engine = "enable"<br />
ssl.pemfile = "/home/lighttpd/ssl/server.pem"<br />
<br />
===Step 6: Edit /etc/lighttpd/lighttpd.conf===<br />
Now that the ssl version is correct, we have to slightly modify the non-ssl version to deal with our new directory structure.<br />
server.document-root = "/home/lighttpd/nonssl/html"<br />
compress.cache-dir = "/home/lighttpd/nonssl/cache"<br />
<br />
===Step 7: Create the self signed certificate===<br />
# cd /home/lighttpd/ssl<br />
# openssl req -new -x509 -keyout server.pem -out server.pem -days 365 -nodes<br />
# chown lighttpd.lighttpd server.pem<br />
# chmod 600 server.pem<br />
<br />
===Step 8: Start the daemons===<br />
# /etc/rc.d/lighttpd start<br />
# /etc/rc.d/lighttpd-ssl start<br />
Check /var/log/lighttpd/error.log and /var/log/lighttpd/error-ssl.log for errors.<br />
<br />
===Step 9: Test===<br />
Try navigating with a web browser to both the http and https address of your server. Hoory!<br />
You just setup for ssl and nonssl serving using lighttpd.<br />
<br />
===SSL: Alternative Method===<br />
Create folders for SSL/html and SSL/cache as above.<br />
Create ssl key (.pem file as above)<br />
Edit /etc/lighttpd/lighttpd.conf<br />
Find the line ssl.engine, and change that area to <br />
$SERVER["socket"] == ":443" {<br />
server.document-root = "/srv/ssl/html" # use your ssl directory here<br />
ssl.engine = "enable"<br />
ssl.pemfile = "/etc/ssl/private/lighttpd.pem" # use the path where you created your pem file<br />
}<br />
<br />
Then restart lighttpd with /etc/rc.d/lighttpd restart<br />
<br />
===SSL: Last step, redirection===<br />
The last step is to set up redirection. The following steps will redirect only certain pages or directories to ssl. For the example, we'll use a squirrelmail directory.<br />
Edit /etc/lighttpd/lighttpd.conf<br />
Uncomment mod_redirect<br />
Then add the following lines:<br />
$SERVER["socket"] == ":80" {<br />
$HTTP["url"] =~ "^/squirrelmail/*" {<br />
$HTTP["host"] =~ "(.*)" {<br />
url.redirect = ( "^/(.*)" => "https://%1/$1" )<br />
} } <br />
}<br />
<br />
This will redirect any normal http requests for squirrelmail to https://host/squirrelmail<br />
<br />
==FastCGI and PHP with eAcceleration==<br />
===Step 1: Install fastcgi and php compiled for cgi/fcgi===<br />
<br />
You may first need to uncomment these lines in /etc/pacman.conf.<br />
[community]<br />
Include = /etc/pacman.d/community<br />
<br />
Note: php-cgi is now obsolete, use php<br />
# pacman -S fcgi php eaccelerator<br />
# /etc/rc.d/lighttpd-ssl start<br />
<br />
===N.B eaccelerator currently doesnt work with php 5.1.x===<br />
<br />
===Step 2: Create a php user===<br />
# mkdir -p /home/phpuser/eaccelerator/cache<br />
# groupadd phpuser<br />
# useradd -g phpuser -d /home/phpuser -s /bin/false phpuser<br />
# chown -R phpuser.phpuser /home/phpuser<br />
<br />
===Step 3: Add eaccelerator to php.ini and make additional changes===<br />
Note. Make sure you use >> in the following command. If you use a single >, you will overwrite, instead of append. not good.<br />
# cat /etc/php/conf.d/eaccelerator.ini >> /etc/php/php.ini<br />
<br />
===Step 4: Edit /etc/php.ini===<br />
zlib.output_compression = On<br />
cgi.fix_pathinfo=1<br />
eaccelerator.cache_dir="/home/phpuser/eaccelerator/cache"<br />
<br />
I additionally set <code>safe_mod</code> to <code>On</code> in my setup, but this is not required.<br />
<br />
===Step 5: Setup fcgi-php prespawns===<br />
Now we are going to setup a mechanism for spawning php instances to handle requests.<br />
# chmod 755 /etc/rc.d/spawn-php<br />
<br />
===Step 6: Modify /etc/conf.d/spawn-php===<br />
You need to edit a few parts of the spawn-php init script<br />
<br />
Change the following to reflect the php user you created earlier:<br />
USERID=phpuser<br />
GROUPID=phpuser<br />
FCGISOCKET="/tmp/php-fastcgi.socket"<br />
<br />
===Step 7: Spawn the php instances===<br />
# /etc/rc.d/spawn-php start<br />
You should get some sort of message saying that is has started child processes.<br />
<br />
To check to see if it indeed has (the spawn script is a bit buggy yet, I haven't worked out the kinks in the wrapper portion).<br />
$ ps afx || grep php<br />
3192 ? Ss 0:00 /usr/bin/php<br />
3193 ? S 0:00 \_ /usr/bin/php<br />
3194 ? S 0:00 \_ /usr/bin/php<br />
3195 ? S 0:00 \_ /usr/bin/php<br />
3196 ? S 0:00 \_ /usr/bin/php<br />
3197 ? S 0:00 \_ /usr/bin/php<br />
3198 ? S 0:00 \_ /usr/bin/php<br />
3199 ? S 0:00 \_ /usr/bin/php<br />
3200 ? S 0:00 \_ /usr/bin/php<br />
3201 ? S 0:00 \_ /usr/bin/php<br />
3202 ? S 0:00 \_ /usr/bin/php<br />
3203 ? S 0:00 \_ /usr/bin/php<br />
3204 ? S 0:00 \_ /usr/bin/php<br />
<br />
===Step 8: Setup lighttpd and lighttpd-ssl to use the instances===<br />
Uncomment both /etc/lighttpd/lighttpd.conf and /etc/lighttpd/lighttpd-ssl.conf to the following:<br />
<pre><br />
fastcgi.server = ( ".php" =><br />
( "localhost" =><br />
(<br />
"socket" => "/tmp/php-fastcgi.socket",<br />
"bin-path" => "/usr/bin/php-cgi"<br />
)<br />
)<br />
)<br />
<br />
</pre><br />
<br />
===Step 9: Restart both daemons===<br />
# /etc/rc.d/lighttpd restart<br />
# /etc/rc.d/lighttpd-ssl restart<br />
Check /var/log/lighttpd/error.log and /var/log/lighttpd/error-ssl.log for errors.<br />
<br />
===Step 10: Try a php page.===<br />
Create the following php page, name it index.php, and place a copy in both /home/lighttpd/ssl/html and /home/lighttpd/nonssl/html<br />
<?php<br />
phpinfo();<br />
?><br />
Try navigating with a web browser to both the http and https address of your server. If you see the phpinfo page, then you are almost done! Hooray!<br />
<br />
<br />
===N.B eaccelerator currently doesnt work with php 5.1.x===<br />
<br />
===Step 11: Check on eaccelerator caching..===<br />
# ls -l /home/phpuser/eaccelerator/cache<br />
If the above command outputs the following:<br />
-rw------- 1 phpuser phpuser 456 2005-05-05 14:53 eaccelerator-277.58081<br />
-rw------- 1 phpuser phpuser 452 2005-05-05 14:53 eaccelerator-277.88081<br />
Then you are done! Eaccelerator is happily caching your php scripts to help speed things up.<br />
Good luck with your setup. :D<br />
<br />
====Resources:====<br />
[[fastcgi and lighttpd]] - klapmuetz's how to on using lighttpd for ruby on rails. It also has good information on lighttpd setup.<br><br />
[http://e.solarblue.net/index.php/arch-repo/ Cacuts Repo Information] - Information about my Archlinuxrepository. Packages used in this howto can be found there.</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Tweaking_for_a_faster_boot_time&diff=105244Tweaking for a faster boot time2010-05-02T18:14:12Z<p>TaylanUB: /* /lib/udev/load-modules.sh */</p>
<hr />
<div>[[Category:HOWTOs (English)]][[Category:Boot process (English)]][[Category:Kernel (English)]]<br />
{{merge|Speedup boot|Speedup boot}}<br />
== Summary ==<br />
<br />
This is the result of 2 days of tweaking for a faster boot time.<br />
<br />
Why: just because you can, for other people to see what is possible with Arch Linux.<br />
<br />
See the [http://bbs.archlinux.org/viewtopic.php?id=62518 forumtopic], the scripts may differ from the one in the topic because of further tweaking.<br />
<br />
Grub to agetty in 13s (coming from 24s) on a Dell Inspiron 1525 (Core2Duo T5450 1,66 Ghz) (bootcharts in same [http://bbs.archlinux.org/viewtopic.php?id=62518 forumtopic])<br />
<br />
Warning: the scripts below may or may not be out of date.<br />
<br />
== /etc/inittab ==<br />
<br />
This will not increase the speed that much, but every little bit helps.<br />
<br />
#<br />
# /etc/inittab<br />
#<br />
<br />
# Boot to console<br />
id:3:initdefault:<br />
<br />
# Use once instead of wait<br />
rc::sysinit:/etc/rc.sysinit<br />
rs:S1:once:/etc/rc.single<br />
rm:2345:once:/etc/rc.multi<br />
rh:06:once:/etc/rc.shutdown<br />
su:S:once:/sbin/sulogin -p<br />
<br />
#Start lesser agetty's and login from agetty<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
<br />
ca::ctrlaltdel:/sbin/shutdown -t3 -r now<br />
<br />
# End of file<br />
<br />
Alternatively instead of using agetty, use [http://www.fefe.de/fgetty/ fgetty] which is smaller and fast by replacing:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
with<br />
1:23:respawn:/sbin/fgetty tty1<br />
<br />
== /etc/mkinitcpio.conf ==<br />
<br />
This didn't really speed up my boot, but on some systems it does.<br />
<br />
This didn't work for me on Kernel 2.6.27 and needed to put Udev back in HOOKS, never tried to figure out why it didn't work. I tried again when installing kernel 2.6.28 and that did work. If you use a USB keyboard, add 'usbinput' in HOOKS<br />
<br />
My boot device was a separate partion on a SATA drive formatted as ext3. I needed to enable AHCI in my BIOS, before this it used a ATA module.<br />
<br />
#<br />
# /etc/mkinitcpio<br />
#<br />
<br />
#Load necessary modules to mount boot device<br />
MODULES="ahci sd-mod ext3"<br />
BINARIES=""<br />
FILES=""<br />
HOOKS="base"<br />
<br />
# End of file<br />
<br />
== /etc/rc.sysinit ==<br />
<br />
Here I had the most work, and gained the most speed.<br />
<br />
I took out the stuff I didn't use: LVM, RAID and Encrypted devices.<br />
<br />
Including default behavior for the clock, LOCALE, KEYMAP and HOSTNAME directly into this file, so it doesn't have to load it from [[#/etc/rc.conf]].<br />
<br />
I've added a lot of ampersands to send these processes to the background. Watch out with what you send to the background, because otherwise later commands that depend on the backgrounded process might be called before the process is running. The first time '/sbin/hwclock' and '/sbin/udevadm settled' are called are examples of that.<br />
<br />
Also I've put '/sbin/udevadm trigger &' earlier and in background, so it had the time to load until '/sbin/udevadm settled' is called. <br />
<br />
Putting in 'status "Updating Module Dependencies" /sbin/depmod -A' in comment requires you to run it when you install new modules. It is not a required for boot, so I don't know what it does there in first time.<br />
<br />
#!/bin/bash<br />
#<br />
# /etc/rc.sysinit<br />
#<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
echo " "<br />
printhl "Arch Linux\n"<br />
printhl "${C_H2}http://www.archlinux.org"<br />
printhl "Copyright 2002-2007 Judd Vinet"<br />
printhl "Copyright 2007-2008 Aaron Griffin"<br />
printhl "Distributed under the GNU General Public License (GPL)"<br />
printsep<br />
<br />
# mount /proc, /sys and our RAM /dev<br />
/bin/mount -n -t ramfs none /dev<br />
/bin/mount -n -t proc none /proc<br />
/bin/mount -n -t sysfs none /sys<br />
<br />
# Create our default nodes that minilogd may need<br />
/bin/mknod /dev/null c 1 3<br />
/bin/mknod /dev/zero c 1 5<br />
/bin/mknod /dev/console c 5 1<br />
<br />
# More initial /dev setup that udev doesn't do<br />
/bin/ln -snf /proc/self/fd /dev/fd<br />
/bin/ln -snf /proc/self/fd/0 /dev/stdin<br />
/bin/ln -snf /proc/self/fd/1 /dev/stdout<br />
/bin/ln -snf /proc/self/fd/2 /dev/stderr<br />
/bin/ln -snf /proc/kcore /dev/core<br />
/bin/mkdir /dev/pts<br />
/bin/mkdir /dev/shm<br />
<br />
# start up our mini logger until syslog takes over<br />
/sbin/minilogd<br />
<br />
# anything more serious than KERN_WARNING goes to the console<br />
# 'verbose' cmdline parameter enables more messages<br />
if /bin/grep -q " verbose" /proc/cmdline; then<br />
/bin/dmesg -n 8<br />
else<br />
/bin/dmesg -n 3<br />
fi<br />
<br />
# enable rtc access<br />
/sbin/modprobe rtc-cmos >/dev/null 2>&1<br />
RTC_MAJOR=$(/bin/grep -w rtc /proc/devices 2>/dev/null); RTC_MAJOR="${RTC_MAJOR%% *}"<br />
if [ -n "$RTC_MAJOR" ]; then<br />
/bin/mkdir /dev/misc/<br />
/bin/mknod /dev/misc/rtc0 c $RTC_MAJOR 0<br />
/bin/ln -s /dev/misc/rtc0 /dev/rtc<br />
fi<br />
<br />
# Set clock early to fix some bugs with filesystem checks<br />
# Clock is set again later to match rc.conf<br />
if [ -f /etc/localtime ]; then<br />
/sbin/hwclock --hctosys --localtime --directisa --noadjfile<br />
fi<br />
<br />
echo > /proc/sys/kernel/hotplug<br />
<br />
if [ -x /sbin/udevadm -a -d /sys/block ]; then<br />
# We have udev and /sys appears to be mounted, use UDev<br />
stat_busy "Starting UDev Daemon"<br />
/sbin/udevd --daemon<br />
/sbin/udevadm trigger &<br />
udevstart="$(/bin/date +%s%0N)"<br />
stat_done<br />
else<br />
# Static /dev, our last resort<br />
status "Using static /dev filesystem" true<br />
fi<br />
<br />
# Load modules from the MODULES array defined in rc.conf<br />
if ! [ "$load_modules" = "off" ]; then<br />
if [ -f /proc/modules ]; then<br />
stat_busy "Loading Modules"<br />
for mod in "${MODULES[@]}"; do<br />
if [ "$mod" = "${mod#!}" ]; then<br />
/sbin/modprobe $mod &<br />
fi<br />
done<br />
stat_done<br />
fi<br />
if [ -d /proc/acpi ]; then<br />
stat_busy "Loading standard ACPI modules"<br />
ACPI_MODULES="ac battery button fan processor thermal"<br />
k="$(echo $BLACKLIST ${MOD_BLACKLIST[@]} | /bin/sed 's|-|_|g')"<br />
j="$(echo ${MODULES[@]} | /bin/sed 's|-|_|g')"<br />
#add disabled MODULES (!) to blacklist - much requested feature<br />
for m in ${j}; do<br />
[ "$m" != "${m#!}" ] && k="${k} ${m#!}"<br />
done<br />
# add disablemodules= from commandline to blacklist<br />
k="${k} $(echo ${disablemodules} | /bin/sed 's|-|_|g' | /bin/sed 's|,| |g')"<br />
for n in ${ACPI_MODULES}; do<br />
if ! echo ${k} | /bin/grep "\<$n\>" 2>&1 >/dev/null; then<br />
/sbin/modprobe $n > /dev/null 2>&1 &<br />
fi<br />
done<br />
stat_done<br />
fi<br />
fi<br />
<br />
# run udev uevents<br />
if /bin/pidof -o %PPID /sbin/udevd >/dev/null; then<br />
stat_busy "Loading UDev uevents"<br />
/sbin/udevadm settle<br />
stat_done<br />
udevend="$(/bin/date +%s%0N)"<br />
printhl " UDev uevent processing time: $((($udevend-$udevstart)/1000000))ms"<br />
fi<br />
<br />
# bring up the loopback interface<br />
if [ -d /sys/class/net/lo ]; then<br />
stat_busy "Bringing up loopback interface"<br />
/sbin/ifconfig lo 127.0.0.1 up &<br />
if [ $? -ne 0 ]; then<br />
stat_fail<br />
else<br />
stat_done<br />
fi<br />
fi<br />
<br />
status "Mounting Root Read-only" /bin/mount -n -o remount,ro /<br />
<br />
FORCEFSCK=<br />
[ -f /forcefsck ] && FORCEFSCK="-- -f"<br />
NETFS="nonfs,nonfs4,nosmbfs,nocifs,nocodafs,noncpfs,nosysfs,noshfs,nofuse,nofuseblk"<br />
<br />
if [ -x /sbin/fsck ]; then<br />
stat_busy "Checking Filesystems"<br />
if /bin/grep -qw quiet /proc/cmdline; then<br />
/sbin/fsck -A -T -C -a -t $NETFS $FORCEFSCK >/dev/null 2>&1<br />
else<br />
/sbin/fsck -A -T -C -a -t $NETFS $FORCEFSCK 2>/dev/null<br />
fi<br />
fsckret=$?<br />
if [ ${fsckret} -gt 1 ]; then<br />
stat_fail<br />
if [ $((${fsckret}&2)) -eq 2 ]; then<br />
echo<br />
echo "********************** REBOOT REQUIRED *********************"<br />
echo "* *"<br />
echo "* The system will be rebooted automatically in 15 seconds. *"<br />
echo "* *"<br />
echo "************************************************************"<br />
echo<br />
/bin/sleep 15<br />
else<br />
echo<br />
echo "***************** FILESYSTEM CHECK FAILED ****************"<br />
echo "* *"<br />
echo "* Please repair manually and reboot. Note that the root *"<br />
echo "* file system is currently mounted read-only. To remount *"<br />
echo "* it read-write type: mount -n -o remount,rw / *"<br />
echo "* When you exit the maintenance shell the system will *"<br />
echo "* reboot automatically. *"<br />
echo "* *"<br />
echo "************************************************************"<br />
echo<br />
/sbin/sulogin -p<br />
fi<br />
echo "Automatic reboot in progress..."<br />
/bin/umount -a<br />
/bin/mount -n -o remount,ro /<br />
/sbin/reboot -f<br />
exit 0<br />
fi<br />
stat_done<br />
fi<br />
<br />
stat_busy "Mounting Local Filesystems"<br />
/bin/mount -n -o remount,rw /<br />
/bin/rm -f /etc/mtab*<br />
# make sure / gets written to /etc/mtab<br />
/bin/mount -o remount,rw /<br />
# Write /proc, /sys and /dev to /etc/mtab<br />
if [ -e /proc/mounts ]; then<br />
/bin/grep -e "/proc " -e "/sys " -e "/dev " /proc/mounts >> /etc/mtab<br />
fi<br />
# now mount all the local filesystems<br />
/bin/mount -a -t $NETFS<br />
stat_done<br />
<br />
status "Activating Swap" /sbin/swapon -a &<br />
<br />
stat_busy "Configuring System Clock"<br />
if [ ! -f /var/lib/hwclock/adjtime ]; then<br />
echo "0.0 0 0.0" > /var/lib/hwclock/adjtime &<br />
fi<br />
<br />
/bin/rm -f /etc/localtime<br />
/bin/cp "/usr/share/zoneinfo/Europe/Brussels" /etc/localtime<br />
/sbin/hwclock --hctosys --localtime --directisa<br />
stat_done<br />
<br />
if [ -f /var/run/random-seed ]; then<br />
stat_busy "Initializing Random Seed"<br />
/bin/cat /var/run/random-seed >/dev/urandom &<br />
stat_done<br />
fi<br />
<br />
stat_busy "Removing Leftover Files"<br />
/bin/rm -f /etc/nologin &>/dev/null &<br />
/bin/rm -f /etc/shutdownpid &>/dev/null &<br />
/bin/rm -f /var/lock/* &>/dev/null &<br />
/bin/rm -rf /tmp/* /tmp/.* &>/dev/null &<br />
/bin/rm -f /forcefsck &>/dev/null &<br />
(cd /var/run && /usr/bin/find . ! -type d -exec /bin/rm -f -- {} \; )<br />
: > /var/run/utmp &<br />
# Keep {x,k,g}dm happy with xorg<br />
/bin/mkdir /tmp/.ICE-unix && /bin/chmod 1777 /tmp/.ICE-unix<br />
/bin/mkdir /tmp/.X11-unix && /bin/chmod 1777 /tmp/.X11-unix<br />
stat_done<br />
<br />
#status "Updating Shared Library Links" /sbin/ldconfig<br />
#status "Updating Module Dependencies" /sbin/depmod -A &<br />
<br />
status "Setting Hostname: Pinguin" /bin/hostname "Pinguin" &<br />
<br />
# Flush old locale settings<br />
: >/etc/profile.d/locale.sh<br />
/bin/chmod 755 /etc/profile.d/locale.sh<br />
# Set user defined locale<br />
[ -z "$LOCALE" ] && LOCALE="en_US"<br />
stat_busy "Setting Locale: en_US"<br />
echo "export LANG=en_US" >>/etc/profile.d/locale.sh<br />
stat_done<br />
<br />
stat_busy "Setting Consoles to UTF-8 mode"<br />
# UTF-8 consoles are default since 2.6.24 kernel<br />
# this code is needed not only for older kernels,<br />
# but also when user has set vt.default_utf8=0 but LOCALE is *.UTF-8.<br />
for i in $(/usr/bin/seq 0 63); do<br />
usr/bin/kbd_mode -u < /dev/vc/${i}<br />
printf "\e%%G" > /dev/vc/${i}<br />
done<br />
# the $CONSOLE check helps us avoid this when running scripts from cron<br />
echo 'if [ "$CONSOLE" = "" -a "$TERM" = "linux" -a -t 1 ]; then printf "\e%%G"; fi' >>/etc/profile.d/locale.sh<br />
stat_done<br />
<br />
status "Loading Keyboard Map: be-latin1" /bin/loadkeys -q -u "be-latin1" &<br />
<br />
# Adding persistent network/cdrom generated rules<br />
if [ -f "/dev/.udev/tmp-rules--70-persistent-cd.rules" ]; then<br />
stat_busy "Adding persistent cdrom udev rules"<br />
/bin/cat /dev/.udev/tmp-rules--70-persistent-cd.rules >> /etc/udev/rules.d/70-persistent-cd.rules<br />
stat_done<br />
fi<br />
if [ -f "/dev/.udev/tmp-rules--70-persistent-net.rules" ]; then<br />
stat_busy "Adding persistent network udev rules"<br />
/bin/cat /dev/.udev/tmp-rules--70-persistent-net.rules >> /etc/udev/rules.d/70-persistent-net.rules<br />
stat_done<br />
fi<br />
<br />
# Save our dmesg output from this boot<br />
if [ -f /var/log/dmesg.log ]; then<br />
/bin/rm /var/log/dmesg.log<br />
fi<br />
/bin/dmesg > /var/log/dmesg.log &<br />
<br />
# End of file<br />
<br />
== /etc/rc.conf ==<br />
<br />
I've stripped out everything here that I included by default in [[#/etc/rc.sysinit]] and [[#/etc/rc.shutdown]].<br />
<br />
In this version the modules I need for my laptop are in the MODULES array, so there is no need to turn MOD_AUTOLOAD on. I could strip out some modules, but didn't find the time to figure that out. The list I got from 'hwdetect --show-modules-order'. I did take out snd-hda-codec and dock, because these gave an error on load.<br />
<br />
#<br />
# /etc/rc.conf<br />
#<br />
<br />
MOD_AUTOLOAD="no"<br />
<br />
MODULES=(ac battery button processor thermal video wmi agpgart intel-agp dcdbas hid usbhid i2c-i801 i2c-core evdev <br />
ff-memless joydev pcspkr psmouse serio_raw led-class mmc_core ricoh_mmc sdhci-pci sdhci rtc-cmos rtc-core rtc-lib <br />
output iTCO_vendor_support iTCO_wdt snd-mixer-oss snd-pcm-oss snd-hwdep snd-page-alloc snd-pcm snd-timer snd snd-hda-<br />
intel soundcore pata_acpi ata_generic ahci ata_piix sky2 mac80211 rfkill usb-storage usbhid usbcore ehci-hcd uhci-hcd <br />
vboxdrv vboxnetflt)<br />
<br />
DAEMONS=(syslog-ng @hal @fam @crond @alsa)<br />
<br />
# End of file<br />
<br />
In this version the modules are discovered by the system itself. I guess this is the smallest a usable /etc/rc.conf can get.<br />
<br />
MOD_AUTOLOAD="yes"<br />
MODULES=()<br />
DAEMONS=(syslog-ng @hal @fam @crond @alsa)<br />
<br />
== /etc/rc.shutdown ==<br />
<br />
This doesn't have anything to do with the boot time, but with [[#/etc/rc.conf]]. By stripping out a lot out, I broke the shutdown script. In meanwhile I've taken out the unnecessary stuff (LVM, ...).<br />
<br />
#!/bin/bash<br />
#<br />
# /etc/rc.shutdown<br />
#<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
# avoid staircase effect<br />
/bin/stty onlcr<br />
<br />
echo " "<br />
printhl "Initiating Shutdown..."<br />
echo " "<br />
<br />
# avoid NIS hanging syslog-ng on shutdown by unsetting the domainname<br />
if [ -x /bin/domainname ]; then<br />
/bin/domainname ""<br />
fi<br />
<br />
if [ -x /etc/rc.local.shutdown ]; then<br />
/etc/rc.local.shutdown<br />
fi<br />
<br />
if [ "$PREVLEVEL" = "3" -o "$PREVLEVEL" = "5" ]; then<br />
# Shutdown daemons<br />
let i=${#DAEMONS[@]}<br />
while [ $i -ge 0 ]; do<br />
if [ "${DAEMONS[$i]:0:1}" != '!' ]; then<br />
ck_daemon ${DAEMONS[$i]#@} || stop_daemon ${DAEMONS[$i]#@}<br />
fi<br />
let i=i-1<br />
done<br />
# find any leftover daemons and shut them down in reverse order<br />
if [ -d /var/run/daemons ]; then<br />
for daemon in $(/bin/ls -1t /var/run/daemons); do<br />
stop_daemon $daemon<br />
done<br />
fi<br />
fi<br />
<br />
# Terminate all processes<br />
stat_busy "Sending SIGTERM To Processes"<br />
/sbin/killall5 -15 &> /dev/null<br />
/bin/sleep 5<br />
stat_done<br />
<br />
stat_busy "Sending SIGKILL To Processes"<br />
/sbin/killall5 -9 &> /dev/null<br />
/bin/sleep 1<br />
stat_done<br />
<br />
stat_busy "Saving Random Seed"<br />
/bin/dd if=/dev/urandom of=/var/run/random-seed count=1 bs=512 2> /dev/null<br />
stat_done<br />
<br />
stat_busy "Saving System Clock"<br />
/bin/rm -f /etc/localtime<br />
/bin/cp "/usr/share/zoneinfo/Europe/Brussels" /etc/localtime<br />
/sbin/hwclock --systohc --localtime --directisa<br />
stat_done<br />
<br />
# removing psmouse module to fix some reboot issues on newer laptops<br />
/sbin/modprobe -r psmouse >/dev/null 2>&1<br />
<br />
# Write to wtmp file before unmounting<br />
/sbin/halt -w<br />
<br />
stat_busy "Deactivating Swap"<br />
/sbin/swapoff -a<br />
stat_done<br />
<br />
stat_busy "Unmounting Filesystems"<br />
/bin/umount -a -r -t noramfs,notmpfs,nosysfs,noproc<br />
stat_done<br />
<br />
stat_busy "Remounting Root Filesystem Read-only"<br />
/bin/mount -n -o remount,ro /<br />
stat_done<br />
<br />
# Power off or reboot<br />
if [ "$RUNLEVEL" = "0" ]; then<br />
printsep<br />
printhl "${C_H2}POWER OFF"<br />
/sbin/poweroff -d -f -h -i<br />
else<br />
printsep<br />
printhl "${C_H2}REBOOTING"<br />
# if kexec is installed and a kernel is loaded, use it<br />
[ -x /sbin/kexec ] && /sbin/kexec -e > /dev/null 2>&1<br />
/sbin/reboot -d -f -i<br />
fi<br />
<br />
# End of file<br />
<br />
== /lib/udev/load-modules.sh ==<br />
<br />
Something little, but improving, here. It takes away the blacklisting function for the MODULES array in [[#/etc/rc.conf]], but when MOD_AUTOLOAD is off it's not used anyway. <br />
<br />
Check [[Speedup_udev#Blacklisting_modules]] if you need blacklisting. I got this tweak from the same page, there are other ways to do this on there.<br />
<br />
#!/bin/sh<br />
#<br />
# /lib/udev/load-modules.sh<br />
#<br />
<br />
/sbin/modprobe $1 &<br />
<br />
# End of file<br />
<br />
= Additional Resources =<br />
* [[The Arch boot process]]<br />
* [[Fast boot without recompiling the kernel]]<br />
* [[Udev]]<br />
* [[Speedup udev]]<br />
* [[Daemons]]<br />
* [[Rc.conf]]<br />
* [[Configuring mkinitcpio]]<br />
* http://bbs.archlinux.org/search.php - a lot of searching :D<br />
* http://kmandla.wordpress.com/howtos/ - some great howtos<br />
* [[Sreadahead]] [http://code.google.com/p/sreadahead/ Google code project] (A AUR package for speeding up the boot process dramatically).<br />
* And others...</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Talk:NTFS-3G&diff=102576Talk:NTFS-3G2010-04-09T22:00:06Z<p>TaylanUB: </p>
<hr />
<div>Anyone else having problems accessing punkrockguy's repository?<br />
<br />
== Default behaviour of mount ==<br />
<br />
The page used to claim that `mount` uses `ntfsmount` from the ntfsprogs package when ntfs-3g is not explicitly stated. This appears to be incorrect (probably outdated), as the ntfs-3g package includes a symlink, /sbin/mount.ntfs, which is used by `mount` on default and points to /bin/ntfs-3g. Correct me if i'm wrong.</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Talk:NTFS-3G&diff=102575Talk:NTFS-3G2010-04-09T21:59:46Z<p>TaylanUB: /* Default behaviour of `mount` */ new section</p>
<hr />
<div>Anyone else having problems accessing punkrockguy's repository?<br />
<br />
== Default behaviour of `mount` ==<br />
<br />
The page used to claim that `mount` uses `ntfsmount` from the ntfsprogs package when ntfs-3g is not explicitly stated. This appears to be incorrect (probably outdated), as the ntfs-3g package includes a symlink, /sbin/mount.ntfs, which is used by `mount` on default and points to /bin/ntfs-3g. Correct me if i'm wrong.</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=NTFS-3G&diff=102573NTFS-3G2010-04-09T21:55:03Z<p>TaylanUB: /* Manual mounting */ Apparently outdated info.</p>
<hr />
<div>[[Category:File systems (English)]]<br />
{{i18n|NTFS Write Support|NTFS-3G}}<br />
<br />
[http://www.tuxera.com/community/ntfs-3g-download/ NTFS-3G] is an open source implementation of Microsoft's NTFS file system that includes read and write support. Because it is considered to be easier to configure and developed write support earlier, users generally prefer NTFS-3G over {{Package Official|ntfsprogs}} ntfsmount. NTFS-3G developers use the FUSE file system to facilitate development and to help with portability. This document will describe how to setup NTFS-3G to work on your computer.<br />
<br />
== Installation ==<br />
<br />
The {{Package Official|ntfs-3g}} package is available in '''Extra''' and can be installed by:<br />
<br />
# pacman -S ntfs-3g<br />
<br />
== Manual mounting ==<br />
<br />
Two options exist for manually mounting NTFS partitions. The traditional:<br />
<br />
# mount -t ntfs-3g /dev/<your-NTFS-partition> /{mnt,...}/<folder><br />
<br />
'ntfs-3g' doesn't need to be explicitly specified, since the {{Codeline|mount}} command by default will use {{Codeline|/sbin/mount.ntfs}} which is symlinked to {{Codeline|/bin/ntfs-3g}} when the ntfs-3g package is installed. On the other hand, it is generally advised to be explicit rather than implicit.<br />
<br />
The second option is to call {{Codeline|ntfs-3g}} directly:<br />
<br />
# ntfs-3g /dev/<your-NTFS-partition> /<mount-location><br />
<br />
== Configuring == <br />
<br />
Your NTFS partition(s) can be setup to mount automatically, or pre-configured to be able to mount in a certain way when you would like them to be mounted. This configuration can be done in the static filesystem configuration ([[fstab]]) or by the use of HAL.<br />
<br />
=== Default settings ===<br />
<br />
Using the default settings will mount the NTFS partition(s) at boot. With this method, '''if''' the parent folder that it is mounted upon has the proper user or group permissions, then that user or group will be able to read and write on that partition(s).<br />
<br />
<pre><br />
# <file system> <dir> <type> <options> <dump> <pass><br />
/dev/<NTFS-part> /mnt/windows ntfs-3g defaults 0 0<br />
</pre><br />
<br />
=== Allowing Group/User ===<br />
<br />
You can also tell fstab (the NTFS-3G driver) other options like those who are allowed to access the partition. For example, for you to allow people in the '''users''' group to have access:<br />
<br />
/dev/<NTFS-part> /mnt/windows ntfs-3g gid=users,umask=0022 0 0<br />
<br />
=== Basic NTFS-3G options ===<br />
<br />
For most, the above settings should suffice. Here are a few other options that are general common options for various Linux filesystems. For a complete list, see [http://www.tuxera.com/community/ntfs-3g-manual/#6 this]<br />
<br />
* '''umask''': umask is a built-in shell command which automatically sets file permissions on newly created files. For Arch the default umask for root and user is 0022. With 0022 new folders have the directory permissions of 755 and new files have permissions of 644. You can read more about umask permissions [http://www.cyberciti.biz/tips/understanding-linux-unix-umask-value-usage.html here].<br />
* '''noauto''': If noauto is set, NTFS entries in fstab do not get mounted automatically at boot.<br />
* '''uid''' : The user id number. This allows a specific user to have full access to the partition. Your uid can be found with the {{Codeline|id}} command.<br />
* '''fmask''' and '''dmask''': Like '''umask''' but defining file and directory respectively individually.<br />
* '''locale''' : (deprecated as of 2009.1.1) - <s>some locales will need to specify their region for local characters to display properly.</s><br />
<br />
== Other configurations ==<br />
<br />
Some other configurations that might help you set up your NTFS partition.<br />
<br />
=== HAL mounting ===<br />
<br />
[[HAL]] can automatically mount your NTFS partition with the use of hotplugging or you can choose to have your Desktop Environment do this too (if it has this feature (which also uses HAL)). By doing this, there is no need to configure NTFS in the {{Filename|fstab}} configuration file.<br />
<br />
==== HAL direct ====<br />
<br />
To automatically mount a NTFS partition with HAL you will have to create a [[HAL#NTFS_write_access|custom HAL policy]]. After you do this, add yourself to the '''storage''' group to obtain write permission.<br />
<br />
==== KDE 4 ====<br />
<br />
For >=KDE 4.4, right-click the Device Notifier applet and choose '''Device Notifier Settings''' then in '''Removable Devices''' select your partition and choose '''Automount on login'''.<br />
<br />
=== NTFS-config ===<br />
<br />
{{Package AUR|ntfs-config}} is a program that may be able to help configure your NTFS partition(s) if other methods don't work.<br />
<br />
== Troubleshooting ==<br />
<br />
Some ideas for troubleshooting common problems.<br />
<br />
=== Damaged NTFS Filesystems ===<br />
<br />
If an NTFS filesystem has errors on it, NTFS-3G will mount it as read only. To fix an NTFS filesystem, load Windows and run it's disk checking program. Repairs of an NTFS filesystem are not possible yet in Linux.<br />
<br />
=== Mount Failure ===<br />
<br />
If you can't mount your NTFS partion even when following this guide, try to add the UUID section to your {{Filename|fstab}} to all ntfs partions.<br />
<br />
== Resources ==<br />
<br />
* [http://www.tuxera.com/community/ntfs-3g-manual/ Official NTFS-3G Manual]</div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Fan_speed_control&diff=101092Fan speed control2010-03-23T17:30:43Z<p>TaylanUB: /* Tweaking */</p>
<hr />
<div>[[Category:CPU (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Fan speed control}}<br />
{{i18n_entry|Русский|Контроль скорости кулера}}<br />
{{i18n_entry|Italiano|Controllo ventola CPU}}<br />
{{i18n_links_end}}<br />
<br />
Controlling the speed (and sound!) of your CPU fan is easy!<br />
<br />
'''This can ruin your hardware. A CPU fan is needed to cool your CPU and in this howto it will be turned off for a couple of seconds. If you are not comfortable with doing this, don't!''''<br />
<br />
=== lm-sensors ===<br />
<br />
First, you need to set up lm-sensors. This is explained [[Lm_sensors|here]]<br />
<br />
Once you have lm-sensors installed, you should have a readout with 'sensors'.<br />
<br />
<pre>$ sensors<br />
coretemp-isa-0000<br />
Adapter: ISA adapter<br />
Core 0: +29.0°C (high = +76.0°C, crit = +100.0°C) <br />
<br />
coretemp-isa-0001<br />
Adapter: ISA adapter<br />
Core 1: +29.0°C (high = +76.0°C, crit = +100.0°C) <br />
<br />
coretemp-isa-0002<br />
Adapter: ISA adapter<br />
Core 2: +31.0°C (high = +76.0°C, crit = +100.0°C) <br />
<br />
coretemp-isa-0003<br />
Adapter: ISA adapter<br />
Core 3: +29.0°C (high = +76.0°C, crit = +100.0°C) <br />
<br />
it8718-isa-0290<br />
Adapter: ISA adapter<br />
Vcc: +1.14 V (min = +0.00 V, max = +4.08 V) <br />
VTT: +2.08 V (min = +0.00 V, max = +4.08 V) <br />
+3.3V: +3.33 V (min = +0.00 V, max = +4.08 V) <br />
NB Vcore: +0.03 V (min = +0.00 V, max = +4.08 V) <br />
VDRAM: +2.13 V (min = +0.00 V, max = +4.08 V) <br />
fan1: 690 RPM (min = 10 RPM)<br />
temp1: +37.5°C (low = +129.5°C, high = +129.5°C) sensor = thermistor<br />
temp2: +25.0°C (low = +127.0°C, high = +127.0°C) sensor = thermal diode<br />
</pre><br />
<br />
If your output does not display an RPM for your CPU fan, and you are positive it is running, you need to increase the fan divisor. If your fan speed is shown and higher than 0, skip the next step.<br />
'''<br />
Increasing fan_div:'''<br />
<br />
The first line of the sensors output is the chipset your motherboard uses to read the speeds/temps/voltages. Make a backup first:<br />
Code:<br />
<br />
<pre>cp /etc/sensors.conf /etc/sensors.conf_original</pre><br />
<br />
Edit the /etc/sensors.conf file as root<br />
<br />
<pre>nano /etc/sensors.conf</pre><br />
<br />
and look up your exact chipset. The names all look alike, so make sure the one you are editing is yours. Add the line fanX_div 4 near the start of your chipset config. Replace the X with the number of your CPU fan's, for me that was 2. You have to figure out for yourself which one it is, but it's probably 1, 2 or 3.<br />
<br />
Save, and run:<br />
<br />
<pre>sudo sensors -s</pre><br />
<br />
which will reload the sensors.conf's set variables.<br />
Run sensors again and check if there is an RPM readout. If not, increase the divisor to 8, 16 or 32. YMMV!<br />
<br />
You can safely ignore anything that's not fanX_div. I would advise you to leave the other default settings as they are.<br />
<br />
=== pwmconfig ===<br />
<br />
(If you are a very cool hacker, you might want to skip this section and write /etc/fancontrol by your own, which also saves you from hearing all your fans at full speed)<br />
<br />
Once you have lm sensors properly configured, run pwmconfig to test and configure speed control of your fans:<br />
<pre>pwmconfig</pre><br />
<br />
Follow the instructions in pwmconfig to set up basic speeds.<br />
<br />
The default configuration options should create a new file, <tt>/etc/fancontrol</tt>. <br />
<br />
Follow the instructions in pwmconfig to set up speeds.<br />
<br />
==== Tweaking ====<br />
<br />
<strong>Second warning:</strong> Some of the steps outlined below describe how to tweak fan speeds. Before doing this be sure you have a low cpu load and are comfortable playing around. If at any time during tweaking you notice the CPU temperature start to rise dramatically, do a <tt>echo "255" > /sys/class/hwmon/hwmon0/device/pwm1</tt> to spin up the fan all the way until things cool down. Basically, you should know what you're doing before fooling with the configuration file.<br />
<br />
{{Note|On several systems, the included script may report errors as it trys to calibrate your fan to the PWM. You may safely ignore these as errors. The problem is that the script doesn't wait long enough before ramping up or down the PWM.}}<br />
<br />
If you want more control, you will probably need to tweak the generated configuration. Here is a sample configuration file:<br />
<br />
<pre><br />
INTERVAL=10<br />
<br />
DEVPATH=hwmon0=devices/platform/coretemp.0 hwmon2=devices/platform/w83627ehf.656<br />
DEVNAME=hwmon0=coretemp hwmon2=w83627dhg<br />
<br />
FCTEMPS=hwmon0/device/pwm1=hwmon0/device/temp1_input<br />
FCFANS= hwmon0/device/pwm1=hwmon0/device/fan1_input<br />
MINTEMP=hwmon0/device/pwm1=20<br />
MAXTEMP=hwmon0/device/pwm1=55<br />
MINSTART=hwmon0/device/pwm1=150<br />
MINSTOP=hwmon0/device/pwm1=105<br />
</pre><br />
<br />
* <strong>INTERVAL</strong>: how often the daemon should poll cpu temps and adjust fan speeds. Interval is in seconds.<br />
<br />
The rest of the configuration file is split into (at least) two values per configuration option. Each configuration option first points to a PWM device which is written to which sets the fan speed. The second "field" is the actual value to set. This allows you to monitor and control multiple fans and temperatures (if your pc supports it).<br />
<br />
* <strong>FCTEMPS</strong>: The temperature input device to read for cpu temperature. The above example corresponds to <tt>/sys/class/hwmon/hwmon0/device/temp1_input</tt>.<br />
* <strong>FCFANS</strong>: The current fan speed, which can be read (like the temperature) in <tt>/sys/class/hwmon/hwmon0/device/fan1_input</tt><br />
* <strong>MINTEMP</strong>: The temperature (&deg;C) at which to <em>SHUT OFF</em> the cpu fan. Efficicent CPU's often will not need a fan while idling. Be sure to set this to a temperature that you <em>know</em> is safe. Setting this to 0 is not reccommended, use a sane value.<br />
* <strong>MAXTEMP</strong>: The temperature (&deg;C) at which to spin the fan at it's <em>MAXIMUM</em> speed. This should be probably be set to perhaps 10 or 20 degrees (&deg;C) below your CPU's critical/shutdown temperature. Setting it closer to MINTEMP will result in higher fan speeds overall.<br />
* <strong>MINSTOP</strong>: The PWM value at which your fan stops spinning. Each fan is a little different. Power tweakers can <tt>cat</tt> different values (between 0 and 255) to <tt>/sys/class/hwmon/hwmon0/device/pwm1</tt> and then watch the cpu fan. When it stops, use this value.<br />
* <strong>MINSTART</strong>: The PWM value at which your fan starts to spin again. This is often a higher value than MINSTOP as more voltage is required to overcome inertia.<br />
<br />
There are also two settings fancontrol needs to verify the configuration file is still up to date. The lines start with the setting name and a equality sign, followed by groups of hwmon-class-device=setting, seperated by spaces. You need to specify each setting for each hwmon class device you use anywhere in the config, or fancontrol wont work.<br />
<br />
* <strong>DEVPATH</strong>: Sets the physical device. You can determine this by executing the command<br />
readlink -f /sys/class/hwmon/<hwmon-device>/device | sed -e 's/^\/sys\///'<br />
* <strong>DEVNAME</strong>: Sets the name of the device. Try<br />
cat /sys/class/hwmon/<hwmon-device>/device/name | sed -e 's/[[:space:]=]/_/g'<br />
<br />
=== fancontrol ===<br />
<br />
Try to run fancontrol:<br />
<pre>/usr/sbin/fancontrol</pre><br />
<br />
Also notice this bug: [http://bugs.archlinux.org/task/17775] (Initscript outputs FAIL when it should be DONE)<br />
<br />
It should start up and you'll probably hear your CPU fans spin down.<br />
<br />
If it's working, in order to run at boot simply add "fancontrol" to DAEMONS in /etc/rc.conf, as <br />
a fancontrol init script is now provided by default!<br />
<br />
''Most of this howto is from [[http://ubuntuforums.org/ Ubuntu forums]] and [[http://ubuntuguide.org/ Ubuntu guide]].''<br />
<br />
For Dell Latitude/Inspiron laptops, you may want to use i8kutils/i8kmon.<br />
<br />
=== simple bash script to fine tune fan speed ===<br />
Run this as root if you'd like to see how various pwm values translate into fan RPM. As you can see, this script assumes that you have fancontrol running and disables it for you, then re-enables it when you're finished. Enjoy.<br />
<br />
<pre>#!/bin/bash<br />
clear<br />
<br />
#################################################<br />
# change the following lines to match your system<br />
#################################################<br />
pwmcontrol=/sys/class/hwmon/hwmon4/device/pwm1<br />
fanrpmread=/sys/class/hwmon/hwmon4/device/fan1_input<br />
<br />
# do not edit below this line<br />
#################################################<br />
log=`pwd`/fandata.log<br />
echo "PWM,RPM" > $log<br />
<br />
echo "This script will set your PWM to values from full power down to 0 decreasing in"<br />
echo "approx 5 % steps and pausing 10 sec between steps to allow the fan RPM to catch"<br />
echo "up to the new settings. Data are logged to ${log}"<br />
echo "which can be used to generate a graph or use as-is."<br />
<br />
collectdata() {<br />
array=( 255 242 230 217 204 191 178 165 152 139 126 113 100 87 74 48 22 0 )<br />
for item in ${array[*]}<br />
do<br />
echo $item > $pwmcontrol<br />
sleep 10s<br />
rpm=`cat ${fanrpmread}`<br />
echo $item,$rpm >> $log<br />
echo "PWM: ${item} RPM: ${rpm}"<br />
done<br />
}<br />
<br />
/etc/rc.d/fancontrol stop<br />
echo "1" > ${pwmcontrol}_enable<br />
<br />
collectdata<br />
<br />
echo "0" > ${pwmcontrol}_enable<br />
/etc/rc.d/fancontrol start</pre></div>TaylanUBhttps://wiki.archlinux.org/index.php?title=Fan_speed_control&diff=101091Fan speed control2010-03-23T17:27:00Z<p>TaylanUB: /* Tweaking */</p>
<hr />
<div>[[Category:CPU (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{i18n_links_start}}<br />
{{i18n_entry|English|Fan speed control}}<br />
{{i18n_entry|Русский|Контроль скорости кулера}}<br />
{{i18n_entry|Italiano|Controllo ventola CPU}}<br />
{{i18n_links_end}}<br />
<br />
Controlling the speed (and sound!) of your CPU fan is easy!<br />
<br />
'''This can ruin your hardware. A CPU fan is needed to cool your CPU and in this howto it will be turned off for a couple of seconds. If you are not comfortable with doing this, don't!''''<br />
<br />
=== lm-sensors ===<br />
<br />
First, you need to set up lm-sensors. This is explained [[Lm_sensors|here]]<br />
<br />
Once you have lm-sensors installed, you should have a readout with 'sensors'.<br />
<br />
<pre>$ sensors<br />
coretemp-isa-0000<br />
Adapter: ISA adapter<br />
Core 0: +29.0°C (high = +76.0°C, crit = +100.0°C) <br />
<br />
coretemp-isa-0001<br />
Adapter: ISA adapter<br />
Core 1: +29.0°C (high = +76.0°C, crit = +100.0°C) <br />
<br />
coretemp-isa-0002<br />
Adapter: ISA adapter<br />
Core 2: +31.0°C (high = +76.0°C, crit = +100.0°C) <br />
<br />
coretemp-isa-0003<br />
Adapter: ISA adapter<br />
Core 3: +29.0°C (high = +76.0°C, crit = +100.0°C) <br />
<br />
it8718-isa-0290<br />
Adapter: ISA adapter<br />
Vcc: +1.14 V (min = +0.00 V, max = +4.08 V) <br />
VTT: +2.08 V (min = +0.00 V, max = +4.08 V) <br />
+3.3V: +3.33 V (min = +0.00 V, max = +4.08 V) <br />
NB Vcore: +0.03 V (min = +0.00 V, max = +4.08 V) <br />
VDRAM: +2.13 V (min = +0.00 V, max = +4.08 V) <br />
fan1: 690 RPM (min = 10 RPM)<br />
temp1: +37.5°C (low = +129.5°C, high = +129.5°C) sensor = thermistor<br />
temp2: +25.0°C (low = +127.0°C, high = +127.0°C) sensor = thermal diode<br />
</pre><br />
<br />
If your output does not display an RPM for your CPU fan, and you are positive it is running, you need to increase the fan divisor. If your fan speed is shown and higher than 0, skip the next step.<br />
'''<br />
Increasing fan_div:'''<br />
<br />
The first line of the sensors output is the chipset your motherboard uses to read the speeds/temps/voltages. Make a backup first:<br />
Code:<br />
<br />
<pre>cp /etc/sensors.conf /etc/sensors.conf_original</pre><br />
<br />
Edit the /etc/sensors.conf file as root<br />
<br />
<pre>nano /etc/sensors.conf</pre><br />
<br />
and look up your exact chipset. The names all look alike, so make sure the one you are editing is yours. Add the line fanX_div 4 near the start of your chipset config. Replace the X with the number of your CPU fan's, for me that was 2. You have to figure out for yourself which one it is, but it's probably 1, 2 or 3.<br />
<br />
Save, and run:<br />
<br />
<pre>sudo sensors -s</pre><br />
<br />
which will reload the sensors.conf's set variables.<br />
Run sensors again and check if there is an RPM readout. If not, increase the divisor to 8, 16 or 32. YMMV!<br />
<br />
You can safely ignore anything that's not fanX_div. I would advise you to leave the other default settings as they are.<br />
<br />
=== pwmconfig ===<br />
<br />
(If you are a very cool hacker, you might want to skip this section and write /etc/fancontrol by your own, which also saves you from hearing all your fans at full speed)<br />
<br />
Once you have lm sensors properly configured, run pwmconfig to test and configure speed control of your fans:<br />
<pre>pwmconfig</pre><br />
<br />
Follow the instructions in pwmconfig to set up basic speeds.<br />
<br />
The default configuration options should create a new file, <tt>/etc/fancontrol</tt>. <br />
<br />
Follow the instructions in pwmconfig to set up speeds.<br />
<br />
==== Tweaking ====<br />
<br />
<strong>Second warning:</strong> Some of the steps outlined below describe how to tweak fan speeds. Before doing this be sure you have a low cpu load and are comfortable playing around. If at any time during tweaking you notice the CPU temperature start to rise dramatically, do a <tt>echo "255" > /sys/class/hwmon/hwmon0/device/pwm1</tt> to spin up the fan all the way until things cool down. Basically, you should know what you're doing before fooling with the configuration file.<br />
<br />
{{Note|On several systems, the included script may report errors as it trys to calibrate your fan to the PWM. You may safely ignore these as errors. The problem is that the script doesn't wait long enough before ramping up or down the PWM.}}<br />
<br />
If your want more control, you probably will need to tweak the generated configuration in order get the results you expect. Here is a sample configuration file:<br />
<br />
<pre><br />
INTERVAL=10<br />
<br />
DEVPATH=hwmon0=devices/platform/coretemp.0 hwmon2=devices/platform/w83627ehf.656<br />
DEVNAME=hwmon0=coretemp hwmon2=w83627dhg<br />
<br />
FCTEMPS=hwmon0/device/pwm1=hwmon0/device/temp1_input<br />
FCFANS= hwmon0/device/pwm1=hwmon0/device/fan1_input<br />
MINTEMP=hwmon0/device/pwm1=20<br />
MAXTEMP=hwmon0/device/pwm1=55<br />
MINSTART=hwmon0/device/pwm1=150<br />
MINSTOP=hwmon0/device/pwm1=105<br />
</pre><br />
<br />
* <strong>INTERVAL</strong>: how often the daemon should poll cpu temps and adjust fan speeds. Interval is in seconds.<br />
<br />
The rest of the configuration file is split into (at least) two values per configuration option. Each configuration option first points to a PWM device which is written to which sets the fan speed. The second "field" is the actual value to set. This allows you to monitor and control multiple fans and temperatures (if your pc supports it).<br />
<br />
* <strong>FCTEMPS</strong>: The temperature input device to read for cpu temperature. The above example corresponds to <tt>/sys/class/hwmon/hwmon0/device/temp1_input</tt>.<br />
* <strong>FCFANS</strong>: The current fan speed, which can be read (like the temperature) in <tt>/sys/class/hwmon/hwmon0/device/fan1_input</tt><br />
* <strong>MINTEMP</strong>: The temperature (&deg;C) at which to <em>SHUT OFF</em> the cpu fan. Efficicent CPU's often will not need a fan while idling. Be sure to set this to a temperature that you <em>know</em> is safe. Setting this to 0 is not reccommended, use a sane value.<br />
* <strong>MAXTEMP</strong>: The temperature (&deg;C) at which to spin the fan at it's <em>MAXIMUM</em> speed. This should be probably be set to perhaps 10 or 20 degrees (&deg;C) below your CPU's critical/shutdown temperature. Setting it closer to MINTEMP will result in higher fan speeds overall.<br />
* <strong>MINSTOP</strong>: The PWM value at which your fan stops spinning. Each fan is a little different. Power tweakers can <tt>cat</tt> different values (between 0 and 255) to <tt>/sys/class/hwmon/hwmon0/device/pwm1</tt> and then watch the cpu fan. When it stops, use this value.<br />
* <strong>MINSTART</strong>: The PWM value at which your fan starts to spin again. This is often a higher value than MINSTOP as more voltage is required to overcome inertia.<br />
<br />
There are also two settings fancontrol needs to verify the configuration file is still up to date. The lines start with the setting name and a equality sign, followed by groups of hwmon-class-device=setting, seperated by spaces. You need to specify each setting for each hwmon class device you use anywhere in the config, or fancontrol wont work.<br />
<br />
* <strong>DEVPATH</strong>: Sets the physical device. You can determine this by executing the command<br />
readlink -f /sys/class/hwmon/<hwmon-device>/device | sed -e 's/^\/sys\///'<br />
* <strong>DEVNAME</strong>: Sets the name of the device. Try<br />
cat /sys/class/hwmon/<hwmon-device>/device/name | sed -e 's/[[:space:]=]/_/g'<br />
<br />
=== fancontrol ===<br />
<br />
Try to run fancontrol:<br />
<pre>/usr/sbin/fancontrol</pre><br />
<br />
Also notice this bug: [http://bugs.archlinux.org/task/17775] (Initscript outputs FAIL when it should be DONE)<br />
<br />
It should start up and you'll probably hear your CPU fans spin down.<br />
<br />
If it's working, in order to run at boot simply add "fancontrol" to DAEMONS in /etc/rc.conf, as <br />
a fancontrol init script is now provided by default!<br />
<br />
''Most of this howto is from [[http://ubuntuforums.org/ Ubuntu forums]] and [[http://ubuntuguide.org/ Ubuntu guide]].''<br />
<br />
For Dell Latitude/Inspiron laptops, you may want to use i8kutils/i8kmon.<br />
<br />
=== simple bash script to fine tune fan speed ===<br />
Run this as root if you'd like to see how various pwm values translate into fan RPM. As you can see, this script assumes that you have fancontrol running and disables it for you, then re-enables it when you're finished. Enjoy.<br />
<br />
<pre>#!/bin/bash<br />
clear<br />
<br />
#################################################<br />
# change the following lines to match your system<br />
#################################################<br />
pwmcontrol=/sys/class/hwmon/hwmon4/device/pwm1<br />
fanrpmread=/sys/class/hwmon/hwmon4/device/fan1_input<br />
<br />
# do not edit below this line<br />
#################################################<br />
log=`pwd`/fandata.log<br />
echo "PWM,RPM" > $log<br />
<br />
echo "This script will set your PWM to values from full power down to 0 decreasing in"<br />
echo "approx 5 % steps and pausing 10 sec between steps to allow the fan RPM to catch"<br />
echo "up to the new settings. Data are logged to ${log}"<br />
echo "which can be used to generate a graph or use as-is."<br />
<br />
collectdata() {<br />
array=( 255 242 230 217 204 191 178 165 152 139 126 113 100 87 74 48 22 0 )<br />
for item in ${array[*]}<br />
do<br />
echo $item > $pwmcontrol<br />
sleep 10s<br />
rpm=`cat ${fanrpmread}`<br />
echo $item,$rpm >> $log<br />
echo "PWM: ${item} RPM: ${rpm}"<br />
done<br />
}<br />
<br />
/etc/rc.d/fancontrol stop<br />
echo "1" > ${pwmcontrol}_enable<br />
<br />
collectdata<br />
<br />
echo "0" > ${pwmcontrol}_enable<br />
/etc/rc.d/fancontrol start</pre></div>TaylanUB