https://wiki.archlinux.org/api.php?action=feedcontributions&user=Eruditorum&feedformat=atomArchWiki - User contributions [en]2024-03-29T11:10:47ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=254349Unified Extensible Firmware Interface2013-04-17T08:24:29Z<p>Eruditorum: /* Detecting UEFI Firmware Arch */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-CN:Unified Extensible Firmware Interface]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the Unified Extensible Firmware Interface.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GUID Partition Table}}<br />
{{Article summary wiki|Master Boot Record}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "MBR boot code" method followed for BIOS systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0 . As of 23 May 2012, UEFI Specification 2.3.1 is the most recent version.<br />
<br />
{{Note|Unless specified as EFI 1.x , EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitely, these instructions are general and not Mac specific. Some of them may not work or may be different in Macs. Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one UEFI Specification version and therefore it is not a standard UEFI firmware.}}<br />
<br />
== Booting an OS using BIOS ==<br />
<br />
A BIOS or Basic Input-Output System is the very first program that is executed once the system is switched on. After all the hardware has been initialized and the POST operation has completed, the BIOS executes the first boot code in the first device in the device booting list. <br />
<br />
If the list starts with a CD/DVD drive, then the El-Torito entry in the CD/DVD is executed. This is how bootable CD/DVD works. If the list starts with a HDD, then BIOS executes the very first 440 bytes MBR boot code. The boot code then chainloads or bootstraps a much larger and complex bootloader which then loads the OS.<br />
<br />
Basically, the BIOS does not know how to read a partition table or filesystem. All it does is initialize the hardware, then load and run the 440-byte boot code.<br />
<br />
=== Multiboot on BIOS ===<br />
<br />
Since very little can be achieved by a program that fits into the 440-byte boot code area, multi-booting using BIOS requires a multi-boot capable bootloader (multi-boot refers to booting multiple operating systems, not to booting a kernel in the Multiboot format specified by the GRUB developers). So usually a common bootloader like [[GRUB]] or [[Syslinux]] or [[LILO]] would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel.<br />
<br />
== Booting an OS using UEFI ==<br />
<br />
UEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS. UEFI has support for reading both the partition table as well as understanding filesystems. <br />
<br />
The commonly used UEFI firmwares support both MBR and GPT partition table. EFI in Apple-Intel Macs are known to also support Apple Partition Map besides MBR and GPT. Most UEFI firmwares have support for accessing FAT12 (floppy disks), FAT16 and FAT32 filesystems in HDDs and ISO9660 (and UDF) in CD/DVDs. EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones.<br />
<br />
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called ''EFI SYSTEM PARTITION'' in which files required to be launched by the firmware are stored. Each vendor can store its files under {{ic|<EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/}} folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it doesn't have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (for 64-bit x86 system)}}<br />
<br />
Under UEFI, every program whether it is an OS loader or an utility (e.g. a memory testing app or recovery tool), should be an UEFI Application corresponding to the EFI firmware architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use i386 EFI are older (pre 2008) Apple Macs.<br />
<br />
{{Note|Some older Intel Server boards are known to operate on Intel EFI 1.10 firmware, and require i386 EFI applications.}}<br />
<br />
A x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike x86_64 Linux and Windows versions which include such support. Therefore the bootloader must be compiled for that specific architecture.<br />
<br />
=== Multibooting on UEFI ===<br />
<br />
Since each OS or vendor can maintain its own files within the EFI SYSTEM PARTITION without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes.<br />
<br />
==== Multibooting Windows and Linux ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using UEFI firmware. These Windows versions support either UEFI-GPT booting or BIOS-MBR booting. 32-bit Windows versions only support BIOS-MBR booting. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
This limitation does not exist in Linux Kernel but rather depends on the bootloader used. For the sake of Windows UEFI booting, the Linux bootloader used should also be installed in UEFI-GPT mode if booting from the same disk.<br />
<br />
== Boot Process under UEFI ==<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded.<br />
# Firmware reads its Boot Manager to determine which UEFI application to be launched and from where (ie. from which disk and partition).<br />
# Firmware launches the UEFI application from the FAT32 formatted UEFISYS partition as defined in the boot entry in the firmware's boot manager.<br />
# UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a bootloader like GRUB) depending on how the UEFI application was configured.<br />
<br />
== Detecting UEFI Firmware Arch ==<br />
<br />
If you have a non-Mac UEFI system, then you most likely have a x86_64 (aka 64-bit) UEFI 2.x firmware. A few known x86_64 UEFI 2.x firmwares are Phoenix SecureCore Tiano, AMI Aptio and Insyde H2O.<br />
<br />
Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi. All Macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware. <br />
<br />
To find out the arch of the efi firmware in a Mac, type the following into the terminal:<br />
ioreg -l -p IODeviceTree | grep firmware-abi<br />
If the command returns EFI32 then it is i386 EFI 1.x firmware. If it returns EFI64 then it is x86_64 EFI 1.x firmware. Macs do not have UEFI 2.x firmware as Apple's EFI implementation is not fully compliant with UEFI Specification.<br />
<br />
== UEFI Support in Linux Kernel ==<br />
<br />
=== Linux Kernel config options for UEFI ===<br />
<br />
The required Linux Kernel configuration options for UEFI systems are :<br />
<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables/Services Support - 'efivars' kernel module . This option is important as this is required to manipulate UEFI Runtime Variables using tools like '''efibootmgr'''.<br />
<br />
CONFIG_EFI_VARS=y<br />
<br />
{{Note| This option is compiled built-in into the Arch core/testing kernel.}}<br />
<br />
{{Note|For Linux to access UEFI Runtime Services, the UEFI Firmware processor architecture and the Linux kernel processor architecture must match. This is independent of the bootloader used.}}<br />
<br />
{{Note|If the UEFI Firmware arch and Linux Kernel arch are different, then the "'''noefi'''" kernel parameter must be used to avoid the kernel panic and boot successfully. The "noefi" option instructs the kernel not to access the UEFI Runtime Services.}}<br />
<br />
GUID Partition Table [[GPT]] config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
{{Note|All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos.}}<br />
<br />
Retrieved from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD .<br />
<br />
== UEFI Variables Support ==<br />
<br />
UEFI defines variables through which an operating system can interact with the firmware. UEFI Boot Variables are used by the boot-loader and used by the OS only for early system start-up. UEFI Runtime Variables allow an OS to manage certain settings of the firmware like the UEFI Boot Manager or managing the keys for UEFI Secure Boot Protocol etc.<br />
<br />
{{Note|The below steps will not work if the system has been booted in BIOS mode and will not work if the UEFI processor architecture does not match the kernel one, i.e. x86_64 UEFI + x86 32-bit Kernel and vice-versa config will not work. This is true only for efivars kernel module and efibootmgr step. The other steps (ie. upto setting up <UEFISYS>/EFI/arch/refind/{refindx64.efi,refind.conf} ) can be done even in BIOS/Legacy boot mode.}}<br />
<br />
Access to UEFI Runtime services is provided by "efivars" kernel module which is enabled through the {{ic|<nowiki>CONFIG_EFI_VARS=y</nowiki>}} kernel config option. This module exposes the variables under the directory {{ic|/sys/firmware/efi/vars}} (for kernels >=3.8 through {{ic|/sys/firmware/efi/efivars}}). One way to check whether the system has booted in UEFI boot mode is to check for the existence of {{ic|/sys/firmware/efi/vars}} (and in kernels >=3.8 for {{ic|/sys/firmware/efi/efivars}})directory with contents similar to :<br />
<br />
Sample output (x86_64-UEFI 2.3.1 in x86_64 Kernel):<br />
<br />
# ls -1 /sys/firmware/efi/vars/<br />
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
MTC-eb704011-1402-11d3-8e77-00a0c969723b/<br />
MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa/<br />
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
RTC-378d7b65-8da9-4773-b6e4-a47826a833e1/<br />
del_var<br />
new_var<br />
<br />
The UEFI Runtime Variables will not be exposed to the OS if you have used "noefi" kernel parameter in the boot-loader menu. This parameter instructs the kernel to completely ignore UEFI Runtime Services.<br />
<br />
=== Userspace Tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
# efibootmgr - Used to create/modify boot entries in the UEFI Boot Manager - {{Pkg|efibootmgr}} or {{AUR|efibootmgr-git}}<br />
# uefivars - simply dumps the variables - {{AUR|uefivars-git}} - uses efibootmgr library<br />
# Ubuntu's Firmware Test Suite - fwts - {{AUR|fwts-git}} - uefidump command - {{ic|fwts uefidump}} <br />
<br />
=== Non-Mac UEFI systems ===<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|Using {{ic|efibootmgr}} in Apple Macs will brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<br />
<br />
{{Note|{{ic|efibootmgr}} command will work only if you have booted the system in UEFI mode itself, since it '''requires access to UEFI Runtime Variables''' which are '''available only in UEFI boot mode''' (with "noefi" kernel parameter NOT being used). Otherwise the message {{ic|Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables}} is shown.}}<br />
<br />
{{Note| If you are unable to use {{ic|efibootmgr}}, some UEFI BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI system partition and manually enter the EFI stub location. (for example '\EFI\refind\refind_x64.efi')}}<br />
<br />
Initially the user may be required to manually launch the boot-loader from the firmware itself (using maybe the UEFI Shell) if the UEFI boot-loader was installed when the system is booted in BIOS mode. Then {{ic|efibootmgr}} should be run to make the UEFI boot-loader entry as the default entry in the UEFI Boot Manager.<br />
<br />
To use efibootmgr, first load the 'efivars' kernel module (if compiled as a external module):<br />
<br />
# modprobe efivars<br />
<br />
If you get '''no such device found''' error for this command, that means you have not booted in UEFI mode or due to some reason the kernel is unable to access UEFI Runtime Variables (noefi?).<br />
<br />
Verify whether there are files in ''/sys/firmware/efi/vars/'' (and ''/sys/firmware/efi/efivars/'' for kernel >=3.8) directory. This directory and its contents are created by "efivars" kernel module and it will exist only if you have booted in UEFI mode, without the "noefi" kernel parameter.<br />
<br />
If ''/sys/firmware/efi/vars/'' directory is empty or does not exist, then {{ic|efibootmgr}} command will not work. If you are unable to make the ISO/CD/DVD/USB boot in UEFI mode try [[#Create_UEFI_bootable_USB_from_ISO]].<br />
<br />
{{Note| The below commands use {{Pkg|gummiboot}} boot-loader as example.}}<br />
{{out of date|[[Gummiboot]] has its own installer now, therefore the following instructions should not be used to install [[gummiboot]]. This example should be changed to use something else.}}<br />
<br />
Assume the boot-loader file to be launched is {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}}. {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} can be split up as {{ic|/boot/efi}} and {{ic|/EFI/gummiboot/gummibootx64.efi}}, wherein {{ic|/boot/efi}} is the mountpoint of the UEFI System Partition, which is assumed to be {{ic|/dev/sdXY}} (here X and Y are just placeholders for the actual values - eg:- in {{ic|/dev/sda1}} , X=a Y=1).<br />
<br />
To determine the actual device path for the UEFI System Partition (should be in the form {{ic|/dev/sdXY}}), try :<br />
<br />
# findmnt /boot/efi<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/boot/efi /dev/sdXY vfat rw,flush,tz=UTC<br />
<br />
Then create the boot entry using efibootmgr as follows :<br />
<br />
# efibootmgr -c -g -d /dev/sdX -p Y -w -L "Gummiboot" -l '\EFI\gummiboot\gummibootx64.efi'<br />
<br />
In the above command {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} translates to {{ic|/boot/efi}} and {{ic|/EFI/gummiboot/gummibootx64.efi}} which in turn translate to drive {{ic|/dev/sdX}} -> partition {{ic|Y}} -> file {{ic|/EFI/gummiboot/gummibootx64.efi}}.<br />
<br />
UEFI uses backward slash as path separator (similar to Windows paths).<br />
<br />
The 'label' is the name of the menu entry shown in the UEFI boot menu. This name is user's choice and does not affect the booting of the system. More info can be obtained from [http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=efibootmgr.git;a=blob_plain;f=README;hb=HEAD efibootmgr GIT README] .<br />
<br />
FAT32 filesystem is case-insensitive since it does not use UTF-8 encoding by default. In that case the firmware uses capital 'EFI' instead of small 'efi', therefore using {{ic|\EFI\gummiboot\gummibootx64.efi}} or {{ic|\efi\gummiboot\gummibootx64.efi}} does not matter (this will change if the filesystem encoding is UTF-8).<br />
<br />
== Linux Bootloaders for UEFI ==<br />
<br />
See [[UEFI Bootloaders]].<br />
<br />
== EFI System Partition ==<br />
<br />
{{Note|UEFI System Partition and EFI System Partition (ESP) are same, the terminologies are used interchangeably in some places.}}<br />
<br />
{{Note|1=The EFI System Partition can be of any size supported by FAT32 filesystem. According to Microsoft Documentation, the minimum partition/volume size for FAT32 is 512 MiB. However ESP with size >=100 MiB but formatted as FAT32 are also allowed by many Linux distros and by Microsoft Windows, hence smaller partitions are fine. However >=512 MiB size for ESP is recommended for most compatibility. Non-FAT filesystems like ext2/3/4, reiserfs, NTFS, UDF etc. are not supported for ESP.}}<br />
<br />
{{Note|The ESP should be accessible by the UEFI firmware, which cannot read LVM and software RAID systems.}}<br />
<br />
{{Note|If you are using Linux EFISTUB booting, then you need to make sure there is adequate space available for keeping the Kernel and Initramfs files in the ESP.}}<br />
<br />
{{Note|Setting "boot" flag in parted in a MBR partition marks that partition as active, while the same "boot" flag in a GPT partition marks that partition as "UEFI System Partition".}}<br />
<br />
=== For GPT partitioned disks ===<br />
Two choices:<br />
* Using GNU Parted/GParted: Create a FAT32 partition. Set "boot" flag on for that partition.<br />
* Using GPT fdisk (aka gdisk): Create a partition with partition type {{ic|EF00}}. Then format that partition as FAT32 using {{ic|mkfs.vfat -F32 /dev/<THAT_PARTITION>}}<br />
<br />
=== For MBR partitioned disks ===<br />
{{Note|It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.}}<br />
Two choices:<br />
* Using GNU Parted/GParted: Create FAT32 partition. Change the type code of that partition to {{ic|0xEF}} using fdisk, cfdisk or sfdisk.<br />
* Using fdisk: Create a partition with partition type {{ic|0xEF}}. Then format that partition as FAT32 using {{ic|mkfs.vfat -F32 /dev/<THAT_PARTITION>}}<br />
<br />
== UEFI Shell ==<br />
<br />
The UEFI Shell is a shell/terminal for the firmware which allows launching uefi applications which include uefi bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading uefi drivers, editing text files (edit), hexedit etc. <br />
<br />
=== UEFI Shell download links === <br />
<br />
You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 Sourceforge.net project.<br />
<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi x86_64 UEFI Shell 2.0 (Beta)] - [http://dl.dropbox.com/u/9710721/UEFI_Shell/shellx64_v2.efi Alternate download link] (compiled from SVN repo, try this link if the file downloaded from previous link does not work in your system)<br />
<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi x86_64 UEFI Shell 1.0 (Old)]<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi i386 UEFI Shell 2.0 (Beta)]<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi i386 UEFI Shell 1.0 (Old)]<br />
<br />
Shell 2.0 works only in UEFI 2.3+ systems and is recommended over Shell 1.0 in those systems. Shell 1.0 should work in all UEFI systems irrespective of the spec. version the firmware follows. More info at [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] and [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail]<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your UEFI SYSTEM PARTITION as {{ic|<UEFI_SYSTEM_PARTITION>/shellx64.efi}} (mostly {{ic|/boot/efi/shellx64.efi}}) .<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either F6, F11 or F12 key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with Shell.efi copied as (USB)/efi/boot/bootx64.efi . This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell Commands === <br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). Run {{ic|help -b}} to list available commands.<br />
<br />
More info at http://software.intel.com/en-us/articles/efi-shells-and-scripting/<br />
<br />
==== bcfg ====<br />
<br />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" pdf document.<br />
<br />
{{Note| Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their system.}}<br />
<br />
{{Note| UEFI Shell 1.0 does not support {{ic|bcfg}} command.}}<br />
<br />
To dump a list of current boot entries -<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu<br />
<br />
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where fs0: is the mapping corresponding to the UEFI System Partition and fs0:\EFI\refind\refind_x64.efi is the file to be launched.<br />
<br />
To remove the 4th boot option<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu)<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example rEFInd's refind.conf in the UEFI System Partition (fs0: in the firmware)<br />
<br />
Shell> fs0:<br />
FS0:\> cd \EFI\arch\refind<br />
FS0:\EFI\arch\refind\> edit refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== Hardware Compatibility ==<br />
<br />
Main page [[HCL/Firmwares/UEFI]]<br />
<br />
== Create UEFI bootable USB from ISO ==<br />
<br />
{{Note|1=The instructions below are specifically for [[Archiso]]/official media; [[Archboot]] preparation is identical, with this [https://bbs.archlinux.org/viewtopic.php?pid=1190788#p1190788 refind.conf] instead of the one mentioned below (which is for Archiso) and without the filesystem label requirement.}}<br />
<br />
{{Note|The USB can use either MBR or GPT partition table (so it is fine to use an already partitioned USB). The filesystem should be either FAT32 (recommended) or FAT16. FAT12 is designed for floppy drives and therefore not recommended for USB drives.}}<br />
<br />
First create a partition table and at most one partition in the USB. Mount the ISO image from the [https://www.archlinux.org/download/ Arch Linux download page].<br />
<br />
{{bc|1=<nowiki><br />
# mkdir -p /mnt/{usb,iso}<br />
# mount -o loop archlinux-2012.12.01-dual.iso /mnt/iso<br />
</nowiki>}}<br />
<br />
Then create a FAT32 filesystem in the partition on the USB (unmount before if necessary) with LABEL as used in the Archiso configuration. Obtain the label from {{ic|/mnt/iso/loader/entries/archiso-x86_64.conf}}; this is used by the {{ic|archiso}} hook in initramfs to identify the udev path to the installation media. {{ic|mkfs.vfat}} is part of package {{Pkg|dosfstools}}.<br />
<br />
{{bc|1=<nowiki><br />
# awk 'BEGIN {FS="="} /archisolabel/ {print $3}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat -F32 /dev/sdXY -n<br />
</nowiki>}}<br />
<br />
Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.<br />
<br />
{{bc|1=<nowiki><br />
# mount /dev/sdXY /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/{usb,iso}</nowiki>}}<br />
<br />
<br />
=== Fixing errors ===<br />
<br />
If you find the error: ''"No loader found. Configuration files in /loader/entries/*.conf are needed."'' A possible fix is to use a different uefi bootloader to the included one, gummiboot.<br />
<br />
Download [https://www.archlinux.org/packages/extra/any/refind-efi/download/ refind-efi pkg] and extract the file {{ic|/usr/lib/refind/refind_x64.efi}} from within the package to {{ic|(USB)/EFI/boot/bootx64.efi}} (overwrite or rename any existing {{ic|(USB)/EFI/boot/bootx64.efi}} file).<br />
<br />
Then copy this text to {{ic|EFI/boot/refind.conf}}. Take care that the label in the Arch menu section ({{ic|ARCH_201302}} here) matches that of your usb's.<br />
<br />
{{hc|refind.conf|<nowiki><br />
timeout 5<br />
textonly<br />
<br />
showtools about,reboot,shutdown,exit<br />
# scan_driver_dirs EFI/tools/drivers_x64<br />
scanfor manual,internal,external,optical<br />
<br />
scan_delay 1<br />
dont_scan_dirs EFI/boot<br />
<br />
max_tags 0<br />
default_selection "Arch Linux Archiso x86_64 UEFI USB"<br />
<br />
menuentry "Arch Linux Archiso x86_64 UEFI USB" {<br />
loader /arch/boot/x86_64/vmlinuz<br />
initrd /arch/boot/x86_64/archiso.img<br />
ostype Linux<br />
graphics off<br />
options "archisobasedir=arch archisolabel=ARCH_201302 add_efi_memmap"<br />
}<br />
<br />
menuentry "UEFI x86_64 Shell v2" {<br />
loader /EFI/shellx64_v2.efi<br />
graphics off<br />
}<br />
<br />
menuentry "UEFI x86_64 Shell v1" {<br />
loader /EFI/shellx64_v1.efi<br />
graphics off<br />
}<br />
</nowiki>}}<br />
<br />
You should now be able to successfully boot, and you can choose which EFI you'd like to load.<br />
<br />
== Remove UEFI boot support from ISO ==<br />
<br />
{{Warning|In the event that UEFI+isohybrid El Torito/MBR really causes problems, it would be better to just UEFI boot using the USB stick instructions in the previous section}}<br />
<br />
Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD. If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first.<br />
<br />
Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
Rebuild the ISO using {{ic|xorriso}} from {{pkg|libisoburn}}:<br />
<br />
{{bc|1=<nowiki><br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "ARCH_201212" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared like a BAWSE" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output "~/archiso.iso" "/mnt/iso/"</nowiki>}}<br />
<br />
Burn {{ic|~/archiso.iso}} to optical media and proceed with installation normally.<br />
<br />
== QEMU with OVMF ==<br />
<br />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU and KVM.<br />
<br />
You can build OVMF from AUR [https://aur.archlinux.org/packages/ovmf-svn/] and use it like this:<br />
<br />
qemu-system-x86_64 -bios /usr/share/ovmf/bios.bin ...<br />
<br />
== See also ==<br />
<br />
* Wikipedia's page on [http://en.wikipedia.org/wiki/UEFI UEFI]<br />
* Wikipedia's page on [http://en.wikipedia.org/wiki/EFI_System_partition UEFI SYSTEM Partition]<br />
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD Linux Kernel UEFI Documentation]<br />
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel's Tianocore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<br />
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]<br />
* [http://hackthejoggler.freeforums.org/download/file.php?id=28 Some useful 32-bit UEFI Shell utilities]<br />
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=254254Unified Extensible Firmware Interface2013-04-16T07:50:14Z<p>Eruditorum: /* Booting an OS using UEFI */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-CN:Unified Extensible Firmware Interface]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the Unified Extensible Firmware Interface.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GUID Partition Table}}<br />
{{Article summary wiki|Master Boot Record}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "MBR boot code" method followed for BIOS systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0 . As of 23 May 2012, UEFI Specification 2.3.1 is the most recent version.<br />
<br />
{{Note|Unless specified as EFI 1.x , EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitely, these instructions are general and not Mac specific. Some of them may not work or may be different in Macs. Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one UEFI Specification version and therefore it is not a standard UEFI firmware.}}<br />
<br />
== Booting an OS using BIOS ==<br />
<br />
A BIOS or Basic Input-Output System is the very first program that is executed once the system is switched on. After all the hardware has been initialized and the POST operation has completed, the BIOS executes the first boot code in the first device in the device booting list. <br />
<br />
If the list starts with a CD/DVD drive, then the El-Torito entry in the CD/DVD is executed. This is how bootable CD/DVD works. If the list starts with a HDD, then BIOS executes the very first 440 bytes MBR boot code. The boot code then chainloads or bootstraps a much larger and complex bootloader which then loads the OS.<br />
<br />
Basically, the BIOS does not know how to read a partition table or filesystem. All it does is initialize the hardware, then load and run the 440-byte boot code.<br />
<br />
=== Multiboot on BIOS ===<br />
<br />
Since very little can be achieved by a program that fits into the 440-byte boot code area, multi-booting using BIOS requires a multi-boot capable bootloader (multi-boot refers to booting multiple operating systems, not to booting a kernel in the Multiboot format specified by the GRUB developers). So usually a common bootloader like [[GRUB]] or [[Syslinux]] or [[LILO]] would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel.<br />
<br />
== Booting an OS using UEFI ==<br />
<br />
UEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS. UEFI has support for reading both the partition table as well as understanding filesystems. <br />
<br />
The commonly used UEFI firmwares support both MBR and GPT partition table. EFI in Apple-Intel Macs are known to also support Apple Partition Map besides MBR and GPT. Most UEFI firmwares have support for accessing FAT12 (floppy disks), FAT16 and FAT32 filesystems in HDDs and ISO9660 (and UDF) in CD/DVDs. EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones.<br />
<br />
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called ''EFI SYSTEM PARTITION'' in which files required to be launched by the firmware are stored. Each vendor can store its files under {{ic|<EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/}} folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it doesn't have custom entry in UEFI boot menu) is to put it in this fixed location: {{ic|<EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}} (for 64-bit x86 system)}}<br />
<br />
Under UEFI, every program whether it is an OS loader or an utility (e.g. a memory testing app or recovery tool), should be an UEFI Application corresponding to the EFI firmware architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use i386 EFI are older (pre 2008) Apple Macs.<br />
<br />
{{Note|Some older Intel Server boards are known to operate on Intel EFI 1.10 firmware, and require i386 EFI applications.}}<br />
<br />
A x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike x86_64 Linux and Windows versions which include such support. Therefore the bootloader must be compiled for that specific architecture.<br />
<br />
=== Multibooting on UEFI ===<br />
<br />
Since each OS or vendor can maintain its own files within the EFI SYSTEM PARTITION without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes.<br />
<br />
==== Multibooting Windows and Linux ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using UEFI firmware. These Windows versions support either UEFI-GPT booting or BIOS-MBR booting. 32-bit Windows versions only support BIOS-MBR booting. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
This limitation does not exist in Linux Kernel but rather depends on the bootloader used. For the sake of Windows UEFI booting, the Linux bootloader used should also be installed in UEFI-GPT mode if booting from the same disk.<br />
<br />
== Boot Process under UEFI ==<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded.<br />
# Firmware reads its Boot Manager to determine which UEFI application to be launched and from where (ie. from which disk and partition).<br />
# Firmware launches the UEFI application from the FAT32 formatted UEFISYS partition as defined in the boot entry in the firmware's boot manager.<br />
# UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a bootloader like GRUB) depending on how the UEFI application was configured.<br />
<br />
== Detecting UEFI Firmware Arch ==<br />
<br />
If you have a non-Mac UEFI system, then you most likely have a x86_64 (aka 64-bit) UEFI 2.x firmware. A few known x86_64 UEFI 2.x firmwares are Phoenix SecureCore Tiano, AMI Aptio (but some are UEFI 1.x) and Insyde H2O.<br />
<br />
Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi. All Macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware. <br />
<br />
To find out the arch of the efi firmware in a Mac, type the following into the terminal:<br />
ioreg -l -p IODeviceTree | grep firmware-abi<br />
If the command returns EFI32 then it is i386 EFI 1.x firmware. If it returns EFI64 then it is x86_64 EFI 1.x firmware. Macs do not have UEFI 2.x firmware as Apple's EFI implementation is not fully compliant with UEFI Specification.<br />
<br />
== UEFI Support in Linux Kernel ==<br />
<br />
=== Linux Kernel config options for UEFI ===<br />
<br />
The required Linux Kernel configuration options for UEFI systems are :<br />
<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables/Services Support - 'efivars' kernel module . This option is important as this is required to manipulate UEFI Runtime Variables using tools like '''efibootmgr'''.<br />
<br />
CONFIG_EFI_VARS=y<br />
<br />
{{Note| This option is compiled built-in into the Arch core/testing kernel.}}<br />
<br />
{{Note|For Linux to access UEFI Runtime Services, the UEFI Firmware processor architecture and the Linux kernel processor architecture must match. This is independent of the bootloader used.}}<br />
<br />
{{Note|If the UEFI Firmware arch and Linux Kernel arch are different, then the "'''noefi'''" kernel parameter must be used to avoid the kernel panic and boot successfully. The "noefi" option instructs the kernel not to access the UEFI Runtime Services.}}<br />
<br />
GUID Partition Table [[GPT]] config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
{{Note|All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos.}}<br />
<br />
Retrieved from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD .<br />
<br />
== UEFI Variables Support ==<br />
<br />
UEFI defines variables through which an operating system can interact with the firmware. UEFI Boot Variables are used by the boot-loader and used by the OS only for early system start-up. UEFI Runtime Variables allow an OS to manage certain settings of the firmware like the UEFI Boot Manager or managing the keys for UEFI Secure Boot Protocol etc.<br />
<br />
{{Note|The below steps will not work if the system has been booted in BIOS mode and will not work if the UEFI processor architecture does not match the kernel one, i.e. x86_64 UEFI + x86 32-bit Kernel and vice-versa config will not work. This is true only for efivars kernel module and efibootmgr step. The other steps (ie. upto setting up <UEFISYS>/EFI/arch/refind/{refindx64.efi,refind.conf} ) can be done even in BIOS/Legacy boot mode.}}<br />
<br />
Access to UEFI Runtime services is provided by "efivars" kernel module which is enabled through the {{ic|<nowiki>CONFIG_EFI_VARS=y</nowiki>}} kernel config option. This module exposes the variables under the directory {{ic|/sys/firmware/efi/vars}} (for kernels >=3.8 through {{ic|/sys/firmware/efi/efivars}}). One way to check whether the system has booted in UEFI boot mode is to check for the existence of {{ic|/sys/firmware/efi/vars}} (and in kernels >=3.8 for {{ic|/sys/firmware/efi/efivars}})directory with contents similar to :<br />
<br />
Sample output (x86_64-UEFI 2.3.1 in x86_64 Kernel):<br />
<br />
# ls -1 /sys/firmware/efi/vars/<br />
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
MTC-eb704011-1402-11d3-8e77-00a0c969723b/<br />
MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa/<br />
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
RTC-378d7b65-8da9-4773-b6e4-a47826a833e1/<br />
del_var<br />
new_var<br />
<br />
The UEFI Runtime Variables will not be exposed to the OS if you have used "noefi" kernel parameter in the boot-loader menu. This parameter instructs the kernel to completely ignore UEFI Runtime Services.<br />
<br />
=== Userspace Tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
# efibootmgr - Used to create/modify boot entries in the UEFI Boot Manager - {{Pkg|efibootmgr}} or {{AUR|efibootmgr-git}}<br />
# uefivars - simply dumps the variables - {{AUR|uefivars-git}} - uses efibootmgr library<br />
# Ubuntu's Firmware Test Suite - fwts - {{AUR|fwts-git}} - uefidump command - {{ic|fwts uefidump}} <br />
<br />
=== Non-Mac UEFI systems ===<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|Using {{ic|efibootmgr}} in Apple Macs will brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<br />
<br />
{{Note|{{ic|efibootmgr}} command will work only if you have booted the system in UEFI mode itself, since it '''requires access to UEFI Runtime Variables''' which are '''available only in UEFI boot mode''' (with "noefi" kernel parameter NOT being used). Otherwise the message {{ic|Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables}} is shown.}}<br />
<br />
{{Note| If you are unable to use {{ic|efibootmgr}}, some UEFI BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI system partition and manually enter the EFI stub location. (for example '\EFI\refind\refind_x64.efi')}}<br />
<br />
Initially the user may be required to manually launch the boot-loader from the firmware itself (using maybe the UEFI Shell) if the UEFI boot-loader was installed when the system is booted in BIOS mode. Then {{ic|efibootmgr}} should be run to make the UEFI boot-loader entry as the default entry in the UEFI Boot Manager.<br />
<br />
To use efibootmgr, first load the 'efivars' kernel module (if compiled as a external module):<br />
<br />
# modprobe efivars<br />
<br />
If you get '''no such device found''' error for this command, that means you have not booted in UEFI mode or due to some reason the kernel is unable to access UEFI Runtime Variables (noefi?).<br />
<br />
Verify whether there are files in ''/sys/firmware/efi/vars/'' (and ''/sys/firmware/efi/efivars/'' for kernel >=3.8) directory. This directory and its contents are created by "efivars" kernel module and it will exist only if you have booted in UEFI mode, without the "noefi" kernel parameter.<br />
<br />
If ''/sys/firmware/efi/vars/'' directory is empty or does not exist, then {{ic|efibootmgr}} command will not work. If you are unable to make the ISO/CD/DVD/USB boot in UEFI mode try [[#Create_UEFI_bootable_USB_from_ISO]].<br />
<br />
{{Note| The below commands use {{Pkg|gummiboot}} boot-loader as example.}}<br />
{{out of date|[[Gummiboot]] has its own installer now, therefore the following instructions should not be used to install [[gummiboot]]. This example should be changed to use something else.}}<br />
<br />
Assume the boot-loader file to be launched is {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}}. {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} can be split up as {{ic|/boot/efi}} and {{ic|/EFI/gummiboot/gummibootx64.efi}}, wherein {{ic|/boot/efi}} is the mountpoint of the UEFI System Partition, which is assumed to be {{ic|/dev/sdXY}} (here X and Y are just placeholders for the actual values - eg:- in {{ic|/dev/sda1}} , X=a Y=1).<br />
<br />
To determine the actual device path for the UEFI System Partition (should be in the form {{ic|/dev/sdXY}}), try :<br />
<br />
# findmnt /boot/efi<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/boot/efi /dev/sdXY vfat rw,flush,tz=UTC<br />
<br />
Then create the boot entry using efibootmgr as follows :<br />
<br />
# efibootmgr -c -g -d /dev/sdX -p Y -w -L "Gummiboot" -l '\EFI\gummiboot\gummibootx64.efi'<br />
<br />
In the above command {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} translates to {{ic|/boot/efi}} and {{ic|/EFI/gummiboot/gummibootx64.efi}} which in turn translate to drive {{ic|/dev/sdX}} -> partition {{ic|Y}} -> file {{ic|/EFI/gummiboot/gummibootx64.efi}}.<br />
<br />
UEFI uses backward slash as path separator (similar to Windows paths).<br />
<br />
The 'label' is the name of the menu entry shown in the UEFI boot menu. This name is user's choice and does not affect the booting of the system. More info can be obtained from [http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=efibootmgr.git;a=blob_plain;f=README;hb=HEAD efibootmgr GIT README] .<br />
<br />
FAT32 filesystem is case-insensitive since it does not use UTF-8 encoding by default. In that case the firmware uses capital 'EFI' instead of small 'efi', therefore using {{ic|\EFI\gummiboot\gummibootx64.efi}} or {{ic|\efi\gummiboot\gummibootx64.efi}} does not matter (this will change if the filesystem encoding is UTF-8).<br />
<br />
== Linux Bootloaders for UEFI ==<br />
<br />
See [[UEFI Bootloaders]].<br />
<br />
== EFI System Partition ==<br />
<br />
{{Note|UEFI System Partition and EFI System Partition (ESP) are same, the terminologies are used interchangeably in some places.}}<br />
<br />
{{Note|1=The EFI System Partition can be of any size supported by FAT32 filesystem. According to Microsoft Documentation, the minimum partition/volume size for FAT32 is 512 MiB. However ESP with size >=100 MiB but formatted as FAT32 are also allowed by many Linux distros and by Microsoft Windows, hence smaller partitions are fine. However >=512 MiB size for ESP is recommended for most compatibility. Non-FAT filesystems like ext2/3/4, reiserfs, NTFS, UDF etc. are not supported for ESP.}}<br />
<br />
{{Note|The ESP should be accessible by the UEFI firmware, which cannot read LVM and software RAID systems.}}<br />
<br />
{{Note|If you are using Linux EFISTUB booting, then you need to make sure there is adequate space available for keeping the Kernel and Initramfs files in the ESP.}}<br />
<br />
{{Note|Setting "boot" flag in parted in a MBR partition marks that partition as active, while the same "boot" flag in a GPT partition marks that partition as "UEFI System Partition".}}<br />
<br />
=== For GPT partitioned disks ===<br />
Two choices:<br />
* Using GNU Parted/GParted: Create a FAT32 partition. Set "boot" flag on for that partition.<br />
* Using GPT fdisk (aka gdisk): Create a partition with partition type {{ic|EF00}}. Then format that partition as FAT32 using {{ic|mkfs.vfat -F32 /dev/<THAT_PARTITION>}}<br />
<br />
=== For MBR partitioned disks ===<br />
{{Note|It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.}}<br />
Two choices:<br />
* Using GNU Parted/GParted: Create FAT32 partition. Change the type code of that partition to {{ic|0xEF}} using fdisk, cfdisk or sfdisk.<br />
* Using fdisk: Create a partition with partition type {{ic|0xEF}}. Then format that partition as FAT32 using {{ic|mkfs.vfat -F32 /dev/<THAT_PARTITION>}}<br />
<br />
== UEFI Shell ==<br />
<br />
The UEFI Shell is a shell/terminal for the firmware which allows launching uefi applications which include uefi bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading uefi drivers, editing text files (edit), hexedit etc. <br />
<br />
=== UEFI Shell download links === <br />
<br />
You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 Sourceforge.net project.<br />
<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi x86_64 UEFI Shell 2.0 (Beta)] - [http://dl.dropbox.com/u/9710721/UEFI_Shell/shellx64_v2.efi Alternate download link] (compiled from SVN repo, try this link if the file downloaded from previous link does not work in your system)<br />
<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi x86_64 UEFI Shell 1.0 (Old)]<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi i386 UEFI Shell 2.0 (Beta)]<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi i386 UEFI Shell 1.0 (Old)]<br />
<br />
Shell 2.0 works only in UEFI 2.3+ systems and is recommended over Shell 1.0 in those systems. Shell 1.0 should work in all UEFI systems irrespective of the spec. version the firmware follows. More info at [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] and [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail]<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your UEFI SYSTEM PARTITION as {{ic|<UEFI_SYSTEM_PARTITION>/shellx64.efi}} (mostly {{ic|/boot/efi/shellx64.efi}}) .<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either F6, F11 or F12 key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with Shell.efi copied as (USB)/efi/boot/bootx64.efi . This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell Commands === <br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). Run {{ic|help -b}} to list available commands.<br />
<br />
More info at http://software.intel.com/en-us/articles/efi-shells-and-scripting/<br />
<br />
==== bcfg ====<br />
<br />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" pdf document.<br />
<br />
{{Note| Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their system.}}<br />
<br />
{{Note| UEFI Shell 1.0 does not support {{ic|bcfg}} command.}}<br />
<br />
To dump a list of current boot entries -<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu<br />
<br />
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where fs0: is the mapping corresponding to the UEFI System Partition and fs0:\EFI\refind\refind_x64.efi is the file to be launched.<br />
<br />
To remove the 4th boot option<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu)<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example rEFInd's refind.conf in the UEFI System Partition (fs0: in the firmware)<br />
<br />
Shell> fs0:<br />
FS0:\> cd \EFI\arch\refind<br />
FS0:\EFI\arch\refind\> edit refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== Hardware Compatibility ==<br />
<br />
Main page [[HCL/Firmwares/UEFI]]<br />
<br />
== Create UEFI bootable USB from ISO ==<br />
<br />
{{Note|1=The instructions below are specifically for [[Archiso]]/official media; [[Archboot]] preparation is identical, with this [https://bbs.archlinux.org/viewtopic.php?pid=1190788#p1190788 refind.conf] instead of the one mentioned below (which is for Archiso) and without the filesystem label requirement.}}<br />
<br />
{{Note|The USB can use either MBR or GPT partition table (so it is fine to use an already partitioned USB). The filesystem should be either FAT32 (recommended) or FAT16. FAT12 is designed for floppy drives and therefore not recommended for USB drives.}}<br />
<br />
First create a partition table and at most one partition in the USB. Mount the ISO image from the [https://www.archlinux.org/download/ Arch Linux download page].<br />
<br />
{{bc|1=<nowiki><br />
# mkdir -p /mnt/{usb,iso}<br />
# mount -o loop archlinux-2012.12.01-dual.iso /mnt/iso<br />
</nowiki>}}<br />
<br />
Then create a FAT32 filesystem in the partition on the USB (unmount before if necessary) with LABEL as used in the Archiso configuration. Obtain the label from {{ic|/mnt/iso/loader/entries/archiso-x86_64.conf}}; this is used by the {{ic|archiso}} hook in initramfs to identify the udev path to the installation media. {{ic|mkfs.vfat}} is part of package {{Pkg|dosfstools}}.<br />
<br />
{{bc|1=<nowiki><br />
# awk 'BEGIN {FS="="} /archisolabel/ {print $3}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat -F32 /dev/sdXY -n<br />
</nowiki>}}<br />
<br />
Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.<br />
<br />
{{bc|1=<nowiki><br />
# mount /dev/sdXY /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/{usb,iso}</nowiki>}}<br />
<br />
<br />
=== Fixing errors ===<br />
<br />
If you find the error: ''"No loader found. Configuration files in /loader/entries/*.conf are needed."'' A possible fix is to use a different uefi bootloader to the included one, gummiboot.<br />
<br />
Download [https://www.archlinux.org/packages/extra/any/refind-efi/download/ refind-efi pkg] and extract the file {{ic|/usr/lib/refind/refind_x64.efi}} from within the package to {{ic|(USB)/EFI/boot/bootx64.efi}} (overwrite or rename any existing {{ic|(USB)/EFI/boot/bootx64.efi}} file).<br />
<br />
Then copy this text to {{ic|EFI/boot/refind.conf}}. Take care that the label in the Arch menu section ({{ic|ARCH_201302}} here) matches that of your usb's.<br />
<br />
{{hc|refind.conf|<nowiki><br />
timeout 5<br />
textonly<br />
<br />
showtools about,reboot,shutdown,exit<br />
# scan_driver_dirs EFI/tools/drivers_x64<br />
scanfor manual,internal,external,optical<br />
<br />
scan_delay 1<br />
dont_scan_dirs EFI/boot<br />
<br />
max_tags 0<br />
default_selection "Arch Linux Archiso x86_64 UEFI USB"<br />
<br />
menuentry "Arch Linux Archiso x86_64 UEFI USB" {<br />
loader /arch/boot/x86_64/vmlinuz<br />
initrd /arch/boot/x86_64/archiso.img<br />
ostype Linux<br />
graphics off<br />
options "archisobasedir=arch archisolabel=ARCH_201302 add_efi_memmap"<br />
}<br />
<br />
menuentry "UEFI x86_64 Shell v2" {<br />
loader /EFI/shellx64_v2.efi<br />
graphics off<br />
}<br />
<br />
menuentry "UEFI x86_64 Shell v1" {<br />
loader /EFI/shellx64_v1.efi<br />
graphics off<br />
}<br />
</nowiki>}}<br />
<br />
You should now be able to successfully boot, and you can choose which EFI you'd like to load.<br />
<br />
== Remove UEFI boot support from ISO ==<br />
<br />
{{Warning|In the event that UEFI+isohybrid El Torito/MBR really causes problems, it would be better to just UEFI boot using the USB stick instructions in the previous section}}<br />
<br />
Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD. If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first.<br />
<br />
Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
Rebuild the ISO using {{ic|xorriso}} from {{pkg|libisoburn}}:<br />
<br />
{{bc|1=<nowiki><br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "ARCH_201212" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared like a BAWSE" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output "~/archiso.iso" "/mnt/iso/"</nowiki>}}<br />
<br />
Burn {{ic|~/archiso.iso}} to optical media and proceed with installation normally.<br />
<br />
== QEMU with OVMF ==<br />
<br />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU and KVM.<br />
<br />
You can build OVMF from AUR [https://aur.archlinux.org/packages/ovmf-svn/] and use it like this:<br />
<br />
qemu-system-x86_64 -bios /usr/share/ovmf/bios.bin ...<br />
<br />
== See also ==<br />
<br />
* Wikipedia's page on [http://en.wikipedia.org/wiki/UEFI UEFI]<br />
* Wikipedia's page on [http://en.wikipedia.org/wiki/EFI_System_partition UEFI SYSTEM Partition]<br />
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD Linux Kernel UEFI Documentation]<br />
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel's Tianocore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<br />
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]<br />
* [http://hackthejoggler.freeforums.org/download/file.php?id=28 Some useful 32-bit UEFI Shell utilities]<br />
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=254253Unified Extensible Firmware Interface2013-04-16T07:48:13Z<p>Eruditorum: /* Booting an OS using UEFI */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-CN:Unified Extensible Firmware Interface]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the Unified Extensible Firmware Interface.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GUID Partition Table}}<br />
{{Article summary wiki|Master Boot Record}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "MBR boot code" method followed for BIOS systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0 . As of 23 May 2012, UEFI Specification 2.3.1 is the most recent version.<br />
<br />
{{Note|Unless specified as EFI 1.x , EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitely, these instructions are general and not Mac specific. Some of them may not work or may be different in Macs. Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one UEFI Specification version and therefore it is not a standard UEFI firmware.}}<br />
<br />
== Booting an OS using BIOS ==<br />
<br />
A BIOS or Basic Input-Output System is the very first program that is executed once the system is switched on. After all the hardware has been initialized and the POST operation has completed, the BIOS executes the first boot code in the first device in the device booting list. <br />
<br />
If the list starts with a CD/DVD drive, then the El-Torito entry in the CD/DVD is executed. This is how bootable CD/DVD works. If the list starts with a HDD, then BIOS executes the very first 440 bytes MBR boot code. The boot code then chainloads or bootstraps a much larger and complex bootloader which then loads the OS.<br />
<br />
Basically, the BIOS does not know how to read a partition table or filesystem. All it does is initialize the hardware, then load and run the 440-byte boot code.<br />
<br />
=== Multiboot on BIOS ===<br />
<br />
Since very little can be achieved by a program that fits into the 440-byte boot code area, multi-booting using BIOS requires a multi-boot capable bootloader (multi-boot refers to booting multiple operating systems, not to booting a kernel in the Multiboot format specified by the GRUB developers). So usually a common bootloader like [[GRUB]] or [[Syslinux]] or [[LILO]] would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel.<br />
<br />
== Booting an OS using UEFI ==<br />
<br />
UEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS. UEFI has support for reading both the partition table as well as understanding filesystems. <br />
<br />
The commonly used UEFI firmwares support both MBR and GPT partition table. EFI in Apple-Intel Macs are known to also support Apple Partition Map besides MBR and GPT. Most UEFI firmwares have support for accessing FAT12 (floppy disks), FAT16 and FAT32 filesystems in HDDs and ISO9660 (and UDF) in CD/DVDs. EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones.<br />
<br />
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called ''EFI SYSTEM PARTITION'' in which files required to be launched by the firmware are stored. Each vendor can store its files under {{ic|<EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/}} folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32.<br />
<br />
{{Note|On some UEFI systems the only possible way to launch UEFI application on boot (if it doesn't have custom entry in UEFI boot menu) is to put it in this fixed location: <EFI SYSTEM PARTITION>/EFI/boot/bootx64.efi}}<br />
<br />
Under UEFI, every program whether it is an OS loader or an utility (e.g. a memory testing app or recovery tool), should be an UEFI Application corresponding to the EFI firmware architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use i386 EFI are older (pre 2008) Apple Macs.<br />
<br />
{{Note|Some older Intel Server boards are known to operate on Intel EFI 1.10 firmware, and require i386 EFI applications.}}<br />
<br />
A x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike x86_64 Linux and Windows versions which include such support. Therefore the bootloader must be compiled for that specific architecture.<br />
<br />
=== Multibooting on UEFI ===<br />
<br />
Since each OS or vendor can maintain its own files within the EFI SYSTEM PARTITION without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes.<br />
<br />
==== Multibooting Windows and Linux ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using UEFI firmware. These Windows versions support either UEFI-GPT booting or BIOS-MBR booting. 32-bit Windows versions only support BIOS-MBR booting. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
This limitation does not exist in Linux Kernel but rather depends on the bootloader used. For the sake of Windows UEFI booting, the Linux bootloader used should also be installed in UEFI-GPT mode if booting from the same disk.<br />
<br />
== Boot Process under UEFI ==<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded.<br />
# Firmware reads its Boot Manager to determine which UEFI application to be launched and from where (ie. from which disk and partition).<br />
# Firmware launches the UEFI application from the FAT32 formatted UEFISYS partition as defined in the boot entry in the firmware's boot manager.<br />
# UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a bootloader like GRUB) depending on how the UEFI application was configured.<br />
<br />
== Detecting UEFI Firmware Arch ==<br />
<br />
If you have a non-Mac UEFI system, then you most likely have a x86_64 (aka 64-bit) UEFI 2.x firmware. A few known x86_64 UEFI 2.x firmwares are Phoenix SecureCore Tiano, AMI Aptio (but some are UEFI 1.x) and Insyde H2O.<br />
<br />
Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi. All Macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware. <br />
<br />
To find out the arch of the efi firmware in a Mac, type the following into the terminal:<br />
ioreg -l -p IODeviceTree | grep firmware-abi<br />
If the command returns EFI32 then it is i386 EFI 1.x firmware. If it returns EFI64 then it is x86_64 EFI 1.x firmware. Macs do not have UEFI 2.x firmware as Apple's EFI implementation is not fully compliant with UEFI Specification.<br />
<br />
== UEFI Support in Linux Kernel ==<br />
<br />
=== Linux Kernel config options for UEFI ===<br />
<br />
The required Linux Kernel configuration options for UEFI systems are :<br />
<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables/Services Support - 'efivars' kernel module . This option is important as this is required to manipulate UEFI Runtime Variables using tools like '''efibootmgr'''.<br />
<br />
CONFIG_EFI_VARS=y<br />
<br />
{{Note| This option is compiled built-in into the Arch core/testing kernel.}}<br />
<br />
{{Note|For Linux to access UEFI Runtime Services, the UEFI Firmware processor architecture and the Linux kernel processor architecture must match. This is independent of the bootloader used.}}<br />
<br />
{{Note|If the UEFI Firmware arch and Linux Kernel arch are different, then the "'''noefi'''" kernel parameter must be used to avoid the kernel panic and boot successfully. The "noefi" option instructs the kernel not to access the UEFI Runtime Services.}}<br />
<br />
GUID Partition Table [[GPT]] config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
{{Note|All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos.}}<br />
<br />
Retrieved from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD .<br />
<br />
== UEFI Variables Support ==<br />
<br />
UEFI defines variables through which an operating system can interact with the firmware. UEFI Boot Variables are used by the boot-loader and used by the OS only for early system start-up. UEFI Runtime Variables allow an OS to manage certain settings of the firmware like the UEFI Boot Manager or managing the keys for UEFI Secure Boot Protocol etc.<br />
<br />
{{Note|The below steps will not work if the system has been booted in BIOS mode and will not work if the UEFI processor architecture does not match the kernel one, i.e. x86_64 UEFI + x86 32-bit Kernel and vice-versa config will not work. This is true only for efivars kernel module and efibootmgr step. The other steps (ie. upto setting up <UEFISYS>/EFI/arch/refind/{refindx64.efi,refind.conf} ) can be done even in BIOS/Legacy boot mode.}}<br />
<br />
Access to UEFI Runtime services is provided by "efivars" kernel module which is enabled through the {{ic|<nowiki>CONFIG_EFI_VARS=y</nowiki>}} kernel config option. This module exposes the variables under the directory {{ic|/sys/firmware/efi/vars}} (for kernels >=3.8 through {{ic|/sys/firmware/efi/efivars}}). One way to check whether the system has booted in UEFI boot mode is to check for the existence of {{ic|/sys/firmware/efi/vars}} (and in kernels >=3.8 for {{ic|/sys/firmware/efi/efivars}})directory with contents similar to :<br />
<br />
Sample output (x86_64-UEFI 2.3.1 in x86_64 Kernel):<br />
<br />
# ls -1 /sys/firmware/efi/vars/<br />
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
MTC-eb704011-1402-11d3-8e77-00a0c969723b/<br />
MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa/<br />
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
RTC-378d7b65-8da9-4773-b6e4-a47826a833e1/<br />
del_var<br />
new_var<br />
<br />
The UEFI Runtime Variables will not be exposed to the OS if you have used "noefi" kernel parameter in the boot-loader menu. This parameter instructs the kernel to completely ignore UEFI Runtime Services.<br />
<br />
=== Userspace Tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
# efibootmgr - Used to create/modify boot entries in the UEFI Boot Manager - {{Pkg|efibootmgr}} or {{AUR|efibootmgr-git}}<br />
# uefivars - simply dumps the variables - {{AUR|uefivars-git}} - uses efibootmgr library<br />
# Ubuntu's Firmware Test Suite - fwts - {{AUR|fwts-git}} - uefidump command - {{ic|fwts uefidump}} <br />
<br />
=== Non-Mac UEFI systems ===<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|Using {{ic|efibootmgr}} in Apple Macs will brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<br />
<br />
{{Note|{{ic|efibootmgr}} command will work only if you have booted the system in UEFI mode itself, since it '''requires access to UEFI Runtime Variables''' which are '''available only in UEFI boot mode''' (with "noefi" kernel parameter NOT being used). Otherwise the message {{ic|Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables}} is shown.}}<br />
<br />
{{Note| If you are unable to use {{ic|efibootmgr}}, some UEFI BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI system partition and manually enter the EFI stub location. (for example '\EFI\refind\refind_x64.efi')}}<br />
<br />
Initially the user may be required to manually launch the boot-loader from the firmware itself (using maybe the UEFI Shell) if the UEFI boot-loader was installed when the system is booted in BIOS mode. Then {{ic|efibootmgr}} should be run to make the UEFI boot-loader entry as the default entry in the UEFI Boot Manager.<br />
<br />
To use efibootmgr, first load the 'efivars' kernel module (if compiled as a external module):<br />
<br />
# modprobe efivars<br />
<br />
If you get '''no such device found''' error for this command, that means you have not booted in UEFI mode or due to some reason the kernel is unable to access UEFI Runtime Variables (noefi?).<br />
<br />
Verify whether there are files in ''/sys/firmware/efi/vars/'' (and ''/sys/firmware/efi/efivars/'' for kernel >=3.8) directory. This directory and its contents are created by "efivars" kernel module and it will exist only if you have booted in UEFI mode, without the "noefi" kernel parameter.<br />
<br />
If ''/sys/firmware/efi/vars/'' directory is empty or does not exist, then {{ic|efibootmgr}} command will not work. If you are unable to make the ISO/CD/DVD/USB boot in UEFI mode try [[#Create_UEFI_bootable_USB_from_ISO]].<br />
<br />
{{Note| The below commands use {{Pkg|gummiboot}} boot-loader as example.}}<br />
{{out of date|[[Gummiboot]] has its own installer now, therefore the following instructions should not be used to install [[gummiboot]]. This example should be changed to use something else.}}<br />
<br />
Assume the boot-loader file to be launched is {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}}. {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} can be split up as {{ic|/boot/efi}} and {{ic|/EFI/gummiboot/gummibootx64.efi}}, wherein {{ic|/boot/efi}} is the mountpoint of the UEFI System Partition, which is assumed to be {{ic|/dev/sdXY}} (here X and Y are just placeholders for the actual values - eg:- in {{ic|/dev/sda1}} , X=a Y=1).<br />
<br />
To determine the actual device path for the UEFI System Partition (should be in the form {{ic|/dev/sdXY}}), try :<br />
<br />
# findmnt /boot/efi<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/boot/efi /dev/sdXY vfat rw,flush,tz=UTC<br />
<br />
Then create the boot entry using efibootmgr as follows :<br />
<br />
# efibootmgr -c -g -d /dev/sdX -p Y -w -L "Gummiboot" -l '\EFI\gummiboot\gummibootx64.efi'<br />
<br />
In the above command {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} translates to {{ic|/boot/efi}} and {{ic|/EFI/gummiboot/gummibootx64.efi}} which in turn translate to drive {{ic|/dev/sdX}} -> partition {{ic|Y}} -> file {{ic|/EFI/gummiboot/gummibootx64.efi}}.<br />
<br />
UEFI uses backward slash as path separator (similar to Windows paths).<br />
<br />
The 'label' is the name of the menu entry shown in the UEFI boot menu. This name is user's choice and does not affect the booting of the system. More info can be obtained from [http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=efibootmgr.git;a=blob_plain;f=README;hb=HEAD efibootmgr GIT README] .<br />
<br />
FAT32 filesystem is case-insensitive since it does not use UTF-8 encoding by default. In that case the firmware uses capital 'EFI' instead of small 'efi', therefore using {{ic|\EFI\gummiboot\gummibootx64.efi}} or {{ic|\efi\gummiboot\gummibootx64.efi}} does not matter (this will change if the filesystem encoding is UTF-8).<br />
<br />
== Linux Bootloaders for UEFI ==<br />
<br />
See [[UEFI Bootloaders]].<br />
<br />
== EFI System Partition ==<br />
<br />
{{Note|UEFI System Partition and EFI System Partition (ESP) are same, the terminologies are used interchangeably in some places.}}<br />
<br />
{{Note|1=The EFI System Partition can be of any size supported by FAT32 filesystem. According to Microsoft Documentation, the minimum partition/volume size for FAT32 is 512 MiB. However ESP with size >=100 MiB but formatted as FAT32 are also allowed by many Linux distros and by Microsoft Windows, hence smaller partitions are fine. However >=512 MiB size for ESP is recommended for most compatibility. Non-FAT filesystems like ext2/3/4, reiserfs, NTFS, UDF etc. are not supported for ESP.}}<br />
<br />
{{Note|The ESP should be accessible by the UEFI firmware, which cannot read LVM and software RAID systems.}}<br />
<br />
{{Note|If you are using Linux EFISTUB booting, then you need to make sure there is adequate space available for keeping the Kernel and Initramfs files in the ESP.}}<br />
<br />
{{Note|Setting "boot" flag in parted in a MBR partition marks that partition as active, while the same "boot" flag in a GPT partition marks that partition as "UEFI System Partition".}}<br />
<br />
=== For GPT partitioned disks ===<br />
Two choices:<br />
* Using GNU Parted/GParted: Create a FAT32 partition. Set "boot" flag on for that partition.<br />
* Using GPT fdisk (aka gdisk): Create a partition with partition type {{ic|EF00}}. Then format that partition as FAT32 using {{ic|mkfs.vfat -F32 /dev/<THAT_PARTITION>}}<br />
<br />
=== For MBR partitioned disks ===<br />
{{Note|It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.}}<br />
Two choices:<br />
* Using GNU Parted/GParted: Create FAT32 partition. Change the type code of that partition to {{ic|0xEF}} using fdisk, cfdisk or sfdisk.<br />
* Using fdisk: Create a partition with partition type {{ic|0xEF}}. Then format that partition as FAT32 using {{ic|mkfs.vfat -F32 /dev/<THAT_PARTITION>}}<br />
<br />
== UEFI Shell ==<br />
<br />
The UEFI Shell is a shell/terminal for the firmware which allows launching uefi applications which include uefi bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading uefi drivers, editing text files (edit), hexedit etc. <br />
<br />
=== UEFI Shell download links === <br />
<br />
You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 Sourceforge.net project.<br />
<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi x86_64 UEFI Shell 2.0 (Beta)] - [http://dl.dropbox.com/u/9710721/UEFI_Shell/shellx64_v2.efi Alternate download link] (compiled from SVN repo, try this link if the file downloaded from previous link does not work in your system)<br />
<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi x86_64 UEFI Shell 1.0 (Old)]<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi i386 UEFI Shell 2.0 (Beta)]<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi i386 UEFI Shell 1.0 (Old)]<br />
<br />
Shell 2.0 works only in UEFI 2.3+ systems and is recommended over Shell 1.0 in those systems. Shell 1.0 should work in all UEFI systems irrespective of the spec. version the firmware follows. More info at [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] and [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail]<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your UEFI SYSTEM PARTITION as {{ic|<UEFI_SYSTEM_PARTITION>/shellx64.efi}} (mostly {{ic|/boot/efi/shellx64.efi}}) .<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either F6, F11 or F12 key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with Shell.efi copied as (USB)/efi/boot/bootx64.efi . This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell Commands === <br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). Run {{ic|help -b}} to list available commands.<br />
<br />
More info at http://software.intel.com/en-us/articles/efi-shells-and-scripting/<br />
<br />
==== bcfg ====<br />
<br />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" pdf document.<br />
<br />
{{Note| Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their system.}}<br />
<br />
{{Note| UEFI Shell 1.0 does not support {{ic|bcfg}} command.}}<br />
<br />
To dump a list of current boot entries -<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu<br />
<br />
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where fs0: is the mapping corresponding to the UEFI System Partition and fs0:\EFI\refind\refind_x64.efi is the file to be launched.<br />
<br />
To remove the 4th boot option<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu)<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example rEFInd's refind.conf in the UEFI System Partition (fs0: in the firmware)<br />
<br />
Shell> fs0:<br />
FS0:\> cd \EFI\arch\refind<br />
FS0:\EFI\arch\refind\> edit refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== Hardware Compatibility ==<br />
<br />
Main page [[HCL/Firmwares/UEFI]]<br />
<br />
== Create UEFI bootable USB from ISO ==<br />
<br />
{{Note|1=The instructions below are specifically for [[Archiso]]/official media; [[Archboot]] preparation is identical, with this [https://bbs.archlinux.org/viewtopic.php?pid=1190788#p1190788 refind.conf] instead of the one mentioned below (which is for Archiso) and without the filesystem label requirement.}}<br />
<br />
{{Note|The USB can use either MBR or GPT partition table (so it is fine to use an already partitioned USB). The filesystem should be either FAT32 (recommended) or FAT16. FAT12 is designed for floppy drives and therefore not recommended for USB drives.}}<br />
<br />
First create a partition table and at most one partition in the USB. Mount the ISO image from the [https://www.archlinux.org/download/ Arch Linux download page].<br />
<br />
{{bc|1=<nowiki><br />
# mkdir -p /mnt/{usb,iso}<br />
# mount -o loop archlinux-2012.12.01-dual.iso /mnt/iso<br />
</nowiki>}}<br />
<br />
Then create a FAT32 filesystem in the partition on the USB (unmount before if necessary) with LABEL as used in the Archiso configuration. Obtain the label from {{ic|/mnt/iso/loader/entries/archiso-x86_64.conf}}; this is used by the {{ic|archiso}} hook in initramfs to identify the udev path to the installation media. {{ic|mkfs.vfat}} is part of package {{Pkg|dosfstools}}.<br />
<br />
{{bc|1=<nowiki><br />
# awk 'BEGIN {FS="="} /archisolabel/ {print $3}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat -F32 /dev/sdXY -n<br />
</nowiki>}}<br />
<br />
Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.<br />
<br />
{{bc|1=<nowiki><br />
# mount /dev/sdXY /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/{usb,iso}</nowiki>}}<br />
<br />
<br />
=== Fixing errors ===<br />
<br />
If you find the error: ''"No loader found. Configuration files in /loader/entries/*.conf are needed."'' A possible fix is to use a different uefi bootloader to the included one, gummiboot.<br />
<br />
Download [https://www.archlinux.org/packages/extra/any/refind-efi/download/ refind-efi pkg] and extract the file {{ic|/usr/lib/refind/refind_x64.efi}} from within the package to {{ic|(USB)/EFI/boot/bootx64.efi}} (overwrite or rename any existing {{ic|(USB)/EFI/boot/bootx64.efi}} file).<br />
<br />
Then copy this text to {{ic|EFI/boot/refind.conf}}. Take care that the label in the Arch menu section ({{ic|ARCH_201302}} here) matches that of your usb's.<br />
<br />
{{hc|refind.conf|<nowiki><br />
timeout 5<br />
textonly<br />
<br />
showtools about,reboot,shutdown,exit<br />
# scan_driver_dirs EFI/tools/drivers_x64<br />
scanfor manual,internal,external,optical<br />
<br />
scan_delay 1<br />
dont_scan_dirs EFI/boot<br />
<br />
max_tags 0<br />
default_selection "Arch Linux Archiso x86_64 UEFI USB"<br />
<br />
menuentry "Arch Linux Archiso x86_64 UEFI USB" {<br />
loader /arch/boot/x86_64/vmlinuz<br />
initrd /arch/boot/x86_64/archiso.img<br />
ostype Linux<br />
graphics off<br />
options "archisobasedir=arch archisolabel=ARCH_201302 add_efi_memmap"<br />
}<br />
<br />
menuentry "UEFI x86_64 Shell v2" {<br />
loader /EFI/shellx64_v2.efi<br />
graphics off<br />
}<br />
<br />
menuentry "UEFI x86_64 Shell v1" {<br />
loader /EFI/shellx64_v1.efi<br />
graphics off<br />
}<br />
</nowiki>}}<br />
<br />
You should now be able to successfully boot, and you can choose which EFI you'd like to load.<br />
<br />
== Remove UEFI boot support from ISO ==<br />
<br />
{{Warning|In the event that UEFI+isohybrid El Torito/MBR really causes problems, it would be better to just UEFI boot using the USB stick instructions in the previous section}}<br />
<br />
Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD. If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first.<br />
<br />
Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
Rebuild the ISO using {{ic|xorriso}} from {{pkg|libisoburn}}:<br />
<br />
{{bc|1=<nowiki><br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "ARCH_201212" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared like a BAWSE" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output "~/archiso.iso" "/mnt/iso/"</nowiki>}}<br />
<br />
Burn {{ic|~/archiso.iso}} to optical media and proceed with installation normally.<br />
<br />
== QEMU with OVMF ==<br />
<br />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU and KVM.<br />
<br />
You can build OVMF from AUR [https://aur.archlinux.org/packages/ovmf-svn/] and use it like this:<br />
<br />
qemu-system-x86_64 -bios /usr/share/ovmf/bios.bin ...<br />
<br />
== See also ==<br />
<br />
* Wikipedia's page on [http://en.wikipedia.org/wiki/UEFI UEFI]<br />
* Wikipedia's page on [http://en.wikipedia.org/wiki/EFI_System_partition UEFI SYSTEM Partition]<br />
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD Linux Kernel UEFI Documentation]<br />
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel's Tianocore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<br />
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]<br />
* [http://hackthejoggler.freeforums.org/download/file.php?id=28 Some useful 32-bit UEFI Shell utilities]<br />
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Unified_Extensible_Firmware_Interface&diff=254251Unified Extensible Firmware Interface2013-04-16T07:41:34Z<p>Eruditorum: /* Detecting UEFI Firmware Arch */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[es:Unified Extensible Firmware Interface]]<br />
[[it:Unified Extensible Firmware Interface]]<br />
[[ja:Unified Extensible Firmware Interface]]<br />
[[ru:Unified Extensible Firmware Interface]]<br />
[[zh-CN:Unified Extensible Firmware Interface]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of the Unified Extensible Firmware Interface.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GUID Partition Table}}<br />
{{Article summary wiki|Master Boot Record}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
'''Unified Extensible Firmware Interface''' (or UEFI for short) is a new type of firmware that was initially designed by Intel (known as EFI then) mainly for its Itanium based systems. It introduces new ways of booting an OS that is distinct from the commonly used "MBR boot code" method followed for BIOS systems. It started as Intel's EFI in versions 1.x and then a group of companies called the UEFI Forum took over its development from which it was called Unified EFI starting with version 2.0 . As of 23 May 2012, UEFI Specification 2.3.1 is the most recent version.<br />
<br />
{{Note|Unless specified as EFI 1.x , EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitely, these instructions are general and not Mac specific. Some of them may not work or may be different in Macs. Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one UEFI Specification version and therefore it is not a standard UEFI firmware.}}<br />
<br />
== Booting an OS using BIOS ==<br />
<br />
A BIOS or Basic Input-Output System is the very first program that is executed once the system is switched on. After all the hardware has been initialized and the POST operation has completed, the BIOS executes the first boot code in the first device in the device booting list. <br />
<br />
If the list starts with a CD/DVD drive, then the El-Torito entry in the CD/DVD is executed. This is how bootable CD/DVD works. If the list starts with a HDD, then BIOS executes the very first 440 bytes MBR boot code. The boot code then chainloads or bootstraps a much larger and complex bootloader which then loads the OS.<br />
<br />
Basically, the BIOS does not know how to read a partition table or filesystem. All it does is initialize the hardware, then load and run the 440-byte boot code.<br />
<br />
=== Multiboot on BIOS ===<br />
<br />
Since very little can be achieved by a program that fits into the 440-byte boot code area, multi-booting using BIOS requires a multi-boot capable bootloader (multi-boot refers to booting multiple operating systems, not to booting a kernel in the Multiboot format specified by the GRUB developers). So usually a common bootloader like [[GRUB]] or [[Syslinux]] or [[LILO]] would be loaded by the BIOS, and it would load an operating system by either chain-loading or directly loading the kernel.<br />
<br />
== Booting an OS using UEFI ==<br />
<br />
UEFI firmware does not support booting through the above mentioned method which is the only way supported by BIOS. UEFI has support for reading both the partition table as well as understanding filesystems. <br />
<br />
The commonly used UEFI firmwares support both MBR and GPT partition table. EFI in Apple-Intel Macs are known to also support Apple Partition Map besides MBR and GPT. Most UEFI firmwares have support for accessing FAT12 (floppy disks), FAT16 and FAT32 filesystems in HDDs and ISO9660 (and UDF) in CD/DVDs. EFI in Apple-Intel Macs can access HFS/HFS+ filesystems also apart from the mentioned ones.<br />
<br />
UEFI does not launch any boot code in the MBR whether it exists or not. Instead it uses a special partition in the partition table called ''EFI SYSTEM PARTITION'' in which files required to be launched by the firmware are stored. Each vendor can store its files under {{ic|<EFI SYSTEM PARTITION>/EFI/<VENDOR NAME>/}} folder and can use the firmware or its shell (UEFI shell) to launch the boot program. An EFI System Partition is usually formatted as FAT32.<br />
<br />
Under UEFI, every program whether it is an OS loader or an utility (e.g. a memory testing app or recovery tool), should be an UEFI Application corresponding to the EFI firmware architecture. The vast majority of UEFI firmwares, including recent Apple Macs, use x86_64 EFI firmware. The only known devices that use i386 EFI are older (pre 2008) Apple Macs.<br />
<br />
{{Note|Some older Intel Server boards are known to operate on Intel EFI 1.10 firmware, and require i386 EFI applications.}}<br />
<br />
A x86_64 EFI firmware does not include support for launching 32-bit EFI apps unlike x86_64 Linux and Windows versions which include such support. Therefore the bootloader must be compiled for that specific architecture.<br />
<br />
=== Multibooting on UEFI ===<br />
<br />
Since each OS or vendor can maintain its own files within the EFI SYSTEM PARTITION without affecting the other, multi-booting using UEFI is just a matter of launching a different UEFI application corresponding to the particular OS's bootloader. This removes the need for relying on chainloading mechanisms of one bootloader to load another to switch OSes.<br />
<br />
==== Multibooting Windows and Linux ====<br />
<br />
64-bit Windows Vista (SP1+), Windows 7 and Windows 8 versions support booting using UEFI firmware. These Windows versions support either UEFI-GPT booting or BIOS-MBR booting. 32-bit Windows versions only support BIOS-MBR booting. See http://support.microsoft.com/kb/2581408 for more info.<br />
<br />
This limitation does not exist in Linux Kernel but rather depends on the bootloader used. For the sake of Windows UEFI booting, the Linux bootloader used should also be installed in UEFI-GPT mode if booting from the same disk.<br />
<br />
== Boot Process under UEFI ==<br />
<br />
# System switched on - Power On Self Test, or POST process.<br />
# UEFI firmware is loaded.<br />
# Firmware reads its Boot Manager to determine which UEFI application to be launched and from where (ie. from which disk and partition).<br />
# Firmware launches the UEFI application from the FAT32 formatted UEFISYS partition as defined in the boot entry in the firmware's boot manager.<br />
# UEFI application may launch another application (in case of UEFI Shell or a boot manager like rEFInd) or the kernel and initramfs (in case of a bootloader like GRUB) depending on how the UEFI application was configured.<br />
<br />
== Detecting UEFI Firmware Arch ==<br />
<br />
If you have a non-Mac UEFI system, then you most likely have a x86_64 (aka 64-bit) UEFI 2.x firmware. A few known x86_64 UEFI 2.x firmwares are Phoenix SecureCore Tiano, AMI Aptio (but some are UEFI 1.x) and Insyde H2O.<br />
<br />
Pre-2008 Macs mostly have i386-efi firmware while >=2008 Macs have mostly x86_64-efi. All Macs capable of running Mac OS X Snow Leopard 64-bit Kernel have x86_64 EFI 1.x firmware. <br />
<br />
To find out the arch of the efi firmware in a Mac, type the following into the terminal:<br />
ioreg -l -p IODeviceTree | grep firmware-abi<br />
If the command returns EFI32 then it is i386 EFI 1.x firmware. If it returns EFI64 then it is x86_64 EFI 1.x firmware. Macs do not have UEFI 2.x firmware as Apple's EFI implementation is not fully compliant with UEFI Specification.<br />
<br />
== UEFI Support in Linux Kernel ==<br />
<br />
=== Linux Kernel config options for UEFI ===<br />
<br />
The required Linux Kernel configuration options for UEFI systems are :<br />
<br />
CONFIG_EFI=y<br />
CONFIG_EFI_STUB=y<br />
CONFIG_RELOCATABLE=y<br />
CONFIG_FB_EFI=y<br />
CONFIG_FRAMEBUFFER_CONSOLE=y<br />
<br />
UEFI Runtime Variables/Services Support - 'efivars' kernel module . This option is important as this is required to manipulate UEFI Runtime Variables using tools like '''efibootmgr'''.<br />
<br />
CONFIG_EFI_VARS=y<br />
<br />
{{Note| This option is compiled built-in into the Arch core/testing kernel.}}<br />
<br />
{{Note|For Linux to access UEFI Runtime Services, the UEFI Firmware processor architecture and the Linux kernel processor architecture must match. This is independent of the bootloader used.}}<br />
<br />
{{Note|If the UEFI Firmware arch and Linux Kernel arch are different, then the "'''noefi'''" kernel parameter must be used to avoid the kernel panic and boot successfully. The "noefi" option instructs the kernel not to access the UEFI Runtime Services.}}<br />
<br />
GUID Partition Table [[GPT]] config option - mandatory for UEFI support<br />
<br />
CONFIG_EFI_PARTITION=y<br />
<br />
{{Note|All of the above options are required to boot Linux via UEFI, and are enabled in Archlinux kernels in official repos.}}<br />
<br />
Retrieved from http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD .<br />
<br />
== UEFI Variables Support ==<br />
<br />
UEFI defines variables through which an operating system can interact with the firmware. UEFI Boot Variables are used by the boot-loader and used by the OS only for early system start-up. UEFI Runtime Variables allow an OS to manage certain settings of the firmware like the UEFI Boot Manager or managing the keys for UEFI Secure Boot Protocol etc.<br />
<br />
{{Note|The below steps will not work if the system has been booted in BIOS mode and will not work if the UEFI processor architecture does not match the kernel one, i.e. x86_64 UEFI + x86 32-bit Kernel and vice-versa config will not work. This is true only for efivars kernel module and efibootmgr step. The other steps (ie. upto setting up <UEFISYS>/EFI/arch/refind/{refindx64.efi,refind.conf} ) can be done even in BIOS/Legacy boot mode.}}<br />
<br />
Access to UEFI Runtime services is provided by "efivars" kernel module which is enabled through the {{ic|<nowiki>CONFIG_EFI_VARS=y</nowiki>}} kernel config option. This module exposes the variables under the directory {{ic|/sys/firmware/efi/vars}} (for kernels >=3.8 through {{ic|/sys/firmware/efi/efivars}}). One way to check whether the system has booted in UEFI boot mode is to check for the existence of {{ic|/sys/firmware/efi/vars}} (and in kernels >=3.8 for {{ic|/sys/firmware/efi/efivars}})directory with contents similar to :<br />
<br />
Sample output (x86_64-UEFI 2.3.1 in x86_64 Kernel):<br />
<br />
# ls -1 /sys/firmware/efi/vars/<br />
Boot0000-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootCurrent-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootOptionSupport-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
BootOrder-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConIn-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConInDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConOut-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ConOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
ErrOutDev-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
Lang-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
LangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
MTC-eb704011-1402-11d3-8e77-00a0c969723b/<br />
MemoryTypeInformation-4c19049f-4137-4dd3-9c10-8b97a83ffdfa/<br />
PlatformLang-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
PlatformLangCodes-8be4df61-93ca-11d2-aa0d-00e098032b8c/<br />
RTC-378d7b65-8da9-4773-b6e4-a47826a833e1/<br />
del_var<br />
new_var<br />
<br />
The UEFI Runtime Variables will not be exposed to the OS if you have used "noefi" kernel parameter in the boot-loader menu. This parameter instructs the kernel to completely ignore UEFI Runtime Services.<br />
<br />
=== Userspace Tools ===<br />
<br />
There are few tools that can access/modify the UEFI variables, namely<br />
<br />
# efibootmgr - Used to create/modify boot entries in the UEFI Boot Manager - {{Pkg|efibootmgr}} or {{AUR|efibootmgr-git}}<br />
# uefivars - simply dumps the variables - {{AUR|uefivars-git}} - uses efibootmgr library<br />
# Ubuntu's Firmware Test Suite - fwts - {{AUR|fwts-git}} - uefidump command - {{ic|fwts uefidump}} <br />
<br />
=== Non-Mac UEFI systems ===<br />
<br />
==== efibootmgr ====<br />
<br />
{{Warning|Using {{ic|efibootmgr}} in Apple Macs will brick the firmware and may need reflash of the motherboard ROM. There have been bug reports regarding this in Ubuntu/Launchpad bug tracker. Use bless command alone in case of Macs. Experimental "bless" utility for Linux by Fedora developers - {{AUR|mactel-boot}}.}}<br />
<br />
{{Note|{{ic|efibootmgr}} command will work only if you have booted the system in UEFI mode itself, since it '''requires access to UEFI Runtime Variables''' which are '''available only in UEFI boot mode''' (with "noefi" kernel parameter NOT being used). Otherwise the message {{ic|Fatal: Couldn't open either sysfs or procfs directories for accessing EFI variables}} is shown.}}<br />
<br />
{{Note| If you are unable to use {{ic|efibootmgr}}, some UEFI BIOSes allow users to directly manage uefi boot options from within the BIOS. For example, some ASUS BIOSes have a "Add New Boot Option" choice which enables you to select a local EFI system partition and manually enter the EFI stub location. (for example '\EFI\refind\refind_x64.efi')}}<br />
<br />
Initially the user may be required to manually launch the boot-loader from the firmware itself (using maybe the UEFI Shell) if the UEFI boot-loader was installed when the system is booted in BIOS mode. Then {{ic|efibootmgr}} should be run to make the UEFI boot-loader entry as the default entry in the UEFI Boot Manager.<br />
<br />
To use efibootmgr, first load the 'efivars' kernel module (if compiled as a external module):<br />
<br />
# modprobe efivars<br />
<br />
If you get '''no such device found''' error for this command, that means you have not booted in UEFI mode or due to some reason the kernel is unable to access UEFI Runtime Variables (noefi?).<br />
<br />
Verify whether there are files in ''/sys/firmware/efi/vars/'' (and ''/sys/firmware/efi/efivars/'' for kernel >=3.8) directory. This directory and its contents are created by "efivars" kernel module and it will exist only if you have booted in UEFI mode, without the "noefi" kernel parameter.<br />
<br />
If ''/sys/firmware/efi/vars/'' directory is empty or does not exist, then {{ic|efibootmgr}} command will not work. If you are unable to make the ISO/CD/DVD/USB boot in UEFI mode try [[#Create_UEFI_bootable_USB_from_ISO]].<br />
<br />
{{Note| The below commands use {{Pkg|gummiboot}} boot-loader as example.}}<br />
{{out of date|[[Gummiboot]] has its own installer now, therefore the following instructions should not be used to install [[gummiboot]]. This example should be changed to use something else.}}<br />
<br />
Assume the boot-loader file to be launched is {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}}. {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} can be split up as {{ic|/boot/efi}} and {{ic|/EFI/gummiboot/gummibootx64.efi}}, wherein {{ic|/boot/efi}} is the mountpoint of the UEFI System Partition, which is assumed to be {{ic|/dev/sdXY}} (here X and Y are just placeholders for the actual values - eg:- in {{ic|/dev/sda1}} , X=a Y=1).<br />
<br />
To determine the actual device path for the UEFI System Partition (should be in the form {{ic|/dev/sdXY}}), try :<br />
<br />
# findmnt /boot/efi<br />
TARGET SOURCE FSTYPE OPTIONS<br />
/boot/efi /dev/sdXY vfat rw,flush,tz=UTC<br />
<br />
Then create the boot entry using efibootmgr as follows :<br />
<br />
# efibootmgr -c -g -d /dev/sdX -p Y -w -L "Gummiboot" -l '\EFI\gummiboot\gummibootx64.efi'<br />
<br />
In the above command {{ic|/boot/efi/EFI/gummiboot/gummibootx64.efi}} translates to {{ic|/boot/efi}} and {{ic|/EFI/gummiboot/gummibootx64.efi}} which in turn translate to drive {{ic|/dev/sdX}} -> partition {{ic|Y}} -> file {{ic|/EFI/gummiboot/gummibootx64.efi}}.<br />
<br />
UEFI uses backward slash as path separator (similar to Windows paths).<br />
<br />
The 'label' is the name of the menu entry shown in the UEFI boot menu. This name is user's choice and does not affect the booting of the system. More info can be obtained from [http://linux.dell.com/cgi-bin/gitweb/gitweb.cgi?p=efibootmgr.git;a=blob_plain;f=README;hb=HEAD efibootmgr GIT README] .<br />
<br />
FAT32 filesystem is case-insensitive since it does not use UTF-8 encoding by default. In that case the firmware uses capital 'EFI' instead of small 'efi', therefore using {{ic|\EFI\gummiboot\gummibootx64.efi}} or {{ic|\efi\gummiboot\gummibootx64.efi}} does not matter (this will change if the filesystem encoding is UTF-8).<br />
<br />
== Linux Bootloaders for UEFI ==<br />
<br />
See [[UEFI Bootloaders]].<br />
<br />
== EFI System Partition ==<br />
<br />
{{Note|UEFI System Partition and EFI System Partition (ESP) are same, the terminologies are used interchangeably in some places.}}<br />
<br />
{{Note|1=The EFI System Partition can be of any size supported by FAT32 filesystem. According to Microsoft Documentation, the minimum partition/volume size for FAT32 is 512 MiB. However ESP with size >=100 MiB but formatted as FAT32 are also allowed by many Linux distros and by Microsoft Windows, hence smaller partitions are fine. However >=512 MiB size for ESP is recommended for most compatibility. Non-FAT filesystems like ext2/3/4, reiserfs, NTFS, UDF etc. are not supported for ESP.}}<br />
<br />
{{Note|The ESP should be accessible by the UEFI firmware, which cannot read LVM and software RAID systems.}}<br />
<br />
{{Note|If you are using Linux EFISTUB booting, then you need to make sure there is adequate space available for keeping the Kernel and Initramfs files in the ESP.}}<br />
<br />
{{Note|Setting "boot" flag in parted in a MBR partition marks that partition as active, while the same "boot" flag in a GPT partition marks that partition as "UEFI System Partition".}}<br />
<br />
=== For GPT partitioned disks ===<br />
Two choices:<br />
* Using GNU Parted/GParted: Create a FAT32 partition. Set "boot" flag on for that partition.<br />
* Using GPT fdisk (aka gdisk): Create a partition with partition type {{ic|EF00}}. Then format that partition as FAT32 using {{ic|mkfs.vfat -F32 /dev/<THAT_PARTITION>}}<br />
<br />
=== For MBR partitioned disks ===<br />
{{Note|It is recommended to use always GPT for UEFI boot as some UEFI firmwares do not allow UEFI-MBR boot.}}<br />
Two choices:<br />
* Using GNU Parted/GParted: Create FAT32 partition. Change the type code of that partition to {{ic|0xEF}} using fdisk, cfdisk or sfdisk.<br />
* Using fdisk: Create a partition with partition type {{ic|0xEF}}. Then format that partition as FAT32 using {{ic|mkfs.vfat -F32 /dev/<THAT_PARTITION>}}<br />
<br />
== UEFI Shell ==<br />
<br />
The UEFI Shell is a shell/terminal for the firmware which allows launching uefi applications which include uefi bootloaders. Apart from that, the shell can also be used to obtain various other information about the system or the firmware like memory map (memmap), modifying boot manager variables (bcfg), running partitioning programs (diskpart), loading uefi drivers, editing text files (edit), hexedit etc. <br />
<br />
=== UEFI Shell download links === <br />
<br />
You can download a BSD licensed UEFI Shell from Intel's Tianocore UDK/EDK2 Sourceforge.net project.<br />
<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/X64/Shell.efi x86_64 UEFI Shell 2.0 (Beta)] - [http://dl.dropbox.com/u/9710721/UEFI_Shell/shellx64_v2.efi Alternate download link] (compiled from SVN repo, try this link if the file downloaded from previous link does not work in your system)<br />
<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/X64/Shell_Full.efi x86_64 UEFI Shell 1.0 (Old)]<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/ShellBinPkg/UefiShell/Ia32/Shell.efi i386 UEFI Shell 2.0 (Beta)]<br />
* [https://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2/EdkShellBinPkg/FullShell/Ia32/Shell_Full.efi i386 UEFI Shell 1.0 (Old)]<br />
<br />
Shell 2.0 works only in UEFI 2.3+ systems and is recommended over Shell 1.0 in those systems. Shell 1.0 should work in all UEFI systems irrespective of the spec. version the firmware follows. More info at [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=ShellPkg ShellPkg] and [http://sourceforge.net/mailarchive/message.php?msg_id=28690732 this mail]<br />
<br />
=== Launching UEFI Shell ===<br />
<br />
Few Asus and other AMI Aptio x86_64 UEFI firmware based motherboards (from Sandy Bridge onwards) provide an option called {{ic|"Launch EFI Shell from filesystem device"}} . For those motherboards, download the x86_64 UEFI Shell and copy it to your UEFI SYSTEM PARTITION as {{ic|<UEFI_SYSTEM_PARTITION>/shellx64.efi}} (mostly {{ic|/boot/efi/shellx64.efi}}) .<br />
<br />
Systems with Phoenix SecureCore Tiano UEFI firmware are known to have embedded UEFI Shell which can be launched using either F6, F11 or F12 key.<br />
<br />
{{Note|If you are unable to launch UEFI Shell from the firmware directly using any of the above mentioned methods, create a FAT32 USB pen drive with Shell.efi copied as (USB)/efi/boot/bootx64.efi . This USB should come up in the firmware boot menu. Launching this option will launch the UEFI Shell for you.}}<br />
<br />
=== Important UEFI Shell Commands === <br />
<br />
UEFI Shell commands usually support {{ic|-b}} option which makes output pause after each page. {{ic|map}} lists recognized filesystems ({{ic|fs0}}, ...) and data storage devices ({{ic|blk0}}, ...). Run {{ic|help -b}} to list available commands.<br />
<br />
More info at http://software.intel.com/en-us/articles/efi-shells-and-scripting/<br />
<br />
==== bcfg ====<br />
<br />
BCFG command is used to modify the UEFI NVRAM entries, which allow the user to change the boot entries or driver options. This command is described in detail in page 83 (Section 5.3) of "UEFI Shell Specification 2.0" pdf document.<br />
<br />
{{Note| Users are recommended to try {{ic|bcfg}} only if {{ic|efibootmgr}} fails to create working boot entries in their system.}}<br />
<br />
{{Note| UEFI Shell 1.0 does not support {{ic|bcfg}} command.}}<br />
<br />
To dump a list of current boot entries -<br />
<br />
Shell> bcfg boot dump -v<br />
<br />
To add a boot menu entry for rEFInd (for example) as 4th (numbering starts from zero) option in the boot menu<br />
<br />
Shell> bcfg boot add 3 fs0:\EFI\refind\refind_x64.efi "rEFInd"<br />
<br />
where fs0: is the mapping corresponding to the UEFI System Partition and fs0:\EFI\refind\refind_x64.efi is the file to be launched.<br />
<br />
To remove the 4th boot option<br />
<br />
Shell> bcfg boot rm 3<br />
<br />
To move the boot option #3 to #0 (i.e. 1st or the default entry in the UEFI Boot menu)<br />
<br />
Shell> bcfg boot mv 3 0<br />
<br />
For bcfg help text<br />
<br />
Shell> help bcfg -v -b<br />
<br />
or<br />
<br />
Shell> bcfg -? -v -b<br />
<br />
==== edit ====<br />
<br />
EDIT command provides a basic text editor with an interface similar to nano text editor, but slightly less functional. It handles UTF-8 encoding and takes care or LF vs CRLF line endings.<br />
<br />
To edit, for example rEFInd's refind.conf in the UEFI System Partition (fs0: in the firmware)<br />
<br />
Shell> fs0:<br />
FS0:\> cd \EFI\arch\refind<br />
FS0:\EFI\arch\refind\> edit refind.conf<br />
<br />
Type {{ic|Ctrl-E}} for help.<br />
<br />
== Hardware Compatibility ==<br />
<br />
Main page [[HCL/Firmwares/UEFI]]<br />
<br />
== Create UEFI bootable USB from ISO ==<br />
<br />
{{Note|1=The instructions below are specifically for [[Archiso]]/official media; [[Archboot]] preparation is identical, with this [https://bbs.archlinux.org/viewtopic.php?pid=1190788#p1190788 refind.conf] instead of the one mentioned below (which is for Archiso) and without the filesystem label requirement.}}<br />
<br />
{{Note|The USB can use either MBR or GPT partition table (so it is fine to use an already partitioned USB). The filesystem should be either FAT32 (recommended) or FAT16. FAT12 is designed for floppy drives and therefore not recommended for USB drives.}}<br />
<br />
First create a partition table and at most one partition in the USB. Mount the ISO image from the [https://www.archlinux.org/download/ Arch Linux download page].<br />
<br />
{{bc|1=<nowiki><br />
# mkdir -p /mnt/{usb,iso}<br />
# mount -o loop archlinux-2012.12.01-dual.iso /mnt/iso<br />
</nowiki>}}<br />
<br />
Then create a FAT32 filesystem in the partition on the USB (unmount before if necessary) with LABEL as used in the Archiso configuration. Obtain the label from {{ic|/mnt/iso/loader/entries/archiso-x86_64.conf}}; this is used by the {{ic|archiso}} hook in initramfs to identify the udev path to the installation media. {{ic|mkfs.vfat}} is part of package {{Pkg|dosfstools}}.<br />
<br />
{{bc|1=<nowiki><br />
# awk 'BEGIN {FS="="} /archisolabel/ {print $3}' /mnt/iso/loader/entries/archiso-x86_64.conf | xargs mkfs.vfat -F32 /dev/sdXY -n<br />
</nowiki>}}<br />
<br />
Mount the newly created FAT32 USB partition, and copy the contents of the installation media to the USB media.<br />
<br />
{{bc|1=<nowiki><br />
# mount /dev/sdXY /mnt/usb<br />
# cp -a /mnt/iso/* /mnt/usb<br />
# sync<br />
# umount /mnt/{usb,iso}</nowiki>}}<br />
<br />
<br />
=== Fixing errors ===<br />
<br />
If you find the error: ''"No loader found. Configuration files in /loader/entries/*.conf are needed."'' A possible fix is to use a different uefi bootloader to the included one, gummiboot.<br />
<br />
Download [https://www.archlinux.org/packages/extra/any/refind-efi/download/ refind-efi pkg] and extract the file {{ic|/usr/lib/refind/refind_x64.efi}} from within the package to {{ic|(USB)/EFI/boot/bootx64.efi}} (overwrite or rename any existing {{ic|(USB)/EFI/boot/bootx64.efi}} file).<br />
<br />
Then copy this text to {{ic|EFI/boot/refind.conf}}. Take care that the label in the Arch menu section ({{ic|ARCH_201302}} here) matches that of your usb's.<br />
<br />
{{hc|refind.conf|<nowiki><br />
timeout 5<br />
textonly<br />
<br />
showtools about,reboot,shutdown,exit<br />
# scan_driver_dirs EFI/tools/drivers_x64<br />
scanfor manual,internal,external,optical<br />
<br />
scan_delay 1<br />
dont_scan_dirs EFI/boot<br />
<br />
max_tags 0<br />
default_selection "Arch Linux Archiso x86_64 UEFI USB"<br />
<br />
menuentry "Arch Linux Archiso x86_64 UEFI USB" {<br />
loader /arch/boot/x86_64/vmlinuz<br />
initrd /arch/boot/x86_64/archiso.img<br />
ostype Linux<br />
graphics off<br />
options "archisobasedir=arch archisolabel=ARCH_201302 add_efi_memmap"<br />
}<br />
<br />
menuentry "UEFI x86_64 Shell v2" {<br />
loader /EFI/shellx64_v2.efi<br />
graphics off<br />
}<br />
<br />
menuentry "UEFI x86_64 Shell v1" {<br />
loader /EFI/shellx64_v1.efi<br />
graphics off<br />
}<br />
</nowiki>}}<br />
<br />
You should now be able to successfully boot, and you can choose which EFI you'd like to load.<br />
<br />
== Remove UEFI boot support from ISO ==<br />
<br />
{{Warning|In the event that UEFI+isohybrid El Torito/MBR really causes problems, it would be better to just UEFI boot using the USB stick instructions in the previous section}}<br />
<br />
Most of the 32-bit EFI Macs and some 64-bit EFI Macs refuse to boot from a UEFI(X64)+BIOS bootable CD/DVD. If one wishes to proceed with the installation using optical media, it might be necessary to remove UEFI support first.<br />
<br />
Mount the official installation media and obtain the {{ic|archisolabel}} as shown in the previous section.<br />
<br />
Rebuild the ISO using {{ic|xorriso}} from {{pkg|libisoburn}}:<br />
<br />
{{bc|1=<nowiki><br />
$ xorriso -as mkisofs -iso-level 3 \<br />
-full-iso9660-filenames\<br />
-volid "ARCH_201212" \<br />
-appid "Arch Linux CD" \<br />
-publisher "Arch Linux <https://www.archlinux.org>" \<br />
-preparer "prepared like a BAWSE" \<br />
-eltorito-boot isolinux/isolinux.bin \<br />
-eltorito-catalog isolinux/boot.cat \<br />
-no-emul-boot -boot-load-size 4 -boot-info-table \<br />
-isohybrid-mbr "/mnt/iso/isolinux/isohdpfx.bin" \<br />
-output "~/archiso.iso" "/mnt/iso/"</nowiki>}}<br />
<br />
Burn {{ic|~/archiso.iso}} to optical media and proceed with installation normally.<br />
<br />
== QEMU with OVMF ==<br />
<br />
OVMF [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF] is a project to enable UEFI support for Virtual Machines. OVMF contains a sample UEFI firmware for QEMU and KVM.<br />
<br />
You can build OVMF from AUR [https://aur.archlinux.org/packages/ovmf-svn/] and use it like this:<br />
<br />
qemu-system-x86_64 -bios /usr/share/ovmf/bios.bin ...<br />
<br />
== See also ==<br />
<br />
* Wikipedia's page on [http://en.wikipedia.org/wiki/UEFI UEFI]<br />
* Wikipedia's page on [http://en.wikipedia.org/wiki/EFI_System_partition UEFI SYSTEM Partition]<br />
* [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob_plain;f=Documentation/x86/x86_64/uefi.txt;hb=HEAD Linux Kernel UEFI Documentation]<br />
* [http://www.uefi.org/home/ UEFI Forum] - contains the official [http://www.uefi.org/specs/ UEFI Specifications] - GUID Partition Table is part of UEFI Specification<br />
* [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Welcome_to_TianoCore Intel's Tianocore Project] for Open-Source UEFI firmware which includes DuetPkg for direct BIOS based booting and OvmfPkg used in QEMU and Oracle VirtualBox<br />
* [http://www.intel.com/technology/efi/ Intel's page on EFI]<br />
* [http://homepage.ntlworld.com/jonathan.deboynepollard/FGA/efi-boot-process.html FGA: The EFI boot process]<br />
* [http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx Microsoft's Windows and GPT FAQ] - Contains info on Windows UEFI booting also<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Windows_x64_BIOS_to_UEFI Convert Windows Vista SP1+ or 7 x86_64 boot from BIOS-MBR mode to UEFI-GPT mode without Reinstall]<br />
* [https://gitorious.org/tianocore_uefi_duet_builds/pages/Linux_Windows_BIOS_UEFI_boot_USB Create a Linux BIOS+UEFI and Windows x64 BIOS+UEFI bootable USB drive]<br />
* [http://rodsbooks.com/bios2uefi/ Rod Smith - A BIOS to UEFI Transformation]<br />
* [https://lkml.org/lkml/2011/6/8/322 UEFI Boot problems on some newer machines (LKML)]<br />
* [http://software.intel.com/en-us/articles/efi-shells-and-scripting/ EFI Shells and Scripting - Intel Documentation]<br />
* [http://software.intel.com/en-us/articles/uefi-shell/ UEFI Shell - Intel Documentation]<br />
* [http://www.hpuxtips.es/?q=node/293 UEFI Shell - bcfg command info]<br />
* [http://hackthejoggler.freeforums.org/download/file.php?id=28 Some useful 32-bit UEFI Shell utilities]<br />
* [http://linuxplumbers.ubicast.tv/videos/plumbing-uefi-into-linux/ LPC 2012 Plumbing UEFI into Linux]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-1/ LPC 2012 UEFI Tutorial : part 1]<br />
* [http://linuxplumbers.ubicast.tv/videos/uefi-tutorial-part-2/ LPC 2012 UEFI Tutorial : part 2]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Laptop&diff=252339Laptop2013-03-30T06:53:38Z<p>Eruditorum: /* Low charge action */</p>
<hr />
<div>[[Category:Laptops]]<br />
[[cs:Laptop]]<br />
[[es:Laptop]]<br />
[[it:Laptop]]<br />
[[ru:Laptop]]<br />
[[zh-CN:Laptop]]<br />
== Setting Up For Laptops ==<br />
This page should contain links to pages needed for configuring a laptop for the best experience. Setting up a laptop is in many ways the same as setting up a desktop. However, there are a few key differences. When setting up a laptop with Arch Linux, the following points should be taken into consideration:<br />
<br />
* [[#Power Management]] Power Management for laptops refers to optimizing the system to last as long as possible on a single battery charge. This can be accomplished by a variety of tweaks.<br />
** [[#Suspend and Hibernate]] : the operating system can be manually suspended either to memory or to disk, allowing for an (almost) complete shutdown of other hardware.<br />
** Hard drive spindown : the system can be configured to automatically turn off the hard disk after a specified interval of inactivity.<br />
** Screen shut off : the laptop screen can be configured to automatically turn off after a specified interval of inactivity (not just blanked with a screensaver but completely shut off).<br />
** CPU frequency scaling : the processor(s) can be configured to automatically step down to a lower frequency at lower loads.<br />
<br />
* [[#Screen brightness]]. How do I manage screen brightness?<br />
* Network and wireless setup is described in [[Wireless Setup]].<br />
* Media buttons can be configured as described in [[Extra Keyboard Keys]].<br />
* [[#Touchpad]] sensitivity, acceleration, button function and scroll borders can be configured for some (Synaptics or Alps) touchpads.<br />
* [[#Hard disk shock protection]] <br />
<br />
All of these points are important to take into consideration when getting a laptop set up the way you like. Fortunately, Arch Linux provides all the tools and programs necessary to take complete control of your laptop. These programs and utilities are highlighted below, with appropriate tips tutorials.<br />
<br />
== Power Management ==<br />
Power management is very important for anyone who wishes to make good use of their battery capacity. The following tools and programs help to increase battery life and keep your laptop cool and quiet.<br />
<br />
=== Battery State ===<br />
<br />
==== Udev events ====<br />
Upon change battery sends events which can be handled by udev. Example of how it could be used is presented below.<br />
<br />
==== Low charge action ====<br />
<br />
By default, system won't do anything if your laptop's battery is going to discharge. In order not to lose all unsaved work this example udev rule could be used (if your battery sends uevent when it charges/discharges by 1%):<br />
{{hc|/etc/udev/rules.d/lowbat.rules|<nowiki><br />
## SLEEP IF BATTERY IS LOW<br />
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend"<br />
</nowiki>}}<br />
Likewise, the rule can be customized to perform other action on different status.<br />
<br />
==== Utilities ====<br />
<br />
Battery state can be read using ACPI utilities from the terminal. ACPI command line utilities are provided via the {{Pkg|acpi}} package. A simple battery monitor that sits in the system tray is {{AUR|batterymon-clone}} which can be found in the [[Arch User Repository|AUR]].<br />
<br />
{{Tip|More information can be found in the [[ACPI modules]] article.}}<br />
<br />
* {{pkg|batti}} is a simple battery monitor for the system tray, similar to batterymon-clone. Unlike the latter {{ic|batti}} uses UPower, and if that is missing DeviceKit.Power, for it's power information.<br />
<br />
=== Suspend and Hibernate ===<br />
<br />
Manually suspending the operating system, either to memory (standby) or to disk (hibernate) sometimes provides the most efficient way to optimize battery life, depending on the usage pattern of the laptop. While there is relatively straightforward support in the linux kernel to support these operations, typically some adjustments have to be made before initiating these operations (typically due to problematic drivers, modules or hardware). The following tools provide wrappers around the kernel interfaces to suspend/resume :<br />
<br />
* [[Acpid]]<br />
* [[Pm-utils]]<br />
* [[Uswsusp]]<br />
<br />
which are described in more detail in [[Suspend]].<br />
<br />
===Power saving===<br />
<br />
See the main article, [[power saving]].<br />
<br />
==== Automatic tweaks for battery life ====<br />
<br />
As opposed to manually initiated actions like suspend/hibernate, a number of tweaks can be made to prolong the battery life of the laptop under low/idle usage.<br />
<br />
* [[CPU Frequency Scaling]] is a technology used primarily by notebooks which enables the OS to scale the CPU frequency up or down, depending on the current system load and/or power scheme.<br />
* [[Laptop Mode Tools]] provides a comprehensive suite of tools to tweak a large number of power saving settings through well documented configuration files.<br />
* [[Powertop]] is a handy utility from Intel that displays which hardware/processes are using the most power on your system, and provides instructions on how to stop or remove power-wasting services. Works great for mobile Intel CPUs; provides the current CPU state and suggestions for power saving. Also works on AMD systems, but does not provide as much information about the CPU state.<br />
<br />
The following options are specific to certain laptop types:<br />
<br />
* [[Asus_G1#The_Lapsus_daemon_.26_KDE_applet|Lapsus]] is a set of programs providing easy access to many features of various laptops. It currently supports most features provided by asus-laptop kernel module from ACPI4Asus project, such as additional LEDs, hotkeys, backlight control etc. It also has support for some IBM laptops features provided by IBM ThinkPad ACPI Extras Driver and NVRAM device.<br />
* Battery tweaks for Thinkpads can be found in the [[tp_smapi]] article.<br />
* [[TLP]] for Thinkpads is a set of scripts, which set many powersaving options according to the current Powersource. [[TLP]] is intended to be used on Thinkpads, but most settings should work on other laptops too.<br />
<br />
====PCI-e ASPM====<br />
On some laptops, powertop suggests enabling the {{ic|CONFIG_PCIEASPM}} kernel option. It can be found under "Bus options (PCI etc.)"->"PCI Express ASPM support". This option is marked as experimental in the current kernel (2.6.35) and allows the PCI-e links to enter a power saving state. <br />
<br />
According to [http://www.lesswatts.org/projects/devices-power-management/pcie.php], this option might degrade performance a bit, but on an Acer 3820TG laptop, it can reduce power consumption by about one third or even more.<br />
<br />
More experience with this setting would be appreciated, so please share them [https://bbs.archlinux.org/viewtopic.php?id=107173 here]!<br />
<br />
It seems like the option is going to be enabled by default in kernel 2.6.36; if so, the information here will be obsolete soon. However, if your system should be able to make use of this power management feature but you are receiving messages like like the following (check {{ic|/var/log/everything.log*}}):<br />
<br />
disabling ASPM on pre-1.1 PCI-e device. You can enable it with 'pcie_aspm=force'<br />
<br />
then add {{ic|pcie_aspm<nowiki>=</nowiki>force}} to your kernel command line.<br />
<br />
==== Granola ====<br />
<br />
{{Out of date|Arch Linux has moved to systemd, so rc.conf is no longer used.}}<br />
<br />
[https://aur.archlinux.org/packages.php?ID=36841 Granola] is a daemon that monitors the cpu usage and uses the cpufreq-userspace module to lessen power usage without any noticeable difference in performance.<br />
To use it, first install from the AUR:[https://aur.archlinux.org/packages.php?ID=36841], the default settings will work for most setups.<br />
You will need to load the cpufreq_userspace module, as well as the cpufreq scaling governor for your CPU at startup.<br />
Edit {{ic|/etc/rc.conf}}:<br />
For most generic cpus:<br />
<br />
MODULES=( ... cpufreq_userspace acpi-cpufreq ... )<br />
<br />
For Intel Atom or Pentium 4 cpus:<br />
<br />
MODULES=( ... cpufreq_userspace p4_clockmod ... )<br />
<br />
Then add Granola to the DAEMONS array:<br />
<br />
DAEMONS=( ... granola ... )<br />
<br />
and reboot. <br />
<br />
To test if it worked, run:<br />
<br />
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq<br />
#OR<br />
cpufreq-info #if you have cpufreq-utils installed<br />
<br />
and check that the cpu frequency is below maximum.<br />
<br />
====Wireless====<br />
When working on your notebook/laptop without wireless access, here is a little script for your system startup that turns off your WLAN-Hardware to keep it from wasting power searching for an Access Point:<br />
{{Note| Edit if <code>wlan0</code> is not your WLAN-device}}<br />
<br />
{{bc|<nowiki>#!/bin/bash<br />
<br />
essid="`iwconfig wlan0 | grep ESSID | awk {'print $4'}`"<br />
if [ "$essid" == "ESSID:off/any" ] ; then<br />
sudo iwconfig wlan0 txpower off<br />
fi</nowiki><br />
}}<br />
Start the script according to your DE/WM options by {{ic|sleep xx && /path/to/script}} depending on how long it usually takes to connect to your Access Point, 60 seconds are a good default value. It checks if you're connected, turning off the device if not. {{ic|# iwconfig wlan0 txpower on}} brings it back up, as well as a reboot.<br />
<br />
{{Tip|It may also be prudent to prevent your wireless interface from starting at boot if it is not used often (e.g. netcfg-menu as needed).}}<br />
<br />
==== Disk-related tweaks ====<br />
Disable file access time: every time you access (read) a file the filesystem writes an access time to the file metadata. You can disable this on individual files by using the chattr command, or you can enable it on an entire disk by setting the ''noatime'' option in your fstab, as follows:<br />
<br />
/dev/sda1 / ext3 defaults,noatime 1 2<br />
<br />
[http://www.faqs.org/docs/securing/chap6sec73.html Source]<br />
<br />
{{Note|<br />
* Disabling {{ic|atime}} causes troubles with [[Mutt|mutt]] and other applications that make use of file timestamps. Consider compromising between performance and compatibility by using mount option {{ic|relatime}} instead, or look into [http://wiki.mutt.org/?MaildirFormat mutt work-around for noatime].<br />
* {{ic|relatime}} is used by default as of kernel 2.6.30, so unless you're using an older kernel, there should be no need to edit fstab.<br />
}}<br />
<br />
To allow the CD/DVD rom to spin down after a while using [[udisks]]:<br />
<br />
# udisks --inhibit-polling /dev/sr0<br />
<br />
==== More tweaks ====<br />
These are some generic suggestions that will work with most laptops.<br />
<br />
Add the following to {{ic|/etc/modprobe.d/modprobe.conf}}:<br />
<br />
options usbcore autosuspend=1<br />
<br />
Add the following to {{ic|/etc/sysctl.conf}}<br />
<br />
vm.dirty_writeback_centisecs=1500<br />
vm.laptop_mode=5<br />
<br />
{{Note|''laptop-mode-tools'' automatically rewrites these values based on the values {{Ic|LM_BATT_MAX_LOST_WORK_SECONDS}}, {{Ic|LM_AC_MAX_LOST_WORK_SECONDS}} (both multiplied by 100) resp. {{Ic|LM_SECONDS_BEFORE_SYNC}}, which are set in {{ic|/etc/laptop-mode/laptop-mode.conf}}. However, that only happens if the three "Enable laptop mode" variables in the same file are set accordingly — left to 0, it resets the values to kernel defaults (500 / 0) for the corresponding scenario regardless of {{ic|/etc/sysctl.conf}}.}}<br />
<br />
{{accuracy|reason=This belongs in a udev rule, not rc.local.}}<br />
<br />
Add the following to {{ic|/etc/rc.local}} (and make sure it gets executed at boot time)<br />
<br />
/usr/sbin/iwpriv your_wireless_interface set_power 5<br />
<br />
Source: [http://www.nervous.it/2007/11/linux-dell-xps-m1330/ here]<br />
<br />
==== Hard drive spin down problem ====<br />
Documented [https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 here]<br />
<br />
To prevent your laptop hard drive from spinning down too often (result of too aggressive APM defaults) do the following:<br />
<br />
Add the following to {{ic|/etc/rc.local}}<br />
<br />
hdparm -B 254 /dev/sdX ''where X is your hard drive device''<br />
<br />
If you are using [https://wiki.archlinux.org/index.php/Systemd Systemd]:<br />
<br />
Add the following to {{ic|/etc/udev/rules.d/75-hdparm.rules}}<br />
ACTION=="add", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/$kernel"<br />
<br />
You can also set it to 255 to completely disable spinning down. You may wish to set a lower value if you move your laptop around as lower values park the heads more often and reduce the chance of damage to your hard disk while it is being moved. If you do not move your laptop at all when you are using it, then 255 or 254 is probably best. If you do, then you might want to try a lower value. A value like 128 might be a good middle-ground.<br />
<br />
Add the following to {{ic|/etc/pm/sleep.d/50-hdparm_pm}}<br />
<br />
#!/bin/sh<br />
<br />
if [ -n "$1" ] && ([ "$1" = "resume" ] || [ "$1" = "thaw" ]); then<br />
hdparm -B 254 /dev/your-hard-drive > /dev/null<br />
fi<br />
<br />
and run ''chmod +x /etc/pm/sleep.d/50-hdparm_pm'' to make sure it resets after suspend. Again, you can change the value 254 as you see fit.<br />
<br />
Now the APM level should be set for your hard drive.<br />
<br />
For some laptops, the option -S to hdparm can also be relevant (sets the spindown time for the drive). Note that all these options can also be configured using the [[Laptop_Mode_Tools | laptop-mode tools]]. This will allow you to set a high value when on AC and a lower value when you are running on battery power.<br />
<br />
=== Using a script and an udev rule ===<br />
Since systemd users can suspend and hibernate through {{ic|systemctl suspend}} or {{ic|systemctl hibernate}} and handle acpi events with {{ic|/etc/systemd/logind.conf}}, it might be interesting to remove pm-utils and acpid. Now, there's just one thing systemd can't do (at this time of writing): powermanagement, depending on whether the system is running on AC or battery. To fill this gap, one can create a single udev rule that launches a script when the laptop is unplugged and plugged:<br />
{{hc|/etc/udev/rules.d/powersave|2=<nowiki><br />
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"<br />
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"<br />
</nowiki>}}<br />
{{Note|One can use the same script that pm-powersave uses. You just have to make it executable and place it somewhere else (for example, /usr/bin).}}<br />
Examples of powersave scripts can be found here: [https://bbs.archlinux.org/viewtopic.php?pid=1046075#p1046075] (or in aur: {{AUR|powerdown}}), here: [https://github.com/Unia/powersave] and there: [https://aur.archlinux.org/packages/powerconf].<br />
<br />
The above udev rule should work as expected, but if your power settings aren't updated after a suspend or hibernate cycle, you should add a script in {{ic|/usr/lib/systemd/system-sleep/}} with the following contents:<br />
{{hc|/usr/lib/systemd/system-sleep/00powersave|<nowiki><br />
#!/bin/sh<br />
<br />
case $1 in<br />
pre) /path/to/your/script false ;;<br />
post) <br />
if cat /sys/class/power_supply/AC0/online | grep 0 > /dev/null 2>&1<br />
then<br />
/path/to/your/script true <br />
else<br />
/path/to/your/script false<br />
fi<br />
;;<br />
esac'<br />
exit 0<br />
</nowiki>}}<br />
<br />
Don't forget to make it executable!<br />
{{Note|Be aware that AC0 may be different for your laptop, change it if that is the case.}}<br />
<br />
Now you don't need pm-utils anymore. Depending on your configuration, it may be a dependency of some other package. If you wish to remove it anyway, run {{ic|pacman -Rdd pm-utils}}.<br />
<br />
== Screen brightness ==<br />
See [[Backlight]].<br />
<br />
== Touchpad ==<br />
To get your touchpad working properly, see the [[Touchpad Synaptics]] page. Note that your laptop may have an ALPS touchpad (such as the DELL Inspiron 6000), and not a Synaptics touchpad. In either case, see the link above.<br />
<br />
== Hard disk shock protection ==<br />
There are several laptops from different vendors featuring shock protection capabilities. As manufacturers have refused to support open source development of the required software components so far, Linux support for shock protection varies considerably between different hardware implementations.<br />
<br />
Currently, two projects, named HDAPS and hpfall, support this kind of protection.<br />
HDAPS is for IBM/Lenovo Thinkpads and hpfall for HP/Compaq laptops<br />
<br />
Just Check [[HDAPS|Hard Disk Active Protection System]].<br />
{{AUR|hpfall}} can be installed from the [[AUR]].<br />
<br />
== Network Time Syncing ==<br />
For a laptop, it may be a good idea to use [[Chrony]] as an alternative to [[NTPd]] to sync your clock over the network. Chrony is designed to work well even on systems with no permanent network connection (such as laptops), and is capable of much faster time synchronisation than standard ntp. Chrony has several advantages when used in systems running on virtual machines, such as a larger range for frequency correction to help correct quickly drifting clocks, and better response to rapid changes in the clock frequency. It also has a smaller memory footprint and no unnecessary process wakeups, improving power efficiency.<br />
<br />
== See also ==<br />
* [http://www.linux-on-laptops.com/ http://www.linux-on-laptops.com/]<br />
* [http://www.linlap.com/ http://www.linlap.com/]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Laptop&diff=252338Laptop2013-03-30T06:52:28Z<p>Eruditorum: /* Udev events */</p>
<hr />
<div>[[Category:Laptops]]<br />
[[cs:Laptop]]<br />
[[es:Laptop]]<br />
[[it:Laptop]]<br />
[[ru:Laptop]]<br />
[[zh-CN:Laptop]]<br />
== Setting Up For Laptops ==<br />
This page should contain links to pages needed for configuring a laptop for the best experience. Setting up a laptop is in many ways the same as setting up a desktop. However, there are a few key differences. When setting up a laptop with Arch Linux, the following points should be taken into consideration:<br />
<br />
* [[#Power Management]] Power Management for laptops refers to optimizing the system to last as long as possible on a single battery charge. This can be accomplished by a variety of tweaks.<br />
** [[#Suspend and Hibernate]] : the operating system can be manually suspended either to memory or to disk, allowing for an (almost) complete shutdown of other hardware.<br />
** Hard drive spindown : the system can be configured to automatically turn off the hard disk after a specified interval of inactivity.<br />
** Screen shut off : the laptop screen can be configured to automatically turn off after a specified interval of inactivity (not just blanked with a screensaver but completely shut off).<br />
** CPU frequency scaling : the processor(s) can be configured to automatically step down to a lower frequency at lower loads.<br />
<br />
* [[#Screen brightness]]. How do I manage screen brightness?<br />
* Network and wireless setup is described in [[Wireless Setup]].<br />
* Media buttons can be configured as described in [[Extra Keyboard Keys]].<br />
* [[#Touchpad]] sensitivity, acceleration, button function and scroll borders can be configured for some (Synaptics or Alps) touchpads.<br />
* [[#Hard disk shock protection]] <br />
<br />
All of these points are important to take into consideration when getting a laptop set up the way you like. Fortunately, Arch Linux provides all the tools and programs necessary to take complete control of your laptop. These programs and utilities are highlighted below, with appropriate tips tutorials.<br />
<br />
== Power Management ==<br />
Power management is very important for anyone who wishes to make good use of their battery capacity. The following tools and programs help to increase battery life and keep your laptop cool and quiet.<br />
<br />
=== Battery State ===<br />
<br />
==== Udev events ====<br />
Upon change battery sends events which can be handled by udev. Example of how it could be used is presented below.<br />
<br />
==== Low charge action ====<br />
<br />
By default, system won't do anything if your laptop's battery is going to discharge. In order not to lose all unsaved work this example udev rule could be used:<br />
{{hc|/etc/udev/rules.d/lowbat.rules|<nowiki><br />
## SLEEP IF BATTERY IS LOW<br />
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend"<br />
</nowiki>}}<br />
Likewise, the rule can be customized to perform other action on different status.<br />
<br />
==== Utilities ====<br />
<br />
Battery state can be read using ACPI utilities from the terminal. ACPI command line utilities are provided via the {{Pkg|acpi}} package. A simple battery monitor that sits in the system tray is {{AUR|batterymon-clone}} which can be found in the [[Arch User Repository|AUR]].<br />
<br />
{{Tip|More information can be found in the [[ACPI modules]] article.}}<br />
<br />
* {{pkg|batti}} is a simple battery monitor for the system tray, similar to batterymon-clone. Unlike the latter {{ic|batti}} uses UPower, and if that is missing DeviceKit.Power, for it's power information.<br />
<br />
=== Suspend and Hibernate ===<br />
<br />
Manually suspending the operating system, either to memory (standby) or to disk (hibernate) sometimes provides the most efficient way to optimize battery life, depending on the usage pattern of the laptop. While there is relatively straightforward support in the linux kernel to support these operations, typically some adjustments have to be made before initiating these operations (typically due to problematic drivers, modules or hardware). The following tools provide wrappers around the kernel interfaces to suspend/resume :<br />
<br />
* [[Acpid]]<br />
* [[Pm-utils]]<br />
* [[Uswsusp]]<br />
<br />
which are described in more detail in [[Suspend]].<br />
<br />
===Power saving===<br />
<br />
See the main article, [[power saving]].<br />
<br />
==== Automatic tweaks for battery life ====<br />
<br />
As opposed to manually initiated actions like suspend/hibernate, a number of tweaks can be made to prolong the battery life of the laptop under low/idle usage.<br />
<br />
* [[CPU Frequency Scaling]] is a technology used primarily by notebooks which enables the OS to scale the CPU frequency up or down, depending on the current system load and/or power scheme.<br />
* [[Laptop Mode Tools]] provides a comprehensive suite of tools to tweak a large number of power saving settings through well documented configuration files.<br />
* [[Powertop]] is a handy utility from Intel that displays which hardware/processes are using the most power on your system, and provides instructions on how to stop or remove power-wasting services. Works great for mobile Intel CPUs; provides the current CPU state and suggestions for power saving. Also works on AMD systems, but does not provide as much information about the CPU state.<br />
<br />
The following options are specific to certain laptop types:<br />
<br />
* [[Asus_G1#The_Lapsus_daemon_.26_KDE_applet|Lapsus]] is a set of programs providing easy access to many features of various laptops. It currently supports most features provided by asus-laptop kernel module from ACPI4Asus project, such as additional LEDs, hotkeys, backlight control etc. It also has support for some IBM laptops features provided by IBM ThinkPad ACPI Extras Driver and NVRAM device.<br />
* Battery tweaks for Thinkpads can be found in the [[tp_smapi]] article.<br />
* [[TLP]] for Thinkpads is a set of scripts, which set many powersaving options according to the current Powersource. [[TLP]] is intended to be used on Thinkpads, but most settings should work on other laptops too.<br />
<br />
====PCI-e ASPM====<br />
On some laptops, powertop suggests enabling the {{ic|CONFIG_PCIEASPM}} kernel option. It can be found under "Bus options (PCI etc.)"->"PCI Express ASPM support". This option is marked as experimental in the current kernel (2.6.35) and allows the PCI-e links to enter a power saving state. <br />
<br />
According to [http://www.lesswatts.org/projects/devices-power-management/pcie.php], this option might degrade performance a bit, but on an Acer 3820TG laptop, it can reduce power consumption by about one third or even more.<br />
<br />
More experience with this setting would be appreciated, so please share them [https://bbs.archlinux.org/viewtopic.php?id=107173 here]!<br />
<br />
It seems like the option is going to be enabled by default in kernel 2.6.36; if so, the information here will be obsolete soon. However, if your system should be able to make use of this power management feature but you are receiving messages like like the following (check {{ic|/var/log/everything.log*}}):<br />
<br />
disabling ASPM on pre-1.1 PCI-e device. You can enable it with 'pcie_aspm=force'<br />
<br />
then add {{ic|pcie_aspm<nowiki>=</nowiki>force}} to your kernel command line.<br />
<br />
==== Granola ====<br />
<br />
{{Out of date|Arch Linux has moved to systemd, so rc.conf is no longer used.}}<br />
<br />
[https://aur.archlinux.org/packages.php?ID=36841 Granola] is a daemon that monitors the cpu usage and uses the cpufreq-userspace module to lessen power usage without any noticeable difference in performance.<br />
To use it, first install from the AUR:[https://aur.archlinux.org/packages.php?ID=36841], the default settings will work for most setups.<br />
You will need to load the cpufreq_userspace module, as well as the cpufreq scaling governor for your CPU at startup.<br />
Edit {{ic|/etc/rc.conf}}:<br />
For most generic cpus:<br />
<br />
MODULES=( ... cpufreq_userspace acpi-cpufreq ... )<br />
<br />
For Intel Atom or Pentium 4 cpus:<br />
<br />
MODULES=( ... cpufreq_userspace p4_clockmod ... )<br />
<br />
Then add Granola to the DAEMONS array:<br />
<br />
DAEMONS=( ... granola ... )<br />
<br />
and reboot. <br />
<br />
To test if it worked, run:<br />
<br />
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq<br />
#OR<br />
cpufreq-info #if you have cpufreq-utils installed<br />
<br />
and check that the cpu frequency is below maximum.<br />
<br />
====Wireless====<br />
When working on your notebook/laptop without wireless access, here is a little script for your system startup that turns off your WLAN-Hardware to keep it from wasting power searching for an Access Point:<br />
{{Note| Edit if <code>wlan0</code> is not your WLAN-device}}<br />
<br />
{{bc|<nowiki>#!/bin/bash<br />
<br />
essid="`iwconfig wlan0 | grep ESSID | awk {'print $4'}`"<br />
if [ "$essid" == "ESSID:off/any" ] ; then<br />
sudo iwconfig wlan0 txpower off<br />
fi</nowiki><br />
}}<br />
Start the script according to your DE/WM options by {{ic|sleep xx && /path/to/script}} depending on how long it usually takes to connect to your Access Point, 60 seconds are a good default value. It checks if you're connected, turning off the device if not. {{ic|# iwconfig wlan0 txpower on}} brings it back up, as well as a reboot.<br />
<br />
{{Tip|It may also be prudent to prevent your wireless interface from starting at boot if it is not used often (e.g. netcfg-menu as needed).}}<br />
<br />
==== Disk-related tweaks ====<br />
Disable file access time: every time you access (read) a file the filesystem writes an access time to the file metadata. You can disable this on individual files by using the chattr command, or you can enable it on an entire disk by setting the ''noatime'' option in your fstab, as follows:<br />
<br />
/dev/sda1 / ext3 defaults,noatime 1 2<br />
<br />
[http://www.faqs.org/docs/securing/chap6sec73.html Source]<br />
<br />
{{Note|<br />
* Disabling {{ic|atime}} causes troubles with [[Mutt|mutt]] and other applications that make use of file timestamps. Consider compromising between performance and compatibility by using mount option {{ic|relatime}} instead, or look into [http://wiki.mutt.org/?MaildirFormat mutt work-around for noatime].<br />
* {{ic|relatime}} is used by default as of kernel 2.6.30, so unless you're using an older kernel, there should be no need to edit fstab.<br />
}}<br />
<br />
To allow the CD/DVD rom to spin down after a while using [[udisks]]:<br />
<br />
# udisks --inhibit-polling /dev/sr0<br />
<br />
==== More tweaks ====<br />
These are some generic suggestions that will work with most laptops.<br />
<br />
Add the following to {{ic|/etc/modprobe.d/modprobe.conf}}:<br />
<br />
options usbcore autosuspend=1<br />
<br />
Add the following to {{ic|/etc/sysctl.conf}}<br />
<br />
vm.dirty_writeback_centisecs=1500<br />
vm.laptop_mode=5<br />
<br />
{{Note|''laptop-mode-tools'' automatically rewrites these values based on the values {{Ic|LM_BATT_MAX_LOST_WORK_SECONDS}}, {{Ic|LM_AC_MAX_LOST_WORK_SECONDS}} (both multiplied by 100) resp. {{Ic|LM_SECONDS_BEFORE_SYNC}}, which are set in {{ic|/etc/laptop-mode/laptop-mode.conf}}. However, that only happens if the three "Enable laptop mode" variables in the same file are set accordingly — left to 0, it resets the values to kernel defaults (500 / 0) for the corresponding scenario regardless of {{ic|/etc/sysctl.conf}}.}}<br />
<br />
{{accuracy|reason=This belongs in a udev rule, not rc.local.}}<br />
<br />
Add the following to {{ic|/etc/rc.local}} (and make sure it gets executed at boot time)<br />
<br />
/usr/sbin/iwpriv your_wireless_interface set_power 5<br />
<br />
Source: [http://www.nervous.it/2007/11/linux-dell-xps-m1330/ here]<br />
<br />
==== Hard drive spin down problem ====<br />
Documented [https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 here]<br />
<br />
To prevent your laptop hard drive from spinning down too often (result of too aggressive APM defaults) do the following:<br />
<br />
Add the following to {{ic|/etc/rc.local}}<br />
<br />
hdparm -B 254 /dev/sdX ''where X is your hard drive device''<br />
<br />
If you are using [https://wiki.archlinux.org/index.php/Systemd Systemd]:<br />
<br />
Add the following to {{ic|/etc/udev/rules.d/75-hdparm.rules}}<br />
ACTION=="add", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", RUN+="/sbin/hdparm -B 254 /dev/$kernel"<br />
<br />
You can also set it to 255 to completely disable spinning down. You may wish to set a lower value if you move your laptop around as lower values park the heads more often and reduce the chance of damage to your hard disk while it is being moved. If you do not move your laptop at all when you are using it, then 255 or 254 is probably best. If you do, then you might want to try a lower value. A value like 128 might be a good middle-ground.<br />
<br />
Add the following to {{ic|/etc/pm/sleep.d/50-hdparm_pm}}<br />
<br />
#!/bin/sh<br />
<br />
if [ -n "$1" ] && ([ "$1" = "resume" ] || [ "$1" = "thaw" ]); then<br />
hdparm -B 254 /dev/your-hard-drive > /dev/null<br />
fi<br />
<br />
and run ''chmod +x /etc/pm/sleep.d/50-hdparm_pm'' to make sure it resets after suspend. Again, you can change the value 254 as you see fit.<br />
<br />
Now the APM level should be set for your hard drive.<br />
<br />
For some laptops, the option -S to hdparm can also be relevant (sets the spindown time for the drive). Note that all these options can also be configured using the [[Laptop_Mode_Tools | laptop-mode tools]]. This will allow you to set a high value when on AC and a lower value when you are running on battery power.<br />
<br />
=== Using a script and an udev rule ===<br />
Since systemd users can suspend and hibernate through {{ic|systemctl suspend}} or {{ic|systemctl hibernate}} and handle acpi events with {{ic|/etc/systemd/logind.conf}}, it might be interesting to remove pm-utils and acpid. Now, there's just one thing systemd can't do (at this time of writing): powermanagement, depending on whether the system is running on AC or battery. To fill this gap, one can create a single udev rule that launches a script when the laptop is unplugged and plugged:<br />
{{hc|/etc/udev/rules.d/powersave|2=<nowiki><br />
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"<br />
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"<br />
</nowiki>}}<br />
{{Note|One can use the same script that pm-powersave uses. You just have to make it executable and place it somewhere else (for example, /usr/bin).}}<br />
Examples of powersave scripts can be found here: [https://bbs.archlinux.org/viewtopic.php?pid=1046075#p1046075] (or in aur: {{AUR|powerdown}}), here: [https://github.com/Unia/powersave] and there: [https://aur.archlinux.org/packages/powerconf].<br />
<br />
The above udev rule should work as expected, but if your power settings aren't updated after a suspend or hibernate cycle, you should add a script in {{ic|/usr/lib/systemd/system-sleep/}} with the following contents:<br />
{{hc|/usr/lib/systemd/system-sleep/00powersave|<nowiki><br />
#!/bin/sh<br />
<br />
case $1 in<br />
pre) /path/to/your/script false ;;<br />
post) <br />
if cat /sys/class/power_supply/AC0/online | grep 0 > /dev/null 2>&1<br />
then<br />
/path/to/your/script true <br />
else<br />
/path/to/your/script false<br />
fi<br />
;;<br />
esac'<br />
exit 0<br />
</nowiki>}}<br />
<br />
Don't forget to make it executable!<br />
{{Note|Be aware that AC0 may be different for your laptop, change it if that is the case.}}<br />
<br />
Now you don't need pm-utils anymore. Depending on your configuration, it may be a dependency of some other package. If you wish to remove it anyway, run {{ic|pacman -Rdd pm-utils}}.<br />
<br />
== Screen brightness ==<br />
See [[Backlight]].<br />
<br />
== Touchpad ==<br />
To get your touchpad working properly, see the [[Touchpad Synaptics]] page. Note that your laptop may have an ALPS touchpad (such as the DELL Inspiron 6000), and not a Synaptics touchpad. In either case, see the link above.<br />
<br />
== Hard disk shock protection ==<br />
There are several laptops from different vendors featuring shock protection capabilities. As manufacturers have refused to support open source development of the required software components so far, Linux support for shock protection varies considerably between different hardware implementations.<br />
<br />
Currently, two projects, named HDAPS and hpfall, support this kind of protection.<br />
HDAPS is for IBM/Lenovo Thinkpads and hpfall for HP/Compaq laptops<br />
<br />
Just Check [[HDAPS|Hard Disk Active Protection System]].<br />
{{AUR|hpfall}} can be installed from the [[AUR]].<br />
<br />
== Network Time Syncing ==<br />
For a laptop, it may be a good idea to use [[Chrony]] as an alternative to [[NTPd]] to sync your clock over the network. Chrony is designed to work well even on systems with no permanent network connection (such as laptops), and is capable of much faster time synchronisation than standard ntp. Chrony has several advantages when used in systems running on virtual machines, such as a larger range for frequency correction to help correct quickly drifting clocks, and better response to rapid changes in the clock frequency. It also has a smaller memory footprint and no unnecessary process wakeups, improving power efficiency.<br />
<br />
== See also ==<br />
* [http://www.linux-on-laptops.com/ http://www.linux-on-laptops.com/]<br />
* [http://www.linlap.com/ http://www.linlap.com/]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Talk:Laptop&diff=252337Talk:Laptop2013-03-30T06:49:00Z<p>Eruditorum: /* Udev Rule to Suspend System */</p>
<hr />
<div>==Other tweaks ==<br />
No explanations with these tweaks? What do these do? Is linking to the source enough or should we describe what we're doing in detail? I'm never too comfortable with "do this" type instructions without a "this is why" explanations.--[[User:Multiphrenic|Multiphrenic]] 09:05, 27 April 2011 (EDT)<br />
<br />
==Udev Rule to Suspend System==<br />
The udev rule could be edited to run a script that does polls the battery's capacity at regular interval when it's status changes to Discharging:<br />
## SLEEP IF BATTERY IS LOW<br />
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", <s>ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend</s> RUN+="/script/to/poll/battery/and/suspend/system.sh"<br />
There may also be a uevent that fires when the battery reaches an alarm state (when /sys/class/power_supply/BAT*/alarm is reached or changes). I have not tested this on my own system yet or figured out just how that file works yet. [[User:Ego.abyssi|Ego.abyssi]] ([[User talk:Ego.abyssi|talk]]) 23:32, 3 March 2013 (UTC)<br />
<br />
Strange, on my system battery sends "change" uevent each time battery is charged or discharged by 1%, so rule works perfectly and polling is an overcomplication.<br />
--[[User:Eruditorum|Eruditorum]] ([[User talk:Eruditorum|talk]]) 06:48, 30 March 2013 (UTC)</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Talk:Laptop&diff=252336Talk:Laptop2013-03-30T06:48:25Z<p>Eruditorum: /* Udev Rule to Suspend System */</p>
<hr />
<div>==Other tweaks ==<br />
No explanations with these tweaks? What do these do? Is linking to the source enough or should we describe what we're doing in detail? I'm never too comfortable with "do this" type instructions without a "this is why" explanations.--[[User:Multiphrenic|Multiphrenic]] 09:05, 27 April 2011 (EDT)<br />
<br />
==Udev Rule to Suspend System==<br />
The udev rule could be edited to run a script that does polls the battery's capacity at regular interval when it's status changes to Discharging:<br />
## SLEEP IF BATTERY IS LOW<br />
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", <s>ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend</s> RUN+="/script/to/poll/battery/and/suspend/system.sh"<br />
There may also be a uevent that fires when the battery reaches an alarm state (when /sys/class/power_supply/BAT*/alarm is reached or changes). I have not tested this on my own system yet or figured out just how that file works yet. [[User:Ego.abyssi|Ego.abyssi]] ([[User talk:Ego.abyssi|talk]]) 23:32, 3 March 2013 (UTC)<br />
Strange, on my system battery sends "change" uevent each time battery is charged or discharged by 1%, so rule works perfectly and polling is an overcomplication.<br />
--[[User:Eruditorum|Eruditorum]] ([[User talk:Eruditorum|talk]]) 06:48, 30 March 2013 (UTC)</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Acpid&diff=252335Acpid2013-03-30T06:38:51Z<p>Eruditorum: </p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Power management]]<br />
[[es:Acpid]]<br />
[[it:Acpid]]<br />
[[zh-CN:Acpid]]<br />
<br />
[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering [[ACPI modules|ACPI events]]. It listens on {{ic|/proc/acpi/event}} and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:<br />
* Pressing special keys, including the Power/Sleep/Suspend button<br />
* Closing a notebook lid<br />
* (Un)Plugging an AC power adapter from a notebook<br />
* (Un)Plugging phone jack etc.<br />
<br />
acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.<br />
<br />
{{Note|<br />
* [[Desktop Environment|desktop environments]], such as [[GNOME]], [[Systemd#ACPI power management|systemd]] login manager and some [[Extra Keyboard Keys|extra key handling]] daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.<br />
* Since by default the script provided by acpid, '''/etc/acpi/handler.sh''', will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).}}<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].<br />
<br />
To have it start on boot :<br />
* if you're using [[systemd]], run {{ic|systemctl enable acpid}} ;<br />
* if you're using [[rc.conf|initscripts]], edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]].<br />
<br />
== Configuration ==<br />
<br />
{{Pkg|acpid}} comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in {{ic|/etc/acpi/handler.sh}}, which is executed after any ACPI events are detected (as determined by {{ic|/etc/acpi/events/anything}}).<br />
<br />
The following is a brief example of one such action. In this case, when the Sleep button is pressed, acpid runs the command {{ic|echo -n mem >/sys/power/state}} which ''should'' place the computer into a sleep (suspend) state:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
;;<br />
<br />
Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as ''SLPB'' and on another as ''SBTN''. <br />
<br />
To determine how your buttons or {{Keypress|Fn}} shortcuts are recognized, run the following command from a terminal as root:<br />
# tail -f /var/log/messages.log<br />
<br />
Now press the Power button and/or Sleep button (e.g. {{Keypress|Fn+Esc}}) on your machine. The result should look something this:<br />
logger: ACPI action undefined: PBTN<br />
logger: ACPI action undefined: SBTN<br />
<br />
If that does not work, run:<br />
# acpi_listen<br />
<br />
Then press the power button and you will see something like this:<br />
power/button PBTN 00000000 00000b31<br />
<br />
The output of {{ic|acpi_listen}} is sent to {{ic|/etc/acpi/handler.sh}} as $1, $2 , $3 & $4 parameters.<br />
Example:<br />
$1 power/button<br />
$2 PBTN<br />
$3 00000000<br />
$4 00000b31<br />
<br />
As you might have noticed, the Sleep button in the sample output is actually recognized as ''SBTN'', rather than the ''SLPB'' label specified in the default {{ic|/etc/acpi/handler.sh}}. In order for Sleep function to work properly on this machine, we would need to replace ''SLPB)'' with ''SBTN)''.<br />
<br />
Using this information as a base, you can easily customize the {{ic|/etc/acpi/handler.sh}} file to execute a variety of commands depending on which event is triggered. See the [[Acpid#Tips & Tricks | Tips & Tricks]] section below for other commonly used commands.<br />
<br />
=== Alternative configuration ===<br />
<br />
By default, all ACPI events are passed through the {{ic|/etc/acpi/handler.sh}} script. This is due to the ruleset outlined in {{ic|/etc/acpi/events/anything}}:<br />
# Pass all events to our one handler script<br />
event=.*<br />
action=/etc/acpi/handler.sh %e<br />
<br />
While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:<br />
<br />
As root, create the following file:<br />
{{hc|/etc/acpi/events/sleep-button|<nowiki><br />
event=button sleep.*<br />
action=/etc/acpi/actions/sleep-button.sh "%e"<br />
</nowiki>}}<br />
<br />
Now create the following file:<br />
{{hc|/etc/acpi/actions/sleep-button.sh|<nowiki><br />
#!/bin/sh<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
</nowiki>}}<br />
<br />
Finally, make the script executable: <br />
# chmod +x /etc/acpi/actions/sleep-button.sh<br />
<br />
Using this method, it is easy to create any number of individual event/action scripts.<br />
<br />
==Tips and tricks==<br />
{{Tip|Some of actions, described here, such as Wi-Fi toggle and backlight control, may already be managed directly by driver. You should consult documentation of corresponding kernel modules, when this is the case.}}<br />
<br />
===Extending acpid with pm-utils===<br />
<br />
Although {{Pkg|acpid}} can provide basic suspend2ram out-of-the-box, a more robust system may be desired. [[pm-utils]] provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, {{ic|pm-suspend}} and {{ic|pm-hibernate}}, both of which can be inserted as events into acpid. For more information, check the [[pm-utils]] wiki.<br />
<br />
===Example Events===<br />
<br />
The following are examples of events that can be used in the {{ic|/etc/acpi/handler.sh}} script. These examples should be modified so that they apply your specific environment e.g. changing the event variable names interpreted by {{ic|acpi_listen}}.<br />
<br />
To lock the screen with {{ic|xscreensaver}} when closing the laptop lid:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
# The lock command need to be run as the user who owns the xscreensaver process and not as root.<br />
# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.<br />
<br />
xs=$(ps -C xscreensaver -o user=)<br />
if test $xs; then su $xs -c "xscreensaver-command -lock"; fi<br />
;;<br />
<br />
To suspend the system and lock the screen using {{ic|slimlock}} when the lid is closed:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
#echo "LID switched!">/dev/tty5<br />
/usr/sbin/pm-suspend &<br />
DISPLAY=:0.0 su -c - username /usr/bin/slimlock<br />
;;<br />
<br />
Execute {{ic|pm-suspend}} when the sleep button is pressed:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SBTN) <br />
#echo -n mem >/sys/power/state<br />
/usr/sbin/pm-suspend<br />
;;<br />
<br />
To set the laptop screen brightness when plugged in power or not (the numbers might need to be adjusted, see {{ic|/sys/class/backlight/acpi_video0/max_brightness}}):<br />
<br />
ac_adapter)<br />
case "$2" in<br />
AC*|AD*)<br />
case "$4" in<br />
00000000)<br />
echo -n 50 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
00000001)<br />
echo -n 100 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
esac<br />
<br />
=== Enabling volume control ===<br />
<br />
Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a script to control the volume (assuming an [[ALSA]] sound card):<br />
<br />
{{hc|/etc/acpi/handlers/vol|<nowiki><br />
#!/bin/sh<br />
step=5<br />
<br />
case $1 in<br />
-) amixer set Master $step-;;<br />
+) amixer set Master $step+;;<br />
esac<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/vol_d|<nowiki><br />
event=button/volumedown<br />
action=/etc/acpi/handlers/vol -<br />
</nowiki>}}<br />
{{hc|/etc/acpi/events/vol_u|<nowiki><br />
event=button/volumeup<br />
action=/etc/acpi/handlers/vol +<br />
</nowiki>}}<br />
<br />
as well as another event to toggle the mute setting:<br />
<br />
{{hc|/etc/acpi/events/mute|<nowiki><br />
event=button/mute<br />
action=/usr/bin/amixer set Master toggle<br />
</nowiki>}}<br />
<br />
=== Enabling backlight control ===<br />
<br />
Similar to volume control, acpid also enables you to control screen backlight. To achieve this you write some handler, like this:<br />
<br />
{{hc|/etc/acpi/handlers/bl|<nowiki><br />
#!/bin/sh<br />
bl_dev=/sys/class/backlight/acpi_video0<br />
step=1<br />
<br />
case $1 in<br />
-) echo $((`cat $bl_dev/brightness` - $step)) >$bl_dev/brightness;;<br />
+) echo $((`cat $bl_dev/brightness` + $step)) >$bl_dev/brightness;;<br />
esac<br />
</nowiki>}}<br />
<br />
and again, connect keys to ACPI events:<br />
<br />
{{hc|/etc/acpi/events/bl_d|<nowiki><br />
event=video/brightnessdown<br />
action=/etc/acpi/handlers/bl -<br />
</nowiki>}}<br />
{{hc|/etc/acpi/events/bl_u|<nowiki><br />
event=video/brightnessup<br />
action=/etc/acpi/handlers/bl +<br />
</nowiki>}}<br />
<br />
=== Enabling Wi-fi toggle ===<br />
<br />
You can also create a simple wireless-power switch by pressing the WLAN button. Example of event:<br />
<br />
{{hc|/etc/acpi/events/wlan|<nowiki><br />
event=button/wlan<br />
action=/etc/acpi/handlers/wlan<br />
</nowiki>}}<br />
<br />
and its' handler:<br />
<br />
{{hc|/etc/acpi/handlers/wlan|<nowiki><br />
#!/bin/sh<br />
rf=/sys/class/rfkill/rfkill0<br />
<br />
case `cat $rf/state` in<br />
0) echo 1 >$rf/state;;<br />
1) echo 0 >$rf/state;;<br />
esac<br />
</nowiki>}}<br />
<br />
=== Laptop Monitor Power Off ===<br />
<br />
Adapted from the [http://en.gentoo-wiki.com/wiki/ACPI/Configuration Gentoo Wiki] comes this little gem. Add this to the bottom of {{ic|/etc/acpi/actions/lm_lid.sh}} or to the ''button/lid'' section {{ic|/etc/acpi/handler.sh}}. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force off ;;<br />
open) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force on ;;<br />
esac<br />
<br />
If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.<br />
<br />
Here is another script not using XAUTHORITY but sudo:<br />
<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force off ;;<br />
open) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force on ;;<br />
esac<br />
<br />
With certain combinations of [[Xorg]] and stubborn hardware, {{ic|xset dpms force off}} only blanks the display leaving the backlight turned on. This can be fixed using {{Pkg|vbetool}} from the [[Official Repositories|official repositories]]. Change the LCD section to:<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) vbetool dpms off ;;<br />
open) vbetool dpms on ;;<br />
esac<br />
<br />
If the monitor appears to shut off only briefly before being re-powered, very possibly the power management shipped with xscreensaver conflicts with any manual ''dpms'' settings.<br />
<br />
=== Getting user name of the current display ===<br />
You can use the function {{ic|getuser}} to discover the user of the current display:<br />
getuser ()<br />
{<br />
export DISPLAY=`echo $DISPLAY | cut -c -2`<br />
user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`<br />
export XAUTHORITY=/home/$user/.Xauthority<br />
eval $1=$user<br />
}<br />
<br />
This function can be used for example, when you press the power button and want to shutdown [[KDE]] properly:<br />
button/power)<br />
case "$2" in<br />
PBTN)<br />
getuser "$user"<br />
echo $user > /dev/tty5<br />
su $user -c "dcop ksmserver ksmserver logout 0 2 0"<br />
;;<br />
*) logger "ACPI action undefined $2" ;;<br />
esac<br />
;;<br />
<br />
<br />
On newer systems using systemd, X11 logins are no longer necessarily displayed in {{ic|who}}, so the {{ic|getuser}} function above does not work. An alternative is to use {{ic|loginctl}} to obtain the required information, e.g. using [https://github.com/rephorm/xuserrun xuserrun].<br />
<br />
==See also==<br />
<br />
* http://acpid.sourceforge.net/ - acpid homepage<br />
* http://www.gentoo-wiki.info/ACPI/Configuration - RIP Gentoo wiki entry - New Gentoo Wiki Archives<br />
* [[ACPI hotkeys]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Bash&diff=252334Bash2013-03-30T06:18:54Z<p>Eruditorum: /* Tips and tricks */</p>
<hr />
<div>[[Category:Command shells]] <br />
[[de:Bash]]<br />
[[es:Bashrc]]<br />
[[it:Bash]]<br />
[[nl:Bashrc]]<br />
[[zh-CN:Bash]]<br />
{{Article summary start}}<br />
{{Article summary text|Discussing and improving Bash's capabilities.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Readline}}<br />
{{Article summary wiki|Environment Variables}}<br />
{{Article summary wiki|Color Bash Prompt}}<br />
{{Article summary end}}<br />
'''Bash''' (Bourne-again Shell) is a [[Command shell|shell]]/programming language by the [[GNU Project]]. Its name is a homaging reference to its predecessor: the long-deprecated Bourne shell. Bash can be run on most UNIX-like operating systems, including GNU/Linux.<br />
<br />
==Invocation==<br />
Bash behaviour can be altered depending on how it is invoked. Some descriptions of different modes follow.<br />
===Login shell===<br />
If Bash is spawned by {{ic|login}} in a tty, by an [[SSH]] daemon, or similar means, it is considered a login shell. This mode can also be engaged using the {{Ic|-l}} or {{Ic|--login}} command line options.<br />
<br />
===Interactive shell===<br />
Bash is considered an interactive shell if it is started neither with the {{Ic|-c}} option nor any non-option arguments, and whose standard input and error are connected to terminals.<br />
<br />
===POSIX compliance===<br />
Bash can be run with enhanced POSIX compliance by starting Bash with the {{Ic|--posix}} command-line option or executing ‘{{Ic|set -o posix}}’ while Bash is running.<br />
<br />
===Legacy mode===<br />
In Arch {{ic|/bin/sh}} (which used to be the Bourne shell executable) is symlinked to {{ic|/bin/bash}}.<br />
<br />
If Bash is invoked with the name {{Ic|sh}}, it tries to mimic the startup behavior of historical versions of {{Ic|sh}}.<br />
<br />
==Configuration==<br />
The following files can be used to configure bash:<br />
* {{ic|/etc/profile}}<br />
* {{ic|~/.bash_profile}}<br />
* {{ic|~/.bash_login}}<br />
* {{ic|~/.profile}}<br />
* {{ic|/etc/bash.bashrc}} (''Non-standard'': only some distros, Arch included)<br />
* {{ic|~/.bashrc}}<br />
* {{ic|~/.bash_logout}}<br />
<br />
These files are commonly used:<br />
* {{ic|/etc/profile}} is sourced by all Bourne-compatible shells upon login. It sets up an environment upon login and loads application-specific ({{ic|/etc/profile.d/*.sh}}) settings.<br />
* {{ic|~/.profile}} is read and sourced by bash when an interactive login shell is started.<br />
* {{ic|~/.bashrc}} is read and sourced by bash when a non-login interactive shell is started, for example, when you open a virtual console from the desktop environment. This file is useful for setting up a user-specific shell environment.<br />
<br />
===Configuration file sourcing order at startup===<br />
These files are sourced by bash in different circumstances. <br />
* if interactive + login shell → {{ic|/etc/profile}} then the first readable of {{ic|~/.bash_profile}}, {{ic|~/.bash_login}}, and {{ic|~/.profile}}<br />
**Bash will source {{ic|~/.bash_logout}} upon exit. <br />
* if interactive + non-login shell → {{ic|/etc/bash.bashrc}} then {{ic|~/.bashrc}}<br />
* if login shell + legacy mode → {{ic|/etc/profile}} then {{ic|~/.profile}}<br />
<br />
And by default in Arch:<br />
* {{ic|/etc/profile}} (indirectly) sources {{ic|/etc/bash.bashrc}}<br />
* {{ic|/etc/skel/.bash_profile}} which users are encouraged to copy to {{ic|~/.bash_profile}}, sources {{ic|~/.bashrc}}<br />
which means that {{ic|/etc/bash.bashrc}} and {{ic|~/.bashrc}} will be executed for all interactive shells, whether they are login shells or not.<br />
<br />
===Shell and environment variables===<br />
The behavior of bash and programs run by it can be influenced by a number of environment variable. Environment variables are used to store useful values such as command search directories, or which browser to use. When a new shell or script is launched it inherits its parent's variables, thus starting with an internal set of shell variables[http://www.kingcomputerservices.com/unix_101/understanding_unix_shells_and_environment_variables.htm ].<br />
<br />
These shell variables in bash can be exported in order to become environment variables:<br />
VARIABLE=content<br />
export VARIABLE<br />
or with a shortcut<br />
export VARIABLE=content<br />
<br />
Environment variables are conventionally placed in {{ic|~/.profile}} or {{ic|/etc/profile}} so that all bourne-compatible shells can use them.<br />
<br />
See [[Environment Variables]] for more general information.<br />
<br />
==Command line==<br />
Bash command line is managed by the separate library called [[Readline]]. Readline provides a lot of shortcuts for interacting with the command line i.e. moving back and forth on the word basis, deleting words etc. It is also Readline's responsibility to manage [[Readline#History|history]] of input commands. Last, but not least, it allows you to create [[Readline#Macros|macros]].<br />
<br />
==Aliases==<br />
[[Wikipedia:alias|alias]] is a command, which enables a replacement of a word with another string. It is often used for abbreviating a system command, or for adding default arguments to a regularly used command.<br />
<br />
Personal aliases are preferably stored in {{ic|~/.bashrc}}, and system-wide aliases (which affect all users) belong in {{ic|/etc/bash.bashrc}}.<br />
<br />
An example excerpt from {{ic|~/.bashrc}} covering several time-saving aliases:<br />
{{hc|~/.bashrc<br />
|2=<nowiki><br />
# modified commands<br />
alias diff='colordiff' # requires colordiff package<br />
alias grep='grep --color=auto'<br />
alias more='less'<br />
alias df='df -h'<br />
alias du='du -c -h'<br />
alias mkdir='mkdir -p -v'<br />
alias nano='nano -w'<br />
alias ping='ping -c 5'<br />
alias ..='cd ..'<br />
<br />
# new commands<br />
alias da='date "+%A, %B %d, %Y [%T]"'<br />
alias du1='du --max-depth=1'<br />
alias hist='history | grep' # requires an argument<br />
alias openports='ss --all --numeric --processes --ipv4 --ipv6'<br />
alias pg='ps -Af | grep $1' # requires an argument (note: /usr/bin/pg is installed by the util-linux package; maybe a different alias name should be used)<br />
<br />
# privileged access<br />
if [ $UID -ne 0 ]; then<br />
alias sudo='sudo '<br />
alias scat='sudo cat'<br />
alias svim='sudo vim'<br />
alias root='sudo su'<br />
alias reboot='sudo reboot'<br />
alias halt='sudo halt'<br />
alias update='sudo pacman -Su'<br />
alias netcfg='sudo netcfg2'<br />
fi<br />
<br />
# ls<br />
alias ls='ls -hF --color=auto'<br />
alias lr='ls -R' # recursive ls<br />
alias ll='ls -l'<br />
alias la='ll -A'<br />
alias lx='ll -BX' # sort by extension<br />
alias lz='ll -rS' # sort by size<br />
alias lt='ll -rt' # sort by date<br />
alias lm='la | more'<br />
<br />
# safety features<br />
alias cp='cp -i'<br />
alias mv='mv -i'<br />
alias rm='rm -I' # 'rm -i' prompts for every file<br />
alias ln='ln -i'<br />
alias chown='chown --preserve-root'<br />
alias chmod='chmod --preserve-root'<br />
alias chgrp='chgrp --preserve-root'<br />
<br />
# pacman aliases (if necessary, replace 'pacman' with your favorite AUR helper and adapt the commands accordingly)<br />
alias pac="sudo /usr/bin/pacman -S" # default action - install one or more packages<br />
alias pacu="/usr/bin/pacman -Syu" # '[u]pdate' - upgrade all packages to their newest version<br />
alias pacr="sudo /usr/bin/pacman -Rs" # '[r]emove' - uninstall one or more packages<br />
alias pacs="/usr/bin/pacman -Ss" # '[s]earch' - search for a package using one or more keywords<br />
alias paci="/usr/bin/pacman -Si" # '[i]nfo' - show information about a package<br />
alias paclo="/usr/bin/pacman -Qdt" # '[l]ist [o]rphans' - list all packages which are orphaned<br />
alias pacc="sudo /usr/bin/pacman -Scc" # '[c]lean cache' - delete all not currently installed package files<br />
alias paclf="/usr/bin/pacman -Ql" # '[l]ist [f]iles' - list all files installed by a given package<br />
alias pacexpl="/usr/bin/pacman -D --asexp" # 'mark as [expl]icit' - mark one or more packages as explicitly installed <br />
alias pacimpl="/usr/bin/pacman -D --asdep" # 'mark as [impl]icit' - mark one or more packages as non explicitly installed<br />
<br />
# '[r]emove [o]rphans' - recursively remove ALL orphaned packages<br />
alias pacro="/usr/bin/pacman -Qtdq > /dev/null && sudo /usr/bin/pacman -Rs \$(/usr/bin/pacman -Qtdq | sed -e ':a;N;$!ba;s/\n/ /g')"</nowiki>}}<br />
<br />
==Functions==<br />
Bash also supports functions. The following function will extract a wide range of compressed file types. Add the function to {{ic|~/.bashrc}} and use it with the syntax {{Ic|extract <file1> <file2> ...}}<br />
<br />
{{hc|~/.bashrc<br />
|2=<nowiki><br />
extract() {<br />
local c e i<br />
<br />
(($#)) || return<br />
<br />
for i; do<br />
c=''<br />
e=1<br />
<br />
if [[ ! -r $i ]]; then<br />
echo "$0: file is unreadable: \`$i'" >&2<br />
continue<br />
fi<br />
<br />
case $i in<br />
*.t@(gz|lz|xz|b@(2|z?(2))|a@(z|r?(.@(Z|bz?(2)|gz|lzma|xz)))))<br />
c='bsdtar xvf';;<br />
*.7z) c='7z x';;<br />
*.Z) c='uncompress';;<br />
*.bz2) c='bunzip2';;<br />
*.exe) c='cabextract';;<br />
*.gz) c='gunzip';;<br />
*.rar) c='unrar x';;<br />
*.xz) c='unxz';;<br />
*.zip) c='unzip';;<br />
*) echo "$0: unrecognized file extension: \`$i'" >&2<br />
continue;;<br />
esac<br />
<br />
command $c "$i"<br />
e=$?<br />
done<br />
<br />
return $e<br />
}<br />
</nowiki>}}<br />
<br />
{{note|[[Bash]] users should make sure extglob is enabled: {{Ic|shopt -s extglob}}, for example by adding it to the {{ic|.bashrc}}. It is enabled by default if using [[Bash#Advanced completion|Bash completion]]. [[Zsh]] users should do: {{Ic|setopt kshglob}} instead.}}<br />
Another way to do this is to install the {{AUR|unp}} package from the [[AUR]] which contains a Perl script.<br />
<br />
Very often changing to a directory is followed by the {{ic|ls}} command to list its contents. Therefore it is helpful to have a second function doing both at once.<br />
In this example we will name it {{ic|cl}} and show an error message if the specified directory does not exist.<br />
{{hc|~/.bashrc<br />
|2=<nowiki><br />
# cd and ls in one<br />
cl() {<br />
if [ -d "$1" ]; then<br />
cd "$1"<br />
ls<br />
else<br />
echo "bash: cl: '$1': Directory not found"<br />
fi<br />
}<br />
</nowiki>}}<br />
Of course the ls command can be altered to fit your needs, for example {{ic|1=ls -hall --color=auto}}.<br />
<br />
More Bash function examples can be found [https://bbs.archlinux.org/viewtopic.php?id=30155 here.]<br />
<br />
==Tips and tricks==<br />
===Prompt customization===<br />
The bash prompt is governed by the variable {{Ic|$PS1}}. To colorize the bash prompt, first comment out the default {{Ic|$PS1}}:<br />
#PS1='[\u@\h \W]\$ '<br />
Then add the following line:<br />
PS1='\[\e[0;31m\]\u\[\e[m\] \[\e[1;34m\]\w\[\e[m\] \[\e[0;31m\]\$ \[\e[m\]\[\e[0;32m\] '<br />
This {{Ic|$PS1}} is useful for a root bash prompt, with red designation and green console text. For details on customizing your bash prompt, see [[Color Bash Prompt]].<br />
<br />
===Tab completion===<br />
It is useful to have the tab complete feature (pressing {{Keypress|Tab}} key twice on the keyboard) after you type some command like sudo.<br />
<br />
To do this add a line in this format to your {{ic|~/.bashrc}} file:<br />
complete -cf your_command<br />
<br />
For example, to enable tab complete after sudo and man:<br />
complete -cf sudo<br />
complete -cf man<br />
<br />
====Advanced completion====<br />
Despite Bash's native support for basic file name, command, and variable tab completion, there are ways of improving and extending its reach.<br />
<br />
The {{Pkg|bash-completion}} package extends functionality by adding tab completion to a wide range of commands and their options. Enabling advanced bash completion is quite simple, just install the following package:<br />
# pacman -S bash-completion<br />
Start a new shell and it will be automatically enabled thanks to {{ic|/etc/bash.bashrc}}.<br />
{{Note|If you added any lines similar to "complete -cf sudo" as mentioned in the previous settings and have problems with bash-completion, try removing those lines.}}<br />
<br />
{{Note|1=The normal expansions that you are used to like "$ ls file.*<tab><tab>" will not work unless you "$ compopt -o bashdefault <prog>" for all programs you want to fallback to the normal glob expansions. See https://bbs.archlinux.org/viewtopic.php?id=128471 and https://www.gnu.org/software/bash/manual/html_node/Programmable-Completion-Builtins.html}}<br />
<br />
====Faster completion====<br />
By appending the following into the readline initialization file ({{ic|~/.inputrc}} or {{ic|/etc/inputrc}} by default):<br />
set show-all-if-ambiguous on<br />
it is no longer necessary to hit {{Keypress|Tab}} (default binding) twice to produce a list of all possible completions (both when a partial completion is possible and when no completion is possible), as a single key-press will suffice. Alternatively, to produce such a list only when no completion is possible (i.e., not when a partial completion is possible), append the following command in lieu of the previous one:<br />
set show-all-if-unmodified on<br />
<br />
=== The "command not found" hook ===<br />
The [[pkgfile]] package includes a "command not found" hook that will automatically search the [[official repositories]] when you enter an unrecognized command. Then it will display something like this:<br />
<div style="font-family: monospace; white-space: pre; overflow: auto; margin: 1em 3em; padding: 1em; border: 3px solid #bcd; background-color: black; color: #aaa;"><span style="color: #0a0">chiri</span> <span style="color: #00f">~/docs</span> <span style="color: #0f0">$</span> abiword<nowiki><br />
abiword may be found in the following packages:<br />
extra/abiword 2.8.6-7 usr/bin/abiword<br />
</nowiki><span style="color: #0a0">chiri</span> <span style="color: #00f">~/docs</span> <span style="color: #0f0">$</span> <span style="text-decoration: blink;">_</span></div><br />
<br />
An alternative "command not found" hook is also provided by the AUR package [https://aur.archlinux.org/packages.php?ID=52305 command-not-found], which will generate an output like the following:<br />
<br />
<div style="font-family: monospace; white-space: pre; overflow: auto; margin: 1em 3em; padding: 1em; border: 3px solid #bcd; background-color: black; color: #aaa;"><span style="color: #0a0">chiri</span> <span style="color: #00f">~/docs</span> <span style="color: #0f0">$</span> abiword<br />
The command 'abiword' is been provided by the following packages:<br />
<span style="font-weight: bold">abiword</span> (2.8.6-7) from extra<nowiki><br />
</nowiki>[ <span style="color: #bb0000">abiword</span> ]<br />
<span style="font-weight: bold">abiword</span> (2.8.6-7) from staging<nowiki><br />
</nowiki>[ <span style="color: #bb0000">abiword</span> ]<br />
<span style="font-weight: bold">abiword</span> (2.8.6-7) from testing<nowiki><br />
</nowiki>[ <span style="color: #bb0000">abiword</span> ]<br />
<span style="color: #0a0">chiri</span> <span style="color: #00f">~/docs</span> <span style="color: #0f0">$</span> <span style="text-decoration: blink;">_</span></div><br />
===Display return codes===<br />
You can set trap to intercept return code of last exited program.<br />
To show non-zero error code of last command you can add following lines to your {{ic|~/.bashrc}}:<br />
{{bc|1=<br />
EC() { echo -e '\e[1;33m'code $?'\e[m\n'; }<br />
trap EC ERR<br />
}}<br />
=== Disable Ctrl+z in terminal===<br />
You can disable {{Keypress|Ctrl+z}} (pauses/closes your CLI application) feature for you CLI by wrapping your command in this script<br />
#!/bin/bash<br />
trap "" 20<br />
/path_to_your_application/<br />
example:<br />
#!/bin/bash<br />
trap "" 20<br />
/usr/bin/adom<br />
<br />
With this example script, when you accidentally press {{Keypress|Ctrl+z}} instead of {{Keypress|Shift+z}} or some other key combination while playing Adom(game) your game will not end. Nothing will happen because {{Keypress|Ctrl+z}} will be ignored.<br />
<br />
===Clear the screen after logging out===<br />
To clear the screen after logging out on a virtual terminal, append the following lines to {{ic|~/.bash_logout}}:<br />
clear<br />
reset<br />
<br />
===ASCII art, fortunes and cowsay===<br />
Along with colors, system info and ASCII symbols, Bash can be made to display a piece of ASCII art on login. ASCII images can be found online and pasted into a text file, or generated from scratch. To set the image to display in a terminal on login, place the string <br />
cat /path/to/text/file<br />
at the top of {{ic|~/.bashrc}}.<br />
<br />
Random poignant, inspirational, silly or snide phrases can also be shown. To see an example, install the {{Pkg|fortune-mod}} package from the {{Ic|extra}} repository.<br />
<br />
{{bc|1=<br />
'''<font color=red>(</font><font color=green>user@host</font><font color=red>)-(</font><font color=green>10:10 AM Wed Dec 22</font><font color=red>)'''<br />
--(</font><font color=green>~</font><font color=red>)---> </font> fortune<br />
<br/><br />
It is Texas law that when two trains meet each other at a railroad crossing,<br />
each shall come to a full stop, and neither shall proceed until the other has gone.}}<br />
<br />
To have a random phrase displayed when logging into a terminal, just set <br />
command fortune<br />
as the top line in {{ic|~/.bashrc}}.<br />
<br />
{{Note|By default, {{Ic|fortune}} displays quotes and phrases that are rather inoccuous. However, the package does contain a set of comments some will find offensive, located in {{ic|/usr/share/fortune/off}}. See the man page for more info on these.}}<br />
<br />
These two features can be combined, using the program {{Pkg|cowsay}}. Modify the line at the top of {{ic|~/.bashrc}} to read <br />
command cowsay $(fortune)<br />
<br />
or<br />
command cowthink $(fortune)<br />
<br />
<br />
The earth is like a tiny grain of sand, <br />
only much, much heavier. <br />
----------------------------------------- <br />
\ ^__^<br />
\ (oo)\_______<br />
(__)\ )\/\<br />
||----w |<br />
|| ||<br />
<br />
The ASCII images are generated by {{ic|.cow}} text files located in {{ic|/usr/share/cows}}, and all themes can be listed with the command {{Ic|cowsay -l}} These files can be edited to the user's liking; custom images can also be created from scratch or found on the net. The easiest way create a custom cow file from an image found online would be to open an existing {{ic|.cow}} file in a text editor, copy-and-paste the image from a browser and save the file as a different name. Test the custom file using<br />
<br />
# cowsay -f {{ic|cowfile}} $(fortune)<br />
<br />
This can produce some nice eye candy, and the commands used can be more complex. For a specialized example, take a look [http://bambambambam.wordpress.com/2009/07/04/futurama-ascii-with-slashdot-header-quotes-in-your-terminal/ here.] Another example, to use a random cow, random facial expression, and nicely wrap the text of long fortunes:<br />
<br />
fortune -a | fmt -80 -s | $(shuf -n 1 -e cowsay cowthink) -$(shuf -n 1 -e b d g p s t w y) -f $(shuf -n 1 -e $(cowsay -l | tail -n +2)) -n<br />
<br />
________________________________________ <br />
( Fry: I must be a robot. Why else would )<br />
( human women refuse to date me? )<br />
---------------------------------------- <br />
o<br />
o<br />
o <br />
,'``.._ ,'``.<br />
:,--._:)\,:,._,.:<br />
:`--,''@@@:`...';\ <br />
`,'@@@@@@@`---'@@`. <br />
/@@@@@@@@@@@@@@@@@:<br />
/@@@@@@@@@@@@@@@@@@@\<br />
,'@@@@@@@@@@@@@@@@@@@@@:\.___,-.<br />
`...,---'``````-..._@@@@|:@@@@@@@\<br />
( )@@@;:@@@@)@@@\ _,-.<br />
`. (@@@//@@@@@@@@@@`'@@@@\<br />
: `.//@@)@@@@@@)@@@@@,@;<br />
|`. _,'/@@@@@@@)@@@@)@,'@,'<br />
:`.`-..____..=:.-':@@@@@.@@@@@_,@@,'<br />
,'\ ``--....-)=' `._,@@\ )@@@'``._<br />
/@_@`. (@) /@@@@@) ; / \ \`-.'<br />
(@@@`-:`. `' ___..'@@_,-' |/ `.)<br />
`-. `.`.``-----``--,@@.'<br />
|/`.\`' ,',');<br />
` (/ (/<br />
'''<font color=red>(</font><font color=green>user@host</font><font color=red>)-(</font><font color=green>10:10 AM Wed Dec 22</font><font color=red>)'''--(</font><font color=green>~</font>)<font color=red>)---></font><br />
<br />
{{Note|If you want a full colored cowsay-like art, the best option is {{Pkg|ponysay}}, this show full colored ponies (more than 220 at version 1.1) in you terminal (inside X11 or in TTY you have full 256 colored ponies) runing 'ponysay "command or fortune command"', the complete list of ponies are showed usind 'ponysay -l'.<br />
Exist in AUR a tool for creating more ponies (or other stuff) called {{aur|util-say-git}}, and these news archives need to be stored in $HOME/.local/share/ponysay/ponies and $HOME/.local/share/ponysay/ttyponies for desktop and TTY respectibely}}<br />
<br />
===ASCII Historical Calendar===<br />
To install [http://www.openbsd.org/cgi-bin/man.cgi?query=calendar&sektion=1 calendar] files in your {{ic|~/.calendar}} directory you will need the {{Pkg|rpmextract}} package installed. Then from your home directory, run the following:<br />
$ mkdir -p ~/.calendar<br />
$ curl -o calendar.rpm http://download.fedora.redhat.com/pub/epel/5/x86_64/calendar-1.25-4.el5.x86_64.rpm<br />
$ rpm2cpio calendar.rpm | bsdtar -C ~/.calendar --strip-components=4 -xf - ./usr/share/c*<br />
<br />
This will then print out the calendar items<br />
$ sed -n "/$(date +%m\\/%d\\\|%b\*\ %d)/p" $(find ~/.calendar /usr/share/calendar -maxdepth 1 -type f -name 'c*' 2>/dev/null);<br />
<br />
===Customise Title===<br />
<br />
The {{ic|$PROMPT_COMMAND}} variable allows you to execute a command before the prompt. For example, this will change the title to your full current working directory:<br />
<br />
export PROMPT_COMMAND='echo -ne "\033]0;$PWD\007"'<br />
<br />
This will change your title to the last command run, and make sure your history file is always up-to-date:<br />
export HISTCONTROL=ignoreboth<br />
export HISTIGNORE='history*'<br />
export PROMPT_COMMAND='history -a;echo -en "\e]2;";history 1|sed "s/^[ \t]*[0-9]\{1,\} //g";echo -en "\e\\";'<br />
<br />
===Fix line wrap on window resize===<br />
<br />
When you resize your xterm in vi for example, Bash will not get the resize signal, and the text you type will not wrap correctly, overlapping the prompt.<br />
<br />
Use the following in your {{ic|/etc/bash.bashrc}} (from Debian) :<br />
# check the window size after each command and, if necessary,<br />
# update the values of LINES and COLUMNS.<br />
shopt -s checkwinsize<br />
<br />
===Bash history completion===<br />
Bash history completion bound to arrow keys (down, up):<br />
# ~/.bashrc<br />
bind '"\e[A": history-search-backward'<br />
bind '"\e[B": history-search-forward'<br />
or equivalently in {{ic|~/.inputrc}}:<br />
# ~/.inputrc<br />
"\e[A": history-search-backward<br />
"\e[B": history-search-forward<br />
More info at [[Readline#History]] and [https://www.gnu.org/software/bash/manual/html_node/Readline-Init-File-Syntax.html]<br />
<br />
===Auto "cd" when entering just a path===<br />
Bash can automatically prepend {{ic|cd }} when entering just a path in the shell. For example,<br />
$ /etc<br />
<br />
normally returns this error:<br />
bash: /etc: Is a directory<br />
<br />
Enabling this feature will instead result in this:<br />
[user@host ~] $ /etc<br />
cd /etc<br />
[user@host etc] $ pwd<br />
/etc<br />
<br />
To enable this feature, you need to enable the shell option for it. To enable this persistently, add this line to your {{ic|~/.bashrc}} file:<br />
shopt -s autocd<br />
<br />
==See also==<br />
* [http://tldp.org/LDP/abs/html/ Advanced Bash Scripting Guide] - Very good resource regarding shell scripting using bash<br />
* [http://www.gnu.org/software/bash/manual/bashref.html Bash Reference Manual] - Official reference (654K)<br />
* [http://wiki.bash-hackers.org/doku.php Bash Hackers Wiki] - Excellent Bash Wiki<br />
* [http://bashscripts.org Bashscripts.org] - Forum for bash coders.<br />
* [http://www.ibm.com/developerworks/linux/library/l-bash.html Bash Scripting by Example]<br />
* [http://www.caliban.org/bash Completion Guide]<br />
* [http://mywiki.wooledge.org/BashFAQ Greg's Wiki] - Highly recommended<br />
* [http://www.gnu.org/software/bash/manual/bash.html man page]<br />
* [http://www.grymoire.com/Unix/Quote.html Quote Tutorial]<br />
* irc://irc.freenode.net#bash - Active and friendly Internet Relay Chat channel for Bash.<br />
* http://chakra-project.org/wiki/index.php/Startup_files<br />
* [http://www.aosabook.org/en/bash.html The Bourne-Again Shell] - The third chapter of ''The Architecture of Open Source Applications''<br />
* [http://tldp.org/HOWTO/Xterm-Title-4.html How to change the title of an xterm]<br />
* [http://www.gnu.org/software/bash/manual/html_node/Readline-Init-File-Syntax.html Readline Init File Syntax ]<br />
* [http://gotux.net/arch-linux/custom-bash-commands-functions/ Custom Bash Commands & Functions]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Laptop&diff=247905Laptop2013-02-19T16:06:51Z<p>Eruditorum: /* Battery State */</p>
<hr />
<div>[[Category:Laptops]]<br />
[[cs:Laptop]]<br />
[[es:Laptop]]<br />
[[it:Laptop]]<br />
[[ru:Laptop]]<br />
[[zh-CN:Laptop]]<br />
== Setting Up For Laptops ==<br />
This page should contain links to pages needed for configuring a laptop for the best experience. Setting up a laptop is in many ways the same as setting up a desktop. However, there are a few key differences. When setting up a laptop with Arch Linux, the following points should be taken into consideration:<br />
<br />
* [[#Power Management]] Power Management for laptops refers to optimizing the system to last as long as possible on a single battery charge. This can be accomplished by a variety of tweaks.<br />
** [[#Suspend and Hibernate]] : the operating system can be manually suspended either to memory or to disk, allowing for an (almost) complete shutdown of other hardware.<br />
** Hard drive spindown : the system can be configured to automatically turn off the hard disk after a specified interval of inactivity.<br />
** Screen shut off : the laptop screen can be configured to automatically turn off after a specified interval of inactivity (not just blanked with a screensaver but completely shut off).<br />
** CPU frequency scaling : the processor(s) can be configured to automatically step down to a lower frequency at lower loads.<br />
<br />
* [[#Screen brightness]]. How do I manage screen brightness?<br />
* Network and wireless setup is described in [[Wireless Setup]].<br />
* Media buttons can be configured as described in [[Extra Keyboard Keys]].<br />
* [[#Touchpad]] sensitivity, acceleration, button function and scroll borders can be configured for some (Synaptics or Alps) touchpads.<br />
* [[#Hard disk shock protection]] <br />
<br />
All of these points are important to take into consideration when getting a laptop set up the way you like. Fortunately, Arch Linux provides all the tools and programs necessary to take complete control of your laptop. These programs and utilities are highlighted below, with appropriate tips tutorials.<br />
<br />
Note: the following links may be useful:<br />
<br />
* [http://www.linux-on-laptops.com/ http://www.linux-on-laptops.com/]<br />
* [http://www.linlap.com/ http://www.linlap.com/]<br />
<br />
== Power Management ==<br />
Power management is very important for anyone who wishes to make good use of their battery capacity. The following tools and programs help to increase battery life and keep your laptop cool and quiet.<br />
<br />
=== Battery State ===<br />
<br />
==== Udev events ====<br />
<br />
When battery charges/discharges it sends events which can be handled by udev. Example of how it could be used is presented below.<br />
<br />
==== Low charge action ====<br />
<br />
By default, system won't do anything if your laptop's battery is going to discharge. In order not to lose all unsaved work this example udev rule could be used:<br />
{{hc|/etc/udev/rules.d/lowbat.rules|<nowiki><br />
## SLEEP IF BATTERY IS LOW<br />
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend"<br />
</nowiki>}}<br />
Likewise, the rule can be customized to perform other action on different status.<br />
<br />
==== Utilities ====<br />
<br />
Battery state can be read using ACPI utilities from the terminal. ACPI command line utilities are provided via the {{Pkg|acpi}} package. A simple battery monitor that sits in the system tray is {{AUR|batterymon-clone}} which can be found in the [[Arch User Repository|AUR]].<br />
<br />
{{Tip|More information can be found in the [[ACPI modules]] article.}}<br />
<br />
* {{pkg|batti}} is a simple battery monitor for the system tray, similar to batterymon-clone. Unlike the latter {{ic|batti}} uses UPower, and if that is missing DeviceKit.Power, for it's power information.<br />
<br />
=== Suspend and Hibernate ===<br />
<br />
Manually suspending the operating system, either to memory (standby) or to disk (hibernate) sometimes provides the most efficient way to optimize battery life, depending on the usage pattern of the laptop. While there is relatively straightforward support in the linux kernel to support these operations, typically some adjustments have to be made before initiating these operations (typically due to problematic drivers, modules or hardware). The following tools provide wrappers around the kernel interfaces to suspend/resume :<br />
<br />
* [[Acpid]]<br />
* [[Pm-utils]]<br />
* [[Uswsusp]]<br />
<br />
which are described in more detail in [[Suspend]].<br />
<br />
===Power saving===<br />
<br />
See the main article, [[power saving]].<br />
<br />
==== Automatic tweaks for battery life ====<br />
<br />
As opposed to manually initiated actions like suspend/hibernate, a number of tweaks can be made to prolong the battery life of the laptop under low/idle usage.<br />
<br />
* [[CPU Frequency Scaling]] is a technology used primarily by notebooks which enables the OS to scale the CPU frequency up or down, depending on the current system load and/or power scheme.<br />
* [[Laptop Mode Tools]] provides a comprehensive suite of tools to tweak a large number of power saving settings through well documented configuration files.<br />
* [[Powertop]] is a handy utility from Intel that displays which hardware/processes are using the most power on your system, and provides instructions on how to stop or remove power-wasting services. Works great for mobile Intel CPUs; provides the current CPU state and suggestions for power saving. Also works on AMD systems, but does not provide as much information about the CPU state.<br />
<br />
The following options are specific to certain laptop types:<br />
<br />
* [[Asus_G1#The_Lapsus_daemon_.26_KDE_applet|Lapsus]] is a set of programs providing easy access to many features of various laptops. It currently supports most features provided by asus-laptop kernel module from ACPI4Asus project, such as additional LEDs, hotkeys, backlight control etc. It also has support for some IBM laptops features provided by IBM ThinkPad ACPI Extras Driver and NVRAM device.<br />
* Battery tweaks for Thinkpads can be found in the [[tp_smapi]] article.<br />
* [[TLP]] for Thinkpads is a set of scripts, which set many powersaving options according to the current Powersource. [[TLP]] is intended to be used on Thinkpads, but most settings should work on other laptops too.<br />
<br />
====PCI-e ASPM====<br />
On some laptops, powertop suggests enabling the {{ic|CONFIG_PCIEASPM}} kernel option. It can be found under "Bus options (PCI etc.)"->"PCI Express ASPM support". This option is marked as experimental in the current kernel (2.6.35) and allows the PCI-e links to enter a power saving state. <br />
<br />
According to [http://www.lesswatts.org/projects/devices-power-management/pcie.php], this option might degrade performance a bit, but on an Acer 3820TG laptop, it can reduce power consumption by about one third or even more.<br />
<br />
More experience with this setting would be appreciated, so please share them [https://bbs.archlinux.org/viewtopic.php?id=107173 here]!<br />
<br />
It seems like the option is going to be enabled by default in kernel 2.6.36; if so, the information here will be obsolete soon. However, if your system should be able to make use of this power management feature but you are receiving messages like like the following (check {{ic|/var/log/everything.log*}}):<br />
<br />
disabling ASPM on pre-1.1 PCI-e device. You can enable it with 'pcie_aspm=force'<br />
<br />
then add {{ic|pcie_aspm<nowiki>=</nowiki>force}} to your kernel command line.<br />
<br />
==== Granola ====<br />
<br />
{{Out of date|Arch Linux has moved to systemd, so rc.conf is no longer used.}}<br />
<br />
[https://aur.archlinux.org/packages.php?ID=36841 Granola] is a daemon that monitors the cpu usage and uses the cpufreq-userspace module to lessen power usage without any noticeable difference in performance.<br />
To use it, first install from the AUR:[https://aur.archlinux.org/packages.php?ID=36841], the default settings will work for most setups.<br />
You will need to load the cpufreq_userspace module, as well as the cpufreq scaling governor for your CPU at startup.<br />
Edit {{ic|/etc/rc.conf}}:<br />
For most generic cpus:<br />
<br />
MODULES=( ... cpufreq_userspace acpi-cpufreq ... )<br />
<br />
For Intel Atom or Pentium 4 cpus:<br />
<br />
MODULES=( ... cpufreq_userspace p4_clockmod ... )<br />
<br />
Then add Granola to the DAEMONS array:<br />
<br />
DAEMONS=( ... granola ... )<br />
<br />
and reboot. <br />
<br />
To test if it worked, run:<br />
<br />
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq<br />
#OR<br />
cpufreq-info #if you have cpufreq-utils installed<br />
<br />
and check that the cpu frequency is below maximum.<br />
<br />
====WLAN-device====<br />
When often en route working with your Notebook without WLAN-Access around, it might be expedient to add a little script to your system startup that automatically turns off your WLAN-Hardware to keep it from searching for Access Points and wasting power on this, when not connected:<br />
<br />
#!/bin/bash<br />
<br />
essid="`iwconfig wlan0 | grep ESSID | awk {'print $4'}`"<br />
if [ "$essid" == "ESSID:off/any" ] ; then<br />
sudo iwconfig wlan0 txpower off<br />
fi<br />
[edit, if wlan0 is not your WLAN-device]<br />
<br />
Start the script according to your DE/WM options by '(sleep xx && /path/to/script)' depending on how long it usually takes to connect to your Access Point, 60 seconds are a good default value. It will check if you're connected, turning off the device if not.<br />
sudo iwconfig wlan0 txpower on<br />
will bring it back up, as, of course, a reboot will.<br />
<br />
==== Disk-related tweaks ====<br />
Disable file access time: every time you access (read) a file the filesystem writes an access time to the file metadata. You can disable this on individual files by using the chattr command, or you can enable it on an entire disk by setting the ''noatime'' option in your fstab, as follows:<br />
<br />
/dev/sda1 / ext3 defaults,noatime 1 2<br />
<br />
[http://www.faqs.org/docs/securing/chap6sec73.html Source]<br />
<br />
{{Note|<br />
* Disabling {{ic|atime}} causes troubles with [[Mutt|mutt]] and other applications that make use of file timestamps. Consider compromising between performance and compatibility by using mount option {{ic|relatime}} instead, or look into [http://wiki.mutt.org/?MaildirFormat mutt work-around for noatime].<br />
* {{ic|relatime}} is used by default as of kernel 2.6.30, so unless you're using an older kernel, there should be no need to edit fstab.<br />
}}<br />
<br />
To allow the CD/DVD rom to spin down after a while using [[udisks]]:<br />
<br />
# udisks --inhibit-polling /dev/sr0<br />
<br />
==== More tweaks ====<br />
These are some generic suggestions that will work with most laptops.<br />
<br />
Add the following to {{ic|/etc/modprobe.d/modprobe.conf}}:<br />
<br />
options usbcore autosuspend=1<br />
<br />
Add the following to {{ic|/etc/sysctl.conf}}<br />
<br />
vm.dirty_writeback_centisecs=1500<br />
vm.laptop_mode=5<br />
<br />
{{Note|''laptop-mode-tools'' automatically rewrites these values based on the values {{Ic|LM_BATT_MAX_LOST_WORK_SECONDS}}, {{Ic|LM_AC_MAX_LOST_WORK_SECONDS}} (both multiplied by 100) resp. {{Ic|LM_SECONDS_BEFORE_SYNC}}, which are set in {{ic|/etc/laptop-mode/laptop-mode.conf}}. However, that only happens if the three "Enable laptop mode" variables in the same file are set accordingly — left to 0, it resets the values to kernel defaults (500 / 0) for the corresponding scenario regardless of {{ic|/etc/sysctl.conf}}.}}<br />
<br />
{{accuracy|reason=This belongs in a udev rule, not rc.local.}}<br />
<br />
Add the following to {{ic|/etc/rc.local}} (and make sure it gets executed at boot time)<br />
<br />
/usr/sbin/iwpriv your_wireless_interface set_power 5<br />
<br />
Source: [http://www.nervous.it/2007/11/linux-dell-xps-m1330/ here]<br />
<br />
==== Hard drive spin down problem ====<br />
Documented [https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 here]<br />
<br />
To prevent your laptop hard drive from spinning down too often (result of too aggressive APM defaults) do the following:<br />
<br />
Add the following to {{ic|/etc/rc.local}}<br />
<br />
hdparm -B 254 /dev/sdX ''where X is your hard drive device''<br />
<br />
You can also set it to 255 to completely disable spinning down. You may wish to set a lower value if you move your laptop around as lower values park the heads more often and reduce the chance of damage to your hard disk while it is being moved. If you do not move your laptop at all when you are using it, then 255 or 254 is probably best. If you do, then you might want to try a lower value. A value like 128 might be a good middle-ground.<br />
<br />
Add the following to {{ic|/etc/pm/sleep.d/50-hdparm_pm}}<br />
<br />
#!/bin/sh<br />
<br />
if [ -n "$1" ] && ([ "$1" = "resume" ] || [ "$1" = "thaw" ]); then<br />
hdparm -B 254 /dev/your-hard-drive > /dev/null<br />
fi<br />
<br />
and run ''chmod +x /etc/pm/sleep.d/50-hdparm_pm'' to make sure it resets after suspend. Again, you can change the value 254 as you see fit.<br />
<br />
Now the APM level should be set for your hard drive.<br />
<br />
For some laptops, the option -S to hdparm can also be relevant (sets the spindown time for the drive). Note that all these options can also be configured using the [[Laptop_Mode_Tools | laptop-mode tools]]. This will allow you to set a high value when on AC and a lower value when you are running on battery power.<br />
<br />
=== Using a script and an udev rule ===<br />
Since systemd users can suspend and hibernate through {{ic|systemctl suspend}} or {{ic|systemctl hibernate}} and handle acpi events with {{ic|/etc/systemd/logind.conf}}, it might be interesting to remove pm-utils and acpid. Now, there's just one thing systemd can't do (at this time of writing): powermanagement, depending on whether the system is running on AC or battery. To fill this gap, one can create a single udev rule that launches a script when the laptop is unplugged and plugged:<br />
{{hc|/etc/udev/rules.d/powersave|2=<nowiki><br />
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"<br />
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"<br />
</nowiki>}}<br />
{{Note|One can use the same script that pm-powersave uses. You just have to make it executable and place it somewhere else (for example, /usr/bin).}}<br />
Examples of powersave scripts can be found here: [https://bbs.archlinux.org/viewtopic.php?pid=1046075#p1046075] (or in aur: {{AUR|powerdown}}), here: [https://github.com/Unia/powersave] and there: [https://aur.archlinux.org/packages/powerconf].<br />
<br />
The above udev rule should work as expected, but if your power settings aren't updated after a suspend or hibernate cycle, you should add a script in {{ic|/usr/lib/systemd/system-sleep/}} with the following contents:<br />
{{hc|/usr/lib/systemd/system-sleep/00powersave|<nowiki><br />
#!/bin/sh<br />
<br />
case $1 in<br />
pre) /path/to/your/script false ;;<br />
post) <br />
if cat /sys/class/power_supply/AC0/online | grep 0 > /dev/null 2>&1<br />
then<br />
/path/to/your/script true <br />
else<br />
/path/to/your/script false<br />
fi<br />
;;<br />
esac'<br />
exit 0<br />
</nowiki>}}<br />
<br />
Don't forget to make it executable!<br />
{{Note|Be aware that AC0 may be different for your laptop, change it if that is the case.}}<br />
<br />
Now you don't need pm-utils anymore. Depending on your configuration, it may be a dependency of some other package. If you wish to remove it anyway, run {{ic|pacman -Rdd pm-utils}}.<br />
<br />
== Screen brightness ==<br />
{{Merge|Backlight}}<br />
To change your display brightness, first check {{ic|/sys/class/backlight}}:<br />
<br />
# ls /sys/class/backlight/<br />
intel_backlight<br />
<br />
So this particular backlight is managed by an Intel card. Keep in mind that different cards might manage this differently! It is called ''acpi_video0'' on an ATI card, for instance.<br />
<br />
Check current value:<br />
<br />
$ cat /sys/class/backlight/intel_backlight/brightness<br />
<br />
In this case, the backlight managed by echoing values into {{ic|/sys/class/backlight/intel_backlight/brightness}}:<br />
<br />
# echo "400" > /sys/class/backlight/intel_backlight/brightness<br />
<br />
If you get a response along the lines of "invalid argument" then you didn't honor the maximum brightness. Obviously you cannot go any higher than your screens maximum brightness. The values for maximum brightness and brightness in general vary wildly among cards. This Intel card, for instance, can go up to 976 while the ATI can go up 9. Obviously these values don't say anything about maximum effective brightness.<br />
<br />
Check your maximum brightness: <br />
<br />
$ cat /sys/class/backlight/intel_backlight/max_brightness<br />
<br />
If your laptop's Fn keys don't work or Gnome/KDE fail to correctly set the brightness using their power daemons, you can try appending '''acpi_backlight=vendor''' to your kernel line in your bootloader.<br />
<br />
=== setpci fallback method ===<br />
{{Warning| The setpci command edits hardware parameters. Use with caution.}}<br />
On some laptops, the above methods do not actually change screen brightness. If this is the case for your laptop, first find the domain and bus using lspci:<br />
$ lspci<br />
(...)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)<br />
(...)<br />
Now use setpci to change the value at slot F4 to, say, a0:<br />
# setpci -s 00:02.0 f4.b=a0<br />
The {{ic|.b}} indicates a byte value; this runs in hexadecimal from {{ic|00}} to {{ic|ff}}. '''ff''' Is usually the brightest, although this may be reversed. See [https://bbs.archlinux.org/viewtopic.php?pid=1088825#p1088825 here] for a script which can be used with brightness keys.<br />
<br />
== Touchpad ==<br />
To get your touchpad working properly, see the [[Touchpad Synaptics]] page. Note that your laptop may have an ALPS touchpad (such as the DELL Inspiron 6000), and not a Synaptics touchpad. In either case, see the link above.<br />
<br />
== Hard disk shock protection ==<br />
There are several laptops from different vendors featuring shock protection capabilities. As manufacturers have refused to support open source development of the required software components so far, Linux support for shock protection varies considerably between different hardware implementations.<br />
<br />
Currently, two projects, named HDAPS and hpfall, support this kind of protection.<br />
HDAPS is for IBM/Lenovo Thinkpads and hpfall for HP/Compaq laptops<br />
<br />
Just Check [[HDAPS|Hard Disk Active Protection System]].<br />
{{AUR|hpfall}} can be installed from the [[AUR]].<br />
<br />
== Network Time Syncing ==<br />
For a laptop, it may be a good idea to use [[Chrony]] as an alternative to [[NTPd]] to sync your clock over the network. Chrony is designed to work well even on systems with no permanent network connection (such as laptops), and is capable of much faster time synchronisation than standard ntp. Chrony has several advantages when used in systems running on virtual machines, such as a larger range for frequency correction to help correct quickly drifting clocks, and better response to rapid changes in the clock frequency. It also has a smaller memory footprint and no unnecessary process wakeups, improving power efficiency.</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Laptop&diff=247904Laptop2013-02-19T16:03:43Z<p>Eruditorum: /* Battery State Monitoring Utilities */</p>
<hr />
<div>[[Category:Laptops]]<br />
[[cs:Laptop]]<br />
[[es:Laptop]]<br />
[[it:Laptop]]<br />
[[ru:Laptop]]<br />
[[zh-CN:Laptop]]<br />
== Setting Up For Laptops ==<br />
This page should contain links to pages needed for configuring a laptop for the best experience. Setting up a laptop is in many ways the same as setting up a desktop. However, there are a few key differences. When setting up a laptop with Arch Linux, the following points should be taken into consideration:<br />
<br />
* [[#Power Management]] Power Management for laptops refers to optimizing the system to last as long as possible on a single battery charge. This can be accomplished by a variety of tweaks.<br />
** [[#Suspend and Hibernate]] : the operating system can be manually suspended either to memory or to disk, allowing for an (almost) complete shutdown of other hardware.<br />
** Hard drive spindown : the system can be configured to automatically turn off the hard disk after a specified interval of inactivity.<br />
** Screen shut off : the laptop screen can be configured to automatically turn off after a specified interval of inactivity (not just blanked with a screensaver but completely shut off).<br />
** CPU frequency scaling : the processor(s) can be configured to automatically step down to a lower frequency at lower loads.<br />
<br />
* [[#Screen brightness]]. How do I manage screen brightness?<br />
* Network and wireless setup is described in [[Wireless Setup]].<br />
* Media buttons can be configured as described in [[Extra Keyboard Keys]].<br />
* [[#Touchpad]] sensitivity, acceleration, button function and scroll borders can be configured for some (Synaptics or Alps) touchpads.<br />
* [[#Hard disk shock protection]] <br />
<br />
All of these points are important to take into consideration when getting a laptop set up the way you like. Fortunately, Arch Linux provides all the tools and programs necessary to take complete control of your laptop. These programs and utilities are highlighted below, with appropriate tips tutorials.<br />
<br />
Note: the following links may be useful:<br />
<br />
* [http://www.linux-on-laptops.com/ http://www.linux-on-laptops.com/]<br />
* [http://www.linlap.com/ http://www.linlap.com/]<br />
<br />
== Power Management ==<br />
Power management is very important for anyone who wishes to make good use of their battery capacity. The following tools and programs help to increase battery life and keep your laptop cool and quiet.<br />
<br />
== Battery State ==<br />
<br />
=== Udev events ===<br />
<br />
When battery charges/discharges it sends events which can be handled by udev. Example of how it could be used is presented below.<br />
<br />
=== Low charge action ===<br />
<br />
By default, system won't do anything if your laptop's battery is going to discharge. In order not to lose all unsaved work this example udev rule could be used:<br />
{{hc|/etc/udev/rules.d/lowbat.rules|<nowiki><br />
## SLEEP IF BATTERY IS LOW<br />
SUBSYSTEM=="power_supply", ATTR{status}=="Discharging", ATTR{capacity}=="2", RUN+="/usr/bin/systemctl suspend"<br />
</nowiki>}}<br />
Likewise, the rule can be customized to perform other action on different status.<br />
<br />
=== Utilities ===<br />
<br />
Battery state can be read using ACPI utilities from the terminal. ACPI command line utilities are provided via the {{Pkg|acpi}} package. A simple battery monitor that sits in the system tray is {{AUR|batterymon-clone}} which can be found in the [[Arch User Repository|AUR]].<br />
<br />
{{Tip|More information can be found in the [[ACPI modules]] article.}}<br />
<br />
* {{pkg|batti}} is a simple battery monitor for the system tray, similar to batterymon-clone. Unlike the latter {{ic|batti}} uses UPower, and if that is missing DeviceKit.Power, for it's power information.<br />
<br />
=== Suspend and Hibernate ===<br />
<br />
Manually suspending the operating system, either to memory (standby) or to disk (hibernate) sometimes provides the most efficient way to optimize battery life, depending on the usage pattern of the laptop. While there is relatively straightforward support in the linux kernel to support these operations, typically some adjustments have to be made before initiating these operations (typically due to problematic drivers, modules or hardware). The following tools provide wrappers around the kernel interfaces to suspend/resume :<br />
<br />
* [[Acpid]]<br />
* [[Pm-utils]]<br />
* [[Uswsusp]]<br />
<br />
which are described in more detail in [[Suspend]].<br />
<br />
===Power saving===<br />
<br />
See the main article, [[power saving]].<br />
<br />
==== Automatic tweaks for battery life ====<br />
<br />
As opposed to manually initiated actions like suspend/hibernate, a number of tweaks can be made to prolong the battery life of the laptop under low/idle usage.<br />
<br />
* [[CPU Frequency Scaling]] is a technology used primarily by notebooks which enables the OS to scale the CPU frequency up or down, depending on the current system load and/or power scheme.<br />
* [[Laptop Mode Tools]] provides a comprehensive suite of tools to tweak a large number of power saving settings through well documented configuration files.<br />
* [[Powertop]] is a handy utility from Intel that displays which hardware/processes are using the most power on your system, and provides instructions on how to stop or remove power-wasting services. Works great for mobile Intel CPUs; provides the current CPU state and suggestions for power saving. Also works on AMD systems, but does not provide as much information about the CPU state.<br />
<br />
The following options are specific to certain laptop types:<br />
<br />
* [[Asus_G1#The_Lapsus_daemon_.26_KDE_applet|Lapsus]] is a set of programs providing easy access to many features of various laptops. It currently supports most features provided by asus-laptop kernel module from ACPI4Asus project, such as additional LEDs, hotkeys, backlight control etc. It also has support for some IBM laptops features provided by IBM ThinkPad ACPI Extras Driver and NVRAM device.<br />
* Battery tweaks for Thinkpads can be found in the [[tp_smapi]] article.<br />
* [[TLP]] for Thinkpads is a set of scripts, which set many powersaving options according to the current Powersource. [[TLP]] is intended to be used on Thinkpads, but most settings should work on other laptops too.<br />
<br />
====PCI-e ASPM====<br />
On some laptops, powertop suggests enabling the {{ic|CONFIG_PCIEASPM}} kernel option. It can be found under "Bus options (PCI etc.)"->"PCI Express ASPM support". This option is marked as experimental in the current kernel (2.6.35) and allows the PCI-e links to enter a power saving state. <br />
<br />
According to [http://www.lesswatts.org/projects/devices-power-management/pcie.php], this option might degrade performance a bit, but on an Acer 3820TG laptop, it can reduce power consumption by about one third or even more.<br />
<br />
More experience with this setting would be appreciated, so please share them [https://bbs.archlinux.org/viewtopic.php?id=107173 here]!<br />
<br />
It seems like the option is going to be enabled by default in kernel 2.6.36; if so, the information here will be obsolete soon. However, if your system should be able to make use of this power management feature but you are receiving messages like like the following (check {{ic|/var/log/everything.log*}}):<br />
<br />
disabling ASPM on pre-1.1 PCI-e device. You can enable it with 'pcie_aspm=force'<br />
<br />
then add {{ic|pcie_aspm<nowiki>=</nowiki>force}} to your kernel command line.<br />
<br />
==== Granola ====<br />
<br />
{{Out of date|Arch Linux has moved to systemd, so rc.conf is no longer used.}}<br />
<br />
[https://aur.archlinux.org/packages.php?ID=36841 Granola] is a daemon that monitors the cpu usage and uses the cpufreq-userspace module to lessen power usage without any noticeable difference in performance.<br />
To use it, first install from the AUR:[https://aur.archlinux.org/packages.php?ID=36841], the default settings will work for most setups.<br />
You will need to load the cpufreq_userspace module, as well as the cpufreq scaling governor for your CPU at startup.<br />
Edit {{ic|/etc/rc.conf}}:<br />
For most generic cpus:<br />
<br />
MODULES=( ... cpufreq_userspace acpi-cpufreq ... )<br />
<br />
For Intel Atom or Pentium 4 cpus:<br />
<br />
MODULES=( ... cpufreq_userspace p4_clockmod ... )<br />
<br />
Then add Granola to the DAEMONS array:<br />
<br />
DAEMONS=( ... granola ... )<br />
<br />
and reboot. <br />
<br />
To test if it worked, run:<br />
<br />
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq<br />
#OR<br />
cpufreq-info #if you have cpufreq-utils installed<br />
<br />
and check that the cpu frequency is below maximum.<br />
<br />
====WLAN-device====<br />
When often en route working with your Notebook without WLAN-Access around, it might be expedient to add a little script to your system startup that automatically turns off your WLAN-Hardware to keep it from searching for Access Points and wasting power on this, when not connected:<br />
<br />
#!/bin/bash<br />
<br />
essid="`iwconfig wlan0 | grep ESSID | awk {'print $4'}`"<br />
if [ "$essid" == "ESSID:off/any" ] ; then<br />
sudo iwconfig wlan0 txpower off<br />
fi<br />
[edit, if wlan0 is not your WLAN-device]<br />
<br />
Start the script according to your DE/WM options by '(sleep xx && /path/to/script)' depending on how long it usually takes to connect to your Access Point, 60 seconds are a good default value. It will check if you're connected, turning off the device if not.<br />
sudo iwconfig wlan0 txpower on<br />
will bring it back up, as, of course, a reboot will.<br />
<br />
==== Disk-related tweaks ====<br />
Disable file access time: every time you access (read) a file the filesystem writes an access time to the file metadata. You can disable this on individual files by using the chattr command, or you can enable it on an entire disk by setting the ''noatime'' option in your fstab, as follows:<br />
<br />
/dev/sda1 / ext3 defaults,noatime 1 2<br />
<br />
[http://www.faqs.org/docs/securing/chap6sec73.html Source]<br />
<br />
{{Note|<br />
* Disabling {{ic|atime}} causes troubles with [[Mutt|mutt]] and other applications that make use of file timestamps. Consider compromising between performance and compatibility by using mount option {{ic|relatime}} instead, or look into [http://wiki.mutt.org/?MaildirFormat mutt work-around for noatime].<br />
* {{ic|relatime}} is used by default as of kernel 2.6.30, so unless you're using an older kernel, there should be no need to edit fstab.<br />
}}<br />
<br />
To allow the CD/DVD rom to spin down after a while using [[udisks]]:<br />
<br />
# udisks --inhibit-polling /dev/sr0<br />
<br />
==== More tweaks ====<br />
These are some generic suggestions that will work with most laptops.<br />
<br />
Add the following to {{ic|/etc/modprobe.d/modprobe.conf}}:<br />
<br />
options usbcore autosuspend=1<br />
<br />
Add the following to {{ic|/etc/sysctl.conf}}<br />
<br />
vm.dirty_writeback_centisecs=1500<br />
vm.laptop_mode=5<br />
<br />
{{Note|''laptop-mode-tools'' automatically rewrites these values based on the values {{Ic|LM_BATT_MAX_LOST_WORK_SECONDS}}, {{Ic|LM_AC_MAX_LOST_WORK_SECONDS}} (both multiplied by 100) resp. {{Ic|LM_SECONDS_BEFORE_SYNC}}, which are set in {{ic|/etc/laptop-mode/laptop-mode.conf}}. However, that only happens if the three "Enable laptop mode" variables in the same file are set accordingly — left to 0, it resets the values to kernel defaults (500 / 0) for the corresponding scenario regardless of {{ic|/etc/sysctl.conf}}.}}<br />
<br />
{{accuracy|reason=This belongs in a udev rule, not rc.local.}}<br />
<br />
Add the following to {{ic|/etc/rc.local}} (and make sure it gets executed at boot time)<br />
<br />
/usr/sbin/iwpriv your_wireless_interface set_power 5<br />
<br />
Source: [http://www.nervous.it/2007/11/linux-dell-xps-m1330/ here]<br />
<br />
==== Hard drive spin down problem ====<br />
Documented [https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 here]<br />
<br />
To prevent your laptop hard drive from spinning down too often (result of too aggressive APM defaults) do the following:<br />
<br />
Add the following to {{ic|/etc/rc.local}}<br />
<br />
hdparm -B 254 /dev/sdX ''where X is your hard drive device''<br />
<br />
You can also set it to 255 to completely disable spinning down. You may wish to set a lower value if you move your laptop around as lower values park the heads more often and reduce the chance of damage to your hard disk while it is being moved. If you do not move your laptop at all when you are using it, then 255 or 254 is probably best. If you do, then you might want to try a lower value. A value like 128 might be a good middle-ground.<br />
<br />
Add the following to {{ic|/etc/pm/sleep.d/50-hdparm_pm}}<br />
<br />
#!/bin/sh<br />
<br />
if [ -n "$1" ] && ([ "$1" = "resume" ] || [ "$1" = "thaw" ]); then<br />
hdparm -B 254 /dev/your-hard-drive > /dev/null<br />
fi<br />
<br />
and run ''chmod +x /etc/pm/sleep.d/50-hdparm_pm'' to make sure it resets after suspend. Again, you can change the value 254 as you see fit.<br />
<br />
Now the APM level should be set for your hard drive.<br />
<br />
For some laptops, the option -S to hdparm can also be relevant (sets the spindown time for the drive). Note that all these options can also be configured using the [[Laptop_Mode_Tools | laptop-mode tools]]. This will allow you to set a high value when on AC and a lower value when you are running on battery power.<br />
<br />
=== Using a script and an udev rule ===<br />
Since systemd users can suspend and hibernate through {{ic|systemctl suspend}} or {{ic|systemctl hibernate}} and handle acpi events with {{ic|/etc/systemd/logind.conf}}, it might be interesting to remove pm-utils and acpid. Now, there's just one thing systemd can't do (at this time of writing): powermanagement, depending on whether the system is running on AC or battery. To fill this gap, one can create a single udev rule that launches a script when the laptop is unplugged and plugged:<br />
{{hc|/etc/udev/rules.d/powersave|2=<nowiki><br />
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"<br />
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"<br />
</nowiki>}}<br />
{{Note|One can use the same script that pm-powersave uses. You just have to make it executable and place it somewhere else (for example, /usr/bin).}}<br />
Examples of powersave scripts can be found here: [https://bbs.archlinux.org/viewtopic.php?pid=1046075#p1046075] (or in aur: {{AUR|powerdown}}), here: [https://github.com/Unia/powersave] and there: [https://aur.archlinux.org/packages/powerconf].<br />
<br />
The above udev rule should work as expected, but if your power settings aren't updated after a suspend or hibernate cycle, you should add a script in {{ic|/usr/lib/systemd/system-sleep/}} with the following contents:<br />
{{hc|/usr/lib/systemd/system-sleep/00powersave|<nowiki><br />
#!/bin/sh<br />
<br />
case $1 in<br />
pre) /path/to/your/script false ;;<br />
post) <br />
if cat /sys/class/power_supply/AC0/online | grep 0 > /dev/null 2>&1<br />
then<br />
/path/to/your/script true <br />
else<br />
/path/to/your/script false<br />
fi<br />
;;<br />
esac'<br />
exit 0<br />
</nowiki>}}<br />
<br />
Don't forget to make it executable!<br />
{{Note|Be aware that AC0 may be different for your laptop, change it if that is the case.}}<br />
<br />
Now you don't need pm-utils anymore. Depending on your configuration, it may be a dependency of some other package. If you wish to remove it anyway, run {{ic|pacman -Rdd pm-utils}}.<br />
<br />
== Screen brightness ==<br />
{{Merge|Backlight}}<br />
To change your display brightness, first check {{ic|/sys/class/backlight}}:<br />
<br />
# ls /sys/class/backlight/<br />
intel_backlight<br />
<br />
So this particular backlight is managed by an Intel card. Keep in mind that different cards might manage this differently! It is called ''acpi_video0'' on an ATI card, for instance.<br />
<br />
Check current value:<br />
<br />
$ cat /sys/class/backlight/intel_backlight/brightness<br />
<br />
In this case, the backlight managed by echoing values into {{ic|/sys/class/backlight/intel_backlight/brightness}}:<br />
<br />
# echo "400" > /sys/class/backlight/intel_backlight/brightness<br />
<br />
If you get a response along the lines of "invalid argument" then you didn't honor the maximum brightness. Obviously you cannot go any higher than your screens maximum brightness. The values for maximum brightness and brightness in general vary wildly among cards. This Intel card, for instance, can go up to 976 while the ATI can go up 9. Obviously these values don't say anything about maximum effective brightness.<br />
<br />
Check your maximum brightness: <br />
<br />
$ cat /sys/class/backlight/intel_backlight/max_brightness<br />
<br />
If your laptop's Fn keys don't work or Gnome/KDE fail to correctly set the brightness using their power daemons, you can try appending '''acpi_backlight=vendor''' to your kernel line in your bootloader.<br />
<br />
=== setpci fallback method ===<br />
{{Warning| The setpci command edits hardware parameters. Use with caution.}}<br />
On some laptops, the above methods do not actually change screen brightness. If this is the case for your laptop, first find the domain and bus using lspci:<br />
$ lspci<br />
(...)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)<br />
(...)<br />
Now use setpci to change the value at slot F4 to, say, a0:<br />
# setpci -s 00:02.0 f4.b=a0<br />
The {{ic|.b}} indicates a byte value; this runs in hexadecimal from {{ic|00}} to {{ic|ff}}. '''ff''' Is usually the brightest, although this may be reversed. See [https://bbs.archlinux.org/viewtopic.php?pid=1088825#p1088825 here] for a script which can be used with brightness keys.<br />
<br />
== Touchpad ==<br />
To get your touchpad working properly, see the [[Touchpad Synaptics]] page. Note that your laptop may have an ALPS touchpad (such as the DELL Inspiron 6000), and not a Synaptics touchpad. In either case, see the link above.<br />
<br />
== Hard disk shock protection ==<br />
There are several laptops from different vendors featuring shock protection capabilities. As manufacturers have refused to support open source development of the required software components so far, Linux support for shock protection varies considerably between different hardware implementations.<br />
<br />
Currently, two projects, named HDAPS and hpfall, support this kind of protection.<br />
HDAPS is for IBM/Lenovo Thinkpads and hpfall for HP/Compaq laptops<br />
<br />
Just Check [[HDAPS|Hard Disk Active Protection System]].<br />
{{AUR|hpfall}} can be installed from the [[AUR]].<br />
<br />
== Network Time Syncing ==<br />
For a laptop, it may be a good idea to use [[Chrony]] as an alternative to [[NTPd]] to sync your clock over the network. Chrony is designed to work well even on systems with no permanent network connection (such as laptops), and is capable of much faster time synchronisation than standard ntp. Chrony has several advantages when used in systems running on virtual machines, such as a larger range for frequency correction to help correct quickly drifting clocks, and better response to rapid changes in the clock frequency. It also has a smaller memory footprint and no unnecessary process wakeups, improving power efficiency.</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Laptop&diff=247903Laptop2013-02-19T15:38:10Z<p>Eruditorum: /* Using a script and an udev rule */</p>
<hr />
<div>[[Category:Laptops]]<br />
[[cs:Laptop]]<br />
[[es:Laptop]]<br />
[[it:Laptop]]<br />
[[ru:Laptop]]<br />
[[zh-CN:Laptop]]<br />
== Setting Up For Laptops ==<br />
This page should contain links to pages needed for configuring a laptop for the best experience. Setting up a laptop is in many ways the same as setting up a desktop. However, there are a few key differences. When setting up a laptop with Arch Linux, the following points should be taken into consideration:<br />
<br />
* [[#Power Management]] Power Management for laptops refers to optimizing the system to last as long as possible on a single battery charge. This can be accomplished by a variety of tweaks.<br />
** [[#Suspend and Hibernate]] : the operating system can be manually suspended either to memory or to disk, allowing for an (almost) complete shutdown of other hardware.<br />
** Hard drive spindown : the system can be configured to automatically turn off the hard disk after a specified interval of inactivity.<br />
** Screen shut off : the laptop screen can be configured to automatically turn off after a specified interval of inactivity (not just blanked with a screensaver but completely shut off).<br />
** CPU frequency scaling : the processor(s) can be configured to automatically step down to a lower frequency at lower loads.<br />
<br />
* [[#Screen brightness]]. How do I manage screen brightness?<br />
* Network and wireless setup is described in [[Wireless Setup]].<br />
* Media buttons can be configured as described in [[Extra Keyboard Keys]].<br />
* [[#Touchpad]] sensitivity, acceleration, button function and scroll borders can be configured for some (Synaptics or Alps) touchpads.<br />
* [[#Hard disk shock protection]] <br />
<br />
All of these points are important to take into consideration when getting a laptop set up the way you like. Fortunately, Arch Linux provides all the tools and programs necessary to take complete control of your laptop. These programs and utilities are highlighted below, with appropriate tips tutorials.<br />
<br />
Note: the following links may be useful:<br />
<br />
* [http://www.linux-on-laptops.com/ http://www.linux-on-laptops.com/]<br />
* [http://www.linlap.com/ http://www.linlap.com/]<br />
<br />
== Power Management ==<br />
Power management is very important for anyone who wishes to make good use of their battery capacity. The following tools and programs help to increase battery life and keep your laptop cool and quiet.<br />
<br />
=== Battery State Monitoring Utilities ===<br />
<br />
Battery state can be read using ACPI utilities from the terminal. ACPI command line utilities are provided via the {{Pkg|acpi}} package. A simple battery monitor that sits in the system tray is {{AUR|batterymon-clone}} which can be found in the [[Arch User Repository|AUR]].<br />
<br />
{{Tip|More information can be found in the [[ACPI modules]] article.}}<br />
<br />
* {{pkg|batti}} is a simple battery monitor for the system tray, similar to batterymon-clone. Unlike the latter {{ic|batti}} uses UPower, and if that is missing DeviceKit.Power, for it's power information.<br />
<br />
=== Suspend and Hibernate ===<br />
<br />
Manually suspending the operating system, either to memory (standby) or to disk (hibernate) sometimes provides the most efficient way to optimize battery life, depending on the usage pattern of the laptop. While there is relatively straightforward support in the linux kernel to support these operations, typically some adjustments have to be made before initiating these operations (typically due to problematic drivers, modules or hardware). The following tools provide wrappers around the kernel interfaces to suspend/resume :<br />
<br />
* [[Acpid]]<br />
* [[Pm-utils]]<br />
* [[Uswsusp]]<br />
<br />
which are described in more detail in [[Suspend]].<br />
<br />
===Power saving===<br />
<br />
See the main article, [[power saving]].<br />
<br />
==== Automatic tweaks for battery life ====<br />
<br />
As opposed to manually initiated actions like suspend/hibernate, a number of tweaks can be made to prolong the battery life of the laptop under low/idle usage.<br />
<br />
* [[CPU Frequency Scaling]] is a technology used primarily by notebooks which enables the OS to scale the CPU frequency up or down, depending on the current system load and/or power scheme.<br />
* [[Laptop Mode Tools]] provides a comprehensive suite of tools to tweak a large number of power saving settings through well documented configuration files.<br />
* [[Powertop]] is a handy utility from Intel that displays which hardware/processes are using the most power on your system, and provides instructions on how to stop or remove power-wasting services. Works great for mobile Intel CPUs; provides the current CPU state and suggestions for power saving. Also works on AMD systems, but does not provide as much information about the CPU state.<br />
<br />
The following options are specific to certain laptop types:<br />
<br />
* [[Asus_G1#The_Lapsus_daemon_.26_KDE_applet|Lapsus]] is a set of programs providing easy access to many features of various laptops. It currently supports most features provided by asus-laptop kernel module from ACPI4Asus project, such as additional LEDs, hotkeys, backlight control etc. It also has support for some IBM laptops features provided by IBM ThinkPad ACPI Extras Driver and NVRAM device.<br />
* Battery tweaks for Thinkpads can be found in the [[tp_smapi]] article.<br />
* [[TLP]] for Thinkpads is a set of scripts, which set many powersaving options according to the current Powersource. [[TLP]] is intended to be used on Thinkpads, but most settings should work on other laptops too.<br />
<br />
====PCI-e ASPM====<br />
On some laptops, powertop suggests enabling the {{ic|CONFIG_PCIEASPM}} kernel option. It can be found under "Bus options (PCI etc.)"->"PCI Express ASPM support". This option is marked as experimental in the current kernel (2.6.35) and allows the PCI-e links to enter a power saving state. <br />
<br />
According to [http://www.lesswatts.org/projects/devices-power-management/pcie.php], this option might degrade performance a bit, but on an Acer 3820TG laptop, it can reduce power consumption by about one third or even more.<br />
<br />
More experience with this setting would be appreciated, so please share them [https://bbs.archlinux.org/viewtopic.php?id=107173 here]!<br />
<br />
It seems like the option is going to be enabled by default in kernel 2.6.36; if so, the information here will be obsolete soon. However, if your system should be able to make use of this power management feature but you are receiving messages like like the following (check {{ic|/var/log/everything.log*}}):<br />
<br />
disabling ASPM on pre-1.1 PCI-e device. You can enable it with 'pcie_aspm=force'<br />
<br />
then add {{ic|pcie_aspm<nowiki>=</nowiki>force}} to your kernel command line.<br />
<br />
==== Granola ====<br />
<br />
{{Out of date|Arch Linux has moved to systemd, so rc.conf is no longer used.}}<br />
<br />
[https://aur.archlinux.org/packages.php?ID=36841 Granola] is a daemon that monitors the cpu usage and uses the cpufreq-userspace module to lessen power usage without any noticeable difference in performance.<br />
To use it, first install from the AUR:[https://aur.archlinux.org/packages.php?ID=36841], the default settings will work for most setups.<br />
You will need to load the cpufreq_userspace module, as well as the cpufreq scaling governor for your CPU at startup.<br />
Edit {{ic|/etc/rc.conf}}:<br />
For most generic cpus:<br />
<br />
MODULES=( ... cpufreq_userspace acpi-cpufreq ... )<br />
<br />
For Intel Atom or Pentium 4 cpus:<br />
<br />
MODULES=( ... cpufreq_userspace p4_clockmod ... )<br />
<br />
Then add Granola to the DAEMONS array:<br />
<br />
DAEMONS=( ... granola ... )<br />
<br />
and reboot. <br />
<br />
To test if it worked, run:<br />
<br />
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq<br />
#OR<br />
cpufreq-info #if you have cpufreq-utils installed<br />
<br />
and check that the cpu frequency is below maximum.<br />
<br />
====WLAN-device====<br />
When often en route working with your Notebook without WLAN-Access around, it might be expedient to add a little script to your system startup that automatically turns off your WLAN-Hardware to keep it from searching for Access Points and wasting power on this, when not connected:<br />
<br />
#!/bin/bash<br />
<br />
essid="`iwconfig wlan0 | grep ESSID | awk {'print $4'}`"<br />
if [ "$essid" == "ESSID:off/any" ] ; then<br />
sudo iwconfig wlan0 txpower off<br />
fi<br />
[edit, if wlan0 is not your WLAN-device]<br />
<br />
Start the script according to your DE/WM options by '(sleep xx && /path/to/script)' depending on how long it usually takes to connect to your Access Point, 60 seconds are a good default value. It will check if you're connected, turning off the device if not.<br />
sudo iwconfig wlan0 txpower on<br />
will bring it back up, as, of course, a reboot will.<br />
<br />
==== Disk-related tweaks ====<br />
Disable file access time: every time you access (read) a file the filesystem writes an access time to the file metadata. You can disable this on individual files by using the chattr command, or you can enable it on an entire disk by setting the ''noatime'' option in your fstab, as follows:<br />
<br />
/dev/sda1 / ext3 defaults,noatime 1 2<br />
<br />
[http://www.faqs.org/docs/securing/chap6sec73.html Source]<br />
<br />
{{Note|<br />
* Disabling {{ic|atime}} causes troubles with [[Mutt|mutt]] and other applications that make use of file timestamps. Consider compromising between performance and compatibility by using mount option {{ic|relatime}} instead, or look into [http://wiki.mutt.org/?MaildirFormat mutt work-around for noatime].<br />
* {{ic|relatime}} is used by default as of kernel 2.6.30, so unless you're using an older kernel, there should be no need to edit fstab.<br />
}}<br />
<br />
To allow the CD/DVD rom to spin down after a while using [[udisks]]:<br />
<br />
# udisks --inhibit-polling /dev/sr0<br />
<br />
==== More tweaks ====<br />
These are some generic suggestions that will work with most laptops.<br />
<br />
Add the following to {{ic|/etc/modprobe.d/modprobe.conf}}:<br />
<br />
options usbcore autosuspend=1<br />
<br />
Add the following to {{ic|/etc/sysctl.conf}}<br />
<br />
vm.dirty_writeback_centisecs=1500<br />
vm.laptop_mode=5<br />
<br />
{{Note|''laptop-mode-tools'' automatically rewrites these values based on the values {{Ic|LM_BATT_MAX_LOST_WORK_SECONDS}}, {{Ic|LM_AC_MAX_LOST_WORK_SECONDS}} (both multiplied by 100) resp. {{Ic|LM_SECONDS_BEFORE_SYNC}}, which are set in {{ic|/etc/laptop-mode/laptop-mode.conf}}. However, that only happens if the three "Enable laptop mode" variables in the same file are set accordingly — left to 0, it resets the values to kernel defaults (500 / 0) for the corresponding scenario regardless of {{ic|/etc/sysctl.conf}}.}}<br />
<br />
{{accuracy|reason=This belongs in a udev rule, not rc.local.}}<br />
<br />
Add the following to {{ic|/etc/rc.local}} (and make sure it gets executed at boot time)<br />
<br />
/usr/sbin/iwpriv your_wireless_interface set_power 5<br />
<br />
Source: [http://www.nervous.it/2007/11/linux-dell-xps-m1330/ here]<br />
<br />
==== Hard drive spin down problem ====<br />
Documented [https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 here]<br />
<br />
To prevent your laptop hard drive from spinning down too often (result of too aggressive APM defaults) do the following:<br />
<br />
Add the following to {{ic|/etc/rc.local}}<br />
<br />
hdparm -B 254 /dev/sdX ''where X is your hard drive device''<br />
<br />
You can also set it to 255 to completely disable spinning down. You may wish to set a lower value if you move your laptop around as lower values park the heads more often and reduce the chance of damage to your hard disk while it is being moved. If you do not move your laptop at all when you are using it, then 255 or 254 is probably best. If you do, then you might want to try a lower value. A value like 128 might be a good middle-ground.<br />
<br />
Add the following to {{ic|/etc/pm/sleep.d/50-hdparm_pm}}<br />
<br />
#!/bin/sh<br />
<br />
if [ -n "$1" ] && ([ "$1" = "resume" ] || [ "$1" = "thaw" ]); then<br />
hdparm -B 254 /dev/your-hard-drive > /dev/null<br />
fi<br />
<br />
and run ''chmod +x /etc/pm/sleep.d/50-hdparm_pm'' to make sure it resets after suspend. Again, you can change the value 254 as you see fit.<br />
<br />
Now the APM level should be set for your hard drive.<br />
<br />
For some laptops, the option -S to hdparm can also be relevant (sets the spindown time for the drive). Note that all these options can also be configured using the [[Laptop_Mode_Tools | laptop-mode tools]]. This will allow you to set a high value when on AC and a lower value when you are running on battery power.<br />
<br />
=== Using a script and an udev rule ===<br />
Since systemd users can suspend and hibernate through {{ic|systemctl suspend}} or {{ic|systemctl hibernate}} and handle acpi events with {{ic|/etc/systemd/logind.conf}}, it might be interesting to remove pm-utils and acpid. Now, there's just one thing systemd can't do (at this time of writing): powermanagement, depending on whether the system is running on AC or battery. To fill this gap, one can create a single udev rule that launches a script when the laptop is unplugged and plugged:<br />
{{hc|/etc/udev/rules.d/powersave|2=<nowiki><br />
SUBSYSTEM=="power_supply", ATTR{online}=="0", RUN+="/path/to/your/script true"<br />
SUBSYSTEM=="power_supply", ATTR{online}=="1", RUN+="/path/to/your/script false"<br />
</nowiki>}}<br />
{{Note|One can use the same script that pm-powersave uses. You just have to make it executable and place it somewhere else (for example, /usr/bin).}}<br />
Examples of powersave scripts can be found here: [https://bbs.archlinux.org/viewtopic.php?pid=1046075#p1046075] (or in aur: {{AUR|powerdown}}), here: [https://github.com/Unia/powersave] and there: [https://aur.archlinux.org/packages/powerconf].<br />
<br />
The above udev rule should work as expected, but if your power settings aren't updated after a suspend or hibernate cycle, you should add a script in {{ic|/usr/lib/systemd/system-sleep/}} with the following contents:<br />
{{hc|/usr/lib/systemd/system-sleep/00powersave|<nowiki><br />
#!/bin/sh<br />
<br />
case $1 in<br />
pre) /path/to/your/script false ;;<br />
post) <br />
if cat /sys/class/power_supply/AC0/online | grep 0 > /dev/null 2>&1<br />
then<br />
/path/to/your/script true <br />
else<br />
/path/to/your/script false<br />
fi<br />
;;<br />
esac'<br />
exit 0<br />
</nowiki>}}<br />
<br />
Don't forget to make it executable!<br />
{{Note|Be aware that AC0 may be different for your laptop, change it if that is the case.}}<br />
<br />
Now you don't need pm-utils anymore. Depending on your configuration, it may be a dependency of some other package. If you wish to remove it anyway, run {{ic|pacman -Rdd pm-utils}}.<br />
<br />
== Screen brightness ==<br />
{{Merge|Backlight}}<br />
To change your display brightness, first check {{ic|/sys/class/backlight}}:<br />
<br />
# ls /sys/class/backlight/<br />
intel_backlight<br />
<br />
So this particular backlight is managed by an Intel card. Keep in mind that different cards might manage this differently! It is called ''acpi_video0'' on an ATI card, for instance.<br />
<br />
Check current value:<br />
<br />
$ cat /sys/class/backlight/intel_backlight/brightness<br />
<br />
In this case, the backlight managed by echoing values into {{ic|/sys/class/backlight/intel_backlight/brightness}}:<br />
<br />
# echo "400" > /sys/class/backlight/intel_backlight/brightness<br />
<br />
If you get a response along the lines of "invalid argument" then you didn't honor the maximum brightness. Obviously you cannot go any higher than your screens maximum brightness. The values for maximum brightness and brightness in general vary wildly among cards. This Intel card, for instance, can go up to 976 while the ATI can go up 9. Obviously these values don't say anything about maximum effective brightness.<br />
<br />
Check your maximum brightness: <br />
<br />
$ cat /sys/class/backlight/intel_backlight/max_brightness<br />
<br />
If your laptop's Fn keys don't work or Gnome/KDE fail to correctly set the brightness using their power daemons, you can try appending '''acpi_backlight=vendor''' to your kernel line in your bootloader.<br />
<br />
=== setpci fallback method ===<br />
{{Warning| The setpci command edits hardware parameters. Use with caution.}}<br />
On some laptops, the above methods do not actually change screen brightness. If this is the case for your laptop, first find the domain and bus using lspci:<br />
$ lspci<br />
(...)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)<br />
(...)<br />
Now use setpci to change the value at slot F4 to, say, a0:<br />
# setpci -s 00:02.0 f4.b=a0<br />
The {{ic|.b}} indicates a byte value; this runs in hexadecimal from {{ic|00}} to {{ic|ff}}. '''ff''' Is usually the brightest, although this may be reversed. See [https://bbs.archlinux.org/viewtopic.php?pid=1088825#p1088825 here] for a script which can be used with brightness keys.<br />
<br />
== Touchpad ==<br />
To get your touchpad working properly, see the [[Touchpad Synaptics]] page. Note that your laptop may have an ALPS touchpad (such as the DELL Inspiron 6000), and not a Synaptics touchpad. In either case, see the link above.<br />
<br />
== Hard disk shock protection ==<br />
There are several laptops from different vendors featuring shock protection capabilities. As manufacturers have refused to support open source development of the required software components so far, Linux support for shock protection varies considerably between different hardware implementations.<br />
<br />
Currently, two projects, named HDAPS and hpfall, support this kind of protection.<br />
HDAPS is for IBM/Lenovo Thinkpads and hpfall for HP/Compaq laptops<br />
<br />
Just Check [[HDAPS|Hard Disk Active Protection System]].<br />
{{AUR|hpfall}} can be installed from the [[AUR]].<br />
<br />
== Network Time Syncing ==<br />
For a laptop, it may be a good idea to use [[Chrony]] as an alternative to [[NTPd]] to sync your clock over the network. Chrony is designed to work well even on systems with no permanent network connection (such as laptops), and is capable of much faster time synchronisation than standard ntp. Chrony has several advantages when used in systems running on virtual machines, such as a larger range for frequency correction to help correct quickly drifting clocks, and better response to rapid changes in the clock frequency. It also has a smaller memory footprint and no unnecessary process wakeups, improving power efficiency.</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Laptop&diff=247902Laptop2013-02-19T15:36:21Z<p>Eruditorum: /* Using a script and an udev rule */</p>
<hr />
<div>[[Category:Laptops]]<br />
[[cs:Laptop]]<br />
[[es:Laptop]]<br />
[[it:Laptop]]<br />
[[ru:Laptop]]<br />
[[zh-CN:Laptop]]<br />
== Setting Up For Laptops ==<br />
This page should contain links to pages needed for configuring a laptop for the best experience. Setting up a laptop is in many ways the same as setting up a desktop. However, there are a few key differences. When setting up a laptop with Arch Linux, the following points should be taken into consideration:<br />
<br />
* [[#Power Management]] Power Management for laptops refers to optimizing the system to last as long as possible on a single battery charge. This can be accomplished by a variety of tweaks.<br />
** [[#Suspend and Hibernate]] : the operating system can be manually suspended either to memory or to disk, allowing for an (almost) complete shutdown of other hardware.<br />
** Hard drive spindown : the system can be configured to automatically turn off the hard disk after a specified interval of inactivity.<br />
** Screen shut off : the laptop screen can be configured to automatically turn off after a specified interval of inactivity (not just blanked with a screensaver but completely shut off).<br />
** CPU frequency scaling : the processor(s) can be configured to automatically step down to a lower frequency at lower loads.<br />
<br />
* [[#Screen brightness]]. How do I manage screen brightness?<br />
* Network and wireless setup is described in [[Wireless Setup]].<br />
* Media buttons can be configured as described in [[Extra Keyboard Keys]].<br />
* [[#Touchpad]] sensitivity, acceleration, button function and scroll borders can be configured for some (Synaptics or Alps) touchpads.<br />
* [[#Hard disk shock protection]] <br />
<br />
All of these points are important to take into consideration when getting a laptop set up the way you like. Fortunately, Arch Linux provides all the tools and programs necessary to take complete control of your laptop. These programs and utilities are highlighted below, with appropriate tips tutorials.<br />
<br />
Note: the following links may be useful:<br />
<br />
* [http://www.linux-on-laptops.com/ http://www.linux-on-laptops.com/]<br />
* [http://www.linlap.com/ http://www.linlap.com/]<br />
<br />
== Power Management ==<br />
Power management is very important for anyone who wishes to make good use of their battery capacity. The following tools and programs help to increase battery life and keep your laptop cool and quiet.<br />
<br />
=== Battery State Monitoring Utilities ===<br />
<br />
Battery state can be read using ACPI utilities from the terminal. ACPI command line utilities are provided via the {{Pkg|acpi}} package. A simple battery monitor that sits in the system tray is {{AUR|batterymon-clone}} which can be found in the [[Arch User Repository|AUR]].<br />
<br />
{{Tip|More information can be found in the [[ACPI modules]] article.}}<br />
<br />
* {{pkg|batti}} is a simple battery monitor for the system tray, similar to batterymon-clone. Unlike the latter {{ic|batti}} uses UPower, and if that is missing DeviceKit.Power, for it's power information.<br />
<br />
=== Suspend and Hibernate ===<br />
<br />
Manually suspending the operating system, either to memory (standby) or to disk (hibernate) sometimes provides the most efficient way to optimize battery life, depending on the usage pattern of the laptop. While there is relatively straightforward support in the linux kernel to support these operations, typically some adjustments have to be made before initiating these operations (typically due to problematic drivers, modules or hardware). The following tools provide wrappers around the kernel interfaces to suspend/resume :<br />
<br />
* [[Acpid]]<br />
* [[Pm-utils]]<br />
* [[Uswsusp]]<br />
<br />
which are described in more detail in [[Suspend]].<br />
<br />
===Power saving===<br />
<br />
See the main article, [[power saving]].<br />
<br />
==== Automatic tweaks for battery life ====<br />
<br />
As opposed to manually initiated actions like suspend/hibernate, a number of tweaks can be made to prolong the battery life of the laptop under low/idle usage.<br />
<br />
* [[CPU Frequency Scaling]] is a technology used primarily by notebooks which enables the OS to scale the CPU frequency up or down, depending on the current system load and/or power scheme.<br />
* [[Laptop Mode Tools]] provides a comprehensive suite of tools to tweak a large number of power saving settings through well documented configuration files.<br />
* [[Powertop]] is a handy utility from Intel that displays which hardware/processes are using the most power on your system, and provides instructions on how to stop or remove power-wasting services. Works great for mobile Intel CPUs; provides the current CPU state and suggestions for power saving. Also works on AMD systems, but does not provide as much information about the CPU state.<br />
<br />
The following options are specific to certain laptop types:<br />
<br />
* [[Asus_G1#The_Lapsus_daemon_.26_KDE_applet|Lapsus]] is a set of programs providing easy access to many features of various laptops. It currently supports most features provided by asus-laptop kernel module from ACPI4Asus project, such as additional LEDs, hotkeys, backlight control etc. It also has support for some IBM laptops features provided by IBM ThinkPad ACPI Extras Driver and NVRAM device.<br />
* Battery tweaks for Thinkpads can be found in the [[tp_smapi]] article.<br />
* [[TLP]] for Thinkpads is a set of scripts, which set many powersaving options according to the current Powersource. [[TLP]] is intended to be used on Thinkpads, but most settings should work on other laptops too.<br />
<br />
====PCI-e ASPM====<br />
On some laptops, powertop suggests enabling the {{ic|CONFIG_PCIEASPM}} kernel option. It can be found under "Bus options (PCI etc.)"->"PCI Express ASPM support". This option is marked as experimental in the current kernel (2.6.35) and allows the PCI-e links to enter a power saving state. <br />
<br />
According to [http://www.lesswatts.org/projects/devices-power-management/pcie.php], this option might degrade performance a bit, but on an Acer 3820TG laptop, it can reduce power consumption by about one third or even more.<br />
<br />
More experience with this setting would be appreciated, so please share them [https://bbs.archlinux.org/viewtopic.php?id=107173 here]!<br />
<br />
It seems like the option is going to be enabled by default in kernel 2.6.36; if so, the information here will be obsolete soon. However, if your system should be able to make use of this power management feature but you are receiving messages like like the following (check {{ic|/var/log/everything.log*}}):<br />
<br />
disabling ASPM on pre-1.1 PCI-e device. You can enable it with 'pcie_aspm=force'<br />
<br />
then add {{ic|pcie_aspm<nowiki>=</nowiki>force}} to your kernel command line.<br />
<br />
==== Granola ====<br />
<br />
{{Out of date|Arch Linux has moved to systemd, so rc.conf is no longer used.}}<br />
<br />
[https://aur.archlinux.org/packages.php?ID=36841 Granola] is a daemon that monitors the cpu usage and uses the cpufreq-userspace module to lessen power usage without any noticeable difference in performance.<br />
To use it, first install from the AUR:[https://aur.archlinux.org/packages.php?ID=36841], the default settings will work for most setups.<br />
You will need to load the cpufreq_userspace module, as well as the cpufreq scaling governor for your CPU at startup.<br />
Edit {{ic|/etc/rc.conf}}:<br />
For most generic cpus:<br />
<br />
MODULES=( ... cpufreq_userspace acpi-cpufreq ... )<br />
<br />
For Intel Atom or Pentium 4 cpus:<br />
<br />
MODULES=( ... cpufreq_userspace p4_clockmod ... )<br />
<br />
Then add Granola to the DAEMONS array:<br />
<br />
DAEMONS=( ... granola ... )<br />
<br />
and reboot. <br />
<br />
To test if it worked, run:<br />
<br />
cat /sys/devices/system/cpu/cpu0/cpufreq/cpuinfo_cur_freq<br />
#OR<br />
cpufreq-info #if you have cpufreq-utils installed<br />
<br />
and check that the cpu frequency is below maximum.<br />
<br />
====WLAN-device====<br />
When often en route working with your Notebook without WLAN-Access around, it might be expedient to add a little script to your system startup that automatically turns off your WLAN-Hardware to keep it from searching for Access Points and wasting power on this, when not connected:<br />
<br />
#!/bin/bash<br />
<br />
essid="`iwconfig wlan0 | grep ESSID | awk {'print $4'}`"<br />
if [ "$essid" == "ESSID:off/any" ] ; then<br />
sudo iwconfig wlan0 txpower off<br />
fi<br />
[edit, if wlan0 is not your WLAN-device]<br />
<br />
Start the script according to your DE/WM options by '(sleep xx && /path/to/script)' depending on how long it usually takes to connect to your Access Point, 60 seconds are a good default value. It will check if you're connected, turning off the device if not.<br />
sudo iwconfig wlan0 txpower on<br />
will bring it back up, as, of course, a reboot will.<br />
<br />
==== Disk-related tweaks ====<br />
Disable file access time: every time you access (read) a file the filesystem writes an access time to the file metadata. You can disable this on individual files by using the chattr command, or you can enable it on an entire disk by setting the ''noatime'' option in your fstab, as follows:<br />
<br />
/dev/sda1 / ext3 defaults,noatime 1 2<br />
<br />
[http://www.faqs.org/docs/securing/chap6sec73.html Source]<br />
<br />
{{Note|<br />
* Disabling {{ic|atime}} causes troubles with [[Mutt|mutt]] and other applications that make use of file timestamps. Consider compromising between performance and compatibility by using mount option {{ic|relatime}} instead, or look into [http://wiki.mutt.org/?MaildirFormat mutt work-around for noatime].<br />
* {{ic|relatime}} is used by default as of kernel 2.6.30, so unless you're using an older kernel, there should be no need to edit fstab.<br />
}}<br />
<br />
To allow the CD/DVD rom to spin down after a while using [[udisks]]:<br />
<br />
# udisks --inhibit-polling /dev/sr0<br />
<br />
==== More tweaks ====<br />
These are some generic suggestions that will work with most laptops.<br />
<br />
Add the following to {{ic|/etc/modprobe.d/modprobe.conf}}:<br />
<br />
options usbcore autosuspend=1<br />
<br />
Add the following to {{ic|/etc/sysctl.conf}}<br />
<br />
vm.dirty_writeback_centisecs=1500<br />
vm.laptop_mode=5<br />
<br />
{{Note|''laptop-mode-tools'' automatically rewrites these values based on the values {{Ic|LM_BATT_MAX_LOST_WORK_SECONDS}}, {{Ic|LM_AC_MAX_LOST_WORK_SECONDS}} (both multiplied by 100) resp. {{Ic|LM_SECONDS_BEFORE_SYNC}}, which are set in {{ic|/etc/laptop-mode/laptop-mode.conf}}. However, that only happens if the three "Enable laptop mode" variables in the same file are set accordingly — left to 0, it resets the values to kernel defaults (500 / 0) for the corresponding scenario regardless of {{ic|/etc/sysctl.conf}}.}}<br />
<br />
{{accuracy|reason=This belongs in a udev rule, not rc.local.}}<br />
<br />
Add the following to {{ic|/etc/rc.local}} (and make sure it gets executed at boot time)<br />
<br />
/usr/sbin/iwpriv your_wireless_interface set_power 5<br />
<br />
Source: [http://www.nervous.it/2007/11/linux-dell-xps-m1330/ here]<br />
<br />
==== Hard drive spin down problem ====<br />
Documented [https://bugs.launchpad.net/ubuntu/+source/acpi-support/+bug/59695 here]<br />
<br />
To prevent your laptop hard drive from spinning down too often (result of too aggressive APM defaults) do the following:<br />
<br />
Add the following to {{ic|/etc/rc.local}}<br />
<br />
hdparm -B 254 /dev/sdX ''where X is your hard drive device''<br />
<br />
You can also set it to 255 to completely disable spinning down. You may wish to set a lower value if you move your laptop around as lower values park the heads more often and reduce the chance of damage to your hard disk while it is being moved. If you do not move your laptop at all when you are using it, then 255 or 254 is probably best. If you do, then you might want to try a lower value. A value like 128 might be a good middle-ground.<br />
<br />
Add the following to {{ic|/etc/pm/sleep.d/50-hdparm_pm}}<br />
<br />
#!/bin/sh<br />
<br />
if [ -n "$1" ] && ([ "$1" = "resume" ] || [ "$1" = "thaw" ]); then<br />
hdparm -B 254 /dev/your-hard-drive > /dev/null<br />
fi<br />
<br />
and run ''chmod +x /etc/pm/sleep.d/50-hdparm_pm'' to make sure it resets after suspend. Again, you can change the value 254 as you see fit.<br />
<br />
Now the APM level should be set for your hard drive.<br />
<br />
For some laptops, the option -S to hdparm can also be relevant (sets the spindown time for the drive). Note that all these options can also be configured using the [[Laptop_Mode_Tools | laptop-mode tools]]. This will allow you to set a high value when on AC and a lower value when you are running on battery power.<br />
<br />
=== Using a script and an udev rule ===<br />
Since systemd users can suspend and hibernate through {{ic|systemctl suspend}} or {{ic|systemctl hibernate}} and handle acpi events with {{ic|/etc/systemd/logind.conf}}, it might be interesting to remove pm-utils and acpid. Now, there's just one thing systemd can't do (at this time of writing): powermanagement, depending on whether the system is running on AC or battery. To fill this gap, one can create a single udev rule that launches a script when the laptop is unplugged and plugged:<br />
{{hc|/etc/udev/rules.d/powersave|2=<nowiki><br />
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="0", RUN+="/path/to/your/script true"<br />
SUBSYSTEM=="power_supply", ENV{POWER_SUPPLY_ONLINE}=="1", RUN+="/path/to/your/script false"<br />
</nowiki>}}<br />
{{Note|One can use the same script that pm-powersave uses. You just have to make it executable and place it somewhere else (for example, /usr/bin).}}<br />
Examples of powersave scripts can be found here: [https://bbs.archlinux.org/viewtopic.php?pid=1046075#p1046075] (or in aur: {{AUR|powerdown}}), here: [https://github.com/Unia/powersave] and there: [https://aur.archlinux.org/packages/powerconf].<br />
<br />
The above udev rule should work as expected, but if your power settings aren't updated after a suspend or hibernate cycle, you should add a script in {{ic|/usr/lib/systemd/system-sleep/}} with the following contents:<br />
{{hc|/usr/lib/systemd/system-sleep/00powersave|<nowiki><br />
#!/bin/sh<br />
<br />
case $1 in<br />
pre) /path/to/your/script false ;;<br />
post) <br />
if cat /sys/class/power_supply/AC0/online | grep 0 > /dev/null 2>&1<br />
then<br />
/path/to/your/script true <br />
else<br />
/path/to/your/script false<br />
fi<br />
;;<br />
esac'<br />
exit 0<br />
</nowiki>}}<br />
<br />
Don't forget to make it executable!<br />
{{Note|Be aware that AC0 may be different for your laptop, change it if that is the case.}}<br />
<br />
Now you don't need pm-utils anymore. Depending on your configuration, it may be a dependency of some other package. If you wish to remove it anyway, run {{ic|pacman -Rdd pm-utils}}.<br />
<br />
== Screen brightness ==<br />
{{Merge|Backlight}}<br />
To change your display brightness, first check {{ic|/sys/class/backlight}}:<br />
<br />
# ls /sys/class/backlight/<br />
intel_backlight<br />
<br />
So this particular backlight is managed by an Intel card. Keep in mind that different cards might manage this differently! It is called ''acpi_video0'' on an ATI card, for instance.<br />
<br />
Check current value:<br />
<br />
$ cat /sys/class/backlight/intel_backlight/brightness<br />
<br />
In this case, the backlight managed by echoing values into {{ic|/sys/class/backlight/intel_backlight/brightness}}:<br />
<br />
# echo "400" > /sys/class/backlight/intel_backlight/brightness<br />
<br />
If you get a response along the lines of "invalid argument" then you didn't honor the maximum brightness. Obviously you cannot go any higher than your screens maximum brightness. The values for maximum brightness and brightness in general vary wildly among cards. This Intel card, for instance, can go up to 976 while the ATI can go up 9. Obviously these values don't say anything about maximum effective brightness.<br />
<br />
Check your maximum brightness: <br />
<br />
$ cat /sys/class/backlight/intel_backlight/max_brightness<br />
<br />
If your laptop's Fn keys don't work or Gnome/KDE fail to correctly set the brightness using their power daemons, you can try appending '''acpi_backlight=vendor''' to your kernel line in your bootloader.<br />
<br />
=== setpci fallback method ===<br />
{{Warning| The setpci command edits hardware parameters. Use with caution.}}<br />
On some laptops, the above methods do not actually change screen brightness. If this is the case for your laptop, first find the domain and bus using lspci:<br />
$ lspci<br />
(...)<br />
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 09)<br />
(...)<br />
Now use setpci to change the value at slot F4 to, say, a0:<br />
# setpci -s 00:02.0 f4.b=a0<br />
The {{ic|.b}} indicates a byte value; this runs in hexadecimal from {{ic|00}} to {{ic|ff}}. '''ff''' Is usually the brightest, although this may be reversed. See [https://bbs.archlinux.org/viewtopic.php?pid=1088825#p1088825 here] for a script which can be used with brightness keys.<br />
<br />
== Touchpad ==<br />
To get your touchpad working properly, see the [[Touchpad Synaptics]] page. Note that your laptop may have an ALPS touchpad (such as the DELL Inspiron 6000), and not a Synaptics touchpad. In either case, see the link above.<br />
<br />
== Hard disk shock protection ==<br />
There are several laptops from different vendors featuring shock protection capabilities. As manufacturers have refused to support open source development of the required software components so far, Linux support for shock protection varies considerably between different hardware implementations.<br />
<br />
Currently, two projects, named HDAPS and hpfall, support this kind of protection.<br />
HDAPS is for IBM/Lenovo Thinkpads and hpfall for HP/Compaq laptops<br />
<br />
Just Check [[HDAPS|Hard Disk Active Protection System]].<br />
{{AUR|hpfall}} can be installed from the [[AUR]].<br />
<br />
== Network Time Syncing ==<br />
For a laptop, it may be a good idea to use [[Chrony]] as an alternative to [[NTPd]] to sync your clock over the network. Chrony is designed to work well even on systems with no permanent network connection (such as laptops), and is capable of much faster time synchronisation than standard ntp. Chrony has several advantages when used in systems running on virtual machines, such as a larger range for frequency correction to help correct quickly drifting clocks, and better response to rapid changes in the clock frequency. It also has a smaller memory footprint and no unnecessary process wakeups, improving power efficiency.</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Powerdown&diff=247901Powerdown2013-02-19T15:32:19Z<p>Eruditorum: /* See also */</p>
<hr />
<div>[[Category:Power management]]<br />
{{Article summary start}}<br />
{{Article summary text|{{AUR|powerdown}} is a bunch of scripts by Taylorchu that combine all sorts of settings to make your computer consume less energy and thus save batterylife.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Pm-utils}}<br />
{{Article summary wiki|Udev}}<br />
{{Article summary wiki|Display Power Management Signaling}}<br />
{{Article summary end}}<br />
<br />
Powerdown is a bunch of scripts to take the hassle out of maximizing battery-life.<br />
<br />
{{Warning|Use at your own risk. It is recommended to read through all the tweaks in order to disable those that might not be compatible with your system.}}<br />
<br />
==Installation==<br />
{{AUR|powerdown}} is available from the [[AUR]].<br />
<br />
{{Note|Powerdown tries disabling NMI watchdog on the fly. If this doesn't work for you, you'll see "Dazed and confused" messages when suspending. You can disable it completely by adding {{ic|1=nmi_watchdog=0}} to the kernel command line.<br />
}}<br />
<br />
Add the following lines to {{ic|~/.xinitrc}} to turn off your screen after 5 minutes of idling by default:<br />
{{hc|~/.xinitrc|<br />
# screen powersave<br />
xset +dpms<br />
xset dpms 0 0 300<br />
}}<br />
<br />
{{Note|The script. If unsatisfactory, add {{ic|1=consoleblank=0}} to the kernel command line and run the following {{ic|xset}} commands (this would be a great addition to the powerdown scripts):<br />
xset s off<br />
xset s noblank<br />
xset s noexpose<br />
xset c on<br />
xset -dpms<br />
}}<br />
<br />
The {{ic|powerdown}} shell script located in {{ic|/usr/bin}} can be customised to your needs. To disable any undesired features simply comment out its appropriate line.<br />
<br />
==Usage==<br />
<br />
The following table presents all scripts installed.<br />
<br />
{| border="1"<br />
! Name !! Function<br />
|-<br />
| powerdown, powerup || Powers everything down or up.<br />
|-<br />
| powerdown-functions || Defines functions that are used by powerdown and powerup.<br />
|-<br />
| powernow || Displays current power usage and settings.<br />
|-<br />
| powerdown.rules || The Udev rule that loads powerdown or powerup.<br />
|-<br />
| suspend-to-mem || Suspends to RAM.<br />
|-<br />
| suspend-to-disk || Suspends to HDD, creates a 2GB swap file at the first time doing so.<br />
|-<br />
| suspend-hybrid || First, suspends to RAM. After 10 minutes, wakes up and suspends to HDD.<br />
|-<br />
| pm-is-supported, pm-powersave, pm-suspend, pm-hibernate || Wrappers with pm-utils syntax (for legacy support?).<br />
|}<br />
<br />
After a reboot the scripts can now be run in a terminal.<br />
<br />
== Automatically running powerdown at power state changes ==<br />
<br />
Powerdown is automatically loaded by a [[Udev]] rule, so no daemon, rc-script or service-file is necessary.<br />
<br />
However, this doesn't work on every machine, so you might want to enable upower.service in systemd with<br />
# systemctl enable upower.service<br />
or add {{ic|upower -e}} to your {{ic|.xinitrc}}.<br />
<br />
== Configuration ==<br />
<br />
As there are no config files for powerdown, you have to edit {{ic|/usr/bin/powerdown}} by hand and adjust the values. Note, however, that these changes will be overwritten during an update!<br />
<br />
==FAQ==<br />
====I do get more spinups and clicks from my HDD. Where is this setting stored in powerdown?====<br />
Set the following tweak to a higher value:<br />
hdparm -B<br />
<br />
==Packages that are no longer necessary after installation==<br />
[https://bbs.archlinux.org/viewtopic.php?pid=1094283#p1094283 Source]<br />
# <s>powertop, powertop2: these packages have no updates for at least 3-4 years. if you think kernel has no changes on power management for 3 or 4 years, go ahead and continue to use them. Replacement: powernow is included in new powerdown. it shows laptop power usage in mWh. the value is usually between 10000 to 25000.</s><br />
# laptop-mode-tools: this is a huge framework on power management. It has dozens of configs you need to setup, which normally no one knows how to control them. I think it is a "troubleware"; to use it properly, you have to google more. most of time, you dont even know what works or not. Replacement: powerdown shows what does not work right in the screen. it contains all the rules optimized that just work.<br />
# tuxonice, uswsusp, pm-utils: too hassle to set things up. again, they complicate suspend and resume. the default kernel already support suspends and resume pretty well. Replacement: ps2mem uses default kernel for ram suspend and resume. you just run "sudo suspend-to-mem"; no framework, no setup.<br />
# turn-off solves a bug in kernel(even in 3,4 rc that ehci_hcd messes up shutdown when it is set to powersave mode). This is a wrapper for 'poweroff'. You just call it to shut down your arch box.<br />
<br />
==See also==<br />
* [https://bbs.archlinux.org/viewtopic.php?id=134109 Initial thread on the forum]<br />
* [https://aur.archlinux.org/packages.php?ID=57421 AUR page]<br />
* [https://github.com/taylorchu/powerdown Github repository]<br />
* [https://github.com/Unia/powersave Alternative, more simple powersave script]<br />
* [https://aur.archlinux.org/packages/powerconf Another simple power saving system]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=247900Power saving2013-02-19T15:20:37Z<p>Eruditorum: /* Backlight */</p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
{{Warning|On systems that don't support it forcing on ASPM can even increase power consumption.}}<br />
<br />
== Backlight ==<br />
<br />
When system starts, screen backlight is set to maximum by default. This can be fixed by specifying backlight level in the following udev rule:<br />
<br />
{{hc|/etc/udev/rules.d/backlight.rules|<nowiki><br />
## SET BACKLIGHT<br />
SUBSYSTEM=="backlight", ACTION=="add", KERNEL=="acpi_video0", ATTR{brightness}="1"<br />
</nowiki>}}<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
Alternatively, [[Kernel_modules#Blacklisting|blacklist]] the {{ic|btusb}} and {{ic|bluetooth}} modules.<br />
<br />
Another variant is to {{pkg|rfkill}} it:<br />
# rfkill block bluetooth<br />
<br />
Or with udev rule:<br />
{{hc|/etc/udev/rules.d/bt.rules|<nowiki><br />
## DISABLE BLUETOOTH<br />
SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"<br />
</nowiki>}}<br />
<br />
== Web-Camera ==<br />
If you won't use integrated web camera then [[Kernel_modules#Blacklisting|blacklist]] the {{ic|uvcvideo}} module.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|1=nmi_watchdog=0}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for all Ethernet interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
You can use multiple names in the matches; for example, {{ic|1=KERNEL=="lan0&#124;eth*"}}<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the {{ic|eth*}} names are not static.}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
{{hc|/etc/udev/rules.d/usb_power_save.rules|2=ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="auto"<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/autosuspend" ATTR{power/autosuspend}="2"}}<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=247899Power saving2013-02-19T15:16:16Z<p>Eruditorum: </p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
{{Warning|On systems that don't support it forcing on ASPM can even increase power consumption.}}<br />
<br />
== Backlight ==<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
Alternatively, [[Kernel_modules#Blacklisting|blacklist]] the {{ic|btusb}} and {{ic|bluetooth}} modules.<br />
<br />
Another variant is to {{pkg|rfkill}} it:<br />
# rfkill block bluetooth<br />
<br />
Or with udev rule:<br />
{{hc|/etc/udev/rules.d/bt.rules|<nowiki><br />
## DISABLE BLUETOOTH<br />
SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"<br />
</nowiki>}}<br />
<br />
== Web-Camera ==<br />
If you won't use integrated web camera then [[Kernel_modules#Blacklisting|blacklist]] the {{ic|uvcvideo}} module.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|1=nmi_watchdog=0}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for all Ethernet interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
You can use multiple names in the matches; for example, {{ic|1=KERNEL=="lan0&#124;eth*"}}<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the {{ic|eth*}} names are not static.}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
{{hc|/etc/udev/rules.d/usb_power_save.rules|2=ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="auto"<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/autosuspend" ATTR{power/autosuspend}="2"}}<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=247898Power saving2013-02-19T15:11:45Z<p>Eruditorum: /* Bluetooth */</p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
{{Warning|On systems that don't support it forcing on ASPM can even increase power consumption.}}<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
Alternatively, [[Kernel_modules#Blacklisting|blacklist]] the {{ic|btusb}} and {{ic|bluetooth}} modules.<br />
<br />
Another variant is to {{pkg|rfkill}} it:<br />
# rfkill block bluetooth<br />
<br />
Or with udev rule:<br />
{{hc|/etc/udev/rules.d/bt.rules|<nowiki><br />
## DISABLE BLUETOOTH<br />
SUBSYSTEM=="rfkill", ATTR{type}=="bluetooth", ATTR{state}="0"<br />
</nowiki>}}<br />
<br />
== Web-Camera ==<br />
If you won't use integrated web camera then [[Kernel_modules#Blacklisting|blacklist]] the {{ic|uvcvideo}} module.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|1=nmi_watchdog=0}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for all Ethernet interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
You can use multiple names in the matches; for example, {{ic|1=KERNEL=="lan0&#124;eth*"}}<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the {{ic|eth*}} names are not static.}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
{{hc|/etc/udev/rules.d/usb_power_save.rules|2=ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="auto"<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/autosuspend" ATTR{power/autosuspend}="2"}}<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=247897Power saving2013-02-19T15:06:41Z<p>Eruditorum: /* Active State Power Management */</p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
{{Warning|On systems that don't support it forcing on ASPM can even increase power consumption.}}<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
Alternatively, [[Kernel_modules#Blacklisting|blacklist]] the {{ic|btusb}} and {{ic|bluetooth}} modules.<br />
<br />
Another variant is to {{pkg|rfkill}} it:<br />
# rfkill block bluetooth<br />
<br />
== Web-Camera ==<br />
If you won't use integrated web camera then [[Kernel_modules#Blacklisting|blacklist]] the {{ic|uvcvideo}} module.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|1=nmi_watchdog=0}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for all Ethernet interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
You can use multiple names in the matches; for example, {{ic|1=KERNEL=="lan0&#124;eth*"}}<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the {{ic|eth*}} names are not static.}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
{{hc|/etc/udev/rules.d/usb_power_save.rules|2=ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="auto"<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/autosuspend" ATTR{power/autosuspend}="2"}}<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Acpid&diff=247873Acpid2013-02-19T00:08:26Z<p>Eruditorum: /* Enabling Wi-fi toggle */</p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Power management]]<br />
[[it:Acpid]]<br />
[[zh-CN:Acpid]]<br />
<br />
[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering [[ACPI modules|ACPI events]]. It listens on {{ic|/proc/acpi/event}} and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:<br />
* Pressing special keys, including the Power/Sleep/Suspend button<br />
* Closing a notebook lid<br />
* (Un)Plugging an AC power adapter from a notebook<br />
* (Un)Plugging phone jack etc.<br />
<br />
acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.<br />
<br />
{{Note|<br />
* [[Desktop Environment|desktop environments]], such as [[GNOME]], [[Systemd#ACPI power management|systemd]] login manager and some [[Extra Keyboard Keys|extra key handling]] daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.<br />
* Since by default the script provided by acpid, '''/etc/acpi/handler.sh''', will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).}}<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].<br />
<br />
To have it start on boot :<br />
* if you're using [[systemd]], run {{ic|systemctl enable acpid}} ;<br />
* if you're using [[rc.conf|initscripts]], edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]].<br />
<br />
== Configuration ==<br />
<br />
{{Pkg|acpid}} comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in {{ic|/etc/acpi/handler.sh}}, which is executed after any ACPI events are detected (as determined by {{ic|/etc/acpi/events/anything}}).<br />
<br />
The following is a brief example of one such action. In this case, when the Sleep button is pressed, acpid runs the command {{ic|echo -n mem >/sys/power/state}} which ''should'' place the computer into a sleep (suspend) state:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
;;<br />
<br />
Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as ''SLPB'' and on another as ''SBTN''. <br />
<br />
To determine how your buttons or {{Keypress|Fn}} shortcuts are recognized, run the following command from a terminal as root:<br />
# tail -f /var/log/messages.log<br />
<br />
Now press the Power button and/or Sleep button (e.g. {{Keypress|Fn+Esc}}) on your machine. The result should look something this:<br />
logger: ACPI action undefined: PBTN<br />
logger: ACPI action undefined: SBTN<br />
<br />
If that does not work, run:<br />
# acpi_listen<br />
<br />
Then press the power button and you will see something like this:<br />
power/button PBTN 00000000 00000b31<br />
<br />
The output of {{ic|acpi_listen}} is sent to {{ic|/etc/acpi/handler.sh}} as $1, $2 , $3 & $4 parameters.<br />
Example:<br />
$1 power/button<br />
$2 PBTN<br />
$3 00000000<br />
$4 00000b31<br />
<br />
As you might have noticed, the Sleep button in the sample output is actually recognized as ''SBTN'', rather than the ''SLPB'' label specified in the default {{ic|/etc/acpi/handler.sh}}. In order for Sleep function to work properly on this machine, we would need to replace ''SLPB)'' with ''SBTN)''.<br />
<br />
Using this information as a base, you can easily customize the {{ic|/etc/acpi/handler.sh}} file to execute a variety of commands depending on which event is triggered. See the [[Acpid#Tips & Tricks | Tips & Tricks]] section below for other commonly used commands.<br />
<br />
=== Alternative configuration ===<br />
<br />
By default, all ACPI events are passed through the {{ic|/etc/acpi/handler.sh}} script. This is due to the ruleset outlined in {{ic|/etc/acpi/events/anything}}:<br />
# Pass all events to our one handler script<br />
event=.*<br />
action=/etc/acpi/handler.sh %e<br />
<br />
While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:<br />
<br />
As root, create the following file:<br />
{{hc|/etc/acpi/events/sleep-button|<nowiki><br />
event=button sleep.*<br />
action=/etc/acpi/actions/sleep-button.sh "%e"<br />
</nowiki>}}<br />
<br />
Now create the following file:<br />
{{hc|/etc/acpi/actions/sleep-button.sh|<nowiki><br />
#!/bin/sh<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
</nowiki>}}<br />
<br />
Finally, make the script executable: <br />
# chmod +x /etc/acpi/actions/sleep-button.sh<br />
<br />
Using this method, it is easy to create any number of individual event/action scripts.<br />
<br />
==Tips and tricks==<br />
<br />
===Extending acpid with pm-utils===<br />
<br />
Although {{Pkg|acpid}} can provide basic suspend2ram out-of-the-box, a more robust system may be desired. [[pm-utils]] provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, {{ic|pm-suspend}} and {{ic|pm-hibernate}}, both of which can be inserted as events into acpid. For more information, check the [[pm-utils]] wiki.<br />
<br />
===Example Events===<br />
<br />
The following are examples of events that can be used in the {{ic|/etc/acpi/handler.sh}} script. These examples should be modified so that they apply your specific environment e.g. changing the event variable names interpreted by {{ic|acpi_listen}}.<br />
<br />
To lock the screen with {{ic|xscreensaver}} when closing the laptop lid:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
# The lock command need to be run as the user who owns the xscreensaver process and not as root.<br />
# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.<br />
<br />
xs=$(ps -C xscreensaver -o user=)<br />
if test $xs; then su $xs -c "xscreensaver-command -lock"; fi<br />
;;<br />
<br />
To suspend the system and lock the screen using {{ic|slimlock}} when the lid is closed:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
#echo "LID switched!">/dev/tty5<br />
/usr/sbin/pm-suspend &<br />
DISPLAY=:0.0 su -c - username /usr/bin/slimlock<br />
;;<br />
<br />
Execute {{ic|pm-suspend}} when the sleep button is pressed:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SBTN) <br />
#echo -n mem >/sys/power/state<br />
/usr/sbin/pm-suspend<br />
;;<br />
<br />
To set the laptop screen brightness when plugged in power or not (the numbers might need to be adjusted, see {{ic|/sys/class/backlight/acpi_video0/max_brightness}}):<br />
<br />
ac_adapter)<br />
case "$2" in<br />
AC*|AD*)<br />
case "$4" in<br />
00000000)<br />
echo -n 50 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
00000001)<br />
echo -n 100 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
esac<br />
<br />
=== Enabling volume control ===<br />
<br />
Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a script to control the volume (assuming an [[ALSA]] sound card):<br />
<br />
{{hc|/etc/acpi/handlers/vol|<nowiki><br />
#!/bin/sh<br />
step=5<br />
<br />
case $1 in<br />
-) amixer set Master $step-;;<br />
+) amixer set Master $step+;;<br />
esac<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/vol_d|<nowiki><br />
event=button/volumedown<br />
action=/etc/acpi/handlers/vol -<br />
</nowiki>}}<br />
{{hc|/etc/acpi/events/vol_u|<nowiki><br />
event=button/volumeup<br />
action=/etc/acpi/handlers/vol +<br />
</nowiki>}}<br />
<br />
as well as another event to toggle the mute setting:<br />
<br />
{{hc|/etc/acpi/events/mute|<nowiki><br />
event=button/mute<br />
action=/usr/bin/amixer set Master toggle<br />
</nowiki>}}<br />
<br />
=== Enabling backlight control ===<br />
<br />
Similar to volume control, acpid also enables you to control screen backlight. To achieve this you write some handler, like this:<br />
<br />
{{hc|/etc/acpi/handlers/bl|<nowiki><br />
#!/bin/sh<br />
bl_dev=/sys/class/backlight/acpi_video0<br />
step=1<br />
<br />
case $1 in<br />
-) echo $((`cat $bl_dev/brightness` - $step)) >$bl_dev/brightness;;<br />
+) echo $((`cat $bl_dev/brightness` + $step)) >$bl_dev/brightness;;<br />
esac<br />
</nowiki>}}<br />
<br />
and again, connect keys to ACPI events:<br />
<br />
{{hc|/etc/acpi/events/bl_d|<nowiki><br />
event=video/brightnessdown<br />
action=/etc/acpi/handlers/bl -<br />
</nowiki>}}<br />
{{hc|/etc/acpi/events/bl_u|<nowiki><br />
event=video/brightnessup<br />
action=/etc/acpi/handlers/bl +<br />
</nowiki>}}<br />
<br />
=== Enabling Wi-fi toggle ===<br />
<br />
You can also create a simple wireless-power switch by pressing the WLAN button. Example of event:<br />
<br />
{{hc|/etc/acpi/events/wlan|<nowiki><br />
event=button/wlan<br />
action=/etc/acpi/handlers/wlan<br />
</nowiki>}}<br />
<br />
and its' handler:<br />
<br />
{{hc|/etc/acpi/handlers/wlan|<nowiki><br />
#!/bin/sh<br />
rf=/sys/class/rfkill/rfkill0<br />
<br />
case `cat $rf/state` in<br />
0) echo 1 >$rf/state && systemctl start net-auto-wireless;;<br />
1) systemctl stop net-auto-wireless && echo 0 >$rf/state;;<br />
esac<br />
</nowiki>}}<br />
<br />
=== Laptop Monitor Power Off ===<br />
<br />
Adapted from the [http://en.gentoo-wiki.com/wiki/ACPI/Configuration Gentoo Wiki] comes this little gem. Add this to the bottom of {{ic|/etc/acpi/actions/lm_lid.sh}} or to the ''button/lid'' section {{ic|/etc/acpi/handler.sh}}. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force off ;;<br />
open) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force on ;;<br />
esac<br />
<br />
If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.<br />
<br />
Here is another script not using XAUTHORITY but sudo:<br />
<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force off ;;<br />
open) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force on ;;<br />
esac<br />
<br />
With certain combinations of [[Xorg]] and stubborn hardware, {{ic|xset dpms force off}} only blanks the display leaving the backlight turned on. This can be fixed using {{Pkg|vbetool}} from the [[Official Repositories|official repositories]]. Change the LCD section to:<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) vbetool dpms off ;;<br />
open) vbetool dpms on ;;<br />
esac<br />
<br />
If the monitor appears to shut off only briefly before being re-powered, very possibly the power management shipped with xscreensaver conflicts with any manual ''dpms'' settings.<br />
<br />
=== Getting user name of the current display ===<br />
You can use the function {{ic|getuser}} to discover the user of the current display:<br />
getuser ()<br />
{<br />
export DISPLAY=`echo $DISPLAY | cut -c -2`<br />
user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`<br />
export XAUTHORITY=/home/$user/.Xauthority<br />
eval $1=$user<br />
}<br />
<br />
This function can be used for example, when you press the power button and want to shutdown [[KDE]] properly:<br />
button/power)<br />
case "$2" in<br />
PBTN)<br />
getuser "$user"<br />
echo $user > /dev/tty5<br />
su $user -c "dcop ksmserver ksmserver logout 0 2 0"<br />
;;<br />
*) logger "ACPI action undefined $2" ;;<br />
esac<br />
;;<br />
<br />
<br />
On newer systems using systemd, X11 logins are no longer necessarily displayed in {{ic|who}}, so the {{ic|getuser}} function above does not work. An alternative is to use {{ic|loginctl}} to obtain the required information, e.g. using [https://github.com/rephorm/xuserrun xuserrun].<br />
<br />
==See also==<br />
<br />
* http://acpid.sourceforge.net/ - acpid homepage<br />
* http://www.gentoo-wiki.info/ACPI/Configuration - RIP Gentoo wiki entry - New Gentoo Wiki Archives<br />
* [[ACPI hotkeys]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Acpid&diff=247872Acpid2013-02-18T23:57:10Z<p>Eruditorum: </p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Power management]]<br />
[[it:Acpid]]<br />
[[zh-CN:Acpid]]<br />
<br />
[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering [[ACPI modules|ACPI events]]. It listens on {{ic|/proc/acpi/event}} and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:<br />
* Pressing special keys, including the Power/Sleep/Suspend button<br />
* Closing a notebook lid<br />
* (Un)Plugging an AC power adapter from a notebook<br />
* (Un)Plugging phone jack etc.<br />
<br />
acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.<br />
<br />
{{Note|<br />
* [[Desktop Environment|desktop environments]], such as [[GNOME]], [[Systemd#ACPI power management|systemd]] login manager and some [[Extra Keyboard Keys|extra key handling]] daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.<br />
* Since by default the script provided by acpid, '''/etc/acpi/handler.sh''', will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).}}<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].<br />
<br />
To have it start on boot :<br />
* if you're using [[systemd]], run {{ic|systemctl enable acpid}} ;<br />
* if you're using [[rc.conf|initscripts]], edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]].<br />
<br />
== Configuration ==<br />
<br />
{{Pkg|acpid}} comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in {{ic|/etc/acpi/handler.sh}}, which is executed after any ACPI events are detected (as determined by {{ic|/etc/acpi/events/anything}}).<br />
<br />
The following is a brief example of one such action. In this case, when the Sleep button is pressed, acpid runs the command {{ic|echo -n mem >/sys/power/state}} which ''should'' place the computer into a sleep (suspend) state:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
;;<br />
<br />
Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as ''SLPB'' and on another as ''SBTN''. <br />
<br />
To determine how your buttons or {{Keypress|Fn}} shortcuts are recognized, run the following command from a terminal as root:<br />
# tail -f /var/log/messages.log<br />
<br />
Now press the Power button and/or Sleep button (e.g. {{Keypress|Fn+Esc}}) on your machine. The result should look something this:<br />
logger: ACPI action undefined: PBTN<br />
logger: ACPI action undefined: SBTN<br />
<br />
If that does not work, run:<br />
# acpi_listen<br />
<br />
Then press the power button and you will see something like this:<br />
power/button PBTN 00000000 00000b31<br />
<br />
The output of {{ic|acpi_listen}} is sent to {{ic|/etc/acpi/handler.sh}} as $1, $2 , $3 & $4 parameters.<br />
Example:<br />
$1 power/button<br />
$2 PBTN<br />
$3 00000000<br />
$4 00000b31<br />
<br />
As you might have noticed, the Sleep button in the sample output is actually recognized as ''SBTN'', rather than the ''SLPB'' label specified in the default {{ic|/etc/acpi/handler.sh}}. In order for Sleep function to work properly on this machine, we would need to replace ''SLPB)'' with ''SBTN)''.<br />
<br />
Using this information as a base, you can easily customize the {{ic|/etc/acpi/handler.sh}} file to execute a variety of commands depending on which event is triggered. See the [[Acpid#Tips & Tricks | Tips & Tricks]] section below for other commonly used commands.<br />
<br />
=== Alternative configuration ===<br />
<br />
By default, all ACPI events are passed through the {{ic|/etc/acpi/handler.sh}} script. This is due to the ruleset outlined in {{ic|/etc/acpi/events/anything}}:<br />
# Pass all events to our one handler script<br />
event=.*<br />
action=/etc/acpi/handler.sh %e<br />
<br />
While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:<br />
<br />
As root, create the following file:<br />
{{hc|/etc/acpi/events/sleep-button|<nowiki><br />
event=button sleep.*<br />
action=/etc/acpi/actions/sleep-button.sh "%e"<br />
</nowiki>}}<br />
<br />
Now create the following file:<br />
{{hc|/etc/acpi/actions/sleep-button.sh|<nowiki><br />
#!/bin/sh<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
</nowiki>}}<br />
<br />
Finally, make the script executable: <br />
# chmod +x /etc/acpi/actions/sleep-button.sh<br />
<br />
Using this method, it is easy to create any number of individual event/action scripts.<br />
<br />
==Tips and tricks==<br />
<br />
===Extending acpid with pm-utils===<br />
<br />
Although {{Pkg|acpid}} can provide basic suspend2ram out-of-the-box, a more robust system may be desired. [[pm-utils]] provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, {{ic|pm-suspend}} and {{ic|pm-hibernate}}, both of which can be inserted as events into acpid. For more information, check the [[pm-utils]] wiki.<br />
<br />
===Example Events===<br />
<br />
The following are examples of events that can be used in the {{ic|/etc/acpi/handler.sh}} script. These examples should be modified so that they apply your specific environment e.g. changing the event variable names interpreted by {{ic|acpi_listen}}.<br />
<br />
To lock the screen with {{ic|xscreensaver}} when closing the laptop lid:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
# The lock command need to be run as the user who owns the xscreensaver process and not as root.<br />
# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.<br />
<br />
xs=$(ps -C xscreensaver -o user=)<br />
if test $xs; then su $xs -c "xscreensaver-command -lock"; fi<br />
;;<br />
<br />
To suspend the system and lock the screen using {{ic|slimlock}} when the lid is closed:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
#echo "LID switched!">/dev/tty5<br />
/usr/sbin/pm-suspend &<br />
DISPLAY=:0.0 su -c - username /usr/bin/slimlock<br />
;;<br />
<br />
Execute {{ic|pm-suspend}} when the sleep button is pressed:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SBTN) <br />
#echo -n mem >/sys/power/state<br />
/usr/sbin/pm-suspend<br />
;;<br />
<br />
To set the laptop screen brightness when plugged in power or not (the numbers might need to be adjusted, see {{ic|/sys/class/backlight/acpi_video0/max_brightness}}):<br />
<br />
ac_adapter)<br />
case "$2" in<br />
AC*|AD*)<br />
case "$4" in<br />
00000000)<br />
echo -n 50 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
00000001)<br />
echo -n 100 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
esac<br />
<br />
=== Enabling volume control ===<br />
<br />
Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a script to control the volume (assuming an [[ALSA]] sound card):<br />
<br />
{{hc|/etc/acpi/handlers/vol|<nowiki><br />
#!/bin/sh<br />
step=5<br />
<br />
case $1 in<br />
-) amixer set Master $step-;;<br />
+) amixer set Master $step+;;<br />
esac<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/vol_d|<nowiki><br />
event=button/volumedown<br />
action=/etc/acpi/handlers/vol -<br />
</nowiki>}}<br />
{{hc|/etc/acpi/events/vol_u|<nowiki><br />
event=button/volumeup<br />
action=/etc/acpi/handlers/vol +<br />
</nowiki>}}<br />
<br />
as well as another event to toggle the mute setting:<br />
<br />
{{hc|/etc/acpi/events/mute|<nowiki><br />
event=button/mute<br />
action=/usr/bin/amixer set Master toggle<br />
</nowiki>}}<br />
<br />
=== Enabling backlight control ===<br />
<br />
Similar to volume control, acpid also enables you to control screen backlight. To achieve this you write some handler, like this:<br />
<br />
{{hc|/etc/acpi/handlers/bl|<nowiki><br />
#!/bin/sh<br />
bl_dev=/sys/class/backlight/acpi_video0<br />
step=1<br />
<br />
case $1 in<br />
-) echo $((`cat $bl_dev/brightness` - $step)) >$bl_dev/brightness;;<br />
+) echo $((`cat $bl_dev/brightness` + $step)) >$bl_dev/brightness;;<br />
esac<br />
</nowiki>}}<br />
<br />
and again, connect keys to ACPI events:<br />
<br />
{{hc|/etc/acpi/events/bl_d|<nowiki><br />
event=video/brightnessdown<br />
action=/etc/acpi/handlers/bl -<br />
</nowiki>}}<br />
{{hc|/etc/acpi/events/bl_u|<nowiki><br />
event=video/brightnessup<br />
action=/etc/acpi/handlers/bl +<br />
</nowiki>}}<br />
<br />
=== Enabling Wi-fi toggle ===<br />
<br />
<br />
=== Laptop Monitor Power Off ===<br />
<br />
Adapted from the [http://en.gentoo-wiki.com/wiki/ACPI/Configuration Gentoo Wiki] comes this little gem. Add this to the bottom of {{ic|/etc/acpi/actions/lm_lid.sh}} or to the ''button/lid'' section {{ic|/etc/acpi/handler.sh}}. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force off ;;<br />
open) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force on ;;<br />
esac<br />
<br />
If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.<br />
<br />
Here is another script not using XAUTHORITY but sudo:<br />
<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force off ;;<br />
open) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force on ;;<br />
esac<br />
<br />
With certain combinations of [[Xorg]] and stubborn hardware, {{ic|xset dpms force off}} only blanks the display leaving the backlight turned on. This can be fixed using {{Pkg|vbetool}} from the [[Official Repositories|official repositories]]. Change the LCD section to:<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) vbetool dpms off ;;<br />
open) vbetool dpms on ;;<br />
esac<br />
<br />
If the monitor appears to shut off only briefly before being re-powered, very possibly the power management shipped with xscreensaver conflicts with any manual ''dpms'' settings.<br />
<br />
=== Getting user name of the current display ===<br />
You can use the function {{ic|getuser}} to discover the user of the current display:<br />
getuser ()<br />
{<br />
export DISPLAY=`echo $DISPLAY | cut -c -2`<br />
user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`<br />
export XAUTHORITY=/home/$user/.Xauthority<br />
eval $1=$user<br />
}<br />
<br />
This function can be used for example, when you press the power button and want to shutdown [[KDE]] properly:<br />
button/power)<br />
case "$2" in<br />
PBTN)<br />
getuser "$user"<br />
echo $user > /dev/tty5<br />
su $user -c "dcop ksmserver ksmserver logout 0 2 0"<br />
;;<br />
*) logger "ACPI action undefined $2" ;;<br />
esac<br />
;;<br />
<br />
<br />
On newer systems using systemd, X11 logins are no longer necessarily displayed in {{ic|who}}, so the {{ic|getuser}} function above does not work. An alternative is to use {{ic|loginctl}} to obtain the required information, e.g. using [https://github.com/rephorm/xuserrun xuserrun].<br />
<br />
==See also==<br />
<br />
* http://acpid.sourceforge.net/ - acpid homepage<br />
* http://www.gentoo-wiki.info/ACPI/Configuration - RIP Gentoo wiki entry - New Gentoo Wiki Archives<br />
* [[ACPI hotkeys]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Acpid&diff=247871Acpid2013-02-18T23:54:43Z<p>Eruditorum: /* Enabling backlight control */</p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Power management]]<br />
[[it:Acpid]]<br />
[[zh-CN:Acpid]]<br />
<br />
[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering [[ACPI modules|ACPI events]]. It listens on {{ic|/proc/acpi/event}} and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:<br />
* Pressing special keys, including the Power/Sleep/Suspend button<br />
* Closing a notebook lid<br />
* (Un)Plugging an AC power adapter from a notebook<br />
* (Un)Plugging phone jack etc.<br />
<br />
acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.<br />
<br />
{{Note|<br />
* [[Desktop Environment|desktop environments]], such as [[GNOME]], [[Systemd#ACPI power management|systemd]] login manager and some [[Extra Keyboard Keys|extra key handling]] daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.<br />
* Since by default the script provided by acpid, '''/etc/acpi/handler.sh''', will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).}}<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].<br />
<br />
To have it start on boot :<br />
* if you're using [[systemd]], run {{ic|systemctl enable acpid}} ;<br />
* if you're using [[rc.conf|initscripts]], edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]].<br />
<br />
== Configuration ==<br />
<br />
{{Pkg|acpid}} comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in {{ic|/etc/acpi/handler.sh}}, which is executed after any ACPI events are detected (as determined by {{ic|/etc/acpi/events/anything}}).<br />
<br />
The following is a brief example of one such action. In this case, when the Sleep button is pressed, acpid runs the command {{ic|echo -n mem >/sys/power/state}} which ''should'' place the computer into a sleep (suspend) state:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
;;<br />
<br />
Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as ''SLPB'' and on another as ''SBTN''. <br />
<br />
To determine how your buttons or {{Keypress|Fn}} shortcuts are recognized, run the following command from a terminal as root:<br />
# tail -f /var/log/messages.log<br />
<br />
Now press the Power button and/or Sleep button (e.g. {{Keypress|Fn+Esc}}) on your machine. The result should look something this:<br />
logger: ACPI action undefined: PBTN<br />
logger: ACPI action undefined: SBTN<br />
<br />
If that does not work, run:<br />
# acpi_listen<br />
<br />
Then press the power button and you will see something like this:<br />
power/button PBTN 00000000 00000b31<br />
<br />
The output of {{ic|acpi_listen}} is sent to {{ic|/etc/acpi/handler.sh}} as $1, $2 , $3 & $4 parameters.<br />
Example:<br />
$1 power/button<br />
$2 PBTN<br />
$3 00000000<br />
$4 00000b31<br />
<br />
As you might have noticed, the Sleep button in the sample output is actually recognized as ''SBTN'', rather than the ''SLPB'' label specified in the default {{ic|/etc/acpi/handler.sh}}. In order for Sleep function to work properly on this machine, we would need to replace ''SLPB)'' with ''SBTN)''.<br />
<br />
Using this information as a base, you can easily customize the {{ic|/etc/acpi/handler.sh}} file to execute a variety of commands depending on which event is triggered. See the [[Acpid#Tips & Tricks | Tips & Tricks]] section below for other commonly used commands.<br />
<br />
=== Alternative configuration ===<br />
<br />
By default, all ACPI events are passed through the {{ic|/etc/acpi/handler.sh}} script. This is due to the ruleset outlined in {{ic|/etc/acpi/events/anything}}:<br />
# Pass all events to our one handler script<br />
event=.*<br />
action=/etc/acpi/handler.sh %e<br />
<br />
While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:<br />
<br />
As root, create the following file:<br />
{{hc|/etc/acpi/events/sleep-button|<nowiki><br />
event=button sleep.*<br />
action=/etc/acpi/actions/sleep-button.sh "%e"<br />
</nowiki>}}<br />
<br />
Now create the following file:<br />
{{hc|/etc/acpi/actions/sleep-button.sh|<nowiki><br />
#!/bin/sh<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
</nowiki>}}<br />
<br />
Finally, make the script executable: <br />
# chmod +x /etc/acpi/actions/sleep-button.sh<br />
<br />
Using this method, it is easy to create any number of individual event/action scripts.<br />
<br />
==Tips and tricks==<br />
<br />
===Extending acpid with pm-utils===<br />
<br />
Although {{Pkg|acpid}} can provide basic suspend2ram out-of-the-box, a more robust system may be desired. [[pm-utils]] provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, {{ic|pm-suspend}} and {{ic|pm-hibernate}}, both of which can be inserted as events into acpid. For more information, check the [[pm-utils]] wiki.<br />
<br />
===Example Events===<br />
<br />
The following are examples of events that can be used in the {{ic|/etc/acpi/handler.sh}} script. These examples should be modified so that they apply your specific environment e.g. changing the event variable names interpreted by {{ic|acpi_listen}}.<br />
<br />
To lock the screen with {{ic|xscreensaver}} when closing the laptop lid:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
# The lock command need to be run as the user who owns the xscreensaver process and not as root.<br />
# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.<br />
<br />
xs=$(ps -C xscreensaver -o user=)<br />
if test $xs; then su $xs -c "xscreensaver-command -lock"; fi<br />
;;<br />
<br />
To suspend the system and lock the screen using {{ic|slimlock}} when the lid is closed:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
#echo "LID switched!">/dev/tty5<br />
/usr/sbin/pm-suspend &<br />
DISPLAY=:0.0 su -c - username /usr/bin/slimlock<br />
;;<br />
<br />
Execute {{ic|pm-suspend}} when the sleep button is pressed:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SBTN) <br />
#echo -n mem >/sys/power/state<br />
/usr/sbin/pm-suspend<br />
;;<br />
<br />
To set the laptop screen brightness when plugged in power or not (the numbers might need to be adjusted, see {{ic|/sys/class/backlight/acpi_video0/max_brightness}}):<br />
<br />
ac_adapter)<br />
case "$2" in<br />
AC*|AD*)<br />
case "$4" in<br />
00000000)<br />
echo -n 50 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
00000001)<br />
echo -n 100 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
esac<br />
<br />
=== Enabling volume control ===<br />
<br />
Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a script to control the volume (assuming an [[ALSA]] sound card):<br />
<br />
{{hc|/etc/acpi/handlers/vol|<nowiki><br />
#!/bin/sh<br />
step=5<br />
<br />
case $1 in<br />
-) amixer set Master $step-;;<br />
+) amixer set Master $step+;;<br />
esac<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/vol_d|<nowiki><br />
event=button/volumedown<br />
action=/etc/acpi/handlers/vol -<br />
</nowiki>}}<br />
{{hc|/etc/acpi/events/vol_u|<nowiki><br />
event=button/volumeup<br />
action=/etc/acpi/handlers/vol +<br />
</nowiki>}}<br />
<br />
as well as another event to toggle the mute setting:<br />
<br />
{{hc|/etc/acpi/events/mute|<nowiki><br />
event=button/mute<br />
action=/usr/bin/amixer set Master toggle<br />
</nowiki>}}<br />
<br />
=== Enabling backlight control ===<br />
<br />
Similar to volume control, acpid also enables you to control screen backlight. To achieve this you write some handler, like this:<br />
<br />
{{hc|/etc/acpi/handlers/bl|<nowiki><br />
#!/bin/sh<br />
bl_dev=/sys/class/backlight/acpi_video0<br />
step=1<br />
<br />
case $1 in<br />
-) echo $((`cat $bl_dev/brightness` - $step)) >$bl_dev/brightness;;<br />
+) echo $((`cat $bl_dev/brightness` + $step)) >$bl_dev/brightness;;<br />
esac<br />
</nowiki>}}<br />
<br />
and again, connect keys to ACPI events:<br />
<br />
{{hc|/etc/acpi/events/bl_d|<nowiki><br />
event=video/brightnessdown<br />
action=/etc/acpi/handlers/bl -<br />
</nowiki>}}<br />
{{hc|/etc/acpi/events/bl_u|<nowiki><br />
event=video/brightnessup<br />
action=/etc/acpi/handlers/bl +<br />
</nowiki>}}<br />
<br />
=== Laptop Monitor Power Off ===<br />
<br />
Adapted from the [http://en.gentoo-wiki.com/wiki/ACPI/Configuration Gentoo Wiki] comes this little gem. Add this to the bottom of {{ic|/etc/acpi/actions/lm_lid.sh}} or to the ''button/lid'' section {{ic|/etc/acpi/handler.sh}}. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force off ;;<br />
open) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force on ;;<br />
esac<br />
<br />
If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.<br />
<br />
Here is another script not using XAUTHORITY but sudo:<br />
<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force off ;;<br />
open) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force on ;;<br />
esac<br />
<br />
With certain combinations of [[Xorg]] and stubborn hardware, {{ic|xset dpms force off}} only blanks the display leaving the backlight turned on. This can be fixed using {{Pkg|vbetool}} from the [[Official Repositories|official repositories]]. Change the LCD section to:<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) vbetool dpms off ;;<br />
open) vbetool dpms on ;;<br />
esac<br />
<br />
If the monitor appears to shut off only briefly before being re-powered, very possibly the power management shipped with xscreensaver conflicts with any manual ''dpms'' settings.<br />
<br />
=== Getting user name of the current display ===<br />
You can use the function {{ic|getuser}} to discover the user of the current display:<br />
getuser ()<br />
{<br />
export DISPLAY=`echo $DISPLAY | cut -c -2`<br />
user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`<br />
export XAUTHORITY=/home/$user/.Xauthority<br />
eval $1=$user<br />
}<br />
<br />
This function can be used for example, when you press the power button and want to shutdown [[KDE]] properly:<br />
button/power)<br />
case "$2" in<br />
PBTN)<br />
getuser "$user"<br />
echo $user > /dev/tty5<br />
su $user -c "dcop ksmserver ksmserver logout 0 2 0"<br />
;;<br />
*) logger "ACPI action undefined $2" ;;<br />
esac<br />
;;<br />
<br />
<br />
On newer systems using systemd, X11 logins are no longer necessarily displayed in {{ic|who}}, so the {{ic|getuser}} function above does not work. An alternative is to use {{ic|loginctl}} to obtain the required information, e.g. using [https://github.com/rephorm/xuserrun xuserrun].<br />
<br />
==See also==<br />
<br />
* http://acpid.sourceforge.net/ - acpid homepage<br />
* http://www.gentoo-wiki.info/ACPI/Configuration - RIP Gentoo wiki entry - New Gentoo Wiki Archives<br />
* [[ACPI hotkeys]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Acpid&diff=247870Acpid2013-02-18T23:53:33Z<p>Eruditorum: /* Enabling volume control */</p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Power management]]<br />
[[it:Acpid]]<br />
[[zh-CN:Acpid]]<br />
<br />
[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering [[ACPI modules|ACPI events]]. It listens on {{ic|/proc/acpi/event}} and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:<br />
* Pressing special keys, including the Power/Sleep/Suspend button<br />
* Closing a notebook lid<br />
* (Un)Plugging an AC power adapter from a notebook<br />
* (Un)Plugging phone jack etc.<br />
<br />
acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.<br />
<br />
{{Note|<br />
* [[Desktop Environment|desktop environments]], such as [[GNOME]], [[Systemd#ACPI power management|systemd]] login manager and some [[Extra Keyboard Keys|extra key handling]] daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.<br />
* Since by default the script provided by acpid, '''/etc/acpi/handler.sh''', will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).}}<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].<br />
<br />
To have it start on boot :<br />
* if you're using [[systemd]], run {{ic|systemctl enable acpid}} ;<br />
* if you're using [[rc.conf|initscripts]], edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]].<br />
<br />
== Configuration ==<br />
<br />
{{Pkg|acpid}} comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in {{ic|/etc/acpi/handler.sh}}, which is executed after any ACPI events are detected (as determined by {{ic|/etc/acpi/events/anything}}).<br />
<br />
The following is a brief example of one such action. In this case, when the Sleep button is pressed, acpid runs the command {{ic|echo -n mem >/sys/power/state}} which ''should'' place the computer into a sleep (suspend) state:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
;;<br />
<br />
Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as ''SLPB'' and on another as ''SBTN''. <br />
<br />
To determine how your buttons or {{Keypress|Fn}} shortcuts are recognized, run the following command from a terminal as root:<br />
# tail -f /var/log/messages.log<br />
<br />
Now press the Power button and/or Sleep button (e.g. {{Keypress|Fn+Esc}}) on your machine. The result should look something this:<br />
logger: ACPI action undefined: PBTN<br />
logger: ACPI action undefined: SBTN<br />
<br />
If that does not work, run:<br />
# acpi_listen<br />
<br />
Then press the power button and you will see something like this:<br />
power/button PBTN 00000000 00000b31<br />
<br />
The output of {{ic|acpi_listen}} is sent to {{ic|/etc/acpi/handler.sh}} as $1, $2 , $3 & $4 parameters.<br />
Example:<br />
$1 power/button<br />
$2 PBTN<br />
$3 00000000<br />
$4 00000b31<br />
<br />
As you might have noticed, the Sleep button in the sample output is actually recognized as ''SBTN'', rather than the ''SLPB'' label specified in the default {{ic|/etc/acpi/handler.sh}}. In order for Sleep function to work properly on this machine, we would need to replace ''SLPB)'' with ''SBTN)''.<br />
<br />
Using this information as a base, you can easily customize the {{ic|/etc/acpi/handler.sh}} file to execute a variety of commands depending on which event is triggered. See the [[Acpid#Tips & Tricks | Tips & Tricks]] section below for other commonly used commands.<br />
<br />
=== Alternative configuration ===<br />
<br />
By default, all ACPI events are passed through the {{ic|/etc/acpi/handler.sh}} script. This is due to the ruleset outlined in {{ic|/etc/acpi/events/anything}}:<br />
# Pass all events to our one handler script<br />
event=.*<br />
action=/etc/acpi/handler.sh %e<br />
<br />
While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:<br />
<br />
As root, create the following file:<br />
{{hc|/etc/acpi/events/sleep-button|<nowiki><br />
event=button sleep.*<br />
action=/etc/acpi/actions/sleep-button.sh "%e"<br />
</nowiki>}}<br />
<br />
Now create the following file:<br />
{{hc|/etc/acpi/actions/sleep-button.sh|<nowiki><br />
#!/bin/sh<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
</nowiki>}}<br />
<br />
Finally, make the script executable: <br />
# chmod +x /etc/acpi/actions/sleep-button.sh<br />
<br />
Using this method, it is easy to create any number of individual event/action scripts.<br />
<br />
==Tips and tricks==<br />
<br />
===Extending acpid with pm-utils===<br />
<br />
Although {{Pkg|acpid}} can provide basic suspend2ram out-of-the-box, a more robust system may be desired. [[pm-utils]] provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, {{ic|pm-suspend}} and {{ic|pm-hibernate}}, both of which can be inserted as events into acpid. For more information, check the [[pm-utils]] wiki.<br />
<br />
===Example Events===<br />
<br />
The following are examples of events that can be used in the {{ic|/etc/acpi/handler.sh}} script. These examples should be modified so that they apply your specific environment e.g. changing the event variable names interpreted by {{ic|acpi_listen}}.<br />
<br />
To lock the screen with {{ic|xscreensaver}} when closing the laptop lid:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
# The lock command need to be run as the user who owns the xscreensaver process and not as root.<br />
# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.<br />
<br />
xs=$(ps -C xscreensaver -o user=)<br />
if test $xs; then su $xs -c "xscreensaver-command -lock"; fi<br />
;;<br />
<br />
To suspend the system and lock the screen using {{ic|slimlock}} when the lid is closed:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
#echo "LID switched!">/dev/tty5<br />
/usr/sbin/pm-suspend &<br />
DISPLAY=:0.0 su -c - username /usr/bin/slimlock<br />
;;<br />
<br />
Execute {{ic|pm-suspend}} when the sleep button is pressed:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SBTN) <br />
#echo -n mem >/sys/power/state<br />
/usr/sbin/pm-suspend<br />
;;<br />
<br />
To set the laptop screen brightness when plugged in power or not (the numbers might need to be adjusted, see {{ic|/sys/class/backlight/acpi_video0/max_brightness}}):<br />
<br />
ac_adapter)<br />
case "$2" in<br />
AC*|AD*)<br />
case "$4" in<br />
00000000)<br />
echo -n 50 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
00000001)<br />
echo -n 100 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
esac<br />
<br />
=== Enabling volume control ===<br />
<br />
Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a script to control the volume (assuming an [[ALSA]] sound card):<br />
<br />
{{hc|/etc/acpi/handlers/vol|<nowiki><br />
#!/bin/sh<br />
step=5<br />
<br />
case $1 in<br />
-) amixer set Master $step-;;<br />
+) amixer set Master $step+;;<br />
esac<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/vol_d|<nowiki><br />
event=button/volumedown<br />
action=/etc/acpi/handlers/vol -<br />
</nowiki>}}<br />
{{hc|/etc/acpi/events/vol_u|<nowiki><br />
event=button/volumeup<br />
action=/etc/acpi/handlers/vol +<br />
</nowiki>}}<br />
<br />
as well as another event to toggle the mute setting:<br />
<br />
{{hc|/etc/acpi/events/mute|<nowiki><br />
event=button/mute<br />
action=/usr/bin/amixer set Master toggle<br />
</nowiki>}}<br />
<br />
=== Enabling backlight control ===<br />
Similar to volume control, acpid also enables you to control screen backlight. To achieve this you write some handler, like this:<br />
<br />
{{hc|/etc/acpi/handlers/bl|<nowiki><br />
#!/bin/sh<br />
bl_dev=/sys/class/backlight/acpi_video0<br />
step=1<br />
<br />
case $1 in<br />
-) echo $((`cat $bl_dev/brightness` - $step)) >$bl_dev/brightness;;<br />
+) echo $((`cat $bl_dev/brightness` + $step)) >$bl_dev/brightness;;<br />
esac<br />
</nowiki>}}<br />
<br />
<br />
and again, connect keys to events:<br />
<br />
{{hc|/etc/acpi/events/bl_d|<nowiki><br />
event=video/brightnessdown<br />
action=/etc/acpi/handlers/bl -<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/events/bl_u|<nowiki><br />
event=video/brightnessup<br />
action=/etc/acpi/handlers/bl +<br />
</nowiki>}}<br />
<br />
=== Laptop Monitor Power Off ===<br />
<br />
Adapted from the [http://en.gentoo-wiki.com/wiki/ACPI/Configuration Gentoo Wiki] comes this little gem. Add this to the bottom of {{ic|/etc/acpi/actions/lm_lid.sh}} or to the ''button/lid'' section {{ic|/etc/acpi/handler.sh}}. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force off ;;<br />
open) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force on ;;<br />
esac<br />
<br />
If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.<br />
<br />
Here is another script not using XAUTHORITY but sudo:<br />
<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force off ;;<br />
open) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force on ;;<br />
esac<br />
<br />
With certain combinations of [[Xorg]] and stubborn hardware, {{ic|xset dpms force off}} only blanks the display leaving the backlight turned on. This can be fixed using {{Pkg|vbetool}} from the [[Official Repositories|official repositories]]. Change the LCD section to:<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) vbetool dpms off ;;<br />
open) vbetool dpms on ;;<br />
esac<br />
<br />
If the monitor appears to shut off only briefly before being re-powered, very possibly the power management shipped with xscreensaver conflicts with any manual ''dpms'' settings.<br />
<br />
=== Getting user name of the current display ===<br />
You can use the function {{ic|getuser}} to discover the user of the current display:<br />
getuser ()<br />
{<br />
export DISPLAY=`echo $DISPLAY | cut -c -2`<br />
user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`<br />
export XAUTHORITY=/home/$user/.Xauthority<br />
eval $1=$user<br />
}<br />
<br />
This function can be used for example, when you press the power button and want to shutdown [[KDE]] properly:<br />
button/power)<br />
case "$2" in<br />
PBTN)<br />
getuser "$user"<br />
echo $user > /dev/tty5<br />
su $user -c "dcop ksmserver ksmserver logout 0 2 0"<br />
;;<br />
*) logger "ACPI action undefined $2" ;;<br />
esac<br />
;;<br />
<br />
<br />
On newer systems using systemd, X11 logins are no longer necessarily displayed in {{ic|who}}, so the {{ic|getuser}} function above does not work. An alternative is to use {{ic|loginctl}} to obtain the required information, e.g. using [https://github.com/rephorm/xuserrun xuserrun].<br />
<br />
==See also==<br />
<br />
* http://acpid.sourceforge.net/ - acpid homepage<br />
* http://www.gentoo-wiki.info/ACPI/Configuration - RIP Gentoo wiki entry - New Gentoo Wiki Archives<br />
* [[ACPI hotkeys]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Acpid&diff=247869Acpid2013-02-18T23:48:42Z<p>Eruditorum: /* Enabling backlight control */</p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Power management]]<br />
[[it:Acpid]]<br />
[[zh-CN:Acpid]]<br />
<br />
[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering [[ACPI modules|ACPI events]]. It listens on {{ic|/proc/acpi/event}} and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:<br />
* Pressing special keys, including the Power/Sleep/Suspend button<br />
* Closing a notebook lid<br />
* (Un)Plugging an AC power adapter from a notebook<br />
* (Un)Plugging phone jack etc.<br />
<br />
acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.<br />
<br />
{{Note|<br />
* [[Desktop Environment|desktop environments]], such as [[GNOME]], [[Systemd#ACPI power management|systemd]] login manager and some [[Extra Keyboard Keys|extra key handling]] daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.<br />
* Since by default the script provided by acpid, '''/etc/acpi/handler.sh''', will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).}}<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].<br />
<br />
To have it start on boot :<br />
* if you're using [[systemd]], run {{ic|systemctl enable acpid}} ;<br />
* if you're using [[rc.conf|initscripts]], edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]].<br />
<br />
== Configuration ==<br />
<br />
{{Pkg|acpid}} comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in {{ic|/etc/acpi/handler.sh}}, which is executed after any ACPI events are detected (as determined by {{ic|/etc/acpi/events/anything}}).<br />
<br />
The following is a brief example of one such action. In this case, when the Sleep button is pressed, acpid runs the command {{ic|echo -n mem >/sys/power/state}} which ''should'' place the computer into a sleep (suspend) state:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
;;<br />
<br />
Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as ''SLPB'' and on another as ''SBTN''. <br />
<br />
To determine how your buttons or {{Keypress|Fn}} shortcuts are recognized, run the following command from a terminal as root:<br />
# tail -f /var/log/messages.log<br />
<br />
Now press the Power button and/or Sleep button (e.g. {{Keypress|Fn+Esc}}) on your machine. The result should look something this:<br />
logger: ACPI action undefined: PBTN<br />
logger: ACPI action undefined: SBTN<br />
<br />
If that does not work, run:<br />
# acpi_listen<br />
<br />
Then press the power button and you will see something like this:<br />
power/button PBTN 00000000 00000b31<br />
<br />
The output of {{ic|acpi_listen}} is sent to {{ic|/etc/acpi/handler.sh}} as $1, $2 , $3 & $4 parameters.<br />
Example:<br />
$1 power/button<br />
$2 PBTN<br />
$3 00000000<br />
$4 00000b31<br />
<br />
As you might have noticed, the Sleep button in the sample output is actually recognized as ''SBTN'', rather than the ''SLPB'' label specified in the default {{ic|/etc/acpi/handler.sh}}. In order for Sleep function to work properly on this machine, we would need to replace ''SLPB)'' with ''SBTN)''.<br />
<br />
Using this information as a base, you can easily customize the {{ic|/etc/acpi/handler.sh}} file to execute a variety of commands depending on which event is triggered. See the [[Acpid#Tips & Tricks | Tips & Tricks]] section below for other commonly used commands.<br />
<br />
=== Alternative configuration ===<br />
<br />
By default, all ACPI events are passed through the {{ic|/etc/acpi/handler.sh}} script. This is due to the ruleset outlined in {{ic|/etc/acpi/events/anything}}:<br />
# Pass all events to our one handler script<br />
event=.*<br />
action=/etc/acpi/handler.sh %e<br />
<br />
While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:<br />
<br />
As root, create the following file:<br />
{{hc|/etc/acpi/events/sleep-button|<nowiki><br />
event=button sleep.*<br />
action=/etc/acpi/actions/sleep-button.sh "%e"<br />
</nowiki>}}<br />
<br />
Now create the following file:<br />
{{hc|/etc/acpi/actions/sleep-button.sh|<nowiki><br />
#!/bin/sh<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
</nowiki>}}<br />
<br />
Finally, make the script executable: <br />
# chmod +x /etc/acpi/actions/sleep-button.sh<br />
<br />
Using this method, it is easy to create any number of individual event/action scripts.<br />
<br />
==Tips and tricks==<br />
<br />
===Extending acpid with pm-utils===<br />
<br />
Although {{Pkg|acpid}} can provide basic suspend2ram out-of-the-box, a more robust system may be desired. [[pm-utils]] provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, {{ic|pm-suspend}} and {{ic|pm-hibernate}}, both of which can be inserted as events into acpid. For more information, check the [[pm-utils]] wiki.<br />
<br />
===Example Events===<br />
<br />
The following are examples of events that can be used in the {{ic|/etc/acpi/handler.sh}} script. These examples should be modified so that they apply your specific environment e.g. changing the event variable names interpreted by {{ic|acpi_listen}}.<br />
<br />
To lock the screen with {{ic|xscreensaver}} when closing the laptop lid:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
# The lock command need to be run as the user who owns the xscreensaver process and not as root.<br />
# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.<br />
<br />
xs=$(ps -C xscreensaver -o user=)<br />
if test $xs; then su $xs -c "xscreensaver-command -lock"; fi<br />
;;<br />
<br />
To suspend the system and lock the screen using {{ic|slimlock}} when the lid is closed:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
#echo "LID switched!">/dev/tty5<br />
/usr/sbin/pm-suspend &<br />
DISPLAY=:0.0 su -c - username /usr/bin/slimlock<br />
;;<br />
<br />
Execute {{ic|pm-suspend}} when the sleep button is pressed:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SBTN) <br />
#echo -n mem >/sys/power/state<br />
/usr/sbin/pm-suspend<br />
;;<br />
<br />
To set the laptop screen brightness when plugged in power or not (the numbers might need to be adjusted, see {{ic|/sys/class/backlight/acpi_video0/max_brightness}}):<br />
<br />
ac_adapter)<br />
case "$2" in<br />
AC*|AD*)<br />
case "$4" in<br />
00000000)<br />
echo -n 50 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
00000001)<br />
echo -n 100 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
esac<br />
<br />
=== Enabling volume control ===<br />
<br />
Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a pair of scripts to control the volume (assuming an [[ALSA]] sound card):<br />
<br />
{{hc|/etc/acpi/actions/volume_up.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%+<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/actions/volume_down.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%-<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/volume_up|<nowiki><br />
event=button[ /]volumeup<br />
action=/etc/acpi/actions/volume_up.sh<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/events/volume_down|<nowiki><br />
event=button[ /]volumedown<br />
action=/etc/acpi/actions/volume_down.sh<br />
</nowiki>}}<br />
<br />
Alternatively, this could be done with two events and a single handler:<br />
{{hc|/etc/acpi/events/vol_d|<nowiki><br />
event=button/volumedown<br />
action=/etc/acpi/actions/vol -<br />
</nowiki>}}<br />
{{hc|/etc/acpi/events/vol_u|<nowiki><br />
event=button/volumeup<br />
action=/etc/acpi/actions/vol +<br />
</nowiki>}}<br />
{{hc|/etc/acpi/actions/vol|<nowiki><br />
#!/bin/sh<br />
step=5<br />
<br />
case $1 in<br />
-) amixer set Master $step-;;<br />
+) amixer set Master $step+;;<br />
esac<br />
</nowiki>}}<br />
<br />
as well as another event to toggle the mute setting:<br />
<br />
{{hc|/etc/acpi/events/mute|<nowiki><br />
event=button/mute<br />
action=/usr/bin/amixer set Master toggle<br />
</nowiki>}}<br />
<br />
=== Enabling backlight control ===<br />
Similar to volume control, acpid also enables you to control screen backlight. To achieve this you write some handler, like this:<br />
<br />
{{hc|/etc/acpi/handlers/bl|<nowiki><br />
#!/bin/sh<br />
bl_dev=/sys/class/backlight/acpi_video0<br />
step=1<br />
<br />
case $1 in<br />
-) echo $((`cat $bl_dev/brightness` - $step)) >$bl_dev/brightness;;<br />
+) echo $((`cat $bl_dev/brightness` + $step)) >$bl_dev/brightness;;<br />
esac<br />
</nowiki>}}<br />
<br />
<br />
and again, connect keys to events:<br />
<br />
{{hc|/etc/acpi/events/bl_d|<nowiki><br />
event=video/brightnessdown<br />
action=/etc/acpi/handlers/bl -<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/events/bl_u|<nowiki><br />
event=video/brightnessup<br />
action=/etc/acpi/handlers/bl +<br />
</nowiki>}}<br />
<br />
=== Laptop Monitor Power Off ===<br />
<br />
Adapted from the [http://en.gentoo-wiki.com/wiki/ACPI/Configuration Gentoo Wiki] comes this little gem. Add this to the bottom of {{ic|/etc/acpi/actions/lm_lid.sh}} or to the ''button/lid'' section {{ic|/etc/acpi/handler.sh}}. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force off ;;<br />
open) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force on ;;<br />
esac<br />
<br />
If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.<br />
<br />
Here is another script not using XAUTHORITY but sudo:<br />
<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force off ;;<br />
open) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force on ;;<br />
esac<br />
<br />
With certain combinations of [[Xorg]] and stubborn hardware, {{ic|xset dpms force off}} only blanks the display leaving the backlight turned on. This can be fixed using {{Pkg|vbetool}} from the [[Official Repositories|official repositories]]. Change the LCD section to:<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) vbetool dpms off ;;<br />
open) vbetool dpms on ;;<br />
esac<br />
<br />
If the monitor appears to shut off only briefly before being re-powered, very possibly the power management shipped with xscreensaver conflicts with any manual ''dpms'' settings.<br />
<br />
=== Getting user name of the current display ===<br />
You can use the function {{ic|getuser}} to discover the user of the current display:<br />
getuser ()<br />
{<br />
export DISPLAY=`echo $DISPLAY | cut -c -2`<br />
user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`<br />
export XAUTHORITY=/home/$user/.Xauthority<br />
eval $1=$user<br />
}<br />
<br />
This function can be used for example, when you press the power button and want to shutdown [[KDE]] properly:<br />
button/power)<br />
case "$2" in<br />
PBTN)<br />
getuser "$user"<br />
echo $user > /dev/tty5<br />
su $user -c "dcop ksmserver ksmserver logout 0 2 0"<br />
;;<br />
*) logger "ACPI action undefined $2" ;;<br />
esac<br />
;;<br />
<br />
<br />
On newer systems using systemd, X11 logins are no longer necessarily displayed in {{ic|who}}, so the {{ic|getuser}} function above does not work. An alternative is to use {{ic|loginctl}} to obtain the required information, e.g. using [https://github.com/rephorm/xuserrun xuserrun].<br />
<br />
==See also==<br />
<br />
* http://acpid.sourceforge.net/ - acpid homepage<br />
* http://www.gentoo-wiki.info/ACPI/Configuration - RIP Gentoo wiki entry - New Gentoo Wiki Archives<br />
* [[ACPI hotkeys]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Acpid&diff=247868Acpid2013-02-18T23:33:26Z<p>Eruditorum: /* Enabling volume control */</p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Power management]]<br />
[[it:Acpid]]<br />
[[zh-CN:Acpid]]<br />
<br />
[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering [[ACPI modules|ACPI events]]. It listens on {{ic|/proc/acpi/event}} and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:<br />
* Pressing special keys, including the Power/Sleep/Suspend button<br />
* Closing a notebook lid<br />
* (Un)Plugging an AC power adapter from a notebook<br />
* (Un)Plugging phone jack etc.<br />
<br />
acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.<br />
<br />
{{Note|<br />
* [[Desktop Environment|desktop environments]], such as [[GNOME]], [[Systemd#ACPI power management|systemd]] login manager and some [[Extra Keyboard Keys|extra key handling]] daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.<br />
* Since by default the script provided by acpid, '''/etc/acpi/handler.sh''', will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).}}<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].<br />
<br />
To have it start on boot :<br />
* if you're using [[systemd]], run {{ic|systemctl enable acpid}} ;<br />
* if you're using [[rc.conf|initscripts]], edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]].<br />
<br />
== Configuration ==<br />
<br />
{{Pkg|acpid}} comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in {{ic|/etc/acpi/handler.sh}}, which is executed after any ACPI events are detected (as determined by {{ic|/etc/acpi/events/anything}}).<br />
<br />
The following is a brief example of one such action. In this case, when the Sleep button is pressed, acpid runs the command {{ic|echo -n mem >/sys/power/state}} which ''should'' place the computer into a sleep (suspend) state:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
;;<br />
<br />
Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as ''SLPB'' and on another as ''SBTN''. <br />
<br />
To determine how your buttons or {{Keypress|Fn}} shortcuts are recognized, run the following command from a terminal as root:<br />
# tail -f /var/log/messages.log<br />
<br />
Now press the Power button and/or Sleep button (e.g. {{Keypress|Fn+Esc}}) on your machine. The result should look something this:<br />
logger: ACPI action undefined: PBTN<br />
logger: ACPI action undefined: SBTN<br />
<br />
If that does not work, run:<br />
# acpi_listen<br />
<br />
Then press the power button and you will see something like this:<br />
power/button PBTN 00000000 00000b31<br />
<br />
The output of {{ic|acpi_listen}} is sent to {{ic|/etc/acpi/handler.sh}} as $1, $2 , $3 & $4 parameters.<br />
Example:<br />
$1 power/button<br />
$2 PBTN<br />
$3 00000000<br />
$4 00000b31<br />
<br />
As you might have noticed, the Sleep button in the sample output is actually recognized as ''SBTN'', rather than the ''SLPB'' label specified in the default {{ic|/etc/acpi/handler.sh}}. In order for Sleep function to work properly on this machine, we would need to replace ''SLPB)'' with ''SBTN)''.<br />
<br />
Using this information as a base, you can easily customize the {{ic|/etc/acpi/handler.sh}} file to execute a variety of commands depending on which event is triggered. See the [[Acpid#Tips & Tricks | Tips & Tricks]] section below for other commonly used commands.<br />
<br />
=== Alternative configuration ===<br />
<br />
By default, all ACPI events are passed through the {{ic|/etc/acpi/handler.sh}} script. This is due to the ruleset outlined in {{ic|/etc/acpi/events/anything}}:<br />
# Pass all events to our one handler script<br />
event=.*<br />
action=/etc/acpi/handler.sh %e<br />
<br />
While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:<br />
<br />
As root, create the following file:<br />
{{hc|/etc/acpi/events/sleep-button|<nowiki><br />
event=button sleep.*<br />
action=/etc/acpi/actions/sleep-button.sh "%e"<br />
</nowiki>}}<br />
<br />
Now create the following file:<br />
{{hc|/etc/acpi/actions/sleep-button.sh|<nowiki><br />
#!/bin/sh<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
</nowiki>}}<br />
<br />
Finally, make the script executable: <br />
# chmod +x /etc/acpi/actions/sleep-button.sh<br />
<br />
Using this method, it is easy to create any number of individual event/action scripts.<br />
<br />
==Tips and tricks==<br />
<br />
===Extending acpid with pm-utils===<br />
<br />
Although {{Pkg|acpid}} can provide basic suspend2ram out-of-the-box, a more robust system may be desired. [[pm-utils]] provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, {{ic|pm-suspend}} and {{ic|pm-hibernate}}, both of which can be inserted as events into acpid. For more information, check the [[pm-utils]] wiki.<br />
<br />
===Example Events===<br />
<br />
The following are examples of events that can be used in the {{ic|/etc/acpi/handler.sh}} script. These examples should be modified so that they apply your specific environment e.g. changing the event variable names interpreted by {{ic|acpi_listen}}.<br />
<br />
To lock the screen with {{ic|xscreensaver}} when closing the laptop lid:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
# The lock command need to be run as the user who owns the xscreensaver process and not as root.<br />
# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.<br />
<br />
xs=$(ps -C xscreensaver -o user=)<br />
if test $xs; then su $xs -c "xscreensaver-command -lock"; fi<br />
;;<br />
<br />
To suspend the system and lock the screen using {{ic|slimlock}} when the lid is closed:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
#echo "LID switched!">/dev/tty5<br />
/usr/sbin/pm-suspend &<br />
DISPLAY=:0.0 su -c - username /usr/bin/slimlock<br />
;;<br />
<br />
Execute {{ic|pm-suspend}} when the sleep button is pressed:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SBTN) <br />
#echo -n mem >/sys/power/state<br />
/usr/sbin/pm-suspend<br />
;;<br />
<br />
To set the laptop screen brightness when plugged in power or not (the numbers might need to be adjusted, see {{ic|/sys/class/backlight/acpi_video0/max_brightness}}):<br />
<br />
ac_adapter)<br />
case "$2" in<br />
AC*|AD*)<br />
case "$4" in<br />
00000000)<br />
echo -n 50 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
00000001)<br />
echo -n 100 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
esac<br />
<br />
=== Enabling volume control ===<br />
<br />
Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a pair of scripts to control the volume (assuming an [[ALSA]] sound card):<br />
<br />
{{hc|/etc/acpi/actions/volume_up.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%+<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/actions/volume_down.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%-<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/volume_up|<nowiki><br />
event=button[ /]volumeup<br />
action=/etc/acpi/actions/volume_up.sh<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/events/volume_down|<nowiki><br />
event=button[ /]volumedown<br />
action=/etc/acpi/actions/volume_down.sh<br />
</nowiki>}}<br />
<br />
Alternatively, this could be done with two events and a single handler:<br />
{{hc|/etc/acpi/events/vol_d|<nowiki><br />
event=button/volumedown<br />
action=/etc/acpi/actions/vol -<br />
</nowiki>}}<br />
{{hc|/etc/acpi/events/vol_u|<nowiki><br />
event=button/volumeup<br />
action=/etc/acpi/actions/vol +<br />
</nowiki>}}<br />
{{hc|/etc/acpi/actions/vol|<nowiki><br />
#!/bin/sh<br />
step=5<br />
<br />
case $1 in<br />
-) amixer set Master $step-;;<br />
+) amixer set Master $step+;;<br />
esac<br />
</nowiki>}}<br />
<br />
as well as another event to toggle the mute setting:<br />
<br />
{{hc|/etc/acpi/events/mute|<nowiki><br />
event=button/mute<br />
action=/usr/bin/amixer set Master toggle<br />
</nowiki>}}<br />
<br />
=== Enabling backlight control ===<br />
<br />
Find out the acpi identity of the brightness buttons (see above) and susbtitute it for the acpi events in the files below:<br />
<br />
{{hc|/etc/acpi/actions/bl_up.sh|<nowiki><br />
#!/bin/sh<br />
bl_device=/sys/class/backlight/acpi_video0/<br />
echo $(($(cat $bl_device)+1)) >$bl_device<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/actions/bl_down.sh|<nowiki><br />
#!/bin/sh<br />
bl_device=/sys/class/backlight/acpi_video0/<br />
echo $(($(cat $bl_device)-1)) >$bl_device<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/bl_up|<nowiki><br />
event=video[ /]brightnessup<br />
action=/etc/acpi/actions/bl_up.sh<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/events/bl_down|<nowiki><br />
event=video[ /]brightnessdown<br />
action=/etc/acpi/actions/bl_down.sh<br />
</nowiki>}}<br />
<br />
=== Laptop Monitor Power Off ===<br />
<br />
Adapted from the [http://en.gentoo-wiki.com/wiki/ACPI/Configuration Gentoo Wiki] comes this little gem. Add this to the bottom of {{ic|/etc/acpi/actions/lm_lid.sh}} or to the ''button/lid'' section {{ic|/etc/acpi/handler.sh}}. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force off ;;<br />
open) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force on ;;<br />
esac<br />
<br />
If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.<br />
<br />
Here is another script not using XAUTHORITY but sudo:<br />
<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force off ;;<br />
open) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force on ;;<br />
esac<br />
<br />
With certain combinations of [[Xorg]] and stubborn hardware, {{ic|xset dpms force off}} only blanks the display leaving the backlight turned on. This can be fixed using {{Pkg|vbetool}} from the [[Official Repositories|official repositories]]. Change the LCD section to:<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) vbetool dpms off ;;<br />
open) vbetool dpms on ;;<br />
esac<br />
<br />
If the monitor appears to shut off only briefly before being re-powered, very possibly the power management shipped with xscreensaver conflicts with any manual ''dpms'' settings.<br />
<br />
=== Getting user name of the current display ===<br />
You can use the function {{ic|getuser}} to discover the user of the current display:<br />
getuser ()<br />
{<br />
export DISPLAY=`echo $DISPLAY | cut -c -2`<br />
user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`<br />
export XAUTHORITY=/home/$user/.Xauthority<br />
eval $1=$user<br />
}<br />
<br />
This function can be used for example, when you press the power button and want to shutdown [[KDE]] properly:<br />
button/power)<br />
case "$2" in<br />
PBTN)<br />
getuser "$user"<br />
echo $user > /dev/tty5<br />
su $user -c "dcop ksmserver ksmserver logout 0 2 0"<br />
;;<br />
*) logger "ACPI action undefined $2" ;;<br />
esac<br />
;;<br />
<br />
<br />
On newer systems using systemd, X11 logins are no longer necessarily displayed in {{ic|who}}, so the {{ic|getuser}} function above does not work. An alternative is to use {{ic|loginctl}} to obtain the required information, e.g. using [https://github.com/rephorm/xuserrun xuserrun].<br />
<br />
==See also==<br />
<br />
* http://acpid.sourceforge.net/ - acpid homepage<br />
* http://www.gentoo-wiki.info/ACPI/Configuration - RIP Gentoo wiki entry - New Gentoo Wiki Archives<br />
* [[ACPI hotkeys]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=DSDT&diff=244953DSDT2013-01-24T06:15:00Z<p>Eruditorum: /* Tell the kernel to report a version of Windows */</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:Kernel]]<br />
[[Category:Power management]]<br />
DSDT (Differentiated System Description Table) is a part of the [[Wikipedia:ACPI|ACPI]] specification. It supplies information about supported power events in a given system. ACPI tables are provided in firmware from the manufacturer. A common Linux problems are missing ACPI functionality, such as: fans not running, screens not turning off when the lid is closed, etc. This can stem from DSDTs made with Windows specifically in mind, which can be patched after installation. The goal of this article is to analyze and rebuild a faulty DSDT, so that the kernel can override the default one.<br />
<br />
{{Note|The goal of the [http://www.lesswatts.org/projects/acpi/ Linux ACPI] project is that Linux should work on unmodified firmware. If you still find this type of workaround necessary on modern kernels then you should consider [[Reporting Bug Guidelines|submiting a bug report]]. }}<br />
<br />
==Before you start...==<br />
* It is possible that the hardware manufacturer has released an updated firmware which fixes ACPI related problems. Installing an updated firmware is often preferred over this method because it would avoid duplication of effort.<br />
* This process does tamper with some fairly fundamental code on your installation. You will want to be absolutely sure of the changes you make. You might also wish to [[Disk cloning | clone your disk]] beforehand.<br />
* Even before attempting to fix your DSDT yourself, you can attempt a couple of different shortcuts: <br />
<br />
===Tell the kernel to report a version of Windows===<br />
<br />
Use the variable '''acpi_os_name''' as a kernel parameter. For example:<br />
<br />
acpi_os_name="Microsoft Windows NT"<br />
appended to the kernel line in grub legacy configuration<br />
<br />
other strings to test:<br />
* "Microsoft Windows XP"<br />
* "Microsoft Windows 2000"<br />
* "Microsoft Windows 2000.1"<br />
* "Microsoft Windows ME: Millennium Edition"<br />
* "Windows 2001"<br />
* "Windows 2006"<br />
* "Windows 2009"<br />
* when all that fails, you can even try "Linux"<br />
<br />
Out of curiousity, you can follow the steps below to extract your DSDT and search the .dsl file. Just grep for "Windows" and see what pops up.<br />
<br />
===Find a fixed DSDT===<br />
A DSDT file is originally written in ACPI Source language (an .asl/.dsl file). Using a compiler this can produce an 'ACPI Machine Language' file (.aml) or a hex table (.hex). To incorporate the file in your Arch install, you will need to get hold of a compiled .aml file. - whether this means compiling it yourself or trusting some stranger on the Internet is at your discretion. If you do download a file from the world wide web, it will most likely be a compressed .asl file. So you will need to unzip it and compile it. The upside to this is that you won't have to research specific code fixes yourself.<br />
<br />
Arch users with the same laptop as you are: a minority of a minority of a minority. Try browsing other distro/linux forums for talk about the same model. Likelihood is that they have the same problems and either because there is a lot of them, or because they're tech savvy -- someone there has produced a working DSDT and maybe even provides a precompiled version (again, use at your own risk).<br />
Search engines are your best tools. Try keeping it short: 'model name' + 'dsdt' will probably produce results.<br />
<br />
== Recompiling it yourself ==<br />
Your best resources in this endeavor are going to be [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems The Gentoo wiki article], [http://www.acpi.info ACPI Spec homepage], and [http://www.lesswatts.org/projects/acpi/ Linux ACPI Project] which supercedes the activity that occurred at ''acpi.sourceforge.net''.<br />
In a nutshell, you can use Intel's ASL compiler to turn your systems DSDT table into source code, locate/fix the errors, and recompile. This process is detailed more comprehensively at the [http://en.gentoo-wiki.com/wiki/ACPI/Fix_common_problems Gentoo wiki].<br />
You'll need to install {{Pkg|iasl}} to modify code, and be familiar with [[Kernel_Compilation#Compilation]] to install it.<br />
<br />
'''What compiled the original code?'''<br />
Check if your system's DSDT was compiled using Intel or Microsoft compiler:<br />
{{hc|<nowiki> $ dmesg|grep DSDT</nowiki> |<br />
ACPI: DSDT 00000000bf7e5000 0A35F (v02 Intel CALPELLA 06040000 INTL 20060912)<br />
ACPI: EC: Look up EC in DSDT<br />
}}<br />
In case Microsoft's compiler had been used, words INTL would instead be MSFT.<br />
In the example, there were 5 errors on decompiling/recompiling the DSDT. Two of them were easy to fix after a bit of googling and delving into the ACPI specification. Three of them were due to different versions of compiler used and are, as later discovered, handled by the ACPICA at boot-time. The ACPICA component of the kernel can handle most of the trivial errors you get while compiling the DSDT. So do not fret yourself over compile errors if your system is working the way it should.<br />
<br />
1.) Extract ACPI tables (as root): {{ic|# cat /sys/firmware/acpi/tables/DSDT > dsdt.dat}}<br />
<br />
2.) Decompile: {{ic|iasl -d dsdt.dat}}<br />
<br />
3.) Recompile: {{ic|iasl -tc dsdt.dsl}}<br />
<br />
4.) Examine errors and fix. e.g.:{{bc|<br />
dsdt.dsl 6727: Name (_PLD, Buffer (0x10) <br />
Error 4105 - Invalid object type for reserved name ^ (found BUFFER, requires Package) }}<br />
{{hc| nano +6727 dsdt.dsl|<br />
(_PLD, Package(1) {Buffer (0x10)...}}<br />
<br />
5.) Compile fixed code: {{ic|iasl -tc dsdt.dsl}} (Might want to try option -ic for C include file to insert into kernel source)<br />
<br />
If it says no errors and no warnings you should be good to go.<br />
<br />
6.) Insert code into kernel source.<br />
<br />
You'll want to be familiar with [[Kernels | compiling your own kernel]]. The most straightforward way is with the "traditional" approach.<br />
<br />
Using ''make menuconfig'':<br />
* Disable "Select only drivers that don't need compile-time external firmware".<br />
* Enable "Include Custom DSDT" and specify the absolute path of your fixed DSDT file.</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Netcfg&diff=244936Netcfg2013-01-23T22:23:57Z<p>Eruditorum: DHCP_TIMEOUT info</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Networking]]<br />
[[es:Netcfg]]<br />
[[fr:Netcfg]]<br />
[[it:Netcfg]]<br />
[[ja:Netcfg]]<br />
[[ro:Netcfg]]<br />
[[ru:Netcfg]]<br />
[[tr:netcfg]]<br />
[[zh-CN:Netcfg]]<br />
{{Article summary start}}<br />
{{Article summary text|A guide to configuring the network using netcfg and network profile scripts.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Networking overview}}}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary wiki|Netcfg Tips}}<br />
{{Article summary wiki|Netcfg Troubleshooting}}<br />
{{Article summary link|Netcfg network scripts repository|https://projects.archlinux.org/netcfg.git/}}<br />
{{Article summary end}}<br />
<br />
Netcfg is used to configure and manage network connections via profiles. It has pluggable support for a range of connection types, such as wireless, Ethernet and [[Wikipedia:Point-to-point_protocol|PPP]]. It is also capable of starting/stopping many-to-one connections, that is, multiple connections within the same profile, optionally with bonding. Further it is useful for users seeking a simple and robust means of managing multiple network configurations (e.g. laptop users).<br />
<br />
== Preparation ==<br />
<br />
In the simplest cases, users must at least know the name of their network interface(s) (e.g. {{ic|eth0}}, {{ic|wlan0}}). If configuring a static IP address, the IP addresses of the default gateway and name server(s) must also be known.<br />
<br />
If connecting to a wireless network, have some basic information ready. For a wireless network this includes what type of security is used, the network name (ESSID), and any passphrase or encryption keys. Additionally, ensure the proper drivers and firmware are installed for the wireless device, as described in [[Wireless Setup]].<br />
<br />
== Installation ==<br />
<br />
The {{Pkg|netcfg}} package is available in the [[Official Repositories|official repositories]]. As of {{Pkg|netcfg}} version 2.5.x, optional dependencies include {{Pkg|wpa_actiond}}, which is required for automatic/roaming wireless connections, and {{Pkg|ifplugd}}, which is required for automatic Ethernet configuration. See [https://www.archlinux.org/news/487/ the announcement].<br />
<br />
Users wanting [[Bash]] completion support for netcfg, install the {{Pkg|bash-completion}} package from the official repositories.<br />
<br />
== Configuration ==<br />
{{Note|1={{Pkg|netcfg}} >= 2.8.9 drops deprecated {{ic|/etc/[[rc.conf]]}} compatibility. Netcfg users should configure all interfaces in {{ic|/etc/conf.d/netcfg}} instead of {{ic|/etc/rc.conf}}.}}<br />
<br />
Network profiles are stored in {{ic|/etc/network.d/}}. To minimize the potential for errors, copy an example configuration from {{ic|/etc/network.d/examples/}} to {{ic|/etc/network.d/mynetwork}}. The file name is the name of the network profile, and {{ic|mynetwork}} is used as an example throughout this article.<br />
<br />
Depending on the connection type and security, use one of the following examples from {{ic|/etc/network.d/examples/}} as a base.<br />
<br />
{{Warning|Be wary of examples found on the internet as they often contain deprecated options that may cause problems!}}<br />
<br />
{| class="wikitable" align="center"<br />
! Connection !! Type !! Example Profile !! Information<br />
|-<br />
| rowspan="3"| '''Wired'''<br />
| Dynamic IP || {{ic|ethernet-dhcp}} ||<br />
|-<br />
| Static IP || {{ic|ethernet-static}} ||<br />
|-<br />
| Routed || {{ic|ethernet-iproute}} || Can be checked with {{ic|route}} from the {{Pkg|net-tools}} package.<br />
|-<br />
| rowspan="3"| '''Wireless'''<br />
| WPA-Personal<br />
| {{ic|wireless-wpa}} || Uses a passphrase/pre-shared key.<br />
|-<br />
| rowspan="2"| WPA-Enterprise<br />
| {{ic|wireless-wpa-config}} || The {{Pkg|wpa_supplicant}} configuration is external.<br />
|-<br />
| {{ic|wireless-wpa-configsection}} || The {{Pkg|wpa_supplicant}} configuration is stored as a string.<br />
|}<br />
<br />
Modify the new configuration file, {{ic|/etc/network.d/mynetwork}}:<br />
<br />
* Set {{ic|INTERFACE}} to the correct wireless or Ethernet interface. This can be checked with {{ic|ip link}} and {{ic|iwconfig}}.<br />
* Ensure the {{ic|ESSID}} and {{ic|KEY}} (passphrase) are set correctly for wireless connections. Typos in these fields are common errors.<br />
** Note that WEP ''string'' keys (not ''hex'' keys) must be specified with a leading {{ic|s:}} (e.g. {{ic|1=KEY="s:''somepasskey''"}}).<br />
<br />
{{Note|If you are using netcfg inside a VPS, please see [[Virtual_Private_Server#Moving_your_VPS_from_network_configuration_in_rc.conf_to_netcfg_.28tested_with_OpenVZ.29|the appropriate page]].}}<br />
<br />
{{Note|Netcfg configurations are valid Bash scripts. Any configuration involving special characters such as {{ic|$}} or {{ic|\}} needs to be quoted correctly otherwise it will be interpreted by Bash. To avoid interpretation, use single quotes or backslash escape characters where appropriate.}}<br />
<br />
{{Note|Network information (e.g. wireless passkey) will be stored in plain text format, so users may want to change the permissions on the newly created profile (e.g. {{ic|chmod 0600 /etc/network.d/mynetwork}}) to make it readable by root only.}}<br />
<br />
{{Note|For WPA-Personal, it is also possible to [[Wpa_supplicant#Classic_method:_.2Fetc.2Fwpa_supplicant.conf|encode the WPA passkey into a hexadecimal string]]. Save the new hexadecimal string into the wireless WPA profile in {{ic|/etc/network.d/mynetwork}} as the value of the {{ic|KEY}} variable (make sure this will be the only {{ic|KEY}} variable enabled), to look similar to this: {{ic|1=KEY='7b271c9a7c8a6ac07d12403a1f0792d7d92b5957ff8dfd56481ced43ec6a6515'}}. However, this key can also be used by anyone to get on your network, and thus must be protected just as well as the cleartext key. The hexadecimal encoding is more convenient if you use special characters that are hard to express in scripts.}}<br />
<br />
{{<br />
Note|1=By default netcfg uses dhcpcd for configuring network interfaces. An alternate to dhcpcd is dhclient. To use dhclient, set DHCLIENT='yes' in appropriate profile configuration.<br />
}}<br />
<br />
== Manual Operation ==<br />
<br />
To connect a profile:<br />
<br />
# netcfg mynetwork<br />
<br />
To disconnect a profile:<br />
<br />
# netcfg down mynetwork<br />
<br />
If successful, users can configure netcfg to connect automatically or during boot. If the connection fails, see [[Netcfg Troubleshooting]] for solutions and for how to ask for help.<br />
<br />
Additionally, see:<br />
<br />
$ netcfg help<br />
<br />
== Automatic Operation ==<br />
<br />
=== Just one profile ===<br />
<br />
In the simplest case, only one profile will be used and is always desired to start on boot:<br />
<br />
# systemctl enable netcfg@myprofile<br />
<br />
=== Net-Profiles ===<br />
<br />
Edit the {{ic|NETWORKS}} array in {{ic|/etc/conf.d/netcfg}} to refer to the network config file {{ic|/etc/network.d/mynetwork}}.<br />
<br />
{{hc|/etc/conf.d/netcfg|2=<br />
NETWORKS=(mynetwork yournetwork)}}<br />
<br />
Start the service on startup:<br />
<br />
# systemctl enable netcfg<br />
<br />
Alternatively, the profiles that were active at last shutdown can be restored by setting the {{ic|NETWORKS}} array to {{ic|last}}.<br />
<br />
{{hc|/etc/conf.d/netcfg|2=<br />
NETWORKS=(last)}}<br />
<br />
{{Note|For {{ic|NETWORKS&#61;(last)}} to work, you will have to connect to your network manually first and then stop the daemon for Netcfg to remember the network. You can stop the Netcfg daemon by running {{ic|netcfg-daemon stop}} as root.}}<br />
<br />
Finally, {{ic|net-profiles}} can be configured to display a menu&mdash;allowing users to choose a desired profile&mdash;by setting the contents of the {{ic|NETWORKS}} array to {{ic|menu}}:<br />
<br />
{{hc|/etc/conf.d/netcfg|2=<br />
NETWORKS=(menu)}}<br />
<br />
Additionally, the {{Pkg|dialog}} package is required.<br />
<br />
{{Note|The {{ic|1=NETWORKS=(menu)}} setting cannot be used anymore when switching to systemd. See {{bug|31377}} for details.}}<br />
<br />
{{Tip|Access the menu at any time by running {{ic|netcfg-menu}} in a terminal.}}<br />
<br />
=== Net-Auto-Wireless ===<br />
<br />
This allows users to automatically connect to wireless networks with proper roaming support. To use this feature, the {{Pkg|wpa_actiond}} package is required. Note that {{ic|wireless-wpa-config}} profiles do not work with {{ic|net-auto-wireless}}. Convert them to {{ic|wireless-wpa-configsection}} or {{ic|wireless-wpa}} instead.<br />
<br />
Specify the desired wireless interface with the {{ic|WIRELESS_INTERFACE}} variable in {{ic|/etc/conf.d/netcfg}} or define a list of wireless networks that should be automatically connected with the {{ic|AUTO_PROFILES}} variable in {{ic|/etc/conf.d/netcfg}}.<br />
<br />
{{Note|If AUTO_PROFILES is not set, all wireless networks will be tried.}}<br />
{{Note|1=By default, wpa_actiond sets dhcp timeout to 10 seconds (line 16 of /usr/bin/netcfg-wpa_actiond-action) which may be not enough for all users to always get an IP-address successfully. To override this, for example with classic 30 seconds timeout, write DHCP_TIMEOUT=30 to /etc/conf.d/netcfg}}<br />
Enable {{ic|net-auto-wireless.service}} so systemd manages it.<br />
<br />
# systemctl enable net-auto-wireless.service<br />
<br />
=== Net-Auto-Wired ===<br />
<br />
This allows users to automatically connect to wired networks. To use this feature, the {{Pkg|ifplugd}} package is required.<br />
<br />
Specify the desired wired interface with the {{ic|WIRED_INTERFACE}} variable in {{ic|/etc/conf.d/netcfg}}.<br />
<br />
Enable {{ic|net-auto-wired.service}} so systemd manages it.<br />
<br />
# systemctl enable net-auto-wired<br />
<br />
The daemon starts an {{ic|ifplugd}} process which runs {{ic|/etc/ifplugd/netcfg.action}} when the status of the wired interface changes (e.g. a cable is plugged in or unplugged). On plugging in a cable, attempts are made to start any profiles with {{ic|1=CONNECTION = "ethernet"}} or {{ic|"ethernet-iproute"}} and {{ic|1=INTERFACE = WIRED_INTERFACE}} until one of them succeeds.<br />
<br />
{{Note|DHCP profiles are tried before static ones, which could lead to undesired results in some cases. However, one can tell netcfg to prefer a particular interface by adding {{ic|1=AUTO_WIRED=1}} to the desired profile.}}<br />
<br />
{{Note|The {{ic|net-auto-wired}} daemon cannot start multiple ifplugd processes for multiple interfaces (unlike ifplugd's own {{ic|/etc/rc.d/ifplugd}} which can).}}<br />
<br />
== FAQ ==<br />
<br />
{{FAQ<br />
|question=Why doesn't netcfg do ''(some feature)''?<br />
|answer=Netcfg does not need to; it connects to networks. Netcfg is modular and re-usable. See {{ic|/usr/lib/network}} for re-usable functions for custom scripts.}}<br />
<br />
{{FAQ<br />
|question=Why doesn't netcfg behave in ''this'' way?<br />
|answer=Netcfg does not enforce any rules; it connects to networks. Netcfg does not impose any heuristics, like "disconnect from wireless if Ethernet is connected". If you want such behavior, it should be simple to write a separate tool on top of netcfg. See the question above. Alternatively, you could be creative with the use of netcfg's {{ic|POST_UP}} functionality to handle some use cases.}}<br />
<br />
{{FAQ<br />
|question=Do I need anything else if I'm using netcfg?<br />
|answer=This question usually references {{ic|/etc/hosts}} and {{ic|/etc/hostname}}, which are both still required.}}</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=GRUB&diff=238486GRUB2012-12-05T05:51:09Z<p>Eruditorum: /* LVM */</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[cs:GRUB2]]<br />
[[de:GRUB]]<br />
[[es:GRUB2]]<br />
[[fr:GRUB2]]<br />
[[id:GRUB2]]<br />
[[it:GRUB2]]<br />
[[ru:GRUB2]]<br />
[[tr:GRUB2]]<br />
[[zh-CN:GRUB2]]<br />
[[zh-TW:GRUB2]]<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|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Burg}} - Burg is a brand-new boot loader based on GRUB2. It uses a new object format which allows it to be built in a wider range of OS, including Linux, Windows, OS X, Solaris, FreeBSD, etc. It also has a highly configurable menu system which works in both text and graphic mode. <br />
{{Article summary heading|Resources}}<br />
{{Article summary wiki|GRUB_EFI_Examples}}<br />
{{Article summary link|GNU GRUB -- GNU Project|https://www.gnu.org/software/grub/}}<br />
{{Article summary end}}<br />
<br />
[https://www.gnu.org/software/grub/ 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. GRUB2 has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
In brief, 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 />
== Preface ==<br />
Here is some information that needs to be clarified:<br />
* The name ''GRUB'' officially refers to version ''2'' of the software, see [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
<br />
* From 1.99-6 onwards, GRUB2 supports [[Btrfs]] as root (without a separate {{ic|/boot}} filesystem) compressed with either zlib or LZO.<br />
<br />
* For GRUB2 UEFI info, it is recommended to read the [[UEFI]], [[GPT]] and [[UEFI_Bootloaders]] pages before reading this page.<br />
<br />
=== Notes for current GRUB Legacy users ===<br />
* Upgrade from [[GRUB Legacy]] to [[GRUB]](2) is the much same as fresh installing GRUB(2)which is covered [[#Installation|below]].<br />
<br />
* There are differences in the commands of GRUB and GRUB2. Familiarize yourself with [https://www.gnu.org/software/grub/manual/grub.html#Commands 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, and prefixed with partition-table type. For example, {{ic|/dev/sda1}} would be referred to as {{ic|(hd0,msdos1)}} (for MBR) or {{ic|(hd0,gpt1)}} (for GPT) using GRUB2.<br />
<br />
=== Preliminary Requirements for GRUB2 ===<br />
<br />
==== BIOS systems ====<br />
<br />
===== [[GPT]] specific instructions =====<br />
<br />
GRUB2 in BIOS-GPT configuration requires a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html#BIOS-installation BIOS Boot Partition] to embed its {{ic|core.img}} in the absence of post-MBR gap in GPT partitioned systems (which is taken over by the GPT Primary Header and Primary Partition table). This partition is used by GRUB2 only in BIOS-GPT setups. No such partition type exists in case of MBR partitioning (at least not for GRUB2). This partition is also not required if the system is UEFI based, as no embedding of bootsectors takes place in that case. Syslinux does not require this partition.<br />
<br />
For a BIOS-GPT configuration, create a 2 MiB partition using cgdisk or GNU Parted with no filesystem. The location of the partition in the partition table does not matter but it should be within the first 2 TiB region of the disk. It is advisable to put it somewhere in the beginning of the disk before the {{ic|/boot}} partition. Set the partition type to "EF02" in cgdisk or {{ic|set <BOOT_PART_NUM> bios_grub on}} in GNU Parted.<br />
<br />
{{Note|This partition should be created before {{ic|grub-install}} or {{ic|grub-setup}} is run or before the '''Install Bootloader''' step of the Archlinux installer (if GRUB2 BIOS is selected as bootloader).}}<br />
<br />
===== [[MBR]] aka msdos partitioning specific instructions =====<br />
<br />
Usually the post-MBR gap (after the 512 byte MBR region and before the start of the 1st partition) in many MBR (or msdos disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB2's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioner which supports 1 MiB partition alignment to obtain this space as well as satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
MBR partitioning has better support in other operating systems, such as Microsoft Windows (up to Windows 7) and Haiku, than GPT partitioning. If you dual boot another operating system, consider using MBR partitioning.<br />
<br />
{{Warning|Create the 2MiB partition mentioned above BEFORE you convert to GPT. If you do not, gparted will not resize your boot partition to allow its creation, and when you reboot GRUB2 will not know where to look.}}<br />
<br />
[[GUID_Partition_Table#Convert_from_MBR_to_GPT]]<br />
<br />
==== UEFI systems ====<br />
===== Preface =====<br />
{{Note|It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI_Bootloaders]] pages.}}<br />
<br />
===== Create and Mount the UEFI SYSTEM PARTITION =====<br />
<br />
Follow [[Unified_Extensible_Firmware_Interface#Create_an_UEFI_System_Partition_in_Linux]] for instructions on creating a UEFI SYSTEM PARTITION. Then mount the UEFI SYSTEM PARTITION at {{ic|/boot/efi}}. If you have mounted the UEFISYS partition in some other mountpoint, replace {{ic|/boot/efi}} in the below instructions with that mountpoint:<br />
<br />
# mkdir -p /boot/efi<br />
# mount -t vfat <UEFISYS_PART_DEVICE> /boot/efi<br />
<br />
Create a <UEFI_SYSTEM_PARTITION>{{ic|/EFI}} directory, if it does not exist:<br />
<br />
# mkdir -p /boot/efi/EFI<br />
<br />
== Installation ==<br />
<br />
=== BIOS systems ===<br />
<br />
==== Backup Important Data ====<br />
<br />
Although a GRUB(2) installation should run smoothly, it is strongly recommended to keep the GRUB Legacy files before installing {{Pkg|grub-bios}}.<br />
<br />
# mv /boot/grub /boot/grub-legacy<br />
<br />
Backup the MBR which contains the boot code and partition table (Replace {{ic|/dev/sd'''X'''}} with your actual disk path)<br />
<br />
# dd if=/dev/sdX of=/path/to/backup/mbr_backup bs=512 count=1<br />
<br />
Only 446 bytes of the MBR contain boot code, the next 64 contain the partition table. If you do not want to overwrite your partition table when restoring, it is strongly advised to backup only the MBR boot code:<br />
<br />
# dd if=/dev/sdX of=/path/to/backup/bootcode_backup bs=446 count=1<br />
<br />
If unable to install GRUB2 correctly, see [[GRUB2#Restore_GRUB_Legacy]].<br />
<br />
==== Install grub-bios package ====<br />
<br />
The GRUB(2) packages can be installed with pacman (and will replace {{Pkg|grub-legacy}} or {{Pkg|grub}}, if it is installed):<br />
<br />
# pacman -S grub-bios<br />
<br />
{{Note|Simply installing the package won't update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB(2) modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install grub-bios boot files ====<br />
<br />
There are 3 ways to install GRUB(2) boot files in BIOS booting:<br />
*[[#Install_to_440-byte_MBR_boot_code_region]] (recommended) , <br />
*[[#Install_to_Partition_or_Partitionless_Disk]] (not recommended),<br />
*[[#Generate_core.img_alone]] (safest method, but requires another BIOS bootloader like [[grub-legacy]] or [[syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}}). <br />
<br />
===== Install to 440-byte MBR boot code region =====<br />
<br />
To setup {{ic|grub-bios}} in the 440-byte Master Boot Record boot code region, populate the {{ic|/boot/grub}} directory, generate the {{ic|/boot/grub/i386-pc/core.img}} file, and embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap (MBR disks) or in BIOS Boot Partition (GPT disks), run:<br />
<br />
# modprobe dm-mod<br />
# grub-install --target=i386-pc --recheck --debug /dev/sda<br />
# mkdir -p /boot/grub/locale<br />
# cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo<br />
<br />
where {{ic|/dev/sda}} is the destination of the installation (in this case the MBR of the first SATA disk). If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB2 on multiple physical disks. <br />
<br />
{{Note|Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware grub(2) is being installed. In such cases grub-install will show {{ic|source_dir doesn't exist. Please specify --target or --directory}} message. Also, {{ic|--target&#61;i386-pc}} is correct for 64-bit systems, as well.}}<br />
<br />
{{Note|After executing the {{ic|grub-install}} command, the directory {{ic|/boot/grub/locale}} may already exist, thus running {{ic|# mkdir -p /boot/grub/locale}} is obsolete.}}<br />
<br />
The {{ic|--no-floppy}} tells {{ic|grub-bios}} utilities not to search for any floppy devices which reduces the overall execution time of {{ic|grub-install}} on many systems (it will also prevent the issue below from occurring). Otherwise you get an error that looks like this:<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 />
{{Note|{{ic|--no-floppy}} has been removed from {{ic|grub-install}} in 2.00~beta2 upstream release, and replaced with {{ic|--allow-floppy}}.}}<br />
<br />
{{Warning|Make sure to check the {{ic|/boot}} directory if you use the latter. Sometimes the {{ic| boot-directory}} parameter creates another {{ic|/boot}} folder inside of {{ic|/boot}}. A wrong install would look like: {{ic|/boot/boot/grub/}}.}}<br />
<br />
===== Install to Partition or Partitionless Disk =====<br />
<br />
{{Note|{{ic|grub-bios}} (any version - including upstream Bazaar repo) does not encourage installation to a partition boot sector or a partitionless disk like GRUB Legacy or Syslinux does. This kind of setup is prone to breakage, especially during updates, and is not supported by Arch devs.}}<br />
<br />
To set up {{ic|grub-bios}} to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# modprobe dm-mod <br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --recheck --debug --force /dev/sdaX<br />
# mkdir -p /boot/grub/locale<br />
# cp /usr/share/locale/en@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists. <br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that {{ic|grub-bios}} relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix dir {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the filesystem in the partition is being altered (files copied, deleted etc.). For more info see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using chattr command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if {{ic|grub-bios}} is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
===== Generate core.img alone =====<br />
<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any {{ic|grub-bios}} bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# modprobe dm-mod<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --recheck --debug /dev/sda<br />
# mkdir -p /boot/grub/locale<br />
# cp /usr/share/locale/en@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo<br />
<br />
You can then chainload GRUB2's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or a multiboot kernel.<br />
<br />
==== Generate GRUB2 BIOS Config file ====<br />
<br />
Finally, generate a configuration for GRUB2 (this is explained in greater detail in the Configuration section):<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|The file path is {{ic|/boot/grub/grub.cfg}}, NOT {{ic|/boot/grub/i386-pc/grub.cfg}}.}}<br />
<br />
If grub(2) complains about "no suitable mode found" while booting, go to [[#Correct_GRUB2_No_Suitable_Mode_Found_Error]].<br />
<br />
If {{ic|grub-mkconfig}} fails, convert your {{ic|/boot/grub/menu.lst}} file to {{ic|/boot/grub/grub.cfg}} using:<br />
<br />
# grub-menulst2cfg /boot/grub/menu.lst /boot/grub/grub.cfg<br />
<br />
For example:<br />
<br />
{{hc|/boot/grub/menu.lst|<nowiki><br />
default=0<br />
timeout=5<br />
<br />
title Arch Linux Stock Kernel<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux.img<br />
<br />
title Arch Linux Stock Kernel Fallback<br />
root (hd0,0)<br />
kernel /vmlinuz-linux root=/dev/sda2 ro<br />
initrd /initramfs-linux-fallback.img<br />
</nowiki>}}<br />
<br />
{{hc|/boot/grub/grub.cfg|<nowiki><br />
set default='0'; if [ x"$default" = xsaved ]; then load_env; set default="$saved_entry"; fi<br />
set timeout=5<br />
<br />
menuentry 'Arch Linux Stock Kernel' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux.img' '/initramfs-linux.img'<br />
<br />
}<br />
<br />
menuentry 'Arch Linux Stock Kernel Fallback' {<br />
set root='(hd0,1)'; set legacy_hdbias='0'<br />
legacy_kernel '/vmlinuz-linux' '/vmlinuz-linux' 'root=/dev/sda2' 'ro'<br />
legacy_initrd '/initramfs-linux-fallback.img' '/initramfs-linux-fallback.img'<br />
}<br />
</nowiki>}}<br />
<br />
If you forgot to create a GRUB2 {{ic|/boot/grub/grub.cfg}} config file and simply rebooted into GRUB2 Command Shell, type:<br />
<br />
sh:grub> insmod legacycfg<br />
sh:grub> legacy_configfile ${prefix}/menu.lst<br />
<br />
Boot into Arch and re-create the proper GRUB2 {{ic|/boot/grub/grub.cfg}} config file.<br />
<br />
{{Note|This option works only in BIOS systems, not in UEFI systems.}}<br />
<br />
==== Multiboot in BIOS ====<br />
<br />
===== Boot Microsoft Windows installed in BIOS-MBR mode =====<br />
<br />
{{Note|GRUB(2) supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|Take note that it is the SYSTEM PARTITION that has the bootmgr, not your "real" windows partition (C:), ie: when showing all UUID's with blkid it is the partition with LABEL&#61;"SYSTEM RESERVED" which is only about 100 mb big much like the boot partition for arch. See http://en.wikipedia.org/wiki/System_partition_and_boot_partition for some more info.}}<br />
<br />
Find the UUID of the NTFS filesystem of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|{{ic|grub-probe}} should be run as root.}}<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|ntldr}} in the above commands.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7 or 8) installed in BIOS-MBR mode:<br />
<br />
For Windows Vista/7/8:<br />
<br />
<pre><br />
menuentry "Microsoft Windows Vista/7/8 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}</pre><br />
<br />
For Windows XP:<br />
<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /ntldr<br />
}<br />
<br />
=== UEFI systems ===<br />
<br />
{{Note|It is recommended to read the [[UEFI]], [[GPT]] and [[UEFI_Bootloaders]] pages before reading this part.}}<br />
<br />
==== Hardware-Specific UEFI Examples ====<br />
<br />
It is well know that different motherboard manufactures implement UEFI differently. Users experiencing problems getting Grub/EFI to work properly are encouraged to share detailed steps for hardware-specific cases where UEFI booting does not work as described below. In an effort to keep the parent [[GRUB]] article neat and tidy, see the [[GRUB EFI Examples]] page for these special cases.<br />
<br />
==== Install grub-uefi package ====<br />
<br />
{{Note|Unless specified as EFI 1.x , EFI and UEFI terms are used interchangeably to denote UEFI 2.x firmware. Also unless stated explicitly, the instructions are general and not Mac specific. Some of them may not work or may be different in Macs. Apple's EFI implementation is neither a EFI 1.x version nor UEFI 2.x version but mixes up both. This kind of firmware does not fall under any one UEFI Specification version and is therefore not a standard UEFI firmware.}}<br />
<br />
GRUB(2) UEFI bootloader is available in Arch Linux only from version 1.99~rc1. To install, first [[Unified_Extensible_Firmware_Interface#Detecting_UEFI_Firmware_Arch|detect which UEFI firmware arch]] you have (either x86_64 or i386).<br />
<br />
Depending on that, install the appropriate package<br />
<br />
For 64-bit aka x86_64 UEFI firmware:<br />
# pacman -S grub-efi-x86_64<br />
<br />
For 32-bit aka i386 UEFI firmware:<br />
# pacman -S grub-efi-i386<br />
<br />
{{Note|Simply installing the package will not update the {{ic|core.efi}} file and the GRUB(2) modules in the UEFI System Partition. You need to do this manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install grub-uefi boot files ====<br />
<br />
===== Install to UEFI SYSTEM PARTITION =====<br />
<br />
{{Note|The below commands assume you are using {{ic|grub-efi-x86_64}} (for {{ic|grub-efi-i386}} replace {{ic|x86_64}} with {{ic|i386}} in the below commands).}}<br />
<br />
{{Note|To do this, you need to boot using UEFI and not the BIOS. If you booted by just copying the ISO file to the USB drive, you will need to follow [[UEFI#Create_UEFI_bootable_USB_from_ISO|this guide]] or grub-install will show errors.}}<br />
<br />
The UEFI system partition will need to be mounted at {{ic|/boot/efi/}} for the GRUB(2) install script to detect it:<br />
<br />
# mkdir -p /boot/efi<br />
# mount -t vfat /dev/sdXY /boot/efi<br />
<br />
Install GRUB UEFI application to {{ic|/boot/efi/EFI/arch_grub}} and its modules to {{ic|/boot/grub/x86_64-efi}} (recommended) using:<br />
<br />
# modprobe dm-mod<br />
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --recheck --debug<br />
# mkdir -p /boot/grub/locale<br />
# cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo<br />
<br />
{{Note|Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware grub(2) is being installed. In such cases grub-install will show {{ic|source_dir doesn't exist. Please specify --target or --directory}} message.}}<br />
<br />
If you want to install grub(2) modules and {{ic|grub.cfg}} at the directory {{ic|/boot/efi/EFI/grub}} and the {{ic|grubx64.efi}} application at {{ic|/boot/efi/EFI/arch_grub}} (ie. all the grub(2) uefi files inside the UEFISYS partition itself) use:<br />
<br />
# modprobe dm-mod <br />
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --boot-directory=/boot/efi/EFI --recheck --debug<br />
# mkdir -p /boot/efi/EFI/grub/locale<br />
# cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/efi/EFI/grub/locale/en.mo<br />
<br />
The {{ic|--efi-directory}} option mentions the mountpoint of UEFI SYSTEM PARTITION , {{ic|--bootloader-id}} mentions the name of the directory used to store the {{ic|grubx64.efi}} file and {{ic|--boot-directory}} mentions the directory wherein the actual modules will be installed (and into which {{ic|grub.cfg}} should be created).<br />
<br />
The actual paths are:<br />
<br />
<efi-directory>/<EFI or efi>/<bootloader-id>/grubx64.efi<br />
<br />
<boot-directory>/grub/x86_64-efi/<all modules, grub.efi, core.efi, grub.cfg><br />
<br />
{{Note|the {{ic|--bootloader-id}} option does not change {{ic|<boot-directory>/grub}}, i.e. you cannot install the modules to {{ic|<boot-directory>/<bootloader-id>}}, the path is hard-coded to be {{ic|<boot-directory>/grub}}.}}<br />
<br />
In {{ic|<nowiki>--efi-directory=/boot/efi --boot-directory=/boot/efi/EFI --bootloader-id=grub</nowiki>}}:<br />
<br />
<efi-directory>/<EFI or efi>/<bootloader-id> == <boot-directory>/grub == /boot/efi/EFI/grub<br />
<br />
In {{ic|<nowiki>--efi-directory=/boot/efi --boot-directory=/boot/efi/EFI --bootloader-id=arch_grub</nowiki>}}:<br />
<br />
<efi-directory>/<EFI or efi>/<bootloader-id> == /boot/efi/EFI/arch_grub<br />
<boot-directory>/grub == /boot/efi/EFI/grub<br />
<br />
In {{ic|<nowiki>--efi-directory=/boot/efi --boot-directory=/boot --bootloader-id=arch_grub</nowiki>}}:<br />
<br />
<efi-directory>/<EFI or efi>/<bootloader-id> == /boot/efi/EFI/arch_grub<br />
<boot-directory>/grub == /boot/grub<br />
<br />
In {{ic|<nowiki>--efi-directory=/boot/efi --boot-directory=/boot --bootloader-id=grub</nowiki>}}:<br />
<br />
<efi-directory>/<EFI or efi>/<bootloader-id> == /boot/efi/EFI/grub<br />
<boot-directory>/grub == /boot/grub<br />
<br />
The {{ic|<nowiki><efi-directory>/<EFI or efi>/<bootloader-id>/grubx64.efi</nowiki>}} is an exact copy of {{ic|<nowiki><boot-directory>/grub/x86_64-efi/core.efi</nowiki>}}.<br />
<br />
{{Note|In GRUB 2.00, the {{ic|grub-install}} option {{ic|--efi-directory}} replaces {{ic|--root-directory}} and the latter is deprecated.}}<br />
<br />
{{Note|The options {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB(2) UEFI.}}<br />
<br />
In all the cases the UEFI SYSTEM PARTITION should be mounted for {{ic|grub-install}} to install {{ic|grubx64.efi}} in it, which will be launched by the firmware (using the {{ic|efibootmgr}} created boot entry in non-Mac systems).<br />
<br />
If you notice carefully, there is no <device_path> option (Eg: {{ic|/dev/sda}}) at the end of the {{ic|grub-install}} command unlike the case of setting up GRUB(2) for BIOS systems. Any <device_path> provided will be ignored by the install script as UEFI bootloaders do not use MBR or Partition boot sectors at all.<br />
<br />
You may now be able to UEFI boot your system by creating a {{ic|grub.cfg}} file by following [[#Generate_GRUB2_UEFI_Config_file]] and [[#Create_GRUB2_entry_in_the_Firmware_Boot_Manager]].<br />
<br />
==== Generate GRUB2 UEFI Config file ====<br />
<br />
Finally, generate a configuration for GRUB(2) (this is explained in greater detail in the Configuration section):<br />
<br />
# grub-mkconfig -o <boot-directory>/grub/grub.cfg<br />
<br />
{{Note|The file path is {{ic|<boot-directory>/grub/grub.cfg}}, NOT {{ic|<boot-directory>/grub/x86_64-efi/grub.cfg}}.}}<br />
<br />
If you used {{ic|<nowiki>--boot-directory=/boot</nowiki>}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
If you used {{ic|<nowiki>--boot-directory=/boot/efi/EFI</nowiki>}}:<br />
<br />
# grub-mkconfig -o /boot/efi/EFI/grub/grub.cfg<br />
<br />
This is independent of the value of {{ic|--bootloader-id}} option.<br />
<br />
If GRUB2 complains about "no suitable mode found" while booting, try [[#Correct_GRUB2_No_Suitable_Mode_Found_Error]].<br />
<br />
==== Create GRUB2 Standalone UEFI Application ====<br />
<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embeddded in a memdisk within the uefi application, thus removing the need for having a separate directory populated with all the GRUB2 uefi modules and other related files. This is done using the {{ic|grub-mkstandalone}} command which is included in {{Pkg|grub-common}} >= 1:1.99-6 package.<br />
<br />
The easiest way to do this would be with the install command already mentioned before, but specifying the modules to include. For example:<br />
<br />
# grub-mkstandalone --directory="/usr/lib/grub/x86_64-efi/" --format="x86_64-efi" --compression="xz" \<br />
--output="/boot/efi/EFI/arch_grub/grubx64_standalone.efi" <any extra files you want to include><br />
<br />
The {{ic|grubx64_standalone.efi}} file expects {{ic|grub.cfg}} to be within its $prefix which is {{ic|(memdisk)/boot/grub}}. The memdisk is embedded within the efi app. The {{ic|grub-mkstandlone}} script allow passing files to be included in the memdisk image to be as the arguments to the script (in <any extra files you want to include>).<br />
<br />
If you have the {{ic|grub.cfg}} at {{ic|/home/user/Desktop/grub.cfg}}, then create a temporary {{ic|/home/user/Desktop/boot/grub/}} directory, copy the {{ic|/home/user/Desktop/grub.cfg}} to {{ic|/home/user/Desktop/boot/grub/grub.cfg}}, cd into {{ic|/home/user/Desktop/boot/grub/}} and run:<br />
<br />
# grub-mkstandalone --directory="/usr/lib/grub/x86_64-efi/" --format="x86_64-efi" --compression="xz" \<br />
--output="/boot/efi/EFI/arch_grub/grubx64_standalone.efi" "boot/grub/grub.cfg"<br />
<br />
The reason to cd into {{ic|/home/user/Desktop/boot/grub/}} and to pass the file path as {{ic|boot/grub/grub.cfg}} (notice the lack of a leading slash - boot/ vs /boot/ ) is because {{ic|dir1/dir2/file}} is included as {{ic|(memdisk)/dir1/dir2/file}} by the {{ic|grub-mkstandalone}} script. <br />
<br />
If you pass {{ic|/home/user/Desktop/grub.cfg}} the file will be included as {{ic|(memdisk)/home/user/Desktop/grub.cfg}}. If you pass {{ic|/home/user/Desktop/boot/grub/grub.cfg}} the file will be included as {{ic|(memdisk)/home/user/Desktop/boot/grub/grub.cfg}}. That is the reason for cd'ing into {{ic|/home/user/Desktop/boot/grub/}} and passing {{ic|boot/grub/grub.cfg}}, to include the file as {{ic|(memdisk)/boot/grub/grub.cfg}}, which is what {{ic|grub.efi}} expects the file to be.<br />
<br />
You need to create an UEFI Boot Manager entry for {{ic|/boot/efi/EFI/arch_grub/grubx64_standalone.efi}} using {{ic|efibootmgr}}. Follow [[#Create GRUB2 entry in the Firmware Boot Manager]].<br />
<br />
==== Multiboot in UEFI ====<br />
<br />
===== Chainload Microsoft Windows x86_64 UEFI-GPT =====<br />
<br />
Find the UUID of the FAT32 filesystem in the UEFI SYSTEM PARTITION where the Windows UEFI Bootloader files reside. For example, if Windows {{ic|bootmgfw.efi}} exists at {{ic|/boot/efi/EFI/Microsoft/Boot/bootmgfw.efi}} (ignore the upper-lower case differences since that is immaterial in FAT filesystem):<br />
<br />
# grub-probe --target=fs_uuid /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi<br />
1ce5-7f28<br />
<br />
# grub-probe --target=hints_string /boot/efi/EFI/Microsoft/Boot/bootmgfw.efi<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1<br />
<br />
{{Note|{{ic|grub-probe}} should be run as root.}}<br />
<br />
Then, add this code to {{ic|/boot/grub/grub.cfg}} OR {{ic|/boot/efi/EFI/grub/grub.cfg}} to chainload Windows x86_64 (Vista SP1+, 7 or 8) installed in UEFI-GPT mode:<br />
<br />
menuentry "Microsoft Windows Vista/7/8 x86_64 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --no-floppy --set=root --hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1 1ce5-7f28<br />
chainloader /efi/Microsoft/Boot/bootmgfw.efi<br />
}<br />
<br />
== Configuration ==<br />
<br />
You can also choose to automatically generate or manually edit {{ic|grub.cfg}}.<br />
<br />
{{Note|For EFI systems, if GRUB2 was installed with the {{ic|--boot-directory}} option set, the {{ic|grub.cfg}} file must be placed in the same directory as {{ic|grubx64.efi}}. Otherwise, the {{ic|grub.cfg}} file goes in {{ic|/boot/grub/}}, just like in the BIOS version of GRUB2.}}<br />
<br />
{{Note|Here is a quite complete description of how to configure GRUB2: http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html }}<br />
<br />
=== Automatically generating using grub-mkconfig (Recommended) ===<br />
<br />
The GRUB2 {{ic|menu.lst}} equivalent configuration files are {{ic|/etc/default/grub}} and {{ic|/etc/grub.d/*}}. {{ic|grub-mkconfig}} uses these files to generate {{ic|grub.cfg}}. By default the script outputs to stdout. To generate a {{ic|grub.cfg}} file run the command:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{ic|/etc/grub.d/10_linux}} is set to automatically add menu items for Arch linux that work out of the box, to any generated configuration. Other operating systems may need to be added manually to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}<br />
<br />
==== Additional arguments ====<br />
<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} variable in {{ic|/etc/default/grub}}. <br />
<br />
For example, use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX"</nowiki>}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation.<br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/disk/by-uuid/${swap_uuid}"</nowiki>}}, where {{ic|${swap_uuid} }} is the [[Persistent_block_device_naming|UUID]] of your swap partition.<br />
<br />
Multiple entries are separated by spaces within the double quotes. So, for users who want both resume and systemd it would look like this:<br />
{{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=/dev/sdaX init=/usr/lib/systemd/systemd"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Manually creating grub.cfg ===<br />
<br />
{{Warning|Editing this file is strongly ''not'' recommended. The file is generated by the {{ic|grub-mkconfig}} command, and it is best to edit your {{ic|/etc/default/grub}} or one of the scripts in the {{ic|/etc/grub.d}} folder.}}<br />
<br />
A basic GRUB config file uses the following options<br />
* {{ic|(hdX,Y)}} is the partition {{ic|Y}} on disk {{ic|X}}, partition numbers starting at 1, disk numbers starting at 0<br />
* {{ic|1=set default=N}} is the default boot entry that is chosen after timeout for user action<br />
* {{ic|1=set timeout=M}} is the time {{ic|M}} to wait in seconds for a user selection before default is booted<br />
* {{ic|<nowiki>menuentry "title" {entry options}</nowiki>}} is a boot entry titled {{ic|title}}<br />
* {{ic|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 ({{ic|/}})<br />
<br />
An example configuration:<br />
<br />
{{hc<br />
|/boot/grub/grub.cfg<br />
|<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 /vmlinuz-linux root=/dev/sda3 ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
## (1) Windows<br />
#menuentry "Windows" {<br />
#set root=(hd0,3)<br />
#chainloader +1<br />
#}<br />
</nowiki>}}<br />
<br />
=== Dual-booting ===<br />
<br />
{{Note|If you want GRUB2 to automatically search for other systems, you may wish to install {{Pkg|os-prober}}.}}<br />
<br />
==== Using grub-mkconfig ====<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} . The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
# grub-mkconfig -o /boot/grub/grub.cfg <br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
===== With GNU/Linux =====<br />
<br />
Assuming that the other distro is on partition {{ic|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 FreeBSD =====<br />
<br />
Requires that FreeBSD is installed on a single partition with UFS. Assuming it is installed on {{ic|sda4}}:<br />
<br />
menuentry "FreeBSD" {<br />
set root=(hd0,4)<br />
chainloader +1<br />
}<br />
<br />
===== With Windows =====<br />
<br />
This assumes that your Windows partition is {{ic|sda3}}. Remember you need to point set root and chainloader to the system reserve partition that windows made when it installed, not the actual partition windows is on. This example works if your system reserve partition is {{ic|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 hard drive than GRUB, it may be necessary to trick Windows into believing that it is the first hard drive. This was possible with {{ic|drivemap}}. Assuming GRUB is on {{ic|hd0}} and Windows is on {{ic|hd2}}, you need to add the following after {{ic|set root}}:<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 {{ic|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/i386-pc/core.img<br />
<br />
===Visual Configuration===<br />
<br />
In GRUB2 it is possible, by default, to change the look of the menu. Make sure to initialize, if not done already, GRUB2 graphical terminal, gfxterm, with proper video mode, gfxmode, in GRUB2. This can be seen in the section [[#Correct_GRUB2_No_Suitable_Mode_Found_Error]]. This video mode is passed by GRUB2 to the linux kernel via 'gfxpayload' so any visual configurations need this mode in order to be in effect.<br />
<br />
====Setting the framebuffer resolution ====<br />
<br />
GRUB2 can set the framebuffer for both GRUB2 itself and the kernel. The old {{ic|1=vga=}} way is deprecated. The preferred method is editing {{ic|/etc/default/grub}} 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 {{ic|gfxpayload}} property will make sure the kernel keeps the resolution.<br />
<br />
{{Note|If this example does not work for you try to replace {{ic|1=gfxmode="1024x768x32"}} by {{ic|1=vbemode="0x105"}}. Remember to replace the specified resolution with one suitable for your screen.}}<br />
{{Note|To show all the modes you can use {{ic|1=# hwinfo --framebuffer}} (hwinfo is available in [community]), while at GRUB2 prompt you can use the {{ic|1=vbeinfo}} command.}}<br />
<br />
If this method does not work for you, the deprecated {{ic|1=vga=}} method will still work. Just<br />
add it next to the {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="}} line in {{ic|/etc/default/grub}}<br />
for eg: {{ic|1="GRUB_CMDLINE_LINUX_DEFAULT="quiet splash vga=792"}} will give you a {{ic|1024x768}} resolution.<br />
<br />
You can choose one of these resolutions: {{ic|640×480}}, {{ic|800×600}}, {{ic|1024×768}}, {{ic|1280×1024}}, {{ic|1600×1200}}, {{ic|1920×1200}}<br />
<br />
====915resolution hack ====<br />
<br />
Some times for Intel graphic adapters neither {{ic|1=# hwinfo --framebuffer}} nor {{ic|1=vbeinfo}} will show you the desired resolution. In this case you can use {{ic|915resolution}} hack. This hack will temporarily modify video BIOS and add needed resolution. See [http://915resolution.mango-lang.org/ 915resolution's home page]<br />
<br />
In the following I will proceed with the example for my system. Please adjust the recipe for your needs. First you need to find a video mode which will be modified later. For that, run {{ic|915resolution}} in GRUB2 command shell:<br />
915resolution -l<br />
The output will be something like:<br />
Intel 800/900 Series VBIOS Hack : version 0.5.3<br />
...<br />
Mode 30 : 640x480, 8 bits/pixel<br />
...<br />
Next, our purpose is to overwrite mode 30. (You can choose what ever mode you want.) In the file {{ic|/etc/grub.d/00_header}} just before the {{ic|set gfxmode&#61;${GRUB_GFXMODE}}} line insert:<br />
915resolution 30 1440 900<br />
Here we are overwriting the mode {{ic|30}} with {{ic|1440x900}} resolution. Lastly we need to set {{ic|GRUB_GFXMODE}} as described earlier, regenerate GRUB2 configuration file and reboot to test changes:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
# reboot<br />
<br />
====Background image and bitmap fonts====<br />
<br />
GRUB2 comes with support for background images and bitmap fonts in {{ic|pf2}} format. The unifont font is included in the {{Pkg|grub-common}} package under the filename {{ic|unicode.pf2}}, or, as only ASCII characters under the name {{ic|ascii.pf2}}.<br />
<br />
Image formats supported include tga, png and jpeg, providing the correct modules are loaded. The maximum supported resolution depends on your hardware.<br />
<br />
Make sure you have set up the proper [https://wiki.archlinux.org/index.php/GRUB2#Setting_the_framebuffer_resolution framebuffer resolution].<br />
<br />
Edit {{ic|/etc/default/grub}} like this:<br />
GRUB_BACKGROUND="/boot/grub/myimage"<br />
#GRUB_THEME="/path/to/gfxtheme"<br />
GRUB_FONT="/path/to/font.pf2"<br />
<br />
{{Note|If you have installed GRUB on a separate partition, {{ic|/boot/grub/myimage}} becomes {{ic|/grub/myimage}}.}}<br />
<br />
To generate the changes and add the information into {{ic|grub.cfg}}, run: <br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
If adding the splash image was successful, the user will see {{ic|"Found background image..."}} in the terminal as the command is executed. <br />
If this phrase is not seen, the image information was probably not incorporated into the {{ic|grub.cfg}} file.<br />
<br />
If the image is not displayed, check:<br />
* The path and the filename in {{ic|/etc/default/grub}} are correct.<br />
* The image is of the proper size and format (tga, png, 8-bit jpg).<br />
* The image was saved in the RGB mode, and is not indexed.<br />
* The console mode is not enabled in {{ic|/etc/default/grub}}.<br />
* The command {{ic|grub-mkconfig}} must be executed to place the background image information into the {{ic|/boot/grub/grub.cfg}} file.<br />
<br />
====Theme====<br />
<br />
Here is an example for configuring Starfield theme which was included in GRUB2 package.<br />
<br />
Edit {{ic|/etc/default/grub}}<br />
GRUB_THEME="/usr/share/grub/themes/starfield/theme.txt"<br />
<br />
Generate the changes:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
If configuring the theme was successful, you'll see {{ic|Found theme: /usr/share/grub/themes/starfield/theme.txt}} in the terminal.<br />
Your splash image will usually not be displayed when using a theme.<br />
<br />
====Menu colors====<br />
<br />
You can set the menu colors in GRUB2. The available colors for GRUB2 are at https://www.gnu.org/software/grub/manual/html_node/Theme-file-format.html#Theme-file-format.<br />
Here is an example:<br />
<br />
Edit {{ic|/etc/default/grub}}:<br />
GRUB_COLOR_NORMAL="light-blue/black"<br />
GRUB_COLOR_HIGHLIGHT="light-cyan/blue"<br />
<br />
Generate the changes:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
====Hidden menu====<br />
<br />
One of the unique features of GRUB2 is hiding/skipping the menu and showing it by holding {{keypress|Esc}} when needed. You can also adjust whether you want to see the timeout counter.<br />
<br />
Edit {{ic|/etc/default/grub}} as you wish. Here is 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 />
====Disable framebuffer====<br />
<br />
Users who use NVIDIA proprietary driver might wish to disable GRUB2's framebuffer as it can cause problems with the binary driver.<br />
<br />
To disable framebuffer, edit {{ic|/etc/default/grub}} and uncomment the following line:<br />
GRUB_TERMINAL_OUTPUT=console<br />
<br />
and run:<br />
grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Other Options ===<br />
<br />
==== LVM ====<br />
<br />
If you use [[LVM]] for your {{ic|/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/''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=lvm/VolumeGroup-lv_boot<br />
# you can only set following two lines<br />
linux /vmlinuz-linux root=/dev/mapper/VolumeGroup-root ro<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
==== RAID ====<br />
<br />
GRUB2 provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md0,1)<br />
<br />
==== Persistent block device naming ====<br />
One naming scheme for [[Persistent block device naming]] is the use of globally unique UUIDs to detect partitions instead of the "old" {{ic|/dev/sd*}}. Advantages are covered up in the above linked article. <br />
<br />
Persistent naming via filesystem UUIDs are used by default in GRUB2. <br />
<br />
{{Note|The {{ic|/boot/grub.cfg}} file needs regeneration with the new UUID in {{ic|/etc/default/grub}} every time a relevant filesystem is resized or recreated. Remember this when modifying partitions & filesystems with a Live-CD.}}<br />
<br />
Whether to use UUIDs is controlled by an option in /etc/default/grub:<br />
<br />
{{bc|1=# GRUB_DISABLE_LINUX_UUID=true}}<br />
<br />
Either way, do not forget to generate the changes:<br />
{{bc|# grub-mkconfig -o /boot/grub/grub.cfg}}<br />
<br />
==== Using Labels ====<br />
<br />
It is possible to use labels, human-readable strings attached to filesystems, by using the {{ic|--label}} option to {{ic|search}}. First of all, label your existing partition:<br />
# tune2fs -L <LABEL> <PARTITION><br />
<br />
Then, add an entry using labels. An example of this:<br />
<br />
menuentry "Arch Linux, session texte" {<br />
search --label --no-floppy --set=root archroot<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/archroot ro<br />
initrd /boot/initramfs-linux.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 {{ic|/etc/default/grub}} and change the setting of {{ic|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 {{ic|/etc/default/grub}}:<br />
<br />
GRUB_SAVEDEFAULT=true<br />
<br />
{{Note|Manually added menu items, eg Windows in {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} , will need {{ic|savedefault}} added. Remember to regenerate your configuration file.}}<br />
<br />
==== Security ====<br />
<br />
If you want to secure GRUB2 so it is not possible for anyone to change boot parameters or use the command line, you can add a user/password combination to GRUB2's configuration files. To do this, run the command {{ic|grub-mkpasswd-pbkdf2}}. Enter a password and confirm it. The output will look like this:<br />
<br />
{{bc|<nowiki><br />
Your PBKDF2 is grub.pbkdf2.sha512.10000.C8ABD3E93C4DFC83138B0C7A3D719BC650E6234310DA069E6FDB0DD4156313DA3D0D9BFFC2846C21D5A2DDA515114CF6378F8A064C94198D0618E70D23717E82.509BFA8A4217EAD0B33C87432524C0B6B64B34FBAD22D3E6E6874D9B101996C5F98AB1746FE7C7199147ECF4ABD8661C222EEEDB7D14A843261FFF2C07B1269A</nowiki>}}Then, add the following to {{ic|/etc/grub.d/00_header}}:<br />
{{bc|<nowiki>cat << EOF<br />
<br />
set superusers="username"<br />
password_pbkdf2 username <password><br />
<br />
EOF</nowiki>}}<br />
where {{ic|<password>}} is the string generated by {{ic|grub-mkpasswd_pbkdf2}}.<br />
<br />
Regenerate your configuration file. Your GRUB2 command line, boot parameters and all boot entries are now protected.<br />
<br />
This can be relaxed and further customized with more users as described in the "Security" part of [https://www.gnu.org/software/grub/manual/grub.html#Security the GRUB manual].<br />
<br />
==== Root Encryption ====<br />
<br />
To let GRUB2 automatically add the kernel parameters for root encryption,<br />
add {{ic|1=cryptdevice=/dev/yourdevice:label}} to {{ic|GRUB_CMDLINE_LINUX}} in {{ic|/etc/default/grub}}.<br />
<br />
Example with root mapped to {{ic|/dev/mapper/root}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:root"<br />
<br />
Also, disable the usage of UUIDs for the rootfs:<br />
<br />
GRUB_DISABLE_LINUX_UUID=true<br />
<br />
Regenerate the configuration.<br />
<br />
=== Booting an ISO Directly From GRUB2 ===<br />
Edit {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} to add an entry for the target ISO. When finished, update the GRUB menu as with the usual {{ic|grub-mkconfig -o /boot/grub/grub.cfg}} (as root).<br />
<br />
==== Arch ISO ====<br />
{{Note|Be sure to adjust the {{ic|hdX,Y}} in the third line to point to the correct disk/partition number of the isofile. Also adjust the {{ic|img_dev}} line to match this same location. However, if booting the ISO from USB on a computer which also has one internal HDD, then it needs to be {{ic|hd0,Y}} with {{ic|sdbY}}, instead of {{ic|sdaY}}.}}<br />
<br />
menuentry "Archlinux-2011.08.19-netinstall-x86_64.iso" {<br />
set isofile="/archives/archlinux-2011.08.19-netinstall-x86_64.iso"<br />
loopback loop (hd0,7)$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201108 img_dev=/dev/sda7 img_loop=$isofile earlymodules=loop<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
menuentry "Archlinux-2012.07.15-netinstall-dual.iso" {<br />
set isofile="/archives/archlinux-2012.07.15-netinstall-dual.iso"<br />
loopback loop (hd0,7)$isofile<br />
linux (loop)/arch/boot/x86_64/vmlinuz archisolabel=ARCH_201207 img_dev=/dev/sda7 img_loop=$isofile<br />
initrd (loop)/arch/boot/x86_64/archiso.img<br />
}<br />
<br />
{{Tip|For thumbdrives, use [[Persistent_block_device_naming|Persistent block device names]] for the "img_dev" kernel parameter. '''Ex:''' img_dev&#61;/dev/disk/by-label/CORSAIR}}<br />
<br />
==== Ubuntu ISO ====<br />
{{Note|Be sure to adjust the {{ic|hdX,Y}} in the third line to point to the correct disk or partition number of the ISO file.}}<br />
<br />
menuentry "ubuntu-12.04-desktop-amd64.iso" {<br />
set isofile="/path/to/ubuntu-12.04-desktop-amd64.iso"<br />
loopback loop (hdX,Y)$isofile<br />
linux (loop)/casper/vmlinuz boot=casper iso-scan/filename=$isofile quiet noeject noprompt splash --<br />
initrd (loop)/casper/initrd.lz<br />
}<br />
<br />
==== Other ISOs ====<br />
<br />
Other working configurations from [http://askubuntu.com/questions/141940/how-to-boot-live-iso-images link Source].<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 {{ic|/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 />
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 />
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 />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
<br />
GRUB2 supports pager for reading commands that provide long output (like the help command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB2 command shell type:<br />
sh:grub> set pager=1<br />
<br />
== GUI configuration tools ==<br />
<br />
Following package may be installed from [[AUR]]<br />
* [https://aur.archlinux.org/packages.php?ID=44020 grub-customizer] (requires gettext gksu gtkmm hicolor-icon-theme openssl)<br />
*:Customize the bootloader (GRUB2 or BURG)<br />
* [http://kde-apps.org/content/show.php?content=139643 grub2-editor] (requires kdelibs)<br />
*:A KDE4 control module for configuring the GRUB2 bootloader<br />
* [http://kde-apps.org/content/show.php?content=137886 kcm-grub2] (requires kdelibs python2-qt kdebindings-python)<br />
*:This Kcm module manages the most common settings of Grub2.<br />
* [http://sourceforge.net/projects/startup-manager/ startupmanager] (requires gnome-python imagemagick yelp python2 xorg-xrandr)<br />
*:GUI app for changing the settings of GRUB, GRUB2, Usplash and Splashy<br />
<br />
== parttool for hide/unhide ==<br />
<br />
If you have a Windows 9x paradigm with hidden C:\ disks GRUB can hide/unhide it using {{ic|parttool}}. For example, to boot the third C:\ disk of three Windows 9x 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 {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<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 {{ic|linux}} module:<br />
grub rescue> insmod (hdX,Y)/boot/grub/linux.mod<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}} and {{ic|insmod (hdX,Y)/grub/linux.mod}}).}}<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar (see [[#Configuration]]).<br />
<br />
An example, booting Arch Linux:<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition, again change the lines accordingly:<br />
set root=(hd0,5)<br />
linux /vmlinuz-linux root=/dev/sda6<br />
initrd /initramfs-linux.img<br />
boot<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB2.<br />
<br />
to reinstall GRUB2 and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Bootloader installation]] for details.<br />
<br />
== Combining the use of UUIDs and basic scripting ==<br />
<br />
If you like the idea of using UUIDs to avoid unreliable BIOS mappings or are struggling with GRUB's syntax, here is an example boot menu item that uses UUIDs and a small script to direct GRUB to the proper disk partitions for your system. All you need to do is replace the UUIDs in the sample with the correct UUIDs 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 the UUIDs for your boot and root partition respectively<br />
set the_boot_uuid=ece0448f-bb08-486d-9864-ac3271bd8d07<br />
set the_root_uuid=c55da16f-e2af-4603-9e0b-03f5f565ec4a<br />
<br />
# (Note: This may be the same as your boot partition)<br />
<br />
# Get the boot/root devices and set them in the root and grub_boot variables<br />
search --fs-uuid --no-floppy --set=root $the_root_uuid<br />
search --fs-uuid --no-floppy --set=grub_boot $the_boot_uuid<br />
<br />
# Check to see if boot and root are equal.<br />
# If they are, then append /boot to $grub_boot (Since $grub_boot is actually the root partition)<br />
if [ $the_boot_uuid == $the_root_uuid] ; then<br />
set grub_boot=$grub_boot/boot<br />
fi<br />
<br />
# $grub_boot now points to the correct location, so the following will properly find the kernel and initrd<br />
linux ($grub_boot)/vmlinuz-linux root=/dev/disk/by-uuid/$uuid_os_root ro<br />
initrd ($grub_boot)/initramfs-linux.img<br />
}<br />
<br />
== Troubleshooting ==<br />
<br />
Any troubleshooting should be added here.<br />
<br />
=== Enable GRUB2 debug messages ===<br />
<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== Correct GRUB2 No Suitable Mode Found Error ===<br />
<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB2 graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB2. This video mode is passed by GRUB2 to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB2 video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB2_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB2 UEFI was installed with {{ic|1=--boot-directory=/boot/efi/EFI}} set, then the directory is {{ic|/boot/efi/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB2_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB2_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB2 to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB2_PREFIX_DIR<nowiki>}</nowiki>}}.<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 [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#MBR_aka_msdos_partitioning_specific_instructions]]<br />
<br />
=== UEFI GRUB2 drops to shell ===<br />
<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB2 UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
=== UEFI GRUB2 not loaded ===<br />
In some cases the EFI may fail to load GRUB correctly. Provided everything is set up correctly, the output of:<br />
efibootmgr -v<br />
might look something like this:<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
If everything works correctly, the EFI would now automatically load GRUB.<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
If booting gets stuck without any error message after grub2 loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Restore GRUB Legacy ===<br />
<br />
* Move GRUB2 files out of the way:<br />
<br />
# mv /boot/grub /boot/grub.nonfunctional<br />
<br />
* Copy GRUB Legacy back to {{ic|/boot}}:<br />
<br />
# cp -af /boot/grub-legacy /boot/grub<br />
<br />
* Replace MBR and next 62 sectors of sda with backed up copy<br />
<br />
{{Warning|This command also restores the partition table, so be careful of overwriting a modified partition table with the old one. It '''will''' mess up your system.}}<br />
<br />
# dd if=/path/to/backup/first-sectors of=/dev/sdX bs=512 count=1<br />
<br />
A safer way is to restore only the MBR boot code use:<br />
<br />
# dd if=/path/to/backup/mbr-boot-code of=/dev/sdX bs=446 count=1<br />
<br />
== References ==<br />
<br />
# Official GRUB2 Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
# Ubuntu wiki page for GRUB2 - https://help.ubuntu.com/community/Grub2<br />
# GRUB2 wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
# Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
<br />
== External Links ==<br />
<br />
# [https://github.com/the-ridikulus-rat/My_Shell_Scripts/blob/master/grub/grub_bios.sh A Linux Bash Shell script to compile and install GRUB(2) for BIOS from BZR Source]<br />
# [https://github.com/the-ridikulus-rat/My_Shell_Scripts/blob/master/grub/grub_uefi.sh A Linux Bash Shell script to compile and install GRUB(2) for UEFI from BZR Source]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Acpid&diff=236563Acpid2012-11-23T23:37:09Z<p>Eruditorum: /* Enabling backlight control */</p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Power management]]<br />
[[Category:Daemons and system services]]<br />
[[it:Acpid]]<br />
[[zh-CN:Acpid]]<br />
<br />
[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering [[ACPI modules|ACPI events]]. It listens on {{ic|/proc/acpi/event}} and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:<br />
* Pressing special keys, including the Power/Sleep/Suspend button<br />
* Closing a notebook lid<br />
* (Un)Plugging an AC power adapter from a notebook<br />
* (Un)Plugging phone jack etc.<br />
<br />
acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.<br />
<br />
{{Note|<br />
* [[Desktop Environment|desktop environments]], such as [[GNOME]], [[Systemd#ACPI power management|systemd]] login manager and some [[Extra Keyboard Keys|extra key handling]] daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.<br />
* Since by default the script provided by acpid, '''/etc/acpi/handler.sh''', will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).}}<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].<br />
<br />
To have it start on boot :<br />
* if you're using [[systemd]], run {{ic|systemctl enable acpid}} ;<br />
* if you're using [[rc.conf|initscripts]], edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]].<br />
<br />
== Configuration ==<br />
<br />
{{Pkg|acpid}} comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in {{ic|/etc/acpi/handler.sh}}, which is executed after any ACPI events are detected (as determined by {{ic|/etc/acpi/events/anything}}).<br />
<br />
The following is a brief example of one such action. In this case, when the Sleep button is pressed, acpid runs the command {{ic|echo -n mem >/sys/power/state}} which ''should'' place the computer into a sleep (suspend) state:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
;;<br />
<br />
Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as ''SLPB'' and on another as ''SBTN''. <br />
<br />
To determine how your buttons or {{Keypress|Fn}} shortcuts are recognized, run the following command from a terminal as root:<br />
# tail -f /var/log/messages.log<br />
<br />
Now press the Power button and/or Sleep button (e.g. {{Keypress|Fn+Esc}}) on your machine. The result should look something this:<br />
logger: ACPI action undefined: PBTN<br />
logger: ACPI action undefined: SBTN<br />
<br />
If that does not work, run:<br />
# acpi_listen<br />
<br />
Then press the power button and you will see something like this:<br />
power/button PBTN 00000000 00000b31<br />
<br />
The output of {{ic|acpi_listen}} is sent to {{ic|/etc/acpi/handler.sh}} as $1, $2 , $3 & $4 parameters.<br />
Example:<br />
$1 power/button<br />
$2 PBTN<br />
$3 00000000<br />
$4 00000b31<br />
<br />
As you might have noticed, the Sleep button in the sample output is actually recognized as ''SBTN'', rather than the ''SLPB'' label specified in the default {{ic|/etc/acpi/handler.sh}}. In order for Sleep function to work properly on this machine, we would need to replace ''SLPB)'' with ''SBTN)''.<br />
<br />
Using this information as a base, you can easily customize the {{ic|/etc/acpi/handler.sh}} file to execute a variety of commands depending on which event is triggered. See the [[Acpid#Tips & Tricks | Tips & Tricks]] section below for other commonly used commands.<br />
<br />
=== Alternative configuration ===<br />
<br />
By default, all ACPI events are passed through the {{ic|/etc/acpi/handler.sh}} script. This is due to the ruleset outlined in {{ic|/etc/acpi/events/anything}}:<br />
# Pass all events to our one handler script<br />
event=.*<br />
action=/etc/acpi/handler.sh %e<br />
<br />
While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:<br />
<br />
As root, create the following file:<br />
{{hc|/etc/acpi/events/sleep-button|<nowiki><br />
event=button sleep.*<br />
action=/etc/acpi/actions/sleep-button.sh "%e"<br />
</nowiki>}}<br />
<br />
Now create the following file:<br />
{{hc|/etc/acpi/actions/sleep-button.sh|<nowiki><br />
#!/bin/sh<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
</nowiki>}}<br />
<br />
Finally, make the script executable: <br />
# chmod +x /etc/acpi/actions/sleep-button.sh<br />
<br />
Using this method, it is easy to create any number of individual event/action scripts.<br />
<br />
==Tips and tricks==<br />
<br />
===Extending acpid with pm-utils===<br />
<br />
Although {{Pkg|acpid}} can provide basic suspend2ram out-of-the-box, a more robust system may be desired. [[pm-utils]] provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, {{ic|pm-suspend}} and {{ic|pm-hibernate}}, both of which can be inserted as events into acpid. For more information, check the [[pm-utils]] wiki.<br />
<br />
===Example Events===<br />
<br />
The following are examples of events that can be used in the {{ic|/etc/acpi/handler.sh}} script. These examples should be modified so that they apply your specific environment e.g. changing the event variable names interpreted by {{ic|acpi_listen}}.<br />
<br />
To lock the screen with {{ic|xscreensaver}} when closing the laptop lid:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
# The lock command need to be run as the user who owns the xscreensaver process and not as root.<br />
# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.<br />
<br />
xs=$(ps -C xscreensaver -o user=)<br />
if test $xs; then su $xs -c "xscreensaver-command -lock"; fi<br />
;;<br />
<br />
To suspend the system and lock the screen using {{ic|slimlock}} when the lid is closed:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
#echo "LID switched!">/dev/tty5<br />
/usr/sbin/pm-suspend &<br />
DISPLAY=:0.0 su -c - username /usr/bin/slimlock<br />
;;<br />
<br />
Execute {{ic|pm-suspend}} when the sleep button is pressed:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SBTN) <br />
#echo -n mem >/sys/power/state<br />
/usr/sbin/pm-suspend<br />
;;<br />
<br />
To set the laptop screen brightness when plugged in power or not (the numbers might need to be adjusted, see {{ic|/sys/class/backlight/acpi_video0/max_brightness}}):<br />
<br />
ac_adapter)<br />
case "$2" in<br />
AC*|AD*)<br />
case "$4" in<br />
00000000)<br />
echo -n 50 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
00000001)<br />
echo -n 100 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
esac<br />
<br />
=== Enabling volume control ===<br />
<br />
Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a pair of scripts to control the volume (assuming an [[ALSA]] sound card):<br />
<br />
{{hc|/etc/acpi/actions/volume_up.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%+<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/actions/volume_down.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%-<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/volume_up|<nowiki><br />
event=button[ /]volumeup<br />
action=/etc/acpi/actions/volume_up.sh<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/events/volume_down|<nowiki><br />
event=button[ /]volumedown<br />
action=/etc/acpi/actions/volume_down.sh<br />
</nowiki>}}<br />
<br />
as well as another event to toggle the mute setting:<br />
<br />
{{hc|/etc/acpi/events/volume_mute|<nowiki><br />
event=button[ /]mute<br />
action=/usr/bin/amixer set Master toggle<br />
</nowiki>}}<br />
<br />
=== Enabling backlight control ===<br />
<br />
Find out the acpi identity of the brightness buttons (see above) and susbtitute it for the acpi events in the files below:<br />
<br />
{{hc|/etc/acpi/actions/bl_up.sh|<nowiki><br />
#!/bin/sh<br />
bl_device=/sys/class/backlight/acpi_video0/<br />
echo $(($(cat $bl_device)+1)) >$bl_device<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/actions/bl_down.sh|<nowiki><br />
#!/bin/sh<br />
bl_device=/sys/class/backlight/acpi_video0/<br />
echo $(($(cat $bl_device)-1)) >$bl_device<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/bl_up|<nowiki><br />
event=video[ /]brightnessup<br />
action=/etc/acpi/actions/bl_up.sh<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/events/bl_down|<nowiki><br />
event=video[ /]brightnessdown<br />
action=/etc/acpi/actions/bl_down.sh<br />
</nowiki>}}<br />
<br />
=== Laptop Monitor Power Off ===<br />
<br />
Adapted from the [http://en.gentoo-wiki.com/wiki/ACPI/Configuration Gentoo Wiki] comes this little gem. Add this to the bottom of {{ic|/etc/acpi/actions/lm_lid.sh}} or to the ''button/lid'' section {{ic|/etc/acpi/handler.sh}}. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force off ;;<br />
open) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force on ;;<br />
esac<br />
<br />
If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.<br />
<br />
Here is another script not using XAUTHORITY but sudo:<br />
<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force off ;;<br />
open) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force on ;;<br />
esac<br />
<br />
With certain combinations of [[Xorg]] and stubborn hardware, {{ic|xset dpms force off}} only blanks the display leaving the backlight turned on. This can be fixed using {{Pkg|vbetool}} from the [[Official Repositories|official repositories]]. Change the LCD section to:<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) vbetool dpms off ;;<br />
open) vbetool dpms on ;;<br />
esac<br />
<br />
If the monitor appears to shut off only briefly before being re-powered, very possibly the power management shipped with xscreensaver conflicts with any manual ''dpms'' settings.<br />
<br />
=== Getting user name of the current display ===<br />
You can use the function {{ic|getuser}} to discover the user of the current display:<br />
getuser ()<br />
{<br />
export DISPLAY=`echo $DISPLAY | cut -c -2`<br />
user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`<br />
export XAUTHORITY=/home/$user/.Xauthority<br />
eval $1=$user<br />
}<br />
<br />
This function can be used for example, when you press the power button and want to shutdown [[KDE]] properly:<br />
button/power)<br />
case "$2" in<br />
PBTN)<br />
getuser "$user"<br />
echo $user > /dev/tty5<br />
su $user -c "dcop ksmserver ksmserver logout 0 2 0"<br />
;;<br />
*) logger "ACPI action undefined $2" ;;<br />
esac<br />
;;<br />
<br />
<br />
On newer systems using systemd, X11 logins are no longer necessarily displayed in {{ic|who}}, so the {{ic|getuser}} function above does not work. An alternative is to use {{ic|loginctl}} to obtain the required information, e.g. using [https://github.com/rephorm/xuserrun xuserrun].<br />
<br />
==See also==<br />
<br />
* http://acpid.sourceforge.net/ - acpid homepage<br />
* http://www.gentoo-wiki.info/ACPI/Configuration - RIP Gentoo wiki entry - New Gentoo Wiki Archives<br />
* [[ACPI hotkeys]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Acpid&diff=236561Acpid2012-11-23T23:33:11Z<p>Eruditorum: /* Enabling backlight control */</p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Power management]]<br />
[[Category:Daemons and system services]]<br />
[[it:Acpid]]<br />
[[zh-CN:Acpid]]<br />
<br />
[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering [[ACPI modules|ACPI events]]. It listens on {{ic|/proc/acpi/event}} and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:<br />
* Pressing special keys, including the Power/Sleep/Suspend button<br />
* Closing a notebook lid<br />
* (Un)Plugging an AC power adapter from a notebook<br />
* (Un)Plugging phone jack etc.<br />
<br />
acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.<br />
<br />
{{Note|<br />
* [[Desktop Environment|desktop environments]], such as [[GNOME]], [[Systemd#ACPI power management|systemd]] login manager and some [[Extra Keyboard Keys|extra key handling]] daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.<br />
* Since by default the script provided by acpid, '''/etc/acpi/handler.sh''', will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).}}<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].<br />
<br />
To have it start on boot :<br />
* if you're using [[systemd]], run {{ic|systemctl enable acpid}} ;<br />
* if you're using [[rc.conf|initscripts]], edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]].<br />
<br />
== Configuration ==<br />
<br />
{{Pkg|acpid}} comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in {{ic|/etc/acpi/handler.sh}}, which is executed after any ACPI events are detected (as determined by {{ic|/etc/acpi/events/anything}}).<br />
<br />
The following is a brief example of one such action. In this case, when the Sleep button is pressed, acpid runs the command {{ic|echo -n mem >/sys/power/state}} which ''should'' place the computer into a sleep (suspend) state:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
;;<br />
<br />
Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as ''SLPB'' and on another as ''SBTN''. <br />
<br />
To determine how your buttons or {{Keypress|Fn}} shortcuts are recognized, run the following command from a terminal as root:<br />
# tail -f /var/log/messages.log<br />
<br />
Now press the Power button and/or Sleep button (e.g. {{Keypress|Fn+Esc}}) on your machine. The result should look something this:<br />
logger: ACPI action undefined: PBTN<br />
logger: ACPI action undefined: SBTN<br />
<br />
If that does not work, run:<br />
# acpi_listen<br />
<br />
Then press the power button and you will see something like this:<br />
power/button PBTN 00000000 00000b31<br />
<br />
The output of {{ic|acpi_listen}} is sent to {{ic|/etc/acpi/handler.sh}} as $1, $2 , $3 & $4 parameters.<br />
Example:<br />
$1 power/button<br />
$2 PBTN<br />
$3 00000000<br />
$4 00000b31<br />
<br />
As you might have noticed, the Sleep button in the sample output is actually recognized as ''SBTN'', rather than the ''SLPB'' label specified in the default {{ic|/etc/acpi/handler.sh}}. In order for Sleep function to work properly on this machine, we would need to replace ''SLPB)'' with ''SBTN)''.<br />
<br />
Using this information as a base, you can easily customize the {{ic|/etc/acpi/handler.sh}} file to execute a variety of commands depending on which event is triggered. See the [[Acpid#Tips & Tricks | Tips & Tricks]] section below for other commonly used commands.<br />
<br />
=== Alternative configuration ===<br />
<br />
By default, all ACPI events are passed through the {{ic|/etc/acpi/handler.sh}} script. This is due to the ruleset outlined in {{ic|/etc/acpi/events/anything}}:<br />
# Pass all events to our one handler script<br />
event=.*<br />
action=/etc/acpi/handler.sh %e<br />
<br />
While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:<br />
<br />
As root, create the following file:<br />
{{hc|/etc/acpi/events/sleep-button|<nowiki><br />
event=button sleep.*<br />
action=/etc/acpi/actions/sleep-button.sh "%e"<br />
</nowiki>}}<br />
<br />
Now create the following file:<br />
{{hc|/etc/acpi/actions/sleep-button.sh|<nowiki><br />
#!/bin/sh<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
</nowiki>}}<br />
<br />
Finally, make the script executable: <br />
# chmod +x /etc/acpi/actions/sleep-button.sh<br />
<br />
Using this method, it is easy to create any number of individual event/action scripts.<br />
<br />
==Tips and tricks==<br />
<br />
===Extending acpid with pm-utils===<br />
<br />
Although {{Pkg|acpid}} can provide basic suspend2ram out-of-the-box, a more robust system may be desired. [[pm-utils]] provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, {{ic|pm-suspend}} and {{ic|pm-hibernate}}, both of which can be inserted as events into acpid. For more information, check the [[pm-utils]] wiki.<br />
<br />
===Example Events===<br />
<br />
The following are examples of events that can be used in the {{ic|/etc/acpi/handler.sh}} script. These examples should be modified so that they apply your specific environment e.g. changing the event variable names interpreted by {{ic|acpi_listen}}.<br />
<br />
To lock the screen with {{ic|xscreensaver}} when closing the laptop lid:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
# The lock command need to be run as the user who owns the xscreensaver process and not as root.<br />
# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.<br />
<br />
xs=$(ps -C xscreensaver -o user=)<br />
if test $xs; then su $xs -c "xscreensaver-command -lock"; fi<br />
;;<br />
<br />
To suspend the system and lock the screen using {{ic|slimlock}} when the lid is closed:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
#echo "LID switched!">/dev/tty5<br />
/usr/sbin/pm-suspend &<br />
DISPLAY=:0.0 su -c - username /usr/bin/slimlock<br />
;;<br />
<br />
Execute {{ic|pm-suspend}} when the sleep button is pressed:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SBTN) <br />
#echo -n mem >/sys/power/state<br />
/usr/sbin/pm-suspend<br />
;;<br />
<br />
To set the laptop screen brightness when plugged in power or not (the numbers might need to be adjusted, see {{ic|/sys/class/backlight/acpi_video0/max_brightness}}):<br />
<br />
ac_adapter)<br />
case "$2" in<br />
AC*|AD*)<br />
case "$4" in<br />
00000000)<br />
echo -n 50 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
00000001)<br />
echo -n 100 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
esac<br />
<br />
=== Enabling volume control ===<br />
<br />
Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a pair of scripts to control the volume (assuming an [[ALSA]] sound card):<br />
<br />
{{hc|/etc/acpi/actions/volume_up.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%+<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/actions/volume_down.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%-<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/volume_up|<nowiki><br />
event=button[ /]volumeup<br />
action=/etc/acpi/actions/volume_up.sh<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/events/volume_down|<nowiki><br />
event=button[ /]volumedown<br />
action=/etc/acpi/actions/volume_down.sh<br />
</nowiki>}}<br />
<br />
as well as another event to toggle the mute setting:<br />
<br />
{{hc|/etc/acpi/events/volume_mute|<nowiki><br />
event=button[ /]mute<br />
action=/usr/bin/amixer set Master toggle<br />
</nowiki>}}<br />
<br />
=== Enabling backlight control ===<br />
<br />
Find out the acpi identity of the brightness buttons (see above) and susbtitute it for the acpi events in the files below:<br />
<br />
{{hc|/etc/acpi/actions/bl_up.sh|<nowiki><br />
#!/bin/sh<br />
/usr/bin/amixer set Master 5%+<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/actions/bl_down.sh|<nowiki><br />
#!/bin/sh<br />
/usr/bin/amixer set Master 5%-<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/bl_up|<nowiki><br />
event=button[ /]volumeup<br />
action=/etc/acpi/actions/volume_up.sh<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/events/bl_down|<nowiki><br />
event=button[ /]volumedown<br />
action=/etc/acpi/actions/volume_down.sh<br />
</nowiki>}}<br />
<br />
=== Laptop Monitor Power Off ===<br />
<br />
Adapted from the [http://en.gentoo-wiki.com/wiki/ACPI/Configuration Gentoo Wiki] comes this little gem. Add this to the bottom of {{ic|/etc/acpi/actions/lm_lid.sh}} or to the ''button/lid'' section {{ic|/etc/acpi/handler.sh}}. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force off ;;<br />
open) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force on ;;<br />
esac<br />
<br />
If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.<br />
<br />
Here is another script not using XAUTHORITY but sudo:<br />
<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force off ;;<br />
open) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force on ;;<br />
esac<br />
<br />
With certain combinations of [[Xorg]] and stubborn hardware, {{ic|xset dpms force off}} only blanks the display leaving the backlight turned on. This can be fixed using {{Pkg|vbetool}} from the [[Official Repositories|official repositories]]. Change the LCD section to:<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) vbetool dpms off ;;<br />
open) vbetool dpms on ;;<br />
esac<br />
<br />
If the monitor appears to shut off only briefly before being re-powered, very possibly the power management shipped with xscreensaver conflicts with any manual ''dpms'' settings.<br />
<br />
=== Getting user name of the current display ===<br />
You can use the function {{ic|getuser}} to discover the user of the current display:<br />
getuser ()<br />
{<br />
export DISPLAY=`echo $DISPLAY | cut -c -2`<br />
user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`<br />
export XAUTHORITY=/home/$user/.Xauthority<br />
eval $1=$user<br />
}<br />
<br />
This function can be used for example, when you press the power button and want to shutdown [[KDE]] properly:<br />
button/power)<br />
case "$2" in<br />
PBTN)<br />
getuser "$user"<br />
echo $user > /dev/tty5<br />
su $user -c "dcop ksmserver ksmserver logout 0 2 0"<br />
;;<br />
*) logger "ACPI action undefined $2" ;;<br />
esac<br />
;;<br />
<br />
<br />
On newer systems using systemd, X11 logins are no longer necessarily displayed in {{ic|who}}, so the {{ic|getuser}} function above does not work. An alternative is to use {{ic|loginctl}} to obtain the required information, e.g. using [https://github.com/rephorm/xuserrun xuserrun].<br />
<br />
==See also==<br />
<br />
* http://acpid.sourceforge.net/ - acpid homepage<br />
* http://www.gentoo-wiki.info/ACPI/Configuration - RIP Gentoo wiki entry - New Gentoo Wiki Archives<br />
* [[ACPI hotkeys]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Acpid&diff=236560Acpid2012-11-23T23:30:23Z<p>Eruditorum: </p>
<hr />
<div>{{lowercase title}}<br />
[[Category:Power management]]<br />
[[Category:Daemons and system services]]<br />
[[it:Acpid]]<br />
[[zh-CN:Acpid]]<br />
<br />
[http://acpid.sourceforge.net/ acpid] is a flexible and extensible daemon for delivering [[ACPI modules|ACPI events]]. It listens on {{ic|/proc/acpi/event}} and when an event occurs, executes programs to handle the event. These events are triggered by certain actions, such as:<br />
* Pressing special keys, including the Power/Sleep/Suspend button<br />
* Closing a notebook lid<br />
* (Un)Plugging an AC power adapter from a notebook<br />
* (Un)Plugging phone jack etc.<br />
<br />
acpid can be used by itself, or combined with a more robust system such as [[pm-utils]] and [[CPU Frequency Scaling|cpufrequtils]] to provide a more complete power management solution.<br />
<br />
{{Note|<br />
* [[Desktop Environment|desktop environments]], such as [[GNOME]], [[Systemd#ACPI power management|systemd]] login manager and some [[Extra Keyboard Keys|extra key handling]] daemons may implement own event handling schemes, independent of acpid. Running more than one system at the same time may lead to unexpected behaviour, such as suspending two times in a row after one sleep button press. You should be aware of this and only activate desirable handlers.<br />
* Since by default the script provided by acpid, '''/etc/acpi/handler.sh''', will override your desktop environment's power button functionality, you most likely want to change acpid's power off routine to avoid shutting down the system suddenly when you press the power button (see instructions below).}}<br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] the {{Pkg|acpid}} package, available in the [[Official Repositories|official repositories]].<br />
<br />
To have it start on boot :<br />
* if you're using [[systemd]], run {{ic|systemctl enable acpid}} ;<br />
* if you're using [[rc.conf|initscripts]], edit {{ic|/etc/rc.conf}} as root and add {{ic|acpid}} to the [[rc.conf#Daemons|DAEMONS array]].<br />
<br />
== Configuration ==<br />
<br />
{{Pkg|acpid}} comes with a number of predefined actions for triggered events, such as what should happen when you press the Power button on your machine. By default, these actions are defined in {{ic|/etc/acpi/handler.sh}}, which is executed after any ACPI events are detected (as determined by {{ic|/etc/acpi/events/anything}}).<br />
<br />
The following is a brief example of one such action. In this case, when the Sleep button is pressed, acpid runs the command {{ic|echo -n mem >/sys/power/state}} which ''should'' place the computer into a sleep (suspend) state:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
;;<br />
<br />
Unfortunately, not every computer labels ACPI events in the same way. For example, the Sleep button may be identified on one machine as ''SLPB'' and on another as ''SBTN''. <br />
<br />
To determine how your buttons or {{Keypress|Fn}} shortcuts are recognized, run the following command from a terminal as root:<br />
# tail -f /var/log/messages.log<br />
<br />
Now press the Power button and/or Sleep button (e.g. {{Keypress|Fn+Esc}}) on your machine. The result should look something this:<br />
logger: ACPI action undefined: PBTN<br />
logger: ACPI action undefined: SBTN<br />
<br />
If that does not work, run:<br />
# acpi_listen<br />
<br />
Then press the power button and you will see something like this:<br />
power/button PBTN 00000000 00000b31<br />
<br />
The output of {{ic|acpi_listen}} is sent to {{ic|/etc/acpi/handler.sh}} as $1, $2 , $3 & $4 parameters.<br />
Example:<br />
$1 power/button<br />
$2 PBTN<br />
$3 00000000<br />
$4 00000b31<br />
<br />
As you might have noticed, the Sleep button in the sample output is actually recognized as ''SBTN'', rather than the ''SLPB'' label specified in the default {{ic|/etc/acpi/handler.sh}}. In order for Sleep function to work properly on this machine, we would need to replace ''SLPB)'' with ''SBTN)''.<br />
<br />
Using this information as a base, you can easily customize the {{ic|/etc/acpi/handler.sh}} file to execute a variety of commands depending on which event is triggered. See the [[Acpid#Tips & Tricks | Tips & Tricks]] section below for other commonly used commands.<br />
<br />
=== Alternative configuration ===<br />
<br />
By default, all ACPI events are passed through the {{ic|/etc/acpi/handler.sh}} script. This is due to the ruleset outlined in {{ic|/etc/acpi/events/anything}}:<br />
# Pass all events to our one handler script<br />
event=.*<br />
action=/etc/acpi/handler.sh %e<br />
<br />
While this works just fine as it is, some users may prefer to define event rules and actions in their own self-contained scripts. The following is an example of how to use an individual event file and corresponding action script:<br />
<br />
As root, create the following file:<br />
{{hc|/etc/acpi/events/sleep-button|<nowiki><br />
event=button sleep.*<br />
action=/etc/acpi/actions/sleep-button.sh "%e"<br />
</nowiki>}}<br />
<br />
Now create the following file:<br />
{{hc|/etc/acpi/actions/sleep-button.sh|<nowiki><br />
#!/bin/sh<br />
case "$2" in<br />
SLPB) echo -n mem >/sys/power/state ;;<br />
*) logger "ACPI action undefined: $2" ;;<br />
esac<br />
</nowiki>}}<br />
<br />
Finally, make the script executable: <br />
# chmod +x /etc/acpi/actions/sleep-button.sh<br />
<br />
Using this method, it is easy to create any number of individual event/action scripts.<br />
<br />
==Tips and tricks==<br />
<br />
===Extending acpid with pm-utils===<br />
<br />
Although {{Pkg|acpid}} can provide basic suspend2ram out-of-the-box, a more robust system may be desired. [[pm-utils]] provides a very flexible framework for suspend2ram (suspend) and suspend2disk (hibernate) operations, including common fixes for stubborn hardware and drivers (e.g. fglrx module). pm-utils provides two scripts, {{ic|pm-suspend}} and {{ic|pm-hibernate}}, both of which can be inserted as events into acpid. For more information, check the [[pm-utils]] wiki.<br />
<br />
===Example Events===<br />
<br />
The following are examples of events that can be used in the {{ic|/etc/acpi/handler.sh}} script. These examples should be modified so that they apply your specific environment e.g. changing the event variable names interpreted by {{ic|acpi_listen}}.<br />
<br />
To lock the screen with {{ic|xscreensaver}} when closing the laptop lid:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
# The lock command need to be run as the user who owns the xscreensaver process and not as root.<br />
# See: man xscreensaver-command. $xs will have the value of the user owning the process, if any.<br />
<br />
xs=$(ps -C xscreensaver -o user=)<br />
if test $xs; then su $xs -c "xscreensaver-command -lock"; fi<br />
;;<br />
<br />
To suspend the system and lock the screen using {{ic|slimlock}} when the lid is closed:<br />
<br />
button/lid)<br />
case $3 in<br />
close)<br />
#echo "LID switched!">/dev/tty5<br />
/usr/sbin/pm-suspend &<br />
DISPLAY=:0.0 su -c - username /usr/bin/slimlock<br />
;;<br />
<br />
Execute {{ic|pm-suspend}} when the sleep button is pressed:<br />
<br />
button/sleep)<br />
case "$2" in<br />
SBTN) <br />
#echo -n mem >/sys/power/state<br />
/usr/sbin/pm-suspend<br />
;;<br />
<br />
To set the laptop screen brightness when plugged in power or not (the numbers might need to be adjusted, see {{ic|/sys/class/backlight/acpi_video0/max_brightness}}):<br />
<br />
ac_adapter)<br />
case "$2" in<br />
AC*|AD*)<br />
case "$4" in<br />
00000000)<br />
echo -n 50 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
00000001)<br />
echo -n 100 > /sys/class/backlight/acpi_video0/brightness<br />
;;<br />
esac<br />
<br />
=== Enabling volume control ===<br />
<br />
Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a pair of scripts to control the volume (assuming an [[ALSA]] sound card):<br />
<br />
{{hc|/etc/acpi/actions/volume_up.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%+<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/actions/volume_down.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%-<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/volume_up|<nowiki><br />
event=button[ /]volumeup<br />
action=/etc/acpi/actions/volume_up.sh<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/events/volume_down|<nowiki><br />
event=button[ /]volumedown<br />
action=/etc/acpi/actions/volume_down.sh<br />
</nowiki>}}<br />
<br />
as well as another event to toggle the mute setting:<br />
<br />
{{hc|/etc/acpi/events/volume_mute|<nowiki><br />
event=button[ /]mute<br />
action=/usr/bin/amixer set Master toggle<br />
</nowiki>}}<br />
<br />
=== Enabling backlight control ===<br />
<br />
Find out the acpi identity of the volume buttons (see above) and susbtitute it for the acpi events in the files below. We create a pair of scripts to control the volume (assuming an [[ALSA]] sound card):<br />
<br />
{{hc|/etc/acpi/actions/volume_up.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%+<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/actions/volume_down.sh|<nowiki><br />
#!/bin/bash<br />
/usr/bin/amixer set Master 5%-<br />
</nowiki>}}<br />
<br />
and connect these to new acpi events:<br />
<br />
{{hc|/etc/acpi/events/volume_up|<nowiki><br />
event=button[ /]volumeup<br />
action=/etc/acpi/actions/volume_up.sh<br />
</nowiki>}}<br />
<br />
{{hc|/etc/acpi/events/volume_down|<nowiki><br />
event=button[ /]volumedown<br />
action=/etc/acpi/actions/volume_down.sh<br />
</nowiki>}}<br />
<br />
as well as another event to toggle the mute setting:<br />
<br />
{{hc|/etc/acpi/events/volume_mute|<nowiki><br />
event=button[ /]mute<br />
action=/usr/bin/amixer set Master toggle<br />
</nowiki>}}<br />
<br />
=== Laptop Monitor Power Off ===<br />
<br />
Adapted from the [http://en.gentoo-wiki.com/wiki/ACPI/Configuration Gentoo Wiki] comes this little gem. Add this to the bottom of {{ic|/etc/acpi/actions/lm_lid.sh}} or to the ''button/lid'' section {{ic|/etc/acpi/handler.sh}}. This will turn off the LCD back-light when the lid is closed, and restart when the lid is opened.<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force off ;;<br />
open) XAUTHORITY=$(ps -C xinit -f --no-header | sed -n 's/.*-auth //; s/ -[^ ].*//; p') xset -display :0 dpms force on ;;<br />
esac<br />
<br />
If you would like to increase/decrease brightness or anything dependent on X, you should specify the X display as well as the MIT magic cookie file (via XAUTHORITY). The last is a security credential providing read and write access to the X server, display, and any input devices.<br />
<br />
Here is another script not using XAUTHORITY but sudo:<br />
<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force off ;;<br />
open) sudo -u `ps -o ruser= -C xinit` xset -display :0 dpms force on ;;<br />
esac<br />
<br />
With certain combinations of [[Xorg]] and stubborn hardware, {{ic|xset dpms force off}} only blanks the display leaving the backlight turned on. This can be fixed using {{Pkg|vbetool}} from the [[Official Repositories|official repositories]]. Change the LCD section to:<br />
case $(cat /proc/acpi/button/lid/LID0/state | awk '{print $2}') in<br />
closed) vbetool dpms off ;;<br />
open) vbetool dpms on ;;<br />
esac<br />
<br />
If the monitor appears to shut off only briefly before being re-powered, very possibly the power management shipped with xscreensaver conflicts with any manual ''dpms'' settings.<br />
<br />
=== Getting user name of the current display ===<br />
You can use the function {{ic|getuser}} to discover the user of the current display:<br />
getuser ()<br />
{<br />
export DISPLAY=`echo $DISPLAY | cut -c -2`<br />
user=`who | grep " $DISPLAY" | awk '{print $1}' | tail -n1`<br />
export XAUTHORITY=/home/$user/.Xauthority<br />
eval $1=$user<br />
}<br />
<br />
This function can be used for example, when you press the power button and want to shutdown [[KDE]] properly:<br />
button/power)<br />
case "$2" in<br />
PBTN)<br />
getuser "$user"<br />
echo $user > /dev/tty5<br />
su $user -c "dcop ksmserver ksmserver logout 0 2 0"<br />
;;<br />
*) logger "ACPI action undefined $2" ;;<br />
esac<br />
;;<br />
<br />
<br />
On newer systems using systemd, X11 logins are no longer necessarily displayed in {{ic|who}}, so the {{ic|getuser}} function above does not work. An alternative is to use {{ic|loginctl}} to obtain the required information, e.g. using [https://github.com/rephorm/xuserrun xuserrun].<br />
<br />
==See also==<br />
<br />
* http://acpid.sourceforge.net/ - acpid homepage<br />
* http://www.gentoo-wiki.info/ACPI/Configuration - RIP Gentoo wiki entry - New Gentoo Wiki Archives<br />
* [[ACPI hotkeys]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=236556Power saving2012-11-23T22:53:53Z<p>Eruditorum: /* Bluetooth */</p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
{{Warning|In some cases forcing on ASPM can even increase power consumption.}}<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
Alternatively, [[Kernel_modules#Blacklisting|blacklist]] the {{ic|btusb}} and {{ic|bluetooth}} modules.<br />
<br />
Another variant is to {{pkg|rfkill}} it:<br />
# rfkill block bluetooth<br />
<br />
== Web-Camera ==<br />
If you won't use integrated web camera then [[Kernel_modules#Blacklisting|blacklist]] the {{ic|uvcvideo}} module.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|1=nmi_watchdog=0}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for one interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol_eth0.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="net0" RUN+="/usr/sbin/ethtool -s net0 wol d"}}<br />
<br />
Disabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
{{hc|/etc/udev/rules.d/usb_power_save.rules|2=ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="auto"<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/autosuspend" ATTR{power/autosuspend}="2"}}<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=236555Power saving2012-11-23T22:43:35Z<p>Eruditorum: </p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
{{Warning|In some cases forcing on ASPM can even increase power consumption.}}<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
== Web-Camera ==<br />
If you won't use integrated web camera then [[Kernel_modules#Blacklisting|blacklist]] the {{ic|uvcvideo}} module.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|1=nmi_watchdog=0}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for one interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol_eth0.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="net0" RUN+="/usr/sbin/ethtool -s net0 wol d"}}<br />
<br />
Disabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
{{hc|/etc/udev/rules.d/usb_power_save.rules|2=ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="auto"<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/autosuspend" ATTR{power/autosuspend}="2"}}<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=236552Power saving2012-11-23T22:11:18Z<p>Eruditorum: /* Disabling NMI watchdog */</p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
{{Warning|In some cases forcing on ASPM can even increase power consumption.}}<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|1=nmi_watchdog=0}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for one interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol_eth0.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="net0" RUN+="/usr/sbin/ethtool -s net0 wol d"}}<br />
<br />
Disabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
{{hc|/etc/udev/rules.d/usb_power_save.rules|2=ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="auto"<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/autosuspend" ATTR{power/autosuspend}="2"}}<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=236551Power saving2012-11-23T22:09:19Z<p>Eruditorum: /* Disabling NMI watchdog */</p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
{{Warning|In some cases forcing on ASPM can even increase power consumption.}}<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|nmi_watchdog = 0}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for one interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol_eth0.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="net0" RUN+="/usr/sbin/ethtool -s net0 wol d"}}<br />
<br />
Disabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
{{hc|/etc/udev/rules.d/usb_power_save.rules|2=ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="auto"<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/autosuspend" ATTR{power/autosuspend}="2"}}<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=236550Power saving2012-11-23T22:08:52Z<p>Eruditorum: /* Disabling NMI watchdog */</p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
{{Warning|In some cases forcing on ASPM can even increase power consumption.}}<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|nmi_watchdog=0}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for one interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol_eth0.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="net0" RUN+="/usr/sbin/ethtool -s net0 wol d"}}<br />
<br />
Disabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
{{hc|/etc/udev/rules.d/usb_power_save.rules|2=ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="auto"<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/autosuspend" ATTR{power/autosuspend}="2"}}<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=236549Power saving2012-11-23T21:57:58Z<p>Eruditorum: /* Active State Power Management */</p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
{{Warning|In some cases forcing on ASPM can even increase power consumption.}}<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|nmi_watchdog}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for one interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol_eth0.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="net0" RUN+="/usr/sbin/ethtool -s net0 wol d"}}<br />
<br />
Disabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
{{hc|/etc/udev/rules.d/usb_power_save.rules|2=ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="auto"<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/autosuspend" ATTR{power/autosuspend}="2"}}<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=236548Power saving2012-11-23T21:52:45Z<p>Eruditorum: /* USB Autosuspend */</p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|nmi_watchdog}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for one interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol_eth0.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="net0" RUN+="/usr/sbin/ethtool -s net0 wol d"}}<br />
<br />
Disabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
{{hc|/etc/udev/rules.d/usb_power_save.rules|2=ACTION=="add", SUBSYSTEM=="usb", TEST=="power/control" ATTR{power/control}="auto"<br />
ACTION=="add", SUBSYSTEM=="usb", TEST=="power/autosuspend" ATTR{power/autosuspend}="2"}}<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorumhttps://wiki.archlinux.org/index.php?title=Power_saving&diff=236547Power saving2012-11-23T21:50:06Z<p>Eruditorum: /* SATA Active Link Powermanagement */</p>
<hr />
<div>[[Category:Power management]]<br />
This article covers the configuration needed to turn on power saving features. Almost all of the features listed here are worth using whether or not the computer is on AC or battery power. Most have negligible performance impact and are just not enabled by default because of commonly broken hardware/drivers. Reducing power usage means reducing heat, which can even lead to higher performance on a modern Intel or AMD CPU, thanks to [[Wikipedia:Intel Turbo Boost|dynamic overclocking]].<br />
<br />
==Audio==<br />
<br />
By default, audio power saving is turned off by most drivers. It can be enabled by setting the power_save parameter to a time (in seconds) to go in idle.<br />
<br />
{{Note|Toggling the audio card's power state can cause a popping sound or noticeable latency on some broken hardware.}}<br />
<br />
;Intel<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_hda_intel power_save=1}}<br />
<br />
;ac97<br />
<br />
{{hc|/etc/modprobe.d/audio_power_save.conf|2=options snd_ac97_codec power_save=1}}<br />
<br />
==Active State Power Management==<br />
<br />
To verify that [[Wikipedia:Active State Power Management|ASPM]] is enabled:<br />
<br />
{{hc|$ cat /sys/module/pcie_aspm/parameters/policy|[default] performance powersave}}<br />
<br />
Either {{ic|[default]}} or {{ic|[powersave]}} means you do not need to force it on.<br />
<br />
Otherwise, it's either unsupported/broken on your hardware, or has to be forced on with {{ic|1=pcie_aspm=force}} on the [[kernel line]].<br />
<br />
{{Warning|Forcing on ASPM can cause a freeze/panic, so make sure you have a way to undo the option if it doesn't work.}}<br />
<br />
== Bluetooth ==<br />
{{expansion|reason=The device should likely be disabled with hciconfig first.}}<br />
[[Kernel_modules#Blacklisting|Blacklist]] the {{ic|hci_usb}} module if the driver is loaded automatically.<br />
<br />
==Disabling NMI watchdog==<br />
The [[Wikipedia:Non-maskable interrupt|NMI]] watchdog is a debugging feature to catch hardware hangs and cause a kernel panic. On some systems it can generate a lot of interrupts, causing a noticeable increase in power usage.<br />
<br />
{{hc|/etc/sysctl.d/disable_watchdog.conf|2=kernel.nmi_watchdog = 0}}<br />
<br />
or add {{ic|nmi_watchdog}} as a [[kernel parameter]] to disable it completely from early boot.<br />
<br />
==Disabling Wake-on-LAN==<br />
<br />
[[Wikipedia:Wake-on-LAN|Wake-on-LAN]] can be a useful feature, but if you're not making use of it then it's simply draining extra power waiting for a magic packet while in suspend.<br />
<br />
Disabling for one interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol_eth0.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="net0" RUN+="/usr/sbin/ethtool -s net0 wol d"}}<br />
<br />
Disabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/disable_wol.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="eth*" RUN+="/usr/sbin/ethtool -s %k wol d"}}<br />
<br />
== PCI Runtime Power Management ==<br />
<br />
{{hc|/etc/udev/rules.d/pci_pm.rules|2=ACTION=="add", SUBSYSTEM=="pci", ATTR{power/control}="auto"}}<br />
<br />
==Wireless power saving==<br />
<br />
Enabling for a specific interface:<br />
<br />
{{Note|This should be combined with [[udev#Network device|static naming]] of devices, the eth* names are not static.}}<br />
<br />
{{hc|/etc/udev/rules.d/wlan0_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wifi0" RUN+="/usr/sbin/iw dev wifi0 set power_save on"}}<br />
<br />
Enabling for all interfaces:<br />
<br />
{{hc|/etc/udev/rules.d/wifi_power_save.rules|2=ACTION=="add", SUBSYSTEM=="net", KERNEL=="wlan*" RUN+="/usr/sbin/iw dev %k set power_save on"}}<br />
<br />
== Writeback Time ==<br />
Increasing the VM dirty writeback time can help to aggregate I/O together - reducing disk writes, and decreasing power usage:<br />
<br />
{{hc|/etc/sysctl.d/dirty_writeback.conf|2=vm.dirty_writeback_centisecs = 1500}}<br />
<br />
To do the same for journal commits with ext4 and some other filesystems, use {{ic|1=commit=15}} as a parameter in [[fstab]] or with the {{ic|rootflags}} [[kernel parameter]].<br />
<br />
== Laptop Mode ==<br />
<br />
{{hc|/etc/sysctl.d/laptop_mode.conf|2=vm.laptop_mode = 5}}<br />
<br />
== SATA Active Link Powermanagement ==<br />
{{Note|This adds latency when accessing a drive that has been idle, so it's one of the few settings that may be worth toggling based on whether you're on AC power.}}<br />
{{hc|/etc/udev/rules.d/hd_power_save.rules|2=SUBSYSTEM=="scsi_host", KERNEL=="host*", ATTR{link_power_management_policy}="min_power"}}<br />
<br />
== USB Autosuspend ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
To enable USB autosuspend after 2 seconds of inactivity:<br />
for i in `find /sys/bus/usb/devices/*/power/control`; do echo auto > $i; done;<br />
for i in `find /sys/bus/usb/devices/*/power/autosuspend`; do echo '''2''' > $i; done;<br />
<br />
== Device Power Management ==<br />
{{accuracy|reason=Should be done with a udev rule.}}<br />
<br />
echo auto | tee /sys/bus/i2c/devices/*/power/control > /dev/null<br />
echo auto | tee /sys/bus/spi/devices/*/power/control > /dev/null<br />
<br />
== View Power Setings ==<br />
This function shows various power settings. Note you either must be root or you must have sudo.<br />
<br />
{{bc|<nowiki>function aa_power_settings ()<br />
{ <br />
sudo bash -c '<br />
for i in `find /sys/devices -name "bMaxPower"`;<br />
do<br />
for ii in `find $i -type f`;<br />
do<br />
bd=`dirname $ii`;<br />
busnum=`cat $bd/busnum`;<br />
devnum=`cat $bd/devnum`;<br />
title=`lsusb -s $busnum:$devnum`;<br />
echo -e "\n\n+++ $title\n -$bd\n -$ii";<br />
for ff in `find $bd/power -type f ! -empty 2>/dev/null`;<br />
do<br />
v=`cat $ff 2>/dev/null|tr -d "\n"`;<br />
[[ ${#v} -gt 0 ]] && echo -e " `basename $ff`=$v";<br />
v=;<br />
done | sort -g;<br />
done;<br />
done;<br />
echo -e "\n\n\n+++ Kernel Modules\n";<br />
for m in `command lspci -k|sed -n "/in use:/s,^.*: ,,p"|sort -u`;<br />
do<br />
echo "+ $m";<br />
systool -v -m $m 2> /dev/null | sed -n "/Parameters:/,/^$/p";<br />
done<br />
';<br />
}</nowiki>}}<br />
<br />
== See also ==<br />
<br />
* [[CPU Frequency Scaling]]</div>Eruditorum