https://wiki.archlinux.org/api.php?action=feedcontributions&user=Leonardodag&feedformat=atomArchWiki - User contributions [en]2024-03-29T07:48:19ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Dm-crypt/Device_encryption&diff=782876Dm-crypt/Device encryption2023-07-09T21:07:17Z<p>Leonardodag: /* Encrypt an existing unencrypted file system */ actually better formatting</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data-at-rest encryption]]<br />
[[es:Dm-crypt (Español)/Device encryption]]<br />
[[ja:Dm-crypt/デバイスの暗号化]]<br />
[[pl:Dm-crypt (Polski)/Device encryption]]<br />
[[pt:Dm-crypt (Português)/Device encryption]]<br />
[[zh-hans:Dm-crypt/Device encryption]]<br />
This section covers how to manually utilize ''dm-crypt'' from the command line to encrypt a system.<br />
<br />
== Preparation ==<br />
<br />
Before using {{pkg|cryptsetup}}, always make sure the {{ic|dm_crypt}} [[kernel module]] is loaded.<br />
<br />
== Cryptsetup usage ==<br />
<br />
''Cryptsetup'' is the command line tool to interface with ''dm-crypt'' for creating, accessing and managing encrypted devices. The tool was later expanded to support different encryption types that rely on the Linux kernel '''d'''evice-'''m'''apper and the '''crypt'''ographic modules. The most notable expansion was for the Linux Unified Key Setup (LUKS) extension, 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. Devices accessed via the device-mapper are called block devices. For further information see [[Data-at-rest encryption#Block device encryption]]. <br />
<br />
The tool is used as follows: <br />
<br />
# cryptsetup ''OPTIONS'' ''action'' ''action-specific-options'' ''device'' ''dmname''<br />
<br />
It has compiled-in defaults for the options and the encryption mode, which will be used if no others are specified on the command line. Have a look at <br />
<br />
$ cryptsetup --help <br />
<br />
which lists options, actions and the default parameters for the encryption modes in that order. A full list of options can be found on the man page.<br />
Since different parameters are required or optional, depending on encryption mode and action, the following sections point out differences further. Block device encryption is fast, but speed matters a lot too. Since changing an encryption cipher of a block device after setup is difficult, it is important to check ''dm-crypt'' performance for the individual parameters in advance: <br />
<br />
$ cryptsetup benchmark <br />
<br />
can give guidance on deciding for an algorithm and key-size prior to installation. If certain AES ciphers excel with a considerable higher throughput, these are probably the ones with hardware support in the CPU.<br />
<br />
{{Tip|You may want to practise encrypting a virtual hard drive in a [[virtual machine]] when learning.}}<br />
<br />
=== Cryptsetup passphrases and keys ===<br />
<br />
An encrypted block device is protected by a key. A key is either: <br />
<br />
* a passphrase: see [[Security#Passwords]].<br />
* a keyfile, see [[#Keyfiles]].<br />
<br />
Both key types have default maximum sizes: passphrases can be up to 512 characters and keyfiles up to 8192 KiB. <br />
<br />
An important distinction of ''LUKS'' to note at this point is that the key is used to unlock the master-key of a LUKS-encrypted device and can be changed with root access. Other encryption modes do not support changing the key after setup, because they do not employ a master-key for the encryption. See [[Data-at-rest encryption#Block device encryption]] for details.<br />
<br />
== Encryption options with dm-crypt ==<br />
<br />
''Cryptsetup'' supports different encryption operating modes to use with ''dm-crypt'': <br />
<br />
* {{ic|--type luks}} for using the default LUKS format version (LUKS1 with {{Pkg|cryptsetup}} < 2.1.0, LUKS2 with {{Pkg|cryptsetup}} ≥ 2.1.0),<br />
* {{ic|--type luks1}} for using LUKS1, the most common version of LUKS,<br />
* {{ic|--type luks2}} for using LUKS2, the latest available version of LUKS that allows additional extensions,<br />
* {{ic|--type plain}} for using dm-crypt plain mode, <br />
* {{ic|--type loopaes}} for a loopaes legacy mode, <br />
* {{ic|--type tcrypt}} for a [[TrueCrypt]] compatibility mode.<br />
* {{ic|--type bitlk}} for a [[Wikipedia:BitLocker|BitLocker]] compatibility mode. See {{man|8|cryptsetup|BITLK (WINDOWS BITLOCKER COMPATIBLE) EXTENSION}}.<br />
<br />
The basic cryptographic options for encryption cipher and hashes available can be used for all modes and rely on the kernel cryptographic backend features. All that are loaded and available to use as options at runtime can be viewed with:<br />
<br />
$ less /proc/crypto <br />
<br />
{{Tip|If the list is short, execute {{ic|$ cryptsetup benchmark}} which will trigger loading available modules.}}<br />
<br />
The following introduces encryption options for the {{ic|luks}}, {{ic|luks1}}, {{ic|luks2}} and {{ic|plain}} modes. Note that the tables list options used in the respective examples in this article and not all available ones.<br />
<br />
=== Encryption options for LUKS mode ===<br />
<br />
The ''cryptsetup'' action to set up a new dm-crypt device in LUKS encryption mode is {{ic|luksFormat}}. Unlike what the name implies, it does not format the device, but sets up the LUKS device header and encrypts the master-key with the desired cryptographic options. <br />
<br />
In order to create a new LUKS container with the compiled-in defaults listed by {{ic|cryptsetup --help}}, simply execute:<br />
<br />
# cryptsetup luksFormat ''device''<br />
<br />
As of cryptsetup 2.4.0, this is equivalent to: <br />
<br />
# cryptsetup --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase luksFormat ''device''<br />
<br />
Defaults are compared with a cryptographically higher specification example in the table below, with accompanying comments: <br />
<br />
{| class="wikitable"<br />
! Options !! Cryptsetup 2.1.0 defaults !! Example !! Comment<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --cipher<br />
-c<br />
| {{ic|aes-xts-plain64}}<br />
| {{ic|aes-xts-plain64}}<br />
| [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/v1.6.0-ReleaseNotes Release 1.6.0] changed the defaults to an AES [[Data-at-rest encryption#Ciphers and modes of operation|cipher]] in [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS]] mode (see item 5.16 [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects of the FAQ]). It is advised against using the previous default {{ic|--cipher aes-cbc-essiv}} because of its known [[wikipedia:Disk encryption theory#Cipher-block chaining (CBC)|issues]] and practical [https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ attacks] against them.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-size<br />
-s<br />
| {{ic|256}} ({{ic|512}} for XTS)<br />
| {{ic|512}}<br />
| By default a 512 bit key-size is used for XTS ciphers. Note however that [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS splits the supplied key in half]], so this results in AES-256 being used.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --hash<br />
-h<br />
| {{ic|sha256}}<br />
| {{ic|sha512}}<br />
| Hash algorithm used for [[Data-at-rest encryption#Cryptographic metadata|key derivation]]. Release 1.7.0 changed defaults from {{ic|sha1}} to {{ic|sha256}} "''not for security reasons [but] mainly to prevent compatibility problems on hardened systems where SHA1 is already [being] phased out''"[https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]. The former default of {{ic|sha1}} can still be used for compatibility with older versions of ''cryptsetup'' since it is [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects considered secure] (see item 5.20). <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --iter-time<br />
-i<br />
| {{ic|2000}}<br />
| {{ic|5000}}<br />
| Number of milliseconds to spend with PBKDF passphrase processing. Release 1.7.0 changed defaults from {{ic|1000}} to {{ic|2000}} to "''try to keep PBKDF2 iteration count still high enough and also still acceptable for users.''"[https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]. This option is only relevant for LUKS operations that set or change passphrases, such as {{ic|luksFormat}} or {{ic|luksAddKey}}. Specifying 0 as parameter selects the compiled-in default.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --use-urandom<br />
| {{ic|--use-urandom}}<br />
| {{ic|--use-random}}<br />
| Selects which [[random number generator]] to use. Note that [https://lwn.net/Articles/808575/ /dev/random blocking pool has been removed]. Therefore, {{ic|--use-random}} flag is now equivalent to {{ic|--use-urandom}}.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --verify-passphrase<br />
-y<br />
| Yes<br />
| -<br />
| Enabled by default in Arch Linux for {{ic|luksFormat}} and {{ic|luksAddKey}}.<br />
|}<br />
<br />
The properties of LUKS features and options are described in the [https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification LUKS1] (pdf) and [https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/on-disk-format-luks2.pdf LUKS2] (pdf) specifications.<br />
<br />
{{Tip|The project developers' [https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf devconfcz2016] (pdf) presentation summarizes the motivation for the major specification update to LUKS2.}}<br />
<br />
==== Iteration time ====<br />
<br />
From [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#2-setup cryptsetup FAQ§2.1] and [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#3-common-problems §3.4]:<br />
<br />
:The unlock time for a key-slot [...] is calculated when setting a passphrase. By default it is 1 second (2 seconds for LUKS2). [...]<br />
:Passphrase iteration count is based on time and hence security level depends on CPU power of the system the LUKS container is created on. [...]<br />
:If you set a passphrase on a fast machine and then unlock it on a slow machine, the unlocking time can be much longer.<br />
<br />
As such, it is better to always create a container on the machine where it will be most often accessed.<br />
<br />
Read the rest of those sections for advice on how to correctly adjust the iteration count should the need arise.<br />
<br />
==== Sector size ====<br />
<br />
See [[Advanced Format#dm-crypt]].<br />
<br />
=== Encryption options for plain mode ===<br />
<br />
In dm-crypt ''plain'' mode, there is no master-key on the device, hence, there is no need to set it up. Instead the encryption options to be employed are used directly to create the mapping between an encrypted disk and a named device. The mapping can be created against a partition or a full device. In the latter case not even a partition table is needed. <br />
<br />
{{Expansion|Using the defaults is not safe as they can change in future cryptsetup releases. [https://www.kernel.org/pub/linux/utils/cryptsetup/v2.6/v2.6.0-ReleaseNotes cryptsetup 2.6.0 changelog] says the the next release will have a backward incompatible change.}}<br />
<br />
To create a ''plain'' mode mapping with cryptsetup's default parameters: <br />
<br />
# cryptsetup ''options'' open --type plain ''device'' ''dmname''<br />
<br />
Executing it will prompt for a password, which should have very high entropy. Below a comparison of default parameters with the example in [[dm-crypt/Encrypting an entire system#Plain dm-crypt]].<br />
<br />
{| class="wikitable"<br />
! Option !! Cryptsetup 2.1.0 defaults !! Example !! Comment<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --hash<br />
-h<br />
| {{ic|ripemd160}}<br />
| -<br />
| The hash is used to create the key from the passphrase; it is not used on a keyfile. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --cipher<br />
-c<br />
| {{ic|aes-cbc-essiv:sha256}}<br />
| {{ic|aes-xts-plain64}}<br />
| The cipher consists of three parts: cipher-chainmode-IV generator. Please see [[Data-at-rest encryption#Ciphers and modes of operation]] for an explanation of these settings, and the [https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt DMCrypt documentation] for some of the options available. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-size<br />
-s<br />
|{{ic|256}}<br />
|{{ic|512}}<br />
|The key size (in bits). The size will depend on the cipher being used and also the chainmode in use. Xts mode requires twice the key size of cbc. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --size<br />
-b<br />
|real size of target disk<br />
|{{ic|2048}} (mapped device will be 512B×2048=1MiB)<br />
|Limit the maximum size of the device (in 512-byte sectors).<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --offset<br />
-o<br />
|{{ic|0}}<br />
|{{ic|0}}<br />
|The offset from the beginning of the target disk (in 512-byte sectors) from which to start the mapping.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --skip<br />
-p<br />
|{{ic|0}}<br />
|{{ic|2048}} (512B×2048=1MiB will be skipped)<br />
|The number of 512-byte sectors of encrypted data to skip at the beginning.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-file<br />
-d<br />
| default uses a passphrase<br />
| {{ic|/dev/sd''Z''}} (or e.g. {{ic|/boot/keyfile.enc}})<br />
|The device or file to be used as a key. See [[#Keyfiles]] for further details.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --keyfile-offset<br />
| {{ic|0}}<br />
| {{ic|0}}<br />
| Offset from the beginning of the file where the key starts (in bytes). This option is supported from ''cryptsetup'' 1.6.7 onwards. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --keyfile-size<br />
-l<br />
|{{ic|8192kB}}<br />
| - (default applies)<br />
| Limits the bytes read from the key file. This option is supported from ''cryptsetup'' 1.6.7 onwards. <br />
|}<br />
<br />
Using the device {{ic|/dev/sd''X''}}, the above right column example results in:<br />
<br />
# cryptsetup --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sd''Z'' --key-size=512 open --type=plain /dev/sdX enc<br />
<br />
Unlike encrypting with LUKS, the above command must be executed ''in full'' whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details. We can now check that the mapping has been made:<br />
<br />
# fdisk -l<br />
<br />
An entry should now exist for {{ic|/dev/mapper/enc}}.<br />
<br />
== Encrypting devices with cryptsetup ==<br />
<br />
This section shows how to employ the options for creating new encrypted block devices and accessing them manually. <br />
<br />
{{Warning|GRUB's support for LUKS2 is limited; see [[GRUB#Encrypted /boot]] for details. Use LUKS1 ({{ic|1=cryptsetup luksFormat --type luks1}}) for partitions that GRUB will need to unlock.}}<br />
<br />
=== Encrypting devices with LUKS mode ===<br />
<br />
==== Formatting LUKS partitions ====<br />
<br />
In order to setup a partition as an encrypted LUKS partition execute:<br />
<br />
# cryptsetup luksFormat ''device''<br />
<br />
You will then be prompted to enter a password and verify it.<br />
<br />
See [[#Encryption options for LUKS mode]] for command line options.<br />
<br />
You can check the results with:<br />
<br />
# cryptsetup luksDump ''device''<br />
<br />
You will note that the dump not only shows the cipher header information, but also the key-slots in use for the LUKS partition. <br />
<br />
The following example will create an encrypted root partition on {{ic|/dev/sda1}} using the default AES cipher in XTS mode with an effective 256-bit encryption <br />
<br />
# cryptsetup -s 512 luksFormat /dev/sda1<br />
<br />
===== Using LUKS to format partitions 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 luksFormat ''device'' ''/path/to/mykeyfile''<br />
<br />
See [[#Keyfiles]] for instructions on how to generate and manage keyfiles.<br />
<br />
==== Unlocking/Mapping LUKS partitions with the device mapper ====<br />
<br />
Once the LUKS partitions have been created, they can then be unlocked.<br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that {{ic|''device''}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/''dm_name''}} so as not to overwrite the encrypted data. To guard against accidental overwriting, read about the possibilities to [[#Backup and restore|backup the cryptheader]] after finishing setup.<br />
<br />
In order to open an encrypted LUKS partition execute:<br />
<br />
# cryptsetup open ''device'' ''dm_name''<br />
<br />
You will then be prompted for the password to unlock the partition. Usually the device mapped name is descriptive of the function of the partition that is mapped. For example the following unlocks a root luks partition {{ic|/dev/sda1}} and maps it to device mapper named {{ic|root}}:<br />
<br />
# cryptsetup open /dev/sda1 root <br />
<br />
Once opened, the root partition device address would be {{ic|/dev/mapper/root}} instead of the partition (e.g. {{ic|/dev/sda1}}). <br />
<br />
For setting up LVM ontop the encryption layer the device file for the decrypted volume group would be anything like {{ic|/dev/mapper/root}} instead of {{ic|/dev/sda1}}. LVM will then give additional names to all logical volumes created, e.g. {{ic|/dev/lvmpool/root}} and {{ic|/dev/lvmpool/swap}}.<br />
<br />
In order to write encrypted data into the partition it must be accessed through the device mapped name. The first step of access will typically be to [[create a file system]]. For example:<br />
<br />
# mkfs -t ext4 /dev/mapper/root<br />
<br />
The device {{ic|/dev/mapper/root}} can then be [[mount]]ed like any other partition.<br />
<br />
To close the LUKS container, unmount the partition and do:<br />
<br />
# cryptsetup close root<br />
<br />
==== Using a TPM to store keys ====<br />
<br />
See [[Trusted Platform Module#Data-at-rest encryption with LUKS]].<br />
<br />
=== Encrypting devices with plain mode ===<br />
<br />
The creation and subsequent access of a ''dm-crypt'' plain mode encryption both require not more than using the ''cryptsetup'' {{ic|open}} action with correct [[#Encryption options for plain mode|parameters]]. The following shows that with two examples of non-root devices, but adds a quirk by stacking both (i.e. the second is created inside the first). Obviously, stacking the encryption doubles overhead. The usecase here is simply to illustrate another example of the cipher option usage. <br />
<br />
A first mapper is created with ''cryptsetup's'' plain-mode defaults, as described in the table's left column above <br />
<br />
{{hc|# cryptsetup --type plain -v open /dev/sd''xY'' plain1|<br />
Enter passphrase: <br />
Command successful.<br />
}}<br />
<br />
Now we add the second block device inside it, using different encryption parameters and with an (optional) offset, create a file system and mount it <br />
<br />
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# lsblk -p|<br />
NAME <br />
/dev/sda <br />
├─/dev/sd''xY'' <br />
│ └─/dev/mapper/plain1 <br />
│ └─/dev/mapper/plain2 <br />
...<br />
}}<br />
<br />
# mkfs -t ext2 /dev/mapper/plain2<br />
# mount -t ext2 /dev/mapper/plain2 /mnt<br />
# echo "This is stacked. one passphrase per foot to shoot." > /mnt/stacked.txt<br />
<br />
We close the stack to check access works<br />
<br />
# cryptsetup close plain2<br />
# cryptsetup close plain1<br />
<br />
First, let us try to open the file system directly: <br />
<br />
# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/sd''xY'' plain2<br />
<br />
{{hc|# mount -t ext2 /dev/mapper/plain2 /mnt|<br />
mount: wrong fs type, bad option, bad superblock on /dev/mapper/plain2,<br />
missing codepage or helper program, or other error<br />
}}<br />
<br />
Why that did not work? Because the "plain2" starting block ({{ic|10}}) is still encrypted with the cipher from "plain1". It can only be accessed via the stacked mapper. The error is arbitrary though, trying a wrong passphrase or wrong options will yield the same. For ''dm-crypt'' plain mode, the {{ic|open}} action will not error out itself. <br />
<br />
Trying again in correct order: <br />
<br />
# cryptsetup close plain2 # dysfunctional mapper from previous try<br />
<br />
{{hc|# cryptsetup --type plain open /dev/sd''xY'' plain1|<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# mount /dev/mapper/plain2 /mnt && cat /mnt/stacked.txt|<br />
This is stacked. one passphrase per foot to shoot.<br />
}}<br />
<br />
''dm-crypt'' will handle stacked encryption with some mixed modes too. For example LUKS mode could be stacked on the "plain1" mapper. Its header would then be encrypted inside "plain1" when that is closed.<br />
<br />
Available for plain mode only is the option {{ic|--shared}}. With it a single device can be segmented into different non-overlapping mappers. We do that in the next example, using a ''loopaes'' compatible cipher mode for "plain2" this time: <br />
<br />
{{hc|# cryptsetup --type plain --offset 0 --size 1000 open /dev/sd''xY'' plain1|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|1=# cryptsetup --type plain --offset 1000 --size 1000 --shared --cipher=aes-cbc-lmk --hash=sha256 open /dev/sd''xY'' plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# lsblk -p|<br />
NAME <br />
dev/sd''xY'' <br />
├─/dev/sd''xY'' <br />
│ ├─/dev/mapper/plain1 <br />
│ └─/dev/mapper/plain2 <br />
...<br />
}}<br />
<br />
As the device tree shows both reside on the same level, i.e. are not stacked and "plain2" can be opened individually.<br />
<br />
== Cryptsetup actions specific for LUKS ==<br />
<br />
=== Key management ===<br />
<br />
It is possible to define additional keys for the LUKS partition. This enables the user to create access keys for safe backup storage In so-called key escrow, one key is used for daily usage, another kept in escrow to gain access to the partition in case the daily passphrase is forgotten or a keyfile is lost/damaged. A different key-slot could also be used to grant access to a partition to a user by issuing a second key and later revoking it again. <br />
<br />
Once an encrypted partition has been created, the initial keyslot 0 is created (if no other was specified manually). Additional keyslots are numbered from 1 to 7. Which keyslots are used can be seen by issuing <br />
<br />
# cryptsetup luksDump /dev/''device''<br />
<br />
Where {{ic|''device''}} is the block device containing the LUKS header. This and all the following commands in this section work on header backup files as well.<br />
<br />
==== Adding LUKS keys ====<br />
<br />
Adding new keyslots is accomplished with the {{ic|luksAddKey}} action. For safety it will always, even for already unlocked devices, ask for a valid existing key (a passphrase for any existing slot) before a new one may be entered:<br />
<br />
{{hc|# cryptsetup luksAddKey /dev/''device'' [''/path/to/additionalkeyfile'']|<br />
Enter any passphrase:<br />
Enter new passphrase for key slot:<br />
Verify passphrase: <br />
}}<br />
<br />
If {{ic|''/path/to/additionalkeyfile''}} is given, cryptsetup will add a new keyslot for {{ic|''additionalkeyfile''}}. Otherwise it prompts for a new passphrase. To authorize the action with an existing ''keyfile'', the {{ic|--key-file}} or {{ic|-d}} option followed by the "old" {{ic|''keyfile''}} will try to unlock all available keyfile keyslots:<br />
<br />
# cryptsetup luksAddKey /dev/''device'' [''/path/to/additionalkeyfile''] -d ''/path/to/keyfile''<br />
<br />
If it is intended to use multiple keys and change or revoke them, the {{ic|--key-slot}} or {{ic|-S}} option may be used to specify the slot: <br />
<br />
{{hc|# cryptsetup luksAddKey /dev/''device'' -S 6|<br />
Enter any passphrase: <br />
Enter new passphrase for key slot: <br />
Verify passphrase:<br />
}}<br />
<br />
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|<br />
Key Slot 6: ENABLED<br />
}}<br />
<br />
To show an associated action in this example, we decide to change the key right away: <br />
<br />
{{hc|# cryptsetup luksChangeKey /dev/''device'' -S 6|<br />
Enter LUKS passphrase to be changed: <br />
Enter new LUKS passphrase:<br />
}}<br />
<br />
before continuing to remove it.<br />
<br />
==== Removing LUKS keys ====<br />
<br />
There are three different actions to remove keys from the header: <br />
<br />
* {{ic|luksRemoveKey}} removes a key by specifying its passphrase/key-file. <br />
* {{ic|luksKillSlot}} removes a key by specifying its slot (needs another valid key). Obviously, this is extremely useful if you have forgotten a passphrase, lost a key-file, or have no access to it. <br />
* {{ic|luksErase}} removes '''all''' active keys. <br />
<br />
{{warning|<br />
* All above actions can be used to irrevocably delete the last active key for an encrypted device! <br />
* The {{ic|luksErase}} command was added in version 1.6.4 to quickly nuke access to the device. This action '''will not''' prompt for a valid passphrase! It will not [[dm-crypt/Drive preparation#Wipe LUKS header|wipe the LUKS header]], but all keyslots at once and you will, therefore, not be able to regain access unless you have a valid backup of the LUKS header.<br />
}}<br />
<br />
For above warning it is good to know the key we want to '''keep''' is valid. An easy check is to unlock the device with the {{ic|-v}} option, which will specify which slot it occupies: <br />
<br />
{{hc|# cryptsetup --test-passphrase -v open /dev/''device''|<br />
Enter passphrase for /dev/''device'': <br />
Key slot 1 unlocked.<br />
Command successful.<br />
}}<br />
<br />
Now we can remove the key added in the previous subsection using its passphrase: <br />
<br />
{{hc|# cryptsetup luksRemoveKey /dev/''device''|<br />
Enter LUKS passphrase to be deleted:<br />
}}<br />
<br />
If we had used the same passphrase for two keyslots, the first slot would be wiped now. Only executing it again would remove the second one. <br />
<br />
Alternatively, we can specify the key slot: <br />
<br />
{{hc|# cryptsetup luksKillSlot /dev/''device'' 6|<br />
Enter any remaining LUKS passphrase:<br />
}}<br />
<br />
Note that in both cases, no confirmation was required.<br />
<br />
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|<br />
Key Slot 6: DISABLED<br />
}}<br />
<br />
To re-iterate the warning above: If the same passphrase had been used for key slots 1 and 6, both would be gone now.<br />
<br />
=== Backup and restore ===<br />
<br />
If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much of a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. Damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table. Therefore, having a backup of the header and storing it on another disk might be a good idea.<br />
<br />
{{Note|If one of the LUKS-encrypted partitions' passphrases becomes compromised, you must revoke it on ''every'' copy of the cryptheader, even those you have backed up. Otherwise, a copy of the backed-up cryptheader that uses the compromised passphrase can be used to determine the master key which in turn can be used to decrypt the associated partition (even your actual partition, not only the backed-up version). On the other hand, if the master key gets compromised, you have to reencrypt your whole partition. See [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery LUKS FAQ] for further details.}}<br />
<br />
==== Backup using cryptsetup ====<br />
<br />
Cryptsetup's {{ic|luksHeaderBackup}} action stores a binary backup of the LUKS header and keyslot area:<br />
<br />
# cryptsetup luksHeaderBackup /dev/''device'' --header-backup-file ''/mnt/backup/file.img''<br />
<br />
where {{ic|''device''}} is the partition containing the LUKS volume.<br />
<br />
You can also back up the plain text header into ramfs and encrypt it with e.g. [[GPG]] before writing it to persistent storage:<br />
<br />
# mount --mkdir -t ramfs ramfs /root/''tmp''<br />
# cryptsetup luksHeaderBackup /dev/''device'' --header-backup-file /root/''tmp''/''file''.img<br />
# gpg2 --recipient ''User_ID'' --encrypt /root/''tmp''/''file''.img <br />
# cp /root/''tmp''/''file''.img.gpg /mnt/''backup''/<br />
# umount /root/''tmp''<br />
<br />
{{Warning|[[tmpfs]] can swap to the disk in low memory situations, so it is not recommended here.}}<br />
<br />
==== Restore using cryptsetup ====<br />
<br />
{{Warning|Restoring the wrong header or restoring to an unencrypted partition will cause data loss! The action can not perform a check whether the header is actually the ''correct'' one for that particular device.}} <br />
<br />
In order to evade restoring a wrong header, you can ensure it does work by using it as a remote {{ic|--header}} first: <br />
<br />
{{hc|# cryptsetup -v --header /mnt/''backup''/''file''.img open /dev/''device'' test|<br />
Key slot 0 unlocked.<br />
Command successful.<br />
}}<br />
<br />
# mount /dev/mapper/test /mnt/test && ls /mnt/test <br />
# umount /mnt/test <br />
# cryptsetup close test <br />
<br />
Now that the check succeeded, the restore may be performed: <br />
<br />
# cryptsetup luksHeaderRestore /dev/''device'' --header-backup-file ./mnt/''backup''/''file''.img<br />
<br />
Now that all the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing the command.<br />
<br />
==== Manual backup and restore ====<br />
<br />
The header always resides at the beginning of the device and a backup can be performed without access to ''cryptsetup'' as well. First you have to find out the payload offset of the crypted partition:<br />
<br />
{{hc|# cryptsetup luksDump /dev/''device'' {{!}} grep "Payload offset"|<br />
Payload offset: 4040<br />
}}<br />
<br />
Second check the sector size of the drive<br />
<br />
{{hc|# fdisk -l /dev/''device'' {{!}} grep "Sector size"|<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
}}<br />
<br />
Now that you know the values, you can backup the header with a simple [[dd]] command:<br />
<br />
# dd if=/dev/''device'' of=/path/to/''file''.img bs=512 count=4040<br />
<br />
and store it safely.<br />
<br />
A restore can then be performed using the same values as when backing up:<br />
<br />
# dd if=./''file''.img of=/dev/''device'' bs=512 count=4040<br />
<br />
=== Re-encrypting devices ===<br />
<br />
{{Expansion|cryptsetup 2.2 using LUKS2 (with a 16 MiB header) supports online encryption/decryption/reencryption.[https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.2/v2.2.0-ReleaseNotes]}}<br />
<br />
{{Out of date|cryptsetup-reencrypt was removed in cryptsetup 2.5.0.[https://www.kernel.org/pub/linux/utils/cryptsetup/v2.5/v2.5.0-ReleaseNotes]}}<br />
<br />
The {{Pkg|cryptsetup}} package features two options for re-encryption.<br />
<br />
; cryptsetup reencrypt: Argument to {{ic|cryptsetup}} itself: Preferred method. Currently LUKS2 devices only. Actions can be performed online. Supports multiple parallel re-encryption jobs. Resilient to system failures. See {{man|8|cryptsetup}} for more information.<br />
<br />
; cryptsetup-reencrypt: Legacy tool, supports LUKS1 in addition to LUKS2. Actions can be performed on unmounted devices only. Single process at a time. Sensitive to system failures. See {{man|8|cryptsetup-reencrypt}} for more information. <br />
<br />
Both can be used to convert an existing unencrypted file system to a LUKS encrypted one or permanently remove LUKS encryption from a device (using {{ic|--decrypt}}). As its name suggests it can also be used to re-encrypt an existing LUKS encrypted device, though, re-encryption is not possible for a detached LUKS header or other encryption modes (e.g. plain-mode). For re-encryption it is possible to change the [[#Encryption options for LUKS mode]]. <br />
<br />
One application of re-encryption may be to secure the data again after a passphrase or [[#Keyfiles|keyfile]] has been compromised ''and'' one cannot be certain that no copy of the LUKS header has been obtained. For example, if only a passphrase has been shoulder-surfed but no physical/logical access to the device happened, it would be enough to change the respective passphrase/key only ([[#Key management]]). <br />
<br />
{{Warning|Always make sure a '''reliable backup''' is available and double-check options you specify before using the tool!}}<br />
<br />
The following shows an example to encrypt an unencrypted file system partition and a re-encryption of an existing LUKS device.<br />
<br />
==== Encrypt an existing unencrypted file system ====<br />
<br />
{{Tip|If you are trying to encrypt an existing root partition, you might want to create a separate and unencrypted boot partition which will be mounted to {{ic|/boot}} (see [[Dm-crypt/Encrypting an entire system#Preparing the boot partition]]). It is not strictly necessary but has a number of advantages:<br />
<br />
* If {{ic|/boot}} is located inside an encrypted root partition, the system will ask for the passphrase twice when the machine is powered on. The first time will happen when the boot loader attempts to read the files located inside encrypted {{ic|/boot}}, the second time will be when the kernel tries to mount the encrypted partition [https://opencraft.com/blog/tutorial-encrypting-an-existing-root-partition-in-ubuntu-with-dm-crypt-and-luks/]. This might not be the desired behaviour and can be prevented by having a separate and unencryted boot partition.<br />
* Some system restore applications (e.g., {{AUR|timeshift}}) will not work if {{ic|/boot}} is located inside an encryted partition [https://github.com/teejee2008/timeshift/issues/280].<br />
<br />
In short, create a partition with the size of at least 260 MiB if needed. See [[Partitioning#/boot]].}}<br />
<br />
A LUKS encryption header is always stored at the beginning of the device. Since an existing file system will usually be allocated all partition sectors, the first step is to shrink it to make space for the LUKS header.<br />
<br />
{{Expansion|cryptsetup man pages suggest using twice the LUKS2 header size. That implies 32 MiB and using {{ic|--reduce-device-size 32M}}}}<br />
<br />
The [[#Encryption options for LUKS mode|default]] LUKS2 header requires 16 MiB. If the current file system occupies all the available space, we will have to shrink it at least that much. To shrink an existing {{ic|ext4}} file system on {{ic|/dev/sd''xY''}} to its current possible minimum:<br />
<br />
# umount /mnt<br />
<br />
{{hc|# e2fsck -f /dev/sd''xY''|<br />
e2fsck 1.46.5 (30-Dec-2021)<br />
Pass 1: Checking inodes, blocks, and sizes<br />
...<br />
/dev/sda6: 12/166320 files (0.0% non-contiguous), 28783/665062 blocks<br />
}}<br />
<br />
{{hc|# resize2fs -p -M /dev/sd''xY''|<br />
e2fsck 1.46.5 (30-Dec-2021)<br />
Resizing the filesystem on /dev/sd''xY'' to 26347 (4k) blocks.<br />
The filesystem on /dev/sd''xY'' is now 26347 (4k) blocks long.<br />
}}<br />
<br />
{{Tip|Shrinking to the minimum size with {{ic|-M}} might take very long. You might want to calculate a size just 32 MiB smaller than the current size instead of using {{ic|-M}}.}}<br />
<br />
{{Warning|The file system should be shrunk while the underlying device (e.g., a partition) should be kept at its original size. Some graphical tools (e.g., [[GParted]]) may resize both the file system and the partition, and data loss may occur after encryption.}}<br />
<br />
Now we encrypt it, using the default cipher we do not have to specify it explicitly:<br />
<br />
{{hc|# cryptsetup reencrypt --encrypt --reduce-device-size 16M /dev/sd''xY''|<nowiki><br />
<br />
WARNING!<br />
<br />
========<br />
<br />
This will overwrite data on LUKS2-temp-12345678-9012-3456-7890-123456789012.new irrevocably.<br />
<br />
Are you sure? (Type 'yes' in capital letters): YES<br />
Enter passphrase for LUKS2-temp-12345678-9012-3456-7890-123456789012.new: <br />
Verify passphrase: <br />
</nowiki>}}<br />
<br />
After it finished, the whole {{ic|/dev/sd''xY''}} partition is encrypted, not only the space the file system was shrunk to. As a final step we extend the original {{ic|ext4}} file system to occupy all available space again, on the now encrypted partition:<br />
<br />
{{hc|# cryptsetup open /dev/sd''xY'' recrypt|<br />
Enter passphrase for /dev/sd''xY'': <br />
...<br />
}}<br />
<br />
{{hc|# resize2fs /dev/mapper/recrypt|<br />
resize2fs 1.43-WIP (18-May-2015)<br />
Resizing the filesystem on /dev/mapper/recrypt to 664807 (4k) blocks.<br />
The filesystem on /dev/mapper/recrypt is now 664807 (4k) blocks long.<br />
}}<br />
<br />
# mount /dev/mapper/recrypt /mnt<br />
<br />
The file system is now ready to use. You may want to add it to your [[crypttab]].<br />
<br />
{{Tip|If you have just encrypted your root partition, you might need to perform a number of post-encryption adjustments.<br />
<br />
# Configure mkinitcpio - see [[Dm-crypt/Encrypting an entire system#Configuring mkinitcpio]].<br />
# Configure the boot loader - see [[Dm-crypt/Encrypting an entire system#Configuring the boot loader]] and [[Dm-crypt/Encrypting an entire system#Configuring GRUB]].<br />
# Configure fstab and crypttab - see [[Dm-crypt/Encrypting an entire system#Configuring fstab and crypttab]].<br />
}}<br />
<br />
==== Re-encrypting an existing LUKS partition ====<br />
<br />
In this example an existing LUKS device is re-encrypted. <br />
<br />
{{Warning|Double-check you specify encryption options for correctly and ''never'' re-encrypt without a '''reliable backup'''!}}<br />
<br />
In order to re-encrypt a device with its existing encryption options, they do not need to be specified:<br />
{{bc|# cryptsetup reencrypt /dev/sd''xY''}}<br />
{{Note|For LUKS1 we will need to use the legacy tool:{{bc|# cryptsetup-reencrypt /dev/sd''xY''}}}}<br />
<br />
Existing keys are retained when re-encrypting a device with a different cipher and/or hash. Another use case is to re-encrypt LUKS devices which have non-current encryption options. Apart from above warning on specifying options correctly, the ability to change the LUKS header may also be limited by its size. For example, if the device was initially encrypted using a CBC mode cipher and 128 bit key-size, the LUKS header will be half the size of above mentioned {{ic|4096}} sectors: <br />
<br />
{{hc|# cryptsetup luksDump /dev/sd''xY'' {{!}} grep -e "mode" -e "Payload" -e "MK bits"|<br />
Cipher mode: cbc-essiv:sha256<br />
Payload offset: '''2048'''<br />
MK bits: 128<br />
}}<br />
<br />
While it is possible to upgrade the encryption of such a device, it is currently only feasible in two steps. First, re-encrypting with the same encryption options, but using the {{ic|--reduce-device-size}} option to make further space for the larger LUKS header. Second, re-encypt the whole device again with the desired cipher. For this reason and the fact that a backup should be created in any case, creating a new, fresh encrypted device to restore into is always the faster option.<br />
<br />
=== Conversion from LUKS1 to LUKS2 and back ===<br />
<br />
The {{Pkg|cryptsetup}} package has {{ic|convert}} option that needed for conversion between LUKS1 and LUKS2 container types. The argument {{ic|--type}} is '''required'''.<br />
<br />
Migration from LUKS1 to LUKS2:<br />
<br />
# cryptsetup convert --type luks2 /dev/sd''xY''<br />
<br />
{{Note|The LUKS header size will be 16 MiB instead of 2 MiB.}}<br />
<br />
Rollback to LUKS1 (for example, to boot from [[GRUB#Encrypted /boot|GRUB with encrypted /boot]]):<br />
<br />
# cryptsetup convert --type luks1 /dev/sd''xY''<br />
<br />
{{Note|Conversion from LUKS2 to LUKS1 is '''not''' always possible. You may get the following error:<br />
Cannot convert to LUKS1 format - keyslot 0 is not LUKS1 compatible.<br />
If the container is using Argon2, it needs to be converted to PBKDF2 to be LUKS1-compatible.<br />
# cryptsetup luksConvertKey --pbkdf pbkdf2 /dev/sd''xY''<br />
}}<br />
<br />
== Resizing encrypted devices ==<br />
<br />
{{Expansion|This section should be rewritten to introduce resizing more generically. Perhaps work on it together with [[Resizing LVM-on-LUKS]].}}<br />
<br />
If a storage device encrypted with dm-crypt is being cloned (with a tool like dd) to another larger device, the underlying dm-crypt device must be resized to use the whole space. <br />
<br />
The destination device is /dev/sdX2 in this example, the whole available space adjacent to the partition will be used:<br />
<br />
# cryptsetup luksOpen /dev/sdX2 sdX2<br />
# cryptsetup resize sdX2<br />
<br />
Then the underlying file system must be resized.<br />
<br />
=== Loopback file system ===<br />
<br />
Assume that an encrypted loopback file system is stored in a file {{ic|/bigsecret}}, looped to {{ic|/dev/loop0}}, mapped to {{ic|secret}} and mounted on {{ic|/mnt/secret}}, as in the example at [[dm-crypt/Encrypting a non-root file system#File container]].<br />
<br />
If the container file is currently mapped and/or mounted, unmount and/or close it:<br />
<br />
# umount /mnt/secret<br />
# cryptsetup close secret<br />
# losetup -d /dev/loop0<br />
<br />
Next, expand the container file with the size of the data you want to add. In this example, the file will be expanded with 1M * 1024, which is 1G.<br />
<br />
{{Warning|Make absolutely sure to use '''two''' {{ic|>}}, instead of just one, or else you will overwrite the file instead of appending to it. Making a backup before this step is strongly recommended.}}<br />
<br />
# dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Now map the container to the loop device:<br />
<br />
# losetup /dev/loop0 /bigsecret<br />
# cryptsetup open /dev/loop0 secret<br />
<br />
After this, resize the encrypted part of the container to the new maximum size of the container file:<br />
<br />
# cryptsetup resize secret<br />
<br />
Finally, perform a file system check and, if it is ok, resize it (example for ext2/3/4):<br />
<br />
# e2fsck -f /dev/mapper/secret<br />
# resize2fs /dev/mapper/secret<br />
<br />
You can now mount the container again:<br />
<br />
# mount /dev/mapper/secret /mnt/secret<br />
<br />
=== Integrity protected device ===<br />
<br />
If the device was formatted with integrity support (e.g., {{ic|--integrity hmac-sha256}}) and the backing block device is shrinked, it cannot be opened with this error: {{ic|device-mapper: reload ioctl on failed: Invalid argument}}.<br />
<br />
To fix this issue without wiping the device again, it can be formatted with the previous master key (keeping the per-sector tags valid).<br />
<br />
# cryptsetup luksDump /dev/sdX2 --dump-master-key --master-key-file=/tmp/masterkey-in-tmpfs.key<br />
# cryptsetup luksFormat /dev/sdX2 --type luks2 --integrity hmac-sha256 --master-key-file=/tmp/masterkey-in-tmpfs.key --integrity-no-wipe<br />
# rm /tmp/masterkey-in-tmpfs.key<br />
<br />
== Keyfiles ==<br />
<br />
{{Note|This section describes using a plaintext keyfile. If you want to encrypt your keyfile giving you two factor authentication see [[dm-crypt/Specialties#Using GPG, LUKS, or OpenSSL Encrypted Keyfiles|Using GPG or OpenSSL Encrypted Keyfiles]] for details, but please still read this section.}}<br />
<br />
'''What is a keyfile?'''<br />
<br />
A keyfile is a file whose data is used as the passphrase to unlock an encrypted volume.<br />
That means if such a file is lost or changed, decrypting the volume may 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 keyfiles. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
=== Types of keyfiles ===<br />
<br />
==== passphrase ====<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 />
Example: {{ic|1234}}<br />
<br />
{{Note|The keyfile containing the passphrase must not have a newline in it. One option is to create it using <br />
<br />
# echo -n 'your_passphrase' > ''/path/to/keyfile''<br />
# chown root:root ''/path/to/keyfile''; chmod 400 ''/path/to/keyfile''<br />
<br />
If the file contains special characters such as a backslash, rather than escaping these, it is recommended to simply edit the key file directly entering or pasting the passphrase and then remove the trailing newline with a handy perl one-liner:<br />
<br />
# perl -pi -e 'chomp if eof' ''/path/to/keyfile''<br />
}}<br />
<br />
==== randomtext ====<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 />
Example: {{ic|fjqweifj830149-57 819y4my1-38t1934yt8-91m 34co3;t8y;9p3y-}}<br />
<br />
==== binary ====<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 random text file. However this is controversial and has never been exploited publicly.<br />
<br />
Example: images, text, video, ...<br />
<br />
=== Creating a keyfile with random characters ===<br />
<br />
==== Storing the keyfile on a file system ====<br />
<br />
A keyfile can be of arbitrary content and size. <br />
<br />
Here [[dd]] is used to generate a keyfile of 2048 random bytes, storing it in the file {{ic|/etc/mykeyfile}}:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/etc/mykeyfile iflag=fullblock<br />
<br />
If you are planning to store the keyfile on an external device, you can also simply change the outputfile to the corresponding directory:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/media/usbstick/mykeyfile iflag=fullblock<br />
<br />
To deny any access for other users than {{ic|root}}:<br />
<br />
# chmod 600 /etc/mykeyfile<br />
<br />
===== Securely overwriting stored keyfiles =====<br />
<br />
If you stored your temporary keyfile on a physical storage device, and want to delete it, remember to not just remove the keyfile later on, but use something like<br />
<br />
# shred --remove --zero mykeyfile<br />
<br />
to securely overwrite it. For overaged file systems like FAT or ext2 this will suffice while in the case of journaling file systems, flash memory hardware and other cases it is highly recommended to [[Securely wipe disk|wipe the entire device]].<br />
<br />
==== Storing the keyfile in ramfs ====<br />
<br />
Alternatively, you can mount a ramfs for storing the keyfile temporarily:<br />
<br />
# mount --mkdir -t ramfs ramfs /root/myramfs<br />
# cd /root/myramfs<br />
<br />
The advantage is that it resides in RAM and not on a physical disk, therefore it can not be recovered after unmounting the ramfs. After copying the keyfile to another secure and persistent file system, unmount the ramfs again with<br />
<br />
# umount /root/myramfs<br />
<br />
=== Configuring LUKS to make use of the keyfile ===<br />
<br />
Add a keyslot for the keyfile to the LUKS header:<br />
<br />
{{hc|# cryptsetup luksAddKey /dev/sda2 /etc/mykeyfile|<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
}}<br />
<br />
=== Manually unlocking a partition using a keyfile ===<br />
<br />
Use the {{ic|--key-file}} option when opening the LUKS device:<br />
<br />
# cryptsetup open /dev/sda2 ''dm_name'' --key-file /etc/mykeyfile<br />
<br />
=== Unlocking the root partition at boot ===<br />
<br />
This is simply a matter of configuring [[mkinitcpio]] to include the necessary modules or files and configuring the [[dm-crypt/System configuration#cryptkey|cryptkey]] [[kernel parameter]] to know where to find the keyfile.<br />
<br />
Two cases are covered below:<br />
<br />
# Using a keyfile stored on an external medium (e.g. a USB stick)<br />
# Using a keyfile embedded in the initramfs<br />
<br />
==== With a keyfile stored on an external media ====<br />
<br />
===== Configuring mkinitcpio =====<br />
<br />
You have to add the kernel module for the drive's [[file system]] to the [[mkinitcpio#MODULES|MODULES array]] in {{ic|/etc/mkinitcpio.conf}}. For example, add {{ic|ext4}} if the file system is [[Ext4]] or {{ic|vfat}} in case it is [[FAT]]:<br />
<br />
MODULES=(vfat)<br />
<br />
If there are messages about bad superblock and bad codepage at boot, then you need an extra codepage module to be loaded. For instance, you may need {{ic|nls_iso8859-1}} module for {{ic|iso8859-1}} codepage.<br />
<br />
[[Regenerate the initramfs]].<br />
<br />
===== Configuring the kernel parameters =====<br />
<br />
* For a busybox-based initramfs using the [[dm-crypt/System configuration#Using encrypt hook|encrypt]] hook, see [[dm-crypt/System configuration#cryptkey]].<br />
* For a systemd based initramfs using the [[sd-encrypt]] hook, see [[dm-crypt/System configuration#rd.luks.key]].<br />
<br />
==== With a keyfile embedded in the initramfs ====<br />
<br />
{{Warning|Use an embedded keyfile '''only''' if you protect the keyfile sufficiently by:<br />
* Using some form of authentication earlier in the boot process. Otherwise auto-decryption will occur, defeating completely the purpose of block device encryption.<br />
* {{ic|/boot}} is encrypted. Otherwise root on a different installation (including the [[Installation guide#Boot the live environment|live environment]]) can extract your key from the initramfs, and unlock the device without any other authentication.}}<br />
<br />
This method allows to use a specially named keyfile that will be embedded in the [[initramfs]] and picked up by the {{ic|encrypt}} [[Mkinitcpio#HOOKS|hook]] to unlock the root file system ({{ic|cryptdevice}}) automatically. It may be useful to apply when using the [[GRUB#Encrypted /boot|GRUB early cryptodisk]] feature, in order to avoid entering two passphrases during boot.<br />
<br />
The {{ic|encrypt}} hook lets the user specify a keyfile with the {{ic|cryptkey}} kernel parameter: in the case of initramfs, the syntax is {{ic|rootfs:''/path/to/keyfile''}}. See [[dm-crypt/System configuration#cryptkey]]. Besides, this kernel parameter defaults to use {{ic|/crypto_keyfile.bin}}, and if the initramfs contains a valid key with this name, decryption will occur automatically without the need to configure the {{ic|cryptkey}} parameter.<br />
<br />
If using {{ic|sd-encrypt}} instead of {{ic|encrypt}}, specify the location of the keyfile with the {{ic|rd.luks.key}} kernel parameter: in the case of initramfs, the syntax is {{ic|''/path/to/keyfile''}}. See [[dm-crypt/System configuration#rd.luks.key]]. This kernel parameter defaults to using {{ic|/etc/cryptsetup-keys.d/''name''.key}} (where {{ic|''name''}} is the {{ic|''dm_name''}} used for decryption in [[#Encrypting devices with cryptsetup]]) and can be omitted if initramfs contains a valid key with this path.<br />
<br />
[[#Creating a keyfile with random characters|Generate the keyfile]], give it suitable permissions and [[#Adding LUKS keys|add it as a LUKS key]]:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/crypto_keyfile.bin iflag=fullblock<br />
# chmod 600 /crypto_keyfile.bin<br />
# cryptsetup luksAddKey /dev/sdX# /crypto_keyfile.bin<br />
<br />
{{Note|The initramfs is generated by mkinitcpio with {{ic|600}} [[permissions]] by default, so regular users are not able to read the keyfile via the generated initramfs.}}<br />
<br />
Include the key in [[mkinitcpio#BINARIES and FILES|mkinitcpio's FILES array]]:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
FILES=(/crypto_keyfile.bin)<br />
}}<br />
<br />
Finally [[regenerate the initramfs]].<br />
<br />
On the next reboot you should only have to enter your container decryption passphrase once.<br />
<br />
([https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#bonus-login-once source])</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Dm-crypt/Device_encryption&diff=782875Dm-crypt/Device encryption2023-07-09T21:03:31Z<p>Leonardodag: format last edit better</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data-at-rest encryption]]<br />
[[es:Dm-crypt (Español)/Device encryption]]<br />
[[ja:Dm-crypt/デバイスの暗号化]]<br />
[[pl:Dm-crypt (Polski)/Device encryption]]<br />
[[pt:Dm-crypt (Português)/Device encryption]]<br />
[[zh-hans:Dm-crypt/Device encryption]]<br />
This section covers how to manually utilize ''dm-crypt'' from the command line to encrypt a system.<br />
<br />
== Preparation ==<br />
<br />
Before using {{pkg|cryptsetup}}, always make sure the {{ic|dm_crypt}} [[kernel module]] is loaded.<br />
<br />
== Cryptsetup usage ==<br />
<br />
''Cryptsetup'' is the command line tool to interface with ''dm-crypt'' for creating, accessing and managing encrypted devices. The tool was later expanded to support different encryption types that rely on the Linux kernel '''d'''evice-'''m'''apper and the '''crypt'''ographic modules. The most notable expansion was for the Linux Unified Key Setup (LUKS) extension, 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. Devices accessed via the device-mapper are called block devices. For further information see [[Data-at-rest encryption#Block device encryption]]. <br />
<br />
The tool is used as follows: <br />
<br />
# cryptsetup ''OPTIONS'' ''action'' ''action-specific-options'' ''device'' ''dmname''<br />
<br />
It has compiled-in defaults for the options and the encryption mode, which will be used if no others are specified on the command line. Have a look at <br />
<br />
$ cryptsetup --help <br />
<br />
which lists options, actions and the default parameters for the encryption modes in that order. A full list of options can be found on the man page.<br />
Since different parameters are required or optional, depending on encryption mode and action, the following sections point out differences further. Block device encryption is fast, but speed matters a lot too. Since changing an encryption cipher of a block device after setup is difficult, it is important to check ''dm-crypt'' performance for the individual parameters in advance: <br />
<br />
$ cryptsetup benchmark <br />
<br />
can give guidance on deciding for an algorithm and key-size prior to installation. If certain AES ciphers excel with a considerable higher throughput, these are probably the ones with hardware support in the CPU.<br />
<br />
{{Tip|You may want to practise encrypting a virtual hard drive in a [[virtual machine]] when learning.}}<br />
<br />
=== Cryptsetup passphrases and keys ===<br />
<br />
An encrypted block device is protected by a key. A key is either: <br />
<br />
* a passphrase: see [[Security#Passwords]].<br />
* a keyfile, see [[#Keyfiles]].<br />
<br />
Both key types have default maximum sizes: passphrases can be up to 512 characters and keyfiles up to 8192 KiB. <br />
<br />
An important distinction of ''LUKS'' to note at this point is that the key is used to unlock the master-key of a LUKS-encrypted device and can be changed with root access. Other encryption modes do not support changing the key after setup, because they do not employ a master-key for the encryption. See [[Data-at-rest encryption#Block device encryption]] for details.<br />
<br />
== Encryption options with dm-crypt ==<br />
<br />
''Cryptsetup'' supports different encryption operating modes to use with ''dm-crypt'': <br />
<br />
* {{ic|--type luks}} for using the default LUKS format version (LUKS1 with {{Pkg|cryptsetup}} < 2.1.0, LUKS2 with {{Pkg|cryptsetup}} ≥ 2.1.0),<br />
* {{ic|--type luks1}} for using LUKS1, the most common version of LUKS,<br />
* {{ic|--type luks2}} for using LUKS2, the latest available version of LUKS that allows additional extensions,<br />
* {{ic|--type plain}} for using dm-crypt plain mode, <br />
* {{ic|--type loopaes}} for a loopaes legacy mode, <br />
* {{ic|--type tcrypt}} for a [[TrueCrypt]] compatibility mode.<br />
* {{ic|--type bitlk}} for a [[Wikipedia:BitLocker|BitLocker]] compatibility mode. See {{man|8|cryptsetup|BITLK (WINDOWS BITLOCKER COMPATIBLE) EXTENSION}}.<br />
<br />
The basic cryptographic options for encryption cipher and hashes available can be used for all modes and rely on the kernel cryptographic backend features. All that are loaded and available to use as options at runtime can be viewed with:<br />
<br />
$ less /proc/crypto <br />
<br />
{{Tip|If the list is short, execute {{ic|$ cryptsetup benchmark}} which will trigger loading available modules.}}<br />
<br />
The following introduces encryption options for the {{ic|luks}}, {{ic|luks1}}, {{ic|luks2}} and {{ic|plain}} modes. Note that the tables list options used in the respective examples in this article and not all available ones.<br />
<br />
=== Encryption options for LUKS mode ===<br />
<br />
The ''cryptsetup'' action to set up a new dm-crypt device in LUKS encryption mode is {{ic|luksFormat}}. Unlike what the name implies, it does not format the device, but sets up the LUKS device header and encrypts the master-key with the desired cryptographic options. <br />
<br />
In order to create a new LUKS container with the compiled-in defaults listed by {{ic|cryptsetup --help}}, simply execute:<br />
<br />
# cryptsetup luksFormat ''device''<br />
<br />
As of cryptsetup 2.4.0, this is equivalent to: <br />
<br />
# cryptsetup --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase luksFormat ''device''<br />
<br />
Defaults are compared with a cryptographically higher specification example in the table below, with accompanying comments: <br />
<br />
{| class="wikitable"<br />
! Options !! Cryptsetup 2.1.0 defaults !! Example !! Comment<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --cipher<br />
-c<br />
| {{ic|aes-xts-plain64}}<br />
| {{ic|aes-xts-plain64}}<br />
| [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/v1.6.0-ReleaseNotes Release 1.6.0] changed the defaults to an AES [[Data-at-rest encryption#Ciphers and modes of operation|cipher]] in [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS]] mode (see item 5.16 [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects of the FAQ]). It is advised against using the previous default {{ic|--cipher aes-cbc-essiv}} because of its known [[wikipedia:Disk encryption theory#Cipher-block chaining (CBC)|issues]] and practical [https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ attacks] against them.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-size<br />
-s<br />
| {{ic|256}} ({{ic|512}} for XTS)<br />
| {{ic|512}}<br />
| By default a 512 bit key-size is used for XTS ciphers. Note however that [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS splits the supplied key in half]], so this results in AES-256 being used.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --hash<br />
-h<br />
| {{ic|sha256}}<br />
| {{ic|sha512}}<br />
| Hash algorithm used for [[Data-at-rest encryption#Cryptographic metadata|key derivation]]. Release 1.7.0 changed defaults from {{ic|sha1}} to {{ic|sha256}} "''not for security reasons [but] mainly to prevent compatibility problems on hardened systems where SHA1 is already [being] phased out''"[https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]. The former default of {{ic|sha1}} can still be used for compatibility with older versions of ''cryptsetup'' since it is [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects considered secure] (see item 5.20). <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --iter-time<br />
-i<br />
| {{ic|2000}}<br />
| {{ic|5000}}<br />
| Number of milliseconds to spend with PBKDF passphrase processing. Release 1.7.0 changed defaults from {{ic|1000}} to {{ic|2000}} to "''try to keep PBKDF2 iteration count still high enough and also still acceptable for users.''"[https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]. This option is only relevant for LUKS operations that set or change passphrases, such as {{ic|luksFormat}} or {{ic|luksAddKey}}. Specifying 0 as parameter selects the compiled-in default.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --use-urandom<br />
| {{ic|--use-urandom}}<br />
| {{ic|--use-random}}<br />
| Selects which [[random number generator]] to use. Note that [https://lwn.net/Articles/808575/ /dev/random blocking pool has been removed]. Therefore, {{ic|--use-random}} flag is now equivalent to {{ic|--use-urandom}}.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --verify-passphrase<br />
-y<br />
| Yes<br />
| -<br />
| Enabled by default in Arch Linux for {{ic|luksFormat}} and {{ic|luksAddKey}}.<br />
|}<br />
<br />
The properties of LUKS features and options are described in the [https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification LUKS1] (pdf) and [https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/on-disk-format-luks2.pdf LUKS2] (pdf) specifications.<br />
<br />
{{Tip|The project developers' [https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf devconfcz2016] (pdf) presentation summarizes the motivation for the major specification update to LUKS2.}}<br />
<br />
==== Iteration time ====<br />
<br />
From [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#2-setup cryptsetup FAQ§2.1] and [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#3-common-problems §3.4]:<br />
<br />
:The unlock time for a key-slot [...] is calculated when setting a passphrase. By default it is 1 second (2 seconds for LUKS2). [...]<br />
:Passphrase iteration count is based on time and hence security level depends on CPU power of the system the LUKS container is created on. [...]<br />
:If you set a passphrase on a fast machine and then unlock it on a slow machine, the unlocking time can be much longer.<br />
<br />
As such, it is better to always create a container on the machine where it will be most often accessed.<br />
<br />
Read the rest of those sections for advice on how to correctly adjust the iteration count should the need arise.<br />
<br />
==== Sector size ====<br />
<br />
See [[Advanced Format#dm-crypt]].<br />
<br />
=== Encryption options for plain mode ===<br />
<br />
In dm-crypt ''plain'' mode, there is no master-key on the device, hence, there is no need to set it up. Instead the encryption options to be employed are used directly to create the mapping between an encrypted disk and a named device. The mapping can be created against a partition or a full device. In the latter case not even a partition table is needed. <br />
<br />
{{Expansion|Using the defaults is not safe as they can change in future cryptsetup releases. [https://www.kernel.org/pub/linux/utils/cryptsetup/v2.6/v2.6.0-ReleaseNotes cryptsetup 2.6.0 changelog] says the the next release will have a backward incompatible change.}}<br />
<br />
To create a ''plain'' mode mapping with cryptsetup's default parameters: <br />
<br />
# cryptsetup ''options'' open --type plain ''device'' ''dmname''<br />
<br />
Executing it will prompt for a password, which should have very high entropy. Below a comparison of default parameters with the example in [[dm-crypt/Encrypting an entire system#Plain dm-crypt]].<br />
<br />
{| class="wikitable"<br />
! Option !! Cryptsetup 2.1.0 defaults !! Example !! Comment<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --hash<br />
-h<br />
| {{ic|ripemd160}}<br />
| -<br />
| The hash is used to create the key from the passphrase; it is not used on a keyfile. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --cipher<br />
-c<br />
| {{ic|aes-cbc-essiv:sha256}}<br />
| {{ic|aes-xts-plain64}}<br />
| The cipher consists of three parts: cipher-chainmode-IV generator. Please see [[Data-at-rest encryption#Ciphers and modes of operation]] for an explanation of these settings, and the [https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt DMCrypt documentation] for some of the options available. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-size<br />
-s<br />
|{{ic|256}}<br />
|{{ic|512}}<br />
|The key size (in bits). The size will depend on the cipher being used and also the chainmode in use. Xts mode requires twice the key size of cbc. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --size<br />
-b<br />
|real size of target disk<br />
|{{ic|2048}} (mapped device will be 512B×2048=1MiB)<br />
|Limit the maximum size of the device (in 512-byte sectors).<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --offset<br />
-o<br />
|{{ic|0}}<br />
|{{ic|0}}<br />
|The offset from the beginning of the target disk (in 512-byte sectors) from which to start the mapping.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --skip<br />
-p<br />
|{{ic|0}}<br />
|{{ic|2048}} (512B×2048=1MiB will be skipped)<br />
|The number of 512-byte sectors of encrypted data to skip at the beginning.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-file<br />
-d<br />
| default uses a passphrase<br />
| {{ic|/dev/sd''Z''}} (or e.g. {{ic|/boot/keyfile.enc}})<br />
|The device or file to be used as a key. See [[#Keyfiles]] for further details.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --keyfile-offset<br />
| {{ic|0}}<br />
| {{ic|0}}<br />
| Offset from the beginning of the file where the key starts (in bytes). This option is supported from ''cryptsetup'' 1.6.7 onwards. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --keyfile-size<br />
-l<br />
|{{ic|8192kB}}<br />
| - (default applies)<br />
| Limits the bytes read from the key file. This option is supported from ''cryptsetup'' 1.6.7 onwards. <br />
|}<br />
<br />
Using the device {{ic|/dev/sd''X''}}, the above right column example results in:<br />
<br />
# cryptsetup --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sd''Z'' --key-size=512 open --type=plain /dev/sdX enc<br />
<br />
Unlike encrypting with LUKS, the above command must be executed ''in full'' whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details. We can now check that the mapping has been made:<br />
<br />
# fdisk -l<br />
<br />
An entry should now exist for {{ic|/dev/mapper/enc}}.<br />
<br />
== Encrypting devices with cryptsetup ==<br />
<br />
This section shows how to employ the options for creating new encrypted block devices and accessing them manually. <br />
<br />
{{Warning|GRUB's support for LUKS2 is limited; see [[GRUB#Encrypted /boot]] for details. Use LUKS1 ({{ic|1=cryptsetup luksFormat --type luks1}}) for partitions that GRUB will need to unlock.}}<br />
<br />
=== Encrypting devices with LUKS mode ===<br />
<br />
==== Formatting LUKS partitions ====<br />
<br />
In order to setup a partition as an encrypted LUKS partition execute:<br />
<br />
# cryptsetup luksFormat ''device''<br />
<br />
You will then be prompted to enter a password and verify it.<br />
<br />
See [[#Encryption options for LUKS mode]] for command line options.<br />
<br />
You can check the results with:<br />
<br />
# cryptsetup luksDump ''device''<br />
<br />
You will note that the dump not only shows the cipher header information, but also the key-slots in use for the LUKS partition. <br />
<br />
The following example will create an encrypted root partition on {{ic|/dev/sda1}} using the default AES cipher in XTS mode with an effective 256-bit encryption <br />
<br />
# cryptsetup -s 512 luksFormat /dev/sda1<br />
<br />
===== Using LUKS to format partitions 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 luksFormat ''device'' ''/path/to/mykeyfile''<br />
<br />
See [[#Keyfiles]] for instructions on how to generate and manage keyfiles.<br />
<br />
==== Unlocking/Mapping LUKS partitions with the device mapper ====<br />
<br />
Once the LUKS partitions have been created, they can then be unlocked.<br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that {{ic|''device''}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/''dm_name''}} so as not to overwrite the encrypted data. To guard against accidental overwriting, read about the possibilities to [[#Backup and restore|backup the cryptheader]] after finishing setup.<br />
<br />
In order to open an encrypted LUKS partition execute:<br />
<br />
# cryptsetup open ''device'' ''dm_name''<br />
<br />
You will then be prompted for the password to unlock the partition. Usually the device mapped name is descriptive of the function of the partition that is mapped. For example the following unlocks a root luks partition {{ic|/dev/sda1}} and maps it to device mapper named {{ic|root}}:<br />
<br />
# cryptsetup open /dev/sda1 root <br />
<br />
Once opened, the root partition device address would be {{ic|/dev/mapper/root}} instead of the partition (e.g. {{ic|/dev/sda1}}). <br />
<br />
For setting up LVM ontop the encryption layer the device file for the decrypted volume group would be anything like {{ic|/dev/mapper/root}} instead of {{ic|/dev/sda1}}. LVM will then give additional names to all logical volumes created, e.g. {{ic|/dev/lvmpool/root}} and {{ic|/dev/lvmpool/swap}}.<br />
<br />
In order to write encrypted data into the partition it must be accessed through the device mapped name. The first step of access will typically be to [[create a file system]]. For example:<br />
<br />
# mkfs -t ext4 /dev/mapper/root<br />
<br />
The device {{ic|/dev/mapper/root}} can then be [[mount]]ed like any other partition.<br />
<br />
To close the LUKS container, unmount the partition and do:<br />
<br />
# cryptsetup close root<br />
<br />
==== Using a TPM to store keys ====<br />
<br />
See [[Trusted Platform Module#Data-at-rest encryption with LUKS]].<br />
<br />
=== Encrypting devices with plain mode ===<br />
<br />
The creation and subsequent access of a ''dm-crypt'' plain mode encryption both require not more than using the ''cryptsetup'' {{ic|open}} action with correct [[#Encryption options for plain mode|parameters]]. The following shows that with two examples of non-root devices, but adds a quirk by stacking both (i.e. the second is created inside the first). Obviously, stacking the encryption doubles overhead. The usecase here is simply to illustrate another example of the cipher option usage. <br />
<br />
A first mapper is created with ''cryptsetup's'' plain-mode defaults, as described in the table's left column above <br />
<br />
{{hc|# cryptsetup --type plain -v open /dev/sd''xY'' plain1|<br />
Enter passphrase: <br />
Command successful.<br />
}}<br />
<br />
Now we add the second block device inside it, using different encryption parameters and with an (optional) offset, create a file system and mount it <br />
<br />
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# lsblk -p|<br />
NAME <br />
/dev/sda <br />
├─/dev/sd''xY'' <br />
│ └─/dev/mapper/plain1 <br />
│ └─/dev/mapper/plain2 <br />
...<br />
}}<br />
<br />
# mkfs -t ext2 /dev/mapper/plain2<br />
# mount -t ext2 /dev/mapper/plain2 /mnt<br />
# echo "This is stacked. one passphrase per foot to shoot." > /mnt/stacked.txt<br />
<br />
We close the stack to check access works<br />
<br />
# cryptsetup close plain2<br />
# cryptsetup close plain1<br />
<br />
First, let us try to open the file system directly: <br />
<br />
# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/sd''xY'' plain2<br />
<br />
{{hc|# mount -t ext2 /dev/mapper/plain2 /mnt|<br />
mount: wrong fs type, bad option, bad superblock on /dev/mapper/plain2,<br />
missing codepage or helper program, or other error<br />
}}<br />
<br />
Why that did not work? Because the "plain2" starting block ({{ic|10}}) is still encrypted with the cipher from "plain1". It can only be accessed via the stacked mapper. The error is arbitrary though, trying a wrong passphrase or wrong options will yield the same. For ''dm-crypt'' plain mode, the {{ic|open}} action will not error out itself. <br />
<br />
Trying again in correct order: <br />
<br />
# cryptsetup close plain2 # dysfunctional mapper from previous try<br />
<br />
{{hc|# cryptsetup --type plain open /dev/sd''xY'' plain1|<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# mount /dev/mapper/plain2 /mnt && cat /mnt/stacked.txt|<br />
This is stacked. one passphrase per foot to shoot.<br />
}}<br />
<br />
''dm-crypt'' will handle stacked encryption with some mixed modes too. For example LUKS mode could be stacked on the "plain1" mapper. Its header would then be encrypted inside "plain1" when that is closed.<br />
<br />
Available for plain mode only is the option {{ic|--shared}}. With it a single device can be segmented into different non-overlapping mappers. We do that in the next example, using a ''loopaes'' compatible cipher mode for "plain2" this time: <br />
<br />
{{hc|# cryptsetup --type plain --offset 0 --size 1000 open /dev/sd''xY'' plain1|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|1=# cryptsetup --type plain --offset 1000 --size 1000 --shared --cipher=aes-cbc-lmk --hash=sha256 open /dev/sd''xY'' plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# lsblk -p|<br />
NAME <br />
dev/sd''xY'' <br />
├─/dev/sd''xY'' <br />
│ ├─/dev/mapper/plain1 <br />
│ └─/dev/mapper/plain2 <br />
...<br />
}}<br />
<br />
As the device tree shows both reside on the same level, i.e. are not stacked and "plain2" can be opened individually.<br />
<br />
== Cryptsetup actions specific for LUKS ==<br />
<br />
=== Key management ===<br />
<br />
It is possible to define additional keys for the LUKS partition. This enables the user to create access keys for safe backup storage In so-called key escrow, one key is used for daily usage, another kept in escrow to gain access to the partition in case the daily passphrase is forgotten or a keyfile is lost/damaged. A different key-slot could also be used to grant access to a partition to a user by issuing a second key and later revoking it again. <br />
<br />
Once an encrypted partition has been created, the initial keyslot 0 is created (if no other was specified manually). Additional keyslots are numbered from 1 to 7. Which keyslots are used can be seen by issuing <br />
<br />
# cryptsetup luksDump /dev/''device''<br />
<br />
Where {{ic|''device''}} is the block device containing the LUKS header. This and all the following commands in this section work on header backup files as well.<br />
<br />
==== Adding LUKS keys ====<br />
<br />
Adding new keyslots is accomplished with the {{ic|luksAddKey}} action. For safety it will always, even for already unlocked devices, ask for a valid existing key (a passphrase for any existing slot) before a new one may be entered:<br />
<br />
{{hc|# cryptsetup luksAddKey /dev/''device'' [''/path/to/additionalkeyfile'']|<br />
Enter any passphrase:<br />
Enter new passphrase for key slot:<br />
Verify passphrase: <br />
}}<br />
<br />
If {{ic|''/path/to/additionalkeyfile''}} is given, cryptsetup will add a new keyslot for {{ic|''additionalkeyfile''}}. Otherwise it prompts for a new passphrase. To authorize the action with an existing ''keyfile'', the {{ic|--key-file}} or {{ic|-d}} option followed by the "old" {{ic|''keyfile''}} will try to unlock all available keyfile keyslots:<br />
<br />
# cryptsetup luksAddKey /dev/''device'' [''/path/to/additionalkeyfile''] -d ''/path/to/keyfile''<br />
<br />
If it is intended to use multiple keys and change or revoke them, the {{ic|--key-slot}} or {{ic|-S}} option may be used to specify the slot: <br />
<br />
{{hc|# cryptsetup luksAddKey /dev/''device'' -S 6|<br />
Enter any passphrase: <br />
Enter new passphrase for key slot: <br />
Verify passphrase:<br />
}}<br />
<br />
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|<br />
Key Slot 6: ENABLED<br />
}}<br />
<br />
To show an associated action in this example, we decide to change the key right away: <br />
<br />
{{hc|# cryptsetup luksChangeKey /dev/''device'' -S 6|<br />
Enter LUKS passphrase to be changed: <br />
Enter new LUKS passphrase:<br />
}}<br />
<br />
before continuing to remove it.<br />
<br />
==== Removing LUKS keys ====<br />
<br />
There are three different actions to remove keys from the header: <br />
<br />
* {{ic|luksRemoveKey}} removes a key by specifying its passphrase/key-file. <br />
* {{ic|luksKillSlot}} removes a key by specifying its slot (needs another valid key). Obviously, this is extremely useful if you have forgotten a passphrase, lost a key-file, or have no access to it. <br />
* {{ic|luksErase}} removes '''all''' active keys. <br />
<br />
{{warning|<br />
* All above actions can be used to irrevocably delete the last active key for an encrypted device! <br />
* The {{ic|luksErase}} command was added in version 1.6.4 to quickly nuke access to the device. This action '''will not''' prompt for a valid passphrase! It will not [[dm-crypt/Drive preparation#Wipe LUKS header|wipe the LUKS header]], but all keyslots at once and you will, therefore, not be able to regain access unless you have a valid backup of the LUKS header.<br />
}}<br />
<br />
For above warning it is good to know the key we want to '''keep''' is valid. An easy check is to unlock the device with the {{ic|-v}} option, which will specify which slot it occupies: <br />
<br />
{{hc|# cryptsetup --test-passphrase -v open /dev/''device''|<br />
Enter passphrase for /dev/''device'': <br />
Key slot 1 unlocked.<br />
Command successful.<br />
}}<br />
<br />
Now we can remove the key added in the previous subsection using its passphrase: <br />
<br />
{{hc|# cryptsetup luksRemoveKey /dev/''device''|<br />
Enter LUKS passphrase to be deleted:<br />
}}<br />
<br />
If we had used the same passphrase for two keyslots, the first slot would be wiped now. Only executing it again would remove the second one. <br />
<br />
Alternatively, we can specify the key slot: <br />
<br />
{{hc|# cryptsetup luksKillSlot /dev/''device'' 6|<br />
Enter any remaining LUKS passphrase:<br />
}}<br />
<br />
Note that in both cases, no confirmation was required.<br />
<br />
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|<br />
Key Slot 6: DISABLED<br />
}}<br />
<br />
To re-iterate the warning above: If the same passphrase had been used for key slots 1 and 6, both would be gone now.<br />
<br />
=== Backup and restore ===<br />
<br />
If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much of a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. Damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table. Therefore, having a backup of the header and storing it on another disk might be a good idea.<br />
<br />
{{Note|If one of the LUKS-encrypted partitions' passphrases becomes compromised, you must revoke it on ''every'' copy of the cryptheader, even those you have backed up. Otherwise, a copy of the backed-up cryptheader that uses the compromised passphrase can be used to determine the master key which in turn can be used to decrypt the associated partition (even your actual partition, not only the backed-up version). On the other hand, if the master key gets compromised, you have to reencrypt your whole partition. See [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery LUKS FAQ] for further details.}}<br />
<br />
==== Backup using cryptsetup ====<br />
<br />
Cryptsetup's {{ic|luksHeaderBackup}} action stores a binary backup of the LUKS header and keyslot area:<br />
<br />
# cryptsetup luksHeaderBackup /dev/''device'' --header-backup-file ''/mnt/backup/file.img''<br />
<br />
where {{ic|''device''}} is the partition containing the LUKS volume.<br />
<br />
You can also back up the plain text header into ramfs and encrypt it with e.g. [[GPG]] before writing it to persistent storage:<br />
<br />
# mount --mkdir -t ramfs ramfs /root/''tmp''<br />
# cryptsetup luksHeaderBackup /dev/''device'' --header-backup-file /root/''tmp''/''file''.img<br />
# gpg2 --recipient ''User_ID'' --encrypt /root/''tmp''/''file''.img <br />
# cp /root/''tmp''/''file''.img.gpg /mnt/''backup''/<br />
# umount /root/''tmp''<br />
<br />
{{Warning|[[tmpfs]] can swap to the disk in low memory situations, so it is not recommended here.}}<br />
<br />
==== Restore using cryptsetup ====<br />
<br />
{{Warning|Restoring the wrong header or restoring to an unencrypted partition will cause data loss! The action can not perform a check whether the header is actually the ''correct'' one for that particular device.}} <br />
<br />
In order to evade restoring a wrong header, you can ensure it does work by using it as a remote {{ic|--header}} first: <br />
<br />
{{hc|# cryptsetup -v --header /mnt/''backup''/''file''.img open /dev/''device'' test|<br />
Key slot 0 unlocked.<br />
Command successful.<br />
}}<br />
<br />
# mount /dev/mapper/test /mnt/test && ls /mnt/test <br />
# umount /mnt/test <br />
# cryptsetup close test <br />
<br />
Now that the check succeeded, the restore may be performed: <br />
<br />
# cryptsetup luksHeaderRestore /dev/''device'' --header-backup-file ./mnt/''backup''/''file''.img<br />
<br />
Now that all the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing the command.<br />
<br />
==== Manual backup and restore ====<br />
<br />
The header always resides at the beginning of the device and a backup can be performed without access to ''cryptsetup'' as well. First you have to find out the payload offset of the crypted partition:<br />
<br />
{{hc|# cryptsetup luksDump /dev/''device'' {{!}} grep "Payload offset"|<br />
Payload offset: 4040<br />
}}<br />
<br />
Second check the sector size of the drive<br />
<br />
{{hc|# fdisk -l /dev/''device'' {{!}} grep "Sector size"|<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
}}<br />
<br />
Now that you know the values, you can backup the header with a simple [[dd]] command:<br />
<br />
# dd if=/dev/''device'' of=/path/to/''file''.img bs=512 count=4040<br />
<br />
and store it safely.<br />
<br />
A restore can then be performed using the same values as when backing up:<br />
<br />
# dd if=./''file''.img of=/dev/''device'' bs=512 count=4040<br />
<br />
=== Re-encrypting devices ===<br />
<br />
{{Expansion|cryptsetup 2.2 using LUKS2 (with a 16 MiB header) supports online encryption/decryption/reencryption.[https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.2/v2.2.0-ReleaseNotes]}}<br />
<br />
{{Out of date|cryptsetup-reencrypt was removed in cryptsetup 2.5.0.[https://www.kernel.org/pub/linux/utils/cryptsetup/v2.5/v2.5.0-ReleaseNotes]}}<br />
<br />
The {{Pkg|cryptsetup}} package features two options for re-encryption.<br />
<br />
; cryptsetup reencrypt: Argument to {{ic|cryptsetup}} itself: Preferred method. Currently LUKS2 devices only. Actions can be performed online. Supports multiple parallel re-encryption jobs. Resilient to system failures. See {{man|8|cryptsetup}} for more information.<br />
<br />
; cryptsetup-reencrypt: Legacy tool, supports LUKS1 in addition to LUKS2. Actions can be performed on unmounted devices only. Single process at a time. Sensitive to system failures. See {{man|8|cryptsetup-reencrypt}} for more information. <br />
<br />
Both can be used to convert an existing unencrypted file system to a LUKS encrypted one or permanently remove LUKS encryption from a device (using {{ic|--decrypt}}). As its name suggests it can also be used to re-encrypt an existing LUKS encrypted device, though, re-encryption is not possible for a detached LUKS header or other encryption modes (e.g. plain-mode). For re-encryption it is possible to change the [[#Encryption options for LUKS mode]]. <br />
<br />
One application of re-encryption may be to secure the data again after a passphrase or [[#Keyfiles|keyfile]] has been compromised ''and'' one cannot be certain that no copy of the LUKS header has been obtained. For example, if only a passphrase has been shoulder-surfed but no physical/logical access to the device happened, it would be enough to change the respective passphrase/key only ([[#Key management]]). <br />
<br />
{{Warning|Always make sure a '''reliable backup''' is available and double-check options you specify before using the tool!}}<br />
<br />
The following shows an example to encrypt an unencrypted file system partition and a re-encryption of an existing LUKS device.<br />
<br />
==== Encrypt an existing unencrypted file system ====<br />
<br />
{{Tip|If you are trying to encrypt an existing root partition, you might want to create a separate and unencrypted boot partition which will be mounted to {{ic|/boot}} (see [[Dm-crypt/Encrypting an entire system#Preparing the boot partition]]). It is not strictly necessary but has a number of advantages:<br />
<br />
* If {{ic|/boot}} is located inside an encrypted root partition, the system will ask for the passphrase twice when the machine is powered on. The first time will happen when the boot loader attempts to read the files located inside encrypted {{ic|/boot}}, the second time will be when the kernel tries to mount the encrypted partition [https://opencraft.com/blog/tutorial-encrypting-an-existing-root-partition-in-ubuntu-with-dm-crypt-and-luks/]. This might not be the desired behaviour and can be prevented by having a separate and unencryted boot partition.<br />
* Some system restore applications (e.g., {{AUR|timeshift}}) will not work if {{ic|/boot}} is located inside an encryted partition [https://github.com/teejee2008/timeshift/issues/280].<br />
<br />
In short, create a partition with the size of at least 260 MiB if needed. See [[Partitioning#/boot]].}}<br />
<br />
A LUKS encryption header is always stored at the beginning of the device. Since an existing file system will usually be allocated all partition sectors, the first step is to shrink it to make space for the LUKS header.<br />
<br />
{{Expansion|cryptsetup man pages suggest using twice the LUKS2 header size. That implies 32 MiB and using {{ic|--reduce-device-size 32M}}}}<br />
<br />
The [[#Encryption options for LUKS mode|default]] LUKS2 header requires 16 MiB. If the current file system occupies all the available space, we will have to shrink it at least that much. To shrink an existing {{ic|ext4}} file system on {{ic|/dev/sd''xY''}} to its current possible minimum:<br />
<br />
# umount /mnt<br />
<br />
{{hc|# e2fsck -f /dev/sd''xY''|<br />
e2fsck 1.46.5 (30-Dec-2021)<br />
Pass 1: Checking inodes, blocks, and sizes<br />
...<br />
/dev/sda6: 12/166320 files (0.0% non-contiguous), 28783/665062 blocks<br />
}}<br />
<br />
{{hc|# resize2fs -p -M /dev/sd''xY''|<br />
e2fsck 1.46.5 (30-Dec-2021)<br />
Resizing the filesystem on /dev/sd''xY'' to 26347 (4k) blocks.<br />
The filesystem on /dev/sd''xY'' is now 26347 (4k) blocks long.<br />
}}<br />
<br />
{{Tip|Shrinking to the minimum size with {{ic|-M}} might take very long. You might want to calculate a size just 32 MiB smaller than the current size instead of using {{ic|-M}}.}}<br />
<br />
{{Warning|The file system should be shrunk while the underlying device (e.g., a partition) should be kept at its original size. Some graphical tools (e.g., [[GParted]]) may resize both the file system and the partition, and data loss may occur after encryption.}}<br />
<br />
Now we encrypt it, using the default cipher we do not have to specify it explicitly:<br />
<br />
{{hc|# cryptsetup reencrypt --encrypt --reduce-device-size 16M /dev/sd''xY''|<nowiki><br />
<br />
WARNING!<br />
<br />
========<br />
<br />
This will overwrite data on LUKS2-temp-12345678-9012-3456-7890-123456789012.new irrevocably.<br />
<br />
Are you sure? (Type 'yes' in capital letters): YES<br />
Enter passphrase for LUKS2-temp-12345678-9012-3456-7890-123456789012.new: <br />
Verify passphrase: <br />
</nowiki>}}<br />
<br />
After it finished, the whole {{ic|/dev/sd''xY''}} partition is encrypted, not only the space the file system was shrunk to. As a final step we extend the original {{ic|ext4}} file system to occupy all available space again, on the now encrypted partition:<br />
<br />
{{hc|# cryptsetup open /dev/sd''xY'' recrypt|<br />
Enter passphrase for /dev/sd''xY'': <br />
...<br />
}}<br />
<br />
{{hc|# resize2fs /dev/mapper/recrypt|<br />
resize2fs 1.43-WIP (18-May-2015)<br />
Resizing the filesystem on /dev/mapper/recrypt to 664807 (4k) blocks.<br />
The filesystem on /dev/mapper/recrypt is now 664807 (4k) blocks long.<br />
}}<br />
<br />
# mount /dev/mapper/recrypt /mnt<br />
<br />
The file system is now ready to use. You may want to add it to your [[crypttab]].<br />
<br />
{{Tip|If you have just encrypted your root partition, you might need to perform a number of post-encryption adjustments.<br />
<br />
1. Configure mkinitcpio - see [[Dm-crypt/Encrypting an entire system#Configuring mkinitcpio]].<br />
<br />
2. Configure the boot loader - see [[Dm-crypt/Encrypting an entire system#Configuring the boot loader]] and [[Dm-crypt/Encrypting an entire system#Configuring GRUB]].<br />
<br />
3. Configure fstab and crypttab - see [[Dm-crypt/Encrypting an entire system#Configuring fstab and crypttab]].<br />
}}<br />
<br />
==== Re-encrypting an existing LUKS partition ====<br />
<br />
In this example an existing LUKS device is re-encrypted. <br />
<br />
{{Warning|Double-check you specify encryption options for correctly and ''never'' re-encrypt without a '''reliable backup'''!}}<br />
<br />
In order to re-encrypt a device with its existing encryption options, they do not need to be specified:<br />
{{bc|# cryptsetup reencrypt /dev/sd''xY''}}<br />
{{Note|For LUKS1 we will need to use the legacy tool:{{bc|# cryptsetup-reencrypt /dev/sd''xY''}}}}<br />
<br />
Existing keys are retained when re-encrypting a device with a different cipher and/or hash. Another use case is to re-encrypt LUKS devices which have non-current encryption options. Apart from above warning on specifying options correctly, the ability to change the LUKS header may also be limited by its size. For example, if the device was initially encrypted using a CBC mode cipher and 128 bit key-size, the LUKS header will be half the size of above mentioned {{ic|4096}} sectors: <br />
<br />
{{hc|# cryptsetup luksDump /dev/sd''xY'' {{!}} grep -e "mode" -e "Payload" -e "MK bits"|<br />
Cipher mode: cbc-essiv:sha256<br />
Payload offset: '''2048'''<br />
MK bits: 128<br />
}}<br />
<br />
While it is possible to upgrade the encryption of such a device, it is currently only feasible in two steps. First, re-encrypting with the same encryption options, but using the {{ic|--reduce-device-size}} option to make further space for the larger LUKS header. Second, re-encypt the whole device again with the desired cipher. For this reason and the fact that a backup should be created in any case, creating a new, fresh encrypted device to restore into is always the faster option.<br />
<br />
=== Conversion from LUKS1 to LUKS2 and back ===<br />
<br />
The {{Pkg|cryptsetup}} package has {{ic|convert}} option that needed for conversion between LUKS1 and LUKS2 container types. The argument {{ic|--type}} is '''required'''.<br />
<br />
Migration from LUKS1 to LUKS2:<br />
<br />
# cryptsetup convert --type luks2 /dev/sd''xY''<br />
<br />
{{Note|The LUKS header size will be 16 MiB instead of 2 MiB.}}<br />
<br />
Rollback to LUKS1 (for example, to boot from [[GRUB#Encrypted /boot|GRUB with encrypted /boot]]):<br />
<br />
# cryptsetup convert --type luks1 /dev/sd''xY''<br />
<br />
{{Note|Conversion from LUKS2 to LUKS1 is '''not''' always possible. You may get the following error:<br />
Cannot convert to LUKS1 format - keyslot 0 is not LUKS1 compatible.<br />
If the container is using Argon2, it needs to be converted to PBKDF2 to be LUKS1-compatible.<br />
# cryptsetup luksConvertKey --pbkdf pbkdf2 /dev/sd''xY''<br />
}}<br />
<br />
== Resizing encrypted devices ==<br />
<br />
{{Expansion|This section should be rewritten to introduce resizing more generically. Perhaps work on it together with [[Resizing LVM-on-LUKS]].}}<br />
<br />
If a storage device encrypted with dm-crypt is being cloned (with a tool like dd) to another larger device, the underlying dm-crypt device must be resized to use the whole space. <br />
<br />
The destination device is /dev/sdX2 in this example, the whole available space adjacent to the partition will be used:<br />
<br />
# cryptsetup luksOpen /dev/sdX2 sdX2<br />
# cryptsetup resize sdX2<br />
<br />
Then the underlying file system must be resized.<br />
<br />
=== Loopback file system ===<br />
<br />
Assume that an encrypted loopback file system is stored in a file {{ic|/bigsecret}}, looped to {{ic|/dev/loop0}}, mapped to {{ic|secret}} and mounted on {{ic|/mnt/secret}}, as in the example at [[dm-crypt/Encrypting a non-root file system#File container]].<br />
<br />
If the container file is currently mapped and/or mounted, unmount and/or close it:<br />
<br />
# umount /mnt/secret<br />
# cryptsetup close secret<br />
# losetup -d /dev/loop0<br />
<br />
Next, expand the container file with the size of the data you want to add. In this example, the file will be expanded with 1M * 1024, which is 1G.<br />
<br />
{{Warning|Make absolutely sure to use '''two''' {{ic|>}}, instead of just one, or else you will overwrite the file instead of appending to it. Making a backup before this step is strongly recommended.}}<br />
<br />
# dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Now map the container to the loop device:<br />
<br />
# losetup /dev/loop0 /bigsecret<br />
# cryptsetup open /dev/loop0 secret<br />
<br />
After this, resize the encrypted part of the container to the new maximum size of the container file:<br />
<br />
# cryptsetup resize secret<br />
<br />
Finally, perform a file system check and, if it is ok, resize it (example for ext2/3/4):<br />
<br />
# e2fsck -f /dev/mapper/secret<br />
# resize2fs /dev/mapper/secret<br />
<br />
You can now mount the container again:<br />
<br />
# mount /dev/mapper/secret /mnt/secret<br />
<br />
=== Integrity protected device ===<br />
<br />
If the device was formatted with integrity support (e.g., {{ic|--integrity hmac-sha256}}) and the backing block device is shrinked, it cannot be opened with this error: {{ic|device-mapper: reload ioctl on failed: Invalid argument}}.<br />
<br />
To fix this issue without wiping the device again, it can be formatted with the previous master key (keeping the per-sector tags valid).<br />
<br />
# cryptsetup luksDump /dev/sdX2 --dump-master-key --master-key-file=/tmp/masterkey-in-tmpfs.key<br />
# cryptsetup luksFormat /dev/sdX2 --type luks2 --integrity hmac-sha256 --master-key-file=/tmp/masterkey-in-tmpfs.key --integrity-no-wipe<br />
# rm /tmp/masterkey-in-tmpfs.key<br />
<br />
== Keyfiles ==<br />
<br />
{{Note|This section describes using a plaintext keyfile. If you want to encrypt your keyfile giving you two factor authentication see [[dm-crypt/Specialties#Using GPG, LUKS, or OpenSSL Encrypted Keyfiles|Using GPG or OpenSSL Encrypted Keyfiles]] for details, but please still read this section.}}<br />
<br />
'''What is a keyfile?'''<br />
<br />
A keyfile is a file whose data is used as the passphrase to unlock an encrypted volume.<br />
That means if such a file is lost or changed, decrypting the volume may 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 keyfiles. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
=== Types of keyfiles ===<br />
<br />
==== passphrase ====<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 />
Example: {{ic|1234}}<br />
<br />
{{Note|The keyfile containing the passphrase must not have a newline in it. One option is to create it using <br />
<br />
# echo -n 'your_passphrase' > ''/path/to/keyfile''<br />
# chown root:root ''/path/to/keyfile''; chmod 400 ''/path/to/keyfile''<br />
<br />
If the file contains special characters such as a backslash, rather than escaping these, it is recommended to simply edit the key file directly entering or pasting the passphrase and then remove the trailing newline with a handy perl one-liner:<br />
<br />
# perl -pi -e 'chomp if eof' ''/path/to/keyfile''<br />
}}<br />
<br />
==== randomtext ====<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 />
Example: {{ic|fjqweifj830149-57 819y4my1-38t1934yt8-91m 34co3;t8y;9p3y-}}<br />
<br />
==== binary ====<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 random text file. However this is controversial and has never been exploited publicly.<br />
<br />
Example: images, text, video, ...<br />
<br />
=== Creating a keyfile with random characters ===<br />
<br />
==== Storing the keyfile on a file system ====<br />
<br />
A keyfile can be of arbitrary content and size. <br />
<br />
Here [[dd]] is used to generate a keyfile of 2048 random bytes, storing it in the file {{ic|/etc/mykeyfile}}:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/etc/mykeyfile iflag=fullblock<br />
<br />
If you are planning to store the keyfile on an external device, you can also simply change the outputfile to the corresponding directory:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/media/usbstick/mykeyfile iflag=fullblock<br />
<br />
To deny any access for other users than {{ic|root}}:<br />
<br />
# chmod 600 /etc/mykeyfile<br />
<br />
===== Securely overwriting stored keyfiles =====<br />
<br />
If you stored your temporary keyfile on a physical storage device, and want to delete it, remember to not just remove the keyfile later on, but use something like<br />
<br />
# shred --remove --zero mykeyfile<br />
<br />
to securely overwrite it. For overaged file systems like FAT or ext2 this will suffice while in the case of journaling file systems, flash memory hardware and other cases it is highly recommended to [[Securely wipe disk|wipe the entire device]].<br />
<br />
==== Storing the keyfile in ramfs ====<br />
<br />
Alternatively, you can mount a ramfs for storing the keyfile temporarily:<br />
<br />
# mount --mkdir -t ramfs ramfs /root/myramfs<br />
# cd /root/myramfs<br />
<br />
The advantage is that it resides in RAM and not on a physical disk, therefore it can not be recovered after unmounting the ramfs. After copying the keyfile to another secure and persistent file system, unmount the ramfs again with<br />
<br />
# umount /root/myramfs<br />
<br />
=== Configuring LUKS to make use of the keyfile ===<br />
<br />
Add a keyslot for the keyfile to the LUKS header:<br />
<br />
{{hc|# cryptsetup luksAddKey /dev/sda2 /etc/mykeyfile|<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
}}<br />
<br />
=== Manually unlocking a partition using a keyfile ===<br />
<br />
Use the {{ic|--key-file}} option when opening the LUKS device:<br />
<br />
# cryptsetup open /dev/sda2 ''dm_name'' --key-file /etc/mykeyfile<br />
<br />
=== Unlocking the root partition at boot ===<br />
<br />
This is simply a matter of configuring [[mkinitcpio]] to include the necessary modules or files and configuring the [[dm-crypt/System configuration#cryptkey|cryptkey]] [[kernel parameter]] to know where to find the keyfile.<br />
<br />
Two cases are covered below:<br />
<br />
# Using a keyfile stored on an external medium (e.g. a USB stick)<br />
# Using a keyfile embedded in the initramfs<br />
<br />
==== With a keyfile stored on an external media ====<br />
<br />
===== Configuring mkinitcpio =====<br />
<br />
You have to add the kernel module for the drive's [[file system]] to the [[mkinitcpio#MODULES|MODULES array]] in {{ic|/etc/mkinitcpio.conf}}. For example, add {{ic|ext4}} if the file system is [[Ext4]] or {{ic|vfat}} in case it is [[FAT]]:<br />
<br />
MODULES=(vfat)<br />
<br />
If there are messages about bad superblock and bad codepage at boot, then you need an extra codepage module to be loaded. For instance, you may need {{ic|nls_iso8859-1}} module for {{ic|iso8859-1}} codepage.<br />
<br />
[[Regenerate the initramfs]].<br />
<br />
===== Configuring the kernel parameters =====<br />
<br />
* For a busybox-based initramfs using the [[dm-crypt/System configuration#Using encrypt hook|encrypt]] hook, see [[dm-crypt/System configuration#cryptkey]].<br />
* For a systemd based initramfs using the [[sd-encrypt]] hook, see [[dm-crypt/System configuration#rd.luks.key]].<br />
<br />
==== With a keyfile embedded in the initramfs ====<br />
<br />
{{Warning|Use an embedded keyfile '''only''' if you protect the keyfile sufficiently by:<br />
* Using some form of authentication earlier in the boot process. Otherwise auto-decryption will occur, defeating completely the purpose of block device encryption.<br />
* {{ic|/boot}} is encrypted. Otherwise root on a different installation (including the [[Installation guide#Boot the live environment|live environment]]) can extract your key from the initramfs, and unlock the device without any other authentication.}}<br />
<br />
This method allows to use a specially named keyfile that will be embedded in the [[initramfs]] and picked up by the {{ic|encrypt}} [[Mkinitcpio#HOOKS|hook]] to unlock the root file system ({{ic|cryptdevice}}) automatically. It may be useful to apply when using the [[GRUB#Encrypted /boot|GRUB early cryptodisk]] feature, in order to avoid entering two passphrases during boot.<br />
<br />
The {{ic|encrypt}} hook lets the user specify a keyfile with the {{ic|cryptkey}} kernel parameter: in the case of initramfs, the syntax is {{ic|rootfs:''/path/to/keyfile''}}. See [[dm-crypt/System configuration#cryptkey]]. Besides, this kernel parameter defaults to use {{ic|/crypto_keyfile.bin}}, and if the initramfs contains a valid key with this name, decryption will occur automatically without the need to configure the {{ic|cryptkey}} parameter.<br />
<br />
If using {{ic|sd-encrypt}} instead of {{ic|encrypt}}, specify the location of the keyfile with the {{ic|rd.luks.key}} kernel parameter: in the case of initramfs, the syntax is {{ic|''/path/to/keyfile''}}. See [[dm-crypt/System configuration#rd.luks.key]]. This kernel parameter defaults to using {{ic|/etc/cryptsetup-keys.d/''name''.key}} (where {{ic|''name''}} is the {{ic|''dm_name''}} used for decryption in [[#Encrypting devices with cryptsetup]]) and can be omitted if initramfs contains a valid key with this path.<br />
<br />
[[#Creating a keyfile with random characters|Generate the keyfile]], give it suitable permissions and [[#Adding LUKS keys|add it as a LUKS key]]:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/crypto_keyfile.bin iflag=fullblock<br />
# chmod 600 /crypto_keyfile.bin<br />
# cryptsetup luksAddKey /dev/sdX# /crypto_keyfile.bin<br />
<br />
{{Note|The initramfs is generated by mkinitcpio with {{ic|600}} [[permissions]] by default, so regular users are not able to read the keyfile via the generated initramfs.}}<br />
<br />
Include the key in [[mkinitcpio#BINARIES and FILES|mkinitcpio's FILES array]]:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
FILES=(/crypto_keyfile.bin)<br />
}}<br />
<br />
Finally [[regenerate the initramfs]].<br />
<br />
On the next reboot you should only have to enter your container decryption passphrase once.<br />
<br />
([https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#bonus-login-once source])</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Dm-crypt/Device_encryption&diff=781446Dm-crypt/Device encryption2023-06-18T20:10:19Z<p>Leonardodag: /* Encryption options for LUKS mode */ --iter-time applies to any PBKDF function in use; not just PBKDF2. This is the same text as in the man page.</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data-at-rest encryption]]<br />
[[es:Dm-crypt (Español)/Device encryption]]<br />
[[ja:Dm-crypt/デバイスの暗号化]]<br />
[[pl:Dm-crypt (Polski)/Device encryption]]<br />
[[pt:Dm-crypt (Português)/Device encryption]]<br />
[[zh-hans:Dm-crypt/Device encryption]]<br />
This section covers how to manually utilize ''dm-crypt'' from the command line to encrypt a system.<br />
<br />
== Preparation ==<br />
<br />
Before using {{pkg|cryptsetup}}, always make sure the {{ic|dm_crypt}} [[kernel module]] is loaded.<br />
<br />
== Cryptsetup usage ==<br />
<br />
''Cryptsetup'' is the command line tool to interface with ''dm-crypt'' for creating, accessing and managing encrypted devices. The tool was later expanded to support different encryption types that rely on the Linux kernel '''d'''evice-'''m'''apper and the '''crypt'''ographic modules. The most notable expansion was for the Linux Unified Key Setup (LUKS) extension, 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. Devices accessed via the device-mapper are called block devices. For further information see [[Data-at-rest encryption#Block device encryption]]. <br />
<br />
The tool is used as follows: <br />
<br />
# cryptsetup ''OPTIONS'' ''action'' ''action-specific-options'' ''device'' ''dmname''<br />
<br />
It has compiled-in defaults for the options and the encryption mode, which will be used if no others are specified on the command line. Have a look at <br />
<br />
$ cryptsetup --help <br />
<br />
which lists options, actions and the default parameters for the encryption modes in that order. A full list of options can be found on the man page.<br />
Since different parameters are required or optional, depending on encryption mode and action, the following sections point out differences further. Block device encryption is fast, but speed matters a lot too. Since changing an encryption cipher of a block device after setup is difficult, it is important to check ''dm-crypt'' performance for the individual parameters in advance: <br />
<br />
$ cryptsetup benchmark <br />
<br />
can give guidance on deciding for an algorithm and key-size prior to installation. If certain AES ciphers excel with a considerable higher throughput, these are probably the ones with hardware support in the CPU.<br />
<br />
{{Tip|You may want to practise encrypting a virtual hard drive in a [[virtual machine]] when learning.}}<br />
<br />
=== Cryptsetup passphrases and keys ===<br />
<br />
An encrypted block device is protected by a key. A key is either: <br />
<br />
* a passphrase: see [[Security#Passwords]].<br />
* a keyfile, see [[#Keyfiles]].<br />
<br />
Both key types have default maximum sizes: passphrases can be up to 512 characters and keyfiles up to 8192 KiB. <br />
<br />
An important distinction of ''LUKS'' to note at this point is that the key is used to unlock the master-key of a LUKS-encrypted device and can be changed with root access. Other encryption modes do not support changing the key after setup, because they do not employ a master-key for the encryption. See [[Data-at-rest encryption#Block device encryption]] for details.<br />
<br />
== Encryption options with dm-crypt ==<br />
<br />
''Cryptsetup'' supports different encryption operating modes to use with ''dm-crypt'': <br />
<br />
* {{ic|--type luks}} for using the default LUKS format version (LUKS1 with {{Pkg|cryptsetup}} < 2.1.0, LUKS2 with {{Pkg|cryptsetup}} ≥ 2.1.0),<br />
* {{ic|--type luks1}} for using LUKS1, the most common version of LUKS,<br />
* {{ic|--type luks2}} for using LUKS2, the latest available version of LUKS that allows additional extensions,<br />
* {{ic|--type plain}} for using dm-crypt plain mode, <br />
* {{ic|--type loopaes}} for a loopaes legacy mode, <br />
* {{ic|--type tcrypt}} for a [[TrueCrypt]] compatibility mode.<br />
* {{ic|--type bitlk}} for a [[Wikipedia:BitLocker|BitLocker]] compatibility mode. See {{man|8|cryptsetup|BITLK (WINDOWS BITLOCKER COMPATIBLE) EXTENSION}}.<br />
<br />
The basic cryptographic options for encryption cipher and hashes available can be used for all modes and rely on the kernel cryptographic backend features. All that are loaded and available to use as options at runtime can be viewed with:<br />
<br />
$ less /proc/crypto <br />
<br />
{{Tip|If the list is short, execute {{ic|$ cryptsetup benchmark}} which will trigger loading available modules.}}<br />
<br />
The following introduces encryption options for the {{ic|luks}}, {{ic|luks1}}, {{ic|luks2}} and {{ic|plain}} modes. Note that the tables list options used in the respective examples in this article and not all available ones.<br />
<br />
=== Encryption options for LUKS mode ===<br />
<br />
The ''cryptsetup'' action to set up a new dm-crypt device in LUKS encryption mode is {{ic|luksFormat}}. Unlike what the name implies, it does not format the device, but sets up the LUKS device header and encrypts the master-key with the desired cryptographic options. <br />
<br />
In order to create a new LUKS container with the compiled-in defaults listed by {{ic|cryptsetup --help}}, simply execute:<br />
<br />
# cryptsetup luksFormat ''device''<br />
<br />
As of cryptsetup 2.4.0, this is equivalent to: <br />
<br />
# cryptsetup --type luks2 --cipher aes-xts-plain64 --hash sha256 --iter-time 2000 --key-size 256 --pbkdf argon2id --use-urandom --verify-passphrase luksFormat ''device''<br />
<br />
Defaults are compared with a cryptographically higher specification example in the table below, with accompanying comments: <br />
<br />
{| class="wikitable"<br />
! Options !! Cryptsetup 2.1.0 defaults !! Example !! Comment<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --cipher<br />
-c<br />
| {{ic|aes-xts-plain64}}<br />
| {{ic|aes-xts-plain64}}<br />
| [https://www.kernel.org/pub/linux/utils/cryptsetup/v1.6/v1.6.0-ReleaseNotes Release 1.6.0] changed the defaults to an AES [[Data-at-rest encryption#Ciphers and modes of operation|cipher]] in [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS]] mode (see item 5.16 [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects of the FAQ]). It is advised against using the previous default {{ic|--cipher aes-cbc-essiv}} because of its known [[wikipedia:Disk encryption theory#Cipher-block chaining (CBC)|issues]] and practical [https://www.jakoblell.com/blog/2013/12/22/practical-malleability-attack-against-cbc-encrypted-luks-partitions/ attacks] against them.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-size<br />
-s<br />
| {{ic|256}} ({{ic|512}} for XTS)<br />
| {{ic|512}}<br />
| By default a 512 bit key-size is used for XTS ciphers. Note however that [[wikipedia:Disk encryption theory#XEX-based tweaked-codebook mode with ciphertext stealing (XTS)|XTS splits the supplied key in half]], so this results in AES-256 being used.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --hash<br />
-h<br />
| {{ic|sha256}}<br />
| {{ic|sha512}}<br />
| Hash algorithm used for [[Data-at-rest encryption#Cryptographic metadata|key derivation]]. Release 1.7.0 changed defaults from {{ic|sha1}} to {{ic|sha256}} "''not for security reasons [but] mainly to prevent compatibility problems on hardened systems where SHA1 is already [being] phased out''"[https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]. The former default of {{ic|sha1}} can still be used for compatibility with older versions of ''cryptsetup'' since it is [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#5-security-aspects considered secure] (see item 5.20). <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --iter-time<br />
-i<br />
| {{ic|2000}}<br />
| {{ic|5000}}<br />
| Number of milliseconds to spend with PBKDF passphrase processing. Release 1.7.0 changed defaults from {{ic|1000}} to {{ic|2000}} to "''try to keep PBKDF2 iteration count still high enough and also still acceptable for users.''"[https://www.kernel.org/pub/linux/utils/cryptsetup/v1.7/v1.7.0-ReleaseNotes]. This option is only relevant for LUKS operations that set or change passphrases, such as {{ic|luksFormat}} or {{ic|luksAddKey}}. Specifying 0 as parameter selects the compiled-in default.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --use-urandom<br />
| {{ic|--use-urandom}}<br />
| {{ic|--use-random}}<br />
| Selects which [[random number generator]] to use. Note that [https://lwn.net/Articles/808575/ /dev/random blocking pool has been removed]. Therefore, {{ic|--use-random}} flag is now equivalent to {{ic|--use-urandom}}.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --verify-passphrase<br />
-y<br />
| Yes<br />
| -<br />
| Enabled by default in Arch Linux for {{ic|luksFormat}} and {{ic|luksAddKey}}.<br />
|}<br />
<br />
The properties of LUKS features and options are described in the [https://gitlab.com/cryptsetup/cryptsetup/wikis/Specification LUKS1] (pdf) and [https://gitlab.com/cryptsetup/cryptsetup/blob/master/docs/on-disk-format-luks2.pdf LUKS2] (pdf) specifications.<br />
<br />
{{Tip|The project developers' [https://mbroz.fedorapeople.org/talks/DevConf2016/devconf2016-luks2.pdf devconfcz2016] (pdf) presentation summarizes the motivation for the major specification update to LUKS2.}}<br />
<br />
==== Iteration time ====<br />
<br />
From [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#2-setup cryptsetup FAQ§2.1] and [https://gitlab.com/cryptsetup/cryptsetup/-/wikis/FrequentlyAskedQuestions#3-common-problems §3.4]:<br />
<br />
:The unlock time for a key-slot [...] is calculated when setting a passphrase. By default it is 1 second (2 seconds for LUKS2). [...]<br />
:Passphrase iteration count is based on time and hence security level depends on CPU power of the system the LUKS container is created on. [...]<br />
:If you set a passphrase on a fast machine and then unlock it on a slow machine, the unlocking time can be much longer.<br />
<br />
As such, it is better to always create a container on the machine where it will be most often accessed.<br />
<br />
Read the rest of those sections for advice on how to correctly adjust the iteration count should the need arise.<br />
<br />
==== Sector size ====<br />
<br />
See [[Advanced Format#dm-crypt]].<br />
<br />
=== Encryption options for plain mode ===<br />
<br />
In dm-crypt ''plain'' mode, there is no master-key on the device, hence, there is no need to set it up. Instead the encryption options to be employed are used directly to create the mapping between an encrypted disk and a named device. The mapping can be created against a partition or a full device. In the latter case not even a partition table is needed. <br />
<br />
{{Expansion|Using the defaults is not safe as they can change in future cryptsetup releases. [https://www.kernel.org/pub/linux/utils/cryptsetup/v2.6/v2.6.0-ReleaseNotes cryptsetup 2.6.0 changelog] says the the next release will have a backward incompatible change.}}<br />
<br />
To create a ''plain'' mode mapping with cryptsetup's default parameters: <br />
<br />
# cryptsetup ''options'' open --type plain ''device'' ''dmname''<br />
<br />
Executing it will prompt for a password, which should have very high entropy. Below a comparison of default parameters with the example in [[dm-crypt/Encrypting an entire system#Plain dm-crypt]].<br />
<br />
{| class="wikitable"<br />
! Option !! Cryptsetup 2.1.0 defaults !! Example !! Comment<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --hash<br />
-h<br />
| {{ic|ripemd160}}<br />
| -<br />
| The hash is used to create the key from the passphrase; it is not used on a keyfile. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --cipher<br />
-c<br />
| {{ic|aes-cbc-essiv:sha256}}<br />
| {{ic|aes-xts-plain64}}<br />
| The cipher consists of three parts: cipher-chainmode-IV generator. Please see [[Data-at-rest encryption#Ciphers and modes of operation]] for an explanation of these settings, and the [https://gitlab.com/cryptsetup/cryptsetup/wikis/DMCrypt DMCrypt documentation] for some of the options available. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-size<br />
-s<br />
|{{ic|256}}<br />
|{{ic|512}}<br />
|The key size (in bits). The size will depend on the cipher being used and also the chainmode in use. Xts mode requires twice the key size of cbc. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --size<br />
-b<br />
|real size of target disk<br />
|{{ic|2048}} (mapped device will be 512B×2048=1MiB)<br />
|Limit the maximum size of the device (in 512-byte sectors).<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --offset<br />
-o<br />
|{{ic|0}}<br />
|{{ic|0}}<br />
|The offset from the beginning of the target disk (in 512-byte sectors) from which to start the mapping.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --skip<br />
-p<br />
|{{ic|0}}<br />
|{{ic|2048}} (512B×2048=1MiB will be skipped)<br />
|The number of 512-byte sectors of encrypted data to skip at the beginning.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --key-file<br />
-d<br />
| default uses a passphrase<br />
| {{ic|/dev/sd''Z''}} (or e.g. {{ic|/boot/keyfile.enc}})<br />
|The device or file to be used as a key. See [[#Keyfiles]] for further details.<br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --keyfile-offset<br />
| {{ic|0}}<br />
| {{ic|0}}<br />
| Offset from the beginning of the file where the key starts (in bytes). This option is supported from ''cryptsetup'' 1.6.7 onwards. <br />
|-<br />
! style="text-align:right;white-space:nowrap;" | --keyfile-size<br />
-l<br />
|{{ic|8192kB}}<br />
| - (default applies)<br />
| Limits the bytes read from the key file. This option is supported from ''cryptsetup'' 1.6.7 onwards. <br />
|}<br />
<br />
Using the device {{ic|/dev/sd''X''}}, the above right column example results in:<br />
<br />
# cryptsetup --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sd''Z'' --key-size=512 open --type=plain /dev/sdX enc<br />
<br />
Unlike encrypting with LUKS, the above command must be executed ''in full'' whenever the mapping needs to be re-established, so it is important to remember the cipher, hash and key file details. We can now check that the mapping has been made:<br />
<br />
# fdisk -l<br />
<br />
An entry should now exist for {{ic|/dev/mapper/enc}}.<br />
<br />
== Encrypting devices with cryptsetup ==<br />
<br />
This section shows how to employ the options for creating new encrypted block devices and accessing them manually. <br />
<br />
{{Warning|GRUB's support for LUKS2 is limited; see [[GRUB#Encrypted /boot]] for details. Use LUKS1 ({{ic|1=cryptsetup luksFormat --type luks1}}) for partitions that GRUB will need to unlock.}}<br />
<br />
=== Encrypting devices with LUKS mode ===<br />
<br />
==== Formatting LUKS partitions ====<br />
<br />
In order to setup a partition as an encrypted LUKS partition execute:<br />
<br />
# cryptsetup luksFormat ''device''<br />
<br />
You will then be prompted to enter a password and verify it.<br />
<br />
See [[#Encryption options for LUKS mode]] for command line options.<br />
<br />
You can check the results with:<br />
<br />
# cryptsetup luksDump ''device''<br />
<br />
You will note that the dump not only shows the cipher header information, but also the key-slots in use for the LUKS partition. <br />
<br />
The following example will create an encrypted root partition on {{ic|/dev/sda1}} using the default AES cipher in XTS mode with an effective 256-bit encryption <br />
<br />
# cryptsetup -s 512 luksFormat /dev/sda1<br />
<br />
===== Using LUKS to format partitions 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 luksFormat ''device'' ''/path/to/mykeyfile''<br />
<br />
See [[#Keyfiles]] for instructions on how to generate and manage keyfiles.<br />
<br />
==== Unlocking/Mapping LUKS partitions with the device mapper ====<br />
<br />
Once the LUKS partitions have been created, they can then be unlocked.<br />
<br />
The unlocking process will map the partitions to a new device name using the device mapper. This alerts the kernel that {{ic|''device''}} is actually an encrypted device and should be addressed through LUKS using the {{ic|/dev/mapper/''dm_name''}} so as not to overwrite the encrypted data. To guard against accidental overwriting, read about the possibilities to [[#Backup and restore|backup the cryptheader]] after finishing setup.<br />
<br />
In order to open an encrypted LUKS partition execute:<br />
<br />
# cryptsetup open ''device'' ''dm_name''<br />
<br />
You will then be prompted for the password to unlock the partition. Usually the device mapped name is descriptive of the function of the partition that is mapped. For example the following unlocks a root luks partition {{ic|/dev/sda1}} and maps it to device mapper named {{ic|root}}:<br />
<br />
# cryptsetup open /dev/sda1 root <br />
<br />
Once opened, the root partition device address would be {{ic|/dev/mapper/root}} instead of the partition (e.g. {{ic|/dev/sda1}}). <br />
<br />
For setting up LVM ontop the encryption layer the device file for the decrypted volume group would be anything like {{ic|/dev/mapper/root}} instead of {{ic|/dev/sda1}}. LVM will then give additional names to all logical volumes created, e.g. {{ic|/dev/lvmpool/root}} and {{ic|/dev/lvmpool/swap}}.<br />
<br />
In order to write encrypted data into the partition it must be accessed through the device mapped name. The first step of access will typically be to [[create a file system]]. For example:<br />
<br />
# mkfs -t ext4 /dev/mapper/root<br />
<br />
The device {{ic|/dev/mapper/root}} can then be [[mount]]ed like any other partition.<br />
<br />
To close the LUKS container, unmount the partition and do:<br />
<br />
# cryptsetup close root<br />
<br />
==== Using a TPM to store keys ====<br />
<br />
See [[Trusted Platform Module#Data-at-rest encryption with LUKS]].<br />
<br />
=== Encrypting devices with plain mode ===<br />
<br />
The creation and subsequent access of a ''dm-crypt'' plain mode encryption both require not more than using the ''cryptsetup'' {{ic|open}} action with correct [[#Encryption options for plain mode|parameters]]. The following shows that with two examples of non-root devices, but adds a quirk by stacking both (i.e. the second is created inside the first). Obviously, stacking the encryption doubles overhead. The usecase here is simply to illustrate another example of the cipher option usage. <br />
<br />
A first mapper is created with ''cryptsetup's'' plain-mode defaults, as described in the table's left column above <br />
<br />
{{hc|# cryptsetup --type plain -v open /dev/sd''xY'' plain1|<br />
Enter passphrase: <br />
Command successful.<br />
}}<br />
<br />
Now we add the second block device inside it, using different encryption parameters and with an (optional) offset, create a file system and mount it <br />
<br />
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# lsblk -p|<br />
NAME <br />
/dev/sda <br />
├─/dev/sd''xY'' <br />
│ └─/dev/mapper/plain1 <br />
│ └─/dev/mapper/plain2 <br />
...<br />
}}<br />
<br />
# mkfs -t ext2 /dev/mapper/plain2<br />
# mount -t ext2 /dev/mapper/plain2 /mnt<br />
# echo "This is stacked. one passphrase per foot to shoot." > /mnt/stacked.txt<br />
<br />
We close the stack to check access works<br />
<br />
# cryptsetup close plain2<br />
# cryptsetup close plain1<br />
<br />
First, let us try to open the file system directly: <br />
<br />
# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/sd''xY'' plain2<br />
<br />
{{hc|# mount -t ext2 /dev/mapper/plain2 /mnt|<br />
mount: wrong fs type, bad option, bad superblock on /dev/mapper/plain2,<br />
missing codepage or helper program, or other error<br />
}}<br />
<br />
Why that did not work? Because the "plain2" starting block ({{ic|10}}) is still encrypted with the cipher from "plain1". It can only be accessed via the stacked mapper. The error is arbitrary though, trying a wrong passphrase or wrong options will yield the same. For ''dm-crypt'' plain mode, the {{ic|open}} action will not error out itself. <br />
<br />
Trying again in correct order: <br />
<br />
# cryptsetup close plain2 # dysfunctional mapper from previous try<br />
<br />
{{hc|# cryptsetup --type plain open /dev/sd''xY'' plain1|<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|1=# cryptsetup --type plain --cipher=serpent-xts-plain64 --hash=sha256 --key-size=256 --offset=10 open /dev/mapper/plain1 plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# mount /dev/mapper/plain2 /mnt && cat /mnt/stacked.txt|<br />
This is stacked. one passphrase per foot to shoot.<br />
}}<br />
<br />
''dm-crypt'' will handle stacked encryption with some mixed modes too. For example LUKS mode could be stacked on the "plain1" mapper. Its header would then be encrypted inside "plain1" when that is closed.<br />
<br />
Available for plain mode only is the option {{ic|--shared}}. With it a single device can be segmented into different non-overlapping mappers. We do that in the next example, using a ''loopaes'' compatible cipher mode for "plain2" this time: <br />
<br />
{{hc|# cryptsetup --type plain --offset 0 --size 1000 open /dev/sd''xY'' plain1|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|1=# cryptsetup --type plain --offset 1000 --size 1000 --shared --cipher=aes-cbc-lmk --hash=sha256 open /dev/sd''xY'' plain2|2=<br />
Enter passphrase:<br />
}}<br />
<br />
{{hc|# lsblk -p|<br />
NAME <br />
dev/sd''xY'' <br />
├─/dev/sd''xY'' <br />
│ ├─/dev/mapper/plain1 <br />
│ └─/dev/mapper/plain2 <br />
...<br />
}}<br />
<br />
As the device tree shows both reside on the same level, i.e. are not stacked and "plain2" can be opened individually.<br />
<br />
== Cryptsetup actions specific for LUKS ==<br />
<br />
=== Key management ===<br />
<br />
It is possible to define additional keys for the LUKS partition. This enables the user to create access keys for safe backup storage In so-called key escrow, one key is used for daily usage, another kept in escrow to gain access to the partition in case the daily passphrase is forgotten or a keyfile is lost/damaged. A different key-slot could also be used to grant access to a partition to a user by issuing a second key and later revoking it again. <br />
<br />
Once an encrypted partition has been created, the initial keyslot 0 is created (if no other was specified manually). Additional keyslots are numbered from 1 to 7. Which keyslots are used can be seen by issuing <br />
<br />
# cryptsetup luksDump /dev/''device''<br />
<br />
Where {{ic|''device''}} is the block device containing the LUKS header. This and all the following commands in this section work on header backup files as well.<br />
<br />
==== Adding LUKS keys ====<br />
<br />
Adding new keyslots is accomplished with the {{ic|luksAddKey}} action. For safety it will always, even for already unlocked devices, ask for a valid existing key (a passphrase for any existing slot) before a new one may be entered:<br />
<br />
{{hc|# cryptsetup luksAddKey /dev/''device'' [''/path/to/additionalkeyfile'']|<br />
Enter any passphrase:<br />
Enter new passphrase for key slot:<br />
Verify passphrase: <br />
}}<br />
<br />
If {{ic|''/path/to/additionalkeyfile''}} is given, cryptsetup will add a new keyslot for {{ic|''additionalkeyfile''}}. Otherwise it prompts for a new passphrase. To authorize the action with an existing ''keyfile'', the {{ic|--key-file}} or {{ic|-d}} option followed by the "old" {{ic|''keyfile''}} will try to unlock all available keyfile keyslots:<br />
<br />
# cryptsetup luksAddKey /dev/''device'' [''/path/to/additionalkeyfile''] -d ''/path/to/keyfile''<br />
<br />
If it is intended to use multiple keys and change or revoke them, the {{ic|--key-slot}} or {{ic|-S}} option may be used to specify the slot: <br />
<br />
{{hc|# cryptsetup luksAddKey /dev/''device'' -S 6|<br />
Enter any passphrase: <br />
Enter new passphrase for key slot: <br />
Verify passphrase:<br />
}}<br />
<br />
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|<br />
Key Slot 6: ENABLED<br />
}}<br />
<br />
To show an associated action in this example, we decide to change the key right away: <br />
<br />
{{hc|# cryptsetup luksChangeKey /dev/''device'' -S 6|<br />
Enter LUKS passphrase to be changed: <br />
Enter new LUKS passphrase:<br />
}}<br />
<br />
before continuing to remove it.<br />
<br />
==== Removing LUKS keys ====<br />
<br />
There are three different actions to remove keys from the header: <br />
<br />
* {{ic|luksRemoveKey}} removes a key by specifying its passphrase/key-file. <br />
* {{ic|luksKillSlot}} removes a key by specifying its slot (needs another valid key). Obviously, this is extremely useful if you have forgotten a passphrase, lost a key-file, or have no access to it. <br />
* {{ic|luksErase}} removes '''all''' active keys. <br />
<br />
{{warning|<br />
* All above actions can be used to irrevocably delete the last active key for an encrypted device! <br />
* The {{ic|luksErase}} command was added in version 1.6.4 to quickly nuke access to the device. This action '''will not''' prompt for a valid passphrase! It will not [[dm-crypt/Drive preparation#Wipe LUKS header|wipe the LUKS header]], but all keyslots at once and you will, therefore, not be able to regain access unless you have a valid backup of the LUKS header.<br />
}}<br />
<br />
For above warning it is good to know the key we want to '''keep''' is valid. An easy check is to unlock the device with the {{ic|-v}} option, which will specify which slot it occupies: <br />
<br />
{{hc|# cryptsetup --test-passphrase -v open /dev/''device''|<br />
Enter passphrase for /dev/''device'': <br />
Key slot 1 unlocked.<br />
Command successful.<br />
}}<br />
<br />
Now we can remove the key added in the previous subsection using its passphrase: <br />
<br />
{{hc|# cryptsetup luksRemoveKey /dev/''device''|<br />
Enter LUKS passphrase to be deleted:<br />
}}<br />
<br />
If we had used the same passphrase for two keyslots, the first slot would be wiped now. Only executing it again would remove the second one. <br />
<br />
Alternatively, we can specify the key slot: <br />
<br />
{{hc|# cryptsetup luksKillSlot /dev/''device'' 6|<br />
Enter any remaining LUKS passphrase:<br />
}}<br />
<br />
Note that in both cases, no confirmation was required.<br />
<br />
{{hc|# cryptsetup luksDump /dev/sda8 {{!}} grep 'Slot 6'|<br />
Key Slot 6: DISABLED<br />
}}<br />
<br />
To re-iterate the warning above: If the same passphrase had been used for key slots 1 and 6, both would be gone now.<br />
<br />
=== Backup and restore ===<br />
<br />
If the header of a LUKS encrypted partition gets destroyed, you will not be able to decrypt your data. It is just as much of a dilemma as forgetting the passphrase or damaging a key-file used to unlock the partition. Damage may occur by your own fault while re-partitioning the disk later or by third-party programs misinterpreting the partition table. Therefore, having a backup of the header and storing it on another disk might be a good idea.<br />
<br />
{{Note|If one of the LUKS-encrypted partitions' passphrases becomes compromised, you must revoke it on ''every'' copy of the cryptheader, even those you have backed up. Otherwise, a copy of the backed-up cryptheader that uses the compromised passphrase can be used to determine the master key which in turn can be used to decrypt the associated partition (even your actual partition, not only the backed-up version). On the other hand, if the master key gets compromised, you have to reencrypt your whole partition. See [https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions#6-backup-and-data-recovery LUKS FAQ] for further details.}}<br />
<br />
==== Backup using cryptsetup ====<br />
<br />
Cryptsetup's {{ic|luksHeaderBackup}} action stores a binary backup of the LUKS header and keyslot area:<br />
<br />
# cryptsetup luksHeaderBackup /dev/''device'' --header-backup-file ''/mnt/backup/file.img''<br />
<br />
where {{ic|''device''}} is the partition containing the LUKS volume.<br />
<br />
You can also back up the plain text header into ramfs and encrypt it with e.g. [[GPG]] before writing it to persistent storage:<br />
<br />
# mount --mkdir -t ramfs ramfs /root/''tmp''<br />
# cryptsetup luksHeaderBackup /dev/''device'' --header-backup-file /root/''tmp''/''file''.img<br />
# gpg2 --recipient ''User_ID'' --encrypt /root/''tmp''/''file''.img <br />
# cp /root/''tmp''/''file''.img.gpg /mnt/''backup''/<br />
# umount /root/''tmp''<br />
<br />
{{Warning|[[tmpfs]] can swap to the disk in low memory situations, so it is not recommended here.}}<br />
<br />
==== Restore using cryptsetup ====<br />
<br />
{{Warning|Restoring the wrong header or restoring to an unencrypted partition will cause data loss! The action can not perform a check whether the header is actually the ''correct'' one for that particular device.}} <br />
<br />
In order to evade restoring a wrong header, you can ensure it does work by using it as a remote {{ic|--header}} first: <br />
<br />
{{hc|# cryptsetup -v --header /mnt/''backup''/''file''.img open /dev/''device'' test|<br />
Key slot 0 unlocked.<br />
Command successful.<br />
}}<br />
<br />
# mount /dev/mapper/test /mnt/test && ls /mnt/test <br />
# umount /mnt/test <br />
# cryptsetup close test <br />
<br />
Now that the check succeeded, the restore may be performed: <br />
<br />
# cryptsetup luksHeaderRestore /dev/''device'' --header-backup-file ./mnt/''backup''/''file''.img<br />
<br />
Now that all the keyslot areas are overwritten; only active keyslots from the backup file are available after issuing the command.<br />
<br />
==== Manual backup and restore ====<br />
<br />
The header always resides at the beginning of the device and a backup can be performed without access to ''cryptsetup'' as well. First you have to find out the payload offset of the crypted partition:<br />
<br />
{{hc|# cryptsetup luksDump /dev/''device'' {{!}} grep "Payload offset"|<br />
Payload offset: 4040<br />
}}<br />
<br />
Second check the sector size of the drive<br />
<br />
{{hc|# fdisk -l /dev/''device'' {{!}} grep "Sector size"|<br />
Sector size (logical/physical): 512 bytes / 512 bytes<br />
}}<br />
<br />
Now that you know the values, you can backup the header with a simple [[dd]] command:<br />
<br />
# dd if=/dev/''device'' of=/path/to/''file''.img bs=512 count=4040<br />
<br />
and store it safely.<br />
<br />
A restore can then be performed using the same values as when backing up:<br />
<br />
# dd if=./''file''.img of=/dev/''device'' bs=512 count=4040<br />
<br />
=== Re-encrypting devices ===<br />
<br />
{{Expansion|cryptsetup 2.2 using LUKS2 (with a 16 MiB header) supports online encryption/decryption/reencryption.[https://mirrors.edge.kernel.org/pub/linux/utils/cryptsetup/v2.2/v2.2.0-ReleaseNotes]}}<br />
<br />
{{Out of date|cryptsetup-reencrypt was removed in cryptsetup 2.5.0.[https://www.kernel.org/pub/linux/utils/cryptsetup/v2.5/v2.5.0-ReleaseNotes]}}<br />
<br />
The {{Pkg|cryptsetup}} package features two options for re-encryption.<br />
<br />
; cryptsetup reencrypt: Argument to {{ic|cryptsetup}} itself: Preferred method. Currently LUKS2 devices only. Actions can be performed online. Supports multiple parallel re-encryption jobs. Resilient to system failures. See {{man|8|cryptsetup}} for more information.<br />
<br />
; cryptsetup-reencrypt: Legacy tool, supports LUKS1 in addition to LUKS2. Actions can be performed on unmounted devices only. Single process at a time. Sensitive to system failures. See {{man|8|cryptsetup-reencrypt}} for more information. <br />
<br />
Both can be used to convert an existing unencrypted file system to a LUKS encrypted one or permanently remove LUKS encryption from a device (using {{ic|--decrypt}}). As its name suggests it can also be used to re-encrypt an existing LUKS encrypted device, though, re-encryption is not possible for a detached LUKS header or other encryption modes (e.g. plain-mode). For re-encryption it is possible to change the [[#Encryption options for LUKS mode]]. <br />
<br />
One application of re-encryption may be to secure the data again after a passphrase or [[#Keyfiles|keyfile]] has been compromised ''and'' one cannot be certain that no copy of the LUKS header has been obtained. For example, if only a passphrase has been shoulder-surfed but no physical/logical access to the device happened, it would be enough to change the respective passphrase/key only ([[#Key management]]). <br />
<br />
{{Warning|Always make sure a '''reliable backup''' is available and double-check options you specify before using the tool!}}<br />
<br />
The following shows an example to encrypt an unencrypted file system partition and a re-encryption of an existing LUKS device.<br />
<br />
==== Encrypt an existing unencrypted file system ====<br />
<br />
{{Tip|If you are trying to encrypt an existing root partition, you might want to create a separate and unencrypted boot partition which will be mounted to {{ic|/boot}} (see [[Dm-crypt/Encrypting an entire system#Preparing the boot partition]]). It is not strictly necessary but has a number of advantages:<br />
<br />
* If {{ic|/boot}} is located inside an encrypted root partition, the system will ask for the passphrase twice when the machine is powered on. The first time will happen when the boot loader attempts to read the files located inside encrypted {{ic|/boot}}, the second time will be when the kernel tries to mount the encrypted partition [https://opencraft.com/blog/tutorial-encrypting-an-existing-root-partition-in-ubuntu-with-dm-crypt-and-luks/]. This might not be the desired behaviour and can be prevented by having a separate and unencryted boot partition.<br />
* Some system restore applications (e.g., {{AUR|timeshift}}) will not work if {{ic|/boot}} is located inside an encryted partition [https://github.com/teejee2008/timeshift/issues/280].<br />
<br />
In short, create a partition with the size of at least 260 MiB if needed. See [[Partitioning#/boot]].}}<br />
<br />
A LUKS encryption header is always stored at the beginning of the device. Since an existing file system will usually be allocated all partition sectors, the first step is to shrink it to make space for the LUKS header.<br />
<br />
{{Expansion|cryptsetup man pages suggest using twice the LUKS2 header size. That implies 32 MiB and using {{ic|--reduce-device-size 32M}}}}<br />
<br />
The [[#Encryption options for LUKS mode|default]] LUKS2 header requires 16 MiB. If the current file system occupies all the available space, we will have to shrink it at least that much. To shrink an existing {{ic|ext4}} file system on {{ic|/dev/sd''xY''}} to its current possible minimum:<br />
<br />
# umount /mnt<br />
<br />
{{hc|# e2fsck -f /dev/sd''xY''|<br />
e2fsck 1.46.5 (30-Dec-2021)<br />
Pass 1: Checking inodes, blocks, and sizes<br />
...<br />
/dev/sda6: 12/166320 files (0.0% non-contiguous), 28783/665062 blocks<br />
}}<br />
<br />
{{hc|# resize2fs -p -M /dev/sd''xY''|<br />
e2fsck 1.46.5 (30-Dec-2021)<br />
Resizing the filesystem on /dev/sd''xY'' to 26347 (4k) blocks.<br />
The filesystem on /dev/sd''xY'' is now 26347 (4k) blocks long.<br />
}}<br />
<br />
{{Tip|Shrinking to the minimum size with {{ic|-M}} might take very long. You might want to calculate a size just 32 MiB smaller than the current size instead of using {{ic|-M}}.}}<br />
<br />
{{Warning|The file system should be shrunk while the underlying device (e.g., a partition) should be kept at its original size. Some graphical tools (e.g., [[GParted]]) may resize both the file system and the partition, and data loss may occur after encryption.}}<br />
<br />
Now we encrypt it, using the default cipher we do not have to specify it explicitly:<br />
<br />
{{hc|# cryptsetup reencrypt --encrypt --reduce-device-size 16M /dev/sd''xY''|<nowiki><br />
<br />
WARNING!<br />
<br />
========<br />
<br />
This will overwrite data on LUKS2-temp-12345678-9012-3456-7890-123456789012.new irrevocably.<br />
<br />
Are you sure? (Type 'yes' in capital letters): YES<br />
Enter passphrase for LUKS2-temp-12345678-9012-3456-7890-123456789012.new: <br />
Verify passphrase: <br />
</nowiki>}}<br />
<br />
After it finished, the whole {{ic|/dev/sd''xY''}} partition is encrypted, not only the space the file system was shrunk to. As a final step we extend the original {{ic|ext4}} file system to occupy all available space again, on the now encrypted partition:<br />
<br />
{{hc|# cryptsetup open /dev/sd''xY'' recrypt|<br />
Enter passphrase for /dev/sd''xY'': <br />
...<br />
}}<br />
<br />
{{hc|# resize2fs /dev/mapper/recrypt|<br />
resize2fs 1.43-WIP (18-May-2015)<br />
Resizing the filesystem on /dev/mapper/recrypt to 664807 (4k) blocks.<br />
The filesystem on /dev/mapper/recrypt is now 664807 (4k) blocks long.<br />
}}<br />
<br />
# mount /dev/mapper/recrypt /mnt<br />
<br />
The file system is now ready to use. You may want to add it to your [[crypttab]].<br />
<br />
{{Tip|If you have just encrypted your root partition, you might need to perform a number of post-encryption adjustments.<br />
<br />
See [[Dm-crypt/Encrypting an entire system#Configuring mkinitcpio]], [[Dm-crypt/Encrypting an entire system#Configuring the boot loader]], and [[Dm-crypt/Encrypting an entire system#Configuring GRUB]].}}<br />
<br />
==== Re-encrypting an existing LUKS partition ====<br />
<br />
In this example an existing LUKS device is re-encrypted. <br />
<br />
{{Warning|Double-check you specify encryption options for correctly and ''never'' re-encrypt without a '''reliable backup'''!}}<br />
<br />
In order to re-encrypt a device with its existing encryption options, they do not need to be specified:<br />
{{bc|# cryptsetup reencrypt /dev/sd''xY''}}<br />
{{Note|For LUKS1 we will need to use the legacy tool:{{bc|# cryptsetup-reencrypt /dev/sd''xY''}}}}<br />
<br />
Existing keys are retained when re-encrypting a device with a different cipher and/or hash. Another use case is to re-encrypt LUKS devices which have non-current encryption options. Apart from above warning on specifying options correctly, the ability to change the LUKS header may also be limited by its size. For example, if the device was initially encrypted using a CBC mode cipher and 128 bit key-size, the LUKS header will be half the size of above mentioned {{ic|4096}} sectors: <br />
<br />
{{hc|# cryptsetup luksDump /dev/sd''xY'' {{!}} grep -e "mode" -e "Payload" -e "MK bits"|<br />
Cipher mode: cbc-essiv:sha256<br />
Payload offset: '''2048'''<br />
MK bits: 128<br />
}}<br />
<br />
While it is possible to upgrade the encryption of such a device, it is currently only feasible in two steps. First, re-encrypting with the same encryption options, but using the {{ic|--reduce-device-size}} option to make further space for the larger LUKS header. Second, re-encypt the whole device again with the desired cipher. For this reason and the fact that a backup should be created in any case, creating a new, fresh encrypted device to restore into is always the faster option.<br />
<br />
=== Conversion from LUKS1 to LUKS2 and back ===<br />
<br />
The {{Pkg|cryptsetup}} package has {{ic|convert}} option that needed for conversion between LUKS1 and LUKS2 container types. The argument {{ic|--type}} is '''required'''.<br />
<br />
Migration from LUKS1 to LUKS2:<br />
<br />
# cryptsetup convert --type luks2 /dev/sd''xY''<br />
<br />
{{Note|The LUKS header size will be 16 MiB instead of 2 MiB.}}<br />
<br />
Rollback to LUKS1 (for example, to boot from [[GRUB#Encrypted /boot|GRUB with encrypted /boot]]):<br />
<br />
# cryptsetup convert --type luks1 /dev/sd''xY''<br />
<br />
{{Note|Conversion from LUKS2 to LUKS1 is '''not''' always possible. You may get the following error:<br />
Cannot convert to LUKS1 format - keyslot 0 is not LUKS1 compatible.<br />
If the container is using Argon2, it needs to be converted to PBKDF2 to be LUKS1-compatible.<br />
# cryptsetup luksConvertKey --pbkdf pbkdf2 /dev/sd''xY''<br />
}}<br />
<br />
== Resizing encrypted devices ==<br />
<br />
{{Expansion|This section should be rewritten to introduce resizing more generically. Perhaps work on it together with [[Resizing LVM-on-LUKS]].}}<br />
<br />
If a storage device encrypted with dm-crypt is being cloned (with a tool like dd) to another larger device, the underlying dm-crypt device must be resized to use the whole space. <br />
<br />
The destination device is /dev/sdX2 in this example, the whole available space adjacent to the partition will be used:<br />
<br />
# cryptsetup luksOpen /dev/sdX2 sdX2<br />
# cryptsetup resize sdX2<br />
<br />
Then the underlying file system must be resized.<br />
<br />
=== Loopback file system ===<br />
<br />
Assume that an encrypted loopback file system is stored in a file {{ic|/bigsecret}}, looped to {{ic|/dev/loop0}}, mapped to {{ic|secret}} and mounted on {{ic|/mnt/secret}}, as in the example at [[dm-crypt/Encrypting a non-root file system#File container]].<br />
<br />
If the container file is currently mapped and/or mounted, unmount and/or close it:<br />
<br />
# umount /mnt/secret<br />
# cryptsetup close secret<br />
# losetup -d /dev/loop0<br />
<br />
Next, expand the container file with the size of the data you want to add. In this example, the file will be expanded with 1M * 1024, which is 1G.<br />
<br />
{{Warning|Make absolutely sure to use '''two''' {{ic|>}}, instead of just one, or else you will overwrite the file instead of appending to it. Making a backup before this step is strongly recommended.}}<br />
<br />
# dd if=/dev/urandom bs=1M count=1024 | cat - >> /bigsecret<br />
<br />
Now map the container to the loop device:<br />
<br />
# losetup /dev/loop0 /bigsecret<br />
# cryptsetup open /dev/loop0 secret<br />
<br />
After this, resize the encrypted part of the container to the new maximum size of the container file:<br />
<br />
# cryptsetup resize secret<br />
<br />
Finally, perform a file system check and, if it is ok, resize it (example for ext2/3/4):<br />
<br />
# e2fsck -f /dev/mapper/secret<br />
# resize2fs /dev/mapper/secret<br />
<br />
You can now mount the container again:<br />
<br />
# mount /dev/mapper/secret /mnt/secret<br />
<br />
=== Integrity protected device ===<br />
<br />
If the device was formatted with integrity support (e.g., {{ic|--integrity hmac-sha256}}) and the backing block device is shrinked, it cannot be opened with this error: {{ic|device-mapper: reload ioctl on failed: Invalid argument}}.<br />
<br />
To fix this issue without wiping the device again, it can be formatted with the previous master key (keeping the per-sector tags valid).<br />
<br />
# cryptsetup luksDump /dev/sdX2 --dump-master-key --master-key-file=/tmp/masterkey-in-tmpfs.key<br />
# cryptsetup luksFormat /dev/sdX2 --type luks2 --integrity hmac-sha256 --master-key-file=/tmp/masterkey-in-tmpfs.key --integrity-no-wipe<br />
# rm /tmp/masterkey-in-tmpfs.key<br />
<br />
== Keyfiles ==<br />
<br />
{{Note|This section describes using a plaintext keyfile. If you want to encrypt your keyfile giving you two factor authentication see [[dm-crypt/Specialties#Using GPG, LUKS, or OpenSSL Encrypted Keyfiles|Using GPG or OpenSSL Encrypted Keyfiles]] for details, but please still read this section.}}<br />
<br />
'''What is a keyfile?'''<br />
<br />
A keyfile is a file whose data is used as the passphrase to unlock an encrypted volume.<br />
That means if such a file is lost or changed, decrypting the volume may 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 keyfiles. Each type of keyfile used has benefits and disadvantages summarized below:<br />
<br />
=== Types of keyfiles ===<br />
<br />
==== passphrase ====<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 />
Example: {{ic|1234}}<br />
<br />
{{Note|The keyfile containing the passphrase must not have a newline in it. One option is to create it using <br />
<br />
# echo -n 'your_passphrase' > ''/path/to/keyfile''<br />
# chown root:root ''/path/to/keyfile''; chmod 400 ''/path/to/keyfile''<br />
<br />
If the file contains special characters such as a backslash, rather than escaping these, it is recommended to simply edit the key file directly entering or pasting the passphrase and then remove the trailing newline with a handy perl one-liner:<br />
<br />
# perl -pi -e 'chomp if eof' ''/path/to/keyfile''<br />
}}<br />
<br />
==== randomtext ====<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 />
Example: {{ic|fjqweifj830149-57 819y4my1-38t1934yt8-91m 34co3;t8y;9p3y-}}<br />
<br />
==== binary ====<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 random text file. However this is controversial and has never been exploited publicly.<br />
<br />
Example: images, text, video, ...<br />
<br />
=== Creating a keyfile with random characters ===<br />
<br />
==== Storing the keyfile on a file system ====<br />
<br />
A keyfile can be of arbitrary content and size. <br />
<br />
Here [[dd]] is used to generate a keyfile of 2048 random bytes, storing it in the file {{ic|/etc/mykeyfile}}:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/etc/mykeyfile iflag=fullblock<br />
<br />
If you are planning to store the keyfile on an external device, you can also simply change the outputfile to the corresponding directory:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/media/usbstick/mykeyfile iflag=fullblock<br />
<br />
To deny any access for other users than {{ic|root}}:<br />
<br />
# chmod 600 /etc/mykeyfile<br />
<br />
===== Securely overwriting stored keyfiles =====<br />
<br />
If you stored your temporary keyfile on a physical storage device, and want to delete it, remember to not just remove the keyfile later on, but use something like<br />
<br />
# shred --remove --zero mykeyfile<br />
<br />
to securely overwrite it. For overaged file systems like FAT or ext2 this will suffice while in the case of journaling file systems, flash memory hardware and other cases it is highly recommended to [[Securely wipe disk|wipe the entire device]].<br />
<br />
==== Storing the keyfile in ramfs ====<br />
<br />
Alternatively, you can mount a ramfs for storing the keyfile temporarily:<br />
<br />
# mount --mkdir -t ramfs ramfs /root/myramfs<br />
# cd /root/myramfs<br />
<br />
The advantage is that it resides in RAM and not on a physical disk, therefore it can not be recovered after unmounting the ramfs. After copying the keyfile to another secure and persistent file system, unmount the ramfs again with<br />
<br />
# umount /root/myramfs<br />
<br />
=== Configuring LUKS to make use of the keyfile ===<br />
<br />
Add a keyslot for the keyfile to the LUKS header:<br />
<br />
{{hc|# cryptsetup luksAddKey /dev/sda2 /etc/mykeyfile|<br />
Enter any LUKS passphrase:<br />
key slot 0 unlocked.<br />
Command successful.<br />
}}<br />
<br />
=== Manually unlocking a partition using a keyfile ===<br />
<br />
Use the {{ic|--key-file}} option when opening the LUKS device:<br />
<br />
# cryptsetup open /dev/sda2 ''dm_name'' --key-file /etc/mykeyfile<br />
<br />
=== Unlocking the root partition at boot ===<br />
<br />
This is simply a matter of configuring [[mkinitcpio]] to include the necessary modules or files and configuring the [[dm-crypt/System configuration#cryptkey|cryptkey]] [[kernel parameter]] to know where to find the keyfile.<br />
<br />
Two cases are covered below:<br />
<br />
# Using a keyfile stored on an external medium (e.g. a USB stick)<br />
# Using a keyfile embedded in the initramfs<br />
<br />
==== With a keyfile stored on an external media ====<br />
<br />
===== Configuring mkinitcpio =====<br />
<br />
You have to add the kernel module for the drive's [[file system]] to the [[mkinitcpio#MODULES|MODULES array]] in {{ic|/etc/mkinitcpio.conf}}. For example, add {{ic|ext4}} if the file system is [[Ext4]] or {{ic|vfat}} in case it is [[FAT]]:<br />
<br />
MODULES=(vfat)<br />
<br />
If there are messages about bad superblock and bad codepage at boot, then you need an extra codepage module to be loaded. For instance, you may need {{ic|nls_iso8859-1}} module for {{ic|iso8859-1}} codepage.<br />
<br />
[[Regenerate the initramfs]].<br />
<br />
===== Configuring the kernel parameters =====<br />
<br />
* For a busybox-based initramfs using the [[dm-crypt/System configuration#Using encrypt hook|encrypt]] hook, see [[dm-crypt/System configuration#cryptkey]].<br />
* For a systemd based initramfs using the [[sd-encrypt]] hook, see [[dm-crypt/System configuration#rd.luks.key]].<br />
<br />
==== With a keyfile embedded in the initramfs ====<br />
<br />
{{Warning|Use an embedded keyfile '''only''' if you protect the keyfile sufficiently by:<br />
* Using some form of authentication earlier in the boot process. Otherwise auto-decryption will occur, defeating completely the purpose of block device encryption.<br />
* {{ic|/boot}} is encrypted. Otherwise root on a different installation (including the [[Installation guide#Boot the live environment|live environment]]) can extract your key from the initramfs, and unlock the device without any other authentication.}}<br />
<br />
This method allows to use a specially named keyfile that will be embedded in the [[initramfs]] and picked up by the {{ic|encrypt}} [[Mkinitcpio#HOOKS|hook]] to unlock the root file system ({{ic|cryptdevice}}) automatically. It may be useful to apply when using the [[GRUB#Encrypted /boot|GRUB early cryptodisk]] feature, in order to avoid entering two passphrases during boot.<br />
<br />
The {{ic|encrypt}} hook lets the user specify a keyfile with the {{ic|cryptkey}} kernel parameter: in the case of initramfs, the syntax is {{ic|rootfs:''/path/to/keyfile''}}. See [[dm-crypt/System configuration#cryptkey]]. Besides, this kernel parameter defaults to use {{ic|/crypto_keyfile.bin}}, and if the initramfs contains a valid key with this name, decryption will occur automatically without the need to configure the {{ic|cryptkey}} parameter.<br />
<br />
If using {{ic|sd-encrypt}} instead of {{ic|encrypt}}, specify the location of the keyfile with the {{ic|rd.luks.key}} kernel parameter: in the case of initramfs, the syntax is {{ic|''/path/to/keyfile''}}. See [[dm-crypt/System configuration#rd.luks.key]]. This kernel parameter defaults to using {{ic|/etc/cryptsetup-keys.d/''name''.key}} (where {{ic|''name''}} is the {{ic|''dm_name''}} used for decryption in [[#Encrypting devices with cryptsetup]]) and can be omitted if initramfs contains a valid key with this path.<br />
<br />
[[#Creating a keyfile with random characters|Generate the keyfile]], give it suitable permissions and [[#Adding LUKS keys|add it as a LUKS key]]:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/crypto_keyfile.bin iflag=fullblock<br />
# chmod 600 /crypto_keyfile.bin<br />
# cryptsetup luksAddKey /dev/sdX# /crypto_keyfile.bin<br />
<br />
{{Note|The initramfs is generated by mkinitcpio with {{ic|600}} [[permissions]] by default, so regular users are not able to read the keyfile via the generated initramfs.}}<br />
<br />
Include the key in [[mkinitcpio#BINARIES and FILES|mkinitcpio's FILES array]]:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
FILES=(/crypto_keyfile.bin)<br />
}}<br />
<br />
Finally [[regenerate the initramfs]].<br />
<br />
On the next reboot you should only have to enter your container decryption passphrase once.<br />
<br />
([https://www.pavelkogan.com/2014/05/23/luks-full-disk-encryption/#bonus-login-once source])</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=MariaDB&diff=731208MariaDB2022-05-31T17:58:28Z<p>Leonardodag: This is not true anymore, by default MariaDB also binds to both IPv4 and IPv6. Also,m the configuration file path was wrong.</p>
<hr />
<div>[[Category:Relational DBMSs]]<br />
[[de:MariaDB]]<br />
[[fr:MariaDB]]<br />
[[ja:MariaDB]]<br />
[[zh-hans:MariaDB]]<br />
{{Related articles start}}<br />
{{Related|phpMyAdmin}}<br />
{{Related|Adminer}}<br />
{{Related|JDBC and MySQL}}<br />
{{Related|Open Database Connectivity}}<br />
{{Related articles end}}<br />
[[Wikipedia:MariaDB|MariaDB]] is a reliable, high performance and full-featured database server which aims to be an 'always Free, backward compatible, drop-in' replacement of [[MySQL]]. Since 2013 MariaDB is Arch Linux's default implementation of MySQL.[https://archlinux.org/news/mariadb-replaces-mysql-in-repositories/]<br />
<br />
== Installation ==<br />
<br />
[https://mariadb.com/ MariaDB] is the [https://archlinux.org/news/mariadb-replaces-mysql-in-repositories/ default implementation] of MySQL in Arch Linux, provided with the {{Pkg|mariadb}} package.<br />
<br />
{{Tip|<br />
* If the database (in {{ic|/var/lib/mysql}}) resides on a [[Btrfs]] file system, you should consider disabling [[Btrfs#Copy-on-Write (CoW)|Copy-on-Write]] for the directory before creating any database.<br />
* If the database resides on a [[ZFS]] file system, you should consult [[ZFS#Databases]] before creating any database.<br />
}}<br />
<br />
[[Install]] {{Pkg|mariadb}}, and run the following command '''before starting''' the {{ic|mariadb.service}}:<br />
<br />
# mariadb-install-db --user=mysql --basedir=/usr --datadir=/var/lib/mysql<br />
<br />
{{Tip|If you use something different from {{ic|/var/lib/mysql}} for your data dir, you need to set {{ic|1=datadir=''YOUR_DATADIR''}} under section {{ic|[mysqld]}} of your {{ic|/etc/my.cnf.d/server.cnf}}.}}<br />
<br />
Now {{ic|mariadb.service}} can be [[started]] and/or [[enabled]].<br />
<br />
{{Note|Before continuing, it is recommended to [[#Improve initial security|improve the initial security]] of the MySQL installation.}}<br />
<br />
To simplify administration, you might want to install a [[MySQL#Graphical tools|front-end]].<br />
<br />
== Configuration ==<br />
<br />
{{Out of date|The main /etc/my.cnf configuration file is now split into various files in /etc/my.cnf.d/ dir.}}<br />
<br />
Once you have started the MySQL server and added a root account, you may want to change the default configuration.<br />
<br />
To log in as {{ic|root}} on the MySQL server, use the following command:<br />
<br />
# mysql -u root -p<br />
<br />
{{Note|The default password is empty. Press {{ic|Enter}} to log in.}}<br />
<br />
=== Add user ===<br />
<br />
Creating a new user takes two steps: create the user; grant privileges. In the below example, the user ''monty'' with ''some_pass'' as password is being created, then granted full permissions to the database ''mydb'': <br />
<br />
{{hc|# mysql -u root -p|<br />
MariaDB> CREATE USER 'monty'@'localhost' IDENTIFIED BY 'some_pass';<br />
MariaDB> GRANT ALL PRIVILEGES ON mydb.* TO 'monty'@'localhost';<br />
MariaDB> FLUSH PRIVILEGES;<br />
MariaDB> quit<br />
}}<br />
<br />
=== Configuration files ===<br />
<br />
''MariaDB'' configuration options are read from the following files in the given order (according to {{ic|mysqld --help --verbose {{!}} tail -20}} output):<br />
<br />
/etc/my.cnf /etc/my.cnf.d/ ~/.my.cnf<br />
<br />
Depending on the scope of the changes you want to make (system-wide, user-only...), use the corresponding file. See [https://mariadb.com/kb/en/library/configuring-mariadb-with-option-files/ this entry] of the Knowledge Base for more information.<br />
<br />
=== Enable auto-completion ===<br />
<br />
{{Note|Enabling this feature can make the client initialization longer.}}<br />
<br />
The MySQL client completion feature is disabled by default. To enable it system-wide edit {{ic|/etc/my.cnf.d/mysql-clients.cnf}}, and add {{ic|auto-rehash}} under {{ic|mysql}}. Note that this must not be placed under {{ic|mysqld}}. Completion will be enabled next time you run the MySQL client.<br />
<br />
=== Using UTF8MB4 ===<br />
<br />
{{Warning|Before changing the character set be sure to create a backup first.}}<br />
<br />
{{Note|<br />
* The {{Pkg|mariadb}} package already uses {{ic|utf8mb4}} as charset and {{ic|utf8mb4_unicode_ci}} as collation. Users using the default (character) settings may want to skip this section.<br />
* UTF8MB4 is recommended over UTF-8 since it allows full Unicode support [https://mathiasbynens.be/notes/mysql-utf8mb4] [https://stackoverflow.com/questions/30074492/what-is-the-difference-between-utf8mb4-and-utf8-charsets-in-mysql].<br />
}}<br />
<br />
[[Append]] the following values to the main configuration file located at {{ic|/etc/my.cnf.d/my.cnf}}:<br />
<br />
{{bc|1=<br />
[client]<br />
default-character-set = utf8mb4<br />
<br />
[mysqld]<br />
collation_server = utf8mb4_unicode_ci<br />
character_set_server = utf8mb4<br />
<br />
[mysql]<br />
default-character-set = utf8mb4<br />
}}<br />
<br />
[[Restart]] {{ic|mariadb.service}} to apply the changes.<br />
<br />
See [[#Maintenance]] to optimize and check the database health.<br />
<br />
=== Increase character limit ===<br />
<br />
{{Out of date|As of 10.3.1 this section is no longer applicable. All 3 options are now enabled by default. {{ic|innodb_file_format}} and {{ic|innodb_large_prefix}} are deprecated and can no longer be used. The mariadb service will fail to start if either are included in {{ic|my.cnf}} ([https://mariadb.com/kb/en/library/innodb-system-variables/#innodb_file_format source])}}<br />
<br />
{{Note|The character-limit depends on the character-set in use [https://web.archive.org/web/20181229154254/http://mechanics.flite.com/blog/2014/07/29/using-innodb-large-prefix-to-avoid-error-1071/] [https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_large_prefix] [https://easyengine.io/tutorials/mysql/enable-innodb-file-per-table/].}}<br />
<br />
For InnoDB execute the following commands to support a higher character-limit:<br />
<br />
mysql> set global innodb_file_format = BARRACUDA;<br />
Query OK, 0 rows affected (0.00 sec)<br />
<br />
mysql> set global innodb_file_per_table = ON;<br />
Query OK, 0 rows affected (0.00 sec)<br />
<br />
mysql> set global innodb_large_prefix = ON;<br />
Query OK, 0 rows affected (0.00 sec)<br />
<br />
[[Append]] the following lines in {{ic|/etc/mysql/my.cnf}} to always use a higher character-limit:<br />
<br />
[mysqld]<br />
innodb_file_format = barracuda<br />
innodb_file_per_table = 1<br />
innodb_large_prefix = 1<br />
<br />
[[Restart]] {{ic|mariadb.service}} to apply the changes.<br />
<br />
On table creating append the {{ic|ROW_FORMAT}} as seen in the example:<br />
<br />
mysql> create table if not exists products (<br />
-> day date not null,<br />
-> product_id int not null,<br />
-> dimension1 varchar(500) not null,<br />
-> dimension2 varchar(500) not null,<br />
-> unique index unique_index (day, product_id, dimension1, dimension2)<br />
-> ) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;<br />
Query OK, 0 rows affected (0.02 sec)<br />
<br />
=== Using a tmpfs for tmpdir ===<br />
<br />
The directory used by MySQL for storing temporary files is named ''tmpdir''. For example, it is used to perform disk based large sorts, as well as for internal and explicit temporary tables.<br />
<br />
Create the directory with appropriate permissions:<br />
<br />
# mkdir -pv /var/lib/mysqltmp<br />
# chown mysql:mysql /var/lib/mysqltmp<br />
<br />
Add the following [[tmpfs]] mount to your {{ic|/etc/fstab}} file:<br />
<br />
tmpfs /var/lib/mysqltmp tmpfs rw,gid=mysql,uid=mysql,size=100M,mode=0750,noatime 0 0<br />
<br />
Add to your {{ic|/etc/my.cnf.d/server.cnf}} file under the {{ic|mysqld}} group:<br />
<br />
tmpdir = /var/lib/mysqltmp<br />
<br />
[[Stop]] {{ic|mariadb.service}}, [[mount]] {{ic|/var/lib/mysqltmp/}} and [[start]] {{ic|mariadb.service}}.<br />
<br />
=== Time zone tables ===<br />
<br />
Although time zone tables are created during the installation, they are not automatically populated. They need to be populated if you are planning on using CONVERT_TZ() in SQL queries.<br />
<br />
To populate the time zone tables with all the time zones:<br />
<br />
$ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql<br />
<br />
Optionally, you may populate the table with specific time zone files:<br />
<br />
$ mysql_tzinfo_to_sql ''timezone_file'' ''timezone_name'' | mysql -u root -p mysql<br />
<br />
== Security ==<br />
<br />
=== Improve initial security ===<br />
<br />
The {{ic|mysql_secure_installation}} command will interactively guide you through a number of recommended security measures, such as removing anonymous accounts and removing the test database:<br />
<br />
# mysql_secure_installation<br />
<br />
{{Warning|After running this, please note that TCP port 3306 will still be open, but refusing connections with an error message. To prevent MySQL from listening on an external interface, see the [[#Listen only on the loopback address]] and [[#Enable access locally only via Unix sockets]] sections.}}<br />
<br />
=== Listen only on the loopback address ===<br />
<br />
By default, MySQL will listen on the 0.0.0.0 address, which includes all network interfaces. In order to restrict MySQL to listen only to the loopback address, add the following line in {{ic|/etc/my.cnf.d/server.cnf}}:<br />
<br />
[mysqld]<br />
bind-address = localhost<br />
<br />
This will bind to both 127.0.0.1 and ::1, and enable MariaDB to receive connections both in IPv4 and IPv6.<br />
<br />
=== Enable access locally only via Unix sockets ===<br />
<br />
By default, MySQL is accessible via both Unix sockets and the network. If MySQL is only needed for the localhost, you can improve security by not listening on TCP port 3306, and only listening on Unix sockets instead. To do this, add the following line in {{ic|/etc/my.cnf.d/server.cnf}}:<br />
<br />
[mysqld]<br />
skip-networking<br />
<br />
You will still be able to log in locally as before, but only using Unix sockets.<br />
<br />
=== Grant remote access ===<br />
<br />
{{Warning|This is not considered as best practice and may cause security issues. Consider using [[Secure Shell]], [[VNC]] or [[VPN]], if you want to maintain the MySQL server from another host inside/outside your network.}}<br />
<br />
To allow remote access to the MySQL server, ensure that MySQL has [[#Enable access locally only via Unix sockets|networking enabled]] and is [[#Listen only on the loopback address|listening on the appropriate interface]].<br />
<br />
Grant any MySQL user remote access (example for root):<br />
<br />
# mysql -u root -p<br />
<br />
Check current users with remote access privileged:<br />
<br />
SELECT User, Host FROM mysql.user WHERE Host <> 'localhost';<br />
<br />
Now grant remote access for your user (here root):<br />
<br />
GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.168.1.%' IDENTIFIED BY 'my_optional_remote_password' WITH GRANT OPTION;<br />
<br />
You can change the '%' wildcard to a specific host if you like. The password can be different from user's main password.<br />
<br />
=== Configure access to home directories ===<br />
<br />
For security reasons, the systemd service file contains {{ic|1=ProtectHome=true}}, which prevents MariaDB from accessing files under the {{ic|/home}}, {{ic|/root}} and {{ic|/run/user}} hierarchies. The {{ic|datadir}} has to be in an accessible location and [[chown|owned]] by the {{ic|mysql}} user and group.<br />
<br />
You can modify this behavior by creating a supplementary service file as described [https://mariadb.com/kb/en/systemd/#configuring-access-to-home-directories here].<br />
<br />
== Maintenance ==<br />
<br />
=== Upgrade databases on major releases ===<br />
<br />
Upon a major version release of {{Pkg|mariadb}} (for example mariadb-10.1.10-1 to mariadb-10.1.18-1), it is wise to upgrade databases:<br />
<br />
# mysql_upgrade -u root -p<br />
<br />
To upgrade from 10.1.x to 10.3.x:<br />
<br />
* keep the 10.1.x database daemon running<br />
* upgrade the package<br />
* run {{ic|mysql_upgrade}} (from the new package version) against the old still-running daemon. This will produce some error messages; however, the upgrade will succeed.<br />
* restart the daemon, so the 10.3.x daemon runs.<br />
<br />
Alternatively, stop the (old) daemon, run the (new) daemon in safe mode, run {{ic|mysql_upgrade}} against that, and then start the (new) daemon as described in [[#Unable to run mysql_upgrade because MySQL cannot start]].<br />
<br />
=== Checking, optimizing and repairing databases ===<br />
<br />
{{Pkg|mariadb}} ships with {{ic|mysqlcheck}} which can be used to check, repair, and optimize tables within databases from the shell. See the mysqlcheck man page for more. Several command tasks are shown:<br />
<br />
To check all tables in all databases:<br />
<br />
$ mysqlcheck --all-databases -u root -p -c<br />
<br />
To analyze all tables in all databases:<br />
<br />
$ mysqlcheck --all-databases -u root -p -a<br />
<br />
To repair all tables in all databases:<br />
<br />
$ mysqlcheck --all-databases -u root -p -r<br />
<br />
To optimize all tables in all databases:<br />
<br />
$ mysqlcheck --all-databases -u root -p -o<br />
<br />
== Backup ==<br />
<br />
There are various [https://mariadb.com/kb/en/mariadb/documentation/backing-up-and-restoring/ tools and strategies] to back up your databases.<br />
<br />
If you are using the default InnoDB storage engine, a [https://mariadb.com/kb/en/mariadb/documentation/clients-and-utilities/backup-restore-and-import/mysqldump/#examples suggested] way of backing up all your bases online while provisioning for [https://dev.mysql.com/doc/refman/5.6/en/point-in-time-recovery.html point-in-time recovery] (also known as “roll-forward,” when you need to restore an old backup and replay the changes that happened since that backup) is to execute the following command:<br />
<br />
$ mysqldump --single-transaction --flush-logs --master-data=2 --all-databases -u root -p > all_databases.sql<br />
<br />
This will prompt for '''MariaDB's''' root user's password, which was defined during database [[#Configuration]].<br />
<br />
Specifying the password on the command line is [https://dev.mysql.com/doc/refman/5.6/en/password-security-user.html strongly discouraged], as it exposes it to discovery by other users through the use of {{ic|ps aux}} or other techniques. Instead, the aforementioned command will prompt for the specified user's password, concealing it away.<br />
<br />
=== Compression ===<br />
<br />
As SQL tables can get pretty large, it is recommended to pipe the output of the aforementioned command in a compression utility like {{Pkg|gzip}}:<br />
<br />
$ mysqldump --single-transaction --flush-logs --master-data=2 --all-databases -u root -p | gzip > all_databases.sql.gz<br />
<br />
Decompressing the backup thus created and reloading it in the server is achieved by doing:<br />
<br />
$ zcat all_databases.sql.gz | mysql -u root -p<br />
<br />
This will recreate and repopulate all the databases previously backed up (see [https://stackoverflow.com/questions/23180963/restore-all-mysql-database-from-a-all-database-sql-gz-file#comment35453351_23180977 this] or [https://www.linuxquestions.org/questions/linux-server-73/how-to-restore-mysqldump-all-databases-backup-892922/ this]).<br />
<br />
=== Non-interactive ===<br />
<br />
If you want to setup non-interactive backup script for use in [[cron]] jobs or [[Systemd/cron_functionality|systemd timers]], see [https://dev.mysql.com/doc/refman/5.6/en/option-files.html option files] and [https://stackoverflow.com/a/9293090 this illustration] for ''mysqldump''.<br />
<br />
Basically you should add the following section to the relevant [[#Configuration files|configuration file]]:<br />
<br />
{{bc|1=<br />
[mysqldump]<br />
user=mysqluser<br />
password=secret<br />
}}<br />
<br />
Mentioning a user here is optional, but doing so will free you from having to mention it on the command line. If you want to set this for all tools, including {{ic|mysql}}, use the {{ic|[client]}} group.<br />
<br />
==== Example script ====<br />
<br />
The database can be dumped to a file for easy backup. The following shell script will do this for you, creating a {{ic|db_backup.gz}} file in the same directory as the script, containing your database dump:<br />
<br />
#!/bin/sh<br />
<br />
THISDIR=$(dirname $(readlink -f "$0"))<br />
<br />
mysqldump --single-transaction --flush-logs --master-data=2 --all-databases \<br />
| gzip > $THISDIR/db_backup.gz<br />
echo 'purge master logs before date_sub(now(), interval 7 day);' | mysql<br />
<br />
See also the official {{ic|mysqldump}} page in the [https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html MySQL] and [https://mariadb.com/kb/en/mariadb/documentation/clients-and-utilities/backup-restore-and-import/mysqldump MariaDB] manuals.<br />
<br />
=== Holland Backup ===<br />
<br />
A python-based software package named [https://hollandbackup.org/ Holland Backup] is available in [[AUR]] to automate all of the backup work. It supports direct mysqldump, LVM snapshots to tar files (mysqllvm), LVM snapshots with mysqldump (mysqldump-lvm), and {{pkg|xtrabackup}} methods to extract the data. The Holland framework supports a multitude of options and is highly configurable to address almost any backup situation.<br />
<br />
The main {{AUR|holland}} and {{AUR|holland-common}} packages provide the core framework; one of the sub-packages ({{AUR|holland-mysqldump}}, {{AUR|holland-mysqllvm}} and/or {{AUR|holland-xtrabackup}} must be installed for full operation. Example configurations for each method are in the {{ic|/usr/share/doc/holland/examples/}} directory and can be copied to {{ic|/etc/holland/backupsets/}}, as well as using the {{ic|holland mk-config}} command to generate a base configuration for a named provider.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unable to run mysql_upgrade because MySQL cannot start ===<br />
<br />
Try run MySQL in safemode:<br />
<br />
# mysqld_safe --datadir=/var/lib/mysql/<br />
<br />
And then run:<br />
<br />
# mysql_upgrade -u root -p<br />
<br />
=== Reset the root password ===<br />
<br />
# Stop {{ic|mariadb.service}}. <br />
# Start the mysqld server with safety features: {{bc|# mysqld_safe --skip-grant-tables --skip-networking &}}<br />
# Connect to it: {{bc|# mysql -u root}}<br />
# Change root password: {{bc|<nowiki><br />
MariaDB [(none)]> use mysql<br />
MariaDB [mysql]> flush privileges;<br />
MariaDB [mysql]> ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password';<br />
MariaDB [mysql]> exit<br />
</nowiki>}}<br />
# Kill running mysqld* processes: {{bc|# kill $(cat /var/lib/mysql/$HOSTNAME.pid)}}<br />
# Start {{ic|mariadb.service}}.<br />
<br />
=== Check and repair all tables ===<br />
<br />
Check and auto repair all tables in all databases, [https://dev.mysql.com/doc/refman/5.7/en/mysqlcheck.html see more]:<br />
<br />
# mysqlcheck -A --auto-repair -u root -p<br />
<br />
=== Optimize all tables ===<br />
<br />
Forcefully optimize all tables, automatically fixing table errors that may come up.<br />
<br />
# mysqlcheck -A --auto-repair -f -o -u root -p<br />
<br />
=== OS error 22 when running on ZFS ===<br />
<br />
If using MySQL databases on [[ZFS]], the error {{ic|InnoDB: Operating system error number 22 in a file operation}} may occur.<br />
<br />
A workaround is to disable {{ic|aio_writes}} in {{ic|/etc/my.cnf.d/my.cnf}}:<br />
<br />
{{hc|/etc/my.cnf.d/my.cnf|2=<br />
[mysqld]<br />
innodb_use_native_aio = 0<br />
}}<br />
<br />
=== Cannot login through CLI, but phpmyadmin works well ===<br />
<br />
This may happen if you are using a long (>70-75) password. As for 5.5.36, for some reason, mysql CLI cannot handle that many characters in readline mode. So, if you are planning to use the recommended password input mode:<br />
<br />
{{hc|$ mysql -u ''user'' -p|<br />
Password:<br />
}}<br />
<br />
Consider changing the password to smaller one.<br />
<br />
{{Note|You still can log in by specifying the password as an argument to mysql command.<br />
<br />
{{Warning|This behavior is considered dangerous, because your password might leak, for example, to the logs. Use it only in case of emergency and do not forget to change password right afterwards.}}<br />
<br />
$ mysql -u ''user'' -p"''some-very-strong-password''"<br />
<br />
}}<br />
<br />
=== MySQL binary logs are taking up huge disk space ===<br />
<br />
{{Out of date|section=Mistakes in "MySQL binary logs are taking up huge disk space"}}<br />
<br />
By default, mysqld creates binary log files in {{ic|/var/lib/mysql}}. This is useful for replication master server or data recovery. But these binary logs can eat up your disk space. If you do not plan to use replication or data recovery features, you may disable binary logging by commenting out these lines in {{ic|/etc/my.cnf.d/my.cnf}}:<br />
<br />
#log-bin=mysql-bin<br />
#binlog_format=mixed<br />
<br />
Or you could limit the size of the logfile like this:<br />
<br />
expire_logs_days = 10<br />
max_binlog_size = 100M<br />
<br />
Alternatively, you can purge some binary logs in {{ic|/var/lib/mysql}} to free up disk space with this command:<br />
<br />
# mysql -u root -p"PASSWORD" -e "PURGE BINARY LOGS TO 'mysql-bin.0000xx';"<br />
<br />
{{Warning|This may decrease the chances of successful data recovery when trying to repair database tables (i.e. on database corruption).}}<br />
<br />
=== OpenRC fails to start MySQL ===<br />
<br />
To use MySQL with [[OpenRC]] you need to add the following lines to the {{ic|[mysqld]}} section in the MySQL configuration file, located at {{ic|/etc/my.cnf.d/my.cnf}}.<br />
<br />
user = mysql<br />
basedir = /usr<br />
datadir = /var/lib/mysql<br />
pid-file = /run/mysqld/mysql.pid<br />
<br />
You should now be able to start MySQL using:<br />
<br />
# rc-service mysql start<br />
<br />
=== Specified key was too long ===<br />
<br />
See [[#Increase character limit]].<br />
<br />
=== Changed limits warning on max_open_files/table_open_cache ===<br />
<br />
Increase the number of file descriptors by creating a [[Systemd#Drop-in_files|systemd drop-in]], e.g.:<br />
<br />
{{hc|/etc/systemd/system/mysqld.service.d/limit_nofile.conf|2=<br />
[Service]<br />
LimitNOFILE=8192<br />
}}<br />
<br />
=== 10.4 to 10.5 upgrade crash: "InnoDB: Upgrade after a crash is not supported. The redo log was created with MariaDB 10.4.x" ===<br />
<br />
Before MariaDB 10.5, redo log was unnecessarily split into multiple files.[https://mariadb.com/kb/en/upgrading-from-mariadb-104-to-mariadb-105/]<br />
<br />
Move the old binary logs {{ic|/var/lib/mysql/ib_logfile*}} out of the way, thus letting MariaDB 10.5 create new ones. Then [[restart]] {{ic|mariadb.service}} and upgrade your tables with {{ic|mysql_upgrade}}.<br />
<br />
== See also ==<br />
<br />
* [https://mariadb.com/ MariaDB Official Website]<br />
* [https://mariadb.com/kb/en/ MariaDB knowledge Base]<br />
* [https://www.askapache.com/mysql/performance-tuning-mysql/ MySQL Performance Tuning Scripts and Know-How]</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=MariaDB&diff=731207MariaDB2022-05-31T17:57:11Z<p>Leonardodag: /* Listen only on the loopback address */ bind to localhost instead of 127.0.0.1 so that IPv6 connections are also accepted</p>
<hr />
<div>[[Category:Relational DBMSs]]<br />
[[de:MariaDB]]<br />
[[fr:MariaDB]]<br />
[[ja:MariaDB]]<br />
[[zh-hans:MariaDB]]<br />
{{Related articles start}}<br />
{{Related|phpMyAdmin}}<br />
{{Related|Adminer}}<br />
{{Related|JDBC and MySQL}}<br />
{{Related|Open Database Connectivity}}<br />
{{Related articles end}}<br />
[[Wikipedia:MariaDB|MariaDB]] is a reliable, high performance and full-featured database server which aims to be an 'always Free, backward compatible, drop-in' replacement of [[MySQL]]. Since 2013 MariaDB is Arch Linux's default implementation of MySQL.[https://archlinux.org/news/mariadb-replaces-mysql-in-repositories/]<br />
<br />
== Installation ==<br />
<br />
[https://mariadb.com/ MariaDB] is the [https://archlinux.org/news/mariadb-replaces-mysql-in-repositories/ default implementation] of MySQL in Arch Linux, provided with the {{Pkg|mariadb}} package.<br />
<br />
{{Tip|<br />
* If the database (in {{ic|/var/lib/mysql}}) resides on a [[Btrfs]] file system, you should consider disabling [[Btrfs#Copy-on-Write (CoW)|Copy-on-Write]] for the directory before creating any database.<br />
* If the database resides on a [[ZFS]] file system, you should consult [[ZFS#Databases]] before creating any database.<br />
}}<br />
<br />
[[Install]] {{Pkg|mariadb}}, and run the following command '''before starting''' the {{ic|mariadb.service}}:<br />
<br />
# mariadb-install-db --user=mysql --basedir=/usr --datadir=/var/lib/mysql<br />
<br />
{{Tip|If you use something different from {{ic|/var/lib/mysql}} for your data dir, you need to set {{ic|1=datadir=''YOUR_DATADIR''}} under section {{ic|[mysqld]}} of your {{ic|/etc/my.cnf.d/server.cnf}}.}}<br />
<br />
Now {{ic|mariadb.service}} can be [[started]] and/or [[enabled]].<br />
<br />
{{Note|Before continuing, it is recommended to [[#Improve initial security|improve the initial security]] of the MySQL installation.}}<br />
<br />
To simplify administration, you might want to install a [[MySQL#Graphical tools|front-end]].<br />
<br />
== Configuration ==<br />
<br />
{{Out of date|The main /etc/my.cnf configuration file is now split into various files in /etc/my.cnf.d/ dir.}}<br />
<br />
Once you have started the MySQL server and added a root account, you may want to change the default configuration.<br />
<br />
To log in as {{ic|root}} on the MySQL server, use the following command:<br />
<br />
# mysql -u root -p<br />
<br />
{{Note|The default password is empty. Press {{ic|Enter}} to log in.}}<br />
<br />
=== Add user ===<br />
<br />
Creating a new user takes two steps: create the user; grant privileges. In the below example, the user ''monty'' with ''some_pass'' as password is being created, then granted full permissions to the database ''mydb'': <br />
<br />
{{hc|# mysql -u root -p|<br />
MariaDB> CREATE USER 'monty'@'localhost' IDENTIFIED BY 'some_pass';<br />
MariaDB> GRANT ALL PRIVILEGES ON mydb.* TO 'monty'@'localhost';<br />
MariaDB> FLUSH PRIVILEGES;<br />
MariaDB> quit<br />
}}<br />
<br />
=== Configuration files ===<br />
<br />
''MariaDB'' configuration options are read from the following files in the given order (according to {{ic|mysqld --help --verbose {{!}} tail -20}} output):<br />
<br />
/etc/my.cnf /etc/my.cnf.d/ ~/.my.cnf<br />
<br />
Depending on the scope of the changes you want to make (system-wide, user-only...), use the corresponding file. See [https://mariadb.com/kb/en/library/configuring-mariadb-with-option-files/ this entry] of the Knowledge Base for more information.<br />
<br />
=== Enable auto-completion ===<br />
<br />
{{Note|Enabling this feature can make the client initialization longer.}}<br />
<br />
The MySQL client completion feature is disabled by default. To enable it system-wide edit {{ic|/etc/my.cnf.d/mysql-clients.cnf}}, and add {{ic|auto-rehash}} under {{ic|mysql}}. Note that this must not be placed under {{ic|mysqld}}. Completion will be enabled next time you run the MySQL client.<br />
<br />
=== Using UTF8MB4 ===<br />
<br />
{{Warning|Before changing the character set be sure to create a backup first.}}<br />
<br />
{{Note|<br />
* The {{Pkg|mariadb}} package already uses {{ic|utf8mb4}} as charset and {{ic|utf8mb4_unicode_ci}} as collation. Users using the default (character) settings may want to skip this section.<br />
* UTF8MB4 is recommended over UTF-8 since it allows full Unicode support [https://mathiasbynens.be/notes/mysql-utf8mb4] [https://stackoverflow.com/questions/30074492/what-is-the-difference-between-utf8mb4-and-utf8-charsets-in-mysql].<br />
}}<br />
<br />
[[Append]] the following values to the main configuration file located at {{ic|/etc/my.cnf.d/my.cnf}}:<br />
<br />
{{bc|1=<br />
[client]<br />
default-character-set = utf8mb4<br />
<br />
[mysqld]<br />
collation_server = utf8mb4_unicode_ci<br />
character_set_server = utf8mb4<br />
<br />
[mysql]<br />
default-character-set = utf8mb4<br />
}}<br />
<br />
[[Restart]] {{ic|mariadb.service}} to apply the changes.<br />
<br />
See [[#Maintenance]] to optimize and check the database health.<br />
<br />
=== Increase character limit ===<br />
<br />
{{Out of date|As of 10.3.1 this section is no longer applicable. All 3 options are now enabled by default. {{ic|innodb_file_format}} and {{ic|innodb_large_prefix}} are deprecated and can no longer be used. The mariadb service will fail to start if either are included in {{ic|my.cnf}} ([https://mariadb.com/kb/en/library/innodb-system-variables/#innodb_file_format source])}}<br />
<br />
{{Note|The character-limit depends on the character-set in use [https://web.archive.org/web/20181229154254/http://mechanics.flite.com/blog/2014/07/29/using-innodb-large-prefix-to-avoid-error-1071/] [https://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_large_prefix] [https://easyengine.io/tutorials/mysql/enable-innodb-file-per-table/].}}<br />
<br />
For InnoDB execute the following commands to support a higher character-limit:<br />
<br />
mysql> set global innodb_file_format = BARRACUDA;<br />
Query OK, 0 rows affected (0.00 sec)<br />
<br />
mysql> set global innodb_file_per_table = ON;<br />
Query OK, 0 rows affected (0.00 sec)<br />
<br />
mysql> set global innodb_large_prefix = ON;<br />
Query OK, 0 rows affected (0.00 sec)<br />
<br />
[[Append]] the following lines in {{ic|/etc/mysql/my.cnf}} to always use a higher character-limit:<br />
<br />
[mysqld]<br />
innodb_file_format = barracuda<br />
innodb_file_per_table = 1<br />
innodb_large_prefix = 1<br />
<br />
[[Restart]] {{ic|mariadb.service}} to apply the changes.<br />
<br />
On table creating append the {{ic|ROW_FORMAT}} as seen in the example:<br />
<br />
mysql> create table if not exists products (<br />
-> day date not null,<br />
-> product_id int not null,<br />
-> dimension1 varchar(500) not null,<br />
-> dimension2 varchar(500) not null,<br />
-> unique index unique_index (day, product_id, dimension1, dimension2)<br />
-> ) ENGINE=InnoDB ROW_FORMAT=DYNAMIC;<br />
Query OK, 0 rows affected (0.02 sec)<br />
<br />
=== Using a tmpfs for tmpdir ===<br />
<br />
The directory used by MySQL for storing temporary files is named ''tmpdir''. For example, it is used to perform disk based large sorts, as well as for internal and explicit temporary tables.<br />
<br />
Create the directory with appropriate permissions:<br />
<br />
# mkdir -pv /var/lib/mysqltmp<br />
# chown mysql:mysql /var/lib/mysqltmp<br />
<br />
Add the following [[tmpfs]] mount to your {{ic|/etc/fstab}} file:<br />
<br />
tmpfs /var/lib/mysqltmp tmpfs rw,gid=mysql,uid=mysql,size=100M,mode=0750,noatime 0 0<br />
<br />
Add to your {{ic|/etc/my.cnf.d/server.cnf}} file under the {{ic|mysqld}} group:<br />
<br />
tmpdir = /var/lib/mysqltmp<br />
<br />
[[Stop]] {{ic|mariadb.service}}, [[mount]] {{ic|/var/lib/mysqltmp/}} and [[start]] {{ic|mariadb.service}}.<br />
<br />
=== Time zone tables ===<br />
<br />
Although time zone tables are created during the installation, they are not automatically populated. They need to be populated if you are planning on using CONVERT_TZ() in SQL queries.<br />
<br />
To populate the time zone tables with all the time zones:<br />
<br />
$ mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root -p mysql<br />
<br />
Optionally, you may populate the table with specific time zone files:<br />
<br />
$ mysql_tzinfo_to_sql ''timezone_file'' ''timezone_name'' | mysql -u root -p mysql<br />
<br />
== Security ==<br />
<br />
=== Improve initial security ===<br />
<br />
The {{ic|mysql_secure_installation}} command will interactively guide you through a number of recommended security measures, such as removing anonymous accounts and removing the test database:<br />
<br />
# mysql_secure_installation<br />
<br />
{{Warning|After running this, please note that TCP port 3306 will still be open, but refusing connections with an error message. To prevent MySQL from listening on an external interface, see the [[#Listen only on the loopback address]] and [[#Enable access locally only via Unix sockets]] sections.}}<br />
<br />
=== Listen only on the loopback address ===<br />
<br />
By default, MySQL will listen on the 0.0.0.0 address, which includes all network interfaces. In order to restrict MySQL to listen only to the loopback address, add the following line in {{ic|/etc/my.cnf.d/server.cnf}}:<br />
<br />
[mysqld]<br />
bind-address = localhost<br />
<br />
This will bind to both 127.0.0.1 and ::1, and enable MariaDB to receive connections both in IPv4 and IPv6.<br />
<br />
=== Enable access locally only via Unix sockets ===<br />
<br />
By default, MySQL is accessible via both Unix sockets and the network. If MySQL is only needed for the localhost, you can improve security by not listening on TCP port 3306, and only listening on Unix sockets instead. To do this, add the following line in {{ic|/etc/my.cnf.d/server.cnf}}:<br />
<br />
[mysqld]<br />
skip-networking<br />
<br />
You will still be able to log in locally as before, but only using Unix sockets.<br />
<br />
=== Grant remote access ===<br />
<br />
{{Warning|This is not considered as best practice and may cause security issues. Consider using [[Secure Shell]], [[VNC]] or [[VPN]], if you want to maintain the MySQL server from another host inside/outside your network.}}<br />
<br />
To allow remote access to the MySQL server, ensure that MySQL has [[#Enable access locally only via Unix sockets|networking enabled]] and is [[#Listen only on the loopback address|listening on the appropriate interface]].<br />
<br />
Grant any MySQL user remote access (example for root):<br />
<br />
# mysql -u root -p<br />
<br />
Check current users with remote access privileged:<br />
<br />
SELECT User, Host FROM mysql.user WHERE Host <> 'localhost';<br />
<br />
Now grant remote access for your user (here root):<br />
<br />
GRANT ALL PRIVILEGES ON *.* TO 'root'@'192.168.1.%' IDENTIFIED BY 'my_optional_remote_password' WITH GRANT OPTION;<br />
<br />
You can change the '%' wildcard to a specific host if you like. The password can be different from user's main password.<br />
<br />
=== Configure access to home directories ===<br />
<br />
For security reasons, the systemd service file contains {{ic|1=ProtectHome=true}}, which prevents MariaDB from accessing files under the {{ic|/home}}, {{ic|/root}} and {{ic|/run/user}} hierarchies. The {{ic|datadir}} has to be in an accessible location and [[chown|owned]] by the {{ic|mysql}} user and group.<br />
<br />
You can modify this behavior by creating a supplementary service file as described [https://mariadb.com/kb/en/systemd/#configuring-access-to-home-directories here].<br />
<br />
== Maintenance ==<br />
<br />
=== Upgrade databases on major releases ===<br />
<br />
Upon a major version release of {{Pkg|mariadb}} (for example mariadb-10.1.10-1 to mariadb-10.1.18-1), it is wise to upgrade databases:<br />
<br />
# mysql_upgrade -u root -p<br />
<br />
To upgrade from 10.1.x to 10.3.x:<br />
<br />
* keep the 10.1.x database daemon running<br />
* upgrade the package<br />
* run {{ic|mysql_upgrade}} (from the new package version) against the old still-running daemon. This will produce some error messages; however, the upgrade will succeed.<br />
* restart the daemon, so the 10.3.x daemon runs.<br />
<br />
Alternatively, stop the (old) daemon, run the (new) daemon in safe mode, run {{ic|mysql_upgrade}} against that, and then start the (new) daemon as described in [[#Unable to run mysql_upgrade because MySQL cannot start]].<br />
<br />
=== Checking, optimizing and repairing databases ===<br />
<br />
{{Pkg|mariadb}} ships with {{ic|mysqlcheck}} which can be used to check, repair, and optimize tables within databases from the shell. See the mysqlcheck man page for more. Several command tasks are shown:<br />
<br />
To check all tables in all databases:<br />
<br />
$ mysqlcheck --all-databases -u root -p -c<br />
<br />
To analyze all tables in all databases:<br />
<br />
$ mysqlcheck --all-databases -u root -p -a<br />
<br />
To repair all tables in all databases:<br />
<br />
$ mysqlcheck --all-databases -u root -p -r<br />
<br />
To optimize all tables in all databases:<br />
<br />
$ mysqlcheck --all-databases -u root -p -o<br />
<br />
== Backup ==<br />
<br />
There are various [https://mariadb.com/kb/en/mariadb/documentation/backing-up-and-restoring/ tools and strategies] to back up your databases.<br />
<br />
If you are using the default InnoDB storage engine, a [https://mariadb.com/kb/en/mariadb/documentation/clients-and-utilities/backup-restore-and-import/mysqldump/#examples suggested] way of backing up all your bases online while provisioning for [https://dev.mysql.com/doc/refman/5.6/en/point-in-time-recovery.html point-in-time recovery] (also known as “roll-forward,” when you need to restore an old backup and replay the changes that happened since that backup) is to execute the following command:<br />
<br />
$ mysqldump --single-transaction --flush-logs --master-data=2 --all-databases -u root -p > all_databases.sql<br />
<br />
This will prompt for '''MariaDB's''' root user's password, which was defined during database [[#Configuration]].<br />
<br />
Specifying the password on the command line is [https://dev.mysql.com/doc/refman/5.6/en/password-security-user.html strongly discouraged], as it exposes it to discovery by other users through the use of {{ic|ps aux}} or other techniques. Instead, the aforementioned command will prompt for the specified user's password, concealing it away.<br />
<br />
=== Compression ===<br />
<br />
As SQL tables can get pretty large, it is recommended to pipe the output of the aforementioned command in a compression utility like {{Pkg|gzip}}:<br />
<br />
$ mysqldump --single-transaction --flush-logs --master-data=2 --all-databases -u root -p | gzip > all_databases.sql.gz<br />
<br />
Decompressing the backup thus created and reloading it in the server is achieved by doing:<br />
<br />
$ zcat all_databases.sql.gz | mysql -u root -p<br />
<br />
This will recreate and repopulate all the databases previously backed up (see [https://stackoverflow.com/questions/23180963/restore-all-mysql-database-from-a-all-database-sql-gz-file#comment35453351_23180977 this] or [https://www.linuxquestions.org/questions/linux-server-73/how-to-restore-mysqldump-all-databases-backup-892922/ this]).<br />
<br />
=== Non-interactive ===<br />
<br />
If you want to setup non-interactive backup script for use in [[cron]] jobs or [[Systemd/cron_functionality|systemd timers]], see [https://dev.mysql.com/doc/refman/5.6/en/option-files.html option files] and [https://stackoverflow.com/a/9293090 this illustration] for ''mysqldump''.<br />
<br />
Basically you should add the following section to the relevant [[#Configuration files|configuration file]]:<br />
<br />
{{bc|1=<br />
[mysqldump]<br />
user=mysqluser<br />
password=secret<br />
}}<br />
<br />
Mentioning a user here is optional, but doing so will free you from having to mention it on the command line. If you want to set this for all tools, including {{ic|mysql}}, use the {{ic|[client]}} group.<br />
<br />
==== Example script ====<br />
<br />
The database can be dumped to a file for easy backup. The following shell script will do this for you, creating a {{ic|db_backup.gz}} file in the same directory as the script, containing your database dump:<br />
<br />
#!/bin/sh<br />
<br />
THISDIR=$(dirname $(readlink -f "$0"))<br />
<br />
mysqldump --single-transaction --flush-logs --master-data=2 --all-databases \<br />
| gzip > $THISDIR/db_backup.gz<br />
echo 'purge master logs before date_sub(now(), interval 7 day);' | mysql<br />
<br />
See also the official {{ic|mysqldump}} page in the [https://dev.mysql.com/doc/refman/5.6/en/mysqldump.html MySQL] and [https://mariadb.com/kb/en/mariadb/documentation/clients-and-utilities/backup-restore-and-import/mysqldump MariaDB] manuals.<br />
<br />
=== Holland Backup ===<br />
<br />
A python-based software package named [https://hollandbackup.org/ Holland Backup] is available in [[AUR]] to automate all of the backup work. It supports direct mysqldump, LVM snapshots to tar files (mysqllvm), LVM snapshots with mysqldump (mysqldump-lvm), and {{pkg|xtrabackup}} methods to extract the data. The Holland framework supports a multitude of options and is highly configurable to address almost any backup situation.<br />
<br />
The main {{AUR|holland}} and {{AUR|holland-common}} packages provide the core framework; one of the sub-packages ({{AUR|holland-mysqldump}}, {{AUR|holland-mysqllvm}} and/or {{AUR|holland-xtrabackup}} must be installed for full operation. Example configurations for each method are in the {{ic|/usr/share/doc/holland/examples/}} directory and can be copied to {{ic|/etc/holland/backupsets/}}, as well as using the {{ic|holland mk-config}} command to generate a base configuration for a named provider.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Unable to run mysql_upgrade because MySQL cannot start ===<br />
<br />
Try run MySQL in safemode:<br />
<br />
# mysqld_safe --datadir=/var/lib/mysql/<br />
<br />
And then run:<br />
<br />
# mysql_upgrade -u root -p<br />
<br />
=== Reset the root password ===<br />
<br />
# Stop {{ic|mariadb.service}}. <br />
# Start the mysqld server with safety features: {{bc|# mysqld_safe --skip-grant-tables --skip-networking &}}<br />
# Connect to it: {{bc|# mysql -u root}}<br />
# Change root password: {{bc|<nowiki><br />
MariaDB [(none)]> use mysql<br />
MariaDB [mysql]> flush privileges;<br />
MariaDB [mysql]> ALTER USER 'root'@'localhost' IDENTIFIED BY 'new_password';<br />
MariaDB [mysql]> exit<br />
</nowiki>}}<br />
# Kill running mysqld* processes: {{bc|# kill $(cat /var/lib/mysql/$HOSTNAME.pid)}}<br />
# Start {{ic|mariadb.service}}.<br />
<br />
=== Check and repair all tables ===<br />
<br />
Check and auto repair all tables in all databases, [https://dev.mysql.com/doc/refman/5.7/en/mysqlcheck.html see more]:<br />
<br />
# mysqlcheck -A --auto-repair -u root -p<br />
<br />
=== Optimize all tables ===<br />
<br />
Forcefully optimize all tables, automatically fixing table errors that may come up.<br />
<br />
# mysqlcheck -A --auto-repair -f -o -u root -p<br />
<br />
=== OS error 22 when running on ZFS ===<br />
<br />
If using MySQL databases on [[ZFS]], the error {{ic|InnoDB: Operating system error number 22 in a file operation}} may occur.<br />
<br />
A workaround is to disable {{ic|aio_writes}} in {{ic|/etc/my.cnf.d/my.cnf}}:<br />
<br />
{{hc|/etc/my.cnf.d/my.cnf|2=<br />
[mysqld]<br />
innodb_use_native_aio = 0<br />
}}<br />
<br />
=== Cannot login through CLI, but phpmyadmin works well ===<br />
<br />
This may happen if you are using a long (>70-75) password. As for 5.5.36, for some reason, mysql CLI cannot handle that many characters in readline mode. So, if you are planning to use the recommended password input mode:<br />
<br />
{{hc|$ mysql -u ''user'' -p|<br />
Password:<br />
}}<br />
<br />
Consider changing the password to smaller one.<br />
<br />
{{Note|You still can log in by specifying the password as an argument to mysql command.<br />
<br />
{{Warning|This behavior is considered dangerous, because your password might leak, for example, to the logs. Use it only in case of emergency and do not forget to change password right afterwards.}}<br />
<br />
$ mysql -u ''user'' -p"''some-very-strong-password''"<br />
<br />
}}<br />
<br />
=== MySQL binary logs are taking up huge disk space ===<br />
<br />
{{Out of date|section=Mistakes in "MySQL binary logs are taking up huge disk space"}}<br />
<br />
By default, mysqld creates binary log files in {{ic|/var/lib/mysql}}. This is useful for replication master server or data recovery. But these binary logs can eat up your disk space. If you do not plan to use replication or data recovery features, you may disable binary logging by commenting out these lines in {{ic|/etc/my.cnf.d/my.cnf}}:<br />
<br />
#log-bin=mysql-bin<br />
#binlog_format=mixed<br />
<br />
Or you could limit the size of the logfile like this:<br />
<br />
expire_logs_days = 10<br />
max_binlog_size = 100M<br />
<br />
Alternatively, you can purge some binary logs in {{ic|/var/lib/mysql}} to free up disk space with this command:<br />
<br />
# mysql -u root -p"PASSWORD" -e "PURGE BINARY LOGS TO 'mysql-bin.0000xx';"<br />
<br />
{{Warning|This may decrease the chances of successful data recovery when trying to repair database tables (i.e. on database corruption).}}<br />
<br />
=== OpenRC fails to start MySQL ===<br />
<br />
To use MySQL with [[OpenRC]] you need to add the following lines to the {{ic|[mysqld]}} section in the MySQL configuration file, located at {{ic|/etc/my.cnf.d/my.cnf}}.<br />
<br />
user = mysql<br />
basedir = /usr<br />
datadir = /var/lib/mysql<br />
pid-file = /run/mysqld/mysql.pid<br />
<br />
You should now be able to start MySQL using:<br />
<br />
# rc-service mysql start<br />
<br />
=== Specified key was too long ===<br />
<br />
See [[#Increase character limit]].<br />
<br />
=== Changed limits warning on max_open_files/table_open_cache ===<br />
<br />
Increase the number of file descriptors by creating a [[Systemd#Drop-in_files|systemd drop-in]], e.g.:<br />
<br />
{{hc|/etc/systemd/system/mysqld.service.d/limit_nofile.conf|2=<br />
[Service]<br />
LimitNOFILE=8192<br />
}}<br />
<br />
=== 10.4 to 10.5 upgrade crash: "InnoDB: Upgrade after a crash is not supported. The redo log was created with MariaDB 10.4.x" ===<br />
<br />
Before MariaDB 10.5, redo log was unnecessarily split into multiple files.[https://mariadb.com/kb/en/upgrading-from-mariadb-104-to-mariadb-105/]<br />
<br />
Move the old binary logs {{ic|/var/lib/mysql/ib_logfile*}} out of the way, thus letting MariaDB 10.5 create new ones. Then [[restart]] {{ic|mariadb.service}} and upgrade your tables with {{ic|mysql_upgrade}}.<br />
<br />
=== Unable to connect from IPv6 only clients ===<br />
<br />
MariaDB in its default configuration binds to {{ic|0.0.0.0}} and is only accessible using IPv4. If you want to connect from hosts using IPv6 exclusively you have to change the servers bind accordingly. {{ic|::}} will listen on IPv6 and IPv4.<br />
<br />
{{hc|/etc/my.cnf.d/my.cnf|2=<br />
[mysqld]<br />
bind-address=::<br />
}}<br />
<br />
== See also ==<br />
<br />
* [https://mariadb.com/ MariaDB Official Website]<br />
* [https://mariadb.com/kb/en/ MariaDB knowledge Base]<br />
* [https://www.askapache.com/mysql/performance-tuning-mysql/ MySQL Performance Tuning Scripts and Know-How]</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=PipeWire&diff=698252PipeWire2021-10-04T04:50:23Z<p>Leonardodag: /* Changing the sample rate */ that character was certainly a typo, whatever it was</p>
<hr />
<div>[[Category:Multimedia]]<br />
[[fi:PipeWire]]<br />
[[ja:PipeWire]]<br />
[[pt:PipeWire]]<br />
[[ru:PipeWire]]<br />
{{Related articles start}}<br />
{{Related|PipeWire/Examples}}<br />
{{Related articles end}}<br />
<br />
[https://pipewire.org PipeWire] is a new low-level multimedia framework. It aims to offer capture and playback for both audio and video with minimal latency and support for [[PulseAudio]], [[JACK]], [[ALSA]] and [[GStreamer]]-based applications.<br />
<br />
The daemon based on the framework can be configured to be both an audio server (with PulseAudio and JACK features) and a video capture server.<br />
<br />
PipeWire also supports containers like [[Flatpak]] and does not rely on ''audio'' and ''video'' [[user group]]s. Instead, it uses a [[Polkit]]-like security model, asking Flatpak or Wayland for permission to record screen or audio.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|pipewire}} package from the official repositories.<br />
<br />
Pipewire uses [[systemd/User]] for management of the server and automatic socket activation.<br />
<br />
Optionally, install {{Pkg|pipewire-docs}} to review the documentation. Other packages, such as {{Pkg|pipewire-alsa}}, {{Pkg|pipewire-pulse}}, and {{Pkg|pipewire-jack}} are normally not needed unless one wants to [[#Audio|use PipeWire as a PulseAudio/JACK replacement]]. Also available are {{Pkg|lib32-pipewire}} and {{Pkg|lib32-pipewire-jack}} for multilib support.<br />
<br />
=== GUI ===<br />
<br />
* {{App|Helvum|GTK-based patchbay for pipewire, inspired by the JACK tool catia.|https://gitlab.freedesktop.org/ryuukyu/helvum|{{AUR|helvum}} or {{AUR|helvum-git}}}}<br />
<br />
== Usage ==<br />
<br />
=== WebRTC screen sharing ===<br />
<br />
Most applications used to rely on X11 for capturing the desktop (or individual applications), for example when using WebRTC in web browsers (e.g. on Google Hangouts). On Wayland, the sharing mechanism is handled differently for security reasons. PipeWire enables sharing content under Wayland with fine-grained access controls.<br />
<br />
This requires {{Pkg|xdg-desktop-portal}} and one of its backends [https://jgrulich.cz/2018/07/04/how-to-enable-and-use-screen-sharing-on-wayland to be installed].<br />
<br />
{{Note|1=<nowiki/><br />
* {{Pkg|xdg-desktop-portal}} 1.10.0 fixed a mismatch between specification and implementation of its D-Bus interface. [https://github.com/flatpak/xdg-desktop-portal/pull/609] <br />
* Some clients may not work with xdg-desktop-portal 1.10.0 or newer.<br />
* Current progress for [https://github.com/obsproject/obs-studio/pull/5294 OBS Studio], [https://bugs.chromium.org/p/chromium/issues/detail?id=1250940 Chromium] and [https://bugzilla.mozilla.org/show_bug.cgi?id=1731495 Firefox]<br />
}}<br />
<br />
The available backends are:<br />
<br />
* {{Pkg|xdg-desktop-portal-gtk}} for GNOME.<br />
* {{Pkg|xdg-desktop-portal-kde}} for KDE.<br />
* {{Pkg|xdg-desktop-portal-wlr}} for wlroots-based compositor (e.g. [[Sway]], [https://github.com/djpohly/dwl dwl])<br />
<br />
Firefox (84+) supports this method by default, while on Chromium (73+) one needs to enable [https://bugs.chromium.org/p/chromium/issues/detail?id=682122 WebRTC PipeWire support] by setting the corresponding (experimental) flag at the following URL:<br />
<br />
chrome://flags/#enable-webrtc-pipewire-capturer<br />
<br />
{{Pkg|obs-studio}} (27+) supports this method by using the new PipeWire capture source.<br />
<br />
For {{ic|xdg-desktop-portal-wlr}} to work, the {{ic|1=XDG_CURRENT_DESKTOP}} and {{ic|1=WAYLAND_DISPLAY}} environment variables have to be set in the [[Systemd/User#Environment_variables|systemd user session]]. {{ic|1=XDG_CURRENT_DESKTOP}} has to be set to the name of your compositor, e.g. {{ic|1=XDG_CURRENT_DESKTOP=sway}}. {{ic|1=WAYLAND_DISPLAY}} is set automatically by the compositor. The recommended way to bring these environment variables over to the systemd user session is to run {{ic|1=systemctl --user import-environment WAYLAND_DISPLAY XDG_CURRENT_DESKTOP}} after launching the compositor, e.g. with the compositors configuration file. See [https://github.com/emersion/xdg-desktop-portal-wlr#running] and [https://github.com/emersion/xdg-desktop-portal-wlr/wiki] for more details.<br />
<br />
{{Tip|To share an individual monitor with {{ic|xdg-desktop-portal-wlr}} if you have more than one, you can use configuration file options, see {{man|5|xdg-desktop-portal-wlr|SCREENCAST OPTIONS}}:<br />
{{hc|~/.config/xdg-desktop-portal-wlr/config|2=<br />
chooser_type = none<br />
output_name = ''Monitor''<br />
}}<br />
In [[Sway]], you can get the ''Monitor'' value using the {{ic|swaymsg -t get_outputs}} command.}}<br />
<br />
{{Accuracy|Since [https://github.com/flatpak/xdg-desktop-portal-gtk/pull/225 this pull request] was merged, the following note about specific app/window sharing may be not correct anymore for {{Pkg|xdg-desktop-portal-gtk}}. Also see the ticket tracking the discussion at [https://github.com/flatpak/xdg-desktop-portal-gtk/issues/204].}}<br />
<br />
Note that the only supported feature is sharing the entire desktop and not a specific app/window [https://github.com/emersion/xdg-desktop-portal-wlr/wiki/FAQ#will-this-let-me-share-individual-windows][https://github.com/KDE/xdg-desktop-portal-kde/blob/master/TODO].<br />
<br />
=== Video ===<br />
<br />
Although the software is not yet production-ready, it is safe to play around with. Most applications that rely on [[GStreamer]] to handle e.g. video streams should work out-of-the-box using the PipeWire GStreamer plugin, see [[GStreamer#PipeWire]]. Applications like e.g. {{Pkg|cheese}} are therefore already able to share video input using it.<br />
<br />
=== Audio ===<br />
<br />
PipeWire can be used as an audio server, similar to PulseAudio and JACK. It aims to replace both PulseAudio and JACK, by providing a PulseAudio-compatible server implementation and ABI-compatible libraries for JACK clients. See [https://blogs.gnome.org/uraeus/2020/09/04/pipewire-late-summer-update-2020/ this blog entry] for more information.<br />
<br />
==== ALSA/Legacy applications ====<br />
<br />
Install {{Pkg|pipewire-alsa}} to route all application using the ALSA API through PipeWire.<br />
<br />
==== PulseAudio clients ====<br />
<br />
Install {{Pkg|pipewire-pulse}}. It will replace {{Pkg|pulseaudio}} and {{Pkg|pulseaudio-bluetooth}}. Reboot, re-login or execute {{ic|systemctl start --user pipewire-pulse.service}} to see the effect. <br />
<br />
Normally, no further action is needed, as the user service {{ic|pipewire-pulse.socket}} should be enabled automatically by the package. To check if the replacement is working, run the following command and see the output:<br />
<br />
{{hc|1=$ pactl info|2=<br />
...<br />
Server Name: PulseAudio (on PipeWire 0.3.32)<br />
...<br />
}}<br />
<br />
If PipeWire does not work correctly on system startup, validate that the [[Systemd/User]] services {{ic|pipewire-pulse.service}}, {{ic|pipewire.service}}, and {{ic|pipewire-media-session.service}} are up and running. Keep in mind that {{ic|pipewire-pulse.service}} and {{ic|pipewire-pulse.socket}} have a {{ic|ConditionUser}} against running as root.<br />
<br />
==== JACK clients ====<br />
<br />
Install {{Pkg|pipewire-jack}} and use {{ic|pw-jack}} to launch JACK clients with the compatible libraries instead of the original {{ic|libjack*}}:<br />
<br />
pw-jack ''application''<br />
<br />
It is also possible to request a custom buffer size by setting a quotient of buffersize/samplerate (which equals the block latency in seconds):<br />
<br />
PIPEWIRE_LATENCY="128/48000" pw-jack ''application''<br />
<br />
Alternatively, install {{AUR|pipewire-jack-dropin}} or uninstall {{AUR|jack}}/{{Pkg|jack2}} to let JACK clients load the compatible libraries automatically.<br />
<br />
Use {{ic|ldd}} to verify that the JACK application links to the correct library:<br />
<br />
{{hc|1=$ ldd /usr/bin/qjackctl {{!}} grep -i libjack|2=<br />
libjack.so.0 => /usr/lib/pipewire-0.3/jack/libjack.so.0 (0x00007f7e5080a000)<br />
}}<br />
<br />
==== Bluetooth devices ====<br />
<br />
PipeWire handles Bluetooth audio devices if the {{Pkg|pipewire-pulse}} package is installed. More specifically, the media session daemon checks for {{ic|/etc/pipewire/media-session.d/with-pulseaudio}}, and enables its {{ic|bluez5}} module automatically if the file exists.<br />
<br />
The configuration is located in the {{ic|bluez-monitor}} configuration file, either {{ic|/etc/pipewire/media-session.d/bluez-monitor.conf}} (for system-wide configuration) or {{ic|~/.config/pipewire/media-session.d/bluez-monitor.conf}} (for user-specific configuration). A template for the configuration file can be copied from {{ic|/usr/share/pipewire/media-session.d/bluez-monitor.conf}}.<br />
<br />
===== Automatic profile selection =====<br />
<br />
To automatically switch between HSP/HFP and A2DP profiles when an input stream is detected, set the {{ic|bluez5.autoswitch-profile}} property to {{ic|true}}:<br />
<br />
{{hc|/etc/pipewire/media-session.d/bluez-monitor.conf|output=<br />
...<br />
rules = [<br />
{<br />
...<br />
actions = {<br />
update-props = {<br />
...<br />
bluez5.autoswitch-profile = true<br />
...<br />
}}<br />
<br />
==== Run PipeWire on top of native JACK ====<br />
<br />
PipeWire can also run as a JACK client on top of the native JACK daemon if desired. See [https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/JACK JACK and PipeWire] for more information.<br />
<br />
== Audio post-processing ==<br />
<br />
=== EasyEffects ===<br />
<br />
EasyEffects (former PulseEffects) is a GTK utility which provides a large array of audio effects and filters to individual application output streams and microphone input streams. Notable effects include an input/output equalizer, output loudness equalization and bass enhancement, input de-esser and noise reduction plug-in. See [https://github.com/wwmm/easyeffects the GitHub page] for a full list of effects.<br />
<br />
In order to use EasyEffects, install {{Pkg|easyeffects}}. See [https://github.com/wwmm/easyeffects/wiki/Community-presets Community Presets] for a collection of preset configurations. See [https://github.com/jaakkopasanen/AutoEq AutoEq] for collection of AI generated EQ presets for headphones.<br />
<br />
{{Note|For PulseEffects legacy version, see [[PulseAudio#PulseEffects]].}}<br />
<br />
=== NoiseTorch ===<br />
<br />
NoiseTorch is an alternative way for noise suppression. {{AUR|noisetorch}}. There also exists a binary version, {{AUR|noisetorch-bin}}, as well as a {{AUR|noisetorch-git}}.<br />
<br />
After starting it the module can be loaded for the selected microphone. It is possible to adjust the voice activation threshold, which should be set to the highest level, not filtering out any actual voice.<br />
<br />
=== LADSPA, LV2 and VST plugins ===<br />
<br />
If you want to choose between the full list of available LADSPA, LV2 and VST plugins, you can apply them using a custom Pulseaudio null sink and Carla Jack host. Install {{Pkg|pipewire-pulse}}, {{Pkg|pipewire-jack}} and {{Pkg|carla}}. At the begin, create a new Pulseaudio null sink named {{ic|default_null_sink}}.<br />
<br />
pactl load-module module-null-sink object.linger=1 media.class=Audio/Sink sink_name=default_null_sink channel_map=FL,FR<br />
<br />
Start Carla through Pipewire, {{ic|pw-jack carla-rack}}. In ''Rack'' tab add whichever plugin you want. Make sure they are ''stereo'' type. You can change their order, the one on top of the list will be the first to receive the audio stream, just like in EasyEffects. Afterwards move to ''Patchbay'' tab and connect the {{ic|default_null_sink}} L/R monitors to Carla inputs, then Carla outputs to the playbacks of your desired device (speakers, earphones, HDMI, etc). Save the configuration to a local folder, i.e. {{ic|~/Documents/carla_sink_effects.carxp}}.<br />
<br />
You can test the effects while a multimedia application is reproducing audio, i.e. watching a video on a website through Firefox. There are two methods to do it. The first one, inside Carla ''Patchbay'' tab, disconnecting all Firefox connections and linking its L/R outputs to {{ic|default_null_sink}} playbacks. The second through {{Pkg|pavucontrol}}, locating Firefox audio stream and redirecting it to {{ic|default_null_sink}} (this should remember the connection to automatically redirect the application to the same sink on the next instance).<br />
<br />
To apply these settings at startup, create two systemd user service units:<br />
<br />
{{hc|~/.config/systemd/user/jack-carla-rack.service|output=<br />
[Unit]<br />
Description=Load Carla Rack JACK host<br />
<br />
[Service]<br />
PassEnvironment="PIPEWIRE_LINK_PASSIVE=true"<br />
Type=exec<br />
ExecStart=/usr/bin/pw-jack carla-rack -n<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
{{hc|~/.config/systemd/user/pulseaudio-null-sink@.service|output=<br />
[Unit]<br />
Description=Load %i Pulseaudio null sink<br />
Before=jack-carla-rack.service<br />
After=pipewire-pulse.service<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/usr/bin/pactl load-module module-null-sink object.linger=1 media.class=Audio/Sink sink_name=%i channel_map=FL,FR<br />
ExecStop=/usr/bin/pactl unload-module module-null-sink<br />
RemainAfterExit=yes<br />
<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
<br />
Then override ''jack-carla-rack'' service specifying the full path of your Carla configuration at ''Environment'' directive:<br />
<br />
{{hc|~/.config/systemd/user/jack-carla-rack.service.d/override.conf|output=<br />
Environment="CARLA_CONFIG_FILE=/home/username/Documents/carla_sink_effects.carxp"<br />
ExecStart=<br />
ExecStart=/usr/bin/pw-jack carla-rack -n $CARLA_CONFIG_FILE<br />
}}<br />
<br />
At last, enable these two services specifying {{ic|default_null_sink}} as argument for ''pulseaudio-null-sink'' service:<br />
<br />
systemctl --user enable pulseaudio-null-sink@default_null_sink.service<br />
systemctl --user enable jack-carla-rack.service<br />
<br />
Note that if you set the {{ic|default_null_sink}} as the default device in system settings, all applications will be redirected to it and the volume keys will change its level, not the one on the speakers. If you want to control volume speakers, leave them as the default in system settings and redirect your desired application to {{ic|default_null_sink}} inside pavucontrol (Pipewire compatibility layer will remember the connection on the next instance of the same application).<br />
<br />
=== Noise suppression for voice ===<br />
<br />
Install {{AUR|noise-suppression-for-voice}} and see https://github.com/werman/noise-suppression-for-voice#pipewire. Then, set the noise cancelled source as default in your audio settings. You might need to restart your application prior being able to use it.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Out of date|Factory config files were moved from /etc/pipewire/ to /usr/share/pipewire/. System wide config can still be done in /etc/pipewire/ and user config in $HOME/.config/pipewire/, but files must be copied from /usr/share/pipewire/. https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/1609126bcd720304b7a4c81b87cc3e70ae91ff44}}<br />
<br />
=== Microphone is not detected by PipeWire ===<br />
<br />
PipeWires {{ic|alsa-monitor}} module uses {{Pkg|alsa-card-profiles}} to detect devices by default. If this is not working for you, try to turn off {{ic|api.alsa.use-acp}}, or optionally turn on {{ic|api.alsa.use-ucm}} in {{ic|/etc/pipewire/media-session.d/alsa-monitor.conf}}, under {{ic|rules}} -> the first rule -> {{ic|actions}} -> {{ic|update-props}}:<br />
<br />
...<br />
update-props = {<br />
api.alsa.use-acp = false<br />
...<br />
<br />
Then, restart pipewire and check available devices:<br />
<br />
{{hc| 1=<br />
$ pw-record --list-targets<br />
|2=<br />
Available targets ("*" denotes default): 62<br />
58: description="Built-in Audio" prio=1872<br />
60: description="Built-in Audio" prio=2000<br />
* 62: description="Built-in Audio (Loopback PCM)" prio=1984<br />
}}<br />
<br />
=== No sound after connecting to Bluetooth device ===<br />
<br />
As of 2020-12-07, if there is no sound after connecting a Bluetooth device, you might need to switch the default sink and/or move a sink input to the correct sink. Use {{ic|pactl list sinks}} to list the available sinks and {{ic|pactl set-default-sink}} to switch the default sink to the Bluetooth device. This can be automated via [[udev]] using a script similar to [https://gist.github.com/tinywrkb/04e7fd644afa9b92d33a3a99ab07ee9e this one].<br />
<br />
See this [https://www.reddit.com/r/archlinux/comments/jydd02/pipewirepulse_03164_in_testing_now_replaces/gd3m7fu/?context=3 Reddit thread] for a discussion of the issue. According to author of the script, the headset profile (HSP) might still have problems.<br />
<br />
=== Low volume ===<br />
<br />
After replacing PulseAudio with Pipewire, sound worked fine, but after a reboot, the volume was intolerably low.<br />
<br />
Open {{ic|alsamixer}}, use {{ic|F6}} to select the proper soundcard, and make sure the ALSA volumes are at 100%. {{ic|alsactl}} should maintain this setting after reboot.<br />
<br />
=== Increasing RLIMIT_MEMLOCK ===<br />
<br />
Dec 13 11:11:11 HOST pipewire-pulse[99999]: Failed to mlock memory 0x7f4f659d8000 32832: This is not a problem but for best performance, consider increasing RLIMIT_MEMLOCK<br />
<br />
Install {{Pkg|realtime-privileges}} and add your own user to the {{ic|realtime}} group.<br />
<br />
Alternatively, increasing memlock from 64kB to 128kB seems enough to fix this. If you are running {{ic|pipewire-pulse}} under [[systemd/User]], add:<br />
<br />
username soft memlock 64<br />
username hard memlock 128<br />
<br />
to {{ic|/etc/security/limits.d/username.conf}}<br />
<br />
=== Changing the sample rate ===<br />
<br />
By default PipeWire sets a global sample rate of 48kHz. If you need to change it (e.g. you own a DAC supporting a higher value) you can do it by editing the line {{ic|1=default.clock.rate = 48000}} in the configuration file {{ic|/etc/pipewire/pipewire.conf}}. For example, if you want 192kHz, uncomment and change value {{ic|48000}} to {{ic|1=default.clock.rate = 192000}}.<br />
<br />
PipeWire can also change output sample rates supported by your DAC. To configure, uncomment and set the line {{ic|1=default.clock.allowed-rates = [ 48000 ]}}, for example, {{ic|[ 44100,48000,88200,96000 ]}}. The sample rate follows the sample rate of the audio stream being played when the card is idle.<br />
<br />
To check out which output sample rate and sample format are the data sent to DAC (probably you need to change digits):<br />
cat /proc/asound/card0/pcm0p/sub0/hw_params<br />
To check out which input sample rate is used, change {{ic|pcm0p}} to {{ic|pcm0c}} ({{ic|c}} is short for "capture", {{ic|p}} is for "playback").<br />
<br />
=== Sound quality (resampling quality) ===<br />
<br />
If you used PulseAudio with {{ic|1=resample-method = speex-float-10}} or {{ic|soxr-vhq}}, then you might consider uncommenting and changing {{ic|1=resample.quality = 4}} to {{ic|10}} or the maximum {{ic|15}} in {{ic|stream.properties}} block in both {{ic|/etc/pipewire/client.conf}} and {{ic|/etc/pipewire/pipewire-pulse.conf}} (copy them from {{ic|/usr/share/pipewire/}} if they do not exist). Do not forget to restart PipeWire (without sudo): {{ic|systemctl --user restart pipewire.service pipewire-pulse.socket}} (never forget {{ic|pipewire-pulse.socket}} if you want your config changes to be applied).<br />
<br />
There is a very little quality difference between {{ic|10}} and {{ic|15}}, but the CPU load difference is 2-3x. And the latency difference between {{ic|4}}, {{ic|10}}, {{ic|15}} is yet to be investigated by anybody. {{ic|1= resample.quality = 15}} on 44100→48000 Hz on Ryzen 2600 causes {{ic|pipewire}} or {{ic|pipewire-pulse}} processes to cause 4.0% one CPU core load.<br />
<br />
You can compare resamplers here: https://src.infinitewave.ca/ (do not pay attention to anything above 18 KHz and over 120 dB). speex is listed as "Xiph.org Speex".<br />
<br />
PipeWire uses its own resampling algorithm called Spa. Like with SoX's {{ic|sox}}, Speex's {{ic|speexenc}}, PipeWire includes its standalone version: {{ic|spa-resample}}. Usage:<br />
spa-resample -q 15 -f s24 -r 48000 input16bit44100orAnythingElse.wav output24bit48000hz.wav<br />
<br />
Probably it's somehow possible to use other resamplers by creating your own sink. Or just use a plugin in your music player (e.g., Qmmp has SoX plugin).<br />
<br />
=== External sound card not activated after reconnect ===<br />
<br />
Check {{ic|~/.config/pipewire-media-session/default-profile}} if there is any entry with default profile "off" and remove it. If that does not help, remove all files from {{ic|~/.config/pipewire-media-session/}} and restart PipeWire using {{ic|systemctl --user restart pipewire.service}}.<br />
<br />
=== No Sound or pactl info shows Failure: Connection refused ===<br />
<br />
It means applications are unable to connect to the PipeWire-Pulse service, confirm that {{ic|/etc/pipewire/pipewire-pulse.conf}} exists and is not empty and restart PipeWire-Pulse using {{ic|systemctl --user restart pipewire-pulse.service}}.<br />
<br />
If that does not fix it, run {{ic|strace -f -o /tmp/pipe.txt pactl info}} and pastebin {{ic|/tmp/pipe.txt}} while seeking help on IRC ([ircs://irc.oftc.net/pipewire #pipewire] on OFTC) or the mailing-lists.<br />
<br />
=== Low audio quality on Bluetooth ===<br />
<br />
In case Bluetooth playback stutters, check {{ic|pipewire.service}} using {{ic|systemctl --user status pipewire.service}}. If there are errors like this one, <br />
<br />
Feb 17 18:23:01 HOST pipewire[249297]: (bluez_input.18:54:CF:04:00:56.a2dp-sink-60) client too slow! rate:512/48000 pos:370688 status:triggered<br />
<br />
check the currently selected codec using {{ic|pactl list sinks}} and try changing it by setting {{ic|bluez5.codecs}} to one of {{ic|sbc aac ldac aptx aptx_hd}} in<br />
<br />
{{hc|/etc/pipewire/media-session.d/bluez-monitor.conf|output=<br />
...<br />
properties = {<br />
...<br />
bluez5.codecs = [sbc]<br />
...<br />
}}<br />
<br />
Try enabling mSBC support (fixes mic on Sony 1000XM3):<br />
<br />
{{hc|/etc/pipewire/media-session.d/bluez-monitor.conf|output=<br />
...<br />
properties = {<br />
...<br />
bluez5.enable-msbc = true<br />
...<br />
}}<br />
<br />
Restart PipeWire using {{ic|systemctl --user restart pipewire.service}} for the changes to take effect.<br />
<br />
=== No devices detected after PipeWire update and reboot (git / >=0.3.23) ===<br />
<br />
As of commit [https://gitlab.freedesktop.org/pipewire/pipewire/-/commit/012a68f8ef33705f1a40ec8ac294b8cce7f6aa88 012a68f8], a new [[user unit]] has been added which is disabled by default, meaning there is no ''pipewire-media-session'' running on user login. Run this program on login by [[enabling]] the {{ic|pipewire-media-session.service}} user unit.<br />
<br />
If the user or the package manager have not sorted out the configuration file changes after update, then another instance of ''pipewire-media-session'' might be running in {{ic|pipewire.service}}. Verify whether this is the case by checking the [[unit status]] of the {{ic|pipewire.service}} user unit. If it shows ''pipewire'' and ''pipewire-media-session'' running, update your system and/or user configuration:<br />
<br />
{{hc|/etc/pipewire/pipewire.conf<br />
~/.config/pipewire/pipewire.conf|output=<br />
context.exec = {<br />
...<br />
# Line below should be commented out<br />
#"/usr/bin/pipewire-media-session" = { args = "" }<br />
...<br />
}<br />
}}<br />
<br />
=== Noticeable audio delay when starting playback ===<br />
<br />
This is caused by node suspension when inactive. It can be disabled by editing {{ic|/etc/pipewire/media-session.d/*-monitor.conf}} depending on where the delay occurs and changing property {{ic|session.suspend-timeout-seconds}} to 0 to disable or to experiment with other values and see what works. Alternatively you can comment out the line {{ic|suspend-node}} in {{ic|/etc/pipewire/media-session.d/media-session.conf}}. Restart both the {{ic|pipewire}} and {{ic|pipewire-pulse}} systemd services to apply these changes, or alternatively reboot.<br />
<br />
=== Audio cutting out when multiple streams start playing ===<br />
<br />
This problem can typically be diagnosed by running {{ic|journalctl --user -b -u pipewire-pulse}} and finding lines similar to:<br />
<br />
pipewire-pulse[21740]: pulse-server 0x56009b9d5de0: [Nightly] UNDERFLOW channel:0 offset:370676 underrun:940<br />
<br />
According to the [https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/Troubleshooting#underrununderflow-and-broken-pipe-errors official PipeWire troubleshooting guide], to solve this problem edit {{ic|/etc/pipewire/media-session.d/alsa-monitor.conf}}, uncomment the line saying {{ic|1=api.alsa.headroom = 0}} and change its value to {{ic|1024}}.<br />
<br />
=== Audio is distorted ===<br />
<br />
* For microphones, try navigating to the card that is having issues after running {{ic|alsamixer}} and use the arrow keys to reduce any "Mic Boost" or "Internal Mic Boost" options.<br />
* Uncomment the {{ic|1=default.clock.rate = 48000}} setting in {{ic|/etc/pipewire/pipewire.conf}} and reduce the value to {{ic|44100}}<br />
<br />
=== Audio problems after standby ===<br />
<br />
If the sound is missing or otherwise garbled after waking the machine up from sleep, it might help to reinitialize ALSA:<br />
<br />
# alsactl init<br />
<br />
== See also ==<br />
<br />
* [https://gitlab.freedesktop.org/pipewire/pipewire/-/wikis/home Wiki] — PipeWire Wiki on Freedesktop GitLab<br />
* [https://blogs.gnome.org/uraeus/2018/01/26/an-update-on-pipewire-the-multimedia-revolution-an-update/ Pipewire Update Blog Post] — Blog post from January 2018 outlining the state of PipeWire at the time<br />
* [https://blogs.gnome.org/uraeus/2020/09/04/pipewire-late-summer-update-2020/ PipeWire Late Summer Update 2020] — Blog post from September 2020</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Core_dump&diff=642205Core dump2020-11-23T20:46:20Z<p>Leonardodag: /* Where do they go? */ Now zstd is used</p>
<hr />
<div>[[Category:Development]]<br />
[[Category:Security]]<br />
[[ja:コアダンプ]]<br />
[[pt:Core dump]]<br />
A [[wikipedia:Core_dump|core dump]] is a file containing a process's address space (memory) when the process terminates unexpectedly. Core dumps may be produced on-demand (such as by a [[#Making a core dump|debugger]]), or automatically upon termination. Core dumps are triggered by the kernel in response to program crashes, and may be passed to a helper program (such as [https://www.freedesktop.org/software/systemd/man/systemd-coredump.html systemd-coredump]) for further processing. A core dump is not typically used by an average user, but may be passed on to developers upon request where it can be invaluable as a post-mortem snapshot of the program's state at the time of the crash, especially if the fault is hard to reliably reproduce.<br />
<br />
== Disabling automatic core dumps ==<br />
<br />
Users may wish to disable automatic core dumps for a number of reasons:<br />
* Performance: generating core dumps for memory-heavy processes can waste system resources and delay the cleanup of memory.<br />
* Disk space: core dumps of memory-heavy processes may consume disk space equal to, if not greater, than the process's memory footprint if not compressed.<br />
* Security: core dumps, although typically readable only by root, may contain sensitive data (such as passwords or cryptographic keys), which are written to disk following a crash.<br />
<br />
=== Using sysctl ===<br />
<br />
[[sysctl]] can be used to set the {{ic|kernel.core_pattern}} to nothing to disable core dump handling. Create this file[https://github.com/systemd/systemd/issues/659#issuecomment-328372788]:<br />
<br />
{{hc|/etc/sysctl.d/50-coredump.conf|2=<br />
kernel.core_pattern={{!}}/bin/false<br />
}}<br />
<br />
To apply the setting immediately, use {{ic|sysctl}}:<br />
<br />
# sysctl -p /etc/sysctl.d/50-coredump.conf<br />
<br />
=== Using systemd ===<br />
<br />
[[systemd]]'s default behavior is to generate core dumps for all processes in {{ic|/var/lib/systemd/coredump}}. This behavior can be overridden by creating a configuration snippet in the {{ic|/etc/systemd/coredump.conf.d/}} directory with the following content[https://www.freedesktop.org/software/systemd/man/coredump.conf.html#Description][https://bbs.archlinux.org/viewtopic.php?id=214207]:<br />
<br />
{{hc|/etc/systemd/coredump.conf.d/custom.conf|2=<br />
[Coredump]<br />
Storage=none<br />
}}<br />
<br />
{{Note|Do not forget to include the {{ic|[Coredump]}} section name, otherwise this option will be ignored: {{ic|systemd-coredump[1728]: [/etc/systemd/coredump.conf.d/custom.conf:1] Assignment outside of section. Ignoring.}}}}<br />
<br />
Then reload systemd's configuration.<br />
# systemctl daemon-reload<br />
<br />
This method alone is usually sufficient to disable userspace core dumps, so long as no other programs enable automatic core dumps on the system, but the coredump is still generated in memory and systemd-coredump run.<br />
<br />
=== Using PAM limits ===<br />
<br />
The maximum core dump size for users logged in via [[PAM]] is enforced by [[limits.conf]]. Setting it to zero disables core dumps entirely. [http://www.cyberciti.biz/faq/linux-disable-core-dumps/]<br />
{{hc|/etc/security/limits.conf|<br />
* hard core 0}}<br />
<br />
=== Using ulimit ===<br />
<br />
[[Command-line shell]]s such as ''bash'' or ''zsh'' provide a builtin ''ulimit'' command which can be used to report or set resource limits of the shell and the processes started by the shell. See {{man|1|bash|SHELL BUILTIN COMMANDS}} or {{man|1|zshbuiltins}} for details.<br />
<br />
To disable core dumps in the current shell:<br />
<br />
$ ulimit -c 0<br />
<br />
== Making a core dump ==<br />
<br />
To generate a core dump of an arbitrary process, first [[install]] the {{Pkg|gdb}} package. Then find the PID of the running process, for example with ''pgrep'':<br />
<br />
{{hc|$ pgrep -f ''firefox''|<br />
2071 firefox<br />
}}<br />
<br />
Attach to the process:<br />
<br />
$ gdb -p 2071<br />
<br />
Then at the {{ic|(gdb)}} prompt:<br />
<br />
(gdb) generate-core-file<br />
Saved corefile core.2071<br />
(gdb) quit<br />
<br />
Now you have a coredump file called {{ic|core.2071}}.<br />
<br />
=== Where do they go? ===<br />
<br />
The {{ic|kernel.core_pattern}} [[sysctl]] decides where automatic core dumps go. By default, core dumps are sent to ''systemd-coredump'' which can be configured in {{ic|/etc/systemd/coredump.conf}}. By default, all core dumps are stored in {{ic|/var/lib/systemd/coredump}} (due to {{ic|1=Storage=external}}) and they are compressed with {{ic|zstd}} (due to {{ic|1=Compress=yes}}). Additionally, various size limits for the storage can be configured.<br />
<br />
{{Note|The default value for {{ic|kernel.core_pattern}} is set in {{ic|/usr/lib/sysctl.d/50-coredump.conf}}. This file may be masked or overridden to use a different setting following normal {{man|5|sysctl.d}} rules.}}<br />
<br />
To retrieve a core dump from the journal, see {{man|1|coredumpctl}}.<br />
<br />
== Examining a core dump ==<br />
<br />
Use ''coredumpctl'' to find the corresponding dump:<br />
# coredumpctl list<br />
<br />
You need to uniquely identify the relevant dump. This is possible by specifying a {{ic|PID}}, name of the executable, path to the executable or a journalctl predicate (see {{man|1|coredumpctl}} and {{man|1|journalctl}} for details). To see details of the core dumps:<br />
# coredumpctl info ''match''<br />
<br />
Pay attention to "Signal" row, that helps to identify crash cause. For deeper analysis you can examine the backtrace using ''gdb'':<br />
# coredumpctl gdb ''match''<br />
<br />
When ''gdb'' is started, use the {{ic|bt}} command to print the backtrace:<br />
(gdb) bt<br />
<br />
See [[Debug - Getting Traces]] if debugging symbols are requested, but not found.<br />
<br />
== Cleanup of core dump files ==<br />
<br />
The core dump files stored in {{ic|/var/lib/systemd/coredump/}} will be automatically cleaned by {{ic|systemd-tmpfiles --clean}}, which is triggered daily with {{ic|systemd-tmpfiles-clean.timer}}. Core dumps are configured to persist for at least 3 days, see {{ic|systemd-tmpfiles --cat-config}}.<br />
<br />
== See also ==<br />
<br />
* [http://lcamtuf.coredump.cx/afl/ american fuzzy lop] - A tool for automated tests of the kernel and programs <br />
* [https://lwn.net/Articles/637151/ Filesystem fuzzing] - LWN article about testing filesystems for bugs</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Icecast&diff=451839Icecast2016-09-24T22:31:21Z<p>Leonardodag: /* Step 3: Configure MPD to be an Icecast Source */ MPD itself has a null output, no need to send it to alsa's null output</p>
<hr />
<div>[[Category:Streaming]]<br />
{{Style|See [[Help:Style]].}}<br />
<br />
'''Icecast''' is a program for streaming media such as audio and video across a network.<br />
Different types of clients connect to the IceCast server, either to provide a "mount point", control the server, or listen to the audio being cast.<br />
<br />
Icecast has support for streaming many audio streams simultaneously - each stream has a "mount point" which a client can access, usually through a network uri, such as:<br />
<nowiki>http://server:8000/mpd.ogg.m3u</nowiki><br />
<br />
This refers to a mount point called "mpd".<br />
<br />
==Setting up Icecast==<br />
*[[Install]] {{Pkg|icecast}}. Alternatively, you can build and install the {{AUR|icecast-kh}} package. Icecast-kh (Karl Heyes) extends on the official release with features that may be (if found to be working out well) merged into next official releases.<br />
*Edit the configuration file.<br />
Open up /etc/icecast.xml in your text editor.<br />
The main section you want to pay attention to is <authentication>. Inside the <authentication> block there are all the passwords that icecast use. '''It is strongly recommended''' that you change them.<br />
Icecast defaults to listening on port 8000, and you may also change that if you wish.<br />
<br />
Since icecast 2.3.2-4 the daemon is started as nobody user. Icecast-kh starts as icecast user by default. To change this behavior, pay attention to the <changeowner> section.<br />
<br />
==Icecast paths==<br />
===Local user===<br />
Note that if you are running icecast under a local user (i.e. one that does not use /etc/icecast.xml) then you will need to copy the icecast web xml files from /usr/share otherwise you will get errors about XSLT and the web interface will not work.<br />
{{bc|<br />
$ cp -R /usr/share/icecast/web ~/icecast/<br />
}}<br />
Also, make sure that the <changeowner> section is commented out, as changing the owner of a process requires root privileges.<br />
<br />
==Running icecast==<br />
<br />
*Start icecast<br />
You can start icecast as a single user by executing:<br />
# icecast -b -c /etc/icecast.xml<br />
If you want icecast to remain in the foreground of your terminal, remove the -b flag.<br />
<br />
To run icecast as a system daemon, [[start]] the {{ic|icecast.service}} systemd unit.<br />
<br />
To run icecast at system boot, [[enable]] the systemd unit.<br />
<br />
*Test it.<br />
Make sure Icecast is running by opening up http://localhost:8000/ in your web browser. You should be greeted by an Icecast2 Status page. This indicates everything is running properly.<br />
<br />
Or run<br />
# systemctl status icecast<br />
<br />
==Streaming with MPD==<br />
<br />
MPD is a program for playing music via a daemon process instead of using a client. It also incorporates a music database for quick access, playlists, and a variety of front-end options.<br />
<br />
{{Note|MPD has its own <u>built-in</u> HTTP Streaming, and using Icecast+mpd may not be needed. See [[Music Player Daemon/Tips and tricks#HTTP_Streaming|Music Player Daemon : HTTP Streaming]] for more information.}}<br />
<br />
===Step 1: Set Up MPD and Install a Client===<br />
Use the [[mpd|MPD Install Guide]] to install and configure MPD and a client.<br />
<br />
===Step 2: Ensure Icecast is running===<br />
Start Icecast in first, or mpd will not have anything to stream :<br />
<br />
# systemctl start icecast<br />
<br />
===Step 3: Configure MPD to be an Icecast Source===<br />
Edit /etc/mpd.conf and enable the Icecast audio_output by adding the following:<br />
<br />
{{bc|<br />
audio_output {<br />
type "shout"<br />
encoding "ogg"<br />
name "my cool stream"<br />
host "localhost"<br />
port "8000"<br />
mount "/mpd.ogg"<br />
<br />
# This is the source password in icecast.xml<br />
password "hackme"<br />
<br />
# Set either quality or bit rate<br />
# quality "5.0"<br />
bitrate "64"<br />
<br />
format "44100:16:1"<br />
<br />
# Optional Parameters<br />
user "source"<br />
# description "here is my long description"<br />
# genre "jazz"<br />
} # end of audio_output<br />
<br />
# Need this so that mpd still works if icecast is not running<br />
audio_output {<br />
type "null"<br />
name "fake out"<br />
}<br />
}}<br />
<br />
===Step 4: Running MPD with Icecast===<br />
Now you can start mpd :<br />
<br />
# systemctl start mpd<br />
<br />
Note that icecast must be started first for the stream to work.<br />
<br />
===Step 5: Test / use the stream===<br />
Now that you have installed the necessary software you probably want to test/use the stream. Realize that you will need your client to do two things:<br />
#Connect to the mpd server so you can control it<br />
#Connect to the stream to actually hear the music. Connecting to the mpd server will alter output to the Icecast server but you will not hear it.<br />
<br />
Sonata (a graphical mpd client) and mplayer (a command line client) are just two of the available clients. Note that if you use mplayer, you will need another way to control the remote mpd server (for example ssh)<br />
<br />
===mpd===<br />
You can play an icecast stream from another mpd instance, on another computer, for example.<br />
<br />
Use mpc to add the url to mpd's playlist<br />
$ mpc add http://ip.of.server:8000/mpd.ogg.m3u<br />
<br />
You can then play the stream as if it was a song belonging to your local mpd instance.<br />
<br />
===Sonata===<br />
*[[Install]] the {{pkg|sonata}} package.<br />
*Start it up and you should be greeted by Sonata's preferences.<br />
*Set 'Name' to the name of your server.<br />
*Set 'Host' to the IP address of your server.<br />
*Set 'Port' to '6600'.<br />
*Click the '+' and repeat the previous steps but instead about your local computer (i.e. its name and IP).<br />
*Right-click->'Connections' and select your server. Then click on the 'Library' tab, if all is well, you should see your entire music selection that is on your server. Find a folder, right-click and click 'Add'. Clicking on the 'Current' tab will show you your current playlist, which should have the contents of whatever folder you just chose from the library. Double-click on a song. You should see the text get bold and the progress bar show up, just like it is playing, but you will not hear anything. Fear not.<br />
*Right-click->'Connections' and select your local computer. Then click the 'Streams' tab. Right-click and click 'New'. Make 'Stream Name' the name from your servers /etc/mpd.conf file's audio_output { } section and make the URL IP.of.server:8000/mpd.ogg.m3u. Double-click on this stream.<br />
*Click on the 'Current' tab and you will see the URL of the stream as your only item. Double-click on it and after a delay you should hear whatever song you had chosen on the server.<br />
<br />
===MPlayer===<br />
*[[Install]] the {{pkg|mplayer}} package.<br />
*Start it, telling it to play the playlist that icecast places in the icecast root directory (the playlist redirects mplayer to mpd.ogg)<br />
$ mplayer -playlist http://ip.of.server:8000/mpd.ogg.m3u<br />
To control the remote mpd server, if you have an ssh server on the same machine, you can login and use [[ncmpcpp]]] to control it.<br />
<br />
Or, if your mpd server is listening on an accessible interface/port ({{ic|$ ss -p -l -t}} on the mpd machine will show mpd listening on 0.0.0.0, for example) then you can set the MPD_HOST variable which directs a local client like mpc to the remote server.<br />
$ export MPD_HOST=ip.of.server<br />
$ export MPD_PORT=6600 # optional<br />
$ mpc play<br />
<br />
==Streaming with oggfwd and ffmpeg2theora==<br />
If you want to stream a single track, for example, you can use this method instead of changing your mpd setup.<br />
*[[Install]] the {{pkg|ffmpeg2theora}} and {{AUR|oggfwd}} packages.<br />
<br />
*Start icecast using a previously setup config file using<br />
$ icecast -c path/to/config.xml<br />
or [[start]] the systemd unit {{ic|icecast}} instead.<br />
*Start ffmpeg2theora, sending its output to oggfwd, which forwards to the icecast server for you.<br />
{{bc|<nowiki><br />
$ ffmpeg2theora --no-skeleton --novideo -o - path/to/audio/file | \<br />
oggfwd localhost 8000 source_password_here /mountpoint_name_here.ogg<br />
</nowiki>}}<br />
<br />
Alternatively, you can use this script:<br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
<br />
if [ $# -eq 1 ] <br />
then<br />
music="$1"<br />
else<br />
echo "Usage: $0 music-file"<br />
exit 1<br />
fi<br />
<br />
pass="source_password"<br />
mountpt="mount_point_name"<br />
<br />
set -e<br />
ffmpeg2theora --no-skeleton --novideo -o - "$music" 2> /dev/null | \ <br />
oggfwd localhost 8000 "$pass" /"$mountpt".ogg<br />
</nowiki>}}<br />
<br />
==Playing the stream==<br />
<br />
The above mentioned sonata and mplayer methods can be used.<br />
<br />
==References==<br />
* [http://mpd.wikia.com/wiki/Configuration MPD Wiki: Configuration]<br />
* [http://en.flossmanuals.net/TheoraCookbook/FfmpegStreaming] - oggfwd and ffmpeg2theora howto.</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Kernel&diff=386223Kernel2015-07-22T01:18:05Z<p>Leonardodag: /* Patches and Patchsets */ BLD is *not* a scheduler. It's a load distribution technique.</p>
<hr />
<div>[[Category:Kernel]]<br />
[[cs:Kernel Compilation]]<br />
[[es:Kernels]]<br />
[[fr:Noyaux Linux]]<br />
[[it:Kernels]]<br />
[[ja:カーネル]]<br />
[[ru:Kernels]]<br />
[[zh-CN:Kernels]]<br />
{{Related articles start}}<br />
{{Related|Kernel modules}}<br />
{{Related|Kernel Panics}}<br />
{{Related|Linux-ck}}<br />
{{Related|sysctl}}<br />
{{Related articles end}}<br />
<br />
From [[Wikipedia:Kernel (computing)|Wikipedia]]:<br />
:''the kernel is the main component of most computer operating systems; it is a bridge between applications and the actual data processing done at the hardware level. The kernel's responsibilities include managing the system's resources (the communication between hardware and software components).''<br />
<br />
There are various alternative kernels available for Arch Linux in addition to the mainline Linux kernel. This article lists some of the options available in the repositories with a brief description of each. There is also a description of patches that can be applied to the system's kernel. The article ends with an overview of custom kernel compilation with links to various methods.<br />
<br />
==Precompiled kernels==<br />
===Official packages===<br />
;{{Pkg|linux}}<br />
:The Linux kernel and modules from the [core] repository. Vanilla kernel with [https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux a few patches applied].<br />
<br />
;{{Pkg|linux-lts}}<br />
:Long term support (LTS) Linux kernel and modules from the [core] repository.<br />
<br />
;{{Pkg|linux-grsec}}<br />
:The Linux Kernel and modules with [[Grsecurity Patchset]] and PaX patches for increased security.<br />
<br />
===AUR packages===<br />
;{{AUR|linux-aufs_friendly}}<br />
:The aufs-compatible linux kernel and modules, useful when using [[docker]].<br />
<br />
;{{AUR|linux-apparmor}}<br />
:Linux kernel with [[AppArmor]] capabilities enabled.<br />
<br />
;{{AUR|linux-bfs}}<br />
:Linux kernel and modules with the [[Wikipedia:Brain_Fuck_Scheduler|Brain Fuck Scheduler]] (BFS) - created by Con Kolivas for desktop computers with fewer than 4096 cores, with BFQ I/O scheduler as optional.<br />
<br />
;{{AUR|linux-chromebook}}<br />
:The Linux kernel with patches added to support chromebook hardware.<br />
<br />
;{{AUR|linux-ck}}<br />
:Linux Kernel built with Con Kolivas' ck1 patchset.<br />
:Additional options which can be toggled on/off in the [[PKGBUILD]] include: BFQ scheduler, nconfig, localmodconfig and use running kernel's config.<br />
:These are patches designed to improve system responsiveness with specific emphasis on the desktop, but suitable to any workload. The ck patches include BFS.<br />
:For further information and installation instructions, please read the [[linux-ck]] main article.<br />
<br />
;{{AUR|linux-eee-ck}}<br />
:The Linux Kernel and modules for the Asus Eee PC 701, built with Con Kolivas' ck1 patchset.<br />
<br />
;{{AUR|linux-fbcondecor}}<br />
:The Linux Kernel and modules with [[Fbsplash|fbcondecor support]]. <br />
<br />
;{{AUR|linux-git}}<br />
:Linux kernel and modules built using sources from [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git Linus Torvalds' Git repository].<br />
<br />
;{{AUR|linux-ice}}<br />
:The Linux Kernel and modules with gentoo-sources patchset and [[TuxOnIce]] support.<br />
<br />
;{{AUR|linux-libre}}, {{AUR|linux-libre-lts}}, {{AUR|linux-libre-grsec}}, {{AUR|linux-libre-rt}}, {{AUR|linux-libre-xen}}<br />
:The Linux Kernels without "binary blobs".<br />
<br />
;{{AUR|linux-lqx}}<br />
:[http://liquorix.net Liquorix] is a distro kernel replacement built using a Debian-targeted configuration and the ZEN kernel sources. Designed for desktop, multimedia, and gaming workloads, it is often used as a Debian Linux performance replacement kernel. Damentz, the maintainer of the Liquorix patchset, is a developer for the ZEN patchset as well.<br />
<br />
;{{AUR|linux-lts34}}<br />
:The Linux 3.4 Long-Term Support Kernel and modules.<br />
<br />
;{{AUR|linux-lts310}}<br />
:The Linux 3.10 Long-Term Support Kernel and modules.<br />
<br />
;{{AUR|linux-lts312}}<br />
:The Linux 3.12 Long-Term Support Kernel and modules.<br />
<br />
;{{AUR|linux-mainline}}<br />
:The Mainline Linux Kernel and modules.<br />
<br />
;{{AUR|linux-mptcp}}<br />
:The Linux Kernel and modules with [http://multipath-tcp.org/ Multipath TCP] support.<br />
<br />
;{{AUR|kernel-netbook}}<br />
:Static kernel for netbooks with Intel Atom N270/N280/N450/N550 such as the Eee PC with the add-on of external firmware ({{AUR|broadcom-wl}}) and patchset (BFS + TuxOnIce + BFQ optional) - Only Intel GPU<br />
<br />
;{{AUR|linux-pax}}<br />
:The Linux Kernel and modules with [[PaX]] patches for increased security.<br />
<br />
;{{AUR|linux-pf}}<br />
:Linux kernel and modules with the pf-kernel patch [-ck patchset (BFS included), TuxOnIce, BFQ] and aufs3.<br />
<br />
;{{AUR|linux-tresor}}/{{AUR|linux-lts-tresor}}<br />
:The current/LTS Linux Kernel and modules with integrated [https://www1.informatik.uni-erlangen.de/tresor TRESOR]<br />
<br />
;{{AUR|linux-zen}}<br />
:The [https://github.com/zen-kernel/zen-kernel ZEN Kernel] is the result of a collaborative effort of kernel hackers to provide the best Linux kernel possible for every day systems. Builds of a ZEN kernel are available [https://bbs.archlinux.org/viewtopic.php?id=117157 in this repository].<br />
<br />
==Patches and Patchsets==<br />
<br />
There are lots of reasons to patch your kernel, the major ones are for performance or support for non-mainline features such as reiser4 file system support. Other reasons might include fun and to see how it is done and what the improvements are.<br />
<br />
However, it is important to note that the best way to increase the speed of your system is to first tailor your kernel to your system, especially the architecture and processor type. For this reason using pre-packaged versions of custom kernels with generic architecture settings is not recommended or really worth it. A further benefit is that you can reduce the size of your kernel (and therefore build time) by not including support for things you do not have or use. For example, you might start with the stock kernel config when a new kernel version is released and remove support for things like bluetooth, video4linux, 1000Mbit ethernet, etc.; functionality you know you will not require for your specific machine. Although this page is not about customizing your kernel config, it is recommended as a first step--before moving on to using a patchset once you have grasped the fundamentals involved.<br />
<br />
The config files for the Arch kernel packages can be used as a starting point. They are in the Arch package source files, for example [https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux] linked from {{Pkg|linux}}. The config file of your currently running kernel is also always available in your file system at {{ic|/proc/config.gz}}.<br />
<br />
===How to install===<br />
<br />
The installation process of custom kernel packages relies on the Arch Build System (ABS). If you have not built any custom packages yet you may consult the following articles: [[Arch Build System]] and [[Creating packages]].<br />
<br />
If you have not actually patched or customized a kernel before it is not that hard and there are many PKGBUILDs on the forum for individual patchsets. However, you are advised to start from scratch with a bit of research on the benefits of each patchset, rather than just arbitrarily picking one. This way you will learn much more about what you are doing rather than just choosing a kernel at startup and then be left wondering what it actually does.<br />
<br />
See [[#Compilation]].<br />
<br />
{{note|Do not forget to change the boot options in your bootloader, e.g. [[GRUB]], to use the new kernel.}}<br />
<br />
===Major patchsets===<br />
<br />
First of all it is important to note that patchsets are developed by a variety of people. Some of these people are actually involved in the production of the linux kernel and others are hobbyists, which may reflect its level of reliability and stability.<br />
<br />
It is also worth noting that some patchsets are built on the back of other patchsets (which may or may not be reflected in the title of the patch). Patchsets (and kernel updates) can be released '''very''' frequently and often it is not worth keeping up with ALL of them so do not go crazy, unless you make it your hobby!<br />
<br />
You can search google for more sets - remember to use quotes {{ic|"-nitro"}} for example otherwise google will deliberately '''NOT''' show the results you want!<br />
<br />
{{note|This section is for '''information only''' - clearly no guarantees of stability or reliability are implied by inclusion on this page.}}<br />
<br />
====-ck====<br />
[[Linux-ck]] contains patches designed to improve system responsiveness with specific emphasis on the desktop, but suitable to any workload. The patches are created and maintained by Con Kolivas, his site is at http://users.on.net/~ckolivas/kernel/. Con maintains a full set but also provides the patches broken down so you can add only those you prefer.<br />
<br />
The -ck patches can be found at http://ck.kolivas.org/patches/3.0/<br />
<br />
====-rt====<br />
<br />
This patchset is maintained by a small group of core developers, led by Ingo Molnar. This patch allows nearly all of the kernel to be preempted, with the exception of a few very small regions of code ("raw_spinlock critical regions"). This is done by replacing most kernel spinlocks with mutexes that support priority inheritance, as well as moving all interrupt and software interrupts to kernel threads. <br />
<br />
It further incorporates high resolution timers - a patch set, which is independently maintained.<br />
<br />
[as said from the [https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch Real-Time Linux Wiki]]<br />
<br />
patch at https://www.kernel.org/pub/linux/kernel/projects/rt/<br />
<br />
====-bld====<br />
{{Warning|This patch is in development.}}<br />
BLD is best described as a O(1) CPU picking technique. Which is done by reordering CPU runqueues based on runqueue loads. In other words, it keeps the scheduler aware of the load changes, which helps scheduler to keep runqueues in an order. This technique does not depend on scheduler ticks. The two most simple things in this technique are: load tracking and runqueue ordering; these are relatively simpler operations. Load tracking will be done whenever a load change happens on the system and based on this load change runqueue will be ordered. So, if we have an ordered runqueue from lowest to highest, then picking the less (or even busiest) runqueue is easy. Scheduler can pick the lowest runqueue without calculation and comparison at the time of placing a task in a runqueue. And while trying to distribute load at sched_exec and sched_fork our best choice is to pick the lowest busiest runqueue of the system. And in this way, system remains balanced without doing any load balancing. At the time of try_to_wake_up picking the idlest runqueue is topmost priority but it has been done as per domain basis to utilize CPU cache properly and it's an area where more concentration is requires.<br />
<br />
Google Code web page: https://code.google.com/p/bld/<br />
<br />
====-grsecurity====<br />
<br />
[[Grsecurity]] is a security focused patchset. It adds numerous security related features such as Role-Based Access Control and utilizes features of the PaX project. It can be used on a desktop but a public server would receive the greatest benefit. Some applications are incompatible with the additional security measures implemented by this patchset. If this occurs, consider using a lower security level.<br />
<br />
The -grsecurity patches can be found at https://grsecurity.net<br />
<br />
====Tiny-Patches====<br />
The goal of [http://elinux.org/Linux_Tiny Linux Tiny] is to reduce its memory and disk footprint, as well as to add features to aid working on small systems. Target users are developers of embedded system and users of small or legacy machines such as 386s.<br />
<br />
Patch releases against the mainstream Linux kernel have been discontinued. The developers chose to focus on a few patches and spend their time trying to get them merged into the mainline kernel.<br />
<br />
====-pf====<br />
{{AUR|linux-pf}} is yet another Linux kernel fork which provides you with a handful of awesome features not merged into mainline. It is based on neither existing Linux fork nor patchset, although some unofficial ports may be used if required patches have not been released officially.<br />
The most prominent patches of linux-pf are TuxOnIce, the CK patchset (most notably BFS), AUFS3, LinuxIMQ, l7 filter and BFQ.<br />
<br />
See [[linux-pf]] for more information.<br />
<br />
===Individual patches===<br />
<br />
These are patches which can be simply included in any build of a vanilla kernel or incorporated (probably with some major tweaking) into another patchset. Some common ones follow.<br />
<br />
====Reiser4====<br />
<br />
[[Reiser4]]<br />
<br />
====fbsplash====<br />
[[fbsplash]]<br />
<br />
== Compilation ==<br />
Arch Linux provides for several methods of kernel compilation.<br />
<br />
=== Using the Arch Build System ===<br />
Using the [[Arch Build System]] takes advantage of the high quality of the existing {{Pkg|linux}} [[PKGBUILD]] and the benefits of [[Wikipedia:Package management system|package management]]. The PKGBUILD is structured so that you can stop the build after the source is downloaded and configure the kernel.<br />
<br />
See [[Kernels/Compilation/Arch Build System]].<br />
<br />
=== Traditional ===<br />
This involves manually downloading a source tarball, and compiling in your home directory as a normal user. Once configured, two installation methods are available; the traditional manual method, or with [[Makepkg]] + [[Pacman]].<br />
<br />
An advantage of learning the traditional method is that it is ''not'' distribution-specific. <br />
<br />
See [[Kernels/Compilation/Traditional]].<br />
<br />
===Proprietary NVIDIA driver===<br />
See [[NVIDIA#Alternate install: custom kernel]] for instructions on using the proprietary NVIDIA driver with a custom kernel.<br />
<br />
== See also ==<br />
*[http://www.kroah.com/lkn/ O'Reilly - Linux Kernel in a Nutshell] (free ebook)</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Kernel&diff=386219Kernel2015-07-22T01:12:33Z<p>Leonardodag: /* Individual patches */ removed the first person</p>
<hr />
<div>[[Category:Kernel]]<br />
[[cs:Kernel Compilation]]<br />
[[es:Kernels]]<br />
[[fr:Noyaux Linux]]<br />
[[it:Kernels]]<br />
[[ja:カーネル]]<br />
[[ru:Kernels]]<br />
[[zh-CN:Kernels]]<br />
{{Related articles start}}<br />
{{Related|Kernel modules}}<br />
{{Related|Kernel Panics}}<br />
{{Related|Linux-ck}}<br />
{{Related|sysctl}}<br />
{{Related articles end}}<br />
<br />
From [[Wikipedia:Kernel (computing)|Wikipedia]]:<br />
:''the kernel is the main component of most computer operating systems; it is a bridge between applications and the actual data processing done at the hardware level. The kernel's responsibilities include managing the system's resources (the communication between hardware and software components).''<br />
<br />
There are various alternative kernels available for Arch Linux in addition to the mainline Linux kernel. This article lists some of the options available in the repositories with a brief description of each. There is also a description of patches that can be applied to the system's kernel. The article ends with an overview of custom kernel compilation with links to various methods.<br />
<br />
==Precompiled kernels==<br />
===Official packages===<br />
;{{Pkg|linux}}<br />
:The Linux kernel and modules from the [core] repository. Vanilla kernel with [https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux a few patches applied].<br />
<br />
;{{Pkg|linux-lts}}<br />
:Long term support (LTS) Linux kernel and modules from the [core] repository.<br />
<br />
;{{Pkg|linux-grsec}}<br />
:The Linux Kernel and modules with [[Grsecurity Patchset]] and PaX patches for increased security.<br />
<br />
===AUR packages===<br />
;{{AUR|linux-aufs_friendly}}<br />
:The aufs-compatible linux kernel and modules, useful when using [[docker]].<br />
<br />
;{{AUR|linux-apparmor}}<br />
:Linux kernel with [[AppArmor]] capabilities enabled.<br />
<br />
;{{AUR|linux-bfs}}<br />
:Linux kernel and modules with the [[Wikipedia:Brain_Fuck_Scheduler|Brain Fuck Scheduler]] (BFS) - created by Con Kolivas for desktop computers with fewer than 4096 cores, with BFQ I/O scheduler as optional.<br />
<br />
;{{AUR|linux-chromebook}}<br />
:The Linux kernel with patches added to support chromebook hardware.<br />
<br />
;{{AUR|linux-ck}}<br />
:Linux Kernel built with Con Kolivas' ck1 patchset.<br />
:Additional options which can be toggled on/off in the [[PKGBUILD]] include: BFQ scheduler, nconfig, localmodconfig and use running kernel's config.<br />
:These are patches designed to improve system responsiveness with specific emphasis on the desktop, but suitable to any workload. The ck patches include BFS.<br />
:For further information and installation instructions, please read the [[linux-ck]] main article.<br />
<br />
;{{AUR|linux-eee-ck}}<br />
:The Linux Kernel and modules for the Asus Eee PC 701, built with Con Kolivas' ck1 patchset.<br />
<br />
;{{AUR|linux-fbcondecor}}<br />
:The Linux Kernel and modules with [[Fbsplash|fbcondecor support]]. <br />
<br />
;{{AUR|linux-git}}<br />
:Linux kernel and modules built using sources from [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git Linus Torvalds' Git repository].<br />
<br />
;{{AUR|linux-ice}}<br />
:The Linux Kernel and modules with gentoo-sources patchset and [[TuxOnIce]] support.<br />
<br />
;{{AUR|linux-libre}}, {{AUR|linux-libre-lts}}, {{AUR|linux-libre-grsec}}, {{AUR|linux-libre-rt}}, {{AUR|linux-libre-xen}}<br />
:The Linux Kernels without "binary blobs".<br />
<br />
;{{AUR|linux-lqx}}<br />
:[http://liquorix.net Liquorix] is a distro kernel replacement built using a Debian-targeted configuration and the ZEN kernel sources. Designed for desktop, multimedia, and gaming workloads, it is often used as a Debian Linux performance replacement kernel. Damentz, the maintainer of the Liquorix patchset, is a developer for the ZEN patchset as well.<br />
<br />
;{{AUR|linux-lts34}}<br />
:The Linux 3.4 Long-Term Support Kernel and modules.<br />
<br />
;{{AUR|linux-lts310}}<br />
:The Linux 3.10 Long-Term Support Kernel and modules.<br />
<br />
;{{AUR|linux-lts312}}<br />
:The Linux 3.12 Long-Term Support Kernel and modules.<br />
<br />
;{{AUR|linux-mainline}}<br />
:The Mainline Linux Kernel and modules.<br />
<br />
;{{AUR|linux-mptcp}}<br />
:The Linux Kernel and modules with [http://multipath-tcp.org/ Multipath TCP] support.<br />
<br />
;{{AUR|kernel-netbook}}<br />
:Static kernel for netbooks with Intel Atom N270/N280/N450/N550 such as the Eee PC with the add-on of external firmware ({{AUR|broadcom-wl}}) and patchset (BFS + TuxOnIce + BFQ optional) - Only Intel GPU<br />
<br />
;{{AUR|linux-pax}}<br />
:The Linux Kernel and modules with [[PaX]] patches for increased security.<br />
<br />
;{{AUR|linux-pf}}<br />
:Linux kernel and modules with the pf-kernel patch [-ck patchset (BFS included), TuxOnIce, BFQ] and aufs3.<br />
<br />
;{{AUR|linux-tresor}}/{{AUR|linux-lts-tresor}}<br />
:The current/LTS Linux Kernel and modules with integrated [https://www1.informatik.uni-erlangen.de/tresor TRESOR]<br />
<br />
;{{AUR|linux-zen}}<br />
:The [https://github.com/zen-kernel/zen-kernel ZEN Kernel] is the result of a collaborative effort of kernel hackers to provide the best Linux kernel possible for every day systems. Builds of a ZEN kernel are available [https://bbs.archlinux.org/viewtopic.php?id=117157 in this repository].<br />
<br />
==Patches and Patchsets==<br />
<br />
There are lots of reasons to patch your kernel, the major ones are for performance or support for non-mainline features such as reiser4 file system support. Other reasons might include fun and to see how it is done and what the improvements are.<br />
<br />
However, it is important to note that the best way to increase the speed of your system is to first tailor your kernel to your system, especially the architecture and processor type. For this reason using pre-packaged versions of custom kernels with generic architecture settings is not recommended or really worth it. A further benefit is that you can reduce the size of your kernel (and therefore build time) by not including support for things you do not have or use. For example, you might start with the stock kernel config when a new kernel version is released and remove support for things like bluetooth, video4linux, 1000Mbit ethernet, etc.; functionality you know you will not require for your specific machine. Although this page is not about customizing your kernel config, it is recommended as a first step--before moving on to using a patchset once you have grasped the fundamentals involved.<br />
<br />
The config files for the Arch kernel packages can be used as a starting point. They are in the Arch package source files, for example [https://projects.archlinux.org/svntogit/packages.git/tree/trunk?h=packages/linux] linked from {{Pkg|linux}}. The config file of your currently running kernel is also always available in your file system at {{ic|/proc/config.gz}}.<br />
<br />
===How to install===<br />
<br />
The installation process of custom kernel packages relies on the Arch Build System (ABS). If you have not built any custom packages yet you may consult the following articles: [[Arch Build System]] and [[Creating packages]].<br />
<br />
If you have not actually patched or customized a kernel before it is not that hard and there are many PKGBUILDs on the forum for individual patchsets. However, you are advised to start from scratch with a bit of research on the benefits of each patchset, rather than just arbitrarily picking one. This way you will learn much more about what you are doing rather than just choosing a kernel at startup and then be left wondering what it actually does.<br />
<br />
See [[#Compilation]].<br />
<br />
{{note|Do not forget to change the boot options in your bootloader, e.g. [[GRUB]], to use the new kernel.}}<br />
<br />
===Major patchsets===<br />
<br />
First of all it is important to note that patchsets are developed by a variety of people. Some of these people are actually involved in the production of the linux kernel and others are hobbyists, which may reflect its level of reliability and stability.<br />
<br />
It is also worth noting that some patchsets are built on the back of other patchsets (which may or may not be reflected in the title of the patch). Patchsets (and kernel updates) can be released '''very''' frequently and often it is not worth keeping up with ALL of them so do not go crazy, unless you make it your hobby!<br />
<br />
You can search google for more sets - remember to use quotes {{ic|"-nitro"}} for example otherwise google will deliberately '''NOT''' show the results you want!<br />
<br />
{{note|This section is for '''information only''' - clearly no guarantees of stability or reliability are implied by inclusion on this page.}}<br />
<br />
====-ck====<br />
[[Linux-ck]] contains patches designed to improve system responsiveness with specific emphasis on the desktop, but suitable to any workload. The patches are created and maintained by Con Kolivas, his site is at http://users.on.net/~ckolivas/kernel/. Con maintains a full set but also provides the patches broken down so you can add only those you prefer.<br />
<br />
The -ck patches can be found at http://ck.kolivas.org/patches/3.0/<br />
<br />
====-rt====<br />
<br />
This patchset is maintained by a small group of core developers, led by Ingo Molnar. This patch allows nearly all of the kernel to be preempted, with the exception of a few very small regions of code ("raw_spinlock critical regions"). This is done by replacing most kernel spinlocks with mutexes that support priority inheritance, as well as moving all interrupt and software interrupts to kernel threads. <br />
<br />
It further incorporates high resolution timers - a patch set, which is independently maintained.<br />
<br />
[as said from the [https://rt.wiki.kernel.org/index.php/CONFIG_PREEMPT_RT_Patch Real-Time Linux Wiki]]<br />
<br />
patch at https://www.kernel.org/pub/linux/kernel/projects/rt/<br />
<br />
====-bld====<br />
{{Warning|This scheduler is in development.}}<br />
BLD is best described as a O(1) CPU picking technique. Which is done by reordering CPU runqueues based on runqueue loads. In other words, it keeps the scheduler aware of the load changes, which helps scheduler to keep runqueues in an order. This technique does not depend on scheduler ticks. The two most simple things in this technique are: load tracking and runqueue ordering; these are relatively simpler operations. Load tracking will be done whenever a load change happens on the system and based on this load change runqueue will be ordered. So, if we have an ordered runqueue from lowest to highest, then picking the less (or even busiest) runqueue is easy. Scheduler can pick the lowest runqueue without calculation and comparison at the time of placing a task in a runqueue. And while trying to distribute load at sched_exec and sched_fork our best choice is to pick the lowest busiest runqueue of the system. And in this way, system remains balanced without doing any load balancing. At the time of try_to_wake_up picking the idlest runqueue is topmost priority but it has been done as per domain basis to utilize CPU cache properly and it's an area where more concentration is requires.<br />
<br />
Google Code web page: https://code.google.com/p/bld/<br />
<br />
====-grsecurity====<br />
<br />
[[Grsecurity]] is a security focused patchset. It adds numerous security related features such as Role-Based Access Control and utilizes features of the PaX project. It can be used on a desktop but a public server would receive the greatest benefit. Some applications are incompatible with the additional security measures implemented by this patchset. If this occurs, consider using a lower security level.<br />
<br />
The -grsecurity patches can be found at https://grsecurity.net<br />
<br />
====Tiny-Patches====<br />
The goal of [http://elinux.org/Linux_Tiny Linux Tiny] is to reduce its memory and disk footprint, as well as to add features to aid working on small systems. Target users are developers of embedded system and users of small or legacy machines such as 386s.<br />
<br />
Patch releases against the mainstream Linux kernel have been discontinued. The developers chose to focus on a few patches and spend their time trying to get them merged into the mainline kernel.<br />
<br />
====-pf====<br />
{{AUR|linux-pf}} is yet another Linux kernel fork which provides you with a handful of awesome features not merged into mainline. It is based on neither existing Linux fork nor patchset, although some unofficial ports may be used if required patches have not been released officially.<br />
The most prominent patches of linux-pf are TuxOnIce, the CK patchset (most notably BFS), AUFS3, LinuxIMQ, l7 filter and BFQ.<br />
<br />
See [[linux-pf]] for more information.<br />
<br />
===Individual patches===<br />
<br />
These are patches which can be simply included in any build of a vanilla kernel or incorporated (probably with some major tweaking) into another patchset. Some common ones follow.<br />
<br />
====Reiser4====<br />
<br />
[[Reiser4]]<br />
<br />
====fbsplash====<br />
[[fbsplash]]<br />
<br />
== Compilation ==<br />
Arch Linux provides for several methods of kernel compilation.<br />
<br />
=== Using the Arch Build System ===<br />
Using the [[Arch Build System]] takes advantage of the high quality of the existing {{Pkg|linux}} [[PKGBUILD]] and the benefits of [[Wikipedia:Package management system|package management]]. The PKGBUILD is structured so that you can stop the build after the source is downloaded and configure the kernel.<br />
<br />
See [[Kernels/Compilation/Arch Build System]].<br />
<br />
=== Traditional ===<br />
This involves manually downloading a source tarball, and compiling in your home directory as a normal user. Once configured, two installation methods are available; the traditional manual method, or with [[Makepkg]] + [[Pacman]].<br />
<br />
An advantage of learning the traditional method is that it is ''not'' distribution-specific. <br />
<br />
See [[Kernels/Compilation/Traditional]].<br />
<br />
===Proprietary NVIDIA driver===<br />
See [[NVIDIA#Alternate install: custom kernel]] for instructions on using the proprietary NVIDIA driver with a custom kernel.<br />
<br />
== See also ==<br />
*[http://www.kroah.com/lkn/ O'Reilly - Linux Kernel in a Nutshell] (free ebook)</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=ACPI_modules&diff=290240ACPI modules2013-12-24T13:47:11Z<p>Leonardodag: /* Troubleshooting */ Removed reference to package "acpica" from AUR as it doesn't exist anymore.</p>
<hr />
<div>[[Category:Power management]]<br />
[[de:ACPI Module]]<br />
[[it:ACPI modules]]<br />
[[zh-CN:ACPI modules]]<br />
{{Related articles start}}<br />
{{Related|acpid}}<br />
{{Related|DSDT}}<br />
{{Related articles end}}<br />
<br />
From [http://www.acpi.info/ ACPI site]:<br />
:''ACPI (Advanced Configuration and Power Interface) is an open industry specification co-developed by Hewlett-Packard, Intel, Microsoft, Phoenix, and Toshiba.''<br />
<br />
ACPI modules are kernel modules for different ACPI parts. They enable special ACPI functions or add information to {{ic|/proc}} or {{ic|/sys}}. These information can be parsed by [[acpid]] for events or other monitoring applications.<br />
<br />
==Which modules are available?==<br />
This is a small list and summary of ACPI kernel modules:<br />
* ac (power connector status)<br />
* asus-laptop (useful on ASUS/medion laptops)<br />
* battery (battery status)<br />
* bay (bay status)<br />
* button (catch button events, like LID or POWER BUTTON)<br />
* container (container status)<br />
* dock (docking station status)<br />
* fan (fan status)<br />
* i2c_ec (EC SMBUs driver)<br />
* thinkpad_acpi (useful on Lenovo Thinkpad laptops)<br />
* processor (processor status)<br />
* sbs (smart battery status)<br />
* thermal (status of thermal sensors)<br />
* toshiba_acpi (useful for Toshiba laptops)<br />
* video (status of video devices)<br />
<br />
complete list of your running kernel:<br />
{{hc|$ ls -l /usr/lib/modules/$(uname -r)/kernel/drivers/acpi|<nowiki><br />
total 112<br />
-rw-r--r-- 1 root root 2808 Aug 29 23:58 ac.ko.gz<br />
-rw-r--r-- 1 root root 3021 Aug 29 23:58 acpi_ipmi.ko.gz<br />
-rw-r--r-- 1 root root 3354 Aug 29 23:58 acpi_memhotplug.ko.gz<br />
-rw-r--r-- 1 root root 4628 Aug 29 23:58 acpi_pad.ko.gz<br />
drwxr-xr-x 2 root root 4096 Aug 29 23:59 apei<br />
-rw-r--r-- 1 root root 7120 Aug 29 23:58 battery.ko.gz<br />
-rw-r--r-- 1 root root 3700 Aug 29 23:58 button.ko.gz<br />
-rw-r--r-- 1 root root 2181 Aug 29 23:58 container.ko.gz<br />
-rw-r--r-- 1 root root 1525 Aug 29 23:58 custom_method.ko.gz<br />
-rw-r--r-- 1 root root 1909 Aug 29 23:58 ec_sys.ko.gz<br />
-rw-r--r-- 1 root root 2001 Aug 29 23:58 fan.ko.gz<br />
-rw-r--r-- 1 root root 1532 Aug 29 23:58 hed.ko.gz<br />
-rw-r--r-- 1 root root 3241 Aug 29 23:58 pci_slot.ko.gz<br />
-rw-r--r-- 1 root root 17742 Aug 29 23:58 processor.ko.gz<br />
-rw-r--r-- 1 root root 3073 Aug 29 23:58 sbshc.ko.gz<br />
-rw-r--r-- 1 root root 7098 Aug 29 23:58 sbs.ko.gz<br />
-rw-r--r-- 1 root root 6311 Aug 29 23:58 thermal.ko.gz<br />
-rw-r--r-- 1 root root 8891 Aug 29 23:58 video.ko.gz<br />
</nowiki>}}<br />
<br />
==How to select the correct ones== <br />
You have to try yourself which module works for your machine:<br />
{{bc|# modprobe <yourmodule>}}<br />
then check if the module is supported on your hardware by using<br />
{{bc|$ dmesg}}<br />
{{Tip| It may help to add a grep text search to narrow your results.}}<br />
$ dmesg | grep acpi<br />
[ 0.000000] ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)<br />
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x04] enabled)<br />
[ 0.000000] ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)<br />
[ 0.000000] ACPI: LAPIC (acpi_id[0x03] lapic_id[0x05] enabled)<br />
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])<br />
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])<br />
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x02] high edge lint[0x1])<br />
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x03] high edge lint[0x1])<br />
[ 5.066752] ACPI: acpi_idle yielding to intel_idle<br />
[ 5.438998] acpi device:04: registered as cooling_device4<br />
<br />
Add the working ones to configuration files in {{ic|/etc/modules-load.d}} according to the pattern described in {{ic|man modules-load.d}}.<br />
<br />
== Getting Information == <br />
To read out battery information you can simply [[pacman|install]] package {{pkg|acpi}} in [[Official Repositories]] and run:<br />
acpi -i<br />
<br />
Using /proc to store ACPI information has been discouraged and deprecated since 2.6.24. The same data is available in /sys now and interested parties can (should) subscribe to ACPI events from the kernel via netlink.E.g for battery:<br />
/sys/class/power_supply/BAT0/<br />
<br />
==Troubleshooting==<br />
===DSDT fix===<br />
If problems with power management persist despite having loaded the proper modules, a Linux-unfriendly [http://en.wikipedia.org/wiki/DSDT#ACPI_Tables DSDT] might be the cause. See the wiki article on [[DSDT]].<br />
===ACPI fix for notebooks===<br />
Sometimes you see "ACPI: EC: input buffer is not empty, aborting transaction". This is a problem with acpi, more specifically an incompatibility of the BIOS. There are four ways to solve this:<br />
<br />
1. Update your BIOS.<br />
<br />
2. "Easy" Put acpi=off in the kernel line in menu.lst (if you are using GRUB), but that will kill all acpi functionality like battery charging and power saving.<br />
<br />
3. In some cases (such as [http://ubuntuforums.org/showthread.php?p=8030130#10 here]) the following has been reported to solve the issue. However, screen brightness may no longer be fully controllable.<br />
$ xset dpms force off<br />
<br />
4. "Hard" build your kernel with patch [https://bugs.launchpad.net/ubuntu/+source/linux/+bug/578506 bugs.launchpad.net].<br />
<br />
5.<strike>seems fixed in 3.6 pf</strike><br />
<br />
<br />
If notebook doesn't start just remove the AC adapter and battery for 5 seconds and start without AC!<br />
<br />
== See also ==<br />
<br />
* [[Wikipedia:Advanced Configuration and Power Interface]]</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Solid_state_drive&diff=244734Solid state drive2013-01-21T19:49:24Z<p>Leonardodag: /* Locate High-Use Files to RAM */ fixed a note</p>
<hr />
<div>[[Category:Storage]]<br />
[[it:Solid State Drives]]<br />
[[ru:Solid State Drives]]<br />
[[zh-CN:Solid State Drives]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers many aspects of SSDs (solid state drives) as they relate to Linux; however, the underlying principals and key learning presented within are general enough to be applicable to users running SSDs on other operating systems such as the Windows family of products as well as Mac OS X. Beyond the aforementioned information, Linux users will benefit from the tweaks/optimization presented herein.}}<br />
{{Article summary heading|Related Articles}}<br />
{{Article summary wiki|SSD Benchmarking}}<br />
{{Article summary wiki|SSD Memory Cell Clearing}}<br />
{{Article summary wiki|profile-sync-daemon}} <br />
{{Article summary end}}<br />
<br />
==Introduction==<br />
Solid State Drives (SSDs) are not PnP devices. Special considerations such as partition alignment, choice of file system, TRIM support, etc. are needed to set up SSDs for optimal performance. This article attempts to capture referenced, key learnings to enable users to get the most out of SSDs under Linux. Users are encouraged to read this article in its entirety before acting on recommendations as the content is organized by topic, not necessarily by any systematic or chronologically relevant order.<br />
<br />
{{Note|This article is targeted at users running Linux, but much of the content is also relevant to our friends using other operating systems like BSD, Mac OS X or Windows.}}<br />
===Advantages over HDDs===<br />
*Fast read speeds - 2-3x faster than modern desktop HDDs (7,200 RPM using SATA2 interface).<br />
*Sustained read speeds - no decrease in read speed across the entirety of the device. HDD performance tapers off as the drive heads move from the outer edges to the center of HDD platters.<br />
*Minimal access time - approximately 100x faster than an HDD. For example, 0.1 ms (100 us) vs. 12-20 ms (12,000-20,000 us) for desktop HDDs.<br />
*High degree of reliability.<br />
*No moving parts.<br />
*Minimal heat production.<br />
*Minimal power consumption - fractions of a W at idle and 1-2 W while reading/writing vs. 10-30 W for a HDD depending on RPMs.<br />
*Light-weight - ideal for laptops.<br />
<br />
===Limitations===<br />
*Per-storage cost (close to a dollar per GB, vs. around a dime or two per GB for rotating media).<br />
*Capacity of marketed models is lower than that of HDDs.<br />
*Large cells require different filesystem optimizations than rotating media. The flash translation layer hides the raw flash access which a modern OS could use to optimize access.<br />
*Partitions and filesystems need some SSD-specific tuning. Page size and erase page size are not autodetected.<br />
*Cells wear out. Consumer MLC cells at mature 50nm processes can handle 10000 writes each; 35nm generally handles 5000 writes, and 25nm 3000 (smaller being higher density and cheaper). If writes are properly spread out, are not too small, and align well with cells, this translates into a lifetime write volume for the SSD that is a multiple of its capacity. Daily write volumes have to be balanced against life expectancy.<br />
*Firmwares and controllers are complex. They occasionally have bugs. Modern ones consume power comparable with HDDs. They [https://lwn.net/Articles/353411/ implement] the equivalent of a log-structured filesystem with garbage collection. They translate SATA commands traditionally intended for rotating media. Some of them do on the fly compression. They spread out repeated writes across the entire area of the flash, to prevent wearing out some cells prematurely. They also coalesce writes together so that small writes are not amplified into as many erase cycles of large cells. Finally they move cells containing data so that the cell does not lose its contents over time.<br />
*Performance can drop as the disk gets filled. Garbage collection is not universally well implemented, meaning freed space is not always collected into entirely free cells.<br />
<br />
==Pre-Purchase Considerations==<br />
There are several key features to look for prior to purchasing a contemporary SSD.<br />
===Key Features===<br />
*Native [http://en.wikipedia.org/wiki/TRIM TRIM] support is a vital feature that both prolongs SSD lifetime and reduces loss of performance for write operations over time.<br />
*Buying the right sized SSD is key. As with all filesystems, target <75 % occupancy for all SSD partitions to ensure efficient use by the kernel.<br />
<br />
===Reviews===<br />
This section is not meant to be all-inclusive, but does capture some key reviews.<br />
*[http://www.anandtech.com/show/2738 SSD Anthology (history lesson, a bit dated)]<br />
*[http://www.anandtech.com/show/2829 SSD Relapse (refresher and more up to date])<br />
*[http://forums.anandtech.com/showthread.php?t=2069761 One user's recommendations]<br />
*[http://techgage.com/article/enabling_and_testing_ssd_trim_support_under_linux/ Enabling and Testing SSD TRIM Support Under Linux]<br />
<br />
==Tips for Maximizing SSD Performance==<br />
===Mount Flags===<br />
There are several key mount flags to use in one's {{ic|/etc/fstab}} entries for SSD partitions.<br />
<br />
* '''noatime''' - Reading accesses to the file system will no longer result in an update to the atime information associated with the file. The importance of the noatime setting is that it eliminates the need by the system to make writes to the file system for files which are simply being read. Since writes can be somewhat expensive as mentioned in previous section, this can result in measurable performance gains. Note that the write time information to a file will continue to be updated anytime the file is written to with this option enabled.<br />
** However, this will cause issues with some programs such as [[Mutt]], as the access time of the file will eventually be previous than the modification time, which would make no sense. Using the '''relatime''' option instead of noatime will ensure that the atime field will never be prior to the last modification time of a file.<br />
* '''discard''' - The discard flag will enable the benefits of the TRIM command as long as one is using kernel version >=2.6.33. It does not work with ext3; using the discard flag for an ext3 root partition will result in it being mounted read-only.<br />
<br />
/dev/sda1 / ext4 defaults,relatime,discard 0 1<br />
/dev/sda2 /home ext4 defaults,relatime,discard 0 2<br />
<br />
{{Warning|Users need to be certain that kernel version 2.6.33 or above is being used AND that their SSD supports TRIM before attempting to mount a partition with the {{ic|discard}} flag. Data loss can occur otherwise!}}<br />
<br />
===Enable TRIM for LVM===<br />
Enable '''issue_discards''' option in /etc/lvm/lvm.conf<br />
<br />
===Enable TRIM With mkfs.ext4 or tune2fs (Discouraged) ===<br />
One can set the trim flag statically with tune2fs or when the filesystem is created.<br />
# tune2fs -o discard /dev/sdXY<br />
or<br />
# mkfs.ext4 -E discard /dev/sdXY<br />
<br />
{{Note|After this option is set as described above, any time the user checks mounted filesystems with "mount", the discard option will not show up. Even when discard is passed on the CLI in addition to the option being set with tune2fs or mkfs.ext4, it will not show up. See the following thread for a discussion about his: https://bbs.archlinux.org/viewtopic.php?id&#61;137314 }}<br />
<br />
===Apply TRIM via cron===<br />
Enabling TRIM on supported SSDs is definitely recommended. But sometimes it may cause some SSDs to [https://patrick-nagel.net/blog/archives/337 perform slowly] during deletion of files. If this is the case, one may choose to use fstrim as an alternative.<br />
# fstrim -v /<br />
The partition for which fstrim is to be applied must be mounted, and must be indicated by the mount point. <br />
<br />
If this method seems like a better alternative, it might be a good idea to have this run from time to time using cron. To have this run daily, the default cron package (cronie) includes an anacron implementation which, by default, is set up for hourly, daily, weekly, and monthly jobs. To add to the list of daily cron tasks, simply create a script that takes care of the desired actions and put it in /etc/cron.daily, /etc/cron.weekly, etc. Appropriate nice and ionice values are recommended if this method is chosen. If implemented, remove the "discard" option from {{ic|/etc/fstab}}.<br />
<br />
{{Note|Use the 'discard' mount option as a first choice. This method should be considered second to the normal implementation of TRIM.}}<br />
<br />
=== I/O Scheduler ===<br />
Consider switching from the default [https://en.wikipedia.org/wiki/CFQ CFQ] scheduler (Completely Fair Queuing) since 2.6.18 to [http://en.wikipedia.org/wiki/NOOP_scheduler NOOP] or [http://en.wikipedia.org/wiki/Deadline_scheduler Deadline]. The latter two offer performance boosts for SSDs. The NOOP scheduler, for example, implements a simple queue for all incoming I/O requests, without re-ordering and grouping the ones that are physically closer on the disk. On SSDs seek times are identical for all sectors, thus invalidating the need to re-order I/O queues based on them.<br />
<br />
For more on schedulers, see these: [http://www.linux-mag.com/id/7564 Linux Magazine article], [http://www.phoronix.com/scan.php?page=article&item=linux_iosched_2012 Phoronix benchmark] and {{Bug|22605}}.<br />
<br />
The CFQ scheduler is enabled by default on Arch. Verify this by viewing the contents {{ic|/sys/block/sdX/queue/scheduler}}:<br />
$ cat /sys/block/sdX/queue/scheduler<br />
noop deadline [cfq]<br />
The scheduler currently in use is denoted from the available schedulers by the brackets. <br />
<br />
Users can change this on the fly without the need to reboot by echoing the scheduler of choice like this:<br />
# echo noop > /sys/block/sdX/queue/scheduler<br />
<br />
This has to be done as root (sudo won't work) and is non-persistent (eg. change will be lost upon rebooting). Confirm the change was made by viewing the contents of the file again and ensuring noop is between brackets.<br />
<br />
===== Kernel parameter (for a single device) =====<br />
If the sole storage device in the system is an SSD, consider setting the I/O scheduler for the entire system via the {{ic|1=elevator=noop}} kernel parameter. See [[Kernel parameters]] for more info.<br />
<br />
===== Using the sys virtual filesystem (for multiple devices) =====<br />
This method is preferred when the system has several physical storage devices (for example an SSD and an HDD).<br />
<br />
Create the following tmpfile where "X" is the letter for the SSD device.<br />
<br />
{{hc| /etc/tmpfiles.d/set_IO_scheduler.conf |<nowiki><br />
w /sys/block/sdX/queue/scheduler - - - - noop<br />
</nowiki>}}<br />
<br />
Because of the potential for udev to assign different {{ic|/dev/}} nodes to drives before and after a kernel update, users must take care that the NOOP scheduler is applied to the correct device upon boot. One way to do this is by using the SSD's device ID to determine its {{ic|/dev/}} node. To do this automatically, use the following snippet instead of the line above and add it to {{ic|/etc/rc.local}}:<br />
declare -ar SSDS=(<br />
'scsi-SATA_SAMSUNG_SSD_PM8_S0NUNEAB861972'<br />
'ata-SAMSUNG_SSD_PM810_2.5__7mm_256GB_S0NUNEAB861972'<br />
)<br />
<br />
for SSD in "${SSDS[@]}" ; do<br />
BY_ID=/dev/disk/by-id/$SSD<br />
<br />
if &#91;&#91; -e $BY_ID ]] ; then<br />
DEV_NAME=`ls -l $BY_ID | awk '{ print $NF }' | sed -e 's/[/\.]//g'`<br />
SCHED=/sys/block/$DEV_NAME/queue/scheduler<br />
<br />
if &#91;&#91; -w $SCHED ]] ; then<br />
echo noop > $SCHED<br />
fi<br />
fi<br />
done<br />
where {{ic|SSDS}} is a Bash array containing the device IDs of all SSD devices. Device IDs are listed in {{ic|/dev/disk/by-id/}} as symbolic links pointing to their corresponding {{ic|/dev/}} nodes. To view the links listed with their targets, issue the following command:<br />
ls -l /dev/disk/by-id/<br />
<br />
=====Using udev for one device or HDD/SSD mixed environment=====<br />
Though the above will undoubtedly work, it is probably considered a reliable workaround. It should also be noted that with the move to [[systemd]] there will be no rc.local. Ergo, it would be preferred to use the system that is responsible for the devices in the first place to implement the scheduler. In this case it is udev, and to do this, all one needs is a simple [[udev]] rule.<br />
<br />
To do this, create and edit a file in /etc/udev/rules.d named something like '60-schedulers.rules'. In the file include the following:<br />
# set deadline scheduler for non-rotating disks<br />
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0", ATTR{queue/scheduler}="deadline"<br />
<br />
# set cfq scheduler for rotating disks<br />
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1", ATTR{queue/scheduler}="cfq"<br />
Of course, set deadline/cfq to the desired schedulers. Changes should occur upon next boot. To check success of the new rule:<br />
$ cat /sys/block/sdX/queue/scheduler #where X is the device in question<br />
<br />
{{note|Keep in mind cfq is the default scheduler, so the second rule with the standard kernel is not actually necessary. Also, in the example sixty is chosen because that is the number udev uses for its own persistent naming rules. Thus, it would seem that block devices are at this point able to be modified and this is a safe position for this particular rule. But the rule can be named anything so long as it ends in '.rules'. (Credit: falconindy and w0ng for posting on his blog)}}<br />
<br />
=== Swap Space on SSDs ===<br />
One can place a swap partition on an SSD. Note that most modern desktops with an excess of 2 Gigs of memory rarely use swap at all. The notable exception is systems which make use of the hibernate feature. The following is recommended tweak for SSDs using a swap partition that will reduce the "swappiness" of the system thus avoiding writes to swap:<br />
<br />
# echo 1 > /proc/sys/vm/swappiness<br />
<br />
Or one can simply modify {{ic|/etc/sysctl.conf}} as recommended in the [[Maximizing_performance#Swappiness|Maximizing Performance]] wiki article:<br />
<br />
vm.swappiness=1<br />
vm.vfs_cache_pressure=50<br />
<br />
=== SSD Memory Cell Clearing ===<br />
On occasion, users may wish to completely reset an SSD's cells to the same virgin state they were at the time the device was installed thus restoring it to its [http://www.anandtech.com/storage/showdoc.aspx?i=3531&p=8 factory default write performance]. Write performance is known to degrade over time even on SSDs with native TRIM support. TRIM only safeguards against file deletes, not replacements such as an incremental save.<br />
<br />
The reset is easily accomplished in a three step procedure denoted on the [[SSD Memory Cell Clearing]] wiki article.<br />
<br />
==Tips for Minimizing SSD Read/Writes==<br />
An overarching theme for SSD usage should be 'simplicity' in terms of locating high-read/write operations either in RAM (Random Access Memory) or on a physical HDD rather than on an SSD. Doing so will add longevity to an SSD. This is primarily due to the large erase block size (512 KiB in some cases); a lot of small writes result in huge effective writes.<br />
<br />
{{Note|A 32GB SSD with a mediocre 10x write amplification factor, a standard 10000 write/erase cycle, and '''10GB of data written per day''', would get an '''8 years life expectancy'''. It gets better with bigger SSDs and modern controllers with less write amplification.}}<br />
<br />
Use {{ic|iotop -oPa}} and sort by disk writes to see how much programs are writing to disk.<br />
<br />
=== Intelligent Partition Scheme ===<br />
*For systems with both an SSD and an HDD, consider relocating the {{ic|/var}} partition to a physical disc on the system rather than on the SSD itself to avoid read/write wear. <br />
*For systems with only an SSD (i.e. no HDDs), consider allocating a separate partition for {{ic|/var}} to allow for better crash recovery for example in the event of a broken program wasting all the space on {{ic|/}} or if some run away log file maxes out the space, etc.<br />
<br />
=== The noatime Mount Flag ===<br />
Assign the {{ic|noatime}} flag to partitions residing on SSDs. See the [[#Mount_Flags|Mount Flags]] section above for more.<br />
<br />
=== Locate High-Use Files to RAM ===<br />
{{Note|SSDs are very good devices for caches. So browser profiles and caches into away from it [http://productforums.google.com/forum/#!topic/chrome/rkXAt47LoEI may be counterproductive].}}<br />
<br />
==== Browser Profiles ====<br />
One can ''easily'' mount browser profile(s) such as chromium, firefox, opera, etc. into RAM via tmpfs and also use rsync to keep them synced with HDD-based backups. In addition to the obvious speed enhancements, users will also save read/write cycles on their SSD by doing so.<br />
<br />
The AUR contains several packages to automate this process, for example {{AUR|profile-sync-daemon}}.<br />
<br />
==== Others ====<br />
For the same reasons a browser's profile can be relocated to RAM, so can highly used directories such as {{ic|/srv/http}} (if running a web server). A sister project to {{AUR|profile-sync-daemon}} is {{AUR|anything-sync-daemon}}, which allows users to define '''any''' directory to sync to RAM using the same underlying logic and safe guards.<br />
<br />
=== Compiling in tmpfs ===<br />
Intentionally compiling in {{ic|/tmp}} is a great idea to minimize this problem. For systems with >4 GB of memory, the tmp line in {{ic|/etc/fstab}} can be tweaked to use more than 1/2 the physical memory on the system via the {{ic|1=size=}} flag as {{ic|/tmp}} keeps filling up.<br />
<br />
Example of a machine with 8 GB of physical memory:<br />
tmpfs /tmp tmpfs nodev,nosuid,size=7G 0 0<br />
<br />
=== Disabling Journaling on the filesystem ===<br />
Using a journaling filesystem such as ext3 or ext4 on an SSD WITHOUT a journal is an option to decrease read/writes. The obvious drawback of using a filesystem with journaling disabled is data loss as a result of an ungraceful dismount (i.e. post power failure, kernel lockup, etc.). With modern SSDs, [http://tytso.livejournal.com/61830.html Ted Tso] advocates that journaling can be enabled with minimal extraneous read/write cycles under most circumstances:<br />
<br />
'''Amount of data written (in megabytes) on an ext4 file system mounted with noatime.'''<br />
{| border="1" cellpadding="5"<br />
! operation !! journal !! w/o journal !! percent change<br />
|-<br />
!git clone<br />
|367.0<br />
|353.0<br />
|3.81 %<br />
|-<br />
!make<br />
|207.6<br />
|199.4<br />
|3.95 %<br />
|-<br />
!make clean<br />
|6.45<br />
|3.73<br />
|42.17 %<br />
|}<br />
<br />
''"What the results show is that metadata-heavy workloads, such as make clean, do result in almost twice the amount data written to disk. This is to be expected, since all changes to metadata blocks are first written to the journal and the journal transaction committed before the metadata is written to their final location on disk. However, for more common workloads where we are writing data as well as modifying filesystem metadata blocks, the difference is much smaller."''<br />
<br />
{{Note|The make clean example from the table above typifies the importance of intentionally doing compiling in tmpfs as recommended in the [[Solid_State_Drives#Compiling_in_tmpfs|preceding section]] of this article!}}<br />
<br />
=== Choice of Filesystem ===<br />
==== Btrfs ====<br />
[http://en.wikipedia.org/wiki/Btrfs Btrfs] support has been included with the mainline 2.6.29 release of the Linux kernel. Some feel that it is not mature enough for production use while there are also early adopters of this potential successor to ext4. Users are encouraged to read the [[Btrfs]] article for more info.<br />
<br />
==== Ext4 ====<br />
[http://en.wikipedia.org/wiki/Ext4 Ext4] is another filesystem that has support for SSD. It is considered as stable since 2.6.28 and is mature enough for daily use. Contrary to Btrfs, ext4 does not automatically detect the disk nature; users must explicitly enable the TRIM command support using the {{ic|discard}} mount option in [[fstab]] (or with {{ic|tune2fs -o discard /dev/sdaX}}).<br />
See the [http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=blob;f=Documentation/filesystems/ext4.txt official in kernel tree documentation] for further information on ext4.<br />
<br />
====XFS====<br />
Many users do not realize that in addition to ext4 and btrfs, [http://en.wikipedia.org/wiki/XFS XFS] has TRIM support as well. This can be enabled in the usual ways. That is, the choice may be made of either using the discard option mentioned above, or by using the fstrim command. More information can be found on the [http://xfs.org/index.php/FITRIM/discard XFS wiki].<br />
<br />
====JFS====<br />
As of Linux kernel version 3.7, proper TRIM support has been added. So far, there is not a great wealth of information of the topic but it has certainly been picked up by [http://www.phoronix.com/scan.php?page=news_item&px=MTE5ODY Linux news sites.] It is apparent that it can be enabled via the {{ic|discard}} mount option, or by using the method of batch TRIMs with fstrim.<br />
<br />
== SSD Benchmarking ==<br />
See the [[SSD Benchmarking]] article for a general process of benchmarking SSDs or to see some of the SSDs in the database.<br />
<br />
== Firmware Updates ==<br />
=== ADATA ===<br />
ADATA has a utility available for Linux (i686) on their support page [http://www.adata.com.tw/index.php?action=ss_main&page=ss_content_driver&lan=en here]. The link to the utility will appear after selecting the model.<br />
===Kingston===<br />
Kingston has a Linux utilty to update the firmware of their Sandforce based drives. It can be found on their [http://www.kingston.com/us/support support page].<br />
<br />
===Mushkin===<br />
The lesser known Mushkin brand Solid State drives also use Sandforce controllers, and have a Linux utility (nearly identical to Kingston's) to update the firmware.<br />
<br />
=== OCZ ===<br />
OCZ has a command line utility available for Linux (i686 and x86_64) on their forum [http://www.ocztechnology.com/ssd_tools/ here].<br />
<br />
===Samsung===<br />
It seems that Samsungs drives must be updated by the Magician Software that is included with their drives. Unfortunately, this software is Windows only, though their firmware is not updated nearly as often as Sandforce driven SSDs. It might be worth mentioning that there has been an update to their 840 (pro) series as of 2012 December, so as Linux users that should probably be kept in mind when purchasing.<br />
<br />
== See also ==<br />
* [http://www.reddit.com/r/archlinux/comments/rkwjm/what_should_i_keep_in_mind_when_installing_on_ssd/ Discussion on Reddit about installing Arch on an SSD]<br />
* See the [[Flashcache]] article for advanced information on using solid-state with rotational drives for top performance.<br />
* [http://lifehacker.com/5837769/make-sure-your-partitions-are-correctly-aligned-for-optimal-solid-state-drive-performance Speed Up Your SSD By Correctly Aligning Your Partitions] (using GParted)</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Persistent_block_device_naming&diff=244377Persistent block device naming2013-01-18T19:57:56Z<p>Leonardodag: /* by-uuid */ fixed a typo</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:File systems]]<br />
[[Category:Hardware detection and troubleshooting]]<br />
[[it:Persistent block device naming]]<br />
[[zh-TW:UUID]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of persistent block device naming; the preferred method of referencing block devices.}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|fstab}}<br />
{{Article summary wiki|udev}}<br />
{{Article summary wiki|LVM}}<br />
{{Article summary end}}<br />
<br />
This article describes how to use persistent names for your block devices. This has been made possible by the introduction of udev and has some advantages over bus-based naming. If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is arbitrary. This may result in device names like {{ic|/dev/'''sda'''}} and {{ic|/dev/'''sdb'''}} switching around on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues.<br />
{{Note|If you are using [[LVM|LVM2]], this article is not relevant as LVM takes care of this automatically.}}<br />
<br />
==Persistent naming methods==<br />
<br />
There are four different schemes for persistent naming: [[#by-label|by-label]], [[#by-uuid|by-uuid]], [[#by-id and by-path|by-id and by-path]]. The following sections describes what the different persistent naming methods are and how they are used. <br />
<br />
Here is a good command for viewing all the information.<br />
<br />
{{hc|# blkid -o list -c /dev/null|<nowiki><br />
device fs_type label mount point UUID<br />
------------------------------------------------------------------------------------------<br />
/dev/sda1 ext2 /boot 7f4cef7e-7ee2-489a-b759-d52ba23b692c<br />
/dev/sda2 swap (not mounted) a807fff3-e89f-46d0-ab17-9b7ad3efa7b5<br />
/dev/sda3 ext4 / 81917291-fd1a-4ffe-b95f-61c05cfba76f<br />
/dev/sda4 ext4 /home c4c23598-19fb-4562-892b-6fb18a09c7d3<br />
/dev/sdb1 ext4 X2 /mnt/X1 4bf265f7-da17-4575-8758-acd40885617b<br />
/dev/sdc1 ext4 X1 /mnt/X2 4bf265f7-da17-4575-8758-acd40885617b<br />
/dev/sdd1 ext4 Y2 /mnt/Y2 8a976a06-3e56-476f-b73a-ea3cad41d915<br />
/dev/sde1 ext4 Z2 /mnt/Z2 9d35eaae-983f-4eba-abc9-434ecd4da09c<br />
/dev/sdf1 ext4 Y1 /mnt/Y1 e2ec37a9-0689-46a8-a07b-0609ce2b7ea2<br />
/dev/sdg1 ext4 Z1 /mnt/Z1 9fa239c1-720f-42e0-8aed-39cf53a743ed<br />
/dev/sdj1 ext4 RAPT (not mounted) a9ed7ecb-96ce-40fe-92fa-e07a532ed157<br />
/dev/sdj2 swap <swap> 20826c74-eb6d-46f8-84d8-69b933a4bf3f<br />
</nowiki>}}<br />
<br />
===by-label===<br />
<br />
Almost every filesystem type can have a label. All your partitions that have one are listed in the {{ic|/dev/disk/by-label}} directory. This directory is created and destroyed dynamically, depending on whether you have partitions with labels attached.<br />
<br />
{{hc|$ ls -lF /dev/disk/by-label|<nowiki><br />
total 0<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 data -> ../../sdb2<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 data2 -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 fat -> ../../sda6<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 home -> ../../sda7<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 root -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 swap -> ../../sda5<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 windows -> ../../sdb1<br />
</nowiki>}}<br />
<br />
The labels of your filesystems can be changed, but note that they have to be unambiguous to prevent any possible conflicts. Following are some methods for changing labels on common filesystems:<br />
<br />
; swap :<br />
# swaplabel -L <label> /dev/XXX<br />
; ext2/3/4 :<br />
# e2label /dev/XXX <label><br />
; btrfs :<br />
# btrfs filesystem label /dev/XXX <label><br />
; reiserfs :<br />
# reiserfstune -l <label> /dev/XXX<br />
; jfs :<br />
# jfs_tune -L <label> /dev/XXX<br />
; xfs :<br />
# xfs_admin -L <label> /dev/XXX<br />
; fat/vfat<br />
# dosfslabel /dev/XXX <label> # {{pkg|dosfstools}} package<br />
# mlabel -i /dev/XXX ::<label> # {{pkg|mtools}} package; converts label to uppercase<br />
; ntfs (ntfsprogs package) :<br />
# ntfslabel /dev/XXX <label><br />
{{Note|Labels can be up to 16 characters long.}}<br />
<br />
===by-uuid===<br />
<br />
[http://en.wikipedia.org/wiki/UUID UUID] is a mechanism to give each filesystem a unique identifier. It is designed so that collisions are unlikely. All GNU/Linux filesystems (including swap and LUKS headers of raw encrypted devices) support UUID. FAT and NTFS filesystems (''fat'' and ''windows'' labels above) do not support UUID, but are still listed in {{ic|/dev/disk/by-uuid}} with a shorter UID (unique identifier):<br />
<br />
{{hc|# ls -l /dev/disk/by-uuid/|total 0<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 2d781b26-0285-421a-b9d0-d4a0d3b55680 -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 31f8eb0d-612b-4805-835e-0e6d8b8c5591 -> ../../sda7<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 3FC2-3DDB -> ../../sda6<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 5090093f-e023-4a93-b2b6-8a9568dd23dc -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 912c7844-5430-4eea-b55c-e23f8959a8ee -> ../../sda5<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 B0DC1977DC193954 -> ../../sdb1<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 bae98338-ec29-4beb-aacf-107e44599b2e -> ../../sdb2}}<br />
<br />
The advantage about using the UUID method is that it is less likely that you have name collisions than with labels. The disadvantage is that UUIDs make long code lines hard to read and break formatting in many configuration files (e.g. fstab or crypttab). Also every time a partition is resized or reformatted a new UUID is generated and configs have to get adjusted (manually).<br />
<br />
===by-id and by-path===<br />
<br />
{{ic|by-id}} creates a unique name depending on the hardware serial number, {{ic|by-path}} depending on the shortest physical path (according to sysfs). Both contain strings to indicate which subsystem they belong to (i.e. {{ic|-ide-}} for {{ic|by-path}}, and {{ic|-ata-}} for {{ic|by-id}}) and thus are not suitable for solving the problems mentioned in the beginning of this article. They will not be discussed any further here.<br />
<br />
===Individual device names===<br />
You can also create individual device names: [[udev#Setting static device names (for iscsi)]].<br />
<br />
==Using persistent naming==<br />
<br />
There are various applications that can be configured using persistent naming. Following are some examples of how to configure them.<br />
<br />
===[[fstab]]===<br />
<br />
To enable persistent naming in {{ic|/etc/fstab}} replace the device kernel name in the first column with the persistent name path as follows:<br />
<br />
/dev/disk/by-label/home_myhost ...<br />
/dev/disk/by-uuid/31f8eb0d-612b-4805-835e-0e6d8b8c5591 [...]<br />
<br />
or directly specify the persistent name type using a prefix:<br />
<br />
LABEL=home_myhost ...<br />
UUID=1f8eb0d-612b-4805-835e-0e6d8b8c5591 [...]<br />
<br />
===Boot managers===<br />
<br />
To use persistent names in your boot manager, the following prerequisites must be met:<br />
<br />
* You are using a [[Configuring mkinitcpio|mkinitcpio]] initial RAM disk image<br />
* You have udev enabled in {{ic|/etc/mkinitcpio.conf}}<br />
<br />
In the above example, {{ic|/dev/sda1}} is the root partition. In the [[GRUB2]] {{ic|grub.cfg}} file, the ''linux'' line looks like this:<br />
<br />
linux /boot/vmlinuz-linux root=/dev/sda1 ro quiet<br />
<br />
Depending on which naming scheme you would prefer, change it to one of the following:<br />
<br />
linux /boot/vmlinuz-linux root=/dev/disk/by-label/root_myhost ro quiet<br />
<br />
or:<br />
<br />
linux /boot/vmlinuz-linux root=UUID=2d781b26-0285-421a-b9d0-d4a0d3b55680 ro quiet<br />
<br />
If you are using [[LILO]], then do not try this with the {{ic|1=root=...}} configuration option; it will not work. Use {{ic|1=append="root=..."}} or {{ic|1=addappend="root=..."}} instead. Read the LILO man page for more information on {{ic|append}} and {{ic|addappend}}.<br />
<br />
There is an alternative way to use the label embedded in the filesystem. For example if (as above) the filesystem in {{ic|/dev/sda1}} is labeled {{ic|root_myhost}}, you would give this line to GRUB2:<br />
<br />
linux /boot/vmlinuz-linux root=LABEL=root_myhost ro quiet</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Partitioning&diff=244285Partitioning2013-01-17T18:06:31Z<p>Leonardodag: /* Partition type */ Split it in "On MBR" and "On GPT"</p>
<hr />
<div>[[Category:File systems]]<br />
[[es:Partitioning]]<br />
[[it:Partitioning]]<br />
[[ja:Partitioning]]<br />
[[ru:Partitioning]]<br />
[[zh-cn:Partitioning]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of disk partitioning tools, best practices, and additional considerations.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|fstab}}<br />
{{Article summary wiki|LVM}}<br />
{{Article summary wiki|Swap}}<br />
{{Article summary wiki|Format a device}}<br />
{{Article summary wiki|File Systems}}<br />
{{Article summary end}}<br />
<br />
''Partitioning'' a hard drive allows one to logically divide the available space into sections that can be accessed independently of one another. Partition information is stored within a hard drive's [[GUID Partition Table]] or [[Master Boot Record]].<br />
<br />
An entire hard drive may be allocated to a single partition, or one may divide the available storage space across multiple partitions. A number of scenarios require creation multiple partitions: dual- or multi-booting, for example, or maintaining a [[swap]] partition. In other cases, partitioning is used as a means of logically separating data, such as creating separate partitions for audio and video files. Common partitioning schemes are discussed in detail below. <br />
<br />
Each partition should be formatted to a [[File Systems|file system type]] before being used.<br />
<br />
Users may create up to four ''primary partitions'' per hard drive (in case of MBR). If additional partitions are required, a single ''extended partition'' can be created instead (that is, up to three primary partitions and one extended partition). An extended partition can be further divided into an unlimited number of ''logical partitions.''<br />
<br />
==Partition type==<br />
Partitioning a hard disk drive defines specific memory storage areas. These are called partitions. Each partition behaves as a separate disk and is formatted with a specific filesystem type (see below).<br />
<br />
===On MBR===<br />
There are 3 types of disk partitions:<br />
<br />
* Primary<br />
* Extended<br />
** Logical<br />
<br />
'''Primary''' partitions can be bootable and are limited to four partitions per disk or RAID volume. If a partitioning scheme requires more than four partitions, an '''extended''' partition containing '''logical''' partitions is used. Extended partitions can be thought of as containers for logical partitions. A hard disk can contain no more than one extended partition. The extended partition is also counted as a primary partition so if the disk has an extended partition, only three additional primary partitions are possible (i.e. three primary partitions and one extended partition). The number of logical partitions residing in an extended partition is unlimited. A system that dual boots with Windows will require that Windows reside in a primary partition.<br />
<br />
The customary numbering scheme is to create primary partitions {{ic|sda1}} through {{ic|sda3}} followed by an extended partition {{ic|sda4}}. The logical partitions on {{ic|sda4}} are numbered {{ic|sda5}}, {{ic|sda6}}, etc.<br />
<br />
===On GPT===<br />
There is only one type of partition, '''Primary'''. The amount of partitions per disk or RAID volume is unlimited.<br />
<br />
== Partition scheme ==<br />
<br />
There are no strict rules for partitioning a hard drive, although one may follow the general guidance given below. A disk partitioning scheme is determined by various issues such as desired flexibility, speed, security, as well as the limitations imposed by available disk space. It is essentially personal preference. If you would like to dual boot Arch Linux and a Windows operating system please see [[Windows and Arch Dual Boot]].<br />
<br />
=== Single root partition ===<br />
This scheme is the simplest and should be enough for most use cases. A [[swapfile]] can be created and easily resized as needed. It usually makes sense to start by considering a single / partition and then separate out others based on specific use cases like raid, encryption, a shared media partition, etc.<br />
<br />
=== Discrete partitions ===<br />
Separating out a path as a partition allows for the choice of a different filesystem and mount options. In some cases like a media partition, they can also be shared between operating systems.<br />
<br />
<br />
=== Mount points ===<br />
The following mount points are possible choices for separate partitions, you can make your decision based on actual needs.<br />
<br />
====/ (root)====<br />
The root directory is the top of the hierarchy, the point where the primary filesystem is mounted and from which all other filesystems stem. All files and directories appear under the root directory'' {{ic|/}}'', even if they are stored on different physical devices. The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Therefore, certain directories under'' {{ic|/}} ''are not candidates for separate partitions. <br />
<br />
The {{ic|/}} partition or root partition is necessary and it is the most important. The other partitions can be replaced by it.<br />
<br />
{{Warning|Directories essential for booting '''must''' be on the same partition as ''' {{ic|/}}''' or mounted in early userspace by the [[initramfs]]. These essential directories are: {{ic|/bin}}, {{ic|/etc}}, {{ic|/lib}}, {{ic|/sbin}} and {{ic|/usr}}[http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken].}}<br />
<br />
====/boot====<br />
The {{ic|/boot}} directory contains the kernel and ramdisk images as well as the bootloader configuration file and bootloader stages. It also stores data that is used before the kernel begins executing user-space programs. {{ic|/boot}} is not required for normal system operation, but only during boot and kernel upgrades (when regenerating the initial ramdisk).<br />
<br />
A separate {{ic|/boot}} partition is needed if installing a software RAID0 (stripe) system.<br />
<br />
====/home====<br />
The {{ic|/home}} directory contains user-specific configuration files, caches, application data and media files.<br />
<br />
Separating out {{ic|/home}} allows {{ic|/}} to be re-partitioned separately, but note that you can still reinstall Arch with {{ic|/home}} untouched even if it isn't separate - the other top-level directories just need to be removed, and then pacstrap can be run.<br />
<br />
You should not share home directories between users on different distributions, because they use incompatible software versions and patches. Instead, consider sharing a media partition or at least using different home directories on the same {{ic|/home}} partition.<br />
<br />
====/var====<br />
The {{ic|/var}} directory stores variable data such as spool directories and files, administrative and logging data, [[pacman]]'s cache, the [[Arch Build System|ABS]] tree, etc. It is used, for example, for caching and logging, and hence frequently read or written. Keeping it in a separate partition avoids running out of disk space due to flunky logs, etc. <br />
<br />
It exists to make it possible to mount'' {{ic|/usr}} ''as read-only. Everything that historically went into'' {{ic|/usr}} ''that is written to during system operation (as opposed to installation and software maintenance) must reside under'' {{ic|/var}}''.<br />
<br />
{{Note|{{ic|/var}} contains many small files. The choice of filesystem type (see below) should consider this fact if a separate partition is used.}}<br />
<br />
====/tmp====<br />
This is already a separate partition by default, by virtue of being mounted as {{ic|tmpfs}} by systemd.<br />
<br />
====Swap====<br />
A [[swap]] partition provides memory that can be used as virtual RAM. A [[swapfile]] should be considered too, as they have almost no performance overhead compared to a partition but are much easier to resize as needed. A swap partition can ''potentially'' be shared between operating systems, but not if hibernation is used.<br />
<br />
{{Note|The old rule of matching the swap partition size with the available RAM when using [[Suspend_to_Disk|suspend-to-disk]] no longer applies. The default suspend method uses an image the size of 40% of the currently available RAM by default. Even with [[TuxOnIce]] the atomic copy generally only takes about 70% after compression.[http://tuxonice.net/features]}}<br />
<br />
<br />
====How big should my partitions be?====<br />
<br />
The size of the partitions depends on personal preference, but the following information may be helpful: <br />
<br />
; {{ic|/boot}} &mdash; 100 MB : A {{ic|/boot}} partition requires only about 100 MB.<br />
; {{ic|/}} &mdash; 15-20 GB : The root filesystem ({{ic|/}}) '''must''' contain the {{ic|/usr}} directory, which can grow significantly depending upon how much software is installed. 15-20 GB should be sufficient for most users with modern hard disks.<br />
; {{ic|/var}} &mdash; 8-12 GB : The {{ic|/var}} filesystem will contain, among other data, the [[Arch Build System|ABS]] tree and the [[pacman]] cache. Keeping cached packages is useful and versatile as it provides the ability to downgrade. As a result, {{ic|/var}} tends to grow in size. The pacman cache in particular will grow as the system is expanded and updated. It can, however, be safely cleared if space becomes an issue. 8-12 GB on a desktop system should be sufficient for {{ic|/var}}, depending on how much software will be installed.<br />
; {{ic|/home}} &mdash; [very large] : The {{ic|/home}} filesystem is typically where user data, downloads, and multimedia reside. On a desktop system, {{ic|/home}} is typically the largest filesystem on the drive by a large margin.<br />
; {{ic|swap}} &mdash; [varies] : Historically, the general rule for swap partition size was to allocate twice the amount of physical RAM. As computers have gained ever larger memory capacities, this rule has become deprecated. On machines with up to 512MB RAM, the 2x rule is usually adequate. If a sufficient amount of RAM (more than 1024MB) is available, it may be possible to have a smaller swap partition or even eliminate it. With more than 2 GB of physical RAM, one can generally expect good performance without a swap partition.<br />
<br />
{{Note|If available, an extra 25% of space added to each filesystem will provide a cushion for future expansion and help protect against fragmentation.}}<br />
<br />
==Partitioning tools==<br />
*{{App|fdisk|Terminal partitioning tools included in Linux.|https://www.kernel.org/|{{Pkg|util-linux}}}}<br />
*{{App|cfdisk|Terminal partitioning tool written with ncurses libraries.|https://www.kernel.org/|{{Pkg|util-linux}}}}<br />
{{Note|The first partition created by cfdisk starts at sector 63, instead of the usual 2048. This will cause problems with [[GRUB2#msdos-style error message|GRUB2]]. grub-legacy and syslinux should work fine.}}<br />
*{{App|gdisk|[[GPT]] version of fdisk.|http://www.rodsbooks.com/gdisk/|{{Pkg|gptfdisk}}}}<br />
*{{App|cgdisk|[[GPT]] version of cfdisk.|http://www.rodsbooks.com/gdisk/|{{Pkg|gptfdisk}}}}<br />
*{{App|GNU Parted|Terminal partitioning tool.|http://www.gnu.org/software/parted/parted.html|{{pkg|parted}}}}<br />
*{{App|[[GParted]]|Graphical tool written in GTK.|http://gparted.sourceforge.net/|{{Pkg|gparted}}}}<br />
*{{App|Partitionmanager|Graphical tool written in QT.|http://sourceforge.net/projects/partitionman/|{{AUR|partitionmanager}}}}<br />
*{{App|QtParted|Similar to Partitionmanager, available in [[AUR]].|http://qtparted.sourceforge.net/|{{AUR|qtparted}}}}<br />
<br />
==Partition Alignment ==<br />
==== High-level Overview ====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' The key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD.<br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If one does not know the EBS of one's SSD, use a size of 512 KiB. Those numbers are greater or equal than almost all of the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows 7 and Ubuntu "optimize" partitions to work with SSD.}}<br />
<br />
If the partitions are not aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
=== Using GPT - Modern Method ===<br />
[[GPT]] is an alternative, contemporary partitioning style. It is intended to replace the old Master Boot Record ([[MBR]]) system. GPT has several advantages over MBR, which has quirks dating back to MS-DOS times. With recent developments to the formatting tools fdisk (MBR) and gdisk (GPT), it is equally easy to use GPT or MBR and get maximum performance. <br />
<br />
==== Choosing between GPT and MBR ====<br />
The choice basically boils down to this: <br />
* If using GRUB Legacy as the bootloader, one must use MBR. See [[#Using MBR - Legacy Method]].<br />
* To dual-boot with Windows, one must use MBR. See [[#Using MBR - Legacy Method]].<br />
** A special exception to this rule: dual-booting Windows Vista/7 64 bit, and using [[UEFI]] instead of BIOS, one must use GPT.<br />
* If none of the above apply, choose freely between GPT and MBR. Since GPT is more modern, it is recommended in this case.<br />
<br />
==== Gdisk Usage Summary====<br />
<br />
The GPT-able tool equivalent to {{ic|fdisk}}, {{ic|gdisk}}, can perform partition alignment automatically on a 2048 sector (or 1024KiB) block size base which should be compatible with the vast majority of SSDs if not all. GNU parted also supports GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions. A summary of the typical usage of {{ic|gdisk}}:<br />
<br />
* Install {{ic|gdisk}} through the {{pkg|gptfdisk}} package from the '''extra''' repository.<br />
* Start {{ic|gdisk}} against your SSD.<br />
* If the SSD is brand new or if wanting to start over, create a new empty GUID partition table (aka GPT) with the {{keypress|o}} command.<br />
* Create a new partition with the {{keypress|n}} command (primary type/1st partition).<br />
* Assuming the partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If choosing to start on a sector before the 2048th gdisk will automatically shift the partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the {{ic|<nowiki>+x{M,G}</nowiki>}} format to extend the partition {{ic|x}} megabytes or gigabytes, if choosing a size that is not a multiple of the alignment size (1024kiB), gdisk will shrink the partition to the nearest inferior multiple.<br />
* Select the partition's type id, the default, {{ic|Linux/Windows data}} (code {{ic|0700}}), should be fine for most use. Press {{Keypress|L}} to show the codes list. If planning to use LVM select Linux LVM (8e00).<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the {{keypress|w}} command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If planning to use the GPT partitioned SSD as a boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) one may have to create, preferably at the disk's beginning, a 2 MiB partition with no filesystem and with the partition type as {{ic|BIOS boot}} or {{ic|bios_grub}} partition (gdisk type code {{ic|EF02}}) for booting from the disk using [[GRUB]]. For [[Syslinux]], one does not need to create a separate 2 MiB bios_grub partition, but one needs to have separate {{ic|/boot}} partition and enable {{ic|Legacy BIOS Bootable partition}} attribute for that partition (using gdisk). See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, users must use [[burg]], [[GRUB]] or [[Syslinux]].}}<br />
<br />
{{Warning|If planning to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk in BIOS systems! Users need to use the legacy MBR method described below for dual-boot in BIOS systems! This limitation does not apply if booting in UEFI mode and using Windows Vista (64bits) or 7 (64bits). For 32-bit Windows Vista and 7, and 32 and 64-bit Windows XP, users need to use MBR partitioning and boot in BIOS mode only.}}<br />
<br />
=== Using MBR - Legacy Method ===<br />
Using MBR, the utility for editing the partition table is called {{ic|fdisk}}. Recent versions of fdisk have abandoned the deprecated system of using cylinders as the default display unit, as well as MS-DOS compatibility by default. The latest fdisk automatically aligns all partitions to 2048 sectors, or 1024 KiB, which should work for all EBS sizes that are known to be used by SSD manufacturers. This means that the default settings will give you proper alignment.<br />
<br />
Note that in the olden days, fdisk used cylinders as the default display unit, and retained an MS-DOS compatibility quirk that messed with SSD alignment. Therefore one will find many guides around the internet from around 2008-2009 making a big deal out of getting everything correct. With the latest fdisk, things are much simpler, as reflected in this guide.<br />
<br />
==== Fdisk Usage Summary ====<br />
*Start {{ic|fdisk}}.<br />
*If the SSD is brand new, create a new empty DOS partition table with the {{keypress|o}} command.<br />
*Create a new partition with the {{keypress|n}} command (primary type/1st partition).<br />
*Use the {{ic|+xG}} format to extend the partition {{ic|x}} gigabytes.<br />
*Change the partition's system id from the default type of Linux ({{ic|type 83}}) to the desired type via the {{keypress|t}} command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, LVM, etc. Note that a complete listing of all valid partition types is available via the {{keypress|l}} command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the {{keypress|w}} command.<br />
<br />
When finished, users may format their newly created partitions with {{ic|mkfs.x /dev/sdXN}} where {{ic|x}} is the filesystem, {{ic|X}} is the drive letter, and {{ic|N}} is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{ic|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the {{ic|mkfs}} command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
==See also==<br />
*[[Ext4#Creating ext4 partitions from scratch|Creating ext4 partitions from scratch]]<br />
*[[Wikipedia:Disk partitioning]]</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Partitioning&diff=244283Partitioning2013-01-17T17:40:13Z<p>Leonardodag: /* Partition type */ Removed reference to swap, which is covered in the next section; adding the info about it that was only here to the other section</p>
<hr />
<div>[[Category:File systems]]<br />
[[es:Partitioning]]<br />
[[it:Partitioning]]<br />
[[ja:Partitioning]]<br />
[[ru:Partitioning]]<br />
[[zh-cn:Partitioning]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of disk partitioning tools, best practices, and additional considerations.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|fstab}}<br />
{{Article summary wiki|LVM}}<br />
{{Article summary wiki|Swap}}<br />
{{Article summary wiki|Format a device}}<br />
{{Article summary wiki|File Systems}}<br />
{{Article summary end}}<br />
<br />
''Partitioning'' a hard drive allows one to logically divide the available space into sections that can be accessed independently of one another. Partition information is stored within a hard drive's [[GUID Partition Table]] or [[Master Boot Record]].<br />
<br />
An entire hard drive may be allocated to a single partition, or one may divide the available storage space across multiple partitions. A number of scenarios require creation multiple partitions: dual- or multi-booting, for example, or maintaining a [[swap]] partition. In other cases, partitioning is used as a means of logically separating data, such as creating separate partitions for audio and video files. Common partitioning schemes are discussed in detail below. <br />
<br />
Each partition should be formatted to a [[File Systems|file system type]] before being used.<br />
<br />
Users may create up to four ''primary partitions'' per hard drive (in case of MBR). If additional partitions are required, a single ''extended partition'' can be created instead (that is, up to three primary partitions and one extended partition). An extended partition can be further divided into an unlimited number of ''logical partitions.''<br />
<br />
==Partition type==<br />
<br />
{{out of date|A limit of 4 partitions only applies to MBR.}}<br />
<br />
Partitioning a hard disk drive defines specific memory storage areas. These are called partitions. Each partition behaves as a separate disk and is formatted with a specific filesystem type (see below).<br />
<br />
There are 3 types of disk partitions:<br />
<br />
* Primary<br />
* Extended<br />
** Logical<br />
<br />
'''Primary''' partitions can be bootable and are limited to four partitions per disk or RAID volume. If a partitioning scheme requires more than four partitions, an '''extended''' partition containing '''logical''' partitions is used. Extended partitions can be thought of as containers for logical partitions. A hard disk can contain no more than one extended partition. The extended partition is also counted as a primary partition so if the disk has an extended partition, only three additional primary partitions are possible (i.e. three primary partitions and one extended partition). The number of logical partitions residing in an extended partition is unlimited. A system that dual boots with Windows will require that Windows reside in a primary partition.<br />
<br />
The customary numbering scheme is to create primary partitions {{ic|sda1}} through {{ic|sda3}} followed by an extended partition {{ic|sda4}}. The logical partitions on {{ic|sda4}} are numbered {{ic|sda5}}, {{ic|sda6}}, etc.<br />
<br />
== Partition scheme ==<br />
<br />
There are no strict rules for partitioning a hard drive, although one may follow the general guidance given below. A disk partitioning scheme is determined by various issues such as desired flexibility, speed, security, as well as the limitations imposed by available disk space. It is essentially personal preference. If you would like to dual boot Arch Linux and a Windows operating system please see [[Windows and Arch Dual Boot]].<br />
<br />
=== Single root partition ===<br />
This scheme is the simplest and should be enough for most use cases. A [[swapfile]] can be created and easily resized as needed. It usually makes sense to start by considering a single / partition and then separate out others based on specific use cases like raid, encryption, a shared media partition, etc.<br />
<br />
=== Discrete partitions ===<br />
Separating out a path as a partition allows for the choice of a different filesystem and mount options. In some cases like a media partition, they can also be shared between operating systems.<br />
<br />
<br />
=== Mount points ===<br />
The following mount points are possible choices for separate partitions, you can make your decision based on actual needs.<br />
<br />
====/ (root)====<br />
The root directory is the top of the hierarchy, the point where the primary filesystem is mounted and from which all other filesystems stem. All files and directories appear under the root directory'' {{ic|/}}'', even if they are stored on different physical devices. The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Therefore, certain directories under'' {{ic|/}} ''are not candidates for separate partitions. <br />
<br />
The {{ic|/}} partition or root partition is necessary and it is the most important. The other partitions can be replaced by it.<br />
<br />
{{Warning|Directories essential for booting '''must''' be on the same partition as ''' {{ic|/}}''' or mounted in early userspace by the [[initramfs]]. These essential directories are: {{ic|/bin}}, {{ic|/etc}}, {{ic|/lib}}, {{ic|/sbin}} and {{ic|/usr}}[http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken].}}<br />
<br />
====/boot====<br />
The {{ic|/boot}} directory contains the kernel and ramdisk images as well as the bootloader configuration file and bootloader stages. It also stores data that is used before the kernel begins executing user-space programs. {{ic|/boot}} is not required for normal system operation, but only during boot and kernel upgrades (when regenerating the initial ramdisk).<br />
<br />
A separate {{ic|/boot}} partition is needed if installing a software RAID0 (stripe) system.<br />
<br />
====/home====<br />
The {{ic|/home}} directory contains user-specific configuration files, caches, application data and media files.<br />
<br />
Separating out {{ic|/home}} allows {{ic|/}} to be re-partitioned separately, but note that you can still reinstall Arch with {{ic|/home}} untouched even if it isn't separate - the other top-level directories just need to be removed, and then pacstrap can be run.<br />
<br />
You should not share home directories between users on different distributions, because they use incompatible software versions and patches. Instead, consider sharing a media partition or at least using different home directories on the same {{ic|/home}} partition.<br />
<br />
====/var====<br />
The {{ic|/var}} directory stores variable data such as spool directories and files, administrative and logging data, [[pacman]]'s cache, the [[Arch Build System|ABS]] tree, etc. It is used, for example, for caching and logging, and hence frequently read or written. Keeping it in a separate partition avoids running out of disk space due to flunky logs, etc. <br />
<br />
It exists to make it possible to mount'' {{ic|/usr}} ''as read-only. Everything that historically went into'' {{ic|/usr}} ''that is written to during system operation (as opposed to installation and software maintenance) must reside under'' {{ic|/var}}''.<br />
<br />
{{Note|{{ic|/var}} contains many small files. The choice of filesystem type (see below) should consider this fact if a separate partition is used.}}<br />
<br />
====/tmp====<br />
This is already a separate partition by default, by virtue of being mounted as {{ic|tmpfs}} by systemd.<br />
<br />
====Swap====<br />
A [[swap]] partition provides memory that can be used as virtual RAM. A [[swapfile]] should be considered too, as they have almost no performance overhead compared to a partition but are much easier to resize as needed. A swap partition can ''potentially'' be shared between operating systems, but not if hibernation is used.<br />
<br />
{{Note|The old rule of matching the swap partition size with the available RAM when using [[Suspend_to_Disk|suspend-to-disk]] no longer applies. The default suspend method uses an image the size of 40% of the currently available RAM by default. Even with [[TuxOnIce]] the atomic copy generally only takes about 70% after compression.[http://tuxonice.net/features]}}<br />
<br />
<br />
====How big should my partitions be?====<br />
<br />
The size of the partitions depends on personal preference, but the following information may be helpful: <br />
<br />
; {{ic|/boot}} &mdash; 100 MB : A {{ic|/boot}} partition requires only about 100 MB.<br />
; {{ic|/}} &mdash; 15-20 GB : The root filesystem ({{ic|/}}) '''must''' contain the {{ic|/usr}} directory, which can grow significantly depending upon how much software is installed. 15-20 GB should be sufficient for most users with modern hard disks.<br />
; {{ic|/var}} &mdash; 8-12 GB : The {{ic|/var}} filesystem will contain, among other data, the [[Arch Build System|ABS]] tree and the [[pacman]] cache. Keeping cached packages is useful and versatile as it provides the ability to downgrade. As a result, {{ic|/var}} tends to grow in size. The pacman cache in particular will grow as the system is expanded and updated. It can, however, be safely cleared if space becomes an issue. 8-12 GB on a desktop system should be sufficient for {{ic|/var}}, depending on how much software will be installed.<br />
; {{ic|/home}} &mdash; [very large] : The {{ic|/home}} filesystem is typically where user data, downloads, and multimedia reside. On a desktop system, {{ic|/home}} is typically the largest filesystem on the drive by a large margin.<br />
; {{ic|swap}} &mdash; [varies] : Historically, the general rule for swap partition size was to allocate twice the amount of physical RAM. As computers have gained ever larger memory capacities, this rule has become deprecated. On machines with up to 512MB RAM, the 2x rule is usually adequate. If a sufficient amount of RAM (more than 1024MB) is available, it may be possible to have a smaller swap partition or even eliminate it. With more than 2 GB of physical RAM, one can generally expect good performance without a swap partition.<br />
<br />
{{Note|If available, an extra 25% of space added to each filesystem will provide a cushion for future expansion and help protect against fragmentation.}}<br />
<br />
==Partitioning tools==<br />
*{{App|fdisk|Terminal partitioning tools included in Linux.|https://www.kernel.org/|{{Pkg|util-linux}}}}<br />
*{{App|cfdisk|Terminal partitioning tool written with ncurses libraries.|https://www.kernel.org/|{{Pkg|util-linux}}}}<br />
{{Note|The first partition created by cfdisk starts at sector 63, instead of the usual 2048. This will cause problems with [[GRUB2#msdos-style error message|GRUB2]]. grub-legacy and syslinux should work fine.}}<br />
*{{App|gdisk|[[GPT]] version of fdisk.|http://www.rodsbooks.com/gdisk/|{{Pkg|gptfdisk}}}}<br />
*{{App|cgdisk|[[GPT]] version of cfdisk.|http://www.rodsbooks.com/gdisk/|{{Pkg|gptfdisk}}}}<br />
*{{App|GNU Parted|Terminal partitioning tool.|http://www.gnu.org/software/parted/parted.html|{{pkg|parted}}}}<br />
*{{App|[[GParted]]|Graphical tool written in GTK.|http://gparted.sourceforge.net/|{{Pkg|gparted}}}}<br />
*{{App|Partitionmanager|Graphical tool written in QT.|http://sourceforge.net/projects/partitionman/|{{AUR|partitionmanager}}}}<br />
*{{App|QtParted|Similar to Partitionmanager, available in [[AUR]].|http://qtparted.sourceforge.net/|{{AUR|qtparted}}}}<br />
<br />
==Partition Alignment ==<br />
==== High-level Overview ====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' The key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD.<br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If one does not know the EBS of one's SSD, use a size of 512 KiB. Those numbers are greater or equal than almost all of the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows 7 and Ubuntu "optimize" partitions to work with SSD.}}<br />
<br />
If the partitions are not aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
=== Using GPT - Modern Method ===<br />
[[GPT]] is an alternative, contemporary partitioning style. It is intended to replace the old Master Boot Record ([[MBR]]) system. GPT has several advantages over MBR, which has quirks dating back to MS-DOS times. With recent developments to the formatting tools fdisk (MBR) and gdisk (GPT), it is equally easy to use GPT or MBR and get maximum performance. <br />
<br />
==== Choosing between GPT and MBR ====<br />
The choice basically boils down to this: <br />
* If using GRUB Legacy as the bootloader, one must use MBR. See [[#Using MBR - Legacy Method]].<br />
* To dual-boot with Windows, one must use MBR. See [[#Using MBR - Legacy Method]].<br />
** A special exception to this rule: dual-booting Windows Vista/7 64 bit, and using [[UEFI]] instead of BIOS, one must use GPT.<br />
* If none of the above apply, choose freely between GPT and MBR. Since GPT is more modern, it is recommended in this case.<br />
<br />
==== Gdisk Usage Summary====<br />
<br />
The GPT-able tool equivalent to {{ic|fdisk}}, {{ic|gdisk}}, can perform partition alignment automatically on a 2048 sector (or 1024KiB) block size base which should be compatible with the vast majority of SSDs if not all. GNU parted also supports GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions. A summary of the typical usage of {{ic|gdisk}}:<br />
<br />
* Install {{ic|gdisk}} through the {{pkg|gptfdisk}} package from the '''extra''' repository.<br />
* Start {{ic|gdisk}} against your SSD.<br />
* If the SSD is brand new or if wanting to start over, create a new empty GUID partition table (aka GPT) with the {{keypress|o}} command.<br />
* Create a new partition with the {{keypress|n}} command (primary type/1st partition).<br />
* Assuming the partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If choosing to start on a sector before the 2048th gdisk will automatically shift the partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the {{ic|<nowiki>+x{M,G}</nowiki>}} format to extend the partition {{ic|x}} megabytes or gigabytes, if choosing a size that is not a multiple of the alignment size (1024kiB), gdisk will shrink the partition to the nearest inferior multiple.<br />
* Select the partition's type id, the default, {{ic|Linux/Windows data}} (code {{ic|0700}}), should be fine for most use. Press {{Keypress|L}} to show the codes list. If planning to use LVM select Linux LVM (8e00).<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the {{keypress|w}} command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If planning to use the GPT partitioned SSD as a boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) one may have to create, preferably at the disk's beginning, a 2 MiB partition with no filesystem and with the partition type as {{ic|BIOS boot}} or {{ic|bios_grub}} partition (gdisk type code {{ic|EF02}}) for booting from the disk using [[GRUB]]. For [[Syslinux]], one does not need to create a separate 2 MiB bios_grub partition, but one needs to have separate {{ic|/boot}} partition and enable {{ic|Legacy BIOS Bootable partition}} attribute for that partition (using gdisk). See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, users must use [[burg]], [[GRUB]] or [[Syslinux]].}}<br />
<br />
{{Warning|If planning to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk in BIOS systems! Users need to use the legacy MBR method described below for dual-boot in BIOS systems! This limitation does not apply if booting in UEFI mode and using Windows Vista (64bits) or 7 (64bits). For 32-bit Windows Vista and 7, and 32 and 64-bit Windows XP, users need to use MBR partitioning and boot in BIOS mode only.}}<br />
<br />
=== Using MBR - Legacy Method ===<br />
Using MBR, the utility for editing the partition table is called {{ic|fdisk}}. Recent versions of fdisk have abandoned the deprecated system of using cylinders as the default display unit, as well as MS-DOS compatibility by default. The latest fdisk automatically aligns all partitions to 2048 sectors, or 1024 KiB, which should work for all EBS sizes that are known to be used by SSD manufacturers. This means that the default settings will give you proper alignment.<br />
<br />
Note that in the olden days, fdisk used cylinders as the default display unit, and retained an MS-DOS compatibility quirk that messed with SSD alignment. Therefore one will find many guides around the internet from around 2008-2009 making a big deal out of getting everything correct. With the latest fdisk, things are much simpler, as reflected in this guide.<br />
<br />
==== Fdisk Usage Summary ====<br />
*Start {{ic|fdisk}}.<br />
*If the SSD is brand new, create a new empty DOS partition table with the {{keypress|o}} command.<br />
*Create a new partition with the {{keypress|n}} command (primary type/1st partition).<br />
*Use the {{ic|+xG}} format to extend the partition {{ic|x}} gigabytes.<br />
*Change the partition's system id from the default type of Linux ({{ic|type 83}}) to the desired type via the {{keypress|t}} command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, LVM, etc. Note that a complete listing of all valid partition types is available via the {{keypress|l}} command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the {{keypress|w}} command.<br />
<br />
When finished, users may format their newly created partitions with {{ic|mkfs.x /dev/sdXN}} where {{ic|x}} is the filesystem, {{ic|X}} is the drive letter, and {{ic|N}} is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{ic|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the {{ic|mkfs}} command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
==See also==<br />
*[[Ext4#Creating ext4 partitions from scratch|Creating ext4 partitions from scratch]]<br />
*[[Wikipedia:Disk partitioning]]</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Partitioning&diff=244282Partitioning2013-01-17T17:40:08Z<p>Leonardodag: /* Partition scheme */ Added swap size recommendation that was on the previous section; moved the swap mountpoint to below all other real mountpoints</p>
<hr />
<div>[[Category:File systems]]<br />
[[es:Partitioning]]<br />
[[it:Partitioning]]<br />
[[ja:Partitioning]]<br />
[[ru:Partitioning]]<br />
[[zh-cn:Partitioning]]<br />
{{Article summary start}}<br />
{{Article summary text|An overview of disk partitioning tools, best practices, and additional considerations.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|fstab}}<br />
{{Article summary wiki|LVM}}<br />
{{Article summary wiki|Swap}}<br />
{{Article summary wiki|Format a device}}<br />
{{Article summary wiki|File Systems}}<br />
{{Article summary end}}<br />
<br />
''Partitioning'' a hard drive allows one to logically divide the available space into sections that can be accessed independently of one another. Partition information is stored within a hard drive's [[GUID Partition Table]] or [[Master Boot Record]].<br />
<br />
An entire hard drive may be allocated to a single partition, or one may divide the available storage space across multiple partitions. A number of scenarios require creation multiple partitions: dual- or multi-booting, for example, or maintaining a [[swap]] partition. In other cases, partitioning is used as a means of logically separating data, such as creating separate partitions for audio and video files. Common partitioning schemes are discussed in detail below. <br />
<br />
Each partition should be formatted to a [[File Systems|file system type]] before being used.<br />
<br />
Users may create up to four ''primary partitions'' per hard drive (in case of MBR). If additional partitions are required, a single ''extended partition'' can be created instead (that is, up to three primary partitions and one extended partition). An extended partition can be further divided into an unlimited number of ''logical partitions.''<br />
<br />
==Partition type==<br />
<br />
{{out of date|A limit of 4 partitions only applies to MBR.}}<br />
<br />
Partitioning a hard disk drive defines specific memory storage areas. These are called partitions. Each partition behaves as a separate disk and is formatted with a specific filesystem type (see below).<br />
<br />
There are 3 types of disk partitions:<br />
<br />
* Primary<br />
* Extended<br />
** Logical<br />
<br />
'''Primary''' partitions can be bootable and are limited to four partitions per disk or RAID volume. If a partitioning scheme requires more than four partitions, an '''extended''' partition containing '''logical''' partitions is used. Extended partitions can be thought of as containers for logical partitions. A hard disk can contain no more than one extended partition. The extended partition is also counted as a primary partition so if the disk has an extended partition, only three additional primary partitions are possible (i.e. three primary partitions and one extended partition). The number of logical partitions residing in an extended partition is unlimited. A system that dual boots with Windows will require that Windows reside in a primary partition.<br />
<br />
The customary numbering scheme is to create primary partitions {{ic|sda1}} through {{ic|sda3}} followed by an extended partition {{ic|sda4}}. The logical partitions on {{ic|sda4}} are numbered {{ic|sda5}}, {{ic|sda6}}, etc.<br />
<br />
===Swap partition===<br />
<br />
A swap partition is a place on the drive for virtual RAM. This allows the kernel to access disk space for data that does not fit into physical RAM.<br />
<br />
Historically, the general rule for swap partition size was to allocate twice the amount of physical RAM. As computers have gained ever larger memory capacities, this rule has become deprecated. On machines with up to 512MB RAM, the 2x rule is usually adequate. If a sufficient amount of RAM (more than 1024MB) is available, it may be possible to have a smaller swap partition or even eliminate it. With more than 2 GB of physical RAM, one can generally expect good performance without a swap partition. There is always an option to create a [[HOW TO: Create swap file|swap file]] after the system is setup. <br />
<br />
{{Note|The old rule of matching the swap partition size with the available RAM when using [[Suspend_to_Disk|suspend-to-disk]] no longer applies. The default suspend method uses an image the size of 40% of the currently available RAM by default. Even with [[TuxOnIce]] the atomic copy generally only takes about 70% after compression.[http://tuxonice.net/features]}}<br />
<br />
== Partition scheme ==<br />
<br />
There are no strict rules for partitioning a hard drive, although one may follow the general guidance given below. A disk partitioning scheme is determined by various issues such as desired flexibility, speed, security, as well as the limitations imposed by available disk space. It is essentially personal preference. If you would like to dual boot Arch Linux and a Windows operating system please see [[Windows and Arch Dual Boot]].<br />
<br />
=== Single root partition ===<br />
This scheme is the simplest and should be enough for most use cases. A [[swapfile]] can be created and easily resized as needed. It usually makes sense to start by considering a single / partition and then separate out others based on specific use cases like raid, encryption, a shared media partition, etc.<br />
<br />
=== Discrete partitions ===<br />
Separating out a path as a partition allows for the choice of a different filesystem and mount options. In some cases like a media partition, they can also be shared between operating systems.<br />
<br />
<br />
=== Mount points ===<br />
The following mount points are possible choices for separate partitions, you can make your decision based on actual needs.<br />
<br />
====/ (root)====<br />
The root directory is the top of the hierarchy, the point where the primary filesystem is mounted and from which all other filesystems stem. All files and directories appear under the root directory'' {{ic|/}}'', even if they are stored on different physical devices. The contents of the root filesystem must be adequate to boot, restore, recover, and/or repair the system. Therefore, certain directories under'' {{ic|/}} ''are not candidates for separate partitions. <br />
<br />
The {{ic|/}} partition or root partition is necessary and it is the most important. The other partitions can be replaced by it.<br />
<br />
{{Warning|Directories essential for booting '''must''' be on the same partition as ''' {{ic|/}}''' or mounted in early userspace by the [[initramfs]]. These essential directories are: {{ic|/bin}}, {{ic|/etc}}, {{ic|/lib}}, {{ic|/sbin}} and {{ic|/usr}}[http://freedesktop.org/wiki/Software/systemd/separate-usr-is-broken].}}<br />
<br />
====/boot====<br />
The {{ic|/boot}} directory contains the kernel and ramdisk images as well as the bootloader configuration file and bootloader stages. It also stores data that is used before the kernel begins executing user-space programs. {{ic|/boot}} is not required for normal system operation, but only during boot and kernel upgrades (when regenerating the initial ramdisk).<br />
<br />
A separate {{ic|/boot}} partition is needed if installing a software RAID0 (stripe) system.<br />
<br />
====/home====<br />
The {{ic|/home}} directory contains user-specific configuration files, caches, application data and media files.<br />
<br />
Separating out {{ic|/home}} allows {{ic|/}} to be re-partitioned separately, but note that you can still reinstall Arch with {{ic|/home}} untouched even if it isn't separate - the other top-level directories just need to be removed, and then pacstrap can be run.<br />
<br />
You should not share home directories between users on different distributions, because they use incompatible software versions and patches. Instead, consider sharing a media partition or at least using different home directories on the same {{ic|/home}} partition.<br />
<br />
====/var====<br />
The {{ic|/var}} directory stores variable data such as spool directories and files, administrative and logging data, [[pacman]]'s cache, the [[Arch Build System|ABS]] tree, etc. It is used, for example, for caching and logging, and hence frequently read or written. Keeping it in a separate partition avoids running out of disk space due to flunky logs, etc. <br />
<br />
It exists to make it possible to mount'' {{ic|/usr}} ''as read-only. Everything that historically went into'' {{ic|/usr}} ''that is written to during system operation (as opposed to installation and software maintenance) must reside under'' {{ic|/var}}''.<br />
<br />
{{Note|{{ic|/var}} contains many small files. The choice of filesystem type (see below) should consider this fact if a separate partition is used.}}<br />
<br />
====/tmp====<br />
This is already a separate partition by default, by virtue of being mounted as {{ic|tmpfs}} by systemd.<br />
<br />
====Swap====<br />
A [[swap]] partition provides memory that can be used as virtual RAM. A [[swapfile]] should be considered too, as they have almost no performance overhead compared to a partition but are much easier to resize as needed. A swap partition can ''potentially'' be shared between operating systems, but not if hibernation is used.<br />
<br />
{{Note|The old rule of matching the swap partition size with the available RAM when using [[Suspend_to_Disk|suspend-to-disk]] no longer applies. The default suspend method uses an image the size of 40% of the currently available RAM by default. Even with [[TuxOnIce]] the atomic copy generally only takes about 70% after compression.[http://tuxonice.net/features]}}<br />
<br />
<br />
====How big should my partitions be?====<br />
<br />
The size of the partitions depends on personal preference, but the following information may be helpful: <br />
<br />
; {{ic|/boot}} &mdash; 100 MB : A {{ic|/boot}} partition requires only about 100 MB.<br />
; {{ic|/}} &mdash; 15-20 GB : The root filesystem ({{ic|/}}) '''must''' contain the {{ic|/usr}} directory, which can grow significantly depending upon how much software is installed. 15-20 GB should be sufficient for most users with modern hard disks.<br />
; {{ic|/var}} &mdash; 8-12 GB : The {{ic|/var}} filesystem will contain, among other data, the [[Arch Build System|ABS]] tree and the [[pacman]] cache. Keeping cached packages is useful and versatile as it provides the ability to downgrade. As a result, {{ic|/var}} tends to grow in size. The pacman cache in particular will grow as the system is expanded and updated. It can, however, be safely cleared if space becomes an issue. 8-12 GB on a desktop system should be sufficient for {{ic|/var}}, depending on how much software will be installed.<br />
; {{ic|/home}} &mdash; [very large] : The {{ic|/home}} filesystem is typically where user data, downloads, and multimedia reside. On a desktop system, {{ic|/home}} is typically the largest filesystem on the drive by a large margin.<br />
; {{ic|swap}} &mdash; [varies] : Historically, the general rule for swap partition size was to allocate twice the amount of physical RAM. As computers have gained ever larger memory capacities, this rule has become deprecated. On machines with up to 512MB RAM, the 2x rule is usually adequate. If a sufficient amount of RAM (more than 1024MB) is available, it may be possible to have a smaller swap partition or even eliminate it. With more than 2 GB of physical RAM, one can generally expect good performance without a swap partition.<br />
<br />
{{Note|If available, an extra 25% of space added to each filesystem will provide a cushion for future expansion and help protect against fragmentation.}}<br />
<br />
==Partitioning tools==<br />
*{{App|fdisk|Terminal partitioning tools included in Linux.|https://www.kernel.org/|{{Pkg|util-linux}}}}<br />
*{{App|cfdisk|Terminal partitioning tool written with ncurses libraries.|https://www.kernel.org/|{{Pkg|util-linux}}}}<br />
{{Note|The first partition created by cfdisk starts at sector 63, instead of the usual 2048. This will cause problems with [[GRUB2#msdos-style error message|GRUB2]]. grub-legacy and syslinux should work fine.}}<br />
*{{App|gdisk|[[GPT]] version of fdisk.|http://www.rodsbooks.com/gdisk/|{{Pkg|gptfdisk}}}}<br />
*{{App|cgdisk|[[GPT]] version of cfdisk.|http://www.rodsbooks.com/gdisk/|{{Pkg|gptfdisk}}}}<br />
*{{App|GNU Parted|Terminal partitioning tool.|http://www.gnu.org/software/parted/parted.html|{{pkg|parted}}}}<br />
*{{App|[[GParted]]|Graphical tool written in GTK.|http://gparted.sourceforge.net/|{{Pkg|gparted}}}}<br />
*{{App|Partitionmanager|Graphical tool written in QT.|http://sourceforge.net/projects/partitionman/|{{AUR|partitionmanager}}}}<br />
*{{App|QtParted|Similar to Partitionmanager, available in [[AUR]].|http://qtparted.sourceforge.net/|{{AUR|qtparted}}}}<br />
<br />
==Partition Alignment ==<br />
==== High-level Overview ====<br />
'''Proper partition alignment is essential for optimal performance and longevity.''' The key to alignment is partitioning to (at least) the EBS (erase block size) of the SSD.<br />
<br />
{{Note|The EBS is largely vendor specific; a Google search on the model of interest would be a good idea! The Intel X25-M for example is thought to have an EBS of 512 KiB, but Intel has yet to publish anything officially to this end.}}<br />
{{Note|If one does not know the EBS of one's SSD, use a size of 512 KiB. Those numbers are greater or equal than almost all of the current EBS. Aligning partitions for such an EBS will result in partitions also aligned for all lesser sizes. This is how Windows 7 and Ubuntu "optimize" partitions to work with SSD.}}<br />
<br />
If the partitions are not aligned to begin at multiples of the EBS (512 KiB for example), aligning the file system is a pointless exercise because everything is skewed by the start offset of the partition. Traditionally, hard drives were addressed by indicating the ''cylinder'', the ''head'', and the ''sector'' at which data was to be read or written. These represented the radial position, the drive head (= platter and side) and the axial position of the data respectively. With LBA (logical block addressing), this is no longer the case. Instead, the entire hard drive is addressed as one continuous stream of data.<br />
<br />
=== Using GPT - Modern Method ===<br />
[[GPT]] is an alternative, contemporary partitioning style. It is intended to replace the old Master Boot Record ([[MBR]]) system. GPT has several advantages over MBR, which has quirks dating back to MS-DOS times. With recent developments to the formatting tools fdisk (MBR) and gdisk (GPT), it is equally easy to use GPT or MBR and get maximum performance. <br />
<br />
==== Choosing between GPT and MBR ====<br />
The choice basically boils down to this: <br />
* If using GRUB Legacy as the bootloader, one must use MBR. See [[#Using MBR - Legacy Method]].<br />
* To dual-boot with Windows, one must use MBR. See [[#Using MBR - Legacy Method]].<br />
** A special exception to this rule: dual-booting Windows Vista/7 64 bit, and using [[UEFI]] instead of BIOS, one must use GPT.<br />
* If none of the above apply, choose freely between GPT and MBR. Since GPT is more modern, it is recommended in this case.<br />
<br />
==== Gdisk Usage Summary====<br />
<br />
The GPT-able tool equivalent to {{ic|fdisk}}, {{ic|gdisk}}, can perform partition alignment automatically on a 2048 sector (or 1024KiB) block size base which should be compatible with the vast majority of SSDs if not all. GNU parted also supports GPT, but is [http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=601813 less user-friendly] for aligning partitions. A summary of the typical usage of {{ic|gdisk}}:<br />
<br />
* Install {{ic|gdisk}} through the {{pkg|gptfdisk}} package from the '''extra''' repository.<br />
* Start {{ic|gdisk}} against your SSD.<br />
* If the SSD is brand new or if wanting to start over, create a new empty GUID partition table (aka GPT) with the {{keypress|o}} command.<br />
* Create a new partition with the {{keypress|n}} command (primary type/1st partition).<br />
* Assuming the partition is new, gdisk will pick the highest possible alignment. Otherwise, it will pick the largest power of two that divides all partition offsets.<br />
* If choosing to start on a sector before the 2048th gdisk will automatically shift the partition start to the 2048th disk sector. This is to ensure a 2048-sectors alignment (as a sector is 512B, this is a 1024KiB alignment which should fit any SSD NAND erase block).<br />
* Use the {{ic|<nowiki>+x{M,G}</nowiki>}} format to extend the partition {{ic|x}} megabytes or gigabytes, if choosing a size that is not a multiple of the alignment size (1024kiB), gdisk will shrink the partition to the nearest inferior multiple.<br />
* Select the partition's type id, the default, {{ic|Linux/Windows data}} (code {{ic|0700}}), should be fine for most use. Press {{Keypress|L}} to show the codes list. If planning to use LVM select Linux LVM (8e00).<br />
* Assign other partitions in a like fashion.<br />
* Write the table to disk and exit via the {{keypress|w}} command.<br />
* Create the filesystems as usual.<br />
<br />
{{Warning|If planning to use the GPT partitioned SSD as a boot-disk on a BIOS based system (most systems except Apple computers and some very rare motherboard models with Intel chipset) one may have to create, preferably at the disk's beginning, a 2 MiB partition with no filesystem and with the partition type as {{ic|BIOS boot}} or {{ic|bios_grub}} partition (gdisk type code {{ic|EF02}}) for booting from the disk using [[GRUB]]. For [[Syslinux]], one does not need to create a separate 2 MiB bios_grub partition, but one needs to have separate {{ic|/boot}} partition and enable {{ic|Legacy BIOS Bootable partition}} attribute for that partition (using gdisk). See [[GPT]] for more information.}}<br />
<br />
{{Warning|GRUB legacy does not support GUID partitioning scheme, users must use [[burg]], [[GRUB]] or [[Syslinux]].}}<br />
<br />
{{Warning|If planning to dual boot with Windows (XP, Vista or 7) do NOT use GPT since they do NOT support booting from a GPT disk in BIOS systems! Users need to use the legacy MBR method described below for dual-boot in BIOS systems! This limitation does not apply if booting in UEFI mode and using Windows Vista (64bits) or 7 (64bits). For 32-bit Windows Vista and 7, and 32 and 64-bit Windows XP, users need to use MBR partitioning and boot in BIOS mode only.}}<br />
<br />
=== Using MBR - Legacy Method ===<br />
Using MBR, the utility for editing the partition table is called {{ic|fdisk}}. Recent versions of fdisk have abandoned the deprecated system of using cylinders as the default display unit, as well as MS-DOS compatibility by default. The latest fdisk automatically aligns all partitions to 2048 sectors, or 1024 KiB, which should work for all EBS sizes that are known to be used by SSD manufacturers. This means that the default settings will give you proper alignment.<br />
<br />
Note that in the olden days, fdisk used cylinders as the default display unit, and retained an MS-DOS compatibility quirk that messed with SSD alignment. Therefore one will find many guides around the internet from around 2008-2009 making a big deal out of getting everything correct. With the latest fdisk, things are much simpler, as reflected in this guide.<br />
<br />
==== Fdisk Usage Summary ====<br />
*Start {{ic|fdisk}}.<br />
*If the SSD is brand new, create a new empty DOS partition table with the {{keypress|o}} command.<br />
*Create a new partition with the {{keypress|n}} command (primary type/1st partition).<br />
*Use the {{ic|+xG}} format to extend the partition {{ic|x}} gigabytes.<br />
*Change the partition's system id from the default type of Linux ({{ic|type 83}}) to the desired type via the {{keypress|t}} command. This is an optional step should the user wish to create another type of partition for example, swap, NTFS, LVM, etc. Note that a complete listing of all valid partition types is available via the {{keypress|l}} command.<br />
*Assign other partitions in a like fashion.<br />
*Write the table to disk and exit via the {{keypress|w}} command.<br />
<br />
When finished, users may format their newly created partitions with {{ic|mkfs.x /dev/sdXN}} where {{ic|x}} is the filesystem, {{ic|X}} is the drive letter, and {{ic|N}} is the partition number.<br />
The following example will format the first partition on the first disk to ext4 using the defaults specified in {{ic|/etc/mke2fs.conf}}:<br />
# mkfs.ext4 /dev/sda1<br />
<br />
{{Warning|Using the {{ic|mkfs}} command can be dangerous as a simple mistake can result in formatting the WRONG partition and in data loss! TRIPLE check the target of this command before hitting the Enter key!}}<br />
<br />
==See also==<br />
*[[Ext4#Creating ext4 partitions from scratch|Creating ext4 partitions from scratch]]<br />
*[[Wikipedia:Disk partitioning]]</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=VMware&diff=226326VMware2012-09-30T22:55:56Z<p>Leonardodag: /* Finishing up */ the name of the daemon is vmware, not vmwared.</p>
<hr />
<div>[[Category:Virtualization]]<br />
[[it:VMware]]<br />
[[ru:VMware]]<br />
[[uk:VMware]]<br />
[[zh-CN:VMware]]<br />
{{Article summary start}}<br />
{{Article summary text|This article will explain how to install and configure VMware Workstation/Player in Arch.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Installing Arch Linux in VMware}}<br />
{{Article summary wiki|VirtualBox}}<br />
{{Article summary wiki|KVM}}<br />
{{Article summary wiki|QEMU}}<br />
{{Article summary wiki|Xen}}<br />
{{Article summary wiki|Moving an existing install into (or out of) a virtual machine}}<br />
{{Article summary end}}<br />
<br />
This article is about installing VMware in Arch Linux; you may also be interested in [[Installing Arch Linux in VMware]].<br />
{{Note|This article supports '''only''' the latest major VMware versions, meaning VMware Workstation 9 and VMware Player 5.}}<br />
<br />
==Installation==<br />
<br />
{{Note| VMware Workstation/Player will '''not''' be manageable with pacman as the files are not installed with it.}}<br />
<br />
'''1.''' Download the latest [http://www.vmware.com/products/workstation/overview.html VMware Workstation] or [http://www.vmware.com/products/player/overview.html VMware Player] (you may also try the [http://communities.vmware.com/community/vmtn/beta testing (Beta/RC) versions]).<br />
<br />
'''2.''' Start the installation ({{Ic|--console}} uses terminal instead of the GUI):<br />
$ chmod +x VMware-<edition>-<version>.<release>.<architecture>.bundle<br />
# ./VMware-<edition>-<version>.<release>.<architecture>.bundle --console<br />
<br />
'''3.''' Read & accept the EULA to continue.<br />
<br />
'''4.''' Set {{Ic|System service scripts directory}} to {{ic|/etc/rc.d}}.<br />
<br />
'''5.''' (Optional) If Eclipse is installed, enter the directory path to the Integrated Virtual Debugger.<br />
<br />
'''6.''' You will now get an error about the {{ic|"rc*.d style init script directories"}} not being set. This can, however, be safely ignored.<br />
<br />
'''7.''' Create links for the daemons:<br />
# ln -s /etc/init.d/vmware /etc/rc.d/<br />
# ln -s /etc/init.d/vmware-workstation-server /etc/rc.d/<br />
<br />
==Configuration==<br />
<br />
{{Tip|There is also a package called {{AUR|vmware-patch}} in the [[Arch User Repository|AUR]] with the intention of trying to automate this section (it also supports older VMware versions).}}<br />
<br />
===Module tool paths===<br />
{{Note|As of {{Pkg|kmod}} 5-2 the locations of {{ic|lsmod}}, {{ic|modinfo}}, etc. have changed from {{ic|/bin/}} to {{ic|/usr/bin/}}.}}<br />
<br />
'''8.''' The {{ic|module tool paths}} of certain Workstation scripts now need to be pointed to {{ic|/usr/bin/}} instead of {{ic|/sbin/}}. These include the service script in {{ic|/etc/init.d/}} and some other ones in {{ic|/usr/bin/}}:<br />
<br />
# perl -p -i -e 's|/sbin/(?!modprobe)|/usr/bin/|g' /etc/init.d/vmware /usr/bin/vm-support /usr/bin/vmplayer /usr/bin/vmware /usr/bin/vmware-hostd /usr/bin/vmware-wssc-adminTool<br />
<br />
with VMware Player you need to drop {{ic|/usr/bin/vmware}}, {{ic|/usr/bin/vmware-hostd}} and {{ic|/usr/bin/vmware-wssc-adminTool}}, as they're not included:<br />
# perl -p -i -e 's|/sbin/(?!modprobe)|/usr/bin/|g' /etc/init.d/vmware /usr/bin/vm-support /usr/bin/vmplayer <br />
<br />
{{Note|You will need to redo this upon every update.}}<br />
<br />
As a long-term solution you could also just create symlinks with:<br />
# for i in {ins,ls,rm}mod modinfo; do ln -s /usr/bin/$i /sbin/$i; done<br />
<br />
===VMware module patches and installation===<br />
VMware Workstation 9 and Player 5 both support kernels up to 3.5.<br />
<br />
====3.5 / 3.6rc kernels====<br />
A change in the format of the kernel exception table introduced back in [http://repo.or.cz/w/linux-2.6.git/commit/706276543b699d80f546e45f8b12574e7b18d952 April] affecting the {{ic|vmmon}} module is known to cause crashes in [http://communities.vmware.com/thread/400616 Fedora guests]. The patch [http://communities.vmware.com/message/2092356#2092356 here] creates a portable exception table (packaged together with the script [http://communities.vmware.com/message/2103172#2103172 in here]) and will also install the modules afterwards by executing {{ic|# vmware-modconfig --console --install-all}} (this will also reload the {{ic|vmmon}} module):<br />
<br />
$ cd /tmp<br />
$ curl -O http://communities.vmware.com/servlet/JiveServlet/download/2103172-94260/vmware9_kernel35_patch.tar.bz2<br />
$ tar --strip-components=1 -xvf vmware9_kernel35_patch.tar.bz2 # The "--strip-components=1" flag extracts the files only<br />
# ./patch-modules_3.5.0.sh<br />
<br />
==Finishing up==<br />
<br />
'''9.''' (Optional) Add {{Ic|vmware}} to the [[Daemons|DAEMONS]] array in {{ic|/etc/[[rc.conf]]}} so that the service is started automatically on boot.<br />
<br />
'''10.''' Now, open your VMware Workstation ({{Ic|vmware}} in the console) or VMware Player ({{Ic|vmplayer}} in the console) to configure & use!<br />
<br />
{{Warning|When upgrading the kernel you '''will''' have to rebuild the VMware modules with the following command:<br />
# vmware-modconfig --console --install-all<br />
<br />
Failure to do so may result in a system crash upon powering up virtual machines.}}<br />
<br />
==Tips & Tricks==<br />
<br />
=== Entering the Workstation License Key from terminal ===<br />
# /usr/lib/vmware/bin/vmware-vmx-debug --new-sn XXXXX-XXXXX-XXXXX-XXXXX-XXXXX<br />
<br />
Where {{ic|XXXXX-XXXXX-XXXXX-XXXXX-XXXXX}} is your license key.<br />
<br />
===Extracting the VMware BIOS===<br />
$ objcopy /usr/lib/vmware/bin/vmware-vmx -O binary -j bios440 --set-section-flags bios440=a bios440.rom.Z<br />
$ perl -e 'use Compress::Zlib; my $v; read STDIN, $v, '$(stat -c%s "./bios440.rom.Z")'; $v = uncompress($v); print $v;' < bios440.rom.Z > bios440.rom<br />
<br />
====Using the modified BIOS====<br />
If and when you decide to modify the extracted BIOS you can make your virtual machine use it by moving it to {{ic|~/vmware/<Virtual machine name>}}:<br />
$ mv bios440.rom ~/vmware/<Virtual machine name>/<br />
<br />
then adding the name to the {{Ic|<Virtual machine name>.vmx}} file:<br />
{{hc|~/vmware/<Virtual machine name>/<Virtual machine name>.vmx|2=bios440.filename = "bios440.rom"}}<br />
<br />
===Using DKMS to manage the modules===<br />
The Dynamic Kernel Module Support (DKMS) can be used to manage Workstation modules and to void from re-running {{ic|vmware-modconfig}} each time the kernel changes. The following example uses a custom {{ic|Makefile}} to compile and install the modules through {{ic|vmware-modconfig}}. Afterwards they are removed from the current kernel tree.<br />
<br />
First install {{pkg|dkms}} from the [[Community repository]]:<br />
# pacman -S dkms<br />
<br />
then create a source directory for the {{ic|Makefile}} and the DKMS config file.<br />
# mkdir /usr/src/vmware-modules<br />
<br />
then the {{ic|dkms.conf}} that describes the module names and the compilation/installation procedure. {{ic|1=AUTOINSTALL="yes"}} tells the modules to be recompiled/installed automatically each time:<br />
<br />
{{hc|dkms.conf|<br />
2=PACKAGE_NAME="vmware-modules"<br />
PACKAGE_VERSION="9"<br />
<br />
MAKE[0]="make all"<br />
CLEAN="make clean"<br />
<br />
BUILT_MODULE_NAME[0]="vmmon"<br />
BUILT_MODULE_LOCATION[0]="modules"<br />
<br />
BUILT_MODULE_NAME[1]="vmnet"<br />
BUILT_MODULE_LOCATION[1]="modules"<br />
<br />
BUILT_MODULE_NAME[2]="vmblock"<br />
BUILT_MODULE_LOCATION[2]="modules"<br />
<br />
BUILT_MODULE_NAME[3]="vmci"<br />
BUILT_MODULE_LOCATION[3]="modules"<br />
<br />
BUILT_MODULE_NAME[4]="vsock"<br />
BUILT_MODULE_LOCATION[4]="modules"<br />
<br />
DEST_MODULE_LOCATION[0]="/extra/vmware"<br />
DEST_MODULE_LOCATION[1]="/extra/vmware"<br />
DEST_MODULE_LOCATION[2]="/extra/vmware"<br />
DEST_MODULE_LOCATION[3]="/extra/vmware"<br />
DEST_MODULE_LOCATION[4]="/extra/vmware"<br />
<br />
AUTOINSTALL="yes"<br />
EOF<br />
}}<br />
<br />
and now the {{ic|Makefile}}:<br />
<br />
{{hc|Makefile|<br />
2=KERNEL := $(KERNELRELEASE)<br />
HEADERS := /usr/src/linux-$(KERNEL)/include<br />
GCC := $(shell vmware-modconfig --console --get-gcc)<br />
DEST := /lib/modules/$(KERNEL)/vmware<br />
<br />
TARGETS := vmmon vmnet vmblock vmci vsock<br />
<br />
LOCAL_MODULES := $(addsuffix .ko, $(TARGETS))<br />
<br />
all: $(LOCAL_MODULES)<br />
mkdir -p modules/<br />
mv *.ko modules/<br />
rm -rf $(DEST)<br />
depmod<br />
<br />
%.ko:<br />
vmware-modconfig --console --build-mod -k $(KERNEL) $* $(GCC) $(HEADERS) vmware/<br />
cp -f $(DEST)/$*.ko .<br />
<br />
clean:<br />
rm -rf modules/<br />
EOF<br />
}}<br />
<br />
The modules can then be registered:<br />
<br />
{{hc|# dkms -m vmware-modules -v 9 -k `uname -r` add|<br />
<br />
Creating symlink /var/lib/dkms/vmware-modules/9/source -><br />
/usr/src/vmware-modules-9<br />
<br />
DKMS: add completed.<br />
}}<br />
<br />
built:<br />
<br />
{{hc|# dkms -m vmware-modules -v 9 -k `uname -r` build|<br />
2=Building module:<br />
cleaning build area....<br />
make KERNELRELEASE=3.5.4-1-ARCH all........<br />
cleaning build area.... <br />
<br />
DKMS: build completed.<br />
}}<br />
<br />
and installed:<br />
<br />
{{hc|# dkms -m vmware-modules -v 9 -k `uname -r` install|<br />
vmmon:<br />
Running module version sanity check.<br />
- Original module<br />
- No original module exists within this kernel<br />
- Installation<br />
- Installing to /usr/lib/modules/3.5.4-1-ARCH/extra/vmware/<br />
[...]<br />
depmod.....<br />
<br />
DKMS: install completed.<br />
}}<br />
<br />
If everything went well, the modules will now be recompiled automatically the next time the kernel changes.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Could not open /dev/vmmon: No such file or directory. ===<br />
The full error is:<br />
Could not open /dev/vmmon: No such file or directory.<br />
Please make sure that the kernel module `vmmon' is loaded.<br />
<br />
This means that at least the {{Ic|vmmon}} VMware service is not running. All VMware services can be started with:<br />
# rc.d start vmware<br />
<br />
On [[Systemd|systemd]] only systems ({{ic|rc.d}} is owned by {{Pkg|initscripts}}) you need to create a separate {{ic|.service}} file:<br />
<br />
{{hc|/etc/systemd/system/vmware.service|<br />
2=[Unit]<br />
Description=VMware daemon<br />
[Service]<br />
ExecStart=/etc/rc.d/vmware start<br />
ExecStop=/etc/rc.d/vmware stop<br />
PIDFile=/var/lock/subsys/vmware<br />
TimeoutSec=0<br />
RemainAfterExit=yes<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
then start the service with:<br />
# systemctl start vmware.service<br />
<br />
=== Kernel headers for version 3.x-xxxx were not found. If you installed them[...] ===<br />
Install them with:<br />
# pacman -S linux-headers<br />
<br />
{{Note|Upgrading the kernel and the headers will require you to boot to the new kernel to match the version of the headers. This is a relatively common error.}}<br />
<br />
=== USB devices not recognized ===<br />
For some reason, some installations are missing the {{ic|vmware-USBArbitrator}} script. To readd it manually see [https://bbs.archlinux.org/viewtopic.php?pid=1003117#p1003117 this forum post].<br />
<br />
You may also manually extract the VMware bundle and copy the {{ic|vmware-USBArbitrator}} script from {{ic|<destination folder>/vmware-usbarbitrator/etc/init.d/}} to {{ic|/etc/rc.d/}} (which seems to be its default installation folder instead of {{ic|/etc/init.d/}}):<br />
$ ./VMware-<edition>-<version>.<release>.<architecture>.bundle --console --extract /tmp/vmware-bundle<br />
# cp /tmp/vmware-bundle/vmware-usbarbitrator/etc/init.d/vmware-USBArbitrator /etc/rc.d/<br />
<br />
This could also mean that the {{ic|vmware-usbarbitrator}} binary called in the script is [https://bbs.archlinux.org/viewtopic.php?pid=1156789 segfaulting]:<br />
{{hc|# vmware-usbarbitrator --info -f|<br />
VTHREAD initialize main thread 2 "usbArb" pid 6426<br />
Segmentation fault<br />
}}<br />
<br />
This is caused by an empty {{ic|/etc/arch-release}} (owned by {{pkg|filesystem}}). It is used by the service to alter its behavior based on the distribution's release version.<br />
<br />
To fix it, add a version string in the form of {{ic|<year>.<month>(.<day>)}} (e.g. {{ic|[https://www.archlinux.org/news/new-install-medium-20120907/ 2012.09.07]}}).<br />
<br />
=== process XXXX: Attempt to remove filter function[...] ===<br />
The full error is, for example:<br />
process 6094: Attempt to remove filter function 0xadcc96f0 user data 0xb795aba0, but no such filter has been added<br />
D-Bus not built with -rdynamic so unable to print a backtrace<br />
Aborted<br />
<br />
This means that the hal daemon is not running. Install {{AUR|hal}} from the [[AUR]] and start the daemon with:<br />
# hald<br />
<br />
=== The installer fails to start ===<br />
If you just get back to the prompt when opening the {{ic|.bundle}}, then you probably have a deprecated or broken version of the VMware installer and you should remove it (you may also refer to the [[#Uninstallation|uninstallation]] section of this article):<br />
# rm -r /etc/vmware-installer<br />
<br />
=== Incorrect login/password when trying to access VMware remotely ===<br />
VMware Workstation 9 provides the possibility to remotely manage Shared VMs through the {{ic|vmware-workstation-server}} service. However, this will fail with the error {{ic|"incorrect username/password"}} due to incorrect PAM configuration of the {{ic|vmware-authd}} service. To fix it, edit {{ic|/etc/pam.d/vmware-authd}} like this:<br />
<br />
{{hc|/etc/pam.d/vmware-authd|<br />
#%PAM-1.0<br />
auth required pam_unix.so<br />
account required pam_unix.so<br />
password required pam_permit.so<br />
session required pam_unix.so<br />
}}<br />
<br />
and restart VMware services with:<br />
# rc.d restart vmware vmware-workstation-server<br />
<br />
Now you can connect to the server with the credentials provided during the installation.<br />
<br />
{{Note|{{Pkg|libxslt}} may be required for starting virtual machines.}}<br />
<br />
=== Issues with ALSA output ===<br />
The following instructions from [http://bankimbhavsar.blogspot.co.nz/2011/09/hd-audio-in-vmware-fusion-4-and-vmware.html Bankim Bhavsar's wiki] show how to manually adjust the [[ALSA]] output device in a VMware {{ic|.vmx}} file. This might help with quality issues or with enabling proper HD audio output:<br />
<br />
# Suspend/Power off the VM.<br />
# Run {{ic|aplay -L}}<br />
# If you are interested in playing 5.1 surround sound from the guest, look for {{ic|1=surround51:CARD=vendor-name,DEV=num}}. If you are experiencing quality issues, look out for a line starting with front. <br />
# Open the {{ic|<Virtual machine name>.vmx}} config file of the VM in a text editor, located under {{ic|~/vmware/<Virtual machine name>/}}, and edit the {{ic|sound.fileName}} field, e.g.: {{ic|1=sound.fileName="surround51:CARD=Live,DEV=0"}}. Ensure that it also reads {{ic|1=sound.autodetect="FALSE"}}.<br />
# Resume/Power on the VM.<br />
<br />
==Uninstallation==<br />
<br />
To uninstall VMware you need the product name (either {{ic|vmware-workstation}} or {{ic|vmware-player}}). To list all the installed products:<br />
<br />
# vmware-installer -l<br />
<br />
and uninstall with:<br />
<br />
# vmware-installer -u <vmware-product><br />
<br />
Manually included symlinks have to be removed manually in {{ic|/etc/rc.d/}} and {{ic|/sbin/}}:<br />
# rm /etc/rc.d/vmware /etc/rc.d/vmware-workstation-server /sbin/insmod /sbin/lsmod /sbin/modinfo /sbin/rmmod<br />
<br />
Remember to also remove {{Ic|vmware}} from the {{ic|/etc/rc.conf}} {{Ic|DAEMONS}} array.</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Arch_User_Repository&diff=220433Arch User Repository2012-08-29T23:29:57Z<p>Leonardodag: /* FAQ */ burp is now in official repositories, updated link.</p>
<hr />
<div>[[Category:Arch User Repository]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[cs:Arch User Repository]]<br />
[[da:Arch User Repository]]<br />
[[el:Arch User Repository]]<br />
[[es:Arch User Repository]]<br />
[[fi:AUR]]<br />
[[fr:AUR]]<br />
[[it:Arch User Repository]]<br />
[[ja:Arch User Repository]]<br />
[[nl:Arch User Repository]]<br />
[[pl:Arch User Repository]]<br />
[[pt:Arch User Repository]]<br />
[[ro:AUR]]<br />
[[ru:Arch User Repository]]<br />
[[sr:Arch User Repository]]<br />
[[tr:Arch_Kullanıcı_Deposu]]<br />
[[uk:Arch User Repository]]<br />
[[zh-CN:Arch User Repository]]<br />
{{Article summary start}}<br />
{{Article summary text|The Arch User Repository is a collection of user-submitted [[PKGBUILD]]s that supplement software available from the [[official repositories]]. This article describes how to build ''unsupported'' software packages from the AUR.}}<br />
{{Article summary heading|Overview}}<br />
{{Article summary text|{{Package management overview}}}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|AUR Helpers}}<br />
{{Article summary wiki|AurJson}}<br />
{{Article summary wiki|AUR Trusted User Guidelines}}<br />
{{Article summary heading|Resources}}<br />
{{Article summary link|AUR Web Interface|https://aur.archlinux.org}}<br />
{{Article summary link|AUR Mailing List|http://www.archlinux.org/mailman/listinfo/aur-general}}<br />
{{Article summary end}}<br />
<br />
The Arch User Repository (AUR) is a community-driven repository for Arch users. It contains package descriptions ([[PKGBUILD]]s) that allow you to compile a package from source with [[makepkg]] and then install it via [[pacman]]. The AUR was created to organize and share new packages from the community and to help expedite popular packages' inclusion into the [[#.5Bcommunity.5D|[community]]] repository. This document explains how users can access and utilize the AUR.<br />
<br />
A good number of new packages that enter the official repositories start in the AUR. In the AUR, users are able to contribute their own package builds (PKGBUILD and related files). The AUR community has the ability to vote for or against packages in the AUR. If a package becomes popular enough -- provided it has a compatible license and good packaging technique -- it may be entered into the [community] repository (directly accessible by [[pacman]] or [[ABS|abs]]).<br />
<br />
==Getting started==<br />
Users can search and download PKGBUILDs from the [https://aur.archlinux.org AUR Web Interface]. These PKGBUILDs can be built into installable packages using [[makepkg]], then installed using pacman. <br />
<br />
* Ensure the {{Grp|base-devel}} group package is installed ({{ic|pacman -S base-devel}}).<br />
* Read the remainder of this article for more info and a short tutorial on installing AUR packages.<br />
* Visit the [https://aur.archlinux.org AUR Web Interface] to inform yourself on updates and happenings. There you will also find statistics and an up-to-date list of newest available packages available in AUR.<br />
* Glance over the [[#FAQ]] for answers to the most common questions.<br />
* You may wish to adjust {{ic|/etc/makepkg.conf}} to better optimize for your processor prior to building packages from the AUR. A significant improvement in compile times can be realized on systems with multi-core processors by adjusting the MAKEFLAGS variable. Users can also enable hardware-specific optimizations in GCC via the CFLAGS variable. See [[makepkg.conf]] for more information.<br />
<br />
==History==<br />
The following items are listed for historical purposes only. They have since been superseded by the AUR and are no longer available.<br />
<br />
At the beginning, there was {{ic|<nowiki>ftp://ftp.archlinux.org/incoming</nowiki>}}, and people contributed by simply uploading the PKGBUILD, the needed supplementary files, and the built package itself to the server. The package and associated files remained there until a [[Package Maintainer]] saw the program and adopted it.<br />
<br />
Then the Trusted User Repositories were born. Certain individuals in the community were allowed to host their own repositories for anyone to use. The AUR expanded on this basis, with the aim of making it both more flexible and more usable. In fact, the AUR maintainers are still referred to as TUs (Trusted Users).<br />
<br />
==Searching==<br />
The AUR web interface can be found [https://aur.archlinux.org/ here], and an interface suitable for accessing the AUR from a script (for example) can be found [https://aur.archlinux.org/rpc.php here]<br />
<br />
Queries search package names and descriptions via a MySQL LIKE comparison. This allows for more flexible search criteria (e.g. try searching for 'tool%like%grep' instead of 'tool like grep'). If you need to search for a description that contains '%', escape it with '\%'.<br />
<br />
==Installing packages==<br />
Installing packages from the AUR is a relatively simple process. Essentially:<br />
# Acquire the tarball which contains the [[PKGBUILD]] and possibly other required files<br />
# Extract the tarball (preferably in a folder set aside just for builds from the AUR)<br />
# Run {{ic|makepkg}} in the directory where the files are saved ({{ic|makepkg -s}} will automatically resolve dependencies with pacman)<br />
# Install the resulting package with [[pacman]]:<br />
<br />
# pacman -U /path/to/pkg.tar.xz<br />
<br />
[[AUR Helpers]] add seamless access to the AUR. They vary in their features but can ease in searching, fetching, building, and installing from PKGBUILDs found in the AUR. All of these scripts can be found in the AUR.<br />
<br />
{{Note|There is not and will never be an ''official'' mechanism for installing build material from the AUR. '''All users should be familiar with the build process.'''}}<br />
<br />
What follows is a detailed example of installation of a package called "foo".<br />
<br />
===Prerequisites===<br />
First ensure that the necessary tools are installed. The package group {{grp|base-devel}} should be sufficient; it includes {{pkg|make}} and other tools needed for compiling from source.<br />
<br />
{{Warning|Packages in the AUR assume the {{grp|base-devel}} group is installed, and AUR packages will not list members of this group as dependencies even if the package cannot be built without them. Please ensure this group is installed before complaining about failed builds.}}<br />
<br />
# pacman -S base-devel<br />
<br />
Next choose an appropriate build directory. A build directory is simply a directory where the package will be made or "built" and can be any directory. Examples of commonly used directories are:<br />
<br />
~/builds<br />
<br />
or if using ABS (the [[Arch Build System]]):<br />
<br />
/var/abs/local<br />
<br />
For more information on ABS read the [[Arch Build System]] article. The example will use {{ic|~/builds}} as the build directory.<br />
<br />
===Acquire build files===<br />
Locate the package in the AUR. This is done using the search feature (text field at the top of the [https://aur.archlinux.org/ AUR home page]). Clicking the application's name in the search list brings up an information page on the package. Read through the description to confirm that this is the desired package, note when the package was last updated, and read any comments.<br />
<br />
Download the necessary build files. From the package's information page download the build files by clicking the "Tarball" link on the left-hand side near the end of the package details. This file should be saved to the build directory or otherwise copied to the directory after downloading. In this example, the file is called "foo.tar.gz" (standard format is ''pkgname''.tar.gz, if it has been properly submitted).<br />
<br />
===Build the package===<br />
Extract the tarball. Change directories to the build directory if not already there and extract the build files.<br />
<br />
$ cd ~/builds<br />
$ tar -xvzf foo.tar.gz<br />
<br />
This should create a new directory called "foo" in the build directory.<br />
<br />
{{Warning|'''Carefully check all files.''' {{ic|cd}} to the newly created directory and carefully check the {{ic|PKGBUILD}} and any {{ic|.install}} file for malicious commands. {{ic|PKGBUILD}}s are bash scripts containing functions to be executed by {{ic|makepkg}}: these functions can contain ''any'' valid commands or Bash syntax, so it is totally possible for a {{ic|PKGBUILD}} to contain dangerous commands through malice or ignorance on the part of the author. Since {{ic|makepkg}} uses fakeroot (and should never be run as root), there is some level of protection but you should never count on it. If in doubt, do not build the package and seek advice on the forums or mailing list.}}<br />
<br />
$ cd foo<br />
$ nano PKGBUILD<br />
$ nano foo.install<br />
<br />
Make the package. After manually confirming the integrity of the files, run [[makepkg]] as a normal user in the build directory.<br />
<br />
$ makepkg -s<br />
<br />
The {{ic|-s}} switch will use [[sudo]] to install any needed dependencies. If the use of sudo is undesirable, manually install required dependencies beforehand and exclude the {{ic|-s}} in the above command.<br />
<br />
===Install the package===<br />
Install the package using pacman. A tarball should have been created named:<br />
<br />
<''application name''>-<''application version number''>-<''package revision number''>-<''architecture''>.pkg.tar.xz<br />
<br />
This package can be installed using pacman's "upgrade" command:<br />
<br />
# pacman -U foo-0.1-1-i686.pkg.tar.xz <br />
<br />
These manually installed packages are called foreign packages - packages which have not originated from any repository known to pacman. To list all foreign packages:<br />
$ pacman -Qm <br />
<br />
{{Note|The above example is only a brief summary of the package building process. A visit to the [[makepkg]] and [[Arch Build System|ABS]] pages will provide more detail and is highly recommended, especially for first-time users.}}<br />
<br />
==Feedback==<br />
The [https://aur.archlinux.org AUR Web Interface] has a comments facility that allows users to provide suggestions and feedback on improvements to the PKGBUILD contributor. Avoid pasting patches or PKGBUILDs into the comments section: they quickly become obsolete and just end up needlessly taking up lots of space. Instead email those files to the maintainer, or even use a [[pastebin Clients|pastebin]].<br />
<br />
One of the easiest activities for '''all''' Arch users is to browse the AUR and '''vote''' for their favourite packages using the online interface. All packages are eligible for adoption by a TU for inclusion in [community], and the vote count is one of the considerations in that process; it is in everyone's interest to vote!<br />
<br />
==Sharing and maintaining packages==<br />
The user plays an essential role in the AUR, which cannot fulfill its potential without the support, involvement, and contribution of the wider user community. The life-cycle of an AUR package starts and ends with the user and requires the user to contribute in several ways.<br />
<br />
Users can '''share''' PKGBUILDs using the Arch User Repository. It does not contain any binary packages but allows users to upload PKGBUILDs that can be downloaded by others. These PKGBUILDs are completely unofficial and have not been thoroughly vetted, so they should be used at your own risk.<br />
<br />
===Submitting packages===<br />
After logging in to the AUR web interface, a user can [https://aur.archlinux.org/pkgsubmit.php submit] a gzipped tarball ({{ic|.tar.gz}}) of a directory containing build files for a package. The directory inside the tarball should contain a [[PKGBUILD]], any {{ic|.install}} files, patches, etc. ('''absolutely''' no binaries). Examples of what such a directory should look like can be seen inside {{ic|/var/abs}} if the [[Arch Build System]] was installed.<br />
<br />
The tarball can be created with the following command:<br />
$ makepkg --source <br />
<br />
Note that this is a gzipped tarball; assuming you are uploading a package called ''libfoo'', when you create the file it should look similar to this:<br />
<br />
# List contents of tarball.<br />
$ tar tf libfoo-0.1-1.src.tar.gz<br />
libfoo/<br />
libfoo/PKGBUILD<br />
libfoo/libfoo.install<br />
<br />
When submitting a package, observe the following rules: <br />
* Check the [https://www.archlinux.org/packages/ package database] for the package. If it exists, '''do not''' submit the package. If the current package is broken or is lacking an included feature then please file a [https://bugs.archlinux.org/ bug report].<br />
* Check the AUR for the package. If it is currently maintained, changes can be submitted in a comment for the maintainer's attention. If it is unmaintained, the package can be adopted and updated as required. Do not create duplicate packages.<br />
* Verify carefully that what you are uploading is correct. All contributors must read and adhere to the [[Arch Packaging Standards]] when writing PKGBUILDs. This is essential to the smooth running and general success of the AUR. Remember that you are not going to earn any credit or respect from your peers by wasting their time with a bad PKGBUILD.<br />
* Packages that contain binaries or that are very poorly written may be deleted without warning.<br />
* If you are unsure about the package (or the build/submission process) in any way, submit the PKGBUILD to the [https://mailman.archlinux.org/mailman/listinfo/ AUR Mailing List] or the [https://bbs.archlinux.org/viewforum.php?id=4 AUR boards] on the forum for public review before adding it to the AUR.<br />
* Make sure the package is useful. Will anyone else want to use this package? Is it extremely specialized? If more than a few people would find this package useful, it is appropriate for submission.<br />
* The AUR and official repositories are intended for packages which install generally software and software-related content, including one or more of the following: executable(s); config file(s); online or offline documentation for specific software or the Arch Linux distribution as a whole; media intended to be used directly by software.<br />
* Gain some experience before submitting packages. Build a few packages to learn the process and then submit.<br />
* If you submit a {{ic|package.tar.gz}} with a file named '{{ic|package}}' in it you will get an error: 'Could not change to directory {{ic|/home/aur/unsupported/package/package}}'. To resolve this, rename the file named '{{ic|package}}' to something else, for example, '{{ic|package.rc}}'. When it is installed in the {{ic|pkg}} directory you may rename it back to '{{ic|package}}'.<br />
Make sure to also read [[Arch Packaging Standards#Submitting packages to the AUR]].<br />
<br />
===Maintaining packages===<br />
* If you maintain a package and want to update the PKGBUILD for your package just resubmit it.<br />
* Check for feedback and comments from other users and try to incorporate any improvements they suggest; consider it a learning process!<br />
* Please do not just submit and forget about packages! It is the maintainer's job to maintain the package by checking for updates and improving the PKGBUILD.<br />
* If you do not want to continue to maintain the package for some reason, {{ic|disown}} the package using the AUR web interface and/or post a message to the AUR Mailing List.<br />
<br />
===Other requests===<br />
* Disownment requests and removal requests go to the aur-general mailing list for TUs and other users to decide upon.<br />
* '''Include package name and URL to AUR page''', preferably with a footnote [1].<br />
* Disownment requests will be granted two weeks after the current maintainer has been contacted by email and did not react.<br />
* '''Package merging has been implemented''', users still have to resubmit a package under a new name and may request merging of the old version's comments and votes on the mailing list<br />
* Removal requests require the following information:<br />
** Package name and URL to AUR page<br />
** Reason for deletion, at least a short note <br> '''Notice:''' A package's comments does not sufficiently point out the reasons why a package is up for deletion. Because as soon as a TU takes action, the only place where such information can be obtained is the aur-general mailing list.<br />
** Include supporting details, like when a package is provided by another package, if you are the maintainer yourself, it's renamed and the original owner agreed, etc.<br />
<br />
Removal requests can be disapproved, in which case you'll likely be advised to disown the package for a future packager's reference.<br />
<br />
==[community]==<br />
The [community] repository, maintained by [[Trusted Users]], contains the most popular packages from the AUR. It is enabled by default in {{ic|/etc/pacman.conf}}. If [community] has been disabled or removed, it can be enabled by uncommenting or adding these two lines: <br />
<br />
{{hc|/etc/pacman.conf|<nowiki><br />
...<br />
[community]<br />
Include = /etc/pacman.d/mirrorlist<br />
...<br />
</nowiki>}}<br />
<br />
[community], unlike the AUR, contains binary packages that can be installed directly with [[pacman]] and the build files can also be accessed with the [[Arch Build System|ABS]]. Some of these packages may eventually make the transition to the [core] or [extra] repositories as the developers consider them crucial to the distribution.<br />
<br />
Users can also access the [community] build files by editing {{ic|/etc/abs.conf}} and enabling the [community] repository in the {{ic|REPOS}} array.<br />
<br />
==Git Repo==<br />
A Git Repo of the AUR is maintained by Thomas Dziedzic providing package history among other things. It is updated at least once a day. To clone the repository (several hundred MB):<br />
<br />
$ git clone git://pkgbuild.com/aur-mirror.git<br />
<br />
[http://pkgbuild.com/git/aur-mirror.git/ Web interface], [http://pkgbuild.com/~td123/readme Readme], [http://bbs.archlinux.org/viewtopic.php?id=113099 Forum thread]<br />
<br />
==FAQ==<br />
{{FAQ<br />
|question=What is the AUR?<br />
|answer=The AUR (Arch User Repository) is a place where the Arch Linux community can upload [[PKGBUILD]]s of applications, libraries, etc., and share them with the entire community. Fellow users can then vote for their favorites to be moved into the [community] repository to be shared with Arch Linux users in binary form.}}<br />
<br />
{{FAQ<br />
|question=What kind of packages are permitted on the AUR?<br />
|answer=The packages on the AUR are merely "build scripts", i.e recipes to build binaries for pacman. For most cases, everything is permitted, subject to the abovementioned usefulness and scope guidelines, as long as you are in compliance with the licensing terms of the content. For other cases, where it is mentioned that "you may not link" to downloads, i.e contents that are not redistributable, you may only use the file name itself as the source. This means and requires users to already have the restricted source in the build directory prior to building the package. When in doubt, ask.}}<br />
<br />
{{FAQ<br />
|question=What is a TU?<br />
|answer=A [[AUR Trusted User Guidelines|TU (Trusted User)]] is a person who is chosen to oversee AUR and the [community] repository. They're the ones who maintain popular PKGBUILDs in [community], and overall keep the AUR running.}}<br />
<br />
{{FAQ<br />
|question=What's the difference between the Arch User Repository and [community]?<br />
|answer=The Arch User Repository is where all PKGBUILDs that users submit are stored, and must be built manually with [[makepkg]]. When PKGBUILDs receive enough votes, they are moved into the [community] repository, where the TUs maintain binary packages that can be installed with [[pacman]].}}<br />
<br />
{{FAQ<br />
|question=How many votes does it take to get a PKGBUILD into [community]?<br />
|answer=Usually, at least 10 votes are required for something to move into [community]. However, if a TU wants to support a package, it will often be found in the repository.}}<br />
<br />
{{FAQ<br />
|question=How do I make a PKGBUILD?<br />
|answer=The best resource is [[Creating Packages]]. Remember to look in AUR before creating the PKGBUILD as to not duplicate efforts.}}<br />
<br />
{{FAQ<br />
|question=I'm trying to do {{ic|pacman -S foo}}; it isn't working but I know it's in [community]<br />
|answer=You probably haven't enabled [community] in your {{ic|/etc/pacman.conf}}. Just uncomment the relevant lines.<br />
If [community] is enabled in your {{ic|/etc/pacman.conf}} try running {{ic|pacman -S -y}} first to synchronize the pkgcache before trying your package again.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR is outdated; what do I do?<br />
|answer=For starters, you can flag packages out-of-date. If it stays out-of-date for an extended period of time, the best thing to do is email the maintainer. If there is no response from the maintainer after two weeks, you could send mail to the aur-general mailing list to have a TU orphan the PKGBUILD if you're willing to maintain it yourself. When we are talking about a package which is flagged out of date for more than 3 months and is in general not updated for a long time, please add this in your orphan request.}}<br />
<br />
{{FAQ<br />
|question=I have a PKGBUILD I would like to submit; can someone check it to see if there are any errors?<br />
|answer=If you would like to have your PKGBUILD critiqued, post it on the aur-general mailing list to get feedback from the TUs and fellow AUR members. You could also get help from the [[ArchChannel|IRC channel]], #archlinux on irc.freenode.net. You can also<br />
use [[namcap]] to check your PKGBUILD and the resulting package for errors.}}<br />
<br />
{{FAQ<br />
|question=Foo in AUR doesn't compile when I do {{ic|makepkg}}; what should I do?<br />
|answer=You are probably missing something trivial.<br />
<br />
# Run {{ic|pacman -Syyu}} before compiling anything with {{ic|makepkg}} as the problem may be that your system is not up-to-date.<br />
# Ensure you have both "base" and "base-devel" groups installed.<br />
# Try using the "{{ic|-s}}" option with {{ic|makepkg}} to check and install all the dependencies needed before starting the build process.<br />
<br />
Be sure to first read the PKGBUILD and the comments on the AUR page of the package in question.<br />
The reason might not be trivial after all. Custom CFLAGS, LDFLAGS and MAKEFLAGS can cause failures. It's also possible that the PKGBUILD is broken for everyone. If you cannot figure it out on your own, just report it to the maintainer e.g. by posting the errors you are getting in the comments on the AUR page.}}<br />
<br />
{{FAQ<br />
|question=How can I speed up repeated build processes?<br />
|answer=If you frequently compile code that uses gcc - say, a git or SVN package - you may find [[ccache]], short for "compiler cache", useful.}}<br />
<br />
{{FAQ<br />
|question=How do I access unsupported packages?<br />
|answer=See [[#Installing packages]]}}<br />
<br />
{{FAQ<br />
|question=How can I upload to AUR without using the web interface?<br />
|answer=You can use {{pkg|burp}}, {{AUR|aurploader}} or {{AUR|aurup}} -- these are command-line programs.}}</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=VirtualBox&diff=215219VirtualBox2012-07-28T00:37:31Z<p>Leonardodag: /* Automatic re-compilation of the virtualbox modules with every kernel update */</p>
<hr />
<div>[[Category:Emulators]]<br />
[[Category:Virtualization]]<br />
[[cs:VirtualBox]]<br />
[[es:VirtualBox]]<br />
[[fr:VirtualBox]]<br />
[[hu:VirtualBox]]<br />
[[it:VirtualBox]]<br />
[[pt:VirtualBox]]<br />
[[ru:VirtualBox]]<br />
[[zh-CN:VirtualBox]]<br />
{{Article summary start}}<br />
{{Article summary text|This article is about basic usage of VirtualBox, including running the VirtualBox software within an Arch ''host'', and running an Arch ''guest'' inside a VirtualBox virtual machine.}}<br />
{{Article summary heading|Required software}}<br />
{{Article summary link|VirtualBox|https://www.virtualbox.org}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|VirtualBox Extras}}<br />
{{Article summary wiki|PhpVirtualBox}}<br />
{{Article summary wiki|VirtualBox Arch Linux Guest On Physical Drive}}<br />
{{Article summary wiki|Advanced VirtualBox Networking}}<br />
{{Article summary wiki|Installing Arch Linux from VirtualBox}}<br />
{{Article summary end}}<br />
<br />
'''VirtualBox''' is a virtual PC emulator like [[VMware]]. 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 [[Qt]] GUI interface, as well as headless and [[Wikipedia:SDL|SDL]] command line tools for managing and running virtual machines. It includes ''guest additions'' for some guest operating systems, which integrate functions of the guest and host systems, including sharing files, the clipboard, video acceleration and a “seamless” window integration mode.<br />
<br />
{{Wikipedia|VirtualBox}}<br />
<br />
== Installation on host ==<br />
The basic GPL-licensed VirtualBox suite can be [[pacman|installed]] with the {{Pkg|virtualbox}} package, found in the [[official repositories]]. You will need to install {{pkg|virtualbox-modules}} separately, if it is not installed with the the {{Pkg|virtualbox}} package, which contains the precompiled modules for the stock archlinux kernel. For custom kernels, read [[#Hosts running a custom kernel|the section below]].<br />
<br />
In order to use the graphical interface, based on [[Qt]] ({{ic|VirtualBox}} command), you will also need to install the {{Pkg|qt}} package. This is not required for the simpler SDL-only GUI ({{ic|VBoxSDL}} command) nor for the {{ic|VBoxHeadless}} command.<br />
<br />
If you are using the {{pkg|linux-lts}} kernel you should install also the {{pkg|virtualbox-modules-lts}} package.<br />
<br />
=== Hosts running systemd ===<br />
If kernel modules won't load by adding them to rc.conf then you may need to follow the instructions at [[Systemd#Kernel_modules_loaded_during_boot]]<br />
Alternatively you can just modprobe as root after each boot:<br />
# modprobe vboxdrv<br />
<br />
=== Hosts running a custom kernel ===<br />
VirtualBox works just fine with custom kernels such as [[Linux-ck]] ''without'' the need to keep any of the official ARCH kernel packages on the system. The trick to keeping pacman from bringing down the ARCH kernel packages is to install virtualbox with the {{pkg|virtualbox-source}} package, which contains the source for the virtualbox kernel modules. See {{Bug|26721}} for further explanations.<br />
<br />
Once {{pkg|virtualbox-source}} is installed, simply generate the kernel modules for your custom kernel by running:<br />
# dkms install vboxhost/<virtualbox-source version> -k <your custom kernel's version>/<your architecture><br />
and load it:<br />
# modprobe vboxdrv<br />
<br />
{{Note| (Not working currently) To load/compile virtualbox modules automatically at startup you can install and add {{pkg|dkms}} in your DAEMONS array.}}<br />
<br />
=== Automatic re-compilation of the virtualbox modules with every kernel update ===<br />
{{Warning | Possibly not working. Can someone confirm if this still works now that virtualbox's modules are compiled using dkms?}}<br />
This is possible thanks to {{AUR|virtualbox-hook}} from the [[AUR]]. In '''virtualbox-hook''', the 'automatic re-compilation' functionality is done by a '''vbox hook''' on [[mkinitcpio]] after forcing to update the '''linux-headers''' package. You will need to add 'vbox' to the HOOKS array in /etc/mkinitcpio.conf as well as 'linux-headers' and your custom kernel(s) headers to the SyncFirst array in /etc/pacman.conf for this to work.<br />
<br />
The hook will call the '''vboxbuild''' command to update the virtualbox modules for the version of your new kernel.<br />
<br />
{{Note| If you are using this functionality it's '''important''' to look at the installation process of the linux (or any other kernel) package. vbox hook will tell you if anything goes wrong.}}<br />
{{Note| If your '''custom kernel''' is using some '''non-standard mkinitcpio configuration file''' (ie. linux-zen is using /etc/mkinitcpio-zen.conf) you'll have to manually add '''vbox''' to the HOOKS array so it can be auto re-compiled after a kernel update.}}<br />
{{Note| If you '''aren't using stock linux''' at all and still wanna use auto recompilation, you should remove linux-headers from SyncFirst list of /etc/pacman.conf after running 'vboxbuild'.}}<br />
<br />
== Setup ==<br />
Add the desired username to the '''vboxusers''' [[group]]. Everything may work fine without this step but shared folders and possibly some other optional stuff require it to work. The new group does not automatically apply to existing sessions; the user has to log in again or start a new environment with a command like {{Ic|newgrp}} or {{Ic|sudo -u ''username'' -s}}.<br />
<br />
# gpasswd -a ''username'' vboxusers<br />
<br />
VirtualBox running on Linux uses its own [[kernel modules]], including a mandatory one called '''vboxdrv''', which must be loaded before virtual machines can run. It can be automatically loaded when Arch Linux starts up, or it can be loaded manually when necessary.<br />
<br />
To load the VirtualBox driver at startup, edit {{ic|/etc/[[rc.conf]]}} and add {{ic|vboxdrv}} to the {{ic|MODULES}} array:<br />
MODULES=(... vboxdrv)<br />
<br />
{{Note| You may need to update the kernel modules db in order to avoid 'no such file or directory' error when loading vboxdrv. Run: {{ic|modprobed_db}}.}}<br />
<br />
To load the module manually:<br />
# modprobe vboxdrv<br />
<br />
To start the VirtualBox graphical manager:<br />
$ VirtualBox<br />
<br />
=== Guest additions disc ===<br />
The {{Ic|virtualbox}} package also suggests installing {{pkg|virtualbox-additions}} on the host (Arch Linux) running VirtualBox. It is a disc image that can be used to install the guest additions onto guest systems.<br />
<br />
=== Booting a live disc ===<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 />
=== Advanced setup ===<br />
See [[VirtualBox Extras]] for advanced configuration.<br />
<br />
== Arch Linux guests ==<br />
Installing Arch under VirtualBox is straightforward, and additions should be installed through pacman (not through "Install Guest Additions" in VirtualBox, or a mounted ISO.) Follow these instructions after doing a basic install of the X-window system found on the [[Beginners' Guide]].<br />
<br />
=== Guest additions package ===<br />
Install {{Pkg|virtualbox-archlinux-additions}}.<br />
<br />
=== Kernel modules ===<br />
Manually load the VirtualBox modules with<br />
<br />
# modprobe -a vboxguest vboxsf vboxvideo<br />
<br />
=== Auto-start modules ===<br />
To autostart these modules each time you boot, you can add the three modules above to the MODULES array in ''/etc/rc.conf''.<br />
MODULES=(... vboxguest vboxsf vboxvideo)<br />
<br />
=== Enable VboxClient-all ===<br />
The VBoxClient contain these services({{Ic|/usr/bin/VBoxClient-all}}) (copy/paste...) :<br />
<br />
--clipboard start the shared clipboard service<br />
--display start the display management service<br />
--checkhostversion start the host version notifier service<br />
--seamless start the seamless windows service<br />
<br />
So you can Enable VBoxClient-all to start all these services.<br />
<br />
If you are running something that launches {{Ic|/etc/xdg/autostart/vboxclient.desktop}}, such as GNOME, then you should be ready to go. If you use {{Ic|.xinitrc}} to launch things instead, you must add<br />
VBoxClient-all &<br />
to your {{Ic|.xinitrc}} before launching your WM.<br />
You should now be all set, and all guest additions should work properly.<br />
<br />
=== Using USB webcam / microphone ===<br />
{{Note|You will need to have VirtualBox extension pack installed before following the steps below. See [[VirtualBox_Extras#Extension_pack]] for details.}}<br />
# Make sure the virtual machine is not running and your webcam / microphone is not being used.<br />
# Bring up the main VirtualBox window and go to settings for Arch machine. Go to USB section.<br />
# Make sure "Enable USB Controller" is selected. Also make sure that "Enable USB 2.0 (EHCI) Controller" is selected too.<br />
# Click the "Add filter from device" button (the cable with the '+' icon).<br />
# Select your USB webcam/microphone device from the list.<br />
# Now click OK and start your VM.<br />
<br />
== Shared Folders as Arch Linux Guest ==<br />
Shared folders are managed via the VirtualBox program on the host. They may be added, auto-mounted and made read-only from there. Creating a shared folder from the VirtualBox program in the host locates that folder in {{Ic|/media/sf_''SHAREDFOLDERNAME''}}. At this time an additional step is needed to have that folder created in the Arch Guest because Arch use a package for Guest Additions. To create and access this shared folder from the Arch Guest, this must also be done at the command line after installing the Guest Additions package(s) from pacman:<br />
<br />
# groupadd vboxsf<br />
# gpasswd -a $USER vboxsf<br />
<br />
If you wish, a symbolic link may be made to another folder in your home directory for easy access. As an example, if a shared folder named "Dropbox" was created in the VirtualBox program on the host machine, then /media/sf_Dropbox is automatically created in the guest so this could be done:<br />
<br />
$ ln -s /media/sf_Dropbox/* ~/dropbox<br />
<br />
The .run script provided in the Guest Additions iso does this for you, however, Arch does not recommend using that script so this step must be done manually. The instructions for it were found here: (pastebin: [http://pastebin.com/6cUE3kjF]) .<br />
<br />
If shared folders are not auto-mounted, try [https://bbs.archlinux.org/viewtopic.php?id=70780 manually mount] or read the next section.<br />
<br />
=== Synchronise guest date with host ===<br />
To keep sync date add the following to the guest ''/etc/rc.conf'' in DAEMONS entry:<br />
<br />
DAEMONS=(... vbox-service ...)<br />
<br />
You also need run this daemon in order to use auto-mounting feature of shared folders that are mentioned above.<br />
<br />
== Troubleshooting ==<br />
<br />
=== USB subsystem is not working on the host ===<br />
<br />
Sometimes the usb subsystem is not auto-detected resulting in an error, even when the user is in the '''vboxusers''' group. See this topic [https://bbs.archlinux.org/viewtopic.php?id=125785] for details.<br />
<br />
Adding an entry in {{Ic|/etc/fstab}} should resolve this issue:<br />
<br />
none /proc/bus/usb usbfs auto,busgid=108,busmode=0775,devgid=108,devmode=664 0 0<br />
<br />
=== Failed to create the host-only network interface ===<br />
<br />
It's needed to load kernel modules {{Ic|vboxnetadp}} and {{Ic|vboxnetflt}} in case of creating Host-Only Network adapter.<br />
It's possible to load this kernel module manually with<br />
<br />
# modprobe -a vboxnetadp vboxnetflt<br />
<br />
or add {{Ic|vboxnetadp}} and {{Ic|vboxnetflt}} into MODULES array in {{Ic|/etc/rc.conf}} when it's needed to load modules at boot<br />
<br />
MODULES=(... vboxnetadp vboxnetflt)<br />
<br />
More information in this [https://bbs.archlinux.org/viewtopic.php?id=130581] topic.<br />
<br />
=== WinXP: Bit-depth cannot be greater than 16 ===<br />
<br />
If you are running at 16-bit color depth, then the icons may appear fuzzy/choppy. However, upon attempting to change the color depth to a higher level, the system may restrict you to a lower resolution or simply not enable you to change the depth at all. To fix this, run {{ic|regedit}} add the following key to the Virtual Windows XP registry:<br />
<br />
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]<br />
"ColorDepth"=dword:00000004<br />
<br />
Then update the color depth in the desktop properties window. If nothing happens, force the screen to redraw through some method (i.e. {{Keypress|Host+F}} to redraw/enter full screen)<br />
<br />
=== Mounting .vdi Images ===<br />
<br />
This just work with '''static''' size vdi images! '''Dynamic size won't''' be easy mountable!<br />
First we need one information from your .vdi image<br />
$ VBoxManage internalcommands dumphdinfo Arch_64min.vdi |grep offData<br />
Header: offBlocks=4096 offData=69632<br />
Now '''add to your''' offData 32256. e.g. 32256 + 69632 = 101888<br />
<br />
Now you can mount your vdi image like that<br />
# mount -t ext4 -o rw,noatime,noexec,loop,offset=101888 Arch_64min.vdi /mnt/<br />
<br />
== External links ==<br />
* [http://www.virtualbox.org/manual/UserManual.html VirtualBox User Manual]</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=VirtualBox&diff=215218VirtualBox2012-07-28T00:32:44Z<p>Leonardodag: /* Hosts running a custom kernel */ updated the command to generate kernel modules for custom kernels</p>
<hr />
<div>[[Category:Emulators]]<br />
[[Category:Virtualization]]<br />
[[cs:VirtualBox]]<br />
[[es:VirtualBox]]<br />
[[fr:VirtualBox]]<br />
[[hu:VirtualBox]]<br />
[[it:VirtualBox]]<br />
[[pt:VirtualBox]]<br />
[[ru:VirtualBox]]<br />
[[zh-CN:VirtualBox]]<br />
{{Article summary start}}<br />
{{Article summary text|This article is about basic usage of VirtualBox, including running the VirtualBox software within an Arch ''host'', and running an Arch ''guest'' inside a VirtualBox virtual machine.}}<br />
{{Article summary heading|Required software}}<br />
{{Article summary link|VirtualBox|https://www.virtualbox.org}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|VirtualBox Extras}}<br />
{{Article summary wiki|PhpVirtualBox}}<br />
{{Article summary wiki|VirtualBox Arch Linux Guest On Physical Drive}}<br />
{{Article summary wiki|Advanced VirtualBox Networking}}<br />
{{Article summary wiki|Installing Arch Linux from VirtualBox}}<br />
{{Article summary end}}<br />
<br />
'''VirtualBox''' is a virtual PC emulator like [[VMware]]. 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 [[Qt]] GUI interface, as well as headless and [[Wikipedia:SDL|SDL]] command line tools for managing and running virtual machines. It includes ''guest additions'' for some guest operating systems, which integrate functions of the guest and host systems, including sharing files, the clipboard, video acceleration and a “seamless” window integration mode.<br />
<br />
{{Wikipedia|VirtualBox}}<br />
<br />
== Installation on host ==<br />
The basic GPL-licensed VirtualBox suite can be [[pacman|installed]] with the {{Pkg|virtualbox}} package, found in the [[official repositories]]. You will need to install {{pkg|virtualbox-modules}} separately, if it is not installed with the the {{Pkg|virtualbox}} package, which contains the precompiled modules for the stock archlinux kernel. For custom kernels, read [[#Hosts running a custom kernel|the section below]].<br />
<br />
In order to use the graphical interface, based on [[Qt]] ({{ic|VirtualBox}} command), you will also need to install the {{Pkg|qt}} package. This is not required for the simpler SDL-only GUI ({{ic|VBoxSDL}} command) nor for the {{ic|VBoxHeadless}} command.<br />
<br />
If you are using the {{pkg|linux-lts}} kernel you should install also the {{pkg|virtualbox-modules-lts}} package.<br />
<br />
=== Hosts running systemd ===<br />
If kernel modules won't load by adding them to rc.conf then you may need to follow the instructions at [[Systemd#Kernel_modules_loaded_during_boot]]<br />
Alternatively you can just modprobe as root after each boot:<br />
# modprobe vboxdrv<br />
<br />
=== Hosts running a custom kernel ===<br />
VirtualBox works just fine with custom kernels such as [[Linux-ck]] ''without'' the need to keep any of the official ARCH kernel packages on the system. The trick to keeping pacman from bringing down the ARCH kernel packages is to install virtualbox with the {{pkg|virtualbox-source}} package, which contains the source for the virtualbox kernel modules. See {{Bug|26721}} for further explanations.<br />
<br />
Once {{pkg|virtualbox-source}} is installed, simply generate the kernel modules for your custom kernel by running:<br />
# dkms install vboxhost/<virtualbox-source version> -k <your custom kernel's version>/<your architecture><br />
and load it:<br />
# modprobe vboxdrv<br />
<br />
{{Note| (Not working currently) To load/compile virtualbox modules automatically at startup you can install and add {{pkg|dkms}} in your DAEMONS array.}}<br />
<br />
=== Automatic re-compilation of the virtualbox modules with every kernel update ===<br />
This is possible thanks to {{AUR|virtualbox-hook}} from the [[AUR]]. In '''virtualbox-hook''', the 'automatic re-compilation' functionality is done by a '''vbox hook''' on [[mkinitcpio]] after forcing to update the '''linux-headers''' package. You will need to add 'vbox' to the HOOKS array in /etc/mkinitcpio.conf as well as 'linux-headers' and your custom kernel(s) headers to the SyncFirst array in /etc/pacman.conf for this to work.<br />
<br />
The hook will call the '''vboxbuild''' command to update the virtualbox modules for the version of your new kernel.<br />
<br />
{{Note| If you are using this functionality it's '''important''' to look at the installation process of the linux (or any other kernel) package. vbox hook will tell you if anything goes wrong.}}<br />
{{Note| If your '''custom kernel''' is using some '''non-standard mkinitcpio configuration file''' (ie. linux-zen is using /etc/mkinitcpio-zen.conf) you'll have to manually add '''vbox''' to the HOOKS array so it can be auto re-compiled after a kernel update.}}<br />
{{Note| If you '''aren't using stock linux''' at all and still wanna use auto recompilation, you should remove linux-headers from SyncFirst list of /etc/pacman.conf after running 'vboxbuild'.}}<br />
<br />
== Setup ==<br />
Add the desired username to the '''vboxusers''' [[group]]. Everything may work fine without this step but shared folders and possibly some other optional stuff require it to work. The new group does not automatically apply to existing sessions; the user has to log in again or start a new environment with a command like {{Ic|newgrp}} or {{Ic|sudo -u ''username'' -s}}.<br />
<br />
# gpasswd -a ''username'' vboxusers<br />
<br />
VirtualBox running on Linux uses its own [[kernel modules]], including a mandatory one called '''vboxdrv''', which must be loaded before virtual machines can run. It can be automatically loaded when Arch Linux starts up, or it can be loaded manually when necessary.<br />
<br />
To load the VirtualBox driver at startup, edit {{ic|/etc/[[rc.conf]]}} and add {{ic|vboxdrv}} to the {{ic|MODULES}} array:<br />
MODULES=(... vboxdrv)<br />
<br />
{{Note| You may need to update the kernel modules db in order to avoid 'no such file or directory' error when loading vboxdrv. Run: {{ic|modprobed_db}}.}}<br />
<br />
To load the module manually:<br />
# modprobe vboxdrv<br />
<br />
To start the VirtualBox graphical manager:<br />
$ VirtualBox<br />
<br />
=== Guest additions disc ===<br />
The {{Ic|virtualbox}} package also suggests installing {{pkg|virtualbox-additions}} on the host (Arch Linux) running VirtualBox. It is a disc image that can be used to install the guest additions onto guest systems.<br />
<br />
=== Booting a live disc ===<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 />
=== Advanced setup ===<br />
See [[VirtualBox Extras]] for advanced configuration.<br />
<br />
== Arch Linux guests ==<br />
Installing Arch under VirtualBox is straightforward, and additions should be installed through pacman (not through "Install Guest Additions" in VirtualBox, or a mounted ISO.) Follow these instructions after doing a basic install of the X-window system found on the [[Beginners' Guide]].<br />
<br />
=== Guest additions package ===<br />
Install {{Pkg|virtualbox-archlinux-additions}}.<br />
<br />
=== Kernel modules ===<br />
Manually load the VirtualBox modules with<br />
<br />
# modprobe -a vboxguest vboxsf vboxvideo<br />
<br />
=== Auto-start modules ===<br />
To autostart these modules each time you boot, you can add the three modules above to the MODULES array in ''/etc/rc.conf''.<br />
MODULES=(... vboxguest vboxsf vboxvideo)<br />
<br />
=== Enable VboxClient-all ===<br />
The VBoxClient contain these services({{Ic|/usr/bin/VBoxClient-all}}) (copy/paste...) :<br />
<br />
--clipboard start the shared clipboard service<br />
--display start the display management service<br />
--checkhostversion start the host version notifier service<br />
--seamless start the seamless windows service<br />
<br />
So you can Enable VBoxClient-all to start all these services.<br />
<br />
If you are running something that launches {{Ic|/etc/xdg/autostart/vboxclient.desktop}}, such as GNOME, then you should be ready to go. If you use {{Ic|.xinitrc}} to launch things instead, you must add<br />
VBoxClient-all &<br />
to your {{Ic|.xinitrc}} before launching your WM.<br />
You should now be all set, and all guest additions should work properly.<br />
<br />
=== Using USB webcam / microphone ===<br />
{{Note|You will need to have VirtualBox extension pack installed before following the steps below. See [[VirtualBox_Extras#Extension_pack]] for details.}}<br />
# Make sure the virtual machine is not running and your webcam / microphone is not being used.<br />
# Bring up the main VirtualBox window and go to settings for Arch machine. Go to USB section.<br />
# Make sure "Enable USB Controller" is selected. Also make sure that "Enable USB 2.0 (EHCI) Controller" is selected too.<br />
# Click the "Add filter from device" button (the cable with the '+' icon).<br />
# Select your USB webcam/microphone device from the list.<br />
# Now click OK and start your VM.<br />
<br />
== Shared Folders as Arch Linux Guest ==<br />
Shared folders are managed via the VirtualBox program on the host. They may be added, auto-mounted and made read-only from there. Creating a shared folder from the VirtualBox program in the host locates that folder in {{Ic|/media/sf_''SHAREDFOLDERNAME''}}. At this time an additional step is needed to have that folder created in the Arch Guest because Arch use a package for Guest Additions. To create and access this shared folder from the Arch Guest, this must also be done at the command line after installing the Guest Additions package(s) from pacman:<br />
<br />
# groupadd vboxsf<br />
# gpasswd -a $USER vboxsf<br />
<br />
If you wish, a symbolic link may be made to another folder in your home directory for easy access. As an example, if a shared folder named "Dropbox" was created in the VirtualBox program on the host machine, then /media/sf_Dropbox is automatically created in the guest so this could be done:<br />
<br />
$ ln -s /media/sf_Dropbox/* ~/dropbox<br />
<br />
The .run script provided in the Guest Additions iso does this for you, however, Arch does not recommend using that script so this step must be done manually. The instructions for it were found here: (pastebin: [http://pastebin.com/6cUE3kjF]) .<br />
<br />
If shared folders are not auto-mounted, try [https://bbs.archlinux.org/viewtopic.php?id=70780 manually mount] or read the next section.<br />
<br />
=== Synchronise guest date with host ===<br />
To keep sync date add the following to the guest ''/etc/rc.conf'' in DAEMONS entry:<br />
<br />
DAEMONS=(... vbox-service ...)<br />
<br />
You also need run this daemon in order to use auto-mounting feature of shared folders that are mentioned above.<br />
<br />
== Troubleshooting ==<br />
<br />
=== USB subsystem is not working on the host ===<br />
<br />
Sometimes the usb subsystem is not auto-detected resulting in an error, even when the user is in the '''vboxusers''' group. See this topic [https://bbs.archlinux.org/viewtopic.php?id=125785] for details.<br />
<br />
Adding an entry in {{Ic|/etc/fstab}} should resolve this issue:<br />
<br />
none /proc/bus/usb usbfs auto,busgid=108,busmode=0775,devgid=108,devmode=664 0 0<br />
<br />
=== Failed to create the host-only network interface ===<br />
<br />
It's needed to load kernel modules {{Ic|vboxnetadp}} and {{Ic|vboxnetflt}} in case of creating Host-Only Network adapter.<br />
It's possible to load this kernel module manually with<br />
<br />
# modprobe -a vboxnetadp vboxnetflt<br />
<br />
or add {{Ic|vboxnetadp}} and {{Ic|vboxnetflt}} into MODULES array in {{Ic|/etc/rc.conf}} when it's needed to load modules at boot<br />
<br />
MODULES=(... vboxnetadp vboxnetflt)<br />
<br />
More information in this [https://bbs.archlinux.org/viewtopic.php?id=130581] topic.<br />
<br />
=== WinXP: Bit-depth cannot be greater than 16 ===<br />
<br />
If you are running at 16-bit color depth, then the icons may appear fuzzy/choppy. However, upon attempting to change the color depth to a higher level, the system may restrict you to a lower resolution or simply not enable you to change the depth at all. To fix this, run {{ic|regedit}} add the following key to the Virtual Windows XP registry:<br />
<br />
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows NT\Terminal Services]<br />
"ColorDepth"=dword:00000004<br />
<br />
Then update the color depth in the desktop properties window. If nothing happens, force the screen to redraw through some method (i.e. {{Keypress|Host+F}} to redraw/enter full screen)<br />
<br />
=== Mounting .vdi Images ===<br />
<br />
This just work with '''static''' size vdi images! '''Dynamic size won't''' be easy mountable!<br />
First we need one information from your .vdi image<br />
$ VBoxManage internalcommands dumphdinfo Arch_64min.vdi |grep offData<br />
Header: offBlocks=4096 offData=69632<br />
Now '''add to your''' offData 32256. e.g. 32256 + 69632 = 101888<br />
<br />
Now you can mount your vdi image like that<br />
# mount -t ext4 -o rw,noatime,noexec,loop,offset=101888 Arch_64min.vdi /mnt/<br />
<br />
== External links ==<br />
* [http://www.virtualbox.org/manual/UserManual.html VirtualBox User Manual]</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Benchmarking/Data_storage_devices&diff=214336Benchmarking/Data storage devices2012-07-24T00:42:37Z<p>Leonardodag: /* Using palimpsest */ Why use sudo if you're already root?</p>
<hr />
<div>[[Category:Storage]]<br />
{{Article summary start}}<br />
{{Article summary text|This article covers several Linux-native apps that benchmark I/O devices such as HDDs, SSDs, USB thumb drives, etc. There is also a "database" section specific to SSDs meant to capture user-entered benchmark results.}}<br />
{{Article summary heading|Related Articles}}<br />
{{Article summary wiki|Solid State Drives}}<br />
{{Article summary wiki|Benchmarking}}<br />
{{Article summary end}}<br />
<br />
==Introduction==<br />
Several I/O benchmark options exist under Linux.<br />
<br />
* Using hddparm with the -Tt switch, one can time sequential reads. This method is '''independent''' of partition alignment!<br />
* There is a graphical benchmark called palimpsest contained in the [http://www.archlinux.org/packages/?sort=&arch=&repo=&q=gnome-disk-utility&maintainer=&last_update=&flagged=&limit=50 gnome-disk-utility] package that will give min/max/ave reads along with ave access time and a nice graphical display. This method is '''independent''' of partition alignment!'''<br />
* The dd utility can be used to measure both reads and writes. This method is '''dependent''' on partition alignment! In other words, if you failed to properly align your partitions, this fact will be seen here since you're writing and reading to a mounted filesystem.<br />
* [http://wiki.archlinux.org/index.php/Benchmarking#Bonnie.2B.2B Bonnie++]<br />
<br />
== Using hdparm ==<br />
<br />
# hdparm -Tt /dev/sdX<br />
/dev/sdX:<br />
Timing cached reads: x MB in y seconds = z MB/sec<br />
Timing buffered disk reads: x MB in y seconds = z MB/sec<br />
<br />
{{Note|One should run the above command 4-5 times and manually average the results for an accurate evaluation of read speed per the hddparm man page.}}<br />
<br />
== Using palimpsest ==<br />
<br />
# palimpsest<br />
<br />
Users will need to navigate through the GUI to the benchmark button.<br />
<br />
== Using dd ==<br />
<br />
{{Note|This method requires the command to be executed from a mounted partition on the device of interest!}}<br />
<br />
First, enter a directory on the SSD with at least 1.1 GB of free space (and one that obviously gives your user wrx permissions) and write a test file to measure write speeds and to give the device something to read:<br />
<br />
$ cd /path/to/SSD<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
w bytes (x GB) copied, y s, z MB/s<br />
<br />
Next, clear the buffer-cache to accurately measure read speeds directly from the device:<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
w bytes (x GB) copied, y s, z MB/s<br />
<br />
Now that the last file is in the buffer, repeat the command to see the speed of the buffer-cache:<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
w bytes (x GB) copied, y s, z GB/s<br />
<br />
{{Note|One should run the above command 4-5 times and manually average the results for an accurate evaluation of the buffer read speed.}}<br />
<br />
Finally, delete the temp file<br />
$ rm tempfile<br />
<br />
== Model Specific Data ==<br />
Please contribute to this section using the template below to post results obtained.<br />
<br />
See [http://www.anandtech.com/bench/SSD/65 here] for a nice database of benchmarks.<br />
<br />
=== Template ===<br />
*SSD:<br />
*Model Number:<br />
*Firmware Version:<br />
*Capacity: x GB<br />
*User:<br />
*Kernel:<br />
[*Filesystem: write something about your FS, optional]<br />
[*Notes: additional Notes, optional]<br />
<br />
# hdparm -Tt /dev/sdx<br />
<br />
Minimum Read Rate: x MB/s<br />
Maximum Read Rate: x MB/s<br />
Average Read Rate: x MS/s<br />
Average Access Time x ms<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
<br />
=== Crucial ===<br />
==== Crucial C300 ====<br />
*SSD: Crucial C300 (SATA 3: 6Gb/s)<br />
*Model Number: CTFDDAC128MAG-1G1<br />
*Capacity: 128 GB<br />
*User: jac<br />
<br />
# hdparm -Tt /dev/sdb<br />
/dev/sda:<br />
Timing cached reads: 24112 MB in 2.00 seconds = 12072.84 MB/sec<br />
Timing buffered disk reads: 1056 MB in 3.00 seconds = 351.58 MB/sec<br />
<br />
Minimum Read Rate: 350.88 MB/s<br />
Maximum Read Rate: 351.58 MB/s<br />
Average Read Rate: 351.264 MB/s<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 7.77883 s, 138 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 2.88752 s, 372 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.164471 s, 6.5 GB/s<br />
<br />
==== Crucial M4 ====<br />
*SSD: Crucial M4 (SATA 3: 6Gb/s)<br />
*Model Number: M4-CT128M4SSD2 (Firmware: 0009)<br />
*Capacity: 128 GB<br />
*User: lynix<br />
*Filesystem: ext4 on LVM<br />
*Notes: connected to SATAII 3Gb/s port while benchmarking. firmware matters!<br />
<br />
# hdparm -Tt /dev/sde<br />
/dev/sde:<br />
Timing cached reads: 19094 MB in 2.00 seconds = 9559.40 MB/sec<br />
Timing buffered disk reads: 786 MB in 3.00 seconds = 261.63 MB/sec<br />
<br />
Minimum Read Rate: 271.7 MB/s<br />
Maximum Read Rate: 381.7 MB/s<br />
Average Read Rate: 279.0 MB/s<br />
<br />
Minimum Write Rate: 58.6 MB/s<br />
Maximum Write Rate: 258.9 MB/s<br />
Average Write Rate: 194.8 MB/s<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 5.57478 s, 193 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.00688 s, 268 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.157567 s, 6.8 GB/s<br />
<br />
=== Intel ===<br />
==== Intel 310 Soda Creek ====<br />
*SSD: Intel 310 Soda Creek<br />
*Model Number: SSDMAEMC040G2<br />
*Firmware Version: 2CV1023M<br />
*Capacity: 40 GB<br />
*User: dundee<br />
*Filesystem: ext4<br />
<br />
# hdparm -Tt /dev/sdb<br />
/dev/sdb:<br />
Timing cached reads: 6278 MB in 2.00 seconds = 3141.39 MB/sec<br />
Timing buffered disk reads: 784 MB in 3.00 seconds = 260.96 MB/sec<br />
<br />
Minimum Read Rate: 189.7 MB/s<br />
Maximum Read Rate: 281.1 MB/s<br />
Average Read Rate: 277.1 MS/s<br />
Minimum Write Rate: 30.3 MB/s<br />
Maximum Write Rate: 44.6 MB/s<br />
Average Write Rate: 43.8 MS/s<br />
<br />
Average Access Time 0.1 ms<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 24.3013 s, 44.2 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 5.45325 s, 197 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.255569 s, 4.2 GB/s<br />
<br />
==== Intel X18-M (G2) ====<br />
*SSD: Intel X18-M Generation 2<br />
*Model Number: SSDSA1M1602GN<br />
*Capacity: 160 GB<br />
*User: Cirk<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 2826 MB in 2.00 seconds = 1414.39 MB/sec<br />
Timing buffered disk reads: 694 MB in 3.00 seconds = 231.14 MB/sec<br />
<br />
Minimum Read Rate: 216.1 MB/s<br />
Maximum Read Rate: 283.5 MB/s<br />
Average Read Rate: 271.2 MB/s<br />
Average Access Time 0.1 ms<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 10.4608 s, 103 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.0866 s, 263 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.403244 s, 2.7 GB/s<br />
<br />
==== Intel X25-M (G2) ====<br />
*SSD: Intel X25-M Generation 2<br />
*Model Number: SSDSA2MH080G2R5<br />
*Capacity: 80 GB<br />
*User: Graysky<br />
<br />
# hdparm -Tt /dev/sdb<br />
/dev/sdb:<br />
Timing cached reads: 15644 MB in 1.99 seconds = 7845.48 MB/sec<br />
Timing buffered disk reads: 788 MB in 3.00 seconds = 262.52 MB/sec<br />
<br />
Minimum Read Rate: 253.6 MB/s<br />
Maximum Read Rate: 286.1 MB/s<br />
Average Read Rate: 282.6 MB/s<br />
Average Access Time 0.1 ms<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 13.3236 s, 80.6 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.00297 s, 268 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.169713 s, 6.3 GB/s<br />
<br />
==== Intel X25-M (G2) ====<br />
*SSD: Intel X25-M Generation 2<br />
*Model Number: SSDSA2M160G2GC<br />
*Capacity: 160 GB<br />
*User: fackamato<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 2890 MB in 2.00 seconds = 1445.86 MB/sec<br />
Timing buffered disk reads: 738 MB in 3.00 seconds = 245.69 MB/sec<br />
<br />
Minimum Read Rate: 244.3 MB/s<br />
Maximum Read Rate: 278.6 MB/s<br />
Average Read Rate: 273.3 MB/s<br />
Average Access Time 0.1 ms<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 10.8582 s, 98.9 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.09679 s, 262 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.363709 s, 3.0 GB/s<br />
<br />
==== Intel X25-M (G2) ====<br />
*SSD: Intel X25-M Generation 2<br />
*Model Number: SSDSA2M080G2C<br />
*Capacity: 80 GB<br />
*User: Cirk<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 9384 MB in 2.00 seconds = 4694.29 MB/sec<br />
Timing buffered disk reads: 808 MB in 3.01 seconds = 268.64 MB/sec<br />
<br />
Minimum Read Rate: 229.9 MB/s<br />
Maximum Read Rate: 281.6 MB/s<br />
Average Read Rate: 272.4 MB/s<br />
Average Access Time 0.1 ms<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 15.1671 s, 70.8 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 5.15237 s, 208 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.256211 s, 4.2 GB/s<br />
<br />
==== Intel X25-M (G2) ====<br />
*SSD: Intel X25-M Generation 2<br />
*Model Number: SSDSA2MH120G2K5<br />
*Capacity: 120 GB<br />
*User: timo.hardebusch<br />
<br />
# hdparm -Tt /dev/sdb<br />
/dev/sdb:<br />
Timing cached reads: 4358 MB in 2.00 seconds = 2178.89 MB/sec<br />
Timing buffered disk reads: 752 MB in 3.01 seconds = 250.07 MB/sec<br />
<br />
Minimum Read Rate: 259.1 MB/s<br />
Maximum Read Rate: 283.3 MB/s<br />
Average Read Rate: 280.6 MB/s<br />
Average Access Time 0.1 ms<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 10.1452 s, 106 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.05181 s, 265 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.369308 s, 2.9 GB/s<br />
<br />
=== OCZ ===<br />
==== OCZ-VERTEX 4 128 GB ====<br />
*SSD:OCZ Vertex 4<br />
*Model Number: VTX4-25SAT3 - '''firmware 1.5'''<br />
*Capacity: 128 GB<br />
*User: Graysky<br />
===== In SATA3 Controller =====<br />
{{Note|The SATA controller here is a Highpoint Rocket 620 in PCIe 8.0x slot running at PCIe bus speeds of 5.0 GB/s which is NOT 6.0 GB/s like an onboard SATA3 controller.}}<br />
<br />
# hdparm -Tt /dev/sda<br />
<br />
/dev/sda:<br />
Timing cached reads: 16656 MB in 2.00 seconds = 8338.76 MB/sec<br />
Timing buffered disk reads: 1114 MB in 3.00 seconds = 370.95 MB/sec<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in <br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.71208 s, 228 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 2.72833 s, 394 MB/s<br />
<br />
===== In SATA2 Controller =====<br />
# hdparm -Tt /dev/sda<br />
<br />
/dev/sda:<br />
Timing cached reads: 15842 MB in 2.00 seconds = 7930.79 MB/sec<br />
Timing buffered disk reads: 814 MB in 3.00 seconds = 271.02 MB/sec<br />
<br />
# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.28493 s, 251 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.78546 s, 284 MB/s<br />
<br />
==== OCZ-VERTEX 60gb ====<br />
*SSD:OCZ-VERTEX<br />
*Model Number:Firmware 1.5<br />
*Capacity: 60 GB<br />
*User:Surfed<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 16306 MB in 2.00 seconds = 8162.55 MB/sec<br />
Timing buffered disk reads: 646 MB in 3.00 seconds = 215.09 MB/sec<br />
<br />
<br />
Minimum Read Rate: 226.7 MB/s<br />
Maximum Read Rate: 275.2 MB/s<br />
Average Read Rate: 256.9 MB/s<br />
Average Access Time 0.1 ms<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 7.5581 s, 142 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.55881 s, 236 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.205299 s, 5.2 GB/s<br />
<br />
==== OCZ-VERTEX3 120GO ====<br />
*SSD:OCZ-VERTEX3<br />
*Firmware Version:2.06<br />
*Capacity: 6Gb/s SATA III<br />
*User:[[User:Sputnick]]<br />
*Notes: tested on '''SATA II 3Gb/s Dell Optiplex 780 motherboard''' 0C27VV <br />
<br />
# hdparm -Tt /dev/sdc<br />
<br />
/dev/sdc:<br />
Timing cached reads: 13702 MB in 2.00 seconds = 6859.89 MB/sec<br />
Timing buffered disk reads: 644 MB in 3.00 seconds = 214.40 MB/sec<br />
<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 enregistrements lus<br />
1024+0 enregistrements écrits<br />
1073741824 octets (1,1 GB) copiés, 4,37831 s, 245 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 enregistrements lus<br />
1024+0 enregistrements écrits<br />
1073741824 octets (1,1 GB) copiés, 4,76932 s, 225 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 enregistrements lus<br />
1024+0 enregistrements écrits<br />
1073741824 octets (1,1 GB) copiés, 0,234682 s, 4,6 GB/s<br />
<br />
==== OCZ-VERTEX-TURBO 30gb ====<br />
*SSD:OCZ-VERTEX-TURBO<br />
*Model Number:Firmware 1.5<br />
*Capacity: 30 GB<br />
*User:ScottKidder<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 6286 MB in 2.00 seconds = 3149.62 MB/sec<br />
Timing buffered disk reads: 630 MB in 3.01 seconds = 209.10 MB/sec<br />
<br />
Minimum Read Rate: 211.8 MB/s<br />
Maximum Read Rate: 254.1 MB/s<br />
Average Read Rate: 249.2 MB/s<br />
Average Access Time 0.1 ms<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 21.5437 s, 49.8 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 9.34704 s, 115 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.40667 s, 2.6 GB/s<br />
<br />
==== OCZ-VERTEX2 240GB ====<br />
*SSD: OCZ<br />
*Model Number: Vertex2<br />
*Capacity: 240GB<br />
*User: longint<br />
*Filesystem: btrfs compression=lzo,space_cache<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 10972 MB in 2.00 seconds = 5489.70 MB/sec<br />
Timing buffered disk reads: 648 MB in 3.00 seconds = 215.96 MB/sec<br />
<br />
# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 1.26013 s, 852 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.45112 s, 241 MB/s<br />
<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.320492 s, 3.4 GB/s<br />
<br />
==== OCZ-VERTEX3 120GB ====<br />
*SSD:OCZ-VERTEX3 SATA III<br />
*Firmware Version:2.13<br />
*Capacity: 120 GB<br />
*Filesystem: ext4 with discard and commit=60<br />
*[[User:muflone]]<br />
<br />
# hdparm -Tt /dev/sdc<br />
/dev/sdc:<br />
Timing cached reads: 23870 MB in 2.00 seconds = 11950.12 MB/sec<br />
Timing buffered disk reads: 866 MB in 3.00 seconds = 288.36 MB/sec<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 2.85159 s, 377 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.6931 s, 291 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.10383 s, 10.3 GB/s<br />
<br />
==== OCZ-AGILITY3 120GB ====<br />
*SSD:OCZ-AGILITY3 SATA III<br />
*Firmware Version:2.15<br />
*Capacity: 120 GB<br />
*Filesystem: ext4 with discard<br />
*[[User:bardo]]<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 27738 MB in 2.00 seconds = 13889.38 MB/sec<br />
Timing buffered disk reads: 1158 MB in 3.01 seconds = 385.08 MB/sec<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 2.41537 s, 445 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 2.35961 s, 455 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.130664 s, 8.2 GB/s<br />
<br />
=== Samsung ===<br />
==== SAMSUNG 128GB / SATAII ====<br />
*SSD: SAMSUNG 128GB / SATAII<br />
*Model Number: MMCQE28GFMUP-MVA<br />
*Capacity: 128 GB<br />
*User: Cirk<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 2612 MB in 2.00 seconds = 1307.40 MB/sec<br />
Timing buffered disk reads: 294 MB in 3.01 seconds = 97.67 MB/sec<br />
<br />
Minimum Read Rate: 108.7 MB/s<br />
Maximum Read Rate: 114.5 MB/s<br />
Average Read Rate: 113.7 MB/s<br />
Average Access Time 0.2 ms<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 23.7352 s, 45.2 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 10.7563 s, 99.8 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.464824 s, 2.3 GB/s<br />
<br />
==== SAMSUNG 470 64GB ====<br />
*SSD: SAMSUNG 470 64GB<br />
*Model Number: MZ-5PA064/US<br />
*Firmware: AXM070Q1<br />
*Capacity: 64 GB<br />
*User: skylinux<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 1736 MB in 2.00 seconds = 868.62 MB/sec<br />
Timing buffered disk reads: 516 MB in 3.00 seconds = 171.87 MB/sec<br />
<br />
Minimum Read Rate: 276.5 MB/s<br />
Maximum Read Rate: 278.8 MB/s<br />
Average Read Rate: 278.2 MB/s<br />
Average Access Time 0.2 ms<br />
<br />
# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 5.69714 s, 188 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 5.25116 s, 204 MB/s<br />
<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 1.05824 s, 1.0 GB/s<br />
<br />
==== SAMSUNG 830 128GB ====<br />
*SSD: SAMSUNG 830 128GB<br />
*Model Number: MZ-7PC128D<br />
*Firmware: CXM03B1Q<br />
*Capacity: 128 GB<br />
*[[User: kevincodux]]<br />
*Filesystem: ext4,discard,noatime<br />
*Notes: SATAIII, partitions aligned and no swap<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 22130 MB in 2.00 seconds = 11080.54 MB/sec<br />
Timing buffered disk reads: 1500 MB in 3.00 seconds = 499.38 MB/sec<br />
<br />
# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.42567 s, 313 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 2.04691 s, 525 MB/s<br />
<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.119695 s, 9.0 GB/s<br />
<br />
=== Kingston ===<br />
==== Kingston HyperX 120 GB ====<br />
*SSD: Kingston HyperX 120 GB<br />
*Model Number: SH100S3120G<br />
*Firmware: 320ABBF0<br />
*Capacity: 120 GB<br />
*User: Artsibash<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 26564 MB in 2.00 seconds = 13296.53 MB/sec<br />
Timing buffered disk reads: 1130 MB in 3.00 seconds = 376.16 MB/sec<br />
<br />
# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 2.37858 s, 451 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches <br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 2.48961 s, 431 MB/s<br />
<br />
# dd if=/tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.125463 s, 8.6 GB/s<br />
<br />
==== Kingston SSDNow V+100 128 GB ====<br />
*SSD: Kingston SSDNow v+100 128 GB<br />
*Model Number: SVP100S2128G<br />
*Firmware: CJRA0202<br />
*Capacity: 128 GB<br />
*User: Tuxe<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 11598 MB in 1.99 seconds = 5822.73 MB/sec<br />
Timing buffered disk reads: 598 MB in 3.01 seconds = 198.90 MB/sec<br />
<br />
Minimum Read Rate: 145.8 MB/s<br />
Maximum Read Rate: 259.2 MB/s<br />
Average Read Rate: 243.5 MB/s<br />
Average Access Time 0.1 ms<br />
<br />
# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 9.74199 s, 110 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches <br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.62165 s, 232 MB/s<br />
<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.330142 s, 3.3 GB/s<br />
<br />
==== Kingston SNV425-S2BD 128GB ====<br />
*SSD: Kingston SNV425-S2BD/128GB<br />
*Model Number: SNV425S2128GB<br />
*Firmware: C09112a6<br />
*Capacity: 128 GB<br />
*User: thof<br />
*Filesystem: ext4<br />
*Kernel: 3.3.4<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 3614 MB in 2.00 seconds = 1808.83 MB/sec<br />
Timing buffered disk reads: 736 MB in 3.01 seconds = 244.91 MB/sec<br />
<br />
# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 6.5301 s, 164 MB/s<br />
<br />
# echo 3 > /proc/sys/vm/drop_caches <br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.1377 s, 260 MB/s<br />
<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.363142 s, 3.0 GB/s<br />
<br />
= Encrypted Partitions =<br />
<br />
This section should show some data for encrypted partitions.<br />
<br />
== dm-crypt with AES ==<br />
<br />
Please list your CPU and if you are using AES-NI. Without AES-NI support in the CPU, the processor will be the bottleneck long before you touch the >500MB/s SSD speeds. <br />
<br />
'''i7-620M Benchmark'''<br />
*~570 MB/s :With AES-NI<br />
*~100 MB/s :Without AES-NI<br />
<br />
=== Crucial ===<br />
<br />
The crucial drive does not use any compression to reach its speeds, so it is expected to be fast.<br />
<br />
==== Crucial M4 256 Gb ====<br />
<br />
* User: crobe<br />
* Filesystem: ext4 on dm-crypt<br />
* Running Sata 6 Gbit/s on an older 3 Gbit/s controller<br />
* Comment: The drive is faster on writing ( on fresh space ), which has been observed on the internet. Maybe this is the maximum of my machine.<br />
<br />
# cryptsetup status<br />
type: LUKS1<br />
cipher: aes-xts-plain<br />
keysize: 256 bits<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 3012 MB in 2.00 seconds = 1507.62 MB/sec<br />
Timing buffered disk reads: 558 MB in 3.00 seconds = 185.93 MB/sec<br />
# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 Datensätze ein<br />
1024+0 Datensätze aus<br />
1073741824 Bytes (1,1 GB) kopiert, 7,86539 s, 137 MB/s<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 Datensätze ein<br />
1024+0 Datensätze aus<br />
1073741824 Bytes (1,1 GB) kopiert, 9,78325 s, 110 MB/s<br />
<br />
=== OCZ ===<br />
<br />
The OCZ Drives use compression on Data, so with uncompressible encrypted Data, speeds are expected to be way lower. Still, seek times should be as low as ever and the drive shouldn't get slower when it gets full, so there should be enough speed.<br />
<br />
==== OCZ-VERTEX2 180GB ====<br />
<br />
* SSD: OCZ <br />
* Model Number: Vertex2 <br />
* Capacity: 180Gb <br />
* User: crobe<br />
* Filesystem: ext4 on dm-crypt with AES, essiv, sha256<br />
* The bottleneck for the read/write speeds is definately the drive<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 2842 MB in 2.00 seconds = 1422.61 MB/sec<br />
Timing buffered disk reads: 550 MB in 3.00 seconds = 183.26 MB/sec<br />
# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 Datensätze ein<br />
1024+0 Datensätze aus<br />
1073741824 Bytes (1,1 GB) kopiert, 16,9194 s, 63,5 MB/s<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 Datensätze ein<br />
1024+0 Datensätze aus<br />
1073741824 Bytes (1,1 GB) kopiert, 14,5509 s, 73,8 MB/s<br />
<br />
Same values for bonnie++.<br />
<br />
=== Samsung ===<br />
<br />
==== SAMSUNG 470 128GB ====<br />
<br />
*SSD: SAMSUNG 470 128GB<br />
*Firmware: AXM09B1Q<br />
*Capacity: 128 GB<br />
*User: FredericChopin<br />
<br />
# cryptsetup status<br />
type: LUKS1<br />
cipher: aes-xts-plain<br />
keysize: 512 bits<br />
offset: 8192 sectors<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 3226 MB in 2.00 seconds = 1614.42 MB/sec<br />
Timing buffered disk reads: 570 MB in 3.00 seconds = 189.84 MB/sec<br />
# dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 9.62518 s, 112 MB/s<br />
# echo 3 > /proc/sys/vm/drop_caches<br />
# dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 9.34282 s, 115 MB/s<br />
<br />
== Truecrypt ==<br />
<br />
= Comparison - high end SCSI RAID 0 hard drive benchmark =<br />
== LSI 320-2X Megaraid SCSI == <br />
<br />
* SSD: N/A<br />
* Model Number: LSI MegaRAID 320-2x RAID 0 x 2 Seagate Cheetah ST373455LC 15,000 RPM 146GB drives<br />
* Capacity: 292Gb <br />
* User: rabinnh<br />
* Filesystem: ext4 on x86_64<br />
* Comment: No, this is not an SSD, but Googlers should have a reasonable basis for comparison to a high end hard drive system, and you won't get much higher end for an individual workstation. The cost of this disk subsystem is conservatively $760, and it gives at best half the performance of most SSDs.<br />
<br />
<pre>$sudo hdparm -Tt /dev/sda2<br />
/dev/sda2:<br />
Timing cached reads: 6344 MB in 2.00 seconds = 3174.02 MB/sec<br />
Timing buffered disk reads: 442 MB in 3.01 seconds = 146.97 MB/sec</pre><br />
<br />
<pre>$dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 7.13482 s, 150 MB/s<br />
</pre><br />
<pre><br />
$echo 3 > /proc/sys/vm/drop_caches<br />
$dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 7.24267 s, 148 MB/s</pre><br />
<br />
<pre>$dd if=tempfile of=/dev/null bs=1M count=1024<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.459814 s, 2.3 GB/s</pre></div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Advanced_Format&diff=214334Advanced Format2012-07-23T23:33:47Z<p>Leonardodag: /* Current HDD Models that Employ a 4k Sectors */</p>
<hr />
<div>[[Category:Storage]]<br />
==Introduction==<br />
The 'advanced format' feature reduces overhead by using 4 kilobyte sectors instead of the traditional 512 byte sectors. The old format gave a format efficiency of 87%. Advanced Format results in a format efficiency of 96% which increases space by up to 11%. The 4k sector is slated to become the next standard for HDDs by 2014.<br />
<br />
===More Detailed Explanation===<br />
The main idea behind using 4096-byte sectors is to increase the bit density on each track by reducing the number of gaps which hold Sync/DAM and ECC (Error Correction Code) information between data sectors. For eight 512-byte sectors, the track also holds eight sector gaps.<br />
<br />
By having one single sector of size 4096-byte (8 x 512-byte), the track holds only 1 sector gap for each data sector thus reducing an overhead for a need to support multiple Sync/DAM and ECC blocks and at the same time increasing bit density.<br />
<br />
Linux partitioning tools by default start each partition on sector 63 which leads to a bad performance in HDDs that use this 4K sector size due to misalignment to 4K sector from the beginning of the track.<br />
<br />
===External Links===<br />
*[http://www.anandtech.com/Show/Index/2888?cPage=2&all=False&sort=0&page=1 Western Digital’s Advanced Format: The 4K Sector Transition Begins]<br />
*[http://www.wdc.com/wdproducts/library/WhitePapers/ENG/2579-771430.pdf White paper entitled "Advanced Format Technology."]<br />
*Failure to align one's HDD results in poor read/write performance. See [http://www.linuxconfig.org/linux-wd-ears-advanced-format this article] for specific examples.<br />
<br />
==Current HDD Models that Employ a 4k Sectors==<br />
As of June 2011, there are a limited number of HDDs that support "Advanced Format" or 4k sectors as shown below.<br />
<br />
All drives in this list have a physical sector size of 4096 bytes, but not all drives correctly report this to the OS. The actual value reported (via new fields in the ATA-8 spec) is shown in the table as the physical reported sector size. As this is the value partitioning tools use for alignment, it is important that it should be 4096 to avoid misalignment issues.<br />
<br />
The logical sector size is the sector size used for data transfer. This value multiplied by the number of LBA sectors on the disk gives the disk capacity. Thus a disk with 4096 byte logical sectors will have a lower maximum LBA for the same capacity compared to a drive with 512 byte sectors. Drives with 512 byte logical sectors offer better compatibility with legacy operating systems (roughly those released before 2009) however drives with 4096 byte logical sectors may offer marginally better performance (e.g. more read/write requests may fit into the NCQ buffer.)<br />
<br />
{|class="wikitable"<br />
!rowspan=2| Manufacturer !!rowspan=2| Model !!rowspan=2| Capacity !!colspan=2| Reported sector size (bytes)<br />
|-<br />
! Logical !! Physical<br />
|-<br />
|colspan=5| '''3.5"'''<br />
|-<br />
| Western Digital || WD30EZRX || 3.0 TB || 512 || 4096<br />
|-<br />
| Western Digital || WD30EZRSDTL || 3.0 TB<br />
|-<br />
| Western Digital || WD25EZRSDTL || 2.5 TB<br />
|-<br />
| Samsung || HD204UI || 2.0 TB || 512 || 512<br />
|-<br />
| Seagate || ST1000DL002 || 1.0 TB || 512 || 4096<br />
|-<br />
| Seagate || ST2000DL003 || 2.0 TB || 512 || 512<br />
|-<br />
| Seagate || ST2000DM001 || 2.0 TB || 512 || 4096<br />
|-<br />
| Seagate || ST3000DM001 || 3.0 TB || 512 || 4096<br />
|-<br />
| Western Digital || WD20EARS || 2.0 TB || 512 || [http://community.wdc.com/t5/Desktop/4k-sector-drive-reporting-512-byte-sectors-to-OS-why/td-p/205060 512]<br />
|-<br />
| Western Digital || WD20EARX || 2.0 TB || 512 || 4096<br />
|-<br />
| Western Digital || WD15EARS || 1.5 TB || 512 || [http://excess.org/article/2010/11/wd-hdd-lying-about-4k-sectors/ 4096]<br />
|-<br />
| Western Digital || WD10EARS || 1.0 TB<br />
|-<br />
| Western Digital || WD10EURS || 1.0 TB<br />
|-<br />
| Western Digital || WD8000AARS || 800.0 GB<br />
|-<br />
| Western Digital || WD6400AARS || 640.0 GB<br />
|-<br />
|colspan=5| '''2.5"'''<br />
|-<br />
| Western Digital || WD10JPVT || 1.0 TB || 512 || 4096<br />
|-<br />
| Western Digital || WD10TPVT || 1.0 TB<br />
|-<br />
| Western Digital || WD7500BPVT || 750.0 GB<br />
|-<br />
| Western Digital || WD7500KPVT || 750.0 GB<br />
|-<br />
| Western Digital || WD6400BPVT || 640.0 GB<br />
|-<br />
| Western Digital || WD5000BPVT || 500.0 GB<br />
|-<br />
| Western Digital || WD3200BPVT || 320.0 GB<br />
|-<br />
| Western Digital || WD2500BPVT || 250.0 GB || 512 || 4096<br />
|-<br />
| Western Digital || WD1600BPVT || 160.0 GB<br />
|}<br />
<br />
{{Note| Readers are encouraged to add to this table.}}<br />
<br />
==Aligning Partitions==<br />
===Check your partitions alignment===<br />
{{Note|This only works with [[MBR]], not [[GPT]].}}<br />
# fdisk -lu /dev/sda<br />
...<br />
# Device Boot Start End Blocks Id System<br />
# /dev/sda1 2048 46876671 23437312 7 HPFS/NTFS<br />
<br />
2048 (default since fdisk 2.17.2) means that your HDD is aligned correctly.<br />
Any other value divisible by 8 is good as well.<br />
<br />
===GPT (Recommended)===<br />
When using [[GPT]] partition tables, one need only use gdisk to create partitions which are aligned by default. For an example, see [[SSD#Detailed_Usage_Example]].<br />
<br />
===MBR (Not Recommended)===<br />
One can employ fdisk to align partitions to sector 2048 which will ensure that the partitions are aligned to the 4k sector. Interestingly, in sector mode, the default starting point is not 63 or 64 but 2048 in the current version of fdisk (2.17.2) so it is automatically taking care of the 4k sector size!<br />
<br />
# fdisk -c -u /dev/sda<br />
<br />
==Special Consideration for WD Green HDDs==<br />
<br />
FYI - this section has nothing to do with Advanced Format technology, but this is an appropriate location to share it with users. The WD20EARS (and other sizes include 1.0 and 1.5 TB driver in the series) will attempt to park the read heads once every 8 seconds FOR THE LIFE OF THE HDD which is just horrible! To see if you are affected use the smartctl command (part of smartmontools). If the last column changes rapidly, this section applies to your drive. <br />
# smartctl /dev/sdb -a | grep '^193'<br />
193 Load_Cycle_Count 0x0032 001 001 000 Old_age Always - 597115<br />
<br />
=== Disable via hdparm ===<br />
<br />
Use hdparm in {{ic|/etc/rc.local}} to disable this 'feature' and likely add life to your hdd:<br />
<br />
# echo "hdparm -S 242 /dev/sdX" >> /etc/rc.local<br />
<br />
Alternatively, the following shell script can accomplish this automatically:<br />
#!/bin/sh<br />
for DISK in `fdisk -l | grep [12]000.4 | cut -c13-13`; do<br />
echo hdparm -S 242 /dev/sd$DISK >> /etc/rc.local<br />
done<br />
<br />
==== Western Digital's solution ====<br />
<br />
According to [http://wdc.custhelp.com/app/answers/detail/search/1/a_id/5357/c/130/p/227,294 Western Digital] the solution to this problem is different than the one above, see link for more information. Their solution is instead to disable Advanced power management (Uses more power as turns off all low power modes but results in no load/unload cycles) . Use hdparm in {{ic|/etc/rc.local}} to disable Advanced power management:<br />
<br />
# echo "hdparm -B 255 /dev/sdX" >> /etc/rc.local<br />
<br />
=== Disable atime ===<br />
<br />
Be sure to disable atime by adding the "noatime" or "relatime" (default since kernel 2.6.30) option to each mount in [[fstab]]. Without this flag every file access will force a write to disk waking it up.<br />
<br />
=== Disable via changing firmware value (persistent) ===<br />
<br />
{{Warning|The tool used in this process is experimental, use at your own risk!}}<br />
<br />
{{Note|This method is persistant, you only need to do this once for every drive.}}<br />
<br />
This method will use a utility called idle3ctl to alter the firmware value for the idle3 timer on WD hard drives (similar to wdidle3.exe from WD). The advantage compared to the official utility is you do not need to create a DOS bootdisk first to change the idle3 timer value. Additionally idle3ctl might also work over USB-to-S-ATA bridges (in some cases).<br />
Download [http://idle3-tools.sourceforge.net/ idle3ctl], extract and compile it.<br />
Within the folder that contains the newly compiled binary, execute<br />
<br />
$ sudo ./idle3ctl -g /dev/your_wd_hdd<br />
<br />
to get the raw idle3 timer value.<br />
You can disable the Intellipark feature completely, with:<br />
<br />
$ sudo ./idle3ctl -d /dev/your_wd_hdd<br />
<br />
or set it to a different value (''0''-''255'') with (e.g. 10 seconds):<br />
<br />
$ sudo ./idle3ctl -s 100 /dev/your_wd_hd<br />
<br />
The range ''0''-''128'' is in 0.1s and ''129-255'' in 30s. For the chages to take effect, the drive needs to go through one powercycle, meaning powering it off and on again (on internal drives, a reboot is not sufficient).<br />
<br />
If your WD hard drive is not recognized, you can use the ''--force'' option. For more options see:<br />
<br />
$ ./idle3ctl -h<br />
<br />
Also make sure to disable atime, [[#Disable_atime]].</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=SSH_keys&diff=202937SSH keys2012-05-27T00:12:35Z<p>Leonardodag: /* Securing the authorized_keys file */</p>
<hr />
<div>[[Category:Secure Shell]]<br />
[[tr:SSH_Anahtarları]]<br />
{{i18n|SSH Keys}}<br />
<br />
SSH keys serve as a means of identifying yourself to an SSH server using [[Wikipedia:Public-key cryptography|public-key cryptography]] and [[Wikipedia:Challenge-response authentication|challenge-response authentication]]. One immediate advantange this method has over traditional password authentication is that you can be authenticated by the server without ever having to send your password over the network. Anyone eavesdropping on your connection will not be able to intercept and crack your password because it is never actually transmitted. Additionally, Using SSH keys for authentication virtually eliminates the risk posed by brute-force password attacks by drastically reducing the chances of the attacker correctly guessing the proper credentials.<br />
<br />
As well as offering additional security, SSH key authentication can be more convenient than the more traditional password authentication. When used with a program known as an SSH agent, SSH keys can allow you to connect to a server, or multiple servers, without having to remember or enter your password for each system.<br />
<br />
SSH keys are not without their drawbacks and may not be appropriate for all environments, but in many circumstances they can offer some strong advantages. A general understanding of how SSH keys work will help you decide how and when to use them to meet your needs. This article assumes you already have a basic understanding of the [[Secure Shell]] protocol and have installed the {{Pkg|openssh}} package, available in the [[Official Repositories]].<br />
<br />
==Background==<br />
SSH keys always come in pairs, one private and the other public. The private key is known only to you and it should be safely guarded. By contrast, the public key can be shared freely with any SSH server to which you would like to connect.<br />
<br />
When an SSH server has your public key on file and sees you requesting a connection, it uses your public key to construct and send you a challenge. This challenge is like a coded message and it must be met with the appropriate response before the server will grant you access. What makes this coded message particularly secure is that it can only be understood by someone with the private key. While the public key can be used to encrypt the message, it cannot be used to decrypt that very same message. Only you, the holder of the private key, will be able to correctly understand the challenge and produce the correct response.<br />
<br />
This challenge-response phase happens behind the scenes and is invisible to the user. As long as you hold the private key, which is typically stored in the {{ic|~/.ssh/}} directory, your SSH client should be able to reply with the appropriate response to the server.<br />
<br />
Because private keys are considered sensitive information, they are often stored on disk in an encrypted form. In this case, when the private key is required, a passphrase must first be entered in order to decrypt it. While this might superficially appear the same as entering a login password on the SSH server, it is only used to decrypt the private key on the local system. This passphrase is not, and should not, be transmitted over the network.<br />
<br />
==Generating an SSH key pair==<br />
An SSH key pair can be generated by running the {{ic|ssh-keygen}} command:<br />
{{hc|1=<br />
$ ssh-keygen -b 521 -t ecdsa -C"$(id -un)@$(hostname)-$(date --rfc-3339=date)"|2= <nowiki>Generating public/private ecdsa key pair.<br />
Enter file in which to save the key (/home/username/.ssh/id_ecdsa):<br />
Enter passphrase (empty for no passphrase):<br />
Enter same passphrase again:<br />
Your identification has been saved in /home/username/.ssh/id_ecdsa.<br />
Your public key has been saved in /home/username/.ssh/id_ecdsa.pub.<br />
The key fingerprint is:<br />
dd:15:ee:24:20:14:11:01:b8:72:a2:0f:99:4c:79:7f username@localhost-2011-12-22<br />
The key's randomart image is:<br />
+--[ECDSA 521]---+<br />
| ..oB=. . |<br />
| . . . . . |<br />
| . . . + |<br />
| oo.o . . = |<br />
|o+.+. S . . . |<br />
|=. . E |<br />
| o . |<br />
| . |<br />
| |<br />
+-----------------+</nowiki>}}<br />
<br />
In the above example, {{ic|ssh-keygen}} generates a 521 bit long ({{ic|-b 521}}) public/private ECDSA ({{ic|-t ecdsa}}) key pair with an extended comment including the data ({{ic|-C"$(id -un)"@$(hostname)-$(date --rfc-3339&#61;date)}}). The [http://www.cs.berkeley.edu/~dawnsong/papers/randomart.pdf randomart image] was introduced in OpenSSH 5.1 as an easier means of visually identifying the key fingerprint.<br />
<br />
===Choosing the type of encryption===<br />
The Elliptic Curve Digital Signature Algorithm (ECDSA) provides smaller key sizes and faster operations for equivalent estimated security to the previous methods. It was introduced as the preferred algorithm for authentication in OpenSSH 5.7, see [http://openssh.org/txt/release-5.7 OpenSSH 5.7 Release Notes]. ECDSA keys might not be compatible with systems that ship old versions of OpenSSH. Some vendors also disable the required implementations due to potential patent issues.<br />
<br />
If you choose to create an RSA (2048-4096 bit) or DSA (1024 bit) key pair instead of ECDSA, use the {{ic|-t rsa}} or {{ic|-t dsa}} switches in your {{ic|ssh-keygen}} command and do not forget to increase the key size. Running {{ic|ssh-keygen}} without the {{ic|-b}} switch should provide reasonable defaults.<br />
<br />
{{Note|These keys are used only to authenticate you, choosing stronger keys will not increase CPU load when transferring data over SSH.}}<br />
<br />
===Choosing the key location and passphrase===<br />
Upon issuing the {{ic|ssh-keygen}} command, you will be prompted for the desired name an location of your private key. By default, keys are stored in the {{ic|~/.ssh/}} directory and named according the type of encryption used. You are advised to accept the default name and location in order for later code examples in this article to work properly.<br />
<br />
When prompted for a passphrase, choose something that will be hard to guess if you have the security of your private key in mind. A longer, more random password will generally be stronger and harder to crack should it fall into the wrong hands.<br />
<br />
It is also possible to create your private key without a passphrase. While this can be convenient, you need to be aware of the associated risks. Without a passphrase, your private key will be stored on disk in an unencrypted form. Anyone who gains access to your private key file will then be able to assume your identity on any SSH server to which you connect using key-based authentication. Furthermore, without a passphrase, you must also trust the root user, as he can bypass file permissions and will be able to access your unencrypted private key file at any time.<br />
<br />
==Copying the public key to the remote server==<br />
Once you have generated a key pair, you will need to copy the public key to the remote server so that it will use SSH key authentication. The public key file shares the same name as the private key except that is appended with a {{ic|.pub}} extension. Note that the private key is not shared and remains on the local machine.<br />
<br />
===Simple method===<br />
If your key file is {{ic|~/.ssh/id_rsa.pub}} you can simply enter the following command.<br />
$ ssh-copy-id remote-server.org<br />
<br />
If your username differs on remote machine, be sure to prepend the username followed by {{ic|@}} to the server name.<br />
$ ssh-copy-id username@remote-server.org<br />
<br />
If your public key filename is anything other than the default of {{ic|~/.ssh/id_rsa.pub}} you will get an error stating {{ic|/usr/bin/ssh-copy-id: ERROR: No identities found}}. In this case, you must explicitly provide the location of the public key.<br />
$ ssh-copy-id -i ~/.ssh/id_ecdsa.pub username@remote-server.org<br />
<br />
If the ssh server is listening on a port other than default of 22, be sure to include it within the host argument.<br />
$ ssh-copy-id -i ~/.ssh/id_rsa.pub '-p 221 username@remote-server.org'<br />
<br />
===Traditional method===<br />
By default, for OpenSSH, the public key needs to be concatenated with {{ic|~/.ssh/authorized_keys}}. Begin by copying the public key to the remote server.<br />
<br />
$ scp ~/.ssh/id_ecdsa.pub username@remote-server.org:<br />
<br />
The above example copies the public key ({{ic|id_ecdsa.pub}}) to your home directory on the remote server via {{ic|scp}}. Do not forget to include the {{ic|:}} at the end of the server address. Also note that the name of your public key may differ from the example given.<br />
<br />
On the remote server, you will need to create the {{ic|~/.ssh}} directory if it does not yet exist and append your public key to the {{ic|authorized_keys}} file.<br />
<br />
$ ssh username@remote-server.org<br />
username@remote-server.org's password:<br />
$ mkdir ~/.ssh<br />
$ cat ~/id_ecdsa.pub >> ~/.ssh/authorized_keys<br />
$ rm ~/id_ecdsa.pub<br />
$ chmod 600 ~/.ssh/authorized_keys<br />
<br />
The last two commands remove the public key file from the server and set the permissions on the {{ic|authorized_keys}} file such that it is only readable and writable by you, the owner.<br />
<br />
===Securing the authorized_keys file===<br />
You can further protect the {{ic|authorized_keys}} file from modification by changing its ownership and file permissions. Create a group, say, sshusers, add your user (say, john) to the group, and give the {{ic|authorized_keys}} file read permissions to the group only. In this case, you should give the file to user root and group sshusers. This way, if your user account gets compromised somehow, an attacker cannot change the {{ic|authorized_keys}} file without the root password. As root, run the following commands:<br />
<br />
# groupadd sshusers<br />
# gpasswd -a john sshusers<br />
# chown root:sshusers /home/john/.ssh/authorized_keys<br />
# chmod 050 /home/john/.ssh/authorized_keys <br />
<br />
Note that, if you do not need your user to write to the .ssh directory (you do not need to write to known_hosts, for example), you can also restrict .ssh in this way. This is useful if the server is going to be used for a restricted purpose, like backups for example. <br />
<br />
Disconnect from the server and then attempt to reconnect. You should now be asked for the passphrase of the key.<br />
<br />
$ ssh username@remote-server.org<br />
Enter passphrase for key '/home/username/.ssh/id_ecdsa':<br />
<br />
If you are unable to login with the key, double check the permissions on the {{ic|authorized_keys}} file.<br />
<br />
Also check the permissions on the {{ic|~/.ssh}} directory, which should have write permissions off for 'group' and 'other'. Run the following command to disable 'group' and 'other' write permissions for the {{ic|~/.ssh}} directory.<br />
$ chmod go-w ~/.ssh<br />
<br />
==Disabling password logins==<br />
While copying your public key to the remote SSH server eliminates the need to transmit your password over the network, it does not give any added protection against a brute-force password attack. In the absence of a private key, the SSH server will fall back to password authentication by default, thus allowing a malicious user to attempt to gain access by guessing your password. To disable this behavior, edit the following lines in the {{ic|/etc/ssh/sshd_config}} file on the remote server.<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
PasswordAuthentication no<br />
ChallengeResponseAuthentication no}}<br />
<br />
==SSH agents==<br />
If your private key is encrypted with a passphrase, this passphrase must be entered every time you attempt to connect to an SSH server using public-key authentication. Each individual invocation of {{ic|ssh}} or {{ic|scp}} will need the passphrase in order to decrypt your private key before authentication can proceed.<br />
<br />
An SSH agent is a program which caches your decrypted private keys and provides them to SSH client programs on your behalf. In this arrangement, you must only provide your passphrase once, when adding your private key to the agent's cache. This facility can be of great convenience when making frequent SSH connections.<br />
<br />
An agent is typically configured to run automatically upon login and persist for the duration of your login session. A variety of agents, front-ends, and configurations exist to achieve this effect. This section provides an overview of a number of different solutions which can be adapted to meet your specific needs.<br />
<br />
===ssh-agent===<br />
ssh-agent is the default agent included with OpenSSH. It can be used directly or serve as the back-end to a few of the front-end solutions mentioned later in this section. When {{ic|ssh-agent}} is run, it will fork itself to the background and print out the environment variables it would use.<br />
<br />
$ ssh-agent<br />
SSH_AUTH_SOCK=/tmp/ssh-vEGjCM2147/agent.2147; export SSH_AUTH_SOCK;<br />
SSH_AGENT_PID=2148; export SSH_AGENT_PID;<br />
echo Agent pid 2148;<br />
<br />
To make use of these variables, run the command through the {{ic|eval}} command.<br />
<br />
$ eval $(ssh-agent)<br />
Agent pid 2157<br />
<br />
You can append the above command to your {{ic|~/.bash_profile}} script so that it will run automatically when starting a login shell.<br />
<br />
$ echo 'eval $(ssh-agent)' >> ~/.bash_profile<br />
<br />
If you would rather have ssh-agent run automatically for all users append the command to {{ic|/etc/profile}} instead.<br />
<br />
# echo 'eval $(ssh-agent)' >> /etc/profile<br />
<br />
Once {{ic|ssh-agent}} is running, you will need to add your private key to its cache.<br />
<br />
$ ssh-add ~/.ssh/id_ecdsa<br />
Enter passphrase for /home/user/.ssh/id_ecdsa:<br />
Identity added: /home/user/.ssh/id_ecdsa (/home/user/.ssh/id_ecdsa)<br />
<br />
If you would like your private keys to be added automatically on login. Append the following command to your {{ic|~/.bash_profile}} as well.<br />
<br />
$ echo 'ssh-add' >> ~/.bash_profile<br />
<br />
If your private key is encrypted {{ic|ssh-add}} will prompt you to enter your passphrase. Once your private key has been successfully added to the agent you will be able to make SSH connections without having to enter a passphrase.<br />
<br />
One downside to this approach is that a new instance of {{ic|ssh-agent}} is created for every login shell and each instance will persist between login sessions. Over time you can wind up with dozens of needless {{ic|ssh-agent}} processes running. There exist a number of front-ends to ssh-agent and alternative agents described later in this section which avoid this problem.<br />
<br />
===GnuPG Agent===<br />
<br />
{{Note|The stock gnupg Arch Linux package does not support ECC encryption and signing. Hence you cannot use the GnuPG agent to manage ECDSA keys.}}<br />
<br />
The [[GnuPG]] agent, distributed with the {{Pkg|gnupg}} package, available in the [[Official Repositories|official repositories]], has OpenSSH agent emulation. If you use GPG you might consider using its agent to take care of all of your keys. Otherwise you might like the PIN entry dialog it provides and its passphrase management, which is different from Keychain.<br />
<br />
To start using GPG agent for your SSH keys you should first start the gpg-agent with the {{ic|--enable-ssh-support}} option. Example (do not forget to make the file executable):<br />
{{hc|/etc/profile.d/gpg-agent.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Start the GnuPG agent and enable OpenSSH agent emulation<br />
gnupginf="${HOME}/.gpg-agent-info"<br />
<br />
if pgrep -u "${USER}" gpg-agent >/dev/null 2>&1; then<br />
eval `cat $gnupginf`<br />
eval `cut -d= -f1 $gnupginf | xargs echo export`<br />
else<br />
eval `gpg-agent -s --enable-ssh-support --daemon`<br />
fi<br />
</nowiki>}}<br />
<br />
Once gpg-agent is running you can use ssh-add to approve keys, just like you did with plain ssh-agent. The list of approved keys is stored in the {{ic|~/.gnupg/sshcontrol}} file. Once your key is approved you will get a PIN entry dialog every time your passphrase is needed. You can control passphrase caching in the {{ic|~/.gnupg/gpg-agent.conf}} file. The following example would have gpg-agent cache your keys for 3 hours: <br />
<br />
# Cache settings<br />
default-cache-ttl 10800<br />
default-cache-ttl-ssh 10800<br />
<br />
Other useful settings for this file include the PIN entry program (GTK, QT or ncurses version), keyboard grabbing and so on...:<br />
<br />
{{Note|gpg-agent.conf must be created and the variable 'write-env-file' must be set in order to allow gpg-agent keys to be injected to SSH across logins. (Unless you restart the gpg-agent, and therefore export its settings, with every login.)}}<br />
<br />
# Environment file<br />
write-env-file /home/username/.gpg-agent-info<br />
<br />
# Keyboard control<br />
#no-grab<br />
<br />
# PIN entry program<br />
#pinentry-program /usr/bin/pinentry-curses<br />
#pinentry-program /usr/bin/pinentry-qt4<br />
#pinentry-program /usr/bin/pinentry-kwallet<br />
pinentry-program /usr/bin/pinentry-gtk-2<br />
<br />
===Keychain===<br />
[http://www.funtoo.org/en/security/keychain/intro/ Keychain] is a program designed to help you easily manage your SSH keys with minimal user interaction. It is implemented as a shell script which drives both {{ic|ssh-agent}} and {{ic|ssh-add}}. A notable feature of Keychain is that it can maintain a single {{ic|ssh-agent}} process across multiple login sessions. This means that you only need to enter your passphrase once each time your local machine is booted.<br />
<br />
[[pacman|Install]] the {{Pkg|keychain}} package, available from the [[Official Repositories]].<br />
<br />
Append the following line to {{ic|~/.bash_profile}}, or create {{ic|/etc/profile.d/keychain.sh}} as root and make it executable (e.g. {{ic|chmod 755 keychain.sh}}):<br />
{{hc|~/.bash_profile|<br />
eval $(keychain --eval --agents ssh -Q --quiet id_ecdsa)<br />
}}<br />
<br />
In the above example, the {{ic|--eval}} switch outputs lines to be evaluated by the opening {{ic|eval}} command. This sets the necessary environments variables for SSH client to be able to find your agent. The {{ic|--agents}} switch is not strictly necessary, because Keychain will build the list automatically based on the existence of ssh-agent or gpg-agent on the system. Adding the {{ic|--quiet}} switch will limit output to warnings, errors, and user prompts. If you want greater security replace {{ic|-Q}} with {{ic|--clear}} but will be less convenient.<br />
<br />
If necessary, replace {{ic|~/.ssh/id_ecdsa}} with the path to your private key. For those using a non-Bash compatible shell, see {{ic|keychain --help}} or {{ic|man keychain}} for details on other shells.<br />
<br />
To test Keychain, log out from your session and log back in. If this is your first time running Keychain, it will prompt you for the passphrase of the specified private key. Because Keychain reuses the same {{ic|ssh-agent}} process on successive logins, you shouldn't have to enter your passphrase the next time you log in. You will only ever be prompted for your passphrase once each time the machine is rebooted.<br />
<br />
====Alternate startup methods====<br />
There are numerous ways in which Keychain can be invoked and you are encouraged to experiment to find a method that works for you. The {{ic|keychain}} command itself comes with dozens of command-line options which are described in the Keychain man page.<br />
<br />
One alternative implementation of a Keychain startup script could be to create the file {{ic|/etc/profile.d/keychain.sh}} as the root user and add the following lines.<br />
<br />
{{hc|/etc/profile.d/keychain.sh|<nowiki><br />
/usr/bin/keychain -Q -q --nogui ~/.ssh/id_ecdsa<br />
[[ -f $HOME/.keychain/$HOSTNAME-sh ]] && source $HOME/.keychain/$HOSTNAME-sh<br />
</nowiki>}}<br />
<br />
Be sure to also make {{ic|/etc/profile.d/keychain.sh}} executable by changing its file permissions.<br />
# chmod 755 /etc/profile.d/keychain.sh<br />
<br />
If you do not want to get asked for your passphrase every time you login but rather the first time you actually attempt to connect, you may add the following to your {{ic|.bashrc}}:<br />
alias ssh='eval $(/usr/bin/keychain --eval --agents ssh -Q --quiet .ssh/id_rsa) && ssh'<br />
This will ask you if you try to use ssh for the first time. Remember however that this will ONLY ask you if {{ic|.bashrc}} is applicable. So you would always have your first ssh-command to be executed in a terminal.<br />
<br />
===x11-ssh-askpass===<br />
The x11-ssh-askpass package provides a graphical dialog for entering your passhrase when running an X session. x11-ssh-askpass depends only the {{Pkg|libx11}} and {{Pkg|libxt}} libraries, and the appearance of x11-ssh-askpass is customizable. While it can be invoked by the {{ic|ssh-add}} program which will then load your decrypted keys into [[#ssh-agent|ssh-agent]], the following instructions will instead configure x11-ssh-askpass to be invoked by the aforementioned [[#Keychain|Keychain]] script.<br />
<br />
Install {{Pkg|keychain}} and {{Pkg|x11-ssh-askpass}}, both available in the [[Official Repositories]].<br />
<br />
Edit your {{ic|~/.xinitrc}} file to include the lines highlighted in bold, replacing the name and location of your private if necessary. Be sure to place these commands '''before''' the line which invokes your window mananger.<br />
<br />
{{hc|~/.xinitrc|<br />
'''keychain ~/.ssh/id_ecdsa'''<br />
'''[ -f ~/.keychain/$HOSTNAME-sh ] && . ~/.keychain/$HOSTNAME-sh 2>/dev/null'''<br />
'''[ -f ~/.keychain/$HOSTNAME-sh-gpg ] && . ~/.keychain/$HOSTNAME-sh-gpg 2>/dev/null'''<br />
...<br />
exec openbox-session}}<br />
<br />
In the above example, the first line invokes {{ic|keychain}} and passes the name and location of your private key. If this is not the first time keychain was invoked, the following two lines load the contents of {{ic|$HOSTNAME-sh}} and {{ic|$HOSTNAME-sh-gpg}} if they exist. These files store the environment variables of the previous instance of {{ic|keychain}}.<br />
<br />
====Theming====<br />
The appearance of the x11-ssh-askpass dialog can be customized by setting its associated [[X resources]]. The x11-ssh-askpass [http://www.jmknoble.net/software/x11-ssh-askpass/ homepage] presents some example [http://www.jmknoble.net/software/x11-ssh-askpass/screenshots.html example themes]. See the x11-ssh-askpass man page for full details.<br />
<br />
====Alternative passphrase dialogs====<br />
There are other passphrase dialog programs which can be used instead of x11-ssh-askpass. The following list provides some alternative solutions.<br />
<br />
* {{Pkg|ksshaskpass}} is available in the Official Repositories. It is dependent on {{Pkg|kdelibs}} and is suitable for the KDE Desktop Environment.<br />
<br />
* {{Pkg|openssh-askpass}} depends on the {{Pkg|qt}} libraries, and is available from the Official Repositories.<br />
<br />
===pam_ssh===<br />
The [http://pam-ssh.sourceforge.net/ pam_ssh] project exists to provide a [[Wikipedia:Pluggable authentication module|Pluggable Authentication Module]] (PAM) for SSH private keys. This module can provide single sign-on behavior for your SSH connections. On login, your SSH private key passphrase can be entered in place of, or in addition to, your traditional system password. Once you have been authenticated, the pam_ssh module spawns ssh-agent to store your decrypted private key for the duration of the session.<br />
<br />
To enable single sign-on behavior at the tty login prompt, install the unofficial {{AUR|pam_ssh}} package, available in the [[Arch User Repository]]. <br />
<br />
Edit the {{ic|/etc/pam.d/login}} configuration file to include the text highlighted in bold in the example below. The order in which these lines appear is significiant and can affect login behavior.<br />
<br />
{{Warning|Misconfiguring PAM can leave the system in a state where all users become locked out. Before making any changes, you should have an understanding of how PAM configuration works as well as a backup means of accessing the PAM configuration files, such as an Arch Live CD, in case you become locked out and need to revert any changes. An IBM developerWorks [http://www.ibm.com/developerworks/linux/library/l-pam/index.html article] is available which explains PAM configuration in further detail.}}<br />
<br />
{{hc|/etc/pam.d/login|2=<br />
#%PAM-1.0<br />
auth required pam_securetty.so<br />
auth requisite pam_nologin.so<br />
'''auth sufficient pam_ssh.so'''<br />
auth required pam_unix.so nullok '''use_first_pass'''<br />
auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
# use this to lockout accounts for 10 minutes after 3 failed attempts<br />
#auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
account required pam_access.so<br />
account required pam_time.so<br />
account required pam_unix.so<br />
#password required pam_cracklib.so difok=2 minlen=8 dcredit=2 ocredit=2 retry=3<br />
#password required pam_unix.so sha512 shadow use_authtok<br />
session required pam_unix.so<br />
session required pam_env.so<br />
session required pam_motd.so<br />
session required pam_limits.so<br />
session optional pam_mail.so dir=/var/spool/mail standard<br />
session optional pam_lastlog.so<br />
session optional pam_loginuid.so<br />
'''session optional pam_ssh.so'''<br />
-session optional pam_ck_connector.so nox11<br />
-session optional pam_systemd.so<br />
}}<br />
<br />
In the above example, login uses pam_ssh to check the entered password against the user's SSH private key passphrase. If the password matches, the user is immediately granted access to the system. If the password does not match, control falls to the pam_unix module which provides traditional password authentication. Because the {{ic|use_first_pass}} option is set, the pam_unix module checks the previously entered password against the {{ic|/etc/passwd}} file instead of asking for a password again. In this way, pam_ssh will be transparent to users without an SSH private key.<br />
<br />
If you use a another means of logging in, such as an X11 display manager like [[SLiM]] or [[XDM]] and you would like it to provide similar functionality, you must edit its associated PAM configuration file in a similar fashion. Packages providing support for PAM typically place a default configuration file in the {{ic|/etc/pam.d/}} directory.<br />
<br />
Further details on how to use pam_ssh and a list of its options can be found in the pam_ssh man page.<br />
<br />
====Known issues with pam_ssh====<br />
Work on the pam_ssh project is infrequent and the documentation provided is sparse. You should be aware of some of its limitations which are not mentioned in the package itself.<br />
<br />
* SSH keys employing the newer option of ECDSA (elliptic curve) cryptography do not appear to be supported by pam_ssh. You must use either RSA or DSA keys.<br />
<br />
* The {{ic|ssh-agent}} process spawned by pam_ssh does not persist between user logins. If you like to keep a [[GNU Screen]] session active between logins you may notice when reattaching to your screen session that it can no longer communicate with ssh-agent. This is because the GNU Screen environment and those of its children will still reference the instance of ssh-agent which existed when GNU Screen was invoked but was subsequently killed in a previous logout. The [[#keychain|Keychain]] front-end avoids this problem by keeping the ssh-agent process alive between logins.<br />
<br />
===GNOME Keyring===<br />
If you use the [[GNOME]] desktop, the [[GNOME Keyring]] tool can be used as an SSH agent. Visit the [[GNOME Keyring]] article.<br />
<br />
==Troubleshooting==<br />
If it appears that the SSH server is ignoring your keys, ensure that you have the proper permissions set on all relevant files.<br />
<br />
For the local machine:<br />
<br />
$ chmod 700 ~/<br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/id_ecdsa<br />
<br />
For the remote machine:<br />
<br />
$ chmod 700 ~/<br />
$ chmod 700 ~/.ssh<br />
$ chmod 600 ~/.ssh/authorized_keys<br />
<br />
Failing this, run the sshd in debug mode and monitor the output while connecting:<br />
<br />
# /usr/sbin/sshd -d<br />
<br />
=== Using kdm ===<br />
It appears that kdm doesn't launch the ssh-agent process directly. You need to install the {{Pkg|kde-agent}}.<br />
<br />
==See also==<br />
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc.html OpenSSH key management, Part 1]<br />
* [http://www-106.ibm.com/developerworks/linux/library/l-keyc2/ OpenSSH key management, Part 2]<br />
* [http://www-106.ibm.com/developerworks/library/l-keyc3/ OpenSSH key management, Part 3]<br />
* [http://kimmo.suominen.com/docs/ssh/ Getting started with SSH]<br />
* [http://openssh.org/txt/release-5.7 OpenSSH 5.7 Release Notes]</div>Leonardodaghttps://wiki.archlinux.org/index.php?title=Persistent_block_device_naming&diff=201305Persistent block device naming2012-05-13T19:51:16Z<p>Leonardodag: Just a small fix</p>
<hr />
<div>[[Category:Boot process]]<br />
[[Category:File systems]]<br />
[[Category:Hardware detection and troubleshooting]]<br />
{{i18n|Persistent block device naming}}<br />
{{Article summary start}}<br />
{{Article summary text|An overview of persistent block device naming; the preferred method of referencing block devices.}}<br />
{{Article summary heading|Related articles}}<br />
{{Article summary wiki|fstab}}<br />
{{Article summary wiki|udev}}<br />
{{Article summary wiki|LVM}}<br />
{{Article summary end}}<br />
<br />
This article describes how to use persistent names for your block devices. This has been made possible by the introduction of udev and has some advantages over bus-based naming. If your machine has more than one SATA, SCSI or IDE disk controller, the order in which their corresponding device nodes are added is random. This may result in device names like {{ic|/dev/'''sda'''}} and {{ic|/dev/'''sdb'''}} switching around randomly on each boot, culminating in an unbootable system, kernel panic, or a block device disappearing. Persistent naming solves these issues. '''Note''' that if you are using [[LVM|LVM2]], this article is not relevant as LVM takes care of this automatically.<br />
<br />
==Persistent naming methods==<br />
<br />
There are four different schemes for persistent naming: by-label, by-uuid, by-id and by-path. The following sections describes what the different persistent naming methods are and how they are used. <br />
<br />
Here is a good command for viewing all the information.<br />
<br />
{{hc|$ blkid -o list -c /dev/null|<nowiki><br />
device fs_type label mount point UUID<br />
------------------------------------------------------------------------------------------<br />
/dev/sda1 ext2 /boot 7f4cef7e-7ee2-489a-b759-d52ba23b692c<br />
/dev/sda2 swap (not mounted) a807fff3-e89f-46d0-ab17-9b7ad3efa7b5<br />
/dev/sda3 ext4 / 81917291-fd1a-4ffe-b95f-61c05cfba76f<br />
/dev/sda4 ext4 /home c4c23598-19fb-4562-892b-6fb18a09c7d3<br />
/dev/sdb1 ext4 X2 /mnt/X1 4bf265f7-da17-4575-8758-acd40885617b<br />
/dev/sdc1 ext4 X1 /mnt/X2 4bf265f7-da17-4575-8758-acd40885617b<br />
/dev/sdd1 ext4 Y2 /mnt/Y2 8a976a06-3e56-476f-b73a-ea3cad41d915<br />
/dev/sde1 ext4 Z2 /mnt/Z2 9d35eaae-983f-4eba-abc9-434ecd4da09c<br />
/dev/sdf1 ext4 Y1 /mnt/Y1 e2ec37a9-0689-46a8-a07b-0609ce2b7ea2<br />
/dev/sdg1 ext4 Z1 /mnt/Z1 9fa239c1-720f-42e0-8aed-39cf53a743ed<br />
/dev/sdj1 ext4 RAPT (not mounted) a9ed7ecb-96ce-40fe-92fa-e07a532ed157<br />
/dev/sdj2 swap <swap> 20826c74-eb6d-46f8-84d8-69b933a4bf3f<br />
</nowiki>}}<br />
<br />
<br />
===By-label===<br />
<br />
Almost every filesystem type can have a label. All your partitions that have one are listed in the {{ic|/dev/disk/by-label}} directory. This directory is created and destroyed dynamically, depending on whether you have partitions with labels attached.<br />
<br />
{{hc|$ ls -lF /dev/disk/by-label|<nowiki><br />
total 0<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 data -> ../../sdb2<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 data2 -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 fat -> ../../sda6<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 home -> ../../sda7<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 root -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 swap -> ../../sda5<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 windows -> ../../sdb1<br />
</nowiki>}}<br />
<br />
<br />
The labels of your filesystems can be changed, but note that they have to be unambiguous to prevent any possible conflicts. Following are some methods for changing labels on common filesystems:<br />
<br />
; swap :<br />
# mkswap -L <label> /dev/XXX<br />
{{Warning|This command will destroy your running swap.}} If your swap is mounted, run {{ic|swapoff /dev/XXX}} before and {{ic|swapon /dev/XXX}} after.<br />
; ext2/ext3/ext4 :<br />
# e2label /dev/XXX <label><br />
; btrfs :<br />
# btrfs filesystem label /dev/XXX <label><br />
; reiserfs :<br />
# reiserfstune -l <label> /dev/XXX<br />
; jfs :<br />
# jfs_tune -L <label> /dev/XXX<br />
; xfs :<br />
# xfs_admin -L <label> /dev/XXX<br />
; fat/vfat<br />
# dosfslabel /dev/XXX <label> # {{pkg|dosfstools}} package<br />
# mlabel -i /dev/XXX ::<label> # {{pkg|mtools}} package; converts label to uppercase<br />
; ntfs (ntfsprogs package) :<br />
# ntfslabel /dev/XXX <label><br />
{{Note|Labels can be up to 16 characters long.}}<br />
<br />
===By-uuid===<br />
<br />
[http://en.wikipedia.org/wiki/UUID UUID] is a mechanism to give each filesystem a unique identifier. It is designed so that collisions are unlikely. All GNU/Linux filesystems (including swap) support UUID. FAT and NTFS filesystems do not support UUID, but are still listed in {{ic|/dev/disk/by-uuid}} with a unique identifier:<br />
<br />
{{hc|$ ls -lF /dev/disk/by-uuid/|<nowiki><br />
total 0<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 2d781b26-0285-421a-b9d0-d4a0d3b55680 -> ../../sda1<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 31f8eb0d-612b-4805-835e-0e6d8b8c5591 -> ../../sda7<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 3FC2-3DDB -> ../../sda6<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 5090093f-e023-4a93-b2b6-8a9568dd23dc -> ../../sda2<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 912c7844-5430-4eea-b55c-e23f8959a8ee -> ../../sda5<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 B0DC1977DC193954 -> ../../sdb1<br />
lrwxrwxrwx 1 root root 10 Oct 16 10:27 bae98338-ec29-4beb-aacf-107e44599b2e -> ../../sdb2<br />
</nowiki>}}<br />
<br />
As you can see, the FAT and NTFS partitions (''fat'' and ''windows'' labels above) have shorter names, but are still listed. The advantage about using the UUID method is that it is less likely that you have name collisions than with labels. The disadvantage is that UUIDs lose any readability advantage.<br />
<br />
===By-id and by-path===<br />
<br />
by-id creates a unique name depending on the hardware serial number. by-path creates a unique name depending on the shortest physical path (according to sysfs). Both contain strings to indicate which subsystem they belong to (i.e. "-ide-", for 'by-path', and "ata-" for 'by-id') and thus are not suitable for solving the problems mentioned in the beginning of this article. They will not be discussed any further here.<br />
<br />
===Individual device names===<br />
You can also create individual device names: [[udev#Setting static device names (for iscsi)]].<br />
<br />
==Using persistent naming==<br />
<br />
There are various applications that can be configured using persistent naming. Following are some examples of how to configure them.<br />
<br />
===[[Fstab]]===<br />
<br />
To enable persistent naming in {{ic|/etc/fstab}} replace the device kernel name in the first column with the persistent name path as follows:<br />
<br />
/dev/disk/by-label/home ...<br />
/dev/disk/by-uuid/31f8eb0d-612b-4805-835e-0e6d8b8c5591 ...<br />
<br />
or directly specify the persistent name type using a prefix:<br />
<br />
LABEL=home ...<br />
UUID=1f8eb0d-612b-4805-835e-0e6d8b8c5591 ...<br />
<br />
===Boot managers===<br />
<br />
To use persistent names in your boot manager, the following prerequisites must be met:<br />
<br />
* You are using a [[Configuring mkinitcpio|mkinitcpio]] initial RAM disk image<br />
* You have udev enabled in {{ic|/etc/mkinitcpio.conf}}<br />
* When your initramfs image was generated, version '''101-3''' or greater of ''klibc-udev'' was installed ('''persistent naming is broken in any earlier version'''). If you are updating ''klibc-udev'' from an earlier version and want to use persistent naming, regenerate your initramfs image before you reboot.<br />
<br />
In the above example, {{ic|/dev/sda1}} is the root partition. In the [[GRUB]] {{ic|menu.lst}} file, the ''kernel'' line looks like this:<br />
<br />
kernel /boot/vmlinuz-linux root=/dev/sda1 ro quiet<br />
<br />
Depending on which naming scheme you would prefer, change it to one of the following:<br />
<br />
kernel /boot/vmlinuz-linux root=/dev/disk/by-label/root ro quiet<br />
<br />
or<br />
<br />
kernel /boot/vmlinuz-linux root=/dev/disk/by-uuid/2d781b26-0285-421a-b9d0-d4a0d3b55680 ro quiet<br />
<br />
If you are using [[LILO]], then do not try this with the {{ic|1=root=...}} configuration option; it will not work. Use {{ic|1=append="root=..."}} or {{ic|1=addappend="root=..."}} instead. Read the LILO man page for more information on ''append'' and ''addappend''.<br />
<br />
There is an alternative way to use the label embedded in the filesystem. For example if (as above) the filesystem in {{ic|/dev/sda1}} is labeled "root", you would give this line to GRUB:<br />
<br />
kernel /boot/vmlinuz-linux root=LABEL=root ro quiet</div>Leonardodag