https://wiki.archlinux.org/api.php?action=feedcontributions&user=JaMeSiTeGeN&feedformat=atomArchWiki - User contributions [en]2024-03-29T07:01:37ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Dm-crypt&diff=218417Dm-crypt2012-08-17T10:26:44Z<p>JaMeSiTeGeN: /* LVM with Arch Linux Installer (>2009.08 <2012.07.15) */</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Disk Encryption}}<br />
{{Article summary wiki|Removing System Encryption}}<br />
{{Article summary end}}<br />
<br />
This article focuses on how to set up full system encryption on Arch Linux, using dm-crypt with LUKS.<br />
<br />
'''dm-crypt''' is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management.<br />
<br />
'''LUKS''' is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
For more details on how dm-crypt+LUKS compares to other disk encryption solution, see [[Disk Encryption#Comparison table]].<br />
<br />
== Caveats ==<br />
<br />
===discard/TRIM support for solid state disks===<br />
<br />
{{Moveto|another place within this article|It describes a specific cryptdevice option which certain users may or may not want to set. This is something the user should deal with when she reaches the step of choosing cryptdevice options, not in the context of the article introduction.}}<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can be accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Hard Disk Drive ===<br />
<br />
{{Merge|Securely_wipe_disk|None of this specific to ''System Encryption with LUKS''. The info that is specific to disk encryption in general has already been duplicated at [[Disk_Encryption#Preparing_the_disk]]; the rest should be merged with [[Securely_wipe_disk]]. This section should then be deleted and replaced with a link to [[Disk_Encryption#Preparing_the_disk]].}}<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk drive ''multiple'' times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Hard Disk Drives'''<br />
<br />
::In hard drives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data, it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/dev/random}} uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten, it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*[[LVM]]<br />
::*[[RAID]]<br />
<br />
LUKS is compatible with systems that require LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
====Standard Partitions====<br />
<br />
These are the partitions that most people are familiar with. They come in three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
====How does LVM fit into the overall system?====<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKS). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKS on LVM). However, the deployment of LVM on LUKS is considered much more generalizable. One reason for this is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
=====Single Disk Systems=====<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However, if LVM is to be used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/boot}} and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the {{ic|/arch/setup}} program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in the dialogue for manual configuration of the hard drive.<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<br />
<br />
{{Note|If hibernation usage is planned, swap must be encrypted in this fashion; otherwise, if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
{{Warning|Irrespective of the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them.<br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<br />
<br />
{{Warning|In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see [https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_GPG_or_OpenSSL_Encrypted_Keyfiles Section 9] for details, but please still read this section.}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it is used as the passphrase to unlock an encrypted volume.<br />
Therefore if these files are lost or changed, decrypting the volume will no longer be possible.<br />
<br />
{{Tip|Define a passphrase in addition to the keyfile for backup access to encrypted volumes in the event the defined keyfile is lost or changed.}}<br />
<br />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<br />
<br />
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<br />
<br />
This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.<br />
<br />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<br />
<br />
LUKS supports the association of up to 8 keys with any single encrypted volume.<br />
Keys can be either keyfiles or passphrases.<br />
<br />
Once an encrytped partition has been created, the initial key is associated at slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/dev/<encrypted volume>}} is the volume that is to have the new key associated with it.<br />
<br />
If the bolded area is present, cryptsetup will look for the keyfile defined at that location to associate with the encrypted volume specified.<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} is somewhat arbitrary and depends on how many storage devices are attached and in what order, etc.<br />
So in order to assure that the {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a [[udev]] rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# ls -l /dev/disk/by-uuid/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1}}<br />
<br />
In this case, I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/dev/disk/by-uuid/4803-8A7B}}. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
{{Note|If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) itself.<br />
Create a udev rule instead as described in the following section.}}<br />
<br />
==== Using udev ====<br />
Optionally you may choose to set up your flash drive with a [[udev]] rule. There is some documentation in the Arch wiki about that already; if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%n}} will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute. If you have a custom rule of your own, you can put it in as well (e.g. using the vendor name).<br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of {{ic|/dev}}:<br />
ls /dev<br />
It should show your device with your desired name.<br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage device, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above.<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|mkinitcpio}} about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it is assumed that you use a FAT formatted USB drive. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. [[GRUB]] needs the first 16 sectors (actually, it depends on the type of the file system, so do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>16}}; otherwise you would overwrite parts of your GRUB installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
''Optional''<br />
If you do not know if you have enough free space before the first partition, you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use {{ic|rm}} as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
==== Without suspend-to-disk support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/mkinitcpio.conf}} to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_Physical_Partitions_to_LUKS | mapping partitions]] above.<br><br />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
{{Note|If you use a Solid State Disk (SSD) for your swap and you consider using discard also on swap you have to add the option '--allow-discards' to the cryptsetup line above. See [https://wiki.archlinux.org/index.php/SSD SSD] for more information on discard. Additionally you have to add the mount option 'discard' to your fstab entry for the swap device.''}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|encrypt}}.<br />
<nowiki>HOOKS="... openswap resume encrypt filesystems ..."</nowiki><br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|openswap}} hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
{{Out of date|AIF does not exist anymore, GRUB Legacy is not available anymore}}<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections. These are marked below.}}<br />
<br />
=== Prepare hard drive ===<br />
Skip the Partitioning and Auto-Prepare steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/home}} partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/boot}} partition, or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual: the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
{{Note|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/etc/crypttab}} among others) take care of those.}}<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB2]]:''' As with [[GRUB Legacy]] you have to specify your {{ic|cryptdevice}} with the same name to map it to as your bootloader expects it. The default boot menu can receive its kernel command line from editing {{ic|/etc/default/grub}}. Extend {{ic|1=GRUB_CMDLINE_LINUX=""}} by the following parameter (assume your root device lies within {{ic|/dev/sda3}} and it should be mapped to {{ic|cryptroot}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda3:cryptroot"<br />
<br />
{{Note|The device name your harddrive should be mapped to depends on your setup and configuration. If you are directly decrypting your root partition, the parameter {{ic|1=root=/dev/mapper/cryptroot}} will indicate the expected name. In case of [[LVM]] this name can be any arbitrary name, as LVM will parse all available devices if specified as the next hook.}}<br />
<br />
<br />
'''[[GRUB Legacy]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|cryptkey}} option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} listed as your swap partition.<br />
<br />
{{Note|Eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) partition ==<br />
If you want to be able to reboot a fully LUKS-encrypted system remotely, or start it with a Wake-on-LAN service, you will need a way to enter a passphrase for the root partition/volume at startup. This can be achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the master key and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)}}<br />
<br />
=== Backup ===<br />
==== Manually ====<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]''<br />
<br />
=== Preparation and mapping ===<br />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors|}}, then run {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/dev/mapper/secret}}.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
=== Encrypt using a key-file ===<br />
Let us first generate a 2048 byte random keyfile:<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the LUKS device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device {{ic|/dev/mapper/container}} with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise encrypting your keyfile using your private GPG key and storing an off-site secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally, we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you do not know how to set up LVM, then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important thing in setting LVM on '''top''' of encryption is that you need to have the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|filesystems}} hook, but that's repeating) ''because they are processed in order''.<br />
<br />
To use encryption on top of LVM, you have to first set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"yes"}}.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08 <2012.07.15) ===<br />
<br />
{{Note|As on 2012.07.15, the AIF was removed so these steps are now obsolote. They still give the backbones to understanding what to do however with btrfs avaliable; It'll be easier to use btrfs instead of lvm with several ext partitions.}}<br />
<br />
Since Arch Linux images 2009.08, LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for [[LVM]] on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM: see the [[#Arch Linux Installer (>2009.08 <2012.07.15)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partition which can later be split up into multiple logic volumes by [[LVM]].<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/dev/sd*}} partition, the second to the name you want to attribute). That should be enough.<br />
<br />
The big advantage is you can have everything automated, while setting up {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<br />
==== The commands ====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-root}}<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
{{Accuracy|/dev/urandom needs dd count and skip paramters. |section=Specifying_skip_and_count_in_.2Fetc.2Fcrypttab_for_.2Ftmp}}<br />
<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After rebooting ====<br />
<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
For example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post has the generic instructions.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.<br />
<br />
Note that:<br />
* You can follow the above instructions with only two primary partitions one boot partition <br />
(required because of LVM), and one primary LVM partition. Within the LVM partition you can have <br />
as many partitions as you need, but most importantly it should contain at least root, swap, and <br />
home logical volume partitions. This has the added benefit of having only one keyfile for all <br />
your partitions, and having the ability to hibernate your computer (suspend to disk) where the <br />
swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} <br />
should look like<br />
{{ic|HOOKS&#61;" ... usb usbinput (etwo or ssldec) encrypt(if using openssl) lvm2 resume ... "}}<br />
and you should add to your {{ic|kernel}} line(if using grub, {{ic|/boot/grub/menu.lst}}) or <br />
{{ic|GRUB_CMD_LINE}}(if using grub2, {{ic|/etc/default/grub}}):<br />
{{ic|"resume&#61;/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>"}}<br />
* If you need to temporarily store the unecrypted keyfile somewhere, do not store them on an <br />
unencrytped disk. Even better make sure to store them to RAM such as {{ic|/dev/shm}}.<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
As {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostart (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart; Gnome3: gnome-session-properties). <br />
<br />
As with Arch Linux changes to {{ic|/boot}} are pretty frequent, for example by new kernels rolling-in, it may be helpful to use those scripts with every full system update. One way to do so: <br />
<br />
#!/bin/bash<br />
#<br />
# Note: Insert your <user> and execute it with sudo for pacman & chkboot to work automagically<br />
#<br />
echo "Pacman update [1] Quickcheck before updating" & <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> <br />
/usr/local/bin/chkboot.sh<br />
sync # sync disks with any results <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> <br />
echo "Pacman update [2] Syncing repos for pacman" <br />
pacman -Syu<br />
/usr/local/bin/chkboot.sh<br />
sync <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user><br />
echo "Pacman update [3] All done, let's roll on ..."<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.<br />
* [http://vimeo.com/40694871 Arch cryptsetup example video] - A HowTo video on setting up an encrypted Arch system from scratch. The video still shows an installation with AIF, which is at the time of writing deprecated / not developed further. The important partitioning and cryptsetup are shown outside AIF though.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=218416Dm-crypt2012-08-17T10:23:56Z<p>JaMeSiTeGeN: /* LVM with Arch Linux Installer (>2009.08) */</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Disk Encryption}}<br />
{{Article summary wiki|Removing System Encryption}}<br />
{{Article summary end}}<br />
<br />
This article focuses on how to set up full system encryption on Arch Linux, using dm-crypt with LUKS.<br />
<br />
'''dm-crypt''' is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management.<br />
<br />
'''LUKS''' is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
For more details on how dm-crypt+LUKS compares to other disk encryption solution, see [[Disk Encryption#Comparison table]].<br />
<br />
== Caveats ==<br />
<br />
===discard/TRIM support for solid state disks===<br />
<br />
{{Moveto|another place within this article|It describes a specific cryptdevice option which certain users may or may not want to set. This is something the user should deal with when she reaches the step of choosing cryptdevice options, not in the context of the article introduction.}}<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can be accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Hard Disk Drive ===<br />
<br />
{{Merge|Securely_wipe_disk|None of this specific to ''System Encryption with LUKS''. The info that is specific to disk encryption in general has already been duplicated at [[Disk_Encryption#Preparing_the_disk]]; the rest should be merged with [[Securely_wipe_disk]]. This section should then be deleted and replaced with a link to [[Disk_Encryption#Preparing_the_disk]].}}<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk drive ''multiple'' times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Hard Disk Drives'''<br />
<br />
::In hard drives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data, it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/dev/random}} uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten, it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*[[LVM]]<br />
::*[[RAID]]<br />
<br />
LUKS is compatible with systems that require LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
====Standard Partitions====<br />
<br />
These are the partitions that most people are familiar with. They come in three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
====How does LVM fit into the overall system?====<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKS). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKS on LVM). However, the deployment of LVM on LUKS is considered much more generalizable. One reason for this is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
=====Single Disk Systems=====<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However, if LVM is to be used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/boot}} and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the {{ic|/arch/setup}} program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in the dialogue for manual configuration of the hard drive.<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<br />
<br />
{{Note|If hibernation usage is planned, swap must be encrypted in this fashion; otherwise, if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
{{Warning|Irrespective of the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them.<br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<br />
<br />
{{Warning|In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see [https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_GPG_or_OpenSSL_Encrypted_Keyfiles Section 9] for details, but please still read this section.}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it is used as the passphrase to unlock an encrypted volume.<br />
Therefore if these files are lost or changed, decrypting the volume will no longer be possible.<br />
<br />
{{Tip|Define a passphrase in addition to the keyfile for backup access to encrypted volumes in the event the defined keyfile is lost or changed.}}<br />
<br />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<br />
<br />
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<br />
<br />
This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.<br />
<br />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<br />
<br />
LUKS supports the association of up to 8 keys with any single encrypted volume.<br />
Keys can be either keyfiles or passphrases.<br />
<br />
Once an encrytped partition has been created, the initial key is associated at slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/dev/<encrypted volume>}} is the volume that is to have the new key associated with it.<br />
<br />
If the bolded area is present, cryptsetup will look for the keyfile defined at that location to associate with the encrypted volume specified.<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} is somewhat arbitrary and depends on how many storage devices are attached and in what order, etc.<br />
So in order to assure that the {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a [[udev]] rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# ls -l /dev/disk/by-uuid/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1}}<br />
<br />
In this case, I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/dev/disk/by-uuid/4803-8A7B}}. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
{{Note|If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) itself.<br />
Create a udev rule instead as described in the following section.}}<br />
<br />
==== Using udev ====<br />
Optionally you may choose to set up your flash drive with a [[udev]] rule. There is some documentation in the Arch wiki about that already; if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%n}} will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute. If you have a custom rule of your own, you can put it in as well (e.g. using the vendor name).<br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of {{ic|/dev}}:<br />
ls /dev<br />
It should show your device with your desired name.<br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage device, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above.<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|mkinitcpio}} about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it is assumed that you use a FAT formatted USB drive. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. [[GRUB]] needs the first 16 sectors (actually, it depends on the type of the file system, so do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>16}}; otherwise you would overwrite parts of your GRUB installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
''Optional''<br />
If you do not know if you have enough free space before the first partition, you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use {{ic|rm}} as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
==== Without suspend-to-disk support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/mkinitcpio.conf}} to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_Physical_Partitions_to_LUKS | mapping partitions]] above.<br><br />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
{{Note|If you use a Solid State Disk (SSD) for your swap and you consider using discard also on swap you have to add the option '--allow-discards' to the cryptsetup line above. See [https://wiki.archlinux.org/index.php/SSD SSD] for more information on discard. Additionally you have to add the mount option 'discard' to your fstab entry for the swap device.''}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|encrypt}}.<br />
<nowiki>HOOKS="... openswap resume encrypt filesystems ..."</nowiki><br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|openswap}} hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
{{Out of date|AIF does not exist anymore, GRUB Legacy is not available anymore}}<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections. These are marked below.}}<br />
<br />
=== Prepare hard drive ===<br />
Skip the Partitioning and Auto-Prepare steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/home}} partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/boot}} partition, or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual: the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
{{Note|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/etc/crypttab}} among others) take care of those.}}<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB2]]:''' As with [[GRUB Legacy]] you have to specify your {{ic|cryptdevice}} with the same name to map it to as your bootloader expects it. The default boot menu can receive its kernel command line from editing {{ic|/etc/default/grub}}. Extend {{ic|1=GRUB_CMDLINE_LINUX=""}} by the following parameter (assume your root device lies within {{ic|/dev/sda3}} and it should be mapped to {{ic|cryptroot}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda3:cryptroot"<br />
<br />
{{Note|The device name your harddrive should be mapped to depends on your setup and configuration. If you are directly decrypting your root partition, the parameter {{ic|1=root=/dev/mapper/cryptroot}} will indicate the expected name. In case of [[LVM]] this name can be any arbitrary name, as LVM will parse all available devices if specified as the next hook.}}<br />
<br />
<br />
'''[[GRUB Legacy]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|cryptkey}} option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} listed as your swap partition.<br />
<br />
{{Note|Eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) partition ==<br />
If you want to be able to reboot a fully LUKS-encrypted system remotely, or start it with a Wake-on-LAN service, you will need a way to enter a passphrase for the root partition/volume at startup. This can be achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the master key and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)}}<br />
<br />
=== Backup ===<br />
==== Manually ====<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]''<br />
<br />
=== Preparation and mapping ===<br />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors|}}, then run {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/dev/mapper/secret}}.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
=== Encrypt using a key-file ===<br />
Let us first generate a 2048 byte random keyfile:<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the LUKS device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device {{ic|/dev/mapper/container}} with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise encrypting your keyfile using your private GPG key and storing an off-site secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally, we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you do not know how to set up LVM, then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important thing in setting LVM on '''top''' of encryption is that you need to have the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|filesystems}} hook, but that's repeating) ''because they are processed in order''.<br />
<br />
To use encryption on top of LVM, you have to first set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"yes"}}.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08 <2012.07.15) ===<br />
<br />
Since Arch Linux images 2009.08, LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for [[LVM]] on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM: see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partition which can later be split up into multiple logic volumes by [[LVM]].<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/dev/sd*}} partition, the second to the name you want to attribute). That should be enough.<br />
<br />
The big advantage is you can have everything automated, while setting up {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<br />
==== The commands ====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-root}}<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
{{Accuracy|/dev/urandom needs dd count and skip paramters. |section=Specifying_skip_and_count_in_.2Fetc.2Fcrypttab_for_.2Ftmp}}<br />
<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After rebooting ====<br />
<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
For example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post has the generic instructions.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.<br />
<br />
Note that:<br />
* You can follow the above instructions with only two primary partitions one boot partition <br />
(required because of LVM), and one primary LVM partition. Within the LVM partition you can have <br />
as many partitions as you need, but most importantly it should contain at least root, swap, and <br />
home logical volume partitions. This has the added benefit of having only one keyfile for all <br />
your partitions, and having the ability to hibernate your computer (suspend to disk) where the <br />
swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} <br />
should look like<br />
{{ic|HOOKS&#61;" ... usb usbinput (etwo or ssldec) encrypt(if using openssl) lvm2 resume ... "}}<br />
and you should add to your {{ic|kernel}} line(if using grub, {{ic|/boot/grub/menu.lst}}) or <br />
{{ic|GRUB_CMD_LINE}}(if using grub2, {{ic|/etc/default/grub}}):<br />
{{ic|"resume&#61;/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>"}}<br />
* If you need to temporarily store the unecrypted keyfile somewhere, do not store them on an <br />
unencrytped disk. Even better make sure to store them to RAM such as {{ic|/dev/shm}}.<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
As {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostart (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart; Gnome3: gnome-session-properties). <br />
<br />
As with Arch Linux changes to {{ic|/boot}} are pretty frequent, for example by new kernels rolling-in, it may be helpful to use those scripts with every full system update. One way to do so: <br />
<br />
#!/bin/bash<br />
#<br />
# Note: Insert your <user> and execute it with sudo for pacman & chkboot to work automagically<br />
#<br />
echo "Pacman update [1] Quickcheck before updating" & <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> <br />
/usr/local/bin/chkboot.sh<br />
sync # sync disks with any results <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> <br />
echo "Pacman update [2] Syncing repos for pacman" <br />
pacman -Syu<br />
/usr/local/bin/chkboot.sh<br />
sync <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user><br />
echo "Pacman update [3] All done, let's roll on ..."<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.<br />
* [http://vimeo.com/40694871 Arch cryptsetup example video] - A HowTo video on setting up an encrypted Arch system from scratch. The video still shows an installation with AIF, which is at the time of writing deprecated / not developed further. The important partitioning and cryptsetup are shown outside AIF though.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=218415Dm-crypt2012-08-17T10:22:47Z<p>JaMeSiTeGeN: /* Install Bootloader */</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Disk Encryption}}<br />
{{Article summary wiki|Removing System Encryption}}<br />
{{Article summary end}}<br />
<br />
This article focuses on how to set up full system encryption on Arch Linux, using dm-crypt with LUKS.<br />
<br />
'''dm-crypt''' is the standard device-mapper encryption functionality provided by the Linux kernel. It can be used directly by those who like to have full control over all aspects of partition and key management.<br />
<br />
'''LUKS''' is an additional convenience layer which stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
For more details on how dm-crypt+LUKS compares to other disk encryption solution, see [[Disk Encryption#Comparison table]].<br />
<br />
== Caveats ==<br />
<br />
===discard/TRIM support for solid state disks===<br />
<br />
{{Moveto|another place within this article|It describes a specific cryptdevice option which certain users may or may not want to set. This is something the user should deal with when she reaches the step of choosing cryptdevice options, not in the context of the article introduction.}}<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can be accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Hard Disk Drive ===<br />
<br />
{{Merge|Securely_wipe_disk|None of this specific to ''System Encryption with LUKS''. The info that is specific to disk encryption in general has already been duplicated at [[Disk_Encryption#Preparing_the_disk]]; the rest should be merged with [[Securely_wipe_disk]]. This section should then be deleted and replaced with a link to [[Disk_Encryption#Preparing_the_disk]].}}<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk drive ''multiple'' times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Hard Disk Drives'''<br />
<br />
::In hard drives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data, it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/dev/random}} uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten, it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*[[LVM]]<br />
::*[[RAID]]<br />
<br />
LUKS is compatible with systems that require LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
====Standard Partitions====<br />
<br />
These are the partitions that most people are familiar with. They come in three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
====How does LVM fit into the overall system?====<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKS). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKS on LVM). However, the deployment of LVM on LUKS is considered much more generalizable. One reason for this is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
=====Single Disk Systems=====<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However, if LVM is to be used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/boot}} and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the {{ic|/arch/setup}} program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in the dialogue for manual configuration of the hard drive.<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<br />
<br />
{{Note|If hibernation usage is planned, swap must be encrypted in this fashion; otherwise, if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
{{Warning|Irrespective of the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them.<br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<br />
<br />
{{Warning|In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see [https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_GPG_or_OpenSSL_Encrypted_Keyfiles Section 9] for details, but please still read this section.}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it is used as the passphrase to unlock an encrypted volume.<br />
Therefore if these files are lost or changed, decrypting the volume will no longer be possible.<br />
<br />
{{Tip|Define a passphrase in addition to the keyfile for backup access to encrypted volumes in the event the defined keyfile is lost or changed.}}<br />
<br />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<br />
<br />
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<br />
<br />
This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.<br />
<br />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<br />
<br />
LUKS supports the association of up to 8 keys with any single encrypted volume.<br />
Keys can be either keyfiles or passphrases.<br />
<br />
Once an encrytped partition has been created, the initial key is associated at slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/dev/<encrypted volume>}} is the volume that is to have the new key associated with it.<br />
<br />
If the bolded area is present, cryptsetup will look for the keyfile defined at that location to associate with the encrypted volume specified.<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} is somewhat arbitrary and depends on how many storage devices are attached and in what order, etc.<br />
So in order to assure that the {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a [[udev]] rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# ls -l /dev/disk/by-uuid/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1}}<br />
<br />
In this case, I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/dev/disk/by-uuid/4803-8A7B}}. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
{{Note|If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) itself.<br />
Create a udev rule instead as described in the following section.}}<br />
<br />
==== Using udev ====<br />
Optionally you may choose to set up your flash drive with a [[udev]] rule. There is some documentation in the Arch wiki about that already; if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%n}} will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute. If you have a custom rule of your own, you can put it in as well (e.g. using the vendor name).<br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of {{ic|/dev}}:<br />
ls /dev<br />
It should show your device with your desired name.<br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage device, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above.<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|mkinitcpio}} about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it is assumed that you use a FAT formatted USB drive. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. [[GRUB]] needs the first 16 sectors (actually, it depends on the type of the file system, so do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>16}}; otherwise you would overwrite parts of your GRUB installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
''Optional''<br />
If you do not know if you have enough free space before the first partition, you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use {{ic|rm}} as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
==== Without suspend-to-disk support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/mkinitcpio.conf}} to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_Physical_Partitions_to_LUKS | mapping partitions]] above.<br><br />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
{{Note|If you use a Solid State Disk (SSD) for your swap and you consider using discard also on swap you have to add the option '--allow-discards' to the cryptsetup line above. See [https://wiki.archlinux.org/index.php/SSD SSD] for more information on discard. Additionally you have to add the mount option 'discard' to your fstab entry for the swap device.''}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|encrypt}}.<br />
<nowiki>HOOKS="... openswap resume encrypt filesystems ..."</nowiki><br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|openswap}} hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
{{Out of date|AIF does not exist anymore, GRUB Legacy is not available anymore}}<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections. These are marked below.}}<br />
<br />
=== Prepare hard drive ===<br />
Skip the Partitioning and Auto-Prepare steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/home}} partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/boot}} partition, or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual: the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
{{Note|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/etc/crypttab}} among others) take care of those.}}<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB2]]:''' As with [[GRUB Legacy]] you have to specify your {{ic|cryptdevice}} with the same name to map it to as your bootloader expects it. The default boot menu can receive its kernel command line from editing {{ic|/etc/default/grub}}. Extend {{ic|1=GRUB_CMDLINE_LINUX=""}} by the following parameter (assume your root device lies within {{ic|/dev/sda3}} and it should be mapped to {{ic|cryptroot}}:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda3:cryptroot"<br />
<br />
{{Note|The device name your harddrive should be mapped to depends on your setup and configuration. If you are directly decrypting your root partition, the parameter {{ic|1=root=/dev/mapper/cryptroot}} will indicate the expected name. In case of [[LVM]] this name can be any arbitrary name, as LVM will parse all available devices if specified as the next hook.}}<br />
<br />
<br />
'''[[GRUB Legacy]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|cryptkey}} option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} listed as your swap partition.<br />
<br />
{{Note|Eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) partition ==<br />
If you want to be able to reboot a fully LUKS-encrypted system remotely, or start it with a Wake-on-LAN service, you will need a way to enter a passphrase for the root partition/volume at startup. This can be achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the master key and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)}}<br />
<br />
=== Backup ===<br />
==== Manually ====<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]''<br />
<br />
=== Preparation and mapping ===<br />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors|}}, then run {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/dev/mapper/secret}}.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
=== Encrypt using a key-file ===<br />
Let us first generate a 2048 byte random keyfile:<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the LUKS device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device {{ic|/dev/mapper/container}} with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise encrypting your keyfile using your private GPG key and storing an off-site secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally, we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you do not know how to set up LVM, then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important thing in setting LVM on '''top''' of encryption is that you need to have the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|filesystems}} hook, but that's repeating) ''because they are processed in order''.<br />
<br />
To use encryption on top of LVM, you have to first set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"yes"}}.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08, LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for [[LVM]] on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM: see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partition which can later be split up into multiple logic volumes by [[LVM]].<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/dev/sd*}} partition, the second to the name you want to attribute). That should be enough.<br />
<br />
The big advantage is you can have everything automated, while setting up {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<br />
==== The commands ====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-root}}<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
{{Accuracy|/dev/urandom needs dd count and skip paramters. |section=Specifying_skip_and_count_in_.2Fetc.2Fcrypttab_for_.2Ftmp}}<br />
<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After rebooting ====<br />
<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
For example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post has the generic instructions.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.<br />
<br />
Note that:<br />
* You can follow the above instructions with only two primary partitions one boot partition <br />
(required because of LVM), and one primary LVM partition. Within the LVM partition you can have <br />
as many partitions as you need, but most importantly it should contain at least root, swap, and <br />
home logical volume partitions. This has the added benefit of having only one keyfile for all <br />
your partitions, and having the ability to hibernate your computer (suspend to disk) where the <br />
swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} <br />
should look like<br />
{{ic|HOOKS&#61;" ... usb usbinput (etwo or ssldec) encrypt(if using openssl) lvm2 resume ... "}}<br />
and you should add to your {{ic|kernel}} line(if using grub, {{ic|/boot/grub/menu.lst}}) or <br />
{{ic|GRUB_CMD_LINE}}(if using grub2, {{ic|/etc/default/grub}}):<br />
{{ic|"resume&#61;/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>"}}<br />
* If you need to temporarily store the unecrypted keyfile somewhere, do not store them on an <br />
unencrytped disk. Even better make sure to store them to RAM such as {{ic|/dev/shm}}.<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
As {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostart (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart; Gnome3: gnome-session-properties). <br />
<br />
As with Arch Linux changes to {{ic|/boot}} are pretty frequent, for example by new kernels rolling-in, it may be helpful to use those scripts with every full system update. One way to do so: <br />
<br />
#!/bin/bash<br />
#<br />
# Note: Insert your <user> and execute it with sudo for pacman & chkboot to work automagically<br />
#<br />
echo "Pacman update [1] Quickcheck before updating" & <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> <br />
/usr/local/bin/chkboot.sh<br />
sync # sync disks with any results <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user> <br />
echo "Pacman update [2] Syncing repos for pacman" <br />
pacman -Syu<br />
/usr/local/bin/chkboot.sh<br />
sync <br />
sudo -u <user> /usr/local/bin/chkboot_user.sh # insert your logged on <user><br />
echo "Pacman update [3] All done, let's roll on ..."<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.<br />
* [http://vimeo.com/40694871 Arch cryptsetup example video] - A HowTo video on setting up an encrypted Arch system from scratch. The video still shows an installation with AIF, which is at the time of writing deprecated / not developed further. The important partitioning and cryptsetup are shown outside AIF though.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Dm-crypt&diff=210308Dm-crypt2012-06-19T08:19:50Z<p>JaMeSiTeGeN: /* Configure System */</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[ru:System Encryption with LUKS]]<br />
[[zh-CN:System Encryption with LUKS]]<br />
{{Article summary start}}<br />
{{Article summary text|This tutorial will show you how to set up system encryption with LUKS for dm-crypt.}}<br />
{{Article summary end}}<br />
<br />
== Introduction ==<br />
=== Why Use Encryption? ===<br />
<br />
In the simplest terms encryption is a method for establishing privacy. <br />
<br />
There are presently two approaches to partition level encryption '''data encryption''' and '''system encryption'''.<br />
<br />
==== Data encryption ====<br />
'''Data encryption''', defined as encrypting a users data, provides for many benefits including: <br />
<br />
*Preventing unauthorized physical access to private data.<br />
*Some confidence in data disposal when discarding obsolete systems.<br />
<br />
However data encryption alone has some significant drawbacks. In modern computing systems, there are many background processes that may store information about encrypted data or parts of the encrypted data itself in non-encrypted areas of the hard drive, thus reducing the effectiveness of any data encryption system in place.<br />
<br />
==== System encryption ====<br />
'''System encryption''', defined as the encryption of the operating system and user data, helps to address some of the inadequacies of data encryption. The benefits of system encryption over data encryption alone include:<br />
<br />
*Preventing unauthorized physical access to operating system files<br />
*Preventing unauthorized physical access to private data that may cached by the system.<br />
<br />
In the context of overall system security, system encryption should be viewed as an adjunct to the existing security mechanisms of the operating system that focuses on physical attempts to breach system security which includes:<br />
<br />
*Attempts to bypass the operating system by inserting a boot CD/USB<br />
*Copying, modifying, or removing the hard disk drives when the computer is off<br />
<br />
Despite the use of system encryption, there are still points of physical insecurity. These issues revolve around the {{ic|/boot}} partition which must remain unencrypted in order for the machine to properly boot. However, system encryption is presently the best way to minimize the loss of data privacy by physical attempts at invasion.<br />
<br />
{{Warning|Any encryption method employed is only as good as its associated key management. Partition level encryption does not protect you from all forms of security compromise. There are ways to break into computers while they are powered on that are unaffected by disk level encryption. Read the [[System Encryption with LUKS for dm-crypt#Caveats | caveats]] section below!}}<br />
<br />
=== What Methods are Available for System Encryption? ===<br />
<br />
There are multiple current methods that can be employed for system encryption, including:<br />
<br />
;loop-AES ([http://loop-aes.sourceforge.net/ loop-AES]):loop-AES is a descendant of cryptoloop and is a secure and fast solution to system encryption.<br />
:However loop-AES is considered less user-friendly than other options as it requires non-standard kernel support.<br />
<br />
;standard device-mapper encryption ([http://www.saout.de/misc/dm-crypt/ dm-crypt]):This is the standard device mapper which can be used for those who like to have control over all aspects partition management.<br />
<br />
;LUKS for dm-crypt ([http://code.google.com/p/cryptsetup/ LUKS]):LUKS stores all of the needed setup information for dm-crypt on the disk itself and abstracts partition and key management in an attempt to improve ease of use.<br />
<br />
:Briefly some key features that LUKS provides include:<br />
<br />
::*Support for either passphrase or keyfiles as encryption keys<br />
::*Per partition key creation and revocation<br />
::*Multiple passphrases or keyfiles for a particular partition<br />
<br />
=== Caveats ===<br />
<br />
For any type of encryption the security of your privacy is dependent on two things:<br />
<br />
::*The complexity/availability of your key (see [[Wikipedia:Kerckhoffs's principle]])<br />
::*The usage of a proven encryption algorithm<br />
<br />
====Key Complexity and Availability====<br />
<br />
The user-provided key used for encryption, whether a passphrase or a keyfile, must be complex enough that is it not easy to guess. Having a strong encryption algorithm does nothing to provide privacy if the key used for encryption is too simple. The tenets of strong keys are based on length and randomness. There are many sources available with instructions on how to create strong encryption keys. <br />
<br />
Part of key complexity is key availability. For example a complex key written on a sticky note pasted to the computer's keyboard would not provide much in the way privacy. Therefore in addition to creating a strong key, maintaining it in a secure location is necessary as well.<br />
<br />
====Encryption Algorithm====<br />
<br />
There are many peer-reviewed encryption algorithms in existence. The encryption algorithms and block ciphers used in any of the mentioned methods for applying encryption in this wiki page are considered strong algorithms that have been subjected to cryptographic review by the cryptography community.<br />
<br />
====discard/TRIM support for solid state disks====<br />
<br />
Solid state disk users should be aware that by default, Linux's full-disk encryption mechanisms will ''not'' forward TRIM commands from the filesystem to the underlying disk. The device-mapper maintainers have made it clear that TRIM support will never be enabled by default on dm-crypt devices because of the potential security implications; if TRIM support were enabled, an attacker may be able to tell which blocks have been used, how many blocks have been used, and other information that is exposed directly to the device when a TRIM is issued.<br />
<br />
It may be possible to determine the filesystem utilized by your encrypted device through the data that is leaked by TRIM. Furthermore, any information that may be derived by a profile of block usage may be exposed by enabling TRIM support on an encrypted device.<br />
<br />
As of {{Pkg|linux}} version 3.1, support for dm-crypt TRIM pass-through can be toggled upon device creation or mount with dmsetup. Support for this option also exists in {{Pkg|cryptsetup}} version 1.4.0 and up. To add support during boot, you will need to add "{{ic|:allow-discards}}" to the {{ic|cryptdevice}} option. The option should look like this:<br />
cryptdevice=/dev/mapper/root:root:allow-discards<br />
<br />
For more information, including specific commands and details on dm-crypt TRIM pass-through, see these mailing list threads:<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.devel/14134<br />
* http://article.gmane.org/gmane.linux.kernel.device-mapper.dm-crypt/5166<br />
<br />
==== System Encryption ====<br />
<br />
System encryption provides security against unauthorized physical access to a machine that is powered off. It does not effect any security advantages for a system that is powered on with its partitions mounted in an unencrypted state. For a powered on user-accessible system the normal precautions to prevent viruses, trojans, worms, or other attempts to access private data should be exercised. Furthermore, system encryption has been shown to be penetrable in cases where a system has been recently shut down. This is due to the fact that cessation of power does not immediately degrade data that was stored in RAM prior to shutdown. Therefore someone with physical access to your computer within a few moments of shutdown could cool the RAM modules and use them to extract your encryption key - thus obtaining access to your data.<br />
<br />
{{Note|System Encryption assumes encryption of all mounted partitions: this includes all partitions except for {{ic|/boot}} - meaning that the root file system, swap partition, and all other partitions must be encrypted. If the swap, {{ic|/tmp}}, or root filesystems are unencrypted, only Data Encryption level of security has been accomplished.}}<br />
<br />
==== Data Encryption ====<br />
<br />
There are two common forms of data encryption:<br />
<br />
::*Encryption of data partitions on the same physical disk as the system.<br />
::*Encryption of data partitions on separate physical disks from the system.<br />
<br />
=====Encryption of data partitions on the same physical disk as the system=====<br />
<br />
The most common form of data encryption is encrypting the {{ic|/home}} partition.<br />
<br />
In cases where the encrypted data are located on the same physical disk as the system accessing the drive the privacy of data has already been decreased by orders of magnitude when compared to system encryption. The reason for this is that the host operating systems employ background methods to assist the user in the access and management of their data. The problem lies in where these processes store this data which is most commonly in the unencrypted system partition. <br />
<br />
For example, {{Pkg|mlocate}} will scan all currently mounted file systems regularly and write the list of filenames to {{ic|/var/lib/mlocate/mlocate.db}}, which is located in the non-encrypted root or {{ic|/var}} partition. Thus an attacker will have a list of all filenames for that computer, even the ones on the encrypted {{ic|/home}} partition, readily available to assist them in accessing the encrypted data present on the disk.<br />
<br />
Some have compared this to reducing the level of security from partition-based encryption to filesystem level encryption like [[System_Encryption_with_eCryptfs|System Encryption with eCryptfs]].<br />
<br />
=====Encryption of data partitions on separate physical disks from the system=====<br />
<br />
Popular forms of data encryption on physically separate partitions include the encryption of removable media such as:<br />
<br />
::*USB Flash Drives<br />
::*External Hard Disk Drives or Separate Internal Hard Disk Drives<br />
::*CD/DVD/Blu-Ray Optical Media<br />
::*Magnetic Storage Media<br />
<br />
The most important part of this form of data encryption is to remember that the encryption protects the privacy of the data that is located within the encrypted media only when it is not mounted. Data encryption does not protect the privacy of data once it is made accessible to a system. For example, attaching an encrypted USB flash drive, and subsequently decrypting a file for use temporarily on a non-secured system could result in remnants of that file existing on the host system in an unencrypted form.<br />
<br />
== Initial Setup ==<br />
=== Overview and Preparation ===<br />
<br />
The Arch installer comes with all the tools required for system encryption. Setup of encrypted partitions can be accomplished either manually prior to executing the arch installer or using the menu interface from the arch installer itself. The installation of an encrypted system is largely the same as installing an unencrypted system, so you can follow the [[Official Arch Linux Install Guide]] or the [[Beginners' Guide]] after the encrypted partitions are set up.<br />
<br />
Routine creation of an encrypted system follows these general steps:<br />
<br />
::* Secure erasure of the hard disk drive(s)<br />
::* Partitioning and setup of encryption ([[LVM]] optional)<br />
::* Routine package selection and installation<br />
::* System Configuration<br />
<br />
{{Warning | Encrypting a partition will erase everything currently on that partition. Please make appropriate data backups prior to starting.}}<br />
<br />
=== Secure Erasure of the Hard Disk Drive ===<br />
<br />
Secure erasure of the hard disk drive involves overwriting the entire drive with random data.<br />
<br />
{{Note|Overwriting a hard disk drive ''multiple'' times with random data serves no purpose. Data existing prior to overwriting cannot be recovered after it has been overwritten. [http://www.springerlink.com/content/408263ql11460147/ Overwriting Hard Drive Data: The Great Wiping Controversy]}}<br />
<br />
====Why perform secure erasure of a drive?====<br />
<br />
There are two types of hard disk drives, new and used, both kinds should be securely overwritten. The reasoning is slightly different for each but the goal is to help ensure the privacy of data located within the encrypted partitions.<br />
<br />
::'''New Hard Disk Drives'''<br />
<br />
::In hard drives that have been directly purchased from a manufacturer there is no preexisting private data to protect. The problem is that there is no consistency in what is presently on the drive. Ideally the drive should be completely filled with random bits. However some drives have been overwritten completely with zeros. Therefore once the drive is used to write encrypted data, it is relatively simple to identify where the encrypted data ends and the zeroed data begins compared to a drive that was written with random data before usage as an encrypted drive. Since an encrypted partition is supposed to be indistinguishable from random data, the lack of random data on a zeroed drive makes an encrypted drive an easier target for cryptanalysis.<br />
<br />
::'''Used Hard Disk Drives'''<br />
<br />
::Repartitioning or reformatting a used hard drive removes the file system structure for identifying where the original data was located while leaving the actual data intact on the drive itself. It is relatively straightforward using data tools like [http://foremost.sourceforge.net/ Foremost] to access the remnant data. Therefore hard drives should be securely overwritten with random data prior to encryption to prevent unintentional data recovery.<br />
<br />
====Overwriting a hard disk drive with random data====<br />
<br />
There are two sources of random data commonly used for securely overwriting hard disk partitions.<br />
<br />
::*{{ic|/dev/urandom}}<br />
::*badblocks<br />
<br />
=====Using urandom=====<br />
<br />
#dd if=/dev/urandom of=/dev/<drive> bs=1M<br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note| Using {{ic|/dev/urandom}} will take a long time to completely overwrite a drive with "random" data. In the strictest sense, {{ic|/dev/urandom}} is less random than {{ic|/dev/random}}; however, {{ic|/dev/random}} uses the kernel entropy pool and will halt overwriting until more input entropy once this pool has been exhausted. This makes the use of {{ic|/dev/random}} for overwriting hard disks impractical.}}<br />
<br />
{{Note| Users may also find that {{ic|/dev/urandom}} takes an excessively long time on large drives of several hundred gigabytes or more (more than twenty-four hours). [[Frandom]] offers a faster alternative.}}<br />
<br />
{{Note|You can retrieve progress of the dd command with this command: {{ic|kill -USR1 $(pidof dd)}}}}<br />
<br />
=====Using badblocks=====<br />
<br />
#badblocks -c 10240 -wsvt random /dev/<drive><br />
<br />
Where {{ic|/dev/<drive>}} is the drive to be encrypted.<br />
<br />
{{Note|The {{ic|badblocks}} command overwrites the drive at a much faster rate by generating data that is not truly random.}}<br />
<br />
See also [[badblocks]].<br />
<br />
{{Tip|In deciding which method to use for secure erasure of a hard disk drive, remember that this will not need to be performed more than once for as long as the drive is used as an encrypted drive.}}<br />
<br />
=====After installation=====<br />
Essentially the same effect can be achieved if a file is created on each of the partitions that fills the partition completely '''after''' the system is installed and booted with encrypted partitions mounted. <br />
#dd if=/dev/zero of=/path/to/the/output/file<br />
#rm /path/to/the/input/file<br />
Just make sure that you do that for every partition on the filesystem. This works as encrypted data is indistinguishabe from random, so anone trying to access potential leftover files will just see random data.<br />
<br />
=== Partitioning ===<br />
<br />
After the drive has been securely overwritten, it is time to create partitions and begin setting up an encrypted system.<br />
<br />
There are multiple ways to create disk partitions:<br />
<br />
::*Standard partitions<br />
::*[[LVM]]<br />
::*[[RAID]]<br />
<br />
LUKS is compatible with systems that require LVM and/or RAID as well as with with standard primary, extended, and logical partitions.<br />
<br />
====Standard Partitions====<br />
<br />
These are the partitions that most people are familiar with. They come in three flavors: primary partitions, extended partitions, and logical partitions.<br />
<br />
;Primary Partitions: These are the normal partitions recognized by the system BIOS. There can be up to four of these stored in the MBR.<br />
<br />
;Extended Partitions: These are primary partitions that also define another partition within themselves. Extended partitions were created to work around the original limit of four primary partitions.<br />
<br />
;Logical Partitions: These are the partitions that are defined within extended partitions.<br />
<br />
====LVM: Logical Volume Manager====<br />
<br />
The LVM allows for creation of volume groups for systems that require complex combinations of multiple hard disk drives and partitions that are not possible with standard partitions. LVM is covered in detail in the [[LVM|Arch Linux LVM Wiki Article]] which is recommended reading prior to continuing with the instructions on setting up LUKS with LVM located below.<br />
<br />
====How does LVM fit into the overall system?====<br />
<br />
There is a growing preference towards logical volume management of LUKS encrypted physical media (LVM on LUKS). It is possible there may exist usage scenarios where encrypting logical volumes rather than physical disks is required (LUKS on LVM). However, the deployment of LVM on LUKS is considered much more generalizable. One reason for this is that using LUKS as the lowest level of infrastructure most closely approximates the deployment of physical disks with built-in hardware encryption. In this case, logical volume management would be layered on top of the hardware encryption &ndash; usage of LUKS would be superfluous.<br />
<br />
==== Creating Disk Partitions ====<br />
<br />
Disk partitions are created using:<br />
<br />
# cfdisk<br />
<br />
This will display a graphical interface for creating disk partitions.<br />
<br />
There are two required partitions for any encrypted system:<br />
<br />
::A root file system<br />
<br />
:::*{{ic|'''/'''}}<br />
:::*Will be encrypted and store all system and user files ({{ic|/usr}}, {{ic|/bin}}, {{ic|/var}}, {{ic|/home}}, etc.)<br />
<br />
::An initial boot partition<br />
<br />
:::*{{ic|'''/boot'''}}<br />
:::*Will ''not'' be encrypted; the bootloader needs to access the {{ic|/boot}} directory where it will load the initramfs/encryption modules needed to load the rest of the system which ''is'' encrypted (see [[Mkinitcpio]] for details). For this reason, {{ic|/boot}} needs to reside on its own, unencrypted partition.<br />
<br />
{{Note| A swap partition is optional; it can be encrypted with dm-crypt/LUKS. See [[#Encrypting_the_Swap_partition|Encrypting the Swap Partition]] for details.}}<br />
<br />
=====Single Disk Systems=====<br />
<br />
Depending on the system demands, there may be additional partitions desired. These partitions can be individually created at this level by defining separate primary or extended/logical partitions. However, if LVM is to be used, the space unoccupied by {{ic|/boot}} and swap should be defined as single large partition which will be divided up later at the LVM level.<br />
<br />
=====Multiple Disk Systems=====<br />
<br />
In systems that will have multiple hard disk drives, the same options exist as a single disk system. After the creation of the {{ic|/boot}} and swap partitions, the remaining free space on physical disks can divided up into their respective partitions at this level, or large partitions can define all free space per physical disk with intent to partition them within the LVM.<br />
<br />
== Configuring LUKS ==<br />
<br />
Creating LUKS partitions with a passphrase is supported by the {{ic|/arch/setup}} program. <br />
<br />
This section of the Wiki will cover how to manually utilize LUKS from the command line to encrypt a system. <br />
<br />
The steps for accomplishing this through the graphical installer are very similar and can be located in the dialogue for manual configuration of the hard drive.<br />
<br />
=== Mapping Physical Partitions to LUKS ===<br />
<br />
Once the desired partitions are created it is time to format them as LUKS partitions and then mount them through the device mapper.<br />
<br />
When creating LUKS partitions they must be associated with a key. <br />
<br />
A key is either a: <br />
<br />
::*Passphrase<br />
::*Keyfile <br />
<br />
It is possible to define up to 8 different keys per LUKS partition.<br />
<br />
==== Using LUKS to Format Partitions with a Passphrase ====<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
Cryptsetup is used to interface with LUKS for formatting, mounting and unmounting encrypted partitions.<br />
<br />
A full list of options {{ic|cryptsetup}} accepts can be found in the [[http://www.linuxcommand.org/man_pages/cryptsetup8.html Cryptsetup Manpage]]<br />
<br />
The options used here are:<br />
<br />
::*{{ic|-c}} defines the cipher type<br />
::*{{ic|-y}} prompts for password confirmation on password creation<br />
::*{{ic|-s}} defines the key size<br />
<br />
::luksFormat addresses the LUKS extensions built into cryptsetup.<br />
<br />
In the following examples for creating LUKS partitions, we will use the AES cipher in XTS mode; at present this is most generally used preferred cipher.<br />
Other ciphers can be used with cryptsetup, and details about them can be found here: [[Wikipedia:Block_cipher]]<br />
<br />
'''Formatting LUKS Partitions'''<br />
<br />
First of all make sure the device mapper kernel module is loaded by executing the following: {{ic|# modprobe dm_mod}}<br />
<br />
In order to format a desired partition as an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup -c <cipher> -y -s <key size> luksFormat /dev/<partition name>|<br />
Enter passphrase: <password><br />
Verify passphrase: <password>}}<br />
<br />
This should be repeated for all partitions except for {{ic|/boot}} and possibly swap.<br />
<br />
The example below will create an encrypted root partition using the AES cipher in XTS mode (generally referred to as ''XTS-AES'').<br />
{{bc|cryptsetup -c aes-xts-plain -y -s 512 luksFormat /dev/sda2}}<br />
<br />
{{Note|If hibernation usage is planned, swap must be encrypted in this fashion; otherwise, if hibernation is not a planned feature for the system, encrypting the swap file will be performed in a alternative manner.}}<br />
<br />
{{Warning|Irrespective of the chosen partitioning method, the {{ic|/boot}} partition must remain separate and unencrypted in order to load the kernel and boot the system.}}<br />
<br />
'''Unlocking/Mapping LUKS Partitions with the Device Mapper'''<br />
<br />
Once the LUKS partitions have been created it is time to unlock them.<br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that {{ic|/dev/<partition name>}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/<name>}} so as not to overwrite the encrypted data. <br />
<br />
In order to open an encrypted LUKS partition execute:<br />
{{hc|# cryptsetup luksOpen /dev/<partition name> <device-mapper name>|<br />
Enter any LUKS passphrase: <password><br />
key slot 0 unlocked.<br />
Command successful.}}<br />
<br />
Usually the device mapped name is descriptive of the function of the partition that is mapped, example:<br />
<br />
::*cryptsetup luksOpen /dev/sda2 '''swap'''<br />
::::Once opened, the swap partition device address would be '''{{ic|/dev/mapper/swap}}''' instead of {{ic|/dev/sda2}}.<br />
<br />
::*cryptsetup luksOpen /dev/sda3 '''root'''<br />
::::Once opened, the root partition device address would be '''{{ic|/dev/mapper/root}}''' instead of {{ic|/dev/sda3}}.<br />
<br />
{{Note|Since {{ic|/boot}} is not encrypted, it does not need a device mapped name and will be addressed as {{ic|/dev/sda1}}.}}<br />
<br />
{{Warning|In order to write encrypted data into the partition it must be accessed through the device mapped name.}}<br />
<br />
==== Using LUKS to Format Partitions with a Keyfile ====<br />
{{Note|This section describes using a plaintext keyfile, if you want to encrypt your keyfile giving you two factor authentication see [https://wiki.archlinux.org/index.php/System_Encryption_with_LUKS#Using_GPG_or_OpenSSL_Encrypted_Keyfiles Section 9] for details, but please still read this section.}}<br />
<br />
'''What is a Keyfile?'''<br />
<br />
A keyfile is any file in which the data contained within it is used as the passphrase to unlock an encrypted volume.<br />
Therefore if these files are lost or changed, decrypting the volume will no longer be possible.<br />
<br />
{{Tip|Define a passphrase in addition to the keyfile for backup access to encrypted volumes in the event the defined keyfile is lost or changed.}}<br />
<br />
'''Why use a Keyfile?'''<br />
<br />
There are many kinds of keyfile. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
:'''keyfile.passphrase:'''<br />
::this is my passphrase I would have typed during boot but I have placed it in a file instead<br />
<br />
This is a keyfile containing a simple passphrase. The benefit of this type of keyfile is that if the file is lost the data it contained is known and hopefully easily remembered by the owner of the encrypted volume. However the disadvantage is that this does not add any security over entering a passphrase during the initial system start.<br />
<br />
:'''keyfile.randomtext:'''<br />
::fjqweifj830149-57 819y4my1- 38t1934yt8-91m 34co3;t8y;9p3y-<br />
<br />
This is a keyfile containing a block of random characters. The benefit of this type of keyfile is that it is much more resistant to dictionary attacks than a simple passphrase. An additional strength of keyfiles can be utilized in this situation which is the length of data used. Since this is not a string meant to be memorized by a person for entry, it is trivial to create files containing thousands of random characters as the key. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase.<br />
<br />
:'''keyfile.binary:'''<br />
::where any binary file, images, text, video could be chosen as the keyfile<br />
<br />
This is a binary file that has been defined as a keyfile. When identifying files as candidates for a keyfile, it is recommended to choose files that are relatively static such as photos, music, video clips. The benefit of these files is that they serve a dual function which can make them harder to identify as keyfiles. Instead of having a text file with a large amount of random text, the keyfile would look like a regular image file or music clip to the casual observer. The disadvantage is that if this file is lost or changed, it will most likely not be possible to access the encrypted volume without a backup passphrase. Additionally, there is a theoretical loss of randomness when compared to a randomly generated text file. This is due to the fact that images, videos and music have some intrinsic relationship between neighboring bits of data that does not exist for a text file. However this is controversial and has never been exploited publicly.<br />
<br />
'''Creating a Keyfile with Random Characters'''<br />
<br />
Here {{ic|dd}} is used to generate a keyfile of 2048 bits of random characters.<br />
<br />
# dd if=/dev/urandom of=mykeyfile bs=512 count=4<br />
<br />
The usage of {{ic|dd}} is similar to initially wiping the volume with random data prior to encryption. <br />
<br />
{{Warning|Do not use [[badblocks]] here. It only generate a random pattern which just repeats its randomness over and over again.}}<br />
<br />
'''Creating a new LUKS encrypted partition with a Keyfile'''<br />
<br />
When creating a new LUKS encrypted partition, a keyfile may be associated with the partition on its creation using:<br />
<br />
# cryptsetup -c <desired cipher> -s <key size> luksFormat /dev/<volume to encrypt> '''/path/to/mykeyfile'''<br />
<br />
This is accomplished by appending the bold area to the standard cryptsetup command which defines where the keyfile is located.<br />
<br />
==== Adding Additional Passphrases or Keyfiles to a LUKS Encrypted Partition ====<br />
<br />
LUKS supports the association of up to 8 keys with any single encrypted volume.<br />
Keys can be either keyfiles or passphrases.<br />
<br />
Once an encrytped partition has been created, the initial key is associated at slot 0.<br />
Additional keys will occupy slots 1&ndash;7.<br />
<br />
The addition of new keys to an encrypted partition is accomplished using cryptsetup with the {{ic|luksAddKey}} extension.<br />
<br />
# cryptsetup luksAddKey /dev/<encrypted volume> '''/path/to/mykeyfile'''<br />
<br />
Where {{ic|/dev/<encrypted volume>}} is the volume that is to have the new key associated with it.<br />
<br />
If the bolded area is present, cryptsetup will look for the keyfile defined at that location to associate with the encrypted volume specified.<br />
<br />
=== Storing the Key File ===<br />
<br />
==== External Storage on a USB Drive ====<br />
<br />
===== Preparation for permanent device names =====<br />
For reading the file from an USB stick it is important to access it through a permanent device name.<br />
The numbering of the normal device names e.g. {{ic|/dev/sdb1}} is somewhat arbitrary and depends on how many storage devices are attached and in what order, etc.<br />
So in order to assure that the {{ic|encrypt}} HOOK in the initcpio finds your keyfile, you must use a permanent device name. <br />
<br />
===== Quick method =====<br />
A quick method (as opposed to setting up a [[udev]] rule) for doing so involves referencing your removable device by its label (or UUID). To find your label or UUID, plug in your USB drive and run the following:<br />
<br />
{{hc|# ls -l /dev/disk/by-label/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 Keys -> ../../sdb1}}<br />
<br />
or<br />
<br />
{{hc|# ls -l /dev/disk/by-uuid/|<br />
lrwxrwxrwx 1 root root 10 12. Feb 10:11 4803-8A7B -> ../../sdb1}}<br />
<br />
In this case, I labeled the vfat partition on my USB drive as "Keys" so my device is always symlinked in {{ic|/dev/disk/by-label/Keys}}, or if I had wanted to use the UUID I would find {{ic|/dev/disk/by-uuid/4803-8A7B}}. This allows me to have a consistent naming of my USB devices regardless of the order they are plugged into the system. These device names can be used in the "cryptkey" kernel option or any where else. Filesystem UUIDs are stored in the filesystem itself, meaning that the UUID will be the same if you plug it into any other computer, and that a dd backup of it will always have the same UUID since dd does a bitwise copy.<br />
<br />
{{Note|If you plan to store the keyfile between [[#Storing_the_key_between_MBR_and_1st_partition|MBR and the 1st partition]] you '''cannot use this method''', since it only allows access to the partitions ({{ic|sdb1}}, {{ic|sdb2}}, ...) but not to the USB device ({{ic|sdb}}) itself.<br />
Create a udev rule instead as described in the following section.}}<br />
<br />
==== Using udev ====<br />
Optionally you may choose to set up your flash drive with a [[udev]] rule. There is some documentation in the Arch wiki about that already; if you want more in-depth, structural info, read [http://reactivated.net/writing_udev_rules.html this guide]. Here is quickly how it goes.<br />
<br />
Get the serial number from your USB flash drive:<br />
lsusb -v | grep -A 5 Vendor<br />
<br />
Create a udev rule for it by adding the following to a file in {{ic|/etc/udev/rules.d/}}, such as {{ic|8-usbstick.rules}}:<br />
KERNEL=="sd*", ATTRS{serial}=="$SERIAL", SYMLINK+="$SYMLINK%n"<br />
<br />
Replace {{ic|$SYMLINK}} and {{ic|$SERIAL}} with their respective values. {{ic|%n}} will expand to the partition (just like sda is subdivided into sda1, sda2, ...). You do not need to go with the 'serial' attribute. If you have a custom rule of your own, you can put it in as well (e.g. using the vendor name).<br />
<br />
Rescan your sysfs:<br />
udevadm trigger<br />
Now check the contents of {{ic|/dev}}:<br />
ls /dev<br />
It should show your device with your desired name.<br />
<br />
==== Generating the keyfile ====<br />
Optionally you can mount a tmpfs for storing the temporary keyfile.<br />
# mkdir ./mytmpfs<br />
# mount tmpfs ./mytmpfs -t tmpfs -o size=32m<br />
# cd ./mytmpfs<br />
The advantage is that it resides in RAM and not on a physical disk, so after unmounting your keyfile is securly gone.<br />
So copy your keyfile to some place you consider as secure before unmounting.<br />
If you are planning to store the keyfile as a plain file on your USB device, you can also simply execute the following command in the corresponding directory, e.g. {{ic|/media/sdb1}}<br />
<br />
The keyfile can be of arbitrary content and size. We will generate a random temporary keyfile of 2048 bytes:<br />
# dd if=/dev/urandom of=secretkey bs=512 count=4<br />
<br />
If you stored your temporary keyfile on a physical storage device, remember to not just (re)move the keyfile later on, but use something like<br />
cp secretkey /destination/path<br />
shred --remove --zero secretkey<br />
to securely overwrite it. (However due to journaling filesystems this is also not 100% secure.)<br />
<br />
Add the temporary keyfile with cryptsetup:<br />
# cryptsetup luksAddKey /dev/sda2 secretkey<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
<br />
==== Storing the keyfile ====<br />
To store the key file, you have two options. The first is less risky than the other, but perhaps a bit more secure (if you consider security by obscurity as more secure).<br />
In any case you have to do some further configuration, if not already done above.<br />
<br />
==== Configuration of initcpio ====<br />
You have to add two extra modules in your {{ic|/etc/mkinitcpio.conf}}, one for the drive's file system and one for the codepage. Further if you created a udev rule, you should tell {{ic|mkinitcpio}} about it:<br />
MODULES="ata_generic ata_piix nls_cp437 vfat"<br />
FILES="/etc/udev/rules.d/8-usbstick.rules"<br />
In this example it is assumed that you use a FAT formatted USB drive. Replace those module names if you use another file system on your USB stick (e.g. ext2) or another codepage. Users running the stock Arch kernel should stick to the codepage mentioned here.<br />
<br />
Additionally, insert the {{ic|usb}} hook somewhere before the {{ic|encrypt}} hook.<br />
HOOKS="... '''usb''' encrypt ... filesystems ..."<br />
<br />
If you have a non-US keyboard, it might prove useful to load your keyboard layout before you are prompted to enter the password to unlock the root partition at boot. For this, you will need the {{ic|keymap}} hook before {{ic|encrypt}}.<br />
<br />
Generate a new image (maybe you should backup a copy of your old kernel26.img first):<br />
mkinitcpio -g /boot/initramfs-linux.img<br />
<br />
==== Storing the key as a plain (visible) file ====<br />
Be sure to choose a plain name for your key &ndash; a bit of 'security through obscurity' is always nice ;-). Avoid using dotfiles (hidden files) &ndash; the {{ic|encrypt}} hook will fail to find the keyfile during the boot process.<br />
<br />
You have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} ([[GRUB]]). It should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usbstick:vfat:/secretkey<br />
This assumes {{ic|/dev/usbstick}} is the FAT partition of your choice. Replace it with {{ic|/dev/disk/by-...}} or whatever your device is.<br />
<br />
That is all, reboot and have fun!<br />
<br />
==== Storing the key between MBR and 1st partition ====<br />
We will write the key directly between the Master Boot Record (MBR) and the first partition.<br />
<br />
{{Warning|You should only follow this step if you know what you are doing -- '''it can cause data loss and damage your partitions or MBR on the stick!'''}}<br />
<br />
If you have a bootloader installed on your drive you have to adjust the values. E.g. [[GRUB]] needs the first 16 sectors (actually, it depends on the type of the file system, so do not rely on this too much), so you would have to replace {{ic|seek<nowiki>=</nowiki>4}} with {{ic|seek<nowiki>=</nowiki>16}}; otherwise you would overwrite parts of your GRUB installation. When in doubt, take a look at the first 64 sectors of your drive and decide on your own where to place your key. <br />
<br />
''Optional''<br />
If you do not know if you have enough free space before the first partition, you can do<br />
dd if=/dev/usbstick of=64sectors bs=512 count=64 # gives you copy of your first 64 sectors<br />
hexcurse 64sectors # determine free space<br />
xxd 64sectors | less # alternative hex viewer<br />
<br />
Write your key to the disk:<br />
dd if=secretkey of=/dev/usbstick bs=512 seek=4<br />
<br />
If everything went fine you can now overwrite and delete your temporary secretkey as noted above.<br />
You should not simply use {{ic|rm}} as the keyfile would only be unlinked from your filesystem and be left physically intact.<br />
<br />
Now you have to add a kernel parameter in your {{ic|/boot/grub/menu.lst}} file (GRUB); it should look something like this:<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:2048:2048<br />
Format for the {{ic|cryptkey}} option:<br />
cryptkey=BLOCKDEVICE:OFFSET:SIZE<br />
{{ic|OFFSET}} and {{ic|SIZE}} match in this example, but this is just coincidence - they can differ (and often will). An other possible example could be<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:root root=/dev/mapper/root ro cryptkey=/dev/usb:8192:2048<br />
That is all, reboot and have fun! And look if your partitions still work after that ;-).<br />
<br />
=== Encrypting the Swap partition ===<br />
<br />
==== Without suspend-to-disk support ====<br />
<br />
In systems where suspend to disk is not a desired feature, it is possible to create a swap file that will have a random passphrase with each boot.<br />
<br />
This is accomplished by using dm-crypt directly without LUKS extensions.<br />
<br />
Append a similar line to {{ic|/etc/crypttab}} to set up a randomly encrypted swap partition:<br />
<br />
<device-mapper name> <swap physical partition> SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
Where:<br />
<br />
:*{{ic|<device-mapper name>}} represents the name you want to use as label in /etc/fstab<br />
:*{{ic|<swap physical partition>}} should be the ID of the actual partition. <br> {{Warning|You should use IDs here because if there are multiple hard drives installed in the system, their naming order (sda, sdb,...) can occasionally be scrambled upon boot and thus the swap would be created over a valuable file system, destroying its content. {{ic|<nowiki>ls -l /dev/disk/*/* | grep sdl7</nowiki>}} should help you to find the desired partition.}}<br />
:*{{ic|SWAP}} identifies the partition as a swap partition<br />
:*{{ic|-c}} defines a cipher<br />
:*{{ic|-h}} defines a hash algorithm<br />
:*{{ic|-s}} defines the key size<br />
<br />
Example line (where {{ic|/dev/sdl7}} is the physical partition and {{ic|<nowiki>LABEL=swap</nowiki>}} the desired label):<br />
<br />
swap /dev/disk/by-id/scsi-SATA_Hitachi_HDS7220_JK1130YAGX0R1T-part7 SWAP "-c aes-xts-plain -h whirlpool -s 512"<br />
<br />
:Maps {{ic|/dev/sdl7}} to {{ic|/dev/mapper/swap}} as a swap partition which we can now add in {{ic|/etc/fstab}} like a normal swap.<br />
<br />
If the partition chosen for swap was previously a LUKS partition, crypttab will not overwrite the partition to create a swap partition. This is a safety measure to prevent data loss from accidental mis-identification of the swap partition in crypttab. In order to use such a partition the LUKS header must be removed. This can be accomplished with:<br />
<br />
# dd if=/dev/zero of=/dev/sdl7 bs=1M<br />
<br />
==== With suspend-to-disk support ====<br />
{{Warning|Do not use this setup with a key file. Please read about the issue reported [[Talk:System_Encryption_with_LUKS_for_dm-crypt#Suspend_to_disk_instructions_are_insecure|here]]}}<br />
<br />
To be able to resume after suspending the computer to disk (hibernate), it is required to keep the swap filesystem intact. Therefore, it is required to have a pre-existent LUKS swap partition, which can be stored on the disk or input manually at startup. Because the resume takes place before {{ic|/etc/crypttab}} can be used, it is required to create a hook in {{ic|/etc/mkinitcpio.conf}} to open the swap LUKS device before resuming. The following setup has the disadvantage of having to insert a key manually for the swap partition.<br />
<br />
If you want to use a partition which is currently used by the system, you have to disable it first:<br />
# swapoff /dev/<device><br />
To create the swap partition, follow steps similar to those described in [[#Mapping_partitions | mapping partitions]] above.<br><br />
* Format the partition you want to use as swap with the {{ic|cryptsetup}} command. For performance reasons, you might want to use different ciphers with different key sizes.<br />
<br />
# cryptsetup -c aes-xts-plain -s 512 -h sha512 -v luksFormat /dev/<device><br />
<br />
Check the result with:<br />
<br />
# cryptsetup luksDump /dev/<device><br />
<br />
* Open the partition in {{ic|/dev/mapper}}:<br />
<br />
# cryptsetup luksOpen /dev/<device> swapDevice<br />
<br />
* Create a swap filesystem inside the mapped partition:<br />
<br />
# mkswap /dev/mapper/swapDevice<br />
<br />
Now you should have a LUKS swap partition which asks for the passphrase before mounting. Make sure you remove any line in {{ic|/etc/crypttab}} which uses this device. Now you have to create a hook to open the swap at boot time.<br />
<br />
* Create a hook file containing the open command:<br />
<br />
{{hc|/lib/initcpio/hooks/openswap|<nowiki><br />
# vim: set ft=sh:<br />
run_hook ()<br />
{<br />
cryptsetup luksOpen /dev/<device> swapDevice<br />
}<br />
</nowiki>}}<br />
<br />
* Then create and edit the hook setup file:<br />
{{hc|/lib/initcpio/install/openswap|<nowiki><br />
# vim: set ft=sh:<br />
build ()<br />
{<br />
MODULES=""<br />
BINARIES=""<br />
FILES=""<br />
SCRIPT="openswap"<br />
}<br />
help ()<br />
{<br />
cat<<HELPEOF<br />
This opens the swap encrypted partition /dev/<device> in /dev/mapper/swapDevice<br />
HELPEOF<br />
}<br />
</nowiki>}}<br />
<br />
* Add the hook {{ic|openswap}} in the {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}}, before {{ic|filesystem}}, but '''after''' {{ic|encrypt}} which is mandatory as well. Do not forget to add the {{ic|resume}} hook between {{ic|openswap}} and {{ic|filesystem}} as well.<br />
<br />
* Regenerate the boot image:<br />
<br />
# mkinitcpio -p linux<br />
<br />
* Add the mapped partition to {{ic|/etc/fstab}} by adding the following line:<br />
/dev/mapper/swapDevice swap swap defaults 0 0<br />
<br />
* Set up your system to resume from {{ic|/dev/mapper/swapDevice}}. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>/dev/mapper/swapDevice}} to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root and swap partitions can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/swapDevice ro<br />
<br />
At boot time, the {{ic|openswap}} hook will open the swap partition so the kernel resume may use it. If you use special hooks for resuming from hibernation, make sure they are placed '''after''' {{ic|openswap}} in the {{ic|HOOKS}} array. Please note that because of initrd opening swap, there is no entry for swapDevice in {{ic|/etc/crypttab}} needed in this case.<br />
<br />
=== Using a swap file for suspend-to-disk support ===<br />
* Choose a mapped partition (e.g. {{ic|/dev/mapper/rootDevice}}) whose mounted filesystem (e.g. {{ic|/}}) contains enough free space to hold the entire contents of your system's RAM. For example, if your system has 4 GiB RAM, then you need at least that much free space on the mounted filesystem of your chosen mapped partition for the swap file.<br />
<br />
* [[HOW_TO:_Create_swap_file#Swap_file_creation | Create the swap file]] (e.g. {{ic|/swapfile}}) inside the mounted filesystem of your chosen mapped partition. Be sure to activate it with {{ic|swapon}} and also add it to your {{ic|/etc/fstab}} file afterward.<br />
<br />
* Set up your system to resume from your chosen mapped partition. For example, if you use [[GRUB]] with kernel hibernation support, add {{ic|resume<nowiki>=</nowiki>}}''your chosen mapped partition'' and {{ic|resume_offset<nowiki>=</nowiki>}}''see calculation command below'' to the kernel line in {{ic|/boot/grub/menu.lst}}. A line with encrypted root partition can look like this:<br />
<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda2:rootDevice root=/dev/mapper/rootDevice resume=/dev/mapper/rootDevice resume_offset=123456789 ro<br />
<br />
You can calculate the {{ic|resume_offset}} of your swap file like this:<br />
<br />
# filefrag -v /swapfile | awk '{if($1==0){print $3}}'<br />
<br />
* Add the {{ic|resume}} hook to your {{ic|etc/mkinitcpio.conf}} file and [[Mkinitcpio#Image_creation_and_activation|rebuild the image]] afterward:<br />
<br />
HOOKS="... encrypt '''resume''' ... filesystems ..."<br />
<br />
== Installing the system ==<br />
Now that {{ic|/dev/mapper/root}} and {{ic|/dev/mapper/home}} are in place, we can enter the regular Arch setup script to install the system into the encrypted volumes.<br />
# /arch/setup<br />
{{Note | Most of the installation can be carried out normally. However, there are a few areas where it is important to make certain selections. These are marked below.}}<br />
<br />
=== Prepare hard drive ===<br />
Skip the Partitioning and Auto-Prepare steps and go straight to manual configuration.<br />
Instead of choosing the hardware devices ({{ic|/dev/sdaX}}) directly, you have to select the mapper devices created above.<br />
Choose {{ic|/dev/mapper/root}} for your root and {{ic|/dev/mapper/home}} as {{ic|/home}} partition respectively and format them with any filesystem you like.<br />
The same is valid for a swap partition which is set up like the {{ic|/home}} partition. Make sure you mount {{ic|/dev/sda1}} as the {{ic|/boot}} partition, or else the installer will not properly set up the bootloader.<br />
<br />
=== Select and Install packages ===<br />
Select and install the packages as usual: the base package contains all required programs.<br />
<br />
=== Configure System ===<br />
{{Note|The {{ic|encrypt}} hook is only needed if your root partition is a ''LUKS'' partition (or a LUKS partition that needs to be mounted ''before'' root). The {{ic|encrypt}} hook is not needed if any other partition (swap, for example) is encrypted. System initialization scripts ({{ic|/etc/rc.sysinit}} and {{ic|/etc/crypttab}} among others) take care of those.}}<br />
<br />
Afterwards you can check the files presented to you by the installer, the most important one being {{ic|/etc/mkinitcpio.conf}}. For detailed information about mkinitcpio and its configuration refer to [[Mkinitcpio]]. You have to make sure that your {{ic|HOOKS}} array in {{ic|/etc/mkinitcpio.conf}} looks something like this:<br />
HOOKS="... encrypt ... filesystems ..."<br />
It is important that the {{ic|encrypt}} hook comes ''before'' the {{ic|filesystems}} hook. If you store your key on an external USB device (e.g. a USB stick), you need to add the USB hook too:<br />
HOOKS="... usb encrypt ... filesystems ..."<br />
For safety, add {{ic|usb}} before {{ic|encrypt}} because the hooks are run in the order they appear.<br />
If you need support for foreign keymaps for your encryption password, you have to specify the hook {{ic|keymap}} as well. I suggest putting this in {{ic|/etc/mkinitcpio.conf}} immediately before {{ic|encrypt}}.<br />
<br />
If you have a USB keyboard, you will need the {{ic|usbinput}} hook in {{ic|/etc/mkinitcpio.conf}}. Without it, no USB keyboard will work in early userspace.<br />
<br />
If your root partition is a ''LUKS'' partition, add the used filesystem to the {{ic|MODULES}} section.<br />
MODULES="... ext3 ext4 xfs ..."<br />
<br />
=== Install Bootloader ===<br />
'''[[GRUB]]:''' You have to make some small changes to the entries generated by the installer by replacing {{ic|/dev/mapper/root}} with {{ic|/dev/sda3}}. The important point to remember here is to use the same {{ic|cryptdevice}} name you assigned when you initially unlocked your device. In this example, the device name is {{ic|cryptroot}}; customize yours accordingly:<br />
<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz-linux cryptdevice=/dev/sda3:cryptroot root=/dev/mapper/cryptroot ro<br />
initrd /initramfs-linux.img<br />
<br />
For kernels older than 2.6.37, the syntax is:<br />
# (0) Arch Linux<br />
title Arch Linux<br />
root (hd0,0)<br />
kernel /vmlinuz26 root=/dev/sda3 ro<br />
initrd /kernel26.img<br />
<br />
'''LILO:''' Edit the Arch Linux section in {{ic|/etc/lilo.conf}} and include a line for the {{ic|append}} option, over the initrd, with the {{ic|root<nowiki>=</nowiki>/dev/sda3}} parameter. The {{ic|append}} section makes the same kernel line as in GRUB. Also, you can omit the {{ic|root}} option above the {{ic|image}} option. The section looks like this:<br />
# Arch Linux lilo section<br />
image = /vmlinuz-linux<br />
# root = /dev/sda3<br />
label = Arch<br />
initrd = /initramfs-linux.img<br />
append = "root=/dev/sda3"<br />
read-only<br />
<br />
{{Note|If you want to use a USB flash drive with a keyfile, you have to append the {{ic|cryptkey}} option. See the corresponding section below.}}<br />
<br />
=== Exit Install ===<br />
Now that the install is finished the only thing left to do is add entries to the {{ic|/etc/crypttab}} file so you do not have to enter the passphrase for all encrypted partitions. This works only for non-root partitions e.g. {{ic|/home}}, swap, etc.<br />
# vi /mnt/etc/crypttab<br />
<br />
Add the following line for the {{ic|/home}} partition<br />
{{Note|Using a passphrase to decrypt LUKS partitions automatically from {{ic|/etc/crypttab}} is deprecated: see http://www.mail-archive.com/arch-projects@archlinux.org/msg02115.html}}<br />
home /dev/sda5 "myotherpassword"<br />
<br />
You can also use a keyfile instead of a passphrase. If not already done, create a keyfile and add the key to the corresponding LUKS partition as described [[#Adding_Additional_Passphrases_or_Keyfiles_to_a_LUKS_Encrypted_Partition|above]].<br />
Then add the following information to the {{ic|/etc/crypttab}} file for automounting:<br />
home /dev/sda5 /path/of/your/keyfile<br />
<br />
If you used a USB device to store your keyfile, you should have something like this:<br />
home /dev/sda5 /dev/sd*1/keyfile<br />
<br />
Or if the keyfile was stored in the MBR, it should be like this:<br />
home /dev/sda5 /dev/sd*:2048:2048<br />
<br />
{{Box BLUE|Note:|When reading the keyfile from the MBR it should be {{ic|/dev/sdb}} not {{ic|/dev/sdb1}} but if the key is in the filesystem it should still be {{ic|/dev/sdb1}}.}}<br />
<br />
After rebooting you should now be presented with the text<br />
A password is required to access the root filesystem:<br />
followed by a prompt for a LUKS password. Type it in and everything should boot.<br />
Once you have logged in, have a look at your mounted partitions by typing {{ic|mount}}. You should have {{ic|/dev/mapper/root}} mounted at {{ic|/}} and, if you set up a separate encrypted home partition, {{ic|/dev/mapper/home}} mounted at {{ic|/home}}. If you set up encrypted swap, {{ic|swapon -s}} should have {{ic|/dev/mapper/swap}} listed as your swap partition.<br />
<br />
{{Note|Eventually the text prompting for the password is mixed up with other boot messages. So the boot process may seem frozen at first glance, but it is not, simply enter your password and press {{keypress|Enter}}.}}<br />
<br />
== Remote unlocking of the root (or other) partition ==<br />
If you want to be able to reboot a fully LUKS-encrypted system remotely, or start it with a Wake-on-LAN service, you will need a way to enter a passphrase for the root partition/volume at startup. This can be achieved by running the {{ic|net}} hook along with an [[SSH]] server in initrd. Install the {{AUR|dropbear_initrd_encrypt}} package from the [[Arch User Repository|AUR]] and follow the post-installation instructions. Replace the {{ic|encrypt}} hook with {{ic|dropbear encryptssh}} in {{ic|/etc/mkinitcpio.conf}}. Put the {{ic|net}} hook early in the HOOKS array if your DHCP server takes a long time to lease IP addresses.<br />
<br />
If you would simply like a nice solution to mount other encrypted partitions (such as {{ic|/home}})remotely, you may want to look at [https://bbs.archlinux.org/viewtopic.php?pid=880484 this forum thread].<br />
<br />
{{Note|Acutally trim will not work with this script because it is not yet updated to the latest encrypt hook, so it is not able to parse {{ic|-–allow-discards}} from {{ic|/boot/grub/menu.lst}}. (Version: dropbear_initrd_encrypt 0.8-16). You won't notice any error when using online discard, but you see an error when you try to use {{ic|fstrim}}.For a temporary solution just add {{ic|-–allow-discards}} to every cryptsetup line of {{ic|/lib/initcpio/install/dropbear}}(1 line) and {{ic|/lib/initcpio/hooks/encryptssh}}(3 lines)}}<br />
<br />
== Backup the cryptheader ==<br />
If the header of your encrypted partition gets destroyed, you will not be able to decrypt your data. Therefore, having a backup of the headers and storing them on another disk might be a good idea.<br />
<br />
'''Attention:''' Many people recommend NOT backing up the cryptheader, but even so it's a single point of failure!<br />
In short, the problem is that LUKS is not aware of the duplicated cryptheader, which contains the master key which is used to encrypt all files on your partition. Of course this master key is encrypted with your passphrases or keyfiles.<br />
But if one of those gets compromised and you want to revoke it you have to do this on all copies of the cryptheader!<br />
I.e. if someone has got your cryptheader and one of your keys he can decrypt the master key and access all your data.<br />
Of course the same is true for all backups you create of your partions.<br />
So you decide if you are one of those paranoids brave enough to go without a backup for the sake of security or not.<br />
See also [http://www.saout.de/tikiwiki/tiki-slideshow.php?page=LUKSFaq&slide=1|LUKSFaq]{{Linkrot|2011|09|05}} for further details on this.<br />
<br />
{{Note|You can also back up the header into a tmpfs/ramfs and encrypt it with gpg or whatever before writing it to a physical disk. Of course you can wrap your encrypted backup into another encryption layer and so on until you feel safe enough :-)}}<br />
<br />
=== Backup ===<br />
==== Manually ====<br />
First you have to find out the payload offset of the crypted partition (replace sdaX with the corresponding partition)<br />
cryptsetup luksDump /dev/sdaX | grep "Payload offset"<br />
Payload offset: 4040<br />
Now that you know the value, you can backup the header with a simple dd command<br />
dd if=/dev/sdaX of=./backup.img bs=512 count=4040<br />
<br />
==== Using cryptsetup ====<br />
You can also use the luksHeaderBackup command instead:<br />
cryptsetup luksHeaderBackup /dev/sdaX --header-backup-file ./backup.img<br />
<br />
=== Restore ===<br />
Be careful before restore: make sure that you chose the right partition (again replace sdaX with the corresponding partition).<br />
Restoring the wrong header or restoring to an unencrypted partition will cause data loss.<br />
==== Manually ====<br />
Again, you will need to the same values as when backing up:<br />
dd if=./backup.img of=/dev/sdX bs=512 count=4040<br />
==== Using cryptsetup ====<br />
Or you can use the luksHeaderRestore command:<br />
cryptsetup luksHeaderRestore /dev/sdaX --header-backup-file ./backup.img<br />
<br />
'''Note:''' All the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing this command.<br />
<br />
== Encrypting a loopback filesystem ==<br />
''[This paragraph has been merged from another page; its consistency with the other paragraphs should be improved]''<br />
<br />
=== Preparation and mapping ===<br />
First, start by creating an encrypted container!<br />
<br />
dd if=/dev/urandom of=/bigsecret bs=1M count=10<br />
<br />
This will create the file {{ic|bigsecret}} with a size of 10 megabytes.<br />
<br />
losetup /dev/loop0 /bigsecret<br />
<br />
This will create the device node {{ic|/dev/loop0}}, so that we can mount/use our container.<br />
<br />
{{Note|If it gives you the error {{ic|/dev/loop0: No such file or directory}}, you need to first load the kernel module with {{ic|modprobe loop}}. These days (Kernel 3.2) loop devices are created on demand. Ask for a new loop device with {{ic|losetup -f}}.}}<br />
<br />
cryptsetup luksFormat /dev/loop0<br />
<br />
This will ask you for a password for your new container file.<br />
<br />
{{Note|If you get an error like {{ic|Command failed: Failed to setup dm-crypt key mapping. Check kernel for support for the aes-cbc-essiv:sha256 cipher spec and verify that /dev/loop0 contains at least 133 sectors|}}, then run {{ic|modprobe dm-mod}}.}}<br />
<br />
cryptsetup luksOpen /dev/loop0 secret<br />
<br />
The encrypted container is now available through the device file {{ic|/dev/mapper/secret}}.<br />
Now we are able to create a partition in the container:<br />
<br />
mkfs.ext2 /dev/mapper/secret<br />
<br />
and mount it...<br />
<br />
mkdir /mnt/secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
We can now use the container as if it was a normal partition!<br />
To unmount the container:<br />
<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
so, if you want to mount the container again, you just apply the following commands:<br />
<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
mount -t ext2 /dev/mapper/secret /mnt/secret<br />
<br />
=== Encrypt using a key-file ===<br />
Let us first generate a 2048 byte random keyfile:<br />
<br />
dd if=/dev/urandom of=keyfile bs=1k count=2<br />
<br />
We can now format our container using this key<br />
<br />
cryptsetup luksFormat /dev/loop0 keyfile<br />
<br />
or our partition : <br />
<br />
cryptsetup luksFormat /dev/hda2 keyfile<br />
<br />
Once formatted, we can now open the LUKS device using the key:<br />
<br />
cryptsetup -d keyfile luksOpen /dev/loop0 container<br />
<br />
You can now like before format the device {{ic|/dev/mapper/container}} with your favorite filesystem and then mount it just as easily.<br />
<br />
The keyfile is now the only key to your file. I personally advise encrypting your keyfile using your private GPG key and storing an off-site secured copy of the file.<br />
<br />
=== Resizing the loopback filesystem ===<br />
First we should unmount the encrypted container:<br />
umount /mnt/secret<br />
cryptsetup luksClose secret<br />
losetup -d /dev/loop0 # free the loopdevice.<br />
<br />
After this we need to expand our container file with the size of the data we want to add:<br />
<br />
dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Be careful to really use TWO {{ic|>}}, or you will override your current container!<br />
<br />
You could use {{ic|/dev/zero}} instead of {{ic|/dev/urandom}} to significantly speed up the process, but with {{ic|/dev/zero}} your encrypted filesystems will ''not be as secure''. (A better option to create random data quicker than {{ic|/dev/urandom}} is {{ic|frandom}} [https://aur.archlinux.org/packages.php?ID=9869], available from the [[AUR]]).<br />
<br />
Now we have to map the container to the loop device:<br />
losetup /dev/loop0 /bigsecret<br />
cryptsetup luksOpen /dev/loop0 secret<br />
After this we will resize the encrypted part of the container to the maximum size of the container file:<br />
cryptsetup resize secret<br />
Finally, we can resize the filesystem. Here is an example for ext2/3/4:<br />
e2fsck -f /dev/mapper/secret # Just doing a filesystem check, because it's a bad idea to resize a broken fs<br />
resize2fs /dev/mapper/secret<br />
You can now mount your container again:<br />
mount /dev/mapper/secret /mnt/secret<br />
<br />
== Encrypting a LVM setup ==<br />
It's really easy to use encryption with [[LVM]]. If you do not know how to set up LVM, then read [[Installing_with_Software_RAID_or_LVM]].<br />
<br />
The easiest and best method is to set up LVM on top of the encrypted partition instead of the other way around. This link here is easy to follow and explains everything: [http://www.pindarsign.de/webblog/?p=767 Arch Linux: LVM on top of an encrypted partition]<br />
<br />
The most important thing in setting LVM on '''top''' of encryption is that you need to have the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook (and those two before the {{ic|filesystems}} hook, but that's repeating) ''because they are processed in order''.<br />
<br />
To use encryption on top of LVM, you have to first set up your LVM volumes and then use them as the base for the encrypted partitions. That means, in short, that you have to set up LVM first. Then follow this guide, but replace all occurrences of {{ic|/dev/sdXy}} in the guide with its LVM counterpart. (E.g.: {{ic|/dev/sda5}} -> {{ic|/dev/<volume group name>/home}}).<br />
<br />
Do not forget to add the {{ic|encrypt}} hook in {{ic|/etc/mkinitcpio.conf}} '''before''' the {{ic|lvm2}} hook, if you chose to set up encrypted partitions on '''top''' of LVM. Also remember to change {{ic|USELVM}} in {{ic|/etc/rc.conf}} to {{ic|"yes"}}.<br />
<br />
=== LVM with Arch Linux Installer (>2009.08) ===<br />
<br />
Since Arch Linux images 2009.08, LVM and dm_crypt is supported by the installer out of the box.<br />
This makes it very easy to configure your system for [[LVM]] on dm-crypt or vice versa.<br />
Actually the configuration is done exactly as without LVM: see the [[#Arch Linux Installer (>2009.08)|corresponding]] section above. It differs only in two aspects.<br />
<br />
==== The partition and filesystem choice ====<br />
Create a small, unencrypted boot partition and use the remaining space for a single partition which can later be split up into multiple logic volumes by [[LVM]].<br />
<br />
For a LVM-on-dm-crypt system set up the filesystems and mounting points for example like this:<br />
/dev/sda1 raw->ext2;yes;/boot;no_opts;no_label;no_params<br />
/dev/sda2 raw->dm_crypt;yes;no_mountpoint;no_opts;sda2crypt;-c_aes-xts-plain_-y_-s_512<br />
/dev/mapper/sda2crypt dm_crypt->lvm-vg;yes;no_mountpoint;no_opts;no_label;no_params<br />
/dev/mapper/sda2crypt+ lvm-pv->lvm-vg;yes;no_mountpoint;no_opts;cryptpool;no_params<br />
/dev/mapper/cryptpool lvm-vg(cryptpool)->lvm-lv;yes;no_mountpoint;no_opts;cryptroot;10000M|lvm-lv;yes;no_mountpoint;no_opts;crypthome;20000M<br />
/dev/mapper/cryptpool-cryptroot lvm-lv(cryptroot)->ext3;yes;/;no_opts;cryptroot;no_params<br />
/dev/mapper/cryptpool-crypthome lvm-lv(crypthome)->ext3;yes;/home;no_opts;cryptroot;no_params<br />
<br />
==== The configuration stage ====<br />
<br />
* In {{ic|/etc/rc.conf}} set {{ic|USELVM}} to {{ic|"yes"}}<br />
* In {{ic|/etc/mkinitcpio.conf}} add the {{ic|encrypt}} hook '''before''' the {{ic|lvm2}} hook in the {{ic|HOOKS}} array, if you set up LVM on top of the encrypted partition.<br />
<br />
That is it for the LVM & dm_crypt specific part. The rest is done as usual.<br />
<br />
=== Applying this to a non-root partition ===<br />
You might get tempted to apply all this fancy stuff to a non-root partition. Arch does not support this out of the box, however, you can easily change the cryptdev and cryptname values in {{ic|/lib/initcpio/hooks/encrypt}} (the first one to your {{ic|/dev/sd*}} partition, the second to the name you want to attribute). That should be enough.<br />
<br />
The big advantage is you can have everything automated, while setting up {{ic|/etc/crypttab}} with an external key file (i.e. the keyfile is not on any internal hard drive partition) can be a pain - you need to make sure the USB/FireWire/... device gets mounted before the encrypted partition, which means you have to change the order of {{ic|/etc/fstab}} (at least).<br />
<br />
Of course, if the {{Pkg|cryptsetup}} package gets upgraded, you will have to change this script again. However, this solution is to be preferred over hacking {{ic|/etc/rc.sysinit}} or similar files. Unlike {{ic|/etc/crypttab}}, only one partition is supported, but with some further hacking one should be able to have multiple partitions unlocked.<br />
<br />
If you want to do this on a software RAID partition, there is one more thing you need to do. Just setting the {{ic|/dev/mdX}} device in {{ic|/lib/initcpio/hooks/encrypt}} is not enough; the {{ic|encrypt}} hook will fail to find the key for some reason, and not prompt for a passphrase either. It looks like the RAID devices are not brought up until after the {{ic|encrypt}} hook is run. You can solve this by putting the RAID array in {{ic|/boot/grub/menu.lst}}, like <br />
kernel /boot/vmlinuz-linux md=1,/dev/hda5,/dev/hdb5<br />
<br />
If you set up your root partition as a RAID, you will notice the similarities with that setup ;-). [[GRUB]] can handle multiple array definitions just fine:<br />
kernel /boot/vmlinuz-linux root=/dev/md0 ro md=0,/dev/sda1,/dev/sdb1 md=1,/dev/sda5,/dev/sdb5,/dev/sdc5<br />
<br />
=== LVM and dm-crypt manually (short version) ===<br />
<br />
==== Notes ====<br />
If you are smart enough for this, you will be smart enough to ignore/replace LVM-specific things if you do not want to use LVM.<br />
<br />
{{Note|This brief uses reiserfs for some of the partitions, so change this accordingly if you want to use a more "normal" file system, like ext4.}}<br />
<br />
==== Partitioning scheme ====<br />
{{ic|/dev/sda1}} -> {{ic|/boot}}<br />
{{ic|/dev/sda2}} -> LVM<br />
<br />
==== The commands ====<br />
cryptsetup -d /dev/random -c aes-xts-plain -s 512 create lvm /dev/sda2<br />
dd if=/dev/urandom of=/dev/mapper/lvm<br />
cryptsetup remove lvm<br />
lvm pvcreate /dev/sda2<br />
lvm vgcreate lvm /dev/sda2<br />
lvm lvcreate -L 10G -n root lvm<br />
lvm lvcreate -L 500M -n swap lvm<br />
lvm lvcreate -L 500M -n tmp lvm<br />
lvm lvcreate -l 100%FREE -n home lvm<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/root<br />
cryptsetup luksOpen /dev/lvm/root root<br />
mkreiserfs /dev/mapper/root<br />
mount /dev/mapper/root /mnt<br />
dd if=/dev/zero of=/dev/sda1 bs=1M<br />
mkreiserfs /dev/sda1<br />
mkdir /mnt/boot<br />
mount /dev/sda1 /mnt/boot<br />
mkdir -p -m 700 /mnt/etc/luks-keys<br />
dd if=/dev/random of=/mnt/etc/luks-keys/home bs=1 count=256<br />
<br />
==== Install Arch Linux ====<br />
Run {{ic|/arch/setup}}<br />
<br />
==== Configuration ====<br />
<br />
===== /etc/rc.conf =====<br />
Change {{ic|USELVM<nowiki>=</nowiki>"no"}} to {{ic|USELVM<nowiki>=</nowiki>"yes"}}.<br />
<br />
===== /etc/mkinitcpio.conf =====<br />
Put {{ic|lvm2}} and {{ic|encrypt}} (in that order) before {{ic|filesystems}} in the {{ic|HOOKS}} array. Again, note that you are setting encryption on '''top''' of LVM.)<br />
<br />
if you want install the system on a usb stick, you need to put {{ic|usb}} just after {{ic|udev}}.<br />
<br />
===== /boot/grub/menu.lst =====<br />
Change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to {{ic|root<nowiki>=</nowiki>/dev/lvm/root}}.<br />
<br />
For kernel >= 2.6.30, you should change {{ic|root<nowiki>=</nowiki>/dev/hda3}} to the following:<br />
cryptdevice=/dev/lvm/root:root root=/dev/mapper/root<br />
<br />
if you want install the system on a usb stick, you need to add {{ic|lvmdelay<nowiki>=</nowiki>/dev/mapper/lvm-root}}<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/root / reiserfs defaults 0 1<br />
/dev/sda1 /boot reiserfs defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
<br />
===== /etc/crypttab =====<br />
swap /dev/lvm/swap SWAP -c aes-xts-plain -h whirlpool -s 512<br />
tmp /dev/lvm/tmp /dev/urandom -c aes-xts-plain -s 512<br />
<br />
==== After rebooting ====<br />
<br />
===== The commands =====<br />
cryptsetup luksFormat -c aes-xts-plain -s 512 /dev/lvm/home /etc/luks-keys/home<br />
cryptsetup luksOpen -d /etc/luks-keys/home /dev/lvm/home home<br />
mkreiserfs /dev/mapper/home<br />
mount /dev/mapper/home /home<br />
<br />
===== /etc/crypttab =====<br />
home /dev/lvm/home /etc/luks-keys/home<br />
<br />
===== /etc/fstab =====<br />
/dev/mapper/home /home reiserfs defaults 0 0<br />
<br />
=== / on LVM on LUKS ===<br />
Make sure your kernel command line looks like this:<br />
root=/dev/mapper/<volume-group>-<logical-volume> cryptdevice=/dev/<luks-part>:<volume-group><br />
For example:<br />
root=/dev/mapper/vg-arch cryptdevice=/dev/sda4:vg<br />
<br />
Or like this:<br />
cryptdevice=/dev/<volume-group>/<logical-volume>:root root=/dev/mapper/root<br />
<br />
==Using GPG or OpenSSL Encrypted Keyfiles==<br />
The following forum posts give instructions to use two factor authentication, gpg or openssl encrypted keyfiles, instead of a plaintext keyfile described earlier in this wiki article [https://bbs.archlinux.org/viewtopic.php?id=120243 System Encryption using LUKS with GPG encrypted keys]:<br />
* GnuPG: [https://bbs.archlinux.org/viewtopic.php?pid=943338#p943338 Post regarding GPG encrypted keys] This post hs the generic instructions.<br />
* OpenSSL: [https://bbs.archlinux.org/viewtopic.php?pid=947805#p947805 Post regarding OpenSSL encrypted keys] This post only has the {{ic|ssldec}} hooks.<br />
<br />
Note that:<br />
* You can follow the above instructions with only two primary partitions one boot partition <br />
(required because of LVM), and one primary LVM partition. Within the LVM partition you can have <br />
as many partitions as you need, but most importantly it should contain at least root, swap, and <br />
home logical volume partitions. This has the added benefit of having only one keyfile for all <br />
your partitions, and having the ability to hibernate your computer (suspend to disk) where the <br />
swap partition is encrypted. If you decide to do so your hooks in {{ic|/etc/mkinitcpio.conf}} <br />
should look like<br />
{{ic|HOOKS&#61;" ... usb usbinput (etwo or ssldec) encrypt lvm2 resume ... "}}<br />
and you should add to your {{ic|kernel}} line(if using grub, {{ic|/boot/grub/menu.lst}}) or <br />
{{ic|GRUB_CMD_LINE}}(if using grub2, {{ic|/etc/default/grub}}):<br />
{{ic|"resume&#61;/dev/mapper/<VolumeGroupName>-<LVNameOfSwap>"}}<br />
* If you need to temporarily store the unecrypted keyfile somewhere, do not store them on an <br />
unencrytped disk. Even better make sure to store them to RAM such as {{ic|/dev/shm}}.<br />
* If you want to use a GPG encrypted keyfile, you need to use a statically compiled GnuPG version 1.4 or you could edit the hooks and use this AUR package [https://aur.archlinux.org/packages.php?ID=58030 gnupg1]<br />
* It is possible that an update to OpenSSL could break the custom {{ic|ssldec}} mentioned in the second forum post.<br />
<br />
==Securing the unencrypted boot partition==<br />
Referring to an article from the ct-magazine (Issue 3/12, page 146, 01.16.2012 http://www.heise.de/ct/inhalt/2012/03/6/) the following script checks all files under {{ic|/boot}} for changes of SHA-1 hash, inode and occupied blocks on the hard drive. It also checks the MBR.<br />
<br />
The script with installation instructions is available here: ftp://ftp.heise.de/pub/ct/listings/1203-146.zip (Author: Juergen Schmidt, ju at heisec.de; License: GPLv2)<br />
<br />
There is also an AUR package: {{AUR|chkboot}}<br />
<br />
After installation, add {{ic|/usr/local/bin/chkboot.sh &}} to your {{ic|/etc/rc.local}}.<br />
<br />
And as {{ic|/usr/local/bin/chkboot_user.sh}} need to be excuted after login, add it to the autostarts (e.g. under KDE -> System Settings -> Startup and Shutdown -> Autostart)<br />
<br />
== Resources ==<br />
* [http://yannickloth.be/blog/2010/08/01/installing-archlinux-with-software-raid1-encrypted-filesystem-and-lvm2/ Install Arch Linux on top of RAID, LVM2, and encrypted partitions]<br />
* [http://www.freeotfe.org/ FreeOTFE] - Supports unlocking LUKS encrypted volumes in Microsoft Windows.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Firefox&diff=192779Firefox2012-04-04T05:57:35Z<p>JaMeSiTeGeN: /* Method for root user */</p>
<hr />
<div>{{i18n|Firefox}}<br />
[[Category:Web Browser (English)]]<br />
<br />
[[fr:Firefox]]<br />
{{Article summary start}}<br />
{{Article summary text|Installing and troubleshooting the Firefox browser and plugins}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Browser Plugins}}: Acquiring and installing plugins such as [[Flash]]<br />
{{Article summary wiki|Firefox Tweaks}}: Configuration and modifications<br />
{{Article summary end}}<br />
<br />
[http://www.firefox.com Firefox] is a popular open-source graphical web browser from [http://www.mozilla.com Mozilla].<br />
<br />
== Installing ==<br />
The {{Pkg|firefox}} package can be found in the [[Official Repositories|official repositories]] and can be installed with [[pacman]].<br />
<br />
There are a number of language packs available if English is not your preferred language. To see a list of available language packs, try:<br />
{{bc|$ pacman -Ss firefox-i18n}}<br />
<br />
== Add-ons ==<br />
Firefox is well known for its large library of add-ons which can be used to add new features or modify the behavior of existing features of Firefox. You can find new add-ons or manage installed add-ons with Firefox's "Add-ons Manager."<br />
<br />
For a list of popular add-ons, see: [https://addons.mozilla.org/en-US/firefox/extensions/?sort=popular Mozilla's add-on list sorted by popularity].<br />
<br />
== Plugins ==<br />
''See: [[Browser Plugins]]''<br />
<br />
To find out what plugins are installed/enabled, enter:<br />
about:plugins<br />
in the Firefox address bar. Or go to ''Addons'' from the main bar drop downs <!-- I use vimperator so I do not know what's the name --> and select the ''Plugins'' tab.<br />
<br />
=== GNOME integration ===<br />
Install {{AUR|firefox-extension-gnome-keyring-git}} from the [[Arch User Repository|AUR]] to integrate Firefox 3.6.x with Gnome-keyring.<br />
<br />
You can also install {{AUR|firefox-extension-firefoxnotify-git}} to get libnotify/notifyOSD integration.<br />
<br />
=== Dictionaries for spell checking ===<br />
Right click in any text entry field and add the dictionary for the solicited language. Restart Firefox, and click in a text entry field again to enable spell checking.<br />
<br />
Or get it from pacman:<br />
pacman -Ss hunspell<br />
<br />
=== Adding Firefox search engines ===<br />
<br />
==== Newer method ====<br />
<br />
Visit https://addons.mozilla.org/en-US/firefox/browse/type:4/ and install.<br />
<br />
If you want to custom one, take a look at: {{ic|~/.mozilla/firefox/xxx.default/searchplugins/}} where xxx is your profile ID).<br />
<br />
==== Method for root user ====<br />
{{out of date}}<br />
Firefox writes search engine files to {{ic|/opt/mozilla/lib/firefox/searchplugins}}, which is, by default, writable only by root. This means users cannot add search engines. You can {{ic|chmod o+w}} this folder to install a search engine.<br />
<br />
To remove search engines, remove the appropriate search engine files in {{ic|/opt/mozilla/lib/firefox/searchplugins}}. The next time you start Firefox, the engine will not be in the list.<br />
<br />
====arch-firefox-search====<br />
Adds Arch-specific searches (AUR, wiki, forum, etc, as specified by user) to the Firefox search toolbar.<br />
# pacman -S arch-firefox-search<br />
<br />
== Projects related to Firefox ==<br />
=== Firefox derivatives ===<br />
*[[Wikipedia:Iceweasel|Iceweasel]] - The name of '''two''' different Firefox forks. One was a GNU project; the name of this project has since changed to [[Wikipedia:GNU_IceCat|Icecat]]. The [http://wiki.debian.org/Iceweasel second] is being developed by Debian and is based on 2.0. At the time of writing the [[AUR]] only has Icecat.<br />
<br />
*[[Wikipedia:GNU IceCat|GNU/IceCat]] - formerly known as GNU IceWeasel, is a web browser distributed by the GNU Project. IceCat, which is made entirely of free software, is a fork of Mozilla Firefox. It is compatible with the GNU/Linux operating system and almost all of Firefox's addons. GNU/IceCat really can fully replace Firefox.<br />
<br />
=== Firefox with better KDE integration ===<br />
*{{AUR|firefox-kde-opensuse}}<br />
:with OpenSUSE patch, integrates better with KDE. OpenSUSE's patch and integration of Firefox with KDE is considered the best by many users.<br />
<br />
*{{Pkg|kpartsplugin}}<br />
:This plugin uses KDE's KParts to embed file viewers into non-KDE browsers<br />
<br />
*[http://kde-look.org/content/show.php/?content=117962 Oxygen KDE]<br />
:This addon provides further integration with KDE's Oxygen theme, color scheme detection, Faenza icons and various customizations.<br />
<br />
== Tips and Tricks ==<br />
This section has been distilled out into a discrete [[Firefox Tweaks]] article.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Firefox 4 New Menu Bar/Firefox Button ===<br />
By default, Arch Linux shows the classic layout of the menu bar. To activate the new Firefox 4 layout with the "Firefox" button replacing the menu bar, uncheck View -> Toolbars -> Menubar.<br />
<br />
In GNU/Linux, you will just get a plain grey button instead of the new orange one from Windows. However you can change this to either a Firefox icon or the icon followed by the "Firefox" text.<br />
<br />
Adding the following to your {{ic|~/.mozilla/firefox/userprofile/chrome/userChrome.css}} file will place the icon before the text:<br />
{{bc|#appmenu-toolbar-button {<br />
list-style-image: url("chrome://branding/content/icon16.png");<br />
}<br />
}}<br />
Adding the following to the same file will ''remove'' the "Firefox" text:<br />
{{bc|#appmenu-toolbar-button > .toolbarbutton-text,<br />
#appmenu-toolbar-button > .toolbarbutton-menu-dropmarker {<br />
display: none !important;<br />
}<br />
}}<br />
<br />
{{Note|You need to create both the {{ic|chrome}} directory and {{ic|userChrome.css}}, if they do not already exist.}}<br />
<br />
=== Open containing folder problems (KDE) ===<br />
If Firefox launches something other than your preferred file manager when using the "Open Containing Folder" option in the Downloads manager, make sure you select your file manager of choice (e.g. Dolphin) in KDE's System Settings:<br />
:'''System Settings -> Default Applications -> File Manager'''<br />
<br />
If you have already selected your file manager of choice and Cervisia (or a file manager other than your favorite) is opening modify your user's {{ic|~/.local/share/applications/defaults.list}} to include these two lines:<br />
x-directory/normal=kde4-dolphin.desktop;kde4-kfmclient_dir.desktop;<br />
inode/directory=kde4-dolphin.desktop;kde4-kfmclient_dir.desktop;kde4-gwenview.desktop;kde4-filelight.desktop;kde4-cervisia.desktop;<br />
<br />
=== Firefox keeps creating ~/Desktop even when this is not desired ===<br />
See [https://bbs.archlinux.org/viewtopic.php?id=66940 this] forum post.<br />
<br />
=== How to prevent plugins from allowing popups? ===<br />
Ever wondered why pop-ups appear even though you have blocked them? It seems that the Flash plugin can bypass default settings and annoy us with those pesky pop-ups. Fear not, for we can prevent it from doing that.<br />
<br />
To get around it:<br />
# Type about:config into the Firefox location bar.<br />
# Right-click on the page and select New and then Integer.<br />
# Name it privacy.popups.disable_from_plugins<br />
# Set the value to 2.<br />
<br />
The possible values are:<br />
* 0: Allow all popups from plugins.<br />
* 1: Allow popups, but limit them to dom.popup_maximum.<br />
* 2: Block popups from plugins.<br />
* 3: Block popups from plugins, even on whitelisted sites.<br />
<br />
=== Middle-click errors ===<br />
! The URL is not valid and cannot be loaded.<br />
Another symptom is that middle-clicking results in unexpected behavior, like accessing a random web page.<br />
<br />
The reason stems from the use of the middle mouse buttons in UNIX-like operating systems. The middle mouse button is used to paste whatever text has been highlighted/added to the clipboard. Then there is the possibly conflicting feature in Firefox, which defaults to loading the URL of the corresponding text when the button is depressed. This can be disabled like so:<br />
<br />
Open the browser, and type the following into the address bar:<br />
about:config<br />
Search for '''middlemouse.contentLoadURL''' and set it to false.<br />
<br />
Alternatively, having the traditional scroll cursor on middle-click (default behaviour on Windows browsers) can be achieved by searching for '''general.autoScroll''' and setting it to true.<br />
<br />
=== Backspace does not work as the 'Back' button ===<br />
As per [http://ubuntu.wordpress.com/2006/12/21/fix-firefox-backspace-to-take-you-to-the-previous-page/ this article], the feature has been removed in order to fix a bug. Follow the next steps to retain the original behaviour.<br />
<br />
Open the browser and type the following address:<br />
about:config<br />
Search for '''browser.backspace_action''' and set it to 0 (zero).<br />
<br />
=== Firefox does not remember login information ===<br />
It may be cause of a corrupted {{ic|cookies.sqlite}} file in [http://support.mozilla.com/en-US/kb/Profiles#How_to_find_your_profile Firefox's profile] folder. In order to fix this, just rename or remove the cookie.sqlite while Firefox is not running.<br />
<br />
Open a terminal of choice and type the following:<br />
$ cd ~/.mozilla/firefox/xxxxxxxx.default/<br />
$ rm -f cookies.sqlite<br />
{{Note|xxxxxxxx represents a random string of 8 characters.}}<br />
<br />
Restart Firefox and see if it solved the problem.<br />
<br />
=== Broken websites / input fields with dark Gtk Themes ===<br />
When using a dark [[GTK]] theme, one might encounter Internet pages with unreadable input and text fields (p.e. Amazon - white text on white background). This can happen because the site only sets either background or text color, and Firefox takes the other one from the theme.<br />
<br />
A work around is to explicitly setting standard colours for all web pages in {{ic|~/.mozilla/firefox/.../chrome/userContent.css}}.<br />
<br />
The following sets input fields to standard black text / white background; both can be overridden by the displayed site, so that colors are seen as intended:<br />
{{bc|<br />
input {<br />
-moz-appearance: none !important;<br />
background-color: white;<br />
color: black;<br />
}<br />
<br />
textarea {<br />
-moz-appearance: none !important;<br />
background-color: white;<br />
color: black;<br />
}<br />
}}<br />
This will force the colours ("Allow paged to choose their own colors [..]" setting, in the '''Preferences > Content > Color''' dialog):<br />
{{bc|<br />
input {<br />
-moz-appearance: none !important;<br />
background-color: pink !important;<br />
color: green !important;<br />
}<br />
<br />
textarea {<br />
-moz-appearance: none !important;<br />
background-color: pink !important;<br />
color: green !important;<br />
}<br />
}}<br />
Change color values to suit, or use an add-on like [https://addons.mozilla.org/en-US/firefox/addon/2108 Stylish].<br />
<br />
=== File association problems ===<br />
For non-[[GNOME]] users, Firefox may not associate file types (in the "Open With" part of the download dialog). Installing {{Pkg|libgnome}} amends the problem:<br />
pacman -S libgnome<br />
If you are using KDE you can also do the following:<br />
ln -s ~/.local/share/applications/mimeapps.list ~/.local/share/applications/mimeinfo.cache<br />
From now on Firefox should use the applications which are explicitly set in KDE.<br />
<br />
=== "I'm Feeling Lucky" Mode ===<br />
"I'm Feeling Lucky" mode lets the user harness the power of Google's "I'm Feeling Lucky" search engine feature via the Firefox address bar.<br />
<br />
To activate this mode, do the following (solution from [http://superuser.com/questions/76530/default-to-im-feeling-lucky-for-non-url-search-terms-in-firefox-address-bar this forum post]):<br />
<br />
# Type "'''about:config'''" in the address bar.<br />
# Search for the string '''keyword.url'''<br />
# Modify its value (if any) to<br />
<nowiki>http://www.google.com/search?btnI=I%27m+Feeling+Lucky&q=</nowiki><br />
<br />
=== "I'm Feeling Ducky" Mode (for DuckDuckGo)===<br />
"I'm Feeling Ducky" is similar to the Google's "I'm Feeling Lucky" but using the DuckDuckGo search engine. <br />
<br />
To activate this mode, do the following (solution using the above one):<br />
<br />
# Type "'''about:config'''" in the address bar.<br />
# Search for the string '''keyword.url'''<br />
# Modify its value (if any) to<br />
<nowiki>https://duckduckgo.com/?q=! </nowiki><br />
<br />
The last character is a space ' '. It is necessary because if you do not put it, it will become a !Bang.<br />
<br />
=== "Do you want Firefox to save your tabs for the next time it starts?" dialog does not appear ===<br />
From the [http://support.mozilla.com/en-US/questions/767751 Mozilla Support] site:<br />
<br />
# Type "'''about:config'''" in the address bar.<br />
# Set '''browser.warnOnQuit''' to '''true'''.<br />
# Set '''browser.showQuitWarning''' to '''true'''.<br />
<br />
=== Firefox has high CPU usage and feels slow on scrolling with nVidia GPUs ===<br />
<br />
In some cases, forcing the proprietary nVidia driver to store pixmaps in video memory instead of system memory can yield massive improvements in the perceived performance of pixmap-intensive applications like Firefox. Run<br />
<br />
$ nvidia-settings -a InitialPixmapPlacement=2<br />
<br />
from the terminal; if desired results are achieved add this line to a script and use your desktop environment's autorun facilities to execute it on every startup. Alternatively, add the parameter to your {{ic|~/.nvidia-settings-rc}} and run<br />
<br />
$ nvidia-settings --load-config-only<br />
<br />
on startup. This setting is documented in [http://cgit.freedesktop.org/~aplattner/nvidia-settings/tree/src/libXNVCtrl/NVCtrl.h?id=b27db3d10d58b821e87fbe3f46166e02dc589855#n2797 nvidia-settings source code]. Make sure you have added other perfomance-improving settings, see [[NVIDIA]].<br />
<br />
=== Firefox uses ugly fonts on certain webpages ===<br />
<br />
When Firefox uses bitmap fonts, it can happen that on certain webpages the fonts are very ugly (compared to Google Chrome for example):<br />
<br />
http://i.imgur.com/SMVdi.png vs http://i.imgur.com/jNmxU.png<br />
<br />
To fix that, just disable bitmap fonts for X:<br />
$ sudo ln -s /etc/fonts/conf.avail/70-no-bitmaps.conf /etc/fonts/conf.d/<br />
<br />
==See also==<br />
* [http://web.glandium.org/blog/?p=97 Facts about Debian and Mozilla® Firefox]<br />
:An account of the trademark issues from the Firefox package maintainer for Debian.<br />
* [http://www.gnu.org/software/gnuzilla/ Gnuzilla and IceWeasel]<br />
:Official website for the GNU Mozilla forks.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=LXDM&diff=176166LXDM2011-12-28T23:49:31Z<p>JaMeSiTeGeN: /* Expected Logout Behavior */</p>
<hr />
<div>[[Category:Display managers (English)]]<br />
{{i18n|LXDM}}<br />
<br />
From [http://wiki.lxde.org/en/LXDM LXDM - LXDE Display Manager]:<br />
<br />
:''LXDM is the lightweight display manager aimed to replace gdm in LXDE distros. The UI is implemented with GTK+. It is stil in early stages of development.''<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] the {{pkg|lxdm}} package which is available in the [[Official Repositories|official repositories]].<br />
<br />
To make the graphical login the default method of logging into the system, edit your {{ic|/etc/inittab}} file (recommended) by adding or uncommenting this line: <br />
{{bc|x:5:respawn:/usr/sbin/lxdm >/dev/null 2>&1}}<br />
Alternatively you can add {{ic|lxdm}} to your list of daemons in {{ic|/etc/rc.conf}}. These procedures are detailed on the [[Display Manager]] page.<br />
<br />
==Configuration==<br />
The configuration files for LXDM are all located in {{ic|/etc/lxdm}}. The main configuration file is {{ic|lxdm.conf}}, and is well documented in it's comments. Another file, {{ic|Xsession}}, is the systemwide x session configuration file and should generally not be edited. The other files in this folder are all bash scripts, which are run when certain events happen in LXDM.<br />
<br />
These are:<br />
# {{ic|LoginReady}}: Is executed with root priviledges when LXDM is ready to show the login window.<br />
# {{ic|PreLogin}}: Is run as root before logging a user in.<br />
# {{ic|PostLogin}}: Is run as the logged-in user right after they have logged in.<br />
# {{ic|PostLogout}}: Is run as the logged-in user right after they have logged out.<br />
# {{ic|PreReboot}}: Is run as root before rebooting with LXDM.<br />
# {{ic|PreShutdown}}: Is run as root before poweroff with LXDM.<br />
<br />
=====Expected Logout Behavior=====<br />
What might be slightly surprising with LXDM is that, by default, it does not clear the last user's desktop background or kill the user's processes when that user logs out. If you desire this behaviour, you can edit {{ic|/etc/lxdm/PostLogout}} like this:<br />
<br />
#!/bin/sh<br />
<br />
# Kills all your processes when you log out.<br />
killall --user $USER -TERM<br />
<br />
# Set's the desktop background to solid black. Useful if you have multiple monitors.<br />
xsetroot -solid black<br />
<br />
{{note|This will kill daemons such as tmux, urxvtd, etc.}}<br />
<br />
=====Default background color=====<br />
Useful if you have a theme such as archlinux-lxdm-theme from the AUR. All you have to do to set a background is add the following to the configuration file.<br />
<br />
bg=#deadbeaf<br />
<br />
=====Autologin=====<br />
If you want to log in to one account automatically, without providing a password, find the line in {{ic|/etc/lxdm/lxdm.conf}} that looks like this:<br />
#autologin=username<br />
Uncomment it, then substitute your own username instead of "username".<br />
<br />
This will cause LXDM to automatically log you in to the specified account when it first starts up. However, if you were to log out of that account, you would have to enter its password to log back into it; and if the password was empty, you would find yourself unable to log into the account. To make it so that you can manually log into the account without entering a password, first delete the password:<br />
<br />
$ passwd -d USERNAME<br />
<br />
Then, edit the PAM file for LXDM, which is {{ic|/etc/pam.d/lxdm}}. The files in this directory describe how users are authenticated by the various installed programs that need to do some sort of authentication. Change the line that says<br />
<br />
auth required pam_unix.so<br />
<br />
to this:<br />
<br />
auth required pam_unix.so nullok<br />
<br />
This will tell the pam_unix authentication module that blank passwords are to be accepted. After making this change, LXDM will let you log into accounts with blank passwords.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=LXDM&diff=176165LXDM2011-12-28T23:38:30Z<p>JaMeSiTeGeN: /* Default background color */</p>
<hr />
<div>[[Category:Display managers (English)]]<br />
{{i18n|LXDM}}<br />
<br />
From [http://wiki.lxde.org/en/LXDM LXDM - LXDE Display Manager]:<br />
<br />
:''LXDM is the lightweight display manager aimed to replace gdm in LXDE distros. The UI is implemented with GTK+. It is stil in early stages of development.''<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] the {{pkg|lxdm}} package which is available in the [[Official Repositories|official repositories]].<br />
<br />
To make the graphical login the default method of logging into the system, edit your {{ic|/etc/inittab}} file (recommended) by adding or uncommenting this line: <br />
{{bc|x:5:respawn:/usr/sbin/lxdm >/dev/null 2>&1}}<br />
Alternatively you can add {{ic|lxdm}} to your list of daemons in {{ic|/etc/rc.conf}}. These procedures are detailed on the [[Display Manager]] page.<br />
<br />
==Configuration==<br />
The configuration files for LXDM are all located in {{ic|/etc/lxdm}}. The main configuration file is {{ic|lxdm.conf}}, and is well documented in it's comments. Another file, {{ic|Xsession}}, is the systemwide x session configuration file and should generally not be edited. The other files in this folder are all bash scripts, which are run when certain events happen in LXDM.<br />
<br />
These are:<br />
# {{ic|LoginReady}}: Is executed with root priviledges when LXDM is ready to show the login window.<br />
# {{ic|PreLogin}}: Is run as root before logging a user in.<br />
# {{ic|PostLogin}}: Is run as the logged-in user right after they have logged in.<br />
# {{ic|PostLogout}}: Is run as the logged-in user right after they have logged out.<br />
# {{ic|PreReboot}}: Is run as root before rebooting with LXDM.<br />
# {{ic|PreShutdown}}: Is run as root before poweroff with LXDM.<br />
<br />
=====Expected Logout Behavior=====<br />
What might be slightly surprising with LXDM is that, by default, it does not clear the last user's desktop background or kill the user's processes when that user logs out. If you desire this behaviour, you can edit {{ic|/etc/lxdm/PostLogout}} like this:<br />
<br />
#!/bin/sh<br />
<br />
# Kills all your processes when you log out.<br />
killall --user $USER -TERM<br />
<br />
# Set's the desktop background to solid black. Useful if you have multiple monitors.<br />
xsetroot -solid black<br />
<br />
=====Default background color=====<br />
Useful if you have a theme such as archlinux-lxdm-theme from the AUR. All you have to do to set a background is add the following to the configuration file.<br />
<br />
bg=#deadbeaf<br />
<br />
=====Autologin=====<br />
If you want to log in to one account automatically, without providing a password, find the line in {{ic|/etc/lxdm/lxdm.conf}} that looks like this:<br />
#autologin=username<br />
Uncomment it, then substitute your own username instead of "username".<br />
<br />
This will cause LXDM to automatically log you in to the specified account when it first starts up. However, if you were to log out of that account, you would have to enter its password to log back into it; and if the password was empty, you would find yourself unable to log into the account. To make it so that you can manually log into the account without entering a password, first delete the password:<br />
<br />
$ passwd -d USERNAME<br />
<br />
Then, edit the PAM file for LXDM, which is {{ic|/etc/pam.d/lxdm}}. The files in this directory describe how users are authenticated by the various installed programs that need to do some sort of authentication. Change the line that says<br />
<br />
auth required pam_unix.so<br />
<br />
to this:<br />
<br />
auth required pam_unix.so nullok<br />
<br />
This will tell the pam_unix authentication module that blank passwords are to be accepted. After making this change, LXDM will let you log into accounts with blank passwords.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=LXDM&diff=176164LXDM2011-12-28T23:38:12Z<p>JaMeSiTeGeN: /* Configuration */</p>
<hr />
<div>[[Category:Display managers (English)]]<br />
{{i18n|LXDM}}<br />
<br />
From [http://wiki.lxde.org/en/LXDM LXDM - LXDE Display Manager]:<br />
<br />
:''LXDM is the lightweight display manager aimed to replace gdm in LXDE distros. The UI is implemented with GTK+. It is stil in early stages of development.''<br />
<br />
==Installation==<br />
<br />
[[pacman|Install]] the {{pkg|lxdm}} package which is available in the [[Official Repositories|official repositories]].<br />
<br />
To make the graphical login the default method of logging into the system, edit your {{ic|/etc/inittab}} file (recommended) by adding or uncommenting this line: <br />
{{bc|x:5:respawn:/usr/sbin/lxdm >/dev/null 2>&1}}<br />
Alternatively you can add {{ic|lxdm}} to your list of daemons in {{ic|/etc/rc.conf}}. These procedures are detailed on the [[Display Manager]] page.<br />
<br />
==Configuration==<br />
The configuration files for LXDM are all located in {{ic|/etc/lxdm}}. The main configuration file is {{ic|lxdm.conf}}, and is well documented in it's comments. Another file, {{ic|Xsession}}, is the systemwide x session configuration file and should generally not be edited. The other files in this folder are all bash scripts, which are run when certain events happen in LXDM.<br />
<br />
These are:<br />
# {{ic|LoginReady}}: Is executed with root priviledges when LXDM is ready to show the login window.<br />
# {{ic|PreLogin}}: Is run as root before logging a user in.<br />
# {{ic|PostLogin}}: Is run as the logged-in user right after they have logged in.<br />
# {{ic|PostLogout}}: Is run as the logged-in user right after they have logged out.<br />
# {{ic|PreReboot}}: Is run as root before rebooting with LXDM.<br />
# {{ic|PreShutdown}}: Is run as root before poweroff with LXDM.<br />
<br />
=====Expected Logout Behavior=====<br />
What might be slightly surprising with LXDM is that, by default, it does not clear the last user's desktop background or kill the user's processes when that user logs out. If you desire this behaviour, you can edit {{ic|/etc/lxdm/PostLogout}} like this:<br />
<br />
#!/bin/sh<br />
<br />
# Kills all your processes when you log out.<br />
killall --user $USER -TERM<br />
<br />
# Set's the desktop background to solid black. Useful if you have multiple monitors.<br />
xsetroot -solid black<br />
<br />
=====Default background color=====<br />
Useful if you have a theme such as archlinux-lxdm-theme from the AUR. All you have to do to set a background is add the following to the configuration file.<br />
<br />
bg=#deadbeaf<br />
<br />
=====Autologin=====<br />
If you want to log in to one account automatically, without providing a password, find the line in {{ic|/etc/lxdm/lxdm.conf}} that looks like this:<br />
#autologin=username<br />
Uncomment it, then substitute your own username instead of "username".<br />
<br />
This will cause LXDM to automatically log you in to the specified account when it first starts up. However, if you were to log out of that account, you would have to enter its password to log back into it; and if the password was empty, you would find yourself unable to log into the account. To make it so that you can manually log into the account without entering a password, first delete the password:<br />
<br />
$ passwd -d USERNAME<br />
<br />
Then, edit the PAM file for LXDM, which is {{ic|/etc/pam.d/lxdm}}. The files in this directory describe how users are authenticated by the various installed programs that need to do some sort of authentication. Change the line that says<br />
<br />
auth required pam_unix.so<br />
<br />
to this:<br />
<br />
auth required pam_unix.so nullok<br />
<br />
This will tell the pam_unix authentication module that blank passwords are to be accepted. After making this change, LXDM will let you log into accounts with blank passwords.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Tmux&diff=172319Tmux2011-12-04T12:14:27Z<p>JaMeSiTeGeN: </p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Software (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article explains how to install and configure tmux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GNU Screen}}<br />
{{Article summary end}}<br />
<br />
[http://tmux.sourceforge.net/ Tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which has not had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in {{Codeline|/usr/share/tmux/}}. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' {{Codeline|Ctrl-b}}<br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type {{Codeline|Ctrl-b %}}.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. {{Codeline|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. {{Codeline|Ctrl-b}}) to {{Codeline|Ctrl-a}} by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
If you enable xterm-keys in your {{filename|tmux.conf}}, then you need to build a custom terminfo to declare the new escape codes or applications will not know about them. Compile the following with {{filename|tic}} and you can use "xterm-screen-256color" as your TERM:<br />
<br />
# A screen- based TERMINFO that declares the escape sequences<br />
# enabled by the tmux config "set-window-option -g xterm-keys".<br />
#<br />
# Prefix the name with xterm- since some applications inspect<br />
# the TERM *name* in addition to the terminal capabilities advertised.<br />
xterm-screen-256color|GNU Screen with 256 colors bce and tmux xterm-keys,<br />
<br />
# As of Nov'11, the below keys are picked up by<br />
# .../tmux/blob/master/trunk/xterm-keys.c:<br />
kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,<br />
kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,<br />
kRIT=\E[1;2C,<br />
<br />
# Change this to screen-256color if the terminal you run tmux in<br />
# doesn't support bce:<br />
use=screen-256color-bce,<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your {{Filename|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==ICCCM Selection Integration==<br />
It is possible to copy a tmux paste buffer to an ICCCM selection, and vice-versa, by defining a shell command which interfaces tmux with an X11 selection interface. The following tmux config file snippet effectively integrates {{Codeline|CLIPBOARD}} with the current tmux paste buffer using xclip:<br />
<br />
{{File|name=~/.tmux.conf|content=<br />
...<br />
##CLIPBOARD selection integration<br />
##Requires prefix key before the command key<br />
#Copy tmux paste buffer to CLIPBOARD<br />
bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"<br />
#Copy CLIPBOARD to tmux paste buffer and paste tmux paste buffer<br />
bind C-v run "tmux set-buffer \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"<br />
}}<br />
<br />
==Tips & Tricks==<br />
<br />
===Start tmux on every shell login===<br />
<br />
Simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, do not do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias sprunge="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable.}}<br />
<br />
This snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
# TMUX<br />
if which tmux 2>&1 >/dev/null; then<br />
# if no session is started, start a new session<br />
if test -z ${TMUX}; then<br />
tmux<br />
fi<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
<br />
{{note|Instead of using the bashrc file, you can launch tmux when you start your terminal emulator. (i. e. urxvt -e tmux)}}<br />
<br />
===Split window and retain current directory===<br />
<br />
====Fast method====<br />
<br />
{{Note|If you have set default-path to something for another convince; it will be reset to ~/}}<br />
<br />
This command simply sets the default-path to your current path, splits the window, and resets it to your home directory. Can be easily bound to a key if you wish.<br />
<br />
tmux set default-path $(pwd) \; split-window\; set default-path ~/<br />
<br />
====cd method====<br />
<br />
{{Note|This trick tries to inject a key into your session, which only works if it is at a command prompt (i. e. fails within a program like vim, emacs, …).}}<br />
<br />
Create a excutable file as follows, for example {{Filename|~/.scripts/tmux-split}}:<br />
<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
<br />
bind v split-window -h<br />
bind n split-window -v<br />
<br />
to<br />
<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
<br />
====/proc method====<br />
<br />
{{Note|This script, [http://chneukirchen.org/dotfiles/bin/tmux-neww-in-cwd borrowed from] Christian Neukirchen, reads the present pane's CWD from {{Codeline|/proc/[pane's top program's $PID]/cwd}}. Some shells like zsh will not always properly update that entry.}}<br />
<br />
Pasted into e. g. {{Filename|~/.scripts/tmux-split-in-cwd}}:<br />
<br />
#!/bin/sh<br />
# tmux-split-in-cwd - open a new shell with same cwd as calling pane<br />
<br />
SIP=$(tmux display-message -p "#S:#I:#P")<br />
PTY=$(tmux server-info |<br />
egrep flags=\|bytes |<br />
awk '/windows/ { s = $2 }<br />
/references/ { i = $1 }<br />
/bytes/ { print s i $1 $2 } ' |<br />
grep "$SIP" |<br />
cut -d: -f4)<br />
PTS=${PTY#/dev/}<br />
PID=$(ps -eao pid,tty,command --forest | awk '$2 == "'$PTS'" {print $1; exit}')<br />
DIR=$(readlink /proc/$PID/cwd)<br />
<br />
case "$1" in<br />
h) tmux splitw -h "cd '$DIR'; $SHELL"<br />
;;<br />
v) tmux splitw -v "cd '$DIR'; $SHELL"<br />
;;<br />
*) tmux neww "cd '$DIR'; $SHELL"<br />
;;<br />
esac<br />
<br />
{{Filename|~/.tmux.conf}} could thus contain:<br />
<br />
bind | run '~/.scripts/tmux-split-in-cwd h' # horizontal split in cwd<br />
bind _ run '~/.scripts/tmux-split-in-cwd v' # vertical split in cwd<br />
bind m run '~/.scripts/tmux-split-in-cwd' # new window in cwd<br />
<br />
===Use tmux windows like tabs===<br />
<br />
The following settings added to {{Filename|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{Keypress|Ctrl}}+{{Keypress|d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
===Clients simultaneously interacting with various windows of a session===<br />
<br />
In “[http://mutelight.org/articles/practical-tmux Practical Tmux]”, Brandur Leach writes:<br />
<br />
{{Box||Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
<br />
This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
However, this usage of tmux results in the problem that detaching from these mirrored sessions will start to litter your system with defunct sessions which can only be cleaned up with some pretty extreme micromanagement.}}<br />
<br />
To avoid these issues he wrote the script “{{Codeline|tmx}}” — the version below is slightly modified to execute “{{Codeline|tmux new-window}}” if “1” is its second parameter. Invoked as {{Codeline|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise it will kill any “zombie” sessions, launch a new “client” session linked to the base, optionally add a new window and attach. Then it waits for detachment and kills its session.<br />
<br />
{{File|tmx|content=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
# Kill defunct sessions first<br />
old_sessions=$(tmux ls 2>/dev/null | egrep "^[0-9]{14}.*[0-9]+\)$" | cut -f 1 -d:)<br />
for old_session_id in $old_sessions; do<br />
tmux kill-session -t $old_session_id<br />
done<br />
<br />
echo "Launching copy of base session $base_session ..."<br />
# Session is is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session<br />
tmux attach-session -t $session_id<br />
# When we detach from it, kill the session<br />
tmux kill-session -t $session_id<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{Filename|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
===Changing the configuration with tmux started===<br />
<br />
By default tmux reads {{Filename|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{Filename|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
== See also ==<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux] by Brandur Leach, providing a number of configuration tips<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial] section from the OpenBSD FAQ<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison] page by Dayid Alan<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial] blog post by Jeff Story<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] & [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2] blog posts on Hawk Host<br />
<br />
'''Forum threads'''<br />
* 2009-11-06 - Arch Linux - [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Anyone loving Tmux in place of Screen? Info/Tips etc. URLs I've found]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Tmux&diff=170579Tmux2011-11-19T04:49:55Z<p>JaMeSiTeGeN: /* Start tmux on every shell login */</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Software (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article explains how to install and configure tmux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GNU Screen}}<br />
{{Article summary end}}<br />
<br />
[http://tmux.sourceforge.net/ Tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which has not had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in {{Codeline|/usr/share/tmux/}}. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' {{Codeline|Ctrl-b}}<br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type {{Codeline|Ctrl-b %}}.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. {{Codeline|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. {{Codeline|Ctrl-b}}) to {{Codeline|Ctrl-a}} by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
If you enable xterm-keys in your {{filename|tmux.conf}}, then you need to build a custom terminfo to declare the new escape codes or applications will not know about them. Compile the following with {{filename|tic}} and you can use "xterm-screen-256color" as your TERM:<br />
<br />
# A screen- based TERMINFO that declares the escape sequences<br />
# enabled by the tmux config "set-window-option -g xterm-keys".<br />
#<br />
# Prefix the name with xterm- since some applications inspect<br />
# the TERM *name* in addition to the terminal capabilities advertised.<br />
xterm-screen-256color|GNU Screen with 256 colors bce and tmux xterm-keys,<br />
<br />
# As of Nov'11, the below keys are picked up by<br />
# .../tmux/blob/master/trunk/xterm-keys.c:<br />
kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,<br />
kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,<br />
kRIT=\E[1;2C,<br />
<br />
# Change this to screen-256color if the terminal you run tmux in<br />
# doesn't support bce:<br />
use=screen-256color-bce,<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your {{Filename|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==ICCCM Selection Integration==<br />
It is possible to copy a tmux paste buffer to an ICCCM selection, and vice-versa, by defining a shell command which interfaces tmux with an X11 selection interface. The following tmux config file snippet effectively integrates {{Codeline|CLIPBOARD}} with the current tmux paste buffer using xclip:<br />
<br />
{{File|name=~/.tmux.conf|content=<br />
...<br />
##CLIPBOARD selection integration<br />
##Requires prefix key before the command key<br />
#Copy tmux paste buffer to CLIPBOARD<br />
bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"<br />
#Copy CLIPBOARD to tmux paste buffer and paste tmux paste buffer<br />
bind C-v run "tmux set-buffer \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"<br />
}}<br />
<br />
==Tips & Tricks==<br />
<br />
===Start tmux on every shell login===<br />
<br />
Simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, do not do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias sprunge="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable.}}<br />
<br />
This snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
# TMUX<br />
if which tmux 2>&1 >/dev/null; then<br />
# if no session is started, start a new session<br />
if test -z ${TMUX}; then<br />
tmux<br />
fi<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
<br />
{{note|Instead of using the bashrc file, you can launch tmux when you start your terminal emulator. (i. e. urxvt -e tmux)}}<br />
<br />
===Split window and retain current directory===<br />
<br />
====Fast method====<br />
<br />
{{Note|This trick tries to inject a key into your session, which only works if it is at a command prompt (i. e. fails within a program like vim, emacs, …).}}<br />
<br />
Create a excutable file as follows, for example {{Filename|~/.scripts/tmux-split}}:<br />
<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
<br />
bind v split-window -h<br />
bind n split-window -v<br />
<br />
to<br />
<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
<br />
====/proc method====<br />
<br />
{{Note|This script, [http://chneukirchen.org/dotfiles/bin/tmux-neww-in-cwd borrowed from] Christian Neukirchen, reads the present pane's CWD from {{Codeline|/proc/[pane's top program's $PID]/cwd}}. Some shells like zsh will not always properly update that entry.}}<br />
<br />
Pasted into e. g. {{Filename|~/.scripts/tmux-split-in-cwd}}:<br />
<br />
#!/bin/sh<br />
# tmux-split-in-cwd - open a new shell with same cwd as calling pane<br />
<br />
SIP=$(tmux display-message -p "#S:#I:#P")<br />
PTY=$(tmux server-info |<br />
egrep flags=\|bytes |<br />
awk '/windows/ { s = $2 }<br />
/references/ { i = $1 }<br />
/bytes/ { print s i $1 $2 } ' |<br />
grep "$SIP" |<br />
cut -d: -f4)<br />
PTS=${PTY#/dev/}<br />
PID=$(ps -eao pid,tty,command --forest | awk '$2 == "'$PTS'" {print $1; exit}')<br />
DIR=$(readlink /proc/$PID/cwd)<br />
<br />
case "$1" in<br />
h) tmux splitw -h "cd '$DIR'; $SHELL"<br />
;;<br />
v) tmux splitw -v "cd '$DIR'; $SHELL"<br />
;;<br />
*) tmux neww "cd '$DIR'; $SHELL"<br />
;;<br />
esac<br />
<br />
{{Filename|~/.tmux.conf}} could thus contain:<br />
<br />
bind | run '~/.scripts/tmux-split-in-cwd h' # horizontal split in cwd<br />
bind _ run '~/.scripts/tmux-split-in-cwd v' # vertical split in cwd<br />
bind m run '~/.scripts/tmux-split-in-cwd' # new window in cwd<br />
<br />
===Use tmux windows like tabs===<br />
<br />
The following settings added to {{Filename|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{Keypress|Ctrl}}+{{Keypress|d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
===Clients simultaneously interacting with various windows of a session===<br />
<br />
In “[http://mutelight.org/articles/practical-tmux Practical Tmux]”, Brandur Leach writes:<br />
<br />
{{Box||Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
<br />
This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
However, this usage of tmux results in the problem that detaching from these mirrored sessions will start to litter your system with defunct sessions which can only be cleaned up with some pretty extreme micromanagement.}}<br />
<br />
To avoid these issues he wrote the script “{{Codeline|tmx}}” — the version below is slightly modified to execute “{{Codeline|tmux new-window}}” if “1” is its second parameter. Invoked as {{Codeline|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise it will kill any “zombie” sessions, launch a new “client” session linked to the base, optionally add a new window and attach. Then it waits for detachment and kills its session.<br />
<br />
{{File|tmx|content=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
# Kill defunct sessions first<br />
old_sessions=$(tmux ls 2>/dev/null | egrep "^[0-9]{14}.*[0-9]+\)$" | cut -f 1 -d:)<br />
for old_session_id in $old_sessions; do<br />
tmux kill-session -t $old_session_id<br />
done<br />
<br />
echo "Launching copy of base session $base_session ..."<br />
# Session is is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session<br />
tmux attach-session -t $session_id<br />
# When we detach from it, kill the session<br />
tmux kill-session -t $session_id<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{Filename|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
===Changing the configuration with tmux started===<br />
<br />
By default tmux reads {{Filename|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{Filename|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
== See also ==<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux] by Brandur Leach, providing a number of configuration tips<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial] section from the OpenBSD FAQ<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison] page by Dayid Alan<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial] blog post by Jeff Story<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] & [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2] blog posts on Hawk Host<br />
<br />
'''Forum threads'''<br />
* 2009-11-06 - Arch Linux - [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Anyone loving Tmux in place of Screen? Info/Tips etc. URLs I've found]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Tmux&diff=170578Tmux2011-11-19T04:49:37Z<p>JaMeSiTeGeN: /* Start tmux on every shell login */</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Software (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article explains how to install and configure tmux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GNU Screen}}<br />
{{Article summary end}}<br />
<br />
[http://tmux.sourceforge.net/ Tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which has not had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in {{Codeline|/usr/share/tmux/}}. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' {{Codeline|Ctrl-b}}<br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type {{Codeline|Ctrl-b %}}.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. {{Codeline|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. {{Codeline|Ctrl-b}}) to {{Codeline|Ctrl-a}} by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
If you enable xterm-keys in your {{filename|tmux.conf}}, then you need to build a custom terminfo to declare the new escape codes or applications will not know about them. Compile the following with {{filename|tic}} and you can use "xterm-screen-256color" as your TERM:<br />
<br />
# A screen- based TERMINFO that declares the escape sequences<br />
# enabled by the tmux config "set-window-option -g xterm-keys".<br />
#<br />
# Prefix the name with xterm- since some applications inspect<br />
# the TERM *name* in addition to the terminal capabilities advertised.<br />
xterm-screen-256color|GNU Screen with 256 colors bce and tmux xterm-keys,<br />
<br />
# As of Nov'11, the below keys are picked up by<br />
# .../tmux/blob/master/trunk/xterm-keys.c:<br />
kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,<br />
kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,<br />
kRIT=\E[1;2C,<br />
<br />
# Change this to screen-256color if the terminal you run tmux in<br />
# doesn't support bce:<br />
use=screen-256color-bce,<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your {{Filename|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==ICCCM Selection Integration==<br />
It is possible to copy a tmux paste buffer to an ICCCM selection, and vice-versa, by defining a shell command which interfaces tmux with an X11 selection interface. The following tmux config file snippet effectively integrates {{Codeline|CLIPBOARD}} with the current tmux paste buffer using xclip:<br />
<br />
{{File|name=~/.tmux.conf|content=<br />
...<br />
##CLIPBOARD selection integration<br />
##Requires prefix key before the command key<br />
#Copy tmux paste buffer to CLIPBOARD<br />
bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"<br />
#Copy CLIPBOARD to tmux paste buffer and paste tmux paste buffer<br />
bind C-v run "tmux set-buffer \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"<br />
}}<br />
<br />
==Tips & Tricks==<br />
<br />
===Start tmux on every shell login===<br />
<br />
Simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, do not do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias sprunge="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable.}}<br />
<br />
This snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
# TMUX<br />
if which tmux 2>&1 >/dev/null; then<br />
# if no session is started, start a new session<br />
if test -z ${TMUX}; then<br />
tmux<br />
fi<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
<br />
{{note|Instead of using the bashrc file, you can launch tmux when you start your terminal emulator. (i. e: urxvt -e tmux)}}<br />
<br />
===Split window and retain current directory===<br />
<br />
====Fast method====<br />
<br />
{{Note|This trick tries to inject a key into your session, which only works if it is at a command prompt (i. e. fails within a program like vim, emacs, …).}}<br />
<br />
Create a excutable file as follows, for example {{Filename|~/.scripts/tmux-split}}:<br />
<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
<br />
bind v split-window -h<br />
bind n split-window -v<br />
<br />
to<br />
<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
<br />
====/proc method====<br />
<br />
{{Note|This script, [http://chneukirchen.org/dotfiles/bin/tmux-neww-in-cwd borrowed from] Christian Neukirchen, reads the present pane's CWD from {{Codeline|/proc/[pane's top program's $PID]/cwd}}. Some shells like zsh will not always properly update that entry.}}<br />
<br />
Pasted into e. g. {{Filename|~/.scripts/tmux-split-in-cwd}}:<br />
<br />
#!/bin/sh<br />
# tmux-split-in-cwd - open a new shell with same cwd as calling pane<br />
<br />
SIP=$(tmux display-message -p "#S:#I:#P")<br />
PTY=$(tmux server-info |<br />
egrep flags=\|bytes |<br />
awk '/windows/ { s = $2 }<br />
/references/ { i = $1 }<br />
/bytes/ { print s i $1 $2 } ' |<br />
grep "$SIP" |<br />
cut -d: -f4)<br />
PTS=${PTY#/dev/}<br />
PID=$(ps -eao pid,tty,command --forest | awk '$2 == "'$PTS'" {print $1; exit}')<br />
DIR=$(readlink /proc/$PID/cwd)<br />
<br />
case "$1" in<br />
h) tmux splitw -h "cd '$DIR'; $SHELL"<br />
;;<br />
v) tmux splitw -v "cd '$DIR'; $SHELL"<br />
;;<br />
*) tmux neww "cd '$DIR'; $SHELL"<br />
;;<br />
esac<br />
<br />
{{Filename|~/.tmux.conf}} could thus contain:<br />
<br />
bind | run '~/.scripts/tmux-split-in-cwd h' # horizontal split in cwd<br />
bind _ run '~/.scripts/tmux-split-in-cwd v' # vertical split in cwd<br />
bind m run '~/.scripts/tmux-split-in-cwd' # new window in cwd<br />
<br />
===Use tmux windows like tabs===<br />
<br />
The following settings added to {{Filename|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{Keypress|Ctrl}}+{{Keypress|d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
===Clients simultaneously interacting with various windows of a session===<br />
<br />
In “[http://mutelight.org/articles/practical-tmux Practical Tmux]”, Brandur Leach writes:<br />
<br />
{{Box||Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
<br />
This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
However, this usage of tmux results in the problem that detaching from these mirrored sessions will start to litter your system with defunct sessions which can only be cleaned up with some pretty extreme micromanagement.}}<br />
<br />
To avoid these issues he wrote the script “{{Codeline|tmx}}” — the version below is slightly modified to execute “{{Codeline|tmux new-window}}” if “1” is its second parameter. Invoked as {{Codeline|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise it will kill any “zombie” sessions, launch a new “client” session linked to the base, optionally add a new window and attach. Then it waits for detachment and kills its session.<br />
<br />
{{File|tmx|content=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
# Kill defunct sessions first<br />
old_sessions=$(tmux ls 2>/dev/null | egrep "^[0-9]{14}.*[0-9]+\)$" | cut -f 1 -d:)<br />
for old_session_id in $old_sessions; do<br />
tmux kill-session -t $old_session_id<br />
done<br />
<br />
echo "Launching copy of base session $base_session ..."<br />
# Session is is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session<br />
tmux attach-session -t $session_id<br />
# When we detach from it, kill the session<br />
tmux kill-session -t $session_id<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{Filename|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
===Changing the configuration with tmux started===<br />
<br />
By default tmux reads {{Filename|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{Filename|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
== See also ==<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux] by Brandur Leach, providing a number of configuration tips<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial] section from the OpenBSD FAQ<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison] page by Dayid Alan<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial] blog post by Jeff Story<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] & [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2] blog posts on Hawk Host<br />
<br />
'''Forum threads'''<br />
* 2009-11-06 - Arch Linux - [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Anyone loving Tmux in place of Screen? Info/Tips etc. URLs I've found]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Tmux&diff=170577Tmux2011-11-19T04:49:22Z<p>JaMeSiTeGeN: /* Start tmux on every shell login */</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Software (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article explains how to install and configure tmux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GNU Screen}}<br />
{{Article summary end}}<br />
<br />
[http://tmux.sourceforge.net/ Tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which has not had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in {{Codeline|/usr/share/tmux/}}. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' {{Codeline|Ctrl-b}}<br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type {{Codeline|Ctrl-b %}}.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. {{Codeline|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. {{Codeline|Ctrl-b}}) to {{Codeline|Ctrl-a}} by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
If you enable xterm-keys in your {{filename|tmux.conf}}, then you need to build a custom terminfo to declare the new escape codes or applications will not know about them. Compile the following with {{filename|tic}} and you can use "xterm-screen-256color" as your TERM:<br />
<br />
# A screen- based TERMINFO that declares the escape sequences<br />
# enabled by the tmux config "set-window-option -g xterm-keys".<br />
#<br />
# Prefix the name with xterm- since some applications inspect<br />
# the TERM *name* in addition to the terminal capabilities advertised.<br />
xterm-screen-256color|GNU Screen with 256 colors bce and tmux xterm-keys,<br />
<br />
# As of Nov'11, the below keys are picked up by<br />
# .../tmux/blob/master/trunk/xterm-keys.c:<br />
kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,<br />
kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,<br />
kRIT=\E[1;2C,<br />
<br />
# Change this to screen-256color if the terminal you run tmux in<br />
# doesn't support bce:<br />
use=screen-256color-bce,<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your {{Filename|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==ICCCM Selection Integration==<br />
It is possible to copy a tmux paste buffer to an ICCCM selection, and vice-versa, by defining a shell command which interfaces tmux with an X11 selection interface. The following tmux config file snippet effectively integrates {{Codeline|CLIPBOARD}} with the current tmux paste buffer using xclip:<br />
<br />
{{File|name=~/.tmux.conf|content=<br />
...<br />
##CLIPBOARD selection integration<br />
##Requires prefix key before the command key<br />
#Copy tmux paste buffer to CLIPBOARD<br />
bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"<br />
#Copy CLIPBOARD to tmux paste buffer and paste tmux paste buffer<br />
bind C-v run "tmux set-buffer \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"<br />
}}<br />
<br />
==Tips & Tricks==<br />
<br />
===Start tmux on every shell login===<br />
<br />
Simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, do not do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias sprunge="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable.}}<br />
<br />
This snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
# TMUX<br />
if which tmux 2>&1 >/dev/null; then<br />
# if no session is started, start a new session<br />
if test -z ${TMUX}; then<br />
tmux<br />
fi<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
<br />
{{note|Instead of using the bashrc file, you can launch tmux when you start your terminal emulator. (I. e: urxvt -e tmux)}}<br />
<br />
===Split window and retain current directory===<br />
<br />
====Fast method====<br />
<br />
{{Note|This trick tries to inject a key into your session, which only works if it is at a command prompt (i. e. fails within a program like vim, emacs, …).}}<br />
<br />
Create a excutable file as follows, for example {{Filename|~/.scripts/tmux-split}}:<br />
<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
<br />
bind v split-window -h<br />
bind n split-window -v<br />
<br />
to<br />
<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
<br />
====/proc method====<br />
<br />
{{Note|This script, [http://chneukirchen.org/dotfiles/bin/tmux-neww-in-cwd borrowed from] Christian Neukirchen, reads the present pane's CWD from {{Codeline|/proc/[pane's top program's $PID]/cwd}}. Some shells like zsh will not always properly update that entry.}}<br />
<br />
Pasted into e. g. {{Filename|~/.scripts/tmux-split-in-cwd}}:<br />
<br />
#!/bin/sh<br />
# tmux-split-in-cwd - open a new shell with same cwd as calling pane<br />
<br />
SIP=$(tmux display-message -p "#S:#I:#P")<br />
PTY=$(tmux server-info |<br />
egrep flags=\|bytes |<br />
awk '/windows/ { s = $2 }<br />
/references/ { i = $1 }<br />
/bytes/ { print s i $1 $2 } ' |<br />
grep "$SIP" |<br />
cut -d: -f4)<br />
PTS=${PTY#/dev/}<br />
PID=$(ps -eao pid,tty,command --forest | awk '$2 == "'$PTS'" {print $1; exit}')<br />
DIR=$(readlink /proc/$PID/cwd)<br />
<br />
case "$1" in<br />
h) tmux splitw -h "cd '$DIR'; $SHELL"<br />
;;<br />
v) tmux splitw -v "cd '$DIR'; $SHELL"<br />
;;<br />
*) tmux neww "cd '$DIR'; $SHELL"<br />
;;<br />
esac<br />
<br />
{{Filename|~/.tmux.conf}} could thus contain:<br />
<br />
bind | run '~/.scripts/tmux-split-in-cwd h' # horizontal split in cwd<br />
bind _ run '~/.scripts/tmux-split-in-cwd v' # vertical split in cwd<br />
bind m run '~/.scripts/tmux-split-in-cwd' # new window in cwd<br />
<br />
===Use tmux windows like tabs===<br />
<br />
The following settings added to {{Filename|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{Keypress|Ctrl}}+{{Keypress|d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
===Clients simultaneously interacting with various windows of a session===<br />
<br />
In “[http://mutelight.org/articles/practical-tmux Practical Tmux]”, Brandur Leach writes:<br />
<br />
{{Box||Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
<br />
This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
However, this usage of tmux results in the problem that detaching from these mirrored sessions will start to litter your system with defunct sessions which can only be cleaned up with some pretty extreme micromanagement.}}<br />
<br />
To avoid these issues he wrote the script “{{Codeline|tmx}}” — the version below is slightly modified to execute “{{Codeline|tmux new-window}}” if “1” is its second parameter. Invoked as {{Codeline|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise it will kill any “zombie” sessions, launch a new “client” session linked to the base, optionally add a new window and attach. Then it waits for detachment and kills its session.<br />
<br />
{{File|tmx|content=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
# Kill defunct sessions first<br />
old_sessions=$(tmux ls 2>/dev/null | egrep "^[0-9]{14}.*[0-9]+\)$" | cut -f 1 -d:)<br />
for old_session_id in $old_sessions; do<br />
tmux kill-session -t $old_session_id<br />
done<br />
<br />
echo "Launching copy of base session $base_session ..."<br />
# Session is is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session<br />
tmux attach-session -t $session_id<br />
# When we detach from it, kill the session<br />
tmux kill-session -t $session_id<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{Filename|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
===Changing the configuration with tmux started===<br />
<br />
By default tmux reads {{Filename|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{Filename|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
== See also ==<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux] by Brandur Leach, providing a number of configuration tips<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial] section from the OpenBSD FAQ<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison] page by Dayid Alan<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial] blog post by Jeff Story<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] & [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2] blog posts on Hawk Host<br />
<br />
'''Forum threads'''<br />
* 2009-11-06 - Arch Linux - [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Anyone loving Tmux in place of Screen? Info/Tips etc. URLs I've found]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Tmux&diff=170576Tmux2011-11-19T04:49:05Z<p>JaMeSiTeGeN: /* Start tmux on every shell login */</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Software (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article explains how to install and configure tmux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GNU Screen}}<br />
{{Article summary end}}<br />
<br />
[http://tmux.sourceforge.net/ Tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which has not had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in {{Codeline|/usr/share/tmux/}}. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' {{Codeline|Ctrl-b}}<br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type {{Codeline|Ctrl-b %}}.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. {{Codeline|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. {{Codeline|Ctrl-b}}) to {{Codeline|Ctrl-a}} by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
If you enable xterm-keys in your {{filename|tmux.conf}}, then you need to build a custom terminfo to declare the new escape codes or applications will not know about them. Compile the following with {{filename|tic}} and you can use "xterm-screen-256color" as your TERM:<br />
<br />
# A screen- based TERMINFO that declares the escape sequences<br />
# enabled by the tmux config "set-window-option -g xterm-keys".<br />
#<br />
# Prefix the name with xterm- since some applications inspect<br />
# the TERM *name* in addition to the terminal capabilities advertised.<br />
xterm-screen-256color|GNU Screen with 256 colors bce and tmux xterm-keys,<br />
<br />
# As of Nov'11, the below keys are picked up by<br />
# .../tmux/blob/master/trunk/xterm-keys.c:<br />
kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,<br />
kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,<br />
kRIT=\E[1;2C,<br />
<br />
# Change this to screen-256color if the terminal you run tmux in<br />
# doesn't support bce:<br />
use=screen-256color-bce,<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your {{Filename|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==ICCCM Selection Integration==<br />
It is possible to copy a tmux paste buffer to an ICCCM selection, and vice-versa, by defining a shell command which interfaces tmux with an X11 selection interface. The following tmux config file snippet effectively integrates {{Codeline|CLIPBOARD}} with the current tmux paste buffer using xclip:<br />
<br />
{{File|name=~/.tmux.conf|content=<br />
...<br />
##CLIPBOARD selection integration<br />
##Requires prefix key before the command key<br />
#Copy tmux paste buffer to CLIPBOARD<br />
bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"<br />
#Copy CLIPBOARD to tmux paste buffer and paste tmux paste buffer<br />
bind C-v run "tmux set-buffer \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"<br />
}}<br />
<br />
==Tips & Tricks==<br />
<br />
===Start tmux on every shell login===<br />
<br />
Simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, do not do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias sprunge="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable.}}<br />
<br />
This snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
# TMUX<br />
if which tmux 2>&1 >/dev/null; then<br />
# if no session is started, start a new session<br />
if test -z ${TMUX}; then<br />
tmux<br />
fi<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
<br />
{{note|Instead of using the bashrc file, you can launch tmux when you start your terminal emulator. I. e: urxvt -e tmux}}<br />
<br />
===Split window and retain current directory===<br />
<br />
====Fast method====<br />
<br />
{{Note|This trick tries to inject a key into your session, which only works if it is at a command prompt (i. e. fails within a program like vim, emacs, …).}}<br />
<br />
Create a excutable file as follows, for example {{Filename|~/.scripts/tmux-split}}:<br />
<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
<br />
bind v split-window -h<br />
bind n split-window -v<br />
<br />
to<br />
<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
<br />
====/proc method====<br />
<br />
{{Note|This script, [http://chneukirchen.org/dotfiles/bin/tmux-neww-in-cwd borrowed from] Christian Neukirchen, reads the present pane's CWD from {{Codeline|/proc/[pane's top program's $PID]/cwd}}. Some shells like zsh will not always properly update that entry.}}<br />
<br />
Pasted into e. g. {{Filename|~/.scripts/tmux-split-in-cwd}}:<br />
<br />
#!/bin/sh<br />
# tmux-split-in-cwd - open a new shell with same cwd as calling pane<br />
<br />
SIP=$(tmux display-message -p "#S:#I:#P")<br />
PTY=$(tmux server-info |<br />
egrep flags=\|bytes |<br />
awk '/windows/ { s = $2 }<br />
/references/ { i = $1 }<br />
/bytes/ { print s i $1 $2 } ' |<br />
grep "$SIP" |<br />
cut -d: -f4)<br />
PTS=${PTY#/dev/}<br />
PID=$(ps -eao pid,tty,command --forest | awk '$2 == "'$PTS'" {print $1; exit}')<br />
DIR=$(readlink /proc/$PID/cwd)<br />
<br />
case "$1" in<br />
h) tmux splitw -h "cd '$DIR'; $SHELL"<br />
;;<br />
v) tmux splitw -v "cd '$DIR'; $SHELL"<br />
;;<br />
*) tmux neww "cd '$DIR'; $SHELL"<br />
;;<br />
esac<br />
<br />
{{Filename|~/.tmux.conf}} could thus contain:<br />
<br />
bind | run '~/.scripts/tmux-split-in-cwd h' # horizontal split in cwd<br />
bind _ run '~/.scripts/tmux-split-in-cwd v' # vertical split in cwd<br />
bind m run '~/.scripts/tmux-split-in-cwd' # new window in cwd<br />
<br />
===Use tmux windows like tabs===<br />
<br />
The following settings added to {{Filename|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{Keypress|Ctrl}}+{{Keypress|d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
===Clients simultaneously interacting with various windows of a session===<br />
<br />
In “[http://mutelight.org/articles/practical-tmux Practical Tmux]”, Brandur Leach writes:<br />
<br />
{{Box||Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
<br />
This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
However, this usage of tmux results in the problem that detaching from these mirrored sessions will start to litter your system with defunct sessions which can only be cleaned up with some pretty extreme micromanagement.}}<br />
<br />
To avoid these issues he wrote the script “{{Codeline|tmx}}” — the version below is slightly modified to execute “{{Codeline|tmux new-window}}” if “1” is its second parameter. Invoked as {{Codeline|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise it will kill any “zombie” sessions, launch a new “client” session linked to the base, optionally add a new window and attach. Then it waits for detachment and kills its session.<br />
<br />
{{File|tmx|content=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
# Kill defunct sessions first<br />
old_sessions=$(tmux ls 2>/dev/null | egrep "^[0-9]{14}.*[0-9]+\)$" | cut -f 1 -d:)<br />
for old_session_id in $old_sessions; do<br />
tmux kill-session -t $old_session_id<br />
done<br />
<br />
echo "Launching copy of base session $base_session ..."<br />
# Session is is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session<br />
tmux attach-session -t $session_id<br />
# When we detach from it, kill the session<br />
tmux kill-session -t $session_id<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{Filename|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
===Changing the configuration with tmux started===<br />
<br />
By default tmux reads {{Filename|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{Filename|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
== See also ==<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux] by Brandur Leach, providing a number of configuration tips<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial] section from the OpenBSD FAQ<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison] page by Dayid Alan<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial] blog post by Jeff Story<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] & [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2] blog posts on Hawk Host<br />
<br />
'''Forum threads'''<br />
* 2009-11-06 - Arch Linux - [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Anyone loving Tmux in place of Screen? Info/Tips etc. URLs I've found]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Tmux&diff=170575Tmux2011-11-19T04:48:42Z<p>JaMeSiTeGeN: /* Start tmux on every shell login */</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Software (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article explains how to install and configure tmux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GNU Screen}}<br />
{{Article summary end}}<br />
<br />
[http://tmux.sourceforge.net/ Tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which has not had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in {{Codeline|/usr/share/tmux/}}. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' {{Codeline|Ctrl-b}}<br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type {{Codeline|Ctrl-b %}}.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. {{Codeline|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. {{Codeline|Ctrl-b}}) to {{Codeline|Ctrl-a}} by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
If you enable xterm-keys in your {{filename|tmux.conf}}, then you need to build a custom terminfo to declare the new escape codes or applications will not know about them. Compile the following with {{filename|tic}} and you can use "xterm-screen-256color" as your TERM:<br />
<br />
# A screen- based TERMINFO that declares the escape sequences<br />
# enabled by the tmux config "set-window-option -g xterm-keys".<br />
#<br />
# Prefix the name with xterm- since some applications inspect<br />
# the TERM *name* in addition to the terminal capabilities advertised.<br />
xterm-screen-256color|GNU Screen with 256 colors bce and tmux xterm-keys,<br />
<br />
# As of Nov'11, the below keys are picked up by<br />
# .../tmux/blob/master/trunk/xterm-keys.c:<br />
kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,<br />
kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,<br />
kRIT=\E[1;2C,<br />
<br />
# Change this to screen-256color if the terminal you run tmux in<br />
# doesn't support bce:<br />
use=screen-256color-bce,<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your {{Filename|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==ICCCM Selection Integration==<br />
It is possible to copy a tmux paste buffer to an ICCCM selection, and vice-versa, by defining a shell command which interfaces tmux with an X11 selection interface. The following tmux config file snippet effectively integrates {{Codeline|CLIPBOARD}} with the current tmux paste buffer using xclip:<br />
<br />
{{File|name=~/.tmux.conf|content=<br />
...<br />
##CLIPBOARD selection integration<br />
##Requires prefix key before the command key<br />
#Copy tmux paste buffer to CLIPBOARD<br />
bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"<br />
#Copy CLIPBOARD to tmux paste buffer and paste tmux paste buffer<br />
bind C-v run "tmux set-buffer \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"<br />
}}<br />
<br />
==Tips & Tricks==<br />
<br />
===Start tmux on every shell login===<br />
<br />
Simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, do not do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias sprunge="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable.}}<br />
<br />
This snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
# TMUX<br />
if which tmux 2>&1 >/dev/null; then<br />
# if no session is started, start a new session<br />
if test -z ${TMUX}; then<br />
tmux<br />
fi<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
<br />
{{note|Instead of using the bashrc file, you can launch tmux when you start your terminal emulator. Ie: urxvt -e tmux}}<br />
<br />
===Split window and retain current directory===<br />
<br />
====Fast method====<br />
<br />
{{Note|This trick tries to inject a key into your session, which only works if it is at a command prompt (i. e. fails within a program like vim, emacs, …).}}<br />
<br />
Create a excutable file as follows, for example {{Filename|~/.scripts/tmux-split}}:<br />
<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
<br />
bind v split-window -h<br />
bind n split-window -v<br />
<br />
to<br />
<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
<br />
====/proc method====<br />
<br />
{{Note|This script, [http://chneukirchen.org/dotfiles/bin/tmux-neww-in-cwd borrowed from] Christian Neukirchen, reads the present pane's CWD from {{Codeline|/proc/[pane's top program's $PID]/cwd}}. Some shells like zsh will not always properly update that entry.}}<br />
<br />
Pasted into e. g. {{Filename|~/.scripts/tmux-split-in-cwd}}:<br />
<br />
#!/bin/sh<br />
# tmux-split-in-cwd - open a new shell with same cwd as calling pane<br />
<br />
SIP=$(tmux display-message -p "#S:#I:#P")<br />
PTY=$(tmux server-info |<br />
egrep flags=\|bytes |<br />
awk '/windows/ { s = $2 }<br />
/references/ { i = $1 }<br />
/bytes/ { print s i $1 $2 } ' |<br />
grep "$SIP" |<br />
cut -d: -f4)<br />
PTS=${PTY#/dev/}<br />
PID=$(ps -eao pid,tty,command --forest | awk '$2 == "'$PTS'" {print $1; exit}')<br />
DIR=$(readlink /proc/$PID/cwd)<br />
<br />
case "$1" in<br />
h) tmux splitw -h "cd '$DIR'; $SHELL"<br />
;;<br />
v) tmux splitw -v "cd '$DIR'; $SHELL"<br />
;;<br />
*) tmux neww "cd '$DIR'; $SHELL"<br />
;;<br />
esac<br />
<br />
{{Filename|~/.tmux.conf}} could thus contain:<br />
<br />
bind | run '~/.scripts/tmux-split-in-cwd h' # horizontal split in cwd<br />
bind _ run '~/.scripts/tmux-split-in-cwd v' # vertical split in cwd<br />
bind m run '~/.scripts/tmux-split-in-cwd' # new window in cwd<br />
<br />
===Use tmux windows like tabs===<br />
<br />
The following settings added to {{Filename|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{Keypress|Ctrl}}+{{Keypress|d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
===Clients simultaneously interacting with various windows of a session===<br />
<br />
In “[http://mutelight.org/articles/practical-tmux Practical Tmux]”, Brandur Leach writes:<br />
<br />
{{Box||Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
<br />
This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
However, this usage of tmux results in the problem that detaching from these mirrored sessions will start to litter your system with defunct sessions which can only be cleaned up with some pretty extreme micromanagement.}}<br />
<br />
To avoid these issues he wrote the script “{{Codeline|tmx}}” — the version below is slightly modified to execute “{{Codeline|tmux new-window}}” if “1” is its second parameter. Invoked as {{Codeline|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise it will kill any “zombie” sessions, launch a new “client” session linked to the base, optionally add a new window and attach. Then it waits for detachment and kills its session.<br />
<br />
{{File|tmx|content=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
# Kill defunct sessions first<br />
old_sessions=$(tmux ls 2>/dev/null | egrep "^[0-9]{14}.*[0-9]+\)$" | cut -f 1 -d:)<br />
for old_session_id in $old_sessions; do<br />
tmux kill-session -t $old_session_id<br />
done<br />
<br />
echo "Launching copy of base session $base_session ..."<br />
# Session is is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session<br />
tmux attach-session -t $session_id<br />
# When we detach from it, kill the session<br />
tmux kill-session -t $session_id<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{Filename|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
===Changing the configuration with tmux started===<br />
<br />
By default tmux reads {{Filename|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{Filename|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
== See also ==<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux] by Brandur Leach, providing a number of configuration tips<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial] section from the OpenBSD FAQ<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison] page by Dayid Alan<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial] blog post by Jeff Story<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] & [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2] blog posts on Hawk Host<br />
<br />
'''Forum threads'''<br />
* 2009-11-06 - Arch Linux - [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Anyone loving Tmux in place of Screen? Info/Tips etc. URLs I've found]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Tmux&diff=170574Tmux2011-11-19T04:48:11Z<p>JaMeSiTeGeN: /* Start tmux on every shell login */</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Software (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article explains how to install and configure tmux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GNU Screen}}<br />
{{Article summary end}}<br />
<br />
[http://tmux.sourceforge.net/ Tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which has not had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in {{Codeline|/usr/share/tmux/}}. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' {{Codeline|Ctrl-b}}<br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type {{Codeline|Ctrl-b %}}.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. {{Codeline|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. {{Codeline|Ctrl-b}}) to {{Codeline|Ctrl-a}} by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
If you enable xterm-keys in your {{filename|tmux.conf}}, then you need to build a custom terminfo to declare the new escape codes or applications will not know about them. Compile the following with {{filename|tic}} and you can use "xterm-screen-256color" as your TERM:<br />
<br />
# A screen- based TERMINFO that declares the escape sequences<br />
# enabled by the tmux config "set-window-option -g xterm-keys".<br />
#<br />
# Prefix the name with xterm- since some applications inspect<br />
# the TERM *name* in addition to the terminal capabilities advertised.<br />
xterm-screen-256color|GNU Screen with 256 colors bce and tmux xterm-keys,<br />
<br />
# As of Nov'11, the below keys are picked up by<br />
# .../tmux/blob/master/trunk/xterm-keys.c:<br />
kDC=\E[3;2~, kEND=\E[1;2F, kHOM=\E[1;2H,<br />
kIC=\E[2;2~, kLFT=\E[1;2D, kNXT=\E[6;2~, kPRV=\E[5;2~,<br />
kRIT=\E[1;2C,<br />
<br />
# Change this to screen-256color if the terminal you run tmux in<br />
# doesn't support bce:<br />
use=screen-256color-bce,<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your {{Filename|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==ICCCM Selection Integration==<br />
It is possible to copy a tmux paste buffer to an ICCCM selection, and vice-versa, by defining a shell command which interfaces tmux with an X11 selection interface. The following tmux config file snippet effectively integrates {{Codeline|CLIPBOARD}} with the current tmux paste buffer using xclip:<br />
<br />
{{File|name=~/.tmux.conf|content=<br />
...<br />
##CLIPBOARD selection integration<br />
##Requires prefix key before the command key<br />
#Copy tmux paste buffer to CLIPBOARD<br />
bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"<br />
#Copy CLIPBOARD to tmux paste buffer and paste tmux paste buffer<br />
bind C-v run "tmux set-buffer \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"<br />
}}<br />
<br />
==Tips & Tricks==<br />
<br />
===Start tmux on every shell login===<br />
<br />
Simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, do not do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias sprunge="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable.}}<br />
<br />
This snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
# TMUX<br />
if which tmux 2>&1 >/dev/null; then<br />
# if no session is started, start a new session<br />
if test -z ${TMUX}; then<br />
tmux<br />
fi<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
<br />
{{note|Instead of using the bashrc file, you can launch tmux stright from your terminal emulator. Ie: urxvt -e tmux}}<br />
<br />
===Split window and retain current directory===<br />
<br />
====Fast method====<br />
<br />
{{Note|This trick tries to inject a key into your session, which only works if it is at a command prompt (i. e. fails within a program like vim, emacs, …).}}<br />
<br />
Create a excutable file as follows, for example {{Filename|~/.scripts/tmux-split}}:<br />
<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
<br />
bind v split-window -h<br />
bind n split-window -v<br />
<br />
to<br />
<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
<br />
====/proc method====<br />
<br />
{{Note|This script, [http://chneukirchen.org/dotfiles/bin/tmux-neww-in-cwd borrowed from] Christian Neukirchen, reads the present pane's CWD from {{Codeline|/proc/[pane's top program's $PID]/cwd}}. Some shells like zsh will not always properly update that entry.}}<br />
<br />
Pasted into e. g. {{Filename|~/.scripts/tmux-split-in-cwd}}:<br />
<br />
#!/bin/sh<br />
# tmux-split-in-cwd - open a new shell with same cwd as calling pane<br />
<br />
SIP=$(tmux display-message -p "#S:#I:#P")<br />
PTY=$(tmux server-info |<br />
egrep flags=\|bytes |<br />
awk '/windows/ { s = $2 }<br />
/references/ { i = $1 }<br />
/bytes/ { print s i $1 $2 } ' |<br />
grep "$SIP" |<br />
cut -d: -f4)<br />
PTS=${PTY#/dev/}<br />
PID=$(ps -eao pid,tty,command --forest | awk '$2 == "'$PTS'" {print $1; exit}')<br />
DIR=$(readlink /proc/$PID/cwd)<br />
<br />
case "$1" in<br />
h) tmux splitw -h "cd '$DIR'; $SHELL"<br />
;;<br />
v) tmux splitw -v "cd '$DIR'; $SHELL"<br />
;;<br />
*) tmux neww "cd '$DIR'; $SHELL"<br />
;;<br />
esac<br />
<br />
{{Filename|~/.tmux.conf}} could thus contain:<br />
<br />
bind | run '~/.scripts/tmux-split-in-cwd h' # horizontal split in cwd<br />
bind _ run '~/.scripts/tmux-split-in-cwd v' # vertical split in cwd<br />
bind m run '~/.scripts/tmux-split-in-cwd' # new window in cwd<br />
<br />
===Use tmux windows like tabs===<br />
<br />
The following settings added to {{Filename|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{Keypress|Ctrl}}+{{Keypress|d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
===Clients simultaneously interacting with various windows of a session===<br />
<br />
In “[http://mutelight.org/articles/practical-tmux Practical Tmux]”, Brandur Leach writes:<br />
<br />
{{Box||Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
<br />
This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
However, this usage of tmux results in the problem that detaching from these mirrored sessions will start to litter your system with defunct sessions which can only be cleaned up with some pretty extreme micromanagement.}}<br />
<br />
To avoid these issues he wrote the script “{{Codeline|tmx}}” — the version below is slightly modified to execute “{{Codeline|tmux new-window}}” if “1” is its second parameter. Invoked as {{Codeline|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise it will kill any “zombie” sessions, launch a new “client” session linked to the base, optionally add a new window and attach. Then it waits for detachment and kills its session.<br />
<br />
{{File|tmx|content=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
# Kill defunct sessions first<br />
old_sessions=$(tmux ls 2>/dev/null | egrep "^[0-9]{14}.*[0-9]+\)$" | cut -f 1 -d:)<br />
for old_session_id in $old_sessions; do<br />
tmux kill-session -t $old_session_id<br />
done<br />
<br />
echo "Launching copy of base session $base_session ..."<br />
# Session is is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session<br />
tmux attach-session -t $session_id<br />
# When we detach from it, kill the session<br />
tmux kill-session -t $session_id<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{Filename|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
===Changing the configuration with tmux started===<br />
<br />
By default tmux reads {{Filename|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{Filename|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
== See also ==<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux] by Brandur Leach, providing a number of configuration tips<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial] section from the OpenBSD FAQ<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison] page by Dayid Alan<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial] blog post by Jeff Story<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] & [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2] blog posts on Hawk Host<br />
<br />
'''Forum threads'''<br />
* 2009-11-06 - Arch Linux - [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Anyone loving Tmux in place of Screen? Info/Tips etc. URLs I've found]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Tmux&diff=170458Tmux2011-11-18T08:34:44Z<p>JaMeSiTeGeN: /* Start tmux on every shell login */</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Software (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|This article explains how to install and configure tmux.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|GNU Screen}}<br />
{{Article summary end}}<br />
<br />
[http://tmux.sourceforge.net/ Tmux] is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." <br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which has not had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in {{Codeline|/usr/share/tmux/}}. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' {{Codeline|Ctrl-b}}<br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type {{Codeline|Ctrl-b %}}.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. {{Codeline|Ctrl-b}}) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. {{Codeline|Ctrl-b}}) to {{Codeline|Ctrl-a}} by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your {{Filename|~/.tmux.conf}}:<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==ICCCM Selection Integration==<br />
It is possible to copy a tmux paste buffer to an ICCCM selection, and vice-versa, by defining a shell command which interfaces tmux with an X11 selection interface. The following tmux config file snippet effectively integrates {{Codeline|CLIPBOARD}} with the current tmux paste buffer using xclip:<br />
<br />
{{File|name=~/.tmux.conf|content=<br />
...<br />
##CLIPBOARD selection integration<br />
##Requires prefix key before the command key<br />
#Copy tmux paste buffer to CLIPBOARD<br />
bind C-c run "tmux show-buffer <nowiki>|</nowiki> xclip -i -selection clipboard"<br />
#Copy CLIPBOARD to tmux paste buffer and paste tmux paste buffer<br />
bind C-v run "tmux set-buffer \"$(xclip -o -selection clipboard)\"; tmux paste-buffer"<br />
}}<br />
<br />
==Tips & Tricks==<br />
<br />
===Start tmux on every shell login===<br />
<br />
Simply add the following line of bash code to your .bashrc before your aliases; the code for other shells is very similar:<br />
<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, do not do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias sprunge="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable.}}<br />
<br />
This snippet does the same thing, but also checks tmux is installed before trying to launch it. It also tries to reattach you to an existing tmux session at logout, so that you can shut down every tmux session quickly from the same terminal at logout.<br />
# TMUX<br />
if which tmux 2>&1 >/dev/null; then<br />
# if no session is started, start a new session<br />
if test -z ${TMUX}; then<br />
tmux<br />
fi<br />
# when quitting tmux, try to attach<br />
while test -z ${TMUX}; do<br />
tmux attach || break<br />
done<br />
fi<br />
<br />
===Split window and retain current directory===<br />
<br />
====Fast method====<br />
<br />
{{Note|This trick tries to inject a key into your session, which only works if it is at a command prompt (i. e. fails within a program like vim, emacs, …).}}<br />
<br />
Create a excutable file as follows, for example {{Filename|~/.scripts/tmux-split}}:<br />
<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
<br />
bind v split-window -h<br />
bind n split-window -v<br />
<br />
to<br />
<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
<br />
====/proc method====<br />
<br />
{{Note|This script, [http://chneukirchen.org/dotfiles/bin/tmux-neww-in-cwd borrowed from] Christian Neukirchen, reads the present pane's CWD from {{Codeline|/proc/[pane's top program's $PID]/cwd}}. Some shells like zsh will not always properly update that entry.}}<br />
<br />
Pasted into e. g. {{Filename|~/.scripts/tmux-split-in-cwd}}:<br />
<br />
#!/bin/sh<br />
# tmux-split-in-cwd - open a new shell with same cwd as calling pane<br />
<br />
SIP=$(tmux display-message -p "#S:#I:#P")<br />
PTY=$(tmux server-info |<br />
egrep flags=\|bytes |<br />
awk '/windows/ { s = $2 }<br />
/references/ { i = $1 }<br />
/bytes/ { print s i $1 $2 } ' |<br />
grep "$SIP" |<br />
cut -d: -f4)<br />
PTS=${PTY#/dev/}<br />
PID=$(ps -eao pid,tty,command --forest | awk '$2 == "'$PTS'" {print $1; exit}')<br />
DIR=$(readlink /proc/$PID/cwd)<br />
<br />
case "$1" in<br />
h) tmux splitw -h "cd '$DIR'; $SHELL"<br />
;;<br />
v) tmux splitw -v "cd '$DIR'; $SHELL"<br />
;;<br />
*) tmux neww "cd '$DIR'; $SHELL"<br />
;;<br />
esac<br />
<br />
{{Filename|~/.tmux.conf}} could thus contain:<br />
<br />
bind | run '~/.scripts/tmux-split-in-cwd h' # horizontal split in cwd<br />
bind _ run '~/.scripts/tmux-split-in-cwd v' # vertical split in cwd<br />
bind m run '~/.scripts/tmux-split-in-cwd' # new window in cwd<br />
<br />
===Use tmux windows like tabs===<br />
<br />
The following settings added to {{Filename|~/.tmux.conf}} allow to use tmux windows like tabs, such as those provided by the reference of these hotkeys — [[rxvt-unicode#urxvtq_with_tabbing|urxvt's tabbing extensions]]. An advantage thereof is that these virtual “tabs” are independent of the terminal emulator.<br />
<br />
#urxvt tab like window switching (-n: no prior escape seq)<br />
bind -n S-down new-window<br />
bind -n S-left prev<br />
bind -n S-right next<br />
bind -n C-left swap-window -t -1<br />
bind -n C-right swap-window -t +1<br />
<br />
Of course, those should not overlap with other applications' hotkeys, such as the terminal's. Given that they substitute terminal tabbing that might as well be deactivated, though.<br />
<br />
It can also come handy to supplement the EOT hotkey {{Keypress|Ctrl}}+{{Keypress|d}} with one for tmux's detach:<br />
<br />
bind-key -n C-j detach<br />
<br />
===Clients simultaneously interacting with various windows of a session===<br />
<br />
In “[http://mutelight.org/articles/practical-tmux Practical Tmux]”, Brandur Leach writes:<br />
<br />
{{Box||Screen and tmux's behaviour for when multiple clients are attached to one session differs slightly. In Screen, each client can be connected to the session but view different windows within it, but in tmux, all clients connected to one session must view the same window.<br />
<br />
This problem can be solved in tmux by spawning two separate sessions and synchronizing the second one to the windows of the first, then pointing a second new session to the first.<br />
<br />
However, this usage of tmux results in the problem that detaching from these mirrored sessions will start to litter your system with defunct sessions which can only be cleaned up with some pretty extreme micromanagement.}}<br />
<br />
To avoid these issues he wrote the script “{{Codeline|tmx}}” — the version below is slightly modified to execute “{{Codeline|tmux new-window}}” if “1” is its second parameter. Invoked as {{Codeline|tmx <base session name> [1]}} it launches the base session if necessary. Otherwise it will kill any “zombie” sessions, launch a new “client” session linked to the base, optionally add a new window and attach. Then it waits for detachment and kills its session.<br />
<br />
{{File|tmx|content=<nowiki><br />
#!/bin/bash<br />
<br />
#<br />
# Modified TMUX start script from:<br />
# http://forums.gentoo.org/viewtopic-t-836006-start-0.html<br />
#<br />
# Store it to `~/bin/tmx` and issue `chmod +x`.<br />
#<br />
<br />
# Works because bash automatically trims by assigning to variables and by <br />
# passing arguments<br />
trim() { echo $1; }<br />
<br />
if [[ -z "$1" ]]; then<br />
echo "Specify session name as the first argument"<br />
exit<br />
fi<br />
<br />
# Only because I often issue `ls` to this script by accident<br />
if [[ "$1" == "ls" ]]; then<br />
tmux ls<br />
exit<br />
fi<br />
<br />
base_session="$1"<br />
# This actually works without the trim() on all systems except OSX<br />
tmux_nb=$(trim `tmux ls | grep "^$base_session" | wc -l`)<br />
if [[ "$tmux_nb" == "0" ]]; then<br />
echo "Launching tmux base session $base_session ..."<br />
tmux new-session -s $base_session<br />
else<br />
# Make sure we are not already in a tmux session<br />
if [[ -z "$TMUX" ]]; then<br />
# Kill defunct sessions first<br />
old_sessions=$(tmux ls 2>/dev/null | egrep "^[0-9]{14}.*[0-9]+\)$" | cut -f 1 -d:)<br />
for old_session_id in $old_sessions; do<br />
tmux kill-session -t $old_session_id<br />
done<br />
<br />
echo "Launching copy of base session $base_session ..."<br />
# Session is is date and time to prevent conflict<br />
session_id=`date +%Y%m%d%H%M%S`<br />
# Create a new session (without attaching it) and link to base session <br />
# to share windows<br />
tmux new-session -d -t $base_session -s $session_id<br />
if [[ "$2" == "1" ]]; then<br />
# Create a new window in that session<br />
tmux new-window<br />
fi<br />
# Attach to the new session<br />
tmux attach-session -t $session_id<br />
# When we detach from it, kill the session<br />
tmux kill-session -t $session_id<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
A useful setting for this is<br />
<br />
setw -g aggressive-resize on<br />
<br />
added to {{Filename|~/.tmux.conf}}. It causes tmux to resize a window based on the smallest client actually viewing it, not on the smallest one attached to the entire session.<br />
<br />
===Changing the configuration with tmux started===<br />
<br />
By default tmux reads {{Filename|~/.tmux.conf}} only if it was not already running. To have tmux load a configuration file afterwards, execute:<br />
<br />
tmux source-file <path><br />
<br />
This can be added to {{Filename|~/.tmux.conf}} as e. g.:<br />
<br />
bind r source-file <path><br />
<br />
== See also ==<br />
* [http://mutelight.org/articles/practical-tmux Practical Tmux] by Brandur Leach, providing a number of configuration tips<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial] section from the OpenBSD FAQ<br />
* [http://www.dayid.org/os/notes/tm.html Screen and tmux feature comparison] page by Dayid Alan<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial] blog post by Jeff Story<br />
* [http://blog.hawkhost.com/2010/06/28/tmux-the-terminal-multiplexer/ Tmux tutorial Part 1] & [http://blog.hawkhost.com/2010/07/02/tmux-%E2%80%93-the-terminal-multiplexer-part-2 Part 2] blog posts on Hawk Host<br />
<br />
'''Forum threads'''<br />
* 2009-11-06 - Arch Linux - [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Anyone loving Tmux in place of Screen? Info/Tips etc. URLs I've found]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Tmux&diff=148893Tmux2011-07-12T07:50:04Z<p>JaMeSiTeGeN: /* Tips & tricks! */</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Utilities (English)]]<br />
Tmux is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." [http://tmux.sourceforge.net/]<br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which hasn't had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in <tt>/usr/share/tmux/</tt>. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' <tt>Ctrl-b</tt><br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type <tt>Ctrl-b %</tt>.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. <tt>Ctrl-b</tt>) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. <tt>Ctrl-b</tt>) to <tt>Ctrl-a</tt> by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your .tmux.conf<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==Split window and remain current directory==<br />
Create a excutable file as follows, for example ~/mbin/split-tmux:<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
bind v split-window -h<br />
bind n split-window -v<br />
to<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
(However, this trick doesn't work when you are using vim.)<br />
<br />
==Tips & tricks!==<br />
To start tmux when you login to a standard terminal, simply add the following line of bash code to your .bashrc before your aliases..<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, don't do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
alias nopaste="curl -F 'sprunge=<-' http://sprunge.us"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable..}}<br />
<br />
==See also==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Tmux topic on Arch forums]<br />
* [[Screen|GNU Screen]]<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial from OpenBSD FAQ]<br />
* [http://www.dayid.org/os/notes/tm.html Tmux/Screen cheat sheet]<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Tmux&diff=148085Tmux2011-07-03T06:14:00Z<p>JaMeSiTeGeN: /* Tips & tricks! */</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Utilities (English)]]<br />
Tmux is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." [http://tmux.sourceforge.net/]<br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which hasn't had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in <tt>/usr/share/tmux/</tt>. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' <tt>Ctrl-b</tt><br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type <tt>Ctrl-b %</tt>.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. <tt>Ctrl-b</tt>) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. <tt>Ctrl-b</tt>) to <tt>Ctrl-a</tt> by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your .tmux.conf<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==Split window and remain current directory==<br />
Create a excutable file as follows, for example ~/mbin/split-tmux:<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
bind v split-window -h<br />
bind n split-window -v<br />
to<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
(However, this trick doesn't work when you are using vim.)<br />
<br />
==Tips & tricks!==<br />
To start tmux when you login to a standard terminal, simply add the following line of bash code to your .bashrc before your aliases..<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
Example .bashrc:<br />
#<br />
# ~/.bashrc<br />
#<br />
<br />
# If not running interactively, don't do anything<br />
&#91;&#91; $- != *i* &#93;&#93; && return<br />
&#91;&#91; $TERM != "screen" &#93;&#93; && tmux && exit<br />
<br />
# Irrelevant from here on, but does show that things here are working from within tmux..<br />
alias svile="sudo vile"<br />
alias updatedb="sudo updatedb"<br />
pacman() {<br />
case $1 in<br />
-S | -S[^sih]* | -R* | -U*)<br />
/usr/bin/sudo /usr/bin/pacman-color "$@" ;;<br />
*) /usr/bin/pacman-color "$@" ;;<br />
esac<br />
}<br />
<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable..}}<br />
<br />
==See also==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Tmux topic on Arch forums]<br />
* [[Screen|GNU Screen]]<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial from OpenBSD FAQ]<br />
* [http://www.dayid.org/os/notes/tm.html Tmux/Screen cheat sheet]<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Tmux&diff=148084Tmux2011-07-03T06:01:40Z<p>JaMeSiTeGeN: /* See also */</p>
<hr />
<div>{{i18n|Tmux}}<br />
[[Category:Utilities (English)]]<br />
Tmux is a "terminal multiplexer: it enables a number of terminals (or windows), each running a separate program, to be created, accessed, and controlled from a single screen. tmux may be detached from a screen and continue running in the background, then later reattached." [http://tmux.sourceforge.net/]<br />
<br />
Tmux is notable as a BSD-licensed alternative to [[Screen Tips|GNU Screen]]. Although similar, there are many differences between the programs, as noted on the [http://tmux.svn.sourceforge.net/viewvc/tmux/trunk/FAQ tmux FAQ page]. Most notably, tmux is currently under active development, in contrast to screen, which hasn't had a stable release since August 8, 2008.<br />
<br />
==Install==<br />
A stable version of tmux may be installed using [[pacman]]:<br />
# pacman -S tmux<br />
Alternatively, [https://aur.archlinux.org/packages.php?ID=35618 tmux-git] is available from the [[AUR]].<br />
<br />
==Configure==<br />
A user-specific configuration file should be located at {{filename|~/.tmux.conf}}, while a global configuration file should be located at {{filename|/etc/tmux.conf}}. Default configuration files can be found in <tt>/usr/share/tmux/</tt>. <br />
<br />
===Key bindings===<br />
{| style="float:right;border:1px #cccccc solid;margin:5px;padding:5px;width:200px;"<br />
|+ ''Prefix all commands with'' <tt>Ctrl-b</tt><br />
!Cmd<br />
!Action<br />
|-<br />
|c<br />
|Create a new window<br />
|-<br />
|n<br />
|Change to next window<br />
|-<br />
|p<br />
|Change to previous window<br />
|-<br />
|"<br />
|Split pane horizontally<br />
|-<br />
|%<br />
|Split pane vertically<br />
|-<br />
|,<br />
|Rename current window<br />
|-<br />
|o<br />
|Move to next pane<br />
|}<br />
<br />
By default, command key bindings are prefixed by Ctrl-b. For example, to vertically split a window type <tt>Ctrl-b %</tt>.<br />
<br />
After splitting a window into multiple panes, you can resize a pane by the hitting prefix key (i.e. <tt>Ctrl-b</tt>) and, while continuing to hold Ctrl, press Left/Right/Up/Down. Swapping panes is achieved in the same manner, but by hitting ''o'' instead of a directional key.<br />
<br />
{{Tip|To mimic screen key bindings copy {{filename|/usr/share/tmux/screen-keys.conf}} to either of the configuration locations.}}<br />
<br />
Key bindings may be changed with the bind and unbind commands in {{filename|tmux.conf}}. For example, you can change the prefix key (i.e. <tt>Ctrl-b</tt>) to <tt>Ctrl-a</tt> by adding the following commands in your configuration file:<br />
unbind C-b<br />
set -g prefix C-a<br />
<br />
Additional ways to move between windows include:<br />
Ctrl-b l (Move to the previously selected window)<br />
Ctrl-b w (List all windows / window numbers)<br />
Ctrl-b <window number> (Move to the specified window number, the default bindings are from 0 – 9)<br />
Ctrl-b q (Show pane numbers, when the numbers show up type the key to goto that pane)<br />
<br />
What if you have 10+ windows open? Tmux has a find-window option & keybinding. <br />
Ctrl-b f <window name> (Search for window name)<br />
Ctrl-b w (Select from interactive list of windows)<br />
<br />
===Browsing URL's===<br />
To browse URL's inside tmux you must have urlview installed and configured:<br />
bind-key u capture-pane \; save-buffer /tmp/tmux-buffer \; run-shell "$TERMINAL -e 'cat /tmp/tmux-buffer | urlview'"<br />
<br />
=== Setting the correct term===<br />
If you are using a 256 colour terminal, you will need to set the correct term in tmux. You can do this in either the {{filename|tmux.conf}}:<br />
<br />
set -g default-terminal "screen-256color" <br />
<br />
or in your {{filename|.bashrc}} with a test like:<br />
<br />
# for tmux: export 256color<br />
[ -n "$TMUX" ] && export TERM=screen-256color<br />
<br />
==Session initialization==<br />
You can have tmux open a session with preloaded windows by including those details in your .tmux.conf<br />
<br />
new -n WindowName Command<br />
neww -n WindowName Command<br />
neww -n WindowName Command<br />
<br />
To start a session with split windows (multiple panes), include the splitw command below the neww you would like to split; thus:<br />
<br />
new -s SessionName -n WindowName Command<br />
neww -n foo/bar foo<br />
splitw -v -p 50 -t 0 bar<br />
selectw -t 1 <br />
selectp -t 0<br />
<br />
would open 2 windows, the second of which would be named foo/bar and would be split vertically in half (50%) with foo running above bar. Focus would be in window 2 (foo/bar), top pane (foo).<br />
<br />
{{Note|Numbering for sessions, windows and panes starts at zero, unless you have specified a base-index of 1 in your {{filename|.conf}} }}<br />
<br />
To manage multiple sessions, source separate session files from your conf file:<br />
<br />
# initialize sessions<br />
bind F source-file ~/.tmux/foo<br />
bind B source-file ~/.tmux/bar<br />
<br />
==Scrolling issues==<br />
If you have issues scrolling with Shift-PageUp/Shift-PageDown in your terminal, try this:<br />
<br />
set -g terminal-overrides 'xterm*:smcup@:rmcup@'<br />
<br />
==Split window and remain current directory==<br />
Create a excutable file as follows, for example ~/mbin/split-tmux:<br />
#!/usr/bin/env bash<br />
PWD=`pwd`<br />
tmux split-window $1<br />
tmux send-keys " cd $PWD;clear"<br />
tmux send-keys "Enter"<br />
<br />
and change the configure from:<br />
bind v split-window -h<br />
bind n split-window -v<br />
to<br />
bind v send-keys " ~/mbin/split-tmux -h" \; send-keys "Enter"<br />
bind n send-keys " ~/mbin/split-tmux -v" \; send-keys "Enter"<br />
(However, this trick doesn't work when you are using vim.)<br />
<br />
==Tips & tricks!==<br />
Say you want to just login to getty or you open any standard terminal and you always type in "tmux", if you just add tmux to your .bashrc file, then you will also be greeted with an error message, to prevent this we simply put it in an if to see that we are not already in a tmux session.. ( also disables tmux from starting in a screen session )<br />
echo 'if &#91;&#91; $TERM != "screen" &#93;&#93;;then tmux;fi'>>.bashrc<br />
{{note|At first you may read screen as if we were using screen and not tmux, but tmux also uses screen for the TERM enviroment variable..}}<br />
<br />
==See also==<br />
<br />
* [https://bbs.archlinux.org/viewtopic.php?id=84157&p=1 Tmux topic on Arch forums]<br />
* [[Screen|GNU Screen]]<br />
* [http://www.openbsd.org/faq/faq7.html#tmux Tmux tutorial from OpenBSD FAQ]<br />
* [http://www.dayid.org/os/notes/tm.html Tmux/Screen cheat sheet]<br />
* [http://www.jeffstory.org/wordpress/?p=132 Tmux tutorial]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=AUR_helpers&diff=147362AUR helpers2011-06-26T11:40:11Z<p>JaMeSiTeGeN: /* cower */</p>
<hr />
<div>[[Category:Utilities (English)]]<br />
[[Category:AUR (English)]]<br />
[[Category:Package management (English)]]<br />
This is a list of helper utilities that search and/or build packages from the [[Arch User Repository]].<br />
<br />
{{Warning|None of these tools are officially supported by Arch devs. See [https://bbs.archlinux.org/viewtopic.php?pid&#61;828254#p828254].}}<br />
<br />
A list of graphical pacman front-ends, some of which also work with the AUR, may be found at [[pacman GUI Frontends]].<br />
<br />
== List of Helpers ==<br />
=== aurbuild ===<br />
<br />
aurbuild is a tool to download and build packages from the AUR.<br />
<br />
*Website: http://aurbuild.berlios.de/<br />
*Package: http://aur.archlinux.org/packages.php?ID=1775<br />
<br />
=== aurget ===<br />
<br />
Aurget aims to be a simple, pacman-like interface to the AUR. It tries to make the AUR convenient; whether the user wishes to find, download, build, install, or update AUR packages quickly. Aurget does not wrap any pure pacman commands, this is by design.<br />
<br />
*Website: http://pbrisbin.com/posts/aurget/<br />
*Package: http://aur.archlinux.org/packages.php?ID=31933<br />
<br />
=== aurora ===<br />
<br />
Aurora is a very simple frontend for the AUR written in python3. It allows the user to install AUR packages, download the AUR packages (for manual installation) and also offers an AUR upgrade feature. By design, aurora does not wrap pacman.<br />
<br />
*Website: http://bitbucket.org/bbenne10/aurora<br />
*Package: http://aur.archlinux.org/packages.php?ID=41732<br />
<br />
=== aurpac ===<br />
<br />
Light'n'fast AUR and pacman frontend.<br />
<br />
*Website: http://3ed.jogger.pl/2009/02/15/aurpac/<br />
*Package: http://aur.archlinux.org/packages.php?ID=23919<br />
<br />
=== aurploader ===<br />
<br />
Aurploader prompts the user for an AUR username and password and will then upload PKGBUILD tarballs to the AUR. Before uploading each package, the user is prompted to select a category. When the uploads have completed, the user is asked if the cookie file should be kept so that the script can be run again without needing the AUR username and password to be re-entered.<br />
<br />
*Website: http://xyne.archlinux.ca/info/aurploader<br />
*Package: http://aur.archlinux.org/packages.php?ID=23393<br />
<br />
=== aursh ===<br />
<br />
AurShell is a shell like application written in Python. With plugins included, it's possible to build and install packages from AUR, ABS, and even wrap pacman.<br />
<br />
*Website: http://github.com/husio/aursh/<br />
*Package: http://aur.archlinux.org/packages.php?ID=33423<br />
<br />
=== autoaur ===<br />
<br />
autoaur is a script for automatic mass downloading, updating, building, and installing groups of AUR packages.<br />
<br />
*Website: http://wiki.archlinux.org/index.php/autoaur<br />
*Package: http://aur.archlinux.org/packages.php?ID=6390<br />
<br />
=== burp ===<br />
<br />
burp is a fast and simple AUR uploader written in C. Supports persistent cookies for seamless logins.<br />
<br />
*Website: http://github.com/falconindy/burp<br />
*Package: http://aur.archlinux.org/packages.php?ID=37216<br />
<br />
=== clyde ===<br />
<br />
[[Clyde]] is a next-generation libalpm/makepkg wrapper with AUR support, multithreaded downloading, and colorized output.<br />
<br />
* Website: https://github.com/Kiwi/clyde<br />
* Forum: http://bbs.archlinux.org/viewtopic.php?id=91860<br />
* Package: http://aur.archlinux.org/packages.php?ID=34686<br />
<br />
=== cower ===<br />
<br />
Cower is a fast and simple AUR search and download agent, which will also check for updates and download dependencies. Written in C.<br />
<br />
*Website: http://github.com/falconindy/cower<br />
*Forum: https://bbs.archlinux.org/viewtopic.php?id=97137<br />
*Package: http://aur.archlinux.org/packages.php?ID=44921<br />
<br />
=== Meat ( Alpha / Under development ) ===<br />
<br />
Meat is a front-end for cower ( see above ) and it is fully written in bash, and developed by e36freak.<br />
<br />
*Website: http://github.com/e36freak/meat<br />
*Package: https://aur.archlinux.org/packages.php?ID=50075<br />
<br />
=== haskell-archlinux ===<br />
<br />
haskell-archlinux is a library to programmatically access the AUR and package metadata from the Haskell programming language.<br />
<br />
*Website: http://hackage.haskell.org/package/archlinux<br />
*Package: http://aur.archlinux.org/packages.php?ID=29267<br />
<br />
=== makeaur ===<br />
<br />
Makeaur is a wrapper for pacman and makepkg that allows users to easily install packages from the Arch User Repository.<br />
<br />
*Website: http://github.com/ghost1227/makeaur/<br />
*Package: http://aur.archlinux.org/packages.php?ID=23678<br />
<br />
=== pacaur ===<br />
Pacaur is a simple wrapper to fetch PKGBUILDS from aur & abs, using [[AUR_Helpers#cower|cower]] as backend. It aims on speed and simplicity, with a fast workflow and an uncluttered interface. It is inspired by [[AUR_Helpers#pbfetch|pbfetch]].<br />
<br />
* Website: https://github.com/Spyhawk/pacaur<br />
* Forum: https://bbs.archlinux.org/viewtopic.php?pid=937423<br />
* Package: https://aur.archlinux.org/packages.php?ID=49145<br />
<br />
=== packer ===<br />
<br />
Packer is a bash wrapper for pacman and the AUR. It was designed to be a simple and very fast replacement for the basic functionality of Yaourt. It has commands to install, update, search, and show information for any package in the main repositories and in the AUR. Use pacman for other commands, such as removing a package. It is fully functional.<br />
<br />
* Website: http://github.com/bruenig/packer<br />
* Forum: http://bbs.archlinux.org/viewtopic.php?id=88115<br />
* Package: http://aur.archlinux.org/packages.php?ID=33378<br />
* Wiki: https://github.com/bruenig/packer/wiki<br />
<br />
=== pacmoon ===<br />
<br />
pacmoon is a script for compiling arch linux packages from the AUR and repositories. It can automatically install make dependencies as binaries when necessary and update the entire system or just packages listed. It keeps track of which files have been compiled so that in the event of compiled packages getting replaced with a binary (like during an upgrade process) then pacmoon can recompile only the necessary packages.<br />
<br />
*Website: http://chilon.net/pacmoon<br />
*Package: http://aur.archlinux.org/packages.php?ID=41911<br />
<br />
=== paktahn ===<br />
<br />
Paktahn is a yaourt replacement written from the ground-up using Lisp. It is under active development and already includes improvements such as a local cache for fast searches and interactive installation.<br />
<br />
* Website: http://github.com/skypher/paktahn<br />
* Forum: http://bbs.archlinux.org/viewtopic.php?id=77674&p=1<br />
* Package: http://aur.archlinux.org/packages.php?ID=30242<br />
<br />
=== pbfetch ===<br />
<br />
Pbfetch is a script which can be used as a pacman-independent AUR helper or a pacman wrapper with additional AUR functionality. Pbfetch aims to be a simple and fast versus the well established yaourt.<br />
Pbfetch can be used as a shortcut to simply download PKGBUILDs from AUR or automatically build with dependency resolution among other things. The user can select which AUR packages to upgrade using a simple menu as well as update all AUR packages.<br />
<br />
*Website/Source: https://github.com/dalingrin/pbfetch<br />
*Forum: https://bbs.archlinux.org/viewtopic.php?id=87789<br />
*Package: http://aur.archlinux.org/packages.php?ID=33256<br />
<br />
=== pbget ===<br />
<br />
Pbget is a simple command-line tool for retrieving PKGBUILDs and local source files for Arch Linux. It is able to retrieve files from the official SVN and CVS web interface, the AUR and the ABS rsync server.<br />
<br />
*Website: http://xyne.archlinux.ca/info/pbget<br />
*Package: http://aur.archlinux.org/packages.php?ID=23848<br />
<br />
=== pkgman ===<br />
<br />
pkgman is a bash script which helps to manage a local repository. It retrieves the PKGBUILD and related files for given name from ABS or AUR and lets you edit them, automatically generates checksums, backs up the source tarball, builds and adds the package to your local repository. Then you can install it as usual with pacman. It also has AUR support for submitting tarballs and leaving comments.<br />
<br />
* Website: http://sourceforge.net/apps/mediawiki/pkgman/index.php<br />
* Forum: http://bbs.archlinux.org/viewtopic.php?id=49023<br />
* Package: http://aur.archlinux.org/packages.php?ID=17100<br />
<br />
=== powaur ===<br />
<br />
powaur is a minimalistic AUR helper with a pacman-like interface. It is written in C.<br />
<br />
* Website: https://github.com/yanhan/powaur<br />
* Forum: http://bbs.archlinux.org/viewtopic.php?pid=938688<br />
* Package: http://aur.archlinux.org/packages.php?ID=49296<br />
<br />
=== slurpy ===<br />
<br />
{{Warning|''Slurpy'' development has been officially discontinued. See [http://rsontech.net/articles/2011/02/20/21/projects-removed].}}<br />
<br />
slurpy is an AUR helper written in python for searching AUR, downloading packages, showing information about packages, checking for updates and uploading a package to AUR. <br />
<br />
* Website: http://rsontech.net/projects/slurpy/<br />
* Forum: https://bbs.archlinux.org/viewtopic.php?id=75984<br />
* Package: http://aur.archlinux.org/packages.php?ID=28285<br />
<br />
=== spinach ===<br />
<br />
Spinach is a tiny Bash AUR helper with few dependencies.<br />
<br />
*Website: http://floft.net/wiki/Scripts/Spinach<br />
*Package: http://aur.archlinux.org/packages.php?ID=46993<br />
<br />
=== srcman ===<br />
<br />
srcman is a pacman/makepkg wrapper written in Bash, which transparently handles pacman operations on 'source packages'. This means, for example, that packages can be specified for installation either explicitly (pacman's -U operation) or can be installed from a (source) repository (-S operation). The address of an AUR pacman database can be found in the corresponding forum thread, by the way.<br />
The primary goal of this project is to provide a complete pacman wrapper and therefore, srcman supports all current pacman operations for binary ''and'' source packages.<br />
<br />
*Website: http://bbs.archlinux.org/viewtopic.php?id=65501<br />
*Package: http://aur.archlinux.org/packages.php?ID=23945<br />
<br />
=== tupac ===<br />
<br />
tupac is a pacman/yaourt wrapper written in PHP. The main difference between tupac and the rest of tupac wrappers is that it caches the local package database, so it gives you really fast operatibility even in environments with low resources (low RAM, slow disks). It also gives you two advanced features: checking for missing installed files and checking for files that are not owned by any package.<br />
<br />
*Package: http://aur.archlinux.org/packages.php?ID=13322<br />
<br />
=== yaourt ===<br />
<br />
[[Yaourt]] (Yet Another User Repository Tool) is a community-contributed wrapper for pacman which adds seamless access to the AUR, allowing and automating package compilation and installation from your choice of the thousands of PKGBUILDs in the AUR, in addition to the many thousands of available Arch binary packages. Yaourt uses the same exact syntax as pacman, which saves you from relearning an entirely new method of system maintenance, but also adds new options. Yaourt expands the power and simplicity of pacman by adding even more useful features and provides pleasing, colorized output, interactive search mode, and much more.<br />
<br />
*Website: http://archlinux.fr/yaourt-en<br />
*Package: http://aur.archlinux.org/packages.php?ID=5863<br />
<br />
== Comparison Table ==<br />
<br />
{| border="1" cellpadding="4" cellspacing="0"<br />
! Program !! Written in !! Dependency Support !! Core/extra/community support !! Actively Developed !! Usage <br />
|-<br />
! [[#aurget|Aurget]]<br />
| Bash || Yes || No || Yes || see <tt>aurget --help</tt><br />
|-<br />
! [[#aursh|AurShell]]<br />
| Python || No || No || Yes, as aursh || aursh (runs Aurshell program, wherein a number of different commands can be used)<br />
|-<br />
! [[#aurora|Aurora]]<br />
| Python3 || Basic (with makepkg) || No || Yes || see aurora --help<br />
|-<br />
! [[#clyde|Clyde]]<br />
| Lua|| Yes || Yes || Yes || Identical to pacman (e.g., clyde -S <pkgname>)<br />
|-<br />
! [[#cower|Cower]]<br />
| C|| Yes || No || Yes || see <tt>cower -h</tt><br />
|-<br />
! [[#makeaur|Makeaur]]<br />
| Bash || No || No || Has been forked || makeaur <pkgname> <br />
|-<br />
! [[#pacaur|Pacaur]]<br />
| Bash, backend in C (cower)|| Yes || Yes || Yes || Identical to pacman, and/or AUR specifc arguments . See also <tt>pacaur -h</tt>.<br />
|-<br />
! [[#packer|Packer]]<br />
| Bash || Yes || Yes || Yes || Identical to pacman (e.g., packer -S <pkgname>)<br />
|-<br />
! [[#pacmoon|pacmoon]]<br />
| Zsh|| Yes || Yes || Yes || Similar to emerge from portage e.g. pacmoon -av <pkgname><br />
|-<br />
! [[#paktahn|Paktahn]]<br />
| Lisp|| Yes || Yes || Yes || Identical to pacman (e.g., pak -S <pkgname>)<br />
|-<br />
! [[#pbfetch|pbfetch]]<br />
| Bash || Yes || Yes || Yes || Identical to pacman, and/or AUR specifc arguments (additional arguments for PKGBUILD editing, etc)<br />
|-<br />
! [[#powaur|powaur]]<br />
| C || No || Limited || Yes || Identical to pacman (eg. powaur -S <pkgname>)<br />
|-<br />
! [[#tupac|tupac]]<br />
| PHP || Yes || Yes || Updated under request || Identical to pacman (e.g., tupac -S <pkgname>)<br />
|-<br />
! [[#yaourt|Yaourt]]<br />
| Bash, back-end in C || Yes || Yes || Yes || Identical to pacman (e.g., yaourt -S <pkgname>)<br />
|}</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=144728USB flash installation medium2011-06-10T03:20:21Z<p>JaMeSiTeGeN: /* Old Method from ISO, deprecated */</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Install from a USB flash drive}}<br />
[[de:Installation von einem USB-Stick]]<br />
<br />
This page discusses how to put Arch installation media onto a USB key (or "flash drive"). The result will be a LiveCD-like system that will discard all changes when it's shut down. Consider whether you're instead interested in [[Installing Arch Linux on a USB key]].<br />
<br />
== On GNU/Linux ==<br />
<br />
=== Arch USB images ===<br />
<br />
Beginning from release 2010.05, all iso files can be directly written to usb media. Download them from your [http://archlinux.org/download/ local mirror]. To install, first ensure the USB device is '''unmounted''' and then issue the following command:<br />
<br />
$ dd if=archlinux.iso of=/dev/sd[x]<br />
<br />
where ''archlinux.iso'' is the path to the iso file and ''/dev/sd[x]'' is your USB device.<br />
<br />
{{Note|You can also add bs&#61;4M to speed up the dd process..}}<br />
<br />
{{Warning|This will irrevocably destroy all data on /dev/sdx.}}<br />
<br />
{{Warning|Make sure to use /dev/sdx and NOT /dev/sdx1. '''This is a very common error!'''}}<br />
<br />
<br />
brain0 made a nice post on his blog on [http://archlinux.me/brain0/2010/05/29/arch-linux-usb-install-and-resuce-media/ Arch Linux USB Install and Rescue Media] where he explains how to have several partitions on the USB stick with some accessible from windows.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using [http://unetbootin.sourceforge.net/ UNetBootin]. This application can download most distributions for you and write them to your flash drive. UNetbootin can download the latest Arch core or netinstall iso for you, or you can supply a manually downloaded one.<br />
<br />
It might happen that UNetBootin fails to start showing the following error.<br />
**<br />
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)<br />
<br />
If this happens try to start it with the following command as normal user.<br />
<br />
# su -c "dbus-launch --exit-with-session unetbootin"<br />
<br />
If using a version of UNetbootin older than 549, then after it finishes, you will have to adjust syslinux.cfg on the root of your flash drive before rebooting. Correct the "archisolabel=" parameter to reflect the label of the USB drive you used, i.e.:<br />
<br />
append initrd=/ubninit archisolabel=<label> tmpfs_size=75% locale=en_US.UTF-8<br />
<br />
=== Gujin ===<br />
<br />
A third method is to follow the instructions about [http://psychoticspoon.blogspot.com/2009/01/booting-multiple-livecds-from-single.html Booting multiple LiveCD's from a single USB stick]. In a nutshell, you create 2 partitions on your USB drive, copy the [http://gujin.sourceforge.net/ Gujin] boot loader image to the first partition, and copy Arch's ISO to the second.<br />
<br />
== On Mac OS X ==<br />
<br />
To be able to use dd on your usb device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and run<br />
<br />
diskutil list<br />
<br />
in Terminal.app. Figure out what your usb device is called - mine was called /dev/disk1. (Just use the `mount` command or `sudo dmesg | tail`.) Now you run<br />
<br />
diskutil unmountDisk /dev/disk1<br />
<br />
to unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1). Now we can continue in accordance with the Linux instructions above (but use bs=8192 if you're using the OS X dd, the number comes from 1024*8).<br />
<br />
dd if=image.iso of=/dev/disk1 bs=8192<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
<br />
== On Windows ==<br />
<br />
To write the USB image on Windows, you will need [http://launchpad.net/win32-image-writer Image Writer for Windows], [http://www.linuxliveusb.com/ Linux Live USB Creator], [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/ Universal USB Installer], [http://shounen.ru/soft/flashnul/ flashnul] ([http://translate.google.com/translate?u=http%3A%2F%2Fshounen.ru%2Fsoft%2Fflashnul%2F&hl=en&ie=UTF8&sl=ru&tl=en English version of the page]), [http://www.cygwin.com/ Cygwin], or [http://unetbootin.sourceforge.net/ UNetBootin].<br />
<br />
=== Image Writer for Windows ===<br />
Image Writer is the only native Windows image writer (except Cygwin) that writes the whole image without any changes (like dd) - other writers unpack the image and then copy all the files to a FAT filesystem.<br />
<br />
Download win32 disk imager from http://launchpad.net/win32-image-writer. Run the program. Select the arch image-file and usb stick. The Win32 Disk Imager's file browser assumes image files end with .img, so if the image-file you've selected ends with .iso, you will have to type its name in manually; this difference in suffixes is simply cosmetic however, the image will be written fine regardless. Click on the write button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
=== Linux Live USB Creator ===<br />
<br />
LiLi USB Creator can be used to create a bootable USB key for Arch either using a manually downloaded iso or automatically downloading the iso itself.<br />
It also supports automatic installation of VirtualBox on the USB key which can be used to boot Arch inside Windows.<br />
<br />
The steps involved are well described by LiLi itself but can be summarized to: download & install LiLi, download Arch iso, insert USB key, start LiLi & choose drive (1), source (2), options (4) and create (5).<br />
<br />
I have tested all features except the automatic download of iso, and all works and are quite fast.<br />
<br />
=== The Universal USB Installer ===<br />
<br />
I had problems booting from a USB key created with flashnul under Windows or dd under Linux.<br />
I gave a try to the "Universal USB Installer" and it created the bootable USB key which worked fine.<br />
<br />
=== The Flashnul Way ===<br />
<br />
From a command prompt, invoke flashnul with -p, and determine which device index is your USB drive. For example, my output looks like this:<br />
<br />
C:\>flashnul -p<br />
<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
<br />
In my case, it is drive E:<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, -L, and the path to your image. In my case, it would be<br />
<br />
C:\>flashnul E: -L path\to\arch.iso<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
<b>Note:</b><br />
<i>Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64. -bgalakazam</i><br />
<br />
=== The Cygwin Way ===<br />
<br />
Make sure your cygwin installation contains the dd package.<br />
Or if you don't want to install Cygwin, you can simply download dd for windows from http://www.chrysocome.net/dd.<br />
<br />
Place your image file in your home directory, in my case it is:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]:<br />
<br />
where image.iso is the path to the iso-image file within the cygwin directory and \\.\[x]: is your USB device where x is the windows designated letter, in my case "\\.\d:".<br />
<br />
On cygwin 6.0 find out the correct partition with <br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
dd if=image.iso of=/dev/sdb<br />
<br />
'''Note:''' This will irrevocably delete all files on your USB stick, so make sure you don't have any important files on the stick before doing this.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using UNetBootin ([[#UNetBootin|see above]])<br />
<br />
==Old Method from ISO, deprecated==<br />
*Prepare USB stick:<br />
The arch-ftp.img is about 150 MB, so it should fit on a 256 MB USB stick. The arch-core.img is ~300 MB and should fit on a 512 MB stick.<br />
<br />
====Partition the USB stick.====<br />
Create one partition with FAT16 type, make it bootable. Remember its name, such as /dev/sd[x]1.<br />
<br />
cfdisk /dev/sd[x]<br />
<br />
====Make a FAT16 filesystem (you need dosfstools)====<br />
<br />
mkdosfs /dev/sd[x]1<br />
<br />
====Get the arch-base install ISO from http://archlinux.org/====<br />
<br />
wget http://www.archlinux.org/iso/2010.05/archlinux-2010.05-netinstall-dual.iso.torrent<br />
pacman -Qq rtorrent || pacman -S rtorrent<br />
rtorrent archlinux-2010.05-netinstall-dual.iso.torrent<br />
<br />
====Mount the iso to an temporary directory====<br />
<br />
mkdir -p /mnt/archcd<br />
mount -o loop /Path/to/iso /mnt/archcd<br />
<br />
====Mount the USB Stick====<br />
<br />
mkdir -p /mnt/usb/<br />
mount /dev/sd[x]1 /mnt/usb/<br />
<br />
====Copy the .iso to the USB Stick====<br />
<br />
cp -ra /mnt/archcd/* /mnt/usb/<br />
<br />
====Copy the boot data====<br />
<br />
cd /mnt/usb/isolinux/<br />
cp vmlinuz /mnt/usb/<br />
cp initrd.img /mnt/usb/<br />
cp boot.* /mnt/usb/<br />
cp isolinux.cfg /mnt/usb/syslinux.cfg<br />
<br />
{{Note|For release 2010.05, replace those command lines by the following}}<br />
<br />
cd /mnt/usb/<br />
cp boot/isolinux/isolinux.cfg ./syslinux.cfg<br />
sed /IPAPPEND/d syslinux.cfg<br />
cp /usr/lib/syslinux/vesamenu.c32 ./<br />
cp /usr/lib/syslinux/chain.c32 ./<br />
cp /usr/lib/syslinux/reboot.c32 ./<br />
<br />
====Install MBR and syslinux<sup>(1)</sup>====<br />
<br />
lilo -M /dev/sd[x] mbr<br />
syslinux -s /dev/sd[x]1<br />
<br />
{{Note|For release 2010.05, replace those command lines by the following}}<br />
<br />
syslinux --install /dev/sd[x]1<br />
cat /usr/lib/syslinux/mbr.bin > /dev/sd[x]<br />
<br />
==After booting from the USB stick:==<br />
<br />
Start the installation by logging in as root and invoke the command "/arch/setup".<br />
<br />
The installer should mount the source media automatically. If it fails you can manually mount the source media on the stick to the /src directory with the following command:<br />
<br />
mount /dev/sd[x] /src<br />
<br />
==Notes and Troubleshooting:==<br />
<br />
<sup>(1)</sup> Using lilo is not really needed because syslinux does the "floppy" loading stuff. But if you get some error like "Can't load operating system" you have to perform the lilo command.<br />
<br />
<sup>(2)</sup> If you get "Cluster sizes larger than 16K not supported" error when booting this means you need to install more recent version of syslinux.<br />
<br />
<sup>(3)</sup> Space not used on the USB stick can still be used for storing files... Use a utility like gparted and add a partition to the unused space.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=144727USB flash installation medium2011-06-10T03:19:02Z<p>JaMeSiTeGeN: /* Old Method from ISO, deprecated */</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Install from a USB flash drive}}<br />
[[de:Installation von einem USB-Stick]]<br />
<br />
This page discusses how to put Arch installation media onto a USB key (or "flash drive"). The result will be a LiveCD-like system that will discard all changes when it's shut down. Consider whether you're instead interested in [[Installing Arch Linux on a USB key]].<br />
<br />
== On GNU/Linux ==<br />
<br />
=== Arch USB images ===<br />
<br />
Beginning from release 2010.05, all iso files can be directly written to usb media. Download them from your [http://archlinux.org/download/ local mirror]. To install, first ensure the USB device is '''unmounted''' and then issue the following command:<br />
<br />
$ dd if=archlinux.iso of=/dev/sd[x]<br />
<br />
where ''archlinux.iso'' is the path to the iso file and ''/dev/sd[x]'' is your USB device.<br />
<br />
{{Note|You can also add bs&#61;4M to speed up the dd process..}}<br />
<br />
{{Warning|This will irrevocably destroy all data on /dev/sdx.}}<br />
<br />
{{Warning|Make sure to use /dev/sdx and NOT /dev/sdx1. '''This is a very common error!'''}}<br />
<br />
<br />
brain0 made a nice post on his blog on [http://archlinux.me/brain0/2010/05/29/arch-linux-usb-install-and-resuce-media/ Arch Linux USB Install and Rescue Media] where he explains how to have several partitions on the USB stick with some accessible from windows.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using [http://unetbootin.sourceforge.net/ UNetBootin]. This application can download most distributions for you and write them to your flash drive. UNetbootin can download the latest Arch core or netinstall iso for you, or you can supply a manually downloaded one.<br />
<br />
It might happen that UNetBootin fails to start showing the following error.<br />
**<br />
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)<br />
<br />
If this happens try to start it with the following command as normal user.<br />
<br />
# su -c "dbus-launch --exit-with-session unetbootin"<br />
<br />
If using a version of UNetbootin older than 549, then after it finishes, you will have to adjust syslinux.cfg on the root of your flash drive before rebooting. Correct the "archisolabel=" parameter to reflect the label of the USB drive you used, i.e.:<br />
<br />
append initrd=/ubninit archisolabel=<label> tmpfs_size=75% locale=en_US.UTF-8<br />
<br />
=== Gujin ===<br />
<br />
A third method is to follow the instructions about [http://psychoticspoon.blogspot.com/2009/01/booting-multiple-livecds-from-single.html Booting multiple LiveCD's from a single USB stick]. In a nutshell, you create 2 partitions on your USB drive, copy the [http://gujin.sourceforge.net/ Gujin] boot loader image to the first partition, and copy Arch's ISO to the second.<br />
<br />
== On Mac OS X ==<br />
<br />
To be able to use dd on your usb device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and run<br />
<br />
diskutil list<br />
<br />
in Terminal.app. Figure out what your usb device is called - mine was called /dev/disk1. (Just use the `mount` command or `sudo dmesg | tail`.) Now you run<br />
<br />
diskutil unmountDisk /dev/disk1<br />
<br />
to unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1). Now we can continue in accordance with the Linux instructions above (but use bs=8192 if you're using the OS X dd, the number comes from 1024*8).<br />
<br />
dd if=image.iso of=/dev/disk1 bs=8192<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
<br />
== On Windows ==<br />
<br />
To write the USB image on Windows, you will need [http://launchpad.net/win32-image-writer Image Writer for Windows], [http://www.linuxliveusb.com/ Linux Live USB Creator], [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/ Universal USB Installer], [http://shounen.ru/soft/flashnul/ flashnul] ([http://translate.google.com/translate?u=http%3A%2F%2Fshounen.ru%2Fsoft%2Fflashnul%2F&hl=en&ie=UTF8&sl=ru&tl=en English version of the page]), [http://www.cygwin.com/ Cygwin], or [http://unetbootin.sourceforge.net/ UNetBootin].<br />
<br />
=== Image Writer for Windows ===<br />
Image Writer is the only native Windows image writer (except Cygwin) that writes the whole image without any changes (like dd) - other writers unpack the image and then copy all the files to a FAT filesystem.<br />
<br />
Download win32 disk imager from http://launchpad.net/win32-image-writer. Run the program. Select the arch image-file and usb stick. The Win32 Disk Imager's file browser assumes image files end with .img, so if the image-file you've selected ends with .iso, you will have to type its name in manually; this difference in suffixes is simply cosmetic however, the image will be written fine regardless. Click on the write button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
=== Linux Live USB Creator ===<br />
<br />
LiLi USB Creator can be used to create a bootable USB key for Arch either using a manually downloaded iso or automatically downloading the iso itself.<br />
It also supports automatic installation of VirtualBox on the USB key which can be used to boot Arch inside Windows.<br />
<br />
The steps involved are well described by LiLi itself but can be summarized to: download & install LiLi, download Arch iso, insert USB key, start LiLi & choose drive (1), source (2), options (4) and create (5).<br />
<br />
I have tested all features except the automatic download of iso, and all works and are quite fast.<br />
<br />
=== The Universal USB Installer ===<br />
<br />
I had problems booting from a USB key created with flashnul under Windows or dd under Linux.<br />
I gave a try to the "Universal USB Installer" and it created the bootable USB key which worked fine.<br />
<br />
=== The Flashnul Way ===<br />
<br />
From a command prompt, invoke flashnul with -p, and determine which device index is your USB drive. For example, my output looks like this:<br />
<br />
C:\>flashnul -p<br />
<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
<br />
In my case, it is drive E:<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, -L, and the path to your image. In my case, it would be<br />
<br />
C:\>flashnul E: -L path\to\arch.iso<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
<b>Note:</b><br />
<i>Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64. -bgalakazam</i><br />
<br />
=== The Cygwin Way ===<br />
<br />
Make sure your cygwin installation contains the dd package.<br />
Or if you don't want to install Cygwin, you can simply download dd for windows from http://www.chrysocome.net/dd.<br />
<br />
Place your image file in your home directory, in my case it is:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]:<br />
<br />
where image.iso is the path to the iso-image file within the cygwin directory and \\.\[x]: is your USB device where x is the windows designated letter, in my case "\\.\d:".<br />
<br />
On cygwin 6.0 find out the correct partition with <br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
dd if=image.iso of=/dev/sdb<br />
<br />
'''Note:''' This will irrevocably delete all files on your USB stick, so make sure you don't have any important files on the stick before doing this.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using UNetBootin ([[#UNetBootin|see above]])<br />
<br />
==Old Method from ISO, deprecated==<br />
*Prepare USB stick:<br />
The arch-ftp.img is about 150 MB, so it should fit on a 256 MB USB stick. The arch-core.img is ~300 MB and should fit on a 512 MB stick.<br />
<br />
====Partition the USB stick.====<br />
Create one partition with FAT16 type, make it bootable. Remember its name, such as /dev/sd[x]1.<br />
<br />
cfdisk /dev/sd[x]<br />
<br />
====Make a FAT16 filesystem (you need dosfstools)====<br />
<br />
mkdosfs /dev/sd[x]1<br />
<br />
====Get the arch-base install ISO from http://archlinux.org/====<br />
<br />
wget http://www.archlinux.org/iso/2010.05/archlinux-2010.05-netinstall-dual.iso.torrent<br />
pacman -Qq rtorrent || pacman -S rtorrent<br />
rtorrent archlinux-2010.05-netinstall-dual.iso.torrent<br />
<br />
====Mount the iso to an temporary directory====<br />
<br />
mkdir -p /mnt/archcd<br />
mount -o loop /Path/to/iso /mnt/archcd<br />
<br />
====Mount the USB Stick====<br />
<br />
mkdir -p /mnt/usb/<br />
mount /dev/sd[x]1 /mnt/usb/<br />
<br />
====Copy the .iso to the USB Stick====<br />
<br />
cp -ra /mnt/archcd/* /mnt/usb/<br />
<br />
====Copy the boot data====<br />
<br />
cd /mnt/usb/isolinux/<br />
cp vmlinuz /mnt/usb/<br />
cp initrd.img /mnt/usb/<br />
cp boot.* /mnt/usb/<br />
cp isolinux.cfg /mnt/usb/syslinux.cfg<br />
<br />
{{Note|For release 2010.05, replace those command lines by the following}}<br />
<br />
cd /mnt/usb/<br />
cp boot/isolinux/isolinux.cfg ./syslinux.cfg<br />
sed /IPAPPEND/d syslinux.cfg<br />
cp /usr/lib/syslinux/vesamenu.c32 ./<br />
cp /usr/lib/syslinux/chain.c32 ./<br />
cp /usr/lib/syslinux/reboot.c32 ./<br />
<br />
====Install MBR and syslinux<sup>(1)</sup>====<br />
<br />
lilo -M /dev/sd[x] mbr<br />
syslinux -s /dev/sd[x]1<br />
<br />
{{Note|For release 2010.05, replace those command lines by the following}}<br />
<br />
syslinux --install /dev/sd[x]1<br />
cat /usr/lib/syslinux/mbr.bin > /dev/sd[x]<br />
<br />
===After booting from the USB stick:===<br />
<br />
Start the installation by logging in as root and invoke the command "/arch/setup".<br />
<br />
The installer should mount the source media automatically. If it fails you can manually mount the source media on the stick to the /src directory with the following command:<br />
<br />
mount /dev/sd[x] /src<br />
<br />
===Notes and Troubleshooting:===<br />
<br />
<sup>(1)</sup> Using lilo is not really needed because syslinux does the "floppy" loading stuff. But if you get some error like "Can't load operating system" you have to perform the lilo command.<br />
<br />
<sup>(2)</sup> If you get "Cluster sizes larger than 16K not supported" error when booting this means you need to install more recent version of syslinux.<br />
<br />
<sup>(3)</sup> Space not used on the USB stick can still be used for storing files... Use a utility like gparted and add a partition to the unused space.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=144726USB flash installation medium2011-06-10T03:11:02Z<p>JaMeSiTeGeN: /* Old Method from ISO, deprecated */</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Install from a USB flash drive}}<br />
[[de:Installation von einem USB-Stick]]<br />
<br />
This page discusses how to put Arch installation media onto a USB key (or "flash drive"). The result will be a LiveCD-like system that will discard all changes when it's shut down. Consider whether you're instead interested in [[Installing Arch Linux on a USB key]].<br />
<br />
== On GNU/Linux ==<br />
<br />
=== Arch USB images ===<br />
<br />
Beginning from release 2010.05, all iso files can be directly written to usb media. Download them from your [http://archlinux.org/download/ local mirror]. To install, first ensure the USB device is '''unmounted''' and then issue the following command:<br />
<br />
$ dd if=archlinux.iso of=/dev/sd[x]<br />
<br />
where ''archlinux.iso'' is the path to the iso file and ''/dev/sd[x]'' is your USB device.<br />
<br />
{{Note|You can also add bs&#61;4M to speed up the dd process..}}<br />
<br />
{{Warning|This will irrevocably destroy all data on /dev/sdx.}}<br />
<br />
{{Warning|Make sure to use /dev/sdx and NOT /dev/sdx1. '''This is a very common error!'''}}<br />
<br />
<br />
brain0 made a nice post on his blog on [http://archlinux.me/brain0/2010/05/29/arch-linux-usb-install-and-resuce-media/ Arch Linux USB Install and Rescue Media] where he explains how to have several partitions on the USB stick with some accessible from windows.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using [http://unetbootin.sourceforge.net/ UNetBootin]. This application can download most distributions for you and write them to your flash drive. UNetbootin can download the latest Arch core or netinstall iso for you, or you can supply a manually downloaded one.<br />
<br />
It might happen that UNetBootin fails to start showing the following error.<br />
**<br />
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)<br />
<br />
If this happens try to start it with the following command as normal user.<br />
<br />
# su -c "dbus-launch --exit-with-session unetbootin"<br />
<br />
If using a version of UNetbootin older than 549, then after it finishes, you will have to adjust syslinux.cfg on the root of your flash drive before rebooting. Correct the "archisolabel=" parameter to reflect the label of the USB drive you used, i.e.:<br />
<br />
append initrd=/ubninit archisolabel=<label> tmpfs_size=75% locale=en_US.UTF-8<br />
<br />
=== Gujin ===<br />
<br />
A third method is to follow the instructions about [http://psychoticspoon.blogspot.com/2009/01/booting-multiple-livecds-from-single.html Booting multiple LiveCD's from a single USB stick]. In a nutshell, you create 2 partitions on your USB drive, copy the [http://gujin.sourceforge.net/ Gujin] boot loader image to the first partition, and copy Arch's ISO to the second.<br />
<br />
== On Mac OS X ==<br />
<br />
To be able to use dd on your usb device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and run<br />
<br />
diskutil list<br />
<br />
in Terminal.app. Figure out what your usb device is called - mine was called /dev/disk1. (Just use the `mount` command or `sudo dmesg | tail`.) Now you run<br />
<br />
diskutil unmountDisk /dev/disk1<br />
<br />
to unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1). Now we can continue in accordance with the Linux instructions above (but use bs=8192 if you're using the OS X dd, the number comes from 1024*8).<br />
<br />
dd if=image.iso of=/dev/disk1 bs=8192<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
<br />
== On Windows ==<br />
<br />
To write the USB image on Windows, you will need [http://launchpad.net/win32-image-writer Image Writer for Windows], [http://www.linuxliveusb.com/ Linux Live USB Creator], [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/ Universal USB Installer], [http://shounen.ru/soft/flashnul/ flashnul] ([http://translate.google.com/translate?u=http%3A%2F%2Fshounen.ru%2Fsoft%2Fflashnul%2F&hl=en&ie=UTF8&sl=ru&tl=en English version of the page]), [http://www.cygwin.com/ Cygwin], or [http://unetbootin.sourceforge.net/ UNetBootin].<br />
<br />
=== Image Writer for Windows ===<br />
Image Writer is the only native Windows image writer (except Cygwin) that writes the whole image without any changes (like dd) - other writers unpack the image and then copy all the files to a FAT filesystem.<br />
<br />
Download win32 disk imager from http://launchpad.net/win32-image-writer. Run the program. Select the arch image-file and usb stick. The Win32 Disk Imager's file browser assumes image files end with .img, so if the image-file you've selected ends with .iso, you will have to type its name in manually; this difference in suffixes is simply cosmetic however, the image will be written fine regardless. Click on the write button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
=== Linux Live USB Creator ===<br />
<br />
LiLi USB Creator can be used to create a bootable USB key for Arch either using a manually downloaded iso or automatically downloading the iso itself.<br />
It also supports automatic installation of VirtualBox on the USB key which can be used to boot Arch inside Windows.<br />
<br />
The steps involved are well described by LiLi itself but can be summarized to: download & install LiLi, download Arch iso, insert USB key, start LiLi & choose drive (1), source (2), options (4) and create (5).<br />
<br />
I have tested all features except the automatic download of iso, and all works and are quite fast.<br />
<br />
=== The Universal USB Installer ===<br />
<br />
I had problems booting from a USB key created with flashnul under Windows or dd under Linux.<br />
I gave a try to the "Universal USB Installer" and it created the bootable USB key which worked fine.<br />
<br />
=== The Flashnul Way ===<br />
<br />
From a command prompt, invoke flashnul with -p, and determine which device index is your USB drive. For example, my output looks like this:<br />
<br />
C:\>flashnul -p<br />
<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
<br />
In my case, it is drive E:<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, -L, and the path to your image. In my case, it would be<br />
<br />
C:\>flashnul E: -L path\to\arch.iso<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
<b>Note:</b><br />
<i>Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64. -bgalakazam</i><br />
<br />
=== The Cygwin Way ===<br />
<br />
Make sure your cygwin installation contains the dd package.<br />
Or if you don't want to install Cygwin, you can simply download dd for windows from http://www.chrysocome.net/dd.<br />
<br />
Place your image file in your home directory, in my case it is:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]:<br />
<br />
where image.iso is the path to the iso-image file within the cygwin directory and \\.\[x]: is your USB device where x is the windows designated letter, in my case "\\.\d:".<br />
<br />
On cygwin 6.0 find out the correct partition with <br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
dd if=image.iso of=/dev/sdb<br />
<br />
'''Note:''' This will irrevocably delete all files on your USB stick, so make sure you don't have any important files on the stick before doing this.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using UNetBootin ([[#UNetBootin|see above]])<br />
<br />
==Old Method from ISO, deprecated==<br />
*Prepare USB stick:<br />
The arch-ftp.img is about 150 MB, so it should fit on a 256 MB USB stick. The arch-core.img is ~300 MB and should fit on a 512 MB stick.<br />
<br />
1. Partition the USB stick.<br />
Create one partition with FAT16 type, make it bootable. Remember its name, such as /dev/sd[x]1.<br />
<br />
cfdisk /dev/sd[x]<br />
<br />
2. Make a FAT16 filesystem (you need dosfstools)<br />
<br />
mkdosfs /dev/sd[x]1<br />
<br />
3. Get the arch-base install ISO from www.archlinux.org<br />
<br />
4. Mount the iso to an temporary directory<br />
<br />
mkdir -p /mnt/archcd<br />
mount -o loop /Path/to/iso /mnt/archcd<br />
<br />
5. Mount the USB Stick<br />
<br />
mkdir -p /mnt/usb/<br />
mount /dev/sd[x]1 /mnt/usb/<br />
<br />
6. Copy the .iso to the USB Stick<br />
<br />
cp -ra /mnt/archcd/* /mnt/usb/<br />
<br />
<br />
7. Copy the boot data<br />
<br />
cd /mnt/usb/isolinux/<br />
cp vmlinuz /mnt/usb/<br />
cp initrd.img /mnt/usb/<br />
cp boot.* /mnt/usb/<br />
cp isolinux.cfg /mnt/usb/syslinux.cfg<br />
<br />
{{Note|For release 2010.05, replace those command lines by the following}}<br />
<br />
cd /mnt/usb/<br />
cp boot/isolinux/isolinux.cfg ./syslinux.cfg<br />
sed /IPAPPEND/d syslinux.cfg<br />
cp /usr/lib/syslinux/vesamenu.c32 ./<br />
cp /usr/lib/syslinux/chain.c32 ./<br />
cp /usr/lib/syslinux/reboot.c32 ./<br />
<br />
8. Install MBR and syslinux<sup>(1)</sup><br />
<br />
lilo -M /dev/sd[x] mbr<br />
syslinux -s /dev/sd[x]1<br />
<br />
{{Note|For release 2010.05, replace those command lines by the following}}<br />
<br />
syslinux --install /dev/sd[x]1<br />
cat /usr/lib/syslinux/mbr.bin > /dev/sd[x]<br />
<br />
===After booting from the USB stick:===<br />
<br />
Start the installation by logging in as root and invoke the command "/arch/setup".<br />
<br />
The installer should mount the source media automatically. If it fails you can manually mount the source media on the stick to the /src directory with the following command:<br />
<br />
mount /dev/sd[x] /src<br />
<br />
===Notes and Troubleshooting:===<br />
<br />
<sup>(1)</sup> Using lilo is not really needed because syslinux does the "floppy" loading stuff. But if you get some error like "Can't load operating system" you have to perform the lilo command.<br />
<br />
<sup>(2)</sup> If you get "Cluster sizes larger than 16K not supported" error when booting this means you need to install more recent version of syslinux.<br />
<br />
<sup>(3)</sup> Space not used on the USB stick can still be used for storing files... Use a utility like gparted and add a partition to the unused space.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=144725USB flash installation medium2011-06-10T03:10:28Z<p>JaMeSiTeGeN: /* Old Method from ISO, deprecated */</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Install from a USB flash drive}}<br />
[[de:Installation von einem USB-Stick]]<br />
<br />
This page discusses how to put Arch installation media onto a USB key (or "flash drive"). The result will be a LiveCD-like system that will discard all changes when it's shut down. Consider whether you're instead interested in [[Installing Arch Linux on a USB key]].<br />
<br />
== On GNU/Linux ==<br />
<br />
=== Arch USB images ===<br />
<br />
Beginning from release 2010.05, all iso files can be directly written to usb media. Download them from your [http://archlinux.org/download/ local mirror]. To install, first ensure the USB device is '''unmounted''' and then issue the following command:<br />
<br />
$ dd if=archlinux.iso of=/dev/sd[x]<br />
<br />
where ''archlinux.iso'' is the path to the iso file and ''/dev/sd[x]'' is your USB device.<br />
<br />
{{Note|You can also add bs&#61;4M to speed up the dd process..}}<br />
<br />
{{Warning|This will irrevocably destroy all data on /dev/sdx.}}<br />
<br />
{{Warning|Make sure to use /dev/sdx and NOT /dev/sdx1. '''This is a very common error!'''}}<br />
<br />
<br />
brain0 made a nice post on his blog on [http://archlinux.me/brain0/2010/05/29/arch-linux-usb-install-and-resuce-media/ Arch Linux USB Install and Rescue Media] where he explains how to have several partitions on the USB stick with some accessible from windows.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using [http://unetbootin.sourceforge.net/ UNetBootin]. This application can download most distributions for you and write them to your flash drive. UNetbootin can download the latest Arch core or netinstall iso for you, or you can supply a manually downloaded one.<br />
<br />
It might happen that UNetBootin fails to start showing the following error.<br />
**<br />
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)<br />
<br />
If this happens try to start it with the following command as normal user.<br />
<br />
# su -c "dbus-launch --exit-with-session unetbootin"<br />
<br />
If using a version of UNetbootin older than 549, then after it finishes, you will have to adjust syslinux.cfg on the root of your flash drive before rebooting. Correct the "archisolabel=" parameter to reflect the label of the USB drive you used, i.e.:<br />
<br />
append initrd=/ubninit archisolabel=<label> tmpfs_size=75% locale=en_US.UTF-8<br />
<br />
=== Gujin ===<br />
<br />
A third method is to follow the instructions about [http://psychoticspoon.blogspot.com/2009/01/booting-multiple-livecds-from-single.html Booting multiple LiveCD's from a single USB stick]. In a nutshell, you create 2 partitions on your USB drive, copy the [http://gujin.sourceforge.net/ Gujin] boot loader image to the first partition, and copy Arch's ISO to the second.<br />
<br />
== On Mac OS X ==<br />
<br />
To be able to use dd on your usb device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and run<br />
<br />
diskutil list<br />
<br />
in Terminal.app. Figure out what your usb device is called - mine was called /dev/disk1. (Just use the `mount` command or `sudo dmesg | tail`.) Now you run<br />
<br />
diskutil unmountDisk /dev/disk1<br />
<br />
to unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1). Now we can continue in accordance with the Linux instructions above (but use bs=8192 if you're using the OS X dd, the number comes from 1024*8).<br />
<br />
dd if=image.iso of=/dev/disk1 bs=8192<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
<br />
== On Windows ==<br />
<br />
To write the USB image on Windows, you will need [http://launchpad.net/win32-image-writer Image Writer for Windows], [http://www.linuxliveusb.com/ Linux Live USB Creator], [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/ Universal USB Installer], [http://shounen.ru/soft/flashnul/ flashnul] ([http://translate.google.com/translate?u=http%3A%2F%2Fshounen.ru%2Fsoft%2Fflashnul%2F&hl=en&ie=UTF8&sl=ru&tl=en English version of the page]), [http://www.cygwin.com/ Cygwin], or [http://unetbootin.sourceforge.net/ UNetBootin].<br />
<br />
=== Image Writer for Windows ===<br />
Image Writer is the only native Windows image writer (except Cygwin) that writes the whole image without any changes (like dd) - other writers unpack the image and then copy all the files to a FAT filesystem.<br />
<br />
Download win32 disk imager from http://launchpad.net/win32-image-writer. Run the program. Select the arch image-file and usb stick. The Win32 Disk Imager's file browser assumes image files end with .img, so if the image-file you've selected ends with .iso, you will have to type its name in manually; this difference in suffixes is simply cosmetic however, the image will be written fine regardless. Click on the write button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
=== Linux Live USB Creator ===<br />
<br />
LiLi USB Creator can be used to create a bootable USB key for Arch either using a manually downloaded iso or automatically downloading the iso itself.<br />
It also supports automatic installation of VirtualBox on the USB key which can be used to boot Arch inside Windows.<br />
<br />
The steps involved are well described by LiLi itself but can be summarized to: download & install LiLi, download Arch iso, insert USB key, start LiLi & choose drive (1), source (2), options (4) and create (5).<br />
<br />
I have tested all features except the automatic download of iso, and all works and are quite fast.<br />
<br />
=== The Universal USB Installer ===<br />
<br />
I had problems booting from a USB key created with flashnul under Windows or dd under Linux.<br />
I gave a try to the "Universal USB Installer" and it created the bootable USB key which worked fine.<br />
<br />
=== The Flashnul Way ===<br />
<br />
From a command prompt, invoke flashnul with -p, and determine which device index is your USB drive. For example, my output looks like this:<br />
<br />
C:\>flashnul -p<br />
<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
<br />
In my case, it is drive E:<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, -L, and the path to your image. In my case, it would be<br />
<br />
C:\>flashnul E: -L path\to\arch.iso<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
<b>Note:</b><br />
<i>Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64. -bgalakazam</i><br />
<br />
=== The Cygwin Way ===<br />
<br />
Make sure your cygwin installation contains the dd package.<br />
Or if you don't want to install Cygwin, you can simply download dd for windows from http://www.chrysocome.net/dd.<br />
<br />
Place your image file in your home directory, in my case it is:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]:<br />
<br />
where image.iso is the path to the iso-image file within the cygwin directory and \\.\[x]: is your USB device where x is the windows designated letter, in my case "\\.\d:".<br />
<br />
On cygwin 6.0 find out the correct partition with <br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
dd if=image.iso of=/dev/sdb<br />
<br />
'''Note:''' This will irrevocably delete all files on your USB stick, so make sure you don't have any important files on the stick before doing this.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using UNetBootin ([[#UNetBootin|see above]])<br />
<br />
==Old Method from ISO, deprecated==<br />
*Prepare USB stick:<br />
The arch-ftp.img is about 150 MB, so it should fit on a 256 MB USB stick. The arch-core.img is ~300 MB and should fit on a 512 MB stick.<br />
<br />
1. Partition the USB stick.<br />
Create one partition with FAT16 type, make it bootable. Remember its name, such as /dev/sd[x]1.<br />
<br />
cfdisk /dev/sd[x]<br />
<br />
2. Make a FAT16 filesystem (you need dosfstools)<br />
<br />
mkdosfs /dev/sd[x]1<br />
<br />
3. Get the arch-base install ISO from www.archlinux.org<br />
<br />
4. Mount the iso to an temporary directory<br />
<br />
mkdir -p /mnt/archcd<br />
mount -o loop /Path/to/iso /mnt/archcd<br />
<br />
5. Mount the USB Stick<br />
<br />
mkdir -p /mnt/usb/<br />
mount /dev/sd[x]1 /mnt/usb/<br />
<br />
6. Copy the .iso to the USB Stick<br />
<br />
cp -ra /mnt/archcd/* /mnt/usb/<br />
<br />
<br />
7. Copy the boot data<br />
<br />
cd /mnt/usb/isolinux/<br />
cp vmlinuz /mnt/usb/<br />
cp initrd.img /mnt/usb/<br />
cp boot.* /mnt/usb/<br />
cp isolinux.cfg /mnt/usb/syslinux.cfg<br />
<br />
'''Note:''' for release 2010.05, replace those command lines by the following<br />
<br />
cd /mnt/usb/<br />
cp boot/isolinux/isolinux.cfg ./syslinux.cfg<br />
sed /IPAPPEND/d syslinux.cfg<br />
cp /usr/lib/syslinux/vesamenu.c32 ./<br />
cp /usr/lib/syslinux/chain.c32 ./<br />
cp /usr/lib/syslinux/reboot.c32 ./<br />
<br />
8. Install MBR and syslinux<sup>(1)</sup><br />
<br />
lilo -M /dev/sd[x] mbr<br />
syslinux -s /dev/sd[x]1<br />
<br />
{{Note|For release 2010.05, replace those command lines by the following}}<br />
<br />
syslinux --install /dev/sd[x]1<br />
cat /usr/lib/syslinux/mbr.bin > /dev/sd[x]<br />
<br />
===After booting from the USB stick:===<br />
<br />
Start the installation by logging in as root and invoke the command "/arch/setup".<br />
<br />
The installer should mount the source media automatically. If it fails you can manually mount the source media on the stick to the /src directory with the following command:<br />
<br />
mount /dev/sd[x] /src<br />
<br />
===Notes and Troubleshooting:===<br />
<br />
<sup>(1)</sup> Using lilo is not really needed because syslinux does the "floppy" loading stuff. But if you get some error like "Can't load operating system" you have to perform the lilo command.<br />
<br />
<sup>(2)</sup> If you get "Cluster sizes larger than 16K not supported" error when booting this means you need to install more recent version of syslinux.<br />
<br />
<sup>(3)</sup> Space not used on the USB stick can still be used for storing files... Use a utility like gparted and add a partition to the unused space.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=144724USB flash installation medium2011-06-10T03:07:13Z<p>JaMeSiTeGeN: /* The Cygwin Way */</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Install from a USB flash drive}}<br />
[[de:Installation von einem USB-Stick]]<br />
<br />
This page discusses how to put Arch installation media onto a USB key (or "flash drive"). The result will be a LiveCD-like system that will discard all changes when it's shut down. Consider whether you're instead interested in [[Installing Arch Linux on a USB key]].<br />
<br />
== On GNU/Linux ==<br />
<br />
=== Arch USB images ===<br />
<br />
Beginning from release 2010.05, all iso files can be directly written to usb media. Download them from your [http://archlinux.org/download/ local mirror]. To install, first ensure the USB device is '''unmounted''' and then issue the following command:<br />
<br />
$ dd if=archlinux.iso of=/dev/sd[x]<br />
<br />
where ''archlinux.iso'' is the path to the iso file and ''/dev/sd[x]'' is your USB device.<br />
<br />
{{Note|You can also add bs&#61;4M to speed up the dd process..}}<br />
<br />
{{Warning|This will irrevocably destroy all data on /dev/sdx.}}<br />
<br />
{{Warning|Make sure to use /dev/sdx and NOT /dev/sdx1. '''This is a very common error!'''}}<br />
<br />
<br />
brain0 made a nice post on his blog on [http://archlinux.me/brain0/2010/05/29/arch-linux-usb-install-and-resuce-media/ Arch Linux USB Install and Rescue Media] where he explains how to have several partitions on the USB stick with some accessible from windows.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using [http://unetbootin.sourceforge.net/ UNetBootin]. This application can download most distributions for you and write them to your flash drive. UNetbootin can download the latest Arch core or netinstall iso for you, or you can supply a manually downloaded one.<br />
<br />
It might happen that UNetBootin fails to start showing the following error.<br />
**<br />
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)<br />
<br />
If this happens try to start it with the following command as normal user.<br />
<br />
# su -c "dbus-launch --exit-with-session unetbootin"<br />
<br />
If using a version of UNetbootin older than 549, then after it finishes, you will have to adjust syslinux.cfg on the root of your flash drive before rebooting. Correct the "archisolabel=" parameter to reflect the label of the USB drive you used, i.e.:<br />
<br />
append initrd=/ubninit archisolabel=<label> tmpfs_size=75% locale=en_US.UTF-8<br />
<br />
=== Gujin ===<br />
<br />
A third method is to follow the instructions about [http://psychoticspoon.blogspot.com/2009/01/booting-multiple-livecds-from-single.html Booting multiple LiveCD's from a single USB stick]. In a nutshell, you create 2 partitions on your USB drive, copy the [http://gujin.sourceforge.net/ Gujin] boot loader image to the first partition, and copy Arch's ISO to the second.<br />
<br />
== On Mac OS X ==<br />
<br />
To be able to use dd on your usb device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and run<br />
<br />
diskutil list<br />
<br />
in Terminal.app. Figure out what your usb device is called - mine was called /dev/disk1. (Just use the `mount` command or `sudo dmesg | tail`.) Now you run<br />
<br />
diskutil unmountDisk /dev/disk1<br />
<br />
to unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1). Now we can continue in accordance with the Linux instructions above (but use bs=8192 if you're using the OS X dd, the number comes from 1024*8).<br />
<br />
dd if=image.iso of=/dev/disk1 bs=8192<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
<br />
== On Windows ==<br />
<br />
To write the USB image on Windows, you will need [http://launchpad.net/win32-image-writer Image Writer for Windows], [http://www.linuxliveusb.com/ Linux Live USB Creator], [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/ Universal USB Installer], [http://shounen.ru/soft/flashnul/ flashnul] ([http://translate.google.com/translate?u=http%3A%2F%2Fshounen.ru%2Fsoft%2Fflashnul%2F&hl=en&ie=UTF8&sl=ru&tl=en English version of the page]), [http://www.cygwin.com/ Cygwin], or [http://unetbootin.sourceforge.net/ UNetBootin].<br />
<br />
=== Image Writer for Windows ===<br />
Image Writer is the only native Windows image writer (except Cygwin) that writes the whole image without any changes (like dd) - other writers unpack the image and then copy all the files to a FAT filesystem.<br />
<br />
Download win32 disk imager from http://launchpad.net/win32-image-writer. Run the program. Select the arch image-file and usb stick. The Win32 Disk Imager's file browser assumes image files end with .img, so if the image-file you've selected ends with .iso, you will have to type its name in manually; this difference in suffixes is simply cosmetic however, the image will be written fine regardless. Click on the write button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
=== Linux Live USB Creator ===<br />
<br />
LiLi USB Creator can be used to create a bootable USB key for Arch either using a manually downloaded iso or automatically downloading the iso itself.<br />
It also supports automatic installation of VirtualBox on the USB key which can be used to boot Arch inside Windows.<br />
<br />
The steps involved are well described by LiLi itself but can be summarized to: download & install LiLi, download Arch iso, insert USB key, start LiLi & choose drive (1), source (2), options (4) and create (5).<br />
<br />
I have tested all features except the automatic download of iso, and all works and are quite fast.<br />
<br />
=== The Universal USB Installer ===<br />
<br />
I had problems booting from a USB key created with flashnul under Windows or dd under Linux.<br />
I gave a try to the "Universal USB Installer" and it created the bootable USB key which worked fine.<br />
<br />
=== The Flashnul Way ===<br />
<br />
From a command prompt, invoke flashnul with -p, and determine which device index is your USB drive. For example, my output looks like this:<br />
<br />
C:\>flashnul -p<br />
<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
<br />
In my case, it is drive E:<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, -L, and the path to your image. In my case, it would be<br />
<br />
C:\>flashnul E: -L path\to\arch.iso<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
<b>Note:</b><br />
<i>Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64. -bgalakazam</i><br />
<br />
=== The Cygwin Way ===<br />
<br />
Make sure your cygwin installation contains the dd package.<br />
Or if you don't want to install Cygwin, you can simply download dd for windows from http://www.chrysocome.net/dd.<br />
<br />
Place your image file in your home directory, in my case it is:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]:<br />
<br />
where image.iso is the path to the iso-image file within the cygwin directory and \\.\[x]: is your USB device where x is the windows designated letter, in my case "\\.\d:".<br />
<br />
On cygwin 6.0 find out the correct partition with <br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
dd if=image.iso of=/dev/sdb<br />
<br />
'''Note:''' This will irrevocably delete all files on your USB stick, so make sure you don't have any important files on the stick before doing this.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using UNetBootin ([[#UNetBootin|see above]])<br />
<br />
==Old Method from ISO, deprecated==<br />
*Prepare USB stick:<br />
The arch-ftp.img is about 150 MB, so it should fit on a 256 MB USB stick. The arch-core.img is ~300 MB and should fit on a 512 MB stick.<br />
<br />
1. Partition the USB stick.<br />
Create one partition with FAT16 type, make it bootable. Remember its name, such as /dev/sd[x]1.<br />
<br />
cfdisk /dev/sd[x]<br />
<br />
2. Make a FAT16 filesystem (you need dosfstools)<br />
<br />
mkdosfs /dev/sd[x]1<br />
<br />
3. Get the arch-base install ISO from www.archlinux.org<br />
<br />
4. Mount the iso to an temporary directory<br />
<br />
mkdir -p /mnt/archcd<br />
mount -o loop /Path/to/iso /mnt/archcd<br />
<br />
5. Mount the USB Stick<br />
<br />
mkdir -p /mnt/usb/<br />
mount /dev/sd[x]1 /mnt/usb/<br />
<br />
6. Copy the .iso to the USB Stick<br />
<br />
cp -ra /mnt/archcd/* /mnt/usb/<br />
<br />
<br />
7. Copy the boot data<br />
<br />
cd /mnt/usb/isolinux/<br />
cp vmlinuz /mnt/usb/<br />
cp initrd.img /mnt/usb/<br />
cp boot.* /mnt/usb/<br />
cp isolinux.cfg /mnt/usb/syslinux.cfg<br />
<br />
'''Note:''' for release 2010.05, replace those command lines by the following<br />
<br />
cd /mnt/usb/<br />
cp boot/isolinux/isolinux.cfg ./syslinux.cfg<br />
sed /IPAPPEND/d syslinux.cfg<br />
cp /usr/lib/syslinux/vesamenu.c32 ./<br />
cp /usr/lib/syslinux/chain.c32 ./<br />
cp /usr/lib/syslinux/reboot.c32 ./<br />
<br />
8. Install MBR and syslinux<sup>(1)</sup><br />
<br />
lilo -M /dev/sd[x] mbr<br />
syslinux -s /dev/sd[x]1<br />
<br />
'''Note:''' for release 2010.05, replace those command lines by the following<br />
<br />
syslinux --install /dev/sd[x]1<br />
cat /usr/lib/syslinux/mbr.bin > /dev/sd[x]<br />
<br />
===After booting from the USB stick:===<br />
<br />
Start the installation by logging in as root and invoke the command "/arch/setup".<br />
<br />
The installer should mount the source media automatically. If it fails you can manually mount the source media on the stick to the /src directory with the following command:<br />
<br />
mount /dev/sd[x] /src<br />
<br />
===Notes and Troubleshooting:===<br />
<br />
<sup>(1)</sup> Using lilo is not really needed because syslinux does the "floppy" loading stuff. But if you get some error like "Can't load operating system" you have to perform the lilo command.<br />
<br />
<sup>(2)</sup> If you get "Cluster sizes larger than 16K not supported" error when booting this means you need to install more recent version of syslinux.<br />
<br />
<sup>(3)</sup> Space not used on the USB stick can still be used for storing files... Use a utility like gparted and add a partition to the unused space.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=USB_flash_installation_medium&diff=144723USB flash installation medium2011-06-10T03:05:38Z<p>JaMeSiTeGeN: /* Arch USB images */</p>
<hr />
<div>[[Category:Getting and installing Arch (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Install from a USB flash drive}}<br />
[[de:Installation von einem USB-Stick]]<br />
<br />
This page discusses how to put Arch installation media onto a USB key (or "flash drive"). The result will be a LiveCD-like system that will discard all changes when it's shut down. Consider whether you're instead interested in [[Installing Arch Linux on a USB key]].<br />
<br />
== On GNU/Linux ==<br />
<br />
=== Arch USB images ===<br />
<br />
Beginning from release 2010.05, all iso files can be directly written to usb media. Download them from your [http://archlinux.org/download/ local mirror]. To install, first ensure the USB device is '''unmounted''' and then issue the following command:<br />
<br />
$ dd if=archlinux.iso of=/dev/sd[x]<br />
<br />
where ''archlinux.iso'' is the path to the iso file and ''/dev/sd[x]'' is your USB device.<br />
<br />
{{Note|You can also add bs&#61;4M to speed up the dd process..}}<br />
<br />
{{Warning|This will irrevocably destroy all data on /dev/sdx.}}<br />
<br />
{{Warning|Make sure to use /dev/sdx and NOT /dev/sdx1. '''This is a very common error!'''}}<br />
<br />
<br />
brain0 made a nice post on his blog on [http://archlinux.me/brain0/2010/05/29/arch-linux-usb-install-and-resuce-media/ Arch Linux USB Install and Rescue Media] where he explains how to have several partitions on the USB stick with some accessible from windows.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using [http://unetbootin.sourceforge.net/ UNetBootin]. This application can download most distributions for you and write them to your flash drive. UNetbootin can download the latest Arch core or netinstall iso for you, or you can supply a manually downloaded one.<br />
<br />
It might happen that UNetBootin fails to start showing the following error.<br />
**<br />
GLib-GIO:ERROR:gdbusconnection.c:2270:initable_init: assertion failed: (connection->initialization_error == NULL)<br />
<br />
If this happens try to start it with the following command as normal user.<br />
<br />
# su -c "dbus-launch --exit-with-session unetbootin"<br />
<br />
If using a version of UNetbootin older than 549, then after it finishes, you will have to adjust syslinux.cfg on the root of your flash drive before rebooting. Correct the "archisolabel=" parameter to reflect the label of the USB drive you used, i.e.:<br />
<br />
append initrd=/ubninit archisolabel=<label> tmpfs_size=75% locale=en_US.UTF-8<br />
<br />
=== Gujin ===<br />
<br />
A third method is to follow the instructions about [http://psychoticspoon.blogspot.com/2009/01/booting-multiple-livecds-from-single.html Booting multiple LiveCD's from a single USB stick]. In a nutshell, you create 2 partitions on your USB drive, copy the [http://gujin.sourceforge.net/ Gujin] boot loader image to the first partition, and copy Arch's ISO to the second.<br />
<br />
== On Mac OS X ==<br />
<br />
To be able to use dd on your usb device on a Mac you have to do some special maneuvers. First of all insert your usb device, OS X will automount it, and run<br />
<br />
diskutil list<br />
<br />
in Terminal.app. Figure out what your usb device is called - mine was called /dev/disk1. (Just use the `mount` command or `sudo dmesg | tail`.) Now you run<br />
<br />
diskutil unmountDisk /dev/disk1<br />
<br />
to unmount the partitions on the device (i.e., /dev/disk1s1) while keeping the device proper (i.e., /dev/disk1). Now we can continue in accordance with the Linux instructions above (but use bs=8192 if you're using the OS X dd, the number comes from 1024*8).<br />
<br />
dd if=image.iso of=/dev/disk1 bs=8192<br />
20480+0 records in<br />
20480+0 records out<br />
167772160 bytes transferred in 220.016918 secs (762542 bytes/sec)<br />
<br />
== On Windows ==<br />
<br />
To write the USB image on Windows, you will need [http://launchpad.net/win32-image-writer Image Writer for Windows], [http://www.linuxliveusb.com/ Linux Live USB Creator], [http://www.pendrivelinux.com/universal-usb-installer-easy-as-1-2-3/ Universal USB Installer], [http://shounen.ru/soft/flashnul/ flashnul] ([http://translate.google.com/translate?u=http%3A%2F%2Fshounen.ru%2Fsoft%2Fflashnul%2F&hl=en&ie=UTF8&sl=ru&tl=en English version of the page]), [http://www.cygwin.com/ Cygwin], or [http://unetbootin.sourceforge.net/ UNetBootin].<br />
<br />
=== Image Writer for Windows ===<br />
Image Writer is the only native Windows image writer (except Cygwin) that writes the whole image without any changes (like dd) - other writers unpack the image and then copy all the files to a FAT filesystem.<br />
<br />
Download win32 disk imager from http://launchpad.net/win32-image-writer. Run the program. Select the arch image-file and usb stick. The Win32 Disk Imager's file browser assumes image files end with .img, so if the image-file you've selected ends with .iso, you will have to type its name in manually; this difference in suffixes is simply cosmetic however, the image will be written fine regardless. Click on the write button. Now you should be able to boot from the usb stick and install Arch Linux from it.<br />
<br />
=== Linux Live USB Creator ===<br />
<br />
LiLi USB Creator can be used to create a bootable USB key for Arch either using a manually downloaded iso or automatically downloading the iso itself.<br />
It also supports automatic installation of VirtualBox on the USB key which can be used to boot Arch inside Windows.<br />
<br />
The steps involved are well described by LiLi itself but can be summarized to: download & install LiLi, download Arch iso, insert USB key, start LiLi & choose drive (1), source (2), options (4) and create (5).<br />
<br />
I have tested all features except the automatic download of iso, and all works and are quite fast.<br />
<br />
=== The Universal USB Installer ===<br />
<br />
I had problems booting from a USB key created with flashnul under Windows or dd under Linux.<br />
I gave a try to the "Universal USB Installer" and it created the bootable USB key which worked fine.<br />
<br />
=== The Flashnul Way ===<br />
<br />
From a command prompt, invoke flashnul with -p, and determine which device index is your USB drive. For example, my output looks like this:<br />
<br />
C:\>flashnul -p<br />
<br />
Avaible physical drives:<br />
Avaible logical disks:<br />
C:\<br />
D:\<br />
E:\<br />
<br />
In my case, it is drive E:<br />
<br />
When you have determined which device is the correct one, you can write the image to your drive, by invoking flashnul with the device index, -L, and the path to your image. In my case, it would be<br />
<br />
C:\>flashnul E: -L path\to\arch.iso<br />
<br />
As long as you are really sure you want to write the data, type yes, then wait a bit for it to write. If you get an access denied error, close any Explorer windows you have open.<br />
<br />
If under Vista or Win7, you should open the console as administrator, or else flashnul will fail to open the stick as a block device and will only be able to write via the drive handle windows provides<br />
<br />
<b>Note:</b><br />
<i>Confirmed that you need to use drive letter as opposed to number. flashnul 1rc1, Windows 7 x64. -bgalakazam</i><br />
<br />
=== The Cygwin Way ===<br />
<br />
Make sure your cygwin installation contains the dd package.<br />
Or if you don't want to install Cygwin, you can simply download dd for windows from http://www.chrysocome.net/dd.<br />
<br />
Place your image file in your home directory, in my case it is:<br />
<br />
C:\cygwin\home\John\<br />
<br />
Run cygwin as administrator (required for cygwin to access hardware). To write to your USB drive use the following command:<br />
<br />
dd if=image.iso of=\\.\[x]:<br />
<br />
where image.iso is the path to the iso-image file within the cygwin directory and \\.\[x]: is your USB device where x is the windows designated letter, in my case "\\.\d:".<br />
<br />
On cygwin 6.0 find out the correct partition with <br />
<br />
cat /proc/partitions<br />
<br />
and write the ISO image with the information from the output. Example:<br />
<br />
dd if image.iso of=/dev/sdb<br />
<br />
'''Note:''' This will irrevocably delete all files on your USB stick, so make sure you don't have any important files on the stick before doing this.<br />
<br />
=== UNetBootin ===<br />
<br />
Another way to make a USB drive bootable, is by using UNetBootin ([[#UNetBootin|see above]])<br />
<br />
==Old Method from ISO, deprecated==<br />
*Prepare USB stick:<br />
The arch-ftp.img is about 150 MB, so it should fit on a 256 MB USB stick. The arch-core.img is ~300 MB and should fit on a 512 MB stick.<br />
<br />
1. Partition the USB stick.<br />
Create one partition with FAT16 type, make it bootable. Remember its name, such as /dev/sd[x]1.<br />
<br />
cfdisk /dev/sd[x]<br />
<br />
2. Make a FAT16 filesystem (you need dosfstools)<br />
<br />
mkdosfs /dev/sd[x]1<br />
<br />
3. Get the arch-base install ISO from www.archlinux.org<br />
<br />
4. Mount the iso to an temporary directory<br />
<br />
mkdir -p /mnt/archcd<br />
mount -o loop /Path/to/iso /mnt/archcd<br />
<br />
5. Mount the USB Stick<br />
<br />
mkdir -p /mnt/usb/<br />
mount /dev/sd[x]1 /mnt/usb/<br />
<br />
6. Copy the .iso to the USB Stick<br />
<br />
cp -ra /mnt/archcd/* /mnt/usb/<br />
<br />
<br />
7. Copy the boot data<br />
<br />
cd /mnt/usb/isolinux/<br />
cp vmlinuz /mnt/usb/<br />
cp initrd.img /mnt/usb/<br />
cp boot.* /mnt/usb/<br />
cp isolinux.cfg /mnt/usb/syslinux.cfg<br />
<br />
'''Note:''' for release 2010.05, replace those command lines by the following<br />
<br />
cd /mnt/usb/<br />
cp boot/isolinux/isolinux.cfg ./syslinux.cfg<br />
sed /IPAPPEND/d syslinux.cfg<br />
cp /usr/lib/syslinux/vesamenu.c32 ./<br />
cp /usr/lib/syslinux/chain.c32 ./<br />
cp /usr/lib/syslinux/reboot.c32 ./<br />
<br />
8. Install MBR and syslinux<sup>(1)</sup><br />
<br />
lilo -M /dev/sd[x] mbr<br />
syslinux -s /dev/sd[x]1<br />
<br />
'''Note:''' for release 2010.05, replace those command lines by the following<br />
<br />
syslinux --install /dev/sd[x]1<br />
cat /usr/lib/syslinux/mbr.bin > /dev/sd[x]<br />
<br />
===After booting from the USB stick:===<br />
<br />
Start the installation by logging in as root and invoke the command "/arch/setup".<br />
<br />
The installer should mount the source media automatically. If it fails you can manually mount the source media on the stick to the /src directory with the following command:<br />
<br />
mount /dev/sd[x] /src<br />
<br />
===Notes and Troubleshooting:===<br />
<br />
<sup>(1)</sup> Using lilo is not really needed because syslinux does the "floppy" loading stuff. But if you get some error like "Can't load operating system" you have to perform the lilo command.<br />
<br />
<sup>(2)</sup> If you get "Cluster sizes larger than 16K not supported" error when booting this means you need to install more recent version of syslinux.<br />
<br />
<sup>(3)</sup> Space not used on the USB stick can still be used for storing files... Use a utility like gparted and add a partition to the unused space.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Acer_Aspire_5745g&diff=143596Acer Aspire 5745g2011-06-02T11:15:02Z<p>JaMeSiTeGeN: /* Networking */</p>
<hr />
<div>[[Category:Acer (English)]]<br />
=Introduction=<br />
General info about the Acer Aspire 5745G<br />
<br />
=Hardware=<br />
'''Processor:''' Intel Core i5-450M 2.4GHz<br />
<br />
'''Video:''' Intel Integrated Graphics and NVIDIA GeForce GT 330M switchable (Second Generation)<br />
<br />
'''Audio:''' Intel Corporation 5 Series/3400 Series Chipset High Definition Audio (rev 05)<br />
<br />
'''Wired NIC:''' Atheros Communications AR8151 v1.0 Gigabit Ethernet (rev c0)<br />
<br />
''' Wireless NIC:''' Broadcom Corporation BCM43225 802.11b/g/n (rev 01)<br />
<br />
<br />
$ lspci -nn<br />
00:00.0 Host bridge [0600]: Intel Corporation Core Processor DRAM Controller [8086:0044] (rev 18)<br />
00:01.0 PCI bridge [0604]: Intel Corporation Core Processor PCI Express x16 Root Port [8086:0045] (rev 18)<br />
00:16.0 Communication controller [0780]: Intel Corporation 5 Series/3400 Series Chipset HECI Controller [8086:3b64] (rev 06)<br />
00:1a.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b3c] (rev 05)<br />
00:1b.0 Audio device [0403]: Intel Corporation 5 Series/3400 Series Chipset High Definition Audio [8086:3b56] (rev 05)<br />
00:1c.0 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 1 [8086:3b42] (rev 05)<br />
00:1c.5 PCI bridge [0604]: Intel Corporation 5 Series/3400 Series Chipset PCI Express Root Port 6 [8086:3b4c] (rev 05)<br />
00:1d.0 USB Controller [0c03]: Intel Corporation 5 Series/3400 Series Chipset USB2 Enhanced Host Controller [8086:3b34] (rev 05)<br />
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 Mobile PCI Bridge [8086:2448] (rev a5)<br />
00:1f.0 ISA bridge [0601]: Intel Corporation Mobile 5 Series Chipset LPC Interface Controller [8086:3b09] (rev 05)<br />
00:1f.2 SATA controller [0106]: Intel Corporation 5 Series/3400 Series Chipset 4 port SATA AHCI Controller [8086:3b29] (rev 05)<br />
00:1f.3 SMBus [0c05]: Intel Corporation 5 Series/3400 Series Chipset SMBus Controller [8086:3b30] (rev 05)<br />
00:1f.6 Signal processing controller [1180]: Intel Corporation 5 Series/3400 Series Chipset Thermal Subsystem [8086:3b32] (rev 05)<br />
01:00.0 VGA compatible controller [0300]: nVidia Corporation GT216 [GeForce GT 330M] [10de:0a29] (rev a2)<br />
01:00.1 Audio device [0403]: nVidia Corporation High Definition Audio Controller [10de:0be2] (rev a1)<br />
02:00.0 Ethernet controller [0200]: Atheros Communications AR8151 v1.0 Gigabit Ethernet [1969:1073] (rev c0)<br />
03:00.0 Network controller [0280]: Broadcom Corporation BCM43225 802.11b/g/n [14e4:4357] (rev 01)<br />
3f:00.0 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture Generic Non-core Registers [8086:2c62] (rev 05)<br />
3f:00.1 Host bridge [0600]: Intel Corporation Core Processor QuickPath Architecture System Address Decoder [8086:2d01] (rev 05)<br />
3f:02.0 Host bridge [0600]: Intel Corporation Core Processor QPI Link 0 [8086:2d10] (rev 05)<br />
3f:02.1 Host bridge [0600]: Intel Corporation Core Processor QPI Physical 0 [8086:2d11] (rev 05)<br />
3f:02.2 Host bridge [0600]: Intel Corporation Core Processor Reserved [8086:2d12] (rev 05)<br />
3f:02.3 Host bridge [0600]: Intel Corporation Core Processor Reserved [8086:2d13] (rev 05)<br />
<br />
=Networking=<br />
<br />
The current livecd release 2010.05 doesn't support either the ethernet or the wireless, which can put you in a rather uncomfortable spot, especially if you were hoping to netinstall.<br />
<br />
The older kernel in the 2010 build doesn't support either, though newer versions of the kernel do. Use a more recent iso from the [http://releng.archlinux.org/isos/ testiso] to do your install and it should find both cards just fine (for reference, I used 2011.04.10, which is no longer avaliable, see the latest and hope that it works!)<br />
<br />
==Wireless==<br />
<br />
The brcm80211 driver is included in the kernel since 2.6.37. No further action is necessary on the part of the user. See [[Wireless Setup]] if you have problems.<br />
<br />
You can manage your wireless connections with [[NetworkManager]] or [[Wicd]].<br />
<br />
=Power Management=<br />
<br />
==CPU frequency scaling==<br />
<br />
===The laptop-mode-tools way===<br />
<br />
You probably want to use laptop-mode-tools with acpi.<br />
pacman -S laptop-mode-tools acpi<br />
<br />
===Another method===<br />
<br />
In /etc/rc.conf, add the following modules :<br />
[...]<br />
<br />
MODULES=( ... '''acpi-cpufreq cpufreq_ondemand''')<br />
<br />
[...]<br />
<br />
And put the following lines in /etc/rc.local :<br />
<br />
[...]<br />
<br />
echo "ondemand" > /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor<br />
echo "ondemand" > /sys/devices/system/cpu/cpu1/cpufreq/scaling_governor<br />
echo "ondemand" > /sys/devices/system/cpu/cpu2/cpufreq/scaling_governor<br />
echo "ondemand" > /sys/devices/system/cpu/cpu3/cpufreq/scaling_governor<br />
<br />
=Xorg=<br />
<br />
To get the video card to behave, I went into BIOS and set the graphics card mode to Discrete instead of Switching<br />
<br />
You will want to install the Nvidia drivers<br />
<br />
$ sudo pacman -S nvidia nvidia-utils<br />
<br />
If you are already running [[xorg]] with vesa or [[nouveau]] (which works btw) you will need to restart for nouveau to be blacklisted.<br />
<br />
Then you should be able to<br />
<br />
$ sudo nvidia-xconfig<br />
$ startx<br />
<br />
See [[nvidia]].<br />
<br />
=Touchpad=<br />
You should install ''xf86-input-synaptics'', worked out of the box for me with xorg.<br />
<br />
If you want to use your mouse without xorg, you can use [[GPM]]<br />
<br />
$ sudo gpm /dev/input/mouse0 -t ps2<br />
<br />
=Hotkeys=<br />
<br />
Volume up/down & mute can be mapped with [[xbindkeys]].<br />
<br />
$ pacman -S xbindkeys alsa-utils<br />
<br />
and then edit ~/.xbindkeysrc and add:<br />
# Increase volume<br />
"amixer set Master playback 1+"<br />
m:0x10 + c:123<br />
Mod2 + XF86AudioRaiseVolume <br />
# Decrease volume<br />
"amixer set Master playback 1-"<br />
m:0x10 + c:122<br />
Mod2 + XF86AudioLowerVolume<br />
# Toggle mute<br />
"amixer set Master toggle"<br />
m:0x10 + c:121<br />
Mod2 + XF86AudioMute<br />
<br />
then edit your ~/.xinitrc file and add<br />
<br />
xbindkeys &<br />
<br />
somewhere before your exec line.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Syslinux&diff=143592Syslinux2011-06-02T10:44:36Z<p>JaMeSiTeGeN: /* Using memtest */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
{{i18n|Syslinux}}<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Describes installing and configuring Syslinux, a collection of bootloaders.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Boot process overview}}}}<br />
{{Article summary end}}<br />
<br />
Syslinux is a collection of boot loaders capable of booting from hard drives, CDs and over the network via PXE. It supports the fat, ext2, ext3, ext4 and btrfs file systems.<br />
<br />
{{Note|Since Syslinux 4, Extlinux and Syslinux are the same thing.}} <br />
<br />
== Syslinux Boot Process ==<br />
<br />
At boot, the computer loads the [[MBR]] ({{Filename|/usr/lib/syslinux/mbr.bin}}). Then the MBR looks for the partition that is marked as active (boot flag). Once found, the volume boot record (VBR) will be executed. In the case of ext2/3/4 and fat12/16/32, the starting sector of {{Filename|ldlinux.sys}} is hard-coded into the VBR. The VBR will execute ({{Filename|ldlinux.sys}}). Therefore, if the location of {{Filename|ldlinux.sys}} changes, syslinux will no longer boot. In the case of btrfs, the above method will not work since files move around resulting in the sector location of {{Filename|ldlinux.sys}} changing. Therefore, the entire Syslinux code needs to be stored outside the filesystem. The code is stored in the sectors following the VBR. Once Syslinux is fully loaded, it looks for a configuration file, either {{Filename|extlinux.conf}} or {{Filename|syslinux.cfg}}. If one is found, the configuration file is loaded. If no configuration file is found you will be given a syslinux prompt.<br />
<br />
==Installation==<br />
===Automatic Install - syslinux===<br />
The syslinux-install_update script will install Syslinux, copy COM32 modules to {{Filename|/boot/syslinux}}, set the boot flag and install the MBR. It can handle MBR and GPT disks along with softraid.<br />
<br />
1. Install Syslinux<br />
pacman -Syu syslinux<br />
2. Make sure {{Filename|/boot}} is mounted<br/><br />
3. Run syslinux-install_update script -i (install) -a (set boot flag) -m (install mbr)<br />
/usr/sbin/syslinux-install_update -iam<br />
4. Edit {{Filename|/boot/syslinux/syslinux.cfg}}<br />
<br />
<br />
===Manual Install - syslinux===<br />
{{Note| If you are unsure of which partition table you are using (MBR or GPT), you are likely using the MBR partition table. Most of the time, GPT will create a special MBR-style partition (type 0xEE) using the whole disk which will be displayed with the following command:<br />
# fdisk -l /dev/sda<br />
or alternatively<br />
# sgdisk -l /dev/sda<br />
will show " GPT: not present" if it is not a GPT disk.<br />
}}<br />
<br />
{{Note| If you are trying to rescue an installed system with a live CD, be sure to [[Change_Root|chroot]] into it before executing these commands. If you do not chroot first, you must prepend all file paths (not /dev/ paths) with the mount point.}}<br />
<br />
Make sure you have the ''syslinux'' package installed. Then install Syslinux onto your boot partition, which must contain a fat, ext2, ext3, ext4, or btrfs file system.<br />
# mkdir /boot/syslinux<br />
# extlinux --install /boot/syslinux #run on a mounted directory (not /dev/sdXY)<br />
/boot/syslinux/ is device /dev/sda1<br />
<br />
====MBR Partition Table====<br />
Next, you need mark your boot partition active in your partition table. Applications capable of doing this include fdisk, cfdisk, sfdisk, (g)parted. It should look like this:<br />
# fdisk -l /dev/sda<br />
[...]<br />
Device Boot Start End Blocks Id System<br />
/dev/sda1 * 2048 104447 51200 83 Linux<br />
/dev/sda2 104448 625142447 312519000 83 Linux<br />
<br />
Install the master boot record:<br />
# dd bs=440 conv=notrunc count=1 if=/usr/lib/syslinux/mbr.bin of=/dev/sda<br />
<!-- conv=notrunc helps if /dev/sda is actually a file not a block device --><br />
<br />
====GUID Partition Table aka GPT====<br />
<br />
Main article [[GUID_Partition_Table]]<br />
<br />
Bit 2 of the attributes for the /boot partition need to be set.<br />
<br />
# sgdisk /dev/sda --attributes=1:set:2<br />
<br />
This would toggle the attribute legacy bios bootable on partition 1 <br />
<br />
Verify:<br />
# sgdisk /dev/sda --attributes=1:show<br />
1:2:1 (legacy BIOS bootable)<br />
<br />
Install the master boot record:<br />
# dd bs=440 conv=notrunc count=1 if=/usr/lib/syslinux/gptmbr.bin of=/dev/sda<br />
<br />
====Rebooting====<br />
When you reboot your system now, you will have a syslinux prompt. To automatically boot your system or get a boot menu, you still need to create a configuration file.<br />
<br />
== Configuring syslinux ==<br />
<br />
The syslinux configuration file, {{Filename|syslinux.cfg}} should be created in the same directory where you installed syslinux. In our case '/boot/syslinux/'<br />
<br />
The bootloader will look for either {{Filename|syslinux.cfg}} (preferred) or {{Filename| extlinux.conf}}<br />
<br />
'''Tips''':<br />
*Instead of LINUX, the keyword KERNEL can also be used. KERNEL tries to detect the type of the file, while LINUX always expects a Linux kernel.<br />
*TIMEOUT value is in units of 1/10 of a second.<br />
<br />
=== Examples ===<br />
==== Basic Syslinux Config ====<br />
<br />
This is a simple configuration file that will show a boot: prompt and automatically boot after 5 seconds.<br />
<br />
Config:<br />
PROMPT 1<br />
TIMEOUT 50<br />
DEFAULT arch<br />
<br />
LABEL arch<br />
LINUX ../vmlinuz26<br />
APPEND root=/dev/sda2 ro<br />
INITRD ../kernel26.img<br />
<br />
LABEL archfallback<br />
LINUX ../vmlinuz26<br />
APPEND root=/dev/sda2 ro<br />
INITRD ../kernel26-fallback.img<br />
<br />
If you want to boot directly without seeing a prompt, set PROMPT to 0. <br />
<br />
==== Text Boot menu ====<br />
<br />
Syslinux also allows you to use a boot menu. To use it, copy the menu COM32 module to your syslinux folder:<br />
# cp /usr/lib/syslinux/menu.c32 /boot/syslinux/<br />
If /boot is the same partition as /, a symlink will also work:<br />
# ln -s /usr/lib/syslinux/menu.c32 /boot/syslinux/<br />
<br />
Config:<br />
UI menu.c32<br />
PROMPT 0<br />
<br />
MENU TITLE Boot Menu<br />
TIMEOUT 50<br />
DEFAULT arch<br />
<br />
LABEL arch<br />
MENU LABEL Arch Linux<br />
LINUX ../vmlinuz26<br />
APPEND root=/dev/sda2 ro<br />
INITRD ../kernel26.img<br />
<br />
LABEL archfallback<br />
MENU LABEL Arch Linux Fallback<br />
LINUX /vmlinuz26<br />
APPEND root=/dev/sda2 ro<br />
INITRD /kernel26-fallback.img<br />
<br />
For more details about the menu system, see http://git.kernel.org/?p=boot/syslinux/syslinux.git;a=blob;f=doc/menu.txt.<br />
<br />
==== Graphical Boot menu ====<br />
<br />
Syslinux also allows you to use a graphical boot menu. To use it, copy the vesamenu COM32 module to your syslinux folder:<br />
# cp /usr/lib/syslinux/vesamenu.c32 /boot/syslinux/<br />
If /boot is the same partition as /, a symlink will also work:<br />
# ln -s /usr/lib/syslinux/vesamenu.c32 /boot/syslinux/<br />
<br />
This config uses the same menu design as the Arch Install CD: [http://projects.archlinux.org/archiso.git/tree/configs/syslinux-iso/boot-files/syslinux/syslinux.cfg syslinux.cfg]<br />
<br />
The background file can be found here: [http://projects.archlinux.org/archiso.git/plain/configs/syslinux-iso/boot-files/splash.png splash.png]<br />
<br />
Config:<br />
UI vesamenu.c32<br />
DEFAULT arch<br />
PROMPT 0<br />
MENU TITLE Boot Menu<br />
MENU BACKGROUND splash.png<br />
TIMEOUT 50<br />
<br />
MENU WIDTH 78<br />
MENU MARGIN 4<br />
MENU ROWS 5<br />
MENU VSHIFT 10<br />
MENU TIMEOUTROW 13<br />
MENU TABMSGROW 11<br />
MENU CMDLINEROW 11<br />
MENU HELPMSGROW 16<br />
MENU HELPMSGENDROW 29<br />
<br />
# Refer to http://syslinux.zytor.com/wiki/index.php/Doc/menu<br />
<br />
MENU COLOR border 30;44 #40ffffff #a0000000 std<br />
MENU COLOR title 1;36;44 #9033ccff #a0000000 std<br />
MENU COLOR sel 7;37;40 #e0ffffff #20ffffff all<br />
MENU COLOR unsel 37;44 #50ffffff #a0000000 std<br />
MENU COLOR help 37;40 #c0ffffff #a0000000 std<br />
MENU COLOR timeout_msg 37;40 #80ffffff #00000000 std<br />
MENU COLOR timeout 1;37;40 #c0ffffff #00000000 std<br />
MENU COLOR msg07 37;40 #90ffffff #a0000000 std<br />
MENU COLOR tabmsg 31;40 #30ffffff #00000000 std<br />
<br />
<br />
LABEL arch<br />
MENU LABEL Arch Linux<br />
LINUX ../vmlinuz26<br />
APPEND root=/dev/sda2 ro<br />
INITRD ../kernel26.img<br />
<br />
<br />
LABEL archfallback<br />
MENU LABEL Arch Linux Fallback<br />
LINUX ../vmlinuz26<br />
APPEND root=/dev/sda2 ro<br />
INITRD ../kernel26-fallback.img<br />
<br />
<br />
Since Syslinux 3.84 vesamenu.c32 supports the "MENU RESOLUTION $WIDTH $HEIGHT" directive.<br />
To use it, insert "MENU RESOLUTION 1440 900" into your config for a 1440x900 resolution.<br />
The background picture has to have exactly the right resolution however as syslinux will otherwise refuse to load the menu.<br />
=== Chainloading ===<br />
<br />
If you want to chainload other operating systems (such as Windows) or boot loaders, copy (or symlink) the ''chain.c32'' module to the syslinux folder (for details, see the instructions in the previous section). Then, create a section in the configuration file:<br />
<br />
LABEL windows<br />
MENU LABEL Windows<br />
COM32 chain.c32<br />
APPEND hd0 3<br />
<br />
''hd0 3'' is the third partition on the first BIOS drive - drives are counted from zero, but partitions are counted from one. For more details about chainloading, see [http://syslinux.zytor.com/wiki/index.php/Comboot/chain.c32].<br />
<br />
If you have [[grub2]] installed in your boot partition, you can chainload it by using: <br />
<br />
LABEL grub2<br />
MENU LABEL Grub2<br />
COM32 chain.c32<br />
append file=../grub/boot.img<br />
<br />
This maybe required for booting from iso images.<br />
<br />
=== Using memtest ===<br />
<br />
Use this LABEL section to launch memtest (install the ''memtest86+'' package):<br />
<br />
LABEL memtest<br />
MENU LABEL Memtest86+<br />
LINUX /memtest86+/memtest.bin<br />
<br />
Add /boot infront of /memtest86+/ if you have /boot on the same partition as /..<br />
<br />
=== HDT ===<br />
<br />
HDT (Hardware Detection Tool) displays hardware information. Like before, the .c32 file has to be copied or symlinked from /boot/syslinux/.<br />
For pci info either copy or symlink {{Filename|/usr/share/hwdata/pci.ids}} to {{Filename|/boot/syslinux/pci.ids}}<br />
<br />
LABEL hdt<br />
MENU LABEL Hardware Info<br />
COM32 hdt.c32<br />
<br />
=== Reboot and power off ===<br />
<br />
Use the following sections to reboot or power off your machine.<br />
<br />
LABEL reboot<br />
MENU LABEL Reboot<br />
COM32 reboot.c32<br />
<br />
LABEL poweroff<br />
MENU LABEL Power Off<br />
COMBOOT poweroff.com<br />
<br />
==Troubleshooting==<br />
===I have a Syslinux Prompt - Yikes!===<br />
You can type in the LABEL name of the entry that you want to boot (as per your syslinux.cfg). If you used the example configs just type<br />
boot: arch<br />
<br />
If you get an error that the config file could not be loaded you can pass your needed boot parameters<br />
boot: vmlinuz26 root=/dev/sda2 ro initrd=/kernel26.img<br />
<br />
===Windows boots up! No Syslinux!===<br />
'''Solution:''' Make sure the partition that contains /boot has the boot flag enabled. Also, make sure the boot flag is not enabled on the windows partition. See the installation section above.<br />
<br />
The MBR that comes with syslinux looks for the first active partition that has the boot flag set. The windows partition was likely found first and had the boot flag set. If you wanted you could use the MBR that windows or msdos fdisk provides.<br />
<br />
===Menu Entries do nothing===<br />
You select a menu entry and it does nothing. It "refreshes" the menu<br/><br />
This usually means that you have an error in your configuration. Hit {{Keypress| TAB }} to edit your boot parameters. Alternatively, press {{Keypress| ESC}} and type in the LABEL of your boot entry (Example: arch)<br />
<br />
<br />
===Can't remove ldlinux.sys===<br />
ldlinux.sys has the immutable attribute set which prevents the file from being deleted or overwritten. This is because the sector location of the file must not change or else syslinux has to be reinstalled.<br />
To remove: <br />
chattr -i /boot/syslinux/ldlinux.sys<br />
rm /boot/syslinux/ldlinux.sys<br />
<br />
== External link ==<br />
* [http://syslinux.zytor.com/ The Syslinux Project]'s website.</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Official_repositories&diff=142000Official repositories2011-05-19T08:32:21Z<p>JaMeSiTeGeN: /* [unsupported] a.k.a The AUR */</p>
<hr />
<div>[[Category:Package management (English)]]<br />
[[Category:About Arch (English)]]<br />
{{i18n|Official Repositories}}<br />
[[fr:Depots]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|Software repositories contain software compiled and packaged by developers and Trusted Users, readily accessible via pacman. This article outlines the official repositories provided and supported by Arch Linux developers.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Mirrors}}<br />
{{Article summary wiki|Arch User Repository}}<br />
{{Article summary wiki|Unofficial User Repositories}}<br />
{{Article summary end}}<br />
<br />
A [[Wikipedia:software repository|software repository]] is a storage location from which software packages may be retrieved and installed on a computer. Arch Linux [[Package Maintainer|package maintainers]] (developers and [[Trusted Users]]) maintain a number of official repositories containing software packages for essential and popular software, readily accessible via [[pacman]]. This article outlines those officially-supported repositories.<br />
<br />
== Historical background ==<br />
<br />
Most of the repository splits are for historical reasons. Originally, when Arch Linux was used by very few users, there was only one repository known as ''[official]'' (now '''[core]'''). At the time, [official] basically contained Judd Vinet's preferred applications. It was designed to contain one of each "type" of program -- one DE, one major browser, etc.<br />
<br />
There were users back then that didn't like Judd's selection, so since the [[Arch Build System]] is so easy to use, they created packages of their own. These packages went into a repository called ''[unofficial]'', and were maintained by developers other than Judd. Eventually, the two repositories were both considered equally supported by the developers, so the names [official] and [unofficial] no longer reflected their true purpose. They were subsequently renamed to ''[current]'' and ''[extra]'' sometime near the release version 0.5.<br />
<br />
Shortly after the 2007.8.1 release, [current] was renamed [core] in order to prevent confusion over what exactly it contains. The repositories are now more or less equal in the eyes of the developers and the community, but [core] does have some differences. The main distinction is that packages used for Installation CDs and release snapshots are taken only from [core]. This repository still gives a complete Linux system, though it may not be the Linux system you want.<br />
<br />
Now, sometime around 0.5 or 0.6, they found there were a lot of packages that the developers didn't want to maintain. One of the developers (Xentac) set up the "Trusted User Repositories", which were unofficial repositories in which trusted users could place packages they had created. There was a ''[staging]'' repository where packages could be promoted into the official repositories by one of the Arch Linux developers, but other than this, the developers and trusted users were more or less distinct.<br />
<br />
This worked for a while, but not when trusted users got bored with their repositories, and not when untrusted users wanted to share their own packages. This led to the development of the [http://aur.archlinux.org/ AUR]. The TUs were conglomerated into a more closely knit group, and they now collectively maintain the '''[community]''' repository. The Trusted Users are still a separate group from the Arch Linux developers, and there isn't a lot of communication between them. However, popular packages are still promoted from [community] to '''[extra]''' on occasion. The [http://aur.archlinux.org/ AUR] also supports allowing untrusted users to submit PKGBUILDs for other users to use if they wish. These packages are unsupported, and the packages are sometimes called the '''[unsupported]''' repository, though since no binary packages are distributed, unsupported isn't really a repository. Trusted users can adopt packages from unsupported into [community] at their discretion, whether it is because the package is popular or because they are interested in maintaining it.<br />
<br />
After a kernel in '''[core]''' [http://www.archlinux.org/news/please-avoid-kernel-261614-1/ broke many user systems] the "core signoff policy" was introduced, since then all package updates for [core] need to go through a '''[testing]''' repository first, only after multiple signoffs from other developers they were allowed to move. Over time it was noticed various [core] packages have low usage and user signoffs or even lack of bugreports became informally accepted as criteria to accept such packages.<br />
Late 2009/begin 2010, with the advent of some new filesystems (and the desire to support them during installation) and the realisation that the [core] repository was never clearly defined (just "importand packages, handpicked by developers") - although some developers required "enough usage among developers to warrant signoffs" before adoption into [core] - the repository received a more accurate description (see below).<br />
<br />
== [core] ==<br />
<br />
The [core] repository can be found in ''core/os/i686'' or ''core/os/x86_64'' on your favorite mirror.<br />
It has fairly strict quality requirements:<br />
* developers and/or users need to signoff on updates before package updates are accepted.<br />
* for packages with low usage a reasonable exposure (as in: inform people about update, request signoffs, keep in testing for a few days upto a week depending on the severity of the change) lack of outstanding bugreports, along with the implicit signoff of the package maintainer is enough).<br />
<br />
It contains packages which:<br />
<br />
* are needed to boot any kind of supported Arch system.<br />
* may be needed to connect to the internet.<br />
* are essential for package building.<br />
* can manage and check/repair supported filesystems.<br />
* virtually anyone will want or need early in the system setup process (like openssh).<br />
* are dependencies (but not necessarily makedepends) of the above.<br />
<br />
''This repository is included in the core installation media, so you can build a fully working base system without internet access.''<br />
<br />
== [extra] ==<br />
<br />
The [extra] repository can be found in ''extra/os/i686'' or ''extra/os/x86_64'' on your favorite mirror. It contains all packages that don't fit in [core]<br><br />
Example: X.org, window managers, web servers, media players, languages like Python and Ruby, and a lot more.<br />
<br />
== [community] ==<br />
<br />
The [community] repository can be found in ''community/os/i686'' or ''community/os/x86_64'' on your favorite mirror. It is maintained by the ''Trusted Users (TUs)'' and is part of the ''Arch User Repository (AUR)''. It contains packages from the ''AUR'' that have enough votes and were adopted by a ''TU''.<br />
<br />
== [multilib] ==<br />
<br />
The [multilib] repository can be found in ''multilib/os/x86_64'' on your favorite mirror. It contains 32 bit libraries that can be used to run 32 bit applications like the flash plugin and skype in 64 bit installation.<br />
<br />
== [testing] ==<br />
<br />
The [testing] repository can be found in ''testing/os/i686'' on your favorite mirror. [testing] is special because it contains packages that are candidates for the [core] or [extra] repositories. New packages go into [testing] if:<br />
* they are expected to break something on update and need to be tested first<br />
* they require other packages to be rebuilt. In this case, all packages that need to be rebuilt are put into [testing] first and when all rebuilds are done, they are moved back to the other repositories.<br />
<br />
[testing] is the only repository that can have name collisions with any of the other official repositories. If enabled, it has to be the first repo listed in your ''pacman.conf'' file.<br />
<br />
Be careful when enabling [testing]. Your system may break after you perform an update with the [testing] repository enabled. Only experienced users who know how to deal with potential system breakage should use it.<br />
<br />
The [testing] repo is not for the "newest of the new" package versions. Part of its purpose is to hold package updates that have the potential to cause system breakage, either by being part of the [core] set of packages, or by being critical in other ways. As such, users of the [testing] repository are strongly encouraged to subscribe to the arch-dev-public mailing list, and to report all bugs to the bug tracker.<br />
<br />
== [community-testing] ==<br />
<br />
The [community-testing] repository is like the [testing] repository but for packages that are candidates for the [community] repository.<br />
<br />
== [unsupported] a.k.a The AUR ==<br />
<br />
[unsupported] is the web based repository that is commonly referred to as the AUR, or Arch User Repository.* Users can submit source packages containing various build files including [[PKGBUILD]]s to this repo. This is an unofficial and unsupported repository which isn't directly accessible via pacman. To install a package from [unsupported] a user would have to download and extract the source package, run [[makepkg]] which downloads upstream sources and builds the package, and finally install the built package using pacman. One of the popular [[AUR Helpers]] may be used to help with these tasks.<br />
<br />
{{Note|Technically, both the [community] and [unsupported] repos make up the AUR.}}<br />
<br />
== Unofficial user repositories ==<br />
<br />
A few users run public but unofficial custom repos. See [[Unofficial User Repositories]].</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=SLiM&diff=141258SLiM2011-05-13T10:49:47Z<p>JaMeSiTeGeN: </p>
<hr />
<div>[[Category:Display managers (English)]]<br />
[[fr:SLiM]]<br />
{{i18n|SLiM}}<br />
{{Article summary start}}<br />
{{Article summary text|Provides an overview of the Simple Login Manager.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Display Manager}}<br />
{{Article summary end}}<br />
[http://slim.berlios.de/ SLiM] is an acronym for Simple Login Manager. SLiM is simple, lightweight and easily configurable. SLiM is used by some because it does not require the dependencies of [[GNOME]] or [[KDE]] and can help make a lighter system for users that like to use lightweight desktops like [[Xfce]], [[Openbox]], and [[Fluxbox]].<br />
<br />
== Installation ==<br />
<br />
Install SLiM from the '''extra''' repository:<br />
<br />
# pacman -S slim<br />
<br />
== Configuration ==<br />
<br />
=== Enabling SLiM ===<br />
<br />
SLiM can be loaded on startup by entering it in your daemons array in {{Filename|rc.conf}} or by modifying {{Filename|inittab}}. See [[Display Manager]] for detailed instructions.<br />
<br />
=== Single environments ===<br />
<br />
To configure SLiM to load a particular environment, edit your {{Filename|~/.xinitrc}} to load your desktop environment:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
#<br />
<br />
exec [session-command]<br />
</pre><br />
<br />
SLiM reads the local {{Filename|~/.xinitrc}} configuration and then launches the desktop according to what is in that file. If you do not have a {{Filename|~/.xinitrc}} file, you can use the skeleton file by:<br />
<br />
$ cp /etc/skel/.xinitrc ~<br />
<br />
Replace {{Codeline|[session-command]}} with the appropriate session command. Some examples of different desktop start commands:<br />
<br />
<pre><br />
exec awesome<br />
exec dwm<br />
exec fluxbox<br />
exec fvwm2<br />
exec gnome-session<br />
exec openbox-session<br />
exec startkde<br />
exec startlxde<br />
exec startxfce4<br />
exec enlightenment_start<br />
exec ck-launch-session $ONE_OF_THE_ABOVE<br />
</pre><br />
<br />
If your environment is not listed here, refer to the appropriate wiki page.<br />
<br />
=== PolicyKit ===<br />
<br />
If you have problems with PolicyKit, use ConsoleKit's {{Codeline|ck-launch-session}} by changing the <code>login_cmd</code> line of your <code>/etc/slim.conf</code> to:<br />
<br />
<pre><br />
login_cmd exec ck-launch-session /bin/bash -login ~/.xinitrc %session<br />
</pre><br />
<br />
and leave your <code>~/.xinitrc</code> as plain as possible; for instance:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec startxfce4 # or the window manager of your choice<br />
</pre><br />
<br />
=== Autologin ===<br />
<br />
To make SLiM automatically login as a specified user (without having to type a password) the following lines in /etc/slim.conf should be changed.<br />
<br />
<pre><br />
# default_user simone<br />
</pre><br />
<br />
Uncomment this line, and change "simone" to the user to be logged into automatically.<br />
<br />
<pre><br />
# auto_login no<br />
</pre><br />
<br />
Uncomment this line and change the 'no' to 'yes'. This enables the auto login feature.<br />
<br />
=== Multiple environments ===<br />
<br />
To be able to choose from multiple desktop environments, SLiM can be setup to log you into whichever you choose.<br />
<br />
Put a case statement similar to this one in your {{Filename|~/.xinitrc}} file and edit the sessions variable in {{Filename|/etc/slim.conf}} to match the names that trigger the case statement. You can choose the session at login time by pressing F1. Note that this feature is experimental.<br />
<br />
<pre><br />
# The following variable defines the session which is started if the user doesn't explicitly select a session<br />
# Source: http://svn.berlios.de/svnroot/repos/slim/trunk/xinitrc.sample<br />
<br />
DEFAULT_SESSION=twm<br />
<br />
case $1 in<br />
kde)<br />
exec startkde<br />
;;<br />
xfce4)<br />
exec startxfce4<br />
;;<br />
icewm)<br />
icewmbg &<br />
icewmtray &<br />
exec icewm<br />
;;<br />
wmaker)<br />
exec wmaker<br />
;;<br />
blackbox)<br />
exec blackbox<br />
;;<br />
*)<br />
exec $DEFAULT_SESSION<br />
;;<br />
esac<br />
</pre><br />
<br />
=== Themes ===<br />
<br />
Install the {{Package Official|slim-themes}} package:<br />
<br />
# pacman -S slim-themes archlinux-themes-slim<br />
<br />
The {{Package Official|archlinux-themes-slim}} packages contains several different themes. Look in the directory of {{Filename|/usr/share/slim/themes}} to see the themes available. Enter the theme name on the 'current_theme' line in {{Filename|/etc/slim.conf}}:<br />
<br />
#current_theme default<br />
current_theme archlinux-simplyblack<br />
<br />
To preview a theme run while an instance of the Xorg server is running by:<br />
<br />
$ slim -p /usr/share/slim/themes/<theme name><br />
<br />
To close, type "exit" in the Login line and press Enter.<br />
<br />
Additional theme packages can be found in the [[AUR]].<br />
<br />
==== Dual screen setup ====<br />
<br />
You can customize the slim theme in /usr/share/slim/themes/<your-theme>/slim.theme to turn these percents values. The box itself is 450 pixels by 250 pixels:<br />
<br />
input_panel_x 50%<br />
input_panel_y 50%<br />
<br />
into pixels values:<br />
<br />
# These settings set the "archlinux-simplyblack" panel in the center of a 1440x900 screen<br />
input_panel_x 495<br />
input_panel_y 325<br />
<br />
# These settings set the "archlinux-retro" panel in the center of a 1680x1050 screen<br />
input_panel_x 615<br />
input_panel_y 400<br />
<br />
If your theme has a background picture you should use the background_style setting ('stretch', 'tile', 'center' or 'color') to get it correctly displayed. Have a look at the [http://slim.berlios.de/themes_howto.php very simple and clear official documentation about slim themes] for further details.<br />
<br />
== Other options ==<br />
<br />
A few things you might like to try.<br />
<br />
=== Changing the cursor ===<br />
<br />
If you want to change the default X cursor to a newer design, the {{Package AUR|slim-cursor}} package is available.<br />
<br />
After installing, edit {{Filename|/etc/slim.conf}} and uncomment the line:<br />
<br />
cursor left_ptr<br />
<br />
This will give you a normal arrow instead. This setting is forwarded to {{Codeline|xsetroot -cursor_name}}. You can look up the possible cursor names [http://cvsweb.xfree86.org/cvsweb/*checkout*/xc/lib/X11/cursorfont.h?rev=HEAD&content-type=text/plain here] or in {{Filename|/usr/share/icons/<your-cursor-theme>/cursors/}}.<br />
<br />
To change the cursor theme being used at the login screen, make a file named {{Filename|/usr/share/icons/default/index.theme}} with this content:<br />
<br />
[Icon Theme]<br />
Inherits=<your-cursor-theme><br />
<br />
Replace <your-cursor-theme> with the name of the cursor theme you want to use (e.g. whiteglass).<br />
<br />
=== Match SLiM and Desktop Wallpaper ===<br />
<br />
To share a wallpaper between SLiM and your desktop, rename the used theme background, then create a link from your desktop wallpaper file to the default SLiM theme:<br />
<br />
# mv /usr/share/slim/themes/default/background.jpg{,.bck}<br />
# ln -s /path/to/mywallpaper.jpg /usr/share/slim/themes/default/background.jpg<br />
<br />
=== Shutdown, reboot, suspend, exit, launch terminal from SLiM ===<br />
<br />
You may shutdown, reboot, suspend, exit or even launch a terminal from the SLiM login screen. To do so, use the values in the username field, and the root password in the password field:<br />
<br />
* To launch a terminal, enter '''console''' as the username (defaults to xterm which must be installed separately... edit {{Filename|/etc/slim.conf}} to change terminal preference)<br />
* For shutdown, enter '''halt''' as the username<br />
* For reboot, enter '''reboot''' as the username<br />
* To exit to bash, enter '''exit''' as the username<br />
* For suspend, enter '''suspend''' as the username (suspend is disabled by default, edit {{Filename|/etc/slim.conf}} as root to uncomment the {{Filename|suspend_cmd}} line and, if necessary modify the suspend command itself (e.g. change {{Codeline|/usr/sbin/suspend}} to {{Codeline|sudo /usr/sbin/pm-suspend}}))<br />
<br />
=== SLiM init error with rc.d daemon ===<br />
<br />
If you initialize SLiM with {{Filename|/etc/rc.conf}} inside the DAEMONS array and it fails to initialize it's most likely a lock file issue. SLiM creates a lock file in {{Filename|/var/lock}} on each initialization, however, in most cases the lock folder in /var does not exist preventing SLiM from initializing. Check to make sure {{Filename|/var/lock}} exists, if it does not you can create it by typing the following:<br />
<br />
# mkdir /var/lock/<br />
<br />
=== Power-off error with Splashy ===<br />
<br />
If you use Splashy and SLiM, sometimes you can't power-off or reboot from menu in GNOME, Xfce, LXDE or others. Check your {{Filename|/etc/slim.conf}} and {{Filename|/etc/splash.conf}}; set the DEFAULT_TTY=7 same as xserver_arguments vt07.<br />
<br />
=== Login information with SLiM ===<br />
<br />
By default, SLiM fails to log logins to utmp and wtmp which causes who, last, etc. to misreport login information. To fix this edit your {{Filename|slim.conf}} as follows:<br />
<br />
sessionstart_cmd /usr/bin/sessreg -a -l $DISPLAY %user<br />
sessionstop_cmd /usr/bin/sessreg -d -l $DISPLAY %user<br />
<br />
=== SLiM and Gnome Keyring ===<br />
If you are using SLiM to launch a Gnome session and have trouble accessing your keyring, for example not being automatically authenticated on login, add the following lines to /etc/pam.d/slim (as discussed [http://bugs.archlinux.org/task/18637 here]).<br />
<pre><br />
auth optional pam_gnome_keyring.so<br />
session optional pam_gnome_keyring.so auto_start<br />
</pre><br />
<br />
However, this fix no longer works for Gnome 2.30. An alternate workaround is described [http://bugs.archlinux.org/task/18930 here]. Modifying the login_cmd line in /etc/slim.conf:<br />
<pre><br />
login_cmd exec ck-launch-session dbus-launch /bin/bash -login ~/.xinitrc %session >~/.xsession-errors 2>&1<br />
</pre><br />
<br />
=== Setting DPI with SLiM ===<br />
<br />
The Xorg server generally picks up the DPI but if it doesn't you can specify it to SLiM. If you set the DPI with the argument -dpi 96 in {{Filename|/etc/X11/xinit/xserverrc}} it will not work with SLiM. To fix this change your {{Filename|slim.conf}} from:<br />
<br />
xserver_arguments -nolisten tcp vt07 <br />
<br />
to<br />
<br />
xserver_arguments -nolisten tcp vt07 -dpi 96<br />
<br />
=== Use a random theme ===<br />
<br />
Use the current_theme variable as a comma separated list to specify a set to randomly choose from.<br />
<br />
===Move the whole session to another VT===<br />
Lets say you have commented out tty terminals 3-6 as you may not use them. ( You may use screen and therefor only need one terminal )<br />
So, to move the X-Server you need to change one number in the /etc/slim.conf file. Just a few lines down you should see:<br />
xserver_arguments -nolisten tcp vt07<br />
<br />
Simply change the vt07 to lets say vt03 as there is no agetty started there.<br />
<br />
=== Automatically mount your encrypted /home on login ===<br />
<br />
You can use [[Pam_mount#Slim|pam_mount]].<br />
<br />
== All Slim Options ==<br />
Here is a list of all the slim configuration options and their default values.<br />
<br />
{{Note|welcome_msg allows 2 variables '''%host''' and '''%domain'''<br>sessionstart_cmd allows '''%user''' ''(execd right before login_cmd)'' and it is also allowed in sessionstop_cmd<br>login_cmd allows '''%session''' and '''%theme'''}}<br />
<br />
<br />
{| class="wikitable collapsible collapsable collapsed"<br />
|-<br />
! Option Name || Default Value<br />
|-<br />
| default_path ||<tt>/bin:/usr/bin:/usr/local/bin</tt><br />
|-<br />
| default_xserver ||<tt>/usr/bin/X</tt><br />
|-<br />
| xserver_arguments ||<tt>vt07 -auth /var/run/slim.auth</tt><br />
|-<br />
| numlock ||<br />
|-<br />
| daemon || <tt>yes</tt><br />
|-<br />
| xauth_path ||<tt>/usr/bin/xauth</tt><br />
|-<br />
| login_cmd ||<tt>exec /bin/bash -login ~/.xinitrc %session</tt><br />
|-<br />
| halt_cmd ||<tt>/sbin/shutdown -h now</tt><br />
|-<br />
| reboot_cmd ||<tt>/sbin/shutdown -r now</tt><br />
|-<br />
| suspend_cmd ||<br />
|-<br />
| sessionstart_cmd ||<br />
|-<br />
| sessionstop_cmd ||<br />
|-<br />
| console_cmd ||<tt>/usr/bin/xterm -C -fg white -bg black +sb -g %dx%d+%d+%d -fn %dx%d -T </tt><br />
|-<br />
| screenshot_cmd ||<tt>import -window root /slim.png</tt><br />
|-<br />
| welcome_msg ||<tt>Welcome to %host</tt><br />
|-<br />
| session_msg ||<tt>Session:</tt><br />
|-<br />
| default_user ||<br />
|-<br />
| focus_password ||<tt>no</tt><br />
|-<br />
| auto_login ||<tt>no</tt><br />
|-<br />
| current_theme ||<tt>default</tt><br />
|-<br />
| lockfile ||<tt>/var/run/slim.lock</tt><br />
|-<br />
| logfile ||<tt>/var/log/slim.log</tt><br />
|-<br />
| authfile ||<tt>/var/run/slim.auth</tt><br />
|-<br />
| shutdown_msg ||<tt>The system is halting...</tt><br />
|-<br />
| reboot_msg ||<tt>The system is rebooting...</tt><br />
|-<br />
| sessions ||<tt>wmaker,blackbox,icewm</tt><br />
|-<br />
| sessiondir ||<br />
|-<br />
| hidecursor ||<tt>false</tt><br />
|-<br />
| input_panel_x ||<tt>50%</tt><br />
|-<br />
| input_panel_y ||<tt>40%</tt><br />
|-<br />
| input_name_x ||<tt>200</tt><br />
|-<br />
| input_name_y ||<tt>154</tt><br />
|-<br />
| input_pass_x ||<tt>-1</tt><br />
|-<br />
| input_pass_y ||<tt>-1</tt><br />
|-<br />
| input_font ||<tt>Verdana:size=11</tt><br />
|-<br />
| input_color ||<tt>#000000</tt><br />
|-<br />
| input_cursor_height ||<tt>20</tt><br />
|-<br />
| input_maxlength_name ||<tt>20</tt><br />
|-<br />
| input_maxlength_passwd ||<tt>20</tt><br />
|-<br />
| input_shadow_xoffset ||<tt>0</tt><br />
|-<br />
| input_shadow_yoffset ||<tt>0</tt><br />
|-<br />
| input_shadow_color ||<tt>#FFFFFF</tt><br />
|-<br />
| welcome_font ||<tt>Verdana:size=14</tt><br />
|-<br />
| welcome_color ||<tt>#FFFFFF</tt><br />
|-<br />
| welcome_x ||<tt>-1</tt><br />
|-<br />
| welcome_y ||<tt>-1</tt><br />
|-<br />
| welcome_shadow_xoffset ||<tt>0</tt><br />
|-<br />
| welcome_shadow_yoffset ||<tt>0</tt><br />
|-<br />
| welcome_shadow_color ||<tt>#FFFFFF</tt><br />
|-<br />
| intro_msg ||<br />
|-<br />
| intro_font ||<tt>Verdana:size=14</tt><br />
|-<br />
| intro_color ||<tt>#FFFFFF</tt><br />
|-<br />
| intro_x ||<tt>-1</tt><br />
|-<br />
| intro_y ||<tt>-1</tt><br />
|-<br />
| background_style ||<tt>stretch</tt><br />
|-<br />
| background_color ||<tt>#CCCCCC</tt><br />
|-<br />
| username_font ||<tt>Verdana:size=12</tt><br />
|-<br />
| username_color ||<tt>#FFFFFF</tt><br />
|-<br />
| username_x ||<tt>-1</tt><br />
|-<br />
| username_y ||<tt>-1</tt><br />
|-<br />
| username_msg ||<tt>Please enter your username</tt><br />
|-<br />
| username_shadow_xoffset ||<tt>0</tt><br />
|-<br />
| username_shadow_yoffset ||<tt>0</tt><br />
|-<br />
| username_shadow_color ||<tt>#FFFFFF</tt><br />
|-<br />
| password_x ||<tt>-1</tt><br />
|-<br />
| password_y ||<tt>-1</tt><br />
|-<br />
| password_msg ||<tt>Please enter your password</tt><br />
|-<br />
| msg_color ||<tt>#FFFFFF</tt><br />
|-<br />
| msg_font ||<tt>Verdana:size=16:bold</tt><br />
|-<br />
| msg_x ||<tt>40</tt><br />
|-<br />
| msg_y ||<tt>40</tt><br />
|-<br />
| msg_shadow_xoffset ||<tt>0</tt><br />
|-<br />
| msg_shadow_yoffset ||<tt>0</tt><br />
|-<br />
| msg_shadow_color ||<tt>#FFFFFF</tt><br />
|-<br />
| session_color ||<tt>#FFFFFF</tt><br />
|-<br />
| session_font ||<tt>Verdana:size=16:bold</tt><br />
|-<br />
| session_x ||<tt>50%</tt><br />
|-<br />
| session_y ||<tt>90%</tt><br />
|-<br />
| session_shadow_xoffset ||<tt>0</tt><br />
|-<br />
| session_shadow_yoffset ||<tt>0</tt><br />
|-<br />
| session_shadow_color ||<tt>#FFFFFF</tt><br />
|}<br />
<br />
== Resources ==<br />
<br />
* [http://slim.berlios.de/ SLiM homepage]<br />
* [http://slim.berlios.de/manual.php SLiM documentation]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Xorg&diff=141244Xorg2011-05-13T08:14:53Z<p>JaMeSiTeGeN: /* Running Xorg */</p>
<hr />
<div>[[Category:X Server (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Xorg}}<br />
[[pl:Xorg]]<br />
[[fr:Xorg]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|An all-inclusive overview about installing and managing Xorg}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Graphical user interface overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|ATI}}<br />
{{Article summary wiki|Intel}}<br />
{{Article summary wiki|NVIDIA}}<br />
{{Article summary end}}<br />
<br />
'''Xorg''' is the public, open-source implementation of the X window system version 11. Since Xorg is the most popular choice among Linux users, its ubiquity has led to making it an ever-present requisite for GUI applications, resulting in massive adoption from most distributions. See the [[Wikipedia:X.Org Server|Xorg]] Wikipedia article or visit the [http://www.x.org/wiki/ Xorg website] for more details.<br />
<br />
==Installing==<br />
<br />
First, you'll need the X server:<br />
# pacman -Syu xorg-server <br />
<br />
Install the xorg-xinit package if you want to start X without a display manager:<br />
# pacman -S xorg-xinit<br />
<br />
Optionally, install twm, xclock and xterm for the default xorg-xinit environment:<br />
# pacman -S xorg-twm xorg-xclock xterm<br />
<br />
You may also want the useful Xorg utilities:<br />
# pacman -S xorg-utils xorg-server-utils <br />
<br />
udev will detect your hardware and evdev will act as the hotplugging input driver for almost all devices. Installing input drivers is not needed for most hardware.<br />
<br />
If evdev doesn't support your device, install the needed driver from the '''xorg-input-drivers''' group.<br />
<br />
Xorg-server can be initiated by the '''startx''' command (from the xorg-xinit package). By default, it starts a basic environment with twm, xclock and xterm. You can switch to a custom environment by editing {{Filename|~/.xinitrc}}.<br />
<br />
{{Note|You may also start X using a display manager such as KDM. See [[Display Manager]] for more info.}}<br />
<br />
==Configuring==<br />
<br />
Xorg can be configured via {{Filename|/etc/xorg.conf}} and/or configuration files located in {{Filename|/etc/X11/xorg.conf.d/}}. Arch supplies default configuration files in {{Filename|/etc/xorg.conf.d}}, and no extra configuration is necessary for most setups.<br />
<br />
You should have {{filename|10-evdev.conf}} which manages the keyboard, the mouse, the touchpad and the touchscreen.<br />
<br />
You are free to create new config files, but they must start with '''XX-''' (where XX is a number) and have a '''.conf''' suffix (10 read before 20 for example).<br />
<br />
===Touchpad/Synaptics===<br />
<br />
If you have a laptop, you need to install the touchpad driver.<br />
# pacman -S xf86-input-synaptics<br />
<br />
After installation, you can find {{filename|10-synaptics.conf}} in the {{filename|/etc/X11/xorg.conf.d}} directory. It is safe to comment out/delete the "InputClass" line regarding the touchpad in {{filename|10-evdev.conf}}.<br />
<br />
===Graphics card and driver===<br />
The default graphics driver is Vesa (xf86-video-vesa), which handles a large number of chipsets but does not include any 2d or 3d acceleration. To enable graphics acceleration, you will need to install and use the driver specific to your graphics card.<br />
<br />
First, identify your card:<br />
$ lspci | grep VGA<br />
<br />
Then, install an appropriate driver. You can ''search'' for these packages with the following command:<br />
# pacman -Ss xf86-video<br />
<br />
Common drivers (open source):<br />
*nvidia: xf86-video-nouveau (see [[Nouveau]])<br />
*intel: xf86-video-intel (see [[Intel]])<br />
*ati: xf86-video-ati (see [[ATI]])<br />
<!--add more drivers with links to wiki pages here--><br />
<br />
====Proprietary drivers====<br />
<br />
Xorg should run smoothly without closed source drivers, which are typically needed only for advanced features such as fast 3D-accelerated rendering for games, dual-screen setups, and TV-out. See [[NVIDIA]] and [[Catalyst]].<br />
<br />
=====Nvidia=====<br />
<br />
During the installation of the proprietary [[NVIDIA]] driver, a config file ('''20-nvidia.conf''') will be installed in the {{filename|/etc/X11/xorg.conf.d}} directory. It allows Xorg to use nvidia's driver at Xorg start.<br />
<br />
===Monitor settings===<br />
<br />
==== Getting started ====<br />
<br />
{{Note|This step is OPTIONAL and shouldn't be done unless you know what you are doing.}}<br />
{{Note|This step is '''NOT OPTIONAL''' if using dual monitors or the nouveau driver. See [[Nouveau#Configuration]].}}<br />
<br />
First, create a new config file, for example, {{filename|/etc/X11/xorg.conf.d/10-monitor.conf}}.<br />
# nano /etc/X11/xorg.conf.d/10-monitor.conf<br />
Copy and paste the following code.<br />
<br />
<pre><br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Device0"<br />
Driver "vesa" #Choose the driver used for this monitor<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen0" #Collapse Monitor and Device section to Screen section<br />
Device "Device0"<br />
Monitor "Monitor0"<br />
DefaultDepth 16 #Choose the depth (16||24)<br />
SubSection "Display"<br />
Depth 16<br />
Modes "1024x768_75.00" #Choose the resolution<br />
EndSubSection<br />
EndSection<br />
</pre><br />
<br />
====Multiple monitors/Dual screen====<br />
<br />
=====Nvidia=====<br />
To activate dual screen support, you just need to edit the {{filename|10-monitor.conf}} file which you made before.<br />
<br />
Per each physical monitor, add one Monitor, Device, and Screen Section entry, and then a ServerLayout section to manage it. Be advised that when Xinerama is enabled, the Nvidia proprietary driver automatically disables compositing. If you desire compositing, you should comment the Xinerama line in "ServerLayout" out and use Twinview (see below) instead.<br />
<br />
<pre><br />
Section "ServerLayout"<br />
Identifier "DualSreen"<br />
Screen 0 "Screen0"<br />
Screen 1 "Screen1" RightOf "Screen0" #Screen1 at the right of Screen0<br />
Option "Xinerama" "1" #To move windows between screens<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor1"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Device0"<br />
Driver "nvidia"<br />
Screen 0<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Device1"<br />
Driver "nvidia"<br />
Screen 1<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "Device0"<br />
Monitor "Monitor0"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1280x800_75.00"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen1"<br />
Device "Device1"<br />
Monitor "Monitor1"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
</pre><br />
<br />
======TwinView======<br />
You want only one big screen instead of two. Set the TwinView argument to 1. This option should be used instead of Xinerama (see above), if you desire compositing.<br />
Option "TwinView" "1"<br />
<br />
======Using Nvidia Settings======<br />
You can also use the Nvidia-settings tool, with this method you will use the proprietary software Nvidia provides with their drivers. Simply open the settings as Root, then configure how you wish, and then save the configuration to /etc/X11/xorg.conf.d/10-monitor.conf .<br />
<br />
=====More than one graphic card=====<br />
You must define the good driver to use and put the ID bus of your graphic cards.<br />
<pre><br />
Section "Device"<br />
Identifier "Screen0"<br />
Driver "nouveau"<br />
BusID "PCI:0:12:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "Screen1"<br />
Driver "radeon"<br />
BusID "PCI:1:0:0"<br />
EndSection<br />
</pre><br />
<br />
To get your ID bus :<br />
$ lspci | grep VGA<br />
01:00.0 VGA compatible controller: nVidia Corporation G96 [GeForce 9600M GT] (rev a1)<br />
<br />
The ID bus here is 1:0:0.<br />
<br />
====Display Size and DPI ====<br />
<br />
'''Q:''' How does the Xorg server calculate DPI? <br /><br />
'''A:''' The DPI of the X server is determined in the following manner:<br />
<br />
# The -dpi command line option has highest priority.<br />
# If this is not used, the DisplaySize setting in the X config file is used to derive the DPI, given the screen resolution.<br />
# If no DisplaySize is given, the monitor size values from DDC are used to derive the DPI, given the screen resolution.<br />
# If DDC does not specify a size, 75 DPI is used by default.<br />
<br />
In order to get correct dots per inch (DPI) set, the display size must be recognized or set. Having the correct DPI is especially necessary where fine detail is required (like font rendering). Previously, manufacturers tried to create a standard for 96 DPI (a 10.3" diagonal monitor would be 800x600, a 13.2" monitor 1024x768). These days, screen DPIs vary and may not be equal horizontally and vertically. For example, a 19" widescreen LCD at 1440x900 may have a DPI of 89x87. To be able to set the DPI, the Xorg server attempts to auto-detect your monitor's physical screen size through the graphic card with [http://en.wikipedia.org/wiki/Display_Data_Channel DDC]. When the Xorg server knows the physical screen size, it will be able to set the correct DPI depending on resolution size.<br />
<br />
To see if your display size and DPI are detected/calculated correctly:<br />
<br />
$ xdpyinfo | grep dimensions<br />
$ xdpyinfo | grep "dots per inch"<br />
<br />
Check that the dimensions match your display size. If the Xorg server is not able to correctly calculate the screen size, it will default to 75x75 DPI and you will have to calculate it yourself.<br />
<br />
If you have specifications on the physical size of the screen, they can be entered in the Xorg configuration file so that the proper DPI is calculated:<br />
<br />
<pre><br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
DisplaySize 286 179 # In millimeters<br />
EndSection<br />
</pre><br />
<br />
If you only want to enter the specification of your monitor WITHOUT creating a full xorg.conf instead, first create a new config file, for example, {{filename|/etc/X11/xorg.conf.d/90-monitor.conf}}.<br />
# nano /etc/X11/xorg.conf.d/10-monitor.conf<br />
Copy and paste the following code:<br />
<br />
<pre><br />
Section "Monitor"<br />
Identifier "<default monitor>"<br />
DisplaySize 286 179 # In millimeters<br />
EndSection<br />
</pre><br />
<br />
If you do not have specifications for physical screen width and height (most specifications these days only list by diagonal size), you can use the monitor's native resolution (or aspect ratio) and diagonal length to calculate the horizontal and vertical physical dimensions. Using the Pythagorean theorem on a 13.3" diagonal length screen with a 1280x800 native resolution (or 16:10 aspect ratio):<br />
<br />
echo 'scale=5;sqrt(1280^2+800^2)' | bc # 1509.43698<br />
<br />
This will give the pixel diagonal length and with this value you can discover the physical horizontal and vertical lengths (and convert them to millimeters):<br />
<br />
<pre><br />
echo 'scale=5;(13.3/1509)*1280*25.4' | bc # 286.43072<br />
echo 'scale=5;(13.3/1509)*800*25.4' | bc # 179.01920<br />
</pre><br />
<br />
{{Note|This calculation works for most monitor sizes; however, there is the seldom monitor that may compress aspect ratio (e.g 16:10 aspect resolution to a 16:9 monitor). If this is the case, you should measure your screen size manually.}}<br />
<br />
===== Setting DPI manually =====<br />
<br />
DPI can be set manually if you only plan to use one resolution:<br />
<br />
<pre><br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
Option "DPI" "96 x 96"<br />
EndSection<br />
</pre><br />
<br />
If you use Nvidia card, you can manually set the DPI adding the options bellow on ''/etc/X11/xorg.conf.d/20-nvidia.conf'' (inside '''Device''' section):<br />
<br />
Option "UseEdidDpi" "False"<br />
Option "DPI" "96 x 96"<br />
<br />
For RandR compliant drivers, you can set it by:<br />
<br />
xrandr --dpi 96<br />
<br />
See [[Execute commands after X start]] to make it permanent.<br />
<br />
====DPMS====<br />
<br />
DPMS (Display Power Management Signaling) is a technology that allows power saving behaviour of monitors when the computer is not in use. This will allow you to have your monitors automatically go into standby after a predefined period of time. See: [[DPMS]]<br />
<br />
===Disabling Input Hot-plugging===<br />
Since version''' 1.8''' Xorg-server uses udev for device detection. The following will disable the use of udev.<br />
<br />
Section "ServerFlags"<br />
Option "AutoAddDevices" "False"<br />
EndSection<br />
{{Warning|This will disable Xorg hot-plugging for '''all''' input devices and revert to the same behavior as xorg-server 1.4. It is much more convenient to let udev configure your devices. '''Therefore, disabling hot-plugging is not recommended!'''}}<br />
<br />
===InputClasses ===<br />
'''Taken from: https://fedoraproject.org/wiki/Input_device_configuration'''<br />
<br />
InputClasses are a new type of configuration section that does not apply to a single device but rather to a class of devices, including hotplugged devices. An InputClass section's scope is limited by the ''matches'' specified &ndash; to apply to an input device, all matches must apply to a device. An example InputClass section is provided below:<br />
<br />
<pre><br />
Section "InputClass"<br />
Identifier "touchpad catchall"<br />
MatchIsTouchpad "on"<br />
Driver "synaptics"<br />
EndSection<br />
</pre><br />
<br />
The next snippet might also be helpful:<br />
<pre><br />
Section "InputClass"<br />
Identifier "evdev touchpad catchall"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Driver "evdev"<br />
EndSection<br />
</pre><br />
<br />
If this snippet is present in the {{Filename|xorg.conf}} or xorg.conf.d, any touchpad present in the system is assigned the synaptics driver. Note that due to precedence order (alphanumeric sorting of xorg.conf.d snippets) the Driver setting overwrites previously set driver options &ndash; the more generic the class, the earlier it should be listed. The default snippet shipped with the xorg-x11-drv-Xorg package is {{Filename|00-evdev.conf}} and applies the evdev driver to all input devices.<br />
<br />
The match options specify which devices a section may apply to. To match a device, all match lines must apply. The following match lines are supported (with examples):<br />
* {{Codeline|MatchIsPointer}}, {{Codeline|MatchIsKeyboard}}, {{Codeline|MatchIsTouchpad}}, {{Codeline|MatchIsTouchscreen}}, {{Codeline|MatchIsJoystick}} &ndash; boolean options to apply to a group of devices.<br />
* {{Codeline|MatchProduct "foo&#124;bar"}}: match any device with a product name containing either "foo" or "bar"<br />
* {{Codeline|MatchVendor "foo&#124;bar&#124;baz"}}: match any device with a vendor string containing either "foo", "bar", or "baz"<br />
* {{Codeline|MatchDevicePath "/dev/input/event*"}}: match any device with a device path matching the given patch (see fnmatch(3) for the allowed pattern)<br />
* {{Codeline|MatchTag "foo&#124;bar"}}: match any device with a tag of either "foo" or "bar". Tags may be assigned by the config backend &ndash; udev in our case &ndash; to label devices that need quirks or special configuration.<br />
<br />
An example section for user-specific configuration is:<br />
<br />
<pre><br />
Section "InputClass"<br />
Identifier "lasermouse slowdown"<br />
MatchIsPointer "on"<br />
MatchProduct "Lasermouse"<br />
MatchVendor "LaserMouse Inc."<br />
Option "ConstantDeceleration" 20<br />
EndSection<br />
</pre><br />
<br />
This section would match a pointer device containing "Lasermouse" from "Lasermouse Inc." and apply a constant deceleration of 20 on this device &ndash; slowing it down by factor 20.<br />
<br />
Some devices may get picked up by the X server when they really shouldn't be. These devices can be configured to be ignored:<br />
<br />
<pre><br />
Section "InputClass"<br />
Identifier "no need for accelerometers in X"<br />
MatchProduct "accelerometer"<br />
Option "Ignore" "on"<br />
EndSection<br />
</pre><br />
<br />
====Example configurations====<br />
<br />
The following subsections describe example configurations for commonly used configuration options. Note that if you use a desktop environment such as GNOME or KDE, options you set in the xorg.conf ''may'' get overwritten with user-specific options upon login.<br />
<br />
=====Example: Wheel Emulation (for a Trackpoint)=====<br />
<br />
If you own a computer with a Trackpoint (a Thinkpad for example) you can add the following to the {{Filename|xorg.conf}} to use the middle Button to emulate a mouse wheel:<br />
<br />
<pre><br />
Section "InputClass"<br />
Identifier "Wheel Emulation"<br />
MatchIsPointer "on"<br />
MatchProduct "TrackPoint"<br />
Option "EmulateWheelButton" "2"<br />
Option "EmulateWheel" "on"<br />
EndSection<br />
</pre><br />
<br />
For full support of TrackPoints (including horizontal scrolling) you can use the following:<br />
<pre><br />
Section "InputClass"<br />
Identifier "Trackpoint Wheel Emulation"<br />
MatchProduct "TPPS/2 IBM TrackPoint|DualPoint Stick|Synaptics Inc. Composite TouchPad / TrackPoint|ThinkPad USB Keyboard with TrackPoint|USB Trackpoint pointing device"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "EmulateWheel" "true"<br />
Option "EmulateWheelButton" "2"<br />
Option "Emulate3Buttons" "false"<br />
Option "XAxisMapping" "6 7"<br />
Option "YAxisMapping" "4 5"<br />
EndSection<br />
</pre><br />
<br />
=====Example: Tap-to-click=====<br />
Tap-to-click can be enabled in the mouse configuration dialog (in the touchpad tab) but if you need tapping enabled at gdm already, the following snippet does it for you:<br />
<pre><br />
Section "InputClass"<br />
Identifier "tap-by-default"<br />
MatchIsTouchpad "on"<br />
Option "TapButton1" "1"<br />
EndSection<br />
</pre><br />
<br />
=====Example: Keyboard layout and model on Acer 5920G Laptop=====<br />
<br />
Keyboard model and layout may be set in the file {{filename|/etc/X11/xorg.conf.d/keyboard.conf}} or any other .conf file in the same directory.<br />
* {{Codeline|MatchIsKeyboard "yes"}}: set the input device to a keyboard<br />
* {{Codeline|Option "XkbModel" "acer_laptop"}}: set the keyboard model to an Acer * {{Codeline|Option "XkbLayout" "be"}}: set the keyboard layout to belgian. You may replace {{Codeline|be}} with whatever layout you have.<br />
* {{Codeline|Option "XkbVariant" "sundeadkeys"}}: set the layout variant to Sun dead keys. You may omit the {{Codeline|XkbVariant}} option if you stick with the default variant.<br />
laptop keyboard. You may replace {{Codeline|acer_laptop}} with your actual keyboard layout.<br />
<br />
Note that a list of keyboard layouts and models can be found in {{filename|/usr/share/X11/xkb/rules/base.lst}}<br />
<br />
<pre><br />
Section "InputClass"<br />
Identifier "Keyboard Defaults"<br />
MatchIsKeyboard "yes"<br />
Option "XkbModel" "acer_laptop"<br />
Option "XkbLayout" "be"<br />
Option "XkbVariant" "sundeadkeys"<br />
EndSection<br />
</pre><br />
<br />
===Keyboard settings===<br />
<br />
Xorg may fail to detect your keyboard correctly. This might give problems with your keyboard layout or keyboard model not being set correctly.<br />
<br />
To see a full list of keyboard models, layouts, variants and options, open:<br />
<br />
/usr/share/X11/xkb/rules/xorg.lst<br />
<br />
To set the keymap for the current Xorg session:<br />
# setxkbmap dvorak<br />
<br />
====Key repeat delay and rate====<br />
<br />
Use {{Codeline|xset r rate DELAY RATE}} to change them, then use [[xinitrc]] to make it permanent.<br />
<br />
====Viewing Keyboard Settings====<br />
$ setxkbmap -print -verbose 10<br />
<pre><br />
Setting verbose level to 10<br />
locale is C<br />
Applied rules from evdev:<br />
model: evdev<br />
layout: us<br />
options: terminate:ctrl_alt_bksp<br />
Trying to build keymap using the following components:<br />
keycodes: evdev+aliases(qwerty)<br />
types: complete<br />
compat: complete<br />
symbols: pc+us+inet(evdev)+terminate(ctrl_alt_bksp)<br />
geometry: pc(pc104)<br />
xkb_keymap {<br />
xkb_keycodes { include "evdev+aliases(qwerty)" };<br />
xkb_types { include "complete" };<br />
xkb_compat { include "complete" };<br />
xkb_symbols { include "pc+us+inet(evdev)+terminate(ctrl_alt_bksp)" };<br />
xkb_geometry { include "pc(pc104)" };<br />
};<br />
</pre><br />
<br />
====Setting Keyboard Layout With Hot-Plugging====<br />
To permanently change your keyboard layout, add the following to xorg.conf:<br />
<pre><br />
Section "InputClass"<br />
Identifier "Keyboard Defaults"<br />
MatchIsKeyboard "yes"<br />
Option "XkbLayout" "dvorak"<br />
EndSection<br />
</pre><br />
<br />
Note that this is in an InputClass Section and not the InputDevice section for the keyboard.<br />
<br />
====Setting Keyboard Layout Without Hot-Plugging (deprecated)====<br />
{{Note|Changing the keyboard layout through this method requires disabling input hot-plugging.}}<br />
<br />
To change the keyboard layout, use the XkbLayout option in the keyboard InputDevice section. For example, if you have a keyboard with English (Great Britain) layout, your keyboard InputDevice section might look similar to this:<br />
<br />
<pre><br />
Section "InputDevice"<br />
Identifier "Keyboard0"<br />
Driver "kbd"<br />
Option "XkbLayout" "gb"<br />
EndSection<br />
</pre><br />
<br />
To change the keyboard model, use the XkbModel option in the keyboard InputDevice section. For example, if you have a Microsoft Wireless Multimedia Keyboard:<br />
<br />
Option "XkbModel" "microsoftmult"<br />
<br />
====Switching Between Keyboard Layouts====<br />
To be able to easily switch keyboard layouts, modify the Options used in either of the above two methods. For example, to switch between a US and a Swedish layout using the Caps Lock key, use:<br />
<br />
Option "XkbLayout" "us, se"<br />
Option "XkbOptions" "grp:caps_toggle"<br />
<br />
This is mainly useful if you run a Desktop Environment which does not take care of keyboard layouts for you.<br />
<br />
====Disable mousekeys Permanently====<br />
To disable the mousekeys permanently and prevent Shift+NumLock or Shift+Alt+NumLock to enable, edit:<br />
/usr/share/X11/xkb/compat/complete<br />
and comment out:<br />
augment "mousekeys"<br />
augment "accessx(full)"<br />
<br />
===Fonts===<br />
See [[Font Configuration]] for information on how to configure font rendering.<br />
<br />
===Sample xorg.conf Files===<br />
Anyone who has an Xorg.conf file written up that works, go ahead and post a link to it here for others to look at. Please do not in-line the entire configuration file; upload it somewhere else and link.<br /><br />
'''Please post input hotplugging configurations only, otherwise note that your config is not using input hotplugging.''' (Xorg 1.8 = udev)<br />
<br />
===== - Sample One: xorg.conf & xorg.conf.d/10-evdev.conf =====<br />
This is a sample configuration file using xorg.conf.d/10-evdev.conf for the keyboard layouts:<br /><br />
''Note: The "InputDevice" sections are commented out, because 10-evdev.conf is taking care of them.''<br />
xorg.conf: http://pastebin.com/raw.php?i=EuSKahkn<br />
xorg.conf.d/10-evdev.conf: http://pastebin.com/raw.php?i=4mPY35Mw><br />
xorg.conf.d/10-monitor.conf (VMWare): http://pastebin.com/raw.php?i=fJv8EXGb<br />
xorg.conf.d/10-monitor.conf (KVM): http://pastebin.com/raw.php?i=NRz7v0Kn<br />
<br />
==Running Xorg==<br />
<br />
You should add dbus to your DAEMONS array:<br />
<br />
DAEMONS=(syslog-ng '''dbus''' network crond)<br />
<br />
If you need to start dbus without rebooting, run<br />
<br />
# rc start dbus<br />
<br />
Finally, start Xorg:<br />
$ startx<br />
or<br />
$ xinit -- /usr/bin/X -nolisten tcp<br />
<br />
{{Note|If you just installed Xorg, there is an empty .xinitrc file in your $HOME that you need to either delete or edit in order for X to start properly. If you do not do this X will show a blank screen with what appears to be no errors in your Xorg.0.log. Simply deleting it will get it running with a default X environment.}}<br />
<br />
The default X environment is rather bare, and you will typically seek to install window managers or desktop environments to supplement X. A list of suitable options is present in [[Common Applications#Window Managers (WM)]].<br />
<br />
If a problem occurs, then view the log at {{Filename|/var/log/Xorg.0.log}}. Be on the lookout for any lines beginning with {{Codeline|(EE)}} which represent errors, and also {{Codeline|(WW)}} which are warnings that could indicate other issues.<br />
<br />
===Methods for starting your Graphical Environment===<br />
What follows are a couple of methods for starting a graphical environment from the command line.<br />
{{Note|If you are using a full-blown Desktop Environment (Gnome, KDE, etc), you might be more interested in reading the wiki page dedicated to said DE.}}<br />
<br />
====Using runlevels====<br />
By default, Linux is set up to have different [[runlevels]]. Arch boots into runlevel 3 by default. Runlevel 5 is typically used in Linux for loading X server.<br />
Edit the file /etc/inittab. In the last section at the bottom of the file, uncomment the appropriate line for your desktop environment's display manager. For example, for XDM (X Display manager) it would look like this:<br />
# Example lines for starting a login manager<br />
x:5:respawn:/usr/bin/xdm -nodaemon<br />
#x:5:respawn:/usr/sbin/gdm -nodaemon<br />
#x:5:respawn:/usr/bin/kdm -nodaemon<br />
#x:5:respawn:/usr/bin/slim >/dev/null 2>&1<br />
<br />
Now, simply start your desktop environment:<br />
# init 5<br />
<br />
====Using .xinitrc====<br />
This method involves the most configuring.<br />
<br />
First we need to configure ~/.xinitrc<br />
<br />
One of the main functions of this file is to dictate what '''X''' Window client is invoked with the '''/usr/bin/startx''' and/or '''/usr/bin/xinit''' program ''on a per-user basis''. (The '''startx''' script is merely a front end to the more versatile '''xinit''' command.) There are vast amounts of additional configurable specifications and commands that may also be added to ~/[[.xinitrc]] as you further customize your system.<br />
<br />
{{Note | '''[[.xinitrc]]''' is a so-called 'dot' (.) file. Files in a *nix filesystem which are preceded with a dot (.) are 'hidden', and will not show up with a regular 'ls' command, usually for the sake of keeping directories tidy. Dot files may be seen by issuing '''ls -a'''. The 'rc' denotes ''Run Commands'' and simply indicates that it is a configuration file. Since it controls how a program runs, it is (although historically incorrect) also said to stand for &quot;Run Control&quot;.}}<br />
<br />
The '''startx''' and '''xinit''' commands will start the '''X''' server and clients. To determine the client to run, '''startx/xinit''' will first look to parse a [[.xinitrc]] file in the user's home directory. In the absence of file ~/[[.xinitrc]], it defaults to the global xinitrc in the xinit library directory; /etc/X11/xinit/xinitrc, which defaults to using the TWM window manager. (Hence, if you invoke startx without a ~/[[.xinitrc]] file, a TWM session will start.) Further details in the [[.xinitrc]] wiki entry.<br />
<br />
Switch to your '''''normal, non-root''''' user:<br />
<br />
# su - ''yourusername''<br />
<br />
* /etc/skel/ contains files and directories to provide sane defaults for newly created user accounts. The name '''skel''' is derived from the word '''skeleton''', because the files it contains form the basic structure for users' home directories.<br />
{{Note | This template file '''[[.xinitrc]]''' is available in the /etc/skel directory when the package '''xorg-xinit''' is installed.}}<br />
<br />
* Sample .xinitrc provided [[Xinitrc#A_standard_.xinitrc | here]]<br />
Copy the sample xinitrc file from /etc/skel/ to your home directory:<br />
<br />
$ cp /etc/skel/[[.xinitrc]] ~/<br />
Edit the file:<br />
$ nano ~/.xinitrc<br />
and uncomment the line that corresponds to your Desktop Environment. For example, if you use Xterm, it will look something like this:<br />
<br />
<pre><br />
#!/bin/sh<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
<br />
# exec gnome-session<br />
# exec startkde<br />
# exec startxfce4<br />
# exec wmaker<br />
# exec icewm<br />
# exec blackbox<br />
# exec fluxbox<br />
# exec openbox-session<br />
# ...or the Window Manager of your choice<br />
exec xterm<br />
</pre><br />
<br />
{{Note | ''Be sure to have only '''one''' uncommented '''exec''' line in ~/.xinitrc''.}}<br />
<br />
Now we're ready to launch X. Start '''X''' as a '''normal, non-root''' user, with:<br />
<br />
$ startx<br />
or<br />
$ xinit<br />
<br />
Your desktop should open up now. You can test your keyboard and its layout in it. Try moving your mouse around and enjoy the view.<br />
<br />
If trouble with automounting is experienced, try using the following command in ~/.xinitrc instead. (Replace "startxfce4" with the command that is appropriate for your window manager/DE.)<br />
exec ck-launch-session startxfce4<br />
This will ensure the various environment variables are set correctly by starting a clean consolekit session. ConsoleKit is a framework for keeping track of the various users, sessions, and seats present on a system. It provides a mechanism for software to react to changes of any of these items or of any of the metadata associated with them. It works in conjunction with dbus, and other tools.<br />
<br />
==Tips and tricks==<br />
<br />
===X startup (/usr/bin/startx) tweaking===<br />
For X's option reference see:<br />
$ man Xserver<br />
<br />
The following options have to be appended to the variable {{Codeline|"defaultserverargs"}} in the {{Filename|/usr/bin/startx}} file:<br />
<br />
* Enable deferred glyph loading for 16 bit fonts:<br />
-deferglyphs 16<br />
<br />
Note: If you start X with kdm, the startx script does not seem to be executed. X options must be appended to the variable {{Codeline|"ServerArgsLocal"}} or {{Codeline|"ServerCmd"}} in the {{Filename|/usr/share/config/kdm/kdmrc}} file. By default kdm options are:<br />
ServerArgsLocal=-nolisten tcp<br />
ServerCmd=/usr/bin/X<br />
<br />
===Virtual X session===<br />
To start another X session in, for example, CTRL + ALT + F8, you need to type this on a console:<br />
xinit /path/to/wm -- :1<br />
<br />
Change "/path/to/wm" to your window manager start file or to your login manager like gdm, kdm, or slim.<br />
<br />
===Nested X session===<br />
To run a nested session of another desktop environment:<br />
$ /usr/bin/Xnest :1 -geometry 1024x768+0+0 -ac -name Windowmaker & wmaker -display :1<br />
<br />
This will launch a Window Maker session in a 1024 by 768 window within your current X session.<br />
<br />
This needs the package ''xorg-server-xnest'' to be installed.<br />
<br />
==Troubleshooting==<br />
===Common problems===<br />
If Xorg will not start, the screen is completely black, the keyboard and mouse are not working, etc., first take these simple steps:<br />
*Check the log file: {{codeline|cat /var/log/Xorg.0.log}}<br />
*Install input driver (keyboard, mouse, joystick, tablet, etc...):<br />
*Finally, search for common problems in [[ATI]], [[Intel]] and [[NVIDIA]] articles.<br />
<br />
===Ctrl-Alt-Backspace doesn't work===<br />
There are two ways of restoring {{keypress|Ctrl}}+{{keypress|Alt}}+{{keypress|Backspace}}; with and without input-hotplugging. Using hot-plugging is recommended.<br />
<br />
====With input hot-plugging====<br />
In most situations, using user-specific configuration might be preferred over system-wide.<br />
<br />
{{Note|On GNOME, this system-wide setting has no effect. Every user must go to System -> Preferences -> Keyboard -> Layouts -> Options [button] -> Key sequence to kill the X server [expand with triangle on left]. Then check Ctrl + Alt + Backspace option.}}<br />
<br />
{{Note|On KDE, this system-wide setting has no effect. To restore, go to Kickoff > Computer > System Settings which will open up the System Settings window. Click on 'Input Devices'. In this new window click the Keyboard tab and then click on the advanced tab. In this new window, click the box for 'Configure keyboard options.' Expand the entry for 'Key sequence to kill the X server' and ensure Control + Alt + Backspace is checked. Click Apply and close the System Settings window. You now have your CTRL-ALT-Backspace back in KDE.}}<br />
<br />
=====System-wide=====<br />
Add<br />
Option "XkbOptions" "terminate:ctrl_alt_bksp"<br />
to InputClass as so:<br />
<br />
<pre><br />
Section "InputClass"<br />
Identifier "Keyboard Defaults"<br />
MatchIsKeyboard "yes"<br />
Option "XkbOptions" "terminate:ctrl_alt_bksp"<br />
EndSection<br />
</pre><br />
<br />
=====User-specific=====<br />
Another way is to put this line in [[xinitrc]]:<br />
setxkbmap -option terminate:ctrl_alt_bksp<br />
<br />
====Without input hot-plugging====<br />
New Xorg disables zapping with {{Keypress|Ctrl}}+{{Keypress|Alt}}+{{Keypress|Backspace}} by default. You can enable it by adding the following line to {{Filename|/etc/X11/xorg.conf}},<br />
Option "XkbOptions" "terminate:ctrl_alt_bksp"<br />
to {{codeline|InputDevice}} section for keyboard.<br />
<br />
===Apple keyboard issues===<br />
:''See: [[Apple Keyboard]]''<br />
<br />
===Touchpad tap-click issues===<br />
:''See: [[Synaptics]]''<br />
<br />
===Extra mouse buttons not recognized===<br />
:''See: [[Get All Mouse Buttons Working]]''<br />
<br />
===X clients started with "su" fail===<br />
If you are getting "Client is not authorized to connect to server", try adding the line:<br />
session optional pam_xauth.so<br />
to {{filename|/etc/pam.d/su}}. {{codeline|pam_xauth}} will then properly set environment variables and handle {{codeline|xauth}} keys.<br />
<br />
===Program requests "font '(null)'"===<br />
*Error message: "''unable to load font `(null)'.''"<br />
Some programs only work with bitmap fonts. Two major packages with bitmap fonts are available, xorg-fonts-75dpi and xorg-fonts-100dpi. You do not need both; one should be enough. To find out which one would be better in your case, try this:<br />
$ xdpyinfo | grep resolution<br />
and use what is closer to you (75 or 100 instead of XX)<br />
# pacman -S xorg-fonts-XXdpi<br />
<br />
===Frame-buffer mode problems===<br />
If X fails to start with the following log messages,<br />
<pre><br />
(WW) Falling back to old probe method for fbdev<br />
(II) Loading sub module "fbdevhw"<br />
(II) LoadModule: "fbdevhw"<br />
(II) Loading /usr/lib/xorg/modules/linux//libfbdevhw.so<br />
(II) Module fbdevhw: vendor="X.Org Foundation"<br />
compiled for 1.6.1, module version=0.0.2<br />
ABI class: X.Org Video Driver, version 5.0<br />
(II) FBDEV(1): using default device<br />
<br />
Fatal server error:<br />
Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices<br />
</pre><br />
uninstall fbdev:<br />
# pacman -R xf86-video-fbdev<br />
<br />
===DRI with Matrox cards stops working===<br />
If you use a Matrox card and DRI stops working after upgrading to Xorg, try adding the line:<br />
Option "OldDmaInit" "On"<br />
to the Device section that references the video card in xorg.conf.<br />
<br />
===Recovery: disabling Xorg before GUI login===<br />
If Xorg is set to boot up automatically and for some reason you need to prevent it from starting up before the login/display manager appears (if {{filename|rc.conf}} is wrongly configured and Xorg does not recognize your mouse or keyboard input, for instance), you can accomplish this task with two methods.<br />
<br />
*From the grub menu, you can specify the runlevel in the kernel line by adding a number to the end of the kernel line specifying the run level you want. The following example sets the run level to 3:<br />
kernel /boot/vmlinuz26 root=/dev/disk/by-uuid/..ro 3<br />
<br />
*If you have not only a faulty {{filename|rc.conf}} to make Xorg unusable, but you have also set the grub menu wait time to zero, or cannot otherwise use grub to prevent Xorg from booting, you can use the Arch live CD. Boot up the live CD and login as root. You need a mount point, such as {{filename|/mnt}}, and you need to know the name of the partition you want to mount.<br />
<br />
:You can use the command,<br />
# fdisk -l<br />
:to see your partitions. Usually, the one you want will be resembling {{filename|/dev/sda1}}. Then, to mount this to {{filename|/mnt}}, use<br />
# mount /dev/sda1 /mnt<br />
<br />
:Then your file-system will show up under {{filename|/mnt}}. So your {{filename|rc.conf}} file, for example, would be in {{filename|/mnt/etc/rc.conf}}. From here you can delete the {{codeline|gdm}} module to prevent Xorg from booting up normally, or make any other necessary changes.<br />
<br />
==See also==<br />
* [[Display Manager]]<br />
* [[Execute commands after X start]]<br />
* [[Start X at boot]]<br />
* [[Font Configuration]]<br />
* Proprietary Video Drivers<br />
** [[ATI Catalyst]]<br />
** [[NVIDIA]]<br />
* [[Desktop Environment]]<br />
* [[Window Manager]]<br />
* [[Get All Mouse Buttons Working]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=141174Disable clearing of boot messages2011-05-12T11:56:50Z<p>JaMeSiTeGeN: /* Method : Give tty1 a custom issue file */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Disable Clearing of Boot Messages}}<br />
[[fr:Messages au demarrage]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Preventing the boot sequence printout from disappearing.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
After the boot process, the screen is cleared and the login prompt appears, leaving users unable to read init output and error messages. This default behavior may be modified using methods outlined in this article.<br />
<br />
Note that regardless of the chosen option, kernel messages can be displayed for inspection after booting by using {{codeline|dmesg}}.<br />
<br />
==Using flow control==<br />
This is basic management that applies to most terminal emulators, including virtual consoles (vc):<br />
* Press {{codeline|Ctrl+S}} to pause the output<br />
* And {{codeline|Ctrl+Q}} to resume it<br />
<br />
==More permanent solution==<br />
For a more permanent change, the following can be used to add a pause, or wait for keypress while boot messages are still on the screen:<br />
<br />
* Wait for a keypress before clearing the screen:<br />
read -n1<br />
* Wait for at most 5 seconds or until a keypress occurs:<br />
read -t5 -n1<br />
<br />
Add one of these to either the bottom of {{Filename|/etc/rc.local}} to pause when booting is finished, or the stat_fail() function in {{Filename|/etc/rc.d/functions}} to pause when a boot script in {{{Filename|/etc/rc.d}}} fails with an explicit error code. Note that the latter is a system script and may be overwritten when that file is updated. If you're unsure what this means, use {{Filename|/etc/rc.local}}.<br />
<br />
==Have boot messages stay on tty1==<br />
<br />
'''Normal behaviour:'''<br />
Boot messages shoot past, screen is cleared, contents of {{Filename|/etc/issue}} are displayed, login (either CLI or login manager) is displayed.<br />
<br />
'''Desired behaviour:'''<br />
Boot messages shoot past, login (either CLI or login manager) is displayed without clearing of tty1<br />
<br />
There are two methods to achieve this. Choose the one that suits you best.<br />
<br />
===Method 1: Give tty1 a custom issue file===<br />
Copy the existing /etc/issue file to /etc/issue.tty1: ( Without the first line )<br />
sed 1d /etc/issue > /etc/issue.tty1<br />
<br />
Find this in /etc/inittab:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
Replace it with:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux -f /etc/issue.tty1<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
===Method 2: edit /etc/inittab===<br />
If the default agetty, i.e. default arch, is used, it is possible to skip displaying the contents of {{Filename|/etc/issue}} altogether and instead keep the boot messages displayed on tty1. In {{Filename|/etc/inittab}}, you will find a list of numbered consoles which look something like the following; just scroll down in the file to find it. Then you need to add the {{Codeline|"-i"}} option for the first virtual console (the c1 line) only:<br />
c1:2345:respawn:/sbin/agetty '''-i''' -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
.<br />
.<br />
.<br />
<br />
Alternatively simply comment the first line. '''Note:''' this way the login dialogue doesn't appear, i.e. tty1 is locked.<br />
#c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux <br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux <br />
.<br />
.<br />
.<br />
<br />
But if you're using '''mingetty''', you'll need to add the {{Codeline|"--noclear"}} and {{Codeline|"--noissue"}} options for your first virtual console (c1) only:<br />
c1:2345:respawn:/sbin/mingetty --noclear --noissue tty1 linux<br />
c2:2345:respawn:/sbin/mingetty tty2 linux<br />
.<br />
.<br />
<br />
===Method 3: edit /etc/issue===<br />
Simply cut the contents of the first line in /etc/issue so it looks like this:<br />
<br />
Arch Linux \r (\n) (\l)<br />
<br />
{{Warning|Read the next section (Restoring /etc/issue) before attempting this!}}<br />
<br />
===Restoring /etc/issue===<br />
The characters can't be just typed again into the file because they are special characters '''not''' available on your keyboard!<br />
<br />
After you cut the contents from line 1 in {{Filename|/etc/issue}}, paste it into a temporary file somewhere on you computer so you can copy and paste it back into {{Filename|/etc/issue}} later when you wish to restore original functionality. You can also backup the whole {{Filename|/etc/issue}} somewhere safe and restore it when needed.<br />
<br />
Optionally, if you are more advanced, you can follow special procidures for typing in these special characters:<br />
<br />
Methods of placing literal escape characters are editor dependent. In [[Vim]]:<br />
<pre><br />
ESC (exit insert mode)<br />
:r !clear<br />
:x (Save and Exit)<br />
</pre><br />
This will insert the literal characters equivalent to the shell {{codeline|clear}} command. Optionally you can also insert the characters manually: <br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In [[Emacs]]:<br />
C-q ESC (to insert literal escape)<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
== See Also ==<br />
*[[Inittab]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=141173Disable clearing of boot messages2011-05-12T11:55:58Z<p>JaMeSiTeGeN: /* Have boot messages stay on tty1 */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Disable Clearing of Boot Messages}}<br />
[[fr:Messages au demarrage]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Preventing the boot sequence printout from disappearing.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
After the boot process, the screen is cleared and the login prompt appears, leaving users unable to read init output and error messages. This default behavior may be modified using methods outlined in this article.<br />
<br />
Note that regardless of the chosen option, kernel messages can be displayed for inspection after booting by using {{codeline|dmesg}}.<br />
<br />
==Using flow control==<br />
This is basic management that applies to most terminal emulators, including virtual consoles (vc):<br />
* Press {{codeline|Ctrl+S}} to pause the output<br />
* And {{codeline|Ctrl+Q}} to resume it<br />
<br />
==More permanent solution==<br />
For a more permanent change, the following can be used to add a pause, or wait for keypress while boot messages are still on the screen:<br />
<br />
* Wait for a keypress before clearing the screen:<br />
read -n1<br />
* Wait for at most 5 seconds or until a keypress occurs:<br />
read -t5 -n1<br />
<br />
Add one of these to either the bottom of {{Filename|/etc/rc.local}} to pause when booting is finished, or the stat_fail() function in {{Filename|/etc/rc.d/functions}} to pause when a boot script in {{{Filename|/etc/rc.d}}} fails with an explicit error code. Note that the latter is a system script and may be overwritten when that file is updated. If you're unsure what this means, use {{Filename|/etc/rc.local}}.<br />
<br />
==Have boot messages stay on tty1==<br />
<br />
'''Normal behaviour:'''<br />
Boot messages shoot past, screen is cleared, contents of {{Filename|/etc/issue}} are displayed, login (either CLI or login manager) is displayed.<br />
<br />
'''Desired behaviour:'''<br />
Boot messages shoot past, login (either CLI or login manager) is displayed without clearing of tty1<br />
<br />
There are two methods to achieve this. Choose the one that suits you best.<br />
<br />
===Method : Give tty1 a custom issue file===<br />
Copy the existing /etc/issue file to /etc/issue.tty1: ( Without the first line )<br />
sed 1d /etc/issue > /etc/issue.tty1<br />
<br />
Find this in /etc/inittab:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
Replace it with:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux -f /etc/issue.tty1<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
===Method 2: edit /etc/inittab===<br />
If the default agetty, i.e. default arch, is used, it is possible to skip displaying the contents of {{Filename|/etc/issue}} altogether and instead keep the boot messages displayed on tty1. In {{Filename|/etc/inittab}}, you will find a list of numbered consoles which look something like the following; just scroll down in the file to find it. Then you need to add the {{Codeline|"-i"}} option for the first virtual console (the c1 line) only:<br />
c1:2345:respawn:/sbin/agetty '''-i''' -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
.<br />
.<br />
.<br />
<br />
Alternatively simply comment the first line. '''Note:''' this way the login dialogue doesn't appear, i.e. tty1 is locked.<br />
#c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux <br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux <br />
.<br />
.<br />
.<br />
<br />
But if you're using '''mingetty''', you'll need to add the {{Codeline|"--noclear"}} and {{Codeline|"--noissue"}} options for your first virtual console (c1) only:<br />
c1:2345:respawn:/sbin/mingetty --noclear --noissue tty1 linux<br />
c2:2345:respawn:/sbin/mingetty tty2 linux<br />
.<br />
.<br />
<br />
===Method 3: edit /etc/issue===<br />
Simply cut the contents of the first line in /etc/issue so it looks like this:<br />
<br />
Arch Linux \r (\n) (\l)<br />
<br />
{{Warning|Read the next section (Restoring /etc/issue) before attempting this!}}<br />
<br />
===Restoring /etc/issue===<br />
The characters can't be just typed again into the file because they are special characters '''not''' available on your keyboard!<br />
<br />
After you cut the contents from line 1 in {{Filename|/etc/issue}}, paste it into a temporary file somewhere on you computer so you can copy and paste it back into {{Filename|/etc/issue}} later when you wish to restore original functionality. You can also backup the whole {{Filename|/etc/issue}} somewhere safe and restore it when needed.<br />
<br />
Optionally, if you are more advanced, you can follow special procidures for typing in these special characters:<br />
<br />
Methods of placing literal escape characters are editor dependent. In [[Vim]]:<br />
<pre><br />
ESC (exit insert mode)<br />
:r !clear<br />
:x (Save and Exit)<br />
</pre><br />
This will insert the literal characters equivalent to the shell {{codeline|clear}} command. Optionally you can also insert the characters manually: <br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In [[Emacs]]:<br />
C-q ESC (to insert literal escape)<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
== See Also ==<br />
*[[Inittab]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=141171Disable clearing of boot messages2011-05-12T11:53:54Z<p>JaMeSiTeGeN: /* Restoring /etc/issue */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Disable Clearing of Boot Messages}}<br />
[[fr:Messages au demarrage]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Preventing the boot sequence printout from disappearing.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
After the boot process, the screen is cleared and the login prompt appears, leaving users unable to read init output and error messages. This default behavior may be modified using methods outlined in this article.<br />
<br />
Note that regardless of the chosen option, kernel messages can be displayed for inspection after booting by using {{codeline|dmesg}}.<br />
<br />
==Using flow control==<br />
This is basic management that applies to most terminal emulators, including virtual consoles (vc):<br />
* Press {{codeline|Ctrl+S}} to pause the output<br />
* And {{codeline|Ctrl+Q}} to resume it<br />
<br />
==More permanent solution==<br />
For a more permanent change, the following can be used to add a pause, or wait for keypress while boot messages are still on the screen:<br />
<br />
* Wait for a keypress before clearing the screen:<br />
read -n1<br />
* Wait for at most 5 seconds or until a keypress occurs:<br />
read -t5 -n1<br />
<br />
Add one of these to either the bottom of {{Filename|/etc/rc.local}} to pause when booting is finished, or the stat_fail() function in {{Filename|/etc/rc.d/functions}} to pause when a boot script in {{{Filename|/etc/rc.d}}} fails with an explicit error code. Note that the latter is a system script and may be overwritten when that file is updated. If you're unsure what this means, use {{Filename|/etc/rc.local}}.<br />
<br />
==Have boot messages stay on tty1==<br />
<br />
'''Normal behaviour:'''<br />
Boot messages shoot past, screen is cleared, contents of {{Filename|/etc/issue}} are displayed, login (either CLI or login manager) is displayed.<br />
<br />
'''Desired behaviour:'''<br />
Boot messages shoot past, login (either CLI or login manager) is displayed without clearing of tty1<br />
<br />
There are two methods to achieve this. Choose the one that suits you best.<br />
<br />
===Method 1: edit /etc/inittab===<br />
If the default agetty, i.e. default arch, is used, it is possible to skip displaying the contents of {{Filename|/etc/issue}} altogether and instead keep the boot messages displayed on tty1. In {{Filename|/etc/inittab}}, you will find a list of numbered consoles which look something like the following; just scroll down in the file to find it. Then you need to add the {{Codeline|"-i"}} option for the first virtual console (the c1 line) only:<br />
c1:2345:respawn:/sbin/agetty '''-i''' -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
.<br />
.<br />
.<br />
<br />
Alternatively simply comment the first line. '''Note:''' this way the login dialogue doesn't appear, i.e. tty1 is locked.<br />
#c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux <br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux <br />
.<br />
.<br />
.<br />
<br />
But if you're using '''mingetty''', you'll need to add the {{Codeline|"--noclear"}} and {{Codeline|"--noissue"}} options for your first virtual console (c1) only:<br />
c1:2345:respawn:/sbin/mingetty --noclear --noissue tty1 linux<br />
c2:2345:respawn:/sbin/mingetty tty2 linux<br />
.<br />
.<br />
<br />
===Method 2: edit /etc/issue===<br />
Simply cut the contents of the first line in /etc/issue so it looks like this:<br />
<br />
Arch Linux \r (\n) (\l)<br />
<br />
{{Warning|Read the section (Restoring /etc/issue) before attempting this!}}<br />
<br />
===Method 3: Give tty1 a custom issue file===<br />
Copy the existing /etc/issue file to /etc/issue.tty1: ( Without the first line )<br />
sed 1d /etc/issue > /etc/issue.tty1<br />
<br />
Find this in /etc/inittab:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
Replace it with:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux -f /etc/issue.tty1<br />
<br />
{{note|Read the note at the next section if you want it to clear after you logout}}<br />
<br />
===Restoring /etc/issue===<br />
The characters can't be just typed again into the file because they are special characters '''not''' available on your keyboard!<br />
<br />
After you cut the contents from line 1 in {{Filename|/etc/issue}}, paste it into a temporary file somewhere on you computer so you can copy and paste it back into {{Filename|/etc/issue}} later when you wish to restore original functionality. You can also backup the whole {{Filename|/etc/issue}} somewhere safe and restore it when needed.<br />
<br />
Optionally, if you are more advanced, you can follow special procidures for typing in these special characters:<br />
<br />
Methods of placing literal escape characters are editor dependent. In [[Vim]]:<br />
<pre><br />
ESC (exit insert mode)<br />
:r !clear<br />
:x (Save and Exit)<br />
</pre><br />
This will insert the literal characters equivalent to the shell {{codeline|clear}} command. Optionally you can also insert the characters manually: <br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In [[Emacs]]:<br />
C-q ESC (to insert literal escape)<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
== See Also ==<br />
*[[Inittab]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=141170Disable clearing of boot messages2011-05-12T11:53:35Z<p>JaMeSiTeGeN: /* Method 2: edit /etc/issue */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Disable Clearing of Boot Messages}}<br />
[[fr:Messages au demarrage]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Preventing the boot sequence printout from disappearing.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
After the boot process, the screen is cleared and the login prompt appears, leaving users unable to read init output and error messages. This default behavior may be modified using methods outlined in this article.<br />
<br />
Note that regardless of the chosen option, kernel messages can be displayed for inspection after booting by using {{codeline|dmesg}}.<br />
<br />
==Using flow control==<br />
This is basic management that applies to most terminal emulators, including virtual consoles (vc):<br />
* Press {{codeline|Ctrl+S}} to pause the output<br />
* And {{codeline|Ctrl+Q}} to resume it<br />
<br />
==More permanent solution==<br />
For a more permanent change, the following can be used to add a pause, or wait for keypress while boot messages are still on the screen:<br />
<br />
* Wait for a keypress before clearing the screen:<br />
read -n1<br />
* Wait for at most 5 seconds or until a keypress occurs:<br />
read -t5 -n1<br />
<br />
Add one of these to either the bottom of {{Filename|/etc/rc.local}} to pause when booting is finished, or the stat_fail() function in {{Filename|/etc/rc.d/functions}} to pause when a boot script in {{{Filename|/etc/rc.d}}} fails with an explicit error code. Note that the latter is a system script and may be overwritten when that file is updated. If you're unsure what this means, use {{Filename|/etc/rc.local}}.<br />
<br />
==Have boot messages stay on tty1==<br />
<br />
'''Normal behaviour:'''<br />
Boot messages shoot past, screen is cleared, contents of {{Filename|/etc/issue}} are displayed, login (either CLI or login manager) is displayed.<br />
<br />
'''Desired behaviour:'''<br />
Boot messages shoot past, login (either CLI or login manager) is displayed without clearing of tty1<br />
<br />
There are two methods to achieve this. Choose the one that suits you best.<br />
<br />
===Method 1: edit /etc/inittab===<br />
If the default agetty, i.e. default arch, is used, it is possible to skip displaying the contents of {{Filename|/etc/issue}} altogether and instead keep the boot messages displayed on tty1. In {{Filename|/etc/inittab}}, you will find a list of numbered consoles which look something like the following; just scroll down in the file to find it. Then you need to add the {{Codeline|"-i"}} option for the first virtual console (the c1 line) only:<br />
c1:2345:respawn:/sbin/agetty '''-i''' -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
.<br />
.<br />
.<br />
<br />
Alternatively simply comment the first line. '''Note:''' this way the login dialogue doesn't appear, i.e. tty1 is locked.<br />
#c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux <br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux <br />
.<br />
.<br />
.<br />
<br />
But if you're using '''mingetty''', you'll need to add the {{Codeline|"--noclear"}} and {{Codeline|"--noissue"}} options for your first virtual console (c1) only:<br />
c1:2345:respawn:/sbin/mingetty --noclear --noissue tty1 linux<br />
c2:2345:respawn:/sbin/mingetty tty2 linux<br />
.<br />
.<br />
<br />
===Method 2: edit /etc/issue===<br />
Simply cut the contents of the first line in /etc/issue so it looks like this:<br />
<br />
Arch Linux \r (\n) (\l)<br />
<br />
{{Warning|Read the section (Restoring /etc/issue) before attempting this!}}<br />
<br />
===Method 3: Give tty1 a custom issue file===<br />
Copy the existing /etc/issue file to /etc/issue.tty1: ( Without the first line )<br />
sed 1d /etc/issue > /etc/issue.tty1<br />
<br />
Find this in /etc/inittab:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
Replace it with:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux -f /etc/issue.tty1<br />
<br />
{{note|Read the note at the next section if you want it to clear after you logout}}<br />
<br />
====Restoring /etc/issue====<br />
The characters can't be just typed again into the file because they are special characters '''not''' available on your keyboard!<br />
<br />
After you cut the contents from line 1 in {{Filename|/etc/issue}}, paste it into a temporary file somewhere on you computer so you can copy and paste it back into {{Filename|/etc/issue}} later when you wish to restore original functionality. You can also backup the whole {{Filename|/etc/issue}} somewhere safe and restore it when needed.<br />
<br />
Optionally, if you are more advanced, you can follow special procidures for typing in these special characters:<br />
<br />
Methods of placing literal escape characters are editor dependent. In [[Vim]]:<br />
<pre><br />
ESC (exit insert mode)<br />
:r !clear<br />
:x (Save and Exit)<br />
</pre><br />
This will insert the literal characters equivalent to the shell {{codeline|clear}} command. Optionally you can also insert the characters manually: <br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In [[Emacs]]:<br />
C-q ESC (to insert literal escape)<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
== See Also ==<br />
*[[Inittab]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=141168Disable clearing of boot messages2011-05-12T11:52:49Z<p>JaMeSiTeGeN: /* Method 3: Give tty1 a custom issue file */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Disable Clearing of Boot Messages}}<br />
[[fr:Messages au demarrage]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Preventing the boot sequence printout from disappearing.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
After the boot process, the screen is cleared and the login prompt appears, leaving users unable to read init output and error messages. This default behavior may be modified using methods outlined in this article.<br />
<br />
Note that regardless of the chosen option, kernel messages can be displayed for inspection after booting by using {{codeline|dmesg}}.<br />
<br />
==Using flow control==<br />
This is basic management that applies to most terminal emulators, including virtual consoles (vc):<br />
* Press {{codeline|Ctrl+S}} to pause the output<br />
* And {{codeline|Ctrl+Q}} to resume it<br />
<br />
==More permanent solution==<br />
For a more permanent change, the following can be used to add a pause, or wait for keypress while boot messages are still on the screen:<br />
<br />
* Wait for a keypress before clearing the screen:<br />
read -n1<br />
* Wait for at most 5 seconds or until a keypress occurs:<br />
read -t5 -n1<br />
<br />
Add one of these to either the bottom of {{Filename|/etc/rc.local}} to pause when booting is finished, or the stat_fail() function in {{Filename|/etc/rc.d/functions}} to pause when a boot script in {{{Filename|/etc/rc.d}}} fails with an explicit error code. Note that the latter is a system script and may be overwritten when that file is updated. If you're unsure what this means, use {{Filename|/etc/rc.local}}.<br />
<br />
==Have boot messages stay on tty1==<br />
<br />
'''Normal behaviour:'''<br />
Boot messages shoot past, screen is cleared, contents of {{Filename|/etc/issue}} are displayed, login (either CLI or login manager) is displayed.<br />
<br />
'''Desired behaviour:'''<br />
Boot messages shoot past, login (either CLI or login manager) is displayed without clearing of tty1<br />
<br />
There are two methods to achieve this. Choose the one that suits you best.<br />
<br />
===Method 1: edit /etc/inittab===<br />
If the default agetty, i.e. default arch, is used, it is possible to skip displaying the contents of {{Filename|/etc/issue}} altogether and instead keep the boot messages displayed on tty1. In {{Filename|/etc/inittab}}, you will find a list of numbered consoles which look something like the following; just scroll down in the file to find it. Then you need to add the {{Codeline|"-i"}} option for the first virtual console (the c1 line) only:<br />
c1:2345:respawn:/sbin/agetty '''-i''' -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
.<br />
.<br />
.<br />
<br />
Alternatively simply comment the first line. '''Note:''' this way the login dialogue doesn't appear, i.e. tty1 is locked.<br />
#c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux <br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux <br />
.<br />
.<br />
.<br />
<br />
But if you're using '''mingetty''', you'll need to add the {{Codeline|"--noclear"}} and {{Codeline|"--noissue"}} options for your first virtual console (c1) only:<br />
c1:2345:respawn:/sbin/mingetty --noclear --noissue tty1 linux<br />
c2:2345:respawn:/sbin/mingetty tty2 linux<br />
.<br />
.<br />
<br />
===Method 2: edit /etc/issue===<br />
Simply cut the contents of the first line in /etc/issue so it looks like this:<br />
<br />
Arch Linux \r (\n) (\l)<br />
<br />
{{Warning|Read the next section (Restoring /etc/issue) before attempting this!}}<br />
<br />
===Method 3: Give tty1 a custom issue file===<br />
Copy the existing /etc/issue file to /etc/issue.tty1: ( Without the first line )<br />
sed 1d /etc/issue > /etc/issue.tty1<br />
<br />
Find this in /etc/inittab:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
Replace it with:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux -f /etc/issue.tty1<br />
<br />
{{note|Read the note at the next section if you want it to clear after you logout}}<br />
<br />
====Restoring /etc/issue====<br />
The characters can't be just typed again into the file because they are special characters '''not''' available on your keyboard!<br />
<br />
After you cut the contents from line 1 in {{Filename|/etc/issue}}, paste it into a temporary file somewhere on you computer so you can copy and paste it back into {{Filename|/etc/issue}} later when you wish to restore original functionality. You can also backup the whole {{Filename|/etc/issue}} somewhere safe and restore it when needed.<br />
<br />
Optionally, if you are more advanced, you can follow special procidures for typing in these special characters:<br />
<br />
Methods of placing literal escape characters are editor dependent. In [[Vim]]:<br />
<pre><br />
ESC (exit insert mode)<br />
:r !clear<br />
:x (Save and Exit)<br />
</pre><br />
This will insert the literal characters equivalent to the shell {{codeline|clear}} command. Optionally you can also insert the characters manually: <br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In [[Emacs]]:<br />
C-q ESC (to insert literal escape)<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
== See Also ==<br />
*[[Inittab]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=141166Disable clearing of boot messages2011-05-12T11:50:48Z<p>JaMeSiTeGeN: </p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Disable Clearing of Boot Messages}}<br />
[[fr:Messages au demarrage]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Preventing the boot sequence printout from disappearing.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
After the boot process, the screen is cleared and the login prompt appears, leaving users unable to read init output and error messages. This default behavior may be modified using methods outlined in this article.<br />
<br />
Note that regardless of the chosen option, kernel messages can be displayed for inspection after booting by using {{codeline|dmesg}}.<br />
<br />
==Using flow control==<br />
This is basic management that applies to most terminal emulators, including virtual consoles (vc):<br />
* Press {{codeline|Ctrl+S}} to pause the output<br />
* And {{codeline|Ctrl+Q}} to resume it<br />
<br />
==More permanent solution==<br />
For a more permanent change, the following can be used to add a pause, or wait for keypress while boot messages are still on the screen:<br />
<br />
* Wait for a keypress before clearing the screen:<br />
read -n1<br />
* Wait for at most 5 seconds or until a keypress occurs:<br />
read -t5 -n1<br />
<br />
Add one of these to either the bottom of {{Filename|/etc/rc.local}} to pause when booting is finished, or the stat_fail() function in {{Filename|/etc/rc.d/functions}} to pause when a boot script in {{{Filename|/etc/rc.d}}} fails with an explicit error code. Note that the latter is a system script and may be overwritten when that file is updated. If you're unsure what this means, use {{Filename|/etc/rc.local}}.<br />
<br />
==Have boot messages stay on tty1==<br />
<br />
'''Normal behaviour:'''<br />
Boot messages shoot past, screen is cleared, contents of {{Filename|/etc/issue}} are displayed, login (either CLI or login manager) is displayed.<br />
<br />
'''Desired behaviour:'''<br />
Boot messages shoot past, login (either CLI or login manager) is displayed without clearing of tty1<br />
<br />
There are two methods to achieve this. Choose the one that suits you best.<br />
<br />
===Method 1: edit /etc/inittab===<br />
If the default agetty, i.e. default arch, is used, it is possible to skip displaying the contents of {{Filename|/etc/issue}} altogether and instead keep the boot messages displayed on tty1. In {{Filename|/etc/inittab}}, you will find a list of numbered consoles which look something like the following; just scroll down in the file to find it. Then you need to add the {{Codeline|"-i"}} option for the first virtual console (the c1 line) only:<br />
c1:2345:respawn:/sbin/agetty '''-i''' -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
.<br />
.<br />
.<br />
<br />
Alternatively simply comment the first line. '''Note:''' this way the login dialogue doesn't appear, i.e. tty1 is locked.<br />
#c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux <br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux <br />
.<br />
.<br />
.<br />
<br />
But if you're using '''mingetty''', you'll need to add the {{Codeline|"--noclear"}} and {{Codeline|"--noissue"}} options for your first virtual console (c1) only:<br />
c1:2345:respawn:/sbin/mingetty --noclear --noissue tty1 linux<br />
c2:2345:respawn:/sbin/mingetty tty2 linux<br />
.<br />
.<br />
<br />
===Method 2: edit /etc/issue===<br />
Simply cut the contents of the first line in /etc/issue so it looks like this:<br />
<br />
Arch Linux \r (\n) (\l)<br />
<br />
{{Warning|Read the next section (Restoring /etc/issue) before attempting this!}}<br />
<br />
===Method 3: Give tty1 a custom issue file===<br />
Copy the existing /etc/issue file to /etc/issue.tty1: ( Without the first line )<br />
sed 1d /etc/issue > /etc/issue.tty1<br />
<br />
Find this in /etc/inittab:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
Replace it with:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux -f /etc/issue.tty1<br />
<br />
{{warning|This will not clear tty1 when you logout.}}<br />
<br />
====Restoring /etc/issue====<br />
The characters can't be just typed again into the file because they are special characters '''not''' available on your keyboard!<br />
<br />
After you cut the contents from line 1 in {{Filename|/etc/issue}}, paste it into a temporary file somewhere on you computer so you can copy and paste it back into {{Filename|/etc/issue}} later when you wish to restore original functionality. You can also backup the whole {{Filename|/etc/issue}} somewhere safe and restore it when needed.<br />
<br />
Optionally, if you are more advanced, you can follow special procidures for typing in these special characters:<br />
<br />
Methods of placing literal escape characters are editor dependent. In [[Vim]]:<br />
<pre><br />
ESC (exit insert mode)<br />
:r !clear<br />
:x (Save and Exit)<br />
</pre><br />
This will insert the literal characters equivalent to the shell {{codeline|clear}} command. Optionally you can also insert the characters manually: <br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In [[Emacs]]:<br />
C-q ESC (to insert literal escape)<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
== See Also ==<br />
*[[Inittab]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=141165Disable clearing of boot messages2011-05-12T11:50:11Z<p>JaMeSiTeGeN: /* Method 3: Give tty1 a custom issue file */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Disable Clearing of Boot Messages}}<br />
[[fr:Messages au demarrage]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Preventing the boot sequence printout from disappearing.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
After the boot process, the screen is cleared and the login prompt appears, leaving users unable to read init output and error messages. This default behavior may be modified using methods outlined in this article.<br />
<br />
Note that regardless of the chosen option, kernel messages can be displayed for inspection after booting by using {{codeline|dmesg}}.<br />
<br />
==Using flow control==<br />
This is basic management that applies to most terminal emulators, including virtual consoles (vc):<br />
* Press {{codeline|Ctrl+S}} to pause the output<br />
* And {{codeline|Ctrl+Q}} to resume it<br />
<br />
==More permanent solution==<br />
For a more permanent change, the following can be used to add a pause, or wait for keypress while boot messages are still on the screen:<br />
<br />
* Wait for a keypress before clearing the screen:<br />
read -n1<br />
* Wait for at most 5 seconds or until a keypress occurs:<br />
read -t5 -n1<br />
<br />
Add one of these to either the bottom of {{Filename|/etc/rc.local}} to pause when booting is finished, or the stat_fail() function in {{Filename|/etc/rc.d/functions}} to pause when a boot script in {{{Filename|/etc/rc.d}}} fails with an explicit error code. Note that the latter is a system script and may be overwritten when that file is updated. If you're unsure what this means, use {{Filename|/etc/rc.local}}.<br />
<br />
==Have boot messages stay on tty1==<br />
<br />
'''Normal behaviour:'''<br />
Boot messages shoot past, screen is cleared, contents of {{Filename|/etc/issue}} are displayed, login (either CLI or login manager) is displayed.<br />
<br />
'''Desired behaviour:'''<br />
Boot messages shoot past, login (either CLI or login manager) is displayed without clearing of tty1<br />
<br />
There are two methods to achieve this. Choose the one that suits you best.<br />
<br />
===Method 1: edit /etc/inittab===<br />
If the default agetty, i.e. default arch, is used, it is possible to skip displaying the contents of {{Filename|/etc/issue}} altogether and instead keep the boot messages displayed on tty1. In {{Filename|/etc/inittab}}, you will find a list of numbered consoles which look something like the following; just scroll down in the file to find it. Then you need to add the {{Codeline|"-i"}} option for the first virtual console (the c1 line) only:<br />
c1:2345:respawn:/sbin/agetty '''-i''' -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
.<br />
.<br />
.<br />
<br />
Alternatively simply comment the first line. '''Note:''' this way the login dialogue doesn't appear, i.e. tty1 is locked.<br />
#c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux <br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux <br />
.<br />
.<br />
.<br />
<br />
But if you're using '''mingetty''', you'll need to add the {{Codeline|"--noclear"}} and {{Codeline|"--noissue"}} options for your first virtual console (c1) only:<br />
c1:2345:respawn:/sbin/mingetty --noclear --noissue tty1 linux<br />
c2:2345:respawn:/sbin/mingetty tty2 linux<br />
.<br />
.<br />
<br />
===Method 2: edit /etc/issue===<br />
Simply cut the contents of the first line in /etc/issue so it looks like this:<br />
<br />
Arch Linux \r (\n) (\l)<br />
<br />
{{Warning|Read the next section (Restoring /etc/issue) before attempting this!}}<br />
<br />
==Method 3: Give tty1 a custom issue file==<br />
Copy the existing /etc/issue file to /etc/issue.tty1: ( Without the first line )<br />
sed 1d /etc/issue > /etc/issue.tty1<br />
<br />
Find this in /etc/inittab:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
Replace it with:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux -f /etc/issue.tty1<br />
<br />
{{warning|This will not clear tty1 when you logout.}}<br />
<br />
====Restoring /etc/issue====<br />
The characters can't be just typed again into the file because they are special characters '''not''' available on your keyboard!<br />
<br />
After you cut the contents from line 1 in {{Filename|/etc/issue}}, paste it into a temporary file somewhere on you computer so you can copy and paste it back into {{Filename|/etc/issue}} later when you wish to restore original functionality. You can also backup the whole {{Filename|/etc/issue}} somewhere safe and restore it when needed.<br />
<br />
Optionally, if you are more advanced, you can follow special procidures for typing in these special characters:<br />
<br />
Methods of placing literal escape characters are editor dependent. In [[Vim]]:<br />
<pre><br />
ESC (exit insert mode)<br />
:r !clear<br />
:x (Save and Exit)<br />
</pre><br />
This will insert the literal characters equivalent to the shell {{codeline|clear}} command. Optionally you can also insert the characters manually: <br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In [[Emacs]]:<br />
C-q ESC (to insert literal escape)<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
== See Also ==<br />
*[[Inittab]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=141163Disable clearing of boot messages2011-05-12T11:49:45Z<p>JaMeSiTeGeN: /* Method 3: Give tty1 a custom issue file */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Disable Clearing of Boot Messages}}<br />
[[fr:Messages au demarrage]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Preventing the boot sequence printout from disappearing.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
After the boot process, the screen is cleared and the login prompt appears, leaving users unable to read init output and error messages. This default behavior may be modified using methods outlined in this article.<br />
<br />
Note that regardless of the chosen option, kernel messages can be displayed for inspection after booting by using {{codeline|dmesg}}.<br />
<br />
==Using flow control==<br />
This is basic management that applies to most terminal emulators, including virtual consoles (vc):<br />
* Press {{codeline|Ctrl+S}} to pause the output<br />
* And {{codeline|Ctrl+Q}} to resume it<br />
<br />
==More permanent solution==<br />
For a more permanent change, the following can be used to add a pause, or wait for keypress while boot messages are still on the screen:<br />
<br />
* Wait for a keypress before clearing the screen:<br />
read -n1<br />
* Wait for at most 5 seconds or until a keypress occurs:<br />
read -t5 -n1<br />
<br />
Add one of these to either the bottom of {{Filename|/etc/rc.local}} to pause when booting is finished, or the stat_fail() function in {{Filename|/etc/rc.d/functions}} to pause when a boot script in {{{Filename|/etc/rc.d}}} fails with an explicit error code. Note that the latter is a system script and may be overwritten when that file is updated. If you're unsure what this means, use {{Filename|/etc/rc.local}}.<br />
<br />
==Have boot messages stay on tty1==<br />
<br />
'''Normal behaviour:'''<br />
Boot messages shoot past, screen is cleared, contents of {{Filename|/etc/issue}} are displayed, login (either CLI or login manager) is displayed.<br />
<br />
'''Desired behaviour:'''<br />
Boot messages shoot past, login (either CLI or login manager) is displayed without clearing of tty1<br />
<br />
There are two methods to achieve this. Choose the one that suits you best.<br />
<br />
===Method 1: edit /etc/inittab===<br />
If the default agetty, i.e. default arch, is used, it is possible to skip displaying the contents of {{Filename|/etc/issue}} altogether and instead keep the boot messages displayed on tty1. In {{Filename|/etc/inittab}}, you will find a list of numbered consoles which look something like the following; just scroll down in the file to find it. Then you need to add the {{Codeline|"-i"}} option for the first virtual console (the c1 line) only:<br />
c1:2345:respawn:/sbin/agetty '''-i''' -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
.<br />
.<br />
.<br />
<br />
Alternatively simply comment the first line. '''Note:''' this way the login dialogue doesn't appear, i.e. tty1 is locked.<br />
#c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux <br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux <br />
.<br />
.<br />
.<br />
<br />
But if you're using '''mingetty''', you'll need to add the {{Codeline|"--noclear"}} and {{Codeline|"--noissue"}} options for your first virtual console (c1) only:<br />
c1:2345:respawn:/sbin/mingetty --noclear --noissue tty1 linux<br />
c2:2345:respawn:/sbin/mingetty tty2 linux<br />
.<br />
.<br />
<br />
===Method 2: edit /etc/issue===<br />
Simply cut the contents of the first line in /etc/issue so it looks like this:<br />
<br />
Arch Linux \r (\n) (\l)<br />
<br />
{{Warning|Read the next section (Restoring /etc/issue) before attempting this!}}<br />
<br />
==Method 3: Give tty1 a custom issue file==<br />
<br />
Copy the existing /etc/issue file to /etc/issue.tty1: ( Without the first line )<br />
sed 1d /etc/issue > /etc/issue.tty1<br />
<br />
Find this in /etc/inittab:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
Replace it with:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux -f /etc/issue.tty1<br />
<br />
{{warning|This will not clear tty1 when you logout.}}<br />
<br />
====Restoring /etc/issue====<br />
The characters can't be just typed again into the file because they are special characters '''not''' available on your keyboard!<br />
<br />
After you cut the contents from line 1 in {{Filename|/etc/issue}}, paste it into a temporary file somewhere on you computer so you can copy and paste it back into {{Filename|/etc/issue}} later when you wish to restore original functionality. You can also backup the whole {{Filename|/etc/issue}} somewhere safe and restore it when needed.<br />
<br />
Optionally, if you are more advanced, you can follow special procidures for typing in these special characters:<br />
<br />
Methods of placing literal escape characters are editor dependent. In [[Vim]]:<br />
<pre><br />
ESC (exit insert mode)<br />
:r !clear<br />
:x (Save and Exit)<br />
</pre><br />
This will insert the literal characters equivalent to the shell {{codeline|clear}} command. Optionally you can also insert the characters manually: <br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In [[Emacs]]:<br />
C-q ESC (to insert literal escape)<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
== See Also ==<br />
*[[Inittab]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=141162Disable clearing of boot messages2011-05-12T11:48:16Z<p>JaMeSiTeGeN: /* Method 3: Give tty1 a custom issue file */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Disable Clearing of Boot Messages}}<br />
[[fr:Messages au demarrage]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Preventing the boot sequence printout from disappearing.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
After the boot process, the screen is cleared and the login prompt appears, leaving users unable to read init output and error messages. This default behavior may be modified using methods outlined in this article.<br />
<br />
Note that regardless of the chosen option, kernel messages can be displayed for inspection after booting by using {{codeline|dmesg}}.<br />
<br />
==Using flow control==<br />
This is basic management that applies to most terminal emulators, including virtual consoles (vc):<br />
* Press {{codeline|Ctrl+S}} to pause the output<br />
* And {{codeline|Ctrl+Q}} to resume it<br />
<br />
==More permanent solution==<br />
For a more permanent change, the following can be used to add a pause, or wait for keypress while boot messages are still on the screen:<br />
<br />
* Wait for a keypress before clearing the screen:<br />
read -n1<br />
* Wait for at most 5 seconds or until a keypress occurs:<br />
read -t5 -n1<br />
<br />
Add one of these to either the bottom of {{Filename|/etc/rc.local}} to pause when booting is finished, or the stat_fail() function in {{Filename|/etc/rc.d/functions}} to pause when a boot script in {{{Filename|/etc/rc.d}}} fails with an explicit error code. Note that the latter is a system script and may be overwritten when that file is updated. If you're unsure what this means, use {{Filename|/etc/rc.local}}.<br />
<br />
==Have boot messages stay on tty1==<br />
<br />
'''Normal behaviour:'''<br />
Boot messages shoot past, screen is cleared, contents of {{Filename|/etc/issue}} are displayed, login (either CLI or login manager) is displayed.<br />
<br />
'''Desired behaviour:'''<br />
Boot messages shoot past, login (either CLI or login manager) is displayed without clearing of tty1<br />
<br />
There are two methods to achieve this. Choose the one that suits you best.<br />
<br />
===Method 1: edit /etc/inittab===<br />
If the default agetty, i.e. default arch, is used, it is possible to skip displaying the contents of {{Filename|/etc/issue}} altogether and instead keep the boot messages displayed on tty1. In {{Filename|/etc/inittab}}, you will find a list of numbered consoles which look something like the following; just scroll down in the file to find it. Then you need to add the {{Codeline|"-i"}} option for the first virtual console (the c1 line) only:<br />
c1:2345:respawn:/sbin/agetty '''-i''' -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
.<br />
.<br />
.<br />
<br />
Alternatively simply comment the first line. '''Note:''' this way the login dialogue doesn't appear, i.e. tty1 is locked.<br />
#c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux <br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux <br />
.<br />
.<br />
.<br />
<br />
But if you're using '''mingetty''', you'll need to add the {{Codeline|"--noclear"}} and {{Codeline|"--noissue"}} options for your first virtual console (c1) only:<br />
c1:2345:respawn:/sbin/mingetty --noclear --noissue tty1 linux<br />
c2:2345:respawn:/sbin/mingetty tty2 linux<br />
.<br />
.<br />
<br />
===Method 2: edit /etc/issue===<br />
Simply cut the contents of the first line in /etc/issue so it looks like this:<br />
<br />
Arch Linux \r (\n) (\l)<br />
<br />
{{Warning|Read the next section (Restoring /etc/issue) before attempting this!}}<br />
<br />
==Method 3: Give tty1 a custom issue file==<br />
<br />
{{tip:This will not clear tty1 when you logout.}}<br />
<br />
Copy the existing /etc/issue file to /etc/issue.tty1: ( Without the first line )<br />
sed 1d /etc/issue > /etc/issue.tty1<br />
<br />
Find this in /etc/inittab:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
Replace it with:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux -f /etc/issue.tty1<br />
<br />
====Restoring /etc/issue====<br />
The characters can't be just typed again into the file because they are special characters '''not''' available on your keyboard!<br />
<br />
After you cut the contents from line 1 in {{Filename|/etc/issue}}, paste it into a temporary file somewhere on you computer so you can copy and paste it back into {{Filename|/etc/issue}} later when you wish to restore original functionality. You can also backup the whole {{Filename|/etc/issue}} somewhere safe and restore it when needed.<br />
<br />
Optionally, if you are more advanced, you can follow special procidures for typing in these special characters:<br />
<br />
Methods of placing literal escape characters are editor dependent. In [[Vim]]:<br />
<pre><br />
ESC (exit insert mode)<br />
:r !clear<br />
:x (Save and Exit)<br />
</pre><br />
This will insert the literal characters equivalent to the shell {{codeline|clear}} command. Optionally you can also insert the characters manually: <br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In [[Emacs]]:<br />
C-q ESC (to insert literal escape)<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
== See Also ==<br />
*[[Inittab]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=141161Disable clearing of boot messages2011-05-12T11:47:11Z<p>JaMeSiTeGeN: /* Method 3: Give tty1 a custom issue file */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Disable Clearing of Boot Messages}}<br />
[[fr:Messages au demarrage]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Preventing the boot sequence printout from disappearing.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
After the boot process, the screen is cleared and the login prompt appears, leaving users unable to read init output and error messages. This default behavior may be modified using methods outlined in this article.<br />
<br />
Note that regardless of the chosen option, kernel messages can be displayed for inspection after booting by using {{codeline|dmesg}}.<br />
<br />
==Using flow control==<br />
This is basic management that applies to most terminal emulators, including virtual consoles (vc):<br />
* Press {{codeline|Ctrl+S}} to pause the output<br />
* And {{codeline|Ctrl+Q}} to resume it<br />
<br />
==More permanent solution==<br />
For a more permanent change, the following can be used to add a pause, or wait for keypress while boot messages are still on the screen:<br />
<br />
* Wait for a keypress before clearing the screen:<br />
read -n1<br />
* Wait for at most 5 seconds or until a keypress occurs:<br />
read -t5 -n1<br />
<br />
Add one of these to either the bottom of {{Filename|/etc/rc.local}} to pause when booting is finished, or the stat_fail() function in {{Filename|/etc/rc.d/functions}} to pause when a boot script in {{{Filename|/etc/rc.d}}} fails with an explicit error code. Note that the latter is a system script and may be overwritten when that file is updated. If you're unsure what this means, use {{Filename|/etc/rc.local}}.<br />
<br />
==Have boot messages stay on tty1==<br />
<br />
'''Normal behaviour:'''<br />
Boot messages shoot past, screen is cleared, contents of {{Filename|/etc/issue}} are displayed, login (either CLI or login manager) is displayed.<br />
<br />
'''Desired behaviour:'''<br />
Boot messages shoot past, login (either CLI or login manager) is displayed without clearing of tty1<br />
<br />
There are two methods to achieve this. Choose the one that suits you best.<br />
<br />
===Method 1: edit /etc/inittab===<br />
If the default agetty, i.e. default arch, is used, it is possible to skip displaying the contents of {{Filename|/etc/issue}} altogether and instead keep the boot messages displayed on tty1. In {{Filename|/etc/inittab}}, you will find a list of numbered consoles which look something like the following; just scroll down in the file to find it. Then you need to add the {{Codeline|"-i"}} option for the first virtual console (the c1 line) only:<br />
c1:2345:respawn:/sbin/agetty '''-i''' -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
.<br />
.<br />
.<br />
<br />
Alternatively simply comment the first line. '''Note:''' this way the login dialogue doesn't appear, i.e. tty1 is locked.<br />
#c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux <br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux <br />
.<br />
.<br />
.<br />
<br />
But if you're using '''mingetty''', you'll need to add the {{Codeline|"--noclear"}} and {{Codeline|"--noissue"}} options for your first virtual console (c1) only:<br />
c1:2345:respawn:/sbin/mingetty --noclear --noissue tty1 linux<br />
c2:2345:respawn:/sbin/mingetty tty2 linux<br />
.<br />
.<br />
<br />
===Method 2: edit /etc/issue===<br />
Simply cut the contents of the first line in /etc/issue so it looks like this:<br />
<br />
Arch Linux \r (\n) (\l)<br />
<br />
{{Warning|Read the next section (Restoring /etc/issue) before attempting this!}}<br />
<br />
==Method 3: Give tty1 a custom issue file==<br />
{{note:This will not clear tty1 when you logout.}}<br />
Copy the existing /etc/issue file to /etc/issue.tty1: ( Without the first line )<br />
sed 1d /etc/issue > /etc/issue.tty1<br />
<br />
Find this in /etc/inittab:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
Replace it with:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux -f /etc/issue.tty1<br />
<br />
====Restoring /etc/issue====<br />
The characters can't be just typed again into the file because they are special characters '''not''' available on your keyboard!<br />
<br />
After you cut the contents from line 1 in {{Filename|/etc/issue}}, paste it into a temporary file somewhere on you computer so you can copy and paste it back into {{Filename|/etc/issue}} later when you wish to restore original functionality. You can also backup the whole {{Filename|/etc/issue}} somewhere safe and restore it when needed.<br />
<br />
Optionally, if you are more advanced, you can follow special procidures for typing in these special characters:<br />
<br />
Methods of placing literal escape characters are editor dependent. In [[Vim]]:<br />
<pre><br />
ESC (exit insert mode)<br />
:r !clear<br />
:x (Save and Exit)<br />
</pre><br />
This will insert the literal characters equivalent to the shell {{codeline|clear}} command. Optionally you can also insert the characters manually: <br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In [[Emacs]]:<br />
C-q ESC (to insert literal escape)<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
== See Also ==<br />
*[[Inittab]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Disable_clearing_of_boot_messages&diff=141157Disable clearing of boot messages2011-05-12T11:40:09Z<p>JaMeSiTeGeN: </p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Disable Clearing of Boot Messages}}<br />
[[fr:Messages au demarrage]]<br />
{{Article summary start|Summary}}<br />
{{Article summary text|Preventing the boot sequence printout from disappearing.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Arch Boot Process}}<br />
{{Article summary end}}<br />
<br />
After the boot process, the screen is cleared and the login prompt appears, leaving users unable to read init output and error messages. This default behavior may be modified using methods outlined in this article.<br />
<br />
Note that regardless of the chosen option, kernel messages can be displayed for inspection after booting by using {{codeline|dmesg}}.<br />
<br />
==Using flow control==<br />
This is basic management that applies to most terminal emulators, including virtual consoles (vc):<br />
* Press {{codeline|Ctrl+S}} to pause the output<br />
* And {{codeline|Ctrl+Q}} to resume it<br />
<br />
==More permanent solution==<br />
For a more permanent change, the following can be used to add a pause, or wait for keypress while boot messages are still on the screen:<br />
<br />
* Wait for a keypress before clearing the screen:<br />
read -n1<br />
* Wait for at most 5 seconds or until a keypress occurs:<br />
read -t5 -n1<br />
<br />
Add one of these to either the bottom of {{Filename|/etc/rc.local}} to pause when booting is finished, or the stat_fail() function in {{Filename|/etc/rc.d/functions}} to pause when a boot script in {{{Filename|/etc/rc.d}}} fails with an explicit error code. Note that the latter is a system script and may be overwritten when that file is updated. If you're unsure what this means, use {{Filename|/etc/rc.local}}.<br />
<br />
==Have boot messages stay on tty1==<br />
<br />
'''Normal behaviour:'''<br />
Boot messages shoot past, screen is cleared, contents of {{Filename|/etc/issue}} are displayed, login (either CLI or login manager) is displayed.<br />
<br />
'''Desired behaviour:'''<br />
Boot messages shoot past, login (either CLI or login manager) is displayed without clearing of tty1<br />
<br />
There are two methods to achieve this. Choose the one that suits you best.<br />
<br />
===Method 1: edit /etc/inittab===<br />
If the default agetty, i.e. default arch, is used, it is possible to skip displaying the contents of {{Filename|/etc/issue}} altogether and instead keep the boot messages displayed on tty1. In {{Filename|/etc/inittab}}, you will find a list of numbered consoles which look something like the following; just scroll down in the file to find it. Then you need to add the {{Codeline|"-i"}} option for the first virtual console (the c1 line) only:<br />
c1:2345:respawn:/sbin/agetty '''-i''' -8 38400 tty1 linux<br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux<br />
.<br />
.<br />
.<br />
<br />
Alternatively simply comment the first line. '''Note:''' this way the login dialogue doesn't appear, i.e. tty1 is locked.<br />
#c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux <br />
c2:2345:respawn:/sbin/agetty -8 38400 tty2 linux <br />
.<br />
.<br />
.<br />
<br />
But if you're using '''mingetty''', you'll need to add the {{Codeline|"--noclear"}} and {{Codeline|"--noissue"}} options for your first virtual console (c1) only:<br />
c1:2345:respawn:/sbin/mingetty --noclear --noissue tty1 linux<br />
c2:2345:respawn:/sbin/mingetty tty2 linux<br />
.<br />
.<br />
<br />
===Method 2: edit /etc/issue===<br />
Simply cut the contents of the first line in /etc/issue so it looks like this:<br />
<br />
Arch Linux \r (\n) (\l)<br />
<br />
{{Warning|Read the next section (Restoring /etc/issue) before attempting this!}}<br />
<br />
==Method 3: Give tty1 a custom issue file==<br />
Copy the existing /etc/issue file to /etc/issue.tty1: ( Without the first line )<br />
sed 1d /etc/issue > /etc/issue.tty1<br />
<br />
Find this in /etc/inittab:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
Replace it with:<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux -f /etc/issue.tty1<br />
<br />
====Restoring /etc/issue====<br />
The characters can't be just typed again into the file because they are special characters '''not''' available on your keyboard!<br />
<br />
After you cut the contents from line 1 in {{Filename|/etc/issue}}, paste it into a temporary file somewhere on you computer so you can copy and paste it back into {{Filename|/etc/issue}} later when you wish to restore original functionality. You can also backup the whole {{Filename|/etc/issue}} somewhere safe and restore it when needed.<br />
<br />
Optionally, if you are more advanced, you can follow special procidures for typing in these special characters:<br />
<br />
Methods of placing literal escape characters are editor dependent. In [[Vim]]:<br />
<pre><br />
ESC (exit insert mode)<br />
:r !clear<br />
:x (Save and Exit)<br />
</pre><br />
This will insert the literal characters equivalent to the shell {{codeline|clear}} command. Optionally you can also insert the characters manually: <br />
<pre><br />
i (insert)<br />
ctrl-v (insert literal character)<br />
ESC (insert escape character)<br />
c<br />
ESC (exit insert mode)<br />
ZZ (Save and Exit)<br />
</pre><br />
<br />
In [[Emacs]]:<br />
C-q ESC (to insert literal escape)<br />
<br />
<!-- The tip is kind of unrelated to the article --><br />
{{tip|to just clear the screen after logging out on a virtual terminal, do: {{codeline|echo -e "clear\nreset" >> ~/.bash_logout}}}}<br />
<br />
== See Also ==<br />
*[[Inittab]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Nginx&diff=141068Nginx2011-05-11T07:16:49Z<p>JaMeSiTeGeN: /* Step 3: Restart nginx */</p>
<hr />
<div>{{i18n|NginX}}<br />
[[Category:HOWTOs (English)]]<br />
[[Category:Web Server (English)]]<br />
<br />
=Introduction =<br />
Nginx (pronounced "engine X") written by Igor Sysoev (Russia) in 2005, is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. According to the ''[http://news.netcraft.com/archives/2010/05/14/may_2010_web_server_survey.html May 2010 Web Server Survey]'', Nginx now hosts nearly 6.55% of all domains worldwide, while [[lighttpd]] hosts about 0.91%. Nginx is now well known for its stability, rich feature set, simple configuration, and low resource consumption.<br />
<br />
=Installation =<br />
The nginx package is now in the [community] repository, the latest stable version is nginx-1.0.0:<br />
# pacman -S nginx<br />
Or, you can compile and install the latest development version with ABS.<br />
<br />
=Starting service =<br />
Check that /etc/rc.d/nginx has this line correct:<br />
<br />
PID="/var/run/nginx.pid"<br />
<br />
Then, run:<br />
# rc start nginx<br />
<br />
To start the service, Nginx server should now be running. <br />
<br />
The default served (i.e. the page served at http://127.0.0.1) page is: <br />
/srv/http/nginx/index.html<br />
<br />
(The Nginx package does not install a default '''index.html''', you must create this one yourself if you wish). <br />
<br />
After creating a ''/srv/http/nginx/index.html'' webpage, you can use this URL: <nowiki>http://127.0.0.1</nowiki> to test if Nginx is working.<br />
<br />
To enable service by default at startup just add "nginx" to the DAEMONS in the /etc/rc.conf:<br />
<br />
DAEMONS=(syslog-ng hal .. nginx)<br />
<br />
=Configuring =<br />
<br />
You can modify the configurations by editing the files in ''/etc/nginx/conf''. (''/etc/nginx/conf/nginx.conf'' being the main config file). <br />
<br />
More details can be referred from [http://wiki.codemongers.com/NginxConfiguration Nginx Configuration Examples].<br />
<br />
==Use PHP/Python with Nginx ==<br />
FastCGI technology is introduced into Nginx to work with many external tools and servers, i.e: PHP and Python. So, you cannot use PHP or Python service unless FastCGI server has been started. <br />
<br />
PHP and Python can be run as FastCGI application and can process FastCGI requests from nginx.<br />
<br />
FastCGI is usually faster than implementations in e.g. Apache where PHP is loaded each time, with FastCGI the script is simply passed to the PHP deamon, and the appropriate value is returned and used by Nginx.<br />
<br />
===Step 1: Start the FastCGI server===<br />
There are two different ways to run FastCGI server. It is recommended to use [[NginX#Method_two_.28Third-party-wrapper.29]].<br />
<br />
====New method (As of PHP 5.3.3)====<br />
PHP now contains a FastCGI server spawner that takes care of everything for you.<br />
<br />
To get started: ( Just login as root, `su -` )<br />
$ su -c 'pacman -S php-fpm'<br />
$ su -c 'rc start php-fpm'<br />
<br />
{{Note|You can configure the number of servers in the pool and tweak other configuration options by editing the file {{Filename|/etc/php/php-fpm.conf}}. More details on ''php-fpm'' can be found on the [http://php-fpm.anight.org/ php-fpm website]}}<br />
<br />
====Old method (PHP's built-in)====<br />
Directly running PHP’s built-in FastCGI server - this method does not require any third party tools.<br />
<br />
Archlinux's '''''php''''' package in the [extra] repository has already enabled FastCGI support.<br />
<br />
For example:<br />
$ sudo pacman -S php php-cgi<br />
$ php-cgi -b 127.0.0.1:9000 &<br />
<br />
This command sets up the local machine as a FastCGI server using port 9000.<br />
<br />
{{Note|Since NginX 0.7.62, the default internal $document_root is /etc/nginx/html which is moved outside the default NginX directory and symlinked to /srv/http/nginx in the Arch package. For PHP to work with NginX 0.7.62 the open_basedir in /etc/php/php.ini has to contain the directory Filename|/etc/nginx/html. i.e. open_basedir = /etc/nginx/html/:/srv/http/:/home/:/tmp/:/usr/share/pear/}}<br />
<br />
Below is a daemon script to be used in {{Filename|/etc/rc.conf}} on boot to start PHP-cgi. save it as {{Filename||/etc/rc.d/fastcgi}} and add "fastcgi" to your DAEMONS array in ''/etc/rc.conf''<br />
<br />
#!/bin/bash<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
case "$1" in<br />
start)<br />
stat_busy 'Starting Fastcgi Server'<br />
if /usr/bin/php-cgi -b 127.0.0.1:9000 &<br />
then<br />
add_daemon fastcgi<br />
stat_done<br />
else<br />
stat_fail fi<br />
fi<br />
;;<br />
stop)<br />
stat_busy 'Stopping Fastcgi Server'<br />
[ -e /var/run/daemons/fastcgi ] && kill $(pidof php-cgi) &> /dev/null;<br />
if [ $? -gt 0 ]; then <br />
stat_fail<br />
else<br />
rm_daemon fastcgi<br />
stat_done<br />
fi<br />
;;<br />
restart)<br />
$0 stop<br />
$0 start<br />
;;<br />
*)<br />
echo "Usage: $0 {start|stop|restart}"<br />
esac<br />
<br />
====Method two (Third-party-wrapper)====<br />
This can be more comfortable than the first method because of increased flexibility.<br />
<br />
There are currently three options for deploying [[PHP]] on NginX:<br />
<br />
* ''fcgi''<br />
** Includes ''cgi-fcgi''<br />
* ''lighttpd''<br />
** Includes ''spawn-fcgi''<br />
* '''''PHP-FPM''''' (Recommended: see above)<br />
<br />
To spawn a process, issue one of the following commands (matching the package you installed):<br />
<br />
# cgi-fcgi -start -connect localhost:9000 /usr/bin/php-cgi<br />
<br />
# spawn-fcgi -a 127.0.0.1 -p 9000 -C 9 -f /usr/bin/php-cgi<br />
<br />
# php --fpm -b 127.0.0.1:<br />
<br />
{{Note|You may need to edit {{Filename|/etc/php/php-fpm.conf}} at first. More details on ''php-fpm'' can be found at the [http://php-fpm.anight.org/ php-fpm website]}}<br />
<br />
{{Note|Sometimes, you may encounter some permission issue when running some third party software to start PHP as FastCGI-server. See [[Nginx#Troubleshooting]]}}<br />
<br />
===Step 2: Edit /etc/nginx/conf/nginx.conf===<br />
#1: Add index.php after index.htm in this line: ''(example below has index.php already added, you need to add it to your file manually)''<br />
location / {<br />
root html;<br />
index index.html index.htm index.php;<br />
}<br />
<br />
#2: Un-comment these lines and edit in the file to be as follows:<br />
location ~ \.php$ {<br />
root html;<br />
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;<br />
fastcgi_index index.php; <br />
fastcgi_param SCRIPT_FILENAME /srv/http/nginx/$fastcgi_script_name;<br />
include fastcgi_params;<br />
}<br />
<br />
{{Note|If you are not using php-fpm, you may want to change the '''fastcgi_pass''' value to '''127.0.0.1:9000''', or whichever IP and port to which your server is configured to respond. Don't forget the semicolon at the end of the line.}}<br />
<br />
===Step 3: Restart nginx===<br />
If NginX has been working, run:<br />
# rc restart nginx<br />
<br />
Edit {{Filename|/srv/http/nginx/index.php}},<br />
<?phpinfo()?> <br />
Visit the URL: <nowiki>http://localhost/index.php</nowiki> with your browser, and you'll find PHP has worked well with NginX.<br />
<br />
==Ruby (Rack-based and Rails)==<br />
The [http://wiki.rubyonrails.org/ Ruby on Rails wiki] has tutorials on configuring Ruby for [http://nginx.org/ Nginx]. It is not recommended to use [http://www.fastcgi.com/drupal/ FastCGI] to make Nginx work with Ruby anymore, although very well possible.<br />
[http://nginx.org/ Nginx] and [http://modrails.com/ Passenger] are a great toolkit, and this setup is extremely easy to achieve on Arch Linux.<br />
It should be noted, however, that there are other alternatives, including [http://github.com/fauna/mongrel Mongrel], [http://code.macournoyer.com/thin/ Thin] and [http://unicorn.bogomips.org/ Unicorn].<br />
<br />
===Setting up Nginx and Passenger===<br />
Install the [http://aur.archlinux.org/packages.php?ID=28185 Nginx Passenger] package from AUR, and you are ready to go.<br />
<br />
For further information on setting up Nginx with Ruby, read the Nginx part of [http://wiki.rubyonrails.org/deployment/vps-setup-nginx-passenger this tutorial].<br />
<br />
{{Note|With Passenger you are also able to run other Rack-based applications, including Sinatra. Note, however, that these requires a {{Filename|config.ru}} file in the source directory.}}<br />
<br />
==phpMyAdmin Setup==<br />
<br />
See the following wiki article: [[PhpMyAdmin#NGINX_Configuration]].<br />
<br />
==Security ==<br />
* Allow/deny visitors based on IP <br />
[http://wiki.codemongers.com/NginxHttpAccessModule ngx_http_access_module]<br />
* HTTP authentication<br />
[http://wiki.codemongers.com/NginxHttpAuthBasicModule ngx_http_auth_basic_module]<br />
* HTTPS support<br />
[http://wiki.codemongers.com/NginxHttpSslModule ngx_http_ssl_module]<br />
<br />
=Troubleshooting=<br />
<br />
== Accessing local IP redirects to localhost ==<br />
Solution from [http://bbs.archlinux.org/viewtopic.php?pid=780561#p780561 forum].<br />
<br />
Edit ''/etc/nginx/nginx.conf'' and locate the "server_name localhost" line without a # infront of it, and add below:<br />
server_name_in_redirect off;<br />
<br />
Default behavior is that nginx redirects any requests to the value given as server_name in the config.<br />
<br />
==Error: 403 (Permission error)==<br />
This is most likely a permission error. Are you sure whatever user configured in the Nginx configuration is able to read the correct files?<br />
<br />
If the files are located within a home directory, (e.g. '''/home/arch/public/webapp''') and you are sure the user running Nginx has the right permissions (you can temporarily chmod all the files to 777 in order to determent this), '''/home/arch''' might be '''chmod 750''', simply '''chmod''' it to '''751''', and it should work.<br />
<br />
==Error: The page you are looking for is temporarily unavailable. Please try again later.==<br />
This is because the FastCGI server has not been started. <br />
<br />
==Error: No input file specified==<br />
Most Likely you don't have the SCRIPT_FILENAME containing the full path to you scripts.<br />
If the configuration of nginx (fastcgi_param SCRIPT_FILENAME) is all right, this kind of error means php fail to load the requestd script. Usually it's simply an permission issue, you can just run php-cgi as root<br />
# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi<br />
or you should create some group and user to start the php-cgi. For instance :<br />
$ sudo groupadd www<br />
$ sudo useradd -g www www<br />
$ sudo chmod +w /srv/www/nginx/html<br />
$ sudo chown -R www:www /srv/www/nginx/html<br />
$ sudo spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi<br />
<br />
Another occasion is that, wrong "root" argument in the "location ~ \.php$" section in nginx.conf, make sure the "root" points to the same directory as it in "location /" in the same server. Or you may just set root as global, don't define it in any location section.<br />
<br />
Also keep in mind that your php script path was defined as /srv/www/nginx/html by default using the variable "open_basedir" in /etc/php/php.ini, you can change them if you need.<br />
<br />
=References =<br />
*[http://nginx.net/ nginx Official Site]<br />
*[http://wiki.nginx.org/Main nginx Wiki]<br />
*[http://calomel.org/nginx.html nginx HOWTO] (Dead?)</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Nginx&diff=141067Nginx2011-05-11T06:57:24Z<p>JaMeSiTeGeN: /* New method (As of PHP 5.3.3) */</p>
<hr />
<div>{{i18n|NginX}}<br />
[[Category:HOWTOs (English)]]<br />
[[Category:Web Server (English)]]<br />
<br />
=Introduction =<br />
Nginx (pronounced "engine X") written by Igor Sysoev (Russia) in 2005, is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. According to the ''[http://news.netcraft.com/archives/2010/05/14/may_2010_web_server_survey.html May 2010 Web Server Survey]'', Nginx now hosts nearly 6.55% of all domains worldwide, while [[lighttpd]] hosts about 0.91%. Nginx is now well known for its stability, rich feature set, simple configuration, and low resource consumption.<br />
<br />
=Installation =<br />
The nginx package is now in the [community] repository, the latest stable version is nginx-1.0.0:<br />
# pacman -S nginx<br />
Or, you can compile and install the latest development version with ABS.<br />
<br />
=Starting service =<br />
Check that /etc/rc.d/nginx has this line correct:<br />
<br />
PID="/var/run/nginx.pid"<br />
<br />
Then, run:<br />
# rc start nginx<br />
<br />
To start the service, Nginx server should now be running. <br />
<br />
The default served (i.e. the page served at http://127.0.0.1) page is: <br />
/srv/http/nginx/index.html<br />
<br />
(The Nginx package does not install a default '''index.html''', you must create this one yourself if you wish). <br />
<br />
After creating a ''/srv/http/nginx/index.html'' webpage, you can use this URL: <nowiki>http://127.0.0.1</nowiki> to test if Nginx is working.<br />
<br />
To enable service by default at startup just add "nginx" to the DAEMONS in the /etc/rc.conf:<br />
<br />
DAEMONS=(syslog-ng hal .. nginx)<br />
<br />
=Configuring =<br />
<br />
You can modify the configurations by editing the files in ''/etc/nginx/conf''. (''/etc/nginx/conf/nginx.conf'' being the main config file). <br />
<br />
More details can be referred from [http://wiki.codemongers.com/NginxConfiguration Nginx Configuration Examples].<br />
<br />
==Use PHP/Python with Nginx ==<br />
FastCGI technology is introduced into Nginx to work with many external tools and servers, i.e: PHP and Python. So, you cannot use PHP or Python service unless FastCGI server has been started. <br />
<br />
PHP and Python can be run as FastCGI application and can process FastCGI requests from nginx.<br />
<br />
FastCGI is usually faster than implementations in e.g. Apache where PHP is loaded each time, with FastCGI the script is simply passed to the PHP deamon, and the appropriate value is returned and used by Nginx.<br />
<br />
===Step 1: Start the FastCGI server===<br />
There are two different ways to run FastCGI server. It is recommended to use [[NginX#Method_two_.28Third-party-wrapper.29]].<br />
<br />
====New method (As of PHP 5.3.3)====<br />
PHP now contains a FastCGI server spawner that takes care of everything for you.<br />
<br />
To get started: ( Just login as root, `su -` )<br />
$ su -c 'pacman -S php-fpm'<br />
$ su -c 'rc start php-fpm'<br />
<br />
{{Note|You can configure the number of servers in the pool and tweak other configuration options by editing the file {{Filename|/etc/php/php-fpm.conf}}. More details on ''php-fpm'' can be found on the [http://php-fpm.anight.org/ php-fpm website]}}<br />
<br />
====Old method (PHP's built-in)====<br />
Directly running PHP’s built-in FastCGI server - this method does not require any third party tools.<br />
<br />
Archlinux's '''''php''''' package in the [extra] repository has already enabled FastCGI support.<br />
<br />
For example:<br />
$ sudo pacman -S php php-cgi<br />
$ php-cgi -b 127.0.0.1:9000 &<br />
<br />
This command sets up the local machine as a FastCGI server using port 9000.<br />
<br />
{{Note|Since NginX 0.7.62, the default internal $document_root is /etc/nginx/html which is moved outside the default NginX directory and symlinked to /srv/http/nginx in the Arch package. For PHP to work with NginX 0.7.62 the open_basedir in /etc/php/php.ini has to contain the directory Filename|/etc/nginx/html. i.e. open_basedir = /etc/nginx/html/:/srv/http/:/home/:/tmp/:/usr/share/pear/}}<br />
<br />
Below is a daemon script to be used in {{Filename|/etc/rc.conf}} on boot to start PHP-cgi. save it as {{Filename||/etc/rc.d/fastcgi}} and add "fastcgi" to your DAEMONS array in ''/etc/rc.conf''<br />
<br />
#!/bin/bash<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
case "$1" in<br />
start)<br />
stat_busy 'Starting Fastcgi Server'<br />
if /usr/bin/php-cgi -b 127.0.0.1:9000 &<br />
then<br />
add_daemon fastcgi<br />
stat_done<br />
else<br />
stat_fail fi<br />
fi<br />
;;<br />
stop)<br />
stat_busy 'Stopping Fastcgi Server'<br />
[ -e /var/run/daemons/fastcgi ] && kill $(pidof php-cgi) &> /dev/null;<br />
if [ $? -gt 0 ]; then <br />
stat_fail<br />
else<br />
rm_daemon fastcgi<br />
stat_done<br />
fi<br />
;;<br />
restart)<br />
$0 stop<br />
$0 start<br />
;;<br />
*)<br />
echo "Usage: $0 {start|stop|restart}"<br />
esac<br />
<br />
====Method two (Third-party-wrapper)====<br />
This can be more comfortable than the first method because of increased flexibility.<br />
<br />
There are currently three options for deploying [[PHP]] on NginX:<br />
<br />
* ''fcgi''<br />
** Includes ''cgi-fcgi''<br />
* ''lighttpd''<br />
** Includes ''spawn-fcgi''<br />
* '''''PHP-FPM''''' (Recommended: see above)<br />
<br />
To spawn a process, issue one of the following commands (matching the package you installed):<br />
<br />
# cgi-fcgi -start -connect localhost:9000 /usr/bin/php-cgi<br />
<br />
# spawn-fcgi -a 127.0.0.1 -p 9000 -C 9 -f /usr/bin/php-cgi<br />
<br />
# php --fpm -b 127.0.0.1:<br />
<br />
{{Note|You may need to edit {{Filename|/etc/php/php-fpm.conf}} at first. More details on ''php-fpm'' can be found at the [http://php-fpm.anight.org/ php-fpm website]}}<br />
<br />
{{Note|Sometimes, you may encounter some permission issue when running some third party software to start PHP as FastCGI-server. See [[Nginx#Troubleshooting]]}}<br />
<br />
===Step 2: Edit /etc/nginx/conf/nginx.conf===<br />
#1: Add index.php after index.htm in this line: ''(example below has index.php already added, you need to add it to your file manually)''<br />
location / {<br />
root html;<br />
index index.html index.htm index.php;<br />
}<br />
<br />
#2: Un-comment these lines and edit in the file to be as follows:<br />
location ~ \.php$ {<br />
root html;<br />
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;<br />
fastcgi_index index.php; <br />
fastcgi_param SCRIPT_FILENAME /srv/http/nginx/$fastcgi_script_name;<br />
include fastcgi_params;<br />
}<br />
<br />
{{Note|If you are not using php-fpm, you may want to change the '''fastcgi_pass''' value to '''127.0.0.1:9000''', or whichever IP and port to which your server is configured to respond. Don't forget the semicolon at the end of the line.}}<br />
<br />
===Step 3: Restart nginx===<br />
If NginX has been working, run:<br />
# /etc/rc.d/nginx restart<br />
<br />
Edit {{Filename|/srv/http/nginx/index.php}},<br />
<?php<br />
phpinfo();<br />
?> <br />
Visit the URL: <nowiki>http://localhost/index.php</nowiki> with your browser, and you'll find PHP has worked well with NginX.<br />
<br />
==Ruby (Rack-based and Rails)==<br />
The [http://wiki.rubyonrails.org/ Ruby on Rails wiki] has tutorials on configuring Ruby for [http://nginx.org/ Nginx]. It is not recommended to use [http://www.fastcgi.com/drupal/ FastCGI] to make Nginx work with Ruby anymore, although very well possible.<br />
[http://nginx.org/ Nginx] and [http://modrails.com/ Passenger] are a great toolkit, and this setup is extremely easy to achieve on Arch Linux.<br />
It should be noted, however, that there are other alternatives, including [http://github.com/fauna/mongrel Mongrel], [http://code.macournoyer.com/thin/ Thin] and [http://unicorn.bogomips.org/ Unicorn].<br />
<br />
===Setting up Nginx and Passenger===<br />
Install the [http://aur.archlinux.org/packages.php?ID=28185 Nginx Passenger] package from AUR, and you are ready to go.<br />
<br />
For further information on setting up Nginx with Ruby, read the Nginx part of [http://wiki.rubyonrails.org/deployment/vps-setup-nginx-passenger this tutorial].<br />
<br />
{{Note|With Passenger you are also able to run other Rack-based applications, including Sinatra. Note, however, that these requires a {{Filename|config.ru}} file in the source directory.}}<br />
<br />
==phpMyAdmin Setup==<br />
<br />
See the following wiki article: [[PhpMyAdmin#NGINX_Configuration]].<br />
<br />
==Security ==<br />
* Allow/deny visitors based on IP <br />
[http://wiki.codemongers.com/NginxHttpAccessModule ngx_http_access_module]<br />
* HTTP authentication<br />
[http://wiki.codemongers.com/NginxHttpAuthBasicModule ngx_http_auth_basic_module]<br />
* HTTPS support<br />
[http://wiki.codemongers.com/NginxHttpSslModule ngx_http_ssl_module]<br />
<br />
=Troubleshooting=<br />
<br />
== Accessing local IP redirects to localhost ==<br />
Solution from [http://bbs.archlinux.org/viewtopic.php?pid=780561#p780561 forum].<br />
<br />
Edit ''/etc/nginx/nginx.conf'' and locate the "server_name localhost" line without a # infront of it, and add below:<br />
server_name_in_redirect off;<br />
<br />
Default behavior is that nginx redirects any requests to the value given as server_name in the config.<br />
<br />
==Error: 403 (Permission error)==<br />
This is most likely a permission error. Are you sure whatever user configured in the Nginx configuration is able to read the correct files?<br />
<br />
If the files are located within a home directory, (e.g. '''/home/arch/public/webapp''') and you are sure the user running Nginx has the right permissions (you can temporarily chmod all the files to 777 in order to determent this), '''/home/arch''' might be '''chmod 750''', simply '''chmod''' it to '''751''', and it should work.<br />
<br />
==Error: The page you are looking for is temporarily unavailable. Please try again later.==<br />
This is because the FastCGI server has not been started. <br />
<br />
==Error: No input file specified==<br />
Most Likely you don't have the SCRIPT_FILENAME containing the full path to you scripts.<br />
If the configuration of nginx (fastcgi_param SCRIPT_FILENAME) is all right, this kind of error means php fail to load the requestd script. Usually it's simply an permission issue, you can just run php-cgi as root<br />
# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi<br />
or you should create some group and user to start the php-cgi. For instance :<br />
$ sudo groupadd www<br />
$ sudo useradd -g www www<br />
$ sudo chmod +w /srv/www/nginx/html<br />
$ sudo chown -R www:www /srv/www/nginx/html<br />
$ sudo spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi<br />
<br />
Another occasion is that, wrong "root" argument in the "location ~ \.php$" section in nginx.conf, make sure the "root" points to the same directory as it in "location /" in the same server. Or you may just set root as global, don't define it in any location section.<br />
<br />
Also keep in mind that your php script path was defined as /srv/www/nginx/html by default using the variable "open_basedir" in /etc/php/php.ini, you can change them if you need.<br />
<br />
=References =<br />
*[http://nginx.net/ nginx Official Site]<br />
*[http://wiki.nginx.org/Main nginx Wiki]<br />
*[http://calomel.org/nginx.html nginx HOWTO] (Dead?)</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Nginx&diff=141066Nginx2011-05-11T06:39:57Z<p>JaMeSiTeGeN: /* Starting service */</p>
<hr />
<div>{{i18n|NginX}}<br />
[[Category:HOWTOs (English)]]<br />
[[Category:Web Server (English)]]<br />
<br />
=Introduction =<br />
Nginx (pronounced "engine X") written by Igor Sysoev (Russia) in 2005, is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server. According to the ''[http://news.netcraft.com/archives/2010/05/14/may_2010_web_server_survey.html May 2010 Web Server Survey]'', Nginx now hosts nearly 6.55% of all domains worldwide, while [[lighttpd]] hosts about 0.91%. Nginx is now well known for its stability, rich feature set, simple configuration, and low resource consumption.<br />
<br />
=Installation =<br />
The nginx package is now in the [community] repository, the latest stable version is nginx-1.0.0:<br />
# pacman -S nginx<br />
Or, you can compile and install the latest development version with ABS.<br />
<br />
=Starting service =<br />
Check that /etc/rc.d/nginx has this line correct:<br />
<br />
PID="/var/run/nginx.pid"<br />
<br />
Then, run:<br />
# rc start nginx<br />
<br />
To start the service, Nginx server should now be running. <br />
<br />
The default served (i.e. the page served at http://127.0.0.1) page is: <br />
/srv/http/nginx/index.html<br />
<br />
(The Nginx package does not install a default '''index.html''', you must create this one yourself if you wish). <br />
<br />
After creating a ''/srv/http/nginx/index.html'' webpage, you can use this URL: <nowiki>http://127.0.0.1</nowiki> to test if Nginx is working.<br />
<br />
To enable service by default at startup just add "nginx" to the DAEMONS in the /etc/rc.conf:<br />
<br />
DAEMONS=(syslog-ng hal .. nginx)<br />
<br />
=Configuring =<br />
<br />
You can modify the configurations by editing the files in ''/etc/nginx/conf''. (''/etc/nginx/conf/nginx.conf'' being the main config file). <br />
<br />
More details can be referred from [http://wiki.codemongers.com/NginxConfiguration Nginx Configuration Examples].<br />
<br />
==Use PHP/Python with Nginx ==<br />
FastCGI technology is introduced into Nginx to work with many external tools and servers, i.e: PHP and Python. So, you cannot use PHP or Python service unless FastCGI server has been started. <br />
<br />
PHP and Python can be run as FastCGI application and can process FastCGI requests from nginx.<br />
<br />
FastCGI is usually faster than implementations in e.g. Apache where PHP is loaded each time, with FastCGI the script is simply passed to the PHP deamon, and the appropriate value is returned and used by Nginx.<br />
<br />
===Step 1: Start the FastCGI server===<br />
There are two different ways to run FastCGI server. It is recommended to use [[NginX#Method_two_.28Third-party-wrapper.29]].<br />
<br />
====New method (As of PHP 5.3.3)====<br />
PHP now contains a FastCGI server spawner that takes care of everything for you.<br />
<br />
To get started:<br />
$ sudo pacman -S php-fpm<br />
$ sudo /etc/rc.d/php-fpm start<br />
<br />
{{Note|You can configure the number of servers in the pool and tweak other configuration options by editing the file {{Filename|/etc/php/php-fpm.conf}}. More details on ''php-fpm'' can be found on the [http://php-fpm.anight.org/ php-fpm website]}}<br />
<br />
====Old method (PHP's built-in)====<br />
Directly running PHP’s built-in FastCGI server - this method does not require any third party tools.<br />
<br />
Archlinux's '''''php''''' package in the [extra] repository has already enabled FastCGI support.<br />
<br />
For example:<br />
$ sudo pacman -S php php-cgi<br />
$ php-cgi -b 127.0.0.1:9000 &<br />
<br />
This command sets up the local machine as a FastCGI server using port 9000.<br />
<br />
{{Note|Since NginX 0.7.62, the default internal $document_root is /etc/nginx/html which is moved outside the default NginX directory and symlinked to /srv/http/nginx in the Arch package. For PHP to work with NginX 0.7.62 the open_basedir in /etc/php/php.ini has to contain the directory Filename|/etc/nginx/html. i.e. open_basedir = /etc/nginx/html/:/srv/http/:/home/:/tmp/:/usr/share/pear/}}<br />
<br />
Below is a daemon script to be used in {{Filename|/etc/rc.conf}} on boot to start PHP-cgi. save it as {{Filename||/etc/rc.d/fastcgi}} and add "fastcgi" to your DAEMONS array in ''/etc/rc.conf''<br />
<br />
#!/bin/bash<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
case "$1" in<br />
start)<br />
stat_busy 'Starting Fastcgi Server'<br />
if /usr/bin/php-cgi -b 127.0.0.1:9000 &<br />
then<br />
add_daemon fastcgi<br />
stat_done<br />
else<br />
stat_fail fi<br />
fi<br />
;;<br />
stop)<br />
stat_busy 'Stopping Fastcgi Server'<br />
[ -e /var/run/daemons/fastcgi ] && kill $(pidof php-cgi) &> /dev/null;<br />
if [ $? -gt 0 ]; then <br />
stat_fail<br />
else<br />
rm_daemon fastcgi<br />
stat_done<br />
fi<br />
;;<br />
restart)<br />
$0 stop<br />
$0 start<br />
;;<br />
*)<br />
echo "Usage: $0 {start|stop|restart}"<br />
esac<br />
<br />
====Method two (Third-party-wrapper)====<br />
This can be more comfortable than the first method because of increased flexibility.<br />
<br />
There are currently three options for deploying [[PHP]] on NginX:<br />
<br />
* ''fcgi''<br />
** Includes ''cgi-fcgi''<br />
* ''lighttpd''<br />
** Includes ''spawn-fcgi''<br />
* '''''PHP-FPM''''' (Recommended: see above)<br />
<br />
To spawn a process, issue one of the following commands (matching the package you installed):<br />
<br />
# cgi-fcgi -start -connect localhost:9000 /usr/bin/php-cgi<br />
<br />
# spawn-fcgi -a 127.0.0.1 -p 9000 -C 9 -f /usr/bin/php-cgi<br />
<br />
# php --fpm -b 127.0.0.1:<br />
<br />
{{Note|You may need to edit {{Filename|/etc/php/php-fpm.conf}} at first. More details on ''php-fpm'' can be found at the [http://php-fpm.anight.org/ php-fpm website]}}<br />
<br />
{{Note|Sometimes, you may encounter some permission issue when running some third party software to start PHP as FastCGI-server. See [[Nginx#Troubleshooting]]}}<br />
<br />
===Step 2: Edit /etc/nginx/conf/nginx.conf===<br />
#1: Add index.php after index.htm in this line: ''(example below has index.php already added, you need to add it to your file manually)''<br />
location / {<br />
root html;<br />
index index.html index.htm index.php;<br />
}<br />
<br />
#2: Un-comment these lines and edit in the file to be as follows:<br />
location ~ \.php$ {<br />
root html;<br />
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;<br />
fastcgi_index index.php; <br />
fastcgi_param SCRIPT_FILENAME /srv/http/nginx/$fastcgi_script_name;<br />
include fastcgi_params;<br />
}<br />
<br />
{{Note|If you are not using php-fpm, you may want to change the '''fastcgi_pass''' value to '''127.0.0.1:9000''', or whichever IP and port to which your server is configured to respond. Don't forget the semicolon at the end of the line.}}<br />
<br />
===Step 3: Restart nginx===<br />
If NginX has been working, run:<br />
# /etc/rc.d/nginx restart<br />
<br />
Edit {{Filename|/srv/http/nginx/index.php}},<br />
<?php<br />
phpinfo();<br />
?> <br />
Visit the URL: <nowiki>http://localhost/index.php</nowiki> with your browser, and you'll find PHP has worked well with NginX.<br />
<br />
==Ruby (Rack-based and Rails)==<br />
The [http://wiki.rubyonrails.org/ Ruby on Rails wiki] has tutorials on configuring Ruby for [http://nginx.org/ Nginx]. It is not recommended to use [http://www.fastcgi.com/drupal/ FastCGI] to make Nginx work with Ruby anymore, although very well possible.<br />
[http://nginx.org/ Nginx] and [http://modrails.com/ Passenger] are a great toolkit, and this setup is extremely easy to achieve on Arch Linux.<br />
It should be noted, however, that there are other alternatives, including [http://github.com/fauna/mongrel Mongrel], [http://code.macournoyer.com/thin/ Thin] and [http://unicorn.bogomips.org/ Unicorn].<br />
<br />
===Setting up Nginx and Passenger===<br />
Install the [http://aur.archlinux.org/packages.php?ID=28185 Nginx Passenger] package from AUR, and you are ready to go.<br />
<br />
For further information on setting up Nginx with Ruby, read the Nginx part of [http://wiki.rubyonrails.org/deployment/vps-setup-nginx-passenger this tutorial].<br />
<br />
{{Note|With Passenger you are also able to run other Rack-based applications, including Sinatra. Note, however, that these requires a {{Filename|config.ru}} file in the source directory.}}<br />
<br />
==phpMyAdmin Setup==<br />
<br />
See the following wiki article: [[PhpMyAdmin#NGINX_Configuration]].<br />
<br />
==Security ==<br />
* Allow/deny visitors based on IP <br />
[http://wiki.codemongers.com/NginxHttpAccessModule ngx_http_access_module]<br />
* HTTP authentication<br />
[http://wiki.codemongers.com/NginxHttpAuthBasicModule ngx_http_auth_basic_module]<br />
* HTTPS support<br />
[http://wiki.codemongers.com/NginxHttpSslModule ngx_http_ssl_module]<br />
<br />
=Troubleshooting=<br />
<br />
== Accessing local IP redirects to localhost ==<br />
Solution from [http://bbs.archlinux.org/viewtopic.php?pid=780561#p780561 forum].<br />
<br />
Edit ''/etc/nginx/nginx.conf'' and locate the "server_name localhost" line without a # infront of it, and add below:<br />
server_name_in_redirect off;<br />
<br />
Default behavior is that nginx redirects any requests to the value given as server_name in the config.<br />
<br />
==Error: 403 (Permission error)==<br />
This is most likely a permission error. Are you sure whatever user configured in the Nginx configuration is able to read the correct files?<br />
<br />
If the files are located within a home directory, (e.g. '''/home/arch/public/webapp''') and you are sure the user running Nginx has the right permissions (you can temporarily chmod all the files to 777 in order to determent this), '''/home/arch''' might be '''chmod 750''', simply '''chmod''' it to '''751''', and it should work.<br />
<br />
==Error: The page you are looking for is temporarily unavailable. Please try again later.==<br />
This is because the FastCGI server has not been started. <br />
<br />
==Error: No input file specified==<br />
Most Likely you don't have the SCRIPT_FILENAME containing the full path to you scripts.<br />
If the configuration of nginx (fastcgi_param SCRIPT_FILENAME) is all right, this kind of error means php fail to load the requestd script. Usually it's simply an permission issue, you can just run php-cgi as root<br />
# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi<br />
or you should create some group and user to start the php-cgi. For instance :<br />
$ sudo groupadd www<br />
$ sudo useradd -g www www<br />
$ sudo chmod +w /srv/www/nginx/html<br />
$ sudo chown -R www:www /srv/www/nginx/html<br />
$ sudo spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi<br />
<br />
Another occasion is that, wrong "root" argument in the "location ~ \.php$" section in nginx.conf, make sure the "root" points to the same directory as it in "location /" in the same server. Or you may just set root as global, don't define it in any location section.<br />
<br />
Also keep in mind that your php script path was defined as /srv/www/nginx/html by default using the variable "open_basedir" in /etc/php/php.ini, you can change them if you need.<br />
<br />
=References =<br />
*[http://nginx.net/ nginx Official Site]<br />
*[http://wiki.nginx.org/Main nginx Wiki]<br />
*[http://calomel.org/nginx.html nginx HOWTO] (Dead?)</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=GNOME&diff=140376GNOME2011-05-08T08:20:34Z<p>JaMeSiTeGeN: </p>
<hr />
<div>{{i18n|GNOME 3}}<br />
[[fr:gnome3]]<br />
<br />
[[Category:Desktop environments (English)]]<br />
[[Category:HOWTOs (English)]]<br />
<br />
{{Article summary start}}<br />
{{Article summary text|GNOME 3 provides a modern desktop, rewritten from scratch, using the GTK3+ toolkit.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Graphical user interface overview}}}}<br />
{{Article summary end}}<br />
<br />
For GNOME 3, the GNOME Project has started from scratch and created a completely new, modern desktop designed for today's users and technologies. In GNOME 3:<br />
* There is a new default modern visual theme and font<br />
* The Activities view which provides an easy way to access all your windows and applications<br />
* Built-in (integrated) messaging desktop services<br />
* A more subtle notifications system and a more discrete panel<br />
* A fast Activities search feature<br />
* A new System Settings application <br />
* ... and more features like: window tiling (Aero Snap like), an improved Nautilus etc. <br />
<br />
[more details on the [http://www.gnome3.org/ GNOME3] website]<br />
<br />
== Introduction ==<br />
<br />
GNOME3 comes with '''two''' interfaces, '''gnome-shell''' (the new, standard layout) and '''fallback''' mode. gnome-session will automatically detect if your computer is capable of running gnome-shell and will start fallback mode if not. <br />
<br />
'''Fallback''' mode is very similar to the GNOME 2.x layout (while using gnome-panel and metacity, instead of gnome-shell and Mutter).<br />
<br />
If you are on fallback mode you can still change the window manager with your preferred one.<br />
<br />
== Upgrade from the current gnome 2.32 ==<br />
<br />
{{Warning|The session might crash during the update and it is recommended that you run the update command in a screen session, from another DE or WM, or from tty}}<br />
<br />
# pacman -Syu <br />
<br />
'''Important''': You will end up with a system that has GNOME 3.x '''fallback''' mode. To install the new shell:<br />
<br />
# pacman -S gnome-shell<br />
<br />
== Installing to a new system ==<br />
<br />
GNOME 3 is in [extra]. You can install it by running the following command:<br />
<br />
# pacman -Syu gnome<br />
<br />
For additional applications<br />
<br />
# pacman -Syu gnome-extra<br />
<br />
===Daemons and modules needed by GNOME===<br />
<br />
The GNOME desktop requires one daemon, '''DBUS''' for proper operation. <br />
<br />
To start the DBUS daemon:<br />
# rc start dbus<br />
<br />
Or add these daemons to the '''DAEMONS''' array in {{Filename|/etc/[[rc.conf]]}} so they will start on boot up, e.g.:<br />
<br />
DAEMONS=(syslog-ng '''dbus''' network crond)<br />
<br />
'''GVFS''' allows the mounting of virtual file systems (e.g. file systems over FTP or SMB) to be used by other applications, including the GNOME file manager Nautilus. This is done with the use of '''FUSE''': a user space virtual file system layer kernel module.<br />
<br />
To load the FUSE kernel module:<br />
# modprobe fuse<br />
<br />
Or add the module to the '''MODULES''' array in {{Filename|/etc/rc.conf}} so they will load at boot up, e.g.:<br />
<br />
MODULES=('''fuse''' usblp)<br />
<br />
{{Note|FUSE is a kernel module, not a daemon.}}<br />
<br />
===Running GNOME===<br />
<br />
For better desktop integration '''GDM''' is recommended (but other login managers, such as SLiM also work, see Policykit section).<br />
<br />
# pacman -S gdm<br />
<br />
Check out [[Display_Manager]] to learn how to start it correctly.<br />
<br />
If you prefer to start it from the console, add the following line to your {{Filename|~/.xinitrc}} file, making sure it's the last line and the only one that starts with ''exec'' (see [[xinitrc]]):<br />
exec ck-launch-session gnome-session<br />
<br />
Now GNOME will start when you enter the following command:<br />
$ startx<br />
<br />
== Using the shell ==<br />
<br />
See https://live.gnome.org/GnomeShell/CheatSheet<br />
<br />
== Customization ==<br />
=== Using Gnome-tweak-tool ===<br />
<br />
# pacman -S gnome-tweak-tool<br />
<br />
This tool can customize fonts, themes, minimize & maximize buttons and some other useful settings like what action is taken when the lid is closed.<br />
<br />
A good customization tutorial is http://blog.fpmurphy.com/2011/03/customizing-the-gnome-3-shell.html which explores the power of gsettings.<br />
<br />
===GDM Customization===<br />
<br />
# su - gdm -s /bin/bash<br />
$ dbus-launch<br />
<br />
This command will print DBUS_SESSION_BUS_ADDRESS and DBUS_SESSION_BUS_PID. We need to export them<br />
<br />
$ export DBUS_SESSION_BUS_ADDRESS=unix:abstract=/tmp/dbus-Jb433gMQHS,guid=fc14d4bf3d000e38276a5a2200000d38<br />
$ export DBUS_SESSION_BUS_PID=4283<br />
<br />
Check to see if dconf-service is running and if not, start it like this<br />
<br />
$ /usr/lib/dconf/dconf-service &<br />
<br />
====Wallpaper====<br />
$ GSETTINGS_BACKEND=dconf gsettings get org.gnome.desktop.background picture-uri<br />
$ GSETTINGS_BACKEND=dconf gsettings set org.gnome.desktop.background picture-uri "file:///usr/share/backgrounds/gnome/SundownDunes.jpg"<br />
<br />
You will need to point to a file where the gdm user has permission to read, not in your home directory.<br />
<br />
====Turning off the sound====<br />
$ GSETTINGS_BACKEND=dconf gsettings set org.gnome.desktop.sound event-sounds false<br />
<br />
====Change GDM's keyboard layout====<br />
Since GDM 3 does not care about your gnome keyboard settings, you have to set your layout to Xorg config.<br />
See here: [https://wiki.archlinux.org/index.php/Beginners'_Guide#Non-US_keyboard Beginners'_Guide#Non-US_keyboard]<br />
<br />
=== Changing the GTK3 theme using settings.ini ===<br />
<br />
Similar to {{Filename|~/.gtkrc-2.0}} for GTK2+ it is possible to set the GTK3 (Gnome 3) theme via {{Filename|${XDG_CONFIG_HOME}/gtk-3.0/settings.ini}}. By default {{Filename|${XDG_CONFIG_HOME} }} is interpreted as {{Filename|~/.config}}.<br />
<br />
Only Adwaita theme exists in this moment for gtk3 and is available in '''gnome-themes-standard''' package.<br />
<br />
Example:<br />
<br />
[Settings]<br />
gtk-theme-name = Adwaita<br />
gtk-fallback-icon-theme = gnome<br />
# next option is applicable only if selected theme supports it<br />
gtk-application-prefer-dark-theme = true<br />
# set font name and dimension<br />
gtk-font-name = Sans 10<br />
<br />
It may be necessary to restart one's DE or WM for the settings to be applied.<br />
<br />
{{Note|More options can be find there: [http://developer.gnome.org/gtk3/3.0/GtkSettings.html#GtkSettings.properties GtkSettings documentation]}}<br />
<br />
=== Resizing the Massive Titlebar ===<br />
# sed -i "/title_vertical_pad/s/value=\"[0-9]\{1,2\}\"/value=\"0\"/g" /usr/share/themes/Adwaita/metacity-1/metacity-theme-3.xml<br />
<br />
Hit {{Keypress|Alt}} + {{Keypress|F2}} and type ''restart'' followed by {{Keypress|Enter}} <br />
<br />
This will change the title_vertical_pad from 14 to 0 giving a much sleeker look to windows.<br />
<br />
To restore the original values:<br />
sudo pacman -S gnome-themes-standard<br />
<br />
===Setting an icon theme===<br />
<br />
{{Note | With gnome-tweak-tool version 3.0.3 and later, you can place icon theme you wish to use inside ~/.icons.}}<br />
<br />
Usefully, Gnome 3 is able to use Gnome 2 icon themes, which means you're not stuck with the default set. To do this, simply copy your desired icon theme's directory to ~/.icons. For example:<br />
<br />
$ cp -R /home/user/Desktop/my_new_icon_theme ~/.icons<br />
<br />
The new icon theme 'my_new_icon_theme' will now be selectable using the gnome-tweak-tool (under 'Interface'), otherwise it can be set with no need of gnome-tweak-tool by adding the gtk-icon-theme-name entry inside ${XDG_CONFIG_HOME}/gtk-3.0/settings.ini.<br />
{{file|name=${XDG_CONFIG_HOME}/gtk-3.0/settings.ini|content=<br />
.....<br />
gtk-icon-theme-name = my_new_icon_theme<br />
.....<br />
}}<br />
<br />
=== Start program automatically after login to GNOME 3 ===<br />
You can specify which programs to start automatically after login using the '''gnome-session-properties''' tool, which is a part of the '''gnome-session''' package.<br />
$ gnome-session-properties<br />
<br />
=== Removing folders from the "Computer" section in Nautilus's Places sidebar ===<br />
<br />
The displayed folders are specified in {{Filename|~/.config/user-dirs.dirs}} and can be altered with any editor. An execution of {{codeline|xdg-user-dirs-update}} will change them again, thus it may be advisable to set the file permissions to read-only.<br />
<br />
=== Setting the default terminal via console ===<br />
<br />
{{codeline|gsettings}}, which replaces {{codeline|gconftool-2}} in Gnome 3, is used to set e. g. the default terminal manually. The setting is relevant for ''nautilus-open-terminal''.<br />
<br />
The commands for [[rxvt-unicode|urxvt]] run as daemon:<br />
<br />
gsettings set org.gnome.desktop.default-applications.terminal exec urxvtc<br />
gsettings set org.gnome.desktop.default-applications.terminal exec-arg "'-e'"<br />
<br />
=== Setting Nautilus to Use Location Bar Entry ===<br />
<br />
If you want to enter path locations manually in Nautilus you can press ctrl+l. To make this persistent you can use gsettings.<br />
<br />
gsettings set org.gnome.nautilus.preferences always-use-location-entry true<br />
<br />
=== Disable accessibility icon in panel ===<br />
First deactivate it as startup-service: [[GNOME_3#Start_program_automatically_after_login_to_GNOME_3]]<br />
<br />
After that create a folder named '''noa11y.icon@panel.ui''' in '''$HOME/.local/share/gnome-shell/extensions'''. In this folder create two files. The first one is named '''extension.js''' and has this content:<br />
const Panel = imports.ui.panel;<br />
<br />
function main() {<br />
Panel.STANDARD_TRAY_ICON_SHELL_IMPLEMENTATION['a11y'] = ''''''';<br />
}<br />
The second one is named '''metadata.json''' and has this content:<br />
{<br />
"shell-version": ["3.0.1"],<br />
"uuid": "noa11y.icon@panel.ui",<br />
"name": "na11y",<br />
"description": "Turn off the ally icon in the panel"<br />
}<br />
Now restart the gnome-shell (press '''ALT+F2''', type '''r''' and press '''Enter''') and the icon is away. If this extensions stops working adjust the shell-version number in the metadata-file according to your version.<br />
<br />
=== Disable bluetooth icon in panel ===<br />
First deactivate it as startup-service: [[GNOME_3#Start_program_automatically_after_login_to_GNOME_3]]<br />
<br />
After that create a folder named '''nobluetooth.icon@panel.ui''' in '''$HOME/.local/share/gnome-shell/extensions'''. In this folder create two files. The first one is named '''extension.js''' and has this content:<br />
const Panel = imports.ui.panel;<br />
<br />
function main() {<br />
Panel.STANDARD_TRAY_ICON_SHELL_IMPLEMENTATION['bluetooth'] = ''''''';<br />
}<br />
The second one is named '''metadata.json''' and has this content:<br />
{<br />
"shell-version": ["3.0.1"],<br />
"uuid": "nobluetooth.icon@panel.ui",<br />
"name": "nbluetooth",<br />
"description": "Turn off the bluetooth icon in the panel"<br />
}<br />
Now restart the gnome-shell (press '''ALT+F2''', type '''r''' and press '''Enter''') and the icon is away. If this extensions stops working adjust the shell-version number in the metadata-file according to your version.<br />
<br />
=== Middle Mouse Button Emulation ===<br />
<br />
By default, GNOME 3 disables middle mouse button emulation regardless of Xorg settings ('''Emulate3Buttons'''). To enable middle mouse button emulation use:<br />
<br />
gsettings set org.gnome.settings-daemon.peripherals.mouse middle-button-enabled true<br />
<br />
=== Battery icon ===<br />
To have battery tray icon, install gnome-power-manager package:<br />
# pacman -S gnome-power-manager<br />
<br />
== Enabling fallback mode==<br />
<br />
Your session will automatically start in fallback mode if gnome-shell is not present or if your desktop cannot handle graphics acceleration (such as running in a Virtual Machine or on old hardware). If you want to enable it while having gnome-shell installed, open gnome-control-center. Open System Info > Graphics. Change ''Forced Fallback Mode'' to ''ON''.<br />
<br />
== Enabling hidden features ==<br />
<br />
Gnome 3.0 hides a lot of useful options which you can customize with '''dconf-editor''' or '''gconf-editor''' for settings not yet migrated to dconf.<br />
<br />
=== Changing Hotkeys ===<br />
<br />
In '''dconf-editor''', enable org.gnome.desktop.interface "can-change-accels".<br />
<br />
An example of changing the delete hotkey:<br />
Open nautilus, select any file/directory, then click "Edit" from the menubar, and hover over the "Move to Trash" menuitem.<br />
While hovering, push '''delete''', and default accel will be unset. Now push the key that you want to set as accel. <br />
i.e. Pushing again '''delete''', will make the accel change to "del".<br />
<br />
Make sure you have selected a file, else the "Move to Trash" menuitem will be greyed out.<br />
You should disable "can-change-accels" afterwards, to prevent accidental accel changes.<br />
<br />
== How to shutdown through the Status menu ==<br />
<br />
For now, the Shutdown option seems to be hidden if the user presses the Status menu on the upper right. If you want to shutdown your system through the Status menu, click on it and then press the '''Alt''' button. The "'''Suspend'''" option will instantly turn into "Power off...", as long as you are pressing the Alt button, which will allow you to properly shutdown your system.<br />
<br />
You can also install the "Alternative Status Menu" extension (see the section on Enabling Extensions, below). This will put a permanent "Power Off" option in the Status menu below the usual suspend option.<br />
<br />
== Enabling integrated messaging ==<br />
<br />
Empathy, the engine behind the integrated messaging, and all of the system settings based on your messaging accounts will not show up unless the '''telepathy''' group of packages or at least one of the backends ('''telepathy-gabble''', or '''telepathy-haze''', for example) is installed. These are not included in the default Arch GNOME installs and the Empathy interface doesn't give a nice error message, it just fails to work silently. You can install them:<br />
<br />
# pacman -S telepathy<br />
<br />
== Enabling extensions ==<br />
<br />
Gnome Shell can be customised to an extent with extensions that have been written by others. These provide functionality like having a dock that is always present, and being able to change the shell theme. More details on the functionality of currently available extensions is given [http://www.webupd8.org/2011/04/gnome-shell-extensions-additional.html here] You can use the [http://aur.archlinux.org/packages.php?ID=47501 gnome-shell-extensions-git] package in the AUR to install them. Restart Gnome to enable them.<br />
<br />
If installing the extensions causes Gnome to stop working then you must remove the user-theme extension and and the auto-move-windows extension from their installation directory (could be in ~/.local/share/gnome-shell/extensions or /usr/share/gnome-shell/extensions or /usr/local/share/gnome-shell/extensions). Removing or adding extensions to these directories will remove or install them form the system. More details on Gnome Shell extensions are available [https://live.gnome.org/GnomeShell/Extensions here].<br />
<br />
== Troubleshooting ==<br />
<br />
=== My screen isn't locked after resume from suspend/hibernate ===<br />
<br />
Screen lock does only work when you suspend through gnome status menu. If you suspend or hibernate with powerbutton/etc. you screen is not locked after resume. This problem occours because of an config failure in dconf, so just open dconf-editor and change lock-use screensaver to false (unchecked) in org/gnome/power-manager. Your screen will no be locked after resume, regardless whether you used gnome status menu or power button or key combination.<br />
For more information see bugreport: [https://bugzilla.redhat.com/show_bug.cgi?id=698135#c8 Screen gets no more locked after suspend#Comment 8]<br />
<br />
=== My GTK2+ apps show segfaults and won't start ===<br />
<br />
That usually happens when '''oxygen-gtk''' is installed. That theme conflicts somehow with GNOME 3's or/and GTK3 settings and when it has been set as a GTK2 theme, the GTK2 apps segfault with errors like:<br />
<br />
<pre> (firefox-bin:14345): GLib-GObject-WARNING **: invalid (NULL) pointer instance<br />
<br />
(firefox-bin:14345): GLib-GObject-CRITICAL **: g_signal_connect_data: assertion `G_TYPE_CHECK_INSTANCE (instance)' failed<br />
<br />
(firefox-bin:14345): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion `GDK_IS_SCREEN (screen)' failed<br />
<br />
(firefox-bin:14345): Gdk-CRITICAL **: IA__gdk_colormap_get_visual: assertion `GDK_IS_COLORMAP (colormap)' failed<br />
<br />
(firefox-bin:14345): Gdk-CRITICAL **: IA__gdk_screen_get_default_colormap: assertion `GDK_IS_SCREEN (screen)' failed<br />
<br />
(firefox-bin:14345): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion `GDK_IS_SCREEN (screen)' failed<br />
<br />
(firefox-bin:14345): Gdk-CRITICAL **: IA__gdk_screen_get_root_window: assertion `GDK_IS_SCREEN (screen)' failed<br />
<br />
(firefox-bin:14345): Gdk-CRITICAL **: IA__gdk_window_new: assertion `GDK_IS_WINDOW (parent)' failed<br />
Segmentation fault<br />
</pre><br />
<br />
The current "workaround" is to '''remove''' '''oxygen-gtk''' from the system completely and set another theme for your apps.<br />
<br />
=== Nautilus segmentation fault in non-GNOME environments ===<br />
Nautilus 3.x depends on gnome-icon-theme and will seg fault if it's missing. See [https://bugs.archlinux.org/task/24099 bug #24099].<br />
<br />
=== I use the ATI Catalyst driver and I encounter glitches and artifacts while using GNOME Shell ===<br />
<br />
For the moment, Catalyst is not proposed to be used while running GNOME Shell. The opensource ATI driver, xf86-video-ati, however, seems to be working properly with the GNOME 3 composited desktop.<br />
<br />
=== I have multiple monitors and the Dock extension appears stuck between them ===<br />
<br />
If you have multiple monitors configured using Nvidia Twinview, the dock extension may get sandwiched in-between the monitors. You can edit the source of this extension to reposition the dock to a position of your choosing.<br />
<br />
Edit '''/usr/share/gnome-shell/extensions/dock@gnome-shell-extensions.gnome.org/extension.js''' and locate this line in the source:<br />
<br />
this.actor.set_position(primary.width-this._item_size-this._spacing-2, (primary.height-height)/2);<br />
<br />
The first parameter is the X position of the dock display, by subtracting 15 pixels as opposed to 2 pixels from this it correctly positioned on my primary monitor, you can play around with any X,Y coordinate pair to position it correctly.<br />
<br />
this.actor.set_position(primary.width-this._item_size-this._spacing-15, (primary.height-height)/2);<br />
<br />
=== There are no event sounds for Empathy and other programs ===<br />
The '''sound-theme-freedesktop''' package must be installed for the default event sounds:<br />
# pacman -S sound-theme-freedesktop<br />
<br />
=== Editing hotkeys via can-change-accels fails ===<br />
It is also possible to manually change the keys via an application's so-called accel map file. Where it is to be found is up to the application: For instance, Thunar's is at {{Filename|~/.config/Thunar/accels.scm}}, whereas Nautilus's is located at {{Filename|~/.gnome2/accels/nautilus}}. The file should contain a list of possible hotkeys, each unchanged line commented out with a leading ";" that has to be removed for a change to become active.<br />
<br />
=== "Failed to load session 'gnome-fallback'" message ===<br />
Check if '''notification-daemon''' is installed.<br />
# pacman -S notification-daemon</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=SLiM&diff=140374SLiM2011-05-08T07:38:24Z<p>JaMeSiTeGeN: </p>
<hr />
<div>[[Category:Display managers (English)]]<br />
[[fr:SLiM]]<br />
{{i18n|SLiM}}<br />
{{Article summary start}}<br />
{{Article summary text|Provides an overview of the Simple Login Manager.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Display Manager}}<br />
{{Article summary end}}<br />
[http://slim.berlios.de/ SLiM] is an acronym for Simple Login Manager. SLiM is simple, lightweight and easily configurable. SLiM is used by some because it does not require the dependencies of [[GNOME]] or [[KDE]] and can help make a lighter system for users that like to use lightweight desktops like [[Xfce]], [[Openbox]], and [[Fluxbox]].<br />
<br />
== Installation ==<br />
<br />
Install SLiM from the '''extra''' repository:<br />
<br />
# pacman -S slim<br />
<br />
== Configuration ==<br />
<br />
=== Enabling SLiM ===<br />
<br />
SLiM can be loaded on startup by entering it in your daemons array in {{Filename|rc.conf}} or by modifying {{Filename|inittab}}. See [[Display Manager]] for detailed instructions.<br />
<br />
=== Single environments ===<br />
<br />
To configure SLiM to load a particular environment, edit your {{Filename|~/.xinitrc}} to load your desktop environment:<br />
<br />
<pre><br />
#!/bin/sh<br />
<br />
#<br />
# ~/.xinitrc<br />
#<br />
# Executed by startx (run your window manager from here)<br />
#<br />
<br />
exec [session-command]<br />
</pre><br />
<br />
SLiM reads the local {{Filename|~/.xinitrc}} configuration and then launches the desktop according to what is in that file. If you do not have a {{Filename|~/.xinitrc}} file, you can use the skeleton file by:<br />
<br />
$ cp /etc/skel/.xinitrc ~<br />
<br />
Replace {{Codeline|[session-command]}} with the appropriate session command. Some examples of different desktop start commands:<br />
<br />
<pre><br />
exec awesome<br />
exec dwm<br />
exec fluxbox<br />
exec fvwm2<br />
exec gnome-session<br />
exec openbox-session<br />
exec startkde<br />
exec startlxde<br />
exec startxfce4<br />
exec enlightenment_start<br />
exec ck-launch-session $ONE_OF_THE_ABOVE<br />
</pre><br />
<br />
If your environment is not listed here, refer to the appropriate wiki page.<br />
<br />
=== PolicyKit ===<br />
<br />
If you have problems with PolicyKit, use ConsoleKit's {{Codeline|ck-launch-session}} by changing the <code>login_cmd</code> line of your <code>/etc/slim.conf</code> to:<br />
<br />
<pre><br />
login_cmd exec ck-launch-session /bin/bash -login ~/.xinitrc %session<br />
</pre><br />
<br />
and leave your <code>~/.xinitrc</code> as plain as possible; for instance:<br />
<br />
<pre><br />
#!/bin/sh<br />
exec startxfce4 # or the window manager of your choice<br />
</pre><br />
<br />
=== Autologin ===<br />
<br />
To make SLiM automatically login as a specified user (without having to type a password) the following lines in /etc/slim.conf should be changed.<br />
<br />
<pre><br />
# default_user simone<br />
</pre><br />
<br />
Uncomment this line, and change "simone" to the user to be logged into automatically.<br />
<br />
<pre><br />
# auto_login no<br />
</pre><br />
<br />
Uncomment this line and change the 'no' to 'yes'. This enables the auto login feature.<br />
<br />
=== Multiple environments ===<br />
<br />
To be able to choose from multiple desktop environments, SLiM can be setup to log you into whichever you choose.<br />
<br />
Put a case statement similar to this one in your {{Filename|~/.xinitrc}} file and edit the sessions variable in {{Filename|/etc/slim.conf}} to match the names that trigger the case statement. You can choose the session at login time by pressing F1. Note that this feature is experimental.<br />
<br />
<pre><br />
# The following variable defines the session which is started if the user doesn't explicitly select a session<br />
# Source: http://svn.berlios.de/svnroot/repos/slim/trunk/xinitrc.sample<br />
<br />
DEFAULT_SESSION=twm<br />
<br />
case $1 in<br />
kde)<br />
exec startkde<br />
;;<br />
xfce4)<br />
exec startxfce4<br />
;;<br />
icewm)<br />
icewmbg &<br />
icewmtray &<br />
exec icewm<br />
;;<br />
wmaker)<br />
exec wmaker<br />
;;<br />
blackbox)<br />
exec blackbox<br />
;;<br />
*)<br />
exec $DEFAULT_SESSION<br />
;;<br />
esac<br />
</pre><br />
<br />
=== Themes ===<br />
<br />
Install the {{Package Official|slim-themes}} package:<br />
<br />
# pacman -S slim-themes archlinux-themes-slim<br />
<br />
The {{Package Official|archlinux-themes-slim}} packages contains several different themes. Look in the directory of {{Filename|/usr/share/slim/themes}} to see the themes available. Enter the theme name on the 'current_theme' line in {{Filename|/etc/slim.conf}}:<br />
<br />
#current_theme default<br />
current_theme archlinux-simplyblack<br />
<br />
To preview a theme run while an instance of the Xorg server is running by:<br />
<br />
$ slim -p /usr/share/slim/themes/<theme name><br />
<br />
To close, type "exit" in the Login line and press Enter.<br />
<br />
Additional theme packages can be found in the [[AUR]].<br />
<br />
==== Dual screen setup ====<br />
<br />
You can customize the slim theme in /usr/share/slim/themes/<your-theme>/slim.theme to turn these percents values. The box itself is 450 pixels by 250 pixels:<br />
<br />
input_panel_x 50%<br />
input_panel_y 50%<br />
<br />
into pixels values:<br />
<br />
# These settings set the "archlinux-simplyblack" panel in the center of a 1440x900 screen<br />
input_panel_x 495<br />
input_panel_y 325<br />
<br />
# These settings set the "archlinux-retro" panel in the center of a 1680x1050 screen<br />
input_panel_x 615<br />
input_panel_y 400<br />
<br />
If your theme has a background picture you should use the background_style setting ('stretch', 'tile', 'center' or 'color') to get it correctly displayed. Have a look at the [http://slim.berlios.de/themes_howto.php very simple and clear official documentation about slim themes] for further details.<br />
<br />
== Other options ==<br />
<br />
A few things you might like to try.<br />
<br />
=== Changing the cursor ===<br />
<br />
If you want to change the default X cursor to a newer design, the {{Package AUR|slim-cursor}} package is available.<br />
<br />
After installing, edit {{Filename|/etc/slim.conf}} and uncomment the line:<br />
<br />
cursor left_ptr<br />
<br />
This will give you a normal arrow instead. This setting is forwarded to {{Codeline|xsetroot -cursor_name}}. You can look up the possible cursor names [http://cvsweb.xfree86.org/cvsweb/*checkout*/xc/lib/X11/cursorfont.h?rev=HEAD&content-type=text/plain here] or in {{Filename|/usr/share/icons/<your-cursor-theme>/cursors/}}.<br />
<br />
To change the cursor theme being used at the login screen, make a file named {{Filename|/usr/share/icons/default/index.theme}} with this content:<br />
<br />
[Icon Theme]<br />
Inherits=<your-cursor-theme><br />
<br />
Replace <your-cursor-theme> with the name of the cursor theme you want to use (e.g. whiteglass).<br />
<br />
=== Match SLiM and Desktop Wallpaper ===<br />
<br />
To share a wallpaper between SLiM and your desktop, rename the used theme background, then create a link from your desktop wallpaper file to the default SLiM theme:<br />
<br />
# mv /usr/share/slim/themes/default/background.jpg{,.bck}<br />
# ln -s /path/to/mywallpaper.jpg /usr/share/slim/themes/default/background.jpg<br />
<br />
=== Shutdown, reboot, suspend, exit, launch terminal from SLiM ===<br />
<br />
You may shutdown, reboot, suspend, exit or even launch a terminal from the SLiM login screen. To do so, use the values in the username field, and the root password in the password field:<br />
<br />
* To launch a terminal, enter '''console''' as the username (defaults to xterm which must be installed separately... edit {{Filename|/etc/slim.conf}} to change terminal preference)<br />
* For shutdown, enter '''halt''' as the username<br />
* For reboot, enter '''reboot''' as the username<br />
* To exit to bash, enter '''exit''' as the username<br />
* For suspend, enter '''suspend''' as the username (suspend is disabled by default, edit {{Filename|/etc/slim.conf}} as root to uncomment the {{Filename|suspend_cmd}} line and, if necessary modify the suspend command itself (e.g. change {{Codeline|/usr/sbin/suspend}} to {{Codeline|sudo /usr/sbin/pm-suspend}}))<br />
<br />
=== SLiM init error with rc.d daemon ===<br />
<br />
If you initialize SLiM with {{Filename|/etc/rc.conf}} inside the DAEMONS array and it fails to initialize it's most likely a lock file issue. SLiM creates a lock file in {{Filename|/var/lock}} on each initialization, however, in most cases the lock folder in /var does not exist preventing SLiM from initializing. Check to make sure {{Filename|/var/lock}} exists, if it does not you can create it by typing the following:<br />
<br />
# mkdir /var/lock/<br />
<br />
=== Power-off error with Splashy ===<br />
<br />
If you use Splashy and SLiM, sometimes you can't power-off or reboot from menu in GNOME, Xfce, LXDE or others. Check your {{Filename|/etc/slim.conf}} and {{Filename|/etc/splash.conf}}; set the DEFAULT_TTY=7 same as xserver_arguments vt07.<br />
<br />
=== Login information with SLiM ===<br />
<br />
By default, SLiM fails to log logins to utmp and wtmp which causes who, last, etc. to misreport login information. To fix this edit your {{Filename|slim.conf}} as follows:<br />
<br />
sessionstart_cmd /usr/bin/sessreg -a -l $DISPLAY %user<br />
sessionstop_cmd /usr/bin/sessreg -d -l $DISPLAY %user<br />
<br />
=== SLiM and Gnome Keyring ===<br />
If you are using SLiM to launch a Gnome session and have trouble accessing your keyring, for example not being automatically authenticated on login, add the following lines to /etc/pam.d/slim (as discussed [http://bugs.archlinux.org/task/18637 here]).<br />
<pre><br />
auth optional pam_gnome_keyring.so<br />
session optional pam_gnome_keyring.so auto_start<br />
</pre><br />
<br />
However, this fix no longer works for Gnome 2.30. An alternate workaround is described [http://bugs.archlinux.org/task/18930 here]. Modifying the login_cmd line in /etc/slim.conf:<br />
<pre><br />
login_cmd exec ck-launch-session dbus-launch /bin/bash -login ~/.xinitrc %session >~/.xsession-errors 2>&1<br />
</pre><br />
<br />
=== Setting DPI with SLiM ===<br />
<br />
The Xorg server generally picks up the DPI but if it doesn't you can specify it to SLiM. If you set the DPI with the argument -dpi 96 in {{Filename|/etc/X11/xinit/xserverrc}} it will not work with SLiM. To fix this change your {{Filename|slim.conf}} from:<br />
<br />
xserver_arguments -nolisten tcp vt07 <br />
<br />
to<br />
<br />
xserver_arguments -nolisten tcp vt07 -dpi 96<br />
<br />
=== Use a random theme ===<br />
<br />
Use the current_theme variable as a comma separated list to specify a set to randomly choose from.<br />
<br />
=== Automatically mount your encrypted /home on login ===<br />
<br />
You can use [[Pam_mount#Slim|pam_mount]].<br />
<br />
== All Slim Options ==<br />
Here is a list of all the slim configuration options and their default values.<br />
<br />
{{Note|welcome_msg allows 2 variables '''%host''' and '''%domain'''<br>sessionstart_cmd allows '''%user''' ''(execd right before login_cmd)'' and it is also allowed in sessionstop_cmd<br>login_cmd allows '''%session''' and '''%theme'''}}<br />
<br />
<br />
{| class="wikitable collapsible collapsable collapsed"<br />
|-<br />
! Option Name || Default Value<br />
|-<br />
| default_path ||<tt>/bin:/usr/bin:/usr/local/bin</tt><br />
|-<br />
| default_xserver ||<tt>/usr/bin/X</tt><br />
|-<br />
| xserver_arguments ||<tt>vt07 -auth /var/run/slim.auth</tt><br />
|-<br />
| numlock ||<br />
|-<br />
| daemon || <tt>yes</tt><br />
|-<br />
| xauth_path ||<tt>/usr/bin/xauth</tt><br />
|-<br />
| login_cmd ||<tt>exec /bin/bash -login ~/.xinitrc %session</tt><br />
|-<br />
| halt_cmd ||<tt>/sbin/shutdown -h now</tt><br />
|-<br />
| reboot_cmd ||<tt>/sbin/shutdown -r now</tt><br />
|-<br />
| suspend_cmd ||<br />
|-<br />
| sessionstart_cmd ||<br />
|-<br />
| sessionstop_cmd ||<br />
|-<br />
| console_cmd ||<tt>/usr/bin/xterm -C -fg white -bg black +sb -g %dx%d+%d+%d -fn %dx%d -T </tt><br />
|-<br />
| screenshot_cmd ||<tt>import -window root /slim.png</tt><br />
|-<br />
| welcome_msg ||<tt>Welcome to %host</tt><br />
|-<br />
| session_msg ||<tt>Session:</tt><br />
|-<br />
| default_user ||<br />
|-<br />
| focus_password ||<tt>no</tt><br />
|-<br />
| auto_login ||<tt>no</tt><br />
|-<br />
| current_theme ||<tt>default</tt><br />
|-<br />
| lockfile ||<tt>/var/run/slim.lock</tt><br />
|-<br />
| logfile ||<tt>/var/log/slim.log</tt><br />
|-<br />
| authfile ||<tt>/var/run/slim.auth</tt><br />
|-<br />
| shutdown_msg ||<tt>The system is halting...</tt><br />
|-<br />
| reboot_msg ||<tt>The system is rebooting...</tt><br />
|-<br />
| sessions ||<tt>wmaker,blackbox,icewm</tt><br />
|-<br />
| sessiondir ||<br />
|-<br />
| hidecursor ||<tt>false</tt><br />
|-<br />
| input_panel_x ||<tt>50%</tt><br />
|-<br />
| input_panel_y ||<tt>40%</tt><br />
|-<br />
| input_name_x ||<tt>200</tt><br />
|-<br />
| input_name_y ||<tt>154</tt><br />
|-<br />
| input_pass_x ||<tt>-1</tt><br />
|-<br />
| input_pass_y ||<tt>-1</tt><br />
|-<br />
| input_font ||<tt>Verdana:size=11</tt><br />
|-<br />
| input_color ||<tt>#000000</tt><br />
|-<br />
| input_cursor_height ||<tt>20</tt><br />
|-<br />
| input_maxlength_name ||<tt>20</tt><br />
|-<br />
| input_maxlength_passwd ||<tt>20</tt><br />
|-<br />
| input_shadow_xoffset ||<tt>0</tt><br />
|-<br />
| input_shadow_yoffset ||<tt>0</tt><br />
|-<br />
| input_shadow_color ||<tt>#FFFFFF</tt><br />
|-<br />
| welcome_font ||<tt>Verdana:size=14</tt><br />
|-<br />
| welcome_color ||<tt>#FFFFFF</tt><br />
|-<br />
| welcome_x ||<tt>-1</tt><br />
|-<br />
| welcome_y ||<tt>-1</tt><br />
|-<br />
| welcome_shadow_xoffset ||<tt>0</tt><br />
|-<br />
| welcome_shadow_yoffset ||<tt>0</tt><br />
|-<br />
| welcome_shadow_color ||<tt>#FFFFFF</tt><br />
|-<br />
| intro_msg ||<br />
|-<br />
| intro_font ||<tt>Verdana:size=14</tt><br />
|-<br />
| intro_color ||<tt>#FFFFFF</tt><br />
|-<br />
| intro_x ||<tt>-1</tt><br />
|-<br />
| intro_y ||<tt>-1</tt><br />
|-<br />
| background_style ||<tt>stretch</tt><br />
|-<br />
| background_color ||<tt>#CCCCCC</tt><br />
|-<br />
| username_font ||<tt>Verdana:size=12</tt><br />
|-<br />
| username_color ||<tt>#FFFFFF</tt><br />
|-<br />
| username_x ||<tt>-1</tt><br />
|-<br />
| username_y ||<tt>-1</tt><br />
|-<br />
| username_msg ||<tt>Please enter your username</tt><br />
|-<br />
| username_shadow_xoffset ||<tt>0</tt><br />
|-<br />
| username_shadow_yoffset ||<tt>0</tt><br />
|-<br />
| username_shadow_color ||<tt>#FFFFFF</tt><br />
|-<br />
| password_x ||<tt>-1</tt><br />
|-<br />
| password_y ||<tt>-1</tt><br />
|-<br />
| password_msg ||<tt>Please enter your password</tt><br />
|-<br />
| msg_color ||<tt>#FFFFFF</tt><br />
|-<br />
| msg_font ||<tt>Verdana:size=16:bold</tt><br />
|-<br />
| msg_x ||<tt>40</tt><br />
|-<br />
| msg_y ||<tt>40</tt><br />
|-<br />
| msg_shadow_xoffset ||<tt>0</tt><br />
|-<br />
| msg_shadow_yoffset ||<tt>0</tt><br />
|-<br />
| msg_shadow_color ||<tt>#FFFFFF</tt><br />
|-<br />
| session_color ||<tt>#FFFFFF</tt><br />
|-<br />
| session_font ||<tt>Verdana:size=16:bold</tt><br />
|-<br />
| session_x ||<tt>50%</tt><br />
|-<br />
| session_y ||<tt>90%</tt><br />
|-<br />
| session_shadow_xoffset ||<tt>0</tt><br />
|-<br />
| session_shadow_yoffset ||<tt>0</tt><br />
|-<br />
| session_shadow_color ||<tt>#FFFFFF</tt><br />
|}<br />
<br />
== Resources ==<br />
<br />
* [http://slim.berlios.de/ SLiM homepage]<br />
* [http://slim.berlios.de/manual.php SLiM documentation]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=Daemons&diff=140373Daemons2011-05-08T07:36:16Z<p>JaMeSiTeGeN: /* Manual Starting and Stopping */</p>
<hr />
<div>[[Category:Boot process (English)]]<br />
[[Category:Daemons and system services (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|Daemon}}<br />
<br />
A '''daemon''' is a program that runs in the background, waiting for events to occur and offering services. A good example is a webserver that waits for a request to deliver a page or a ssh server waiting for someone trying to log in. While these are full featured applications, there are daemons whose work is not that visible. Daemons are for tasks like writing messages into a log file (e.g. syslog, metalog) or lowering your CPU frequency when the system is idle (e.g. cpufreq).<br />
<br />
==Starting on Boot==<br />
A default install of Arch Linux will leave you with very few services (or daemons) enabled during boot. You can add or remove services by editing the DAEMONS array in your [[rc.conf]] file. It will initially look something like this:<br />
DAEMONS=(syslog-ng network netfs crond)<br />
<br />
They will start in the order you have them listed. You can disable one and keep it in the array by prefixing it with an exclamation mark (!). You can also have them start in the background by adding an at (@) symbol in front of it.<br />
<br />
==Manual Starting and Stopping==<br />
You can see what service start up scripts you have by looking in your /etc/rc.d/ directory. You can also manually start, stop, and restart them by issuing<br />
/etc/rc.d/''daemonname'' {start|stop|restart}<br />
or<br />
rc {start|stop|restart} daemon-name<br />
Eg: rc start slim<br />
<br />
They may also have other commands, check with the documentation.<br />
<br />
==Essentials==<br />
You do not have to add any more services, if you do not feel the need. However, a typical desktop user will add at least [[CUPS]] and [[dbus]]. As you install new services, you will have to manually add them to the DAEMONS array in /etc/rc.conf. (The DAEMONS array is at the end of the default rc.conf file.)<br />
<br />
{{Note|Some services will start other services. For example, HAL will automatically start [[D-Bus]] and [[Acpid]]. But keep in mind, as it has been mentioned elsewhere, that HAL will sometimes fail to automatically start D-Bus, without the user's awareness. It is considered good practice, therefore, to add D-Bus explicitly before HAL and not to "background" it. This will let the user know during bootup if it fails to start, before other services dependent on D-Bus break. Don't forget that dbus will still be useful even after programs stop using hal.|}}<br />
<br />
==Starting Daemons in Background==<br />
This is helpful for starting a service and letting the next service start before the previous one has finished. Which services to start background depends on your needs. Do not background anything you need immediately. Here is an example:<br />
DAEMONS=(syslog-ng gensplash dbus hal network netfs @avahi-daemon @samba @crond @openntpd @cups @mpd)<br />
<br />
Starting ''openntpd'' in the background could lead to synchronization errors between the actual time and the time stored on your computer. If you recognize an increasing time difference between your desktop clock and the actual time, try to start the ''openntpd'' daemon normally and not in the background.<br />
<br />
==Rc.conf GUI Frontends==<br />
[[Rc.conf GUI Frontends]] allow you to easily change settings in /etc/rc.conf using graphical aplication.<br />
<br />
==List of Daemons==<br />
(Here is a list of daemons. Any package can use a daemon if it needs to, so this list will never be complete. Please feel free to add any missing daemons here, in alphabetical order.)<br />
{| border="1"<br />
|<b>Daemon</b>||<b>Description</b><br />
|-<br />
|[[Acpid|acpid]]||Delivers ACPI events.<br />
|-<br />
|[[Alsa|alsa]]||Advanced Linux Sound Architecture; provides device drivers for sound cards.<br />
|-<br />
|atd||run jobs queued for later execution.||<br />
|-<br />
|[[Avahi|avahi-daemon]]||Allows programs to automatically find local network services.<br />
|-<br />
|[[Avahi|avahi-dnsconfd]]||<br />
|-<br />
|crond||Daemon to schedule and time events.<br />
|-<br />
|[[CUPS|cups]]||Common UNIX Printing System daemon.<br />
|-<br />
|[[D-Bus|dbus]]||Message bus system for software communication.<br />
|-<br />
|[[FAM|fam]]||File Alteration Monitor.<br />
|-<br />
|[[Fbsplash|fbsplash]]||Graphical boot splash screen for the user.<br />
|-<br />
|[[Gensplash|gensplash]]||(see fbsplash)<br />
|-<br />
|[[HAL|hal]]||Hardware Abstraction Layer.<br />
|-<br />
|[[MDADM|mdadm]]||MD Administration (Linux Software RAID).<br />
|-<br />
|[[MPD|mpd]]||Music Player Daemon.<br />
|-<br />
|[[MySQL|mysqld]]||MySQL database server.<br />
|-<br />
|netfs||Mounts network file systems.<br />
|-<br />
|[[Configuring_Network|network]]||To bring up the network connections.<br />
|-<br />
|[[NetworkManager|networkmanager]]||Combine with HAL to replace network, and provide configuration and detection for automatic network connections.<br />
|-<br />
|nsyslogd||<br />
|-<br />
|[[NTPD|ntpd]]||Network Time Protocol daemon (client and server).<br />
|-<br />
|[[OpenNTP|openntpd]]||alternate Network Time Protocol daemon (client and server).<br />
|-<br />
|[[Pure-FTPD|pure-ftpd]]||FTP server.<br />
|-<br />
|[[Rsyslog|rsyslogd]]||The latest version of a system logger.<br />
|-<br />
|[[SLiM|slim]]||Simple Login Manager<br />
|-<br />
|[[Samba|samba]]||File and print services for Microsoft Windows clients.<br />
|-<br />
|[[USB_Scanner_Support|saned]]||To share the scanner system over network.<br />
|-<br />
|sensors||Hardware (temperature, fans etc) monitoring.<br />
|-<br />
|[[OpenSSH|sshd]]||OpenSSH (secure shell) daemon.<br />
|-<br />
|stbd ||This daemon was previously necessary for gnome-system-tools. However, as of gnome-tools 2.28, it is no longer needed.<br />
|-<br />
|syslogd||This was the older and basic system logger.<br />
|-<br />
|[[Syslog-ng|syslog-ng]]||System logger next generation.<br />
|-<br />
|[[Timidity|timidity++]]||Software synthesizer for MIDI.<br />
|-<br />
|[[Vsftpd|vsftpd]]||FTP server.<br />
|-<br />
|[[Wicd|wicd]]||Combine with dbus to replace network, a lightweigh alternative to networkmanager.<br />
|-<br />
|}<br />
<br />
==See also==<br />
<br />
Examples for [[writing rc.d scripts]]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=VirtualBox&diff=140372VirtualBox2011-05-08T07:34:07Z<p>JaMeSiTeGeN: </p>
<hr />
<div>[[Category:Emulators (English)]]<br />
[[Category:HOWTOs (English)]]<br />
[[fr:VirtualBox]]<br />
{{i18n|VirtualBox}}<br />
<br />
This article is about VirtualBox running in Arch, you may also be interested in [[Arch Linux VirtualBox Guest|Arch Linux as a VirtualBox Guest]].<br />
<br />
[http://www.virtualbox.org VirtualBox] is a virtual pc emulator like [[vmware]]. It has many of the features vmware has, as well as some of its own. It is in constant development and new features are implemented all the time. e.g. version 2.2 introduced OpenGL 3D acceleration support for Linux and Solaris guests. It has a nice GUI interface (Qt and/or SDL) or command line tools for managing virtual machines. Headless operation is also supported. Running iTunes under VirtualBox is the only way (currently) to sync iPod Touch/iPhone firmware 3.0+.<br />
<br />
==Installing==<br />
;{{package Official|virtualbox}}<br />
:This is the basic GPL licensed VirtualBox suite, which can be found in the community repository.<br />
<br />
;{{package AUR|virtualbox-ext-oracle}}<br />
:This PUEL licensed extension pack is free for personal use. You can download it from the [[AUR]]. It features an RPD server, USB 2.0 support and PXE boot for Intel cards.<br />
<br />
Install the basic package:<br />
# pacman -S virtualbox<br />
Optionally install {{package Official|qt}} in order to use the GUI:<br />
# pacman -S qt<br />
<br />
==Running VirtualBox==<br />
Now, add the desired username to the ''vboxusers'' group:<br />
# gpasswd -a USERNAME vboxusers<br />
<br />
Build the required modules:<br />
# /etc/rc.d/vboxdrv setup<br />
or ( untested )<br />
# rc setup vboxdrv<br />
<br />
Lastly, edit {{Filename|/etc/[[rc.conf]]}} and add ''vboxdrv'' to the MODULES array in order to load the VirtualBox drivers at startup:<br />
MODULES=(... ''vboxdrv'')<br />
<br />
To load the module manually:<br />
# modprobe vboxdrv<br />
<br />
To start Virtualbox:<br />
$ VirtualBox<br />
<br />
===Solving the impossible /etc/rc.d/vboxdrv setup===<br />
<br />
In some case when VirtualBox is freshly installed you can't compile the module and some error message appears, like :<br />
<br />
<pre><br />
# /etc/rc.d/vboxdrv setup <br />
### or rc sedup vboxdrv ( untested )<br />
:: Unloading VirtualBox kernel modules [DONE]<br />
:: Recompiling VirtualBox kernel modules [BUSY]<br />
Look at /var/log/vbox-install.log to find out what went wrong<br />
Look at /var/log/vbox-install.log to find out what went wrong<br />
Look at /var/log/vbox-install.log to find out what went wrong<br />
[DONE]<br />
:: Reloading VirtualBox kernel modules}</pre><br />
<br />
with the evocated log file saying :<br />
<pre>Makefile:169: *** Error: unable to find the sources of your current Linux kernel. Specify KERN_DIR=<directory> and run Make again. Stop.<br />
cp: cannot stat `/tmp/vboxdrv-Module.symvers': No such file or directory<br />
Makefile:94: *** Error: unable to find the sources of your current Linux kernel. Specify KERN_DIR=<directory> and run Make again. Stop.<br />
cp: cannot stat `/tmp/vboxdrv-Module.symvers': No such file or directory<br />
Makefile:90: *** Error: unable to find the sources of your current Linux kernel. Specify KERN_DIR=<directory> and run Make again. Stop.</pre><br />
<br />
A solution is to install headers of your kernel :<br />
<br />
pacman -S kernel26-headers<br />
or, if you have got a lts version :<br />
pacman -S kernel26-lts-headers<br />
<br />
Then it could be useful to reboot your computer (but maybe not necessary, try) and following previous steps, your virtual machine should run.<br />
<br />
==Configuring==<br />
===Networking===<br />
VirtualBox guests may be networked through various methods; among them, there's [[#NAT]] and [[#Bridged]] networking. Using the [[#NAT]] method is the simplest and the default for new virtual machines.<br />
<br />
The [http://www.virtualbox.org/manual/UserManual.html VirtualBox manual] covers host-only and internal network options. These have been omitted due to them being, for the most part, OS agnostic.<br />
<br />
====NAT====<br />
From VirtualBox:<br />
* access the VM's ''Settings'' menu;<br />
* click on ''Network'' from the list to the left; finally,<br />
* in the ''Attached to'' drop-down list, select ''NAT''.<br />
<br />
VirtualBox's bundled DHCP server enables the guest system to be configured with DHCP. The NAT IP address on the first card is 10.0.2.0, 10.0.3.0 on the second and so on.<br />
<br />
====Bridged====<br />
Bridged networking may be setup through various methods; among them, there's the native way, which requires minimal setup at the expense of having less control. For other methods, see [[Advanced VirtualBox Networking]]. Since newer versions, VirtualBox can bridge between a guest and a wireless host interface without the help of third party utilities.<br />
<br />
Before continuing, load the required module:<br />
# modprobe vboxnetflt<br />
<br />
From VirtualBox:<br />
* access the VM's ''Settings'' menu;<br />
* click on ''Network'' from the list to the left;<br />
* in the ''Attached to'' drop-down list, select ''Bridged Adapter''; finally,<br />
* in the ''Name'' drop-down list, select the name of the host interface that's connected to the network that the guest OS should be part of.<br />
<br />
Start the virtual machine and configure its network as usual; e.g., DHCP or static.<br />
<br />
===Guest additions===<br />
The Guest Additions make the shared folders feature available, improve video card acceleration support, and enable bi-directional clipboard between the guest and host. Mouse integration is another feature, taking away the need of releasing the mouse after using it in the guest.<br />
<br />
====Arch Linux guests====<br />
<br />
Refer to [[Arch Linux VirtualBox Guest]]<br />
<br />
====Windows guests====<br />
After installing Windows (XP etc.) on your virtual machine, simply select ''Devices &rarr; Install Guest Additions...''<br />
<br />
This will mount the iso image and windows should then automatically launch the guest additions installer. Follow the instructions to the end.<br />
<br />
===Keyboard and mouse between the host and the guest===<br />
*To capture the keyboard and mouse, click the mouse inside the virtual machine display.<br />
*To uncapture, press right {{keypress|Ctrl}}.<br />
<br />
To get seamless mouse integration between host and guest, install the [[#Guest Additions]] inside the guest.<br />
<br />
When generating the guests' {{Filename|xorg.conf}} with {{Codeline|X -configure}}, the InputDevice section may feature the {{Codeline|mouse}} driver. After installing the Guest Additions, replace {{Codeline|mouse}} with {{Codeline|vboxmouse}} and then restart X or reboot the guest.<br />
<br />
Alternatively, add the following to the guest's {{Filename|xorg.conf}}:<br />
<pre><br />
Section "InputDevice"<br />
Identifier "Mouse0"<br />
Driver "vboxmouse"<br />
Option "Protocol" "auto"<br />
Option "Device" "/dev/input/mice"<br />
Option "ZAxisMapping" "4 5 6 7"<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "X.org Configured"<br />
Screen 0 "Screen0" 0 0<br />
InputDevice "Mouse0" "CorePointer"<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
EndSection<br />
</pre><br />
<br />
===Using full resolution of the host system in the guest===<br />
Set the resolution of your guest in the grub boot script {{Filename|/boot/grub/menu.lst}}, i.e. add the correct vga code to the kernel command line. For a resolution of 1280x1024, this would e.g. look like<br />
# kernel /vmlinuz26 root=/dev/disk/by-uuid/7bdc5dee-8fb0-4260-bc43-60ac6e4e4a54 ro vga=795<br />
<br />
Add the resolution to {{Filename|/etc/X11/xorg.conf}}, e.g.<br />
<pre><br />
Section "Screen"<br />
...<br />
SubSection "Display"<br />
Viewport 0 0<br />
Depth 24<br />
Modes "1280x1024" "1024x768"<br />
EndSubSection<br />
...<br />
EndSection<br />
</pre><br />
If you experience problems with your resolution dropping back to second lower resolution in the 'Modes' setting, simply omit the second resolution. Example <br />
Modes "1280x1024"<br />
<br />
===Sharing folders between the host and the guest===<br />
In the settings of the virtual machine go to shared folders tab and add the folders you want to share.<br />
<br />
*NOTE: You need to install Guest Additions in order to use this feature.<br />
In a Linux host, ''Devices &rarr; Install Guest Additions''<br />
Yes (when asked to download the CD image)<br />
Mount (when asked to register and mount)<br />
<br />
In a Linux host, create one or more folders for sharing files, then set the shared folders via the virtualbox menu (guest window).<br />
<br />
In a Windows guest, starting with VirtualBox 1.5.0, shared folders are browseable and are therefore visible in Windows Explorer. Open Windows Explorer and look for it under ''My Networking Places &rarr; Entire Network &rarr; VirtualBox Shared Folders''.<br />
<br />
Launch the windows explorer (run explorer command) to browse the network places -> expand with the (+) sign : entire network &rarr; VirtualBox shared folders &rarr; '''\\Vboxsvr''' &rarr; then you can now expand all your configured shared folders here, and set up shortcuts for linux folders in the guest filesystem. You can alternatively use the "Add network place wizard", and browse to "VBoxsvr".<br />
<br />
Alternatively, on the Windows command line, you can also use the following:<br />
net use x: \\VBOXSVR\sharename<br />
<br />
While {{Codeline|VBOXSVR}} is a fixed name, replace {{Codeline|x:}} with the drive letter that you want to use for the share, and sharename with the share name specified with VBoxManage.<br />
<br />
In a Windows guest, to improve loading and saving files (e.g. MS Office) by VirtualBox Shared Folders edit ''c:\windows\system32\drivers\etc\hosts'' as below:<br />
127.0.0.1 localhost vboxsvr<br />
<br />
In a Linux guest, use the following command:<br />
# mount -t vboxsf [-o OPTIONS] sharename mountpoint<br />
(Notes: sharename is optional or same as selected in the VirtualBox-Dialog , mountpoint of the shared directory in the hosts filesystem)<br />
:Automatically mounting a shared folder is possible through the linux-guest /etc/fstab file. You may also specify the uid=#,gid=# (where # is replaced by the actual numerical uid and gid) to mount the share with normal user permissions instead of root permissions. (this can be helpful to mount parts of your host ~/home for use in your linux-guest. To do this add an entry in the following format to the linux-guest /etc/fstab:<br />
<br />
sharename mountpoint vboxsf uid=#,gid=# 0 0<br />
<br />
Replace {{Codeline|sharename}} with the share name specified with VBoxManage, and mountpoint with the path where you want the share to be mounted (e.g. /mnt/share). The usual mount rules apply, that is, create this directory first if it does not exist yet. Note that if you have told VirtualBox to "automatically mount" the shared folder, this step may not be necessary and your folder will be found somewhere under /media.<br />
<br />
Beyond the standard options supplied by the mount command, the following are available:<br />
iocharset=CHARSET<br />
to set the character set used for I/O operations (utf8 by default) and<br />
convertcp=CHARSET<br />
to specify the character set used for the shared folder name (utf8 by default).<br />
<br />
===Getting audio to work in the guest machine===<br />
In the machine settings, go to the audio tab and select the correct driver according to your sound system (ALSA, OSS or PulseAudio).<br />
<br />
===Setting up the RAM and video memory for the guest===<br />
You can change the default values by going to ''Settings &rarr; General''.<br />
<br />
===Setting up CD-ROM for the guest===<br />
You can change the default values by going to ''Settings &rarr; CD/DVD-ROM''.<br />
<br />
Check mount CD/DVD drive and select one of the following options.<br />
<br />
===Enabling D3D acceleration in Windows guests===<br />
Recent versions of Virtualbox have support for accelerating OpenGL inside guests. This can be enabled with a simple checkbox in the machine's settings, right below where video ram is set, and installing the Virtualbox guest additions. However, most Windows games use Direct3D (part of DirectX), not OpenGL, and are thus not helped by this method. However, it is possible to gain accelerated Direct3D in your Windows guests by borrowing the d3d libraries from Wine, which translate d3d calls into OpenGL, which is then accelerated. <br />
<br />
After enabling OpenGL acceleration as described above, go to http://www.nongnu.org/wined3d/ in your Windows guest and grab the "Latest version (Installer):". Reboot the guest into safe mode (press F8 before the Windows screen appears but after the Virtualbox screen disappears), and install wined3d, accepting the defaults during the install. (You may check the box for DirectX 10 support if you like, dont touch anything else.) Reboot back to normal mode and you should have accelerated Direct3D. <br />
<br />
{{Note | This hack may or may not work for some games depending on what hardware checks they make and what parts of D3D they use.}}<br />
{{Note | This has only been tried on Windows XP and Windows 7 RC guests AFAIK, and does not work on the Windows 7 guest. If you have experience with this on a different windows version, please add that data here.}}<br />
<br />
==Virtualized OS setup==<br />
Virtualbox needs to be setup to virtualize another operating system.<br />
<br />
===Test a liveCD/DVD===<br />
Click the 'New' button to create a new virtual environment. Name it appropriately and select Operating System type and version. Select base memory size (note: most operating systems will need at least 512MB to function properly). Create a new hard disk image (a hard disk image is a file that will contain the operating system's filesystem and files).<br />
<br />
When the new image has been created, click 'Settings', then CD/DVD-ROM, check 'Mount CD/DVD Drive' then select an ISO image.<br />
<br />
==Maintenance==<br />
<br />
===Rebuild the vboxdrv module===<br />
Note that any time your kernel version changes (due to an upgrade, recompile, etc.) you must also rebuild the VirtualBox kernel modules.<br />
<br />
Ensure that ''kernel26-headers'' is still installed, and run the following command:<br />
# /etc/rc.d/vboxdrv setup<br />
or ( untested )<br />
# rc setup vboxdrv<br />
This will build the VirtualBox kernel modules for the ''currently running kernel''; if you have just upgraded your kernel package, reboot before trying to rebuild your kernel modules.<br />
<br />
After rebuilding the module, do not forget to load it with<br />
# modprobe vboxdrv<br />
<br />
''vboxdrv'' and ''vboxnetflt'' should be in the MODULES=() section of your /etc/rc.conf<br />
<br />
If you are using an old virtualbox_bin package built from AUR, run:<br />
# vbox_build_module<br />
<br />
If you need to rebuild the Virtual Box Additions in a guest installation of Arch Linux, use this command:<br />
# /etc/rc.d/rc.vboxadd setup<br />
or ( untested )<br />
# rc setup rc.vboxadd<br />
<br />
===Compact a disk image===<br />
See [http://my.opera.com/locksley90/blog/2008/06/01/how-to-compact-a-virtualbox-virtual-disk-image-vdi How to compact a VirtualBox virtual disk image (VDI)]<br />
<br />
===Increase the size of a virtual hard drive for a Windows guest===<br />
WARNING: ONLY TESTED WITH XP GUEST!<br />
<br />
If you find that you are running out of space due to the small hard drive size you selected when created your VM, you can take the following steps:<br />
<br />
Create a new vdi in ~/.VirtualBox/HardDisks by running:<br />
# cd ~/.VirtualBox/HardDisks<br />
# VBoxManage createhd -filename new.vdi --size 10000 --remember<br />
<br />
where size is in mb, in this example 10000MB ~= 10GB, and new.vdi is name of new hard drive to be created.<br />
<br />
Next the old vdi needs to be cloned to the new vdi, this may take some time so wait while it occurs:<br />
# VBoxManage clonehd old.vdi new.vdi --existing<br />
<br />
Detach old harddrive and attach new hard drive, replace VMName with whatever you called your VM:<br />
# VBoxManage modifyvm VMName --hda none<br />
# VBoxManage modifyvm VMName --hda new.vdi<br />
<br />
Boot the VM, run Partition Wizard 5 to resize the partition on the fly, and reboot.<br />
<br />
Remove old vdi from VirtualBox and delete<br />
# VBoxManage closemedium disk old.vdi<br />
# rm old.vdi<br />
<br />
===Windows Xp and Nokia phones===<br />
To get working Windows XP and Nokia phones with Pc Suite mode, Virtualbox needs two simple steps:<br />
<br />
'''1.''' Add a rule to udev with {{Filename|/etc/udev/rules.d/40-permissions.rules}}:<br />
LABEL="usb_serial_start"<br />
ATTRS{idVendor}=="0403", ATTRS{idProduct}=="6001", \<br />
GROUP="usbfs", MODE="0660", GROUP="dialout"<br />
LABEL="usb_serial_end"<br />
<br />
'''2.''' Create the group usbfs and add its user to it<br />
$ sudo groupadd usbfs<br />
$ sudo usermod -a -G usbfs $USER<br />
<br />
After a logout, connect a Nokia phone with PC Suite mode and start Windows XP to test new rule.<br />
<br />
==Migrating from another VM==<br />
The <code>qemu-img</code> program can be used to convert images from one format to another, or add compression or encryption to an image. <br />
# pacman -S qemu<br />
<br />
===Converting from QEMU images===<br />
To convert a QEMU image for use with VirtualBox, first convert it to ''raw'' format, then use VirtualBox's conversion utility to convert and compact it in its native format.<br />
$ qemu-img convert -O raw test.qcow2 test.raw<br />
$ VBoxManage modifyvdi /full/path/to/test.vdi compact<br />
or <br />
$ qemu-img convert -O raw test.qcow2 test.raw<br />
(of course you must have installed qemu package for that)<br />
$ VBoxManage convertfromraw /full/path/to/test.raw /full/path/to/test.vdi<br />
$ VBoxManage modifyvdi /full/path/to/test.vdi compact<br />
<br />
===Converting from VMware images ===<br />
Do <br />
$ VBoxManage clonehd source.vmdk target.vdi --format VDI<br />
<br />
This may not be needed anymore with recent virtualbox versions (to be confirmed)<br />
<br />
==Tips and tricks==<br />
<br />
===Getting Web-cams and other USB devices to detect===<br />
Make sure you filter any devices that are not a keyboard or a mouse so they don't start up at boot and this insures that Windows will detect the device at start-up.<br />
<br />
===Sending a CTRL+ALT+F1 to the Guest===<br />
If your guest O/S is a Linux distro, and you want to open a new tty text shell or exit X via typing {{Keypress|Ctrl}}+{{Keypress|Alt}}+{{Keypress|F1}}, you can easily send this command to the guest O/S simply by hitting your 'Host Key' (usually the {{Keypress|Ctrl}} in the Right side of your keyboard) + {{Keypress|F1}} or {{Keypress|F2}}, etc.<br />
<br />
===Starting VMs at system boot on headless servers===<br />
Add this line to /etc/rc.local<br />
exec /bin/su -c 'VBoxManage startvm --type headless <''UUID|NAME''>' ''PREFERED_USER'' >/dev/null 2>&1<br />
Where <UUID|NAME> is the guest identifier, and PREFERRED_USER is the user profile that contains the VM definitions and .vdi files.<br />
<br />
Since exec replaces the currently running process, you will not be able to start a second VM, or execute any other commands, after the exec. Try the following if this is a problem:<br />
su -c 'VBoxHeadless -s <''UUID|NAME''> &' -s /bin/sh ''PREFERED_USER'' >/dev/null 2>&1<br />
Using fully qualified path to su and VBoxHeadless is recommend. Add additional lines like above to start additional VMs. Commands following these in rc.local will be executed. Based on some rooting around in the VBox documentation, I get the impression this will be a little more robust than 'VBoxManage ... --type headless' in future VBox releases.<br />
<br />
To determine the available VMs for a user:<br />
su -c 'VBoxManage list vms' PREFERED_USER<br />
<br />
To save the state of a running VM:<br />
su -c 'VBoxManage controlvm <UUID|NAME> savestate' PREFERED_USER<br />
rc.local.shutdown would be a good spot for this.<br />
<br />
=== Guest managament daemon ===<br />
Below is a [[daemon]] for automating guest administration. Guests will be initialized on start, and state-saved on stop, or you will just get a "./vbox_service: line 31: out[${m[1]}]: bad array subscript" message when you run it.<br />
<br />
The configuration file:<br />
{{File|name=/etc/conf.d/vbox_service|content=<nowiki><br />
# Guests to manage:<br />
#VB_GUESTS=('OpenBSD' 'Slackware' 'Windows XP')<br />
#<br />
# Disable a guest by prepending a bang:<br />
#VB_GUESTS=('OpenBSD' 'Slackware' !'Windows XP')<br />
#<br />
# Default value matches none:<br />
VB_GUESTS=()<br />
<br />
# User to run Virtual Box as:<br />
VB_USER='vbox'<br />
</nowiki>}}<br />
<br />
The script:<br />
{{File|name=/etc/rc.d/vbox_service|content=<nowiki><br />
#!/bin/bash<br />
<br />
. /etc/rc.conf<br />
. /etc/rc.d/functions<br />
<br />
unset VB_GUESTS<br />
unset VB_USER<br />
[[ -r /etc/conf.d/vbox_service ]] && . /etc/conf.d/vbox_service<br />
[[ ${VB_GUESTS[@]} ]] || VB_GUESTS=()<br />
[[ ${VB_USER[@]} ]] || VB_USER='vbox'<br />
<br />
<br />
match() {<br />
[[ $REPLY =~ $1 ]] && m=("${BASH_REMATCH[@]}")<br />
}<br />
<br />
<br />
vm_raw() {<br />
local argv=''<br />
printf -v argv ' %q ' "$@"<br />
su -c "/usr/bin/VBoxManage $argv" -s /bin/sh "$VB_USER"<br />
}<br />
<br />
vm_ls() {<br />
local -A out=''<br />
local -i ret=1<br />
<br />
local m=()<br />
while read -r; do<br />
match '^"(.+)" \{(.+)\}$'<br />
out[${m[1]}]=${m[2]}<br />
done < <(vm_raw list vms)<br />
<br />
local i=''<br />
for i in "${VB_GUESTS[@]##!*}"; do<br />
if [[ ${out[$i]} ]]; then<br />
printf ' %q ' "${out[$i]}"<br />
ret=0<br />
fi<br />
done<br />
<br />
return $ret<br />
}<br />
<br />
vm_envinit() {<br />
local m=()<br />
while read -r; do<br />
match '^(.+)="?([^"]+)'<br />
env[$1:${m[1]}]=${m[2]}<br />
done < <(vm_raw showvminfo --machinereadable "$1")<br />
}<br />
<br />
<br />
start() {<br />
if [[ ${env[$1:VMState]} != 'running' ]]; then<br />
vm_raw startvm --type headless "$1"<br />
fi<br />
}<br />
<br />
stop() {<br />
if [[ ${env[$1:VMState]} == 'running' ]]; then<br />
vm_raw controlvm "$1" savestate<br />
fi<br />
}<br />
<br />
restart() {<br />
stop "$1"<br />
sleep 3<br />
start "$1"<br />
}<br />
<br />
usage() {<br />
printf '%s\n' "usage: $0 <start|stop|restart> [name|uuid]..." >&2<br />
}<br />
<br />
<br />
if [[ ! $1 =~ ^(start|stop|restart)$ ]]; then<br />
usage<br />
exit 2<br />
fi<br />
cmd=$1<br />
shift<br />
(($#)) || eval set -- "$(vm_ls)"<br />
<br />
stat_busy "${cmd^}ing VMs:"<br />
trap 'stat_die' ERR<br />
set -Ee<br />
<br />
declare -A env=''<br />
<br />
for i; do<br />
[[ $i ]]<br />
vm_envinit "$i"<br />
stat_append "${env[$i:name]}, "<br />
$cmd "${env[$i:UUID]}" &>/dev/null<br />
done<br />
<br />
stat_done<br />
</nowiki>}}<br />
<br />
===Accessing server on VM from host===<br />
To access apache on a VM from the Host machine ONLY, simply execute the following lines on the Host:<br />
$ VBoxManage setextradata GuestName "VBoxInternal/Devices/pcnet/0/LUN#0/Config/Apache/HostPort" 8888<br />
$ VBoxManage setextradata GuestName "VBoxInternal/Devices/pcnet/0/LUN#0/Config/Apache/GuestPort" 80<br />
$ VBoxManage setextradata GuestName "VBoxInternal/Devices/pcnet/0/LUN#0/Config/Apache/Protocol" TCP<br />
Where 8888 is the port the host should listen on and 80 is the port the VM will send Apache's signal on. <br />
To use a port lower than 1024 on the host machine changes need to be made to the firewall on the host machine. This can also be set up to work with SSH, etc.. by changing "Apache" to whatever service and using different ports. <br />
<br />
Note: "pcnet" refers to the network card of the VM. If you use an Intel card in your VM settings change "pcnet" to "e1000"<br />
<br />
*from [http://mydebian.blogdns.org/?p=111 ]<br />
<br />
It might also be necessary to allow connections from the outside to the server in your VM. E.g. if the guest OS is Arch, you may want to add the line <br />
httpd: ALL<br />
to your /etc/hosts.allow file.<br />
<br />
===DAEMON Tools===<br />
While VirtualBox can mount ISO images without a problem, there are some image formats which cannot reliably be converted to ISO. For instance, ccd2iso ignores .ccd and .sub files, which can give disk images with broken files. cdemu, fuseiso, and MagicISO will do the same. In this case there is no choice but to use Daemon Tools inside VirtualBox.<br />
<br />
Recent Daemon Tools versions won't install, so use this old one: [http://www.disc-tools.com/download/daemon347+hashcalc]<br />
<br />
===Using VirtualBox on a USB key===<br />
When using VirtualBox on a USB key, for example to start an installed machine with an ISO image, you will manually have to create VDMKs from the existing drives. However, once the new VMDKs are saved and you move on to another machine, you may experience problems launching an appropriate machine again. To get rid of this issue, you can use the following script to launch VirtualBox. This script will clean up and unregister old VMDK files and it will create new, proper VMDKs for you:<br />
<pre><br />
#!/bin/bash<br />
<br />
# Erase old VMDK entries<br />
rm ~/.VirtualBox/*.vmdk<br />
<br />
# Clean up VBox-Registry<br />
sed -i '/sd/d' ~/.VirtualBox/VirtualBox.xml<br />
<br />
# Remove old harddisks from existing machines<br />
find ~/.VirtualBox/Machines -name \*.xml | while read file; do<br />
line=`grep -e "type\=\"HardDisk\"" -n $file | cut -d ':' -f 1`<br />
if [ -n "$line" ]; then<br />
sed -i ${line}d $file<br />
sed -i ${line}d $file<br />
sed -i ${line}d $file<br />
fi<br />
sed -i "/rg/d" $file<br />
done<br />
<br />
# Delete prev-files created by VirtualBox<br />
find ~/.VirtualBox/Machines -name \*-prev -exec rm '{}' \;<br />
<br />
# Recreate VMDKs<br />
ls -l /dev/disk/by-uuid | cut -d ' ' -f 9,11 | while read ln; do<br />
if [ -n "$ln" ]; then<br />
uuid=`echo "$ln" | cut -d ' ' -f 1`<br />
device=`echo "$ln" | cut -d ' ' -f 2 | cut -d '/' -f 3 | cut -b 1-3`<br />
<br />
# determine whether drive is mounted already<br />
checkstr1=`mount | grep $uuid`<br />
checkstr2=`mount | grep $device`<br />
checkstr3=`ls ~/.VirtualBox/*.vmdk | grep $device`<br />
if [[ -z "$checkstr1" && -z "$checkstr2" && -z "$checkstr3" ]]; then<br />
VBoxManage internalcommands createrawvmdk -filename ~/.VirtualBox/$device.vmdk -rawdisk /dev/$device -register<br />
fi<br />
fi<br />
done<br />
<br />
# Start VirtualBox<br />
VirtualBox<br />
</pre><br />
Note that your user has to be added to the "disk" group to create VMDKs out of existing drives.<br />
<br />
===phpVirtualBox===<br />
An open source, AJAX implementation of the VirtualBox user interface written in PHP. As a modern web interface, it allows you to access and control remote VirtualBox instances. Much of its verbage and some of its code is based on the (inactive) vboxweb project. It allows the administrator to remotely, graphically, administer their virtual machines without having to log in to their headless VirtualBox servers.<br />
<br />
This requires the PUEL edition for VirtualBox.<br />
<br />
An installation guide is available here:<br />
http://code.google.com/p/phpvirtualbox/wiki/Installation<br />
<br />
Arch Linux users should uncomment these 2 extensions in ''/etc/php/php.ini''<br />
extension=json.so<br />
extension=soap.so<br />
<br />
See also [[PhpVirtualBox]]<br />
<br />
==External links==<br />
* [http://www.virtualbox.org/manual/UserManual.html VirtualBox User Manual]</div>JaMeSiTeGeNhttps://wiki.archlinux.org/index.php?title=NFSv3&diff=140370NFSv32011-05-08T07:30:19Z<p>JaMeSiTeGeN: </p>
<hr />
<div>[[Category:Networking (English)]]<br />
[[Category:HOWTOs (English)]]<br />
{{i18n|NFS}}<br />
<br />
The goal of this article is to assist in setting up an nfs-server for sharing files over a network.<br />
<br />
*For NFSv4, see: [[NFSv4]]<br />
*nfs-utils has been upgraded since 2009-06-23, and NFS4 support is now implemented. Refer to the [http://www.archlinux.org/news/452/ news bulletin].<br />
*portmap has been replaced by rpcbind.<br />
<br />
==Required packages==<br />
Required packages for both the server and the client are minimal. You will only need to install:<br />
# pacman -S nfs-utils rpcbind #instead of rpcbind, you can also install portmap which was replaced<br />
<br />
==Setting up the server==<br />
You can now edit your configuration and then start the daemons.<br />
<br />
===Files===<br />
<br />
====/etc/exports====<br />
This file defines the various shares on the nfs server and their permissions. A few examples:<br />
/files *(ro,sync) # Read-only access to anyone<br />
/files 192.168.0.100(rw,sync) # Read-write access to a client on 192.168.0.100<br />
/files 192.168.1.1/24(rw,sync) # Read-write access to all clients from 192.168.1.1 to 192.168.1.255<br />
<br />
If you make changes to /etc/exports after starting the daemons, you can make them effective by issuing the following command:<br />
# exportfs -r<br />
<br />
If you decide to make your NFS share public and writable, you can use the all_squash option in combination with anonuid and the anongid option.<br />
For example, to set the privileges for the user nobody in the group nobody, you can do the following:<br />
; Read-write access to a client on 192.168.0.100, with rw access for the user 99 with gid 99<br />
/files 192.168.0.100(rw,sync,all_squash,anonuid=99,anongid=99))<br />
<br />
This also means, that if you want write access to this directory, nobody.nobody must be the owner of the share directory:<br />
# chown -R nobody.nobody /files<br />
<br />
Full details on the exports file are provided by the exports man page.<br />
<br />
====/etc/conf.d/nfs-common.conf====<br />
{{Note|This used to be in /etc/conf.d/nfs which is replaced by "/etc/conf.d/nfs-common.conf" and "/etc/conf.d/nfs-server.conf".}}<br />
<br />
Edit this file to pass appropriate run-time options to nfsd, mountd, statd, and sm-notify. The default Arch NFS init scripts require the --no-notify option for statd, as follows:<br />
STATD_OPTS="--no-notify"<br />
Others may be left at the provided defaults, or changed according to your requirements. Please refer to the relevant man pages for full details.<br />
<br />
====/etc/hosts.allow====<br />
To allow network access to the nfs server you should edit /etc/hosts.allow. The following example opens these services to anyone:<br />
nfsd: ALL<br />
rpcbind: ALL<br />
mountd:ALL<br />
<br />
This is a very insecure way of allowing host access. To get better control over who is allowed to access the daemons, hosts.deny should be everyone, and hosts.allow should specifically allow certain people. In this example, 192.168.0.101 should be the IP address of the person(s) allowed to access it. The numbers after the '/' is the netmask:<br />
nfsd: 192.168.0.101/255.255.255.255<br />
rpcbind: 192.168.0.101/255.255.255.255<br />
mountd: 192.168.0.101/255.255.255.255<br />
<br />
This examples enables access for anyone on that network:<br />
nfsd: 192.168.0.0/255.255.255.0<br />
rpcbind: 192.168.0.0/255.255.255.0<br />
mountd: 192.168.0.0/255.255.255.0<br />
<br />
For finer control, read the hosts_access(5) man page.<br />
<br />
===Daemons===<br />
You can now start the server with the following commands:<br />
# rc start rpcbind (or: rc start portmap)<br />
# rc start nfs-common (or: rc start nfslock)<br />
# rc start nfs-server (or: rc start nfsd)<br />
<br />
Please note that they must be started in that order. To start the server at boot time, add these daemons to the DAEMONS array in /etc/rc.conf.<br />
<br />
==Setting up the client==<br />
<br />
===Files===<br />
<br />
====/etc/conf.d/nfs-common.conf====<br />
Edit this file to pass appropriate run-time options to statd - the remaining options are for server use only. Do ''not'' use the --no-notify option on the client side, unless you are fully aware of the consequences of doing so.<br />
<br />
Please refer to the statd man page for full details.<br />
<br />
====/etc/hosts.allow====<br />
You will need to allow rpcbind for the server's ip:<br />
rpcbind: 192.168.0.100/255.255.255.255<br />
<br />
===Daemons===<br />
Start the rpcbind and nfs-common daemons:<br />
rc start rpcbind (or: rc start portmap)<br />
rc start nfs-common (or: rc start nfslock)<br />
<br />
Please note that they must be started in that order ''or'' start only ''nfs-common'', as ''rpcbind'' will be started as a dependency.<br />
<br />
To start the daemons at boot time, add them to the DAEMONS array in /etc/rc.conf.<br />
<br />
Then just mount as normal:<br />
mount server:/files /files<br />
<br />
Unlike CIFS shares or [[rsync]], NFS exports must be called by the full path on the server; example, if /home/fred/music is defined in /etc/exports on server ELROND, you must call:<br />
mount ELROND:/home/fred/music /mnt/point<br />
instead of just using:<br />
mount ELROND:music /mnt/point<br />
or you will get ''mount.nfs: access denied by server while mounting''<br />
<br />
===Auto-mount on boot===<br />
If you want to mount on boot, make sure network, rpcbind (portmap), nfs-common (nfslock) and netfs are in the DAEMONS array in /etc/rc.conf. Make sure the order is this one. It is better not to put any '@' in front of them (although you could safely use @netfs); for instance:<br />
DAEMONS=(... network rpcbind nfs-common @netfs ...)<br />
or<br />
DAEMONS=(... network portmap nfslock @netfs ...)<br />
<br />
Add an appropriate line in /etc/fstab, for example:<br />
server:/files /files nfs defaults 0 0<br />
<br />
If you wish to specify a packet size for read and write packets, specify them in your fstab entry. The values listed below are the defaults if none are specified:<br />
server:/files /files nfs rsize=32768,wsize=32768 0 0<br />
<br />
Read the nfs man page for further information, including all available mount options.<br />
<br />
==Troubleshooting==<br />
<br />
===Unreliable performance, slow data transfer, and/or high load when using NFS and gigabit===<br />
====Async====<br />
Verify that the async flag is used in {{Filename|/etc/exports}}<br />
Example:<br />
<br />
/nfs4exports 192.168.0.0/24(ro,fsid=0,no_subtree_check,async)<br />
/nfs4exports/data 192.168.0.0/24(rw,no_subtree_check,async,nohide)<br />
/nfs4exports/backup 192.168.0.0/24(rw,no_subtree_check,async,nohide)<br />
<br />
====Packetsize====<br />
This is a result of the default packetsize used by NFS, which causes significant fragmentation on gigabit networks. You can modify this behavior by the rsize and wsize mount parameters. Using rsize=32768,wsize=32768 should suffice. Please note that this problem does not occur on 100Mb networks, due to the lower packet transfer speed.<br />
<br />
Default value for NFS4 is 32768. Maximum is 65536. Increase from default in increments of 1024 until maximum transfer rate is achieved.<br />
<br />
===Portmap daemon fails to start at boot===<br />
Make sure you place portmap ''before'' netfs in the daemons array in /etc/rc.conf.<br />
<br />
===Nfsd fails to start with "nfssvc: No such device"===<br />
Make sure the nfs and nfsd modules are loaded in the kernel.<br />
<br />
===Nfsd seems to work, but I cannot connect from MacOS X clients===<br />
When trying to connect from a MacOS X client, you will see that everything is ok at logs, but MacOS X refuses to mount your NFS share. You have to add {{Codeline|insecure}} option to your share and re-run {{Codeline|exportfs -r}}.<br />
<br />
===mount.nfs: Operation not permitted===<br />
After updating to nfs-utils 1.2.1-2, mounting NFS shares stopped working. Henceforth, nfs-utils uses NFSv4 per default instead of NFSv3. The problem can be solved by using either mount option <code>'vers=3'</code> or <code>'nfsvers=3'</code> on the command line: <br />
# mount.nfs <remote target> <directory> -o ...,vers=3,...<br />
# mount.nfs <remote target> <directory> -o ...,nfsvers=3,...<br />
or in <code>/etc/fstab</code>:<br />
<remote target> <directory> nfs ...,vers=3,... 0 0<br />
<remote target> <directory> nfs ...,nfsvers=3,... 0 0<br />
<br />
===Ownership of mounted shares is 4294967294:4294967294===<br />
The following two values in /etc/conf.d/nfs-common.conf (on the client) need to be set:<br />
NEED_STATD="no"<br />
NEED_IDMAPD="yes"<br />
<br />
==Links and references==<br />
* See also [[Avahi]], a Zeroconf implementation which allows automatic discovery of NFS shares.<br />
* HOWTO: [[Diskless network boot NFS root]]<br />
* [http://publib.boulder.ibm.com/infocenter/pseries/v5r3/index.jsp?topic=/com.ibm.aix.prftungd/doc/prftungd/nfs_perf.htm Very helpful]<br />
* If you are setting up the Archlinux NFS server for use by Windows clients through Microsoft's SFU, you will save a lot of time and hair-scratching by looking at [http://bbs.archlinux.org/viewtopic.php?pid=523934#p523934 this forum post] first !<br />
* [http://blogs.msdn.com/sfu/archive/2008/04/14/all-well-almost-about-client-for-nfs-configuration-and-performance.aspx Microsoft Services for Unix NFS Client info]<br />
* [http://blogs.msdn.com/sfu/archive/2007/05/01/unix-interoperability-and-windows-vista.aspx Unix interoperability and Windows Vista] Prerequisites to connect to NFS with Vista</div>JaMeSiTeGeN