https://wiki.archlinux.org/api.php?action=feedcontributions&user=Wooptoo&feedformat=atomArchWiki - User contributions [en]2024-03-29T02:12:32ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=757695Dm-crypt/Encrypting an entire system2022-11-20T21:32:05Z<p>Wooptoo: Minor changes to Configuring the boot loader</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data-at-rest encryption]]<br />
[[Category:Installation process]]<br />
[[de:Systemverschlüsselung mit dm-crypt]]<br />
[[es:Dm-crypt (Español)/Encrypting an entire system]]<br />
[[ja:Dm-crypt/システム全体の暗号化]]<br />
[[pl:Dm-crypt (Polski)/Encrypting an entire system]]<br />
[[pt:Dm-crypt (Português)/Encrypting an entire system]]<br />
The following are examples of common scenarios of full system encryption with ''dm-crypt''. They explain all the adaptations that need to be done to the normal [[Installation guide|installation procedure]]. All the necessary tools are on the [https://archlinux.org/download/ installation image].<br />
<br />
If you want to encrypt an existing unencrypted file system, see [[dm-crypt/Device encryption#Encrypt an existing unencrypted file system]].<br />
<br />
== Overview ==<br />
<br />
Securing a root filesystem is where ''dm-crypt'' excels, feature and performance-wise. Unlike selectively encrypting non-root filesystems, an encrypted root filesystem can conceal information such as which programs are installed, the usernames of all user accounts, and common data-leakage vectors such as [[mlocate]] and {{ic|/var/log/}}. Furthermore, an encrypted root filesystem makes tampering with the system far more difficult, as everything except the [[boot loader]] and (usually) the kernel is encrypted.<br />
<br />
All scenarios illustrated in the following share these advantages, other pros and cons differentiating them are summarized below:<br />
<br />
{| class="wikitable"<br />
! Scenarios<br />
! Advantages<br />
! Disadvantages<br />
|----------------------------------------------------------<br />
| [[#LUKS on a partition]]<br />
shows a basic and straightforward set-up for a fully LUKS encrypted root.<br />
|<br />
* Simple partitioning and setup<br />
* On a GPT partitioned disk, [[systemd#GPT partition automounting|systemd can auto-mount]] the root partition.<br />
|<br />
* Inflexible; disk-space to be encrypted has to be pre-allocated<br />
|----------------------------------------------------------<br />
| [[#LVM on LUKS]]<br />
achieves partitioning flexibility by using LVM inside a single LUKS encrypted partition.<br />
|<br />
* Simple partitioning with knowledge of LVM<br />
* Only one key required to unlock all volumes (e.g. easy resume-from-disk setup)<br />
* Volume layout not visible when locked<br />
* Easiest method to allow [[dm-crypt/Swap encryption#With suspend-to-disk support|suspension to disk]]<br />
|<br />
* LVM adds an additional mapping layer and hook<br />
* Less useful, if a singular volume should receive a separate key<br />
|----------------------------------------------------------<br />
| [[#LUKS on LVM]]<br />
uses dm-crypt only after the LVM is setup.<br />
|<br />
* LVM can be used to have encrypted volumes span multiple disks<br />
* Easy mix of un-/encrypted volume groups<br />
|<br />
* Complex; changing volumes requires changing encryption mappers too<br />
* Volumes require individual keys<br />
* LVM layout is visible when locked<br />
* Slower boot time; each encrypted LV must be unlocked seperately<br />
|----------------------------------------------------------<br />
| [[#LUKS on software RAID]]<br />
uses dm-crypt only after RAID is setup.<br />
|<br />
* Analogous to LUKS on LVM<br />
|<br />
* Analogous to LUKS on LVM<br />
|----------------------------------------------------------<br />
| [[#Plain dm-crypt]]<br />
uses dm-crypt plain mode, i.e. without a LUKS header and its options for multiple keys. <br>This scenario also employs USB devices for {{ic|/boot}} and key storage, which may be applied to the other scenarios.<br />
|<br />
* Data resilience for cases where a LUKS header may be damaged<br />
* Allows [[Wikipedia:Disk encryption#Full disk encryption|Full Disk Encryption]]<br />
* Helps addressing [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)|problems]] with SSDs<br />
|<br />
* High care to all encryption parameters is required<br />
* Single encryption key and no option to change it<br />
|----------------------------------------------------------<br />
| [[#Encrypted boot partition (GRUB)]]<br />
shows how to encrypt the boot partition using the GRUB bootloader. <br> This scenario also employs an EFI system partition, which may be applied to the other scenarios.<br />
|<br />
* Same advantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* Less data is left unencrypted, i.e. the boot loader and the EFI system partition, if present<br />
|<br />
* Same disadvantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* More complicated configuration<br />
* Not supported by other boot loaders<br />
|----------------------------------------------------------<br />
| [[#Btrfs subvolumes with swap]]<br />
shows how to encrypt a [[Btrfs]] system, including the {{ic|/boot}} directory, also adding a partition for swap, on UEFI hardware.<br />
|<br />
* Similar advantages as [[#Encrypted boot partition (GRUB)]]<br />
* Availability of Btrfs' features<br />
|<br />
* Similar disadvantages as [[#Encrypted boot partition (GRUB)]]<br />
|----------------------------------------------------------<br />
| [[#Root on ZFS]]<br />
|<br />
|<br />
|}<br />
<br />
While all above scenarios provide much greater protection from outside threats than encrypted secondary filesystems, they also share a common disadvantage: any user in possession of the encryption key is able to decrypt the entire drive, and therefore can access other users' data. If that is of concern, it is possible to use a combination of block device and stacked filesystem encryption and reap the advantages of both. See [[Data-at-rest encryption]] to plan ahead.<br />
<br />
See [[dm-crypt/Drive preparation#Partitioning]] for a general overview of the partitioning strategies used in the scenarios.<br />
<br />
Another area to consider is whether to set up an encrypted swap partition and what kind. See [[dm-crypt/Swap encryption]] for alternatives.<br />
<br />
If you anticipate to protect the system's data not only against physical theft, but also have a requirement of precautions against logical tampering, see [[dm-crypt/Specialties#Securing the unencrypted boot partition]] for further possibilities after following one of the scenarios.<br />
<br />
For [[solid state drive]]s you might want to consider enabling TRIM support, but be warned, there are potential security implications. See [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] for more information.<br />
<br />
{{Warning|<br />
* In any scenario, never use file system repair software such as [[fsck]] directly on an encrypted volume, or it will destroy any means to recover the key used to decrypt your files. Such tools must be used on the decrypted (opened) device instead.<br />
* For the LUKS2 format:<br />
** 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 />
** The LUKS2 format has a high RAM usage per design, defaulting to 1GB per encrypted mapper. Machines with low RAM and/or multiple LUKS2 partitions unlocked in parallel may error on boot. See the {{ic|--pbkdf-memory}} option to control memory usage.[https://gitlab.com/cryptsetup/cryptsetup/issues/372]<br />
}}<br />
<br />
== LUKS on a partition ==<br />
<br />
This example covers a full system encryption with ''dm-crypt'' + LUKS in a simple partition layout:<br />
<br />
{{Text art|<nowiki><br />
+-----------------------+------------------------+-----------------------+<br />
| Boot partition | LUKS2 encrypted system | Optional free space |<br />
| | partition | for additional |<br />
| | | partitions to be set |<br />
| /boot | / | up later |<br />
| | | |<br />
| | /dev/mapper/root | |<br />
| |------------------------| |<br />
| /dev/sda1 | /dev/sda2 | |<br />
+-----------------------+------------------------+-----------------------+<br />
</nowiki>}}<br />
<br />
The first steps can be performed directly after booting the Arch Linux install image.<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
Then create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda2}}) and {{ic|/boot}} ({{ic|/dev/sda1}}). See [[Partitioning]].<br />
<br />
=== Preparing non-boot partitions ===<br />
<br />
The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in [[dm-crypt/Encrypting a non-root file system#Partition]] (which, despite the title, ''can'' be applied to root partitions, as long as [[#Configuring mkinitcpio|mkinitcpio]] and the [[#Configuring the boot loader|boot loader]] are correctly configured).<br />
If you want to use particular non-default encryption options (e.g. cipher, key length), see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|encryption options]] before executing the first command. For information on changing the default sector size, see [[dm-crypt/Device encryption#Sector size]].<br />
<br />
# cryptsetup -y -v luksFormat /dev/sda2<br />
# cryptsetup open /dev/sda2 root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
Check the mapping works as intended:<br />
<br />
# umount /mnt<br />
# cryptsetup close root<br />
# cryptsetup open /dev/sda2 root<br />
# mount /dev/mapper/root /mnt<br />
<br />
If you created separate partitions (e.g. {{ic|/home}}), these steps have to be adapted and repeated for all of them, ''except'' for {{ic|/boot}}. See [[dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting]] on how to handle additional partitions at boot.<br />
<br />
Note that each block device requires its own passphrase. This may be inconvenient, because it results in a separate passphrase to be input during boot. An alternative is to use a keyfile stored in the system partition to unlock the separate partition via {{ic|crypttab}}. See [[dm-crypt/Device encryption#Using LUKS to format partitions with a keyfile]] for instructions.<br />
<br />
=== Preparing the boot partition ===<br />
<br />
What you do have to setup is a non-encrypted {{ic|/boot}} partition, which is needed for an encrypted root. For an ordinary boot partition on BIOS systems, for example, execute:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
or for an [[EFI system partition]] on UEFI systems:<br />
<br />
# mkfs.fat -F32 /dev/sda1<br />
<br />
Afterwards create the directory for the mountpoint and mount the partition:<br />
<br />
# mount --mkdir /dev/sda1 /mnt/boot<br />
<br />
=== Mounting the devices ===<br />
<br />
At [[Installation guide#Mount the file systems]] you will have to mount the mapped devices, not the actual partitions. Of course {{ic|/boot}}, which is not encrypted, will still have to be mounted directly.<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Add the {{ic|keyboard}}, {{ic|keymap}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]. If the default US keymap is fine for you, you can omit the {{ic|keymap}} hook.<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following [[kernel parameters]] need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':root root=/dev/mapper/root<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=root root=/dev/mapper/root<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of the LUKS superblock, in this case {{ic|/dev/sda2}}. See [[Persistent block device naming]] for details.<br />
<br />
{{ic|rd.luks.name}} is honored only in the initrd, while {{ic|luks.name}} is honored by both the main system and the initrd.<br />
<br />
Read the [https://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html systemd-cryptsetup-generator] manual page for more boot loader options relevant to Sd-encrypt.<br />
<br />
Also see [[dm-crypt/System configuration#Kernel parameters]] for more details.<br />
<br />
== LVM on LUKS ==<br />
<br />
The straightforward method is to set up [[LVM]] on top of the encrypted partition instead of the other way round. Technically the LVM is setup inside one big encrypted block device. Hence, the LVM is not visible until the block device is unlocked and the underlying volume structure is scanned and mounted during boot.<br />
<br />
The disk layout in this example is:<br />
<br />
{{Text art|<nowiki><br />
+-----------------------------------------------------------------------+ +----------------+<br />
| Logical volume 1 | Logical volume 2 | Logical volume 3 | | Boot partition |<br />
| | | | | |<br />
| [SWAP] | / | /home | | /boot |<br />
| | | | | |<br />
| /dev/MyVolGroup/swap | /dev/MyVolGroup/root | /dev/MyVolGroup/home | | |<br />
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on |<br />
| | | other device) |<br />
| LUKS2 encrypted partition | | |<br />
| /dev/sda1 | | /dev/sdb1 |<br />
+-----------------------------------------------------------------------+ +----------------+<br />
</nowiki>}}<br />
<br />
{{Note|While using the {{ic|encrypt}} hook this method does not allow you to span the logical volumes over multiple disks; either use the [[sd-encrypt]] or see [[dm-crypt/Specialties#Modifying the encrypt hook for multiple partitions]].}}<br />
<br />
{{Tip|Two variants of this setup:<br />
* Instructions at [[dm-crypt/Specialties#Encrypted system using a detached LUKS header]] use this setup with a detached LUKS header on a USB device to achieve a two factor authentication with it.<br />
* Instructions at [[dm-crypt/Specialties#Encrypted /boot and a detached LUKS header on USB]] use this setup with a detached LUKS header, encrypted {{ic|/boot}} partition, and encrypted keyfile all on a USB device.<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
{{Tip|When using the [[GRUB]] boot loader for BIOS booting from a [[GPT]] disk, create a [[BIOS boot partition]].}}<br />
<br />
[[Installation guide#Partition the disks|Create a partition]] to be mounted at {{ic|/boot}} with a size of 200 MiB or more.<br />
<br />
{{Tip|UEFI systems can use the [[EFI system partition]] for {{ic|/boot}}.}}<br />
<br />
Create a partition which will later contain the encrypted container.<br />
<br />
Create the LUKS encrypted container at the "system" partition. Enter the chosen password twice.<br />
<br />
# cryptsetup luksFormat /dev/sda1<br />
<br />
For more information about the available cryptsetup options see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|LUKS encryption options]] prior to above command.<br />
<br />
Open the container:<br />
<br />
# cryptsetup open /dev/sda1 cryptlvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/cryptlvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
Create a physical volume on top of the opened LUKS container:<br />
<br />
# pvcreate /dev/mapper/cryptlvm<br />
<br />
Create a volume group (in this example named {{ic|MyVolGroup}}, but it can be whatever you want) and add the previously created physical volume to it:<br />
<br />
# vgcreate MyVolGroup /dev/mapper/cryptlvm<br />
<br />
Create all your logical volumes on the volume group:<br />
<br />
{{Tip|If a logical volume will be formatted with [[ext4]], leave at least 256 MiB free space in the volume group to allow using {{man|8|e2scrub}}.}}<br />
<br />
# lvcreate -L 8G MyVolGroup -n swap<br />
# lvcreate -L 32G MyVolGroup -n root<br />
# lvcreate -l 100%FREE MyVolGroup -n home<br />
<br />
Format your filesystems on each logical volume:<br />
<br />
# mkfs.ext4 /dev/MyVolGroup/root<br />
# mkfs.ext4 /dev/MyVolGroup/home<br />
# mkswap /dev/MyVolGroup/swap<br />
<br />
Mount your filesystems:<br />
<br />
# mount /dev/MyVolGroup/root /mnt<br />
# mount --mkdir /dev/MyVolGroup/home /mnt/home<br />
# swapon /dev/MyVolGroup/swap<br />
<br />
=== Preparing the boot partition ===<br />
<br />
The bootloader loads the kernel, [[initramfs]], and its own configuration files from the {{ic|/boot}} directory. Any filesystem on a disk that can be read by the bootloader is eligible.<br />
<br />
Create a [[filesystem]] on the partition intended for {{ic|/boot}}:<br />
<br />
# mkfs.ext4 /dev/sdb1<br />
<br />
{{Tip|When opting to keep {{ic|/boot}} on an [[EFI system partition]] the recommended formatting is<br />
<br />
# mkfs.fat -F32 /dev/sdb1<br />
<br />
}}<br />
<br />
Mount the partition to {{ic|/mnt/boot}}:<br />
<br />
# mount --mkdir /dev/sdb1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following kernel parameter needs to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':cryptlvm root=/dev/MyVolGroup/root<br />
<br />
If using the [[sd-encrypt]] hook, the following needs to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=cryptlvm root=/dev/MyVolGroup/root<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of the LUKS superblock, in this case {{ic|/dev/sda1}}. See [[Persistent block device naming]] for details.<br />
<br />
{{ic|rd.luks.name}} is honored only in the initrd, while {{ic|luks.name}} is honored by both the main system and the initrd.<br />
<br />
Read the [https://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html systemd-cryptsetup-generator] manual page for more boot loader options relevant to Sd-encrypt.<br />
<br />
If using [[dracut]], you may need a more extensive list of parameters, try:<br />
<br />
kernel_cmdline="rd.luks.uuid=luks-''deviceUUID'' rd.lvm.lv=''MyVolGroup''/root rd.lvm.lv=''MyVolGroup''/swap root=/dev/mapper/''MyVolGroup''-root rootfstype=ext4 rootflags=rw,relatime"<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] for details.<br />
<br />
== LUKS on LVM ==<br />
<br />
To use encryption on top of [[LVM]], the LVM volumes are set up first and then used as the base for the encrypted partitions. This way, a mixture of encrypted and non-encrypted volumes/partitions is possible as well.<br />
{{tip|Unlike [[#LVM on LUKS]], this method allows normally spanning the logical volumes over multiple disks. }}<br />
<br />
The following short example creates a LUKS on LVM setup and mixes in the use of a key-file for the /home partition and temporary crypt volumes for {{ic|/tmp}} and {{ic|/swap}}. The latter is considered desirable from a security perspective, because no potentially sensitive temporary data survives the reboot, when the encryption is re-initialised. If you are experienced with LVM, you will be able to ignore/replace LVM and other specifics according to your plan.<br />
<br />
If you want to span a logical volume over multiple disks that have already been set up, or expand the logical volume for {{ic|/home}} (or any other volume), a procedure to do so is described in [[dm-crypt/Specialties#Expanding LVM on multiple disks]]. It is important to note that the LUKS encrypted container has to be resized as well.<br />
<br />
{{Expansion|The intro of this scenario needs some adjustment now that a comparison has been added to [[#Overview]]. A suggested structure is to make it similar to the [[#LUKS on a partition]] intro.}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Partitioning scheme:<br />
<br />
{{Text art|<nowiki><br />
+----------------+-------------------------------------------------------------------------------------------------+<br />
| Boot partition | dm-crypt plain encrypted volume | LUKS2 encrypted volume | LUKS2 encrypted volume |<br />
| | | | |<br />
| /boot | [SWAP] | / | /home |<br />
| | | | |<br />
| | /dev/mapper/swap | /dev/mapper/root | /dev/mapper/home |<br />
| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
| | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | /dev/MyVolGroup/cryptswap | /dev/MyVolGroup/cryptroot | /dev/MyVolGroup/crypthome |<br />
| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
| | |<br />
| /dev/sda1 | /dev/sda2 |<br />
+----------------+-------------------------------------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
Randomise {{ic|/dev/sda2}} according to [[dm-crypt/Drive preparation#dm-crypt wipe on an empty disk or partition]].<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
# pvcreate /dev/sda2<br />
# vgcreate MyVolGroup /dev/sda2<br />
# lvcreate -L 32G -n cryptroot MyVolGroup<br />
# lvcreate -L 500M -n cryptswap MyVolGroup<br />
# lvcreate -L 500M -n crypttmp MyVolGroup<br />
# lvcreate -l 100%FREE -n crypthome MyVolGroup<br />
<br />
# cryptsetup luksFormat /dev/MyVolGroup/cryptroot<br />
# cryptsetup open /dev/MyVolGroup/cryptroot root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
More information about the encryption options can be found in [[dm-crypt/Device encryption#Encryption options for LUKS mode]].<br />
Note that {{ic|/home}} will be encrypted in [[#Encrypting logical volume /home]].<br />
<br />
{{Tip|If you ever have to access the encrypted root from the Arch-ISO, the above {{ic|open}} action will allow you to after the [[LVM#Logical Volumes do not show up|LVM shows up]].}}<br />
<br />
=== Preparing the boot partition ===<br />
<br />
# dd if=/dev/zero of=/dev/sda1 bs=1M status=progress<br />
# mkfs.ext4 /dev/sda1<br />
# mount --mkdir /dev/sda1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|lvm2}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''lvm2''' '''encrypt''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following [[kernel parameters]] need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':root root=/dev/mapper/root<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=root root=/dev/mapper/root<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/MyVolGroup/cryptroot}}. See [[Persistent block device naming]] for details.<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] for details.<br />
<br />
=== Configuring fstab and crypttab ===<br />
<br />
Both [[crypttab]] and [[fstab]] entries are required to both unlock the device and mount the filesystems, respectively. The following lines will re-encrypt the temporary filesystems on each reboot:<br />
<br />
{{hc|/etc/crypttab|2=<br />
swap /dev/MyVolGroup/cryptswap /dev/urandom swap,cipher=aes-xts-plain64,size=256<br />
tmp /dev/MyVolGroup/crypttmp /dev/urandom tmp,cipher=aes-xts-plain64,size=256<br />
}}<br />
<br />
{{hc|/etc/fstab|<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/sda1 /boot ext4 defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
=== Encrypting logical volume /home ===<br />
<br />
Since this scenario uses LVM as the primary and dm-crypt as secondary mapper, each encrypted logical volume requires its own encryption. Yet, unlike the temporary filesystems configured with volatile encryption above, the logical volume for {{ic|/home}} should of course be persistent. The following assumes you have rebooted into the installed system, otherwise you have to adjust paths.<br />
To save on entering a second passphrase at boot, a [[dm-crypt/Device encryption#Keyfiles|keyfile]] is created:<br />
<br />
# mkdir -m 700 /etc/luks-keys<br />
# dd if=/dev/random of=/etc/luks-keys/home bs=1 count=256 status=progress<br />
<br />
The logical volume is encrypted with it:<br />
<br />
# cryptsetup luksFormat -v /dev/MyVolGroup/crypthome /etc/luks-keys/home<br />
# cryptsetup -d /etc/luks-keys/home open /dev/MyVolGroup/crypthome home<br />
# mkfs.ext4 /dev/mapper/home<br />
# mount /dev/mapper/home /home<br />
<br />
The encrypted mount is configured in both [[crypttab]] and [[fstab]]:<br />
<br />
{{hc|/etc/crypttab|<br />
home /dev/MyVolGroup/crypthome /etc/luks-keys/home<br />
}}<br />
<br />
{{hc|/etc/fstab|<br />
/dev/mapper/home /home ext4 defaults 0 2<br />
}}<br />
<br />
== LUKS on software RAID ==<br />
<br />
This example is based on a real-world setup for a workstation class laptop equipped with two SSDs of equal size, and an additional HDD for bulk storage. The end result is LUKS1 based full disk encryption (including {{ic|/boot}}) for all drives, with the SSDs in a [[RAID|RAID0]] array, and keyfiles used to unlock all encryption after [[GRUB]] is given a correct passphrase at boot.<br />
<br />
This setup utilizes a very simplistic partitioning scheme, with all the available RAID storage being mounted at {{ic|/}} (no separate {{ic|/boot}} partition), and the decrypted HDD being mounted at {{ic|/data}}.<br />
<br />
Please note that regular [[System backup|backups]] are very important in this setup. If either of the SSDs fail, the data contained in the RAID array will be practically impossible to recover. You may wish to select a different [[RAID#Standard RAID levels|RAID level]] if fault tolerance is important to you. <br />
<br />
The encryption is not deniable in this setup.<br />
<br />
For the sake of the instructions below, the following block devices are used:<br />
<br />
/dev/sda = first SSD<br />
/dev/sdb = second SSD<br />
/dev/sdc = HDD<br />
<br />
{{Text art|<nowiki><br />
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+<br />
| BIOS boot partition | EFI system partition | LUKS1 encrypted volume | | BIOS boot partition | EFI system partition | LUKS1 encrypted volume | | LUKS2 encrypted volume |<br />
| | | | | | | | | |<br />
| | /efi | / | | | /efi | / | | /data |<br />
| | | | | | | | | |<br />
| | | /dev/mapper/root | | | | /dev/mapper/root | | |<br />
| +---------------------------+---------------------------+ | +---------------------------+---------------------------+ | |<br />
| | RAID1 array (part 1 of 2) | RAID0 array (part 1 of 2) | | | RAID1 array (part 2 of 2) | RAID0 array (part 2 of 2) | | |<br />
| | | | | | | | | |<br />
| | /dev/md/ESP | /dev/md/root | | | /dev/md/ESP | /dev/md/root | | /dev/mapper/data |<br />
| +---------------------------+---------------------------+ | +---------------------------+---------------------------+ +---------------------------+<br />
| /dev/sda1 | /dev/sda2 | /dev/sda3 | | /dev/sdb1 | /dev/sdb2 | /dev/sdb3 | | /dev/sdc1 |<br />
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+<br />
</nowiki>}}<br />
<br />
Be sure to substitute them with the appropriate device designations for your setup, as they may be different.<br />
<br />
=== Preparing the disks ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
For [[GRUB#BIOS systems|BIOS systems]] with GPT, create a [[BIOS boot partition]] with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition.<br />
<br />
For [[GRUB#UEFI systems|UEFI systems]] create an [[EFI system partition]] with an appropriate size, it will later be mounted at {{ic|/efi}}.<br />
<br />
In the remaining space on the drive create a partition ({{ic|/dev/sda3}} in this example) for "Linux RAID". Choose partition type ID {{ic|fd}} for MBR or partition type GUID {{ic|A19D880F-05FC-4D3B-A006-743F0F84911E}} for GPT.<br />
<br />
Once partitions have been created on {{ic|/dev/sda}}, the following commands can be used to clone them to {{ic|/dev/sdb}}.<br />
<br />
# sfdisk -d /dev/sda > sda.dump<br />
# sfdisk /dev/sdb < sda.dump<br />
<br />
The HDD is prepared with a single Linux partition covering the whole drive at {{ic|/dev/sdc1}}.<br />
<br />
=== Building the RAID array ===<br />
<br />
Create the RAID array for the SSDs.<br />
<br />
{{Note|<br />
* All parts of an EFI system partition RAID array must be individually usable, that means that ESP can only placed in a RAID1 array.<br />
* The RAID superblock must be placed at the end of the EFI system partition using {{ic|1=--metadata=1.0}}, otherwise the firmware will not be able to access the partition.<br />
}}<br />
<br />
# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sda2 /dev/sdb2<br />
<br />
This example utilizes RAID0 for root, you may wish to substitute a different level based on your preferences or requirements.<br />
<br />
# mdadm --create --verbose --level=0 --metadata=1.2 --raid-devices=2 /dev/md/root /dev/sda3 /dev/sdb3<br />
<br />
=== Preparing the block devices ===<br />
<br />
As explained in [[dm-crypt/Drive preparation]], the devices are wiped with random data utilizing {{ic|/dev/zero}} and a crypt device with a random key. Alternatively, you could use {{ic|dd}} with {{ic|/dev/random}} or {{ic|/dev/urandom}}, though it will be much slower.<br />
<br />
# cryptsetup open --type plain /dev/md/root container --key-file /dev/random<br />
# dd if=/dev/zero of=/dev/mapper/container bs=1M status=progress<br />
# cryptsetup close container<br />
<br />
And repeat above for the HDD ({{ic|/dev/sdc1}} in this example).<br />
<br />
Set up encryption for {{ic|/dev/md/root}}:<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 />
# cryptsetup -y -v luksFormat --type luks1 /dev/md/root<br />
# cryptsetup open /dev/md/root root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
And repeat for the HDD:<br />
<br />
# cryptsetup -y -v luksFormat /dev/sdc1<br />
# cryptsetup open /dev/sdc1 data<br />
# mkfs.ext4 /dev/mapper/data<br />
# mount --mkdir /dev/mapper/data /mnt/data<br />
<br />
For UEFI systems, set up the EFI system partition:<br />
<br />
# mkfs.fat -F32 /dev/md/ESP<br />
# mount --mkdir /dev/md/ESP /mnt/efi<br />
<br />
=== Configuring GRUB ===<br />
<br />
Configure [[GRUB]] for the LUKS1 encrypted system by editing {{ic|/etc/default/grub}} with the following:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/md/root:root"<br />
GRUB_ENABLE_CRYPTODISK=y<br />
<br />
{{Merge|GRUB#Troubleshooting|GRUB troubleshooting issues belong in the [[GRUB]] page. It should be moved there and simply linked from this section.}}<br />
<br />
If you have a USB keyboard on a newer system either enable legacy USB support in firmware or add the following to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_TERMINAL_INPUT="usb_keyboard"<br />
GRUB_PRELOAD_MODULES="usb usb_keyboard ohci uhci ehci"<br />
<br />
Otherwise you may not be able to use your keyboard at the LUKS prompt.<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] and [[GRUB#Encrypted /boot]] for details.<br />
<br />
Complete the GRUB install to both SSDs (in reality, installing only to {{ic|/dev/sda}} will work).<br />
<br />
# grub-install --target=i386-pc /dev/sda<br />
# grub-install --target=i386-pc /dev/sdb<br />
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Creating the keyfiles ===<br />
<br />
The next steps save you from entering your passphrase twice when you boot the system (once so GRUB can unlock the LUKS1 device, and second time once the initramfs assumes control of the system). This is done by creating a [[dm-crypt/Device encryption#Keyfiles|keyfile]] for the encryption and adding it to the initramfs image to allow the encrypt hook to unlock the root device. See [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] for details.<br />
<br />
* Create the [[dm-crypt/Device encryption#Keyfiles|keyfile]] and add the key to {{ic|/dev/md/root}}.<br />
* Create another keyfile for the HDD ({{ic|/dev/sdc1}}) so it can also be unlocked at boot. For convenience, leave the passphrase created above in place as this can make recovery easier if you ever need it. Edit {{ic|/etc/crypttab}} to decrypt the HDD at boot. See [[Dm-crypt/System configuration#Unlocking with a keyfile]].<br />
<br />
=== Configuring the system ===<br />
<br />
Edit [[fstab]] to mount the root and data block devices and the ESP:<br />
<br />
/dev/mapper/root / ext4 rw,noatime 0 1<br />
/dev/mapper/data /data ext4 defaults 0 2<br />
/dev/md/ESP /efi vfat rw,relatime,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,tz=UTC,errors=remount-ro 0 2<br />
<br />
Save the RAID configuration:<br />
<br />
# mdadm --detail --scan >> /etc/mdadm.conf<br />
<br />
Edit [[mkinitcpio.conf]] to include your keyfile and add the proper hooks:<br />
<br />
FILES=(/crypto_keyfile.bin)<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''mdadm_udev''' '''encrypt''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details.<br />
<br />
== Plain dm-crypt ==<br />
<br />
Contrary to LUKS, dm-crypt ''plain'' mode does not require a header on the encrypted device: this scenario exploits this feature to set up a system on an unpartitioned, encrypted disk that will be indistinguishable from a disk filled with random data, which could allow [[Wikipedia:Deniable encryption|deniable encryption]]. See also [[wikipedia:Disk encryption#Full disk encryption]].<br />
<br />
Note that if full-disk encryption is not required, the methods using LUKS described in the sections above are better options for both system encryption and encrypted partitions. LUKS features like key management with multiple passphrases/key-files or re-encrypting a device in-place are unavailable with ''plain'' mode.<br />
<br />
''Plain'' dm-crypt encryption can be more resilient to damage than LUKS, because it does not rely on an encryption master-key which can be a single-point of failure if damaged. However, using ''plain'' mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also [[Data-at-rest encryption#Cryptographic metadata]]. Using ''plain'' mode could also be considered if concerned with the problems explained in [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]].<br />
<br />
{{Tip|If headerless encryption is your goal but you are unsure about the lack of key-derivation with ''plain'' mode, then two alternatives are:<br />
* [[dm-crypt/Specialties#Encrypted system using a detached LUKS header|dm-crypt LUKS mode with a detached header]] by using the ''cryptsetup'' {{ic|--header}} option. It cannot be used with the standard ''encrypt'' hook, but the hook may be modified.<br />
* [[tcplay]] which offers headerless encryption but with the PBKDF2 function.<br />
}}<br />
<br />
The scenario uses two USB sticks:<br />
<br />
* one for the boot device, which also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone;<br />
* another for the encryption key file, assuming it stored as raw bits so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also [[Wikipedia:Security through obscurity]], follow [[dm-crypt/Device encryption#Keyfiles]] to prepare the keyfile.<br />
<br />
The disk layout is:<br />
<br />
{{Text art|<nowiki><br />
+----------------------+----------------------+----------------------+ +----------------+ +----------------+<br />
| Logical volume 1 | Logical volume 2 | Logical volume 3 | | Boot device | | Encryption key |<br />
| | | | | | | file storage |<br />
| / | [SWAP] | /home | | /boot | | (unpartitioned |<br />
| | | | | | | in example) |<br />
| /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home | | /dev/sdb1 | | /dev/sdc |<br />
|----------------------+----------------------+----------------------| |----------------| |----------------|<br />
| disk drive /dev/sda encrypted using plain mode and LVM | | USB stick 1 | | USB stick 2 |<br />
+--------------------------------------------------------------------+ +----------------+ +----------------+<br />
</nowiki>}}<br />
<br />
{{Tip|<br />
* It is also possible to use a single USB key physical device:<br />
** By putting the key on another partition (/dev/sdb2) of the USB storage device (/dev/sdb).<br />
** By copying the keyfile to the initramfs directly. An example keyfile {{ic|/etc/keyfile}} gets copied to the initramfs image by setting {{ic|1=FILES=(/etc/keyfile)}} in {{ic|/etc/mkinitcpio.conf}}. The way to instruct the {{ic|encrypt}} hook to read the keyfile in the initramfs image is using {{ic|rootfs:}} prefix before the filename, e.g. {{ic|1=cryptkey=rootfs:/etc/keyfile}}.<br />
* Another option is using a passphrase with good [[Security#Choosing secure passwords|entropy]].<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
It is vital that the mapped device is filled with random data. In particular this applies to the scenario use case we apply here.<br />
<br />
See [[dm-crypt/Drive preparation]] and [[dm-crypt/Drive preparation#dm-crypt specific methods]]<br />
<br />
=== Preparing the non-boot partitions ===<br />
<br />
See [[dm-crypt/Device encryption#Encryption options for plain mode]] for details.<br />
<br />
Using the device {{ic|/dev/sda}}, with the aes-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario:<br />
<br />
# cryptsetup --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sdc --key-size=512 open --type plain /dev/sda cryptlvm<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, and key file details.<br />
<br />
We can now check a mapping entry has been made for {{ic|/dev/mapper/cryptlvm}}:<br />
<br />
# fdisk -l<br />
<br />
{{Tip|A simpler alternative to using LVM, advocated in the cryptsetup FAQ for cases where LVM is not necessary, is to just create a filesystem on the entirety of the mapped dm-crypt device.}} <br />
<br />
Next, we setup [[LVM]] logical volumes on the mapped device. See [[Install Arch Linux on LVM]] for further details:<br />
<br />
# pvcreate /dev/mapper/cryptlvm<br />
# vgcreate MyVolGroup /dev/mapper/cryptlvm<br />
# lvcreate -L 32G MyVolGroup -n root<br />
# lvcreate -L 10G MyVolGroup -n swap<br />
# lvcreate -l 100%FREE MyVolGroup -n home<br />
<br />
We format and mount them and activate swap. See [[File systems#Create a file system]] for further details:<br />
<br />
# mkfs.ext4 /dev/MyVolGroup/root<br />
# mkfs.ext4 /dev/MyVolGroup/home<br />
# mount /dev/MyVolGroup/root /mnt<br />
# mount --mkdir /dev/MyVolGroup/home /mnt/home<br />
# mkswap /dev/MyVolGroup/swap<br />
# swapon /dev/MyVolGroup/swap<br />
<br />
=== Preparing the boot partition ===<br />
<br />
The {{ic|/boot}} partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200 MiB partition is all that is required. Create the partition using a [[Partitioning#Partitioning tools|partitioning tool]] of your choice.<br />
<br />
Create a [[filesystem]] on the partition intended for {{ic|/boot}}:<br />
<br />
# mkfs.fat -F32 /dev/sdb1<br />
# mount --mkdir /dev/sdb1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to boot the encrypted root partition, the following [[kernel parameters]] need to be set by the boot loader (note that 64 is the number of bytes in 512 bits):<br />
<br />
cryptdevice=/dev/disk/by-id/''disk-ID-of-sda'':cryptlvm cryptkey=/dev/disk/by-id/''disk-ID-of-sdc'':0:64 crypto=:aes-xts-plain64:512:0:<br />
<br />
The {{ic|''disk-ID-of-'''disk'''''}} refers to the id of the referenced disk. See [[Persistent block device naming]] for details.<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] for details and other parameters that you may need.<br />
<br />
{{Tip|If using GRUB, you can install it on the same USB as the {{ic|/boot}} partition with:<br />
<br />
# grub-install --recheck /dev/sdb<br />
<br />
}}<br />
<br />
=== Post-installation ===<br />
<br />
You may wish to remove the USB sticks after booting. Since the {{ic|/boot}} partition is not usually needed, the {{ic|noauto}} option can be added to the relevant line in {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|<br />
# /dev/sdb1<br />
/dev/sdb1 /boot vfat '''noauto''',rw,noatime 0 2<br />
}}<br />
<br />
However, when an update to anything used in the initramfs, or a kernel, or the bootloader is required; the {{ic|/boot}} partition must be present and mounted. As the entry in {{ic|fstab}} already exists, it can be mounted simply with:<br />
<br />
# mount /boot<br />
<br />
== Encrypted boot partition (GRUB) ==<br />
<br />
This setup utilizes the same partition layout and configuration as the previous [[#LVM on LUKS]] section, with the difference that the [[GRUB]] boot loader is used since it is capable of booting from an LVM logical volume and a LUKS1-encrypted {{ic|/boot}}. See also [[GRUB#Encrypted /boot]].<br />
<br />
The disk layout in this example is:<br />
<br />
{{Text art|<nowiki><br />
+---------------------+----------------------+----------------------+----------------------+----------------------+<br />
| BIOS boot partition | EFI system partition | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | | | | |<br />
| | /efi | / | [SWAP] | /home |<br />
| | | | | |<br />
| | | /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home |<br />
| /dev/sda1 | /dev/sda2 |----------------------+----------------------+----------------------+<br />
| unencrypted | unencrypted | /dev/sda3 encrypted using LVM on LUKS1 |<br />
+---------------------+----------------------+--------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
{{Tip|<br />
* All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in [[#LVM on LUKS]].<br />
* You can use {{ic|cryptboot}} script from {{AUR|cryptboot}} package for simplified encrypted boot management (mounting, unmounting, upgrading packages) and as a defense against [https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html Evil Maid] attacks with [[Secure Boot#Using your own keys|UEFI Secure Boot]]. For more information and limitations see [https://github.com/kmille/cryptboot cryptboot project] page.<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
For [[GRUB#GUID Partition Table (GPT) specific instructions|BIOS/GPT systems]] create a [[BIOS boot partition]] with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition. For BIOS/MBR systems this is not necessary.<br />
<br />
For [[GRUB#UEFI systems|UEFI systems]] create an [[EFI system partition]] with an appropriate size, it will later be mounted at {{ic|/efi}}.<br />
<br />
Create a partition of type {{ic|8309}}, which will later contain the encrypted container for the LVM.<br />
<br />
Create the LUKS encrypted container:<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 />
# cryptsetup luksFormat --type luks1 /dev/sda3<br />
<br />
For more information about the available cryptsetup options see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|LUKS encryption options]] prior to above command.<br />
<br />
Your partition layout should look similar to this:<br />
<br />
{{hc|# gdisk -l /dev/sda|<br />
...<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 4095 1024.0 KiB EF02 BIOS boot partition<br />
2 4096 1130495 550.0 MiB EF00 EFI System<br />
3 1130496 68239360 32.0 GiB 8309 Linux LUKS<br />
}}<br />
<br />
Open the container:<br />
<br />
# cryptsetup open /dev/sda3 cryptlvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/cryptlvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
The LVM logical volumes of this example follow the exact layout as the [[#LVM on LUKS]] scenario. Therefore, please follow [[#Preparing the logical volumes]] above and adjust as required.<br />
<br />
If you plan to boot in UEFI mode, create a mountpoint for the [[EFI system partition]] at {{ic|/efi}} for compatibility with {{ic|grub-install}} and mount it:<br />
<br />
# mount --mkdir /dev/sda2 /mnt/efi<br />
<br />
At this point, you should have the following partitions and logical volumes inside of {{ic|/mnt}}:<br />
<br />
{{hc|$ lsblk|<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 200G 0 disk<br />
├─sda1 8:1 0 1M 0 part<br />
├─sda2 8:2 0 550M 0 part /mnt/efi<br />
└─sda3 8:3 0 100G 0 part<br />
└─cryptlvm 254:0 0 100G 0 crypt<br />
├─MyVolGroup-swap 254:1 0 8G 0 lvm [SWAP]<br />
├─MyVolGroup-root 254:2 0 32G 0 lvm /mnt<br />
└─MyVolGroup-home 254:3 0 60G 0 lvm /mnt/home<br />
}}<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring GRUB ===<br />
<br />
Configure GRUB to allow booting from {{ic|/boot}} on a LUKS1 encrypted partition:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_ENABLE_CRYPTODISK=y<br />
}}<br />
<br />
Set the kernel parameters, so that the initramfs can unlock the encrypted root partition. Using the {{ic|encrypt}} hook:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="... cryptdevice=UUID=''device-UUID'':cryptlvm ..."<br />
}}<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="... rd.luks.name=''device-UUID''=cryptlvm ..."<br />
}}<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] and [[GRUB#Encrypted /boot]] for details. The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/sda3}} (the partition which holds the lvm containing the root filesystem). See [[Persistent block device naming]].<br />
<br />
[[GRUB#Installation_2|install GRUB]] to the mounted ESP for UEFI booting:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB --recheck<br />
<br />
[[GRUB#Installation|install GRUB]] to the disk for BIOS booting:<br />
<br />
# grub-install --target=i386-pc --recheck /dev/sda<br />
<br />
Generate GRUB's [[GRUB#Generate the main configuration file|configuration]] file:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
If all commands finished without errors, GRUB should prompt for the passphrase to unlock the {{ic|/dev/sda3}} partition after the next reboot.<br />
<br />
=== Avoiding having to enter the passphrase twice ===<br />
<br />
{{Merge|Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|Too much duplicated content, too much detail here for this overview page.|section=Security Issue with Grub Keyfile}}<br />
<br />
While GRUB asks for a passphrase to unlock the LUKS1 encrypted partition after above instructions, the partition unlock is not passed on to the initramfs. Hence, you have to enter the passphrase twice at boot: once for GRUB and once for the initramfs.<br />
<br />
This section deals with extra configuration to let the system boot by only entering the passphrase once, in GRUB. This is accomplished by [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs|with a keyfile embedded in the initramfs]].<br />
<br />
First create a keyfile and add it as LUKS key:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/root/cryptlvm.keyfile iflag=fullblock<br />
# chmod 000 /root/cryptlvm.keyfile<br />
# cryptsetup -v luksAddKey /dev/sda3 /root/cryptlvm.keyfile<br />
<br />
Add the keyfile to the initramfs image:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
FILES=(/root/cryptlvm.keyfile)<br />
}}<br />
<br />
Recreate the initramfs image and secure the embedded keyfile:<br />
<br />
# chmod 600 /boot/initramfs-linux*<br />
<br />
Set the following kernel parameters to unlock the LUKS partition with the keyfile. Using the {{ic|encrypt}} hook:<br />
<br />
GRUB_CMDLINE_LINUX="... cryptkey=rootfs:/root/cryptlvm.keyfile"<br />
<br />
Or, using the [[sd-encrypt]] hook:<br />
<br />
GRUB_CMDLINE_LINUX="... rd.luks.key=''device-UUID''=/root/cryptlvm.keyfile"<br />
<br />
If for some reason the keyfile fails to unlock the boot partition, systemd will fallback to ask for a passphrase to unlock and, in case that is correct, continue booting.<br />
<br />
{{Tip|If you want to encrypt the {{ic|/boot}} partition to protect against offline tampering threats, the [[dm-crypt/Specialties#mkinitcpio-chkcryptoboot|mkinitcpio-chkcryptoboot]] hook has been contributed to help.}}<br />
<br />
== Btrfs subvolumes with swap ==<br />
<br />
{{Out of date|Btrfs [[Btrfs#Swap_file|supports swapfile]] since 5.0|Talk:Dm-crypt/Encrypting_an_entire_system#Complete_guide_of_Btrfs_on_LUKS_full_disk_encryption}}<br />
The following example creates a full system encryption with LUKS1 using [[Btrfs]] subvolumes to [[Btrfs#Mounting subvolumes|simulate partitions]].<br />
<br />
If using UEFI, an [[EFI system partition]] (ESP) is required. {{ic|/boot}} itself may reside on {{ic|/}} and be encrypted; however, the ESP itself cannot be encrypted. In this example layout, the ESP is {{ic|/dev/sda1}} and is mounted at {{ic|/efi}}. {{ic|/boot}} itself is located on the system partition, {{ic|/dev/sda2}}.<br />
<br />
Since {{ic|/boot}} resides on the LUKS1 encrypted {{ic|/}}, [[GRUB]] must be used as the bootloader because only GRUB can load modules necessary to decrypt {{ic|/boot}} (e.g., crypto.mod, cryptodisk.mod and luks.mod).<br />
<br />
Additionally an optional plain-encrypted [[swap]] partition is shown.<br />
<br />
{{Text art|<nowiki><br />
+----------------------+----------------------+----------------------+<br />
| EFI system partition | System partition | Swap partition |<br />
| unencrypted | LUKS1-encrypted | plain-encrypted |<br />
| | | |<br />
| /efi | / | [SWAP] |<br />
| /dev/sda1 | /dev/sda2 | /dev/sda3 |<br />
+----------------------+----------------------+----------------------+<br />
</nowiki>}}<br />
<br />
=== Preparing the disk ===<br />
<br />
{{Note|It is not possible to use btrfs partitioning as described in [[Btrfs#Partitionless Btrfs disk]] when using LUKS. Traditional partitioning must be used, even if it is just to create one partition.}}<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]]. If you are using [[UEFI]] create an [[EFI system partition]] with an appropriate size. It will later be mounted at {{ic|/efi}}. If you are going to create an encrypted swap partition, create the partition for it, but do '''not''' mark it as swap, since plain ''dm-crypt'' will be used with the partition.<br />
<br />
Create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda2}}). See the [[Partitioning]] article.<br />
<br />
=== Preparing the system partition ===<br />
<br />
==== Create LUKS container ====<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 />
Follow [[dm-crypt/Device encryption#Encrypting devices with LUKS mode]] to setup {{ic|/dev/sda2}} for LUKS. See the [[dm-crypt/Device encryption#Encryption options for LUKS mode]] before doing so for a list of encryption options.<br />
<br />
==== Unlock LUKS container ====<br />
<br />
Now follow [[dm-crypt/Device encryption#Unlocking/Mapping LUKS partitions with the device mapper]] to unlock the LUKS container and map it.<br />
<br />
==== Format mapped device ====<br />
<br />
Proceed to format the mapped device as described in [[Btrfs#File system on a single device]], where {{ic|''/dev/partition''}} is the name of the mapped device (i.e., {{ic|/dev/mapper/''root''}}) and '''not''' {{ic|/dev/sda2}}.<br />
<br />
==== Mount mapped device ====<br />
<br />
Finally, [[mount]] the now-formatted mapped device (i.e., {{ic|/dev/mapper/root}}) to {{ic|/mnt}}.<br />
<br />
=== Creating btrfs subvolumes ===<br />
<br />
{{Merge|Btrfs|The subvolume layout is not specific to an encrypted system.}}<br />
<br />
==== Layout ====<br />
<br />
[[Btrfs#Subvolumes|Subvolumes]] will be used to simulate partitions, but other (nested) subvolumes will also be created. Here is a partial representation of what the following example will generate:<br />
<br />
{{Text art|<nowiki><br />
subvolid=5<br />
|<br />
├── @ -|<br />
| contained directories:<br />
| ├── /usr<br />
| ├── /bin<br />
| ├── /.snapshots<br />
| ├── ...<br />
|<br />
├── @home<br />
├── @snapshots<br />
├── @var_log<br />
└── @...<br />
</nowiki>}}<br />
<br />
This section follows the [[Snapper#Suggested filesystem layout]], which is most useful when used with [[Snapper]]. You should also consult [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout Btrfs Wiki SysadminGuide#Layout].<br />
<br />
==== Create subvolumes for initial mount ====<br />
<br />
Here we are using the convention of prefixing {{ic|@}} to subvolume names that will be used as mount points, and {{ic|@}} will be the subvolume that is mounted as {{ic|/}}.<br />
<br />
Following the [[Btrfs#Creating a subvolume]] article, create subvolumes at {{ic|/mnt/@}}, {{ic|/mnt/@snapshots}}, and {{ic|/mnt/@home}}.<br />
<br />
Create any additional subvolumes you wish to use as mount points now.<br />
<br />
==== Create subvolumes for excludes ====<br />
<br />
Create any subvolumes you do '''not''' want to have snapshots of when taking a snapshot of {{ic|/}}. For example, you probably do not want to take snapshots of {{ic|/var/cache/pacman/pkg}}. These subvolumes will be nested under the {{ic|@}} subvolume, but just as easily could have been created earlier at the same level as {{ic|@}} according to your preference.<br />
<br />
Since the {{ic|@}} subvolume is mounted at {{ic|/mnt}} you will need to [[create a subvolume]] at {{ic|/mnt/var/cache/pacman/pkg}} for this example. You may have to create any parent directories first.<br />
<br />
Other directories you may wish to do this with are {{ic|/var/abs}}, {{ic|/var/tmp}}, and {{ic|/srv}}.<br />
<br />
==== Mount top-level subvolumes ====<br />
<br />
Unmount the system partition at {{ic|/mnt}}.<br />
<br />
Now mount the newly created {{ic|@}} subvolume which will serve as {{ic|/}} to {{ic|/mnt}} using the {{ic|1=subvol=}} mount option. Assuming the mapped device is named {{ic|root}}, the command would look like:<br />
<br />
# mount -o compress=zstd,subvol=@ /dev/mapper/root /mnt<br />
<br />
See [[Btrfs#Mounting subvolumes]] for more details.<br />
<br />
Also mount the other subvolumes to their respective mount points: {{ic|@home}} to {{ic|/mnt/home}} and {{ic|@snapshots}} to {{ic|/mnt/.snapshots}}.<br />
<br />
==== Mount ESP ====<br />
<br />
If you prepared an EFI system partition earlier, create its mount point and mount it now.<br />
<br />
{{Note|Btrfs snapshots will exclude {{ic|/efi}}, since it is not a btrfs file system.}}<br />
<br />
At the [[Installation guide#Install essential packages|pacstrap]] installation step, the {{Pkg|btrfs-progs}} must be installed in addition to the {{Pkg|base}} [[meta package]].<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
==== Create keyfile ====<br />
<br />
In order for GRUB to open the LUKS partition without having the user enter their passphrase twice, we will use a keyfile embedded in the initramfs. Follow [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] making sure to add the key to {{ic|/dev/sda2}} at the ''luksAddKey'' step.<br />
<br />
==== Edit mkinitcpio.conf ====<br />
<br />
After creating, adding, and embedding the key as described above, add the {{ic|encrypt}} hook to [[mkinitcpio.conf]] as well as any other hooks you require.<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
{{Tip|You may want to add {{ic|1=BINARIES=(btrfs)}} to your {{ic|/etc/mkinitcpio.conf}}. See the [[Btrfs#Corruption recovery]] article.}}<br />
<br />
=== Configuring the boot loader ===<br />
<br />
Install [[GRUB]] to {{ic|/dev/sda}}. Then, edit {{ic|/etc/default/grub}} as instructed in the [[GRUB#Additional arguments]], [[GRUB#Encrypted /boot]] and [[dm-crypt/System configuration#Using encrypt hook]], following both the instructions for an encrypted root and boot partition. Finally, generate the GRUB configuration file. Note that you will need to pass kernel parameters for the root mount point as instructed in [[Btrfs#Mounting subvolume as root]].<br />
<br />
=== Configuring swap ===<br />
<br />
If you created a partition to be used for encrypted swap, now is the time to configure it. Follow the instructions at [[dm-crypt/Swap encryption]].<br />
<br />
== Root on ZFS ==<br />
<br />
Root on [[ZFS]] can be configured to encrypt everything except boot loader. See [https://openzfs.github.io/openzfs-docs/Getting%20Started/Arch%20Linux/Arch%20Linux%20Root%20on%20ZFS.html installation guide] on OpenZFS page.<br />
<br />
Boot loader can be verified with [[Secure Boot]] on UEFI-based systems.<br />
<br />
See also [[ZFS#Encryption in ZFS using dm-crypt]].<br />
<br />
== Simple encrypted root with TPM2 and Secure Boot ==<br />
<br />
This example covers a full system encryption with ''dm-crypt'' + LUKS, TPM2 and [[Secure Boot]] :<br />
Only the ESP remains unencrypted, with a [[Unified kernel image]] and [[Systemd-boot]] residing on it, both of which can be signed for use with [[Secure Boot]], providing a reasonably safe boot chain.<br />
<br />
Be aware though that as long as the system is [[Trusted Platform Module#Accessing PCR registers|not tempered with]], the root partition will automatically be decrypted upon boot, without a password prompt.<br />
<br />
In this example, partitions are created respecting [[Systemd#GPT partition automounting]], there is no need for an fstab or crypttab file.<br />
<br />
{{Text art|<nowiki><br />
+-----------------------+------------------------+-----------------------+<br />
| ESP | System partition |<br />
| unencrypted | encrypted |<br />
| | |<br />
| /efi | / |<br />
| | |<br />
| | /dev/mapper/root |<br />
| |------------------------------------------------|<br />
| /dev/sda1 | /dev/sda2 |<br />
+-----------------------+------------------------+-----------------------+<br />
</nowiki>}}<br />
<br />
Follow the [[Installation guide]] up to step [[Installation guide#Partition the disks|1.9 Partition the disks]]<br />
<br />
=== Partition the disks ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
Additionally, check that your disk reports the correct [[Advanced Format|sector size]].<br />
<br />
Make sure to create a [[GPT]] partition table. Then create the needed partitions for {{ic|/}} (e.g. {{ic|/dev/sda2}}) and {{ic|/efi}} ({{ic|/dev/sda1}}). See [[Partitioning]].<br />
<br />
* See [[EFI system partition#GPT partitioned disks]] to create the ESP with the appropriate partition GUID.<br />
* For the Luks (root) partition, you can use [[gdisk]] with partition type {{ic|8304}}, or [[fdisk]] with partition type {{ic|23 Linux root (x86-64)}} (if your architecture is x86-64). See [[GPT fdisk#Partition type]].<br />
<br />
=== Format the partitions ===<br />
==== Root partition ====<br />
<br />
The following commands create and mount the encrypted root partition, and make use of the TPM to store the encryption key. See [[dm-crypt/Encrypting a non-root file system#Partition]] (which, despite the title, ''can'' be applied to root partitions, as long as [[#Configuring mkinitcpio|mkinitcpio]] and the [[#Configuring the boot loader|boot loader]] are correctly configured), and [[Trusted Platform Module#systemd-cryptenroll]].<br />
<br />
If you want to use particular non-default encryption options (e.g. cipher, key length), or if you don't want to use TPM based decryption, see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|encryption options]] before executing the first command.<br />
<br />
We will create a luks volume with a key bound to the TPM [[Trusted Platform Module#Accessing PCR registers|PCR 7]] (default, [[Secure Boot]] state) and a recovery key to be used in case of any problem. The TPM will automatically release the key as long as the boot chain is not tempered with. See {{man|1|systemd-cryptenroll}}.<br />
<br />
Create the luks volume (you can simply use a blank password, as it will be wiped in the next step)<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
# systemd-cryptenroll /dev/sda2 --recovery-key<br />
# systemd-cryptenroll /dev/sda2 --wipe-slot=empty --tpm2-device=auto<br />
# cryptsetup open /dev/sda2 root<br />
# mkfs.ext4 /dev/mapper/root<br />
<br />
==== ESP ====<br />
<br />
See [[EFI system partition#Format the partition]].<br />
<br />
=== Mount the file systems ===<br />
<br />
At [[Installation guide#Mount the file systems]] you will have to mount the mapped device, not the actual partitions, i.e.<br />
<br />
# mount /dev/mapper/root /mnt<br />
# mount --mkdir /dev/sda1 /mnt/efi<br />
<br />
Continue the installation process until [[Installation guide#Initramfs]]. You can skip [[Installation guide#Fstab]].<br />
<br />
=== Initramfs ===<br />
<br />
To build a working systemd based initramfs, modify the {{ic|1=HOOKS=}} line in [[mkinitcpio.conf]] as follows:<br />
<br />
HOOKS=('''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' filesystems fsck)<br />
<br />
(if the default US keymap is fine for you, you can omit the {{ic|keymap}} hook)<br />
<br />
Next, see [[Unified kernel image#mkinitpcio]] to configure mkinitcpio for [[Unified kernel image]]s.<br />
<br />
Do not [[regenerate the initramfs]] yet, as the EFI path {{ic|/efi/EFI/Linux/}} needs to be created by the boot loader installer first.<br />
<br />
=== Boot loader ===<br />
<br />
Install [[systemd-boot]] with<br />
<br />
# bootctl install<br />
<br />
The [[Unified kernel image]] generated by mkinitcpio will be automatically recognized and does not need an entry in {{ic|/efi/loader/entries}}<br />
<br />
See [[Systemd-boot#Updating the EFI boot manager]] and [[Systemd-boot#Loader configuration]] for further configuration.<br />
<br />
=== Finalizing the installation ===<br />
<br />
First, [[Regenerate the initramfs]], and make sure the image generation is successful.<br />
<br />
Make sure you did not forget to [[Installation guide#Root password|set a root password]], reboot to [[Installation guide#Reboot|reboot]] to finish the installation.<br />
<br />
=== Secure Boot ===<br />
<br />
You can now sign the boot loader executables and the EFI binary, in order to enable [[Secure Boot]]. For a quick and easy way, see [[Unified Extensible Firmware Interface/Secure Boot#sbctl]]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=757692Dm-crypt/Encrypting an entire system2022-11-20T21:28:49Z<p>Wooptoo: Added man page for sd-encrypt hook for LVM on LUKS</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data-at-rest encryption]]<br />
[[Category:Installation process]]<br />
[[de:Systemverschlüsselung mit dm-crypt]]<br />
[[es:Dm-crypt (Español)/Encrypting an entire system]]<br />
[[ja:Dm-crypt/システム全体の暗号化]]<br />
[[pl:Dm-crypt (Polski)/Encrypting an entire system]]<br />
[[pt:Dm-crypt (Português)/Encrypting an entire system]]<br />
The following are examples of common scenarios of full system encryption with ''dm-crypt''. They explain all the adaptations that need to be done to the normal [[Installation guide|installation procedure]]. All the necessary tools are on the [https://archlinux.org/download/ installation image].<br />
<br />
If you want to encrypt an existing unencrypted file system, see [[dm-crypt/Device encryption#Encrypt an existing unencrypted file system]].<br />
<br />
== Overview ==<br />
<br />
Securing a root filesystem is where ''dm-crypt'' excels, feature and performance-wise. Unlike selectively encrypting non-root filesystems, an encrypted root filesystem can conceal information such as which programs are installed, the usernames of all user accounts, and common data-leakage vectors such as [[mlocate]] and {{ic|/var/log/}}. Furthermore, an encrypted root filesystem makes tampering with the system far more difficult, as everything except the [[boot loader]] and (usually) the kernel is encrypted.<br />
<br />
All scenarios illustrated in the following share these advantages, other pros and cons differentiating them are summarized below:<br />
<br />
{| class="wikitable"<br />
! Scenarios<br />
! Advantages<br />
! Disadvantages<br />
|----------------------------------------------------------<br />
| [[#LUKS on a partition]]<br />
shows a basic and straightforward set-up for a fully LUKS encrypted root.<br />
|<br />
* Simple partitioning and setup<br />
* On a GPT partitioned disk, [[systemd#GPT partition automounting|systemd can auto-mount]] the root partition.<br />
|<br />
* Inflexible; disk-space to be encrypted has to be pre-allocated<br />
|----------------------------------------------------------<br />
| [[#LVM on LUKS]]<br />
achieves partitioning flexibility by using LVM inside a single LUKS encrypted partition.<br />
|<br />
* Simple partitioning with knowledge of LVM<br />
* Only one key required to unlock all volumes (e.g. easy resume-from-disk setup)<br />
* Volume layout not visible when locked<br />
* Easiest method to allow [[dm-crypt/Swap encryption#With suspend-to-disk support|suspension to disk]]<br />
|<br />
* LVM adds an additional mapping layer and hook<br />
* Less useful, if a singular volume should receive a separate key<br />
|----------------------------------------------------------<br />
| [[#LUKS on LVM]]<br />
uses dm-crypt only after the LVM is setup.<br />
|<br />
* LVM can be used to have encrypted volumes span multiple disks<br />
* Easy mix of un-/encrypted volume groups<br />
|<br />
* Complex; changing volumes requires changing encryption mappers too<br />
* Volumes require individual keys<br />
* LVM layout is visible when locked<br />
* Slower boot time; each encrypted LV must be unlocked seperately<br />
|----------------------------------------------------------<br />
| [[#LUKS on software RAID]]<br />
uses dm-crypt only after RAID is setup.<br />
|<br />
* Analogous to LUKS on LVM<br />
|<br />
* Analogous to LUKS on LVM<br />
|----------------------------------------------------------<br />
| [[#Plain dm-crypt]]<br />
uses dm-crypt plain mode, i.e. without a LUKS header and its options for multiple keys. <br>This scenario also employs USB devices for {{ic|/boot}} and key storage, which may be applied to the other scenarios.<br />
|<br />
* Data resilience for cases where a LUKS header may be damaged<br />
* Allows [[Wikipedia:Disk encryption#Full disk encryption|Full Disk Encryption]]<br />
* Helps addressing [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)|problems]] with SSDs<br />
|<br />
* High care to all encryption parameters is required<br />
* Single encryption key and no option to change it<br />
|----------------------------------------------------------<br />
| [[#Encrypted boot partition (GRUB)]]<br />
shows how to encrypt the boot partition using the GRUB bootloader. <br> This scenario also employs an EFI system partition, which may be applied to the other scenarios.<br />
|<br />
* Same advantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* Less data is left unencrypted, i.e. the boot loader and the EFI system partition, if present<br />
|<br />
* Same disadvantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* More complicated configuration<br />
* Not supported by other boot loaders<br />
|----------------------------------------------------------<br />
| [[#Btrfs subvolumes with swap]]<br />
shows how to encrypt a [[Btrfs]] system, including the {{ic|/boot}} directory, also adding a partition for swap, on UEFI hardware.<br />
|<br />
* Similar advantages as [[#Encrypted boot partition (GRUB)]]<br />
* Availability of Btrfs' features<br />
|<br />
* Similar disadvantages as [[#Encrypted boot partition (GRUB)]]<br />
|----------------------------------------------------------<br />
| [[#Root on ZFS]]<br />
|<br />
|<br />
|}<br />
<br />
While all above scenarios provide much greater protection from outside threats than encrypted secondary filesystems, they also share a common disadvantage: any user in possession of the encryption key is able to decrypt the entire drive, and therefore can access other users' data. If that is of concern, it is possible to use a combination of block device and stacked filesystem encryption and reap the advantages of both. See [[Data-at-rest encryption]] to plan ahead.<br />
<br />
See [[dm-crypt/Drive preparation#Partitioning]] for a general overview of the partitioning strategies used in the scenarios.<br />
<br />
Another area to consider is whether to set up an encrypted swap partition and what kind. See [[dm-crypt/Swap encryption]] for alternatives.<br />
<br />
If you anticipate to protect the system's data not only against physical theft, but also have a requirement of precautions against logical tampering, see [[dm-crypt/Specialties#Securing the unencrypted boot partition]] for further possibilities after following one of the scenarios.<br />
<br />
For [[solid state drive]]s you might want to consider enabling TRIM support, but be warned, there are potential security implications. See [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] for more information.<br />
<br />
{{Warning|<br />
* In any scenario, never use file system repair software such as [[fsck]] directly on an encrypted volume, or it will destroy any means to recover the key used to decrypt your files. Such tools must be used on the decrypted (opened) device instead.<br />
* For the LUKS2 format:<br />
** 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 />
** The LUKS2 format has a high RAM usage per design, defaulting to 1GB per encrypted mapper. Machines with low RAM and/or multiple LUKS2 partitions unlocked in parallel may error on boot. See the {{ic|--pbkdf-memory}} option to control memory usage.[https://gitlab.com/cryptsetup/cryptsetup/issues/372]<br />
}}<br />
<br />
== LUKS on a partition ==<br />
<br />
This example covers a full system encryption with ''dm-crypt'' + LUKS in a simple partition layout:<br />
<br />
{{Text art|<nowiki><br />
+-----------------------+------------------------+-----------------------+<br />
| Boot partition | LUKS2 encrypted system | Optional free space |<br />
| | partition | for additional |<br />
| | | partitions to be set |<br />
| /boot | / | up later |<br />
| | | |<br />
| | /dev/mapper/root | |<br />
| |------------------------| |<br />
| /dev/sda1 | /dev/sda2 | |<br />
+-----------------------+------------------------+-----------------------+<br />
</nowiki>}}<br />
<br />
The first steps can be performed directly after booting the Arch Linux install image.<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
Then create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda2}}) and {{ic|/boot}} ({{ic|/dev/sda1}}). See [[Partitioning]].<br />
<br />
=== Preparing non-boot partitions ===<br />
<br />
The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in [[dm-crypt/Encrypting a non-root file system#Partition]] (which, despite the title, ''can'' be applied to root partitions, as long as [[#Configuring mkinitcpio|mkinitcpio]] and the [[#Configuring the boot loader|boot loader]] are correctly configured).<br />
If you want to use particular non-default encryption options (e.g. cipher, key length), see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|encryption options]] before executing the first command. For information on changing the default sector size, see [[dm-crypt/Device encryption#Sector size]].<br />
<br />
# cryptsetup -y -v luksFormat /dev/sda2<br />
# cryptsetup open /dev/sda2 root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
Check the mapping works as intended:<br />
<br />
# umount /mnt<br />
# cryptsetup close root<br />
# cryptsetup open /dev/sda2 root<br />
# mount /dev/mapper/root /mnt<br />
<br />
If you created separate partitions (e.g. {{ic|/home}}), these steps have to be adapted and repeated for all of them, ''except'' for {{ic|/boot}}. See [[dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting]] on how to handle additional partitions at boot.<br />
<br />
Note that each block device requires its own passphrase. This may be inconvenient, because it results in a separate passphrase to be input during boot. An alternative is to use a keyfile stored in the system partition to unlock the separate partition via {{ic|crypttab}}. See [[dm-crypt/Device encryption#Using LUKS to format partitions with a keyfile]] for instructions.<br />
<br />
=== Preparing the boot partition ===<br />
<br />
What you do have to setup is a non-encrypted {{ic|/boot}} partition, which is needed for an encrypted root. For an ordinary boot partition on BIOS systems, for example, execute:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
or for an [[EFI system partition]] on UEFI systems:<br />
<br />
# mkfs.fat -F32 /dev/sda1<br />
<br />
Afterwards create the directory for the mountpoint and mount the partition:<br />
<br />
# mount --mkdir /dev/sda1 /mnt/boot<br />
<br />
=== Mounting the devices ===<br />
<br />
At [[Installation guide#Mount the file systems]] you will have to mount the mapped devices, not the actual partitions. Of course {{ic|/boot}}, which is not encrypted, will still have to be mounted directly.<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Add the {{ic|keyboard}}, {{ic|keymap}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]. If the default US keymap is fine for you, you can omit the {{ic|keymap}} hook.<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following [[kernel parameters]] need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':root root=/dev/mapper/root<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=root root=/dev/mapper/root<br />
<br />
{{ic|rd.luks.name}} is honored only in the initrd, while {{ic|luks.name}} is honored by both the main system and the initrd.<br />
<br />
Read the [https://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html systemd-cryptsetup-generator] manual page for more boot loader options. <br />
<br />
Also see [[dm-crypt/System configuration#Kernel parameters]] for more details.<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of the LUKS superblock, in this case {{ic|/dev/sda2}}. See [[Persistent block device naming]] for details.<br />
<br />
== LVM on LUKS ==<br />
<br />
The straightforward method is to set up [[LVM]] on top of the encrypted partition instead of the other way round. Technically the LVM is setup inside one big encrypted block device. Hence, the LVM is not visible until the block device is unlocked and the underlying volume structure is scanned and mounted during boot.<br />
<br />
The disk layout in this example is:<br />
<br />
{{Text art|<nowiki><br />
+-----------------------------------------------------------------------+ +----------------+<br />
| Logical volume 1 | Logical volume 2 | Logical volume 3 | | Boot partition |<br />
| | | | | |<br />
| [SWAP] | / | /home | | /boot |<br />
| | | | | |<br />
| /dev/MyVolGroup/swap | /dev/MyVolGroup/root | /dev/MyVolGroup/home | | |<br />
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on |<br />
| | | other device) |<br />
| LUKS2 encrypted partition | | |<br />
| /dev/sda1 | | /dev/sdb1 |<br />
+-----------------------------------------------------------------------+ +----------------+<br />
</nowiki>}}<br />
<br />
{{Note|While using the {{ic|encrypt}} hook this method does not allow you to span the logical volumes over multiple disks; either use the [[sd-encrypt]] or see [[dm-crypt/Specialties#Modifying the encrypt hook for multiple partitions]].}}<br />
<br />
{{Tip|Two variants of this setup:<br />
* Instructions at [[dm-crypt/Specialties#Encrypted system using a detached LUKS header]] use this setup with a detached LUKS header on a USB device to achieve a two factor authentication with it.<br />
* Instructions at [[dm-crypt/Specialties#Encrypted /boot and a detached LUKS header on USB]] use this setup with a detached LUKS header, encrypted {{ic|/boot}} partition, and encrypted keyfile all on a USB device.<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
{{Tip|When using the [[GRUB]] boot loader for BIOS booting from a [[GPT]] disk, create a [[BIOS boot partition]].}}<br />
<br />
[[Installation guide#Partition the disks|Create a partition]] to be mounted at {{ic|/boot}} with a size of 200 MiB or more.<br />
<br />
{{Tip|UEFI systems can use the [[EFI system partition]] for {{ic|/boot}}.}}<br />
<br />
Create a partition which will later contain the encrypted container.<br />
<br />
Create the LUKS encrypted container at the "system" partition. Enter the chosen password twice.<br />
<br />
# cryptsetup luksFormat /dev/sda1<br />
<br />
For more information about the available cryptsetup options see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|LUKS encryption options]] prior to above command.<br />
<br />
Open the container:<br />
<br />
# cryptsetup open /dev/sda1 cryptlvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/cryptlvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
Create a physical volume on top of the opened LUKS container:<br />
<br />
# pvcreate /dev/mapper/cryptlvm<br />
<br />
Create a volume group (in this example named {{ic|MyVolGroup}}, but it can be whatever you want) and add the previously created physical volume to it:<br />
<br />
# vgcreate MyVolGroup /dev/mapper/cryptlvm<br />
<br />
Create all your logical volumes on the volume group:<br />
<br />
{{Tip|If a logical volume will be formatted with [[ext4]], leave at least 256 MiB free space in the volume group to allow using {{man|8|e2scrub}}.}}<br />
<br />
# lvcreate -L 8G MyVolGroup -n swap<br />
# lvcreate -L 32G MyVolGroup -n root<br />
# lvcreate -l 100%FREE MyVolGroup -n home<br />
<br />
Format your filesystems on each logical volume:<br />
<br />
# mkfs.ext4 /dev/MyVolGroup/root<br />
# mkfs.ext4 /dev/MyVolGroup/home<br />
# mkswap /dev/MyVolGroup/swap<br />
<br />
Mount your filesystems:<br />
<br />
# mount /dev/MyVolGroup/root /mnt<br />
# mount --mkdir /dev/MyVolGroup/home /mnt/home<br />
# swapon /dev/MyVolGroup/swap<br />
<br />
=== Preparing the boot partition ===<br />
<br />
The bootloader loads the kernel, [[initramfs]], and its own configuration files from the {{ic|/boot}} directory. Any filesystem on a disk that can be read by the bootloader is eligible.<br />
<br />
Create a [[filesystem]] on the partition intended for {{ic|/boot}}:<br />
<br />
# mkfs.ext4 /dev/sdb1<br />
<br />
{{Tip|When opting to keep {{ic|/boot}} on an [[EFI system partition]] the recommended formatting is<br />
<br />
# mkfs.fat -F32 /dev/sdb1<br />
<br />
}}<br />
<br />
Mount the partition to {{ic|/mnt/boot}}:<br />
<br />
# mount --mkdir /dev/sdb1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following kernel parameter needs to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':cryptlvm root=/dev/MyVolGroup/root<br />
<br />
If using the [[sd-encrypt]] hook, the following needs to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=cryptlvm root=/dev/MyVolGroup/root<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of the LUKS superblock, in this case {{ic|/dev/sda1}}. See [[Persistent block device naming]] for details.<br />
<br />
{{ic|rd.luks.name}} is honored only in the initrd, while {{ic|luks.name}} is honored by both the main system and the initrd.<br />
<br />
Read the [https://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html systemd-cryptsetup-generator] manual page for more boot loader options relevant to Sd-encrypt.<br />
<br />
If using [[dracut]], you may need a more extensive list of parameters, try:<br />
<br />
kernel_cmdline="rd.luks.uuid=luks-''deviceUUID'' rd.lvm.lv=''MyVolGroup''/root rd.lvm.lv=''MyVolGroup''/swap root=/dev/mapper/''MyVolGroup''-root rootfstype=ext4 rootflags=rw,relatime"<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] for details.<br />
<br />
== LUKS on LVM ==<br />
<br />
To use encryption on top of [[LVM]], the LVM volumes are set up first and then used as the base for the encrypted partitions. This way, a mixture of encrypted and non-encrypted volumes/partitions is possible as well.<br />
{{tip|Unlike [[#LVM on LUKS]], this method allows normally spanning the logical volumes over multiple disks. }}<br />
<br />
The following short example creates a LUKS on LVM setup and mixes in the use of a key-file for the /home partition and temporary crypt volumes for {{ic|/tmp}} and {{ic|/swap}}. The latter is considered desirable from a security perspective, because no potentially sensitive temporary data survives the reboot, when the encryption is re-initialised. If you are experienced with LVM, you will be able to ignore/replace LVM and other specifics according to your plan.<br />
<br />
If you want to span a logical volume over multiple disks that have already been set up, or expand the logical volume for {{ic|/home}} (or any other volume), a procedure to do so is described in [[dm-crypt/Specialties#Expanding LVM on multiple disks]]. It is important to note that the LUKS encrypted container has to be resized as well.<br />
<br />
{{Expansion|The intro of this scenario needs some adjustment now that a comparison has been added to [[#Overview]]. A suggested structure is to make it similar to the [[#LUKS on a partition]] intro.}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Partitioning scheme:<br />
<br />
{{Text art|<nowiki><br />
+----------------+-------------------------------------------------------------------------------------------------+<br />
| Boot partition | dm-crypt plain encrypted volume | LUKS2 encrypted volume | LUKS2 encrypted volume |<br />
| | | | |<br />
| /boot | [SWAP] | / | /home |<br />
| | | | |<br />
| | /dev/mapper/swap | /dev/mapper/root | /dev/mapper/home |<br />
| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
| | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | /dev/MyVolGroup/cryptswap | /dev/MyVolGroup/cryptroot | /dev/MyVolGroup/crypthome |<br />
| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
| | |<br />
| /dev/sda1 | /dev/sda2 |<br />
+----------------+-------------------------------------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
Randomise {{ic|/dev/sda2}} according to [[dm-crypt/Drive preparation#dm-crypt wipe on an empty disk or partition]].<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
# pvcreate /dev/sda2<br />
# vgcreate MyVolGroup /dev/sda2<br />
# lvcreate -L 32G -n cryptroot MyVolGroup<br />
# lvcreate -L 500M -n cryptswap MyVolGroup<br />
# lvcreate -L 500M -n crypttmp MyVolGroup<br />
# lvcreate -l 100%FREE -n crypthome MyVolGroup<br />
<br />
# cryptsetup luksFormat /dev/MyVolGroup/cryptroot<br />
# cryptsetup open /dev/MyVolGroup/cryptroot root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
More information about the encryption options can be found in [[dm-crypt/Device encryption#Encryption options for LUKS mode]].<br />
Note that {{ic|/home}} will be encrypted in [[#Encrypting logical volume /home]].<br />
<br />
{{Tip|If you ever have to access the encrypted root from the Arch-ISO, the above {{ic|open}} action will allow you to after the [[LVM#Logical Volumes do not show up|LVM shows up]].}}<br />
<br />
=== Preparing the boot partition ===<br />
<br />
# dd if=/dev/zero of=/dev/sda1 bs=1M status=progress<br />
# mkfs.ext4 /dev/sda1<br />
# mount --mkdir /dev/sda1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|lvm2}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''lvm2''' '''encrypt''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following [[kernel parameters]] need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':root root=/dev/mapper/root<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=root root=/dev/mapper/root<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/MyVolGroup/cryptroot}}. See [[Persistent block device naming]] for details.<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] for details.<br />
<br />
=== Configuring fstab and crypttab ===<br />
<br />
Both [[crypttab]] and [[fstab]] entries are required to both unlock the device and mount the filesystems, respectively. The following lines will re-encrypt the temporary filesystems on each reboot:<br />
<br />
{{hc|/etc/crypttab|2=<br />
swap /dev/MyVolGroup/cryptswap /dev/urandom swap,cipher=aes-xts-plain64,size=256<br />
tmp /dev/MyVolGroup/crypttmp /dev/urandom tmp,cipher=aes-xts-plain64,size=256<br />
}}<br />
<br />
{{hc|/etc/fstab|<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/sda1 /boot ext4 defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
=== Encrypting logical volume /home ===<br />
<br />
Since this scenario uses LVM as the primary and dm-crypt as secondary mapper, each encrypted logical volume requires its own encryption. Yet, unlike the temporary filesystems configured with volatile encryption above, the logical volume for {{ic|/home}} should of course be persistent. The following assumes you have rebooted into the installed system, otherwise you have to adjust paths.<br />
To save on entering a second passphrase at boot, a [[dm-crypt/Device encryption#Keyfiles|keyfile]] is created:<br />
<br />
# mkdir -m 700 /etc/luks-keys<br />
# dd if=/dev/random of=/etc/luks-keys/home bs=1 count=256 status=progress<br />
<br />
The logical volume is encrypted with it:<br />
<br />
# cryptsetup luksFormat -v /dev/MyVolGroup/crypthome /etc/luks-keys/home<br />
# cryptsetup -d /etc/luks-keys/home open /dev/MyVolGroup/crypthome home<br />
# mkfs.ext4 /dev/mapper/home<br />
# mount /dev/mapper/home /home<br />
<br />
The encrypted mount is configured in both [[crypttab]] and [[fstab]]:<br />
<br />
{{hc|/etc/crypttab|<br />
home /dev/MyVolGroup/crypthome /etc/luks-keys/home<br />
}}<br />
<br />
{{hc|/etc/fstab|<br />
/dev/mapper/home /home ext4 defaults 0 2<br />
}}<br />
<br />
== LUKS on software RAID ==<br />
<br />
This example is based on a real-world setup for a workstation class laptop equipped with two SSDs of equal size, and an additional HDD for bulk storage. The end result is LUKS1 based full disk encryption (including {{ic|/boot}}) for all drives, with the SSDs in a [[RAID|RAID0]] array, and keyfiles used to unlock all encryption after [[GRUB]] is given a correct passphrase at boot.<br />
<br />
This setup utilizes a very simplistic partitioning scheme, with all the available RAID storage being mounted at {{ic|/}} (no separate {{ic|/boot}} partition), and the decrypted HDD being mounted at {{ic|/data}}.<br />
<br />
Please note that regular [[System backup|backups]] are very important in this setup. If either of the SSDs fail, the data contained in the RAID array will be practically impossible to recover. You may wish to select a different [[RAID#Standard RAID levels|RAID level]] if fault tolerance is important to you. <br />
<br />
The encryption is not deniable in this setup.<br />
<br />
For the sake of the instructions below, the following block devices are used:<br />
<br />
/dev/sda = first SSD<br />
/dev/sdb = second SSD<br />
/dev/sdc = HDD<br />
<br />
{{Text art|<nowiki><br />
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+<br />
| BIOS boot partition | EFI system partition | LUKS1 encrypted volume | | BIOS boot partition | EFI system partition | LUKS1 encrypted volume | | LUKS2 encrypted volume |<br />
| | | | | | | | | |<br />
| | /efi | / | | | /efi | / | | /data |<br />
| | | | | | | | | |<br />
| | | /dev/mapper/root | | | | /dev/mapper/root | | |<br />
| +---------------------------+---------------------------+ | +---------------------------+---------------------------+ | |<br />
| | RAID1 array (part 1 of 2) | RAID0 array (part 1 of 2) | | | RAID1 array (part 2 of 2) | RAID0 array (part 2 of 2) | | |<br />
| | | | | | | | | |<br />
| | /dev/md/ESP | /dev/md/root | | | /dev/md/ESP | /dev/md/root | | /dev/mapper/data |<br />
| +---------------------------+---------------------------+ | +---------------------------+---------------------------+ +---------------------------+<br />
| /dev/sda1 | /dev/sda2 | /dev/sda3 | | /dev/sdb1 | /dev/sdb2 | /dev/sdb3 | | /dev/sdc1 |<br />
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+<br />
</nowiki>}}<br />
<br />
Be sure to substitute them with the appropriate device designations for your setup, as they may be different.<br />
<br />
=== Preparing the disks ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
For [[GRUB#BIOS systems|BIOS systems]] with GPT, create a [[BIOS boot partition]] with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition.<br />
<br />
For [[GRUB#UEFI systems|UEFI systems]] create an [[EFI system partition]] with an appropriate size, it will later be mounted at {{ic|/efi}}.<br />
<br />
In the remaining space on the drive create a partition ({{ic|/dev/sda3}} in this example) for "Linux RAID". Choose partition type ID {{ic|fd}} for MBR or partition type GUID {{ic|A19D880F-05FC-4D3B-A006-743F0F84911E}} for GPT.<br />
<br />
Once partitions have been created on {{ic|/dev/sda}}, the following commands can be used to clone them to {{ic|/dev/sdb}}.<br />
<br />
# sfdisk -d /dev/sda > sda.dump<br />
# sfdisk /dev/sdb < sda.dump<br />
<br />
The HDD is prepared with a single Linux partition covering the whole drive at {{ic|/dev/sdc1}}.<br />
<br />
=== Building the RAID array ===<br />
<br />
Create the RAID array for the SSDs.<br />
<br />
{{Note|<br />
* All parts of an EFI system partition RAID array must be individually usable, that means that ESP can only placed in a RAID1 array.<br />
* The RAID superblock must be placed at the end of the EFI system partition using {{ic|1=--metadata=1.0}}, otherwise the firmware will not be able to access the partition.<br />
}}<br />
<br />
# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sda2 /dev/sdb2<br />
<br />
This example utilizes RAID0 for root, you may wish to substitute a different level based on your preferences or requirements.<br />
<br />
# mdadm --create --verbose --level=0 --metadata=1.2 --raid-devices=2 /dev/md/root /dev/sda3 /dev/sdb3<br />
<br />
=== Preparing the block devices ===<br />
<br />
As explained in [[dm-crypt/Drive preparation]], the devices are wiped with random data utilizing {{ic|/dev/zero}} and a crypt device with a random key. Alternatively, you could use {{ic|dd}} with {{ic|/dev/random}} or {{ic|/dev/urandom}}, though it will be much slower.<br />
<br />
# cryptsetup open --type plain /dev/md/root container --key-file /dev/random<br />
# dd if=/dev/zero of=/dev/mapper/container bs=1M status=progress<br />
# cryptsetup close container<br />
<br />
And repeat above for the HDD ({{ic|/dev/sdc1}} in this example).<br />
<br />
Set up encryption for {{ic|/dev/md/root}}:<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 />
# cryptsetup -y -v luksFormat --type luks1 /dev/md/root<br />
# cryptsetup open /dev/md/root root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
And repeat for the HDD:<br />
<br />
# cryptsetup -y -v luksFormat /dev/sdc1<br />
# cryptsetup open /dev/sdc1 data<br />
# mkfs.ext4 /dev/mapper/data<br />
# mount --mkdir /dev/mapper/data /mnt/data<br />
<br />
For UEFI systems, set up the EFI system partition:<br />
<br />
# mkfs.fat -F32 /dev/md/ESP<br />
# mount --mkdir /dev/md/ESP /mnt/efi<br />
<br />
=== Configuring GRUB ===<br />
<br />
Configure [[GRUB]] for the LUKS1 encrypted system by editing {{ic|/etc/default/grub}} with the following:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/md/root:root"<br />
GRUB_ENABLE_CRYPTODISK=y<br />
<br />
{{Merge|GRUB#Troubleshooting|GRUB troubleshooting issues belong in the [[GRUB]] page. It should be moved there and simply linked from this section.}}<br />
<br />
If you have a USB keyboard on a newer system either enable legacy USB support in firmware or add the following to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_TERMINAL_INPUT="usb_keyboard"<br />
GRUB_PRELOAD_MODULES="usb usb_keyboard ohci uhci ehci"<br />
<br />
Otherwise you may not be able to use your keyboard at the LUKS prompt.<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] and [[GRUB#Encrypted /boot]] for details.<br />
<br />
Complete the GRUB install to both SSDs (in reality, installing only to {{ic|/dev/sda}} will work).<br />
<br />
# grub-install --target=i386-pc /dev/sda<br />
# grub-install --target=i386-pc /dev/sdb<br />
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Creating the keyfiles ===<br />
<br />
The next steps save you from entering your passphrase twice when you boot the system (once so GRUB can unlock the LUKS1 device, and second time once the initramfs assumes control of the system). This is done by creating a [[dm-crypt/Device encryption#Keyfiles|keyfile]] for the encryption and adding it to the initramfs image to allow the encrypt hook to unlock the root device. See [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] for details.<br />
<br />
* Create the [[dm-crypt/Device encryption#Keyfiles|keyfile]] and add the key to {{ic|/dev/md/root}}.<br />
* Create another keyfile for the HDD ({{ic|/dev/sdc1}}) so it can also be unlocked at boot. For convenience, leave the passphrase created above in place as this can make recovery easier if you ever need it. Edit {{ic|/etc/crypttab}} to decrypt the HDD at boot. See [[Dm-crypt/System configuration#Unlocking with a keyfile]].<br />
<br />
=== Configuring the system ===<br />
<br />
Edit [[fstab]] to mount the root and data block devices and the ESP:<br />
<br />
/dev/mapper/root / ext4 rw,noatime 0 1<br />
/dev/mapper/data /data ext4 defaults 0 2<br />
/dev/md/ESP /efi vfat rw,relatime,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,tz=UTC,errors=remount-ro 0 2<br />
<br />
Save the RAID configuration:<br />
<br />
# mdadm --detail --scan >> /etc/mdadm.conf<br />
<br />
Edit [[mkinitcpio.conf]] to include your keyfile and add the proper hooks:<br />
<br />
FILES=(/crypto_keyfile.bin)<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''mdadm_udev''' '''encrypt''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details.<br />
<br />
== Plain dm-crypt ==<br />
<br />
Contrary to LUKS, dm-crypt ''plain'' mode does not require a header on the encrypted device: this scenario exploits this feature to set up a system on an unpartitioned, encrypted disk that will be indistinguishable from a disk filled with random data, which could allow [[Wikipedia:Deniable encryption|deniable encryption]]. See also [[wikipedia:Disk encryption#Full disk encryption]].<br />
<br />
Note that if full-disk encryption is not required, the methods using LUKS described in the sections above are better options for both system encryption and encrypted partitions. LUKS features like key management with multiple passphrases/key-files or re-encrypting a device in-place are unavailable with ''plain'' mode.<br />
<br />
''Plain'' dm-crypt encryption can be more resilient to damage than LUKS, because it does not rely on an encryption master-key which can be a single-point of failure if damaged. However, using ''plain'' mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also [[Data-at-rest encryption#Cryptographic metadata]]. Using ''plain'' mode could also be considered if concerned with the problems explained in [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]].<br />
<br />
{{Tip|If headerless encryption is your goal but you are unsure about the lack of key-derivation with ''plain'' mode, then two alternatives are:<br />
* [[dm-crypt/Specialties#Encrypted system using a detached LUKS header|dm-crypt LUKS mode with a detached header]] by using the ''cryptsetup'' {{ic|--header}} option. It cannot be used with the standard ''encrypt'' hook, but the hook may be modified.<br />
* [[tcplay]] which offers headerless encryption but with the PBKDF2 function.<br />
}}<br />
<br />
The scenario uses two USB sticks:<br />
<br />
* one for the boot device, which also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone;<br />
* another for the encryption key file, assuming it stored as raw bits so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also [[Wikipedia:Security through obscurity]], follow [[dm-crypt/Device encryption#Keyfiles]] to prepare the keyfile.<br />
<br />
The disk layout is:<br />
<br />
{{Text art|<nowiki><br />
+----------------------+----------------------+----------------------+ +----------------+ +----------------+<br />
| Logical volume 1 | Logical volume 2 | Logical volume 3 | | Boot device | | Encryption key |<br />
| | | | | | | file storage |<br />
| / | [SWAP] | /home | | /boot | | (unpartitioned |<br />
| | | | | | | in example) |<br />
| /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home | | /dev/sdb1 | | /dev/sdc |<br />
|----------------------+----------------------+----------------------| |----------------| |----------------|<br />
| disk drive /dev/sda encrypted using plain mode and LVM | | USB stick 1 | | USB stick 2 |<br />
+--------------------------------------------------------------------+ +----------------+ +----------------+<br />
</nowiki>}}<br />
<br />
{{Tip|<br />
* It is also possible to use a single USB key physical device:<br />
** By putting the key on another partition (/dev/sdb2) of the USB storage device (/dev/sdb).<br />
** By copying the keyfile to the initramfs directly. An example keyfile {{ic|/etc/keyfile}} gets copied to the initramfs image by setting {{ic|1=FILES=(/etc/keyfile)}} in {{ic|/etc/mkinitcpio.conf}}. The way to instruct the {{ic|encrypt}} hook to read the keyfile in the initramfs image is using {{ic|rootfs:}} prefix before the filename, e.g. {{ic|1=cryptkey=rootfs:/etc/keyfile}}.<br />
* Another option is using a passphrase with good [[Security#Choosing secure passwords|entropy]].<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
It is vital that the mapped device is filled with random data. In particular this applies to the scenario use case we apply here.<br />
<br />
See [[dm-crypt/Drive preparation]] and [[dm-crypt/Drive preparation#dm-crypt specific methods]]<br />
<br />
=== Preparing the non-boot partitions ===<br />
<br />
See [[dm-crypt/Device encryption#Encryption options for plain mode]] for details.<br />
<br />
Using the device {{ic|/dev/sda}}, with the aes-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario:<br />
<br />
# cryptsetup --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sdc --key-size=512 open --type plain /dev/sda cryptlvm<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, and key file details.<br />
<br />
We can now check a mapping entry has been made for {{ic|/dev/mapper/cryptlvm}}:<br />
<br />
# fdisk -l<br />
<br />
{{Tip|A simpler alternative to using LVM, advocated in the cryptsetup FAQ for cases where LVM is not necessary, is to just create a filesystem on the entirety of the mapped dm-crypt device.}} <br />
<br />
Next, we setup [[LVM]] logical volumes on the mapped device. See [[Install Arch Linux on LVM]] for further details:<br />
<br />
# pvcreate /dev/mapper/cryptlvm<br />
# vgcreate MyVolGroup /dev/mapper/cryptlvm<br />
# lvcreate -L 32G MyVolGroup -n root<br />
# lvcreate -L 10G MyVolGroup -n swap<br />
# lvcreate -l 100%FREE MyVolGroup -n home<br />
<br />
We format and mount them and activate swap. See [[File systems#Create a file system]] for further details:<br />
<br />
# mkfs.ext4 /dev/MyVolGroup/root<br />
# mkfs.ext4 /dev/MyVolGroup/home<br />
# mount /dev/MyVolGroup/root /mnt<br />
# mount --mkdir /dev/MyVolGroup/home /mnt/home<br />
# mkswap /dev/MyVolGroup/swap<br />
# swapon /dev/MyVolGroup/swap<br />
<br />
=== Preparing the boot partition ===<br />
<br />
The {{ic|/boot}} partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200 MiB partition is all that is required. Create the partition using a [[Partitioning#Partitioning tools|partitioning tool]] of your choice.<br />
<br />
Create a [[filesystem]] on the partition intended for {{ic|/boot}}:<br />
<br />
# mkfs.fat -F32 /dev/sdb1<br />
# mount --mkdir /dev/sdb1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to boot the encrypted root partition, the following [[kernel parameters]] need to be set by the boot loader (note that 64 is the number of bytes in 512 bits):<br />
<br />
cryptdevice=/dev/disk/by-id/''disk-ID-of-sda'':cryptlvm cryptkey=/dev/disk/by-id/''disk-ID-of-sdc'':0:64 crypto=:aes-xts-plain64:512:0:<br />
<br />
The {{ic|''disk-ID-of-'''disk'''''}} refers to the id of the referenced disk. See [[Persistent block device naming]] for details.<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] for details and other parameters that you may need.<br />
<br />
{{Tip|If using GRUB, you can install it on the same USB as the {{ic|/boot}} partition with:<br />
<br />
# grub-install --recheck /dev/sdb<br />
<br />
}}<br />
<br />
=== Post-installation ===<br />
<br />
You may wish to remove the USB sticks after booting. Since the {{ic|/boot}} partition is not usually needed, the {{ic|noauto}} option can be added to the relevant line in {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|<br />
# /dev/sdb1<br />
/dev/sdb1 /boot vfat '''noauto''',rw,noatime 0 2<br />
}}<br />
<br />
However, when an update to anything used in the initramfs, or a kernel, or the bootloader is required; the {{ic|/boot}} partition must be present and mounted. As the entry in {{ic|fstab}} already exists, it can be mounted simply with:<br />
<br />
# mount /boot<br />
<br />
== Encrypted boot partition (GRUB) ==<br />
<br />
This setup utilizes the same partition layout and configuration as the previous [[#LVM on LUKS]] section, with the difference that the [[GRUB]] boot loader is used since it is capable of booting from an LVM logical volume and a LUKS1-encrypted {{ic|/boot}}. See also [[GRUB#Encrypted /boot]].<br />
<br />
The disk layout in this example is:<br />
<br />
{{Text art|<nowiki><br />
+---------------------+----------------------+----------------------+----------------------+----------------------+<br />
| BIOS boot partition | EFI system partition | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | | | | |<br />
| | /efi | / | [SWAP] | /home |<br />
| | | | | |<br />
| | | /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home |<br />
| /dev/sda1 | /dev/sda2 |----------------------+----------------------+----------------------+<br />
| unencrypted | unencrypted | /dev/sda3 encrypted using LVM on LUKS1 |<br />
+---------------------+----------------------+--------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
{{Tip|<br />
* All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in [[#LVM on LUKS]].<br />
* You can use {{ic|cryptboot}} script from {{AUR|cryptboot}} package for simplified encrypted boot management (mounting, unmounting, upgrading packages) and as a defense against [https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html Evil Maid] attacks with [[Secure Boot#Using your own keys|UEFI Secure Boot]]. For more information and limitations see [https://github.com/kmille/cryptboot cryptboot project] page.<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
For [[GRUB#GUID Partition Table (GPT) specific instructions|BIOS/GPT systems]] create a [[BIOS boot partition]] with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition. For BIOS/MBR systems this is not necessary.<br />
<br />
For [[GRUB#UEFI systems|UEFI systems]] create an [[EFI system partition]] with an appropriate size, it will later be mounted at {{ic|/efi}}.<br />
<br />
Create a partition of type {{ic|8309}}, which will later contain the encrypted container for the LVM.<br />
<br />
Create the LUKS encrypted container:<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 />
# cryptsetup luksFormat --type luks1 /dev/sda3<br />
<br />
For more information about the available cryptsetup options see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|LUKS encryption options]] prior to above command.<br />
<br />
Your partition layout should look similar to this:<br />
<br />
{{hc|# gdisk -l /dev/sda|<br />
...<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 4095 1024.0 KiB EF02 BIOS boot partition<br />
2 4096 1130495 550.0 MiB EF00 EFI System<br />
3 1130496 68239360 32.0 GiB 8309 Linux LUKS<br />
}}<br />
<br />
Open the container:<br />
<br />
# cryptsetup open /dev/sda3 cryptlvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/cryptlvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
The LVM logical volumes of this example follow the exact layout as the [[#LVM on LUKS]] scenario. Therefore, please follow [[#Preparing the logical volumes]] above and adjust as required.<br />
<br />
If you plan to boot in UEFI mode, create a mountpoint for the [[EFI system partition]] at {{ic|/efi}} for compatibility with {{ic|grub-install}} and mount it:<br />
<br />
# mount --mkdir /dev/sda2 /mnt/efi<br />
<br />
At this point, you should have the following partitions and logical volumes inside of {{ic|/mnt}}:<br />
<br />
{{hc|$ lsblk|<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 200G 0 disk<br />
├─sda1 8:1 0 1M 0 part<br />
├─sda2 8:2 0 550M 0 part /mnt/efi<br />
└─sda3 8:3 0 100G 0 part<br />
└─cryptlvm 254:0 0 100G 0 crypt<br />
├─MyVolGroup-swap 254:1 0 8G 0 lvm [SWAP]<br />
├─MyVolGroup-root 254:2 0 32G 0 lvm /mnt<br />
└─MyVolGroup-home 254:3 0 60G 0 lvm /mnt/home<br />
}}<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring GRUB ===<br />
<br />
Configure GRUB to allow booting from {{ic|/boot}} on a LUKS1 encrypted partition:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_ENABLE_CRYPTODISK=y<br />
}}<br />
<br />
Set the kernel parameters, so that the initramfs can unlock the encrypted root partition. Using the {{ic|encrypt}} hook:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="... cryptdevice=UUID=''device-UUID'':cryptlvm ..."<br />
}}<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="... rd.luks.name=''device-UUID''=cryptlvm ..."<br />
}}<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] and [[GRUB#Encrypted /boot]] for details. The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/sda3}} (the partition which holds the lvm containing the root filesystem). See [[Persistent block device naming]].<br />
<br />
[[GRUB#Installation_2|install GRUB]] to the mounted ESP for UEFI booting:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB --recheck<br />
<br />
[[GRUB#Installation|install GRUB]] to the disk for BIOS booting:<br />
<br />
# grub-install --target=i386-pc --recheck /dev/sda<br />
<br />
Generate GRUB's [[GRUB#Generate the main configuration file|configuration]] file:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
If all commands finished without errors, GRUB should prompt for the passphrase to unlock the {{ic|/dev/sda3}} partition after the next reboot.<br />
<br />
=== Avoiding having to enter the passphrase twice ===<br />
<br />
{{Merge|Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|Too much duplicated content, too much detail here for this overview page.|section=Security Issue with Grub Keyfile}}<br />
<br />
While GRUB asks for a passphrase to unlock the LUKS1 encrypted partition after above instructions, the partition unlock is not passed on to the initramfs. Hence, you have to enter the passphrase twice at boot: once for GRUB and once for the initramfs.<br />
<br />
This section deals with extra configuration to let the system boot by only entering the passphrase once, in GRUB. This is accomplished by [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs|with a keyfile embedded in the initramfs]].<br />
<br />
First create a keyfile and add it as LUKS key:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/root/cryptlvm.keyfile iflag=fullblock<br />
# chmod 000 /root/cryptlvm.keyfile<br />
# cryptsetup -v luksAddKey /dev/sda3 /root/cryptlvm.keyfile<br />
<br />
Add the keyfile to the initramfs image:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
FILES=(/root/cryptlvm.keyfile)<br />
}}<br />
<br />
Recreate the initramfs image and secure the embedded keyfile:<br />
<br />
# chmod 600 /boot/initramfs-linux*<br />
<br />
Set the following kernel parameters to unlock the LUKS partition with the keyfile. Using the {{ic|encrypt}} hook:<br />
<br />
GRUB_CMDLINE_LINUX="... cryptkey=rootfs:/root/cryptlvm.keyfile"<br />
<br />
Or, using the [[sd-encrypt]] hook:<br />
<br />
GRUB_CMDLINE_LINUX="... rd.luks.key=''device-UUID''=/root/cryptlvm.keyfile"<br />
<br />
If for some reason the keyfile fails to unlock the boot partition, systemd will fallback to ask for a passphrase to unlock and, in case that is correct, continue booting.<br />
<br />
{{Tip|If you want to encrypt the {{ic|/boot}} partition to protect against offline tampering threats, the [[dm-crypt/Specialties#mkinitcpio-chkcryptoboot|mkinitcpio-chkcryptoboot]] hook has been contributed to help.}}<br />
<br />
== Btrfs subvolumes with swap ==<br />
<br />
{{Out of date|Btrfs [[Btrfs#Swap_file|supports swapfile]] since 5.0|Talk:Dm-crypt/Encrypting_an_entire_system#Complete_guide_of_Btrfs_on_LUKS_full_disk_encryption}}<br />
The following example creates a full system encryption with LUKS1 using [[Btrfs]] subvolumes to [[Btrfs#Mounting subvolumes|simulate partitions]].<br />
<br />
If using UEFI, an [[EFI system partition]] (ESP) is required. {{ic|/boot}} itself may reside on {{ic|/}} and be encrypted; however, the ESP itself cannot be encrypted. In this example layout, the ESP is {{ic|/dev/sda1}} and is mounted at {{ic|/efi}}. {{ic|/boot}} itself is located on the system partition, {{ic|/dev/sda2}}.<br />
<br />
Since {{ic|/boot}} resides on the LUKS1 encrypted {{ic|/}}, [[GRUB]] must be used as the bootloader because only GRUB can load modules necessary to decrypt {{ic|/boot}} (e.g., crypto.mod, cryptodisk.mod and luks.mod).<br />
<br />
Additionally an optional plain-encrypted [[swap]] partition is shown.<br />
<br />
{{Text art|<nowiki><br />
+----------------------+----------------------+----------------------+<br />
| EFI system partition | System partition | Swap partition |<br />
| unencrypted | LUKS1-encrypted | plain-encrypted |<br />
| | | |<br />
| /efi | / | [SWAP] |<br />
| /dev/sda1 | /dev/sda2 | /dev/sda3 |<br />
+----------------------+----------------------+----------------------+<br />
</nowiki>}}<br />
<br />
=== Preparing the disk ===<br />
<br />
{{Note|It is not possible to use btrfs partitioning as described in [[Btrfs#Partitionless Btrfs disk]] when using LUKS. Traditional partitioning must be used, even if it is just to create one partition.}}<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]]. If you are using [[UEFI]] create an [[EFI system partition]] with an appropriate size. It will later be mounted at {{ic|/efi}}. If you are going to create an encrypted swap partition, create the partition for it, but do '''not''' mark it as swap, since plain ''dm-crypt'' will be used with the partition.<br />
<br />
Create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda2}}). See the [[Partitioning]] article.<br />
<br />
=== Preparing the system partition ===<br />
<br />
==== Create LUKS container ====<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 />
Follow [[dm-crypt/Device encryption#Encrypting devices with LUKS mode]] to setup {{ic|/dev/sda2}} for LUKS. See the [[dm-crypt/Device encryption#Encryption options for LUKS mode]] before doing so for a list of encryption options.<br />
<br />
==== Unlock LUKS container ====<br />
<br />
Now follow [[dm-crypt/Device encryption#Unlocking/Mapping LUKS partitions with the device mapper]] to unlock the LUKS container and map it.<br />
<br />
==== Format mapped device ====<br />
<br />
Proceed to format the mapped device as described in [[Btrfs#File system on a single device]], where {{ic|''/dev/partition''}} is the name of the mapped device (i.e., {{ic|/dev/mapper/''root''}}) and '''not''' {{ic|/dev/sda2}}.<br />
<br />
==== Mount mapped device ====<br />
<br />
Finally, [[mount]] the now-formatted mapped device (i.e., {{ic|/dev/mapper/root}}) to {{ic|/mnt}}.<br />
<br />
=== Creating btrfs subvolumes ===<br />
<br />
{{Merge|Btrfs|The subvolume layout is not specific to an encrypted system.}}<br />
<br />
==== Layout ====<br />
<br />
[[Btrfs#Subvolumes|Subvolumes]] will be used to simulate partitions, but other (nested) subvolumes will also be created. Here is a partial representation of what the following example will generate:<br />
<br />
{{Text art|<nowiki><br />
subvolid=5<br />
|<br />
├── @ -|<br />
| contained directories:<br />
| ├── /usr<br />
| ├── /bin<br />
| ├── /.snapshots<br />
| ├── ...<br />
|<br />
├── @home<br />
├── @snapshots<br />
├── @var_log<br />
└── @...<br />
</nowiki>}}<br />
<br />
This section follows the [[Snapper#Suggested filesystem layout]], which is most useful when used with [[Snapper]]. You should also consult [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout Btrfs Wiki SysadminGuide#Layout].<br />
<br />
==== Create subvolumes for initial mount ====<br />
<br />
Here we are using the convention of prefixing {{ic|@}} to subvolume names that will be used as mount points, and {{ic|@}} will be the subvolume that is mounted as {{ic|/}}.<br />
<br />
Following the [[Btrfs#Creating a subvolume]] article, create subvolumes at {{ic|/mnt/@}}, {{ic|/mnt/@snapshots}}, and {{ic|/mnt/@home}}.<br />
<br />
Create any additional subvolumes you wish to use as mount points now.<br />
<br />
==== Create subvolumes for excludes ====<br />
<br />
Create any subvolumes you do '''not''' want to have snapshots of when taking a snapshot of {{ic|/}}. For example, you probably do not want to take snapshots of {{ic|/var/cache/pacman/pkg}}. These subvolumes will be nested under the {{ic|@}} subvolume, but just as easily could have been created earlier at the same level as {{ic|@}} according to your preference.<br />
<br />
Since the {{ic|@}} subvolume is mounted at {{ic|/mnt}} you will need to [[create a subvolume]] at {{ic|/mnt/var/cache/pacman/pkg}} for this example. You may have to create any parent directories first.<br />
<br />
Other directories you may wish to do this with are {{ic|/var/abs}}, {{ic|/var/tmp}}, and {{ic|/srv}}.<br />
<br />
==== Mount top-level subvolumes ====<br />
<br />
Unmount the system partition at {{ic|/mnt}}.<br />
<br />
Now mount the newly created {{ic|@}} subvolume which will serve as {{ic|/}} to {{ic|/mnt}} using the {{ic|1=subvol=}} mount option. Assuming the mapped device is named {{ic|root}}, the command would look like:<br />
<br />
# mount -o compress=zstd,subvol=@ /dev/mapper/root /mnt<br />
<br />
See [[Btrfs#Mounting subvolumes]] for more details.<br />
<br />
Also mount the other subvolumes to their respective mount points: {{ic|@home}} to {{ic|/mnt/home}} and {{ic|@snapshots}} to {{ic|/mnt/.snapshots}}.<br />
<br />
==== Mount ESP ====<br />
<br />
If you prepared an EFI system partition earlier, create its mount point and mount it now.<br />
<br />
{{Note|Btrfs snapshots will exclude {{ic|/efi}}, since it is not a btrfs file system.}}<br />
<br />
At the [[Installation guide#Install essential packages|pacstrap]] installation step, the {{Pkg|btrfs-progs}} must be installed in addition to the {{Pkg|base}} [[meta package]].<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
==== Create keyfile ====<br />
<br />
In order for GRUB to open the LUKS partition without having the user enter their passphrase twice, we will use a keyfile embedded in the initramfs. Follow [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] making sure to add the key to {{ic|/dev/sda2}} at the ''luksAddKey'' step.<br />
<br />
==== Edit mkinitcpio.conf ====<br />
<br />
After creating, adding, and embedding the key as described above, add the {{ic|encrypt}} hook to [[mkinitcpio.conf]] as well as any other hooks you require.<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
{{Tip|You may want to add {{ic|1=BINARIES=(btrfs)}} to your {{ic|/etc/mkinitcpio.conf}}. See the [[Btrfs#Corruption recovery]] article.}}<br />
<br />
=== Configuring the boot loader ===<br />
<br />
Install [[GRUB]] to {{ic|/dev/sda}}. Then, edit {{ic|/etc/default/grub}} as instructed in the [[GRUB#Additional arguments]], [[GRUB#Encrypted /boot]] and [[dm-crypt/System configuration#Using encrypt hook]], following both the instructions for an encrypted root and boot partition. Finally, generate the GRUB configuration file. Note that you will need to pass kernel parameters for the root mount point as instructed in [[Btrfs#Mounting subvolume as root]].<br />
<br />
=== Configuring swap ===<br />
<br />
If you created a partition to be used for encrypted swap, now is the time to configure it. Follow the instructions at [[dm-crypt/Swap encryption]].<br />
<br />
== Root on ZFS ==<br />
<br />
Root on [[ZFS]] can be configured to encrypt everything except boot loader. See [https://openzfs.github.io/openzfs-docs/Getting%20Started/Arch%20Linux/Arch%20Linux%20Root%20on%20ZFS.html installation guide] on OpenZFS page.<br />
<br />
Boot loader can be verified with [[Secure Boot]] on UEFI-based systems.<br />
<br />
See also [[ZFS#Encryption in ZFS using dm-crypt]].<br />
<br />
== Simple encrypted root with TPM2 and Secure Boot ==<br />
<br />
This example covers a full system encryption with ''dm-crypt'' + LUKS, TPM2 and [[Secure Boot]] :<br />
Only the ESP remains unencrypted, with a [[Unified kernel image]] and [[Systemd-boot]] residing on it, both of which can be signed for use with [[Secure Boot]], providing a reasonably safe boot chain.<br />
<br />
Be aware though that as long as the system is [[Trusted Platform Module#Accessing PCR registers|not tempered with]], the root partition will automatically be decrypted upon boot, without a password prompt.<br />
<br />
In this example, partitions are created respecting [[Systemd#GPT partition automounting]], there is no need for an fstab or crypttab file.<br />
<br />
{{Text art|<nowiki><br />
+-----------------------+------------------------+-----------------------+<br />
| ESP | System partition |<br />
| unencrypted | encrypted |<br />
| | |<br />
| /efi | / |<br />
| | |<br />
| | /dev/mapper/root |<br />
| |------------------------------------------------|<br />
| /dev/sda1 | /dev/sda2 |<br />
+-----------------------+------------------------+-----------------------+<br />
</nowiki>}}<br />
<br />
Follow the [[Installation guide]] up to step [[Installation guide#Partition the disks|1.9 Partition the disks]]<br />
<br />
=== Partition the disks ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
Additionally, check that your disk reports the correct [[Advanced Format|sector size]].<br />
<br />
Make sure to create a [[GPT]] partition table. Then create the needed partitions for {{ic|/}} (e.g. {{ic|/dev/sda2}}) and {{ic|/efi}} ({{ic|/dev/sda1}}). See [[Partitioning]].<br />
<br />
* See [[EFI system partition#GPT partitioned disks]] to create the ESP with the appropriate partition GUID.<br />
* For the Luks (root) partition, you can use [[gdisk]] with partition type {{ic|8304}}, or [[fdisk]] with partition type {{ic|23 Linux root (x86-64)}} (if your architecture is x86-64). See [[GPT fdisk#Partition type]].<br />
<br />
=== Format the partitions ===<br />
==== Root partition ====<br />
<br />
The following commands create and mount the encrypted root partition, and make use of the TPM to store the encryption key. See [[dm-crypt/Encrypting a non-root file system#Partition]] (which, despite the title, ''can'' be applied to root partitions, as long as [[#Configuring mkinitcpio|mkinitcpio]] and the [[#Configuring the boot loader|boot loader]] are correctly configured), and [[Trusted Platform Module#systemd-cryptenroll]].<br />
<br />
If you want to use particular non-default encryption options (e.g. cipher, key length), or if you don't want to use TPM based decryption, see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|encryption options]] before executing the first command.<br />
<br />
We will create a luks volume with a key bound to the TPM [[Trusted Platform Module#Accessing PCR registers|PCR 7]] (default, [[Secure Boot]] state) and a recovery key to be used in case of any problem. The TPM will automatically release the key as long as the boot chain is not tempered with. See {{man|1|systemd-cryptenroll}}.<br />
<br />
Create the luks volume (you can simply use a blank password, as it will be wiped in the next step)<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
# systemd-cryptenroll /dev/sda2 --recovery-key<br />
# systemd-cryptenroll /dev/sda2 --wipe-slot=empty --tpm2-device=auto<br />
# cryptsetup open /dev/sda2 root<br />
# mkfs.ext4 /dev/mapper/root<br />
<br />
==== ESP ====<br />
<br />
See [[EFI system partition#Format the partition]].<br />
<br />
=== Mount the file systems ===<br />
<br />
At [[Installation guide#Mount the file systems]] you will have to mount the mapped device, not the actual partitions, i.e.<br />
<br />
# mount /dev/mapper/root /mnt<br />
# mount --mkdir /dev/sda1 /mnt/efi<br />
<br />
Continue the installation process until [[Installation guide#Initramfs]]. You can skip [[Installation guide#Fstab]].<br />
<br />
=== Initramfs ===<br />
<br />
To build a working systemd based initramfs, modify the {{ic|1=HOOKS=}} line in [[mkinitcpio.conf]] as follows:<br />
<br />
HOOKS=('''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' filesystems fsck)<br />
<br />
(if the default US keymap is fine for you, you can omit the {{ic|keymap}} hook)<br />
<br />
Next, see [[Unified kernel image#mkinitpcio]] to configure mkinitcpio for [[Unified kernel image]]s.<br />
<br />
Do not [[regenerate the initramfs]] yet, as the EFI path {{ic|/efi/EFI/Linux/}} needs to be created by the boot loader installer first.<br />
<br />
=== Boot loader ===<br />
<br />
Install [[systemd-boot]] with<br />
<br />
# bootctl install<br />
<br />
The [[Unified kernel image]] generated by mkinitcpio will be automatically recognized and does not need an entry in {{ic|/efi/loader/entries}}<br />
<br />
See [[Systemd-boot#Updating the EFI boot manager]] and [[Systemd-boot#Loader configuration]] for further configuration.<br />
<br />
=== Finalizing the installation ===<br />
<br />
First, [[Regenerate the initramfs]], and make sure the image generation is successful.<br />
<br />
Make sure you did not forget to [[Installation guide#Root password|set a root password]], reboot to [[Installation guide#Reboot|reboot]] to finish the installation.<br />
<br />
=== Secure Boot ===<br />
<br />
You can now sign the boot loader executables and the EFI binary, in order to enable [[Secure Boot]]. For a quick and easy way, see [[Unified Extensible Firmware Interface/Secure Boot#sbctl]]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Dm-crypt/Encrypting_an_entire_system&diff=757691Dm-crypt/Encrypting an entire system2022-11-20T21:25:37Z<p>Wooptoo: Added man page for sd-encrypt hook</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Data-at-rest encryption]]<br />
[[Category:Installation process]]<br />
[[de:Systemverschlüsselung mit dm-crypt]]<br />
[[es:Dm-crypt (Español)/Encrypting an entire system]]<br />
[[ja:Dm-crypt/システム全体の暗号化]]<br />
[[pl:Dm-crypt (Polski)/Encrypting an entire system]]<br />
[[pt:Dm-crypt (Português)/Encrypting an entire system]]<br />
The following are examples of common scenarios of full system encryption with ''dm-crypt''. They explain all the adaptations that need to be done to the normal [[Installation guide|installation procedure]]. All the necessary tools are on the [https://archlinux.org/download/ installation image].<br />
<br />
If you want to encrypt an existing unencrypted file system, see [[dm-crypt/Device encryption#Encrypt an existing unencrypted file system]].<br />
<br />
== Overview ==<br />
<br />
Securing a root filesystem is where ''dm-crypt'' excels, feature and performance-wise. Unlike selectively encrypting non-root filesystems, an encrypted root filesystem can conceal information such as which programs are installed, the usernames of all user accounts, and common data-leakage vectors such as [[mlocate]] and {{ic|/var/log/}}. Furthermore, an encrypted root filesystem makes tampering with the system far more difficult, as everything except the [[boot loader]] and (usually) the kernel is encrypted.<br />
<br />
All scenarios illustrated in the following share these advantages, other pros and cons differentiating them are summarized below:<br />
<br />
{| class="wikitable"<br />
! Scenarios<br />
! Advantages<br />
! Disadvantages<br />
|----------------------------------------------------------<br />
| [[#LUKS on a partition]]<br />
shows a basic and straightforward set-up for a fully LUKS encrypted root.<br />
|<br />
* Simple partitioning and setup<br />
* On a GPT partitioned disk, [[systemd#GPT partition automounting|systemd can auto-mount]] the root partition.<br />
|<br />
* Inflexible; disk-space to be encrypted has to be pre-allocated<br />
|----------------------------------------------------------<br />
| [[#LVM on LUKS]]<br />
achieves partitioning flexibility by using LVM inside a single LUKS encrypted partition.<br />
|<br />
* Simple partitioning with knowledge of LVM<br />
* Only one key required to unlock all volumes (e.g. easy resume-from-disk setup)<br />
* Volume layout not visible when locked<br />
* Easiest method to allow [[dm-crypt/Swap encryption#With suspend-to-disk support|suspension to disk]]<br />
|<br />
* LVM adds an additional mapping layer and hook<br />
* Less useful, if a singular volume should receive a separate key<br />
|----------------------------------------------------------<br />
| [[#LUKS on LVM]]<br />
uses dm-crypt only after the LVM is setup.<br />
|<br />
* LVM can be used to have encrypted volumes span multiple disks<br />
* Easy mix of un-/encrypted volume groups<br />
|<br />
* Complex; changing volumes requires changing encryption mappers too<br />
* Volumes require individual keys<br />
* LVM layout is visible when locked<br />
* Slower boot time; each encrypted LV must be unlocked seperately<br />
|----------------------------------------------------------<br />
| [[#LUKS on software RAID]]<br />
uses dm-crypt only after RAID is setup.<br />
|<br />
* Analogous to LUKS on LVM<br />
|<br />
* Analogous to LUKS on LVM<br />
|----------------------------------------------------------<br />
| [[#Plain dm-crypt]]<br />
uses dm-crypt plain mode, i.e. without a LUKS header and its options for multiple keys. <br>This scenario also employs USB devices for {{ic|/boot}} and key storage, which may be applied to the other scenarios.<br />
|<br />
* Data resilience for cases where a LUKS header may be damaged<br />
* Allows [[Wikipedia:Disk encryption#Full disk encryption|Full Disk Encryption]]<br />
* Helps addressing [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)|problems]] with SSDs<br />
|<br />
* High care to all encryption parameters is required<br />
* Single encryption key and no option to change it<br />
|----------------------------------------------------------<br />
| [[#Encrypted boot partition (GRUB)]]<br />
shows how to encrypt the boot partition using the GRUB bootloader. <br> This scenario also employs an EFI system partition, which may be applied to the other scenarios.<br />
|<br />
* Same advantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* Less data is left unencrypted, i.e. the boot loader and the EFI system partition, if present<br />
|<br />
* Same disadvantages as the scenario the installation is based on (LVM on LUKS for this particular example)<br />
* More complicated configuration<br />
* Not supported by other boot loaders<br />
|----------------------------------------------------------<br />
| [[#Btrfs subvolumes with swap]]<br />
shows how to encrypt a [[Btrfs]] system, including the {{ic|/boot}} directory, also adding a partition for swap, on UEFI hardware.<br />
|<br />
* Similar advantages as [[#Encrypted boot partition (GRUB)]]<br />
* Availability of Btrfs' features<br />
|<br />
* Similar disadvantages as [[#Encrypted boot partition (GRUB)]]<br />
|----------------------------------------------------------<br />
| [[#Root on ZFS]]<br />
|<br />
|<br />
|}<br />
<br />
While all above scenarios provide much greater protection from outside threats than encrypted secondary filesystems, they also share a common disadvantage: any user in possession of the encryption key is able to decrypt the entire drive, and therefore can access other users' data. If that is of concern, it is possible to use a combination of block device and stacked filesystem encryption and reap the advantages of both. See [[Data-at-rest encryption]] to plan ahead.<br />
<br />
See [[dm-crypt/Drive preparation#Partitioning]] for a general overview of the partitioning strategies used in the scenarios.<br />
<br />
Another area to consider is whether to set up an encrypted swap partition and what kind. See [[dm-crypt/Swap encryption]] for alternatives.<br />
<br />
If you anticipate to protect the system's data not only against physical theft, but also have a requirement of precautions against logical tampering, see [[dm-crypt/Specialties#Securing the unencrypted boot partition]] for further possibilities after following one of the scenarios.<br />
<br />
For [[solid state drive]]s you might want to consider enabling TRIM support, but be warned, there are potential security implications. See [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]] for more information.<br />
<br />
{{Warning|<br />
* In any scenario, never use file system repair software such as [[fsck]] directly on an encrypted volume, or it will destroy any means to recover the key used to decrypt your files. Such tools must be used on the decrypted (opened) device instead.<br />
* For the LUKS2 format:<br />
** 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 />
** The LUKS2 format has a high RAM usage per design, defaulting to 1GB per encrypted mapper. Machines with low RAM and/or multiple LUKS2 partitions unlocked in parallel may error on boot. See the {{ic|--pbkdf-memory}} option to control memory usage.[https://gitlab.com/cryptsetup/cryptsetup/issues/372]<br />
}}<br />
<br />
== LUKS on a partition ==<br />
<br />
This example covers a full system encryption with ''dm-crypt'' + LUKS in a simple partition layout:<br />
<br />
{{Text art|<nowiki><br />
+-----------------------+------------------------+-----------------------+<br />
| Boot partition | LUKS2 encrypted system | Optional free space |<br />
| | partition | for additional |<br />
| | | partitions to be set |<br />
| /boot | / | up later |<br />
| | | |<br />
| | /dev/mapper/root | |<br />
| |------------------------| |<br />
| /dev/sda1 | /dev/sda2 | |<br />
+-----------------------+------------------------+-----------------------+<br />
</nowiki>}}<br />
<br />
The first steps can be performed directly after booting the Arch Linux install image.<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
Then create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda2}}) and {{ic|/boot}} ({{ic|/dev/sda1}}). See [[Partitioning]].<br />
<br />
=== Preparing non-boot partitions ===<br />
<br />
The following commands create and mount the encrypted root partition. They correspond to the procedure described in detail in [[dm-crypt/Encrypting a non-root file system#Partition]] (which, despite the title, ''can'' be applied to root partitions, as long as [[#Configuring mkinitcpio|mkinitcpio]] and the [[#Configuring the boot loader|boot loader]] are correctly configured).<br />
If you want to use particular non-default encryption options (e.g. cipher, key length), see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|encryption options]] before executing the first command. For information on changing the default sector size, see [[dm-crypt/Device encryption#Sector size]].<br />
<br />
# cryptsetup -y -v luksFormat /dev/sda2<br />
# cryptsetup open /dev/sda2 root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
Check the mapping works as intended:<br />
<br />
# umount /mnt<br />
# cryptsetup close root<br />
# cryptsetup open /dev/sda2 root<br />
# mount /dev/mapper/root /mnt<br />
<br />
If you created separate partitions (e.g. {{ic|/home}}), these steps have to be adapted and repeated for all of them, ''except'' for {{ic|/boot}}. See [[dm-crypt/Encrypting a non-root file system#Automated unlocking and mounting]] on how to handle additional partitions at boot.<br />
<br />
Note that each block device requires its own passphrase. This may be inconvenient, because it results in a separate passphrase to be input during boot. An alternative is to use a keyfile stored in the system partition to unlock the separate partition via {{ic|crypttab}}. See [[dm-crypt/Device encryption#Using LUKS to format partitions with a keyfile]] for instructions.<br />
<br />
=== Preparing the boot partition ===<br />
<br />
What you do have to setup is a non-encrypted {{ic|/boot}} partition, which is needed for an encrypted root. For an ordinary boot partition on BIOS systems, for example, execute:<br />
<br />
# mkfs.ext4 /dev/sda1<br />
<br />
or for an [[EFI system partition]] on UEFI systems:<br />
<br />
# mkfs.fat -F32 /dev/sda1<br />
<br />
Afterwards create the directory for the mountpoint and mount the partition:<br />
<br />
# mount --mkdir /dev/sda1 /mnt/boot<br />
<br />
=== Mounting the devices ===<br />
<br />
At [[Installation guide#Mount the file systems]] you will have to mount the mapped devices, not the actual partitions. Of course {{ic|/boot}}, which is not encrypted, will still have to be mounted directly.<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Add the {{ic|keyboard}}, {{ic|keymap}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]. If the default US keymap is fine for you, you can omit the {{ic|keymap}} hook.<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following [[kernel parameters]] need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':root root=/dev/mapper/root<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=root root=/dev/mapper/root<br />
<br />
{{ic|rd.luks.name}} is honored only in the initrd, while {{ic|luks.name}} is honored by both the main system and the initrd.<br />
<br />
Read the [https://www.freedesktop.org/software/systemd/man/systemd-cryptsetup-generator.html systemd-cryptsetup-generator] manual page for more boot loader options. <br />
<br />
Also see [[dm-crypt/System configuration#Kernel parameters]] for more details.<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of the LUKS superblock, in this case {{ic|/dev/sda2}}. See [[Persistent block device naming]] for details.<br />
<br />
== LVM on LUKS ==<br />
<br />
The straightforward method is to set up [[LVM]] on top of the encrypted partition instead of the other way round. Technically the LVM is setup inside one big encrypted block device. Hence, the LVM is not visible until the block device is unlocked and the underlying volume structure is scanned and mounted during boot.<br />
<br />
The disk layout in this example is:<br />
<br />
{{Text art|<nowiki><br />
+-----------------------------------------------------------------------+ +----------------+<br />
| Logical volume 1 | Logical volume 2 | Logical volume 3 | | Boot partition |<br />
| | | | | |<br />
| [SWAP] | / | /home | | /boot |<br />
| | | | | |<br />
| /dev/MyVolGroup/swap | /dev/MyVolGroup/root | /dev/MyVolGroup/home | | |<br />
|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _| | (may be on |<br />
| | | other device) |<br />
| LUKS2 encrypted partition | | |<br />
| /dev/sda1 | | /dev/sdb1 |<br />
+-----------------------------------------------------------------------+ +----------------+<br />
</nowiki>}}<br />
<br />
{{Note|While using the {{ic|encrypt}} hook this method does not allow you to span the logical volumes over multiple disks; either use the [[sd-encrypt]] or see [[dm-crypt/Specialties#Modifying the encrypt hook for multiple partitions]].}}<br />
<br />
{{Tip|Two variants of this setup:<br />
* Instructions at [[dm-crypt/Specialties#Encrypted system using a detached LUKS header]] use this setup with a detached LUKS header on a USB device to achieve a two factor authentication with it.<br />
* Instructions at [[dm-crypt/Specialties#Encrypted /boot and a detached LUKS header on USB]] use this setup with a detached LUKS header, encrypted {{ic|/boot}} partition, and encrypted keyfile all on a USB device.<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
{{Tip|When using the [[GRUB]] boot loader for BIOS booting from a [[GPT]] disk, create a [[BIOS boot partition]].}}<br />
<br />
[[Installation guide#Partition the disks|Create a partition]] to be mounted at {{ic|/boot}} with a size of 200 MiB or more.<br />
<br />
{{Tip|UEFI systems can use the [[EFI system partition]] for {{ic|/boot}}.}}<br />
<br />
Create a partition which will later contain the encrypted container.<br />
<br />
Create the LUKS encrypted container at the "system" partition. Enter the chosen password twice.<br />
<br />
# cryptsetup luksFormat /dev/sda1<br />
<br />
For more information about the available cryptsetup options see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|LUKS encryption options]] prior to above command.<br />
<br />
Open the container:<br />
<br />
# cryptsetup open /dev/sda1 cryptlvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/cryptlvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
Create a physical volume on top of the opened LUKS container:<br />
<br />
# pvcreate /dev/mapper/cryptlvm<br />
<br />
Create a volume group (in this example named {{ic|MyVolGroup}}, but it can be whatever you want) and add the previously created physical volume to it:<br />
<br />
# vgcreate MyVolGroup /dev/mapper/cryptlvm<br />
<br />
Create all your logical volumes on the volume group:<br />
<br />
{{Tip|If a logical volume will be formatted with [[ext4]], leave at least 256 MiB free space in the volume group to allow using {{man|8|e2scrub}}.}}<br />
<br />
# lvcreate -L 8G MyVolGroup -n swap<br />
# lvcreate -L 32G MyVolGroup -n root<br />
# lvcreate -l 100%FREE MyVolGroup -n home<br />
<br />
Format your filesystems on each logical volume:<br />
<br />
# mkfs.ext4 /dev/MyVolGroup/root<br />
# mkfs.ext4 /dev/MyVolGroup/home<br />
# mkswap /dev/MyVolGroup/swap<br />
<br />
Mount your filesystems:<br />
<br />
# mount /dev/MyVolGroup/root /mnt<br />
# mount --mkdir /dev/MyVolGroup/home /mnt/home<br />
# swapon /dev/MyVolGroup/swap<br />
<br />
=== Preparing the boot partition ===<br />
<br />
The bootloader loads the kernel, [[initramfs]], and its own configuration files from the {{ic|/boot}} directory. Any filesystem on a disk that can be read by the bootloader is eligible.<br />
<br />
Create a [[filesystem]] on the partition intended for {{ic|/boot}}:<br />
<br />
# mkfs.ext4 /dev/sdb1<br />
<br />
{{Tip|When opting to keep {{ic|/boot}} on an [[EFI system partition]] the recommended formatting is<br />
<br />
# mkfs.fat -F32 /dev/sdb1<br />
<br />
}}<br />
<br />
Mount the partition to {{ic|/mnt/boot}}:<br />
<br />
# mount --mkdir /dev/sdb1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following kernel parameter needs to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':cryptlvm root=/dev/MyVolGroup/root<br />
<br />
If using the [[sd-encrypt]] hook, the following needs to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=cryptlvm root=/dev/MyVolGroup/root<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/sda1}}. See [[Persistent block device naming]] for details.<br />
<br />
If using [[dracut]], you may need a more extensive list of parameters, try:<br />
<br />
kernel_cmdline="rd.luks.uuid=luks-''deviceUUID'' rd.lvm.lv=''MyVolGroup''/root rd.lvm.lv=''MyVolGroup''/swap root=/dev/mapper/''MyVolGroup''-root rootfstype=ext4 rootflags=rw,relatime"<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] for details.<br />
<br />
== LUKS on LVM ==<br />
<br />
To use encryption on top of [[LVM]], the LVM volumes are set up first and then used as the base for the encrypted partitions. This way, a mixture of encrypted and non-encrypted volumes/partitions is possible as well.<br />
{{tip|Unlike [[#LVM on LUKS]], this method allows normally spanning the logical volumes over multiple disks. }}<br />
<br />
The following short example creates a LUKS on LVM setup and mixes in the use of a key-file for the /home partition and temporary crypt volumes for {{ic|/tmp}} and {{ic|/swap}}. The latter is considered desirable from a security perspective, because no potentially sensitive temporary data survives the reboot, when the encryption is re-initialised. If you are experienced with LVM, you will be able to ignore/replace LVM and other specifics according to your plan.<br />
<br />
If you want to span a logical volume over multiple disks that have already been set up, or expand the logical volume for {{ic|/home}} (or any other volume), a procedure to do so is described in [[dm-crypt/Specialties#Expanding LVM on multiple disks]]. It is important to note that the LUKS encrypted container has to be resized as well.<br />
<br />
{{Expansion|The intro of this scenario needs some adjustment now that a comparison has been added to [[#Overview]]. A suggested structure is to make it similar to the [[#LUKS on a partition]] intro.}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Partitioning scheme:<br />
<br />
{{Text art|<nowiki><br />
+----------------+-------------------------------------------------------------------------------------------------+<br />
| Boot partition | dm-crypt plain encrypted volume | LUKS2 encrypted volume | LUKS2 encrypted volume |<br />
| | | | |<br />
| /boot | [SWAP] | / | /home |<br />
| | | | |<br />
| | /dev/mapper/swap | /dev/mapper/root | /dev/mapper/home |<br />
| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
| | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | /dev/MyVolGroup/cryptswap | /dev/MyVolGroup/cryptroot | /dev/MyVolGroup/crypthome |<br />
| |_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _|<br />
| | |<br />
| /dev/sda1 | /dev/sda2 |<br />
+----------------+-------------------------------------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
Randomise {{ic|/dev/sda2}} according to [[dm-crypt/Drive preparation#dm-crypt wipe on an empty disk or partition]].<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
# pvcreate /dev/sda2<br />
# vgcreate MyVolGroup /dev/sda2<br />
# lvcreate -L 32G -n cryptroot MyVolGroup<br />
# lvcreate -L 500M -n cryptswap MyVolGroup<br />
# lvcreate -L 500M -n crypttmp MyVolGroup<br />
# lvcreate -l 100%FREE -n crypthome MyVolGroup<br />
<br />
# cryptsetup luksFormat /dev/MyVolGroup/cryptroot<br />
# cryptsetup open /dev/MyVolGroup/cryptroot root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
More information about the encryption options can be found in [[dm-crypt/Device encryption#Encryption options for LUKS mode]].<br />
Note that {{ic|/home}} will be encrypted in [[#Encrypting logical volume /home]].<br />
<br />
{{Tip|If you ever have to access the encrypted root from the Arch-ISO, the above {{ic|open}} action will allow you to after the [[LVM#Logical Volumes do not show up|LVM shows up]].}}<br />
<br />
=== Preparing the boot partition ===<br />
<br />
# dd if=/dev/zero of=/dev/sda1 bs=1M status=progress<br />
# mkfs.ext4 /dev/sda1<br />
# mount --mkdir /dev/sda1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|lvm2}} and {{ic|encrypt}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''lvm2''' '''encrypt''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to unlock the encrypted root partition at boot, the following [[kernel parameters]] need to be set by the boot loader:<br />
<br />
cryptdevice=UUID=''device-UUID'':root root=/dev/mapper/root<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
rd.luks.name=''device-UUID''=root root=/dev/mapper/root<br />
<br />
The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/MyVolGroup/cryptroot}}. See [[Persistent block device naming]] for details.<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] for details.<br />
<br />
=== Configuring fstab and crypttab ===<br />
<br />
Both [[crypttab]] and [[fstab]] entries are required to both unlock the device and mount the filesystems, respectively. The following lines will re-encrypt the temporary filesystems on each reboot:<br />
<br />
{{hc|/etc/crypttab|2=<br />
swap /dev/MyVolGroup/cryptswap /dev/urandom swap,cipher=aes-xts-plain64,size=256<br />
tmp /dev/MyVolGroup/crypttmp /dev/urandom tmp,cipher=aes-xts-plain64,size=256<br />
}}<br />
<br />
{{hc|/etc/fstab|<br />
/dev/mapper/root / ext4 defaults 0 1<br />
/dev/sda1 /boot ext4 defaults 0 2<br />
/dev/mapper/tmp /tmp tmpfs defaults 0 0<br />
/dev/mapper/swap none swap sw 0 0<br />
}}<br />
<br />
=== Encrypting logical volume /home ===<br />
<br />
Since this scenario uses LVM as the primary and dm-crypt as secondary mapper, each encrypted logical volume requires its own encryption. Yet, unlike the temporary filesystems configured with volatile encryption above, the logical volume for {{ic|/home}} should of course be persistent. The following assumes you have rebooted into the installed system, otherwise you have to adjust paths.<br />
To save on entering a second passphrase at boot, a [[dm-crypt/Device encryption#Keyfiles|keyfile]] is created:<br />
<br />
# mkdir -m 700 /etc/luks-keys<br />
# dd if=/dev/random of=/etc/luks-keys/home bs=1 count=256 status=progress<br />
<br />
The logical volume is encrypted with it:<br />
<br />
# cryptsetup luksFormat -v /dev/MyVolGroup/crypthome /etc/luks-keys/home<br />
# cryptsetup -d /etc/luks-keys/home open /dev/MyVolGroup/crypthome home<br />
# mkfs.ext4 /dev/mapper/home<br />
# mount /dev/mapper/home /home<br />
<br />
The encrypted mount is configured in both [[crypttab]] and [[fstab]]:<br />
<br />
{{hc|/etc/crypttab|<br />
home /dev/MyVolGroup/crypthome /etc/luks-keys/home<br />
}}<br />
<br />
{{hc|/etc/fstab|<br />
/dev/mapper/home /home ext4 defaults 0 2<br />
}}<br />
<br />
== LUKS on software RAID ==<br />
<br />
This example is based on a real-world setup for a workstation class laptop equipped with two SSDs of equal size, and an additional HDD for bulk storage. The end result is LUKS1 based full disk encryption (including {{ic|/boot}}) for all drives, with the SSDs in a [[RAID|RAID0]] array, and keyfiles used to unlock all encryption after [[GRUB]] is given a correct passphrase at boot.<br />
<br />
This setup utilizes a very simplistic partitioning scheme, with all the available RAID storage being mounted at {{ic|/}} (no separate {{ic|/boot}} partition), and the decrypted HDD being mounted at {{ic|/data}}.<br />
<br />
Please note that regular [[System backup|backups]] are very important in this setup. If either of the SSDs fail, the data contained in the RAID array will be practically impossible to recover. You may wish to select a different [[RAID#Standard RAID levels|RAID level]] if fault tolerance is important to you. <br />
<br />
The encryption is not deniable in this setup.<br />
<br />
For the sake of the instructions below, the following block devices are used:<br />
<br />
/dev/sda = first SSD<br />
/dev/sdb = second SSD<br />
/dev/sdc = HDD<br />
<br />
{{Text art|<nowiki><br />
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+<br />
| BIOS boot partition | EFI system partition | LUKS1 encrypted volume | | BIOS boot partition | EFI system partition | LUKS1 encrypted volume | | LUKS2 encrypted volume |<br />
| | | | | | | | | |<br />
| | /efi | / | | | /efi | / | | /data |<br />
| | | | | | | | | |<br />
| | | /dev/mapper/root | | | | /dev/mapper/root | | |<br />
| +---------------------------+---------------------------+ | +---------------------------+---------------------------+ | |<br />
| | RAID1 array (part 1 of 2) | RAID0 array (part 1 of 2) | | | RAID1 array (part 2 of 2) | RAID0 array (part 2 of 2) | | |<br />
| | | | | | | | | |<br />
| | /dev/md/ESP | /dev/md/root | | | /dev/md/ESP | /dev/md/root | | /dev/mapper/data |<br />
| +---------------------------+---------------------------+ | +---------------------------+---------------------------+ +---------------------------+<br />
| /dev/sda1 | /dev/sda2 | /dev/sda3 | | /dev/sdb1 | /dev/sdb2 | /dev/sdb3 | | /dev/sdc1 |<br />
+---------------------+---------------------------+---------------------------+ +---------------------+---------------------------+---------------------------+ +---------------------------+<br />
</nowiki>}}<br />
<br />
Be sure to substitute them with the appropriate device designations for your setup, as they may be different.<br />
<br />
=== Preparing the disks ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
For [[GRUB#BIOS systems|BIOS systems]] with GPT, create a [[BIOS boot partition]] with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition.<br />
<br />
For [[GRUB#UEFI systems|UEFI systems]] create an [[EFI system partition]] with an appropriate size, it will later be mounted at {{ic|/efi}}.<br />
<br />
In the remaining space on the drive create a partition ({{ic|/dev/sda3}} in this example) for "Linux RAID". Choose partition type ID {{ic|fd}} for MBR or partition type GUID {{ic|A19D880F-05FC-4D3B-A006-743F0F84911E}} for GPT.<br />
<br />
Once partitions have been created on {{ic|/dev/sda}}, the following commands can be used to clone them to {{ic|/dev/sdb}}.<br />
<br />
# sfdisk -d /dev/sda > sda.dump<br />
# sfdisk /dev/sdb < sda.dump<br />
<br />
The HDD is prepared with a single Linux partition covering the whole drive at {{ic|/dev/sdc1}}.<br />
<br />
=== Building the RAID array ===<br />
<br />
Create the RAID array for the SSDs.<br />
<br />
{{Note|<br />
* All parts of an EFI system partition RAID array must be individually usable, that means that ESP can only placed in a RAID1 array.<br />
* The RAID superblock must be placed at the end of the EFI system partition using {{ic|1=--metadata=1.0}}, otherwise the firmware will not be able to access the partition.<br />
}}<br />
<br />
# mdadm --create --verbose --level=1 --metadata=1.0 --raid-devices=2 /dev/md/ESP /dev/sda2 /dev/sdb2<br />
<br />
This example utilizes RAID0 for root, you may wish to substitute a different level based on your preferences or requirements.<br />
<br />
# mdadm --create --verbose --level=0 --metadata=1.2 --raid-devices=2 /dev/md/root /dev/sda3 /dev/sdb3<br />
<br />
=== Preparing the block devices ===<br />
<br />
As explained in [[dm-crypt/Drive preparation]], the devices are wiped with random data utilizing {{ic|/dev/zero}} and a crypt device with a random key. Alternatively, you could use {{ic|dd}} with {{ic|/dev/random}} or {{ic|/dev/urandom}}, though it will be much slower.<br />
<br />
# cryptsetup open --type plain /dev/md/root container --key-file /dev/random<br />
# dd if=/dev/zero of=/dev/mapper/container bs=1M status=progress<br />
# cryptsetup close container<br />
<br />
And repeat above for the HDD ({{ic|/dev/sdc1}} in this example).<br />
<br />
Set up encryption for {{ic|/dev/md/root}}:<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 />
# cryptsetup -y -v luksFormat --type luks1 /dev/md/root<br />
# cryptsetup open /dev/md/root root<br />
# mkfs.ext4 /dev/mapper/root<br />
# mount /dev/mapper/root /mnt<br />
<br />
And repeat for the HDD:<br />
<br />
# cryptsetup -y -v luksFormat /dev/sdc1<br />
# cryptsetup open /dev/sdc1 data<br />
# mkfs.ext4 /dev/mapper/data<br />
# mount --mkdir /dev/mapper/data /mnt/data<br />
<br />
For UEFI systems, set up the EFI system partition:<br />
<br />
# mkfs.fat -F32 /dev/md/ESP<br />
# mount --mkdir /dev/md/ESP /mnt/efi<br />
<br />
=== Configuring GRUB ===<br />
<br />
Configure [[GRUB]] for the LUKS1 encrypted system by editing {{ic|/etc/default/grub}} with the following:<br />
<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/md/root:root"<br />
GRUB_ENABLE_CRYPTODISK=y<br />
<br />
{{Merge|GRUB#Troubleshooting|GRUB troubleshooting issues belong in the [[GRUB]] page. It should be moved there and simply linked from this section.}}<br />
<br />
If you have a USB keyboard on a newer system either enable legacy USB support in firmware or add the following to {{ic|/etc/default/grub}}:<br />
<br />
GRUB_TERMINAL_INPUT="usb_keyboard"<br />
GRUB_PRELOAD_MODULES="usb usb_keyboard ohci uhci ehci"<br />
<br />
Otherwise you may not be able to use your keyboard at the LUKS prompt.<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] and [[GRUB#Encrypted /boot]] for details.<br />
<br />
Complete the GRUB install to both SSDs (in reality, installing only to {{ic|/dev/sda}} will work).<br />
<br />
# grub-install --target=i386-pc /dev/sda<br />
# grub-install --target=i386-pc /dev/sdb<br />
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Creating the keyfiles ===<br />
<br />
The next steps save you from entering your passphrase twice when you boot the system (once so GRUB can unlock the LUKS1 device, and second time once the initramfs assumes control of the system). This is done by creating a [[dm-crypt/Device encryption#Keyfiles|keyfile]] for the encryption and adding it to the initramfs image to allow the encrypt hook to unlock the root device. See [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] for details.<br />
<br />
* Create the [[dm-crypt/Device encryption#Keyfiles|keyfile]] and add the key to {{ic|/dev/md/root}}.<br />
* Create another keyfile for the HDD ({{ic|/dev/sdc1}}) so it can also be unlocked at boot. For convenience, leave the passphrase created above in place as this can make recovery easier if you ever need it. Edit {{ic|/etc/crypttab}} to decrypt the HDD at boot. See [[Dm-crypt/System configuration#Unlocking with a keyfile]].<br />
<br />
=== Configuring the system ===<br />
<br />
Edit [[fstab]] to mount the root and data block devices and the ESP:<br />
<br />
/dev/mapper/root / ext4 rw,noatime 0 1<br />
/dev/mapper/data /data ext4 defaults 0 2<br />
/dev/md/ESP /efi vfat rw,relatime,codepage=437,iocharset=iso8859-1,shortname=mixed,utf8,tz=UTC,errors=remount-ro 0 2<br />
<br />
Save the RAID configuration:<br />
<br />
# mdadm --detail --scan >> /etc/mdadm.conf<br />
<br />
Edit [[mkinitcpio.conf]] to include your keyfile and add the proper hooks:<br />
<br />
FILES=(/crypto_keyfile.bin)<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''mdadm_udev''' '''encrypt''' filesystems fsck)<br />
<br />
See [[dm-crypt/System configuration#mkinitcpio]] for details.<br />
<br />
== Plain dm-crypt ==<br />
<br />
Contrary to LUKS, dm-crypt ''plain'' mode does not require a header on the encrypted device: this scenario exploits this feature to set up a system on an unpartitioned, encrypted disk that will be indistinguishable from a disk filled with random data, which could allow [[Wikipedia:Deniable encryption|deniable encryption]]. See also [[wikipedia:Disk encryption#Full disk encryption]].<br />
<br />
Note that if full-disk encryption is not required, the methods using LUKS described in the sections above are better options for both system encryption and encrypted partitions. LUKS features like key management with multiple passphrases/key-files or re-encrypting a device in-place are unavailable with ''plain'' mode.<br />
<br />
''Plain'' dm-crypt encryption can be more resilient to damage than LUKS, because it does not rely on an encryption master-key which can be a single-point of failure if damaged. However, using ''plain'' mode also requires more manual configuration of encryption options to achieve the same cryptographic strength. See also [[Data-at-rest encryption#Cryptographic metadata]]. Using ''plain'' mode could also be considered if concerned with the problems explained in [[dm-crypt/Specialties#Discard/TRIM support for solid state drives (SSD)]].<br />
<br />
{{Tip|If headerless encryption is your goal but you are unsure about the lack of key-derivation with ''plain'' mode, then two alternatives are:<br />
* [[dm-crypt/Specialties#Encrypted system using a detached LUKS header|dm-crypt LUKS mode with a detached header]] by using the ''cryptsetup'' {{ic|--header}} option. It cannot be used with the standard ''encrypt'' hook, but the hook may be modified.<br />
* [[tcplay]] which offers headerless encryption but with the PBKDF2 function.<br />
}}<br />
<br />
The scenario uses two USB sticks:<br />
<br />
* one for the boot device, which also allows storing the options required to open/unlock the plain encrypted device in the boot loader configuration, since typing them on each boot would be error prone;<br />
* another for the encryption key file, assuming it stored as raw bits so that to the eyes of an unaware attacker who might get the usbkey the encryption key will appear as random data instead of being visible as a normal file. See also [[Wikipedia:Security through obscurity]], follow [[dm-crypt/Device encryption#Keyfiles]] to prepare the keyfile.<br />
<br />
The disk layout is:<br />
<br />
{{Text art|<nowiki><br />
+----------------------+----------------------+----------------------+ +----------------+ +----------------+<br />
| Logical volume 1 | Logical volume 2 | Logical volume 3 | | Boot device | | Encryption key |<br />
| | | | | | | file storage |<br />
| / | [SWAP] | /home | | /boot | | (unpartitioned |<br />
| | | | | | | in example) |<br />
| /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home | | /dev/sdb1 | | /dev/sdc |<br />
|----------------------+----------------------+----------------------| |----------------| |----------------|<br />
| disk drive /dev/sda encrypted using plain mode and LVM | | USB stick 1 | | USB stick 2 |<br />
+--------------------------------------------------------------------+ +----------------+ +----------------+<br />
</nowiki>}}<br />
<br />
{{Tip|<br />
* It is also possible to use a single USB key physical device:<br />
** By putting the key on another partition (/dev/sdb2) of the USB storage device (/dev/sdb).<br />
** By copying the keyfile to the initramfs directly. An example keyfile {{ic|/etc/keyfile}} gets copied to the initramfs image by setting {{ic|1=FILES=(/etc/keyfile)}} in {{ic|/etc/mkinitcpio.conf}}. The way to instruct the {{ic|encrypt}} hook to read the keyfile in the initramfs image is using {{ic|rootfs:}} prefix before the filename, e.g. {{ic|1=cryptkey=rootfs:/etc/keyfile}}.<br />
* Another option is using a passphrase with good [[Security#Choosing secure passwords|entropy]].<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
It is vital that the mapped device is filled with random data. In particular this applies to the scenario use case we apply here.<br />
<br />
See [[dm-crypt/Drive preparation]] and [[dm-crypt/Drive preparation#dm-crypt specific methods]]<br />
<br />
=== Preparing the non-boot partitions ===<br />
<br />
See [[dm-crypt/Device encryption#Encryption options for plain mode]] for details.<br />
<br />
Using the device {{ic|/dev/sda}}, with the aes-xts cipher with a 512 bit key size and using a keyfile we have the following options for this scenario:<br />
<br />
# cryptsetup --cipher=aes-xts-plain64 --offset=0 --key-file=/dev/sdc --key-size=512 open --type plain /dev/sda cryptlvm<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, and key file details.<br />
<br />
We can now check a mapping entry has been made for {{ic|/dev/mapper/cryptlvm}}:<br />
<br />
# fdisk -l<br />
<br />
{{Tip|A simpler alternative to using LVM, advocated in the cryptsetup FAQ for cases where LVM is not necessary, is to just create a filesystem on the entirety of the mapped dm-crypt device.}} <br />
<br />
Next, we setup [[LVM]] logical volumes on the mapped device. See [[Install Arch Linux on LVM]] for further details:<br />
<br />
# pvcreate /dev/mapper/cryptlvm<br />
# vgcreate MyVolGroup /dev/mapper/cryptlvm<br />
# lvcreate -L 32G MyVolGroup -n root<br />
# lvcreate -L 10G MyVolGroup -n swap<br />
# lvcreate -l 100%FREE MyVolGroup -n home<br />
<br />
We format and mount them and activate swap. See [[File systems#Create a file system]] for further details:<br />
<br />
# mkfs.ext4 /dev/MyVolGroup/root<br />
# mkfs.ext4 /dev/MyVolGroup/home<br />
# mount /dev/MyVolGroup/root /mnt<br />
# mount --mkdir /dev/MyVolGroup/home /mnt/home<br />
# mkswap /dev/MyVolGroup/swap<br />
# swapon /dev/MyVolGroup/swap<br />
<br />
=== Preparing the boot partition ===<br />
<br />
The {{ic|/boot}} partition can be installed on the standard vfat partition of a USB stick, if required. But if manual partitioning is needed, then a small 200 MiB partition is all that is required. Create the partition using a [[Partitioning#Partitioning tools|partitioning tool]] of your choice.<br />
<br />
Create a [[filesystem]] on the partition intended for {{ic|/boot}}:<br />
<br />
# mkfs.fat -F32 /dev/sdb1<br />
# mount --mkdir /dev/sdb1 /mnt/boot<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base udev autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring the boot loader ===<br />
<br />
In order to boot the encrypted root partition, the following [[kernel parameters]] need to be set by the boot loader (note that 64 is the number of bytes in 512 bits):<br />
<br />
cryptdevice=/dev/disk/by-id/''disk-ID-of-sda'':cryptlvm cryptkey=/dev/disk/by-id/''disk-ID-of-sdc'':0:64 crypto=:aes-xts-plain64:512:0:<br />
<br />
The {{ic|''disk-ID-of-'''disk'''''}} refers to the id of the referenced disk. See [[Persistent block device naming]] for details.<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] for details and other parameters that you may need.<br />
<br />
{{Tip|If using GRUB, you can install it on the same USB as the {{ic|/boot}} partition with:<br />
<br />
# grub-install --recheck /dev/sdb<br />
<br />
}}<br />
<br />
=== Post-installation ===<br />
<br />
You may wish to remove the USB sticks after booting. Since the {{ic|/boot}} partition is not usually needed, the {{ic|noauto}} option can be added to the relevant line in {{ic|/etc/fstab}}:<br />
<br />
{{hc|/etc/fstab|<br />
# /dev/sdb1<br />
/dev/sdb1 /boot vfat '''noauto''',rw,noatime 0 2<br />
}}<br />
<br />
However, when an update to anything used in the initramfs, or a kernel, or the bootloader is required; the {{ic|/boot}} partition must be present and mounted. As the entry in {{ic|fstab}} already exists, it can be mounted simply with:<br />
<br />
# mount /boot<br />
<br />
== Encrypted boot partition (GRUB) ==<br />
<br />
This setup utilizes the same partition layout and configuration as the previous [[#LVM on LUKS]] section, with the difference that the [[GRUB]] boot loader is used since it is capable of booting from an LVM logical volume and a LUKS1-encrypted {{ic|/boot}}. See also [[GRUB#Encrypted /boot]].<br />
<br />
The disk layout in this example is:<br />
<br />
{{Text art|<nowiki><br />
+---------------------+----------------------+----------------------+----------------------+----------------------+<br />
| BIOS boot partition | EFI system partition | Logical volume 1 | Logical volume 2 | Logical volume 3 |<br />
| | | | | |<br />
| | /efi | / | [SWAP] | /home |<br />
| | | | | |<br />
| | | /dev/MyVolGroup/root | /dev/MyVolGroup/swap | /dev/MyVolGroup/home |<br />
| /dev/sda1 | /dev/sda2 |----------------------+----------------------+----------------------+<br />
| unencrypted | unencrypted | /dev/sda3 encrypted using LVM on LUKS1 |<br />
+---------------------+----------------------+--------------------------------------------------------------------+<br />
</nowiki>}}<br />
<br />
{{Tip|<br />
* All scenarios are intended as examples. It is, of course, possible to apply both of the two above distinct installation steps with the other scenarios as well. See also the variants linked in [[#LVM on LUKS]].<br />
* You can use {{ic|cryptboot}} script from {{AUR|cryptboot}} package for simplified encrypted boot management (mounting, unmounting, upgrading packages) and as a defense against [https://www.schneier.com/blog/archives/2009/10/evil_maid_attac.html Evil Maid] attacks with [[Secure Boot#Using your own keys|UEFI Secure Boot]]. For more information and limitations see [https://github.com/kmille/cryptboot cryptboot project] page.<br />
}}<br />
<br />
=== Preparing the disk ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
For [[GRUB#GUID Partition Table (GPT) specific instructions|BIOS/GPT systems]] create a [[BIOS boot partition]] with size of 1 MiB for GRUB to store the second stage of BIOS bootloader. Do not mount the partition. For BIOS/MBR systems this is not necessary.<br />
<br />
For [[GRUB#UEFI systems|UEFI systems]] create an [[EFI system partition]] with an appropriate size, it will later be mounted at {{ic|/efi}}.<br />
<br />
Create a partition of type {{ic|8309}}, which will later contain the encrypted container for the LVM.<br />
<br />
Create the LUKS encrypted container:<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 />
# cryptsetup luksFormat --type luks1 /dev/sda3<br />
<br />
For more information about the available cryptsetup options see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|LUKS encryption options]] prior to above command.<br />
<br />
Your partition layout should look similar to this:<br />
<br />
{{hc|# gdisk -l /dev/sda|<br />
...<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 4095 1024.0 KiB EF02 BIOS boot partition<br />
2 4096 1130495 550.0 MiB EF00 EFI System<br />
3 1130496 68239360 32.0 GiB 8309 Linux LUKS<br />
}}<br />
<br />
Open the container:<br />
<br />
# cryptsetup open /dev/sda3 cryptlvm<br />
<br />
The decrypted container is now available at {{ic|/dev/mapper/cryptlvm}}.<br />
<br />
=== Preparing the logical volumes ===<br />
<br />
The LVM logical volumes of this example follow the exact layout as the [[#LVM on LUKS]] scenario. Therefore, please follow [[#Preparing the logical volumes]] above and adjust as required.<br />
<br />
If you plan to boot in UEFI mode, create a mountpoint for the [[EFI system partition]] at {{ic|/efi}} for compatibility with {{ic|grub-install}} and mount it:<br />
<br />
# mount --mkdir /dev/sda2 /mnt/efi<br />
<br />
At this point, you should have the following partitions and logical volumes inside of {{ic|/mnt}}:<br />
<br />
{{hc|$ lsblk|<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 200G 0 disk<br />
├─sda1 8:1 0 1M 0 part<br />
├─sda2 8:2 0 550M 0 part /mnt/efi<br />
└─sda3 8:3 0 100G 0 part<br />
└─cryptlvm 254:0 0 100G 0 crypt<br />
├─MyVolGroup-swap 254:1 0 8G 0 lvm [SWAP]<br />
├─MyVolGroup-root 254:2 0 32G 0 lvm /mnt<br />
└─MyVolGroup-home 254:3 0 60G 0 lvm /mnt/home<br />
}}<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
Make sure the {{Pkg|lvm2}} package is [[install]]ed and add the {{ic|keyboard}}, {{ic|keymap}}, {{ic|encrypt}} and {{ic|lvm2}} hooks to [[mkinitcpio.conf]]:<br />
<br />
HOOKS=(base '''udev''' autodetect '''keyboard''' '''keymap''' consolefont modconf block '''encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
If using the [[sd-encrypt]] hook with the systemd-based initramfs, the following needs to be set instead:<br />
<br />
HOOKS=(base '''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' '''lvm2''' filesystems fsck)<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
=== Configuring GRUB ===<br />
<br />
Configure GRUB to allow booting from {{ic|/boot}} on a LUKS1 encrypted partition:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_ENABLE_CRYPTODISK=y<br />
}}<br />
<br />
Set the kernel parameters, so that the initramfs can unlock the encrypted root partition. Using the {{ic|encrypt}} hook:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="... cryptdevice=UUID=''device-UUID'':cryptlvm ..."<br />
}}<br />
<br />
If using the [[sd-encrypt]] hook, the following need to be set instead:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="... rd.luks.name=''device-UUID''=cryptlvm ..."<br />
}}<br />
<br />
See [[dm-crypt/System configuration#Kernel parameters]] and [[GRUB#Encrypted /boot]] for details. The {{ic|''device-UUID''}} refers to the UUID of {{ic|/dev/sda3}} (the partition which holds the lvm containing the root filesystem). See [[Persistent block device naming]].<br />
<br />
[[GRUB#Installation_2|install GRUB]] to the mounted ESP for UEFI booting:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=/efi --bootloader-id=GRUB --recheck<br />
<br />
[[GRUB#Installation|install GRUB]] to the disk for BIOS booting:<br />
<br />
# grub-install --target=i386-pc --recheck /dev/sda<br />
<br />
Generate GRUB's [[GRUB#Generate the main configuration file|configuration]] file:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
If all commands finished without errors, GRUB should prompt for the passphrase to unlock the {{ic|/dev/sda3}} partition after the next reboot.<br />
<br />
=== Avoiding having to enter the passphrase twice ===<br />
<br />
{{Merge|Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|Too much duplicated content, too much detail here for this overview page.|section=Security Issue with Grub Keyfile}}<br />
<br />
While GRUB asks for a passphrase to unlock the LUKS1 encrypted partition after above instructions, the partition unlock is not passed on to the initramfs. Hence, you have to enter the passphrase twice at boot: once for GRUB and once for the initramfs.<br />
<br />
This section deals with extra configuration to let the system boot by only entering the passphrase once, in GRUB. This is accomplished by [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs|with a keyfile embedded in the initramfs]].<br />
<br />
First create a keyfile and add it as LUKS key:<br />
<br />
# dd bs=512 count=4 if=/dev/random of=/root/cryptlvm.keyfile iflag=fullblock<br />
# chmod 000 /root/cryptlvm.keyfile<br />
# cryptsetup -v luksAddKey /dev/sda3 /root/cryptlvm.keyfile<br />
<br />
Add the keyfile to the initramfs image:<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
FILES=(/root/cryptlvm.keyfile)<br />
}}<br />
<br />
Recreate the initramfs image and secure the embedded keyfile:<br />
<br />
# chmod 600 /boot/initramfs-linux*<br />
<br />
Set the following kernel parameters to unlock the LUKS partition with the keyfile. Using the {{ic|encrypt}} hook:<br />
<br />
GRUB_CMDLINE_LINUX="... cryptkey=rootfs:/root/cryptlvm.keyfile"<br />
<br />
Or, using the [[sd-encrypt]] hook:<br />
<br />
GRUB_CMDLINE_LINUX="... rd.luks.key=''device-UUID''=/root/cryptlvm.keyfile"<br />
<br />
If for some reason the keyfile fails to unlock the boot partition, systemd will fallback to ask for a passphrase to unlock and, in case that is correct, continue booting.<br />
<br />
{{Tip|If you want to encrypt the {{ic|/boot}} partition to protect against offline tampering threats, the [[dm-crypt/Specialties#mkinitcpio-chkcryptoboot|mkinitcpio-chkcryptoboot]] hook has been contributed to help.}}<br />
<br />
== Btrfs subvolumes with swap ==<br />
<br />
{{Out of date|Btrfs [[Btrfs#Swap_file|supports swapfile]] since 5.0|Talk:Dm-crypt/Encrypting_an_entire_system#Complete_guide_of_Btrfs_on_LUKS_full_disk_encryption}}<br />
The following example creates a full system encryption with LUKS1 using [[Btrfs]] subvolumes to [[Btrfs#Mounting subvolumes|simulate partitions]].<br />
<br />
If using UEFI, an [[EFI system partition]] (ESP) is required. {{ic|/boot}} itself may reside on {{ic|/}} and be encrypted; however, the ESP itself cannot be encrypted. In this example layout, the ESP is {{ic|/dev/sda1}} and is mounted at {{ic|/efi}}. {{ic|/boot}} itself is located on the system partition, {{ic|/dev/sda2}}.<br />
<br />
Since {{ic|/boot}} resides on the LUKS1 encrypted {{ic|/}}, [[GRUB]] must be used as the bootloader because only GRUB can load modules necessary to decrypt {{ic|/boot}} (e.g., crypto.mod, cryptodisk.mod and luks.mod).<br />
<br />
Additionally an optional plain-encrypted [[swap]] partition is shown.<br />
<br />
{{Text art|<nowiki><br />
+----------------------+----------------------+----------------------+<br />
| EFI system partition | System partition | Swap partition |<br />
| unencrypted | LUKS1-encrypted | plain-encrypted |<br />
| | | |<br />
| /efi | / | [SWAP] |<br />
| /dev/sda1 | /dev/sda2 | /dev/sda3 |<br />
+----------------------+----------------------+----------------------+<br />
</nowiki>}}<br />
<br />
=== Preparing the disk ===<br />
<br />
{{Note|It is not possible to use btrfs partitioning as described in [[Btrfs#Partitionless Btrfs disk]] when using LUKS. Traditional partitioning must be used, even if it is just to create one partition.}}<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]]. If you are using [[UEFI]] create an [[EFI system partition]] with an appropriate size. It will later be mounted at {{ic|/efi}}. If you are going to create an encrypted swap partition, create the partition for it, but do '''not''' mark it as swap, since plain ''dm-crypt'' will be used with the partition.<br />
<br />
Create the needed partitions, at least one for {{ic|/}} (e.g. {{ic|/dev/sda2}}). See the [[Partitioning]] article.<br />
<br />
=== Preparing the system partition ===<br />
<br />
==== Create LUKS container ====<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 />
Follow [[dm-crypt/Device encryption#Encrypting devices with LUKS mode]] to setup {{ic|/dev/sda2}} for LUKS. See the [[dm-crypt/Device encryption#Encryption options for LUKS mode]] before doing so for a list of encryption options.<br />
<br />
==== Unlock LUKS container ====<br />
<br />
Now follow [[dm-crypt/Device encryption#Unlocking/Mapping LUKS partitions with the device mapper]] to unlock the LUKS container and map it.<br />
<br />
==== Format mapped device ====<br />
<br />
Proceed to format the mapped device as described in [[Btrfs#File system on a single device]], where {{ic|''/dev/partition''}} is the name of the mapped device (i.e., {{ic|/dev/mapper/''root''}}) and '''not''' {{ic|/dev/sda2}}.<br />
<br />
==== Mount mapped device ====<br />
<br />
Finally, [[mount]] the now-formatted mapped device (i.e., {{ic|/dev/mapper/root}}) to {{ic|/mnt}}.<br />
<br />
=== Creating btrfs subvolumes ===<br />
<br />
{{Merge|Btrfs|The subvolume layout is not specific to an encrypted system.}}<br />
<br />
==== Layout ====<br />
<br />
[[Btrfs#Subvolumes|Subvolumes]] will be used to simulate partitions, but other (nested) subvolumes will also be created. Here is a partial representation of what the following example will generate:<br />
<br />
{{Text art|<nowiki><br />
subvolid=5<br />
|<br />
├── @ -|<br />
| contained directories:<br />
| ├── /usr<br />
| ├── /bin<br />
| ├── /.snapshots<br />
| ├── ...<br />
|<br />
├── @home<br />
├── @snapshots<br />
├── @var_log<br />
└── @...<br />
</nowiki>}}<br />
<br />
This section follows the [[Snapper#Suggested filesystem layout]], which is most useful when used with [[Snapper]]. You should also consult [https://btrfs.wiki.kernel.org/index.php/SysadminGuide#Layout Btrfs Wiki SysadminGuide#Layout].<br />
<br />
==== Create subvolumes for initial mount ====<br />
<br />
Here we are using the convention of prefixing {{ic|@}} to subvolume names that will be used as mount points, and {{ic|@}} will be the subvolume that is mounted as {{ic|/}}.<br />
<br />
Following the [[Btrfs#Creating a subvolume]] article, create subvolumes at {{ic|/mnt/@}}, {{ic|/mnt/@snapshots}}, and {{ic|/mnt/@home}}.<br />
<br />
Create any additional subvolumes you wish to use as mount points now.<br />
<br />
==== Create subvolumes for excludes ====<br />
<br />
Create any subvolumes you do '''not''' want to have snapshots of when taking a snapshot of {{ic|/}}. For example, you probably do not want to take snapshots of {{ic|/var/cache/pacman/pkg}}. These subvolumes will be nested under the {{ic|@}} subvolume, but just as easily could have been created earlier at the same level as {{ic|@}} according to your preference.<br />
<br />
Since the {{ic|@}} subvolume is mounted at {{ic|/mnt}} you will need to [[create a subvolume]] at {{ic|/mnt/var/cache/pacman/pkg}} for this example. You may have to create any parent directories first.<br />
<br />
Other directories you may wish to do this with are {{ic|/var/abs}}, {{ic|/var/tmp}}, and {{ic|/srv}}.<br />
<br />
==== Mount top-level subvolumes ====<br />
<br />
Unmount the system partition at {{ic|/mnt}}.<br />
<br />
Now mount the newly created {{ic|@}} subvolume which will serve as {{ic|/}} to {{ic|/mnt}} using the {{ic|1=subvol=}} mount option. Assuming the mapped device is named {{ic|root}}, the command would look like:<br />
<br />
# mount -o compress=zstd,subvol=@ /dev/mapper/root /mnt<br />
<br />
See [[Btrfs#Mounting subvolumes]] for more details.<br />
<br />
Also mount the other subvolumes to their respective mount points: {{ic|@home}} to {{ic|/mnt/home}} and {{ic|@snapshots}} to {{ic|/mnt/.snapshots}}.<br />
<br />
==== Mount ESP ====<br />
<br />
If you prepared an EFI system partition earlier, create its mount point and mount it now.<br />
<br />
{{Note|Btrfs snapshots will exclude {{ic|/efi}}, since it is not a btrfs file system.}}<br />
<br />
At the [[Installation guide#Install essential packages|pacstrap]] installation step, the {{Pkg|btrfs-progs}} must be installed in addition to the {{Pkg|base}} [[meta package]].<br />
<br />
=== Configuring mkinitcpio ===<br />
<br />
==== Create keyfile ====<br />
<br />
In order for GRUB to open the LUKS partition without having the user enter their passphrase twice, we will use a keyfile embedded in the initramfs. Follow [[dm-crypt/Device encryption#With a keyfile embedded in the initramfs]] making sure to add the key to {{ic|/dev/sda2}} at the ''luksAddKey'' step.<br />
<br />
==== Edit mkinitcpio.conf ====<br />
<br />
After creating, adding, and embedding the key as described above, add the {{ic|encrypt}} hook to [[mkinitcpio.conf]] as well as any other hooks you require.<br />
<br />
[[Regenerate the initramfs]] after saving the changes. See [[dm-crypt/System configuration#mkinitcpio]] for details and other hooks that you may need.<br />
<br />
{{Tip|You may want to add {{ic|1=BINARIES=(btrfs)}} to your {{ic|/etc/mkinitcpio.conf}}. See the [[Btrfs#Corruption recovery]] article.}}<br />
<br />
=== Configuring the boot loader ===<br />
<br />
Install [[GRUB]] to {{ic|/dev/sda}}. Then, edit {{ic|/etc/default/grub}} as instructed in the [[GRUB#Additional arguments]], [[GRUB#Encrypted /boot]] and [[dm-crypt/System configuration#Using encrypt hook]], following both the instructions for an encrypted root and boot partition. Finally, generate the GRUB configuration file. Note that you will need to pass kernel parameters for the root mount point as instructed in [[Btrfs#Mounting subvolume as root]].<br />
<br />
=== Configuring swap ===<br />
<br />
If you created a partition to be used for encrypted swap, now is the time to configure it. Follow the instructions at [[dm-crypt/Swap encryption]].<br />
<br />
== Root on ZFS ==<br />
<br />
Root on [[ZFS]] can be configured to encrypt everything except boot loader. See [https://openzfs.github.io/openzfs-docs/Getting%20Started/Arch%20Linux/Arch%20Linux%20Root%20on%20ZFS.html installation guide] on OpenZFS page.<br />
<br />
Boot loader can be verified with [[Secure Boot]] on UEFI-based systems.<br />
<br />
See also [[ZFS#Encryption in ZFS using dm-crypt]].<br />
<br />
== Simple encrypted root with TPM2 and Secure Boot ==<br />
<br />
This example covers a full system encryption with ''dm-crypt'' + LUKS, TPM2 and [[Secure Boot]] :<br />
Only the ESP remains unencrypted, with a [[Unified kernel image]] and [[Systemd-boot]] residing on it, both of which can be signed for use with [[Secure Boot]], providing a reasonably safe boot chain.<br />
<br />
Be aware though that as long as the system is [[Trusted Platform Module#Accessing PCR registers|not tempered with]], the root partition will automatically be decrypted upon boot, without a password prompt.<br />
<br />
In this example, partitions are created respecting [[Systemd#GPT partition automounting]], there is no need for an fstab or crypttab file.<br />
<br />
{{Text art|<nowiki><br />
+-----------------------+------------------------+-----------------------+<br />
| ESP | System partition |<br />
| unencrypted | encrypted |<br />
| | |<br />
| /efi | / |<br />
| | |<br />
| | /dev/mapper/root |<br />
| |------------------------------------------------|<br />
| /dev/sda1 | /dev/sda2 |<br />
+-----------------------+------------------------+-----------------------+<br />
</nowiki>}}<br />
<br />
Follow the [[Installation guide]] up to step [[Installation guide#Partition the disks|1.9 Partition the disks]]<br />
<br />
=== Partition the disks ===<br />
<br />
Prior to creating any partitions, you should inform yourself about the importance and methods to securely erase the disk, described in [[dm-crypt/Drive preparation]].<br />
<br />
Additionally, check that your disk reports the correct [[Advanced Format|sector size]].<br />
<br />
Make sure to create a [[GPT]] partition table. Then create the needed partitions for {{ic|/}} (e.g. {{ic|/dev/sda2}}) and {{ic|/efi}} ({{ic|/dev/sda1}}). See [[Partitioning]].<br />
<br />
* See [[EFI system partition#GPT partitioned disks]] to create the ESP with the appropriate partition GUID.<br />
* For the Luks (root) partition, you can use [[gdisk]] with partition type {{ic|8304}}, or [[fdisk]] with partition type {{ic|23 Linux root (x86-64)}} (if your architecture is x86-64). See [[GPT fdisk#Partition type]].<br />
<br />
=== Format the partitions ===<br />
==== Root partition ====<br />
<br />
The following commands create and mount the encrypted root partition, and make use of the TPM to store the encryption key. See [[dm-crypt/Encrypting a non-root file system#Partition]] (which, despite the title, ''can'' be applied to root partitions, as long as [[#Configuring mkinitcpio|mkinitcpio]] and the [[#Configuring the boot loader|boot loader]] are correctly configured), and [[Trusted Platform Module#systemd-cryptenroll]].<br />
<br />
If you want to use particular non-default encryption options (e.g. cipher, key length), or if you don't want to use TPM based decryption, see the [[dm-crypt/Device encryption#Encryption options for LUKS mode|encryption options]] before executing the first command.<br />
<br />
We will create a luks volume with a key bound to the TPM [[Trusted Platform Module#Accessing PCR registers|PCR 7]] (default, [[Secure Boot]] state) and a recovery key to be used in case of any problem. The TPM will automatically release the key as long as the boot chain is not tempered with. See {{man|1|systemd-cryptenroll}}.<br />
<br />
Create the luks volume (you can simply use a blank password, as it will be wiped in the next step)<br />
<br />
# cryptsetup luksFormat /dev/sda2<br />
# systemd-cryptenroll /dev/sda2 --recovery-key<br />
# systemd-cryptenroll /dev/sda2 --wipe-slot=empty --tpm2-device=auto<br />
# cryptsetup open /dev/sda2 root<br />
# mkfs.ext4 /dev/mapper/root<br />
<br />
==== ESP ====<br />
<br />
See [[EFI system partition#Format the partition]].<br />
<br />
=== Mount the file systems ===<br />
<br />
At [[Installation guide#Mount the file systems]] you will have to mount the mapped device, not the actual partitions, i.e.<br />
<br />
# mount /dev/mapper/root /mnt<br />
# mount --mkdir /dev/sda1 /mnt/efi<br />
<br />
Continue the installation process until [[Installation guide#Initramfs]]. You can skip [[Installation guide#Fstab]].<br />
<br />
=== Initramfs ===<br />
<br />
To build a working systemd based initramfs, modify the {{ic|1=HOOKS=}} line in [[mkinitcpio.conf]] as follows:<br />
<br />
HOOKS=('''systemd''' autodetect '''keyboard''' '''sd-vconsole''' modconf block '''sd-encrypt''' filesystems fsck)<br />
<br />
(if the default US keymap is fine for you, you can omit the {{ic|keymap}} hook)<br />
<br />
Next, see [[Unified kernel image#mkinitpcio]] to configure mkinitcpio for [[Unified kernel image]]s.<br />
<br />
Do not [[regenerate the initramfs]] yet, as the EFI path {{ic|/efi/EFI/Linux/}} needs to be created by the boot loader installer first.<br />
<br />
=== Boot loader ===<br />
<br />
Install [[systemd-boot]] with<br />
<br />
# bootctl install<br />
<br />
The [[Unified kernel image]] generated by mkinitcpio will be automatically recognized and does not need an entry in {{ic|/efi/loader/entries}}<br />
<br />
See [[Systemd-boot#Updating the EFI boot manager]] and [[Systemd-boot#Loader configuration]] for further configuration.<br />
<br />
=== Finalizing the installation ===<br />
<br />
First, [[Regenerate the initramfs]], and make sure the image generation is successful.<br />
<br />
Make sure you did not forget to [[Installation guide#Root password|set a root password]], reboot to [[Installation guide#Reboot|reboot]] to finish the installation.<br />
<br />
=== Secure Boot ===<br />
<br />
You can now sign the boot loader executables and the EFI binary, in order to enable [[Secure Boot]]. For a quick and easy way, see [[Unified Extensible Firmware Interface/Secure Boot#sbctl]]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Rsync&diff=752698Rsync2022-10-13T08:41:11Z<p>Wooptoo: Advanced usage of filter rules - small fixup</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Synchronization]]<br />
[[Category:Backup]]<br />
[[Category:Commands]]<br />
[[de:Rsync]]<br />
[[es:Rsync]]<br />
[[fr:Rsync]]<br />
[[ja:Rsync]]<br />
[[ru:Rsync]]<br />
[[zh-hans:Rsync]]<br />
{{Related articles start}}<br />
{{Related|System backup}}<br />
{{Related|Synchronization and backup programs}}<br />
{{Related articles end}}<br />
[https://rsync.samba.org/ rsync] is an open source utility that provides fast incremental file transfer.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|rsync}} package.<br />
<br />
''rsync'' must be installed on both the source and the destination machine.<br />
<br />
=== Front-ends ===<br />
<br />
* {{App|Grsync|GTK front-end.|https://www.opbyte.it/grsync/|{{Pkg|grsync}}}}<br />
* {{App|JotaSync|Java Swing GUI for rsync with integrated scheduler.|https://trixon.se/projects/jotasync/|{{Aur|jotasync}}}}<br />
* {{App|luckyBackup|Qt front-end written in C++.|http://luckybackup.sourceforge.net/index.html|{{Aur|luckybackup}}}}<br />
<br />
Other tools using rsync are {{Pkg|rdiff-backup}}, {{AUR|osync}} and {{AUR|yarsync}}.<br />
<br />
== As cp/mv alternative ==<br />
<br />
{{Note|1=Using rsync instead of cp/mv is efficient across different filesystems, but not for copying or moving files on the same filesystem. See [https://bbs.archlinux.org/viewtopic.php?id=271953]}}<br />
<br />
rsync can be used as an advanced alternative for the {{ic|cp}} or {{ic|mv}} command, especially for copying larger files:<br />
<br />
$ rsync -P source destination<br />
<br />
The {{ic|-P}} option is the same as {{Ic|--partial --progress}}, which keeps partially transferred files and shows a progress bar.<br />
<br />
You may want to use the {{ic|-r}}/{{ic|--recursive}} option to recurse into directories.<br />
<br />
Files can be copied locally as with cp, but the motivating purpose of rsync is to copy files remotely, i.e. between two different hosts. Remote locations can be specified with a host-colon syntax:<br />
<br />
$ rsync source host:destination<br />
<br />
or<br />
<br />
$ rsync host:source destination<br />
<br />
Network file transfers use the [[SSH]] protocol by default and {{ic|host}} can be a real hostname or a predefined profile/alias from {{ic|.ssh/config}}.<br />
<br />
Whether transferring files locally or remotely, rsync first creates a file-list containing information (by default, it is the file size and last modification timestamp) which will then be used to determine if a file needs to be constructed. For each file to be constructed, a weak and strong checksum is found for all blocks such that each block is of length '''S''' bytes, non-overlapping, and has an offset which is divisible by '''S'''. Using this information a large file can be constructed using rsync without having to transfer the entire file. For a more detailed practical and mathematical explanation refer to [https://rsync.samba.org/how-rsync-works.html how rsync works] and [https://rsync.samba.org/tech_report/tech_report.html the rsync algorithm], respectively.<br />
<br />
To use sane defaults quickly, you could use some aliases:<br />
{{bc|1=<br />
cpr() {<br />
rsync --archive -hh --partial --info=stats1,progress2 --modify-window=1 "$@"<br />
} <br />
mvr() {<br />
rsync --archive -hh --partial --info=stats1,progress2 --modify-window=1 --remove-source-files "$@"<br />
} }}<br />
<br />
* {{ic|-hh}}: output numbers in a human-readable format<br />
* {{ic|1=--info=stats1,progress2}}: {{ic|stats1}} displays rsync transfer statistics with verbosity level 1. {{ic|progress2}} prints total transfer progress as opposed to per-file transfer progress ({{ic|progress1}})<br />
* {{ic|1=--modify-window=1}}: when comparing the timestamps of two files, treat their timestamps as being equivalent if their timestamps have a difference of less than 1 second<br />
* {{ic|--remove-source-files}}: remove files from the source directory after they have been successfully synced<br />
<br />
{{Note|The use of the term ''checksum'' is '''not''' interchangeable with the behavior of the {{ic|--checksum}} option. The {{ic|--checksum}} option affects the file skip heuristic used prior to any file being transferred. Independent of {{ic|--checksum}}, a ''checksum'' is always used for the block-based file construction which is how rsync transfers a file.}}<br />
<br />
=== Trailing slash caveat ===<br />
<br />
Arch by default uses GNU cp (part of GNU {{Pkg|coreutils}}). However, rsync follows the convention of BSD cp, which gives special treatment to source directories with a trailing slash "/". Whereas<br />
<br />
$ rsync -r source destination<br />
<br />
creates a directory "destination/source" with the contents of "source", the command<br />
<br />
$ rsync -r source/ destination<br />
<br />
copies all of the files in "source/" directly into "destination", with no intervening subdirectory - just as if you had invoked it as<br />
<br />
$ rsync -r source/. destination<br />
<br />
This behavior is different from that of GNU cp, which treats "source" and "source/" identically (but not "source/."). Also, some shells automatically append the trailing slash when tab-completing directory names. Because of these factors, there can be a tendency among new or occasional rsync users to forget about rsync's different behavior, and inadvertently create a mess or even overwrite important files by leaving the trailing slash on the command line.<br />
<br />
Thus it can be prudent to use a wrapper script to automatically remove trailing slashes before invoking rsync:<br />
<br />
#!/bin/bash<br />
new_args=()<br />
for i in "${@}"; do<br />
case "${i}" in<br />
/)<br />
i="/"<br />
;;<br />
*/)<br />
i="${i%/}"<br />
;;<br />
esac<br />
new_args+=("${i}")<br />
done<br />
exec rsync "${new_args[@]}"<br />
<br />
This script can be put somewhere in the path, and aliased to rsync in the shell init file.<br />
<br />
== As a backup utility ==<br />
<br />
The rsync protocol can easily be used for backups, only transferring files that have changed since the last backup. This section describes a very simple scheduled backup script using rsync, typically used for copying to removable media.<br />
<br />
=== Automated backup ===<br />
<br />
For the sake of this example, the script is created in the {{ic|/etc/cron.daily}} directory, and will be run on a daily basis if a cron [[daemon]] is installed and properly configured. Configuring and using [[cron]] is outside the scope of this article.<br />
<br />
First, create a script containing the appropriate command options:<br />
<br />
{{hc|/etc/cron.daily/backup|<br />
#!/bin/sh<br />
rsync -a --delete --quiet /path/to/backup /location/of/backup}}<br />
<br />
* {{ic|-a}}: indicates that files should be archived, meaning that most of their characteristics are preserved (but '''not''' ACLs, hard links or extended attributes such as capabilities)<br />
* {{ic|--delete}}: means files deleted on the source are to be deleted on the backup as well<br />
<br />
Here, {{ic|/path/to/backup}} should be changed to what needs to be backed-up (e.g. {{ic|/home}}) and {{ic|/location/of/backup}} is where the backup should be saved (e.g. {{ic|/media/disk}}).<br />
<br />
Finally, the script must be [[executable]].<br />
<br />
=== Automated backup with SSH ===<br />
<br />
If backing-up to a remote host using [[SSH]], use this script instead:<br />
<br />
{{hc|/etc/cron.daily/backup|<br />
#!/bin/sh<br />
rsync -a --delete --quiet -e ssh /path/to/backup remoteuser@remotehost:/location/of/backup<br />
}}<br />
<br />
* {{ic|-e ssh}}: tells rsync to use SSH<br />
* {{ic|remoteuser}}: is the user on the host {{ic|remotehost}}<br />
* {{ic|-a}}: groups all these options {{ic|-rlptgoD}} (recursive, links, perms, times, group, owner, devices)<br />
<br />
{{Note|<br />
Rsync will try to modify any previously backed up files on the target machine to match their current state at the source machine, with each incremental backup. This means that when backing up files that are owned by root over SSH (and when preserving permissions and ownerships such as with the {{ic|-a}} option), root access to the target machine is needed. The preferred way to achieve this for automation is to set up the SSH daemon to allow root to login using a [https://unix.stackexchange.com/a/92397 public key without password] and run the rsync command as root.}}<br />
<br />
=== Automated backup with NetworkManager ===<br />
<br />
This script starts a backup when network connection is established.<br />
<br />
First, create a script containing the appropriate command options:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/backup|2=<br />
#!/bin/sh<br />
<br />
if [ x"$2" = "xup" ] ; then<br />
rsync --force --ignore-errors -a --delete --bwlimit=2000 --files-from=files.rsync /path/to/backup /location/of/backup<br />
fi<br />
}}<br />
<br />
* {{ic|-a}}: group all this options {{ic|-rlptgoD}} recursive, links, perms, times, group, owner, devices<br />
* {{ic|--files-from}}: read the relative path of {{ic|/path/to/backup}} from this file<br />
* {{ic|--bwlimit}}: limit I/O bandwidth; Kilo-bytes per second<br />
<br />
The script must be owned by root (see [[NetworkManager#Network services with NetworkManager dispatcher]] for details).<br />
<br />
=== Automated backup with systemd and inotify ===<br />
<br />
{{Note|<br />
* Due to the limitations of inotify and systemd (see [https://www.quora.com/Linux-Kernel/Inotify-monitoring-of-directories-is-not-recursive-Is-there-any-specific-reason-for-this-design-in-Linux-kernel this question and answer]), recursive filesystem monitoring is not possible. Although you can watch a directory and its contents, it will not recurse into subdirectories and watch the contents of them; you must explicitly specify every directory to watch, even if that directory is a child of an already watched directory.<br />
* This setup is based on a [[systemd/User]] instance.<br />
}}<br />
<br />
Instead of running time interval backups with time based schedules, such as those implemented in [[cron]], it is possible to run a backup every time one of the files you are backing up changes. {{ic|systemd.path}} units use {{ic|inotify}} to monitor the filesystem, and can be used in conjunction with {{ic|systemd.service}} files to start any process (in this case your rsync backup) based on a filesystem event.<br />
<br />
First, create the {{ic|systemd.path}} unit that will monitor the files you are backing up:<br />
<br />
{{hc|~/.config/systemd/user/backup.path|<nowiki><br />
[Unit]<br />
Description=Checks if paths that are currently being backed up have changed<br />
<br />
[Path]<br />
PathChanged=%h/documents<br />
PathChanged=%h/music<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki>}}<br />
<br />
Then create a {{ic|systemd.service}} file that will be activated when it detects a change. By default a service file of the same name as the path unit (in this case {{ic|backup.path}}) will be activated, except with the {{ic|.service}} extension instead of {{ic|.path}} (in this case {{ic|backup.service}}).<br />
<br />
{{Note|If you need to run multiple rsync commands, use {{ic|1=Type=oneshot}}. This allows you to specify multiple {{ic|1=ExecStart=}} parameters, one for each rsync command, that will be executed. Alternatively, you can simply write a script to perform all of your backups, just like [[cron]] scripts.}}<br />
<br />
{{hc|~/.config/systemd/user/backup.service|<nowiki><br />
[Unit]<br />
Description=Backs up files<br />
<br />
[Service]<br />
ExecStart=/usr/bin/rsync %h/./documents %h/./music -CERrltm --delete ubuntu:<br />
</nowiki>}}<br />
<br />
Now all you have to do is [[enable/start]] {{ic|backup.path}} like a normal systemd service and it will start monitoring file changes and automatically start {{ic|backup.service}}.<br />
<br />
=== Differential backup on a week ===<br />
<br />
This is a useful option of rsync, resulting in a full backup (on each run) and keeping a differential backup copy of changed files only in a separate directory for each day of a week.<br />
<br />
First, create a script containing the appropriate command options:<br />
<br />
{{hc|/etc/cron.daily/backup|2=<br />
#!/bin/sh<br />
<br />
DAY=$(date +%A)<br />
<br />
if [ -e /location/to/backup/incr/$DAY ] ; then<br />
rm -fr /location/to/backup/incr/$DAY<br />
fi<br />
<br />
rsync -a --delete --quiet --inplace --backup --backup-dir=/location/to/backup/incr/$DAY /path/to/backup/ /location/to/backup/full/<br />
}}<br />
<br />
The {{ic|--inplace}} option implies {{ic|--partial}} and updates destination files in-place.<br />
<br />
=== Snapshot backup ===<br />
<br />
The same idea can be used to maintain a tree of snapshots of your files. In other words, a directory with date-ordered copies of the files. The copies are made using hardlinks, which means that only files that did change will occupy space. Generally speaking, this is the idea behind Apple's TimeMachine.<br />
<br />
This basic script is easy to implement and creates quick incremental snapshots using the {{ic|--link-dest}} option to hardlink unchanged files: <br />
<br />
{{hc|/usr/local/bin/snapbackup.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Basic snapshot-style rsync backup script <br />
<br />
# Config<br />
OPT="-aPh"<br />
LINK="--link-dest=/snapshots/username/last/" <br />
SRC="/home/username/files/"<br />
SNAP="/snapshots/username/"<br />
LAST="/snapshots/username/last"<br />
date=`date "+%Y-%b-%d:_%T"`<br />
<br />
# Run rsync to create snapshot<br />
rsync $OPT $LINK $SRC ${SNAP}$date<br />
<br />
# Remove symlink to previous snapshot<br />
rm -f $LAST<br />
<br />
# Create new symlink to latest snapshot for the next backup to hardlink<br />
ln -s ${SNAP}$date $LAST<br />
</nowiki>}}<br />
<br />
There must be a symlink to a full backup already in existence as a target for {{ic|--link-dest}}. If the most recent snapshot is deleted, the symlink will need to be recreated to point to the most recent snapshot. If {{ic|--link-dest}} does not find a working symlink, rsync will proceed to copy all source files instead of only the changes. <br />
<br />
A more sophisticated version keeps an up-to-date full backup {{ic|$SNAP/latest}} and in case a certain number of files has changed since the last full backup, it creates a snapshot {{ic|$SNAP/$DATETAG}} of the current full-backup utilizing {{ic|cp -al}} to hardlink unchanged files:<br />
<br />
{{hc|/usr/local/bin/rsnapshot.sh|<nowiki><br />
#!/bin/sh<br />
<br />
## my own rsync-based snapshot-style backup procedure<br />
## (cc) marcio rps AT gmail.com<br />
<br />
# config vars<br />
<br />
SRC="/home/username/files/" #dont forget trailing slash!<br />
SNAP="/snapshots/username"<br />
OPTS="-rltgoi --delay-updates --delete --chmod=a-w"<br />
MINCHANGES=20<br />
<br />
# run this process with real low priority<br />
<br />
ionice -c 3 -p $$<br />
renice +12 -p $$<br />
<br />
# sync<br />
<br />
rsync $OPTS $SRC $SNAP/latest >> $SNAP/rsync.log<br />
<br />
# check if enough has changed and if so<br />
# make a hardlinked copy named as the date<br />
<br />
COUNT=$( wc -l $SNAP/rsync.log|cut -d" " -f1 )<br />
if [ $COUNT -gt $MINCHANGES ] ; then<br />
DATETAG=$(date +%Y-%m-%d)<br />
if [ ! -e $SNAP/$DATETAG ] ; then<br />
cp -al $SNAP/latest $SNAP/$DATETAG<br />
chmod u+w $SNAP/$DATETAG<br />
mv $SNAP/rsync.log $SNAP/$DATETAG<br />
chmod u-w $SNAP/$DATETAG<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
To make things really, really simple this script can be run from a [[systemd/Timers]] unit.<br />
<br />
=== Full system backup ===<br />
<br />
This section is about using ''rsync'' to transfer a copy of the entire {{ic|/}} tree, excluding a few selected directories. This approach is considered to be better than [[disk cloning]] with {{ic|dd}} since it allows for a different size, partition table and filesystem to be used, and better than copying with {{ic|cp -a}} as well, because it allows greater control over file permissions, attributes, [[Access Control Lists]] and [[extended attributes]].<br />
<br />
''rsync'' will work even while the system is running, but files changed during the transfer may or may not be transferred, which can cause undefined behavior of some programs using the transferred files.<br />
<br />
This approach works well for migrating an existing installation to a new hard drive or [[SSD]].<br />
<br />
Run the following command as root to make sure that rsync can access all system files and preserve the ownership:<br />
<br />
# rsync -aAXHv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / ''/path/to/backup''<br />
<br />
By using the {{ic|-aAX}} set of options, the files are transferred in archive mode which ensures that symbolic links, devices, permissions, ownerships, modification times, [[ACL]]s, and extended attributes are preserved, assuming that the target [[file system]] supports the feature. The option {{ic|-H}} preserves hard links, but uses more memory.<br />
<br />
The {{ic|--exclude}} option causes files that match the given patterns to be excluded. The directories {{ic|/dev}}, {{ic|/proc}}, {{ic|/sys}}, {{ic|/tmp}}, and {{ic|/run}} are included in the above command, but the ''contents'' of those directories are excluded. This is because they are populated on boot, but the directories themselves are not created. {{ic|/lost+found}} is filesystem-specific. The command above depends on brace expansion available in both the [https://www.gnu.org/software/bash/manual/html_node/Brace-Expansion.html bash] and [http://zsh.sourceforge.net/Doc/Release/Expansion.html#Brace-Expansion zsh] shells. When using a different [[shell]], {{ic|--exclude}} patterns should be repeated manually. Quoting the exclude patterns will avoid expansion by the [[shell]], which is necessary, for example, when backing up over [[SSH]]. Ending the excluded paths with {{ic|*}} ensures that the directories themselves are created if they do not already exist.<br />
<br />
{{Note|<br />
* If you plan on backing up your system somewhere other than {{ic|/mnt}} or {{ic|/media}}, do not forget to add it to the list of exclude patterns to avoid an infinite loop.<br />
* If there are any bind mounts in the system, they should be excluded as well so that the bind mounted contents is copied only once.<br />
* If you use a [[swap file]], make sure to exclude it as well.<br />
* Consider if you want to backup the {{ic|/home/}} directory. If it contains your data it might be considerably larger than the system. Otherwise consider excluding unimportant sub-directories such as {{ic|/home/*/.thumbnails/*}}, {{ic|/home/*/.cache/mozilla/*}}, {{ic|/home/*/.cache/chromium/*}}, and {{ic|/home/*/.local/share/Trash/*}}, depending on software installed on the system.<br />
* If [[GVFS]] is installed, {{ic|/home/*/.gvfs}} must be excluded to prevent rsync errors.<br />
* If [[Dhcpcd]] ≥ 9.0.0 is installed, exclude the {{ic|/var/lib/dhcpcd/*}} directory as it mounts several system directories as sub-directories there.<br />
}}<br />
<br />
You may want to include additional rsync options, or remove some, such as the following. See {{man|1|rsync}} for the full list.<br />
<br />
* If you run on a system with very low memory, consider removing {{ic|-H}} option; however, it should be no problem on most modern machines. There can be many hard links on the file system depending on the software used (e.g. if you are using [[Flatpak]]). Many hard links reside under the {{ic|/usr/}} directory.<br />
* You may want to add rsync's {{ic|--delete}} option if you are running this multiple times to the same backup directory. In this case make sure that the source path does not end with {{ic|/*}}, or this option will only have effect on the files inside the subdirectories of the source directory, but it will have no effect on the files residing directly inside the source directory.<br />
* If you use any sparse files, such as virtual disks, [[Docker]] images and similar, you should add the {{ic|-S}} option.<br />
* The {{ic|--numeric-ids}} option will disable mapping of user and group names; instead, numeric group and user IDs will be transfered. This is useful when backing up over [[SSH]] or when using a live system to backup different system disk.<br />
* Choosing {{ic|1=--info=progress2}} option instead of {{ic|-v}} will show the overall progress info and transfer speed instead of the list of files being transferred.<br />
* To avoid crossing a filesystem boundary when recursing, add the option {{ic|-x}}/{{ic|--one-file-system}}. This will prevent backing up any mount point in the hierarchy.<br />
<br />
=== Restore a backup ===<br />
<br />
If you wish to restore a backup, use the same rsync command that was executed but with the source and destination reversed.<br />
<br />
=== Advanced usage of filter rules ===<br />
<br />
Instead of specifying include and exclude rules separately Rsync can read all of these from a single filter file. Rsync then processes the rules in a top-down order; the first matching rule wins.<br />
<br />
{{hc|backup.filter|<nowiki><br />
# Exclude patterns<br />
<br />
- .thumbnails/***<br />
- node_modules/***<br />
- venv/***<br />
<br />
# Include patterns<br />
<br />
+ /Documents/***<br />
+ /Books/***<br />
+ /Music/***<br />
<br />
# Exclude everything else<br />
- /**<br />
</nowiki>}}<br />
<br />
{{ic|***}} is a special rsync pattern which matches a folder and all of its contents recursively.<br />
<br />
Check {{ic|man rsync}} → {{ic|Pattern matching rules}} and {{ic|Filter rules in depth}} for more details.<br />
<br />
<br />
Then run Rsync with:<br />
<br />
{{hc|backup.sh|<nowiki><br />
/usr/bin/rsync -avHAX \<br />
--delete-after \<br />
--filter="merge backup.filter" \<br />
$HOME $REMOTE_DEST<br />
</nowiki>}}<br />
<br />
The key word is the {{ic|--filter "merge ..."}} parameter which will take the filter file and parse the rules in order for each sync-ed file.<br />
<br />
== File system cloning ==<br />
<br />
rsync provides a way to do a copy of all data in a file system while preserving as much information as possible, including the file system metadata. It is a procedure of data cloning on a file system level where source and destination file systems do not need to be of the same type. It can be used for backing up, file system migration or data recovery.<br />
<br />
rsync's ''archive'' mode comes close to being fit for the job, but it does not back up the special file system metadata such as access control lists, extended attributes or sparse file properties. For successful cloning at the file system level, some additional options need to be provided:<br />
<br />
rsync -qaHAXS SOURCE_DIR DESTINATION_DIR<br />
<br />
And their meaning is (from the manpage):<br />
<br />
--hard-links, -H preserve hard links<br />
--acls, -A preserve ACLs (implies --perms)<br />
--xattrs, -X preserve extended attributes<br />
--sparse, -S turn sequences of nulls into sparse blocks<br />
<br />
Additionally, use {{ic|-x}} if you have other filesystems mounted under the tree that you want to exclude from the copy.<br />
Produced copy can be simply reread and checked (for example after a data recovery attempt) at the file system level with {{ic|diff}}'s recursive option:<br />
<br />
diff -r SOURCE_DIR DESTINATION_DIR<br />
<br />
It is possible to do a successful file system migration by using rsync as described in this article and updating the [[fstab]] and [[bootloader]] as described in [[Migrate installation to new hardware]]. This essentially provides a way to convert any root file system to another one.<br />
<br />
== As a daemon ==<br />
<br />
''rsync'' can be run as [[daemon]] on a server listening on port {{ic|873}}.<br />
<br />
Edit the template {{ic|/etc/rsyncd.conf}}, configure a share and [[start]] the {{ic|rsyncd.service}}.<br />
<br />
{{Note|As of {{Pkg|rsync}} 3.2.0-1 the package adopted the upstream systemd unit files {{ic|rsyncd.service}} and {{ic|rsyncd@.service}}. The change for {{ic|1=ProtectHome}} has been commented, the security feature {{ic|1=ProtectSystem=full}} under the {{ic|[Service]}} section is still active. This makes the {{ic|/boot/}}, {{ic|/etc/}} and {{ic|/usr/}} directories read-only. If you need rsyncd write system directories you can [[edit]] the unit and set {{ic|1=ProtectSystem=off}} in the {{ic|[Service]}} section of the overriding snippet.}}<br />
<br />
Usage from client, e.g. list server content:<br />
<br />
$ rsync rsync://''server/share''<br />
<br />
transfer file from client to server: <br />
<br />
$ rsync ''local-file'' rsync://''server/share/''<br />
<br />
Consider iptables to open port {{ic|873}} and user authentication.<br />
<br />
{{Note|All transferred data including user authentication are not encrypted.}}<br />
<br />
=== Example configuration ===<br />
<br />
==== Sharing from a list of files ====<br />
<br />
{{hc|1=/etc/rsyncd.conf|2=<br />
...<br />
<br />
# Needed when crossing filesystem boundaries.<br />
#use chroot = no<br />
read only = yes<br />
<br />
...<br />
<br />
[sync]<br />
path = /<br />
# List of files to copy.<br />
include from = /backup.list<br />
# Exclude the rest.<br />
exclude = *<br />
}}<br />
<br />
Inside the file list, all the ''intermediary paths'' are necessary, except when the {{ic|***}} wildcard is used:<br />
<br />
{{hc|/backup.list|<br />
/etc/<br />
/etc/conf.d/<br />
/etc/conf.d/hwclock<br />
/etc/fonts/***<br />
}}<br />
<br />
== See also ==<br />
<br />
* More usage examples can be searched in the [https://bbs.archlinux.org/viewforum.php?id=27 Community Contributions] and [https://bbs.archlinux.org/viewforum.php?id=33 General Programming] forums<br />
* [https://www.pointsoftware.ch/2012/09/12/howto-local-and-remote-snapshot-backup-using-rsync-with-hard-links/ Howto – local and remote snapshot backup using rsync with hard links] Includes file deduplication with hard-links, MD5 integrity signature, 'chattr' protection, filter rules, disk quota, retention policy with exponential distribution (backups rotation while saving more recent backups than older)<br />
* [https://stackoverflow.com/questions/5527068/how-do-you-use-an-identity-file-with-rsync Using SSH keys/identity files with rsync]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Rsync&diff=752696Rsync2022-10-13T08:38:03Z<p>Wooptoo: Advanced usage of filter rules</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Synchronization]]<br />
[[Category:Backup]]<br />
[[Category:Commands]]<br />
[[de:Rsync]]<br />
[[es:Rsync]]<br />
[[fr:Rsync]]<br />
[[ja:Rsync]]<br />
[[ru:Rsync]]<br />
[[zh-hans:Rsync]]<br />
{{Related articles start}}<br />
{{Related|System backup}}<br />
{{Related|Synchronization and backup programs}}<br />
{{Related articles end}}<br />
[https://rsync.samba.org/ rsync] is an open source utility that provides fast incremental file transfer.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|rsync}} package.<br />
<br />
''rsync'' must be installed on both the source and the destination machine.<br />
<br />
=== Front-ends ===<br />
<br />
* {{App|Grsync|GTK front-end.|https://www.opbyte.it/grsync/|{{Pkg|grsync}}}}<br />
* {{App|JotaSync|Java Swing GUI for rsync with integrated scheduler.|https://trixon.se/projects/jotasync/|{{Aur|jotasync}}}}<br />
* {{App|luckyBackup|Qt front-end written in C++.|http://luckybackup.sourceforge.net/index.html|{{Aur|luckybackup}}}}<br />
<br />
Other tools using rsync are {{Pkg|rdiff-backup}}, {{AUR|osync}} and {{AUR|yarsync}}.<br />
<br />
== As cp/mv alternative ==<br />
<br />
{{Note|1=Using rsync instead of cp/mv is efficient across different filesystems, but not for copying or moving files on the same filesystem. See [https://bbs.archlinux.org/viewtopic.php?id=271953]}}<br />
<br />
rsync can be used as an advanced alternative for the {{ic|cp}} or {{ic|mv}} command, especially for copying larger files:<br />
<br />
$ rsync -P source destination<br />
<br />
The {{ic|-P}} option is the same as {{Ic|--partial --progress}}, which keeps partially transferred files and shows a progress bar.<br />
<br />
You may want to use the {{ic|-r}}/{{ic|--recursive}} option to recurse into directories.<br />
<br />
Files can be copied locally as with cp, but the motivating purpose of rsync is to copy files remotely, i.e. between two different hosts. Remote locations can be specified with a host-colon syntax:<br />
<br />
$ rsync source host:destination<br />
<br />
or<br />
<br />
$ rsync host:source destination<br />
<br />
Network file transfers use the [[SSH]] protocol by default and {{ic|host}} can be a real hostname or a predefined profile/alias from {{ic|.ssh/config}}.<br />
<br />
Whether transferring files locally or remotely, rsync first creates a file-list containing information (by default, it is the file size and last modification timestamp) which will then be used to determine if a file needs to be constructed. For each file to be constructed, a weak and strong checksum is found for all blocks such that each block is of length '''S''' bytes, non-overlapping, and has an offset which is divisible by '''S'''. Using this information a large file can be constructed using rsync without having to transfer the entire file. For a more detailed practical and mathematical explanation refer to [https://rsync.samba.org/how-rsync-works.html how rsync works] and [https://rsync.samba.org/tech_report/tech_report.html the rsync algorithm], respectively.<br />
<br />
To use sane defaults quickly, you could use some aliases:<br />
{{bc|1=<br />
cpr() {<br />
rsync --archive -hh --partial --info=stats1,progress2 --modify-window=1 "$@"<br />
} <br />
mvr() {<br />
rsync --archive -hh --partial --info=stats1,progress2 --modify-window=1 --remove-source-files "$@"<br />
} }}<br />
<br />
* {{ic|-hh}}: output numbers in a human-readable format<br />
* {{ic|1=--info=stats1,progress2}}: {{ic|stats1}} displays rsync transfer statistics with verbosity level 1. {{ic|progress2}} prints total transfer progress as opposed to per-file transfer progress ({{ic|progress1}})<br />
* {{ic|1=--modify-window=1}}: when comparing the timestamps of two files, treat their timestamps as being equivalent if their timestamps have a difference of less than 1 second<br />
* {{ic|--remove-source-files}}: remove files from the source directory after they have been successfully synced<br />
<br />
{{Note|The use of the term ''checksum'' is '''not''' interchangeable with the behavior of the {{ic|--checksum}} option. The {{ic|--checksum}} option affects the file skip heuristic used prior to any file being transferred. Independent of {{ic|--checksum}}, a ''checksum'' is always used for the block-based file construction which is how rsync transfers a file.}}<br />
<br />
=== Trailing slash caveat ===<br />
<br />
Arch by default uses GNU cp (part of GNU {{Pkg|coreutils}}). However, rsync follows the convention of BSD cp, which gives special treatment to source directories with a trailing slash "/". Whereas<br />
<br />
$ rsync -r source destination<br />
<br />
creates a directory "destination/source" with the contents of "source", the command<br />
<br />
$ rsync -r source/ destination<br />
<br />
copies all of the files in "source/" directly into "destination", with no intervening subdirectory - just as if you had invoked it as<br />
<br />
$ rsync -r source/. destination<br />
<br />
This behavior is different from that of GNU cp, which treats "source" and "source/" identically (but not "source/."). Also, some shells automatically append the trailing slash when tab-completing directory names. Because of these factors, there can be a tendency among new or occasional rsync users to forget about rsync's different behavior, and inadvertently create a mess or even overwrite important files by leaving the trailing slash on the command line.<br />
<br />
Thus it can be prudent to use a wrapper script to automatically remove trailing slashes before invoking rsync:<br />
<br />
#!/bin/bash<br />
new_args=()<br />
for i in "${@}"; do<br />
case "${i}" in<br />
/)<br />
i="/"<br />
;;<br />
*/)<br />
i="${i%/}"<br />
;;<br />
esac<br />
new_args+=("${i}")<br />
done<br />
exec rsync "${new_args[@]}"<br />
<br />
This script can be put somewhere in the path, and aliased to rsync in the shell init file.<br />
<br />
== As a backup utility ==<br />
<br />
The rsync protocol can easily be used for backups, only transferring files that have changed since the last backup. This section describes a very simple scheduled backup script using rsync, typically used for copying to removable media.<br />
<br />
=== Automated backup ===<br />
<br />
For the sake of this example, the script is created in the {{ic|/etc/cron.daily}} directory, and will be run on a daily basis if a cron [[daemon]] is installed and properly configured. Configuring and using [[cron]] is outside the scope of this article.<br />
<br />
First, create a script containing the appropriate command options:<br />
<br />
{{hc|/etc/cron.daily/backup|<br />
#!/bin/sh<br />
rsync -a --delete --quiet /path/to/backup /location/of/backup}}<br />
<br />
* {{ic|-a}}: indicates that files should be archived, meaning that most of their characteristics are preserved (but '''not''' ACLs, hard links or extended attributes such as capabilities)<br />
* {{ic|--delete}}: means files deleted on the source are to be deleted on the backup as well<br />
<br />
Here, {{ic|/path/to/backup}} should be changed to what needs to be backed-up (e.g. {{ic|/home}}) and {{ic|/location/of/backup}} is where the backup should be saved (e.g. {{ic|/media/disk}}).<br />
<br />
Finally, the script must be [[executable]].<br />
<br />
=== Automated backup with SSH ===<br />
<br />
If backing-up to a remote host using [[SSH]], use this script instead:<br />
<br />
{{hc|/etc/cron.daily/backup|<br />
#!/bin/sh<br />
rsync -a --delete --quiet -e ssh /path/to/backup remoteuser@remotehost:/location/of/backup<br />
}}<br />
<br />
* {{ic|-e ssh}}: tells rsync to use SSH<br />
* {{ic|remoteuser}}: is the user on the host {{ic|remotehost}}<br />
* {{ic|-a}}: groups all these options {{ic|-rlptgoD}} (recursive, links, perms, times, group, owner, devices)<br />
<br />
{{Note|<br />
Rsync will try to modify any previously backed up files on the target machine to match their current state at the source machine, with each incremental backup. This means that when backing up files that are owned by root over SSH (and when preserving permissions and ownerships such as with the {{ic|-a}} option), root access to the target machine is needed. The preferred way to achieve this for automation is to set up the SSH daemon to allow root to login using a [https://unix.stackexchange.com/a/92397 public key without password] and run the rsync command as root.}}<br />
<br />
=== Automated backup with NetworkManager ===<br />
<br />
This script starts a backup when network connection is established.<br />
<br />
First, create a script containing the appropriate command options:<br />
<br />
{{hc|/etc/NetworkManager/dispatcher.d/backup|2=<br />
#!/bin/sh<br />
<br />
if [ x"$2" = "xup" ] ; then<br />
rsync --force --ignore-errors -a --delete --bwlimit=2000 --files-from=files.rsync /path/to/backup /location/of/backup<br />
fi<br />
}}<br />
<br />
* {{ic|-a}}: group all this options {{ic|-rlptgoD}} recursive, links, perms, times, group, owner, devices<br />
* {{ic|--files-from}}: read the relative path of {{ic|/path/to/backup}} from this file<br />
* {{ic|--bwlimit}}: limit I/O bandwidth; Kilo-bytes per second<br />
<br />
The script must be owned by root (see [[NetworkManager#Network services with NetworkManager dispatcher]] for details).<br />
<br />
=== Automated backup with systemd and inotify ===<br />
<br />
{{Note|<br />
* Due to the limitations of inotify and systemd (see [https://www.quora.com/Linux-Kernel/Inotify-monitoring-of-directories-is-not-recursive-Is-there-any-specific-reason-for-this-design-in-Linux-kernel this question and answer]), recursive filesystem monitoring is not possible. Although you can watch a directory and its contents, it will not recurse into subdirectories and watch the contents of them; you must explicitly specify every directory to watch, even if that directory is a child of an already watched directory.<br />
* This setup is based on a [[systemd/User]] instance.<br />
}}<br />
<br />
Instead of running time interval backups with time based schedules, such as those implemented in [[cron]], it is possible to run a backup every time one of the files you are backing up changes. {{ic|systemd.path}} units use {{ic|inotify}} to monitor the filesystem, and can be used in conjunction with {{ic|systemd.service}} files to start any process (in this case your rsync backup) based on a filesystem event.<br />
<br />
First, create the {{ic|systemd.path}} unit that will monitor the files you are backing up:<br />
<br />
{{hc|~/.config/systemd/user/backup.path|<nowiki><br />
[Unit]<br />
Description=Checks if paths that are currently being backed up have changed<br />
<br />
[Path]<br />
PathChanged=%h/documents<br />
PathChanged=%h/music<br />
<br />
[Install]<br />
WantedBy=default.target<br />
</nowiki>}}<br />
<br />
Then create a {{ic|systemd.service}} file that will be activated when it detects a change. By default a service file of the same name as the path unit (in this case {{ic|backup.path}}) will be activated, except with the {{ic|.service}} extension instead of {{ic|.path}} (in this case {{ic|backup.service}}).<br />
<br />
{{Note|If you need to run multiple rsync commands, use {{ic|1=Type=oneshot}}. This allows you to specify multiple {{ic|1=ExecStart=}} parameters, one for each rsync command, that will be executed. Alternatively, you can simply write a script to perform all of your backups, just like [[cron]] scripts.}}<br />
<br />
{{hc|~/.config/systemd/user/backup.service|<nowiki><br />
[Unit]<br />
Description=Backs up files<br />
<br />
[Service]<br />
ExecStart=/usr/bin/rsync %h/./documents %h/./music -CERrltm --delete ubuntu:<br />
</nowiki>}}<br />
<br />
Now all you have to do is [[enable/start]] {{ic|backup.path}} like a normal systemd service and it will start monitoring file changes and automatically start {{ic|backup.service}}.<br />
<br />
=== Differential backup on a week ===<br />
<br />
This is a useful option of rsync, resulting in a full backup (on each run) and keeping a differential backup copy of changed files only in a separate directory for each day of a week.<br />
<br />
First, create a script containing the appropriate command options:<br />
<br />
{{hc|/etc/cron.daily/backup|2=<br />
#!/bin/sh<br />
<br />
DAY=$(date +%A)<br />
<br />
if [ -e /location/to/backup/incr/$DAY ] ; then<br />
rm -fr /location/to/backup/incr/$DAY<br />
fi<br />
<br />
rsync -a --delete --quiet --inplace --backup --backup-dir=/location/to/backup/incr/$DAY /path/to/backup/ /location/to/backup/full/<br />
}}<br />
<br />
The {{ic|--inplace}} option implies {{ic|--partial}} and updates destination files in-place.<br />
<br />
=== Snapshot backup ===<br />
<br />
The same idea can be used to maintain a tree of snapshots of your files. In other words, a directory with date-ordered copies of the files. The copies are made using hardlinks, which means that only files that did change will occupy space. Generally speaking, this is the idea behind Apple's TimeMachine.<br />
<br />
This basic script is easy to implement and creates quick incremental snapshots using the {{ic|--link-dest}} option to hardlink unchanged files: <br />
<br />
{{hc|/usr/local/bin/snapbackup.sh|<nowiki><br />
#!/bin/sh<br />
<br />
# Basic snapshot-style rsync backup script <br />
<br />
# Config<br />
OPT="-aPh"<br />
LINK="--link-dest=/snapshots/username/last/" <br />
SRC="/home/username/files/"<br />
SNAP="/snapshots/username/"<br />
LAST="/snapshots/username/last"<br />
date=`date "+%Y-%b-%d:_%T"`<br />
<br />
# Run rsync to create snapshot<br />
rsync $OPT $LINK $SRC ${SNAP}$date<br />
<br />
# Remove symlink to previous snapshot<br />
rm -f $LAST<br />
<br />
# Create new symlink to latest snapshot for the next backup to hardlink<br />
ln -s ${SNAP}$date $LAST<br />
</nowiki>}}<br />
<br />
There must be a symlink to a full backup already in existence as a target for {{ic|--link-dest}}. If the most recent snapshot is deleted, the symlink will need to be recreated to point to the most recent snapshot. If {{ic|--link-dest}} does not find a working symlink, rsync will proceed to copy all source files instead of only the changes. <br />
<br />
A more sophisticated version keeps an up-to-date full backup {{ic|$SNAP/latest}} and in case a certain number of files has changed since the last full backup, it creates a snapshot {{ic|$SNAP/$DATETAG}} of the current full-backup utilizing {{ic|cp -al}} to hardlink unchanged files:<br />
<br />
{{hc|/usr/local/bin/rsnapshot.sh|<nowiki><br />
#!/bin/sh<br />
<br />
## my own rsync-based snapshot-style backup procedure<br />
## (cc) marcio rps AT gmail.com<br />
<br />
# config vars<br />
<br />
SRC="/home/username/files/" #dont forget trailing slash!<br />
SNAP="/snapshots/username"<br />
OPTS="-rltgoi --delay-updates --delete --chmod=a-w"<br />
MINCHANGES=20<br />
<br />
# run this process with real low priority<br />
<br />
ionice -c 3 -p $$<br />
renice +12 -p $$<br />
<br />
# sync<br />
<br />
rsync $OPTS $SRC $SNAP/latest >> $SNAP/rsync.log<br />
<br />
# check if enough has changed and if so<br />
# make a hardlinked copy named as the date<br />
<br />
COUNT=$( wc -l $SNAP/rsync.log|cut -d" " -f1 )<br />
if [ $COUNT -gt $MINCHANGES ] ; then<br />
DATETAG=$(date +%Y-%m-%d)<br />
if [ ! -e $SNAP/$DATETAG ] ; then<br />
cp -al $SNAP/latest $SNAP/$DATETAG<br />
chmod u+w $SNAP/$DATETAG<br />
mv $SNAP/rsync.log $SNAP/$DATETAG<br />
chmod u-w $SNAP/$DATETAG<br />
fi<br />
fi<br />
</nowiki>}}<br />
<br />
To make things really, really simple this script can be run from a [[systemd/Timers]] unit.<br />
<br />
=== Full system backup ===<br />
<br />
This section is about using ''rsync'' to transfer a copy of the entire {{ic|/}} tree, excluding a few selected directories. This approach is considered to be better than [[disk cloning]] with {{ic|dd}} since it allows for a different size, partition table and filesystem to be used, and better than copying with {{ic|cp -a}} as well, because it allows greater control over file permissions, attributes, [[Access Control Lists]] and [[extended attributes]].<br />
<br />
''rsync'' will work even while the system is running, but files changed during the transfer may or may not be transferred, which can cause undefined behavior of some programs using the transferred files.<br />
<br />
This approach works well for migrating an existing installation to a new hard drive or [[SSD]].<br />
<br />
Run the following command as root to make sure that rsync can access all system files and preserve the ownership:<br />
<br />
# rsync -aAXHv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / ''/path/to/backup''<br />
<br />
By using the {{ic|-aAX}} set of options, the files are transferred in archive mode which ensures that symbolic links, devices, permissions, ownerships, modification times, [[ACL]]s, and extended attributes are preserved, assuming that the target [[file system]] supports the feature. The option {{ic|-H}} preserves hard links, but uses more memory.<br />
<br />
The {{ic|--exclude}} option causes files that match the given patterns to be excluded. The directories {{ic|/dev}}, {{ic|/proc}}, {{ic|/sys}}, {{ic|/tmp}}, and {{ic|/run}} are included in the above command, but the ''contents'' of those directories are excluded. This is because they are populated on boot, but the directories themselves are not created. {{ic|/lost+found}} is filesystem-specific. The command above depends on brace expansion available in both the [https://www.gnu.org/software/bash/manual/html_node/Brace-Expansion.html bash] and [http://zsh.sourceforge.net/Doc/Release/Expansion.html#Brace-Expansion zsh] shells. When using a different [[shell]], {{ic|--exclude}} patterns should be repeated manually. Quoting the exclude patterns will avoid expansion by the [[shell]], which is necessary, for example, when backing up over [[SSH]]. Ending the excluded paths with {{ic|*}} ensures that the directories themselves are created if they do not already exist.<br />
<br />
{{Note|<br />
* If you plan on backing up your system somewhere other than {{ic|/mnt}} or {{ic|/media}}, do not forget to add it to the list of exclude patterns to avoid an infinite loop.<br />
* If there are any bind mounts in the system, they should be excluded as well so that the bind mounted contents is copied only once.<br />
* If you use a [[swap file]], make sure to exclude it as well.<br />
* Consider if you want to backup the {{ic|/home/}} directory. If it contains your data it might be considerably larger than the system. Otherwise consider excluding unimportant sub-directories such as {{ic|/home/*/.thumbnails/*}}, {{ic|/home/*/.cache/mozilla/*}}, {{ic|/home/*/.cache/chromium/*}}, and {{ic|/home/*/.local/share/Trash/*}}, depending on software installed on the system.<br />
* If [[GVFS]] is installed, {{ic|/home/*/.gvfs}} must be excluded to prevent rsync errors.<br />
* If [[Dhcpcd]] ≥ 9.0.0 is installed, exclude the {{ic|/var/lib/dhcpcd/*}} directory as it mounts several system directories as sub-directories there.<br />
}}<br />
<br />
You may want to include additional rsync options, or remove some, such as the following. See {{man|1|rsync}} for the full list.<br />
<br />
* If you run on a system with very low memory, consider removing {{ic|-H}} option; however, it should be no problem on most modern machines. There can be many hard links on the file system depending on the software used (e.g. if you are using [[Flatpak]]). Many hard links reside under the {{ic|/usr/}} directory.<br />
* You may want to add rsync's {{ic|--delete}} option if you are running this multiple times to the same backup directory. In this case make sure that the source path does not end with {{ic|/*}}, or this option will only have effect on the files inside the subdirectories of the source directory, but it will have no effect on the files residing directly inside the source directory.<br />
* If you use any sparse files, such as virtual disks, [[Docker]] images and similar, you should add the {{ic|-S}} option.<br />
* The {{ic|--numeric-ids}} option will disable mapping of user and group names; instead, numeric group and user IDs will be transfered. This is useful when backing up over [[SSH]] or when using a live system to backup different system disk.<br />
* Choosing {{ic|1=--info=progress2}} option instead of {{ic|-v}} will show the overall progress info and transfer speed instead of the list of files being transferred.<br />
* To avoid crossing a filesystem boundary when recursing, add the option {{ic|-x}}/{{ic|--one-file-system}}. This will prevent backing up any mount point in the hierarchy.<br />
<br />
=== Restore a backup ===<br />
<br />
If you wish to restore a backup, use the same rsync command that was executed but with the source and destination reversed.<br />
<br />
=== Advanced usage of filter rules ===<br />
<br />
Instead of specifying include and exclude rules separately Rsync can read all of these from a single filter file. Rsync then processes the rules in a top-down order; the first matching rule wins.<br />
<br />
{{hc|backup.filter|<nowiki><br />
# Exclude patterns<br />
<br />
- .thumbnails/***<br />
- node_modules/***<br />
- venv/***<br />
<br />
# Include patterns<br />
<br />
+ /Documents/***<br />
+ /Books/***<br />
+ /Music/***<br />
<br />
# Exclude everything else<br />
- /**<br />
</nowiki>}}<br />
<br />
{{ic|***}} is a special rsync pattern which matches a folder and all of its contents recursively.<br />
<br />
Check {{ic|man rsync → Pattern matching rules}} and also {{ic|Filter rules in depth}} for more details.<br />
<br />
<br />
Then run Rsync with:<br />
<br />
{{hc|backup.sh|<nowiki><br />
/usr/bin/rsync -avHAX \<br />
--delete-after \<br />
--filter="merge backup.filter" \<br />
$SRC $DEST<br />
</nowiki>}}<br />
<br />
The key word is the {{ic|--filter "merge ..."}} parameter which will take the filter file and parse the rules in order for each sync-ed file.<br />
<br />
== File system cloning ==<br />
<br />
rsync provides a way to do a copy of all data in a file system while preserving as much information as possible, including the file system metadata. It is a procedure of data cloning on a file system level where source and destination file systems do not need to be of the same type. It can be used for backing up, file system migration or data recovery.<br />
<br />
rsync's ''archive'' mode comes close to being fit for the job, but it does not back up the special file system metadata such as access control lists, extended attributes or sparse file properties. For successful cloning at the file system level, some additional options need to be provided:<br />
<br />
rsync -qaHAXS SOURCE_DIR DESTINATION_DIR<br />
<br />
And their meaning is (from the manpage):<br />
<br />
--hard-links, -H preserve hard links<br />
--acls, -A preserve ACLs (implies --perms)<br />
--xattrs, -X preserve extended attributes<br />
--sparse, -S turn sequences of nulls into sparse blocks<br />
<br />
Additionally, use {{ic|-x}} if you have other filesystems mounted under the tree that you want to exclude from the copy.<br />
Produced copy can be simply reread and checked (for example after a data recovery attempt) at the file system level with {{ic|diff}}'s recursive option:<br />
<br />
diff -r SOURCE_DIR DESTINATION_DIR<br />
<br />
It is possible to do a successful file system migration by using rsync as described in this article and updating the [[fstab]] and [[bootloader]] as described in [[Migrate installation to new hardware]]. This essentially provides a way to convert any root file system to another one.<br />
<br />
== As a daemon ==<br />
<br />
''rsync'' can be run as [[daemon]] on a server listening on port {{ic|873}}.<br />
<br />
Edit the template {{ic|/etc/rsyncd.conf}}, configure a share and [[start]] the {{ic|rsyncd.service}}.<br />
<br />
{{Note|As of {{Pkg|rsync}} 3.2.0-1 the package adopted the upstream systemd unit files {{ic|rsyncd.service}} and {{ic|rsyncd@.service}}. The change for {{ic|1=ProtectHome}} has been commented, the security feature {{ic|1=ProtectSystem=full}} under the {{ic|[Service]}} section is still active. This makes the {{ic|/boot/}}, {{ic|/etc/}} and {{ic|/usr/}} directories read-only. If you need rsyncd write system directories you can [[edit]] the unit and set {{ic|1=ProtectSystem=off}} in the {{ic|[Service]}} section of the overriding snippet.}}<br />
<br />
Usage from client, e.g. list server content:<br />
<br />
$ rsync rsync://''server/share''<br />
<br />
transfer file from client to server: <br />
<br />
$ rsync ''local-file'' rsync://''server/share/''<br />
<br />
Consider iptables to open port {{ic|873}} and user authentication.<br />
<br />
{{Note|All transferred data including user authentication are not encrypted.}}<br />
<br />
=== Example configuration ===<br />
<br />
==== Sharing from a list of files ====<br />
<br />
{{hc|1=/etc/rsyncd.conf|2=<br />
...<br />
<br />
# Needed when crossing filesystem boundaries.<br />
#use chroot = no<br />
read only = yes<br />
<br />
...<br />
<br />
[sync]<br />
path = /<br />
# List of files to copy.<br />
include from = /backup.list<br />
# Exclude the rest.<br />
exclude = *<br />
}}<br />
<br />
Inside the file list, all the ''intermediary paths'' are necessary, except when the {{ic|***}} wildcard is used:<br />
<br />
{{hc|/backup.list|<br />
/etc/<br />
/etc/conf.d/<br />
/etc/conf.d/hwclock<br />
/etc/fonts/***<br />
}}<br />
<br />
== See also ==<br />
<br />
* More usage examples can be searched in the [https://bbs.archlinux.org/viewforum.php?id=27 Community Contributions] and [https://bbs.archlinux.org/viewforum.php?id=33 General Programming] forums<br />
* [https://www.pointsoftware.ch/2012/09/12/howto-local-and-remote-snapshot-backup-using-rsync-with-hard-links/ Howto – local and remote snapshot backup using rsync with hard links] Includes file deduplication with hard-links, MD5 integrity signature, 'chattr' protection, filter rules, disk quota, retention policy with exponential distribution (backups rotation while saving more recent backups than older)<br />
* [https://stackoverflow.com/questions/5527068/how-do-you-use-an-identity-file-with-rsync Using SSH keys/identity files with rsync]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=LightDM&diff=727621LightDM2022-04-26T11:31:25Z<p>Wooptoo: Remove newline</p>
<hr />
<div>[[Category:Display managers]]<br />
[[Category:Canonical]]<br />
[[de:Login-Manager#LightDM]]<br />
[[fr:LightDM]]<br />
[[ja:LightDM]]<br />
[[ru:LightDM]]<br />
{{Related articles start}}<br />
{{Related|Display manager}}<br />
{{Related|GDM}}<br />
{{Related|LXDM}}<br />
{{Related articles end}}<br />
<br />
[https://github.com/canonical/lightdm LightDM] is a cross-desktop [[display manager]]. Its key features are:<br />
<br />
* Cross-desktop - supports different desktop technologies.<br />
* Supports different display technologies (X, Mir, Wayland ...).<br />
* Lightweight - low memory usage and high performance.<br />
* Supports guest sessions.<br />
* Supports remote login (incoming - [[XDMCP]], [[VNC]], outgoing - XDMCP, [[PAM]]).<br />
* Comprehensive test suite.<br />
* Low code complexity.<br />
<br />
More details about LightDM's design can be found [https://www.freedesktop.org/wiki/Software/LightDM/Design here].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|lightdm}} package.<br />
{{Tip|Stable releases are even-numbered (1.8, 1.10) while development releases are odd-numbered (1.9, 1.11). These development releases are available with {{AUR|lightdm-devel}}. Also available is {{AUR|lightdm-git}}.}}<br />
<br />
=== Greeter ===<br />
<br />
You will probably want to install a greeter. A greeter is a GUI that prompts the user for credentials, lets the user select a session, and so on. It is possible to use LightDM without a greeter, but only if an automatic login is configured; otherwise you will need to install {{pkg|xorg-server}} and one of the greeter packages below.<br />
<br />
The official repositories contain the following greeters:<br />
<br />
* {{Pkg|lightdm-gtk-greeter}}: This is the '''default''' greeter LightDM attempts to use, unless configured otherwise.<br />
* lightdm-deepin-greeter ({{Pkg|deepin-session-shell}}): A greeter from the [[Deepin]] project.<br />
* {{Pkg|lightdm-pantheon-greeter}}: A greeter from the elementary OS project.<br />
* {{Pkg|lightdm-slick-greeter}}: A GTK based greeter focused more on appearance than {{Pkg|lightdm-gtk-greeter}}, forked from {{AUR|lightdm-unity-greeter}}, and default in Linux Mint.<br />
* {{Pkg|lightdm-webkit2-greeter}}: A greeter that uses Webkit2 for theming. It supersedes {{AUR|lightdm-webkit-greeter}}.<br />
* {{Pkg|lightdm-webkit-theme-litarvan}}: A modern and full-featured Webkit2 LightDM theme.<br />
<br />
Other alternative greeters are available in the [[AUR]]:<br />
<br />
* {{AUR|lightdm-unity-greeter}}: The greeter used by Unity.<br />
* {{AUR|lightdm-mini-greeter}}: A minimal, configurable, single-user greeter.<br />
* {{AUR|lightdm-webkit-theme-aether}}: A sleek, straightforward Arch Linux themed login screen written on lightdm and the lightdm-webkit2-greeter.<br />
* {{AUR|lightdm-elephant-greeter-git}}: A small and simple greeter that runs in the {{Pkg|cage}} Wayland compositor per default.<br />
<br />
You can set the default greeter by changing the {{ic|[Seat:*]}} section of the LightDM configuration file, like so:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
...<br />
greeter-session=lightdm-''yourgreeter''-greeter<br />
...<br />
}}<br />
<br />
One way to check which greeters are available is to list the files in the {{ic|/usr/share/xgreeters}} directory; each ''.desktop'' file represents an available greeter. In this example, the {{ic|lightdm-gtk-greeter}} and {{ic|lightdm-webkit2-greeter}} greeters are available:<br />
<br />
$ ls -1 /usr/share/xgreeters/<br />
lightdm-gtk-greeter.desktop<br />
lightdm-webkit2-greeter.desktop<br />
<br />
== Enabling LightDM ==<br />
<br />
Make sure to [[enable]] {{ic|lightdm.service}} so LightDM will be started at boot; see also [[Display manager#Loading the display manager]].<br />
<br />
== Command line tool ==<br />
<br />
LightDM offers a command line tool, {{ic|dm-tool}}, which can be used to lock the current seat, switch sessions, etc, which is useful with 'minimalist' window managers and for testing. To see a list of available commands, execute:<br />
<br />
$ dm-tool --help<br />
<br />
=== User switching ===<br />
<br />
{{Accuracy|Is this warning inappropriate? {{ic|dm-tool lock}} and {{ic|dm-tool switch-to-greeter}} are NOT screen lockers. They only switch to the LightDM greeter and send a notification to lock the session (as {{ic|loginctl lock-session}}). This notification should be processed by a screen locker or redirected by ''xss-lock''. In the absence of a screen locker to listen, there is nothing {{ic|dm-tool ...}} can do - but that's not LightDM's fault. This issue is well known and touched upon [[List_of_applications#Screen_lockers|here]] and [[XScreenSaver#Lock_on_suspend|here]].}}<br />
<br />
{{Warning|1=The use of lightDM's built-in screen lockers like {{ic|dm-tool lock}} or {{ic|dm-tool switch-to-greeter}} are [https://bbs.archlinux.org/viewtopic.php?pid=1712213#p1712213 '''not''' recommended]. Use [[#Lock the screen using light-locker|light-locker]] or something from [[List of applications/Security#Screen lockers]].}}<br />
<br />
LightDM's ''dm-tool'' command can be used to allow multiple users to be logged in on separate ttys. The following will send a signal requesting that the current session be locked and then will initiate a switch to LightDM's greeter, allowing a new user to log in to the system.<br />
<br />
$ dm-tool switch-to-greeter<br />
<br />
== Testing ==<br />
<br />
First, [[install]] {{Pkg|xorg-server-xephyr}} from the [[official repositories]].<br />
<br />
Then, run LightDM as an X application:<br />
<br />
$ lightdm --test-mode --debug<br />
<br />
== Optional configuration and tweaks ==<br />
<br />
LightDM can be configured by modifying its configuration file, {{ic|/etc/lightdm/lightdm.conf}}.<br />
<br />
Some greeters have their own configuration files. For example:<br />
<br />
{{Pkg|lightdm-gtk-greeter}}: {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} (or you can use the {{Pkg|lightdm-gtk-greeter-settings}} gui).<br />
<br />
{{Pkg|lightdm-webkit2-greeter}}: {{ic|/etc/lightdm/lightdm-webkit2-greeter.conf}}<br />
<br />
=== X session wrapper ===<br />
<br />
{{Merge|Xprofile|Duplicated information}}<br />
<br />
If you are migrating from [[xinit]], you will notice that the display is not launched by your shell. This is because, as opposed to your shell starting the display (and the display inheriting the environment of your shell), LightDM starts your display and does not source your shell. LightDM launches the display by running a wrapper script and that finally exec's your graphic environment. By default, {{ic|/etc/lightdm/Xsession}} is run.<br />
<br />
==== Environment variables ====<br />
<br />
The script checks and sources {{ic|/etc/profile}}, {{ic|~/.profile}}, {{ic|/etc/xprofile}} and {{ic|~/.xprofile}}, in that order. If you are using a shell that does not source any of these files, you can create an {{ic|~/.xprofile}} to do so. (In this example, the login shell is [[zsh]])<br />
<br />
{{hc|~/.xprofile|2=<br />
#!/bin/sh<br />
<nowiki>[ -f ~/.config/zsh/.zshenv ] && . ~/.config/zsh/.zshenv</nowiki><br />
}}<br />
<br />
If you have shell variables that are important for your display (such as Gtk or QT themes, GNUPG location, configuration overrides, etc.) this will let your graphic environment have access to your environment without having to be launched by your login shell.<br />
<br />
==== Keymap ====<br />
<br />
The script runs [[Xkbmap]] with arguments provided in files {{ic|/etc/X11/Xkbmap}}, {{ic|~/.Xkbmap}}. If those files are not found, it runs [[xmodmap]] with {{ic|/etc/X11/Xmodmap}}, {{ic|~/.Xmodmap}}. If using xkbmap, the files are parsed using cat. The following example works<br />
<br />
{{hc|~/.Xmodmap|2=<br />
-model pc105 -layout us,us,tr -variant ,dvorak,f -option grp:caps_toggle<br />
}}<br />
<br />
Otherwise, the session inherits the system default mapping of X11. This mapping can be defined in the xorg configuration files, either manually or with {{ic|localectl set-x11-keymap}}. See [[Xorg/Keyboard configuration#Setting keyboard layout]].<br />
<br />
==== Multiple keyboard layouts in lightdm-gtk-greeter ====<br />
<br />
To enable users switch between pre-defined keyboard layouts on the log-in screen enable the drop-down menu and configure the layouts. Either use the {{Pkg|lightdm-gtk-greeter-settings}} gui or edit the configuration file directly:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
indicators = ~hosts;~spacer;~clock;~spacer;~layout;~language;~session;~ally;~power<br />
}}<br />
<br />
Use [[Xorg/Keyboard_configuration#Using_localectl|localectl]] to set multiple layouts, e.g. de and its “variant” neo with the latter as primary:<br />
<br />
# localectl --no-convert set-x11-keymap de,de pc105 neo,<br />
<br />
Note the trailing comma which implies a blank variant for the second de.<br />
<br />
=== Changing background images/colors ===<br />
<br />
You can set the background to a hex color or an image. Some greeters offer more robust background options like background selection from the login screen, random backgrounds, etc.<br />
<br />
==== GTK greeter ====<br />
<br />
You can use the {{Pkg|lightdm-gtk-greeter-settings}} gui.<br />
<br />
Users wishing to customize the wallpaper on the greeter screen need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and define the {{ic|background}} variable under the {{ic|[greeter]}} section. For example:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
background=/usr/share/pixmaps/black_and_white_photography-wallpaper-1920x1080.jpg<br />
}}<br />
<br />
{{Note|It is recommended to place the PNG or JPG file in {{ic|/usr/share/pixmaps}} since the LightDM user needs read access to the wallpaper file.}}<br />
<br />
===== GTK3 Theme =====<br />
<br />
GTK3 themes can be specified with the {{ic|theme-name}} variable in the {{ic|[greeter]}} section of {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} For example, {{ic|1=theme-name=Adwaita-dark}}.<br />
<br />
==== Webkit2 greeter ====<br />
<br />
The {{Pkg|lightdm-webkit2-greeter}} allows you to choose a background image directly on the login screen. It also offers an option to display a random image each time it starts if you use the [https://github.com/artur9010/lightdm-webkit-material Material theme]. By default, images are sourced from {{ic|/usr/share/backgrounds}}. You can change the background images directory by editing {{ic|lightdm-webkit2-greeter.conf}}. For example:<br />
{{hc|/etc/lightdm/lightdm-webkit2-greeter.conf|2=<br />
[branding]<br />
background_images = /usr/share/backgrounds<br />
}}<br />
<br />
{{Note|The background images directory must be accessible to the LightDM user so it should not be located anywhere under {{ic|/home}}. }}<br />
<br />
==== Unity greeter ====<br />
<br />
Users using the {{AUR|lightdm-unity-greeter}} must edit the {{ic|/usr/share/glib-2.0/schemas/com.canonical.unity-greeter.gschema.xml}} file and then execute:<br />
<br />
# glib-compile-schemas /usr/share/glib-2.0/schemas/<br />
<br />
According to [https://bbs.archlinux.org/viewtopic.php?id=149945 this] page.<br />
<br />
==== Slick Greeter ====<br />
<br />
Use the {{AUR|lightdm-settings}} GUI<br />
<br />
=== Changing your avatar ===<br />
<br />
First, make sure the {{Pkg|accountsservice}} package from the [[official repositories]] is installed, then set it up as follows, replacing {{ic|''username''}} with the desired user's login name.<br />
<br />
* Create the file {{ic|/var/lib/AccountsService/icons/''username''.png}} using a 96x96 PNG image file. Different image file formats are possible too, e.g., JPEG.<br />
* Alternatively, create the image file as {{ic|/home/''username''/.face}} and skip the next step if the defaults already point to the user home directory path<br />
* Edit or create the account settings file {{ic|/var/lib/AccountsService/users/''username''}}, and add the lines<br />
<br />
[User]<br />
Icon=/var/lib/AccountsService/icons/''username''.png<br />
<br />
The filename here should point to the icon created in the first step, so adjust the filename extension if necessary.<br />
<br />
{{Note|Make sure that both created files have 644 permissions, use [[chmod]] to correct them.}}<br />
<br />
=== Sources of Arch-centric 64x64 icons ===<br />
<br />
The {{AUR|archlinux-artwork}} package contains some nice examples that install to {{ic|/usr/share/archlinux/icons}} and that can be copied to {{ic|/usr/share/icons/hicolor/64x64/devices}} as follows:<br />
<br />
# find /usr/share/archlinux/icons -name "*64*" -exec cp {} /usr/share/icons/hicolor/64x64/devices \;<br />
<br />
After copying, the {{AUR|archlinux-artwork}} package can be removed.<br />
<br />
=== Enabling autologin ===<br />
<br />
Edit the LightDM configuration file and ensure these lines are uncommented and correctly configured:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
}}<br />
<br />
You must be part of the {{ic|autologin}} group to be able to login automatically without entering your password:<br />
<br />
# groupadd -r autologin<br />
# gpasswd -a ''username'' autologin<br />
<br />
LightDM logs in using the session specified in the {{ic|~/.dmrc}} of the user getting logged in automatically. To override this file, specify {{ic|autologin-session}} in {{ic|lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
autologin-session=''session''<br />
}}<br />
<br />
The list of valid session names can be found by listing {{ic|/usr/share/xsessions/*.desktop}} for X's sessions and {{ic|/usr/share/wayland-sessions/*.desktop}} for Wayland's.<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user will have to set up a blank password to their keyring for it to be unlocked automatically.}}<br />
<br />
=== Enabling interactive passwordless login ===<br />
<br />
LightDM goes through [[PAM]] so you must configure the lightdm configuration of PAM:<br />
<br />
{{hc|/etc/pam.d/lightdm|2=<br />
#%PAM-1.0<br />
'''auth sufficient pam_succeed_if.so user ingroup nopasswdlogin'''<br />
auth include system-login<br />
...<br />
}}<br />
<br />
You must then also be part of the {{ic|nopasswdlogin}} group to be able to login interactively without entering your password:<br />
<br />
# groupadd -r nopasswdlogin<br />
# gpasswd -a ''username'' nopasswdlogin<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user may have to follow the instructions at the end of the previous section on enabling autologin.}}<br />
<br />
To create a new user account that logs in automatically and additionally able to login again without a password the user can be created with supplementary membership of both groups, e.g.:<br />
<br />
# useradd -mG autologin,nopasswdlogin -s /bin/bash ''username''<br />
<br />
=== Enabling guest sessions ===<br />
<br />
{{Note|A guest user has passwordless access to your system after enabling this feature.}} <br />
<br />
To enable guest sessions in LightDM (without changing your system configuration) you need at least two things:<br />
<br />
# a '''guest-account-script''': defaults to {{ic|guest-account}} and accepts two commands:<br />
#* '''add''' (to create a temporary guest system account and returns the user name of the created account)<br />
#* '''remove''' ''account name''(to delete the corresponding account)<br />
# an [[#Enabling autologin|'''autologin''']] group to which the created guest account must be added (cf. {{ic|/etc/pam.d/lightdm-autologin}})<br />
<br />
There are two AUR packages that enable guest sessions in lightdm:<br />
<br />
* {{aur|lightdm-guest}} which provides the (largely unmodified) upstream guest-session script as well as {{pkg|lightdm}} itself.<br />
* {{aur|lightdm-guest-account}} which provides only a minimal version of the script.<br />
<br />
=== Hiding system and services users ===<br />
<br />
To prevent system users from showing-up in the login, install the optional dependency {{Pkg|accountsservice}}, or add the user names to {{ic|/etc/lightdm/users.conf}} under {{ic|hidden-users}}. The first option has the advantage of not needing to update the list when more users are added or removed.<br />
<br />
=== Migrating from SLiM ===<br />
<br />
{{Merge|Display Manager|Not LightDM specific (or even SLiM specific for that matter as [[XDM]] also uses [[xinitrc]]). Perhaps this merits a one-liner somewhere on the [[Display Manager]] page?}}<br />
<br />
Move the contents of [[xinitrc]] to [[xprofile]], removing the call to start the [[window manager]] or [[desktop environment]].<br />
<br />
=== Login using ~/.xinitrc ===<br />
<br />
See [[Display manager#Run ~/.xinitrc as a session]].<br />
<br />
=== NumLock on by default ===<br />
<br />
Install the {{Pkg|numlockx}} package and then edit {{ic|/etc/lightdm/lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
greeter-setup-script=/usr/bin/numlockx on<br />
}}<br />
<br />
=== Default session ===<br />
<br />
Lightdm, like other DMs, stores the last-selected xsession in {{ic|~/.dmrc}}. See [[Display manager#Session configuration]] for more info.<br />
<br />
=== Adjusting the login window's position ===<br />
<br />
==== GTK greeter ====<br />
<br />
Users need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and enter a value for the {{ic|position}} variable. It accepts {{ic|x}} and {{ic|y}} values, either absolute (in pixels) or relative (in percent). Each value can also have an additional anchor location for the window, {{ic|start}}, {{ic|center}} and {{ic|end}} separated from the value by a comma.<br />
<br />
Example:<br />
<br />
position=200,start 50%,center<br />
<br />
=== VNC Server ===<br />
<br />
Lightdm can also be used to connect to via VNC. Make sure to install {{pkg|tigervnc}} on the server side and optionally as your VNC client on the client PC.<br />
<br />
Setup an authentication password on the server as root:<br />
<br />
# vncpasswd /etc/vncpasswd<br />
<br />
Edit the LightDM configuration file as shown below. Note that {{ic|listen-address}} configures the VNC to only listen to connections from localhost. This is used to only allow connections via [[TigerVNC#On_the_client|SSH and port forwarding]]. On the SSH client, make sure that you use {{ic|localhost:5900}} for the tunnel destination; using {{ic|127.0.0.1:5900}} or {{ic|::1:5900}} is not reliable on dual stack network connections. If you want to allow insecure connections you can disable this setting.<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[VNCServer]<br />
enabled=true<br />
command=Xvnc -rfbauth /etc/vncpasswd<br />
port=5900<br />
listen-address=localhost<br />
width=1024<br />
height=768<br />
depth=24<br />
}}<br />
<br />
Now open an SSH tunnel and connect to localhost as described in [[TigerVNC#On the client]].<br />
<br />
{{Note|If you get a blank screen upon opening the VNC connection, try a different LightDM greeter.}}<br />
<br />
=== Lock the screen using light-locker ===<br />
<br />
{{Pkg|light-locker}} is a simple screen locker using LightDM to authenticate the user. Once installed and running, you can lock your session via:<br />
<br />
$ light-locker-command -l<br />
<br />
This requires {{ic|light-locker}} to be started at the beginning of your session. By default, this is enabled through [[XDG Autostart]]. See [[Autostarting]] for more options.<br />
<br />
=== Multiple-monitor setup ===<br />
<br />
Sometimes LightDM does not set the monitor resolution correctly on a multiple-monitor setup. The following Xorg configuration works with two monitors: a large primary screen on the left side, and a secondary smaller screen to its right. The order can be reversed and tweaked.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/52-resolution-fix.conf|2=<br />
Section "Monitor"<br />
Identifier "DP1"<br />
Option "PreferredMode" "3840x2160"<br />
Option "Primary" "1"<br />
EndSection<br />
Section "Monitor"<br />
Identifier "eDP1"<br />
Option "PreferredMode" "1920x1080"<br />
Option "RightOf" "DP1"<br />
EndSection<br />
}}<br />
<br />
This makes the {{ic|display-setup-script}} tweaks from {{ic|/etc/lightdm/lightdm.conf}} redundant.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Autologin does not work ===<br />
<br />
Ensure {{ic|1=autologin-user=}} in {{ic|/etc/lightdm/lightdm.conf}} contain the correct values. Trailing whitespace will cause errors.<br />
<br />
If autologin fails with a blank screen or if the login screen immediately returns, you may need to set {{ic|1=logind-check-graphical=true}}.<br />
<br />
You can also install {{AUR|lightdm-autologin-greeter-git}} for this special purpose.<br />
<br />
=== Viewing current configuration ===<br />
<br />
To view effective configuration, run:<br />
<br />
$ lightdm --show-config<br />
<br />
This will show current settings, with the configuration files these settings were read from.<br />
<br />
=== LightDM not starting and screen flashing ===<br />
<br />
If you encounter consistent screen flashing and ultimately no LightDM on boot, ensure that you have defined the greeter correctly in LightDM's configuration file. And if you have correctly defined the GTK greeter, make sure the {{ic|xsessions-directory}} (default: {{ic|/usr/share/xsessions}}) exists and contains at least one .desktop file.<br />
<br />
The same error can happen on lightdm startup if the last used session is not available anymore (eg. you last used gnome and then removed the gnome-session package): the easiest workaround is to temporarily restore the removed package. Another solution might be:<br />
<br />
# dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User.SetXSession string:xfce<br />
<br />
This example sets the session "xfce" as default for the user 1000.<br />
<br />
=== Wrong locale displayed ===<br />
<br />
In case of your locale not being displayed correctly in Lightdm add your locale to {{ic|/etc/environment}}:<br />
<br />
LANG=pt_PT.utf8<br />
<br />
Alternatively if you want LightDM and its greeters to be in a language other than your set system locale, you can use the {{ic|1=Environment=}} option in [[Systemd#Drop-in files]].<br />
<br />
=== Unresponsive for a few minutes after startup ===<br />
<br />
You may have to download more entropy. Install and enable haveged, c.f. https://github.com/canonical/lightdm/issues/17<br />
<br />
=== Missing icons with GTK greeter ===<br />
<br />
If you are using {{Pkg|lightdm-gtk-greeter}} as a greeter and it shows placeholder images as icons, make sure valid icon themes and themes are installed and configured. Check the following file:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
theme-name=mate # this should be the name of a directory under /usr/share/themes/<br />
icon-theme-name=mate # this should be the name of a fully featured icons set directory under /usr/share/icons/<br />
}}<br />
<br />
=== Using a custom icon and cursor theme with GTK greeter ===<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
theme-name = Adwaita<br />
icon-theme-name = Adwaita41<br />
cursor-theme-name = Adwaita41<br />
cursor-theme-size = 32<br />
font-name = Lato 20<br />
}}<br />
<br />
=== LightDM freezes on login attempt ===<br />
<br />
You may find that after entering the correct username and password and attempting to log in, LightDM freezes and you are unable to continue to the desktop. To fix the issue, reinstall the {{Pkg|gdk-pixbuf2}} package. See [https://bbs.archlinux.org/viewtopic.php?id=179031 this forum thread].<br />
<br />
=== LightDM displaying in wrong monitor ===<br />
<br />
If you are using multiple monitors, LightDM may display in the wrong one (e.g. if your primary monitor is on the right). To force the LightDM login screen to display on a specific monitor, edit {{ic|/etc/lightdm/lightdm.conf}} and change the ''display-setup-script'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
display-setup-script=xrandr --output ''HDMI1'' --primary<br />
}}<br />
<br />
Replace ''HDMI1'' with your real monitor ID, which you can find from '''xrandr''' command output.<br />
<br />
Alternatively, if you are using the GTK greeter, you can edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and add the ''active-monitor'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
active-monitor=0<br />
}}<br />
<br />
Replace 0 with the desired display number.<br />
<br />
=== LightDM does not appear or monitor only displays TTY output ===<br />
<br />
It may happen that your system boots so fast that LightDM service is started before your graphics drivers are properly loaded. If this is your case, you will want to add the following to your {{ic|lightdm.conf}} file:<br />
<br />
[LightDM]<br />
logind-check-graphical=true<br />
<br />
This setting will tell LightDM to wait until graphics devices are ready before spawning greeters/autostarting sessions on them.<br />
<br />
=== LightDM is running with low FPS on Intel Graphics ===<br />
<br />
See [[Intel graphics#AccelMethod]].<br />
<br />
=== Pulseaudio not starting automatically ===<br />
<br />
See [[PulseAudio#Running]].<br />
<br />
=== Long pause before LightDM shows up when home is encrypted ===<br />
<br />
Some LightDM themes try to access the user avatar located in HOME. If your HOME is encrypted, LightDM cannot access it and hangs. To prevent this from happening, you can either:<br />
<br />
* Set your avatar as explained in [[#Changing your avatar]]<br />
* for {{Pkg|lightdm-gtk-greeter}} only: {{Ic|<nowiki>hide-user-image = true</nowiki>}} in {{Ic|/etc/lightdm/lightdm-gtk-greeter.conf}}<br />
<br />
=== Boot hangs on "[ OK ] Reached target Graphical Interface." ===<br />
<br />
There is a possibility that user and group lookups fail if you modified /etc/nsswitch.conf. That happens when:<br />
<br />
* nsswitch.conf group: includes {{Ic|<nowiki>ldap</nowiki>}} without setting {{Ic|<nowiki>nss_initgroups_ignoreusers ALLLOCAL</nowiki>}} in {{Ic|<nowiki>/etc/nslcd.conf</nowiki>}}<br />
<br />
=== Wayland session not working with duplicate GNOME entries in greeter ===<br />
<br />
* Some greeters ({{Pkg|lightdm-webkit2-greeter}} for example) do not support two sessions with the same name [https://github.com/CanonicalLtd/lightdm/issues/16]. To check for duplicate entries:<br />
<br />
$ ls -1 /usr/share/wayland-sessions /usr/share/xsessions<br />
<br />
* Rename the duplicate entry in /usr/share/xsessions. For example:<br />
<br />
# mv /usr/share/xsessions/gnome.desktop /usr/share/xsessions/gnome.desktop.disabled<br />
<br />
=== Login always segfaults on first attempt ===<br />
<br />
Set a hostname as described in [[Network_configuration#Set_the_hostname|Network Page]]. See also {{Bug|47694}}.<br />
<br />
=== Infinite login loop ===<br />
<br />
If you get stuck in loop in which you type your correct user and password but the screen goes black and the you are back in the login after every attempt, running {{ic|rm ~/.Xauthority}} (or the stuck user's problematic {{ic|.Xauthority}}) may fix the issue.<br />
<br />
Another reason for this may be that you tried to recreate your "lightdm.conf" from scratch and your version is missing this line:<br />
<br />
session-wrapper=/etc/lightdm/Xsession<br />
<br />
In that case, lightdm tries to use "lightdm-session" as the session-wrapper which does not exist on Arch Linux.<br />
<br />
== See also ==<br />
<br />
* [https://wiki.ubuntu.com/LightDM Ubuntu Wiki article]<br />
* [[Gentoo:LightDM]]<br />
* [https://launchpad.net/lightdm Launchpad Page] obsolete<br />
* https://wiki.ubuntu.com/MattFischer<br />
* [https://github.com/CanonicalLtd/lightdm LightDM on GitHub]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=LightDM&diff=727620LightDM2022-04-26T11:30:12Z<p>Wooptoo: Added Using a custom icon and cursor theme with GTK greeter</p>
<hr />
<div>[[Category:Display managers]]<br />
[[Category:Canonical]]<br />
[[de:Login-Manager#LightDM]]<br />
[[fr:LightDM]]<br />
[[ja:LightDM]]<br />
[[ru:LightDM]]<br />
{{Related articles start}}<br />
{{Related|Display manager}}<br />
{{Related|GDM}}<br />
{{Related|LXDM}}<br />
{{Related articles end}}<br />
<br />
[https://github.com/canonical/lightdm LightDM] is a cross-desktop [[display manager]]. Its key features are:<br />
<br />
* Cross-desktop - supports different desktop technologies.<br />
* Supports different display technologies (X, Mir, Wayland ...).<br />
* Lightweight - low memory usage and high performance.<br />
* Supports guest sessions.<br />
* Supports remote login (incoming - [[XDMCP]], [[VNC]], outgoing - XDMCP, [[PAM]]).<br />
* Comprehensive test suite.<br />
* Low code complexity.<br />
<br />
More details about LightDM's design can be found [https://www.freedesktop.org/wiki/Software/LightDM/Design here].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|lightdm}} package.<br />
{{Tip|Stable releases are even-numbered (1.8, 1.10) while development releases are odd-numbered (1.9, 1.11). These development releases are available with {{AUR|lightdm-devel}}. Also available is {{AUR|lightdm-git}}.}}<br />
<br />
=== Greeter ===<br />
<br />
You will probably want to install a greeter. A greeter is a GUI that prompts the user for credentials, lets the user select a session, and so on. It is possible to use LightDM without a greeter, but only if an automatic login is configured; otherwise you will need to install {{pkg|xorg-server}} and one of the greeter packages below.<br />
<br />
The official repositories contain the following greeters:<br />
<br />
* {{Pkg|lightdm-gtk-greeter}}: This is the '''default''' greeter LightDM attempts to use, unless configured otherwise.<br />
* lightdm-deepin-greeter ({{Pkg|deepin-session-shell}}): A greeter from the [[Deepin]] project.<br />
* {{Pkg|lightdm-pantheon-greeter}}: A greeter from the elementary OS project.<br />
* {{Pkg|lightdm-slick-greeter}}: A GTK based greeter focused more on appearance than {{Pkg|lightdm-gtk-greeter}}, forked from {{AUR|lightdm-unity-greeter}}, and default in Linux Mint.<br />
* {{Pkg|lightdm-webkit2-greeter}}: A greeter that uses Webkit2 for theming. It supersedes {{AUR|lightdm-webkit-greeter}}.<br />
* {{Pkg|lightdm-webkit-theme-litarvan}}: A modern and full-featured Webkit2 LightDM theme.<br />
<br />
Other alternative greeters are available in the [[AUR]]:<br />
<br />
* {{AUR|lightdm-unity-greeter}}: The greeter used by Unity.<br />
* {{AUR|lightdm-mini-greeter}}: A minimal, configurable, single-user greeter.<br />
* {{AUR|lightdm-webkit-theme-aether}}: A sleek, straightforward Arch Linux themed login screen written on lightdm and the lightdm-webkit2-greeter.<br />
* {{AUR|lightdm-elephant-greeter-git}}: A small and simple greeter that runs in the {{Pkg|cage}} Wayland compositor per default.<br />
<br />
You can set the default greeter by changing the {{ic|[Seat:*]}} section of the LightDM configuration file, like so:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
...<br />
greeter-session=lightdm-''yourgreeter''-greeter<br />
...<br />
}}<br />
<br />
One way to check which greeters are available is to list the files in the {{ic|/usr/share/xgreeters}} directory; each ''.desktop'' file represents an available greeter. In this example, the {{ic|lightdm-gtk-greeter}} and {{ic|lightdm-webkit2-greeter}} greeters are available:<br />
<br />
$ ls -1 /usr/share/xgreeters/<br />
lightdm-gtk-greeter.desktop<br />
lightdm-webkit2-greeter.desktop<br />
<br />
== Enabling LightDM ==<br />
<br />
Make sure to [[enable]] {{ic|lightdm.service}} so LightDM will be started at boot; see also [[Display manager#Loading the display manager]].<br />
<br />
== Command line tool ==<br />
<br />
LightDM offers a command line tool, {{ic|dm-tool}}, which can be used to lock the current seat, switch sessions, etc, which is useful with 'minimalist' window managers and for testing. To see a list of available commands, execute:<br />
<br />
$ dm-tool --help<br />
<br />
=== User switching ===<br />
<br />
{{Accuracy|Is this warning inappropriate? {{ic|dm-tool lock}} and {{ic|dm-tool switch-to-greeter}} are NOT screen lockers. They only switch to the LightDM greeter and send a notification to lock the session (as {{ic|loginctl lock-session}}). This notification should be processed by a screen locker or redirected by ''xss-lock''. In the absence of a screen locker to listen, there is nothing {{ic|dm-tool ...}} can do - but that's not LightDM's fault. This issue is well known and touched upon [[List_of_applications#Screen_lockers|here]] and [[XScreenSaver#Lock_on_suspend|here]].}}<br />
<br />
{{Warning|1=The use of lightDM's built-in screen lockers like {{ic|dm-tool lock}} or {{ic|dm-tool switch-to-greeter}} are [https://bbs.archlinux.org/viewtopic.php?pid=1712213#p1712213 '''not''' recommended]. Use [[#Lock the screen using light-locker|light-locker]] or something from [[List of applications/Security#Screen lockers]].}}<br />
<br />
LightDM's ''dm-tool'' command can be used to allow multiple users to be logged in on separate ttys. The following will send a signal requesting that the current session be locked and then will initiate a switch to LightDM's greeter, allowing a new user to log in to the system.<br />
<br />
$ dm-tool switch-to-greeter<br />
<br />
== Testing ==<br />
<br />
First, [[install]] {{Pkg|xorg-server-xephyr}} from the [[official repositories]].<br />
<br />
Then, run LightDM as an X application:<br />
<br />
$ lightdm --test-mode --debug<br />
<br />
== Optional configuration and tweaks ==<br />
<br />
LightDM can be configured by modifying its configuration file, {{ic|/etc/lightdm/lightdm.conf}}.<br />
<br />
Some greeters have their own configuration files. For example:<br />
<br />
{{Pkg|lightdm-gtk-greeter}}: {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} (or you can use the {{Pkg|lightdm-gtk-greeter-settings}} gui).<br />
<br />
{{Pkg|lightdm-webkit2-greeter}}: {{ic|/etc/lightdm/lightdm-webkit2-greeter.conf}}<br />
<br />
=== X session wrapper ===<br />
<br />
{{Merge|Xprofile|Duplicated information}}<br />
<br />
If you are migrating from [[xinit]], you will notice that the display is not launched by your shell. This is because, as opposed to your shell starting the display (and the display inheriting the environment of your shell), LightDM starts your display and does not source your shell. LightDM launches the display by running a wrapper script and that finally exec's your graphic environment. By default, {{ic|/etc/lightdm/Xsession}} is run.<br />
<br />
==== Environment variables ====<br />
<br />
The script checks and sources {{ic|/etc/profile}}, {{ic|~/.profile}}, {{ic|/etc/xprofile}} and {{ic|~/.xprofile}}, in that order. If you are using a shell that does not source any of these files, you can create an {{ic|~/.xprofile}} to do so. (In this example, the login shell is [[zsh]])<br />
<br />
{{hc|~/.xprofile|2=<br />
#!/bin/sh<br />
<nowiki>[ -f ~/.config/zsh/.zshenv ] && . ~/.config/zsh/.zshenv</nowiki><br />
}}<br />
<br />
If you have shell variables that are important for your display (such as Gtk or QT themes, GNUPG location, configuration overrides, etc.) this will let your graphic environment have access to your environment without having to be launched by your login shell.<br />
<br />
==== Keymap ====<br />
<br />
The script runs [[Xkbmap]] with arguments provided in files {{ic|/etc/X11/Xkbmap}}, {{ic|~/.Xkbmap}}. If those files are not found, it runs [[xmodmap]] with {{ic|/etc/X11/Xmodmap}}, {{ic|~/.Xmodmap}}. If using xkbmap, the files are parsed using cat. The following example works<br />
<br />
{{hc|~/.Xmodmap|2=<br />
-model pc105 -layout us,us,tr -variant ,dvorak,f -option grp:caps_toggle<br />
}}<br />
<br />
Otherwise, the session inherits the system default mapping of X11. This mapping can be defined in the xorg configuration files, either manually or with {{ic|localectl set-x11-keymap}}. See [[Xorg/Keyboard configuration#Setting keyboard layout]].<br />
<br />
==== Multiple keyboard layouts in lightdm-gtk-greeter ====<br />
<br />
To enable users switch between pre-defined keyboard layouts on the log-in screen enable the drop-down menu and configure the layouts. Either use the {{Pkg|lightdm-gtk-greeter-settings}} gui or edit the configuration file directly:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
indicators = ~hosts;~spacer;~clock;~spacer;~layout;~language;~session;~ally;~power<br />
}}<br />
<br />
Use [[Xorg/Keyboard_configuration#Using_localectl|localectl]] to set multiple layouts, e.g. de and its “variant” neo with the latter as primary:<br />
<br />
# localectl --no-convert set-x11-keymap de,de pc105 neo,<br />
<br />
Note the trailing comma which implies a blank variant for the second de.<br />
<br />
=== Changing background images/colors ===<br />
<br />
You can set the background to a hex color or an image. Some greeters offer more robust background options like background selection from the login screen, random backgrounds, etc.<br />
<br />
==== GTK greeter ====<br />
<br />
You can use the {{Pkg|lightdm-gtk-greeter-settings}} gui.<br />
<br />
Users wishing to customize the wallpaper on the greeter screen need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and define the {{ic|background}} variable under the {{ic|[greeter]}} section. For example:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
background=/usr/share/pixmaps/black_and_white_photography-wallpaper-1920x1080.jpg<br />
}}<br />
<br />
{{Note|It is recommended to place the PNG or JPG file in {{ic|/usr/share/pixmaps}} since the LightDM user needs read access to the wallpaper file.}}<br />
<br />
===== GTK3 Theme =====<br />
<br />
GTK3 themes can be specified with the {{ic|theme-name}} variable in the {{ic|[greeter]}} section of {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} For example, {{ic|1=theme-name=Adwaita-dark}}.<br />
<br />
==== Webkit2 greeter ====<br />
<br />
The {{Pkg|lightdm-webkit2-greeter}} allows you to choose a background image directly on the login screen. It also offers an option to display a random image each time it starts if you use the [https://github.com/artur9010/lightdm-webkit-material Material theme]. By default, images are sourced from {{ic|/usr/share/backgrounds}}. You can change the background images directory by editing {{ic|lightdm-webkit2-greeter.conf}}. For example:<br />
{{hc|/etc/lightdm/lightdm-webkit2-greeter.conf|2=<br />
[branding]<br />
background_images = /usr/share/backgrounds<br />
}}<br />
<br />
{{Note|The background images directory must be accessible to the LightDM user so it should not be located anywhere under {{ic|/home}}. }}<br />
<br />
==== Unity greeter ====<br />
<br />
Users using the {{AUR|lightdm-unity-greeter}} must edit the {{ic|/usr/share/glib-2.0/schemas/com.canonical.unity-greeter.gschema.xml}} file and then execute:<br />
<br />
# glib-compile-schemas /usr/share/glib-2.0/schemas/<br />
<br />
According to [https://bbs.archlinux.org/viewtopic.php?id=149945 this] page.<br />
<br />
==== Slick Greeter ====<br />
<br />
Use the {{AUR|lightdm-settings}} GUI<br />
<br />
=== Changing your avatar ===<br />
<br />
First, make sure the {{Pkg|accountsservice}} package from the [[official repositories]] is installed, then set it up as follows, replacing {{ic|''username''}} with the desired user's login name.<br />
<br />
* Create the file {{ic|/var/lib/AccountsService/icons/''username''.png}} using a 96x96 PNG image file. Different image file formats are possible too, e.g., JPEG.<br />
* Alternatively, create the image file as {{ic|/home/''username''/.face}} and skip the next step if the defaults already point to the user home directory path<br />
* Edit or create the account settings file {{ic|/var/lib/AccountsService/users/''username''}}, and add the lines<br />
<br />
[User]<br />
Icon=/var/lib/AccountsService/icons/''username''.png<br />
<br />
The filename here should point to the icon created in the first step, so adjust the filename extension if necessary.<br />
<br />
{{Note|Make sure that both created files have 644 permissions, use [[chmod]] to correct them.}}<br />
<br />
=== Sources of Arch-centric 64x64 icons ===<br />
<br />
The {{AUR|archlinux-artwork}} package contains some nice examples that install to {{ic|/usr/share/archlinux/icons}} and that can be copied to {{ic|/usr/share/icons/hicolor/64x64/devices}} as follows:<br />
<br />
# find /usr/share/archlinux/icons -name "*64*" -exec cp {} /usr/share/icons/hicolor/64x64/devices \;<br />
<br />
After copying, the {{AUR|archlinux-artwork}} package can be removed.<br />
<br />
=== Enabling autologin ===<br />
<br />
Edit the LightDM configuration file and ensure these lines are uncommented and correctly configured:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
}}<br />
<br />
You must be part of the {{ic|autologin}} group to be able to login automatically without entering your password:<br />
<br />
# groupadd -r autologin<br />
# gpasswd -a ''username'' autologin<br />
<br />
LightDM logs in using the session specified in the {{ic|~/.dmrc}} of the user getting logged in automatically. To override this file, specify {{ic|autologin-session}} in {{ic|lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
autologin-session=''session''<br />
}}<br />
<br />
The list of valid session names can be found by listing {{ic|/usr/share/xsessions/*.desktop}} for X's sessions and {{ic|/usr/share/wayland-sessions/*.desktop}} for Wayland's.<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user will have to set up a blank password to their keyring for it to be unlocked automatically.}}<br />
<br />
=== Enabling interactive passwordless login ===<br />
<br />
LightDM goes through [[PAM]] so you must configure the lightdm configuration of PAM:<br />
<br />
{{hc|/etc/pam.d/lightdm|2=<br />
#%PAM-1.0<br />
'''auth sufficient pam_succeed_if.so user ingroup nopasswdlogin'''<br />
auth include system-login<br />
...<br />
}}<br />
<br />
You must then also be part of the {{ic|nopasswdlogin}} group to be able to login interactively without entering your password:<br />
<br />
# groupadd -r nopasswdlogin<br />
# gpasswd -a ''username'' nopasswdlogin<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user may have to follow the instructions at the end of the previous section on enabling autologin.}}<br />
<br />
To create a new user account that logs in automatically and additionally able to login again without a password the user can be created with supplementary membership of both groups, e.g.:<br />
<br />
# useradd -mG autologin,nopasswdlogin -s /bin/bash ''username''<br />
<br />
=== Enabling guest sessions ===<br />
<br />
{{Note|A guest user has passwordless access to your system after enabling this feature.}} <br />
<br />
To enable guest sessions in LightDM (without changing your system configuration) you need at least two things:<br />
<br />
# a '''guest-account-script''': defaults to {{ic|guest-account}} and accepts two commands:<br />
#* '''add''' (to create a temporary guest system account and returns the user name of the created account)<br />
#* '''remove''' ''account name''(to delete the corresponding account)<br />
# an [[#Enabling autologin|'''autologin''']] group to which the created guest account must be added (cf. {{ic|/etc/pam.d/lightdm-autologin}})<br />
<br />
There are two AUR packages that enable guest sessions in lightdm:<br />
<br />
* {{aur|lightdm-guest}} which provides the (largely unmodified) upstream guest-session script as well as {{pkg|lightdm}} itself.<br />
* {{aur|lightdm-guest-account}} which provides only a minimal version of the script.<br />
<br />
=== Hiding system and services users ===<br />
<br />
To prevent system users from showing-up in the login, install the optional dependency {{Pkg|accountsservice}}, or add the user names to {{ic|/etc/lightdm/users.conf}} under {{ic|hidden-users}}. The first option has the advantage of not needing to update the list when more users are added or removed.<br />
<br />
=== Migrating from SLiM ===<br />
<br />
{{Merge|Display Manager|Not LightDM specific (or even SLiM specific for that matter as [[XDM]] also uses [[xinitrc]]). Perhaps this merits a one-liner somewhere on the [[Display Manager]] page?}}<br />
<br />
Move the contents of [[xinitrc]] to [[xprofile]], removing the call to start the [[window manager]] or [[desktop environment]].<br />
<br />
=== Login using ~/.xinitrc ===<br />
<br />
See [[Display manager#Run ~/.xinitrc as a session]].<br />
<br />
=== NumLock on by default ===<br />
<br />
Install the {{Pkg|numlockx}} package and then edit {{ic|/etc/lightdm/lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
greeter-setup-script=/usr/bin/numlockx on<br />
}}<br />
<br />
=== Default session ===<br />
<br />
Lightdm, like other DMs, stores the last-selected xsession in {{ic|~/.dmrc}}. See [[Display manager#Session configuration]] for more info.<br />
<br />
=== Adjusting the login window's position ===<br />
<br />
==== GTK greeter ====<br />
<br />
Users need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and enter a value for the {{ic|position}} variable. It accepts {{ic|x}} and {{ic|y}} values, either absolute (in pixels) or relative (in percent). Each value can also have an additional anchor location for the window, {{ic|start}}, {{ic|center}} and {{ic|end}} separated from the value by a comma.<br />
<br />
Example:<br />
<br />
position=200,start 50%,center<br />
<br />
=== VNC Server ===<br />
<br />
Lightdm can also be used to connect to via VNC. Make sure to install {{pkg|tigervnc}} on the server side and optionally as your VNC client on the client PC.<br />
<br />
Setup an authentication password on the server as root:<br />
<br />
# vncpasswd /etc/vncpasswd<br />
<br />
Edit the LightDM configuration file as shown below. Note that {{ic|listen-address}} configures the VNC to only listen to connections from localhost. This is used to only allow connections via [[TigerVNC#On_the_client|SSH and port forwarding]]. On the SSH client, make sure that you use {{ic|localhost:5900}} for the tunnel destination; using {{ic|127.0.0.1:5900}} or {{ic|::1:5900}} is not reliable on dual stack network connections. If you want to allow insecure connections you can disable this setting.<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[VNCServer]<br />
enabled=true<br />
command=Xvnc -rfbauth /etc/vncpasswd<br />
port=5900<br />
listen-address=localhost<br />
width=1024<br />
height=768<br />
depth=24<br />
}}<br />
<br />
Now open an SSH tunnel and connect to localhost as described in [[TigerVNC#On the client]].<br />
<br />
{{Note|If you get a blank screen upon opening the VNC connection, try a different LightDM greeter.}}<br />
<br />
=== Lock the screen using light-locker ===<br />
<br />
{{Pkg|light-locker}} is a simple screen locker using LightDM to authenticate the user. Once installed and running, you can lock your session via:<br />
<br />
$ light-locker-command -l<br />
<br />
This requires {{ic|light-locker}} to be started at the beginning of your session. By default, this is enabled through [[XDG Autostart]]. See [[Autostarting]] for more options.<br />
<br />
=== Multiple-monitor setup ===<br />
<br />
Sometimes LightDM does not set the monitor resolution correctly on a multiple-monitor setup. The following Xorg configuration works with two monitors: a large primary screen on the left side, and a secondary smaller screen to its right. The order can be reversed and tweaked.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/52-resolution-fix.conf|2=<br />
Section "Monitor"<br />
Identifier "DP1"<br />
Option "PreferredMode" "3840x2160"<br />
Option "Primary" "1"<br />
EndSection<br />
Section "Monitor"<br />
Identifier "eDP1"<br />
Option "PreferredMode" "1920x1080"<br />
Option "RightOf" "DP1"<br />
EndSection<br />
}}<br />
<br />
This makes the {{ic|display-setup-script}} tweaks from {{ic|/etc/lightdm/lightdm.conf}} redundant.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Autologin does not work ===<br />
<br />
Ensure {{ic|1=autologin-user=}} in {{ic|/etc/lightdm/lightdm.conf}} contain the correct values. Trailing whitespace will cause errors.<br />
<br />
If autologin fails with a blank screen or if the login screen immediately returns, you may need to set {{ic|1=logind-check-graphical=true}}.<br />
<br />
You can also install {{AUR|lightdm-autologin-greeter-git}} for this special purpose.<br />
<br />
=== Viewing current configuration ===<br />
<br />
To view effective configuration, run:<br />
<br />
$ lightdm --show-config<br />
<br />
This will show current settings, with the configuration files these settings were read from.<br />
<br />
=== LightDM not starting and screen flashing ===<br />
<br />
If you encounter consistent screen flashing and ultimately no LightDM on boot, ensure that you have defined the greeter correctly in LightDM's configuration file. And if you have correctly defined the GTK greeter, make sure the {{ic|xsessions-directory}} (default: {{ic|/usr/share/xsessions}}) exists and contains at least one .desktop file.<br />
<br />
The same error can happen on lightdm startup if the last used session is not available anymore (eg. you last used gnome and then removed the gnome-session package): the easiest workaround is to temporarily restore the removed package. Another solution might be:<br />
<br />
# dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User.SetXSession string:xfce<br />
<br />
This example sets the session "xfce" as default for the user 1000.<br />
<br />
=== Wrong locale displayed ===<br />
<br />
In case of your locale not being displayed correctly in Lightdm add your locale to {{ic|/etc/environment}}:<br />
<br />
LANG=pt_PT.utf8<br />
<br />
Alternatively if you want LightDM and its greeters to be in a language other than your set system locale, you can use the {{ic|1=Environment=}} option in [[Systemd#Drop-in files]].<br />
<br />
=== Unresponsive for a few minutes after startup ===<br />
<br />
You may have to download more entropy. Install and enable haveged, c.f. https://github.com/canonical/lightdm/issues/17<br />
<br />
=== Missing icons with GTK greeter ===<br />
<br />
If you are using {{Pkg|lightdm-gtk-greeter}} as a greeter and it shows placeholder images as icons, make sure valid icon themes and themes are installed and configured. Check the following file:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
theme-name=mate # this should be the name of a directory under /usr/share/themes/<br />
icon-theme-name=mate # this should be the name of a fully featured icons set directory under /usr/share/icons/<br />
}}<br />
<br />
<br />
=== Using a custom icon and cursor theme with GTK greeter ===<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
theme-name = Adwaita<br />
icon-theme-name = Adwaita41<br />
cursor-theme-name = Adwaita41<br />
cursor-theme-size = 32<br />
font-name = Lato 20<br />
}}<br />
<br />
=== LightDM freezes on login attempt ===<br />
<br />
You may find that after entering the correct username and password and attempting to log in, LightDM freezes and you are unable to continue to the desktop. To fix the issue, reinstall the {{Pkg|gdk-pixbuf2}} package. See [https://bbs.archlinux.org/viewtopic.php?id=179031 this forum thread].<br />
<br />
=== LightDM displaying in wrong monitor ===<br />
<br />
If you are using multiple monitors, LightDM may display in the wrong one (e.g. if your primary monitor is on the right). To force the LightDM login screen to display on a specific monitor, edit {{ic|/etc/lightdm/lightdm.conf}} and change the ''display-setup-script'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
display-setup-script=xrandr --output ''HDMI1'' --primary<br />
}}<br />
<br />
Replace ''HDMI1'' with your real monitor ID, which you can find from '''xrandr''' command output.<br />
<br />
Alternatively, if you are using the GTK greeter, you can edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and add the ''active-monitor'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
active-monitor=0<br />
}}<br />
<br />
Replace 0 with the desired display number.<br />
<br />
=== LightDM does not appear or monitor only displays TTY output ===<br />
<br />
It may happen that your system boots so fast that LightDM service is started before your graphics drivers are properly loaded. If this is your case, you will want to add the following to your {{ic|lightdm.conf}} file:<br />
<br />
[LightDM]<br />
logind-check-graphical=true<br />
<br />
This setting will tell LightDM to wait until graphics devices are ready before spawning greeters/autostarting sessions on them.<br />
<br />
=== LightDM is running with low FPS on Intel Graphics ===<br />
<br />
See [[Intel graphics#AccelMethod]].<br />
<br />
=== Pulseaudio not starting automatically ===<br />
<br />
See [[PulseAudio#Running]].<br />
<br />
=== Long pause before LightDM shows up when home is encrypted ===<br />
<br />
Some LightDM themes try to access the user avatar located in HOME. If your HOME is encrypted, LightDM cannot access it and hangs. To prevent this from happening, you can either:<br />
<br />
* Set your avatar as explained in [[#Changing your avatar]]<br />
* for {{Pkg|lightdm-gtk-greeter}} only: {{Ic|<nowiki>hide-user-image = true</nowiki>}} in {{Ic|/etc/lightdm/lightdm-gtk-greeter.conf}}<br />
<br />
=== Boot hangs on "[ OK ] Reached target Graphical Interface." ===<br />
<br />
There is a possibility that user and group lookups fail if you modified /etc/nsswitch.conf. That happens when:<br />
<br />
* nsswitch.conf group: includes {{Ic|<nowiki>ldap</nowiki>}} without setting {{Ic|<nowiki>nss_initgroups_ignoreusers ALLLOCAL</nowiki>}} in {{Ic|<nowiki>/etc/nslcd.conf</nowiki>}}<br />
<br />
=== Wayland session not working with duplicate GNOME entries in greeter ===<br />
<br />
* Some greeters ({{Pkg|lightdm-webkit2-greeter}} for example) do not support two sessions with the same name [https://github.com/CanonicalLtd/lightdm/issues/16]. To check for duplicate entries:<br />
<br />
$ ls -1 /usr/share/wayland-sessions /usr/share/xsessions<br />
<br />
* Rename the duplicate entry in /usr/share/xsessions. For example:<br />
<br />
# mv /usr/share/xsessions/gnome.desktop /usr/share/xsessions/gnome.desktop.disabled<br />
<br />
=== Login always segfaults on first attempt ===<br />
<br />
Set a hostname as described in [[Network_configuration#Set_the_hostname|Network Page]]. See also {{Bug|47694}}.<br />
<br />
=== Infinite login loop ===<br />
<br />
If you get stuck in loop in which you type your correct user and password but the screen goes black and the you are back in the login after every attempt, running {{ic|rm ~/.Xauthority}} (or the stuck user's problematic {{ic|.Xauthority}}) may fix the issue.<br />
<br />
Another reason for this may be that you tried to recreate your "lightdm.conf" from scratch and your version is missing this line:<br />
<br />
session-wrapper=/etc/lightdm/Xsession<br />
<br />
In that case, lightdm tries to use "lightdm-session" as the session-wrapper which does not exist on Arch Linux.<br />
<br />
== See also ==<br />
<br />
* [https://wiki.ubuntu.com/LightDM Ubuntu Wiki article]<br />
* [[Gentoo:LightDM]]<br />
* [https://launchpad.net/lightdm Launchpad Page] obsolete<br />
* https://wiki.ubuntu.com/MattFischer<br />
* [https://github.com/CanonicalLtd/lightdm LightDM on GitHub]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Webcam_setup&diff=701548Webcam setup2021-11-10T23:01:58Z<p>Wooptoo: Persisting configuration changes: Add relevant comment</p>
<hr />
<div>[[Category:Digital imaging]]<br />
[[Category:Input devices]]<br />
[[es:Webcam setup]]<br />
[[ja:ウェブカメラ設定]]<br />
[[zh-hans:Webcam setup]]<br />
This is a guide to setting up your webcam in Arch Linux.<br />
<br />
Most probably your webcam will work out of the box. Permissions to access video devices (e.g. {{ic|/dev/video0}}) are handled by [[udev]], there is no configuration necessary.<br />
<br />
== Loading ==<br />
<br />
Most recent webcams are UVC (''USB Video Class'') compliant and are supported by the generic ''uvcvideo'' kernel driver module. To check that your webcam is recognized, run [[dmesg]] just after you plug the webcam in. You should see something like this:<br />
<br />
{{hc|# dmesg {{!}} tail|<br />
sn9c102: V4L2 driver for SN9C10x PC Camera Controllers v1:1.24a<br />
usb 1-1: SN9C10[12] PC Camera Controller detected (vid/pid 0x0C45/0x600D)<br />
usb 1-1: PAS106B image sensor detected<br />
usb 1-1: Initialization succeeded<br />
usb 1-1: V4L2 device registered as /dev/video0<br />
usb 1-1: Optional device control through 'sysfs' interface ready<br />
usbcore: registered new driver sn9c102}}<br />
Some pre-UVC webcams are also supported via the ''gspca'' kernel driver module. See the [https://www.kernel.org/doc/html/latest/admin-guide/media/gspca-cardlist.html gspca cards list] for a non-exhaustive list of supported devices under this framework.<br />
<br />
Otherwise, if your webcam is not supported by the kernel's drivers, an external driver is necessary. The first step is to identify the name of the webcam, using for example {{ic|lsusb}}. Then you can check [https://www.linuxtv.org/wiki/index.php/Webcam_devices webcam devices] for information and resources about webcams. Once you find a driver compatible with the webcam, you have to add the corresponding [[kernel module]] in {{ic|/etc/modules-load.d/webcam.conf}} so it will be loaded into the kernel during init stage bootstrapping.<br />
<br />
{{Note|The Linux kernel to userspace API used to control webcams is named ''Video4Linux2'', '''v4l2''' for short. All applications which support v4l2 will work with the kernel's drivers.}}<br />
<br />
== Configuration ==<br />
<br />
If you want to configure brightness, color and other webcam parameters (e.g. in the case when out-of-the-box colors are too bluish/reddish/greenish) you may use ''Qt V4L2 Test Bench''. To run it, [[install]] {{Pkg|v4l-utils}} and launch {{ic|qv4l2}}, and it will present you a list of configurable settings. Changing these settings will affect all applications.<br />
<br />
=== Command line ===<br />
<br />
{{Pkg|v4l-utils}} also installs an equivalent command line tool, {{ic|v4l2-ctl}}. To list all video devices:<br />
<br />
$ v4l2-ctl --list-devices<br />
<br />
To list the configurable settings of a video device:<br />
<br />
$ v4l2-ctl -d /dev/video0 --list-ctrls<br />
<br />
=== Persisting configuration changes ===<br />
<br />
Configuration made via V4L2 does not persist after the webcam is disconnected and reconnected. It is possible to use {{ic|v4l2-ctl}} with [[Udev]] rules in order to set some configuration each time a particular camera is connected.<br />
<br />
For example, to set a default zoom setting on a particular Logitech webcam each time it is connected, add a [[Udev#udev_rule_example|udev rule]] like this:<br />
<br />
{{hc|/etc/udev/rules.d/99-logitech-default-zoom.rules|2=<br />
SUBSYSTEM=="video4linux", KERNEL=="video[0-9]*", ATTR{index}=="0", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0892", RUN+="/usr/bin/v4l2-ctl -d $devnode --set-ctrl=zoom_absolute=170"<br />
}}<br />
<br />
The above rule is valid for the Logitech C920 HD Pro Webcam - hardware ID 046d:0892.<br />
<br />
The device's vendor id and product id can be found using {{ic|lsusb}}. These are unique per product and don't change unless the product gets a new hardware revision.<br />
<br />
To find udev attributes like the product name and serial, see [[Udev#List the attributes of a device]]. It also possible to [[Udev#Setting static device names|set a static name for a video device]]).<br />
<br />
=== Disable internal laptop webcam ===<br />
<br />
Sometimes we might want to disable a laptop's internal webcam so that only the one attached<br />
via USB is showing. This can be done with a udev rule.<br />
First we'll need the device's vendor id and the product id from {{ic|lsusb}}<br />
<br />
{{hc|lsusb|2=<br />
Bus 001 Device 008: ID 1bcf:28c1 Sunplus Innovation Technology Inc. Integrated_Webcam_HD<br />
}}<br />
<br />
Then we add new udev rule to remove the device as soon as it is detected:<br />
<br />
{{hc|/etc/udev/rules.d/40-disable-internal-webcam.rules|2=<br />
ACTION=="add", ATTR{idVendor}=="1bcf", ATTR{idProduct}=="28c1", RUN="/bin/sh -c 'echo 1 >/sys/\$devpath/remove'"<br />
}}<br />
<br />
== Applications ==<br />
<br />
See also [[List of applications/Multimedia#Webcam]].<br />
<br />
=== xawtv ===<br />
<br />
This is a basic ''Video4Linux2'' device viewer, and although it is intended for use with TV tuner cards, it works well with webcams. It will display what your webcam sees in a window.<br />
<br />
[[Install]] {{Pkg|xawtv}} and run it with:<br />
$ xawtv -c /dev/video0<br />
<br />
In case of error see [[#xawtv with nvidia card]].<br />
<br />
=== VLC ===<br />
<br />
[[VLC]] can also be used to view and record your webcam. In VLC's "Media" menu, open the 'Capture Device...' dialog and enter the video and audio device files. Or from the command line, do:<br />
$ vlc v4l2://:input-slave=alsa://:v4l-vdev="/dev/video0"<br />
This will make VLC mirror your webcam.<br />
* To take stills, simply choose ''Snapshot'' in the ''Video'' menu. <br />
* To record the stream, add a {{ic|--sout}} argument to the command line, e.g.<br />
$ vlc v4l://:v4l-vdev="/dev/video0":v4l-adev="/dev/audio2" --sout "#transcode{vcodec=mp1v,vb=1024,scale=1,acodec=mpga,ab=192,channels=2}:duplicate{dst=std{access=file,mux=mpeg1,dst=/tmp/test.mpg}}"<br />
<br />
(Obviously a bit overkill with regard to the bit rates but it is fine for testing purposes). Note that by default this will not display the video, in order to see what you are recording, you need to add the display as a destination to the argument (note that it will slow down the operation):<br />
... :duplicate{'''dst=display''',dst=std{access= ....<br />
<br />
If VLC does not detect webcams, ensure that {{Pkg|zvbi}} package is installed.<br />
<br />
=== MPlayer ===<br />
<br />
To use [[MPlayer]] to take snapshots from your webcam run this command from the terminal:<br />
$ mplayer tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0 -fps 15 -vf screenshot<br />
From here you have to press {{ic|s}} to take the snapshot. The snapshot will be saved in the current folder as {{ic|shotXXXX.png}}.<br />
If you want to record video continuous:<br />
$ mencoder tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0:forceaudio:adevice=/dev/dsp -ovc lavc -oac mp3lame -lameopts cbr:br=64:mode=3 -o ''filename''.avi<br />
Press {{ic|Ctrl+c}} to end the recording.<br />
<br />
To play video with [[MPlayer]] using MJPEG as the pixelformat instead of the default, which in most cases is YUYV, you can run the following:<br />
$ mplayer tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0:outfmt=mjpeg -fps 15<br />
<br />
=== mpv ===<br />
<br />
To use [[mpv]] to take snapshots from your webcam, run this command from the terminal:<br />
$ mpv av://v4l2:/dev/video0 --profile=low-latency --untimed<br />
<br />
From here you have to press {{ic|s}} to take the snapshot. The snapshot will be saved in your current folder as {{ic|mpv-shot''NNNN''.jpg}}.<br />
<br />
To use MJPEG as the pixelformat instead of the default, which in most cases is YUYV, you can run the following instead:<br />
$ mpv --demuxer-lavf-format=video4linux2 --demuxer-lavf-o-set=input_format=mjpeg av://v4l2:/dev/video0<br />
<br />
In some cases this can lead to drastic improvements in quality and performance (5FPS -> 30FPS for example).<br />
<br />
To adjust webcam settings, including the resolution, [https://github.com/mpv-player/mpv/wiki/Video4Linux2-Input see the mpv documentation].<br />
<br />
=== FFmpeg ===<br />
<br />
See [[FFmpeg#Recording webcam]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== V4L1 support ===<br />
<br />
Version 2.6.27 of the Linux kernel dropped support for the legacy Video4Linux (1) API. Pixel format decoding has been pushed to user space, since Video4Linux version 2 does not support kernel space decoding. The libv4l library provides userland applications with pixel decoding services and will be used by most programs. Other compatibility layers are also available.<br />
<br />
'''If your device is created but your image looks strange (e.g. nearly completely green), you probably need this.'''<br />
<br />
If the application has V4L2 support but no pixelformat support then use the following command:<br />
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so application<br />
<br />
If the application only supports the older version of V4L, use this command:<br />
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so application<br />
<br />
{{Tip|1=You also might want to put a line like the following into {{ic|/etc/profile}} or [[xprofile]] so you do not have to type that long command all the time:<br />
{{ic|1=export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so}} or {{ic|1=export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so}}}}<br />
<br />
For 32-bit [[multilib]] applications, install the {{Pkg|lib32-v4l-utils}} package and replace {{ic|/usr/lib/libv4l/}} by {{ic|/usr/lib32/libv4l/}} in the above commands.<br />
<br />
=== xawtv with nvidia card ===<br />
<br />
If you are using an nvidia graphic card, and get an error like<br />
X Error of failed request: XF86DGANoDirectVideoMode<br />
Major opcode of failed request: 139 (XFree86-DGA)<br />
Minor opcode of failed request: 1 (XF86DGAGetVideoLL)<br />
Serial number of failed request: 69<br />
Current serial number in output stream: 69<br />
you should instead run it as {{ic|$ xawtv -nodga}}<br />
<br />
=== Microsoft Lifecam Studio/Cinema ===<br />
<br />
Under certain configurations, the Microsoft lifecam studio/cinema may request too much usb bandwidth and fail [https://www.ideasonboard.org/uvc/#footnote-13 see Uvcvideo FAQ]. In this case, change the buffering by loading the {{ic|uvcvideo}} driver with {{ic|1=quirks=0x80}}. Add it to {{ic|/etc/modprobe.d/uvcvideo.conf}} :<br />
<br />
{{hc|1=/etc/modprobe.d/uvcvideo.conf|2=<br />
## fix bandwidth issue for lifecam studio/cinema<br />
options uvcvideo quirks=0x80<br />
}}<br />
<br />
{{Note|If delays are visible in the logs, or the camera works periodically, this workaround should apply generally. Bigger values such as {{ic|1=quirks=0x100}} are possible.}}<br />
<br />
=== Skype ===<br />
<br />
When testing the webcam, note the following:<br />
* The echobot does not support videochat. Do not use it for testing your webcam.<br />
* Skype might recognize different video/camera devices (/dev/video*). These will be listed as something like "integrated camera..." in a dropdown menu in the camera settings. Try each camera and wait a few seconds, because it takes time to switch to a different camera.<br />
<br />
=== Check bandwidth used by USB webcams ===<br />
<br />
When running multiple webcams on a single USB bus, they may saturate the bandwidth of the USB bus and not work properly. You can diagnose this with the ''usbtop'' tool from the {{AUR|usbtop}} package.<br />
<br />
=== Invert the video stream ===<br />
<br />
If your video stream is inverted, you can make a new virtual video camera which inverts the inverted video. You need to [[install]] {{Pkg|v4l-utils}} and also {{Pkg|v4l2loopback-dkms}}. Create the virtual video camera:<br />
<br />
# modprobe v4l2loopback<br />
<br />
Check the name of the newly created camera:<br />
<br />
$ v4l2-ctl --list-devices<br />
Dummy video device (0x0000) (platform:v4l2loopback-000):<br />
/dev/video1<br />
<br />
Then you can run {{Pkg|ffmpeg}} to read from your actual webcam (here {{ic|/dev/video0}}) and invert it and feed it to the virtual camera:<br />
<br />
$ ffmpeg -f v4l2 -i /dev/video0 -vf "vflip" -f v4l2 /dev/video1<br />
<br />
Here {{ic|vflip}} inverts the video stream vertically. Use {{ic|hflip}} to invert it horizontally.<br />
<br />
Note that the format argument {{ic|yuv420p}} might be needed to avoid an error, otherwise there might not be any video stream and a black screen will be shown [https://stackoverflow.com/questions/61485726/ffmpeg-flip-horizontally-webcam-to-virtual-video-camera/63943783#63943783]. In other words:<br />
<br />
$ ffmpeg -f v4l2 -i /dev/video0 -vf "hflip,format=yuv420p" -f v4l2 /dev/video1<br />
<br />
You can then use the "Dummy" camera in your applications instead of the "Integrated" camera.<br />
<br />
=== Bad image quality ===<br />
<br />
If you experience images being too bright, too dark, too exposed or any other, you can install {{AUR|v4l2ucp}} to tweak your image output.</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Webcam_setup&diff=701547Webcam setup2021-11-10T22:57:16Z<p>Wooptoo: Added 'Disable internal laptop webcam'</p>
<hr />
<div>[[Category:Digital imaging]]<br />
[[Category:Input devices]]<br />
[[es:Webcam setup]]<br />
[[ja:ウェブカメラ設定]]<br />
[[zh-hans:Webcam setup]]<br />
This is a guide to setting up your webcam in Arch Linux.<br />
<br />
Most probably your webcam will work out of the box. Permissions to access video devices (e.g. {{ic|/dev/video0}}) are handled by [[udev]], there is no configuration necessary.<br />
<br />
== Loading ==<br />
<br />
Most recent webcams are UVC (''USB Video Class'') compliant and are supported by the generic ''uvcvideo'' kernel driver module. To check that your webcam is recognized, run [[dmesg]] just after you plug the webcam in. You should see something like this:<br />
<br />
{{hc|# dmesg {{!}} tail|<br />
sn9c102: V4L2 driver for SN9C10x PC Camera Controllers v1:1.24a<br />
usb 1-1: SN9C10[12] PC Camera Controller detected (vid/pid 0x0C45/0x600D)<br />
usb 1-1: PAS106B image sensor detected<br />
usb 1-1: Initialization succeeded<br />
usb 1-1: V4L2 device registered as /dev/video0<br />
usb 1-1: Optional device control through 'sysfs' interface ready<br />
usbcore: registered new driver sn9c102}}<br />
Some pre-UVC webcams are also supported via the ''gspca'' kernel driver module. See the [https://www.kernel.org/doc/html/latest/admin-guide/media/gspca-cardlist.html gspca cards list] for a non-exhaustive list of supported devices under this framework.<br />
<br />
Otherwise, if your webcam is not supported by the kernel's drivers, an external driver is necessary. The first step is to identify the name of the webcam, using for example {{ic|lsusb}}. Then you can check [https://www.linuxtv.org/wiki/index.php/Webcam_devices webcam devices] for information and resources about webcams. Once you find a driver compatible with the webcam, you have to add the corresponding [[kernel module]] in {{ic|/etc/modules-load.d/webcam.conf}} so it will be loaded into the kernel during init stage bootstrapping.<br />
<br />
{{Note|The Linux kernel to userspace API used to control webcams is named ''Video4Linux2'', '''v4l2''' for short. All applications which support v4l2 will work with the kernel's drivers.}}<br />
<br />
== Configuration ==<br />
<br />
If you want to configure brightness, color and other webcam parameters (e.g. in the case when out-of-the-box colors are too bluish/reddish/greenish) you may use ''Qt V4L2 Test Bench''. To run it, [[install]] {{Pkg|v4l-utils}} and launch {{ic|qv4l2}}, and it will present you a list of configurable settings. Changing these settings will affect all applications.<br />
<br />
=== Command line ===<br />
<br />
{{Pkg|v4l-utils}} also installs an equivalent command line tool, {{ic|v4l2-ctl}}. To list all video devices:<br />
<br />
$ v4l2-ctl --list-devices<br />
<br />
To list the configurable settings of a video device:<br />
<br />
$ v4l2-ctl -d /dev/video0 --list-ctrls<br />
<br />
=== Persisting configuration changes ===<br />
<br />
Configuration made via V4L2 does not persist after the webcam is disconnected and reconnected. It is possible to use {{ic|v4l2-ctl}} with [[Udev]] rules in order to set some configuration each time a particular camera is connected.<br />
<br />
For example, to set a default zoom setting on a particular Logitech webcam each time it is connected, add a [[Udev#udev_rule_example|udev rule]] like this:<br />
<br />
{{hc|/etc/udev/rules.d/99-logitech-default-zoom.rules|2=<br />
SUBSYSTEM=="video4linux", KERNEL=="video[0-9]*", ATTR{index}=="0", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0892", RUN+="/usr/bin/v4l2-ctl -d $devnode --set-ctrl=zoom_absolute=170"<br />
}}<br />
<br />
The device's vendor id and product id can be found using {{ic|lsusb}}. These are unique per product and don't change unless the product gets a new hardware revision.<br />
<br />
To find udev attributes like the product name and serial, see [[Udev#List the attributes of a device]]. It also possible to [[Udev#Setting static device names|set a static name for a video device]]).<br />
<br />
=== Disable internal laptop webcam ===<br />
<br />
Sometimes we might want to disable a laptop's internal webcam so that only the one attached<br />
via USB is showing. This can be done with a udev rule.<br />
First we'll need the device's vendor id and the product id from {{ic|lsusb}}<br />
<br />
{{hc|lsusb|2=<br />
Bus 001 Device 008: ID 1bcf:28c1 Sunplus Innovation Technology Inc. Integrated_Webcam_HD<br />
}}<br />
<br />
Then we add new udev rule to remove the device as soon as it is detected:<br />
<br />
{{hc|/etc/udev/rules.d/40-disable-internal-webcam.rules|2=<br />
ACTION=="add", ATTR{idVendor}=="1bcf", ATTR{idProduct}=="28c1", RUN="/bin/sh -c 'echo 1 >/sys/\$devpath/remove'"<br />
}}<br />
<br />
== Applications ==<br />
<br />
See also [[List of applications/Multimedia#Webcam]].<br />
<br />
=== xawtv ===<br />
<br />
This is a basic ''Video4Linux2'' device viewer, and although it is intended for use with TV tuner cards, it works well with webcams. It will display what your webcam sees in a window.<br />
<br />
[[Install]] {{Pkg|xawtv}} and run it with:<br />
$ xawtv -c /dev/video0<br />
<br />
In case of error see [[#xawtv with nvidia card]].<br />
<br />
=== VLC ===<br />
<br />
[[VLC]] can also be used to view and record your webcam. In VLC's "Media" menu, open the 'Capture Device...' dialog and enter the video and audio device files. Or from the command line, do:<br />
$ vlc v4l2://:input-slave=alsa://:v4l-vdev="/dev/video0"<br />
This will make VLC mirror your webcam.<br />
* To take stills, simply choose ''Snapshot'' in the ''Video'' menu. <br />
* To record the stream, add a {{ic|--sout}} argument to the command line, e.g.<br />
$ vlc v4l://:v4l-vdev="/dev/video0":v4l-adev="/dev/audio2" --sout "#transcode{vcodec=mp1v,vb=1024,scale=1,acodec=mpga,ab=192,channels=2}:duplicate{dst=std{access=file,mux=mpeg1,dst=/tmp/test.mpg}}"<br />
<br />
(Obviously a bit overkill with regard to the bit rates but it is fine for testing purposes). Note that by default this will not display the video, in order to see what you are recording, you need to add the display as a destination to the argument (note that it will slow down the operation):<br />
... :duplicate{'''dst=display''',dst=std{access= ....<br />
<br />
If VLC does not detect webcams, ensure that {{Pkg|zvbi}} package is installed.<br />
<br />
=== MPlayer ===<br />
<br />
To use [[MPlayer]] to take snapshots from your webcam run this command from the terminal:<br />
$ mplayer tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0 -fps 15 -vf screenshot<br />
From here you have to press {{ic|s}} to take the snapshot. The snapshot will be saved in the current folder as {{ic|shotXXXX.png}}.<br />
If you want to record video continuous:<br />
$ mencoder tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0:forceaudio:adevice=/dev/dsp -ovc lavc -oac mp3lame -lameopts cbr:br=64:mode=3 -o ''filename''.avi<br />
Press {{ic|Ctrl+c}} to end the recording.<br />
<br />
To play video with [[MPlayer]] using MJPEG as the pixelformat instead of the default, which in most cases is YUYV, you can run the following:<br />
$ mplayer tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0:outfmt=mjpeg -fps 15<br />
<br />
=== mpv ===<br />
<br />
To use [[mpv]] to take snapshots from your webcam, run this command from the terminal:<br />
$ mpv av://v4l2:/dev/video0 --profile=low-latency --untimed<br />
<br />
From here you have to press {{ic|s}} to take the snapshot. The snapshot will be saved in your current folder as {{ic|mpv-shot''NNNN''.jpg}}.<br />
<br />
To use MJPEG as the pixelformat instead of the default, which in most cases is YUYV, you can run the following instead:<br />
$ mpv --demuxer-lavf-format=video4linux2 --demuxer-lavf-o-set=input_format=mjpeg av://v4l2:/dev/video0<br />
<br />
In some cases this can lead to drastic improvements in quality and performance (5FPS -> 30FPS for example).<br />
<br />
To adjust webcam settings, including the resolution, [https://github.com/mpv-player/mpv/wiki/Video4Linux2-Input see the mpv documentation].<br />
<br />
=== FFmpeg ===<br />
<br />
See [[FFmpeg#Recording webcam]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== V4L1 support ===<br />
<br />
Version 2.6.27 of the Linux kernel dropped support for the legacy Video4Linux (1) API. Pixel format decoding has been pushed to user space, since Video4Linux version 2 does not support kernel space decoding. The libv4l library provides userland applications with pixel decoding services and will be used by most programs. Other compatibility layers are also available.<br />
<br />
'''If your device is created but your image looks strange (e.g. nearly completely green), you probably need this.'''<br />
<br />
If the application has V4L2 support but no pixelformat support then use the following command:<br />
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so application<br />
<br />
If the application only supports the older version of V4L, use this command:<br />
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so application<br />
<br />
{{Tip|1=You also might want to put a line like the following into {{ic|/etc/profile}} or [[xprofile]] so you do not have to type that long command all the time:<br />
{{ic|1=export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so}} or {{ic|1=export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so}}}}<br />
<br />
For 32-bit [[multilib]] applications, install the {{Pkg|lib32-v4l-utils}} package and replace {{ic|/usr/lib/libv4l/}} by {{ic|/usr/lib32/libv4l/}} in the above commands.<br />
<br />
=== xawtv with nvidia card ===<br />
<br />
If you are using an nvidia graphic card, and get an error like<br />
X Error of failed request: XF86DGANoDirectVideoMode<br />
Major opcode of failed request: 139 (XFree86-DGA)<br />
Minor opcode of failed request: 1 (XF86DGAGetVideoLL)<br />
Serial number of failed request: 69<br />
Current serial number in output stream: 69<br />
you should instead run it as {{ic|$ xawtv -nodga}}<br />
<br />
=== Microsoft Lifecam Studio/Cinema ===<br />
<br />
Under certain configurations, the Microsoft lifecam studio/cinema may request too much usb bandwidth and fail [https://www.ideasonboard.org/uvc/#footnote-13 see Uvcvideo FAQ]. In this case, change the buffering by loading the {{ic|uvcvideo}} driver with {{ic|1=quirks=0x80}}. Add it to {{ic|/etc/modprobe.d/uvcvideo.conf}} :<br />
<br />
{{hc|1=/etc/modprobe.d/uvcvideo.conf|2=<br />
## fix bandwidth issue for lifecam studio/cinema<br />
options uvcvideo quirks=0x80<br />
}}<br />
<br />
{{Note|If delays are visible in the logs, or the camera works periodically, this workaround should apply generally. Bigger values such as {{ic|1=quirks=0x100}} are possible.}}<br />
<br />
=== Skype ===<br />
<br />
When testing the webcam, note the following:<br />
* The echobot does not support videochat. Do not use it for testing your webcam.<br />
* Skype might recognize different video/camera devices (/dev/video*). These will be listed as something like "integrated camera..." in a dropdown menu in the camera settings. Try each camera and wait a few seconds, because it takes time to switch to a different camera.<br />
<br />
=== Check bandwidth used by USB webcams ===<br />
<br />
When running multiple webcams on a single USB bus, they may saturate the bandwidth of the USB bus and not work properly. You can diagnose this with the ''usbtop'' tool from the {{AUR|usbtop}} package.<br />
<br />
=== Invert the video stream ===<br />
<br />
If your video stream is inverted, you can make a new virtual video camera which inverts the inverted video. You need to [[install]] {{Pkg|v4l-utils}} and also {{Pkg|v4l2loopback-dkms}}. Create the virtual video camera:<br />
<br />
# modprobe v4l2loopback<br />
<br />
Check the name of the newly created camera:<br />
<br />
$ v4l2-ctl --list-devices<br />
Dummy video device (0x0000) (platform:v4l2loopback-000):<br />
/dev/video1<br />
<br />
Then you can run {{Pkg|ffmpeg}} to read from your actual webcam (here {{ic|/dev/video0}}) and invert it and feed it to the virtual camera:<br />
<br />
$ ffmpeg -f v4l2 -i /dev/video0 -vf "vflip" -f v4l2 /dev/video1<br />
<br />
Here {{ic|vflip}} inverts the video stream vertically. Use {{ic|hflip}} to invert it horizontally.<br />
<br />
Note that the format argument {{ic|yuv420p}} might be needed to avoid an error, otherwise there might not be any video stream and a black screen will be shown [https://stackoverflow.com/questions/61485726/ffmpeg-flip-horizontally-webcam-to-virtual-video-camera/63943783#63943783]. In other words:<br />
<br />
$ ffmpeg -f v4l2 -i /dev/video0 -vf "hflip,format=yuv420p" -f v4l2 /dev/video1<br />
<br />
You can then use the "Dummy" camera in your applications instead of the "Integrated" camera.<br />
<br />
=== Bad image quality ===<br />
<br />
If you experience images being too bright, too dark, too exposed or any other, you can install {{AUR|v4l2ucp}} to tweak your image output.</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Webcam_setup&diff=701546Webcam setup2021-11-10T22:40:35Z<p>Wooptoo: Persisting configuration changes: Replaced with working example for C920</p>
<hr />
<div>[[Category:Digital imaging]]<br />
[[Category:Input devices]]<br />
[[es:Webcam setup]]<br />
[[ja:ウェブカメラ設定]]<br />
[[zh-hans:Webcam setup]]<br />
This is a guide to setting up your webcam in Arch Linux.<br />
<br />
Most probably your webcam will work out of the box. Permissions to access video devices (e.g. {{ic|/dev/video0}}) are handled by [[udev]], there is no configuration necessary.<br />
<br />
== Loading ==<br />
<br />
Most recent webcams are UVC (''USB Video Class'') compliant and are supported by the generic ''uvcvideo'' kernel driver module. To check that your webcam is recognized, run [[dmesg]] just after you plug the webcam in. You should see something like this:<br />
<br />
{{hc|# dmesg {{!}} tail|<br />
sn9c102: V4L2 driver for SN9C10x PC Camera Controllers v1:1.24a<br />
usb 1-1: SN9C10[12] PC Camera Controller detected (vid/pid 0x0C45/0x600D)<br />
usb 1-1: PAS106B image sensor detected<br />
usb 1-1: Initialization succeeded<br />
usb 1-1: V4L2 device registered as /dev/video0<br />
usb 1-1: Optional device control through 'sysfs' interface ready<br />
usbcore: registered new driver sn9c102}}<br />
Some pre-UVC webcams are also supported via the ''gspca'' kernel driver module. See the [https://www.kernel.org/doc/html/latest/admin-guide/media/gspca-cardlist.html gspca cards list] for a non-exhaustive list of supported devices under this framework.<br />
<br />
Otherwise, if your webcam is not supported by the kernel's drivers, an external driver is necessary. The first step is to identify the name of the webcam, using for example {{ic|lsusb}}. Then you can check [https://www.linuxtv.org/wiki/index.php/Webcam_devices webcam devices] for information and resources about webcams. Once you find a driver compatible with the webcam, you have to add the corresponding [[kernel module]] in {{ic|/etc/modules-load.d/webcam.conf}} so it will be loaded into the kernel during init stage bootstrapping.<br />
<br />
{{Note|The Linux kernel to userspace API used to control webcams is named ''Video4Linux2'', '''v4l2''' for short. All applications which support v4l2 will work with the kernel's drivers.}}<br />
<br />
== Configuration ==<br />
<br />
If you want to configure brightness, color and other webcam parameters (e.g. in the case when out-of-the-box colors are too bluish/reddish/greenish) you may use ''Qt V4L2 Test Bench''. To run it, [[install]] {{Pkg|v4l-utils}} and launch {{ic|qv4l2}}, and it will present you a list of configurable settings. Changing these settings will affect all applications.<br />
<br />
=== Command line ===<br />
<br />
{{Pkg|v4l-utils}} also installs an equivalent command line tool, {{ic|v4l2-ctl}}. To list all video devices:<br />
<br />
$ v4l2-ctl --list-devices<br />
<br />
To list the configurable settings of a video device:<br />
<br />
$ v4l2-ctl -d /dev/video0 --list-ctrls<br />
<br />
=== Persisting configuration changes ===<br />
<br />
Configuration made via V4L2 does not persist after the webcam is disconnected and reconnected. It is possible to use {{ic|v4l2-ctl}} with [[Udev]] rules in order to set some configuration each time a particular camera is connected.<br />
<br />
For example, to set a default zoom setting on a particular Logitech webcam each time it is connected, add a [[Udev#udev_rule_example|udev rule]] like this:<br />
<br />
{{hc|/etc/udev/rules.d/99-logitech-default-zoom.rules|2=<br />
# lsusb ID 046d:0892 Logitech, Inc. C920 HD Pro Webcam<br />
<br />
SUBSYSTEM=="video4linux", KERNEL=="video[0-9]*", ATTR{index}=="0", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="0892", RUN+="/usr/bin/v4l2-ctl -d $devnode --set-ctrl=zoom_absolute=170"<br />
}}<br />
<br />
To find udev attributes like the product name and serial, see [[Udev#List the attributes of a device]]. It also possible to [[Udev#Setting static device names|set a static name for a video device]]).<br />
<br />
== Applications ==<br />
<br />
See also [[List of applications/Multimedia#Webcam]].<br />
<br />
=== xawtv ===<br />
<br />
This is a basic ''Video4Linux2'' device viewer, and although it is intended for use with TV tuner cards, it works well with webcams. It will display what your webcam sees in a window.<br />
<br />
[[Install]] {{Pkg|xawtv}} and run it with:<br />
$ xawtv -c /dev/video0<br />
<br />
In case of error see [[#xawtv with nvidia card]].<br />
<br />
=== VLC ===<br />
<br />
[[VLC]] can also be used to view and record your webcam. In VLC's "Media" menu, open the 'Capture Device...' dialog and enter the video and audio device files. Or from the command line, do:<br />
$ vlc v4l2://:input-slave=alsa://:v4l-vdev="/dev/video0"<br />
This will make VLC mirror your webcam.<br />
* To take stills, simply choose ''Snapshot'' in the ''Video'' menu. <br />
* To record the stream, add a {{ic|--sout}} argument to the command line, e.g.<br />
$ vlc v4l://:v4l-vdev="/dev/video0":v4l-adev="/dev/audio2" --sout "#transcode{vcodec=mp1v,vb=1024,scale=1,acodec=mpga,ab=192,channels=2}:duplicate{dst=std{access=file,mux=mpeg1,dst=/tmp/test.mpg}}"<br />
<br />
(Obviously a bit overkill with regard to the bit rates but it is fine for testing purposes). Note that by default this will not display the video, in order to see what you are recording, you need to add the display as a destination to the argument (note that it will slow down the operation):<br />
... :duplicate{'''dst=display''',dst=std{access= ....<br />
<br />
If VLC does not detect webcams, ensure that {{Pkg|zvbi}} package is installed.<br />
<br />
=== MPlayer ===<br />
<br />
To use [[MPlayer]] to take snapshots from your webcam run this command from the terminal:<br />
$ mplayer tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0 -fps 15 -vf screenshot<br />
From here you have to press {{ic|s}} to take the snapshot. The snapshot will be saved in the current folder as {{ic|shotXXXX.png}}.<br />
If you want to record video continuous:<br />
$ mencoder tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0:forceaudio:adevice=/dev/dsp -ovc lavc -oac mp3lame -lameopts cbr:br=64:mode=3 -o ''filename''.avi<br />
Press {{ic|Ctrl+c}} to end the recording.<br />
<br />
To play video with [[MPlayer]] using MJPEG as the pixelformat instead of the default, which in most cases is YUYV, you can run the following:<br />
$ mplayer tv:// -tv driver=v4l2:width=640:height=480:device=/dev/video0:outfmt=mjpeg -fps 15<br />
<br />
=== mpv ===<br />
<br />
To use [[mpv]] to take snapshots from your webcam, run this command from the terminal:<br />
$ mpv av://v4l2:/dev/video0 --profile=low-latency --untimed<br />
<br />
From here you have to press {{ic|s}} to take the snapshot. The snapshot will be saved in your current folder as {{ic|mpv-shot''NNNN''.jpg}}.<br />
<br />
To use MJPEG as the pixelformat instead of the default, which in most cases is YUYV, you can run the following instead:<br />
$ mpv --demuxer-lavf-format=video4linux2 --demuxer-lavf-o-set=input_format=mjpeg av://v4l2:/dev/video0<br />
<br />
In some cases this can lead to drastic improvements in quality and performance (5FPS -> 30FPS for example).<br />
<br />
To adjust webcam settings, including the resolution, [https://github.com/mpv-player/mpv/wiki/Video4Linux2-Input see the mpv documentation].<br />
<br />
=== FFmpeg ===<br />
<br />
See [[FFmpeg#Recording webcam]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== V4L1 support ===<br />
<br />
Version 2.6.27 of the Linux kernel dropped support for the legacy Video4Linux (1) API. Pixel format decoding has been pushed to user space, since Video4Linux version 2 does not support kernel space decoding. The libv4l library provides userland applications with pixel decoding services and will be used by most programs. Other compatibility layers are also available.<br />
<br />
'''If your device is created but your image looks strange (e.g. nearly completely green), you probably need this.'''<br />
<br />
If the application has V4L2 support but no pixelformat support then use the following command:<br />
LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so application<br />
<br />
If the application only supports the older version of V4L, use this command:<br />
LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so application<br />
<br />
{{Tip|1=You also might want to put a line like the following into {{ic|/etc/profile}} or [[xprofile]] so you do not have to type that long command all the time:<br />
{{ic|1=export LD_PRELOAD=/usr/lib/libv4l/v4l2convert.so}} or {{ic|1=export LD_PRELOAD=/usr/lib/libv4l/v4l1compat.so}}}}<br />
<br />
For 32-bit [[multilib]] applications, install the {{Pkg|lib32-v4l-utils}} package and replace {{ic|/usr/lib/libv4l/}} by {{ic|/usr/lib32/libv4l/}} in the above commands.<br />
<br />
=== xawtv with nvidia card ===<br />
<br />
If you are using an nvidia graphic card, and get an error like<br />
X Error of failed request: XF86DGANoDirectVideoMode<br />
Major opcode of failed request: 139 (XFree86-DGA)<br />
Minor opcode of failed request: 1 (XF86DGAGetVideoLL)<br />
Serial number of failed request: 69<br />
Current serial number in output stream: 69<br />
you should instead run it as {{ic|$ xawtv -nodga}}<br />
<br />
=== Microsoft Lifecam Studio/Cinema ===<br />
<br />
Under certain configurations, the Microsoft lifecam studio/cinema may request too much usb bandwidth and fail [https://www.ideasonboard.org/uvc/#footnote-13 see Uvcvideo FAQ]. In this case, change the buffering by loading the {{ic|uvcvideo}} driver with {{ic|1=quirks=0x80}}. Add it to {{ic|/etc/modprobe.d/uvcvideo.conf}} :<br />
<br />
{{hc|1=/etc/modprobe.d/uvcvideo.conf|2=<br />
## fix bandwidth issue for lifecam studio/cinema<br />
options uvcvideo quirks=0x80<br />
}}<br />
<br />
{{Note|If delays are visible in the logs, or the camera works periodically, this workaround should apply generally. Bigger values such as {{ic|1=quirks=0x100}} are possible.}}<br />
<br />
=== Skype ===<br />
<br />
When testing the webcam, note the following:<br />
* The echobot does not support videochat. Do not use it for testing your webcam.<br />
* Skype might recognize different video/camera devices (/dev/video*). These will be listed as something like "integrated camera..." in a dropdown menu in the camera settings. Try each camera and wait a few seconds, because it takes time to switch to a different camera.<br />
<br />
=== Check bandwidth used by USB webcams ===<br />
<br />
When running multiple webcams on a single USB bus, they may saturate the bandwidth of the USB bus and not work properly. You can diagnose this with the ''usbtop'' tool from the {{AUR|usbtop}} package.<br />
<br />
=== Invert the video stream ===<br />
<br />
If your video stream is inverted, you can make a new virtual video camera which inverts the inverted video. You need to [[install]] {{Pkg|v4l-utils}} and also {{Pkg|v4l2loopback-dkms}}. Create the virtual video camera:<br />
<br />
# modprobe v4l2loopback<br />
<br />
Check the name of the newly created camera:<br />
<br />
$ v4l2-ctl --list-devices<br />
Dummy video device (0x0000) (platform:v4l2loopback-000):<br />
/dev/video1<br />
<br />
Then you can run {{Pkg|ffmpeg}} to read from your actual webcam (here {{ic|/dev/video0}}) and invert it and feed it to the virtual camera:<br />
<br />
$ ffmpeg -f v4l2 -i /dev/video0 -vf "vflip" -f v4l2 /dev/video1<br />
<br />
Here {{ic|vflip}} inverts the video stream vertically. Use {{ic|hflip}} to invert it horizontally.<br />
<br />
Note that the format argument {{ic|yuv420p}} might be needed to avoid an error, otherwise there might not be any video stream and a black screen will be shown [https://stackoverflow.com/questions/61485726/ffmpeg-flip-horizontally-webcam-to-virtual-video-camera/63943783#63943783]. In other words:<br />
<br />
$ ffmpeg -f v4l2 -i /dev/video0 -vf "hflip,format=yuv420p" -f v4l2 /dev/video1<br />
<br />
You can then use the "Dummy" camera in your applications instead of the "Integrated" camera.<br />
<br />
=== Bad image quality ===<br />
<br />
If you experience images being too bright, too dark, too exposed or any other, you can install {{AUR|v4l2ucp}} to tweak your image output.</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Laptop/Dell&diff=700064Laptop/Dell2021-10-27T11:31:02Z<p>Wooptoo: Inspiron 15 7000 Series (Model 7570) tweaks</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:ノートパソコン/Dell]]<br />
{{Laptops navigation}}<br />
<br />
== Inspiron ==<br />
<br />
{{Laptops table header}}<br />
| Inspiron 1420 || 2012.09 || 3D with {{Pkg|xf86-video-nouveau}} || Intel HD Audio with ALSA || Yes || Yes, {{pkg|broadcom-wl}} is needed || Untested || Untested || Untested || Untested || Everything that I have tested works great without any problems<br />
|-<br />
| Inspiron 1501 || Duke || 3D with proprietary ATI fglrx || Intel HD audio with ALSA || Yes || Yes, BCM4311 PCI-E with bcm43xx || N/A || Untested || Untested || Smart card reader works out-of-the-box || Everything else works without a hitch<br />
|-<br />
| Inspiron 1520 || Core Dump || 3D with NVIDIA || SigmaTel audio with ALSA || ''b44'' module, out of the box || ''b43'', need firmware || Yes || || Untested || Hot keys work out-of-the-box || Everything else works without a hitch<br />
|-<br />
| [[Dell Inspiron 1525|Inspiron 1525]] || Arch Linux 2008.06 - "Overlord" FTP Install || 3D with {{Pkg|xf86-video-intel}} 2.4.3, native resolution with {{Pkg|xorg-server}} 1.5.3 (1280x800) || Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || PRO/Wireless 3945ABG with ''iwlwifi-3945-ucode'' 15.28.2.8 || Untested (does not have) || Untested || Untested || SD card reader works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS. Everything else work out-of-the-box.<br />
|- <br />
| Inspiron 1525 || Core Dump (2008.03 ISO) || 3D with {{Pkg|xf86-video-intel}} 2.2, native resolution with {{Pkg|xorg-server}} 1.4 (1280x800)|| Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || Broadcom BCM4310: Yes, [[ndiswrapper]] ({{pkg|broadcom-wl}} works, but must blacklist {{ic|ssb}} module) || Untested (does not have) || Untested || Untested || SD card reader (Ricoh) works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS. DVD-RW drive and everything else work out-of-the-box.<br />
|- <br />
| Inspiron 1764 || 2011.08.19 || 3D with {{Pkg|xf86-video-intel}} || Works well with ALSA || Realtek RTL8101E 10/100 Ethernet Controller || [[Broadcom wireless|Broadcom BCM43224]] 802.11a/b/g/n works well with [[Broadcom_wireless#brcm80211|brcmsmac]] || Untested || Untested || Does not have a modem || SD card reader and LCD brightness {{ic|Fn}} keys work out-of-the-box || Fan control/monitoring is completely broken with {{AUR|i8kutils}}<br />
|-<br />
| [[Dell Inspiron 14 3420|Inspiron 14 3000 Series (Model 3420)]] || 2016.09.03 || Intel® HD Graphics 4000. Works out of the box with {{Pkg|xf86-video-intel}}. || Works well with {{Pkg|alsa-utils}}. || Yes, works out of the box || Yes, with {{pkg|broadcom-wl}} || Untested || Suspend-to-RAM perfect. Hibernate untested. Disk spindown untested. || No || Synaptics touchpad work flawlessly. Wifi on/off and brightness ''Fn keys'' work flawlessly. Webcam and integrated microphone work. || Volume up / down and player control buttons need configuring through key bindings to work.<br />
|-<br />
| [[Dell Inspiron 15 3541|Inspiron 15 3000 Series (Model 3541)]] || 2016.01.01 || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}}<br />
|-<br />
| [[Dell Inspiron 5547|Inspiron 15 5000 Series (Model 5547)]] || 2016.01.25 || Hybrid graphics/AMD Radeon R7 M260/M265, Please read [[Hybrid graphics#Dynamic Switching Model]]. This has not be tested yet.|| Works with Intel HD Audio and [[PulseAudio]], but need to configure [[PulseAudio/Troubleshooting#Microphone_not_detected_by_PulseAudio|microphone]] || Yes || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM untested. Hibernate untested. Disk spindown untested. || No modem || HDMI work, need configuration to swith between monitor. The touchpad work properly, but just test the basics || Webcam works, SD card reader untested<br />
|-<br />
| [[Dell Inspiron 5566|Inspiron 15 5000 Series (Model 5566)]] || 2020.09.24 || Intel® HD Graphics 620. Works out of the box with {{Pkg|xf86-video-intel}}. || Intel HD Audio with ALSA. || Not tested. || Yes, with {{Pkg|networkmanager}} and {{Pkg|dhcpcd}} or {{AUR|networkmanager-iwd}} || Yes, works with {{Pkg|bluez-utils}}. || Suspend-to-RAM untested. Hibernate untested. Disk spindown untested. But good battery performance using [[TLP]]. || No modem || The touchpad work properly, but just test the basics. HDMI untested. || Webcam works, SD card reader untested.<br />
|-<br />
| [[Dell Inspiron 15 5559|Inspiron 15 5000 Series (Model 5559)]] || 2021.07.19 || Intel® HD Graphics 520. || Intel HD Audio with ALSA || Yes, out of the box. || Intel Corp. Wireless 3160 with iwlwifi and nmcli || Untested. || Untested. || Untested. || {{-}} || {{-}} <br />
|-<br />
| Inspiron 15 7000 Series (Model 7537) || 2016.06.01 || Intel® HD Graphics 4400. Works out of the box with {{Pkg|xf86-video-intel}}. || Intel HD Audio. Works out of the box. || Yes RJ45 Ethernet || Intel 7260N or 7260AC, Works out of the box with iwlwifi. || Yes, works out of the box. || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown untested. || No modem || HDMI perfect. The touchpad works with minimal configuration. || Volume up / down button needs some modifying to work all other buttons work with drivers that come with the kernel. ACPI battery is not detected on bootup and requires you to plug in and out the AC adapter.<br />
|-<br />
| Inspiron 15 7000 Series (Model 7570) || 2021.10.27 || Intel® UHD Graphics 620 (KBL GT2). Works out of the box with both modesetting and {{Pkg|xf86-video-intel}}. || Intel HD Audio. Works out of the box. || Yes RJ45 Ethernet || Intel 9260N or 9260AC, Works out of the box with iwlwifi. || Yes, works out of the box. || Suspend-to-RAM perfect. Hibernate perfect. || No modem || HDMI perfect. Touchpad perfect (gestures not tested). Webcam perfect (uvcvideo). USB-C DisplayPort alt-mode works reasonably well. || USB-C DisplayPort alt-mode tested with a Dell P2721Q monitor. 65W of power, USB hub and Video delivered over USB-C work well. Rare issues with the monitor sometimes losing the video connection when switching users or logging out (on resolution changes). The power and USB keep working though.<br />
|-<br />
| Inspiron 15 7000 Series (Model 7548) || 2015.05 || AMD Radeon® R7 M270 || Untested || N/A || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM perfect. Hibernate untested. Disk spindown untested. || No modem || HDMI is currently untested. The touchpad (clickpad) needs some tweaking to work properly. If the kernel [https://bbs.archlinux.org/viewtopic.php?id=200763 panics] during bootup replace the 'keyboard'-hook with the specifc module.|| Webcam works, SD card reader untested<br />
|-<br />
| Inspiron 15 7000 Series (Model 7559) || 2016.08 || Hybrid graphics NVIDIA GM107M(GeForce GTX960M)({{Pkg|nvidia}}) + Intel HD Graphics 530 ({{Pkg|xf86-video-intel}}) via [[Bumblebee]] ([https://github.com/Bumblebee-Project/bbswitch/issues/140 see this issue]) || Intel HD Audio. Works out of the box. || Yes (you may need the [[Network_configuration/Ethernet#Realtek_RTL8111/8168B|r8168]] module). || Yes, works out of the box || Yes || Suspend-to-RAM and hibernate works. || No modem || HDMI tested only for presentation with projector via HDMI-VGA cable - works out of the box. || Webcam works, SD card reader works, ACPI battery detection works<br />
|-<br />
| Inspiron 15 7000 Series (Model 7566) || 2016.12 || Hybrid graphics NVIDIA GM107M(GeForce GTX960M)({{Pkg|nvidia}}) + Intel HD Graphics 530 ({{Pkg|xf86-video-intel}}) via [[Bumblebee]] || Intel HD Audio. Works out of the box. || Yes. || Yes, works out of the box || Yes || Suspend-to-RAM works. Otherwise untested. || No modem || HDMI has issues connecting monitor after turning laptop on. If monitor is connected before, there is no problem.(might be caused by bad config) || Webcam works, SD card reader works, ACPI battery detection works<br />
|-<br />
| [[Dell Inspiron 15 (7590)|Inspiron 15 7000 Series (Model 7590)]] || 2020.02 || Hybrid graphics NVIDIA GTX1650 ({{Pkg|nvidia}}) + Intel HD Graphics 620 ({{Pkg|xf86-video-intel}}) via [[Bumblebee]] || Intel HD Audio. May require `snd_hda_intel.dmic_detect=0` kernel option to work. Cannot get microphone working. || N/A, did not check thunderbolt yet. || Yes, works out of the box || Untested || Suspend-to-RAM works. About 10 hours of youtube watching if NVIDIA card is not powered || No modem || HDMI works out of the box. Did not check thunderbolt, but according to the link it works || Webcam works, ACPI battery detection works<br />
|-<br />
| Inspiron 13 7000 Series (7370) || 2017.12 || Intel® UHD-Graphics 620. Works out of the box with {{Pkg|xf86-video-intel}}. || Intel HD Audio. Works out of the box. || N/A || Intel® Dual Band Wireless-AC 7265, works out of the box || Yes || Suspend-to-RAM works. Does not wake up after closing the screen lid. || N/A || HDMI works, SD card reader works, USB-C works with support for DisplayPort and charging, keyboard backlight brightness control works || Integrated [https://bugs.launchpad.net/ubuntu/+source/libfprint/+bug/1641290 fingerprint reader is unsupported]. {{ic|Fn}} keys work except [https://bugzilla.kernel.org/show_bug.cgi?id=198393 Wireless toggle]<br />
|-<br />
| Inspiron M5030 || Any || [[ATI]] works fine, [[catalyst]]{{Archived page}} untested || Yes, works out of the box || Yes || Yes, works out of the box || N/A || Untested || N/A || Everything works alright, and out of the box. || {{AUR|i8kutils}} required for fan control<br />
|-<br />
| Inspiron Duo 1090 (hybrid touchscreen netbook/tablet) || 2014.10.01 || Intel Atom Integrated VGA graphics controller. Software 3D, works out-of-the-box (1366x768). || Intel HD Audio with ALSA || No. || Yes, Qualcomm Atheros (ath9k) || Untested || Suspend-to-RAM works flawlessly. Hibernate untested. || No. || eGalax touchscreen and Synaptics touchpad work flawlessly. All function keys (Power manager, Wifi on/off, touchpad on/off, brightness and audio up/down work flawlessly. Webcam and integrated microphone work. || Audio out works, no standard audio-in or video out ports. USB audio-in and USB video-out untested. <br />
|-<br />
| Dell Inspiron 5567|Inspiron 15 5000 Series (model 5567) - Intel i5, no AMD || 2020.04.01 || Intel HD Graphics, 3D with {{Pkg|mesa}}, modesetting driver. {{ic|<nowiki>export MESA_LOADER_DRIVER_OVERRIDE=i965</nowiki>}} if you do not want to use a compositor. || Intel HD audio || Yes || Yes || Yes || Yes || Yes || Everything else works || Make sure to not have {{Pkg|xf86-video-intel}} as it runs worse, the correct vaapi driver is {{Pkg|intel-media-driver}}. Very Linux friendly overall.<br />
|-<br />
| [[Dell Inspiron 5575|Inspiron 15 5000 Series (model 5575)]] || 2019.12.01 || AMD Vega 8 Gfx graphics. || AMD. || Yes. Untested. || Yes, Qualcomm Atheros (ath10k) || Yes. Works out of the box || Suspend to ram and hibernation works flawlessly. || No. || Synaptics touchpad work flawlessly. HDMI untested. || Webcam works,SD card reader untested, fn keys work. Overall, linux-friendly and everything I tested works out of the box.<br />
|-<br />
| [[Dell Inspiron 7586|Inspiron 15 7000 Series (model 7586)]] || 2019.07.01 || Intel UHD Graphics 620 (Whiskey Lake) and NVIDIA GeForce MX150 (1D10) || Intel HD Works out of box || N/A || Yes, Intel 9560 (iwlwifi) || Yes || Suspend-to-RAM perfect. Hibernate untested. Disk spindown untested. || N/A || Touchpad works fine, fingerprint works with a proprietary driver. || Touchscreen, autorotation of screen, work out of box. Active pen works out of box in Gnome but axis are flipped in i3wm, a script would solve this. SD card reader works, webcam untested. So far a great experience running Arch with this system.<br />
|-<br />
| [[Dell Inspiron 13 (5391)|Inspiron 13 5000 Series (model 5391)]] || 2020.09 || Intel UHD Graphics || Intel || No || Intel Corporation Wireless-AC 9462 || Unknown || No || No || No || No<br />
|-<br />
| Inspiron 13 7000 Series (model 7348) || 2021 || Intel UHD Graphics, works out of the box ({{pkg|mesa}} and {{pkg|vulkan-intel}}) || Intel, works out of the box with {{pkg|alsa-utils}} || N/A || Intel Corporation Wireless-AC 7265 works out of the box, succesfully upgraded to Intel AX 200 (both with iwlwifi module) || Intel, works out of the box both with AC 7265 and AX 200 || Suspend to RAM works fine. || N/A || Touchscreen, Microphone, Webcam work all fine out of the box. || No<br />
|}<br />
<br />
== Latitude ==<br />
<br />
{{Laptops table header}}<br />
| Latitude D620 || Duke || 3D with NVIDIA, native resolution with {{Pkg|xorg-server}} 1.2 (1440x900)<br> 3D with Intel 945GM, native resolution 1440x900 || Intel HD Audio with ALSA || Yes || Yes, bcm4311 PCI-E with bcm43xx. Yes for some models with iwl3945. || N/A || Suspend-to-RAM perfect, hibernate works fine. || Untested || not tested smart card reader || Everything else works without a hitch<br />
|-<br />
| Latitude D820 || Duke || 3D with NVIDIA drivers || Intel HD Audio with ALSA || Yes || Yes, IPW3945 || Yes || Suspending with [[KDE]] works || Untested || Everything works, even fingerprint reader with ''bioapi'' and ''pam_bioapi'' || Everything else works without a hitch<br />
|-<br />
| Latitude D830 || Don't Panic (2007.08-2) || NVIDIA Quadro NVS 140M with proprietary NVIDIA drivers || ALSA with the {{ic|snd_hda_intel}} module || Yes, with {{ic|tg3}} module || Yes, with {{ic|iwl3965}} module || Yes || Yes || Untested || ||<br />
|-<br />
| Latitude E5500 || 2016.03.01 || Intel® HD Graphics 4000, use {{pkg|xf86-video-intel}} || Works well with {{Pkg|alsa-utils}} || Untested || Yes, b43 || Untested || Yes || Untested || The luminosity sensor works out of the box || Everything seems to work without problems<br />
|-<br />
| [[Dell Latitude E5430|Latitude E5430]] || 2016.02.01 || Intel® HD Graphics 4000, use {{pkg|xf86-video-intel}} || Intel HD Audio. Works out of the box. || Yes, Ethernet port, {{ic|tg3}} || Yes, with {{pkg|broadcom-wl}} or ''b43'' || Yes, with {{pkg|bluez}} || Suspend-to-RAM perfect, hibernate works fine. || No modem || webcam, card reader and fingerprint reader works fine || Everything seems to work without problems<br />
|-<br />
| [[Dell Latitude E5540|Latitude E5540]] || 2016.02.01 || Haswell-ULT Integrated + GeForce GT 720M using {{Pkg|nvidia}} || Haswell-ULT HD Audio || Yes, e1000e || Yes, Atheros AR9485 || Untested || Untested || No modem || Dock works fine (DisplayPort expander, ethernet, USB || Everything seems to work without problems<br />
|-<br />
| Latitude E5570 || 2017.02.01 || Skylake Integrated + AMD Radeon HD 8750M || Skylake Integrated. Works well with {{Pkg|alsa-utils}} || Yes, Intel I219-LM (rev 31) || Yes, Intel 8260 (rev 3a) || Untested || Untested || No modem || All Dock Ports function || BIOS Firmware bug may report incorrect RAM size. Booting UEFI does not have the issue.<br />
|-<br />
| [[Dell Latitude E5580]] || 2018.07.01 || Kaby Lake + GeForce 940MX (blacklist nouveau, run [[bumblebee]]/[[NVIDIA]] drivers) || Yes, Intel CM238 || Yes, (Intel I219-LM) || Yes, Intel 8265 / 8275 || Working || Working, Some complaints || No modem || All Dock Ports function (TB16 and WD15 both tested working) || UEFI working with NVMe drive via AHCPI, Backlit keys, Function keys<br />
|-<br />
| Latitude E5401 || 2019.10 || Intel Corporation UHD Graphics 630, use {{pkg|xf86-video-intel}},3D NVIDIA GP108M [GeForce MX150] - disabled || Intel HD Audio (ALC3204). Works. || Yes, Ethernet port, Intel I219-LM || Yes, Intel AC 9560 with iwlwifi } || Yes, with {{pkg|bluez}} || Suspend-to-RAM works, hibernate untested. || No modem || webcam untested, card reader works. Thunderbolt 3 ( JHL6340) - untested || Poor thermal design (i7 i7-9850H CPU @ 2.60GHz)<br />
|-<br />
| Latitude E6230 || 2018.12 || Intel HD4000 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes || Yes, Intel Centrino A-N 6205 with iwlwifi || No Bluetooth || Suspend-to-RAM perfect, hibernate untested || No modem || SD card reader works, smart card reader works, RFID reader works after enabling RFID radio, see [https://blog.g3rt.nl/enable-dell-nfc-contactless-reader.html this blog post], Touchpad (alps a10) shaky || Everything else works without a hitch <br />
|-<br />
| Latitude E6410 || 2018.06.01 || Nvidia Quatro NVS3100m W/ NVIDIA 340xx Drivers || Intel HD Audio with ALSA - PulseAudio Untested || Yes || Yes, Works after installation || Not Functioning - Working on it || Lid-Closed suspension not functioning right || N/A || Fingerprint Sensor not functioning, no drivers seem to exist || Everything but 1. Bluetooth 2. Fingerprint Sensor 3. Suspension on closing the lid works, and I am working actively on finding fixes<br />
|-<br />
| Latitude E6410 (BIOS A16)|| 2018.08.01 || Intel HD, use {{pkg|xf86-video-intel}} || Intel HD Audio, [[ALSA]] + [[PulseAudio]] || Yes || Yes (Centrino Advanced-N 6200) || Untested || Untested || N/A || For advanced touchpad functionality install {{pkg|xf86-input-synaptics}} and create {{ic|/etc/X11/xorg.conf.d/70-synaptics.conf}} (see [[Touchpad Synaptics]])|| [[EFISTUB]] bootmanager does not work for me, [[GRUB]] works. Latest BIOS A16 does not contain latest ucode, install {{pkg|intel-ucode}}. SD card reader works but is unreliable. Webcam works.<br />
|-<br />
| Latitude E6420 || 2011.08.19 || Intel HD3000 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes, e1000e || Yes, bcma-pci-bridge || Untested || Suspend-to-RAM perfect, hibernate perfect || No modem || SD card reader works out-of-the-box, smart card reader works with ccid, opensc, pcsc-tools. || Ethernet was not working in fresh installation, had to clone repositories to HDD and update<br />
|-<br />
| Latitude E6430 || 2018.12 || Intel HD4000 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes, e1000e || Yes, Intel Centrino A-N 6205 with iwlwifi || Untested || Suspend-to-RAM perfect, hibernate untested || untested || SD card reader untested, smart card reader untested, Touchpad (alps a10) shaky || Everything else works without a hitch <br />
|-<br />
| Latitude E6530 || 2014.10.01 || NVIDIA NVS5200 3D works flawlessly with either {{Pkg|nvidia}} or {{Pkg|xf86-video-nouveau}} (1600x900). || Intel HD Audio with ALSA || Yes || Intel Centrino A-N (with iwlwifi) || Flawless. File transfer and Audio streaming works || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown perfect. || Untested || SD card reader, ALPS touchpad with gestures, and Webcam work flawlessly. Integrated and external microphone ports work flawlessly. Backlit keyboard, monitor backlight, audio up/down/mute controls all work flawlessly. || HDMI video works but must disable Optimus in bios. HDMI audio out works. If Optimus enabled, Intel HD4000 will be used and optirun works. Prevents use of HDMI (VGA only) but otherwise works.<br />
|-<br />
| [[Dell Latitude E7270|Latitude E7270]] || 2017.01.01 || {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA and Pulseaudio || yes || yes (IWL 8260) || untested || suspend-to-RAM after UEFI Update, hibernate works || Yes, working without runtime pm || || High suspend usage with power share port active<br />
|-<br />
| [[Dell Latitude 7370|Latitude 7370]] || || || || || || || || || ||<br />
|-<br />
| Latitude 7390 ( 2-in-1 ) || 2019.02.01 || Intel UHD Graphics 620 ( works with and without {{pkg|xf86-video-intel}} ) || Intel HD Audio with ALSA and Pulseaudio || yes || yes || yes || yes || untested || || Touchscreen display works<br />
|-<br />
| [[Dell Latitude E7440|Latitude E7440]] || || Yes || Yes || Yes || Yes || Yes || Yes, some complaints || || ||<br />
|-<br />
| [https://www.dell.com/us/business/p/latitude-e7450-ultrabook/pd?oc=cal147w7pf2 Latitude E7450] || [https://archlinux.org/releng/releases/2016.03.01/ 2016.03.01] || Intel HD5500 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes || Intel Wireless 7265 || BT 4.0 LE, untested || Suspend-to-RAM perfect, Hibernate does not work. SSD drive (no spindown) || No. || SD card reader. Synaptics touchpad + stick. Webcam works without problems. Backlit keyboard. Integrated mic works. FN-keys works once you set them up (lock, volume, monitor, search, sleep, backlight). RFID reader. Fingerprint reader. Get about 9h batterylife. Intel i7 CPU, 16GB RAM. || Everything else works without a hitch<br />
|-<br />
| [[Dell Latitude E7470|Latitude E7470]] || 2017.01.01 || Yes || Yes || Yes || Yes || Yes || Suspend-to-RAM perfect, hibernate untested || N/A || [[EFISTUB]] bootmanager does not work because it seems impossible to pass kernel parameters. Not via [[efibootmgr]], nor [[UEFI]] shell bcfg, nor the built-in gui. All ports of the docking station (PR03X) work. ||<br />
|-<br />
| [[Dell Latitude 3500|Latitude 3500]] || 2020.10.28 || Intel UHD Graphics 620 (Whiskey Lake) || Intel HD Audio with Pulseaudio || Yes || Yes || Yes, with {{Pkg|bluez}} || Suspend-to-RAM perfect, hibernate perfect || N/A || Fingerprint reader works with proprietary driver. || See linked article for more details<br />
|-<br />
| Latitude 5580 || ± 2017.11.06 || Intel Graphics work, NVIDIA (fails on first attempt, did not try harder) || Intel HD Audio with ALSA and Pulseaudio || Yes, ethernet port I219-LM (rev 31) || Yes, Intel 8265 / 8275 (rev 78) || Yes, audio streaming and file transfer || Works (needs BIOS update ([[fwupd]]) to not have black screen when resuming sometimes) || || Webcam works; Backlight changeable; BIOS, TPM and SanDisk SSD firmware updatable with [[fwupd]]; UEFI works || NVIDIA drivers work in Ubuntu, so it should be possible to get it working; I cannot remember the exact CD version I used.<br />
|-<br />
| Latitude 7420 || 2020/10 || Yes || Yes || || Yes || Yes || Yes || || CPU throttle to 400mhz after short power-intensive workloads. With [https://github.com/intel/thermal_daemon Thermald] CPU can reach 1800mhz(15w). This bug not fixed yet. Please see this thread to more info: https://github.com/intel/thermal_daemon/issues/293 ||<br />
|-<br />
<br />
|-<br />
| [[Dell Latitude 7480|Latitude 7480]] || || Yes || || || Yes || Yes || || || webcam Fingerprint reader not working ||<br />
|-<br />
| [[Dell Latitude 7490|Latitude 7490]] || || Yes || Yes || Yes || Yes || Yes || Yes || Yes || ||<br />
|-<br />
| Latitude 5511 || 2020.10 || Yes || Yes || || Yes || || || || '''Freezing.''' Probably issues with KINGSTON SA2000M81000G NVME HDD. Under investigation. See <https://tekbyte.net/2020/fixing-nvme-ssd-problems-on-linux/>. <br />
|| WD19 Docking station OK<br />
|}<br />
<br />
== Precision ==<br />
<br />
{{Laptops table header}}<br />
| Precision M4800 || 2014.04.01 || System not usable if booted without kernel parameter {{ic|nomodeset}}. Nvidia Quadro K2100M works with {{Pkg|nvidia}}, but [[Nouveau]] does not work because it requires KMS. || Untested || Yes || Yes || Untested || Untested || No modem || N/A || {{ic|nomodeset}} is ''required'' to boot to a usable system, both with the Arch installation media and post-installation.<br />
|-<br />
| Precision M6700 || 2017.01.01 || [Nvidia] Quadro K3000M works with both [[Nouveau]] and {{Pkg|nvidia}}. || Intel Corporation 7 Series/C216 HD Audio with Pulse Audio works; HDMI audio device untested || yes || Intel Corporation Wireless 7260 output works || not tested || Suspend and Hibernate works. || N/A || Touchpad, trackpoint, special function keys work || KDE Plasma works perfectly; Occasional GPU freezes with "GPU has fallen off the bus" errors since January 2018 ( kernel 4.14.15-1 and NVIDIA Kernel Module 387.34)<br />
|-<br />
| Precision 7710 || 2017.11.01 || [AMD/ATI] Venus XTX [Radeon HD 8890M / R9 M275X/M375X] (rev 83) works without problems. || Intel Corporation Sunrise Point-H HD Audio (rev 31) with Pulse Audio works || yes || Intel Corporation Wireless 8260 (rev 3a) output works; microphone not detected by pulse audio; HDMI audio device untested || not tested || Suspend works if no BIOS hard drive password. Hibernate untested. || N/A || || Solid experience using XFCE; all defaults. Lots of errors when booting up about the video card, etc., but no noticeable problems. xcalib -a -i; is very slow -- not sure why.<br />
|-<br />
| Precision 5510 || 2020.04.01 || [Nvidia] Quadro M1000 Mobile and Intel HD 530 with [NVIDIA Optimus]. Quadro M1000 Mobile works well with optimus-manager || Works out of the box; Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller (rev 31) || yes || Intel Corporation Wireless 8260 (rev 3a) || Works out of the box || Suspend works || N/A || SD Card reader, webcam, mic and function keys work out of the box.|| Essentially the same device as the [[Dell XPS 15 9550]]<br />
|-<br />
| Precision 3530 || 2020.07.01 || [Nvidia] Quadro P600 Mobile and Intel UHD 630 with [NVIDIA Optimus]. Quadro P600 Mobile works well with nvidia-prime || Works out of the box; Intel Corporation Cannon Lake PCH cAVS (rev 10)|| yes || Intel Corporation Wireless-AC 9560 (rev 10) || Works out of the box || Suspend works. You need to disable early microcode loading || No modem || SD Card reader, webcam, mic and function keys work out of the box. || Upgrade the Thunderbolt controller to latest available firmware from Windows and, if needed, disable Thunderbolt security within the BIOS (especially with TB16 docking station).<br />
|-<br />
| Precision 5520 || 2018.02.01 || [Nvidia] Quadro M1200 Mobile disabled for Energy consumption reasons. Quadro M1200 Mobile works well with {{Pkg|nvidia}} and [[bumblebee]] with {{Pkg|tlp}}. {{Pkg|bbswitch}} does work. Intel HD P630 works with {{Pkg|xf86-video-intel}} || Works out of the box || yes || Qualcomm QCA61x4A works flawless || Works out of the box || Suspend work|| N/A || SD Card reader, webcam, mic and function keys work out of the box.|| Everything works out of the box for Dell Precision developer edition<br />
|-<br />
| Precision 5530 || 2018.06.01 || [Nvidia] Quadro P2000 Mobile disabled for Energy consumption reasons. Quadro P1000 works well with {{Pkg|nvidia}} and [[bumblebee]] with {{Pkg|tlp}}. {{Pkg|bbswitch}} does not work. Intel HD630 works with {{Pkg|xf86-video-intel}}. || Works out of the box || yes || Intel Corporation Wireless-AC 9260 works flawless with Linux 4.18 || Works with occasional driver reloads {{ic|modprobe btusb}} || Suspend works. Need to change sleep state as per [[Dell XPS 15 9570]]. || N/A || SD Card reader, webcam, mic and function keys work out of the box.|| Besides occasional bluetooth issues a great experience so far.<br />
|}<br />
<br />
== Studio ==<br />
<br />
{{Laptops table header}}<br />
| Studio 1749 || 2013.01.04 || Radeon HD 5650M, {{ic|xf86-video-ati}} is almost flawless (just slower 3D), {{ic|catalyst}} is faster but has various issues. || HDA Intel MID, works with ALSA after adding {{ic|1=options snd-hda-intel index=0 model=dell-m6-dmic}} to {{ic|/etc/modprobe.d/alsa-base.conf}}. HDMI audio has some issues. || Yes || BCM43224, brcmsmac and {{pkg|broadcom-wl}} both work || N/A || Suspend works; hibernate untested. || N/A || SD card reader works, media keys work, web cam, and microphone both work. || Flawless except for poor 3D performance and battery life.<br />
|-<br />
| Studio XPS M1640 || (2009.08) || ATI HD4670 Mobile works with {{Pkg|xf86-video-ati}} (see the forums for 3D support); Catalyst drivers untested || Works with Intel HD Audio and ALSA. || Yes || Works with iwlagn || Bluetooth works || Works but when using {{Pkg|xf86-video-ati}}, there is video corruption upon boot || N/A || Web cam works, media keys work with the {{ic|dell_laptop}} kernel module, IR works, card reader works || Everything basically worked out-of-the-box<br />
|}<br />
<br />
== Vostro ==<br />
<br />
{{Laptops table header}}<br />
| Vostro 1710 || {{-}} || {{-}} || {{-}} || Yes, RTL8111/8168B || Works (Broadcom BCM4328) || {{-}} || {{-}} ||{{-}} || {{-}} || AlpsPS/2 ALPS GlidePoint<br />
|-<br />
| Vostro 5481 || 2019.11.01 || Works out of the box, {{Pkg|xf86-video-intel}} recommended just in case. || Yes || Yes || Yes. {{Pkg|broadcom-wl}} may be needed. || Yes || Yes ||{{-}} || {{-}} || Disable secure boot, fast boot, and TPM in the BIOS. Also, enable AHCI SATA Operation in the BIOS instead of RAID or the disk may not be detected. Do note that you will get a BSOD on Windows after this, which can be fixed by following this [https://support.thinkcritical.com/kb/articles/switch-windows-10-from-raid-ide-to-ahci quick guide].<br />
|-<br />
| Vostro 3583 || {{-}} || No need to install {{Pkg|xf86-video-intel}} and {{Pkg|xf86-video-amdgpu}} as modesetting drivers works perfectly. || Yes || Yes || Works || Yes || Yes ||{{-}} || Webcame works out of box || after resuming from sleep, wifi stops working for some unknown cause. work around is to reload kernel module ath10k_pci. AMD 520 Radeon performs less than Intel UHD 620 with both amdgpu and radeon module. same results under Windows <br />
|-<br />
| Vostro 3560 || 2020.02.01 || Works, use Radeon, installed {{Pkg|mesa}} and {{Pkg|mesa-vdpau}} for hardware acceleration. || Works || Works || Works (Atheros AR9485 - ath9k) || Works || Works || {{-}} || Fingerprint reader works. || Everything works.<br />
|-<br />
| Vostro 5590 || {{-}} || Works out of the box. Followed [[Bumblebee#Installation]]. || Works with {{Pkg|sof-firmware}}. || Yes || Yes || Yes || {{-}} || {{-}} || {{ - }} || <br />
<ul><br />
<li>Installing the package {{Pkg|sof-firmware}} solves all the audio problems.<li><br />
<li>Install package aur/pulseaudio-modules-bt, if device bluetooth-sound not working</li><br />
<li> execute: pactl load-module module-bluetooth-discover</li><br />
</ul><br />
|-<br />
| Vostro 7500 || 2020.10.16 || Works out of box using nouveau || Works with {{Pkg|sof-firmware}} || N/A || Works || {{-}} || {{-}} || {{-}} || Finger print scanner not yet supported. Webcam works out of box. || <br />
<ul><br />
<li>No audio out of box, but {{Pkg|sof-firmware}} fixes this issue. </li><br />
<li>SSD was initially in RAID configuration in the Bios + not detected by the installer. Fixed by changing to AHCI. </li><br />
<li>Dell UEFI implementation does not pass kernel parameters on boot, so EFIStub does not work. Side-stepped the issue by installing Grub.</li><br />
</ul><br />
|}<br />
<br />
== XPS ==<br />
<br />
{{Laptops table header}}<br />
| XPS L322 || 2013_03 || Intel HD 4000, with {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || No Ethernet port || Yes || Untested || Yes || No modem || No SD card slot || ALPS Touchpad recognized only as PS/2 mouse, two-finger scroll, finger tap-to-click, etc... does not work. Some new mouse drivers suggest a fix but have not worked.<br />
|-<br />
| [[Dell XPS M1330|XPS M1330]] || 2021-01) || works with Nouveau or mode-setting || Works with Intel HD Audio and ALSA or Pulseaudio, but need to configure microphone || Yes || Works with iwl4965, b43 driver || Works with bluez || (''acpi_cpufreq'' problem: [https://bbs.archlinux.org/viewtopic.php?id=44500 see forums]) || No modem || 2.0 MP web cam works with ''uvcvideo'', IR remote works, SD card works || Everything basically worked out-of-the-box except the microphone.<br />
|-<br />
| [[Dell XPS 13 (9333)|XPS 13 (9333)]] || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}}<br />
|-<br />
| [[Dell XPS 13 (9310)|XPS 13 (9310)]] || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}}<br />
|-<br />
| [[Dell XPS 13 (9343)|XPS 13 (9343)]] || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}}<br />
|-<br />
| [[Dell XPS 13 (9350)|XPS 13 (9350)]] || {{-}} || Yes || Yes || Yes || Yes, after firmware update || Yes (Suspend and Hibernate) || {{-}} || {{-}} || All Dock Ports function (WD15 tested working, except Ethernet Realtek 8152/8153 not resuming from USB supend mode. Install WD15 firmware 1.0.4 to fix.) || Everything basically works out-of-the-box with a reasonably up-to-date kernel.<br />
|-<br />
| [[Dell XPS 13 (9360)|XPS 13 (9360)]] || {{-}} || Yes || Yes || Yes || Yes, after firmware update || Yes (Suspend and Hibernate) || {{-}} || {{-}} || {{-}} || Everything basically works out-of-the-box with a reasonably up-to-date kernel.<br />
|-<br />
| [[Dell XPS 13 (9370)|XPS 13 (9370)]] || {{-}} || Yes || Yes || Yes || Yes || Yes || {{-}} || {{-}} || {{-}} || {{-}}<br />
|-<br />
| [[Dell XPS 13 (9380)|XPS 13 (9380)]] || 2019 || Yes || Yes || Yes || Yes || Yes || {{-}} || {{-}} || {{-}} || Everything basically works out-of-the-box with a reasonably up-to-date kernel. <br />
|-<br />
| [[Dell XPS 13 2-in-1 (9365)|XPS 13 2-in-1 (9365)]] || {{-}} || Yes || Yes || No Ethernet Port || Yes || Yes (Suspend and Hibernate) || {{-}} || {{-}} || {{-}} || Everything basically works out-of-the-box with a reasonably up-to-date kernel.<br />
|-<br />
| [[Dell XPS 13 (7390)|XPS 13 (7390)]] || {{-}} || Yes || Yes || No Ethernet Port || Yes || Yes || {{-}} || {{-}} || Fingerprint not tested as the developer version does not have one. || This is the regular XPS 13, not the 2-in-1. Only tested with Wayland (Sway WM) ecosystem.<br />
|-<br />
| [[Dell XPS 13 2-in-1 (7390)|XPS 13 2-in-1 (7390)]] || 2019.09.01 || Yes || Yes || No Ethernet Port || Yes || Yes (Requires Drivers) || {{-}} || No Modem || Camera, Fingerprint Sensor not working || System freezes on boot. See device page for fix.<br />
|-<br />
| [[Dell XPS 15]] || {{-}} || Intel HD 530 works with {{Pkg|xf86-video-intel}} i915 and GTX 960M works with {{Pkg|nvidia}} || Yes || No Ethernet Port || Yes || Yes || Yes || No Modem || {{-}} || Everything basically works out-of-the-box with a reasonably up-to-date kernel.<br />
|-<br />
| [[Dell XPS 17 (9700)]] || {{-}} || Intel UHD (CML GT2) works with {{Pkg|mesa}} or {{Pkg|xf86-video-intel}} and GTX 1650 Ti/RTX 2060 Max-Q works with {{Pkg|nvidia}} || Yes || No Ethernet Port || Yes || Yes || Yes || No Modem || Camera working, Fingerprint sensor workable. || Builtin audio can work, but is currently difficult to get working.<br />
|}<br />
<br />
== G3 ==<br />
<br />
{{Laptops table header}}<br />
| G3 15 3590 || 2020.19.10 || Intel UHD 630 and NVIDIA GTX 1050/1660 Mobile {{Pkg|nvidia}} and {{Pkg|nvidia-prime}} using [[PRIME#PRIME render offload|PRIME Render Offloading]]. Until now, [[GPGPU#CUDA|NVIDIA CUDA]] is not working with linux 5.9 || You must install {{Pkg|sof-firmware}} and any kernel after 5.6.3+ to get internal microphone/sound working. || Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller || Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter || Working || Working || {{-}} || {{-}} || Works well with {{AUR|optimus-manager-git}}, follow [https://github.com/Askannz/optimus-manager/wiki/A-guide--to-power-management-options#configuration-1--built-in-power-management-inside-the-nvidia-driver their page on power managment]<br />
|}<br />
<br />
== G5 ==<br />
<br />
{{Laptops table header}}<br />
| [[Dell G5 5590-9340|G5 5590-9340]] || 2020.08.20 || Yes (both integrated and dedicated) || Yes || Yes || Yes || Yes || Yes || {{-}} || Goodix fingerprint reader not working due to lack of drivers but probably can be extracted from Ubuntu image this laptop goes with. || Everything works OOB except FP.</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Laptop/Dell&diff=700063Laptop/Dell2021-10-27T11:26:59Z<p>Wooptoo: Added Inspiron 15 7000 Series (Model 7570)</p>
<hr />
<div>[[Category:Dell]]<br />
[[ja:ノートパソコン/Dell]]<br />
{{Laptops navigation}}<br />
<br />
== Inspiron ==<br />
<br />
{{Laptops table header}}<br />
| Inspiron 1420 || 2012.09 || 3D with {{Pkg|xf86-video-nouveau}} || Intel HD Audio with ALSA || Yes || Yes, {{pkg|broadcom-wl}} is needed || Untested || Untested || Untested || Untested || Everything that I have tested works great without any problems<br />
|-<br />
| Inspiron 1501 || Duke || 3D with proprietary ATI fglrx || Intel HD audio with ALSA || Yes || Yes, BCM4311 PCI-E with bcm43xx || N/A || Untested || Untested || Smart card reader works out-of-the-box || Everything else works without a hitch<br />
|-<br />
| Inspiron 1520 || Core Dump || 3D with NVIDIA || SigmaTel audio with ALSA || ''b44'' module, out of the box || ''b43'', need firmware || Yes || || Untested || Hot keys work out-of-the-box || Everything else works without a hitch<br />
|-<br />
| [[Dell Inspiron 1525|Inspiron 1525]] || Arch Linux 2008.06 - "Overlord" FTP Install || 3D with {{Pkg|xf86-video-intel}} 2.4.3, native resolution with {{Pkg|xorg-server}} 1.5.3 (1280x800) || Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || PRO/Wireless 3945ABG with ''iwlwifi-3945-ucode'' 15.28.2.8 || Untested (does not have) || Untested || Untested || SD card reader works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS. Everything else work out-of-the-box.<br />
|- <br />
| Inspiron 1525 || Core Dump (2008.03 ISO) || 3D with {{Pkg|xf86-video-intel}} 2.2, native resolution with {{Pkg|xorg-server}} 1.4 (1280x800)|| Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || Broadcom BCM4310: Yes, [[ndiswrapper]] ({{pkg|broadcom-wl}} works, but must blacklist {{ic|ssb}} module) || Untested (does not have) || Untested || Untested || SD card reader (Ricoh) works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS. DVD-RW drive and everything else work out-of-the-box.<br />
|- <br />
| Inspiron 1764 || 2011.08.19 || 3D with {{Pkg|xf86-video-intel}} || Works well with ALSA || Realtek RTL8101E 10/100 Ethernet Controller || [[Broadcom wireless|Broadcom BCM43224]] 802.11a/b/g/n works well with [[Broadcom_wireless#brcm80211|brcmsmac]] || Untested || Untested || Does not have a modem || SD card reader and LCD brightness {{ic|Fn}} keys work out-of-the-box || Fan control/monitoring is completely broken with {{AUR|i8kutils}}<br />
|-<br />
| [[Dell Inspiron 14 3420|Inspiron 14 3000 Series (Model 3420)]] || 2016.09.03 || Intel® HD Graphics 4000. Works out of the box with {{Pkg|xf86-video-intel}}. || Works well with {{Pkg|alsa-utils}}. || Yes, works out of the box || Yes, with {{pkg|broadcom-wl}} || Untested || Suspend-to-RAM perfect. Hibernate untested. Disk spindown untested. || No || Synaptics touchpad work flawlessly. Wifi on/off and brightness ''Fn keys'' work flawlessly. Webcam and integrated microphone work. || Volume up / down and player control buttons need configuring through key bindings to work.<br />
|-<br />
| [[Dell Inspiron 15 3541|Inspiron 15 3000 Series (Model 3541)]] || 2016.01.01 || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}}<br />
|-<br />
| [[Dell Inspiron 5547|Inspiron 15 5000 Series (Model 5547)]] || 2016.01.25 || Hybrid graphics/AMD Radeon R7 M260/M265, Please read [[Hybrid graphics#Dynamic Switching Model]]. This has not be tested yet.|| Works with Intel HD Audio and [[PulseAudio]], but need to configure [[PulseAudio/Troubleshooting#Microphone_not_detected_by_PulseAudio|microphone]] || Yes || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM untested. Hibernate untested. Disk spindown untested. || No modem || HDMI work, need configuration to swith between monitor. The touchpad work properly, but just test the basics || Webcam works, SD card reader untested<br />
|-<br />
| [[Dell Inspiron 5566|Inspiron 15 5000 Series (Model 5566)]] || 2020.09.24 || Intel® HD Graphics 620. Works out of the box with {{Pkg|xf86-video-intel}}. || Intel HD Audio with ALSA. || Not tested. || Yes, with {{Pkg|networkmanager}} and {{Pkg|dhcpcd}} or {{AUR|networkmanager-iwd}} || Yes, works with {{Pkg|bluez-utils}}. || Suspend-to-RAM untested. Hibernate untested. Disk spindown untested. But good battery performance using [[TLP]]. || No modem || The touchpad work properly, but just test the basics. HDMI untested. || Webcam works, SD card reader untested.<br />
|-<br />
| [[Dell Inspiron 15 5559|Inspiron 15 5000 Series (Model 5559)]] || 2021.07.19 || Intel® HD Graphics 520. || Intel HD Audio with ALSA || Yes, out of the box. || Intel Corp. Wireless 3160 with iwlwifi and nmcli || Untested. || Untested. || Untested. || {{-}} || {{-}} <br />
|-<br />
| Inspiron 15 7000 Series (Model 7537) || 2016.06.01 || Intel® HD Graphics 4400. Works out of the box with {{Pkg|xf86-video-intel}}. || Intel HD Audio. Works out of the box. || Yes RJ45 Ethernet || Intel 7260N or 7260AC, Works out of the box with iwlwifi. || Yes, works out of the box. || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown untested. || No modem || HDMI perfect. The touchpad works with minimal configuration. || Volume up / down button needs some modifying to work all other buttons work with drivers that come with the kernel. ACPI battery is not detected on bootup and requires you to plug in and out the AC adapter.<br />
|-<br />
| Inspiron 15 7000 Series (Model 7570) || 2021.10.27 || Intel® UHD Graphics 620 (KBL GT2). Works out of the box with both modesetting and {{Pkg|xf86-video-intel}}. || Intel HD Audio. Works out of the box. || Yes RJ45 Ethernet || Intel 9260N or 9260AC, Works out of the box with iwlwifi. || Yes, works out of the box. || Suspend-to-RAM perfect. Hibernate perfect. || No modem || HDMI perfect. Touchpad perfect (gestures not tested). USB-C DisplayPort alt-mode works well. || USB-C DisplayPort alt-mode tested with a Dell P2721Q monitor. 65W of power, USB hub and Video delivered over USB-C work well. Some issues with the monitor sometimes losing the video connection when switching users or logging out (on resolution changes). The power and USB keep working though.<br />
|-<br />
| Inspiron 15 7000 Series (Model 7548) || 2015.05 || AMD Radeon® R7 M270 || Untested || N/A || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM perfect. Hibernate untested. Disk spindown untested. || No modem || HDMI is currently untested. The touchpad (clickpad) needs some tweaking to work properly. If the kernel [https://bbs.archlinux.org/viewtopic.php?id=200763 panics] during bootup replace the 'keyboard'-hook with the specifc module.|| Webcam works, SD card reader untested<br />
|-<br />
| Inspiron 15 7000 Series (Model 7559) || 2016.08 || Hybrid graphics NVIDIA GM107M(GeForce GTX960M)({{Pkg|nvidia}}) + Intel HD Graphics 530 ({{Pkg|xf86-video-intel}}) via [[Bumblebee]] ([https://github.com/Bumblebee-Project/bbswitch/issues/140 see this issue]) || Intel HD Audio. Works out of the box. || Yes (you may need the [[Network_configuration/Ethernet#Realtek_RTL8111/8168B|r8168]] module). || Yes, works out of the box || Yes || Suspend-to-RAM and hibernate works. || No modem || HDMI tested only for presentation with projector via HDMI-VGA cable - works out of the box. || Webcam works, SD card reader works, ACPI battery detection works<br />
|-<br />
| Inspiron 15 7000 Series (Model 7566) || 2016.12 || Hybrid graphics NVIDIA GM107M(GeForce GTX960M)({{Pkg|nvidia}}) + Intel HD Graphics 530 ({{Pkg|xf86-video-intel}}) via [[Bumblebee]] || Intel HD Audio. Works out of the box. || Yes. || Yes, works out of the box || Yes || Suspend-to-RAM works. Otherwise untested. || No modem || HDMI has issues connecting monitor after turning laptop on. If monitor is connected before, there is no problem.(might be caused by bad config) || Webcam works, SD card reader works, ACPI battery detection works<br />
|-<br />
| [[Dell Inspiron 15 (7590)|Inspiron 15 7000 Series (Model 7590)]] || 2020.02 || Hybrid graphics NVIDIA GTX1650 ({{Pkg|nvidia}}) + Intel HD Graphics 620 ({{Pkg|xf86-video-intel}}) via [[Bumblebee]] || Intel HD Audio. May require `snd_hda_intel.dmic_detect=0` kernel option to work. Cannot get microphone working. || N/A, did not check thunderbolt yet. || Yes, works out of the box || Untested || Suspend-to-RAM works. About 10 hours of youtube watching if NVIDIA card is not powered || No modem || HDMI works out of the box. Did not check thunderbolt, but according to the link it works || Webcam works, ACPI battery detection works<br />
|-<br />
| Inspiron 13 7000 Series (7370) || 2017.12 || Intel® UHD-Graphics 620. Works out of the box with {{Pkg|xf86-video-intel}}. || Intel HD Audio. Works out of the box. || N/A || Intel® Dual Band Wireless-AC 7265, works out of the box || Yes || Suspend-to-RAM works. Does not wake up after closing the screen lid. || N/A || HDMI works, SD card reader works, USB-C works with support for DisplayPort and charging, keyboard backlight brightness control works || Integrated [https://bugs.launchpad.net/ubuntu/+source/libfprint/+bug/1641290 fingerprint reader is unsupported]. {{ic|Fn}} keys work except [https://bugzilla.kernel.org/show_bug.cgi?id=198393 Wireless toggle]<br />
|-<br />
| Inspiron M5030 || Any || [[ATI]] works fine, [[catalyst]]{{Archived page}} untested || Yes, works out of the box || Yes || Yes, works out of the box || N/A || Untested || N/A || Everything works alright, and out of the box. || {{AUR|i8kutils}} required for fan control<br />
|-<br />
| Inspiron Duo 1090 (hybrid touchscreen netbook/tablet) || 2014.10.01 || Intel Atom Integrated VGA graphics controller. Software 3D, works out-of-the-box (1366x768). || Intel HD Audio with ALSA || No. || Yes, Qualcomm Atheros (ath9k) || Untested || Suspend-to-RAM works flawlessly. Hibernate untested. || No. || eGalax touchscreen and Synaptics touchpad work flawlessly. All function keys (Power manager, Wifi on/off, touchpad on/off, brightness and audio up/down work flawlessly. Webcam and integrated microphone work. || Audio out works, no standard audio-in or video out ports. USB audio-in and USB video-out untested. <br />
|-<br />
| Dell Inspiron 5567|Inspiron 15 5000 Series (model 5567) - Intel i5, no AMD || 2020.04.01 || Intel HD Graphics, 3D with {{Pkg|mesa}}, modesetting driver. {{ic|<nowiki>export MESA_LOADER_DRIVER_OVERRIDE=i965</nowiki>}} if you do not want to use a compositor. || Intel HD audio || Yes || Yes || Yes || Yes || Yes || Everything else works || Make sure to not have {{Pkg|xf86-video-intel}} as it runs worse, the correct vaapi driver is {{Pkg|intel-media-driver}}. Very Linux friendly overall.<br />
|-<br />
| [[Dell Inspiron 5575|Inspiron 15 5000 Series (model 5575)]] || 2019.12.01 || AMD Vega 8 Gfx graphics. || AMD. || Yes. Untested. || Yes, Qualcomm Atheros (ath10k) || Yes. Works out of the box || Suspend to ram and hibernation works flawlessly. || No. || Synaptics touchpad work flawlessly. HDMI untested. || Webcam works,SD card reader untested, fn keys work. Overall, linux-friendly and everything I tested works out of the box.<br />
|-<br />
| [[Dell Inspiron 7586|Inspiron 15 7000 Series (model 7586)]] || 2019.07.01 || Intel UHD Graphics 620 (Whiskey Lake) and NVIDIA GeForce MX150 (1D10) || Intel HD Works out of box || N/A || Yes, Intel 9560 (iwlwifi) || Yes || Suspend-to-RAM perfect. Hibernate untested. Disk spindown untested. || N/A || Touchpad works fine, fingerprint works with a proprietary driver. || Touchscreen, autorotation of screen, work out of box. Active pen works out of box in Gnome but axis are flipped in i3wm, a script would solve this. SD card reader works, webcam untested. So far a great experience running Arch with this system.<br />
|-<br />
| [[Dell Inspiron 13 (5391)|Inspiron 13 5000 Series (model 5391)]] || 2020.09 || Intel UHD Graphics || Intel || No || Intel Corporation Wireless-AC 9462 || Unknown || No || No || No || No<br />
|-<br />
| Inspiron 13 7000 Series (model 7348) || 2021 || Intel UHD Graphics, works out of the box ({{pkg|mesa}} and {{pkg|vulkan-intel}}) || Intel, works out of the box with {{pkg|alsa-utils}} || N/A || Intel Corporation Wireless-AC 7265 works out of the box, succesfully upgraded to Intel AX 200 (both with iwlwifi module) || Intel, works out of the box both with AC 7265 and AX 200 || Suspend to RAM works fine. || N/A || Touchscreen, Microphone, Webcam work all fine out of the box. || No<br />
|}<br />
<br />
== Latitude ==<br />
<br />
{{Laptops table header}}<br />
| Latitude D620 || Duke || 3D with NVIDIA, native resolution with {{Pkg|xorg-server}} 1.2 (1440x900)<br> 3D with Intel 945GM, native resolution 1440x900 || Intel HD Audio with ALSA || Yes || Yes, bcm4311 PCI-E with bcm43xx. Yes for some models with iwl3945. || N/A || Suspend-to-RAM perfect, hibernate works fine. || Untested || not tested smart card reader || Everything else works without a hitch<br />
|-<br />
| Latitude D820 || Duke || 3D with NVIDIA drivers || Intel HD Audio with ALSA || Yes || Yes, IPW3945 || Yes || Suspending with [[KDE]] works || Untested || Everything works, even fingerprint reader with ''bioapi'' and ''pam_bioapi'' || Everything else works without a hitch<br />
|-<br />
| Latitude D830 || Don't Panic (2007.08-2) || NVIDIA Quadro NVS 140M with proprietary NVIDIA drivers || ALSA with the {{ic|snd_hda_intel}} module || Yes, with {{ic|tg3}} module || Yes, with {{ic|iwl3965}} module || Yes || Yes || Untested || ||<br />
|-<br />
| Latitude E5500 || 2016.03.01 || Intel® HD Graphics 4000, use {{pkg|xf86-video-intel}} || Works well with {{Pkg|alsa-utils}} || Untested || Yes, b43 || Untested || Yes || Untested || The luminosity sensor works out of the box || Everything seems to work without problems<br />
|-<br />
| [[Dell Latitude E5430|Latitude E5430]] || 2016.02.01 || Intel® HD Graphics 4000, use {{pkg|xf86-video-intel}} || Intel HD Audio. Works out of the box. || Yes, Ethernet port, {{ic|tg3}} || Yes, with {{pkg|broadcom-wl}} or ''b43'' || Yes, with {{pkg|bluez}} || Suspend-to-RAM perfect, hibernate works fine. || No modem || webcam, card reader and fingerprint reader works fine || Everything seems to work without problems<br />
|-<br />
| [[Dell Latitude E5540|Latitude E5540]] || 2016.02.01 || Haswell-ULT Integrated + GeForce GT 720M using {{Pkg|nvidia}} || Haswell-ULT HD Audio || Yes, e1000e || Yes, Atheros AR9485 || Untested || Untested || No modem || Dock works fine (DisplayPort expander, ethernet, USB || Everything seems to work without problems<br />
|-<br />
| Latitude E5570 || 2017.02.01 || Skylake Integrated + AMD Radeon HD 8750M || Skylake Integrated. Works well with {{Pkg|alsa-utils}} || Yes, Intel I219-LM (rev 31) || Yes, Intel 8260 (rev 3a) || Untested || Untested || No modem || All Dock Ports function || BIOS Firmware bug may report incorrect RAM size. Booting UEFI does not have the issue.<br />
|-<br />
| [[Dell Latitude E5580]] || 2018.07.01 || Kaby Lake + GeForce 940MX (blacklist nouveau, run [[bumblebee]]/[[NVIDIA]] drivers) || Yes, Intel CM238 || Yes, (Intel I219-LM) || Yes, Intel 8265 / 8275 || Working || Working, Some complaints || No modem || All Dock Ports function (TB16 and WD15 both tested working) || UEFI working with NVMe drive via AHCPI, Backlit keys, Function keys<br />
|-<br />
| Latitude E5401 || 2019.10 || Intel Corporation UHD Graphics 630, use {{pkg|xf86-video-intel}},3D NVIDIA GP108M [GeForce MX150] - disabled || Intel HD Audio (ALC3204). Works. || Yes, Ethernet port, Intel I219-LM || Yes, Intel AC 9560 with iwlwifi } || Yes, with {{pkg|bluez}} || Suspend-to-RAM works, hibernate untested. || No modem || webcam untested, card reader works. Thunderbolt 3 ( JHL6340) - untested || Poor thermal design (i7 i7-9850H CPU @ 2.60GHz)<br />
|-<br />
| Latitude E6230 || 2018.12 || Intel HD4000 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes || Yes, Intel Centrino A-N 6205 with iwlwifi || No Bluetooth || Suspend-to-RAM perfect, hibernate untested || No modem || SD card reader works, smart card reader works, RFID reader works after enabling RFID radio, see [https://blog.g3rt.nl/enable-dell-nfc-contactless-reader.html this blog post], Touchpad (alps a10) shaky || Everything else works without a hitch <br />
|-<br />
| Latitude E6410 || 2018.06.01 || Nvidia Quatro NVS3100m W/ NVIDIA 340xx Drivers || Intel HD Audio with ALSA - PulseAudio Untested || Yes || Yes, Works after installation || Not Functioning - Working on it || Lid-Closed suspension not functioning right || N/A || Fingerprint Sensor not functioning, no drivers seem to exist || Everything but 1. Bluetooth 2. Fingerprint Sensor 3. Suspension on closing the lid works, and I am working actively on finding fixes<br />
|-<br />
| Latitude E6410 (BIOS A16)|| 2018.08.01 || Intel HD, use {{pkg|xf86-video-intel}} || Intel HD Audio, [[ALSA]] + [[PulseAudio]] || Yes || Yes (Centrino Advanced-N 6200) || Untested || Untested || N/A || For advanced touchpad functionality install {{pkg|xf86-input-synaptics}} and create {{ic|/etc/X11/xorg.conf.d/70-synaptics.conf}} (see [[Touchpad Synaptics]])|| [[EFISTUB]] bootmanager does not work for me, [[GRUB]] works. Latest BIOS A16 does not contain latest ucode, install {{pkg|intel-ucode}}. SD card reader works but is unreliable. Webcam works.<br />
|-<br />
| Latitude E6420 || 2011.08.19 || Intel HD3000 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes, e1000e || Yes, bcma-pci-bridge || Untested || Suspend-to-RAM perfect, hibernate perfect || No modem || SD card reader works out-of-the-box, smart card reader works with ccid, opensc, pcsc-tools. || Ethernet was not working in fresh installation, had to clone repositories to HDD and update<br />
|-<br />
| Latitude E6430 || 2018.12 || Intel HD4000 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes, e1000e || Yes, Intel Centrino A-N 6205 with iwlwifi || Untested || Suspend-to-RAM perfect, hibernate untested || untested || SD card reader untested, smart card reader untested, Touchpad (alps a10) shaky || Everything else works without a hitch <br />
|-<br />
| Latitude E6530 || 2014.10.01 || NVIDIA NVS5200 3D works flawlessly with either {{Pkg|nvidia}} or {{Pkg|xf86-video-nouveau}} (1600x900). || Intel HD Audio with ALSA || Yes || Intel Centrino A-N (with iwlwifi) || Flawless. File transfer and Audio streaming works || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown perfect. || Untested || SD card reader, ALPS touchpad with gestures, and Webcam work flawlessly. Integrated and external microphone ports work flawlessly. Backlit keyboard, monitor backlight, audio up/down/mute controls all work flawlessly. || HDMI video works but must disable Optimus in bios. HDMI audio out works. If Optimus enabled, Intel HD4000 will be used and optirun works. Prevents use of HDMI (VGA only) but otherwise works.<br />
|-<br />
| [[Dell Latitude E7270|Latitude E7270]] || 2017.01.01 || {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA and Pulseaudio || yes || yes (IWL 8260) || untested || suspend-to-RAM after UEFI Update, hibernate works || Yes, working without runtime pm || || High suspend usage with power share port active<br />
|-<br />
| [[Dell Latitude 7370|Latitude 7370]] || || || || || || || || || ||<br />
|-<br />
| Latitude 7390 ( 2-in-1 ) || 2019.02.01 || Intel UHD Graphics 620 ( works with and without {{pkg|xf86-video-intel}} ) || Intel HD Audio with ALSA and Pulseaudio || yes || yes || yes || yes || untested || || Touchscreen display works<br />
|-<br />
| [[Dell Latitude E7440|Latitude E7440]] || || Yes || Yes || Yes || Yes || Yes || Yes, some complaints || || ||<br />
|-<br />
| [https://www.dell.com/us/business/p/latitude-e7450-ultrabook/pd?oc=cal147w7pf2 Latitude E7450] || [https://archlinux.org/releng/releases/2016.03.01/ 2016.03.01] || Intel HD5500 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes || Intel Wireless 7265 || BT 4.0 LE, untested || Suspend-to-RAM perfect, Hibernate does not work. SSD drive (no spindown) || No. || SD card reader. Synaptics touchpad + stick. Webcam works without problems. Backlit keyboard. Integrated mic works. FN-keys works once you set them up (lock, volume, monitor, search, sleep, backlight). RFID reader. Fingerprint reader. Get about 9h batterylife. Intel i7 CPU, 16GB RAM. || Everything else works without a hitch<br />
|-<br />
| [[Dell Latitude E7470|Latitude E7470]] || 2017.01.01 || Yes || Yes || Yes || Yes || Yes || Suspend-to-RAM perfect, hibernate untested || N/A || [[EFISTUB]] bootmanager does not work because it seems impossible to pass kernel parameters. Not via [[efibootmgr]], nor [[UEFI]] shell bcfg, nor the built-in gui. All ports of the docking station (PR03X) work. ||<br />
|-<br />
| [[Dell Latitude 3500|Latitude 3500]] || 2020.10.28 || Intel UHD Graphics 620 (Whiskey Lake) || Intel HD Audio with Pulseaudio || Yes || Yes || Yes, with {{Pkg|bluez}} || Suspend-to-RAM perfect, hibernate perfect || N/A || Fingerprint reader works with proprietary driver. || See linked article for more details<br />
|-<br />
| Latitude 5580 || ± 2017.11.06 || Intel Graphics work, NVIDIA (fails on first attempt, did not try harder) || Intel HD Audio with ALSA and Pulseaudio || Yes, ethernet port I219-LM (rev 31) || Yes, Intel 8265 / 8275 (rev 78) || Yes, audio streaming and file transfer || Works (needs BIOS update ([[fwupd]]) to not have black screen when resuming sometimes) || || Webcam works; Backlight changeable; BIOS, TPM and SanDisk SSD firmware updatable with [[fwupd]]; UEFI works || NVIDIA drivers work in Ubuntu, so it should be possible to get it working; I cannot remember the exact CD version I used.<br />
|-<br />
| Latitude 7420 || 2020/10 || Yes || Yes || || Yes || Yes || Yes || || CPU throttle to 400mhz after short power-intensive workloads. With [https://github.com/intel/thermal_daemon Thermald] CPU can reach 1800mhz(15w). This bug not fixed yet. Please see this thread to more info: https://github.com/intel/thermal_daemon/issues/293 ||<br />
|-<br />
<br />
|-<br />
| [[Dell Latitude 7480|Latitude 7480]] || || Yes || || || Yes || Yes || || || webcam Fingerprint reader not working ||<br />
|-<br />
| [[Dell Latitude 7490|Latitude 7490]] || || Yes || Yes || Yes || Yes || Yes || Yes || Yes || ||<br />
|-<br />
| Latitude 5511 || 2020.10 || Yes || Yes || || Yes || || || || '''Freezing.''' Probably issues with KINGSTON SA2000M81000G NVME HDD. Under investigation. See <https://tekbyte.net/2020/fixing-nvme-ssd-problems-on-linux/>. <br />
|| WD19 Docking station OK<br />
|}<br />
<br />
== Precision ==<br />
<br />
{{Laptops table header}}<br />
| Precision M4800 || 2014.04.01 || System not usable if booted without kernel parameter {{ic|nomodeset}}. Nvidia Quadro K2100M works with {{Pkg|nvidia}}, but [[Nouveau]] does not work because it requires KMS. || Untested || Yes || Yes || Untested || Untested || No modem || N/A || {{ic|nomodeset}} is ''required'' to boot to a usable system, both with the Arch installation media and post-installation.<br />
|-<br />
| Precision M6700 || 2017.01.01 || [Nvidia] Quadro K3000M works with both [[Nouveau]] and {{Pkg|nvidia}}. || Intel Corporation 7 Series/C216 HD Audio with Pulse Audio works; HDMI audio device untested || yes || Intel Corporation Wireless 7260 output works || not tested || Suspend and Hibernate works. || N/A || Touchpad, trackpoint, special function keys work || KDE Plasma works perfectly; Occasional GPU freezes with "GPU has fallen off the bus" errors since January 2018 ( kernel 4.14.15-1 and NVIDIA Kernel Module 387.34)<br />
|-<br />
| Precision 7710 || 2017.11.01 || [AMD/ATI] Venus XTX [Radeon HD 8890M / R9 M275X/M375X] (rev 83) works without problems. || Intel Corporation Sunrise Point-H HD Audio (rev 31) with Pulse Audio works || yes || Intel Corporation Wireless 8260 (rev 3a) output works; microphone not detected by pulse audio; HDMI audio device untested || not tested || Suspend works if no BIOS hard drive password. Hibernate untested. || N/A || || Solid experience using XFCE; all defaults. Lots of errors when booting up about the video card, etc., but no noticeable problems. xcalib -a -i; is very slow -- not sure why.<br />
|-<br />
| Precision 5510 || 2020.04.01 || [Nvidia] Quadro M1000 Mobile and Intel HD 530 with [NVIDIA Optimus]. Quadro M1000 Mobile works well with optimus-manager || Works out of the box; Intel Corporation 100 Series/C230 Series Chipset Family HD Audio Controller (rev 31) || yes || Intel Corporation Wireless 8260 (rev 3a) || Works out of the box || Suspend works || N/A || SD Card reader, webcam, mic and function keys work out of the box.|| Essentially the same device as the [[Dell XPS 15 9550]]<br />
|-<br />
| Precision 3530 || 2020.07.01 || [Nvidia] Quadro P600 Mobile and Intel UHD 630 with [NVIDIA Optimus]. Quadro P600 Mobile works well with nvidia-prime || Works out of the box; Intel Corporation Cannon Lake PCH cAVS (rev 10)|| yes || Intel Corporation Wireless-AC 9560 (rev 10) || Works out of the box || Suspend works. You need to disable early microcode loading || No modem || SD Card reader, webcam, mic and function keys work out of the box. || Upgrade the Thunderbolt controller to latest available firmware from Windows and, if needed, disable Thunderbolt security within the BIOS (especially with TB16 docking station).<br />
|-<br />
| Precision 5520 || 2018.02.01 || [Nvidia] Quadro M1200 Mobile disabled for Energy consumption reasons. Quadro M1200 Mobile works well with {{Pkg|nvidia}} and [[bumblebee]] with {{Pkg|tlp}}. {{Pkg|bbswitch}} does work. Intel HD P630 works with {{Pkg|xf86-video-intel}} || Works out of the box || yes || Qualcomm QCA61x4A works flawless || Works out of the box || Suspend work|| N/A || SD Card reader, webcam, mic and function keys work out of the box.|| Everything works out of the box for Dell Precision developer edition<br />
|-<br />
| Precision 5530 || 2018.06.01 || [Nvidia] Quadro P2000 Mobile disabled for Energy consumption reasons. Quadro P1000 works well with {{Pkg|nvidia}} and [[bumblebee]] with {{Pkg|tlp}}. {{Pkg|bbswitch}} does not work. Intel HD630 works with {{Pkg|xf86-video-intel}}. || Works out of the box || yes || Intel Corporation Wireless-AC 9260 works flawless with Linux 4.18 || Works with occasional driver reloads {{ic|modprobe btusb}} || Suspend works. Need to change sleep state as per [[Dell XPS 15 9570]]. || N/A || SD Card reader, webcam, mic and function keys work out of the box.|| Besides occasional bluetooth issues a great experience so far.<br />
|}<br />
<br />
== Studio ==<br />
<br />
{{Laptops table header}}<br />
| Studio 1749 || 2013.01.04 || Radeon HD 5650M, {{ic|xf86-video-ati}} is almost flawless (just slower 3D), {{ic|catalyst}} is faster but has various issues. || HDA Intel MID, works with ALSA after adding {{ic|1=options snd-hda-intel index=0 model=dell-m6-dmic}} to {{ic|/etc/modprobe.d/alsa-base.conf}}. HDMI audio has some issues. || Yes || BCM43224, brcmsmac and {{pkg|broadcom-wl}} both work || N/A || Suspend works; hibernate untested. || N/A || SD card reader works, media keys work, web cam, and microphone both work. || Flawless except for poor 3D performance and battery life.<br />
|-<br />
| Studio XPS M1640 || (2009.08) || ATI HD4670 Mobile works with {{Pkg|xf86-video-ati}} (see the forums for 3D support); Catalyst drivers untested || Works with Intel HD Audio and ALSA. || Yes || Works with iwlagn || Bluetooth works || Works but when using {{Pkg|xf86-video-ati}}, there is video corruption upon boot || N/A || Web cam works, media keys work with the {{ic|dell_laptop}} kernel module, IR works, card reader works || Everything basically worked out-of-the-box<br />
|}<br />
<br />
== Vostro ==<br />
<br />
{{Laptops table header}}<br />
| Vostro 1710 || {{-}} || {{-}} || {{-}} || Yes, RTL8111/8168B || Works (Broadcom BCM4328) || {{-}} || {{-}} ||{{-}} || {{-}} || AlpsPS/2 ALPS GlidePoint<br />
|-<br />
| Vostro 5481 || 2019.11.01 || Works out of the box, {{Pkg|xf86-video-intel}} recommended just in case. || Yes || Yes || Yes. {{Pkg|broadcom-wl}} may be needed. || Yes || Yes ||{{-}} || {{-}} || Disable secure boot, fast boot, and TPM in the BIOS. Also, enable AHCI SATA Operation in the BIOS instead of RAID or the disk may not be detected. Do note that you will get a BSOD on Windows after this, which can be fixed by following this [https://support.thinkcritical.com/kb/articles/switch-windows-10-from-raid-ide-to-ahci quick guide].<br />
|-<br />
| Vostro 3583 || {{-}} || No need to install {{Pkg|xf86-video-intel}} and {{Pkg|xf86-video-amdgpu}} as modesetting drivers works perfectly. || Yes || Yes || Works || Yes || Yes ||{{-}} || Webcame works out of box || after resuming from sleep, wifi stops working for some unknown cause. work around is to reload kernel module ath10k_pci. AMD 520 Radeon performs less than Intel UHD 620 with both amdgpu and radeon module. same results under Windows <br />
|-<br />
| Vostro 3560 || 2020.02.01 || Works, use Radeon, installed {{Pkg|mesa}} and {{Pkg|mesa-vdpau}} for hardware acceleration. || Works || Works || Works (Atheros AR9485 - ath9k) || Works || Works || {{-}} || Fingerprint reader works. || Everything works.<br />
|-<br />
| Vostro 5590 || {{-}} || Works out of the box. Followed [[Bumblebee#Installation]]. || Works with {{Pkg|sof-firmware}}. || Yes || Yes || Yes || {{-}} || {{-}} || {{ - }} || <br />
<ul><br />
<li>Installing the package {{Pkg|sof-firmware}} solves all the audio problems.<li><br />
<li>Install package aur/pulseaudio-modules-bt, if device bluetooth-sound not working</li><br />
<li> execute: pactl load-module module-bluetooth-discover</li><br />
</ul><br />
|-<br />
| Vostro 7500 || 2020.10.16 || Works out of box using nouveau || Works with {{Pkg|sof-firmware}} || N/A || Works || {{-}} || {{-}} || {{-}} || Finger print scanner not yet supported. Webcam works out of box. || <br />
<ul><br />
<li>No audio out of box, but {{Pkg|sof-firmware}} fixes this issue. </li><br />
<li>SSD was initially in RAID configuration in the Bios + not detected by the installer. Fixed by changing to AHCI. </li><br />
<li>Dell UEFI implementation does not pass kernel parameters on boot, so EFIStub does not work. Side-stepped the issue by installing Grub.</li><br />
</ul><br />
|}<br />
<br />
== XPS ==<br />
<br />
{{Laptops table header}}<br />
| XPS L322 || 2013_03 || Intel HD 4000, with {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || No Ethernet port || Yes || Untested || Yes || No modem || No SD card slot || ALPS Touchpad recognized only as PS/2 mouse, two-finger scroll, finger tap-to-click, etc... does not work. Some new mouse drivers suggest a fix but have not worked.<br />
|-<br />
| [[Dell XPS M1330|XPS M1330]] || 2021-01) || works with Nouveau or mode-setting || Works with Intel HD Audio and ALSA or Pulseaudio, but need to configure microphone || Yes || Works with iwl4965, b43 driver || Works with bluez || (''acpi_cpufreq'' problem: [https://bbs.archlinux.org/viewtopic.php?id=44500 see forums]) || No modem || 2.0 MP web cam works with ''uvcvideo'', IR remote works, SD card works || Everything basically worked out-of-the-box except the microphone.<br />
|-<br />
| [[Dell XPS 13 (9333)|XPS 13 (9333)]] || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}}<br />
|-<br />
| [[Dell XPS 13 (9310)|XPS 13 (9310)]] || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}}<br />
|-<br />
| [[Dell XPS 13 (9343)|XPS 13 (9343)]] || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}} || {{-}}<br />
|-<br />
| [[Dell XPS 13 (9350)|XPS 13 (9350)]] || {{-}} || Yes || Yes || Yes || Yes, after firmware update || Yes (Suspend and Hibernate) || {{-}} || {{-}} || All Dock Ports function (WD15 tested working, except Ethernet Realtek 8152/8153 not resuming from USB supend mode. Install WD15 firmware 1.0.4 to fix.) || Everything basically works out-of-the-box with a reasonably up-to-date kernel.<br />
|-<br />
| [[Dell XPS 13 (9360)|XPS 13 (9360)]] || {{-}} || Yes || Yes || Yes || Yes, after firmware update || Yes (Suspend and Hibernate) || {{-}} || {{-}} || {{-}} || Everything basically works out-of-the-box with a reasonably up-to-date kernel.<br />
|-<br />
| [[Dell XPS 13 (9370)|XPS 13 (9370)]] || {{-}} || Yes || Yes || Yes || Yes || Yes || {{-}} || {{-}} || {{-}} || {{-}}<br />
|-<br />
| [[Dell XPS 13 (9380)|XPS 13 (9380)]] || 2019 || Yes || Yes || Yes || Yes || Yes || {{-}} || {{-}} || {{-}} || Everything basically works out-of-the-box with a reasonably up-to-date kernel. <br />
|-<br />
| [[Dell XPS 13 2-in-1 (9365)|XPS 13 2-in-1 (9365)]] || {{-}} || Yes || Yes || No Ethernet Port || Yes || Yes (Suspend and Hibernate) || {{-}} || {{-}} || {{-}} || Everything basically works out-of-the-box with a reasonably up-to-date kernel.<br />
|-<br />
| [[Dell XPS 13 (7390)|XPS 13 (7390)]] || {{-}} || Yes || Yes || No Ethernet Port || Yes || Yes || {{-}} || {{-}} || Fingerprint not tested as the developer version does not have one. || This is the regular XPS 13, not the 2-in-1. Only tested with Wayland (Sway WM) ecosystem.<br />
|-<br />
| [[Dell XPS 13 2-in-1 (7390)|XPS 13 2-in-1 (7390)]] || 2019.09.01 || Yes || Yes || No Ethernet Port || Yes || Yes (Requires Drivers) || {{-}} || No Modem || Camera, Fingerprint Sensor not working || System freezes on boot. See device page for fix.<br />
|-<br />
| [[Dell XPS 15]] || {{-}} || Intel HD 530 works with {{Pkg|xf86-video-intel}} i915 and GTX 960M works with {{Pkg|nvidia}} || Yes || No Ethernet Port || Yes || Yes || Yes || No Modem || {{-}} || Everything basically works out-of-the-box with a reasonably up-to-date kernel.<br />
|-<br />
| [[Dell XPS 17 (9700)]] || {{-}} || Intel UHD (CML GT2) works with {{Pkg|mesa}} or {{Pkg|xf86-video-intel}} and GTX 1650 Ti/RTX 2060 Max-Q works with {{Pkg|nvidia}} || Yes || No Ethernet Port || Yes || Yes || Yes || No Modem || Camera working, Fingerprint sensor workable. || Builtin audio can work, but is currently difficult to get working.<br />
|}<br />
<br />
== G3 ==<br />
<br />
{{Laptops table header}}<br />
| G3 15 3590 || 2020.19.10 || Intel UHD 630 and NVIDIA GTX 1050/1660 Mobile {{Pkg|nvidia}} and {{Pkg|nvidia-prime}} using [[PRIME#PRIME render offload|PRIME Render Offloading]]. Until now, [[GPGPU#CUDA|NVIDIA CUDA]] is not working with linux 5.9 || You must install {{Pkg|sof-firmware}} and any kernel after 5.6.3+ to get internal microphone/sound working. || Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller || Qualcomm Atheros QCA9377 802.11ac Wireless Network Adapter || Working || Working || {{-}} || {{-}} || Works well with {{AUR|optimus-manager-git}}, follow [https://github.com/Askannz/optimus-manager/wiki/A-guide--to-power-management-options#configuration-1--built-in-power-management-inside-the-nvidia-driver their page on power managment]<br />
|}<br />
<br />
== G5 ==<br />
<br />
{{Laptops table header}}<br />
| [[Dell G5 5590-9340|G5 5590-9340]] || 2020.08.20 || Yes (both integrated and dedicated) || Yes || Yes || Yes || Yes || Yes || {{-}} || Goodix fingerprint reader not working due to lack of drivers but probably can be extracted from Ubuntu image this laptop goes with. || Everything works OOB except FP.</div>Wooptoohttps://wiki.archlinux.org/index.php?title=LightDM&diff=684850LightDM2021-07-01T21:27:27Z<p>Wooptoo: Multiple-monitor setup</p>
<hr />
<div>[[Category:Display managers]]<br />
[[Category:Canonical]]<br />
[[de:Login-Manager#LightDM]]<br />
[[es:LightDM]]<br />
[[fr:LightDM]]<br />
[[ja:LightDM]]<br />
[[ru:LightDM]]<br />
[[zh-hans:LightDM]]<br />
{{Related articles start}}<br />
{{Related|Display manager}}<br />
{{Related|GDM}}<br />
{{Related|LXDM}}<br />
{{Related articles end}}<br />
<br />
[https://github.com/canonical/lightdm LightDM] is a cross-desktop [[display manager]]. Its key features are:<br />
<br />
* Cross-desktop - supports different desktop technologies.<br />
* Supports different display technologies (X, Mir, Wayland ...).<br />
* Lightweight - low memory usage and high performance.<br />
* Supports guest sessions.<br />
* Supports remote login (incoming - [[XDMCP]], [[VNC]], outgoing - XDMCP, [[pluggable]]).<br />
* Comprehensive test suite.<br />
* Low code complexity.<br />
<br />
More details about LightDM's design can be found [https://www.freedesktop.org/wiki/Software/LightDM/Design here].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|lightdm}} package.<br />
{{Tip|Stable releases are even-numbered (1.8, 1.10) while development releases are odd-numbered (1.9, 1.11). These development releases are available with {{AUR|lightdm-devel}}. Also available is {{AUR|lightdm-git}}.}}<br />
<br />
=== Greeter ===<br />
<br />
You will probably want to install a greeter. A greeter is a GUI that prompts the user for credentials, lets the user select a session, and so on. It is possible to use LightDM without a greeter, but only if an automatic login is configured; otherwise you will need to install {{pkg|xorg-server}} and one of the greeter packages below.<br />
<br />
The official repositories contain the following greeters:<br />
<br />
* {{Pkg|lightdm-gtk-greeter}}: this is the '''default''' greeter LightDM attempts to use when started unless configured to do otherwise.<br />
* lightdm-deepin-greeter ({{Pkg|deepin-session-shell}}): A greeter from the [[Deepin]] project.<br />
* {{Pkg|lightdm-pantheon-greeter}}: A greeter from the elementary OS project.<br />
* {{Pkg|lightdm-webkit2-greeter}}: A greeter that uses Webkit2 for theming. It supersedes {{AUR|lightdm-webkit-greeter}}.<br />
* {{Pkg|lightdm-webkit-theme-litarvan}}: A modern and full-featured Webkit2 LightDM theme.<br />
<br />
Other alternative greeters are available in the [[AUR]]:<br />
<br />
* {{AUR|lightdm-slick-greeter}}: A GTK based greeter focused more on appearance than {{Pkg|lightdm-gtk-greeter}}, forked from {{AUR|lightdm-unity-greeter}}, and default in Linux Mint.<br />
* {{AUR|lightdm-unity-greeter}}: The greeter used by Unity.<br />
* {{AUR|lightdm-mini-greeter}}: A minimal, configurable, single-user greeter.<br />
* {{AUR|lightdm-webkit-theme-aether}}: A sleek, straightforward Archlinux themed login screen written on lightdm and the lightdm-webkit2-greeter.<br />
* {{AUR|lightdm-elephant-greeter-git}}: A small and simple greeter that runs in the {{Pkg|cage}} Wayland compositor per default.<br />
<br />
You can set the default greeter by changing the {{ic|[Seat:*]}} section of the LightDM configuration file, like so:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
...<br />
greeter-session=lightdm-''yourgreeter''-greeter<br />
...<br />
}}<br />
<br />
One way to check which greeters are available is to list the files in the {{ic|/usr/share/xgreeters}} directory; each ''.desktop'' file represents an available greeter. In this example, the {{ic|lightdm-gtk-greeter}} and {{ic|lightdm-webkit2-greeter}} greeters are available:<br />
<br />
$ ls -1 /usr/share/xgreeters/<br />
lightdm-gtk-greeter.desktop<br />
lightdm-webkit2-greeter.desktop<br />
<br />
== Enabling LightDM ==<br />
<br />
Make sure to [[enable]] {{ic|lightdm.service}} so LightDM will be started at boot; see also [[Display manager#Loading the display manager]].<br />
<br />
# systemctl enable lightdm<br />
<br />
== Command line tool ==<br />
<br />
LightDM offers a command line tool, {{ic|dm-tool}}, which can be used to lock the current seat, switch sessions, etc, which is useful with 'minimalist' window managers and for testing. To see a list of available commands, execute:<br />
<br />
$ dm-tool --help<br />
<br />
=== User switching ===<br />
<br />
{{Accuracy|Is this warning inappropriate? {{ic|dm-tool lock}} and {{ic|dm-tool switch-to-greeter}} are NOT screen lockers. They only switch to the LightDM greeter and send a notification to lock the session (as {{ic|loginctl lock-session}}). This notification should be processed by a screen locker or redirected by ''xss-lock''. In the absence of a screen locker to listen, there is nothing {{ic|dm-tool ...}} can do - but that's not LightDM's fault. This issue is well known and touched upon [[List_of_applications#Screen_lockers|here]] and [[XScreenSaver#Lock_on_suspend|here]].}}<br />
<br />
{{Warning|1=The use of lightDM's built-in screen lockers like {{ic|dm-tool lock}} or {{ic|dm-tool switch-to-greeter}} are [https://bbs.archlinux.org/viewtopic.php?pid=1712213#p1712213 '''not''' recommended]. Use [[#Lock the screen using light-locker|light-locker]] or something from [[List of applications/Security#Screen lockers]].}}<br />
<br />
LightDM's ''dm-tool'' command can be used to allow multiple users to be logged in on separate ttys. The following will send a signal requesting that the current session be locked and then will initiate a switch to LightDM's greeter, allowing a new user to log in to the system.<br />
<br />
$ dm-tool switch-to-greeter<br />
<br />
== Testing ==<br />
<br />
First, [[install]] {{Pkg|xorg-server-xephyr}} from the [[official repositories]].<br />
<br />
Then, run LightDM as an X application:<br />
<br />
$ lightdm --test-mode --debug<br />
<br />
== Optional configuration and tweaks ==<br />
<br />
LightDM can be configured by modifying its config file, {{ic|/etc/lightdm/lightdm.conf}}.<br />
<br />
Some greeters have their own configuration files. For example:<br />
<br />
{{Pkg|lightdm-gtk-greeter}}: {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} (or you can use the {{Pkg|lightdm-gtk-greeter-settings}} gui).<br />
<br />
{{Pkg|lightdm-webkit2-greeter}}: {{ic|/etc/lightdm/lightdm-webkit2-greeter.conf}}<br />
<br />
=== X session wrapper ===<br />
<br />
{{Merge|Xprofile|Duplicated information}}<br />
<br />
If you are migrating from [[xinit]], you will notice that the display is not launched by your shell. This is because, as opposed to your shell starting the display (and the display inheriting the environment of your shell), LightDM starts your display and does not source your shell. LightDM launches the display by running a wrapper script and that finally exec's your graphic environment. By default, {{ic|/etc/lightdm/Xsession}} is run.<br />
<br />
==== Environment variables ====<br />
<br />
The script checks and sources {{ic|/etc/profile}}, {{ic|~/.profile}}, {{ic|/etc/xprofile}} and {{ic|~/.xprofile}}, in that order. If you are using a shell that does not source any of these files, you can create an {{ic|~/.xprofile}} to do so. (In this example, the login shell is [[zsh]])<br />
<br />
{{hc|~/.xprofile|2=<br />
#!/bin/sh<br />
<nowiki>[[ -f ~/.config/zsh/.zshenv ]] && source ~/.config/zsh/.zshenv</nowiki><br />
}}<br />
<br />
If you have shell variables that are important for your display (such as Gtk or QT themes, GNUPG location, config overrides, etc.) this will let your graphic environment have access to your environment without having to be launched by your login shell.<br />
<br />
==== Keymap ====<br />
<br />
The script runs [[Xkbmap]] with arguments provided in files {{ic|/etc/X11/Xkbmap}}, {{ic|~/.Xkbmap}}. If those files are not found, it runs [[xmodmap]] with {{ic|/etc/X11/Xmodmap}}, {{ic|~/.Xmodmap}}. If using xkbmap, the files are parsed using cat. The following example works<br />
<br />
{{hc|~/.Xmodmap|2=<br />
-model pc105 -layout us,us,tr -variant ,dvorak,f -option grp:caps_toggle<br />
}}<br />
<br />
Otherwise, the session inherits the system default mapping of X11. This mapping can be defined in the xorg configuration files, either manually or with {{ic|localectl set-x11-keymap}}. See [[Xorg/Keyboard configuration#Setting keyboard layout]].<br />
<br />
==== Multiple keyboard layouts in lightdm-gtk-greeter ====<br />
<br />
To enable users switch between pre-defined keyboard layouts on the log-in screen enable the drop-down menu and configure the layouts. Either use the {{Pkg|lightdm-gtk-greeter-settings}} gui or edit the configuration file directly:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
indicators = ~hosts;~spacer;~clock;~spacer;~layout;~language;~session;~ally;~power<br />
}}<br />
<br />
Use [[Xorg/Keyboard_configuration#Using_localectl|localectl]] to set multiple layouts, e.g. de and its “variant” neo with the latter as primary:<br />
<br />
# localectl --no-convert set-x11-keymap de,de pc105 neo,<br />
<br />
Note the trailing comma which implies a blank variant for the second de.<br />
<br />
=== Changing background images/colors ===<br />
<br />
You can set the background to a hex color or an image. Some greeters offer more robust background options like background selection from the login screen, random backgrounds, etc.<br />
<br />
==== GTK greeter ====<br />
<br />
You can use the {{Pkg|lightdm-gtk-greeter-settings}} gui.<br />
<br />
Users wishing to customize the wallpaper on the greeter screen need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and define the {{ic|background}} variable under the {{ic|[greeter]}} section. For example:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
background=/usr/share/pixmaps/black_and_white_photography-wallpaper-1920x1080.jpg<br />
}}<br />
<br />
{{Note|It is recommended to place the PNG or JPG file in {{ic|/usr/share/pixmaps}} since the LightDM user needs read access to the wallpaper file.}}<br />
<br />
===== GTK3 Theme =====<br />
<br />
GTK3 themes can be specified with the {{ic|theme-name}} variable in the {{ic|[greeter]}} section of {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} For example, {{ic|1=theme-name=Adwaita-dark}}.<br />
<br />
==== Webkit2 greeter ====<br />
<br />
The {{Pkg|lightdm-webkit2-greeter}} allows you to choose a background image directly on the login screen. It also offers an option to display a random image each time it starts if you use the [https://github.com/artur9010/lightdm-webkit-material Material theme]. By default, images are sourced from {{ic|/usr/share/backgrounds}}. You can change the background images directory by editing {{ic|lightdm-webkit2-greeter.conf}}. For example:<br />
{{hc|/etc/lightdm/lightdm-webkit2-greeter.conf|2=<br />
[branding]<br />
background_images = /usr/share/backgrounds<br />
}}<br />
<br />
{{Note|The background images directory must be accessible to the LightDM user so it should not be located anywhere under {{ic|/home}}. }}<br />
<br />
==== Unity greeter ====<br />
<br />
Users using the {{AUR|lightdm-unity-greeter}} must edit the {{ic|/usr/share/glib-2.0/schemas/com.canonical.unity-greeter.gschema.xml}} file and then execute:<br />
<br />
# glib-compile-schemas /usr/share/glib-2.0/schemas/<br />
<br />
According to [https://bbs.archlinux.org/viewtopic.php?id=149945 this] page.<br />
<br />
==== Slick Greeter ====<br />
<br />
Use the {{AUR|lightdm-settings}} GUI<br />
<br />
=== Changing your avatar ===<br />
<br />
First, make sure the {{Pkg|accountsservice}} package from the [[official repositories]] is installed, then set it up as follows, replacing {{ic|''username''}} with the desired user's login name.<br />
<br />
* Create the file {{ic|/var/lib/AccountsService/icons/''username''.png}} using a 96x96 PNG image file. Different image file formats are possible too, e.g., JPEG.<br />
* Alternatively, create the image file as {{ic|/home/''username''/.face}} and skip the next step if the defaults already point to the user home directory path<br />
* Edit or create the account settings file {{ic|/var/lib/AccountsService/users/''username''}}, and add the lines<br />
<br />
[User]<br />
Icon=/var/lib/AccountsService/icons/''username''.png<br />
<br />
The filename here should point to the icon created in the first step, so adjust the filename extension if necessary.<br />
<br />
{{Note|Make sure that both created files have 644 permissions, use [[chmod]] to correct them.}}<br />
<br />
=== Sources of Arch-centric 64x64 icons ===<br />
<br />
The {{AUR|archlinux-artwork}} package contains some nice examples that install to {{ic|/usr/share/archlinux/icons}} and that can be copied to {{ic|/usr/share/icons/hicolor/64x64/devices}} as follows:<br />
<br />
# find /usr/share/archlinux/icons -name "*64*" -exec cp {} /usr/share/icons/hicolor/64x64/devices \;<br />
<br />
After copying, the {{AUR|archlinux-artwork}} package can be removed.<br />
<br />
=== Enabling autologin ===<br />
<br />
Edit the LightDM configuration file and ensure these lines are uncommented and correctly configured:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
}}<br />
<br />
You must be part of the {{ic|autologin}} group to be able to login automatically without entering your password:<br />
<br />
# groupadd -r autologin<br />
# gpasswd -a ''username'' autologin<br />
<br />
LightDM logs in using the session specified in the {{ic|~/.dmrc}} of the user getting logged in automatically. To override this file, specify {{ic|autologin-session}} in {{ic|lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
autologin-session=''session''<br />
}}<br />
<br />
The list of valid session names can be found by listing {{ic|/usr/share/xsessions/*.desktop}} for X's sessions and {{ic|/usr/share/wayland-sessions/*.desktop}} for Wayland's.<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user will have to set up a blank password to their keyring for it to be unlocked automatically.}}<br />
<br />
=== Enabling interactive passwordless login ===<br />
<br />
LightDM goes through PAM so you must configure the lightdm configuration of PAM:<br />
<br />
{{hc|/etc/pam.d/lightdm|2=<br />
#%PAM-1.0<br />
'''auth sufficient pam_succeed_if.so user ingroup nopasswdlogin'''<br />
auth include system-login<br />
...<br />
}}<br />
<br />
You must then also be part of the {{ic|nopasswdlogin}} group to be able to login interactively without entering your password:<br />
<br />
# groupadd -r nopasswdlogin<br />
# gpasswd -a ''username'' nopasswdlogin<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user may have to follow the instructions at the end of the previous section on enabling autologin.}}<br />
<br />
To create a new user account that logs in automatically and additionally able to login again without a password the user can be created with supplementary membership of both groups, e.g.:<br />
<br />
# useradd -mG autologin,nopasswdlogin -s /bin/bash ''username''<br />
<br />
=== Enabling guest sessions ===<br />
<br />
{{Note|A guest user has passwordless access to your system after enabling this feature.}} <br />
<br />
To enable guest sessions in LightDM (without changing your system configuration) you need at least two things:<br />
<br />
# a '''guest-account-script''': defaults to {{ic|guest-account}} and accepts two commands:<br />
#* '''add''' (to create a temporary guest system account and returns the user name of the created account)<br />
#* '''remove''' ''account name''(to delete the corresponding account)<br />
# an [[#Enabling autologin|'''autologin''']] group to which the created guest account must be added (cf. {{ic|/etc/pam.d/lightdm-autologin}})<br />
<br />
There are two AUR packages that enable guest sessions in lightdm:<br />
<br />
* {{aur|lightdm-guest}} which provides the (largely unmodified) upstream guest-session script as well as {{pkg|lightdm}} itself.<br />
* {{aur|lightdm-guest-account}} which provides only a minimal version of the script.<br />
<br />
=== Hiding system and services users ===<br />
<br />
To prevent system users from showing-up in the login, install the optional dependency {{Pkg|accountsservice}}, or add the user names to {{ic|/etc/lightdm/users.conf}} under {{ic|hidden-users}}. The first option has the advantage of not needing to update the list when more users are added or removed.<br />
<br />
=== Migrating from SLiM ===<br />
<br />
{{Merge|Display Manager|Not LightDM specific (or even SLiM specific for that matter as [[XDM]] also uses [[xinitrc]]). Perhaps this merits a one-liner somewhere on the [[Display Manager]] page?}}<br />
<br />
Move the contents of [[xinitrc]] to [[xprofile]], removing the call to start the [[window manager]] or [[desktop environment]].<br />
<br />
=== Login using ~/.xinitrc ===<br />
<br />
See [[Display manager#Run ~/.xinitrc as a session]].<br />
<br />
=== NumLock on by default ===<br />
<br />
Install the {{Pkg|numlockx}} package and then edit {{ic|/etc/lightdm/lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
greeter-setup-script=/usr/bin/numlockx on<br />
}}<br />
<br />
=== Default session ===<br />
<br />
Lightdm, like other DMs, stores the last-selected xsession in {{ic|~/.dmrc}}. See [[Display manager#Session configuration]] for more info.<br />
<br />
=== Adjusting the login window's position ===<br />
<br />
==== GTK greeter ====<br />
<br />
Users need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and enter a value for the {{ic|position}} variable. It accepts {{ic|x}} and {{ic|y}} values, either absolute (in pixels) or relative (in percent). Each value can also have an additional anchor location for the window, {{ic|start}}, {{ic|center}} and {{ic|end}} separated from the value by a comma.<br />
<br />
Example:<br />
<br />
position=200,start 50%,center<br />
<br />
=== VNC Server ===<br />
<br />
Lightdm can also be used to connect to via VNC. Make sure to install {{pkg|tigervnc}} on the server side and optionally as your VNC client on the client PC.<br />
<br />
Setup an authentication password on the server as root:<br />
<br />
# vncpasswd /etc/vncpasswd<br />
<br />
Edit the LightDM configuration file as shown below. Note that {{ic|listen-address}} configures the VNC to only listen to connections from localhost. This is used to only allow connections via [[TigerVNC#On_the_client|SSH and port forwarding]]. On the SSH client, make sure that you use {{ic|localhost:5900}} for the tunnel destination; using {{ic|127.0.0.1:5900}} or {{ic|::1:5900}} is not reliable on dual stack network connections. If you want to allow insecure connections you can disable this setting.<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[VNCServer]<br />
enabled=true<br />
command=Xvnc -rfbauth /etc/vncpasswd<br />
port=5900<br />
listen-address=localhost<br />
width=1024<br />
height=768<br />
depth=24<br />
}}<br />
<br />
Now open an SSH tunnel and connect to localhost as described in [[TigerVNC#On the client]].<br />
<br />
{{Note|If you get a blank screen upon opening the VNC connection, try a different LightDM greeter.}}<br />
<br />
=== Lock the screen using light-locker ===<br />
<br />
{{Pkg|light-locker}} is a simple screen locker using LightDM to authenticate the user. Once installed and running, you can lock your session via:<br />
<br />
$ light-locker-command -l<br />
<br />
This requires {{ic|light-locker}} to be started at the beginning of your session - see [[Autostarting]].<br />
<br />
<br />
=== Multiple-monitor setup ===<br />
<br />
Sometimes LightDM does not set the monitor resolution correctly on a multiple-monitor setup.<br />
The following Xorg configuration works with two monitors: a large primary screen on the left side,<br />
and a secondary smaller screen to its right.<br />
The order can be reversed and tweaked.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/52-resolution-fix.conf|2=<br />
Section "Monitor"<br />
Identifier "DP1"<br />
Option "PreferredMode" "3840x2160"<br />
Option "Primary" "1"<br />
EndSection<br />
Section "Monitor"<br />
Identifier "eDP1"<br />
Option "PreferredMode" "1920x1080"<br />
Option "RightOf" "DP1"<br />
EndSection<br />
}}<br />
<br />
This makes the {{ic|display-setup-script}} tweaks from {{ic|/etc/lightdm/lightdm.conf}} redundant.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Autologin does not work ===<br />
<br />
Ensure {{ic|1=autologin-user=}} in {{ic|/etc/lightdm/lightdm.conf}} contain the correct values. Trailing whitespace will cause errors.<br />
<br />
If autologin fails with a blank screen or if the login screen immediately returns, you may need to set {{ic|1=logind-check-graphical=true}}.<br />
<br />
You can also install {{AUR|lightdm-autologin-greeter-git}} for this special purpose.<br />
<br />
=== Viewing current configuration ===<br />
<br />
To view effective configuration, run:<br />
<br />
$ lightdm --show-config<br />
<br />
This will show current settings, with the configuration files these settings were read from.<br />
<br />
=== LightDM not starting and screen flashing ===<br />
<br />
If you encounter consistent screen flashing and ultimately no LightDM on boot, ensure that you have defined the greeter correctly in LightDM's config file. And if you have correctly defined the GTK greeter, make sure the {{ic|xsessions-directory}} (default: {{ic|/usr/share/xsessions}}) exists and contains at least one .desktop file.<br />
<br />
The same error can happen on lightdm startup if the last used session is not available anymore (eg. you last used gnome and then removed the gnome-session package): the easiest workaround is to temporarily restore the removed package. Another solution might be:<br />
<br />
# dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User.SetXSession string:xfce<br />
<br />
This example sets the session "xfce" as default for the user 1000.<br />
<br />
=== Wrong locale displayed ===<br />
<br />
In case of your locale not being displayed correctly in Lightdm add your locale to {{ic|/etc/environment}}:<br />
<br />
LANG=pt_PT.utf8<br />
<br />
Alternatively if you want LightDM and its greeters to be in a language other than your set system locale, you can use the {{ic|1=Environment=}} option in [[Systemd#Drop-in files]].<br />
<br />
=== Unresponsive for a few minutes after startup ===<br />
<br />
You may have to download more entropy. Install and enable haveged, c.f. https://github.com/canonical/lightdm/issues/17<br />
<br />
=== Missing icons with GTK greeter ===<br />
<br />
If you are using {{Pkg|lightdm-gtk-greeter}} as a greeter and it shows placeholder images as icons, make sure valid icon themes and themes are installed and configured. Check the following file:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
theme-name=mate # this should be the name of a directory under /usr/share/themes/<br />
icon-theme-name=mate # this should be the name of a fully featured icons set directory under /usr/share/icons/<br />
}}<br />
<br />
=== LightDM freezes on login attempt ===<br />
<br />
You may find that after entering the correct username and password and attempting to log in, LightDM freezes and you are unable to continue to the desktop. To fix the issue, reinstall the {{Pkg|gdk-pixbuf2}} package. See [https://bbs.archlinux.org/viewtopic.php?id=179031 this forum thread].<br />
<br />
=== LightDM displaying in wrong monitor ===<br />
<br />
If you are using multiple monitors, LightDM may display in the wrong one (e.g. if your primary monitor is on the right). To force the LightDM login screen to display on a specific monitor, edit {{ic|/etc/lightdm/lightdm.conf}} and change the ''display-setup-script'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
display-setup-script=xrandr --output ''HDMI1'' --primary<br />
}}<br />
<br />
Replace ''HDMI1'' with your real monitor ID, which you can find from '''xrandr''' command output.<br />
<br />
Alternatively, if you are using the GTK greeter, you can edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and add the ''active-monitor'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
active-monitor=0<br />
}}<br />
<br />
Replace 0 with the desired display number.<br />
<br />
=== LightDM does not appear or monitor only displays TTY output ===<br />
<br />
It may happen that your system boots so fast that LightDM service is started before your graphics drivers are properly loaded. If this is your case, you will want to add the following config to your lightdm.conf file:<br />
<br />
[LightDM]<br />
logind-check-graphical=true<br />
<br />
This setting will tell LightDM to wait until graphics devices are ready before spawning greeters/autostarting sessions on them.<br />
<br />
=== LightDM is running with low FPS on Intel Graphics ===<br />
<br />
See [[Intel graphics#AccelMethod]].<br />
<br />
=== Pulseaudio not starting automatically ===<br />
<br />
See [[PulseAudio#Running]].<br />
<br />
=== Long pause before LightDM shows up when home is encrypted ===<br />
<br />
Some LightDM themes try to access the user avatar located in HOME. If your HOME is encrypted, LightDM cannot access it and hangs. To prevent this from happening, you can either:<br />
<br />
* Set your avatar as explained in [[#Changing your avatar]]<br />
* for {{Pkg|lightdm-gtk-greeter}} only: {{Ic|<nowiki>hide-user-image = true</nowiki>}} in {{Ic|/etc/lightdm/lightdm-gtk-greeter.conf}}<br />
<br />
=== Boot hangs on "[ OK ] Reached target Graphical Interface." ===<br />
<br />
There is a possibility that user and group lookups fail if you modified /etc/nsswitch.conf. That happens when:<br />
<br />
* nsswitch.conf group: includes {{Ic|<nowiki>ldap</nowiki>}} without setting {{Ic|<nowiki>nss_initgroups_ignoreusers ALLLOCAL</nowiki>}} in {{Ic|<nowiki>/etc/nslcd.conf</nowiki>}}<br />
<br />
=== Wayland session not working with duplicate GNOME entries in greeter ===<br />
<br />
* Some greeters ({{Pkg|lightdm-webkit2-greeter}} for example) do not support two sessions with the same name [https://github.com/CanonicalLtd/lightdm/issues/16]. To check for duplicate entries:<br />
<br />
$ ls -1 /usr/share/wayland-sessions /usr/share/xsessions<br />
<br />
* Rename the duplicate entry in /usr/share/xsessions. For example:<br />
<br />
# mv /usr/share/xsessions/gnome.desktop /usr/share/xsessions/gnome.desktop.disabled<br />
<br />
=== Login always segfaults on first attempt ===<br />
<br />
Set a hostname as described in [[Network_configuration#Set_the_hostname|Network Page]]. See also {{Bug|47694}}.<br />
<br />
=== Infinite login loop ===<br />
<br />
If you get stuck in loop in which you type your correct user and password but the screen goes black and the you are back in the login after every attempt, running {{ic|rm ~/.Xauthority}} (or the stuck user's problematic {{ic|.Xauthority}}) may fix the issue.<br />
<br />
Another reason for this may be that you tried to recreate your "lightdm.conf" from scratch and your version is missing this line:<br />
<br />
session-wrapper=/etc/lightdm/Xsession<br />
<br />
In that case, lightdm tries to use "lightdm-session" as the session-wrapper which does not exist on Arch Linux.<br />
<br />
== See also ==<br />
<br />
* [https://wiki.ubuntu.com/LightDM Ubuntu Wiki article]<br />
* [[Gentoo:LightDM]]<br />
* [https://launchpad.net/lightdm Launchpad Page] obsolete<br />
* [http://www.mattfischer.com/blog/?tag=lightdm LightDM blog]<br />
* [https://github.com/CanonicalLtd/lightdm LightDM on GitHub]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=LightDM&diff=684849LightDM2021-07-01T21:25:52Z<p>Wooptoo: Multiple-monitor setup</p>
<hr />
<div>[[Category:Display managers]]<br />
[[Category:Canonical]]<br />
[[de:Login-Manager#LightDM]]<br />
[[es:LightDM]]<br />
[[fr:LightDM]]<br />
[[ja:LightDM]]<br />
[[ru:LightDM]]<br />
[[zh-hans:LightDM]]<br />
{{Related articles start}}<br />
{{Related|Display manager}}<br />
{{Related|GDM}}<br />
{{Related|LXDM}}<br />
{{Related articles end}}<br />
<br />
[https://github.com/canonical/lightdm LightDM] is a cross-desktop [[display manager]]. Its key features are:<br />
<br />
* Cross-desktop - supports different desktop technologies.<br />
* Supports different display technologies (X, Mir, Wayland ...).<br />
* Lightweight - low memory usage and high performance.<br />
* Supports guest sessions.<br />
* Supports remote login (incoming - [[XDMCP]], [[VNC]], outgoing - XDMCP, [[pluggable]]).<br />
* Comprehensive test suite.<br />
* Low code complexity.<br />
<br />
More details about LightDM's design can be found [https://www.freedesktop.org/wiki/Software/LightDM/Design here].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|lightdm}} package.<br />
{{Tip|Stable releases are even-numbered (1.8, 1.10) while development releases are odd-numbered (1.9, 1.11). These development releases are available with {{AUR|lightdm-devel}}. Also available is {{AUR|lightdm-git}}.}}<br />
<br />
=== Greeter ===<br />
<br />
You will probably want to install a greeter. A greeter is a GUI that prompts the user for credentials, lets the user select a session, and so on. It is possible to use LightDM without a greeter, but only if an automatic login is configured; otherwise you will need to install {{pkg|xorg-server}} and one of the greeter packages below.<br />
<br />
The official repositories contain the following greeters:<br />
<br />
* {{Pkg|lightdm-gtk-greeter}}: this is the '''default''' greeter LightDM attempts to use when started unless configured to do otherwise.<br />
* lightdm-deepin-greeter ({{Pkg|deepin-session-shell}}): A greeter from the [[Deepin]] project.<br />
* {{Pkg|lightdm-pantheon-greeter}}: A greeter from the elementary OS project.<br />
* {{Pkg|lightdm-webkit2-greeter}}: A greeter that uses Webkit2 for theming. It supersedes {{AUR|lightdm-webkit-greeter}}.<br />
* {{Pkg|lightdm-webkit-theme-litarvan}}: A modern and full-featured Webkit2 LightDM theme.<br />
<br />
Other alternative greeters are available in the [[AUR]]:<br />
<br />
* {{AUR|lightdm-slick-greeter}}: A GTK based greeter focused more on appearance than {{Pkg|lightdm-gtk-greeter}}, forked from {{AUR|lightdm-unity-greeter}}, and default in Linux Mint.<br />
* {{AUR|lightdm-unity-greeter}}: The greeter used by Unity.<br />
* {{AUR|lightdm-mini-greeter}}: A minimal, configurable, single-user greeter.<br />
* {{AUR|lightdm-webkit-theme-aether}}: A sleek, straightforward Archlinux themed login screen written on lightdm and the lightdm-webkit2-greeter.<br />
* {{AUR|lightdm-elephant-greeter-git}}: A small and simple greeter that runs in the {{Pkg|cage}} Wayland compositor per default.<br />
<br />
You can set the default greeter by changing the {{ic|[Seat:*]}} section of the LightDM configuration file, like so:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
...<br />
greeter-session=lightdm-''yourgreeter''-greeter<br />
...<br />
}}<br />
<br />
One way to check which greeters are available is to list the files in the {{ic|/usr/share/xgreeters}} directory; each ''.desktop'' file represents an available greeter. In this example, the {{ic|lightdm-gtk-greeter}} and {{ic|lightdm-webkit2-greeter}} greeters are available:<br />
<br />
$ ls -1 /usr/share/xgreeters/<br />
lightdm-gtk-greeter.desktop<br />
lightdm-webkit2-greeter.desktop<br />
<br />
== Enabling LightDM ==<br />
<br />
Make sure to [[enable]] {{ic|lightdm.service}} so LightDM will be started at boot; see also [[Display manager#Loading the display manager]].<br />
<br />
# systemctl enable lightdm<br />
<br />
== Command line tool ==<br />
<br />
LightDM offers a command line tool, {{ic|dm-tool}}, which can be used to lock the current seat, switch sessions, etc, which is useful with 'minimalist' window managers and for testing. To see a list of available commands, execute:<br />
<br />
$ dm-tool --help<br />
<br />
=== User switching ===<br />
<br />
{{Accuracy|Is this warning inappropriate? {{ic|dm-tool lock}} and {{ic|dm-tool switch-to-greeter}} are NOT screen lockers. They only switch to the LightDM greeter and send a notification to lock the session (as {{ic|loginctl lock-session}}). This notification should be processed by a screen locker or redirected by ''xss-lock''. In the absence of a screen locker to listen, there is nothing {{ic|dm-tool ...}} can do - but that's not LightDM's fault. This issue is well known and touched upon [[List_of_applications#Screen_lockers|here]] and [[XScreenSaver#Lock_on_suspend|here]].}}<br />
<br />
{{Warning|1=The use of lightDM's built-in screen lockers like {{ic|dm-tool lock}} or {{ic|dm-tool switch-to-greeter}} are [https://bbs.archlinux.org/viewtopic.php?pid=1712213#p1712213 '''not''' recommended]. Use [[#Lock the screen using light-locker|light-locker]] or something from [[List of applications/Security#Screen lockers]].}}<br />
<br />
LightDM's ''dm-tool'' command can be used to allow multiple users to be logged in on separate ttys. The following will send a signal requesting that the current session be locked and then will initiate a switch to LightDM's greeter, allowing a new user to log in to the system.<br />
<br />
$ dm-tool switch-to-greeter<br />
<br />
== Testing ==<br />
<br />
First, [[install]] {{Pkg|xorg-server-xephyr}} from the [[official repositories]].<br />
<br />
Then, run LightDM as an X application:<br />
<br />
$ lightdm --test-mode --debug<br />
<br />
== Optional configuration and tweaks ==<br />
<br />
LightDM can be configured by modifying its config file, {{ic|/etc/lightdm/lightdm.conf}}.<br />
<br />
Some greeters have their own configuration files. For example:<br />
<br />
{{Pkg|lightdm-gtk-greeter}}: {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} (or you can use the {{Pkg|lightdm-gtk-greeter-settings}} gui).<br />
<br />
{{Pkg|lightdm-webkit2-greeter}}: {{ic|/etc/lightdm/lightdm-webkit2-greeter.conf}}<br />
<br />
=== X session wrapper ===<br />
<br />
{{Merge|Xprofile|Duplicated information}}<br />
<br />
If you are migrating from [[xinit]], you will notice that the display is not launched by your shell. This is because, as opposed to your shell starting the display (and the display inheriting the environment of your shell), LightDM starts your display and does not source your shell. LightDM launches the display by running a wrapper script and that finally exec's your graphic environment. By default, {{ic|/etc/lightdm/Xsession}} is run.<br />
<br />
==== Environment variables ====<br />
<br />
The script checks and sources {{ic|/etc/profile}}, {{ic|~/.profile}}, {{ic|/etc/xprofile}} and {{ic|~/.xprofile}}, in that order. If you are using a shell that does not source any of these files, you can create an {{ic|~/.xprofile}} to do so. (In this example, the login shell is [[zsh]])<br />
<br />
{{hc|~/.xprofile|2=<br />
#!/bin/sh<br />
<nowiki>[[ -f ~/.config/zsh/.zshenv ]] && source ~/.config/zsh/.zshenv</nowiki><br />
}}<br />
<br />
If you have shell variables that are important for your display (such as Gtk or QT themes, GNUPG location, config overrides, etc.) this will let your graphic environment have access to your environment without having to be launched by your login shell.<br />
<br />
==== Keymap ====<br />
<br />
The script runs [[Xkbmap]] with arguments provided in files {{ic|/etc/X11/Xkbmap}}, {{ic|~/.Xkbmap}}. If those files are not found, it runs [[xmodmap]] with {{ic|/etc/X11/Xmodmap}}, {{ic|~/.Xmodmap}}. If using xkbmap, the files are parsed using cat. The following example works<br />
<br />
{{hc|~/.Xmodmap|2=<br />
-model pc105 -layout us,us,tr -variant ,dvorak,f -option grp:caps_toggle<br />
}}<br />
<br />
Otherwise, the session inherits the system default mapping of X11. This mapping can be defined in the xorg configuration files, either manually or with {{ic|localectl set-x11-keymap}}. See [[Xorg/Keyboard configuration#Setting keyboard layout]].<br />
<br />
==== Multiple keyboard layouts in lightdm-gtk-greeter ====<br />
<br />
To enable users switch between pre-defined keyboard layouts on the log-in screen enable the drop-down menu and configure the layouts. Either use the {{Pkg|lightdm-gtk-greeter-settings}} gui or edit the configuration file directly:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
indicators = ~hosts;~spacer;~clock;~spacer;~layout;~language;~session;~ally;~power<br />
}}<br />
<br />
Use [[Xorg/Keyboard_configuration#Using_localectl|localectl]] to set multiple layouts, e.g. de and its “variant” neo with the latter as primary:<br />
<br />
# localectl --no-convert set-x11-keymap de,de pc105 neo,<br />
<br />
Note the trailing comma which implies a blank variant for the second de.<br />
<br />
=== Changing background images/colors ===<br />
<br />
You can set the background to a hex color or an image. Some greeters offer more robust background options like background selection from the login screen, random backgrounds, etc.<br />
<br />
==== GTK greeter ====<br />
<br />
You can use the {{Pkg|lightdm-gtk-greeter-settings}} gui.<br />
<br />
Users wishing to customize the wallpaper on the greeter screen need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and define the {{ic|background}} variable under the {{ic|[greeter]}} section. For example:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
background=/usr/share/pixmaps/black_and_white_photography-wallpaper-1920x1080.jpg<br />
}}<br />
<br />
{{Note|It is recommended to place the PNG or JPG file in {{ic|/usr/share/pixmaps}} since the LightDM user needs read access to the wallpaper file.}}<br />
<br />
===== GTK3 Theme =====<br />
<br />
GTK3 themes can be specified with the {{ic|theme-name}} variable in the {{ic|[greeter]}} section of {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} For example, {{ic|1=theme-name=Adwaita-dark}}.<br />
<br />
==== Webkit2 greeter ====<br />
<br />
The {{Pkg|lightdm-webkit2-greeter}} allows you to choose a background image directly on the login screen. It also offers an option to display a random image each time it starts if you use the [https://github.com/artur9010/lightdm-webkit-material Material theme]. By default, images are sourced from {{ic|/usr/share/backgrounds}}. You can change the background images directory by editing {{ic|lightdm-webkit2-greeter.conf}}. For example:<br />
{{hc|/etc/lightdm/lightdm-webkit2-greeter.conf|2=<br />
[branding]<br />
background_images = /usr/share/backgrounds<br />
}}<br />
<br />
{{Note|The background images directory must be accessible to the LightDM user so it should not be located anywhere under {{ic|/home}}. }}<br />
<br />
==== Unity greeter ====<br />
<br />
Users using the {{AUR|lightdm-unity-greeter}} must edit the {{ic|/usr/share/glib-2.0/schemas/com.canonical.unity-greeter.gschema.xml}} file and then execute:<br />
<br />
# glib-compile-schemas /usr/share/glib-2.0/schemas/<br />
<br />
According to [https://bbs.archlinux.org/viewtopic.php?id=149945 this] page.<br />
<br />
==== Slick Greeter ====<br />
<br />
Use the {{AUR|lightdm-settings}} GUI<br />
<br />
=== Changing your avatar ===<br />
<br />
First, make sure the {{Pkg|accountsservice}} package from the [[official repositories]] is installed, then set it up as follows, replacing {{ic|''username''}} with the desired user's login name.<br />
<br />
* Create the file {{ic|/var/lib/AccountsService/icons/''username''.png}} using a 96x96 PNG image file. Different image file formats are possible too, e.g., JPEG.<br />
* Alternatively, create the image file as {{ic|/home/''username''/.face}} and skip the next step if the defaults already point to the user home directory path<br />
* Edit or create the account settings file {{ic|/var/lib/AccountsService/users/''username''}}, and add the lines<br />
<br />
[User]<br />
Icon=/var/lib/AccountsService/icons/''username''.png<br />
<br />
The filename here should point to the icon created in the first step, so adjust the filename extension if necessary.<br />
<br />
{{Note|Make sure that both created files have 644 permissions, use [[chmod]] to correct them.}}<br />
<br />
=== Sources of Arch-centric 64x64 icons ===<br />
<br />
The {{AUR|archlinux-artwork}} package contains some nice examples that install to {{ic|/usr/share/archlinux/icons}} and that can be copied to {{ic|/usr/share/icons/hicolor/64x64/devices}} as follows:<br />
<br />
# find /usr/share/archlinux/icons -name "*64*" -exec cp {} /usr/share/icons/hicolor/64x64/devices \;<br />
<br />
After copying, the {{AUR|archlinux-artwork}} package can be removed.<br />
<br />
=== Enabling autologin ===<br />
<br />
Edit the LightDM configuration file and ensure these lines are uncommented and correctly configured:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
}}<br />
<br />
You must be part of the {{ic|autologin}} group to be able to login automatically without entering your password:<br />
<br />
# groupadd -r autologin<br />
# gpasswd -a ''username'' autologin<br />
<br />
LightDM logs in using the session specified in the {{ic|~/.dmrc}} of the user getting logged in automatically. To override this file, specify {{ic|autologin-session}} in {{ic|lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
autologin-session=''session''<br />
}}<br />
<br />
The list of valid session names can be found by listing {{ic|/usr/share/xsessions/*.desktop}} for X's sessions and {{ic|/usr/share/wayland-sessions/*.desktop}} for Wayland's.<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user will have to set up a blank password to their keyring for it to be unlocked automatically.}}<br />
<br />
=== Enabling interactive passwordless login ===<br />
<br />
LightDM goes through PAM so you must configure the lightdm configuration of PAM:<br />
<br />
{{hc|/etc/pam.d/lightdm|2=<br />
#%PAM-1.0<br />
'''auth sufficient pam_succeed_if.so user ingroup nopasswdlogin'''<br />
auth include system-login<br />
...<br />
}}<br />
<br />
You must then also be part of the {{ic|nopasswdlogin}} group to be able to login interactively without entering your password:<br />
<br />
# groupadd -r nopasswdlogin<br />
# gpasswd -a ''username'' nopasswdlogin<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user may have to follow the instructions at the end of the previous section on enabling autologin.}}<br />
<br />
To create a new user account that logs in automatically and additionally able to login again without a password the user can be created with supplementary membership of both groups, e.g.:<br />
<br />
# useradd -mG autologin,nopasswdlogin -s /bin/bash ''username''<br />
<br />
=== Enabling guest sessions ===<br />
<br />
{{Note|A guest user has passwordless access to your system after enabling this feature.}} <br />
<br />
To enable guest sessions in LightDM (without changing your system configuration) you need at least two things:<br />
<br />
# a '''guest-account-script''': defaults to {{ic|guest-account}} and accepts two commands:<br />
#* '''add''' (to create a temporary guest system account and returns the user name of the created account)<br />
#* '''remove''' ''account name''(to delete the corresponding account)<br />
# an [[#Enabling autologin|'''autologin''']] group to which the created guest account must be added (cf. {{ic|/etc/pam.d/lightdm-autologin}})<br />
<br />
There are two AUR packages that enable guest sessions in lightdm:<br />
<br />
* {{aur|lightdm-guest}} which provides the (largely unmodified) upstream guest-session script as well as {{pkg|lightdm}} itself.<br />
* {{aur|lightdm-guest-account}} which provides only a minimal version of the script.<br />
<br />
=== Hiding system and services users ===<br />
<br />
To prevent system users from showing-up in the login, install the optional dependency {{Pkg|accountsservice}}, or add the user names to {{ic|/etc/lightdm/users.conf}} under {{ic|hidden-users}}. The first option has the advantage of not needing to update the list when more users are added or removed.<br />
<br />
=== Migrating from SLiM ===<br />
<br />
{{Merge|Display Manager|Not LightDM specific (or even SLiM specific for that matter as [[XDM]] also uses [[xinitrc]]). Perhaps this merits a one-liner somewhere on the [[Display Manager]] page?}}<br />
<br />
Move the contents of [[xinitrc]] to [[xprofile]], removing the call to start the [[window manager]] or [[desktop environment]].<br />
<br />
=== Login using ~/.xinitrc ===<br />
<br />
See [[Display manager#Run ~/.xinitrc as a session]].<br />
<br />
=== NumLock on by default ===<br />
<br />
Install the {{Pkg|numlockx}} package and then edit {{ic|/etc/lightdm/lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
greeter-setup-script=/usr/bin/numlockx on<br />
}}<br />
<br />
=== Default session ===<br />
<br />
Lightdm, like other DMs, stores the last-selected xsession in {{ic|~/.dmrc}}. See [[Display manager#Session configuration]] for more info.<br />
<br />
=== Adjusting the login window's position ===<br />
<br />
==== GTK greeter ====<br />
<br />
Users need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and enter a value for the {{ic|position}} variable. It accepts {{ic|x}} and {{ic|y}} values, either absolute (in pixels) or relative (in percent). Each value can also have an additional anchor location for the window, {{ic|start}}, {{ic|center}} and {{ic|end}} separated from the value by a comma.<br />
<br />
Example:<br />
<br />
position=200,start 50%,center<br />
<br />
=== VNC Server ===<br />
<br />
Lightdm can also be used to connect to via VNC. Make sure to install {{pkg|tigervnc}} on the server side and optionally as your VNC client on the client PC.<br />
<br />
Setup an authentication password on the server as root:<br />
<br />
# vncpasswd /etc/vncpasswd<br />
<br />
Edit the LightDM configuration file as shown below. Note that {{ic|listen-address}} configures the VNC to only listen to connections from localhost. This is used to only allow connections via [[TigerVNC#On_the_client|SSH and port forwarding]]. On the SSH client, make sure that you use {{ic|localhost:5900}} for the tunnel destination; using {{ic|127.0.0.1:5900}} or {{ic|::1:5900}} is not reliable on dual stack network connections. If you want to allow insecure connections you can disable this setting.<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[VNCServer]<br />
enabled=true<br />
command=Xvnc -rfbauth /etc/vncpasswd<br />
port=5900<br />
listen-address=localhost<br />
width=1024<br />
height=768<br />
depth=24<br />
}}<br />
<br />
Now open an SSH tunnel and connect to localhost as described in [[TigerVNC#On the client]].<br />
<br />
{{Note|If you get a blank screen upon opening the VNC connection, try a different LightDM greeter.}}<br />
<br />
=== Lock the screen using light-locker ===<br />
<br />
{{Pkg|light-locker}} is a simple screen locker using LightDM to authenticate the user. Once installed and running, you can lock your session via:<br />
<br />
$ light-locker-command -l<br />
<br />
This requires {{ic|light-locker}} to be started at the beginning of your session - see [[Autostarting]].<br />
<br />
<br />
=== Multiple-monitor setup ===<br />
<br />
Sometimes LightDM does not set the monitor resolution correctly on a multiple-monitor setup.<br />
The following Xorg configuration works with two monitors: a large primary screen on the left,<br />
and a secondary smaller screen to its right.<br />
The order can be reversed and tweaked.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/52-resolution-fix.conf|2=<br />
Section "Monitor"<br />
Identifier "DP1"<br />
Option "PreferredMode" "3840x2160"<br />
Option "Primary" "1"<br />
EndSection<br />
Section "Monitor"<br />
Identifier "eDP1"<br />
Option "PreferredMode" "1920x1080"<br />
Option "RightOf" "DP1"<br />
EndSection<br />
}}<br />
<br />
This makes the {{ic|display-setup-script}} tweaks from {{ic|/etc/lightdm/lightdm.conf}} redundant.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Autologin does not work ===<br />
<br />
Ensure {{ic|1=autologin-user=}} in {{ic|/etc/lightdm/lightdm.conf}} contain the correct values. Trailing whitespace will cause errors.<br />
<br />
If autologin fails with a blank screen or if the login screen immediately returns, you may need to set {{ic|1=logind-check-graphical=true}}.<br />
<br />
You can also install {{AUR|lightdm-autologin-greeter-git}} for this special purpose.<br />
<br />
=== Viewing current configuration ===<br />
<br />
To view effective configuration, run:<br />
<br />
$ lightdm --show-config<br />
<br />
This will show current settings, with the configuration files these settings were read from.<br />
<br />
=== LightDM not starting and screen flashing ===<br />
<br />
If you encounter consistent screen flashing and ultimately no LightDM on boot, ensure that you have defined the greeter correctly in LightDM's config file. And if you have correctly defined the GTK greeter, make sure the {{ic|xsessions-directory}} (default: {{ic|/usr/share/xsessions}}) exists and contains at least one .desktop file.<br />
<br />
The same error can happen on lightdm startup if the last used session is not available anymore (eg. you last used gnome and then removed the gnome-session package): the easiest workaround is to temporarily restore the removed package. Another solution might be:<br />
<br />
# dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User.SetXSession string:xfce<br />
<br />
This example sets the session "xfce" as default for the user 1000.<br />
<br />
=== Wrong locale displayed ===<br />
<br />
In case of your locale not being displayed correctly in Lightdm add your locale to {{ic|/etc/environment}}:<br />
<br />
LANG=pt_PT.utf8<br />
<br />
Alternatively if you want LightDM and its greeters to be in a language other than your set system locale, you can use the {{ic|1=Environment=}} option in [[Systemd#Drop-in files]].<br />
<br />
=== Unresponsive for a few minutes after startup ===<br />
<br />
You may have to download more entropy. Install and enable haveged, c.f. https://github.com/canonical/lightdm/issues/17<br />
<br />
=== Missing icons with GTK greeter ===<br />
<br />
If you are using {{Pkg|lightdm-gtk-greeter}} as a greeter and it shows placeholder images as icons, make sure valid icon themes and themes are installed and configured. Check the following file:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
theme-name=mate # this should be the name of a directory under /usr/share/themes/<br />
icon-theme-name=mate # this should be the name of a fully featured icons set directory under /usr/share/icons/<br />
}}<br />
<br />
=== LightDM freezes on login attempt ===<br />
<br />
You may find that after entering the correct username and password and attempting to log in, LightDM freezes and you are unable to continue to the desktop. To fix the issue, reinstall the {{Pkg|gdk-pixbuf2}} package. See [https://bbs.archlinux.org/viewtopic.php?id=179031 this forum thread].<br />
<br />
=== LightDM displaying in wrong monitor ===<br />
<br />
If you are using multiple monitors, LightDM may display in the wrong one (e.g. if your primary monitor is on the right). To force the LightDM login screen to display on a specific monitor, edit {{ic|/etc/lightdm/lightdm.conf}} and change the ''display-setup-script'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
display-setup-script=xrandr --output ''HDMI1'' --primary<br />
}}<br />
<br />
Replace ''HDMI1'' with your real monitor ID, which you can find from '''xrandr''' command output.<br />
<br />
Alternatively, if you are using the GTK greeter, you can edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and add the ''active-monitor'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
active-monitor=0<br />
}}<br />
<br />
Replace 0 with the desired display number.<br />
<br />
=== LightDM does not appear or monitor only displays TTY output ===<br />
<br />
It may happen that your system boots so fast that LightDM service is started before your graphics drivers are properly loaded. If this is your case, you will want to add the following config to your lightdm.conf file:<br />
<br />
[LightDM]<br />
logind-check-graphical=true<br />
<br />
This setting will tell LightDM to wait until graphics devices are ready before spawning greeters/autostarting sessions on them.<br />
<br />
=== LightDM is running with low FPS on Intel Graphics ===<br />
<br />
See [[Intel graphics#AccelMethod]].<br />
<br />
=== Pulseaudio not starting automatically ===<br />
<br />
See [[PulseAudio#Running]].<br />
<br />
=== Long pause before LightDM shows up when home is encrypted ===<br />
<br />
Some LightDM themes try to access the user avatar located in HOME. If your HOME is encrypted, LightDM cannot access it and hangs. To prevent this from happening, you can either:<br />
<br />
* Set your avatar as explained in [[#Changing your avatar]]<br />
* for {{Pkg|lightdm-gtk-greeter}} only: {{Ic|<nowiki>hide-user-image = true</nowiki>}} in {{Ic|/etc/lightdm/lightdm-gtk-greeter.conf}}<br />
<br />
=== Boot hangs on "[ OK ] Reached target Graphical Interface." ===<br />
<br />
There is a possibility that user and group lookups fail if you modified /etc/nsswitch.conf. That happens when:<br />
<br />
* nsswitch.conf group: includes {{Ic|<nowiki>ldap</nowiki>}} without setting {{Ic|<nowiki>nss_initgroups_ignoreusers ALLLOCAL</nowiki>}} in {{Ic|<nowiki>/etc/nslcd.conf</nowiki>}}<br />
<br />
=== Wayland session not working with duplicate GNOME entries in greeter ===<br />
<br />
* Some greeters ({{Pkg|lightdm-webkit2-greeter}} for example) do not support two sessions with the same name [https://github.com/CanonicalLtd/lightdm/issues/16]. To check for duplicate entries:<br />
<br />
$ ls -1 /usr/share/wayland-sessions /usr/share/xsessions<br />
<br />
* Rename the duplicate entry in /usr/share/xsessions. For example:<br />
<br />
# mv /usr/share/xsessions/gnome.desktop /usr/share/xsessions/gnome.desktop.disabled<br />
<br />
=== Login always segfaults on first attempt ===<br />
<br />
Set a hostname as described in [[Network_configuration#Set_the_hostname|Network Page]]. See also {{Bug|47694}}.<br />
<br />
=== Infinite login loop ===<br />
<br />
If you get stuck in loop in which you type your correct user and password but the screen goes black and the you are back in the login after every attempt, running {{ic|rm ~/.Xauthority}} (or the stuck user's problematic {{ic|.Xauthority}}) may fix the issue.<br />
<br />
Another reason for this may be that you tried to recreate your "lightdm.conf" from scratch and your version is missing this line:<br />
<br />
session-wrapper=/etc/lightdm/Xsession<br />
<br />
In that case, lightdm tries to use "lightdm-session" as the session-wrapper which does not exist on Arch Linux.<br />
<br />
== See also ==<br />
<br />
* [https://wiki.ubuntu.com/LightDM Ubuntu Wiki article]<br />
* [[Gentoo:LightDM]]<br />
* [https://launchpad.net/lightdm Launchpad Page] obsolete<br />
* [http://www.mattfischer.com/blog/?tag=lightdm LightDM blog]<br />
* [https://github.com/CanonicalLtd/lightdm LightDM on GitHub]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=LightDM&diff=684848LightDM2021-07-01T21:20:25Z<p>Wooptoo: Multiple-monitor setup</p>
<hr />
<div>[[Category:Display managers]]<br />
[[Category:Canonical]]<br />
[[de:Login-Manager#LightDM]]<br />
[[es:LightDM]]<br />
[[fr:LightDM]]<br />
[[ja:LightDM]]<br />
[[ru:LightDM]]<br />
[[zh-hans:LightDM]]<br />
{{Related articles start}}<br />
{{Related|Display manager}}<br />
{{Related|GDM}}<br />
{{Related|LXDM}}<br />
{{Related articles end}}<br />
<br />
[https://github.com/canonical/lightdm LightDM] is a cross-desktop [[display manager]]. Its key features are:<br />
<br />
* Cross-desktop - supports different desktop technologies.<br />
* Supports different display technologies (X, Mir, Wayland ...).<br />
* Lightweight - low memory usage and high performance.<br />
* Supports guest sessions.<br />
* Supports remote login (incoming - [[XDMCP]], [[VNC]], outgoing - XDMCP, [[pluggable]]).<br />
* Comprehensive test suite.<br />
* Low code complexity.<br />
<br />
More details about LightDM's design can be found [https://www.freedesktop.org/wiki/Software/LightDM/Design here].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|lightdm}} package.<br />
{{Tip|Stable releases are even-numbered (1.8, 1.10) while development releases are odd-numbered (1.9, 1.11). These development releases are available with {{AUR|lightdm-devel}}. Also available is {{AUR|lightdm-git}}.}}<br />
<br />
=== Greeter ===<br />
<br />
You will probably want to install a greeter. A greeter is a GUI that prompts the user for credentials, lets the user select a session, and so on. It is possible to use LightDM without a greeter, but only if an automatic login is configured; otherwise you will need to install {{pkg|xorg-server}} and one of the greeter packages below.<br />
<br />
The official repositories contain the following greeters:<br />
<br />
* {{Pkg|lightdm-gtk-greeter}}: this is the '''default''' greeter LightDM attempts to use when started unless configured to do otherwise.<br />
* lightdm-deepin-greeter ({{Pkg|deepin-session-shell}}): A greeter from the [[Deepin]] project.<br />
* {{Pkg|lightdm-pantheon-greeter}}: A greeter from the elementary OS project.<br />
* {{Pkg|lightdm-webkit2-greeter}}: A greeter that uses Webkit2 for theming. It supersedes {{AUR|lightdm-webkit-greeter}}.<br />
* {{Pkg|lightdm-webkit-theme-litarvan}}: A modern and full-featured Webkit2 LightDM theme.<br />
<br />
Other alternative greeters are available in the [[AUR]]:<br />
<br />
* {{AUR|lightdm-slick-greeter}}: A GTK based greeter focused more on appearance than {{Pkg|lightdm-gtk-greeter}}, forked from {{AUR|lightdm-unity-greeter}}, and default in Linux Mint.<br />
* {{AUR|lightdm-unity-greeter}}: The greeter used by Unity.<br />
* {{AUR|lightdm-mini-greeter}}: A minimal, configurable, single-user greeter.<br />
* {{AUR|lightdm-webkit-theme-aether}}: A sleek, straightforward Archlinux themed login screen written on lightdm and the lightdm-webkit2-greeter.<br />
* {{AUR|lightdm-elephant-greeter-git}}: A small and simple greeter that runs in the {{Pkg|cage}} Wayland compositor per default.<br />
<br />
You can set the default greeter by changing the {{ic|[Seat:*]}} section of the LightDM configuration file, like so:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
...<br />
greeter-session=lightdm-''yourgreeter''-greeter<br />
...<br />
}}<br />
<br />
One way to check which greeters are available is to list the files in the {{ic|/usr/share/xgreeters}} directory; each ''.desktop'' file represents an available greeter. In this example, the {{ic|lightdm-gtk-greeter}} and {{ic|lightdm-webkit2-greeter}} greeters are available:<br />
<br />
$ ls -1 /usr/share/xgreeters/<br />
lightdm-gtk-greeter.desktop<br />
lightdm-webkit2-greeter.desktop<br />
<br />
== Enabling LightDM ==<br />
<br />
Make sure to [[enable]] {{ic|lightdm.service}} so LightDM will be started at boot; see also [[Display manager#Loading the display manager]].<br />
<br />
# systemctl enable lightdm<br />
<br />
== Command line tool ==<br />
<br />
LightDM offers a command line tool, {{ic|dm-tool}}, which can be used to lock the current seat, switch sessions, etc, which is useful with 'minimalist' window managers and for testing. To see a list of available commands, execute:<br />
<br />
$ dm-tool --help<br />
<br />
=== User switching ===<br />
<br />
{{Accuracy|Is this warning inappropriate? {{ic|dm-tool lock}} and {{ic|dm-tool switch-to-greeter}} are NOT screen lockers. They only switch to the LightDM greeter and send a notification to lock the session (as {{ic|loginctl lock-session}}). This notification should be processed by a screen locker or redirected by ''xss-lock''. In the absence of a screen locker to listen, there is nothing {{ic|dm-tool ...}} can do - but that's not LightDM's fault. This issue is well known and touched upon [[List_of_applications#Screen_lockers|here]] and [[XScreenSaver#Lock_on_suspend|here]].}}<br />
<br />
{{Warning|1=The use of lightDM's built-in screen lockers like {{ic|dm-tool lock}} or {{ic|dm-tool switch-to-greeter}} are [https://bbs.archlinux.org/viewtopic.php?pid=1712213#p1712213 '''not''' recommended]. Use [[#Lock the screen using light-locker|light-locker]] or something from [[List of applications/Security#Screen lockers]].}}<br />
<br />
LightDM's ''dm-tool'' command can be used to allow multiple users to be logged in on separate ttys. The following will send a signal requesting that the current session be locked and then will initiate a switch to LightDM's greeter, allowing a new user to log in to the system.<br />
<br />
$ dm-tool switch-to-greeter<br />
<br />
== Testing ==<br />
<br />
First, [[install]] {{Pkg|xorg-server-xephyr}} from the [[official repositories]].<br />
<br />
Then, run LightDM as an X application:<br />
<br />
$ lightdm --test-mode --debug<br />
<br />
== Optional configuration and tweaks ==<br />
<br />
LightDM can be configured by modifying its config file, {{ic|/etc/lightdm/lightdm.conf}}.<br />
<br />
Some greeters have their own configuration files. For example:<br />
<br />
{{Pkg|lightdm-gtk-greeter}}: {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} (or you can use the {{Pkg|lightdm-gtk-greeter-settings}} gui).<br />
<br />
{{Pkg|lightdm-webkit2-greeter}}: {{ic|/etc/lightdm/lightdm-webkit2-greeter.conf}}<br />
<br />
=== X session wrapper ===<br />
<br />
{{Merge|Xprofile|Duplicated information}}<br />
<br />
If you are migrating from [[xinit]], you will notice that the display is not launched by your shell. This is because, as opposed to your shell starting the display (and the display inheriting the environment of your shell), LightDM starts your display and does not source your shell. LightDM launches the display by running a wrapper script and that finally exec's your graphic environment. By default, {{ic|/etc/lightdm/Xsession}} is run.<br />
<br />
==== Environment variables ====<br />
<br />
The script checks and sources {{ic|/etc/profile}}, {{ic|~/.profile}}, {{ic|/etc/xprofile}} and {{ic|~/.xprofile}}, in that order. If you are using a shell that does not source any of these files, you can create an {{ic|~/.xprofile}} to do so. (In this example, the login shell is [[zsh]])<br />
<br />
{{hc|~/.xprofile|2=<br />
#!/bin/sh<br />
<nowiki>[[ -f ~/.config/zsh/.zshenv ]] && source ~/.config/zsh/.zshenv</nowiki><br />
}}<br />
<br />
If you have shell variables that are important for your display (such as Gtk or QT themes, GNUPG location, config overrides, etc.) this will let your graphic environment have access to your environment without having to be launched by your login shell.<br />
<br />
==== Keymap ====<br />
<br />
The script runs [[Xkbmap]] with arguments provided in files {{ic|/etc/X11/Xkbmap}}, {{ic|~/.Xkbmap}}. If those files are not found, it runs [[xmodmap]] with {{ic|/etc/X11/Xmodmap}}, {{ic|~/.Xmodmap}}. If using xkbmap, the files are parsed using cat. The following example works<br />
<br />
{{hc|~/.Xmodmap|2=<br />
-model pc105 -layout us,us,tr -variant ,dvorak,f -option grp:caps_toggle<br />
}}<br />
<br />
Otherwise, the session inherits the system default mapping of X11. This mapping can be defined in the xorg configuration files, either manually or with {{ic|localectl set-x11-keymap}}. See [[Xorg/Keyboard configuration#Setting keyboard layout]].<br />
<br />
==== Multiple keyboard layouts in lightdm-gtk-greeter ====<br />
<br />
To enable users switch between pre-defined keyboard layouts on the log-in screen enable the drop-down menu and configure the layouts. Either use the {{Pkg|lightdm-gtk-greeter-settings}} gui or edit the configuration file directly:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
indicators = ~hosts;~spacer;~clock;~spacer;~layout;~language;~session;~ally;~power<br />
}}<br />
<br />
Use [[Xorg/Keyboard_configuration#Using_localectl|localectl]] to set multiple layouts, e.g. de and its “variant” neo with the latter as primary:<br />
<br />
# localectl --no-convert set-x11-keymap de,de pc105 neo,<br />
<br />
Note the trailing comma which implies a blank variant for the second de.<br />
<br />
=== Changing background images/colors ===<br />
<br />
You can set the background to a hex color or an image. Some greeters offer more robust background options like background selection from the login screen, random backgrounds, etc.<br />
<br />
==== GTK greeter ====<br />
<br />
You can use the {{Pkg|lightdm-gtk-greeter-settings}} gui.<br />
<br />
Users wishing to customize the wallpaper on the greeter screen need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and define the {{ic|background}} variable under the {{ic|[greeter]}} section. For example:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
background=/usr/share/pixmaps/black_and_white_photography-wallpaper-1920x1080.jpg<br />
}}<br />
<br />
{{Note|It is recommended to place the PNG or JPG file in {{ic|/usr/share/pixmaps}} since the LightDM user needs read access to the wallpaper file.}}<br />
<br />
===== GTK3 Theme =====<br />
<br />
GTK3 themes can be specified with the {{ic|theme-name}} variable in the {{ic|[greeter]}} section of {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} For example, {{ic|1=theme-name=Adwaita-dark}}.<br />
<br />
==== Webkit2 greeter ====<br />
<br />
The {{Pkg|lightdm-webkit2-greeter}} allows you to choose a background image directly on the login screen. It also offers an option to display a random image each time it starts if you use the [https://github.com/artur9010/lightdm-webkit-material Material theme]. By default, images are sourced from {{ic|/usr/share/backgrounds}}. You can change the background images directory by editing {{ic|lightdm-webkit2-greeter.conf}}. For example:<br />
{{hc|/etc/lightdm/lightdm-webkit2-greeter.conf|2=<br />
[branding]<br />
background_images = /usr/share/backgrounds<br />
}}<br />
<br />
{{Note|The background images directory must be accessible to the LightDM user so it should not be located anywhere under {{ic|/home}}. }}<br />
<br />
==== Unity greeter ====<br />
<br />
Users using the {{AUR|lightdm-unity-greeter}} must edit the {{ic|/usr/share/glib-2.0/schemas/com.canonical.unity-greeter.gschema.xml}} file and then execute:<br />
<br />
# glib-compile-schemas /usr/share/glib-2.0/schemas/<br />
<br />
According to [https://bbs.archlinux.org/viewtopic.php?id=149945 this] page.<br />
<br />
==== Slick Greeter ====<br />
<br />
Use the {{AUR|lightdm-settings}} GUI<br />
<br />
=== Changing your avatar ===<br />
<br />
First, make sure the {{Pkg|accountsservice}} package from the [[official repositories]] is installed, then set it up as follows, replacing {{ic|''username''}} with the desired user's login name.<br />
<br />
* Create the file {{ic|/var/lib/AccountsService/icons/''username''.png}} using a 96x96 PNG image file. Different image file formats are possible too, e.g., JPEG.<br />
* Alternatively, create the image file as {{ic|/home/''username''/.face}} and skip the next step if the defaults already point to the user home directory path<br />
* Edit or create the account settings file {{ic|/var/lib/AccountsService/users/''username''}}, and add the lines<br />
<br />
[User]<br />
Icon=/var/lib/AccountsService/icons/''username''.png<br />
<br />
The filename here should point to the icon created in the first step, so adjust the filename extension if necessary.<br />
<br />
{{Note|Make sure that both created files have 644 permissions, use [[chmod]] to correct them.}}<br />
<br />
=== Sources of Arch-centric 64x64 icons ===<br />
<br />
The {{AUR|archlinux-artwork}} package contains some nice examples that install to {{ic|/usr/share/archlinux/icons}} and that can be copied to {{ic|/usr/share/icons/hicolor/64x64/devices}} as follows:<br />
<br />
# find /usr/share/archlinux/icons -name "*64*" -exec cp {} /usr/share/icons/hicolor/64x64/devices \;<br />
<br />
After copying, the {{AUR|archlinux-artwork}} package can be removed.<br />
<br />
=== Enabling autologin ===<br />
<br />
Edit the LightDM configuration file and ensure these lines are uncommented and correctly configured:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
}}<br />
<br />
You must be part of the {{ic|autologin}} group to be able to login automatically without entering your password:<br />
<br />
# groupadd -r autologin<br />
# gpasswd -a ''username'' autologin<br />
<br />
LightDM logs in using the session specified in the {{ic|~/.dmrc}} of the user getting logged in automatically. To override this file, specify {{ic|autologin-session}} in {{ic|lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
autologin-user=''username''<br />
autologin-session=''session''<br />
}}<br />
<br />
The list of valid session names can be found by listing {{ic|/usr/share/xsessions/*.desktop}} for X's sessions and {{ic|/usr/share/wayland-sessions/*.desktop}} for Wayland's.<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user will have to set up a blank password to their keyring for it to be unlocked automatically.}}<br />
<br />
=== Enabling interactive passwordless login ===<br />
<br />
LightDM goes through PAM so you must configure the lightdm configuration of PAM:<br />
<br />
{{hc|/etc/pam.d/lightdm|2=<br />
#%PAM-1.0<br />
'''auth sufficient pam_succeed_if.so user ingroup nopasswdlogin'''<br />
auth include system-login<br />
...<br />
}}<br />
<br />
You must then also be part of the {{ic|nopasswdlogin}} group to be able to login interactively without entering your password:<br />
<br />
# groupadd -r nopasswdlogin<br />
# gpasswd -a ''username'' nopasswdlogin<br />
<br />
{{Note|GNOME users, and by extension any gnome-keyring user may have to follow the instructions at the end of the previous section on enabling autologin.}}<br />
<br />
To create a new user account that logs in automatically and additionally able to login again without a password the user can be created with supplementary membership of both groups, e.g.:<br />
<br />
# useradd -mG autologin,nopasswdlogin -s /bin/bash ''username''<br />
<br />
=== Enabling guest sessions ===<br />
<br />
{{Note|A guest user has passwordless access to your system after enabling this feature.}} <br />
<br />
To enable guest sessions in LightDM (without changing your system configuration) you need at least two things:<br />
<br />
# a '''guest-account-script''': defaults to {{ic|guest-account}} and accepts two commands:<br />
#* '''add''' (to create a temporary guest system account and returns the user name of the created account)<br />
#* '''remove''' ''account name''(to delete the corresponding account)<br />
# an [[#Enabling autologin|'''autologin''']] group to which the created guest account must be added (cf. {{ic|/etc/pam.d/lightdm-autologin}})<br />
<br />
There are two AUR packages that enable guest sessions in lightdm:<br />
<br />
* {{aur|lightdm-guest}} which provides the (largely unmodified) upstream guest-session script as well as {{pkg|lightdm}} itself.<br />
* {{aur|lightdm-guest-account}} which provides only a minimal version of the script.<br />
<br />
=== Hiding system and services users ===<br />
<br />
To prevent system users from showing-up in the login, install the optional dependency {{Pkg|accountsservice}}, or add the user names to {{ic|/etc/lightdm/users.conf}} under {{ic|hidden-users}}. The first option has the advantage of not needing to update the list when more users are added or removed.<br />
<br />
=== Migrating from SLiM ===<br />
<br />
{{Merge|Display Manager|Not LightDM specific (or even SLiM specific for that matter as [[XDM]] also uses [[xinitrc]]). Perhaps this merits a one-liner somewhere on the [[Display Manager]] page?}}<br />
<br />
Move the contents of [[xinitrc]] to [[xprofile]], removing the call to start the [[window manager]] or [[desktop environment]].<br />
<br />
=== Login using ~/.xinitrc ===<br />
<br />
See [[Display manager#Run ~/.xinitrc as a session]].<br />
<br />
=== NumLock on by default ===<br />
<br />
Install the {{Pkg|numlockx}} package and then edit {{ic|/etc/lightdm/lightdm.conf}}:<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[Seat:*]<br />
greeter-setup-script=/usr/bin/numlockx on<br />
}}<br />
<br />
=== Default session ===<br />
<br />
Lightdm, like other DMs, stores the last-selected xsession in {{ic|~/.dmrc}}. See [[Display manager#Session configuration]] for more info.<br />
<br />
=== Adjusting the login window's position ===<br />
<br />
==== GTK greeter ====<br />
<br />
Users need to edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and enter a value for the {{ic|position}} variable. It accepts {{ic|x}} and {{ic|y}} values, either absolute (in pixels) or relative (in percent). Each value can also have an additional anchor location for the window, {{ic|start}}, {{ic|center}} and {{ic|end}} separated from the value by a comma.<br />
<br />
Example:<br />
<br />
position=200,start 50%,center<br />
<br />
=== VNC Server ===<br />
<br />
Lightdm can also be used to connect to via VNC. Make sure to install {{pkg|tigervnc}} on the server side and optionally as your VNC client on the client PC.<br />
<br />
Setup an authentication password on the server as root:<br />
<br />
# vncpasswd /etc/vncpasswd<br />
<br />
Edit the LightDM configuration file as shown below. Note that {{ic|listen-address}} configures the VNC to only listen to connections from localhost. This is used to only allow connections via [[TigerVNC#On_the_client|SSH and port forwarding]]. On the SSH client, make sure that you use {{ic|localhost:5900}} for the tunnel destination; using {{ic|127.0.0.1:5900}} or {{ic|::1:5900}} is not reliable on dual stack network connections. If you want to allow insecure connections you can disable this setting.<br />
<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
[VNCServer]<br />
enabled=true<br />
command=Xvnc -rfbauth /etc/vncpasswd<br />
port=5900<br />
listen-address=localhost<br />
width=1024<br />
height=768<br />
depth=24<br />
}}<br />
<br />
Now open an SSH tunnel and connect to localhost as described in [[TigerVNC#On the client]].<br />
<br />
{{Note|If you get a blank screen upon opening the VNC connection, try a different LightDM greeter.}}<br />
<br />
=== Lock the screen using light-locker ===<br />
<br />
{{Pkg|light-locker}} is a simple screen locker using LightDM to authenticate the user. Once installed and running, you can lock your session via:<br />
<br />
$ light-locker-command -l<br />
<br />
This requires {{ic|light-locker}} to be started at the beginning of your session - see [[Autostarting]].<br />
<br />
<br />
=== Multiple-monitor setup ===<br />
<br />
Sometimes LightDM does not set the monitor resolution correctly on a multiple-monitor setup.<br />
The following Xorg configuration works with two monitors: a large primary screen on the left,<br />
and a secondary smaller screen to its right.<br />
The order can be reversed and tweaked.<br />
<br />
{{hc|/etc/X11/xorg.conf.d/52-resolution-fix.conf|2=<br />
Section "Monitor"<br />
Identifier "DP1"<br />
Option "PreferredMode" "3840x2160"<br />
Option "Primary" "1"<br />
EndSection<br />
Section "Monitor"<br />
Identifier "eDP1"<br />
Option "PreferredMode" "1920x1080"<br />
Option "RightOf" "DP1"<br />
EndSection<br />
}}<br />
<br />
== Troubleshooting ==<br />
<br />
=== Autologin does not work ===<br />
<br />
Ensure {{ic|1=autologin-user=}} in {{ic|/etc/lightdm/lightdm.conf}} contain the correct values. Trailing whitespace will cause errors.<br />
<br />
If autologin fails with a blank screen or if the login screen immediately returns, you may need to set {{ic|1=logind-check-graphical=true}}.<br />
<br />
You can also install {{AUR|lightdm-autologin-greeter-git}} for this special purpose.<br />
<br />
=== Viewing current configuration ===<br />
<br />
To view effective configuration, run:<br />
<br />
$ lightdm --show-config<br />
<br />
This will show current settings, with the configuration files these settings were read from.<br />
<br />
=== LightDM not starting and screen flashing ===<br />
<br />
If you encounter consistent screen flashing and ultimately no LightDM on boot, ensure that you have defined the greeter correctly in LightDM's config file. And if you have correctly defined the GTK greeter, make sure the {{ic|xsessions-directory}} (default: {{ic|/usr/share/xsessions}}) exists and contains at least one .desktop file.<br />
<br />
The same error can happen on lightdm startup if the last used session is not available anymore (eg. you last used gnome and then removed the gnome-session package): the easiest workaround is to temporarily restore the removed package. Another solution might be:<br />
<br />
# dbus-send --system --type=method_call --print-reply --dest=org.freedesktop.Accounts /org/freedesktop/Accounts/User1000 org.freedesktop.Accounts.User.SetXSession string:xfce<br />
<br />
This example sets the session "xfce" as default for the user 1000.<br />
<br />
=== Wrong locale displayed ===<br />
<br />
In case of your locale not being displayed correctly in Lightdm add your locale to {{ic|/etc/environment}}:<br />
<br />
LANG=pt_PT.utf8<br />
<br />
Alternatively if you want LightDM and its greeters to be in a language other than your set system locale, you can use the {{ic|1=Environment=}} option in [[Systemd#Drop-in files]].<br />
<br />
=== Unresponsive for a few minutes after startup ===<br />
<br />
You may have to download more entropy. Install and enable haveged, c.f. https://github.com/canonical/lightdm/issues/17<br />
<br />
=== Missing icons with GTK greeter ===<br />
<br />
If you are using {{Pkg|lightdm-gtk-greeter}} as a greeter and it shows placeholder images as icons, make sure valid icon themes and themes are installed and configured. Check the following file:<br />
<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
theme-name=mate # this should be the name of a directory under /usr/share/themes/<br />
icon-theme-name=mate # this should be the name of a fully featured icons set directory under /usr/share/icons/<br />
}}<br />
<br />
=== LightDM freezes on login attempt ===<br />
<br />
You may find that after entering the correct username and password and attempting to log in, LightDM freezes and you are unable to continue to the desktop. To fix the issue, reinstall the {{Pkg|gdk-pixbuf2}} package. See [https://bbs.archlinux.org/viewtopic.php?id=179031 this forum thread].<br />
<br />
=== LightDM displaying in wrong monitor ===<br />
<br />
If you are using multiple monitors, LightDM may display in the wrong one (e.g. if your primary monitor is on the right). To force the LightDM login screen to display on a specific monitor, edit {{ic|/etc/lightdm/lightdm.conf}} and change the ''display-setup-script'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm.conf|2=<br />
display-setup-script=xrandr --output ''HDMI1'' --primary<br />
}}<br />
<br />
Replace ''HDMI1'' with your real monitor ID, which you can find from '''xrandr''' command output.<br />
<br />
Alternatively, if you are using the GTK greeter, you can edit {{ic|/etc/lightdm/lightdm-gtk-greeter.conf}} and add the ''active-monitor'' parameter like this:<br />
{{hc|/etc/lightdm/lightdm-gtk-greeter.conf|2=<br />
[greeter]<br />
active-monitor=0<br />
}}<br />
<br />
Replace 0 with the desired display number.<br />
<br />
=== LightDM does not appear or monitor only displays TTY output ===<br />
<br />
It may happen that your system boots so fast that LightDM service is started before your graphics drivers are properly loaded. If this is your case, you will want to add the following config to your lightdm.conf file:<br />
<br />
[LightDM]<br />
logind-check-graphical=true<br />
<br />
This setting will tell LightDM to wait until graphics devices are ready before spawning greeters/autostarting sessions on them.<br />
<br />
=== LightDM is running with low FPS on Intel Graphics ===<br />
<br />
See [[Intel graphics#AccelMethod]].<br />
<br />
=== Pulseaudio not starting automatically ===<br />
<br />
See [[PulseAudio#Running]].<br />
<br />
=== Long pause before LightDM shows up when home is encrypted ===<br />
<br />
Some LightDM themes try to access the user avatar located in HOME. If your HOME is encrypted, LightDM cannot access it and hangs. To prevent this from happening, you can either:<br />
<br />
* Set your avatar as explained in [[#Changing your avatar]]<br />
* for {{Pkg|lightdm-gtk-greeter}} only: {{Ic|<nowiki>hide-user-image = true</nowiki>}} in {{Ic|/etc/lightdm/lightdm-gtk-greeter.conf}}<br />
<br />
=== Boot hangs on "[ OK ] Reached target Graphical Interface." ===<br />
<br />
There is a possibility that user and group lookups fail if you modified /etc/nsswitch.conf. That happens when:<br />
<br />
* nsswitch.conf group: includes {{Ic|<nowiki>ldap</nowiki>}} without setting {{Ic|<nowiki>nss_initgroups_ignoreusers ALLLOCAL</nowiki>}} in {{Ic|<nowiki>/etc/nslcd.conf</nowiki>}}<br />
<br />
=== Wayland session not working with duplicate GNOME entries in greeter ===<br />
<br />
* Some greeters ({{Pkg|lightdm-webkit2-greeter}} for example) do not support two sessions with the same name [https://github.com/CanonicalLtd/lightdm/issues/16]. To check for duplicate entries:<br />
<br />
$ ls -1 /usr/share/wayland-sessions /usr/share/xsessions<br />
<br />
* Rename the duplicate entry in /usr/share/xsessions. For example:<br />
<br />
# mv /usr/share/xsessions/gnome.desktop /usr/share/xsessions/gnome.desktop.disabled<br />
<br />
=== Login always segfaults on first attempt ===<br />
<br />
Set a hostname as described in [[Network_configuration#Set_the_hostname|Network Page]]. See also {{Bug|47694}}.<br />
<br />
=== Infinite login loop ===<br />
<br />
If you get stuck in loop in which you type your correct user and password but the screen goes black and the you are back in the login after every attempt, running {{ic|rm ~/.Xauthority}} (or the stuck user's problematic {{ic|.Xauthority}}) may fix the issue.<br />
<br />
Another reason for this may be that you tried to recreate your "lightdm.conf" from scratch and your version is missing this line:<br />
<br />
session-wrapper=/etc/lightdm/Xsession<br />
<br />
In that case, lightdm tries to use "lightdm-session" as the session-wrapper which does not exist on Arch Linux.<br />
<br />
== See also ==<br />
<br />
* [https://wiki.ubuntu.com/LightDM Ubuntu Wiki article]<br />
* [[Gentoo:LightDM]]<br />
* [https://launchpad.net/lightdm Launchpad Page] obsolete<br />
* [http://www.mattfischer.com/blog/?tag=lightdm LightDM blog]<br />
* [https://github.com/CanonicalLtd/lightdm LightDM on GitHub]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Logrotate&diff=653767Logrotate2021-03-01T15:42:13Z<p>Wooptoo: Compressing logs -- Fix potentially destructive command.</p>
<hr />
<div>[[Category:Logging]]<br />
[[Category:Data compression and archiving]]<br />
[[ja:Logrotate]]<br />
[[pl:Logrotate]]<br />
{{Related articles start}}<br />
{{Related|Cron}}<br />
{{Related|systemd/Timers}}<br />
{{Related articles end}}<br />
<br />
From https://github.com/logrotate/logrotate:<br />
<br />
:The logrotate utility is designed to simplify the administration of log files on a system which generates a lot of log files. Logrotate allows for the automatic rotation compression, removal and mailing of log files. Logrotate can be set to handle a log file daily, weekly, monthly or when the log file gets to a certain size.<br />
<br />
By default, logrotate's ''rotation'' consists of renaming existing log files with a numerical suffix, then recreating the original ''empty'' log file. For example, {{ic|/var/log/syslog.log}} is renamed {{ic|/var/log/syslog.log.1}}. If {{ic|/var/log/syslog.log.1}} already exists from a previous rotation, it is first renamed {{ic|/var/log/syslog.log.2}}. (The number of backlogs to keep can be configured.)<br />
<br />
==Installation==<br />
<br />
Logrotate can be installed with the {{Pkg|logrotate}} package.<br />
<br />
By default, logrotate runs daily using a [[systemd timer]]: {{ic|logrotate.timer}}.<br />
<br />
==Configuration==<br />
<br />
The primary configuration file for logrotate which sets default parameters is {{ic|/etc/logrotate.conf}}; additional application-specific configuration files are included from the {{ic|/etc/logrotate.d}} directory. Values set in application-specific configuration files override those same parameters in the primary configuration file. See {{man|5|logrotate.conf}} for configuration examples and a reference of available directives.<br />
<br />
To verify if logrotate works correctly, run it in debug mode, in this mode it does nothing except producing debug output:<br />
logrotate --debug /etc/logrotate.conf<br />
<br />
=== Compressing logs ===<br />
<br />
Logrotate can compress logs with a custom command like {{ic|zstd}}.<br />
<br />
{{hc|/etc/logrotate.conf|<br />
compress<br />
compresscmd /usr/bin/zstd<br />
compressext .zst<br />
compressoptions -T0 --long<br />
uncompresscmd /usr/bin/unzstd<br />
}}<br />
<br />
See {{man|5|logrotate.conf}} and {{man|1|zstd}} for more details.<br />
<br />
== Usage ==<br />
<br />
logrotate is usually run through the [[systemd]] service: {{ic|logrotate.service}}.<br />
<br />
To run logrotate manually:<br />
logrotate /etc/logrotate.conf<br />
<br />
To rotate a single log file:<br />
logrotate /etc/logrotate.d/mylog<br />
<br />
To simulate running your configuration file (''dry run''):<br />
logrotate --debug /etc/logrotate.d/mylog<br />
<br />
To force running rotations even when conditions are not met, run:<br />
logrotate -vf /etc/logrotate.d/mylog<br />
<br />
See {{man|8|logrotate}} for more details.<br />
<br />
==Troubleshooting==<br />
<br />
=== exim log not rotated ===<br />
<br />
If you have set the {{ic|olddir}} variable in {{ic|/etc/logrotate.conf}}, you will get a message such as:<br />
<br />
{{Ic|error: failed to rename /var/log/exim/mainlog to /var/log/old/mainlog.1: Permission denied}}<br />
<br />
To fix this, add the user {{ic|exim}} to the group {{ic|log}}. Then change the group of the {{ic|olddir}}, usually {{ic|/var/log/old}}, to {{ic|log}} instead of the default {{ic|root}}.<br />
<br />
=== Check logrotate status ===<br />
Logrotate rotations are usually logged to {{ic|/var/lib/logrotate.status}} (the {{ic|-s}} option allows you to specify another state file):<br />
<br />
{{hc|/var/lib/logrotate.status|<br />
"/var/log/mysql/query.log" 2016-3-20-5:0:0<br />
"/var/log/samba/samba-smbd.log" 2016-3-21-5:0:0<br />
"/var/log/httpd/access_log" 2016-3-20-5:0:0<br />
...<br />
}}<br />
<br />
=== Skipping log because parent directory has insecure permission ===<br />
Set in the config which user and which group has to job {{ic|/etc/logrotate.d/job}} to be run with:<br />
<br />
{{bc|<br />
file-to-be-rotated {<br />
su user group<br />
rotate 4<br />
}<br />
}}<br />
<br />
== See also ==<br />
<br />
* [http://wiki.gentoo.org/wiki/Logrotate Logrotate on Gentoo Linux Wiki]<br />
* {{man|8|logrotate}} manual page<br />
* {{man|5|logrotate.conf}} manual page</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Mkinitcpio&diff=653125Mkinitcpio2021-02-22T12:33:46Z<p>Wooptoo: COMPRESSION -- add clarification to zstd compressed image</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Initramfs]]<br />
[[Category:Kernel]]<br />
[[Category:Arch projects]]<br />
[[Category:Commands]]<br />
[[da:Mkinitcpio]]<br />
[[de:Mkinitcpio]]<br />
[[es:Mkinitcpio]]<br />
[[fr:mkinitcpio]]<br />
[[id:Mkinitcpio]]<br />
[[it:Mkinitcpio]]<br />
[[ja:Mkinitcpio]]<br />
[[pt:Mkinitcpio]]<br />
[[ru:Mkinitcpio]]<br />
[[zh-hans:Mkinitcpio]]<br />
{{Related articles start}}<br />
{{Related|systemd}}<br />
{{Related|Kernel modules}}<br />
{{Related|Minimal initramfs}}<br />
{{Related|Boot debugging}}<br />
{{Related|dracut}}<br />
{{Related|Booster}}<br />
{{Related articles end}}<br />
[https://projects.archlinux.org/mkinitcpio.git/ mkinitcpio] is a Bash script used to create an [[Wikipedia:Initial ramdisk|initial ramdisk]] environment. From the {{man|8|mkinitcpio}} man page:<br />
<br />
:The initial ramdisk is in essence a very small environment (early userspace) which loads various kernel modules and sets up necessary things before handing over control to {{ic|init}}. This makes it possible to have, for example, encrypted root file systems and root file systems on a software RAID array. ''mkinitcpio'' allows for easy extension with custom hooks, has autodetection at runtime, and many other features.<br />
<br />
Traditionally, the kernel was responsible for all hardware detection and initialization tasks early in the [[boot process]] before mounting the root file system and passing control to {{ic|init}}. However, as technology advances, these tasks have become increasingly complex. <br />
<br />
Nowadays, the root file system may be on a wide range of hardware, from SCSI to SATA to USB drives, controlled by a variety of drive controllers from different manufacturers. Additionally, the root file system may be encrypted or compressed; within a software RAID array or a logical volume group. The simple way to handle that complexity is to pass management into userspace: an initial ramdisk. See also: [https://web.archive.org/web/20150430223035/http://archlinux.me/brain0/2010/02/13/early-userspace-in-arch-linux/ /dev/brain0 » Blog Archive » Early Userspace in Arch Linux].<br />
<br />
''mkinitcpio'' has been developed by the Arch Linux developers and from community contributions. See the [https://projects.archlinux.org/mkinitcpio.git/ public Git repository].<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|mkinitcpio}} package, which is a dependency of the {{Pkg|linux}} package, so most users will already have it installed.<br />
<br />
Advanced users may wish to install the latest development version of ''mkinitcpio'' from Git with the {{AUR|mkinitcpio-git}} package.<br />
<br />
{{Note|It is '''highly''' recommended that you follow the [https://mailman.archlinux.org/mailman/listinfo/arch-projects arch-projects mailing list] if you use ''mkinitcpio'' from Git!}}<br />
<br />
== Image creation and activation ==<br />
<br />
=== Automated generation ===<br />
<br />
Every time a kernel is installed or upgraded, a [[pacman hook]] automatically generates a ''.preset'' file saved in {{ic|/etc/mkinitcpio.d/}}. For example {{ic|linux.preset}} for the official stable {{Pkg|linux}} kernel package. A preset is simply a list of information required to create initial ramdisk images, instead of manually specifying the various parameters and the location of the output files.<br />
By default, it contains the instructions to create two images:<br />
<br />
# the ''default'' ramdisk image created following the directives specified in the mkinitcpio [[#Configuration]], and<br />
# the ''fallback'' ramdisk image, same as above except that the ''autodetect'' hook is skipped during creation, thus including a full range of modules which supports most systems.<br />
<br />
After creating the preset, the pacman hook calls the ''mkinitcpio'' script which generates the two images, using the information provided in the preset.<br />
<br />
{{Note|''.preset'' files are used to automatically regenerate the initramfs after a kernel update; be careful when editing them.}}<br />
<br />
=== Manual generation ===<br />
<br />
To run the script manually, refer to the {{man|8|mkinitcpio}} manual page for instructions. In particular, to (re-)generate the preset provided by a kernel package, use the {{ic|-p}}/{{ic|--preset}} option followed by the preset to utilize. For example, for the {{Pkg|linux}} package, use the command:<br />
<br />
# mkinitcpio -p linux<br />
<br />
To (re-)generate all existing presets, use the {{ic|-P}}/{{ic|--allpresets}} switch. This is typically used to regenerate all the initramfs images after a change of the global [[#Configuration]]:<br />
<br />
# mkinitcpio -P<br />
<br />
Users may create any number of initramfs images with a variety of different configurations. The desired image must be specified in the respective [[boot loader]] configuration file.<br />
<br />
=== Customized generation ===<br />
<br />
Users can generate an image using an alternative configuration file. For example, the following will generate an initial ramdisk image according to the directions in {{ic|/etc/mkinitcpio-custom.conf}} and save it as {{ic|/boot/initramfs-custom.img}}.<br />
<br />
# mkinitcpio --config /etc/mkinitcpio-custom.conf --generate /boot/initramfs-custom.img<br />
<br />
If generating an image for a kernel other than the one currently running, add the kernel release version to the command line. The installed kernel releases can be found in {{ic|/usr/lib/modules/}}, the syntax is consistent with the output of the command {{ic|uname -r}} for each kernel.<br />
<br />
# mkinitcpio --generate /boot/initramfs-custom2.img --kernel 5.7.12-arch1-1<br />
<br />
== Configuration ==<br />
<br />
The primary configuration file for ''mkinitcpio'' is {{ic|/etc/mkinitcpio.conf}}. Additionally, preset definitions are provided by kernel packages in the {{ic|/etc/mkinitcpio.d}} directory (e.g. {{ic|/etc/mkinitcpio.d/linux.preset}}).<br />
<br />
Users can modify six variables within the configuration file, see {{man|5|mkinitcpio.conf}} for more details:<br />
<br />
; {{ic|MODULES}}: Kernel modules to be loaded before any boot hooks are run. <br />
; {{ic|BINARIES}}: Additional binaries to be included in the initramfs image.<br />
; {{ic|FILES}}: Additional files to be included in the initramfs image.<br />
; {{ic|HOOKS}}: Hooks are scripts that execute in the initial ramdisk.<br />
; {{ic|COMPRESSION}}: Used to compress the initramfs image.<br />
; {{ic|COMPRESSION_OPTIONS}}: Extra arguments to pass to the {{ic|COMPRESSION}} program. Usage of this setting is strongly discouraged. ''mkinitcpio'' will handle special requirements for compressors (e.g. passing {{ic|1=--check=crc32}} to xz), and misusage can easily lead to an unbootable system.<br />
<br />
{{Note|<br />
* Some hooks that may be required for your system like '''lvm2''', '''mdadm''', and '''encrypt''' are '''NOT''' enabled by default. Read the [[#HOOKS]] section carefully for instructions.<br />
* Users with multiple hardware disk controllers that use the same node names but different kernel modules (e.g. two SCSI/SATA or two IDE controllers) should use [[persistent block device naming]] to ensure that the right devices are mounted. Otherwise, the root device location may change between boots, resulting in kernel panics.<br />
}}<br />
<br />
=== MODULES ===<br />
<br />
The {{ic|MODULES}} array is used to specify modules to load before anything else is done.<br />
<br />
Modules suffixed with a {{ic|?}} will not throw errors if they are not found. This might be useful for custom kernels that compile in modules which are listed explicitly in a hook or configuration file.<br />
<br />
{{Note|<br />
* If you will be needing any file system during the boot process that is '''not live when ''mkinitcpio'' is run''' — for example, if your LUKS encryption key file is on an ext2 file system but no ext2 file system is mounted at the time ''mkinitcpio'' runs, this file system module must be added to the {{ic|MODULES}} array. See [[Dm-crypt/System configuration#cryptkey]] for more details.<br />
* If using '''reiser4''', it ''must'' be added to the {{ic|MODULES}} array.<br />
* If using a keyboard through a USB 3 hub and wish to use it to unlock a LUKS device, add {{ic|usbhid xhci_hcd}}<br />
}}<br />
<br />
=== BINARIES and FILES ===<br />
<br />
These options allow users to add files to the image. Both {{ic|BINARIES}} and {{ic|FILES}} are added before hooks are run, and may be used to override files used or provided by a hook. {{ic|BINARIES}} are auto-located within a standard {{ic|PATH}} and are dependency-parsed, meaning any required libraries will also be added. {{ic|FILES}} are added ''as-is''. For example:<br />
<br />
FILES=(/etc/modprobe.d/modprobe.conf)<br />
<br />
BINARIES=(kexec)<br />
<br />
Note that as both {{ic|BINARIES}} and {{ic|FILES}} are [[Bash]] arrays, multiple entries can be added delimited with spaces.<br />
<br />
=== HOOKS ===<br />
<br />
The {{ic|HOOKS}} array is the most important setting in the file. Hooks are small scripts which describe what will be added to the image. For some hooks, they will also contain a runtime component which provides additional behavior, such as starting a daemon, or assembling a stacked block device. Hooks are referred to by their name, and executed in the order they exist in the {{ic|HOOKS}} array of the configuration file.<br />
<br />
The default {{ic|HOOKS}} setting should be sufficient for most simple, single disk setups. For root devices which are stacked or multi-block devices such as [[LVM]], [[Software_RAID_and_LVM|mdadm]], or [[dm-crypt]], see the respective wiki pages for further necessary configuration.<br />
<br />
==== Build hooks ====<br />
<br />
Build hooks are found in {{ic|/usr/lib/initcpio/install/}}, custom build hooks can be placed in {{ic|/etc/initcpio/install/}}. These files are sourced by the bash shell during runtime of ''mkinitcpio'' and should contain two functions: {{ic|build}} and {{ic|help}}. The {{ic|build}} function describes the modules, files, and binaries which will be added to the image. An API, documented by {{man|8|mkinitcpio}}, serves to facilitate the addition of these items. The {{ic|help}} function outputs a description of what the hook accomplishes.<br />
<br />
For a list of all available hooks:<br />
<br />
$ mkinitcpio -L<br />
<br />
Use ''mkinitcpio'''s {{ic|-H}}/{{ic|--hookhelp}} option to output help for a specific hook, for example:<br />
<br />
$ mkinitcpio -H udev<br />
<br />
==== Runtime hooks ====<br />
<br />
Runtime hooks are found in {{ic|/usr/lib/initcpio/hooks/}}, custom runtime hooks can be placed in {{ic|/etc/initcpio/hooks/}}. For any runtime hook, there should always be a build hook of the same name, which calls {{ic|add_runscript}} to add the runtime hook to the image. These files are sourced by the busybox ash shell during early userspace. With the exception of cleanup hooks, they will always be run in the order listed in the {{ic|HOOKS}} setting. Runtime hooks may contain several functions:<br />
<br />
{{ic|run_earlyhook}}: Functions of this name will be run once the API file systems have been mounted and the kernel command line has been parsed. This is generally where additional daemons, such as udev, which are needed for the early boot process are started from.<br />
<br />
{{ic|run_hook}}: Functions of this name are run shortly after the early hooks. This is the most common hook point, and operations such as assembly of stacked block devices should take place here.<br />
<br />
{{ic|run_latehook}}: Functions of this name are run after the root device has been mounted. This should be used, sparingly, for further setup of the root device, or for mounting other file systems, such as {{ic|/usr}}.<br />
<br />
{{ic|run_cleanuphook}}: Functions of this name are run as late as possible, and in the reverse order of how they are listed in the {{ic|HOOKS}} array in the configuration file. These hooks should be used for any last minute cleanup, such as shutting down any daemons started by an early hook.<br />
<br />
{{Note|Runtime hooks are only used by busybox init. '''systemd''' hook triggers a systemd based init, which does not run any runtime hooks but uses systemd units instead.}}<br />
<br />
==== Common hooks ====<br />
<br />
A table of common hooks and how they affect image creation and runtime follows. Note that this table is not complete, as packages can provide custom hooks.<br />
<br />
{{Expansion|Add info about {{ic|hostdata}}, {{ic|memdisk}}, {{ic|sleep}} and {{ic|strip}}, find out if {{ic|dmraid}}, etc. work/are needed for systemd based initramfs.|section=Improvements for the Common hooks table and section about systemd hook}}<br />
<br />
{| class="wikitable"<br />
! busybox init !! systemd init !! [[#Build hooks|Build hook]] !! [[#Runtime hooks|Runtime hook]] (busybox init only)<br />
|-<br />
|colspan="2" {{C|'''base'''}} || Sets up all initial directories and installs base utilities and libraries. Always keep this hook as the first hook unless you know what you are doing, as it provides critical busybox init when not using '''systemd''' hook. <br/>Provides a busybox recovery shell when using '''systemd''' hook. {{Note|The recovery shell is not usable since the root account in the initramfs is [https://github.com/archlinux/svntogit-packages/commit/776743d220cbb56e9abca2cc8bcef3a0ab7c8d0a locked].}}<br />
| {{-}}<br />
|-<br />
| {{C|'''udev'''}} ||rowspan="3" {{C|'''systemd'''}} || Adds udevd, udevadm, and a small subset of udev rules to your image. || Starts the udev daemon and processes uevents from the kernel; creating device nodes. As it simplifies the boot process by not requiring the user to explicitly specify necessary modules, using it is recommended.<br />
|-<br />
| {{C|'''usr'''}} || Adds support for {{ic|/usr}} on a separate partition. See [[#/usr as a separate partition]] for details. || Mounts the {{ic|/usr}} partition after the real root has been mounted.<br />
|-<br />
|-<br />
| {{C|'''resume'''}} || {{-}} || Tries to resume from the "suspend to disk" state. See [[Hibernation]] for further configuration.<br />
|-<br />
| {{C|'''btrfs'''}} || {{Grey|--}} || Sets the required modules to enable [[Btrfs]] for using multiple devices with Btrfs. You need to have {{Pkg|btrfs-progs}} installed to use this. This hook is not required for using Btrfs on a single device. || Runs {{ic|btrfs device scan}} to assemble a multi-device Btrfs root file system when '''udev''' hook or '''systemd''' hook is not present. The {{Pkg|btrfs-progs}} package is required for this hook.<br />
|-<br />
|colspan="2" {{C|'''autodetect'''}} || Shrinks your initramfs to a smaller size by creating a whitelist of modules from a scan of sysfs. Be sure to verify included modules are correct and none are missing. This hook must be run before other subsystem hooks in order to take advantage of auto-detection. Any hooks placed before 'autodetect' will be installed in full. || {{-}}<br />
|-<br />
|colspan="2" {{C|'''modconf'''}} || Includes modprobe configuration files from {{ic|/etc/modprobe.d/}} and {{ic|/usr/lib/modprobe.d/}}. || {{-}}<br />
|-<br />
|colspan="2" {{C|'''block'''}} || Adds all block device modules, formerly separately provided by the ''fw'', ''mmc'', ''pata'', ''sata'', ''scsi'', ''usb'', and ''virtio'' hooks. || {{-}}<br />
|-<br />
| {{C|'''net'''}} || {{Grey|''not implemented''}} || Adds the necessary modules for a network device. You must have {{Pkg|mkinitcpio-nfs-utils}} installed to use this, see [[#Using net]] for details. || Provides handling for an NFS-based root file system.<br />
|-<br />
| {{C|'''dmraid'''}} || {{Grey|''?''}} || Provides support for fakeRAID root devices. You must have {{Pkg|dmraid}} installed to use this. Note that it is preferred to use {{ic|mdadm}} with the '''mdadm_udev''' hook with fakeRAID if your controller supports it. See [[#Using RAID]] for details. || Locates and assembles fakeRAID block devices using {{ic|dmraid}}.<br />
|-<br />
| {{C|'''mdadm'''}} || {{Grey|--}} || Provides support for assembling RAID arrays from {{ic|/etc/mdadm.conf}}, or autodetection during boot. You must have {{Pkg|mdadm}} installed to use this. The '''mdadm_udev''' hook is preferred over this hook. See [[#Using RAID]] for details. || Locates and assembles software RAID block devices using {{ic|mdassemble}}.<br />
|-<br />
|colspan="2" {{C|'''mdadm_udev'''}} || Provides support for assembling RAID arrays via udev. You must have {{Pkg|mdadm}} installed to use this. If you use this hook with a FakeRAID array, it is recommended to include {{ic|mdmon}} in {{ic|BINARIES}}. See [[#Using RAID]] for details. || Locates and assembles software RAID block devices using {{ic|udev}} and {{ic|mdadm}} incremental assembly. This is the preferred method of mdadm assembly (rather than using the above ''mdadm'' hook). <br />
|-<br />
|colspan="2" {{C|'''keyboard'''}} || Adds the necessary modules for keyboard devices. Use this if you have an USB or serial keyboard and need it in early userspace (either for entering encryption passphrases or for use in an interactive shell). As a side effect, modules for some non-keyboard input devices might be added too, but this should not be relied on. Supersedes old ''usbinput'' hook.<br />
<br />
{{Tip|For systems that are booted with different hardware configurations (e.g. laptops with external keyboard vs. internal keyboard or [[Wikipedia:Headless computer|headless systems]]), it is helpful to place this hook before '''autodetect''' in order to always include all keyboard drivers. Otherwise the external keyboard only works in early userspace if it was connected when creating the image.}}<br />
<br />
| {{-}}<br />
|-<br />
| {{C|'''keymap'''}} ||rowspan="2" {{C|'''sd-vconsole'''}} || Adds the specified [[Linux console/Keyboard configuration#Persistent configuration|keymap(s)]] from {{ic|/etc/vconsole.conf}} to the initramfs. If you use [[dm-crypt/Encrypting an entire system|system encryption]], especially full-disk encryption, make sure you add it before the {{ic|1=encrypt}} hook. || Loads the specified keymap(s) from {{ic|/etc/vconsole.conf}} during early userspace.<br />
|-<br />
| {{C|'''consolefont'''}} || Adds the specified [[Linux console#Persistent configuration|console font]] from {{ic|/etc/vconsole.conf}} to the initramfs. || Loads the specified console font from {{ic|/etc/vconsole.conf}} during early userspace.<br />
|-<br />
| {{C|'''encrypt'''}} || {{C|'''sd-encrypt'''}} || Adds the {{ic|dm_crypt}} kernel module and the {{ic|cryptsetup}} tool to the image. You must have {{Pkg|cryptsetup}} installed to use this. || Detects and unlocks an encrypted root partition. See [[#Runtime customization]] for further configuration.<br />
For '''sd-encrypt''' see [[dm-crypt/System configuration#Using sd-encrypt hook]].<br />
|-<br />
|colspan="2" {{C|'''lvm2'''}} || Adds the device mapper kernel module and the {{ic|lvm}} tool to the image. You must have {{Pkg|lvm2}} installed to use this. || Enables all LVM2 volume groups. This is necessary if you have your root file system on [[LVM]].<br />
|-<br />
|colspan="2" {{C|'''fsck'''}} || Adds the fsck binary and file system-specific helpers. If added after the '''autodetect''' hook, only the helper specific to your root file system will be added. Usage of this hook is '''strongly''' recommended, and it is required with a separate {{ic|/usr}} partition. It is highly recommended that if you include this hook that you also include any necessary modules to ensure your keyboard will work in early userspace. See [[fsck#Boot time checking]] for more details.|| Runs fsck against your root device (and {{ic|/usr}} if separate) prior to mounting. The use of this hook requires the rw parameter to be set on the kernel commandline ([https://bbs.archlinux.org/viewtopic.php?pid=1307895#p1307895 discussion]).<br />
|-<br />
|colspan="2" {{C|'''filesystems'''}} || This includes necessary file system modules into your image. This hook is '''required''' unless you specify your file system modules in {{ic|MODULES}}. || {{-}}<br />
|-<br />
|}<br />
<br />
=== COMPRESSION ===<br />
<br />
The kernel supports several formats for compression of the initramfs: {{pkg|gzip}}, {{pkg|bzip2}}, lzma, {{pkg|xz}}, {{pkg|lzo}}, {{pkg|lz4}} and {{pkg|zstd}}. The provided {{ic|mkinitcpio.conf}} has the various {{ic|COMPRESSION}} options commented out. Uncomment one to choose which compression format you desire.<br />
<br />
Specifying no {{ic|COMPRESSION}} will result in a zstd-compressed initramfs file, with {{ic|zstd -T0}} as the default compression option.<br />
<br />
To create an uncompressed image, specify {{ic|1=COMPRESSION=cat}} in the configuration file or use {{ic|-z cat}} on the command line.<br />
<br />
Make sure you have the correct file compression utility installed for the method you wish to use.<br />
<br />
{{Tip|With a compression ratio typically around 2.5 on the image in its high compression mode (-9) and a very fast decompression speed, lz4 is a safe choice. For a slightly better compression, lzo is still fast to decompress. If further size reduction is needed, zstd provides a good balance of compressed image size and decompression speed. xz will achieve the smallest size with a reduction factor around 5 in its high compression preset (-9), at the cost of a much slower decompression speed.}}<br />
<br />
=== COMPRESSION_OPTIONS ===<br />
<br />
These are additional flags passed to the program specified by {{ic|COMPRESSION}}, such as:<br />
<br />
COMPRESSION_OPTIONS=(-9)<br />
<br />
{{Note|This option can be left empty, ''mkinitcpio'' will ensure that any supported compression method has the necessary flags to produce a working image. On the other hand, misusage of this option can lead to an '''unbootable system''' if the kernel is unable to unpack the resultant archive.}}<br />
<br />
== Runtime customization ==<br />
<br />
{{Expansion|Which options work with the {{ic|systemd}} hook and which are {{ic|base}}-only?}}<br />
<br />
Runtime configuration options can be passed to {{ic|init}} and certain hooks via the kernel command line. Kernel command-line parameters are often supplied by the bootloader. The options discussed below can be appended to the kernel command line to alter default behavior. See [[Kernel parameters]] and [[Arch boot process]] for more information.<br />
<br />
=== init from base hook ===<br />
<br />
; {{ic|root}}: This is the most important parameter specified on the kernel command line, as it determines what device will be mounted as your proper root device. ''mkinitcpio'' is flexible enough to allow a wide variety of formats, for example:<br />
<br />
root=/dev/sda1 # /dev node<br />
root=LABEL=CorsairF80 # label<br />
root=UUID=ea1c4959-406c-45d0-a144-912f4e86b207 # UUID<br />
root=PARTUUID=14420948-2cea-4de7-b042-40f67c618660 # GPT partition UUID<br />
<br />
{{Note|The following boot parameters alter the default behavior of {{ic|init}} in the initramfs environment. See {{ic|/usr/lib/initcpio/init}} for details. They will not work when {{ic|systemd}} hook is being used since the {{ic|init}} from {{ic|base}} hook is replaced.}}<br />
<br />
; {{ic|break}}: If {{ic|break}} or {{ic|1=break=premount}} is specified, {{ic|init}} pauses the boot process (after loading hooks, but before mounting the root file system) and launches an interactive shell which can be used for troubleshooting purposes. This shell can be launched after the root has been mounted by specifying {{ic|1=break=postmount}}. Normal boot continues after exiting from the shell.<br />
<br />
; {{ic|disablehooks}}: Disable hooks at runtime by adding {{ic|1=disablehooks=hook1[,hook2,...]}}. For example: {{bc|1=disablehooks=resume}}<br />
<br />
; {{ic|earlymodules}}: Alter the order in which modules are loaded by specifying modules to load early via {{ic|1=earlymodules=mod1[,mod2,...]}}. (This may be used, for example, to ensure the correct ordering of multiple network interfaces.)<br />
<br />
See [[Boot debugging]] and {{man|8|mkinitcpio}} for other parameters.<br />
<br />
=== Using RAID ===<br />
<br />
{{Note|{{ic|mdadm}} is deprecated. If using it you will see {{ic|1===> WARNING: Hook 'mdadm' is deprecated. Replace it with 'mdadm_udev' in your config}} when doing an upgrade.}}<br />
<br />
First, add the {{ic|mdadm_udev}} or {{ic|mdadm}} hook to the {{ic|HOOKS}} array and any required RAID modules (e.g. raid456, ext4) to the {{ic|MODULES}} array in {{ic|/etc/mkinitcpio.conf}}.<br />
<br />
Using the {{ic|mdadm}} hook, you no longer need to configure your RAID array in the [[kernel parameters]]. The {{ic|mdadm}} hook will either use your {{ic|/etc/mdadm.conf}} file or automatically detect the array(s) during the init phase of boot.<br />
<br />
Assembly via udev is also possible using the {{ic|mdadm_udev}} hook. Upstream prefers this method of assembly. {{ic|/etc/mdadm.conf}} will still be read for purposes of naming the assembled devices if it exists.<br />
<br />
Some RAID controllers may require a {{ic|mdmon}} binary for arrays to become fully operational.<br />
<br />
=== Using net ===<br />
<br />
{{Note|NFSv4 is not yet supported {{Bug|28287}}.}}<br />
<br />
'''Required Packages'''<br />
<br />
{{ic|net}} requires the {{Pkg|mkinitcpio-nfs-utils}} package.<br />
<br />
'''Kernel Parameters''' <br />
<br />
Comprehensive and up-to-date information can be found in the official [https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsroot.html kernel documentation].<br />
<br />
'''ip='''<br />
<br />
This parameter tells the kernel how to configure IP addresses of devices and also how to set up the IP routing table. It can take up to nine arguments separated by colons: {{ic|1=ip=<client-ip>:<server-ip>:<gw-ip>:<netmask>:<hostname>:<device>:<autoconf>:<dns0-ip>:<dns1-ip>}}.<br />
<br />
If this parameter is missing from the kernel command line, all fields are assumed to be empty, and the defaults mentioned in the [https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsroot.html kernel documentation] apply. In general this means that the kernel tries to configure everything using autoconfiguration.<br />
<br />
The {{ic|<autoconf>}} parameter can appear alone as the value to the 'ip' parameter (without all the ':' characters before). If the value is {{ic|1=ip=off}} or {{ic|1=ip=none}}, no autoconfiguration will take place, otherwise autoconfiguration will take place. The most common way to use this is {{ic|1=ip=dhcp}}.<br />
<br />
For parameters explanation, see the [https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsroot.html kernel documentation].<br />
<br />
Examples:<br />
<br />
ip=127.0.0.1:::::lo:none --> Enable the loopback interface.<br />
ip=192.168.1.1:::::eth2:none --> Enable static eth2 interface.<br />
ip=:::::eth0:dhcp --> Enable dhcp protocol for eth0 configuration.<br />
<br />
{{Note|Make sure to use kernel device names (e.g. {{ic|eth0}}) for the {{ic|<device>}} parameter, the persistent names (e.g. {{ic|enp2s0}}) will not work. See [[Network configuration#Network interfaces]] for details.}}<br />
<br />
'''BOOTIF='''<br />
<br />
If you have multiple network cards, this parameter can include the MAC address of the interface you are booting from. This is often useful as interface numbering may change, or in conjunction with pxelinux IPAPPEND 2 or IPAPPEND 3 option.<br />
If not given, eth0 will be used.<br />
<br />
Example:<br />
<br />
BOOTIF=01-A1-B2-C3-D4-E5-F6 # Note the prepended "01-" and capital letters.<br />
<br />
'''nfsroot='''<br />
<br />
If the {{ic|nfsroot}} parameter is NOT given on the command line, the default {{ic|/tftpboot/%s}} will be used.<br />
<br />
nfsroot=[<server-ip>:]<root-dir>[,<nfs-options>]<br />
<br />
Run {{ic|mkinitcpio -H net}} for parameter explanation.<br />
<br />
=== Using LVM ===<br />
<br />
If your root device is on [[LVM]], see [[Install Arch Linux on LVM#Adding mkinitcpio hooks]].<br />
<br />
=== Using encrypted root ===<br />
<br />
If using an [[Dm-crypt/Encrypting_an_entire_system|encrypted root]] see [[dm-crypt/System configuration#mkinitcpio]] for detailed information on which hooks to include.<br />
<br />
=== /usr as a separate partition ===<br />
<br />
If you keep {{ic|/usr}} as a separate partition, you must adhere to the following requirements:<br />
<br />
* Add the {{ic|fsck}} hook, mark {{ic|/usr}} with a {{ic|passno}} of {{ic|2}} in {{ic|/etc/fstab}} to run the check on the partition at startup. While recommended for everyone, it is mandatory if you want your {{ic|/usr}} partition to be fsck'ed at boot-up. Without this hook, {{ic|/usr}} will never be fsck'd.<br />
* If not using the systemd hook, add the {{ic|usr}} hook. This will mount the {{ic|/usr}} partition after root is mounted.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Extracting the image ===<br />
<br />
If you are curious about what is inside the initramfs image, you can extract it and poke at the files inside of it. <br />
<br />
The initramfs image is an SVR4 CPIO archive, generated via the {{ic|find}} and {{ic|bsdcpio}} commands, optionally compressed with a compression scheme understood by the kernel. For more information on the compression schemes, see [[#COMPRESSION]].<br />
<br />
''mkinitcpio'' includes a utility called {{ic|lsinitcpio}} which will list and/or extract the contents of initramfs images.<br />
<br />
You can list the files in the image with:<br />
<br />
$ lsinitcpio /boot/initramfs-linux.img<br />
<br />
And to extract them all in the current directory:<br />
<br />
$ lsinitcpio -x /boot/initramfs-linux.img<br />
<br />
You can also get a more human-friendly listing of the important parts in the image:<br />
<br />
$ lsinitcpio -a /boot/initramfs-linux.img<br />
<br />
=== Recompressing a modified extracted image ===<br />
<br />
After extracting an image as explained above, after modifying it, you can find the command necessary to recompress it. Edit {{ic|/usr/bin/mkinitcpio}} and change the line as shown below (line 531 in ''mkinitcpio'' v20-1.)<br />
<br />
#MKINITCPIO_PROCESS_PRESET=1 "$0" "${preset_cmd[@]}"<br />
MKINITCPIO_PROCESS_PRESET=1 /usr/bin/bash -x "$0" "${preset_cmd[@]}"<br />
<br />
Then running {{ic|mkinitcpio}} with its usual options (typically {{ic|mkinitcpio -p linux}}), toward the last 20 lines or so you will see something like:<br />
<br />
+ find -mindepth 1 -printf '%P\0'<br />
+ LANG=C<br />
+ bsdcpio -0 -o -H newc --quiet<br />
+ gzip<br />
<br />
Which corresponds to the command you need to run, which may be:<br />
<br />
# find -mindepth 1 -printf '%P\0' | LANG=C bsdcpio -0 -o -H newc --quiet | gzip > /boot/initramfs-linux.img<br />
<br />
{{Warning|It is a good idea to rename the automatically generated {{ic|/boot/initramfs-linux.img}} before you overwrite it, so you can easily undo your changes. Be prepared for making a mistake that prevents your system from booting. If this happens, you will need to boot through the fallback, or a boot CD, to restore your original, run ''mkinitcpio'' to overwrite your changes, or fix them yourself and recompress the image.}}<br />
<br />
=== "/dev must be mounted" when it already is ===<br />
<br />
The test used by ''mkinitcpio'' to determine if {{ic|/dev}} is mounted is to see if {{ic|/dev/fd/}} is there. If everything else looks fine, it can be "created" manually by:<br />
<br />
# ln -s /proc/self/fd /dev/<br />
<br />
(Obviously, {{ic|/proc}} must be mounted as well. ''mkinitcpio'' requires that anyway, and that is the next thing it will check.)<br />
<br />
=== Possibly missing firmware for module XXXX ===<br />
<br />
When initramfs are being rebuild after a kernel update, you might get these or similar warnings:<br />
<br />
==> WARNING: Possibly missing firmware for module: wd719x<br />
==> WARNING: Possibly missing firmware for module: aic94xx<br />
==> WARNING: Possibly missing firmware for module: xhci_pci<br />
<br />
These appear to any Arch Linux users, especially those who have not installed these firmware modules. If you do not use hardware which uses these firmwares you can safely ignore this message.<br />
<br />
Most common firmware files can be acquired by [[install]]ing the {{Pkg|linux-firmware}} package. For other packages proving firmware, try searching for the module name in the [[official repositories]] or [[AUR]].<br />
<br />
See also related discussion at [https://gist.github.com/imrvelj/c65cd5ca7f5505a65e59204f5a3f7a6d].<br />
<br />
=== No PS/2 controller found ===<br />
<br />
On some motherboards (mostly ancient ones, but also a few new ones), the i8042 controller cannot be automatically detected. It is rare, but some people will surely be without keyboard. You can detect this situation in advance. If you have a PS/2 port and get {{ic|i8042: PNP: No PS/2 controller found. Probing ports directly}} message, add '''atkbd''' to the {{ic|MODULES}} array.<br />
<br />
=== Standard rescue procedures ===<br />
<br />
With an improper initial ram-disk a system often is unbootable. So follow a system rescue procedure like below:<br />
<br />
==== Boot succeeds on one machine and fails on another ====<br />
<br />
''mkinitcpio'''s {{ic|autodetect}} hook filters unneeded [[kernel modules]] in the primary initramfs scanning {{ic|/sys}} and the modules loaded at the time it is run. If you transfer your {{ic|/boot}} directory to another machine and the boot sequence fails during early userspace, it may be because the new hardware is not detected due to missing kernel modules. Note that USB 2.0 and 3.0 need different kernel modules. <br />
<br />
To fix, first try choosing the [[#Image creation and activation|fallback]] image from your [[bootloader]], as it is not filtered by {{ic|autodetect}}. Once booted, run ''mkinitcpio'' on the new machine to rebuild the primary image with the correct modules. If the fallback image fails, try booting into an Arch Linux live CD/USB, chroot into the installation, and run ''mkinitcpio'' on the new machine. As a last resort, try [[#MODULES|manually]] adding modules to the initramfs.<br />
<br />
== See also ==<br />
<br />
* Linux Kernel documentation on [https://www.kernel.org/doc/html/latest/filesystems/ramfs-rootfs-initramfs.html#what-is-rootfs initramfs, "What is rootfs?"]<br />
* Linux Kernel documentation on [https://www.kernel.org/doc/html/latest/admin-guide/initrd.html initrd]<br />
* Wikipedia article on [[wikipedia:initrd|initrd]]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=User:Wooptoo&diff=652517User:Wooptoo2021-02-15T19:53:09Z<p>Wooptoo: </p>
<hr />
<div>Occasional ArchWiki contributor :)<br />
<br />
* [https://aur.archlinux.org/packages/?K=wooptoo&SeB=m AUR Packages]<br />
* [https://wooptoo.com/ My Blog]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Logrotate&diff=652290Logrotate2021-02-14T11:16:06Z<p>Wooptoo: Added Compressing logs with zstd</p>
<hr />
<div>[[Category:Logging]]<br />
[[Category:Data compression and archiving]]<br />
[[ja:Logrotate]]<br />
[[pl:Logrotate]]<br />
{{Related articles start}}<br />
{{Related|Cron}}<br />
{{Related|systemd/Timers}}<br />
{{Related articles end}}<br />
<br />
From https://github.com/logrotate/logrotate:<br />
<br />
:The logrotate utility is designed to simplify the administration of log files on a system which generates a lot of log files. Logrotate allows for the automatic rotation compression, removal and mailing of log files. Logrotate can be set to handle a log file daily, weekly, monthly or when the log file gets to a certain size.<br />
<br />
By default, logrotate's ''rotation'' consists of renaming existing log files with a numerical suffix, then recreating the original ''empty'' log file. For example, {{ic|/var/log/syslog.log}} is renamed {{ic|/var/log/syslog.log.1}}. If {{ic|/var/log/syslog.log.1}} already exists from a previous rotation, it is first renamed {{ic|/var/log/syslog.log.2}}. (The number of backlogs to keep can be configured.)<br />
<br />
==Installation==<br />
<br />
Logrotate can be installed with the {{Pkg|logrotate}} package.<br />
<br />
By default, logrotate runs daily using a [[systemd timer]]: {{ic|logrotate.timer}}.<br />
<br />
==Configuration==<br />
<br />
The primary configuration file for logrotate which sets default parameters is {{ic|/etc/logrotate.conf}}; additional application-specific configuration files are included from the {{ic|/etc/logrotate.d}} directory. Values set in application-specific configuration files override those same parameters in the primary configuration file. See {{man|5|logrotate.conf}} for configuration examples and a reference of available directives.<br />
<br />
To verify if logrotate works correctly, run it in debug mode, in this mode it does nothing except producing debug output:<br />
logrotate --debug /etc/logrotate.conf<br />
<br />
== Usage ==<br />
<br />
logrotate is usually run through the [[systemd]] service: {{ic|logrotate.service}}.<br />
<br />
To run logrotate manually:<br />
logrotate /etc/logrotate.conf<br />
<br />
To rotate a single log file:<br />
logrotate /etc/logrotate.d/mylog<br />
<br />
To simulate running your configuration file (''dry run''):<br />
logrotate --debug /etc/logrotate.d/mylog<br />
<br />
To force running rotations even when conditions are not met, run:<br />
logrotate -vf /etc/logrotate.d/mylog<br />
<br />
See {{man|8|logrotate}} for more details.<br />
<br />
== Compressing logs ==<br />
<br />
Logrotate can compress logs with a custom command like {{ic|zstd}}.<br />
<br />
{{hc|/etc/logrotate.conf|<br />
# uncomment this if you want your log files compressed<br />
compress<br />
compresscmd /usr/bin/zstd<br />
compressext .zst<br />
compressoptions -T0 --long --rm<br />
uncompresscmd /usr/bin/unzstd<br />
}}<br />
<br />
See {{man|5|logrotate.conf}} and {{man|1|zstd}} for more details.<br />
<br />
<br />
==Troubleshooting==<br />
<br />
=== exim log not rotated ===<br />
<br />
If you have set the {{ic|olddir}} variable in {{ic|/etc/logrotate.conf}}, you will get a message such as:<br />
<br />
{{Ic|error: failed to rename /var/log/exim/mainlog to /var/log/old/mainlog.1: Permission denied}}<br />
<br />
To fix this, add the user {{ic|exim}} to the group {{ic|log}}. Then change the group of the {{ic|olddir}}, usually {{ic|/var/log/old}}, to {{ic|log}} instead of the default {{ic|root}}.<br />
<br />
=== Check logrotate status ===<br />
Logrotate rotations are usually logged to {{ic|/var/lib/logrotate.status}} (the {{ic|-s}} option allows you to specify another state file):<br />
<br />
{{hc|/var/lib/logrotate.status|<br />
"/var/log/mysql/query.log" 2016-3-20-5:0:0<br />
"/var/log/samba/samba-smbd.log" 2016-3-21-5:0:0<br />
"/var/log/httpd/access_log" 2016-3-20-5:0:0<br />
...<br />
}}<br />
<br />
=== Skipping log because parent directory has insecure permission ===<br />
Set in the config which user and which group has to job {{ic|/etc/logrotate.d/job}} to be run with:<br />
<br />
{{bc|<br />
file-to-be-rotated {<br />
su user group<br />
rotate 4<br />
}<br />
}}<br />
<br />
== See also ==<br />
<br />
* [http://wiki.gentoo.org/wiki/Logrotate Logrotate on Gentoo Linux Wiki]<br />
* {{man|8|logrotate}} manual page<br />
* {{man|5|logrotate.conf}} manual page</div>Wooptoohttps://wiki.archlinux.org/index.php?title=User:Wooptoo&diff=644160User:Wooptoo2020-12-08T14:49:42Z<p>Wooptoo: </p>
<hr />
<div>Occasional ArchWiki contributor :)<br />
<br />
[https://wooptoo.com/ My Blog]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=User:Wooptoo&diff=644159User:Wooptoo2020-12-08T14:38:06Z<p>Wooptoo: </p>
<hr />
<div>Occasional ArchWiki contributor :)<br />
<br />
[https://wooptoo.com My Blog]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=PulseAudio/Examples&diff=644158PulseAudio/Examples2020-12-08T14:37:19Z<p>Wooptoo: Added the Renaming devices section</p>
<hr />
<div>[[Category:Sound]]<br />
[[it:PulseAudio (Italiano)/Examples]]<br />
[[ja:PulseAudio/サンプル]]<br />
[[ru:PulseAudio (Русский)/Examples]]<br />
{{Related articles start}}<br />
{{Related|PulseAudio}}<br />
{{Related|PulseAudio/Troubleshooting}}<br />
{{Related articles end}}<br />
== Set default input source ==<br />
<br />
List available input sources<br />
{{hc|$ pacmd list-sources {{!}} grep -e 'index:' -e device.string -e 'name:'|2=<br />
'' ''index: 0<br />
name: <input><br />
device.string = "hw:2"<br />
* index: 1<br />
name: <oss_input.dsp><br />
device.string = "/dev/dsp"<br />
index: 2<br />
name: <alsa_output.pci-0000_04_01.0.analog-stereo.monitor><br />
}}<br />
<br />
The {{ic|*}} in front of the index indicates the current default input.<br />
<br />
To set a system wide default, add the source name in the {{ic|default.pa}} file:<br />
{{hc|/etc/pulse/default.pa|...<br />
set-default-source ''alsa_output.pci-0000_04_01.0.analog-stereo.monitor''<br />
...}}<br />
<br />
For temporary use<br />
$ pacmd "set-default-source alsa_output.pci-0000_04_01.0.analog-stereo.monitor"<br />
<br />
{{Tip|The default source can be referred as {{ic|@DEFAULT_SOURCE@}} in commands, for example: {{ic|$ pactl set-source-mute @DEFAULT_SOURCE@ toggle}}.}}<br />
<br />
== Set the default output sink ==<br />
<br />
To list the output sinks available, type the following command:<br />
{{hc|$ pacmd list-sinks {{!}} grep -e 'name:' -e 'index:'|<br />
* index: 0<br />
name: <alsa_output.pci-0000_04_01.0.analog-stereo><br />
index: 1<br />
name: <combined>}}<br />
<br />
The {{ic|*}} in front of the index indicates the current default output.<br />
<br />
To set a system wide default, add the source name in the {{ic|default.pa}} file:<br />
{{hc|/etc/pulse/default.pa|...<br />
set-default-sink ''alsa_output.pci-0000_04_01.0.analog-stereo''<br />
...}}<br />
<br />
When done then you can logout/login or restart PulseAudio manually for these changes to take effect.<br />
<br />
{{Note|1=<nowiki></nowiki><br />
* The numbering of sinks is not guaranteed to be persistent, so all sinks in the {{ic|default.pa}} file should be identified by the name.<br />
* For quick identification at runtime (e.g. to manage sound volume), you can use the sink index instead of the sink name: {{bc|<nowiki><br />
$ pactl set-sink-volume 0 +3%<br />
$ pactl set-sink-volume 0 -3%<br />
$ pactl set-sink-mute 0 toggle<br />
</nowiki>}}<br />
* To avoid unnecessary overriding of 100% normal volume it is better to use alternative utilities for managing of sound. See the [https://bbs.archlinux.org/viewtopic.php?id=124513 forum thread] for more information.}}<br />
<br />
{{Tip|The default sink can be referred as {{ic|@DEFAULT_SINK@}} in commands, for example: {{ic|$ pactl set-sink-volume @DEFAULT_SINK@ +5%}}.}}<br />
<br />
== Set the default output sink profile ==<br />
<br />
Sometimes PulseAudio neglects to load the desired profile on start (e.g. a profile for having [[#Independent analog and digital outputs on the same card]]). To change the default profile, append the following to {{ic|default.pa}}:<br />
<br />
{{hc|/etc/pulse/default.pa|...<br />
set-card-profile <symbolic-name> <profilename>}}<br />
<br />
{{Note|<br />
You could also use {{ic|<cardindex>}} instead of {{ic|<symbolic-name>}}, but using {{ic|<symbolic-name>}} ensures referencing the correct device. {{ic|<cardindex>}} is dynamic, and changes when a new device is plugged in.<br />
}}<br />
<br />
Find {{ic|<symbolic-name>}} by running {{ic|pacmd list-cards}}:<br />
<br />
{{bc|$ pacmd list-cards<br />
3 card(s) available.<br />
index: 0<br />
name: <alsa_card.pci-0000_01_00.1><br />
driver: <module-alsa-card.c><br />
owner module: 6<br />
(...)<br />
<br />
index: 1<br />
name: <alsa_card.usb-Sony_Interactive_Entertainment_Wireless_Controller-00><br />
driver: <module-alsa-card.c><br />
owner module: 7<br />
(...)<br />
<br />
index: 2<br />
name: <alsa_card.pci-0000_00_14.2><br />
driver: <module-alsa-card.c><br />
owner module: 8<br />
(...)}}<br />
<br />
In this case, I want to use the device with index number 2, so {{ic|<symbolic-name>}} should be {{ic|alsa_card.pci-0000_00_14.2}}.<br />
<br />
To find {{ic|<profilename>}}, set the desired profile manually, then run {{ic|pacmd list-cards | grep 'active profile'}}:<br />
<br />
{{bc|<nowiki>$ pacmd list-cards | grep 'active profile'</nowiki><br />
active profile: <off><br />
active profile: <off><br />
active profile: <output:analog-stereo+output:iec958-stereo+input:analog-stereo>}}<br />
<br />
In this case, {{ic|default.pa}} should now be changed to this:<br />
{{hc|/etc/pulse/default.pa|...<br />
set-card-profile alsa_card.pci-0000_00_14.2 output:analog-stereo+output:iec958-stereo+input:analog-stereo}}<br />
<br />
You can test your configuration by running {{ic|pactl set-card-profile <symbolic-name> <profilename>}}.<br />
<br />
== Independent analog and digital outputs on the same card ==<br />
{{Out of date|{{ic|/usr/share/pulseaudio/alsa-mixer/paths}} has been replaced by {{ic|/usr/share/alsa-card-profile/mixer/paths}}|section=Having both speakers and headphones plugged in and switching in software on-the-fly}}<br />
Sound cards may have both analog and digital (iec958) outputs. Pulseaudio does not generate combined profiles by default, you can choose either digital or analog profiles.<br />
<br />
The easiest way to make both outputs available is to add a combined profile to the end of default profile configuration file:<br />
<br />
{{hc|/usr/share/pulseaudio/alsa-mixer/profile-sets/default.conf|...<br />
<nowiki><br />
# Profile must be a '+' separated list of relevant mappings configured above<br />
[Profile output:analog-stereo+output:iec958-stereo+input:analog-stereo]<br />
# Human readable description<br />
description = Analog and digital stereo output and analog stereo intput<br />
output-mappings = analog-stereo iec958-stereo<br />
input-mappings = analog-stereo<br />
</nowiki>}}<br />
<br />
This way a defined profile is added to the end of the list of available profiles.<br />
<br />
Although this works, pulseaudio has a nasty habit of falling back to auto-generated profiles, so you may eventually need to set your card back to the combined profile. The best way to overcome this is by writing a custom config with disabled {{ic|auto-profiles}}. Copy {{ic|default.conf}} to {{ic|custom-profile.conf}}, and edit it to suit your needs (this example is for stereo output/input):<br />
<br />
{{hc|/usr/share/pulseaudio/alsa-mixer/profile-sets/custom-profile.conf|<br />
<nowiki><br />
[General]<br />
auto-profiles = no # disable profile auto-generation<br />
# Leave only relevant mappings:<br />
[Mapping analog-stereo]<br />
device-strings = front:%f<br />
channel-map = left,right<br />
paths-output = analog-output analog-output-lineout analog-output-speaker analog-output-headphones analog-output-headphones-2<br />
paths-input = analog-input-front-mic analog-input-rear-mic analog-input-internal-mic analog-input-dock-mic analog-input analog-input-mic analog-input-linein analog-input-aux analog-input-video analog-input-tvtuner analog-input-fm analog-input-mic-line analog-input-headphone-mic analog-input-headset-mic<br />
priority = 15<br />
<br />
[Mapping iec958-stereo]<br />
device-strings = iec958:%f<br />
channel-map = left,right<br />
paths-input = iec958-stereo-input<br />
paths-output = iec958-stereo-output<br />
priority = 5<br />
<br />
[Profile output:analog-stereo+output:iec958-stereo+input:analog-stereo]<br />
description = Analog and digital stereo output and analog stereo intput<br />
output-mappings = analog-stereo iec958-stereo<br />
input-mappings = analog-stereo<br />
skip-probe=yes # since you know what your sound card has, there is no need for checking which sinks are available<br />
</nowiki>}}<br />
<br />
Now that you have your custom profile you need to tell pulseaudio to use it. This can be done by defining an [[Udev#About udev rules|udev rule]]:<br />
<br />
First get relevant information about your sound card:<br />
<br />
{{bc|$ pactl list cards<br />
<nowiki><br />
Card #0<br />
Name: alsa_card.pci-0000_00_1b.0<br />
--- snip ----<br />
Properties:<br />
--- snip ---<br />
device.vendor.id = "8086" # This is a 'vendor' attribute for udev rule<br />
device.product.id = "1c20" # This is a 'device' attribute for udev rule</nowiki>}}<br />
<br />
Now create a config file:<br />
<br />
{{hc|/usr/lib/udev/rules.d/91-pulseaudio-custom.rules|<br />
<nowiki><br />
SUBSYSTEM!="sound", GOTO="pulseaudio_end"<br />
ACTION!="change", GOTO="pulseaudio_end"<br />
KERNEL!="card*", GOTO="pulseaudio_end"<br />
<br />
SUBSYSTEMS=="pci", ATTRS{vendor}=="0x8086", ATTRS{device}=="0x1c20", ENV{PULSE_PROFILE_SET}="custom-profile.conf"<br />
<br />
LABEL="pulseaudio_end"<br />
</nowiki>}}<br />
<br />
Now tell udev to reload sound subsystem {{ic|udevadm trigger -ssound}} (as the root user) and restart pulseaudio. Your sound card should now use only the defined profile and have both analog and digital outputs available.<br />
<br />
== Simultaneous HDMI and analog output ==<br />
PulseAudio allows for simultaneous output to multiple sources. In this example, some applications are configured to use HDMI while others are configured to use analog. Multiple applications are able to receive audio at the same time.<br />
{{bc|$ aplay -l<br />
**** List of PLAYBACK Hardware Devices ****<br />
card 0: Intel [HDA Intel], device 0: ALC889A Analog [ALC889A Analog]<br />
Subdevices: 0/1<br />
Subdevice #0: subdevice #0<br />
card 0: Intel [HDA Intel], device 1: ALC889A Digital [ALC889A Digital]<br />
Subdevices: 1/1<br />
Subdevice #0: subdevice #0<br />
card 0: Intel [HDA Intel], device 3: HDMI 0 [HDMI 0]<br />
Subdevices: 0/1<br />
Subdevice #0: subdevice #0}}<br />
<br />
Or by using the the {{ic|pacmd}} command: <br />
<br />
{{hc|<nowiki>$ pacmd list-sinks | grep -e 'name:' -e 'alsa.device ' -e 'alsa.subdevice '</nowiki>|<nowiki><br />
name: <alsa_output.pci-0000_00_1b.0.analog-stereo><br />
alsa.subdevice = "0"<br />
alsa.device = "0"</nowiki>}}<br />
<br />
The key to a configuration like this is to understand that whatever is selected in pavucontrol under ''Configuration > Internal Audio'' is the default device. Load ''pavucontrol > Configuration'' and select HDMI as the profile. <br />
<br />
To setup the analog device as a secondary source, add the following to the {{ic|/etc/pulse/default.pa}} configuration at the beginning, before any other modules are loaded: <br />
<br />
### Load analog device<br />
load-module module-alsa-sink device=hw:0,0<br />
load-module module-combine-sink sink_name=combined<br />
set-default-sink combined<br />
<br />
Restart PulseAudio, run ''pavucontrol'' and select the "Output Devices" tab. Three settings should be displayed:<br />
# Internal Audio Digital Stereo (HDMI)<br />
# Internal Audio<br />
# Simultaneous output to Internal Audio Digital Stereo (HDMI), Internal Audio<br />
<br />
Now start a program that will use PulseAudio such as MPlayer, VLC, mpd, etc. and switch to the "Playback" tab. A drop-down list should be available for the running program to select one of the three sources.<br />
<br />
Also see [https://bbs.archlinux.org/viewtopic.php?id=118026 this thread] for a variation on this theme and [https://www.freedesktop.org/wiki/Software/PulseAudio/FAQ#Can_I_use_PulseAudio_to_playback_music_on_two_sound_cards_simultaneously.3F PulseAudio FAQ].<br />
<br />
==HDMI output configuration==<br />
As outlined in https://download.nvidia.com/XFree86/gpu-hdmi-audio-document/index.html#_issues_in_pulseaudio unless the HDMI port is the first<br />
output, PulseAudio will not be able to have any audio when using certain graphics cards with HDMI audio support. This is because of a bug in PulseAudio where it will only select the first HDMI output on a device. A work around posted further down is to first find which HDMI output is working by using the aplay utility from ALSA.<br />
<br />
The original title for this section indicated the problem is specific to nVidia cards. As seen in [https://bbs.archlinux.org/viewtopic.php?id=133222 this forum thread] other cards are affected as well. The rest of the section will use an nVidia card as a case-study but the solution should carry over for people using other affected cards.<br />
<br />
===Finding HDMI output===<br />
Then find the working output by listing the available cards<br />
# aplay -l<br />
<br />
sample output:<br />
**** List of PLAYBACK Hardware Devices ****<br />
card 0: NVidia [HDA NVidia], device 0: ALC1200 Analog [ALC1200 Analog]<br />
Subdevices: 1/1<br />
Subdevice #0: subdevice #0<br />
card 0: NVidia [HDA NVidia], device 3: ALC1200 Digital [ALC1200 Digital]<br />
Subdevices: 1/1<br />
Subdevice #0: subdevice #0<br />
card 1: NVidia_1 [HDA NVidia], device 3: HDMI 0 [HDMI 0]<br />
Subdevices: 1/1<br />
Subdevice #0: subdevice #0<br />
card 1: NVidia_1 [HDA NVidia], device 7: HDMI 0 [HDMI 0]<br />
Subdevices: 0/1<br />
Subdevice #0: subdevice #0<br />
card 1: NVidia_1 [HDA NVidia], device 8: HDMI 0 [HDMI 0]<br />
Subdevices: 1/1<br />
Subdevice #0: subdevice #0<br />
card 1: NVidia_1 [HDA NVidia], device 9: HDMI 0 [HDMI 0]<br />
Subdevices: 1/1<br />
Subdevice #0: subdevice #0<br />
<br />
In case your HDMI port is wired to the NVIDIA card, but aplay does not detect an NVIDIA audio card, follow [[NVIDIA/Troubleshooting#No audio over HDMI]].<br />
<br />
===Testing for the correct card===<br />
Now a list of the detected cards is known, users will need to test for which one is outputting to the TV/monitor<br />
# aplay -D plughw:1,3 /usr/share/sounds/alsa/Front_Right.wav<br />
<br />
where 1 is the card and 3 is the device substitute in the values listed from the previous section. If there is no audio, then try substituting a different device (on my card I had to use card 1 device 7)<br />
<br />
===Manually configuring PulseAudio to detect the Nvidia HDMI===<br />
Having identified which HDMI device is working, PulseAudio can be forced to use it via an edit to {{ic|/etc/pulse/default.pa}}:<br />
# load-module module-alsa-sink device=hw:1,7<br />
<br />
where the 1 is the card and the 7 is the device found to work in the previous section<br />
<br />
restart pulse audio<br />
$ pulseaudio -k<br />
$ pulseaudio --start<br />
<br />
open the sound settings manager, make sure that under the hardware tab the graphics cards HDMI audio is set to "Digital Stereo (HDMI) Output" (My graphics card audio is called "GF100 High Definition Audio Controller").<br />
<br />
Then, open the output tab. There should now be two HDMI outputs for the graphics card. Test which one works by selecting one of them, and then using a program to play audio. For example, use VLC to play a movie, and if it does not work, then select the other.<br />
<br />
=== Automatically switch audio to HDMI ===<br />
<br />
Create a script to switch to the desired audio profile if an HDMI cable is plugged in:<br />
<br />
{{hc|/usr/local/bin/hdmi_sound_toggle.sh|2=<nowiki><br />
#!/bin/bash<br />
<br />
export PATH=/usr/bin<br />
<br />
USER_NAME=$(who | awk -v vt=tty$(fgconsole) '$0 ~ vt {print $1}')<br />
USER_ID=$(id -u "$USER_NAME")<br />
CARD_PATH="/sys/class/drm/card0/"<br />
AUDIO_OUTPUT="analog-surround-40"<br />
PULSE_SERVER="unix:/run/user/"$USER_ID"/pulse/native"<br />
<br />
for OUTPUT in $(cd "$CARD_PATH" && echo card*); do<br />
OUT_STATUS=$(<"$CARD_PATH"/"$OUTPUT"/status)<br />
if [[ $OUT_STATUS == connected ]]<br />
then<br />
echo $OUTPUT connected<br />
case "$OUTPUT" in<br />
"card0-HDMI-A-1")<br />
AUDIO_OUTPUT="hdmi-stereo" # Digital Stereo (HDMI 1)<br />
;;<br />
"card0-HDMI-A-2")<br />
AUDIO_OUTPUT="hdmi-stereo-extra1" # Digital Stereo (HDMI 2)<br />
;;<br />
esac<br />
fi<br />
done<br />
echo selecting output $AUDIO_OUTPUT<br />
sudo -u "$USER_NAME" pactl --server "$PULSE_SERVER" set-card-profile 0 output:$AUDIO_OUTPUT+input:analog-stereo<br />
</nowiki>}}<br />
<br />
Make the script executable:<br />
<br />
chmod +x /usr/local/bin/hdmi_sound_toggle.sh<br />
<br />
Create a [[udev]] rule to run this script when the status of the HDMI change:<br />
<br />
{{hc|/etc/udev/rules.d/99-hdmi_sound.rules|2=<br />
KERNEL=="card0", SUBSYSTEM=="drm", ACTION=="change", RUN+="/usr/local/bin/hdmi_sound_toggle.sh"<br />
}}<br />
<br />
To make the change effective don't forget to reload the udev rules:<br />
udevadm control --reload-rules<br />
<br />
A reboot might be required.<br />
<br />
==Surround sound systems==<br />
Many people have a surround sound card, but have speakers for just two channels, so PulseAudio cannot really default to a surround sound setup. To enable all of the channels, edit {{ic|/etc/pulse/daemon.conf}}: uncomment the default-sample-channels line (i.e. remove the semicolon from the beginning of the line) and set the value to '''6'''. For a ''5.1'' setup, or '''8''' for a ''7.1'' setup etc.<br />
# Default<br />
default-sample-channels=2<br />
# For 5.1<br />
default-sample-channels=6<br />
# For 7.1<br />
default-sample-channels=8<br />
<br />
If your channels are not correclty mapped or the volume controls for the individual channels do not work as expected in pavucontrol, and you have a HDMI and an analog soundcard, then try to add the following line to {{ic|/etc/pulse/default.pa}}<br />
<br />
load-module module-combine channels=6 channel_map=front-left,front-right,rear-left,rear-right,front-center,lfe<br />
<br />
Note that this example is for a 5.1 setup.<br />
<br />
After doing the edit, restart PulseAudio.<br />
<br />
=== Splitting front/rear ===<br />
<br />
Connect speakers to front analog output and headphones to rear output. It would be useful to split front/rear to separate sinks. Add to {{ic|/etc/pulse/default.pa}}:<br />
<br />
load-module module-remap-sink sink_name=speakers sink_properties="device.description='Speakers'" remix=no master=alsa_output.pci-0000_05_00.0.analog-surround-40 channels=2 master_channel_map=front-left,front-right channel_map=front-left,front-right<br />
load-module module-remap-sink sink_name=headphones sink_properties="device.description='Headphones'" remix=no master=alsa_output.pci-0000_05_00.0.analog-surround-40 channels=2 master_channel_map=rear-left,rear-right channel_map=front-left,front-right<br />
Make sure to replace alsa_output.pci-0000_05_00.0.analog-surround-40 with the sound card name shown in 'pacmd list-sinks'.<br />
Now you have 2 additional sinks which can be used separately. You can choose 'sink_name' freely, as long as there is no sink with that name already. The 'remix' parameter controls whether the audio should be down-/upmixed to match the channels in the sink.<br />
<br />
{{Tip|If pulseaudio fails with {{ic|master sink not found}}, comment out the remapping lines, start PulseAudio and verify your card output is set to the one you specified (e.g. analog surround 4.0). Alternatively, try using a [[#Set the default output source|sink index]]{{Broken section link}} instead of a sink name.}}<br />
<br />
===Splitting 7.1 into 5.1+2.0===<br />
<br />
Similar to the example above, you can also split a 7.1 configuration into 5.1 surround and stereo output devices.<br />
Set your card to 7.1 mode, then add the following lines to {{ic|/etc/pulse/default.pa}}:<br />
load-module module-remap-sink sink_name=Surround sink_properties="device.description='Surround'" remix=no master=alsa_output.pci-0000_00_14.2.analog-surround-71 channels=6 master_channel_map=front-left,front-right,rear-left,rear-right,front-center,lfe channel_map=front-left,front-right,rear-left,rear-right,front-center,lfe<br />
load-module module-remap-sink sink_name=Stereo sink_properties="device.description='Stereo'" remix=no master=alsa_output.pci-0000_00_14.2.analog-surround-71 channels=2 master_channel_map=side-left,side-right channel_map=front-left,front-right<br />
<br />
Make sure to replace alsa_output.pci-0000_00_14.2 with your sound card name, get it by running 'pacmd list-sinks'.<br />
This configuration will use the front/rear/center+lfe (green/black/orange) jacks for the 5.1 sink and the side (grey) jack for the stereo sink.<br />
It will also downmix any audio to stereo for the stereo sink, but will not touch the 5.1 output.<br />
<br />
{{Tip|If pulseaudio fails with {{ic|master sink not found}}, comment out the remapping lines, start PulseAudio and verify your card output is set to analog surround 7.1. Alternatively, try using a [[#Set the default output source|sink index]]{{Broken section link}} instead of a sink name.}}<br />
<br />
===Disabling LFE remixing===<br />
By default, PulseAudio remixes the number of channels to the default-sample-channels and since version 7 it also remixes the LFE channel. If you wish to disable LFE remixing, uncomment the line:<br />
<br />
; enable-lfe-remixing = yes<br />
<br />
and replace yes with no:<br />
<br />
enable-lfe-remixing = no<br />
<br />
then restart Pulseaudio.<br />
<br />
===Binaural Headphones===<br />
{{AUR|ladspa-bs2b}} provides a plugin to simulate surround sound on stereo headphones. To use it, find your headphones with:<br />
{{hc|<nowiki>$ pacmd list-sinks | grep -e 'name:'</nowiki>|<br />
name: <alsa_output.pci-0000_00_1b.0.iec958-ac3-surround-51><br />
name: <alsa_output.pci-0000_00_1b.0.iec958-ac3-surround-51.equalizer><br />
name: <bluez_sink.00_1F_82_28_93_51><br />
}}<br />
Load the plugin (''new'' sink_name is up to you, master=''headphone's sink name''):<br />
pacmd load-module module-ladspa-sink sink_name=binaural master=bluez_sink.00_1F_82_28_93_51 plugin=bs2b label=bs2b control=700,4.5<br />
Use {{Pkg|pavucontrol}} to transfer streams to the new sink, or:<br />
pactl move-sink-input $INPUTID $BINAURALSINKNAME<br />
<br />
==PulseAudio over network==<br />
One of PulseAudio's unique features is its ability to stream audio from clients over TCP to a server running the PulseAudio daemon reliably within a LAN. Ensure that client and server systems agree on the time (i.e., use NTP), or audio streams may be choppy or may not work at all. For a more detailed guide visit the [https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Network/ Official PulseAudio Documentation]<br />
<br />
Enable the TCP module on the server(the computer that actually outputs sound), edit {{ic|/etc/pulse/default.pa}} to add or uncomment:<br />
load-module module-native-protocol-tcp<br />
<br />
Or you can use the {{ic|paprefs}} gui application (root is not required):<br />
Go to Network Access -> Enable network access to local sound devices<br />
<br />
To make sure module-native-protocol-tcp is loaded on the server, you can use:<br />
pacmd list-modules | grep module-native-protocol-tcp<br />
<br />
It is a requirement that both the client and server share the same cookie. Ensure that the clients and server share the same cookie file found under {{ic|~/.config/pulse/cookie}}. It does not matter whose cookie file you use (the server or a client's), just that the server and client(s) share the same one.<br />
<br />
If it is undesirable to copy the cookie file from clients, anonymous clients can access the server by passing {{ic|auth-anonymous}} to {{ic|module-native-protocol-tcp}} on the server (again in {{ic|/etc/pulse/default.pa}}):<br />
<br />
load-module module-native-protocol-tcp auth-anonymous=1<br />
<br />
It is also possible to authenticate based on client IP address:<br />
<br />
load-module module-native-protocol-tcp auth-ip-acl=127.0.0.1;192.168.0.0/24<br />
<br />
Change the LAN IP subnet to match that of those clients you wish to have access to the server.<br />
<br />
===Selecting the Server===<br />
For a single shell or command you can set the environment variable {{ic|$PULSE_SERVER}} to the host name or IP address of the desired PulseAudio server.<br />
$ export PULSE_SERVER=<i>server-hostname-or-ip</i> && mplayer test.mp3<br />
Alternatively you can create or modify {{ic|~/.pulse/client.conf}} or {{ic|/etc/pulse/client.conf}} to set a default-server persistently.<br />
default-server = <i>server-hostname-or-ip</i><br />
<br />
===Selecting the Server with Zeroconf===<br />
{{note|This section is known to be unreliable for some people.}}<br />
For the remote PulseAudio server to appear in the PulseAudio Device Chooser ({{ic|pasystray}}), load the appropriate zeroconf modules, and enable the [[Avahi]] [[daemon]]. On both machines, the client and server, [[install]] {{Pkg|pulseaudio-zeroconf}} then [[start]] and [[enable]] {{ic|avahi-daemon.service}}.<br />
<br />
On the server, add {{ic|load-module module-zeroconf-publish}} to {{ic|/etc/pulse/default.pa}}. <br />
On the client, add {{ic|load-module module-zeroconf-discover}} to {{ic|/etc/pulse/default.pa}}. Now redirect any stream or complete audio output to the remote PulseAudio server by selecting the appropriate sink.<br />
<br />
If you have issues with the remote syncs appearing on the client, try restarting the Avahi daemon on the server to rebroadcast the available interfaces.<br />
<br />
Run the graphical PulseAudio Volume Control {{ic|pavucontrol}}. Under the '''Output Devices''' tab, you should see the local and remote output devices. Under the '''Playback''' tab, to the left of the "X" Mute Audio button, you should see a box containing the name of an output device. That box is ''actually a button'', which will display a drop-down radio-button list of the available output devices, with one output device selected. Selecting an output device from the list will allow the audio stream to be switched to the PulseAudio server associated with that output device. This control is not at all obvious until you have used it, and is especially useful with a remote Headless sound server.<br />
<br />
Similarly, under the '''Input Devices''' tab, local and remote input devices will be seen. And under the '''Recording''' tab, there will be a box, to the left of the "X" Mute Audio button, with the name of an input device which is actually a button which will display a drop-down radio-button list of available input devices.<br />
<br />
Run {{ic|pavucontrol}} on the local or remote host associated with the audio stream to be directed. For instance, run {{ic|pavucontrol}} on the remote host to direct the remote audio output to the local host. Run {{ic|pavucontrol}} on the local host to direct the local audio output to some remote host.<br />
<br />
Setting up simultaneous inputs or outputs is a different thing. Search about "monitor" and "module-combine-sink" for that.<br />
===Switching the PulseAudio server used by local X clients===<br />
To switch between servers on the client from within X, the {{ic|pax11publish}} command can be used. For example, to switch from the default server to the server at hostname foo:<br />
$ pax11publish -e -S foo<br />
<br />
Or to switch back to the default:<br />
$ pax11publish -e -r<br />
<br />
Instead of telling the PulseAudio server to stream audio (as described above), this will edit PulseAudio variables on the X11 root window, which will instruct the PulseAudio client libraries to connect to a PulseAudio server other than {{ic|localhost}}. As such, the programs will no longer interact with the local {{ic|pulseaudio}} process, which can then be [[stop]]ped. Programs such as {{ic|pactl}}, {{ic|pacmd}} or {{ic|pavucontrol}} will need to also run with the appropriate {{ic|PULSE_SERVER}} environment/X variable to control the remote PulseAudio server.<br />
<br />
Note that for the switch to become apparent, the programs using Pulse must be restarted, or their PulseAudio client library otherwise reinitialized (completely stopping and restarting playback may be enough). To make this setting permanent, edit {{ic|default-server}} in {{ic|~/.config/pulse/client.conf}} or {{ic|/etc/pulse/client.conf}}.<br />
<br />
===When everything else seems to fail===<br />
The following is a quick fix and NOT a permanent solution<br />
<br />
On the server:<br />
$ paprefs <br />
Go to Network Access -> Enable access to local sound devices (Also check both 'Allow discover' and 'Don't require authentication').<br />
<br />
On the client:<br />
$ export PULSE_SERVER=server.ip && mplayer test.mp3<br />
<br />
==ALSA monitor source==<br />
To be able to record from a monitor source (a.k.a. "What-U-Hear", "Stereo Mix"), use {{ic|pactl list}} to find out the name of the source in PulseAudio (e.g. {{ic|alsa_output.pci-0000_00_1b.0.analog-stereo.monitor}}). Then add lines like the following to {{ic|/etc/asound.conf}} or {{ic|~/.asoundrc}}:<br />
pcm.pulse_monitor {<br />
type pulse<br />
device alsa_output.pci-0000_00_1b.0.analog-stereo.monitor<br />
}<br />
<br />
ctl.pulse_monitor {<br />
type pulse<br />
device alsa_output.pci-0000_00_1b.0.analog-stereo.monitor<br />
}<br />
<br />
Now you can select {{ic|pulse_monitor}} as a recording source.<br />
<br />
Alternatively, you can use pavucontrol to do this: make sure you have set up the display to "All input devices", then select "Monitor of [your sound card]" as the recording source.<br />
<br />
== Monitor specific output ==<br />
<br />
It is possible to monitor a specific output, for example to stream audio from a music player into a VOIP application.<br />
Simply create a null output device:<br />
<br />
pactl load-module module-null-sink sink_name=<name><br />
<br />
In Pulseaudio Volume Control (pavucontrol), under the "Playback" tab, change the output of an application to <name>, and in the recording tab change the input of an application to "Monitor of <name>". Audio will now be outputted from one application into the other.<br />
<br />
==PulseAudio through JACK==<br />
The [[JACK Audio Connection Kit]] is popular for audio work, and is widely supported by Linux audio applications. It fills a similar niche as PulseAudio, but with more of an emphasis on professional audio work. It can offer lower latency audio monitoring along with greater control of input and output of multi-i/o sound devices.<br />
<br />
===The KXStudio method===<br />
This configuration requires the {{Pkg|jack2}} package.<br />
<br />
JACK now has native features for bridging between ALSA, PulseAudio, and JACK. This will allow you to simultaneously have JACK and PulseAudio running with both outputting at the same time, with no config editing or terminal commands required.<br />
<br />
If you have {{Pkg|qjackctl}} installed, make sure that it is not running (it might be running minified in the system tray). Also ensure that no {{ic|jackd}} process is running (use {{ic|ps xw | grep jackd}} in a terminal to check).<br />
<br />
Install {{Pkg|cadence}}, as well as {{Pkg|pulseaudio-jack}}. Once installed and started, JACK bridge configuration is found in the bottom right of the window. The ALSA audio bridge should be set to ALSA -> PulseAudio -> JACK, and the PulseAudio bridge should be enabled. Make sure in {{ic|pavucontrol}} that all output devices besides Jack sink are muted, and all input devices besides Jack input are muted. Start JACK using the Force Restart button, and if it starts successfully PulseAudio programs should begin outputting to JACK.<br />
<br />
===The manual sink configuration method===<br />
This configuration provides a method of allowing JACK and PulseAudio to run at the same time and output to each other. It uses manual configuration of the systems that bridge between JACK and PulseAudio. This configuration has no reliance on scripts or commands and is entirely based in configuration.<br />
<br />
This configuration only works with jack2. To use this configuration, just install the {{Pkg|pulseaudio-jack}} package. {{ic|/etc/pulse/default.pa}} is already configured to load the modules in {{Pkg|pulseaudio-jack}} if they are present. If you want to be sure, open the file and look for the line:<br />
load-module module-jackdbus-detect ''options''<br />
Where {{ic|''options''}} can be any options supported by this module, usually {{ic|1=channels=2}}.<br />
<br />
As described on the [https://github.com/jackaudio/jackaudio.github.com/wiki/JackDbusPackaging Jack-DBUS Packaging] page:<br />
<br />
''Server auto-launching is implemented as D-Bus call that auto-activates JACK D-Bus service, in case it is not already started, and starts the JACK server. Correct interaction with PulseAudio is done using a D-Bus based audio card "acquire/release" mechanism. When JACK server starts, it asks this D-Bus service to acquire the audio card and PulseAudio will unconditionally release it. When JACK server stops, it releases the audio card that can be grabbed again by PulseAudio.''<br />
<br />
{{ic|module-jackdbus-detect.so}} dynamically loads and unloads module-jack-sink and module-jack-source when jackdbus is started and stopped.<br />
<br />
If PulseAudio sound does not work, check with {{ic|pavucontrol}} to see if the relevant programs appear in the playback tab. If not, add the following to {{ic|~/.asoundrc}} or {{ic|/etc/asound.conf}} to redirect ALSA to PulseAudio:<br />
<br />
pcm.pulse {<br />
type pulse<br />
}<br />
<br />
ctl.pulse {<br />
type pulse<br />
}<br />
<br />
pcm.!default {<br />
type pulse<br />
}<br />
ctl.!default {<br />
type pulse<br />
}<br />
<br />
If it still does not work, check with {{ic|pavucontrol}} in the playback tab and make sure the relevant programs are outputting to PulseAudio JACK Sink instead of your audio card (which JACK has control of, so it will not work). Also ensure that in the JACK graph the PulseAudio JACK Source is connected to the system audio output.<br />
<br />
===The shell script method===<br />
This method allows JACK and PulseAudio to output at the same time. It mostly relies on shell scripts that are automatically run by QJackCTL to manage aspects of how the JACK sinks and PulseAudio behave.<br />
<br />
The basic idea is that killing PulseAudio is a bad idea because it may crash any apps using PulseAudio and disrupt any audio playing.<br />
<br />
The flow of how this setup works:<br />
<br />
# PulseAudio releases the sound card<br />
# JACK grabs sound card and starts up<br />
# script redirects PulseAudio to JACK<br />
# manually send PulseAudio apps to JACK output (pavucontrol may come in helpful for this)<br />
# use JACK programs etc<br />
# via script, stop redirecting PulseAudio to JACK<br />
# stop JACK and release sound card<br />
# PulseAudio grabs sound card and reroutes audio to it directly<br />
<br />
With QJackCTL, set up these scripts:<br />
<br />
{{ic|pulse-jack-pre-start.sh}} set it up as the execute script on startup script<br />
#!/bin/bash<br />
pacmd suspend true<br />
<br />
{{ic|pulse-jack-post-start.sh}} set this one up as execute script after startup<br />
#!/bin/bash<br />
pactl load-module module-jack-sink channels=2<br />
pactl load-module module-jack-source channels=2<br />
pacmd set-default-sink jack_out<br />
pacmd set-default-source jack_in<br />
<br />
{{ic|pulse-jack-pre-stop.sh}} "execute script on shutdown"<br />
#!/bin/bash<br />
SINKID=$(LANG=C pactl list | grep -B 1 "Name: module-jack-sink" | grep Module | sed 's/[^0-9]//g')<br />
SOURCEID=$(LANG=C pactl list | grep -B 1 "Name: module-jack-source" | grep Module | sed 's/[^0-9]//g')<br />
pactl unload-module $SINKID<br />
pactl unload-module $SOURCEID<br />
sleep 5<br />
<br />
{{ic|pulse-jack-post-stop.sh}} "execute script after shutdown"<br />
#!/bin/bash<br />
pacmd suspend false<br />
<br />
===The PulseAudio kill method=== <br />
This method relies on shell scripts to automatically kill PulseAudio when JACK is started, and automatically restart it when JACK is stopped. This will result in lower CPU usage than having both running, but can cause errors in already running PulseAudio application and does not allow simultaneous output of both.<br />
<br />
Using the settings listed above, use QjackCtl to execute a script upon startup and shutdown to load/unload PulseAudio. Part of the reason users may wish to do this is that the above changes disable PulseAudio's automatic hardware detection modules. This particular setup is for using PulseAudio in an exclusive fashion with JACK, though the scripts could be modified to unload and load an alternate non-JACK setup, but killing and starting PulseAudio while programs might be using it would become problematic.<br />
<br />
{{Note|padevchooser in the following example is deprecated. It is replaced by pasystray}}<br />
<br />
The following example could be used and modified as necessary as a startup script that daemonizes PulseAudio and loads the ''padevchooser'' program (optional, needs to be built from AUR) called {{ic|jack_startup}}: <br />
#!/bin/bash <br />
#Load PulseAudio and PulseAudio Device Chooser<br />
pulseaudio -D<br />
padevchooser&<br />
<br />
as well as a shutdown script to kill PulseAudio and the Pulse Audio Device Chooser, as another example called {{ic|jack_shutdown}} also in the home directory: <br />
#!/bin/bash <br />
#Kill PulseAudio and PulseAudio Device Chooser <br />
pulseaudio --kill <br />
killall padevchooser <br />
<br />
Both scripts need to be made executable: <br />
chmod +x jack_startup jack_shutdown<br />
<br />
then with QjackCtl loaded, click on the ''Setup'' button and then the ''Options'' tab and tick both "Execute Script after Startup:" And "Execute Script on Shutdown:" and put either use the ... button or type the path to the scripts (assuming the scripts are in the home directory) {{ic|~/jack_startup}} and {{ic|~/jack_shutdown}} making sure to save the changes.<br />
<br />
==PulseAudio through JACK issues==<br />
<br />
===When JACK is started Firefox, Chrome and other apps stop playing video and audio===<br />
<br />
Firefox/Chrome/etc. is using PulseAudio soundcard sink instead of the JACK sink. Open {{ic|pavucontrol}} and on the ''Playback'' tab switch all audiostreams from something like "Built-in Audio Analog Stereo" to something like "Jack sink (PulseAudio JACK Sink)".<br />
<br />
===After I start JACK the sound from PulseAudio becomes distorted===<br />
<br />
In QjackCtl click ''Setup'' and on the ''Settings'' tab, ''Parameters'' subtab untick "Realtime". In addition, tweaking Sample Rate, Frames/Period and Period/Buffer may help. Look for latency in the bottom right corner, as you still want minimal latency for audio production. Also, I think Sample Rate should match one of the rates supported by your audio interface ({{ic|cat /proc/asound/cardN/codec\#M}} and look for {{ic|rates}}, there could be multiple occurrences).<br />
<br />
==PulseAudio through OSS==<br />
Add the following to {{ic|/etc/pulse/default.pa}}:<br />
load-module module-oss<br />
<br />
Then start PulseAudio as usual, making sure that sinks and sources are defined for OSS devices.<br />
<br />
==PulseAudio from within a chroot ==<br />
Since a chroot sets up an alternative root for the running/jailing of applications, PulseAudio must be installed within the chroot itself ({{ic|pacman -S pulseaudio}} within the chroot environment).<br />
<br />
PulseAudio, if not set up to connect to any specific server (this can be done in {{ic|/etc/pulse/client.conf}}, through the PULSE_SERVER environment variable, or through publishing to the local X11 properties using module-x11-publish), will attempt to connect to the local pulse server, failing which it will spawn a new pulse server. Each pulse server has a unique ID based on the machine-id value in {{ic|/var/lib/dbus}}. To allow for chrooted apps to access the pulse server, the following directories must be mounted within the chroot:-<br />
/run<br />
/var/lib/dbus<br />
/tmp<br />
~/config/.pulse<br />
<br />
{{ic|/dev/shm}} should also be mounted for efficiency and good performance. Note that mounting /home would normally also allow sharing of the {{ic|~/.pulse}} folder.<br />
<br />
PulseAudio selects the path to the socket via XDG_RUNTIME_DIR, so be sure to drag it along when you chroot as a normal user using [[sudo]] (see [[Sudo#Environment variables]]).<br />
<br />
==Disabling automatic spawning of PulseAudio server==<br />
Some users may prefer to manually start the PulseAudio server before running certain programs and then stop the PulseAudio server when they are finished. A simple way to accomplish this is to edit {{ic|~/.config/pulse/client.conf}} or {{ic|/etc/pulse/client.conf}} and change {{ic|1=autospawn = yes}} to {{ic|1=autospawn=no}}. Make sure the line is uncommented as well.<br />
{{hc|~/.config/pulse/client.conf #or /etc/pulse/client.conf|<nowiki><br />
autospawn=no<br />
</nowiki>}}<br />
Now you can manually start the pulseaudio server with<br />
$ pulseaudio --start<br />
and stop it with<br />
$ pulseaudio --kill<br />
<br />
This setting is also respected by the default pulseaudio dektop session startup script {{ic|start-pulseaudio-x11}} which is executed from {{ic|/etc/xdg/autostart/pulseaudio.desktop}}.<br />
<br />
==Disabling pulseaudio daemon altogether==<br />
To disable the pulseaudio daemon completely, and thereby preventing it from starting, one can add {{ic|1=daemon-binary=/bin/true}} to the configuration file.<br />
{{hc|~/.config/pulse/client.conf #or /etc/pulse/client.conf|2=daemon-binary=/bin/true}}<br />
<br />
==Remap stereo to mono==<br />
Remap a stereo input-sink to a mono sink by creating a virtual sink. It would be useful if you only have one speaker. Add to {{ic|/etc/pulse/default.pa}}:<br />
<br />
load-module module-remap-sink master=alsa_output.pci-0000_00_1f.5.analog-stereo sink_name=mono sink_properties="device.description='Mono'" channels=2 channel_map=mono,mono<br />
# Optional: Select new remap as default<br />
set-default-sink mono<br />
<br />
(replace alsa_output.pci-0000_00_1f.5.analog-stereo in the sound card name shown from {{ic|pacmd list-sinks}})<br />
<br />
Switch player between virtual mono sink and real stereo sink.<br />
<br />
==Remap left or right to mono==<br />
Particularly useful in the case an audio stream has different content in the left and right channels, such as Japanese television broadcasts with bilingual audio.<br />
<br />
# For Japanese bilingual TV<br />
load-module module-remap-sink sink_name=Left-to-Mono sink_properties="device.description='Left to Mono (5.1 AC3 on ALC892 Digital)'" master=alsa_output.pci-0000_00_1b.0.iec958-ac3-surround-51 channels=2 master_channel_map=mono,mono channel_map=front-left,rear-left<br />
load-module module-remap-sink sink_name=Right-to-Mono sink_properties="device.description='Right to Mono (5.1 AC3 on ALC892 Digital)'" master=alsa_output.pci-0000_00_1b.0.iec958-ac3-surround-51 channels=2 master_channel_map=mono,mono channel_map=front-right,rear-right<br />
<br />
Replace {{ic|alsa_output.pci-0000_00_1b.0.iec958-ac3-surround-51}} (5.1 AC3 on ALC892 Digital) with your own card ({{ic|pacmd list-sinks}}).<br />
<br />
{{Note|<br />
* ''master_channel_map'' is a list of outputs to be remapped to.<br />
* ''channel_map'' is a list of inputs to be remapped from.<br />
* A stereo card will not have to specify as many channels, eg. {{ic|1=channels=1 master_channel_map=mono channel_map=right}}}}<br />
<br />
==Remap for broadcasting software==<br />
If you do not want to capture sound from the application you need to create Remap sink:<br />
<br />
### Create Remap sink<br />
load-module module-remap-sink sink_name=Remap_sink master=SINK_NAME channels=2 remix=no<br />
set-default-sink Remap_sink <br />
<br />
{{Note|1=Replace {{ic|SINK_NAME}} with the real name of the master sink {{ic|pacmd list-sinks}}.}}<br />
<br />
Then restart PulseAudio daemon:<br />
<br />
$ pulseaudio -k<br />
$ pulseaudio --start<br />
<br />
Now you need set the {{ic|Remap_sink}} as the default sound source in broadcast software<br />
<br />
{{Note|1=Use environment variable {{ic|1=PULSE_SINK=SINK_NAME}} for applications, sound that does not need to be captured.}}<br />
<br />
==Swap left/right channels==<br />
This is the same as "reverse stereo", where the left and right channels are to be swapped.<br />
<br />
First, identify the card you want its channels swapped:<br />
$ cat /proc/asound/cards<br />
and use the name string for the device you wish to use (the one in square brackets, e.g. [Intel]).<br />
<br />
Edit {{ic|/etc/pulse/default.pa}} and comment out module-hal-detect and module-detect lines.<br />
<br />
Search for the commented-out line that starts "#load-module module-alsa-sink", uncomment it and change it to<br />
<br />
load-module module-alsa-sink device=hw:"device_name" channel_map=right,left<br />
Restart the pulseaudio deamon by running<br />
pulseaudio -k; pulseaudio -D<br />
<br />
[https://www.freedesktop.org/wiki/Software/PulseAudio/FAQ/#index34h3 Pulseaudio FAQ: How can I reverse my left and right speaker channels?]<br />
<br />
===Using default.pa===<br />
Another approach to swapping channels is suggested in [https://superuser.com/a/144252/161008]:<br />
<br />
{{hc|~/.config/pulse/default.pa|2=<br />
#!/usr/bin/pulseaudio -nF<br />
<br />
.include /etc/pulse/default.pa<br />
<br />
load-module module-remap-sink sink_name=reverse-stereo master=0 channels=2 master_channel_map=front-right,front-left channel_map=front-left,front-right<br />
set-default-sink reverse-stereo<br />
}}<br />
<br />
===Using PulseEffects===<br />
<br />
# Install {{Pkg|pulseeffects}}:<br />
# Using the "Stereo Tools" application on the left of the PulseEffects UI<br />
# Navigate to the "Stereo Matrix" page<br />
# Under "Mode" select "LR > RL (Stereo Flip Channels)"<br />
<br />
The way PulseEffects works is it becomes your primary output device. You'll then need to use the PulseAudio Volume Control {{Pkg|pavucontrol}} tool to set the PulseEffects output to the device you want.<br />
<br />
== PulseAudio as a minimal unintrusive dumb pipe to ALSA ==<br />
Some people do not want to run PulseAudio all the time for various reasons. This example will turn the full fledged audio server into an unobstrusive dumb pipe to ALSA devices that automatically starts '''and''' stops itself when done, allowing applications that requires PulseAudio to fully function while not touching any ALSA setting nor setting itself as the default ALSA device.<br />
<br />
This configuration tells native PA clients to autospawn the daemon when they need it, then the daemon is configured to autoexit as soon as all clients have disconnected. The daemon itself uses a plain simple static configuration that uses your configured {{ic|pcm.!default}} ALSA devices and nothing more. No replacement of ALSA's default, no playing with mixer levels, nothing but record/playback. Also make sure {{Pkg|pulseaudio-alsa}} is '''not''' installed so standard ALSA clients don't default to pulse. Since {{Pkg|pulseaudio-alsa}} contains only a configuration file {{ic|/etc/asound.conf}}, if it's installed as dependency, one could simply comment all contents in {{ic|/etc/asound.conf}}. {{ic|alsamixer}} functions properly as well as any other ALSA clients. Also make sure common frameworks like Xine, Gstreamer and Phonon are configured to use ALSA: by default if they detect PulseAudio is installed they will try to use it before ALSA.<br />
<br />
{{hc|/etc/pulse/daemon.conf|<nowiki><br />
# Replace these with the proper values<br />
exit-idle-time = 0 # Exit as soon as unneeded<br />
flat-volumes = yes # Prevent messing with the master volume<br />
</nowiki>}}<br />
<br />
{{hc|/etc/pulse/client.conf|<nowiki><br />
# Replace these with the proper values<br />
<br />
# Applications that uses PulseAudio *directly* will spawn it,<br />
# use it, and pulse will exit itself when done because of the<br />
# exit-idle-time setting in daemon.conf<br />
autospawn = yes<br />
</nowiki>}}<br />
<br />
{{hc|/etc/pulse/default.pa|<nowiki><br />
# Replace the *entire* content of this file with these few lines and<br />
# read the comments<br />
<br />
.fail<br />
# Set tsched=0 here if you experience glitchy playback. This will<br />
# revert back to interrupt-based scheduling and should fix it.<br />
#<br />
# Replace the device= part if you want pulse to use a specific device<br />
# such as "dmix" and "dsnoop" so it doesn't lock an hw: device.<br />
<br />
# INPUT/RECORD<br />
load-module module-alsa-source device="default" tsched=1<br />
<br />
# OUTPUT/PLAYBACK<br />
load-module module-alsa-sink device="default" tsched=1 <br />
<br />
# Accept clients -- very important<br />
load-module module-native-protocol-unix<br />
<br />
.nofail<br />
.ifexists module-x11-publish.so<br />
# Publish to X11 so the clients know how to connect to Pulse. Will<br />
# clear itself on unload.<br />
load-module module-x11-publish<br />
.endif<br />
</nowiki>}}<br />
<br />
== Having both speakers and headphones plugged in and switching in software on-the-fly ==<br />
{{Out of date|{{ic|/usr/share/pulseaudio/alsa-mixer/paths}} has been replaced by {{ic|/usr/share/alsa-card-profile/mixer/paths}}|section=Having both speakers and headphones plugged in and switching in software on-the-fly}}<br />
By design, Pulseaudio automatically turns off Line Out when headphones are plugged in and uses Headphone slider instead. You can observe this behavior in {{ic|alsamixer}}. What we want is to have Headphone and Line Out sliders working separately and at the same time. This is extremely useful if you want to remap Realtek's jacks to have, say, Rear Green for headphones and Blue for speakers (with the help of {{ic|hdajackretask}} from {{Pkg|alsa-tools}}).<br />
<br />
To achieve this, you should directly edit Pulseaudio mixer's configuration.<br />
<br />
1. We tell pulseaudio that headphones are always plugged in. Edit:<br />
<br />
{{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-output-lineout.conf}}<br />
<br />
Find:<br />
{{bc|<nowiki><br />
[Jack Headphone]<br />
state.plugged = no<br />
state.unplugged = unknown<br />
</nowiki>}}<br />
<br />
Change {{ic|no}} to {{ic|yes}}<br />
<br />
2. By default, Line Out's volume controlled only by Master, and not by Line Out slider itself. We want to merge Line Out with Master.<br />
<br />
Add this snippet to the end of the file:<br />
<br />
{{bc|<nowiki><br />
[Element Line Out]<br />
switch = mute<br />
volume = merge<br />
</nowiki>}}<br />
<br />
3. We need to completely cut off Line Out when we use headphones. Edit:<br />
<br />
{{ic|/usr/share/pulseaudio/alsa-mixer/paths/analog-output-headphones.conf}}<br />
<br />
Add this snippet to the end of the file:<br />
<br />
{{bc|<nowiki><br />
[Element Line Out]<br />
switch = off<br />
volume = off<br />
</nowiki>}}<br />
<br />
{{Note|On some systems you might need to use {{ic|[Element Front]}} instead of {{ic|[Element Line Out]}}.}}<br />
<br />
4. Like Pulseaudio, Alsa itself cuts off speakers when headphones are plugged in. Open {{ic|alsamixer}} (in case of Realtek HDA {{ic|alsamixer -c0}}) and change {{ic|Auto-Mute mode}} to {{ic|disabled}}. <br />
<br />
5. Restart Pulseaudio<br />
<br />
{{bc|<nowiki><br />
$ pulseaudio -k<br />
$ pulseaudio --start<br />
</nowiki>}}<br />
<br />
Now you have two separate ports on the same sink in pulseaudio. They mute each other, so you can switch to headphones and this will mute Line Out, and vice versa.<br />
To switch between ports you can use Gnome or Plasma sound mixer, or install appropriate desktop extension.<br />
<br />
== Allowing multiple users to use PulseAudio at the same time ==<br />
<br />
It is sometimes desirable to run some programs as another user on the same desktop of the primary user in order to isolate the software. However, PulseAudio will not accept by default connections by the secondary users, since a PulseAudio daemon is already running for the primary user. However, a PulseAudio UNIX socket can be created in order to accept connections from other users to the main PulseAudio daemon run by the primary user.<br />
<br />
First, edit {{ic|/etc/pulse/default.pa}} or {{ic|~/.config/pulse/default.pa}} and add a directive for the unix socket to be created:<br />
<br />
{{hc|1=~/.config/pulse/default.pa|2=load-module module-native-protocol-unix auth-anonymous=1 socket=/tmp/pulse-socket}}<br />
<br />
Afterwards, set PulseAudio as a client to the UNIX socket just created in the secondary user:<br />
<br />
{{hc|/home/''secondaryuser''/.config/pulse/client.conf|2=default-server = unix:/tmp/pulse-socket}}<br />
<br />
Now, after restarting the PulseAudio daemon, applications running as the secondary user should be able to play sound through the main PulseAudio daemon running as the primary user without problems.<br />
<br />
== Mixing additional audio into the microphone's audio ==<br />
<br />
Using a setup of null sinks and loopbacks you can mix arbitrary applications' audio output into your microphone's audio, for example to play sound effects or music on voice chat applications.<br />
<br />
The setup suggested here will also play your sound effects back to you and use [https://www.freedesktop.org/wiki/Software/PulseAudio/Documentation/User/Modules/#module-echo-cancel PulseAudio echo cancellation] to prevent the effects from feeding back into your microphone.<br />
Despite this, using headphones instead of loudspeakers is probably a good idea.<br />
<br />
=== Overview of the targeted PulseAudio configuration ===<br />
<br />
Symbology: {{ic|(Application)}}, {{ic|<nowiki>{Audio source}</nowiki>}}, {{ic|[Audio sink]}}, {{ic|<nowiki>{m} = Monitor of audio sink</nowiki>}}<br />
<br />
{Microphone}<br />
|| Input<br />
{mic_ec} -------------> [vsink_fx_mic]{m} ------------> (Voice chat)<br />
Loopback ^ |<br />
Loopback| Output|<br />
| |<br />
Output | Loopback v<br />
(Soundboard) ---------> [vsink_fx]{m} ----------------> [spk_ec]<br />
||<br />
[Speakers]<br />
; {mic_ec}, [spk_ec]<br />
: Echo cancellation "clones" of the microphone and speakers<br />
; [vsink_fx]<br />
: Virtual sink into which the sound effects are played<br />
; [vsink_fx_mic]<br />
: Virtual sink where the microphone and the sound effects are mixed together<br />
<br />
=== Applications configuration ===<br />
<br />
The applications providing the sound effects must<br />
* Output to "vsink_fx"<br />
<br />
All other applications, including the voice chat, must<br />
* Record audio from "Monitor of vsink_fx_mic"<br />
* Output to "spk_ec"<br />
Accordingly, these devices will be set as default source and default sink; ultimately, controlling which application uses which audio source/sink can be done in the {{ic|pavucontrol}} graphical PulseAudio volume control panel.<br />
<br />
'''No application whatsoever''' must record from, or output to, the "real" microphone or speakers, as this would bypass the echo cancellation.<br />
<br />
Any echo cancellation or other audio processing provided by the voice chat application should be disabled – PulseAudio is doing this already, and as the application is not aware of the sound effects being played on the speakers, it will likely be ineffective in filtering them from the microphone anyway.<br />
<br />
=== Setup steps ===<br />
<br />
As of August 2020 there is {{AUR|pulse-autoconf}}, a PulseAudio server dynamic configuration daemon that supports this setup with its 'EchoCancellationWithSourcesMix' preset and that dynamically reacts to e.g. a headset being plugged in our unplugged.<br />
<br />
If {{AUR|pulse-autoconf}} does not work out for your use case, here is the manual way:<br />
<br />
# Connect your microphone and headphones and make sure PulseAudio is configured correctly for their use, for example in the "Configuration" tab in {{ic|pavucontrol}}<br />
# ''First time only:''<br />
## Save the template script below to an executable file of your choice<br />
## Find the {{ic|name:}}s of your microphone and headphones with {{ic|pacmd list-sources}} and {{ic|pacmd list-sinks}}, respectively<br />
## In the script, replace the values of "microphone" and "speakers" with the names of your microphone/headphones<br />
# Run the script<br />
# Run your voice chat application and, in {{ic|pavucontrol}}, make it record audio from "Monitor of vsink_fx_mic" and output audio to "spk_ec"<br />
# Run your sound effects application(s) and, in {{ic|pavucontrol}}, make them play to "vsink_fx"<br />
<br />
As for applications that can play sound effects, {{AUR|castersoundboard-git}} has been found to work quite well.<br />
It however needs to be closed and re-opened when PulseAudio is restarted.<br />
<br />
=== Teardown ===<br />
<br />
The changes that the script makes to the running PulseAudio server are not permanent and will be lost when PulseAudio terminates.<br />
<br />
To ditch the custom configuration, just restart PulseAudio, e.g. with {{ic|systemctl --user stop pulseaudio.service}}. (PulseAudio is socket-activated and will automatically start on demand.)<br />
<br />
=== Template script ===<br />
<br />
#!/bin/bash<br />
<br />
microphone="alsa_input.pci-0000_00_1b.0.analog-stereo"<br />
speakers="alsa_output.pci-0000_00_1b.0.analog-stereo"<br />
<br />
echo "Setting up echo cancellation"<br />
pactl load-module module-echo-cancel use_master_format=1 aec_method=webrtc \<br />
aec_args="analog_gain_control=0\\ digital_gain_control=1\\ experimental_agc=1\\ noise_suppression=1\\ voice_detection=1\\ extended_filter=1" \<br />
source_master="$microphone" source_name=mic_ec source_properties=device.description=mic_ec \<br />
sink_master="$speakers" sink_name=spk_ec sink_properties=device.description=spk_ec<br />
<br />
echo "Creating virtual output devices"<br />
pactl load-module module-null-sink sink_name=vsink_fx sink_properties=device.description=vsink_fx<br />
pactl load-module module-null-sink sink_name=vsink_fx_mic sink_properties=device.description=vsink_fx_mic<br />
<br />
echo "Creating loopbacks"<br />
pactl load-module module-loopback latency_msec=30 adjust_time=3 source=mic_ec sink=vsink_fx_mic<br />
pactl load-module module-loopback latency_msec=30 adjust_time=3 source=vsink_fx.monitor sink=vsink_fx_mic<br />
pactl load-module module-loopback latency_msec=30 adjust_time=3 source=vsink_fx.monitor sink=spk_ec<br />
<br />
echo "Setting default devices"<br />
pactl set-default-source vsink_fx_mic.monitor<br />
pactl set-default-sink spk_ec<br />
<br />
This script has been inspired by https://askubuntu.com/a/915064 , for more in-depth information also see that post's author's [https://github.com/toadjaune/pulseaudio-config pulseaudio-config GitHub repository].<br />
<br />
== Invert phase of one audio channel ==<br />
<br />
This is useful for compensating when one of your speakers is wired with the wrong polarity. To test if this is needed, see [https://www.audiocheck.net/audiotests_polaritycheck.php].<br />
<br />
Adapted from a more general example of [https://askubuntu.com/a/194345 Assigning a LADSPA filter to a single audio channel].<br />
Requires {{Pkg|swh-plugins}}.<br />
<br />
#!/bin/bash<br />
master=alsa_output.pci-0000_07_00.0.analog-stereo<br />
pacmd load-module module-ladspa-sink sink_name=ladspa_out sink_master=$master plugin=inv_1429 label=inv<br />
pacmd load-module module-remap-sink sink_name=remapR master=ladspa_out channels=1 master_channel_map=front-right channel_map=front-right<br />
pacmd load-module module-remap-sink sink_name=remapL master=$master channels=1 master_channel_map=front-left channel_map=front-left<br />
pacmd load-module module-combine-sink sink_name=invert sink_properties=device.description='"Invert\ phase"' slaves=remapL,remapR channels=2<br />
<br />
== Renaming devices ==<br />
<br />
Sound devices will sometimes have confusing names assigned to them by default. Names like ''"CM106 Like Sound Device"'' are not very descriptive.<br />
This can be easily fixed and it works for both Pulseaudio sources and sinks.<br />
<br />
The easiest method is to add the following lines to the end of the {{ic|/etc/pulse/default.pa}} file.<br />
<br />
To update a source name:<br />
<br />
update-source-proplist <DEVICE_NAME> device.description="<NEW_NAME>"<br />
<br />
And to update a sink name:<br />
<br />
update-sink-proplist <DEVICE_NAME> device.description="<NEW_NAME>"<br />
<br />
The device name can be queried using the command {{ic|pacmd list-sources {{!}} grep name:}} for sources, or {{ic|pacmd list-sinks {{!}} grep name:}} for sinks.<br />
<br />
This configuration can also be persisted on a per-user basis and be written to {{ic|~/.config/pulse/default.pa}} like so:<br />
<br />
#!/usr/bin/pulseaudio -nF<br />
<br />
## Include defaults<br />
.include /etc/pulse/default.pa<br />
<br />
## Rename devices<br />
update-source-proplist <DEVICE_NAME> device.description="<NEW_NAME>"<br />
<br />
The default Pulseaudio config needs to be included, otherwise the daemon will not start.</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Convert_FLAC_to_MP3&diff=502807Convert FLAC to MP32017-12-16T14:53:22Z<p>Wooptoo: Added audiotools to Packages</p>
<hr />
<div>[[Category:Multimedia]]<br />
[[ja:Flac を Mp3 に変換]]<br />
{{Related articles start}}<br />
{{Related|Convert any Movie to DVD Video}}<br />
{{Related articles end}}<br />
<br />
This article presents ways of doing audio transcoding between FLAC and MP3 audio files using command line/scripted tools, and suggest a few graphical utilities to do the same and more.<br />
<br />
== Scripts ==<br />
<br />
In these two examples, FLAC files in current directory are encoded by the LAME MP3 encoder. Both scripts pass the ID3 tags from the FLAC files to the resulting MP3 files, and encode to MP3 V0. V0 results in a variable bitrate usually between 220-260 kbps. The audio of a V0 file is transparent, meaning one cannot tell the difference between the lossy file and the original source (compact disc/lossless), but yet the file size is significantly reduced. For more information on LAME switches/settings such as V0, visit the [http://wiki.hydrogenaudio.org/index.php?title=LAME Hydrogenaudio LAME Wiki].<br />
<br />
The original {{ic|.flac}} files are not modified and the resulting {{ic|.mp3}}s will be in the same directory. All files with extensions not matching {{ic|*.flac}} in the working directory ({{ic|.nfo}}, images, {{ic|.sfv}}, etc.) are ignored.<br />
<br />
=== With FFmpeg ===<br />
<br />
Chances are, your system already has [[FFmpeg]] installed, which brings in the {{Pkg|flac}} and {{Pkg|lame}} packages. FFmpeg has all the encoding and decoding facilities built in to do the job.<br />
<br />
{{bc|<br />
#!/bin/bash<br />
<br />
for a in ./*.flac; do<br />
ffmpeg -i "$a" -qscale:a 0 "${a[@]/%flac/mp3}"<br />
done<br />
}}<br />
<br />
==== Parallel version ====<br />
<br />
Since LAME is a single-threaded encoder, conversion can be accelerated by encoding multiple files concurrently on multiple cores. To do this, [[install]] the {{Pkg|parallel}} package, and run:<br />
<br />
parallel ffmpeg -i {} -qscale:a 0 {.}.mp3 ::: ./*.flac<br />
<br />
==== Makefile for incremental recursive transcoding ====<br />
<br />
{{Warning|1=Makefiles do not handle spaces correctly, see [https://bbs.archlinux.org/viewtopic.php?pid=1506405#p1506405] for details.}}<br />
<br />
Besides transcoding in parallel with {{ic|make -j$(nproc)}}, this has the added benefit of not regenerating transcoded files that already exist on subsequent executions:<br />
<br />
{{bc|<nowiki><br />
SOURCE_DIR := flacdir<br />
XCODE_MP3_DIR := mp3dir<br />
# NOTE: see lame -v option for quality meaning<br />
XCODE_MP3_QUALITY := 0<br />
<br />
# Find .flac sources and determine corresponding targets<br />
flac_srcs := $(shell find $(SOURCE_DIR) -type f -name '*.flac')<br />
flac_2_mp3_tgts := $(patsubst $(SOURCE_DIR)/%.flac, $(XCODE_MP3_DIR)/%.mp3, \<br />
$(flac_srcs))<br />
<br />
.PHONY: all mp3 flac_2_mp3<br />
<br />
all: mp3 <br />
<br />
mp3: flac_2_mp3<br />
<br />
flac_2_mp3: $(flac_2_mp3_tgts)<br />
<br />
$(XCODE_MP3_DIR)/%.mp3: $(SOURCE_DIR)/%.flac<br />
@echo "converting -> $@"<br />
@mkdir -p "$(@D)"<br />
@ffmpeg -v error -i "$<" -codec:a libmp3lame \<br />
-q:a $(XCODE_MP3_QUALITY) "$(@)"<br />
</nowiki>}}<br />
<br />
=== Without FFmpeg ===<br />
<br />
If for some reason FFmpeg is not installed and you do not want to install it, you still need to have {{Pkg|flac}} and {{Pkg|lame}} installed. Here, the tagging process is more explicit using the metadata utility that comes with {{Pkg|flac}} and passing the information to {{Pkg|lame}}. The process duration will slightly increase since FLACs must first be decoded to WAVE and then fed into the MP3 encoder.<br />
<br />
{{bc|<nowiki><br />
#!/bin/bash<br />
<br />
for a in ./*.flac; do<br />
# give output correct extension<br />
OUTF="${a[@]/%flac/mp3}"<br />
<br />
# get the tags<br />
ARTIST=$(metaflac "$a" --show-tag=ARTIST | sed s/.*=//g)<br />
TITLE=$(metaflac "$a" --show-tag=TITLE | sed s/.*=//g)<br />
ALBUM=$(metaflac "$a" --show-tag=ALBUM | sed s/.*=//g)<br />
GENRE=$(metaflac "$a" --show-tag=GENRE | sed s/.*=//g)<br />
TRACKNUMBER=$(metaflac "$a" --show-tag=TRACKNUMBER | sed s/.*=//g)<br />
DATE=$(metaflac "$a" --show-tag=DATE | sed s/.*=//g)<br />
<br />
# stream flac into the lame encoder<br />
flac -c -d "$a" | lame -V0 --add-id3v2 --pad-id3v2 --ignore-tag-errors \<br />
--ta "$ARTIST" --tt "$TITLE" --tl "$ALBUM" --tg "${GENRE:-12}" \<br />
--tn "${TRACKNUMBER:-0}" --ty "$DATE" - "$OUTF"<br />
done<br />
</nowiki>}}<br />
<br />
=== Recursively ===<br />
A useful extension of the above scripts is to let them recurse into all subdirectories of the working directory. To do so, replace the first line ({{ic|for .... do}}) with:<br />
<br />
find -type f -name "*.flac" -print0 | while read -d $'\0' a; do<br />
<br />
=== Usage ===<br />
<br />
For ease of use, add the script to your {{ic|PATH}}. Open up a terminal, {{ic|cd}} to the directory of FLAC files that you wish to convert, and invoke {{ic|flac2mp3}} (or whatever you named the script). You will see the verbose decoding/encoding process in the terminal which may take a few moments. Done! At this point, it is trivial to {{ic|mv *.mp3}} all your new MP3s wherever you wish.<br />
<br />
=== Packages ===<br />
<br />
* {{AUR|whatmp3}} - A small Python script that accepts a list of directories containing FLAC files as arguments and converts them to MP3 with the specified options.<br />
* {{AUR|flac2all}} - Audio converter of FLAC to either Ogg Vorbis or MP3 retaining all tags and metadata.<br />
* {{AUR|flac2mp3-bash}} - Bash script to convert Flac to Mp3 easily.<br />
* {{AUR|audiotools}} - Transcode between different formats and keep tags with {{ic|track2track}}, can encode from CDDA with {{ic|cdda2track}}, has an optional Ncurses GUI.<br />
<br />
== Graphical applications ==<br />
<br />
*{{App|SoundConverter|A dedicated audio transcoding utility built for the [[GNOME]] desktop and relying on GStreamer. It can make use of [http://library.gnome.org/users/gnome-audio-profiles/stable/gnome-audio-profiles-usage.html.en GNOME Audio Profiles] and features multithreaded conversions. It can also extract the audio from videos.|http://soundconverter.org/|{{Pkg|soundconverter}}}}<br />
*{{App|soundKonverter|A Qt graphical frontend to various audio manipulation programs. Features conversion, ripping and other audio manipulation functionalities.|https://github.com/HessiJames/soundkonverter/wiki|{{Pkg|soundkonverter}}}}<br />
*{{App|[[Wikipedia:FFmpeg#Projects_using_FFmpeg|WinFF]]|A GUI for the powerful multimedia converter FFmpeg. Features dedicated profiles for audio transcoding.|http://code.google.com/p/winff/|{{Pkg|winff}}}}<br />
<br />
== See also ==<br />
<br />
* https://www.xiph.org/flac/<br />
* [[wikipedia:FLAC]]<br />
* http://lame.sourceforge.net/<br />
* http://wiki.hydrogenaudio.org/index.php?title=Flac - More information on FLAC.</div>Wooptoohttps://wiki.archlinux.org/index.php?title=GRUB&diff=465573GRUB2017-01-16T23:51:28Z<p>Wooptoo: Clearer explanation of what's going on when chainloading Windows</p>
<hr />
<div>[[Category:Boot loaders]]<br />
[[ar:GRUB]]<br />
[[cs:GRUB]]<br />
[[de:GRUB]]<br />
[[el:GRUB]]<br />
[[es:GRUB]]<br />
[[fr:GRUB]]<br />
[[he:GRUB]]<br />
[[id:GRUB]]<br />
[[it:GRUB]]<br />
[[ja:GRUB]]<br />
[[nl:GRUB]]<br />
[[pt:GRUB]]<br />
[[ru:GRUB]]<br />
[[tr:GRUB2]]<br />
[[uk:GRUB]]<br />
[[zh-hans:GRUB]]<br />
[[zh-hant:GRUB]]<br />
{{Related articles start}}<br />
{{Related|Arch boot process}}<br />
{{Related|Boot loaders}}<br />
{{Related|Master Boot Record}}<br />
{{Related|GUID Partition Table}}<br />
{{Related|Unified Extensible Firmware Interface}}<br />
{{Related|GRUB Legacy}}<br />
{{Related|GRUB/EFI examples}}<br />
{{Related|GRUB/Tips and tricks}}<br />
{{Related|Multiboot USB drive}}<br />
{{Related articles end}}<br />
[https://www.gnu.org/software/grub/ GRUB] — not to be confused with [[GRUB Legacy]] — is the next generation of the GRand Unified Bootloader. GRUB is derived from [http://www.nongnu.org/pupa/ PUPA] which was a research project to develop the next generation of what is now GRUB Legacy. GRUB has been rewritten from scratch to clean up everything and provide modularity and portability [https://www.gnu.org/software/grub/grub-faq.html#q1].<br />
<br />
== Preface ==<br />
<br />
A ''bootloader'' is the first software program that runs when a computer starts. It is responsible for loading and transferring control to the Linux kernel. The kernel, in turn, initializes the rest of the operating system. The name ''GRUB'' officially refers to version ''2'' of the software. See [https://www.gnu.org/software/grub/]. If you are looking for the article on the legacy version, see [[GRUB Legacy]].<br />
<br />
GRUB has a few root file system-specific limitations:<br />
* [[F2FS]] is not supported<br />
<br />
If your root partition is on an unsupported file system, you must create a separate {{ic|/boot}} partition with a supported file system. In some cases, the development version of GRUB {{aur|grub-git}} has native support.<br />
<br />
== BIOS systems ==<br />
<br />
=== GUID Partition Table (GPT) specific instructions ===<br />
<br />
On a BIOS/[[GPT]] configuration a [http://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html BIOS boot partition] is required. GRUB embeds its {{ic|core.img}} into this partition.<br />
<br />
{{Note|<br />
* Before attempting this method keep in mind that not all systems will be able to support this partitioning scheme. Read more on [[GUID Partition Table#BIOS systems|GUID partition tables]].<br />
* This additional partition is only needed on a GRUB, BIOS/GPT partitioning scheme. Previously, for a GRUB, BIOS/MBR partitioning scheme, GRUB used the Post-MBR gap for the embedding the {{ic|core.img}}). GRUB for GPT, however, does not use the Post-GPT gap to conform to GPT specifications that require 1_megabyte/2048_sector disk boundaries.<br />
* For [[UEFI]] systems this extra partition is not required, since no embedding of boot sectors takes place in that case. However, UEFI systems still require an [[ESP]].<br />
}}<br />
<br />
Create a mebibyte partition ({{ic|1=+1M}} with [[fdisk]] or [[gdisk]]) on the disk with no file system and with partition type BIOS boot. Select {{ic|BIOS boot}} and partition type number {{ic|4}} for ''fdisk'', {{ic|ef02}} for ''gdisk'', and {{ic|bios_grub}} for ''parted''. This partition can be in any position order but has to be on the first 2 TiB of the disk. This partition needs to be created before GRUB installation. When the partition is ready, install the bootloader as per the instructions below.<br />
<br />
The post-GPT gap can also be used as the BIOS boot partition though it will be out of GPT alignment specification. Since the partition will not be regularly accessed performance issues can be disregarded, though some disk utilities will display a warning about it. In ''fdisk'' or ''gdisk'' create a new partition starting at sector 34 and spanning to 2047 and set the type. To have the viewable partitions begin at the base consider adding this partition last.<br />
<br />
=== Master Boot Record (MBR) specific instructions ===<br />
<br />
Usually the post-[[MBR]] gap (after the 512 byte MBR region and before the start of the first partition) in many MBR (or 'msdos' disklabel) partitioned systems is 31 KiB when DOS compatibility cylinder alignment issues are satisfied in the partition table. However a post-MBR gap of about 1 to 2 MiB is recommended to provide sufficient room for embedding GRUB's {{ic|core.img}} ({{bug|24103}}). It is advisable to use a partitioning tool that supports 1 MiB partition alignment to obtain this space as well as to satisfy other non-512 byte sector issues (which are unrelated to embedding of {{ic|core.img}}).<br />
<br />
=== Installation ===<br />
<br />
[[Install]] the {{Pkg|grub}} package. It will replace {{AUR|grub-legacy}}, where already installed.<br />
<br />
{{Note|Simply installing the package will not update the {{ic|/boot/grub/i386-pc/core.img}} file and the GRUB modules in {{ic|/boot/grub/i386-pc}}. You need to update them manually using {{ic|grub-install}} as explained below.}}<br />
<br />
==== Install boot files ====<br />
<br />
There are 4 ways to install GRUB boot files in BIOS booting:<br />
<br />
* [[#Install to disk|Install to disk]] (recommended)<br />
* [[#Install to external USB stick|Install to external USB stick]] (for recovery)<br />
* [[#Install to partition or partitionless disk|Install to partition or partitionless disk]] (not recommended)<br />
* [[#Generate core.img alone|Generate core.img alone]] (safest method, but requires another BIOS bootloader like [[Syslinux]] to be installed to chainload {{ic|/boot/grub/i386-pc/core.img}})<br />
<br />
{{Note|See https://www.gnu.org/software/grub/manual/html_node/BIOS-installation.html for additional documentation.}}<br />
<br />
===== Install to disk =====<br />
<br />
{{Note|The method below is specific to installing GRUB to a partitioned (MBR or GPT) disk, with GRUB files installed to the current {{ic|/boot/grub}} directory and its first stage code installed to the 440-byte MBR boot code region (not to be confused with MBR partition table). To signal ''grub-install'' to install files to a different location, such as when migrating to new drives, use the {{ic|--boot-directory}} flag, such as in [[#Install to external USB stick]].}}<br />
<br />
The following commands will:<br />
* Set up GRUB in the 440-byte Master Boot Record boot code region<br />
* Populate the {{ic|/boot/grub}} directory<br />
* Generate the {{ic|/boot/grub/i386-pc/core.img}} file<br />
* Embed it in the 31 KiB (minimum size - varies depending on partition alignment) post-MBR gap in case of MBR partitioned disk<br />
* In the case of a GPT partitioned disk it will embed it in the BIOS Boot Partition, denoted by {{ic|bios_grub}} flag in parted and EF02 type code in gdisk<br />
<br />
# grub-install --target=i386-pc /dev/sd''x''<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, you can install GRUB on multiple physical disks.<br />
<br />
===== Install to external USB stick =====<br />
<br />
Assume your USB stick's first partition is FAT32 and its partition is /dev/sdy1<br />
<br />
# mkdir -p /mnt/usb<br />
# mount /dev/sdy1 /mnt/usb<br />
# grub-install --target=i386-pc --debug --boot-directory=/mnt/usb/boot /dev/sdy<br />
# grub-mkconfig -o /mnt/usb/boot/grub/grub.cfg<br />
<br />
Optionally backup configuration files of {{ic|grub.cfg}}:<br />
# mkdir -p /mnt/usb/etc/default<br />
# cp /etc/default/grub /mnt/usb/etc/default<br />
# cp -a /etc/grub.d /mnt/usb/etc<br />
<br />
# sync; umount /mnt/usb<br />
<br />
===== Install to partition or partitionless disk =====<br />
{{Warning|GRUB '''strongly discourages''' installation to a partition boot sector or a partitionless disk as GRUB Legacy or Syslinux does. This setup is prone to breakage, especially during updates, and is '''not supported''' by the Arch developers.}}<br />
<br />
To set up grub to a partition boot sector, to a partitionless disk (also called superfloppy) or to a floppy disk, run (using for example {{ic|/dev/sdaX}} as the {{ic|/boot}} partition):<br />
<br />
# chattr -i /boot/grub/i386-pc/core.img<br />
# grub-install --target=i386-pc --debug --force /dev/sdaX<br />
# chattr +i /boot/grub/i386-pc/core.img<br />
<br />
{{Note|<br />
* {{ic|/dev/sdaX}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in ''grub-install''.<br />
}}<br />
<br />
You need to use the {{ic|--force}} option to allow usage of blocklists and should not use {{ic|1=--grub-setup=/bin/true}} (which is similar to simply generating {{ic|core.img}}).<br />
<br />
{{ic|grub-install}} will give out warnings like which should give you the idea of what might go wrong with this approach:<br />
<br />
/sbin/grub-setup: warn: Attempting to install GRUB to a partitionless disk or to a partition. This is a BAD idea.<br />
/sbin/grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and their use is discouraged.<br />
<br />
Without {{ic|--force}} you may get the below error and {{ic|grub-setup}} will not setup its boot code in the partition boot sector:<br />
<br />
/sbin/grub-setup: error: will not proceed with blocklists<br />
<br />
With {{ic|--force}} you should get:<br />
<br />
Installation finished. No error reported.<br />
<br />
The reason why {{ic|grub-setup}} does not by default allow this is because in case of partition or a partitionless disk is that GRUB relies on embedded blocklists in the partition bootsector to locate the {{ic|/boot/grub/i386-pc/core.img}} file and the prefix directory {{ic|/boot/grub}}. The sector locations of {{ic|core.img}} may change whenever the file system in the partition is being altered (files copied, deleted etc.). For more info, see https://bugzilla.redhat.com/show_bug.cgi?id=728742 and https://bugzilla.redhat.com/show_bug.cgi?id=730915.<br />
<br />
The workaround for this is to set the immutable flag on {{ic|/boot/grub/i386-pc/core.img}} (using {{ic|chattr}} command as mentioned above) so that the sector locations of the {{ic|core.img}} file in the disk is not altered. The immutable flag on {{ic|/boot/grub/i386-pc/core.img}} needs to be set only if GRUB is installed to a partition boot sector or a partitionless disk, not in case of installation to MBR or simple generation of {{ic|core.img}} without embedding any bootsector (mentioned above).<br />
<br />
Unfortunately, the {{ic|grub.cfg}} file that is created will not contain the proper UUID in order to boot, even if it reports no errors. see https://bbs.archlinux.org/viewtopic.php?pid=1294604#p1294604.<br />
In order to fix this issue the following commands:<br />
<br />
# mount /dev/sdxY /mnt #Your root partition.<br />
# mount /dev/sdxZ /mnt/boot #Your boot partition (if you have one).<br />
# arch-chroot /mnt<br />
# pacman -S linux<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
===== Generate core.img alone =====<br />
<br />
To populate the {{ic|/boot/grub}} directory and generate a {{ic|/boot/grub/i386-pc/core.img}} file '''without''' embedding any GRUB bootsector code in the MBR, post-MBR region, or the partition bootsector, add {{ic|1=--grub-setup=/bin/true}} to {{ic|grub-install}}:<br />
<br />
# grub-install --target=i386-pc --grub-setup=/bin/true --debug /dev/sda<br />
<br />
{{Note|<br />
* {{ic|/dev/sda}} used for example only.<br />
* {{ic|1=--target=i386-pc}} instructs {{ic|grub-install}} to install for BIOS systems only. It is recommended to always use this option to remove ambiguity in grub-install.<br />
}}<br />
<br />
You can then chainload GRUB's {{ic|core.img}} from GRUB Legacy or syslinux as a Linux kernel or as a multiboot kernel (see also [[Syslinux#Chainloading]]).<br />
<br />
== UEFI systems ==<br />
<br />
{{Note|<br />
* It is recommended to read and understand the [[UEFI]], [[GPT]] and [[UEFI Bootloaders]] pages.<br />
* When installing to use UEFI it is important to start the install with your machine in UEFI mode. The Arch Linux install media must be UEFI bootable.<br />
}}<br />
<br />
=== Check if you have GPT and an ESP ===<br />
<br />
An [[EFI System Partition]] (ESP) is needed on every disc you want to boot using EFI. GPT is not strictly necessary, but it is highly recommended and is the only method currently supported in this article. If you are installing Arch Linux on an EFI-capable computer with an already-working operating system, like Windows 8 for example, it is very likely that you already have an ESP. To check for GPT and for an ESP, use {{ic|parted}} as root to print the partition table of the disk you want to boot from. (We are calling it {{ic|/dev/sda}}.)<br />
<br />
# parted /dev/sda print<br />
<br />
For GPT, you are looking for "Partition Table: gpt". For EFI, you are looking for a small (512 MiB or less) partition with a vfat/fat32 file system and the ''boot'' flag enabled. On it, there should be a directory named "EFI". If these criteria are met, this is your ESP. Make note of the partition number. You will need to know which one it is, so you can mount it later on while installing GRUB to it.<br />
<br />
=== Create an ESP ===<br />
<br />
If you do not have an ESP, you will need to create one. See [[EFI System Partition]]<br />
<br />
=== Installation ===<br />
<br />
{{Note|UEFI firmware are not implemented consistently by hardware manufacturers. The installation examples provided are intended to work on the widest range of UEFI systems possible. Those experiencing problems despite applying these methods are encouraged to share detailed information for their hardware-specific cases, especially where solving these problems. A [[GRUB/EFI examples]] article has been provided for such cases.}}<br />
<br />
This section assumes you are installing GRUB for x86_64 systems (x86_64-efi). For i686 systems, replace {{ic|x86_64-efi}} with {{ic|i386-efi}} where appropriate.<br />
<br />
Make sure you are in a [[bash]] shell. For example, when booting from the Arch ISO:<br />
<br />
# arch-chroot /mnt /bin/bash<br />
<br />
[[Install]] the packages {{Pkg|grub}} and {{Pkg|efibootmgr}}. ''GRUB'' is the bootloader, ''efibootmgr'' creates bootable {{ic|.efi}} stub entries used by the GRUB installation script.<br />
<br />
The following steps install the GRUB UEFI application to {{ic|''esp''/EFI/grub}}, install its modules to {{ic|/boot/grub/x86_64-efi}}, and place the bootable {{ic|grubx64.efi}} stub in {{ic|''esp''/EFI/grub}}.<br />
<br />
First, tell GRUB to use UEFI, set the boot directory and set the bootloader ID. Mount the ESP partition to e.g. {{ic|/boot}} or {{ic|/boot/efi}} and in the following change {{ic|''esp_mount''}} to that mount point (usually {{ic|/boot}}):<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp_mount'' --bootloader-id='''grub'''<br />
<br />
The {{ic|--bootloader-id}} is what appears in the boot options to identify the GRUB EFI boot option; make sure this is something you will recognize later. The install will create a directory of the same name under {{ic|''esp''/EFI/}} where the EFI binary bootloader will be placed.<br />
{{Tip|If you use {{ic|boot}} as your bootloader-id then you will have the additional ability of being able to boot from the drive in case EFI variables are reset or you move the drive to another computer. Usually you can do this by selecting the drive itself similar to how you would using BIOS. If dual booting with Windows, be aware Windows usually has a folder called boot inside the EFI folder of the EFI partition, but the only purpose this serves is to recreate the EFI boot option for Windows.}}<br />
<br />
After the above install finished the main GRUB directory is located at {{ic|/boot/grub/}}. <br />
<br />
Remember to [[#Generate the main configuration file]] after finalizing [[#Configuration]]. <br />
<br />
{{Note|<br />
* While some distributions require a {{ic|/boot/efi}} or {{ic|/boot/EFI}} directory, Arch does not.<br />
* {{ic|--efi-directory}} and {{ic|--bootloader-id}} are specific to GRUB UEFI. {{ic|--efi-directory}} specifies the mountpoint of the ESP. It replaces {{ic|--root-directory}}, which is deprecated. <br />
* You might note the absence of a <device_path> option (e.g.: {{ic|/dev/sda}}) in the {{ic|grub-install}} command. In fact any <device_path> provided will be ignored by the GRUB install script, as UEFI bootloaders do not use a MBR or partition boot sector at all.<br />
}}<br />
<br />
See [[#UEFI|UEFI troubleshooting]] in case of problems.<br />
<br />
=== Further reading ===<br />
<br />
Below is other relevant information regarding installing Arch via UEFI<br />
<br />
==== Alternative install method ====<br />
<br />
Usually, GRUB keeps all files, including configuration files, in {{ic|/boot}}, regardless of where the EFI System Partition is mounted.<br />
<br />
If you want to keep these files inside the EFI System Partition itself, add {{ic|1=--boot-directory=''esp''}} to the grub-install command:<br />
<br />
# grub-install --target=x86_64-efi --efi-directory=''esp'' --bootloader-id=grub --boot-directory=''esp'' --debug<br />
<br />
This puts all GRUB files in {{ic|''esp''/grub}}, instead of in {{ic|/boot/grub}}. When using this method, make sure you have ''grub-mkconfig'' put the configuration file in the same place:<br />
<br />
# grub-mkconfig -o ''esp''/grub/grub.cfg<br />
<br />
Configuration is otherwise the same.<br />
<br />
==== UEFI firmware workaround ====<br />
<br />
Some UEFI firmware requires that the bootable {{ic|.efi}} stub have a specific name and be placed in a specific location: {{ic|''esp''/EFI/boot/bootx64.efi}} (where {{ic|''esp''}} is the UEFI partition mountpoint). Failure to do so in such instances will result in an unbootable installation. Fortunately, this will not cause any problems with other firmware that does not require this.<br />
<br />
To do so, first create the necessary directory, and then copy across the grub {{ic|.efi}} stub, renaming it in the process:<br />
<br />
# mkdir ''esp''/EFI/boot<br />
# cp ''esp''/EFI/grub_uefi/grubx64.efi ''esp''/EFI/boot/bootx64.efi<br />
<br />
==== Create a GRUB entry in the firmware boot manager ====<br />
{{ic|grub-install}} automatically tries to create a menu entry in the boot manager. If it does not, then see [[UEFI#efibootmgr]] for instructions to use {{ic|efibootmgr}} to create a menu entry. However, the problem is likely to be that you have not booted your CD/USB in UEFI mode, as in [[UEFI#Create UEFI bootable USB from ISO]].<br />
<br />
==== GRUB standalone ====<br />
<br />
This section assumes you are creating a standalone GRUB for x86_64 systems (x86_64-efi). For i686 systems, replace {{ic|x86_64-efi}} with {{ic|i386-efi}} where appropriate.<br />
<br />
It is possible to create a {{ic|grubx64_standalone.efi}} application which has all the modules embedded in a tar archive within the UEFI application, thus removing the need for having a separate directory populated with all of the GRUB UEFI modules and other related files. This is done using the {{ic|grub-mkstandalone}} command (included in {{Pkg|grub}}) as follows:<br />
<br />
# echo 'configfile ${cmdpath}/grub.cfg' > /tmp/grub.cfg<br />
# grub-mkstandalone -d /usr/lib/grub/x86_64-efi/ -O x86_64-efi --modules="part_gpt part_msdos" --fonts="unicode" --locales="en@quot" --themes="" -o "''esp''/EFI/grub/grubx64_standalone.efi" "boot/grub/grub.cfg=/tmp/grub.cfg" -v<br />
<br />
Then copy the GRUB config file to {{ic|''esp''/EFI/grub/grub.cfg}} and create a UEFI Boot Manager entry for {{ic|''esp''/EFI/grub/grubx64_standalone.efi}} using [[UEFI#efibootmgr|efibootmgr]].<br />
<br />
{{Note|<br />
The option {{ic|1=--modules="part_gpt part_msdos"}} (with the quotes) is necessary for the {{ic|${cmdpath} }} feature to work properly.<br />
}}<br />
<br />
{{Warning|You may find that the {{ic|grub.cfg}} file is not loaded due to {{ic|${cmdpath} }} missing a slash (i.e. {{ic|(hd1,msdos2)EFI/Boot}} instead of {{ic|(hd1,msdos2)/EFI/Boot}}) and so you are dropped into a GRUB shell. If this happens determine what {{ic|${cmdpath} }} is set to ({{ic|echo ${cmdpath} }}) and then load the config file manually (e.g. {{ic|configfile (hd1,msdos2)/EFI/Boot/grub.cfg}}).}}<br />
<br />
==== Technical information ====<br />
<br />
The GRUB EFI file always expects its config file to be at {{ic|${prefix}/grub.cfg}}. However in the standalone GRUB EFI file, the {{ic|${prefix} }} is located inside a tar archive and embedded inside the standalone GRUB EFI file itself (inside the GRUB environment, it is denoted by {{ic|"(memdisk)"}}, without quotes). This tar archive contains all the files that would be stored normally at {{ic|/boot/grub}} in case of a normal GRUB EFI install.<br />
<br />
Due to this embedding of {{ic|/boot/grub}} contents inside the standalone image itself, it does not rely on actual (external) {{ic|/boot/grub}} for anything. Thus in case of standalone GRUB EFI file {{ic|1=${prefix}==(memdisk)/boot/grub}} and the standalone GRUB EFI file reads expects the config file to be at {{ic|1=${prefix}/grub.cfg==(memdisk)/boot/grub/grub.cfg}}.<br />
<br />
Hence to make sure the standalone GRUB EFI file reads the external {{ic|grub.cfg}} located in the same directory as the EFI file (inside the GRUB environment, it is denoted by {{ic|${cmdpath} }}), we create a simple {{ic|/tmp/grub.cfg}} which instructs GRUB to use {{ic|${cmdpath}/grub.cfg}} as its config ({{ic|configfile ${cmdpath}/grub.cfg}} command in {{ic|(memdisk)/boot/grub/grub.cfg}}). We then instruct grub-mkstandalone to copy this {{ic|/tmp/grub.cfg}} file to {{ic|${prefix}/grub.cfg}} (which is actually {{ic|(memdisk)/boot/grub/grub.cfg}}) using the option {{ic|1="boot/grub/grub.cfg=/tmp/grub.cfg"}}.<br />
<br />
This way, the standalone GRUB EFI file and actual {{ic|grub.cfg}} can be stored in any directory inside the EFI System Partition (as long as they are in the same directory), thus making them portable.<br />
<br />
== Generate the main configuration file ==<br />
<br />
After the installation, the main configuration file {{ic|grub.cfg}} needs to be generated. The generation process can be influenced by a variety of options in {{ic|/etc/default/grub}} and scripts in {{ic|/etc/grub.d/}}; see [[#Configuration]]. <br />
<br />
If you have not done additional configuration, the automatic generation will determine the root filesystem of the system to boot for the configuration file. For that to succeed it is important that the system is either booted or chrooted into. <br />
<br />
{{Note|Remember that {{ic|grub.cfg}} has to be re-generated after any change to {{ic|/etc/default/grub}} or files in {{ic|/etc/grub.d/}}.}}<br />
<br />
Use the ''grub-mkconfig'' tool to generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|<br />
* The default file path is {{ic|/boot/grub/grub.cfg}}, not {{ic|/boot/grub/i386-pc/grub.cfg}}. The {{Pkg|grub}} includes a sample {{ic|/boot/grub/grub.cfg}}; ensure your intended changes were written to this file.<br />
* If you are trying to run ''grub-mkconfig'' in a chroot or ''systemd-nspawn'' container, you might notice that it does not work, complaining that ''grub-probe'' cannot get the "canonical path of /dev/sdaX". In this case, try using ''arch-chroot'' as described in the [https://bbs.archlinux.org/viewtopic.php?pid&#61;1225067#p1225067 BBS post].<br />
}}<br />
<br />
By default the generation scripts automatically add menu entries for Arch Linux to any generated configuration. See [[Multiboot USB drive#Boot entries]] and [[#Dual-booting]] for custom menu entries for other systems.<br />
<br />
{{Tip|To have ''grub-mkconfig'' search for other installed systems, [[install]] {{Pkg|os-prober}}.}}<br />
<br />
== Configuration ==<br />
<br />
This section only covers editing the {{ic|/etc/default/grub}} configuration file. See [[GRUB/Tips and tricks]] for more information.<br />
<br />
Remember to always [[#Generate the main configuration file]] after making changes to {{ic|/etc/default/grub}}.<br />
<br />
=== Additional arguments ===<br />
<br />
To pass custom additional arguments to the Linux image, you can set the {{ic|GRUB_CMDLINE_LINUX}} + {{ic|GRUB_CMDLINE_LINUX_DEFAULT}} variables in {{ic|/etc/default/grub}}. The two are appended to each other and passed to kernel when generating regular boot entries. For the ''recovery'' boot entry, only {{ic|GRUB_CMDLINE_LINUX}} is used in the generation.<br />
<br />
It is not necessary to use both, but can be useful. For example, you could use {{ic|<nowiki>GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sdaX</nowiki> quiet"}} where {{ic|sda'''X'''}} is your swap partition to enable resume after hibernation. This would generate a recovery boot entry without the resume and without ''quiet'' suppressing kernel messages during a boot from that menu entry. Though, the other (regular) menu entries would have them as options.<br />
<br />
By default ''grub-mkconfig'' determines the [[UUID]] of the root filesystem for the configuration. To disable this, uncomment {{ic|1=GRUB_DISABLE_LINUX_UUID=true}}. <br />
<br />
For generating the GRUB recovery entry you also have to comment out {{ic|<nowiki>#GRUB_DISABLE_RECOVERY=true</nowiki>}} in {{ic|/etc/default/grub}}.<br />
<br />
You can also use {{ic|<nowiki>GRUB_CMDLINE_LINUX="resume=UUID=uuid-of-swap-partition"</nowiki>}}<br />
<br />
See [[Kernel parameters]] for more info.<br />
<br />
=== Dual-booting ===<br />
<br />
{{Merge|Multiboot USB drive|Same topic, substituting USB drives for SATA drives is trivial.}}<br />
<br />
The best way to add other entries is editing the {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}}. The entries in this file will be automatically added when running {{ic|grub-mkconfig}}.<br />
After adding the new lines, run:<br />
{{bc|<nowiki># grub-mkconfig -o /boot/grub/grub.cfg</nowiki>}}<br />
or, for UEFI-GPT Mode (As per [[#Alternative install method]]):<br />
{{bc|<nowiki># grub-mkconfig -o /boot/efi/EFI/GRUB/grub.cfg</nowiki>}}<br />
to generate an updated {{ic|grub.cfg}}.<br />
<br />
===== "Shutdown" menu entry =====<br />
<br />
{{bc|<nowiki>menuentry "System shutdown" {<br />
echo "System shutting down..."<br />
halt<br />
}</nowiki>}}<br />
<br />
===== "Restart" menu entry =====<br />
<br />
{{bc|<nowiki>menuentry "System restart" {<br />
echo "System rebooting..."<br />
reboot<br />
}</nowiki>}}<br />
<br />
===== GNU/Linux menu entry =====<br />
Assuming that the other distro is on partition {{ic|sda2}}:<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
set root=(hd0,2)<br />
linux /boot/vmlinuz (add other options here as required)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
Alternatively let grub search for the right partition by ''UUID'' or ''label'':<br />
<br />
{{bc|<nowiki>menuentry "Other Linux" {<br />
# assuming that UUID is 763A-9CB6<br />
search --set=root --fs-uuid 763A-9CB6<br />
<br />
# search by label OTHER_LINUX (make sure that partition label is unambiguous)<br />
#search --set=root --label OTHER_LINUX<br />
<br />
linux /boot/vmlinuz (add other options here as required, for example: root=UUID=763A-9CB6)<br />
initrd /boot/initrd.img (if the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
====== Encrypted GNU/Linux menuentry ======<br />
<br />
{{bc|<nowiki>menuentry "Other Linux (Encrypted)"{<br />
insmod luks<br />
cryptomount (hd0,2)<br />
set root=(crypto0)<br />
linux /boot/vmlinuz cryptdevice=/dev/sda2:cryptroot root=/dev/mapper/cryptroot (add more options if required)<br />
initrd /boot/initrd.img (If the other kernel uses/needs one)<br />
}</nowiki>}}<br />
<br />
===== FreeBSD menu entry =====<br />
The following three methods require that FreeBSD is installed on a single partition with UFS(v2). Assuming the nested BSD partition table is on {{ic|sda4}}:<br />
<br />
====== Loading the kernel directly ======<br />
{{bc|1=<br />
menuentry 'FreeBSD' {<br />
insmod ufs2<br />
set root='hd0,gpt4,bsd1'<br />
## or 'hd0,msdos4,bsd1', if using an IBM-PC (MS-DOS) style partition table<br />
kfreebsd /boot/kernel/kernel<br />
kfreebsd_loadenv /boot/device.hints<br />
set kFreeBSD.vfs.root.mountfrom=ufs:/dev/ada0s4a<br />
set kFreeBSD.vfs.root.mountfrom.options=rw<br />
}<br />
}}<br />
<br />
====== Chainloading the embedded boot record ======<br />
{{bc|1=<br />
menuentry 'FreeBSD' {<br />
insmod ufs2<br />
set root='hd0,gpt4,bsd1'<br />
chainloader +1<br />
}<br />
}}<br />
<br />
====== Running the traditional BSD 2nd stage loader ======<br />
{{bc|1=<br />
menuentry 'FreeBSD' {<br />
insmod ufs2<br />
set root='(hd0,4)'<br />
kfreebsd /boot/loader<br />
}<br />
}}<br />
<br />
===== Windows installed in UEFI-GPT Mode menu entry =====<br />
<br />
This mode determines where the Windows bootloader resides and chain-loads it after Grub when the meny entry is selected. The main task here is finding the EFI partition and running the bootloader from it.<br />
<br />
{{Note|This menuentry will work only in UEFI boot mode and only if the Windows bitness matches the UEFI bitness. It '''WILL NOT WORK''' in BIOS installed GRUB. See [[Dual boot with Windows#Windows UEFI vs BIOS limitations]] and [[Dual boot with Windows#Bootloader UEFI vs BIOS limitations]] for more info.}}<br />
<br />
{{bc|<nowiki>if [ "${grub_platform}" == "efi" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 UEFI-GPT" {<br />
insmod part_gpt<br />
insmod fat<br />
insmod search_fs_uuid<br />
insmod chain<br />
search --fs-uuid --set=root $hints_string $fs_uuid<br />
chainloader /EFI/Microsoft/Boot/bootmgfw.efi<br />
}<br />
fi</nowiki>}}<br />
<br />
where {{ic|$hints_string}} and {{ic|$fs_uuid}} are obtained with the following two commands. <br />
<br />
The {{ic|$fs_uuid}} command determines the UUID of the EFI partition:<br />
<br />
{{hc|1=# grub-probe --target=fs_uuid $esp/EFI/Microsoft/Boot/bootmgfw.efi|2=<br />
1ce5-7f28<br />
}}<br />
<br />
Alternatively one can run {{ic|blkid}} (as root) and read the UUID of the EFI partition from there.<br />
<br />
The {{ic|$hints_string}} command will determine the location of the EFI partition, in this case harddrive 0:<br />
<br />
{{hc|1=# grub-probe --target=hints_string $esp/EFI/Microsoft/Boot/bootmgfw.efi|2=<br />
--hint-bios=hd0,gpt1 --hint-efi=hd0,gpt1 --hint-baremetal=ahci0,gpt1<br />
}}<br />
<br />
These two commands assume the ESP Windows uses is mounted at {{ic|$esp}}. There might be case differences in the path to Windows's EFI file, what with being Windows, and all.<br />
<br />
===== Windows installed in BIOS-MBR mode =====<br />
<br />
{{Poor writing|This section does not fit into the others, should be slimmed down a bit.}}<br />
<br />
{{Note|GRUB supports booting {{ic|bootmgr}} directly and chainload of partition boot sector is no longer required to boot Windows in a BIOS-MBR setup.}}<br />
<br />
{{Warning|It is the '''system partition''' that has {{ic|/bootmgr}}, not your "real" Windows partition (usually C:). In {{ic|blkid}} output, the system partition is the one with {{ic|LABEL&#61;"SYSTEM RESERVED"}} or {{ic|LABEL&#61;"SYSTEM"}} and is only about 100 to 200 MB in size (much like the boot partition for Arch). See [[Wikipedia:System partition and boot partition]] for more info.}}<br />
<br />
Throughout this section, it is assumed your Windows partition is {{ic|/dev/sda1}}. A different partition will change every instance of hd0,msdos1. First, find the UUID of the NTFS file system of the Windows's SYSTEM PARTITION where the {{ic|bootmgr}} and its files reside. For example, if Windows {{ic|bootmgr}} exists at {{ic|/media/SYSTEM_RESERVED/bootmgr}}:<br />
<br />
For Windows Vista/7/8/8.1/10:<br />
<br />
# grub-probe --target=fs_uuid /media/SYSTEM_RESERVED/bootmgr<br />
69B235F6749E84CE<br />
<br />
# grub-probe --target=hints_string /media/SYSTEM_RESERVED/bootmgr<br />
--hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1<br />
<br />
{{Note|For Windows XP, replace {{ic|bootmgr}} with {{ic|NTLDR}} in the above commands. And note that there may not be a separate SYSTEM_RESERVED partition; just probe the file NTLDR on your Windows partition.}}<br />
<br />
Then, add the below code to {{ic|/etc/grub.d/40_custom}} or {{ic|/boot/grub/custom.cfg}} and regenerate {{ic|grub.cfg}} with {{ic|grub-mkconfig}} as explained above to boot Windows (XP, Vista, 7, 8 or 10) installed in BIOS-MBR mode:<br />
<br />
{{Note|These menuentries will work only in Legacy BIOS boot mode. It WILL NOT WORK in uefi installed grub(2). See [[Dual boot with Windows#Windows UEFI vs BIOS limitations]] and [[Dual boot with Windows#Bootloader UEFI vs BIOS limitations]].}}<br />
<br />
For Windows Vista/7/8/8.1/10:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows Vista/7/8/8.1 BIOS-MBR" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /bootmgr<br />
}<br />
fi<br />
<br />
For Windows XP:<br />
<br />
if [ "${grub_platform}" == "pc" ]; then<br />
menuentry "Microsoft Windows XP" {<br />
insmod part_msdos<br />
insmod ntfs<br />
insmod search_fs_uuid<br />
insmod ntldr <br />
search --fs-uuid --set=root --hint-bios=hd0,msdos1 --hint-efi=hd0,msdos1 --hint-baremetal=ahci0,msdos1 69B235F6749E84CE<br />
ntldr /ntldr<br />
}<br />
fi<br />
<br />
In both examples ''69B235F6749E84CE'' is the partition UUID which can be found with command ''lsblk --fs''.<br />
<br />
{{Note|In some cases, mine, I have installed GRUB before a clean Windows 8, you cannot boot Windows having an error with {{ic|\boot\bcd}} (error code {{ic|0xc000000f}}). You can fix it going to Windows Recovery Console (cmd from install disk) and executing:<br />
x:\> "bootrec.exe /fixboot" <br />
x:\> "bootrec.exe /RebuildBcd".<br />
Do '''not''' use {{ic|bootrec.exe /Fixmbr}} because it will wipe GRUB out.<br />
Or you can use Boot Repair function in Troubleshooting menu - it won't wipe out GRUB but will fix most error.<br />
Also you'd better keep plugged both target harddrive and your bootable device '''ONLY'''. Windows usually fails to repair boot information if any other devices are connected.}}<br />
<br />
{{ic|/etc/grub.d/40_custom}} can be used as a template to create {{ic|/etc/grub.d/nn_custom}}. Where {{ic|nn}} defines the precendence, indicating the order the script is executed. The order scripts are executed determine the placement in the grub boot menu.<br />
<br />
{{Note|{{ic|nn}} should be greater than 06 to ensure necessary scripts are executed first.}}<br />
<br />
=== LVM ===<br />
<br />
If you use [[LVM]] for your {{ic|/boot}}, make sure that the {{ic|lvm}} module is preloaded:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_PRELOAD_MODULES="lvm"<br />
}}<br />
<br />
=== RAID ===<br />
<br />
GRUB provides convenient handling of RAID volumes. You need to add {{ic|insmod mdraid09}} or {{ic|mdraid1x}} which allows you to address the volume natively. For example, {{ic|/dev/md0}} becomes:<br />
set root=(md/0)<br />
<br />
whereas a partitioned RAID volume (e.g. {{ic|/dev/md0p1}}) becomes:<br />
set root=(md/0,1)<br />
<br />
To install grub when using RAID1 as the {{ic|/boot}} partition (or using {{ic|/boot}} housed on a RAID1 root partition), on devices with GPT ef02/'BIOS boot partition', simply run ''grub-install'' on both of the drives, such as:<br />
# grub-install --target=i386-pc --debug /dev/sda<br />
# grub-install --target=i386-pc --debug /dev/sdb<br />
<br />
Where the RAID 1 array housing {{ic|/boot}} is housed on {{ic|/dev/sda}} and {{ic|/dev/sdb}}.<br />
<br />
{{Note|GRUB currently (Sep 2015) supports booting from [[Btrfs]] RAID 0/1/10, but ''not'' RAID 5/6. You may use [[mdadm]] for RAID 5/6, which is supported by GRUB.}}<br />
<br />
=== Multiple entries ===<br />
<br />
For tips on managing multiple GRUB entries, for example when using both {{Pkg|linux}} and {{Pkg|linux-lts}} kernels, see [[GRUB/Tips and tricks#Multiple entries]].<br />
<br />
=== Encryption ===<br />
<br />
==== Root partition ====<br />
<br />
To encrypt a root filesystem to be used with GRUB, add the {{ic|encrypt}} hook or the {{ic|sd-encrypt}} hook (if using systemd hooks) to [[mkinitcpio]]. See [[dm-crypt/System configuration#mkinitcpio]] for details, and [[Mkinitcpio#Common hooks]] for alternative encryption hooks.<br />
<br />
If using the {{ic|encrypt}} hook, add {{ic|cryptdevice}} to {{ic|/etc/default/grub}}. In the example below, the {{ic|sda2}} partition has been encrypted as {{ic|/dev/mapper/cryptroot}}:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="cryptdevice=/dev/sda2:cryptroot"<br />
}}<br />
<br />
If using the {{ic|sd-encrypt}} hook, add {{ic|luks.uuid}}:<br />
<br />
{{hc|/etc/default/grub|2=<br />
GRUB_CMDLINE_LINUX="luks.uuid=''UUID''"<br />
}}<br />
<br />
where ''UUID'' is the UUID of the LUKS-encrypted device.<br />
<br />
Be sure to [[#Generate the main configuration file]] when done.<br />
<br />
For further information about bootloader configuration for encrypted devices, see [[Dm-crypt/System configuration#Boot loader]].<br />
<br />
{{Note|If you wish to encrypt {{ic|/boot}} either as a separate partition or part of the {{ic|/}} partition, further setup is required. See [[#Boot partition]].}}<br />
<br />
{{Tip|If you are upgrading from a working GRUB Legacy configuration, check {{ic|/boot/grub/menu.lst.pacsave}} for the correct device/label to add. Look for them after the text {{ic|kernel /vmlinuz-linux}}.}}<br />
<br />
==== Boot partition ====<br />
<br />
GRUB can be set to ask for a password to open a [[LUKS]] blockdevice in order to read its configuration and load any [[initramfs]] and [[kernel]] from it. This option tries to solve the issue of having an [[Dm-crypt/Specialties#Securing_the_unencrypted_boot_partition|unencrypted boot partition]]. {{ic|/boot}} is '''not''' required to be kept in a separate partition; it may also stay under the system's root {{ic|/}} directory tree.<br />
<br />
To enable this feature encrypt the partition with {{ic|/boot}} residing on it using [[LUKS]] as normal. Then add the following option to {{ic|/etc/default/grub}}:<br />
<br />
{{hc|/etc/default/grub|output=<br />
GRUB_ENABLE_CRYPTODISK=y<br />
}}<br />
<br />
Be sure to [[#Generate the main configuration file]] while the partition containing {{ic|/boot}} is mounted. <br />
<br />
Without further changes you will be prompted twice for a passhrase: the first for GRUB to unlock the {{ic|/boot}} mount point in early boot, the second to unlock the root filesystem itself as described in [[#Root partition]]. You can use a [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|keyfile]] to avoid this.<br />
<br />
{{Note|<br />
* If you use a special keymap, a default GRUB installation will not know it. This is relevant for how to enter the passphrase to unlock the LUKS blockdevice.<br />
* In order to perform system updates involving the {{ic|/boot}} mount point, ensure that the encrypted {{ic|/boot}} is unlocked and mounted before performing an update. With a separate {{ic|/boot}} partition, this may be accomplished automatically on boot by using [[Dm-crypt/System configuration#crypttab|crypttab]] with a [[Dm-crypt/Device encryption#With a keyfile embedded in the initramfs|keyfile]].<br />
* If you experience issues getting the prompt for a password to display (errors regarding cryptouuid, cryptodisk, or "device not found"), try reinstalling grub as below appending the following to the end of your installation command:<br />
{{bc|1=# grub-install --target=x86_64-efi --efi-directory=$esp --bootloader-id=grub '''--modules="part_gpt part_msdos"'''}}}}<br />
<br />
== Using the command shell ==<br />
<br />
Since the MBR is too small to store all GRUB modules, only the menu and a few basic commands reside there. The majority of GRUB functionality remains in modules in {{ic|/boot/grub}}, which are inserted as needed. In error conditions (e.g. if the partition layout changes) GRUB may fail to boot. When this happens, a command shell may appear.<br />
<br />
GRUB offers multiple shells/prompts. If there is a problem reading the menu but the bootloader is able to find the disk, you will likely be dropped to the "normal" shell:<br />
grub><br />
<br />
If there is a more serious problem (e.g. GRUB cannot find required files), you may instead be dropped to the "rescue" shell:<br />
grub rescue><br />
<br />
The rescue shell is a restricted subset of the normal shell, offering much less functionality. If dumped to the rescue shell, first try inserting the "normal" module, then starting the "normal" shell:<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
grub rescue> insmod (hdX,Y)/boot/grub/i386-pc/normal.mod<br />
rescue:grub> normal<br />
<br />
=== Pager support ===<br />
<br />
GRUB supports pager for reading commands that provide long output (like the {{ic|help}} command). This works only in normal shell mode and not in rescue mode. To enable pager, in GRUB command shell type:<br />
sh:grub> set pager=1<br />
<br />
=== Using the command shell environment to boot operating systems ===<br />
<br />
grub><br />
<br />
The GRUB's command shell environment can be used to boot operating systems.<br />
A common scenario may be to boot Windows / Linux stored on a drive/partition via '''chainloading'''.<br />
<br />
''Chainloading'' means to load another boot-loader from the current one, ie, chain-loading.<br />
<br />
The other bootloader may be embedded at the starting of the disk(MBR) or at the starting of a partition or as an EFI file in the ESP in the case of UEFI.<br />
<br />
==== Chainloading a partition ====<br />
<br />
set root=(hdX,Y)<br />
chainloader +1<br />
boot<br />
<br />
X=0,1,2...<br />
Y=1,2,3...<br />
<br />
For example to chainload Windows stored in the first partiton of the first hard disk,<br />
<br />
set root=(hd0,1)<br />
chainloader +1<br />
boot<br />
<br />
Similarly GRUB installed to a partition can be chainloaded.<br />
<br />
==== Chainloading a disk/drive ====<br />
<br />
set root=hdX<br />
chainloader +1<br />
boot<br />
<br />
==== Chainloading Windows/Linux installed in UEFI mode ====<br />
<br />
insmod ntfs<br />
set root=(hd0,gpt4)<br />
chainloader (${root})/EFI/Microsoft/Boot/bootmgfw.efi<br />
boot<br />
<br />
''insmod ntfs'' used for loading the ntfs file system module for loading Windows.<br />
(hd0,gpt4) or /dev/sda4 is my EFI System Partition (ESP).<br />
The entry in the ''chainloader'' line specifies the path of the .efi file to be chain-loaded.<br />
<br />
==== Normal loading ====<br />
<br />
See the examples in [[#Using the rescue console]]<br />
<br />
=== Using the rescue console ===<br />
<br />
See [[#Using the command shell]] first. If unable to activate the standard shell, one possible solution is to boot using a live CD or some other rescue disk to correct configuration errors and reinstall GRUB. However, such a boot disk is not always available (nor necessary); the rescue console is surprisingly robust.<br />
<br />
The available commands in GRUB rescue include {{ic|insmod}}, {{ic|ls}}, {{ic|set}}, and {{ic|unset}}. This example uses {{ic|set}} and {{ic|insmod}}. {{ic|set}} modifies variables and {{ic|insmod}} inserts new modules to add functionality.<br />
<br />
Before starting, the user must know the location of their {{ic|/boot}} partition (be it a separate partition, or a subdirectory under their root):<br />
<br />
grub rescue> set prefix=(hdX,Y)/boot/grub<br />
<br />
where X is the physical drive number and Y is the partition number.<br />
<br />
{{Note|With a separate boot partition, omit {{ic|/boot}} from the path, (i.e. type {{ic|1=set prefix=(hdX,Y)/grub}}).}}<br />
<br />
To expand console capabilities, insert the {{ic|linux}} module:<br />
grub rescue> insmod i386-pc/linux.mod<br />
or simply<br />
grub rescue> insmod linux<br />
<br />
This introduces the {{ic|linux}} and {{ic|initrd}} commands, which should be familiar.<br />
<br />
An example, booting Arch Linux:<br />
<br />
set root=(hd0,5)<br />
linux /boot/vmlinuz-linux root=/dev/sda5<br />
initrd /boot/initramfs-linux.img<br />
boot<br />
<br />
With a separate boot partition (e.g. when using EFI), again change the lines accordingly: <br />
{{Note|Since boot is a separate partition and not part of your root partition, you must address the boot partition manually, in the same way as for the prefix variable.}}<br />
<br />
set root=(hd0,5)<br />
linux (hdX,Y)/vmlinuz-linux root=/dev/sda6<br />
initrd (hdX,Y)/initramfs-linux.img<br />
boot<br />
<br />
{{Note|If you experienced {{ic|error: premature end of file /YOUR_KERNEL_NAME}} during execution of {{ic|linux}} command, you can try {{ic|linux16}} instead.}}<br />
<br />
After successfully booting the Arch Linux installation, users can correct {{ic|grub.cfg}} as needed and then reinstall GRUB.<br />
<br />
To reinstall GRUB and fix the problem completely, changing {{ic|/dev/sda}} if needed. See [[#Installation]] for details.<br />
<br />
== Troubleshooting ==<br />
<br />
=== Intel BIOS not booting GPT ===<br />
<br />
==== MBR ====<br />
<br />
Some Intel BIOS's require at least one bootable MBR partition to be present at boot, causing GPT-partitioned boot setups to be unbootable.<br />
<br />
This can be circumvented by using (for instance) fdisk to mark one of the GPT partitions (preferably the 1007 KiB partition you have created for GRUB already) bootable in the MBR. This can be achieved, using fdisk, by the following commands: Start fdisk against the disk you are installing, for instance {{ic|fdisk /dev/sda}}, then press {{ic|a}} and select the partition you wish to mark as bootable (probably #1) by pressing the corresponding number, finally press {{ic|w}} to write the changes to the MBR.<br />
<br />
{{Note|The bootable-marking must be done in {{ic|fdisk}} or similar, not in GParted or others, as they will not set the bootable flag in the MBR.}}<br />
<br />
With cfdisk, the steps are similar, just {{ic|cfdisk /dev/sda}}, choose bootable (at the left) in the desired hard disk, and quit saving.<br />
<br />
More information is available [http://www.rodsbooks.com/gdisk/bios.html here]<br />
<br />
==== EFI path ====<br />
<br />
Some UEFI firmwares require a bootable file at a known location before they will show UEFI NVRAM boot entries. If this is the case, {{ic|grub-install}} will claim {{ic|efibootmgr}} has added an entry to boot GRUB, however the entry will not show up in the VisualBIOS boot order selector. The solution is to place a file at one of the known locations. Assuming the EFI partition is at {{ic|/boot/efi/}} this will work:<br />
<br />
mkdir /boot/efi/EFI/boot<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi<br />
<br />
This solution worked for an Intel DH87MC motherboard with firmware dated Jan 2014.<br />
<br />
=== Enable debug messages ===<br />
<br />
{{Note|This change is overwritten when [[#Generate the main configuration file]].}}<br />
<br />
Add:<br />
<br />
set pager=1<br />
set debug=all<br />
<br />
to {{ic|grub.cfg}}.<br />
<br />
=== "No suitable mode found" error ===<br />
<br />
If you get this error when booting any menuentry:<br />
<br />
error: no suitable mode found<br />
Booting however<br />
<br />
Then you need to initialize GRUB graphical terminal ({{ic|gfxterm}}) with proper video mode ({{ic|gfxmode}}) in GRUB. This video mode is passed by GRUB to the linux kernel via 'gfxpayload'. In case of UEFI systems, if the GRUB video mode is not initialized, no kernel boot messages will be shown in the terminal (atleast until KMS kicks in).<br />
<br />
Copy {{ic|/usr/share/grub/unicode.pf2}} to ${GRUB_PREFIX_DIR} ({{ic|/boot/grub/}} in case of BIOS and UEFI systems). If GRUB UEFI was installed with {{ic|1=--boot-directory=$esp/EFI}} set, then the directory is {{ic|$esp/EFI/grub/}}:<br />
<br />
# cp /usr/share/grub/unicode.pf2 ${GRUB_PREFIX_DIR}<br />
<br />
If {{ic|/usr/share/grub/unicode.pf2}} does not exist, install {{Pkg|bdf-unifont}}, create the {{ic|unifont.pf2}} file and then copy it to {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}:<br />
<br />
# grub-mkfont -o unicode.pf2 /usr/share/fonts/misc/unifont.bdf<br />
<br />
Then, in the {{ic|grub.cfg}} file, add the following lines to enable GRUB to pass the video mode correctly to the kernel, without of which you will only get a black screen (no output) but booting (actually) proceeds successfully without any system hang.<br />
<br />
BIOS systems:<br />
<br />
insmod vbe<br />
<br />
UEFI systems:<br />
<br />
insmod efi_gop<br />
insmod efi_uga<br />
<br />
After that add the following code (common to both BIOS and UEFI):<br />
<br />
insmod font<br />
<br />
if loadfont ${prefix}/fonts/unicode.pf2<br />
then<br />
insmod gfxterm<br />
set gfxmode=auto<br />
set gfxpayload=keep<br />
terminal_output gfxterm<br />
fi<br />
<br />
As you can see for gfxterm (graphical terminal) to function properly, {{ic|unicode.pf2}} font file should exist in {{ic|${GRUB_PREFIX_DIR<nowiki>}</nowiki>}}.<br />
<br />
=== msdos-style error message ===<br />
<br />
grub-setup: warn: This msdos-style partition label has no post-MBR gap; embedding will not be possible!<br />
grub-setup: warn: Embedding is not possible. GRUB can only be installed in this setup by using blocklists.<br />
However, blocklists are UNRELIABLE and its use is discouraged.<br />
grub-setup: error: If you really want blocklists, use --force.<br />
<br />
This error may occur when you try installing GRUB in a VMware container. Read more about it [https://bbs.archlinux.org/viewtopic.php?pid=581760#p581760 here]. It happens when the first partition starts just after the MBR (block 63), without the usual space of 1 MiB (2048 blocks) before the first partition. Read [[#Master Boot Record (MBR) specific instructions]]<br />
<br />
=== UEFI ===<br />
<br />
==== Common installation errors ====<br />
<br />
* If you have a problem when running grub-install with sysfs or procfs and it says you must run {{ic|modprobe efivars}}, try [[Unified Extensible Firmware Interface#Switch to efivarfs]]{{Broken section link}}.<br />
* Without {{ic|--target}} or {{ic|--directory}} option, grub-install cannot determine for which firmware to install. In such cases {{ic|grub-install}} will print {{ic|source_dir does not exist. Please specify --target or --directory}}.<br />
* If after running grub-install you are told your partition does not look like an EFI partition then the partition is most likely not {{ic|Fat32}}.<br />
<br />
==== Drop to rescue shell ====<br />
<br />
If GRUB loads but drops you into the rescue shell with no errors, it may be because of a missing or misplaced {{ic|grub.cfg}}. This will happen if GRUB UEFI was installed with {{ic|--boot-directory}} and {{ic|grub.cfg}} is missing OR if the partition number of the boot partition changed (which is hard-coded into the {{ic|grubx64.efi}} file).<br />
<br />
==== GRUB UEFI not loaded ====<br />
<br />
An example of a working EFI:<br />
<br />
{{hc|# efibootmgr -v|<br />
BootCurrent: 0000<br />
Timeout: 3 seconds<br />
BootOrder: 0000,0001,0002<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\efi\grub\grub.efi)<br />
Boot0001* Shell HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\EfiShell.efi)<br />
Boot0002* Festplatte BIOS(2,0,00)P0: SAMSUNG HD204UI<br />
}}<br />
<br />
If the screen only goes black for a second and the next boot option is tried afterwards, according to [https://bbs.archlinux.org/viewtopic.php?pid=981560#p981560 this post], moving GRUB to the partition root can help. The boot option has to be deleted and recreated afterwards. The entry for GRUB should look like this then:<br />
<br />
Boot0000* Grub HD(1,800,32000,23532fbb-1bfa-4e46-851a-b494bfe9478c)File(\grub.efi)<br />
<br />
=== Invalid signature ===<br />
<br />
If trying to boot Windows results in an "invalid signature" error, e.g. after reconfiguring partitions or adding additional hard drives, (re)move GRUB's device configuration and let it reconfigure:<br />
<br />
# mv /boot/grub/device.map /boot/grub/device.map-old<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{ic|grub-mkconfig}} should now mention all found boot options, including Windows. If it works, remove {{ic|/boot/grub/device.map-old}}.<br />
<br />
=== Boot freezes ===<br />
<br />
If booting gets stuck without any error message after GRUB loading the kernel and the initial ramdisk, try removing the {{ic|add_efi_memmap}} kernel parameter.<br />
<br />
=== Arch not found from other OS ===<br />
<br />
Some have reported that other distributions have trouble finding Arch Linux automatically with {{ic|os-prober}}. If this problem arises, it has been reported that detection can be improved with the presence of {{ic|/etc/lsb-release}}. This file and updating tool is available with the package {{Pkg|lsb-release}} in the [[official repositories]].<br />
<br />
=== Warning when installing in chroot ===<br />
<br />
When installing GRUB on a LVM system in a chroot environment (e.g. during system installation), you may receive warnings like {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} or {{ic|WARNING: failed to connect to lvmetad: No such file or directory. Falling back to internal scanning.}} This is because {{ic|/run}} is not available inside the chroot. These warnings will not prevent the system from booting, provided that everything has been done correctly, so you may continue with the installation.<br />
<br />
=== GRUB loads slowly ===<br />
<br />
GRUB can take a long time to load when disk space is low. Check if you have sufficient free disk space on your {{ic|/boot}} or {{ic|/}} partition when you are having problems.<br />
<br />
=== error: unknown filesystem ===<br />
GRUB may output {{ic|error: unknown filesystem}} and refuse to boot for a few reasons. If you are certain that all [[UUID]]s are correct and all filesystems are valid and supported, it may be because your [[#GUID_Partition_Table_.28GPT.29_specific_instructions|BIOS Boot Partition]] is located outside the first 2TB of the drive [https://bbs.archlinux.org/viewtopic.php?id=195948]. Use a partitioning tool of your choice to ensure this partition is located fully within the first 2TB, then reinstall and reconfigure GRUB.<br />
<br />
=== grub-reboot not resetting ===<br />
<br />
GRUB seems to be unable to write to root BTRFS partitions [https://bbs.archlinux.org/viewtopic.php?id=166131]. If you use grub-reboot to boot into another entry it will therefore be unable to update its on-disk environment. Either run grub-reboot from the other entry (for example when switching between various distributions) or consider a different file system. You can reset a "sticky" entry by executing {{ic|grub-editenv create}} and setting {{ic|GRUB_DEFAULT<nowiki>=</nowiki>0}} in your {{ic|/etc/default/grub}} (don't forget {{ic|grub-mkconfig -o /boot/grub/grub.cfg}}).<br />
<br />
=== Old BTRFS prevents installation ===<br />
<br />
If a drive is formatted with BTRFS without creating a partition table (eg. /dev/sdx), then later has partition table written to, there are parts of the BTRFS format that persist. Most utilities and OS's do not see this, but GRUB will refuse to install, even with --force<br />
<br />
# grub-install: warning: Attempting to install GRUB to a disk with multiple partition labels. This is not supported yet..<br />
# grub-install: error: filesystem `btrfs' doesn't support blocklists.<br />
<br />
You can zero the drive, but the easy solution that leaves your data alone is to erase the BTRFS superblock with {{ic|wipefs -o 0x10040 /dev/sdx}}<br />
<br />
=== Windows 8/10 not found ===<br />
<br />
A setting in Windows 8/10 called "Hiberboot", "Hybrid Boot" or "Fast Boot" can prevent the Windows partition from being mounted, so {{ic|grub-mkconfig}} will not find a Windows install. Disabling Hiberboot in Windows will allow it to be added to the GRUB menu.<br />
<br />
== See also ==<br />
<br />
* Official GRUB Manual - https://www.gnu.org/software/grub/manual/grub.html<br />
* Ubuntu wiki page for GRUB - https://help.ubuntu.com/community/Grub2<br />
* GRUB wiki page describing steps to compile for UEFI systems - https://help.ubuntu.com/community/UEFIBooting<br />
* Wikipedia's page on [[Wikipedia:BIOS Boot partition|BIOS Boot partition]]<br />
* http://web.archive.org/web/20160424042444/http://members.iinet.net/~herman546/p20/GRUB2%20Configuration%20File%20Commands.html#Editing_etcgrub.d05_debian_theme - quite complete description of how to configure GRUB (Original link down)</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Ext4&diff=442911Ext42016-07-25T07:41:55Z<p>Wooptoo: see also</p>
<hr />
<div>[[Category:File systems]]<br />
[[cs:Ext4]]<br />
[[de:Ext4]]<br />
[[es:Ext4]]<br />
[[fr:Ext4]]<br />
[[it:Ext4]]<br />
[[ja:Ext4]]<br />
[[ru:Ext4]]<br />
[[tr:Ext4]]<br />
[[zh-CN:Ext4]]<br />
{{Related articles start}}<br />
{{Related|File systems}}<br />
{{Related|Ext3}}<br />
{{Related articles end}}<br />
From [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies]:<br />
:Ext4 is the evolution of the most used Linux filesystem, Ext3. In many ways, Ext4 is a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding journaling to Ext2, but Ext4 modifies important data structures of the filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability, and features.<br />
<br />
== Create a new ext4 filesystem ==<br />
<br />
To format a partition do:<br />
<br />
# mkfs.ext4 /dev/''partition''<br />
<br />
{{Tip|See the mkfs.ext4 [[man page]] for more options; edit {{ic|/etc/mke2fs.conf}} to view/configure default options.}}<br />
<br />
=== Bytes-per-inode ratio ===<br />
<br />
From {{ic|man mkfs.ext4}}:<br />
<br />
:'''''mke2fs''' creates an inode for every ''bytes-per-inode'' bytes of space on the disk. The larger the ''bytes-per-inode'' ratio, the fewer inodes will be created.''<br />
<br />
Creating a new file, directory, symlink etc. requires at least one free [[Wikipedia:Inode|inode]]. If the inode count is too low, no file can be created on the filesystem even though there is still space left on it. <br />
<br />
Because it is not possible to change either the bytes-per-inode ratio or the inode count after the filesystem is created, {{ic|mkfs.ext4}} uses by default a rather low ratio of one inode every 16384 bytes (16 Kb) to avoid this situation.<br />
<br />
However, for partitions with size in the hundreds or thousands of GB and average file size in the megabyte range, this usually results in a much too large inode number because the number of files created never reaches the number of inodes.<br />
<br />
This results in a waste of disk space, because all those unused inodes each take up 256 bytes on the filesystem (this is also set in {{ic|/etc/mke2fs.conf}} but should not be changed). 256 * several millions = quite a few gigabytes wasted in unused inodes.<br />
<br />
This situation can be evaluated by comparing the {{ic|{I}Use%}} figures provided by {{ic|df}} and {{ic|df -i}}:<br />
<br />
{{hc|$ df -h /home|<br />
Filesystem Size Used Avail '''Use%''' Mounted on<br />
/dev/mapper/lvm-home 115G 56G 59G '''49%''' /home}}<br />
{{hc|$ df -hi /home|<br />
Filesystem Inodes IUsed IFree '''IUse%''' Mounted on<br />
/dev/mapper/lvm-home 1.8M 1.1K 1.8M '''1%''' /home}}<br />
<br />
To specify a different bytes-per-inode ratio, you can use the {{ic|-T ''usage-type''}} option which hints at the expected usage of the filesystem using types defined in {{ic|/etc/mke2fs.conf}}. Among those types are the bigger {{ic|largefile}} and {{ic|largefile4}} which offer more relevant ratios of one inode every 1 MiB and 4 MiB respectively. It can be used as such:<br />
<br />
# mkfs.ext4 -T largefile /dev/''device''<br />
<br />
The bytes-per-inode ratio can also be set directly via the {{ic|-i}} option: ''e.g.'' use {{ic|-i 2097152}} for a 2 MiB ratio and {{ic|-i 6291456}} for a 6 MiB ratio.<br />
<br />
{{Tip|Conversely, if you are setting up a partition dedicated to host millions of small files like emails or newsgroup items, you can use smaller ''usage-type'' values such as {{ic|news}} (one inode for every 4096 bytes) or {{ic|small}} (same plus smaller inode and block sizes).}}<br />
<br />
{{Warning|If you make a heavy use of symbolic links, make sure to keep the inode count high enough with a low bytes-per-inode ratio, because while not taking more space every new symbolic link consumes one new inode and therefore the filesystem may run out of them quickly.}}<br />
<br />
=== Reserved blocks ===<br />
<br />
By default, 5% of the filesystem blocks will be reserved for the super-user, to avoid fragmentation and "''allow root-owned daemons to continue to function correctly after non-privileged processes are prevented from writing to the filesystem''" (from {{ic|man mkfs.ext4}}).<br />
<br />
For modern high-capacity disks, this is higher than necessary if the partition is used as a long-term archive or not crucial to system operations (like {{ic|/home}}). See [http://www.redhat.com/archives/ext3-users/2009-January/msg00026.html this email] for the opinion of ext4 developer Ted Ts'o on reserved blocks.<br />
<br />
It is generally safe to reduce the percentage of reserved blocks to free up disk space when the partition is either:<br />
<br />
* Very large (for example > 50G)<br />
* Used as long-term archive, i.e., where files will not be deleted and created very often<br />
<br />
The {{ic|-m}} option of ext4-related utilities allows to specify the percentage of reserved blocks.<br />
<br />
To totally prevent reserving blocks upon filesystem creation, use:<br />
<br />
# mkfs.ext4 -m 0 /dev/''device''<br />
<br />
To reduce it to 1% afterwards, use:<br />
<br />
# tune2fs -m 1 /dev/''device''<br />
<br />
You can use {{ic|findmnt(8)}} to find the device name:<br />
<br />
$ findmnt ''/the/mount/point''<br />
<br />
==Migrating from ext2/ext3 to ext4==<br />
<br />
===Mounting ext2/ext3 partitions as ext4 without converting===<br />
<br />
====Rationale====<br />
<br />
A compromise between fully converting to ext4 and simply remaining with ext2/ext3 is to mount the partitions as ext4.<br />
<br />
'''Pros:'''<br />
* Compatibility (the filesystem can continue to be mounted as ext3) &ndash; This allows users to still read the filesystem from other operating systems without ext4 support (e.g. Windows with ext2/ext3 drivers)<br />
* Improved performance (though not as much as a fully-converted ext4 partition).[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Fewer features of ext4 are used (only those that do not change the disk format such as multiblock allocation and delayed allocation)<br />
<br />
{{Note|Except for the relative novelty of ext4 (which can be seen as a risk), '''there is no major drawback to this technique'''.}}<br />
<br />
====Procedure====<br />
<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext2/ext3 to ext4 for any partitions you would like to mount as ext4.<br />
# Re-mount the affected partitions.<br />
<br />
===Converting ext2/ext3 partitions to ext4===<br />
<br />
====Rationale====<br />
<br />
To experience the benefits of ext4, an irreversible conversion process must be completed.<br />
<br />
'''Pros:'''<br />
* Improved performance and new features.[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Partitions that contain mostly static files, such as a {{ic|/boot}} partition, may not benefit from the new features. Also, adding a journal (which is implied by moving a ext2 partition to ext3/4) always incurs performance overhead. <br />
* Irreversible (ext4 partitions cannot be 'downgraded' to ext2/ext3. It is, however, backwards compatible until extent and other unique options are enabled)<br />
<br />
====Procedure====<br />
<br />
These instructions were adapted from [http://ext4.wiki.kernel.org/index.php/Ext4_Howto Kernel documentation] and an [https://bbs.archlinux.org/viewtopic.php?id=61602 BBS thread]. <br />
<br />
{{Warning|<br />
* If you convert the system's root filesystem, ensure that the 'fallback' initramfs is available at reboot. Alternatively, add {{ic|ext4}} according to [[Mkinitcpio#MODULES]] and re-create the 'default' initial ramdisk with {{Ic|mkinitcpio -p linux}} before starting.<br />
* If you decide to convert a separate {{ic|/boot}} partition, ensure the [[bootloader]] supports booting from ext4.}}<br />
<br />
In the following steps {{Ic|/dev/sdxX}} denotes the path to the partition to be converted, such as {{Ic|/dev/sda1}}. <br />
<br />
# '''[[Backup programs|BACK-UP!]]''' Back-up all data on any ext3 partitions that are to be converted to ext4. A useful package, especially for root partitions, is [http://clonezilla.org Clonezilla].<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext3 to ext4 for any partitions that are to be converted to ext4.<br />
# Boot the live medium (if necessary). The conversion process with {{Pkg|e2fsprogs}} must be done when the drive is not mounted. If converting a root partition, the simplest way to achieve this is to boot from some other live medium.<br />
# Ensure the partition is '''NOT''' mounted<br />
# If you want to convert a ext2 partition, the first conversion step is to add a [[File systems#Journaling|journal]] by running {{ic|tune2fs -j /dev/sdxX}} as root; making it a ext3 partition. <br />
# Run {{Ic|tune2fs -O extent,uninit_bg,dir_index /dev/sdxX}} as root. This command converts the ext3 filesystem to ext4 (irreversibly). <br />
# Run {{Ic|fsck -f /dev/sdxX}} as root. <br />
#* The user '''must ''fsck''''' the filesystem, or it '''will be unreadable'''! This ''fsck'' run is needed to return the filesystem to a consistent state. It '''will''' find checksum errors in the group descriptors - this '''is''' expected. The {{ic|-f}} option asks ''fsck'' to force checking even if the file system seems clean. The {{ic|-p}} option may be used on top to 'automatically repair' (otherwise, the user will be asked for input for each error). <br />
# Recommended: mount the partition and run {{Ic|e4defrag -c -v /dev/sdxX}} as root.<br />
#* Even though the filesystem is now converted to ext4, all files that have been written before the conversion do not yet take advantage of the extent option of ext4, which will improve large file performance and reduce fragmentation and filesystem check time. In order to fully take advantage of ext4, all files would have to be rewritten on disk. Use ''e4defrag'' to take care of this problem.<br />
# Reboot Arch Linux!<br />
<br />
== Using ext4 per directory encryption == <br />
<br />
Linux comes with an Ext4 feature to encrypt directories of a filesystem. See also [http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html Quarkslab's blog] entry with a write-up of the features, an overview of the implementation state and practical test results with kernel 4.1. <br />
<br />
Encryption keys are stored in the keyring. To get started, make sure you have enabled {{ic|CONFIG_KEYS}} and {{ic|CONFIG_EXT4_ENCRYPTION}} kernel options and you have kernel 4.1 or higher. Note the Arch default {{Pkg|linux}} does not have {{ic|CONFIG_EXT4_ENCRYPTION}} set yet. <br />
<br />
First of all, you need to update {{Pkg|e2fsprogs}} to at least version 1.43.<br />
<br />
Let us make a directory that we will encrypt. Encryption policy can be set only on new empty directories. For example, if we are to encrypt {{ic|/encrypted/dir}}, create the upper level directory:<br />
<br />
# mkdir /encrypted<br />
<br />
First generate a random salt value and store it in a safe place:<br />
<br />
# head -c 16 /dev/random | xxd -p<br />
877282f53bd0adbbef92142fc4cac459<br />
<br />
Now generate and add a new key into your keyring:<br />
this step should be repeated every time you flush your keychain (reboot)<br />
<br />
# e4crypt add_key -S 0x877282f53bd0adbbef92142fc4cac459<br />
Enter passphrase (echo disabled): <br />
Added key with descriptor [f88747555a6115f5]<br />
<br />
Now you know a descriptor for your key.<br />
Make sure you have added a key into your keychain:<br />
<br />
# keyctl show<br />
Session Keyring<br />
1021618178 --alswrv 1000 1000 keyring: _ses<br />
176349519 --alsw-v 1000 1000 \_ logon: ext4:f88747555a6115f5<br />
<br />
Almost done. Now set an encryption policy for a directory:<br />
<br />
# e4crypt set_policy f88747555a6115f5 /encrypted/dir<br />
<br />
That is all. If you try accessing the disk without adding a key into keychain,<br />
filenames and their contents will be seen as encrypted gibberish. Be careful<br />
running old versions of e2fsck on your filesystem - it will treat encrypted<br />
filenames as invalid.<br />
<br />
== Tips and tricks ==<br />
<br />
=== E4rat ===<br />
<br />
[[E4rat]] is a preload application designed for the ext4 filesystem. It monitors files opened during boot, optimizes their placement on the partition to improve access time, and preloads them at the very beginning of the boot process. [[E4rat]] does not offer improvements with [[SSD]]s, whose access time is negligible compared to hard disks.<br />
<br />
=== Barriers and performance ===<br />
<br />
Since kernel 2.6.30, ext4 performance has decreased due to changes that serve to improve data integrity.[http://www.phoronix.com/scan.php?page=article&item=ext4_then_now&num=1]<br />
<br />
:Most file systems (XFS, ext3, ext4, reiserfs) send write barriers to disk after fsync or during transaction commits. Write barriers enforce proper ordering of writes, making volatile disk write caches safe to use (at some performance penalty). If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.<br />
<br />
:Sending write barriers can be disabled using the {{Ic|1=barrier=0}} mount option (for ext3, ext4, and reiserfs), or using the {{Ic|1=nobarrier}} mount option (for XFS).[http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning.io.html]{{dead link|2016|7|5}}<br />
<br />
{{Warning|Disabling barriers when disks cannot guarantee caches are properly written in case of power failure can lead to severe file system corruption and data loss.}}<br />
<br />
To turn barriers off add the option {{Ic|1=barrier=0}} to the desired filesystem. For example:<br />
<br />
{{hc|/etc/fstab|2=<br />
/dev/sda5 / ext4 noatime,barrier=0 0 1<br />
}}<br />
<br />
==Enabling metadata checksums==<br />
<br />
In both cases of enabling metadata checksums for new and existing filesystems, you will need to load some kernel modules.<br />
<br />
If your CPU supports SSE 4.2, make sure the {{Ic|crc32c_intel}} kernel module is loaded in order to enable the hardware accelerated CRC32C algorithm. If not you will need to load the {{Ic|crc32c_generic}} module.<br />
<br />
If this is the root file-system your {{Ic|crc32c_}} module might need to be added to {{Ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES="... crc32c_intel crc32c_generic"<br />
<br />
And then regenerate the initramfs. See [[Mkinitcpio#Image creation and activation]].<br />
<br />
After this, you are ready to enable support for metadata checksums as described in the following two sections. In both cases the device must not be mounted.<br />
<br />
More about metadata checksums can be read on the [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums ext4 wiki].<br />
<br />
=== New filesystem ===<br />
<br />
To enable support for ext4 metadata checksums on a new file system make sure that you have {{Ic|e2fsprogs 1.43}} or newer and simply do a:<br />
<br />
# mkfs.ext4 ''/dev/path/to/disk''<br />
<br />
The {{Ic |metadata_csum}} and {{Ic|64bit}} options will be enabled by default. <br />
<br />
The file-system can then be mounted as usual.<br />
<br />
=== Existing filesystem ===<br />
<br />
To enable support on an existing ext4 file system do the following.<br />
<br />
This needs to be done with the partition unmounted, so if you want to convert the root, you'll need to run off an USB live distro.<br />
<br />
First the partition needs to be checked and optimized using:<br />
<br />
# e2fsck -Df ''/dev/path/to/disk'' <br />
<br />
Then the file-system needs to be converted to 64bit:<br />
<br />
# resize2fs -b ''/dev/path/to/disk'' <br />
<br />
Finally checksums can be added<br />
<br />
# tune2fs -O metadata_csum ''/dev/path/to/disk''<br />
<br />
The file-system can then be mounted as usual.<br />
<br />
You can check whether the features were successfully enabled by running:<br />
<br />
# dumpe2fs ''/dev/path/to/disk''<br />
<br />
=== Impact on performance ===<br />
<br />
Keep in mind that the intel module consistently performs 10x faster than the generic one, peaking at 20x faster as can be seen in [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums#Benchmarking this benchmark].<br />
<br />
== See also ==<br />
<br />
* [https://ext4.wiki.kernel.org/ Official Ext4 wiki]<br />
* [https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout Ext4 Disk Layout] described in its wiki<br />
* [http://lwn.net/Articles/639427/ Ext4 Encryption] LWN article<br />
* Kernel commits for ext4 encryption [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6162e4b0bedeb3dac2ba0a5e1b1f56db107d97ec] [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8663da2c0919896788321cd8a0016af08588c656]<br />
* [http://e2fsprogs.sourceforge.net/e2fsprogs-release.html e2fsprogs Changelog]<br />
* [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums Ext4 Metadata Checksums]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=User:Wooptoo&diff=442908User:Wooptoo2016-07-25T07:25:44Z<p>Wooptoo: </p>
<hr />
<div>Occasional ArchWiki contributor :)<br />
<br />
[http://wooptoo.com My Blog]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Ext4&diff=442907Ext42016-07-25T07:20:45Z<p>Wooptoo: small fixes to checksums part</p>
<hr />
<div>[[Category:File systems]]<br />
[[cs:Ext4]]<br />
[[de:Ext4]]<br />
[[es:Ext4]]<br />
[[fr:Ext4]]<br />
[[it:Ext4]]<br />
[[ja:Ext4]]<br />
[[ru:Ext4]]<br />
[[tr:Ext4]]<br />
[[zh-CN:Ext4]]<br />
{{Related articles start}}<br />
{{Related|File systems}}<br />
{{Related|Ext3}}<br />
{{Related articles end}}<br />
From [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies]:<br />
:Ext4 is the evolution of the most used Linux filesystem, Ext3. In many ways, Ext4 is a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding journaling to Ext2, but Ext4 modifies important data structures of the filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability, and features.<br />
<br />
== Create a new ext4 filesystem ==<br />
<br />
To format a partition do:<br />
<br />
# mkfs.ext4 /dev/''partition''<br />
<br />
{{Tip|See the mkfs.ext4 [[man page]] for more options; edit {{ic|/etc/mke2fs.conf}} to view/configure default options.}}<br />
<br />
=== Bytes-per-inode ratio ===<br />
<br />
From {{ic|man mkfs.ext4}}:<br />
<br />
:'''''mke2fs''' creates an inode for every ''bytes-per-inode'' bytes of space on the disk. The larger the ''bytes-per-inode'' ratio, the fewer inodes will be created.''<br />
<br />
Creating a new file, directory, symlink etc. requires at least one free [[Wikipedia:Inode|inode]]. If the inode count is too low, no file can be created on the filesystem even though there is still space left on it. <br />
<br />
Because it is not possible to change either the bytes-per-inode ratio or the inode count after the filesystem is created, {{ic|mkfs.ext4}} uses by default a rather low ratio of one inode every 16384 bytes (16 Kb) to avoid this situation.<br />
<br />
However, for partitions with size in the hundreds or thousands of GB and average file size in the megabyte range, this usually results in a much too large inode number because the number of files created never reaches the number of inodes.<br />
<br />
This results in a waste of disk space, because all those unused inodes each take up 256 bytes on the filesystem (this is also set in {{ic|/etc/mke2fs.conf}} but should not be changed). 256 * several millions = quite a few gigabytes wasted in unused inodes.<br />
<br />
This situation can be evaluated by comparing the {{ic|{I}Use%}} figures provided by {{ic|df}} and {{ic|df -i}}:<br />
<br />
{{hc|$ df -h /home|<br />
Filesystem Size Used Avail '''Use%''' Mounted on<br />
/dev/mapper/lvm-home 115G 56G 59G '''49%''' /home}}<br />
{{hc|$ df -hi /home|<br />
Filesystem Inodes IUsed IFree '''IUse%''' Mounted on<br />
/dev/mapper/lvm-home 1.8M 1.1K 1.8M '''1%''' /home}}<br />
<br />
To specify a different bytes-per-inode ratio, you can use the {{ic|-T ''usage-type''}} option which hints at the expected usage of the filesystem using types defined in {{ic|/etc/mke2fs.conf}}. Among those types are the bigger {{ic|largefile}} and {{ic|largefile4}} which offer more relevant ratios of one inode every 1 MiB and 4 MiB respectively. It can be used as such:<br />
<br />
# mkfs.ext4 -T largefile /dev/''device''<br />
<br />
The bytes-per-inode ratio can also be set directly via the {{ic|-i}} option: ''e.g.'' use {{ic|-i 2097152}} for a 2 MiB ratio and {{ic|-i 6291456}} for a 6 MiB ratio.<br />
<br />
{{Tip|Conversely, if you are setting up a partition dedicated to host millions of small files like emails or newsgroup items, you can use smaller ''usage-type'' values such as {{ic|news}} (one inode for every 4096 bytes) or {{ic|small}} (same plus smaller inode and block sizes).}}<br />
<br />
{{Warning|If you make a heavy use of symbolic links, make sure to keep the inode count high enough with a low bytes-per-inode ratio, because while not taking more space every new symbolic link consumes one new inode and therefore the filesystem may run out of them quickly.}}<br />
<br />
=== Reserved blocks ===<br />
<br />
By default, 5% of the filesystem blocks will be reserved for the super-user, to avoid fragmentation and "''allow root-owned daemons to continue to function correctly after non-privileged processes are prevented from writing to the filesystem''" (from {{ic|man mkfs.ext4}}).<br />
<br />
For modern high-capacity disks, this is higher than necessary if the partition is used as a long-term archive or not crucial to system operations (like {{ic|/home}}). See [http://www.redhat.com/archives/ext3-users/2009-January/msg00026.html this email] for the opinion of ext4 developer Ted Ts'o on reserved blocks.<br />
<br />
It is generally safe to reduce the percentage of reserved blocks to free up disk space when the partition is either:<br />
<br />
* Very large (for example > 50G)<br />
* Used as long-term archive, i.e., where files will not be deleted and created very often<br />
<br />
The {{ic|-m}} option of ext4-related utilities allows to specify the percentage of reserved blocks.<br />
<br />
To totally prevent reserving blocks upon filesystem creation, use:<br />
<br />
# mkfs.ext4 -m 0 /dev/''device''<br />
<br />
To reduce it to 1% afterwards, use:<br />
<br />
# tune2fs -m 1 /dev/''device''<br />
<br />
You can use {{ic|findmnt(8)}} to find the device name:<br />
<br />
$ findmnt ''/the/mount/point''<br />
<br />
==Migrating from ext2/ext3 to ext4==<br />
<br />
===Mounting ext2/ext3 partitions as ext4 without converting===<br />
<br />
====Rationale====<br />
<br />
A compromise between fully converting to ext4 and simply remaining with ext2/ext3 is to mount the partitions as ext4.<br />
<br />
'''Pros:'''<br />
* Compatibility (the filesystem can continue to be mounted as ext3) &ndash; This allows users to still read the filesystem from other operating systems without ext4 support (e.g. Windows with ext2/ext3 drivers)<br />
* Improved performance (though not as much as a fully-converted ext4 partition).[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Fewer features of ext4 are used (only those that do not change the disk format such as multiblock allocation and delayed allocation)<br />
<br />
{{Note|Except for the relative novelty of ext4 (which can be seen as a risk), '''there is no major drawback to this technique'''.}}<br />
<br />
====Procedure====<br />
<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext2/ext3 to ext4 for any partitions you would like to mount as ext4.<br />
# Re-mount the affected partitions.<br />
<br />
===Converting ext2/ext3 partitions to ext4===<br />
<br />
====Rationale====<br />
<br />
To experience the benefits of ext4, an irreversible conversion process must be completed.<br />
<br />
'''Pros:'''<br />
* Improved performance and new features.[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Partitions that contain mostly static files, such as a {{ic|/boot}} partition, may not benefit from the new features. Also, adding a journal (which is implied by moving a ext2 partition to ext3/4) always incurs performance overhead. <br />
* Irreversible (ext4 partitions cannot be 'downgraded' to ext2/ext3. It is, however, backwards compatible until extent and other unique options are enabled)<br />
<br />
====Procedure====<br />
<br />
These instructions were adapted from [http://ext4.wiki.kernel.org/index.php/Ext4_Howto Kernel documentation] and an [https://bbs.archlinux.org/viewtopic.php?id=61602 BBS thread]. <br />
<br />
{{Warning|<br />
* If you convert the system's root filesystem, ensure that the 'fallback' initramfs is available at reboot. Alternatively, add {{ic|ext4}} according to [[Mkinitcpio#MODULES]] and re-create the 'default' initial ramdisk with {{Ic|mkinitcpio -p linux}} before starting.<br />
* If you decide to convert a separate {{ic|/boot}} partition, ensure the [[bootloader]] supports booting from ext4.}}<br />
<br />
In the following steps {{Ic|/dev/sdxX}} denotes the path to the partition to be converted, such as {{Ic|/dev/sda1}}. <br />
<br />
# '''[[Backup programs|BACK-UP!]]''' Back-up all data on any ext3 partitions that are to be converted to ext4. A useful package, especially for root partitions, is [http://clonezilla.org Clonezilla].<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext3 to ext4 for any partitions that are to be converted to ext4.<br />
# Boot the live medium (if necessary). The conversion process with {{Pkg|e2fsprogs}} must be done when the drive is not mounted. If converting a root partition, the simplest way to achieve this is to boot from some other live medium.<br />
# Ensure the partition is '''NOT''' mounted<br />
# If you want to convert a ext2 partition, the first conversion step is to add a [[File systems#Journaling|journal]] by running {{ic|tune2fs -j /dev/sdxX}} as root; making it a ext3 partition. <br />
# Run {{Ic|tune2fs -O extent,uninit_bg,dir_index /dev/sdxX}} as root. This command converts the ext3 filesystem to ext4 (irreversibly). <br />
# Run {{Ic|fsck -f /dev/sdxX}} as root. <br />
#* The user '''must ''fsck''''' the filesystem, or it '''will be unreadable'''! This ''fsck'' run is needed to return the filesystem to a consistent state. It '''will''' find checksum errors in the group descriptors - this '''is''' expected. The {{ic|-f}} option asks ''fsck'' to force checking even if the file system seems clean. The {{ic|-p}} option may be used on top to 'automatically repair' (otherwise, the user will be asked for input for each error). <br />
# Recommended: mount the partition and run {{Ic|e4defrag -c -v /dev/sdxX}} as root.<br />
#* Even though the filesystem is now converted to ext4, all files that have been written before the conversion do not yet take advantage of the extent option of ext4, which will improve large file performance and reduce fragmentation and filesystem check time. In order to fully take advantage of ext4, all files would have to be rewritten on disk. Use ''e4defrag'' to take care of this problem.<br />
# Reboot Arch Linux!<br />
<br />
== Using ext4 per directory encryption == <br />
<br />
Linux comes with an Ext4 feature to encrypt directories of a filesystem. See also [http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html Quarkslab's blog] entry with a write-up of the features, an overview of the implementation state and practical test results with kernel 4.1. <br />
<br />
Encryption keys are stored in the keyring. To get started, make sure you have enabled {{ic|CONFIG_KEYS}} and {{ic|CONFIG_EXT4_ENCRYPTION}} kernel options and you have kernel 4.1 or higher. Note the Arch default {{Pkg|linux}} does not have {{ic|CONFIG_EXT4_ENCRYPTION}} set yet. <br />
<br />
First of all, you need to update {{Pkg|e2fsprogs}} to at least version 1.43.<br />
<br />
Let us make a directory that we will encrypt. Encryption policy can be set only on new empty directories. For example, if we are to encrypt {{ic|/encrypted/dir}}, create the upper level directory:<br />
<br />
# mkdir /encrypted<br />
<br />
First generate a random salt value and store it in a safe place:<br />
<br />
# head -c 16 /dev/random | xxd -p<br />
877282f53bd0adbbef92142fc4cac459<br />
<br />
Now generate and add a new key into your keyring:<br />
this step should be repeated every time you flush your keychain (reboot)<br />
<br />
# e4crypt add_key -S 0x877282f53bd0adbbef92142fc4cac459<br />
Enter passphrase (echo disabled): <br />
Added key with descriptor [f88747555a6115f5]<br />
<br />
Now you know a descriptor for your key.<br />
Make sure you have added a key into your keychain:<br />
<br />
# keyctl show<br />
Session Keyring<br />
1021618178 --alswrv 1000 1000 keyring: _ses<br />
176349519 --alsw-v 1000 1000 \_ logon: ext4:f88747555a6115f5<br />
<br />
Almost done. Now set an encryption policy for a directory:<br />
<br />
# e4crypt set_policy f88747555a6115f5 /encrypted/dir<br />
<br />
That is all. If you try accessing the disk without adding a key into keychain,<br />
filenames and their contents will be seen as encrypted gibberish. Be careful<br />
running old versions of e2fsck on your filesystem - it will treat encrypted<br />
filenames as invalid.<br />
<br />
== Tips and tricks ==<br />
<br />
=== E4rat ===<br />
<br />
[[E4rat]] is a preload application designed for the ext4 filesystem. It monitors files opened during boot, optimizes their placement on the partition to improve access time, and preloads them at the very beginning of the boot process. [[E4rat]] does not offer improvements with [[SSD]]s, whose access time is negligible compared to hard disks.<br />
<br />
=== Barriers and performance ===<br />
<br />
Since kernel 2.6.30, ext4 performance has decreased due to changes that serve to improve data integrity.[http://www.phoronix.com/scan.php?page=article&item=ext4_then_now&num=1]<br />
<br />
:Most file systems (XFS, ext3, ext4, reiserfs) send write barriers to disk after fsync or during transaction commits. Write barriers enforce proper ordering of writes, making volatile disk write caches safe to use (at some performance penalty). If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.<br />
<br />
:Sending write barriers can be disabled using the {{Ic|1=barrier=0}} mount option (for ext3, ext4, and reiserfs), or using the {{Ic|1=nobarrier}} mount option (for XFS).[http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning.io.html]{{dead link|2016|7|5}}<br />
<br />
{{Warning|Disabling barriers when disks cannot guarantee caches are properly written in case of power failure can lead to severe file system corruption and data loss.}}<br />
<br />
To turn barriers off add the option {{Ic|1=barrier=0}} to the desired filesystem. For example:<br />
<br />
{{hc|/etc/fstab|2=<br />
/dev/sda5 / ext4 noatime,barrier=0 0 1<br />
}}<br />
<br />
==Enabling metadata checksums==<br />
<br />
In both cases of enabling metadata checksums for new and existing filesystems, you will need to load some kernel modules.<br />
<br />
If your CPU supports SSE 4.2, make sure the {{Ic|crc32c_intel}} kernel module is loaded in order to enable the hardware accelerated CRC32C algorithm. If not you will need to load the {{Ic|crc32c_generic}} module.<br />
<br />
If this is the root file-system your {{Ic|crc32c_}} module might need to be added to {{Ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES="... crc32c_intel crc32c_generic"<br />
<br />
And then regenerate the initramfs. See [[Mkinitcpio#Image creation and activation]].<br />
<br />
After this, you are ready to enable support for metadata checksums as described in the following two sections. In both cases the device must not be mounted.<br />
<br />
More about metadata checksums can be read on the [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums ext4 wiki].<br />
<br />
=== New filesystem ===<br />
<br />
To enable support for ext4 metadata checksums on a new file system make sure that you have {{Ic|e2fsprogs 1.43}} or newer and simply do a:<br />
<br />
# mkfs.ext4 ''/dev/path/to/disk''<br />
<br />
The {{Ic |metadata_csum}} and {{Ic|64bit}} options will be enabled by default. <br />
<br />
The file-system can then be mounted as usual.<br />
<br />
=== Existing filesystem ===<br />
<br />
To enable support on an existing ext4 file system do the following.<br />
<br />
This needs to be done with the partition unmounted, so if you want to convert the root, you'll need to run off an USB live distro.<br />
<br />
First the partition needs to be checked and optimized using:<br />
<br />
# e2fsck -D ''/dev/path/to/disk'' <br />
<br />
Then the file-system needs to be converted to 64bit:<br />
<br />
# resize2fs -b ''/dev/path/to/disk'' <br />
<br />
Finally checksums can be added<br />
<br />
# tune2fs -O metadata_csum ''/dev/path/to/disk''<br />
<br />
The file-system can then be mounted as usual.<br />
<br />
You can check whether the features were successfully enabled by running:<br />
<br />
# dumpe2fs ''/dev/path/to/disk''<br />
<br />
=== Impact on performance ===<br />
<br />
Keep in mind that the intel module consistently performs 10x faster than the generic one, peaking at 20x faster as can be seen in [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums#Benchmarking this benchmark].<br />
<br />
== See also ==<br />
<br />
* [https://ext4.wiki.kernel.org/ Official Ext4 wiki]<br />
* [https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout Ext4 Disk Layout] described in its wiki<br />
* [http://lwn.net/Articles/639427/ Ext4 Encryption] LWN article<br />
* Kernel commits for ext4 encryption [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6162e4b0bedeb3dac2ba0a5e1b1f56db107d97ec] [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8663da2c0919896788321cd8a0016af08588c656]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Ext4&diff=442901Ext42016-07-25T03:19:58Z<p>Wooptoo: Performance</p>
<hr />
<div>[[Category:File systems]]<br />
[[cs:Ext4]]<br />
[[de:Ext4]]<br />
[[es:Ext4]]<br />
[[fr:Ext4]]<br />
[[it:Ext4]]<br />
[[ja:Ext4]]<br />
[[ru:Ext4]]<br />
[[tr:Ext4]]<br />
[[zh-CN:Ext4]]<br />
{{Related articles start}}<br />
{{Related|File systems}}<br />
{{Related|Ext3}}<br />
{{Related articles end}}<br />
From [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies]:<br />
:Ext4 is the evolution of the most used Linux filesystem, Ext3. In many ways, Ext4 is a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding journaling to Ext2, but Ext4 modifies important data structures of the filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability, and features.<br />
<br />
== Create a new ext4 filesystem ==<br />
<br />
To format a partition do:<br />
<br />
# mkfs.ext4 /dev/''partition''<br />
<br />
{{Tip|See the mkfs.ext4 [[man page]] for more options; edit {{ic|/etc/mke2fs.conf}} to view/configure default options.}}<br />
<br />
=== Bytes-per-inode ratio ===<br />
<br />
From {{ic|man mkfs.ext4}}:<br />
<br />
:'''''mke2fs''' creates an inode for every ''bytes-per-inode'' bytes of space on the disk. The larger the ''bytes-per-inode'' ratio, the fewer inodes will be created.''<br />
<br />
Creating a new file, directory, symlink etc. requires at least one free [[Wikipedia:Inode|inode]]. If the inode count is too low, no file can be created on the filesystem even though there is still space left on it. <br />
<br />
Because it is not possible to change either the bytes-per-inode ratio or the inode count after the filesystem is created, {{ic|mkfs.ext4}} uses by default a rather low ratio of one inode every 16384 bytes (16 Kb) to avoid this situation.<br />
<br />
However, for partitions with size in the hundreds or thousands of GB and average file size in the megabyte range, this usually results in a much too large inode number because the number of files created never reaches the number of inodes.<br />
<br />
This results in a waste of disk space, because all those unused inodes each take up 256 bytes on the filesystem (this is also set in {{ic|/etc/mke2fs.conf}} but should not be changed). 256 * several millions = quite a few gigabytes wasted in unused inodes.<br />
<br />
This situation can be evaluated by comparing the {{ic|{I}Use%}} figures provided by {{ic|df}} and {{ic|df -i}}:<br />
<br />
{{hc|$ df -h /home|<br />
Filesystem Size Used Avail '''Use%''' Mounted on<br />
/dev/mapper/lvm-home 115G 56G 59G '''49%''' /home}}<br />
{{hc|$ df -hi /home|<br />
Filesystem Inodes IUsed IFree '''IUse%''' Mounted on<br />
/dev/mapper/lvm-home 1.8M 1.1K 1.8M '''1%''' /home}}<br />
<br />
To specify a different bytes-per-inode ratio, you can use the {{ic|-T ''usage-type''}} option which hints at the expected usage of the filesystem using types defined in {{ic|/etc/mke2fs.conf}}. Among those types are the bigger {{ic|largefile}} and {{ic|largefile4}} which offer more relevant ratios of one inode every 1 MiB and 4 MiB respectively. It can be used as such:<br />
<br />
# mkfs.ext4 -T largefile /dev/''device''<br />
<br />
The bytes-per-inode ratio can also be set directly via the {{ic|-i}} option: ''e.g.'' use {{ic|-i 2097152}} for a 2 MiB ratio and {{ic|-i 6291456}} for a 6 MiB ratio.<br />
<br />
{{Tip|Conversely, if you are setting up a partition dedicated to host millions of small files like emails or newsgroup items, you can use smaller ''usage-type'' values such as {{ic|news}} (one inode for every 4096 bytes) or {{ic|small}} (same plus smaller inode and block sizes).}}<br />
<br />
{{Warning|If you make a heavy use of symbolic links, make sure to keep the inode count high enough with a low bytes-per-inode ratio, because while not taking more space every new symbolic link consumes one new inode and therefore the filesystem may run out of them quickly.}}<br />
<br />
=== Reserved blocks ===<br />
<br />
By default, 5% of the filesystem blocks will be reserved for the super-user, to avoid fragmentation and "''allow root-owned daemons to continue to function correctly after non-privileged processes are prevented from writing to the filesystem''" (from {{ic|man mkfs.ext4}}).<br />
<br />
For modern high-capacity disks, this is higher than necessary if the partition is used as a long-term archive or not crucial to system operations (like {{ic|/home}}). See [http://www.redhat.com/archives/ext3-users/2009-January/msg00026.html this email] for the opinion of ext4 developer Ted Ts'o on reserved blocks.<br />
<br />
It is generally safe to reduce the percentage of reserved blocks to free up disk space when the partition is either:<br />
<br />
* Very large (for example > 50G)<br />
* Used as long-term archive, i.e., where files will not be deleted and created very often<br />
<br />
The {{ic|-m}} option of ext4-related utilities allows to specify the percentage of reserved blocks.<br />
<br />
To totally prevent reserving blocks upon filesystem creation, use:<br />
<br />
# mkfs.ext4 -m 0 /dev/''device''<br />
<br />
To reduce it to 1% afterwards, use:<br />
<br />
# tune2fs -m 1 /dev/''device''<br />
<br />
You can use {{ic|findmnt(8)}} to find the device name:<br />
<br />
$ findmnt ''/the/mount/point''<br />
<br />
==Migrating from ext2/ext3 to ext4==<br />
<br />
===Mounting ext2/ext3 partitions as ext4 without converting===<br />
<br />
====Rationale====<br />
<br />
A compromise between fully converting to ext4 and simply remaining with ext2/ext3 is to mount the partitions as ext4.<br />
<br />
'''Pros:'''<br />
* Compatibility (the filesystem can continue to be mounted as ext3) &ndash; This allows users to still read the filesystem from other operating systems without ext4 support (e.g. Windows with ext2/ext3 drivers)<br />
* Improved performance (though not as much as a fully-converted ext4 partition).[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Fewer features of ext4 are used (only those that do not change the disk format such as multiblock allocation and delayed allocation)<br />
<br />
{{Note|Except for the relative novelty of ext4 (which can be seen as a risk), '''there is no major drawback to this technique'''.}}<br />
<br />
====Procedure====<br />
<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext2/ext3 to ext4 for any partitions you would like to mount as ext4.<br />
# Re-mount the affected partitions.<br />
<br />
===Converting ext2/ext3 partitions to ext4===<br />
<br />
====Rationale====<br />
<br />
To experience the benefits of ext4, an irreversible conversion process must be completed.<br />
<br />
'''Pros:'''<br />
* Improved performance and new features.[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Partitions that contain mostly static files, such as a {{ic|/boot}} partition, may not benefit from the new features. Also, adding a journal (which is implied by moving a ext2 partition to ext3/4) always incurs performance overhead. <br />
* Irreversible (ext4 partitions cannot be 'downgraded' to ext2/ext3. It is, however, backwards compatible until extent and other unique options are enabled)<br />
<br />
====Procedure====<br />
<br />
These instructions were adapted from [http://ext4.wiki.kernel.org/index.php/Ext4_Howto Kernel documentation] and an [https://bbs.archlinux.org/viewtopic.php?id=61602 BBS thread]. <br />
<br />
{{Warning|<br />
* If you convert the system's root filesystem, ensure that the 'fallback' initramfs is available at reboot. Alternatively, add {{ic|ext4}} according to [[Mkinitcpio#MODULES]] and re-create the 'default' initial ramdisk with {{Ic|mkinitcpio -p linux}} before starting.<br />
* If you decide to convert a separate {{ic|/boot}} partition, ensure the [[bootloader]] supports booting from ext4.}}<br />
<br />
In the following steps {{Ic|/dev/sdxX}} denotes the path to the partition to be converted, such as {{Ic|/dev/sda1}}. <br />
<br />
# '''[[Backup programs|BACK-UP!]]''' Back-up all data on any ext3 partitions that are to be converted to ext4. A useful package, especially for root partitions, is [http://clonezilla.org Clonezilla].<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext3 to ext4 for any partitions that are to be converted to ext4.<br />
# Boot the live medium (if necessary). The conversion process with {{Pkg|e2fsprogs}} must be done when the drive is not mounted. If converting a root partition, the simplest way to achieve this is to boot from some other live medium.<br />
# Ensure the partition is '''NOT''' mounted<br />
# If you want to convert a ext2 partition, the first conversion step is to add a [[File systems#Journaling|journal]] by running {{ic|tune2fs -j /dev/sdxX}} as root; making it a ext3 partition. <br />
# Run {{Ic|tune2fs -O extent,uninit_bg,dir_index /dev/sdxX}} as root. This command converts the ext3 filesystem to ext4 (irreversibly). <br />
# Run {{Ic|fsck -f /dev/sdxX}} as root. <br />
#* The user '''must ''fsck''''' the filesystem, or it '''will be unreadable'''! This ''fsck'' run is needed to return the filesystem to a consistent state. It '''will''' find checksum errors in the group descriptors - this '''is''' expected. The {{ic|-f}} option asks ''fsck'' to force checking even if the file system seems clean. The {{ic|-p}} option may be used on top to 'automatically repair' (otherwise, the user will be asked for input for each error). <br />
# Recommended: mount the partition and run {{Ic|e4defrag -c -v /dev/sdxX}} as root.<br />
#* Even though the filesystem is now converted to ext4, all files that have been written before the conversion do not yet take advantage of the extent option of ext4, which will improve large file performance and reduce fragmentation and filesystem check time. In order to fully take advantage of ext4, all files would have to be rewritten on disk. Use ''e4defrag'' to take care of this problem.<br />
# Reboot Arch Linux!<br />
<br />
== Using ext4 per directory encryption == <br />
<br />
Linux comes with an Ext4 feature to encrypt directories of a filesystem. See also [http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html Quarkslab's blog] entry with a write-up of the features, an overview of the implementation state and practical test results with kernel 4.1. <br />
<br />
Encryption keys are stored in the keyring. To get started, make sure you have enabled {{ic|CONFIG_KEYS}} and {{ic|CONFIG_EXT4_ENCRYPTION}} kernel options and you have kernel 4.1 or higher. Note the Arch default {{Pkg|linux}} does not have {{ic|CONFIG_EXT4_ENCRYPTION}} set yet. <br />
<br />
First of all, you need to update {{Pkg|e2fsprogs}} to at least version 1.43.<br />
<br />
Let us make a directory that we will encrypt. Encryption policy can be set only on new empty directories. For example, if we are to encrypt {{ic|/encrypted/dir}}, create the upper level directory:<br />
<br />
# mkdir /encrypted<br />
<br />
First generate a random salt value and store it in a safe place:<br />
<br />
# head -c 16 /dev/random | xxd -p<br />
877282f53bd0adbbef92142fc4cac459<br />
<br />
Now generate and add a new key into your keyring:<br />
this step should be repeated every time you flush your keychain (reboot)<br />
<br />
# e4crypt add_key -S 0x877282f53bd0adbbef92142fc4cac459<br />
Enter passphrase (echo disabled): <br />
Added key with descriptor [f88747555a6115f5]<br />
<br />
Now you know a descriptor for your key.<br />
Make sure you have added a key into your keychain:<br />
<br />
# keyctl show<br />
Session Keyring<br />
1021618178 --alswrv 1000 1000 keyring: _ses<br />
176349519 --alsw-v 1000 1000 \_ logon: ext4:f88747555a6115f5<br />
<br />
Almost done. Now set an encryption policy for a directory:<br />
<br />
# e4crypt set_policy f88747555a6115f5 /encrypted/dir<br />
<br />
That is all. If you try accessing the disk without adding a key into keychain,<br />
filenames and their contents will be seen as encrypted gibberish. Be careful<br />
running old versions of e2fsck on your filesystem - it will treat encrypted<br />
filenames as invalid.<br />
<br />
== Tips and tricks ==<br />
<br />
=== E4rat ===<br />
<br />
[[E4rat]] is a preload application designed for the ext4 filesystem. It monitors files opened during boot, optimizes their placement on the partition to improve access time, and preloads them at the very beginning of the boot process. [[E4rat]] does not offer improvements with [[SSD]]s, whose access time is negligible compared to hard disks.<br />
<br />
=== Barriers and performance ===<br />
<br />
Since kernel 2.6.30, ext4 performance has decreased due to changes that serve to improve data integrity.[http://www.phoronix.com/scan.php?page=article&item=ext4_then_now&num=1]<br />
<br />
:Most file systems (XFS, ext3, ext4, reiserfs) send write barriers to disk after fsync or during transaction commits. Write barriers enforce proper ordering of writes, making volatile disk write caches safe to use (at some performance penalty). If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.<br />
<br />
:Sending write barriers can be disabled using the {{Ic|1=barrier=0}} mount option (for ext3, ext4, and reiserfs), or using the {{Ic|1=nobarrier}} mount option (for XFS).[http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning.io.html]{{dead link|2016|7|5}}<br />
<br />
{{Warning|Disabling barriers when disks cannot guarantee caches are properly written in case of power failure can lead to severe file system corruption and data loss.}}<br />
<br />
To turn barriers off add the option {{Ic|1=barrier=0}} to the desired filesystem. For example:<br />
<br />
{{hc|/etc/fstab|2=<br />
/dev/sda5 / ext4 noatime,barrier=0 0 1<br />
}}<br />
<br />
==Enabling metadata checksums==<br />
<br />
In both cases of enabling metadata checksums for new and existing filesystems, you will need to load some kernel modules.<br />
<br />
If your CPU supports SSE 4.2, make sure the {{Ic|crc32c_intel}} kernel module is loaded in order to enable the hardware accelerated CRC32C algorithm. If not you will need to load the {{Ic|crc32c_generic}} module.<br />
<br />
If this is the root file-system your {{Ic|crc32c_}} module might need to be added to {{Ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES="... crc32c_intel crc32c_generic"<br />
<br />
And then regenerate the initramfs. See [[Mkinitcpio#Image creation and activation]].<br />
<br />
After this, you are ready to enable support for metadata checksums as described in the following two sections. In both cases the device must not be mounted.<br />
<br />
More about metadata checksums can be [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums read here].<br />
<br />
=== New filesystem ===<br />
<br />
To enable support for ext4 metadata checksums on a new file system make sure that you have {{Ic|e2fsprogs 1.43}} or newer and simply do a:<br />
<br />
# mkfs.ext4 ''/dev/path/to/disk''<br />
<br />
The metadata_csum and 64bit options will be enabled by default. <br />
<br />
The file-system can then be mounted as usual.<br />
<br />
=== Existing filesystem ===<br />
<br />
To enable support on an existing ext4 file system do the following.<br />
<br />
This needs to be done with the partition unmounted, so if you want to convert the root, you'll need to run off an USB live distro.<br />
<br />
First the partition needs to be checked and optimized using:<br />
<br />
# e2fsck -D ''/dev/path/to/disk'' <br />
<br />
Then the file-system needs to be converted to 64bit:<br />
<br />
# resize2fs -b ''/dev/path/to/disk'' <br />
<br />
Finally checksums can be added<br />
<br />
# tune2fs -O metadata_csum ''/dev/path/to/disk''<br />
<br />
The file-system can then be mounted as usual.<br />
<br />
You can check whether the features were successfully enabled by running:<br />
<br />
# dumpe2fs ''/dev/path/to/disk''<br />
<br />
=== Impact on performance ===<br />
<br />
Keep in mind that the intel module consistently performs 10x faster than the generic one, peaking at 20x faster as can be seen in [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums#Benchmarking this benchmark].<br />
<br />
== See also ==<br />
<br />
* [https://ext4.wiki.kernel.org/ Official Ext4 wiki]<br />
* [https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout Ext4 Disk Layout] described in its wiki<br />
* [http://lwn.net/Articles/639427/ Ext4 Encryption] LWM article<br />
* Kernel commits for ext4 encryption [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6162e4b0bedeb3dac2ba0a5e1b1f56db107d97ec] [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8663da2c0919896788321cd8a0016af08588c656]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Ext4&diff=442899Ext42016-07-25T03:06:02Z<p>Wooptoo: Fix</p>
<hr />
<div>[[Category:File systems]]<br />
[[cs:Ext4]]<br />
[[de:Ext4]]<br />
[[es:Ext4]]<br />
[[fr:Ext4]]<br />
[[it:Ext4]]<br />
[[ja:Ext4]]<br />
[[ru:Ext4]]<br />
[[tr:Ext4]]<br />
[[zh-CN:Ext4]]<br />
{{Related articles start}}<br />
{{Related|File systems}}<br />
{{Related|Ext3}}<br />
{{Related articles end}}<br />
From [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies]:<br />
:Ext4 is the evolution of the most used Linux filesystem, Ext3. In many ways, Ext4 is a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding journaling to Ext2, but Ext4 modifies important data structures of the filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability, and features.<br />
<br />
== Create a new ext4 filesystem ==<br />
<br />
To format a partition do:<br />
<br />
# mkfs.ext4 /dev/''partition''<br />
<br />
{{Tip|See the mkfs.ext4 [[man page]] for more options; edit {{ic|/etc/mke2fs.conf}} to view/configure default options.}}<br />
<br />
=== Bytes-per-inode ratio ===<br />
<br />
From {{ic|man mkfs.ext4}}:<br />
<br />
:'''''mke2fs''' creates an inode for every ''bytes-per-inode'' bytes of space on the disk. The larger the ''bytes-per-inode'' ratio, the fewer inodes will be created.''<br />
<br />
Creating a new file, directory, symlink etc. requires at least one free [[Wikipedia:Inode|inode]]. If the inode count is too low, no file can be created on the filesystem even though there is still space left on it. <br />
<br />
Because it is not possible to change either the bytes-per-inode ratio or the inode count after the filesystem is created, {{ic|mkfs.ext4}} uses by default a rather low ratio of one inode every 16384 bytes (16 Kb) to avoid this situation.<br />
<br />
However, for partitions with size in the hundreds or thousands of GB and average file size in the megabyte range, this usually results in a much too large inode number because the number of files created never reaches the number of inodes.<br />
<br />
This results in a waste of disk space, because all those unused inodes each take up 256 bytes on the filesystem (this is also set in {{ic|/etc/mke2fs.conf}} but should not be changed). 256 * several millions = quite a few gigabytes wasted in unused inodes.<br />
<br />
This situation can be evaluated by comparing the {{ic|{I}Use%}} figures provided by {{ic|df}} and {{ic|df -i}}:<br />
<br />
{{hc|$ df -h /home|<br />
Filesystem Size Used Avail '''Use%''' Mounted on<br />
/dev/mapper/lvm-home 115G 56G 59G '''49%''' /home}}<br />
{{hc|$ df -hi /home|<br />
Filesystem Inodes IUsed IFree '''IUse%''' Mounted on<br />
/dev/mapper/lvm-home 1.8M 1.1K 1.8M '''1%''' /home}}<br />
<br />
To specify a different bytes-per-inode ratio, you can use the {{ic|-T ''usage-type''}} option which hints at the expected usage of the filesystem using types defined in {{ic|/etc/mke2fs.conf}}. Among those types are the bigger {{ic|largefile}} and {{ic|largefile4}} which offer more relevant ratios of one inode every 1 MiB and 4 MiB respectively. It can be used as such:<br />
<br />
# mkfs.ext4 -T largefile /dev/''device''<br />
<br />
The bytes-per-inode ratio can also be set directly via the {{ic|-i}} option: ''e.g.'' use {{ic|-i 2097152}} for a 2 MiB ratio and {{ic|-i 6291456}} for a 6 MiB ratio.<br />
<br />
{{Tip|Conversely, if you are setting up a partition dedicated to host millions of small files like emails or newsgroup items, you can use smaller ''usage-type'' values such as {{ic|news}} (one inode for every 4096 bytes) or {{ic|small}} (same plus smaller inode and block sizes).}}<br />
<br />
{{Warning|If you make a heavy use of symbolic links, make sure to keep the inode count high enough with a low bytes-per-inode ratio, because while not taking more space every new symbolic link consumes one new inode and therefore the filesystem may run out of them quickly.}}<br />
<br />
=== Reserved blocks ===<br />
<br />
By default, 5% of the filesystem blocks will be reserved for the super-user, to avoid fragmentation and "''allow root-owned daemons to continue to function correctly after non-privileged processes are prevented from writing to the filesystem''" (from {{ic|man mkfs.ext4}}).<br />
<br />
For modern high-capacity disks, this is higher than necessary if the partition is used as a long-term archive or not crucial to system operations (like {{ic|/home}}). See [http://www.redhat.com/archives/ext3-users/2009-January/msg00026.html this email] for the opinion of ext4 developer Ted Ts'o on reserved blocks.<br />
<br />
It is generally safe to reduce the percentage of reserved blocks to free up disk space when the partition is either:<br />
<br />
* Very large (for example > 50G)<br />
* Used as long-term archive, i.e., where files will not be deleted and created very often<br />
<br />
The {{ic|-m}} option of ext4-related utilities allows to specify the percentage of reserved blocks.<br />
<br />
To totally prevent reserving blocks upon filesystem creation, use:<br />
<br />
# mkfs.ext4 -m 0 /dev/''device''<br />
<br />
To reduce it to 1% afterwards, use:<br />
<br />
# tune2fs -m 1 /dev/''device''<br />
<br />
You can use {{ic|findmnt(8)}} to find the device name:<br />
<br />
$ findmnt ''/the/mount/point''<br />
<br />
==Migrating from ext2/ext3 to ext4==<br />
<br />
===Mounting ext2/ext3 partitions as ext4 without converting===<br />
<br />
====Rationale====<br />
<br />
A compromise between fully converting to ext4 and simply remaining with ext2/ext3 is to mount the partitions as ext4.<br />
<br />
'''Pros:'''<br />
* Compatibility (the filesystem can continue to be mounted as ext3) &ndash; This allows users to still read the filesystem from other operating systems without ext4 support (e.g. Windows with ext2/ext3 drivers)<br />
* Improved performance (though not as much as a fully-converted ext4 partition).[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Fewer features of ext4 are used (only those that do not change the disk format such as multiblock allocation and delayed allocation)<br />
<br />
{{Note|Except for the relative novelty of ext4 (which can be seen as a risk), '''there is no major drawback to this technique'''.}}<br />
<br />
====Procedure====<br />
<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext2/ext3 to ext4 for any partitions you would like to mount as ext4.<br />
# Re-mount the affected partitions.<br />
<br />
===Converting ext2/ext3 partitions to ext4===<br />
<br />
====Rationale====<br />
<br />
To experience the benefits of ext4, an irreversible conversion process must be completed.<br />
<br />
'''Pros:'''<br />
* Improved performance and new features.[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Partitions that contain mostly static files, such as a {{ic|/boot}} partition, may not benefit from the new features. Also, adding a journal (which is implied by moving a ext2 partition to ext3/4) always incurs performance overhead. <br />
* Irreversible (ext4 partitions cannot be 'downgraded' to ext2/ext3. It is, however, backwards compatible until extent and other unique options are enabled)<br />
<br />
====Procedure====<br />
<br />
These instructions were adapted from [http://ext4.wiki.kernel.org/index.php/Ext4_Howto Kernel documentation] and an [https://bbs.archlinux.org/viewtopic.php?id=61602 BBS thread]. <br />
<br />
{{Warning|<br />
* If you convert the system's root filesystem, ensure that the 'fallback' initramfs is available at reboot. Alternatively, add {{ic|ext4}} according to [[Mkinitcpio#MODULES]] and re-create the 'default' initial ramdisk with {{Ic|mkinitcpio -p linux}} before starting.<br />
* If you decide to convert a separate {{ic|/boot}} partition, ensure the [[bootloader]] supports booting from ext4.}}<br />
<br />
In the following steps {{Ic|/dev/sdxX}} denotes the path to the partition to be converted, such as {{Ic|/dev/sda1}}. <br />
<br />
# '''[[Backup programs|BACK-UP!]]''' Back-up all data on any ext3 partitions that are to be converted to ext4. A useful package, especially for root partitions, is [http://clonezilla.org Clonezilla].<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext3 to ext4 for any partitions that are to be converted to ext4.<br />
# Boot the live medium (if necessary). The conversion process with {{Pkg|e2fsprogs}} must be done when the drive is not mounted. If converting a root partition, the simplest way to achieve this is to boot from some other live medium.<br />
# Ensure the partition is '''NOT''' mounted<br />
# If you want to convert a ext2 partition, the first conversion step is to add a [[File systems#Journaling|journal]] by running {{ic|tune2fs -j /dev/sdxX}} as root; making it a ext3 partition. <br />
# Run {{Ic|tune2fs -O extent,uninit_bg,dir_index /dev/sdxX}} as root. This command converts the ext3 filesystem to ext4 (irreversibly). <br />
# Run {{Ic|fsck -f /dev/sdxX}} as root. <br />
#* The user '''must ''fsck''''' the filesystem, or it '''will be unreadable'''! This ''fsck'' run is needed to return the filesystem to a consistent state. It '''will''' find checksum errors in the group descriptors - this '''is''' expected. The {{ic|-f}} option asks ''fsck'' to force checking even if the file system seems clean. The {{ic|-p}} option may be used on top to 'automatically repair' (otherwise, the user will be asked for input for each error). <br />
# Recommended: mount the partition and run {{Ic|e4defrag -c -v /dev/sdxX}} as root.<br />
#* Even though the filesystem is now converted to ext4, all files that have been written before the conversion do not yet take advantage of the extent option of ext4, which will improve large file performance and reduce fragmentation and filesystem check time. In order to fully take advantage of ext4, all files would have to be rewritten on disk. Use ''e4defrag'' to take care of this problem.<br />
# Reboot Arch Linux!<br />
<br />
== Using ext4 per directory encryption == <br />
<br />
Linux comes with an Ext4 feature to encrypt directories of a filesystem. See also [http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html Quarkslab's blog] entry with a write-up of the features, an overview of the implementation state and practical test results with kernel 4.1. <br />
<br />
Encryption keys are stored in the keyring. To get started, make sure you have enabled {{ic|CONFIG_KEYS}} and {{ic|CONFIG_EXT4_ENCRYPTION}} kernel options and you have kernel 4.1 or higher. Note the Arch default {{Pkg|linux}} does not have {{ic|CONFIG_EXT4_ENCRYPTION}} set yet. <br />
<br />
First of all, you need to update {{Pkg|e2fsprogs}} to at least version 1.43.<br />
<br />
Let us make a directory that we will encrypt. Encryption policy can be set only on new empty directories. For example, if we are to encrypt {{ic|/encrypted/dir}}, create the upper level directory:<br />
<br />
# mkdir /encrypted<br />
<br />
First generate a random salt value and store it in a safe place:<br />
<br />
# head -c 16 /dev/random | xxd -p<br />
877282f53bd0adbbef92142fc4cac459<br />
<br />
Now generate and add a new key into your keyring:<br />
this step should be repeated every time you flush your keychain (reboot)<br />
<br />
# e4crypt add_key -S 0x877282f53bd0adbbef92142fc4cac459<br />
Enter passphrase (echo disabled): <br />
Added key with descriptor [f88747555a6115f5]<br />
<br />
Now you know a descriptor for your key.<br />
Make sure you have added a key into your keychain:<br />
<br />
# keyctl show<br />
Session Keyring<br />
1021618178 --alswrv 1000 1000 keyring: _ses<br />
176349519 --alsw-v 1000 1000 \_ logon: ext4:f88747555a6115f5<br />
<br />
Almost done. Now set an encryption policy for a directory:<br />
<br />
# e4crypt set_policy f88747555a6115f5 /encrypted/dir<br />
<br />
That is all. If you try accessing the disk without adding a key into keychain,<br />
filenames and their contents will be seen as encrypted gibberish. Be careful<br />
running old versions of e2fsck on your filesystem - it will treat encrypted<br />
filenames as invalid.<br />
<br />
== Tips and tricks ==<br />
<br />
=== E4rat ===<br />
<br />
[[E4rat]] is a preload application designed for the ext4 filesystem. It monitors files opened during boot, optimizes their placement on the partition to improve access time, and preloads them at the very beginning of the boot process. [[E4rat]] does not offer improvements with [[SSD]]s, whose access time is negligible compared to hard disks.<br />
<br />
=== Barriers and performance ===<br />
<br />
Since kernel 2.6.30, ext4 performance has decreased due to changes that serve to improve data integrity.[http://www.phoronix.com/scan.php?page=article&item=ext4_then_now&num=1]<br />
<br />
:Most file systems (XFS, ext3, ext4, reiserfs) send write barriers to disk after fsync or during transaction commits. Write barriers enforce proper ordering of writes, making volatile disk write caches safe to use (at some performance penalty). If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.<br />
<br />
:Sending write barriers can be disabled using the {{Ic|1=barrier=0}} mount option (for ext3, ext4, and reiserfs), or using the {{Ic|1=nobarrier}} mount option (for XFS).[http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning.io.html]{{dead link|2016|7|5}}<br />
<br />
{{Warning|Disabling barriers when disks cannot guarantee caches are properly written in case of power failure can lead to severe file system corruption and data loss.}}<br />
<br />
To turn barriers off add the option {{Ic|1=barrier=0}} to the desired filesystem. For example:<br />
<br />
{{hc|/etc/fstab|2=<br />
/dev/sda5 / ext4 noatime,barrier=0 0 1<br />
}}<br />
<br />
==Enabling metadata checksums==<br />
<br />
In both cases of enabling metadata checksums for new and existing filesystems, you will need to load some kernel modules.<br />
<br />
If your CPU supports SSE 4.2, make sure the {{Ic|crc32c_intel}} kernel module is loaded in order to enable the hardware accelerated CRC32C algorithm. If not you will need to load the {{Ic|crc32c_generic}} module.<br />
<br />
If this is the root file-system your {{Ic|crc32c_}} module might need to be added to {{Ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES="... crc32c_intel crc32c_generic"<br />
<br />
And then regenerate the initramfs. See [[Mkinitcpio#Image creation and activation]].<br />
<br />
After this, you are ready to enable support for metadata checksums as described in the following two sections. In both cases the device must not be mounted.<br />
<br />
More about metadata checksums can be [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums read here].<br />
<br />
=== New filesystem ===<br />
<br />
To enable support for ext4 metadata checksums on a new file system make sure that you have {{Ic|e2fsprogs 1.43}} or newer and simply do a:<br />
<br />
# mkfs.ext4 ''/dev/path/to/disk''<br />
<br />
The metadata_csum and 64bit options will be enabled by default. <br />
<br />
The file-system can then be mounted as usual.<br />
<br />
=== Existing filesystem ===<br />
<br />
To enable support on an existing ext4 file system do the following.<br />
<br />
This needs to be done with the partition unmounted, so if you want to convert the root, you'll need to run off an USB live distro.<br />
<br />
First the partition needs to be checked and optimized using:<br />
<br />
# e2fsck -D ''/dev/path/to/disk'' <br />
<br />
Then the file-system needs to be converted to 64bit:<br />
<br />
# resize2fs -b ''/dev/path/to/disk'' <br />
<br />
Finally checksums can be added<br />
<br />
# tune2fs -O metadata_csum ''/dev/path/to/disk''<br />
<br />
The file-system can then be mounted as usual.<br />
<br />
You can check whether the features were successfully enabled by running:<br />
<br />
# dumpe2fs ''/dev/path/to/disk''<br />
<br />
== See also ==<br />
<br />
* [https://ext4.wiki.kernel.org/ Official Ext4 wiki]<br />
* [https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout Ext4 Disk Layout] described in its wiki<br />
* [http://lwn.net/Articles/639427/ Ext4 Encryption] LWM article<br />
* Kernel commits for ext4 encryption [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6162e4b0bedeb3dac2ba0a5e1b1f56db107d97ec] [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8663da2c0919896788321cd8a0016af08588c656]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Ext4&diff=442897Ext42016-07-25T02:59:32Z<p>Wooptoo: Csum by default</p>
<hr />
<div>[[Category:File systems]]<br />
[[cs:Ext4]]<br />
[[de:Ext4]]<br />
[[es:Ext4]]<br />
[[fr:Ext4]]<br />
[[it:Ext4]]<br />
[[ja:Ext4]]<br />
[[ru:Ext4]]<br />
[[tr:Ext4]]<br />
[[zh-CN:Ext4]]<br />
{{Related articles start}}<br />
{{Related|File systems}}<br />
{{Related|Ext3}}<br />
{{Related articles end}}<br />
From [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies]:<br />
:Ext4 is the evolution of the most used Linux filesystem, Ext3. In many ways, Ext4 is a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding journaling to Ext2, but Ext4 modifies important data structures of the filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability, and features.<br />
<br />
== Create a new ext4 filesystem ==<br />
<br />
To format a partition do:<br />
<br />
# mkfs.ext4 /dev/''partition''<br />
<br />
{{Tip|See the mkfs.ext4 [[man page]] for more options; edit {{ic|/etc/mke2fs.conf}} to view/configure default options.}}<br />
<br />
=== Bytes-per-inode ratio ===<br />
<br />
From {{ic|man mkfs.ext4}}:<br />
<br />
:'''''mke2fs''' creates an inode for every ''bytes-per-inode'' bytes of space on the disk. The larger the ''bytes-per-inode'' ratio, the fewer inodes will be created.''<br />
<br />
Creating a new file, directory, symlink etc. requires at least one free [[Wikipedia:Inode|inode]]. If the inode count is too low, no file can be created on the filesystem even though there is still space left on it. <br />
<br />
Because it is not possible to change either the bytes-per-inode ratio or the inode count after the filesystem is created, {{ic|mkfs.ext4}} uses by default a rather low ratio of one inode every 16384 bytes (16 Kb) to avoid this situation.<br />
<br />
However, for partitions with size in the hundreds or thousands of GB and average file size in the megabyte range, this usually results in a much too large inode number because the number of files created never reaches the number of inodes.<br />
<br />
This results in a waste of disk space, because all those unused inodes each take up 256 bytes on the filesystem (this is also set in {{ic|/etc/mke2fs.conf}} but should not be changed). 256 * several millions = quite a few gigabytes wasted in unused inodes.<br />
<br />
This situation can be evaluated by comparing the {{ic|{I}Use%}} figures provided by {{ic|df}} and {{ic|df -i}}:<br />
<br />
{{hc|$ df -h /home|<br />
Filesystem Size Used Avail '''Use%''' Mounted on<br />
/dev/mapper/lvm-home 115G 56G 59G '''49%''' /home}}<br />
{{hc|$ df -hi /home|<br />
Filesystem Inodes IUsed IFree '''IUse%''' Mounted on<br />
/dev/mapper/lvm-home 1.8M 1.1K 1.8M '''1%''' /home}}<br />
<br />
To specify a different bytes-per-inode ratio, you can use the {{ic|-T ''usage-type''}} option which hints at the expected usage of the filesystem using types defined in {{ic|/etc/mke2fs.conf}}. Among those types are the bigger {{ic|largefile}} and {{ic|largefile4}} which offer more relevant ratios of one inode every 1 MiB and 4 MiB respectively. It can be used as such:<br />
<br />
# mkfs.ext4 -T largefile /dev/''device''<br />
<br />
The bytes-per-inode ratio can also be set directly via the {{ic|-i}} option: ''e.g.'' use {{ic|-i 2097152}} for a 2 MiB ratio and {{ic|-i 6291456}} for a 6 MiB ratio.<br />
<br />
{{Tip|Conversely, if you are setting up a partition dedicated to host millions of small files like emails or newsgroup items, you can use smaller ''usage-type'' values such as {{ic|news}} (one inode for every 4096 bytes) or {{ic|small}} (same plus smaller inode and block sizes).}}<br />
<br />
{{Warning|If you make a heavy use of symbolic links, make sure to keep the inode count high enough with a low bytes-per-inode ratio, because while not taking more space every new symbolic link consumes one new inode and therefore the filesystem may run out of them quickly.}}<br />
<br />
=== Reserved blocks ===<br />
<br />
By default, 5% of the filesystem blocks will be reserved for the super-user, to avoid fragmentation and "''allow root-owned daemons to continue to function correctly after non-privileged processes are prevented from writing to the filesystem''" (from {{ic|man mkfs.ext4}}).<br />
<br />
For modern high-capacity disks, this is higher than necessary if the partition is used as a long-term archive or not crucial to system operations (like {{ic|/home}}). See [http://www.redhat.com/archives/ext3-users/2009-January/msg00026.html this email] for the opinion of ext4 developer Ted Ts'o on reserved blocks.<br />
<br />
It is generally safe to reduce the percentage of reserved blocks to free up disk space when the partition is either:<br />
<br />
* Very large (for example > 50G)<br />
* Used as long-term archive, i.e., where files will not be deleted and created very often<br />
<br />
The {{ic|-m}} option of ext4-related utilities allows to specify the percentage of reserved blocks.<br />
<br />
To totally prevent reserving blocks upon filesystem creation, use:<br />
<br />
# mkfs.ext4 -m 0 /dev/''device''<br />
<br />
To reduce it to 1% afterwards, use:<br />
<br />
# tune2fs -m 1 /dev/''device''<br />
<br />
You can use {{ic|findmnt(8)}} to find the device name:<br />
<br />
$ findmnt ''/the/mount/point''<br />
<br />
==Migrating from ext2/ext3 to ext4==<br />
<br />
===Mounting ext2/ext3 partitions as ext4 without converting===<br />
<br />
====Rationale====<br />
<br />
A compromise between fully converting to ext4 and simply remaining with ext2/ext3 is to mount the partitions as ext4.<br />
<br />
'''Pros:'''<br />
* Compatibility (the filesystem can continue to be mounted as ext3) &ndash; This allows users to still read the filesystem from other operating systems without ext4 support (e.g. Windows with ext2/ext3 drivers)<br />
* Improved performance (though not as much as a fully-converted ext4 partition).[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Fewer features of ext4 are used (only those that do not change the disk format such as multiblock allocation and delayed allocation)<br />
<br />
{{Note|Except for the relative novelty of ext4 (which can be seen as a risk), '''there is no major drawback to this technique'''.}}<br />
<br />
====Procedure====<br />
<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext2/ext3 to ext4 for any partitions you would like to mount as ext4.<br />
# Re-mount the affected partitions.<br />
<br />
===Converting ext2/ext3 partitions to ext4===<br />
<br />
====Rationale====<br />
<br />
To experience the benefits of ext4, an irreversible conversion process must be completed.<br />
<br />
'''Pros:'''<br />
* Improved performance and new features.[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Partitions that contain mostly static files, such as a {{ic|/boot}} partition, may not benefit from the new features. Also, adding a journal (which is implied by moving a ext2 partition to ext3/4) always incurs performance overhead. <br />
* Irreversible (ext4 partitions cannot be 'downgraded' to ext2/ext3. It is, however, backwards compatible until extent and other unique options are enabled)<br />
<br />
====Procedure====<br />
<br />
These instructions were adapted from [http://ext4.wiki.kernel.org/index.php/Ext4_Howto Kernel documentation] and an [https://bbs.archlinux.org/viewtopic.php?id=61602 BBS thread]. <br />
<br />
{{Warning|<br />
* If you convert the system's root filesystem, ensure that the 'fallback' initramfs is available at reboot. Alternatively, add {{ic|ext4}} according to [[Mkinitcpio#MODULES]] and re-create the 'default' initial ramdisk with {{Ic|mkinitcpio -p linux}} before starting.<br />
* If you decide to convert a separate {{ic|/boot}} partition, ensure the [[bootloader]] supports booting from ext4.}}<br />
<br />
In the following steps {{Ic|/dev/sdxX}} denotes the path to the partition to be converted, such as {{Ic|/dev/sda1}}. <br />
<br />
# '''[[Backup programs|BACK-UP!]]''' Back-up all data on any ext3 partitions that are to be converted to ext4. A useful package, especially for root partitions, is [http://clonezilla.org Clonezilla].<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext3 to ext4 for any partitions that are to be converted to ext4.<br />
# Boot the live medium (if necessary). The conversion process with {{Pkg|e2fsprogs}} must be done when the drive is not mounted. If converting a root partition, the simplest way to achieve this is to boot from some other live medium.<br />
# Ensure the partition is '''NOT''' mounted<br />
# If you want to convert a ext2 partition, the first conversion step is to add a [[File systems#Journaling|journal]] by running {{ic|tune2fs -j /dev/sdxX}} as root; making it a ext3 partition. <br />
# Run {{Ic|tune2fs -O extent,uninit_bg,dir_index /dev/sdxX}} as root. This command converts the ext3 filesystem to ext4 (irreversibly). <br />
# Run {{Ic|fsck -f /dev/sdxX}} as root. <br />
#* The user '''must ''fsck''''' the filesystem, or it '''will be unreadable'''! This ''fsck'' run is needed to return the filesystem to a consistent state. It '''will''' find checksum errors in the group descriptors - this '''is''' expected. The {{ic|-f}} option asks ''fsck'' to force checking even if the file system seems clean. The {{ic|-p}} option may be used on top to 'automatically repair' (otherwise, the user will be asked for input for each error). <br />
# Recommended: mount the partition and run {{Ic|e4defrag -c -v /dev/sdxX}} as root.<br />
#* Even though the filesystem is now converted to ext4, all files that have been written before the conversion do not yet take advantage of the extent option of ext4, which will improve large file performance and reduce fragmentation and filesystem check time. In order to fully take advantage of ext4, all files would have to be rewritten on disk. Use ''e4defrag'' to take care of this problem.<br />
# Reboot Arch Linux!<br />
<br />
== Using ext4 per directory encryption == <br />
<br />
Linux comes with an Ext4 feature to encrypt directories of a filesystem. See also [http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html Quarkslab's blog] entry with a write-up of the features, an overview of the implementation state and practical test results with kernel 4.1. <br />
<br />
Encryption keys are stored in the keyring. To get started, make sure you have enabled {{ic|CONFIG_KEYS}} and {{ic|CONFIG_EXT4_ENCRYPTION}} kernel options and you have kernel 4.1 or higher. Note the Arch default {{Pkg|linux}} does not have {{ic|CONFIG_EXT4_ENCRYPTION}} set yet. <br />
<br />
First of all, you need to update {{Pkg|e2fsprogs}} to at least version 1.43.<br />
<br />
Let us make a directory that we will encrypt. Encryption policy can be set only on new empty directories. For example, if we are to encrypt {{ic|/encrypted/dir}}, create the upper level directory:<br />
<br />
# mkdir /encrypted<br />
<br />
First generate a random salt value and store it in a safe place:<br />
<br />
# head -c 16 /dev/random | xxd -p<br />
877282f53bd0adbbef92142fc4cac459<br />
<br />
Now generate and add a new key into your keyring:<br />
this step should be repeated every time you flush your keychain (reboot)<br />
<br />
# e4crypt add_key -S 0x877282f53bd0adbbef92142fc4cac459<br />
Enter passphrase (echo disabled): <br />
Added key with descriptor [f88747555a6115f5]<br />
<br />
Now you know a descriptor for your key.<br />
Make sure you have added a key into your keychain:<br />
<br />
# keyctl show<br />
Session Keyring<br />
1021618178 --alswrv 1000 1000 keyring: _ses<br />
176349519 --alsw-v 1000 1000 \_ logon: ext4:f88747555a6115f5<br />
<br />
Almost done. Now set an encryption policy for a directory:<br />
<br />
# e4crypt set_policy f88747555a6115f5 /encrypted/dir<br />
<br />
That is all. If you try accessing the disk without adding a key into keychain,<br />
filenames and their contents will be seen as encrypted gibberish. Be careful<br />
running old versions of e2fsck on your filesystem - it will treat encrypted<br />
filenames as invalid.<br />
<br />
== Tips and tricks ==<br />
<br />
=== E4rat ===<br />
<br />
[[E4rat]] is a preload application designed for the ext4 filesystem. It monitors files opened during boot, optimizes their placement on the partition to improve access time, and preloads them at the very beginning of the boot process. [[E4rat]] does not offer improvements with [[SSD]]s, whose access time is negligible compared to hard disks.<br />
<br />
=== Barriers and performance ===<br />
<br />
Since kernel 2.6.30, ext4 performance has decreased due to changes that serve to improve data integrity.[http://www.phoronix.com/scan.php?page=article&item=ext4_then_now&num=1]<br />
<br />
:Most file systems (XFS, ext3, ext4, reiserfs) send write barriers to disk after fsync or during transaction commits. Write barriers enforce proper ordering of writes, making volatile disk write caches safe to use (at some performance penalty). If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.<br />
<br />
:Sending write barriers can be disabled using the {{Ic|1=barrier=0}} mount option (for ext3, ext4, and reiserfs), or using the {{Ic|1=nobarrier}} mount option (for XFS).[http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning.io.html]{{dead link|2016|7|5}}<br />
<br />
{{Warning|Disabling barriers when disks cannot guarantee caches are properly written in case of power failure can lead to severe file system corruption and data loss.}}<br />
<br />
To turn barriers off add the option {{Ic|1=barrier=0}} to the desired filesystem. For example:<br />
<br />
{{hc|/etc/fstab|2=<br />
/dev/sda5 / ext4 noatime,barrier=0 0 1<br />
}}<br />
<br />
==Enabling metadata checksums==<br />
<br />
In both cases of enabling metadata checksums for new and existing filesystems, you will need to load some kernel modules.<br />
<br />
If your CPU supports SSE 4.2, make sure the {{Ic|crc32c_intel}} kernel module is loaded in order to enable the hardware accelerated CRC32C algorithm. If not you will need to load the {{Ic|crc32c_generic}} module.<br />
<br />
If this is the root file-system your {{Ic|crc32c_}} module might need to be added to {{Ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES="... crc32c_intel crc32c_generic"<br />
<br />
And then regenerate the initramfs. See [[Mkinitcpio#Image creation and activation]].<br />
<br />
After this, you are ready to enable support for metadata checksums as described in the following two sections. In both cases the device must not be mounted.<br />
<br />
More about metadata checksums can be [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums read here].<br />
<br />
=== New filesystem ===<br />
<br />
To enable support for ext4 metadata checksums on a new file system make sure that you have {{Ic|e2fsprogs >= 1.43}} and simply do a:<br />
<br />
# mkfs.ext4 ''/dev/path/to/disk''<br />
<br />
The metadata_csum and 64bit options will be enabled by default. <br />
<br />
The file-system can then be mounted as usual.<br />
<br />
=== Existing filesystem ===<br />
<br />
To enable support on an existing ext4 file system do the following.<br />
<br />
This needs to be done with the partition unmounted, so if you want to convert the root, you'll need to run off an USB live distro.<br />
<br />
First the partition needs to be checked and optimized using:<br />
<br />
# e2fsck -D ''/dev/path/to/disk'' <br />
<br />
Then the file-system needs to be converted to 64bit:<br />
<br />
# resize2fs -b ''/dev/path/to/disk'' <br />
<br />
Finally checksums can be added<br />
<br />
# tune2fs -O metadata_csum ''/dev/path/to/disk''<br />
<br />
The file-system can then be mounted as usual.<br />
<br />
== See also ==<br />
<br />
* [https://ext4.wiki.kernel.org/ Official Ext4 wiki]<br />
* [https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout Ext4 Disk Layout] described in its wiki<br />
* [http://lwn.net/Articles/639427/ Ext4 Encryption] LWM article<br />
* Kernel commits for ext4 encryption [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6162e4b0bedeb3dac2ba0a5e1b1f56db107d97ec] [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8663da2c0919896788321cd8a0016af08588c656]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Ext4&diff=442869Ext42016-07-24T21:33:37Z<p>Wooptoo: mkinitcpio module</p>
<hr />
<div>[[Category:File systems]]<br />
[[cs:Ext4]]<br />
[[de:Ext4]]<br />
[[es:Ext4]]<br />
[[fr:Ext4]]<br />
[[it:Ext4]]<br />
[[ja:Ext4]]<br />
[[ru:Ext4]]<br />
[[tr:Ext4]]<br />
[[zh-CN:Ext4]]<br />
{{Related articles start}}<br />
{{Related|File systems}}<br />
{{Related|Ext3}}<br />
{{Related articles end}}<br />
From [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies]:<br />
:Ext4 is the evolution of the most used Linux filesystem, Ext3. In many ways, Ext4 is a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding journaling to Ext2, but Ext4 modifies important data structures of the filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability, and features.<br />
<br />
== Create a new ext4 filesystem ==<br />
<br />
To format a partition do:<br />
<br />
# mkfs.ext4 /dev/''partition''<br />
<br />
{{Tip|See the mkfs.ext4 [[man page]] for more options; edit {{ic|/etc/mke2fs.conf}} to view/configure default options.}}<br />
<br />
=== Bytes-per-inode ratio ===<br />
<br />
From {{ic|man mkfs.ext4}}:<br />
<br />
:'''''mke2fs''' creates an inode for every ''bytes-per-inode'' bytes of space on the disk. The larger the ''bytes-per-inode'' ratio, the fewer inodes will be created.''<br />
<br />
Creating a new file, directory, symlink etc. requires at least one free [[Wikipedia:Inode|inode]]. If the inode count is too low, no file can be created on the filesystem even though there is still space left on it. <br />
<br />
Because it is not possible to change either the bytes-per-inode ratio or the inode count after the filesystem is created, {{ic|mkfs.ext4}} uses by default a rather low ratio of one inode every 16384 bytes (16 Kb) to avoid this situation.<br />
<br />
However, for partitions with size in the hundreds or thousands of GB and average file size in the megabyte range, this usually results in a much too large inode number because the number of files created never reaches the number of inodes.<br />
<br />
This results in a waste of disk space, because all those unused inodes each take up 256 bytes on the filesystem (this is also set in {{ic|/etc/mke2fs.conf}} but should not be changed). 256 * several millions = quite a few gigabytes wasted in unused inodes.<br />
<br />
This situation can be evaluated by comparing the {{ic|{I}Use%}} figures provided by {{ic|df}} and {{ic|df -i}}:<br />
<br />
{{hc|$ df -h /home|<br />
Filesystem Size Used Avail '''Use%''' Mounted on<br />
/dev/mapper/lvm-home 115G 56G 59G '''49%''' /home}}<br />
{{hc|$ df -hi /home|<br />
Filesystem Inodes IUsed IFree '''IUse%''' Mounted on<br />
/dev/mapper/lvm-home 1.8M 1.1K 1.8M '''1%''' /home}}<br />
<br />
To specify a different bytes-per-inode ratio, you can use the {{ic|-T ''usage-type''}} option which hints at the expected usage of the filesystem using types defined in {{ic|/etc/mke2fs.conf}}. Among those types are the bigger {{ic|largefile}} and {{ic|largefile4}} which offer more relevant ratios of one inode every 1 MiB and 4 MiB respectively. It can be used as such:<br />
<br />
# mkfs.ext4 -T largefile /dev/''device''<br />
<br />
The bytes-per-inode ratio can also be set directly via the {{ic|-i}} option: ''e.g.'' use {{ic|-i 2097152}} for a 2 MiB ratio and {{ic|-i 6291456}} for a 6 MiB ratio.<br />
<br />
{{Tip|Conversely, if you are setting up a partition dedicated to host millions of small files like emails or newsgroup items, you can use smaller ''usage-type'' values such as {{ic|news}} (one inode for every 4096 bytes) or {{ic|small}} (same plus smaller inode and block sizes).}}<br />
<br />
{{Warning|If you make a heavy use of symbolic links, make sure to keep the inode count high enough with a low bytes-per-inode ratio, because while not taking more space every new symbolic link consumes one new inode and therefore the filesystem may run out of them quickly.}}<br />
<br />
=== Reserved blocks ===<br />
<br />
By default, 5% of the filesystem blocks will be reserved for the super-user, to avoid fragmentation and "''allow root-owned daemons to continue to function correctly after non-privileged processes are prevented from writing to the filesystem''" (from {{ic|man mkfs.ext4}}).<br />
<br />
For modern high-capacity disks, this is higher than necessary if the partition is used as a long-term archive or not crucial to system operations (like {{ic|/home}}). See [http://www.redhat.com/archives/ext3-users/2009-January/msg00026.html this email] for the opinion of ext4 developer Ted Ts'o on reserved blocks.<br />
<br />
It is generally safe to reduce the percentage of reserved blocks to free up disk space when the partition is either:<br />
<br />
* Very large (for example > 50G)<br />
* Used as long-term archive, i.e., where files will not be deleted and created very often<br />
<br />
The {{ic|-m}} option of ext4-related utilities allows to specify the percentage of reserved blocks.<br />
<br />
To totally prevent reserving blocks upon filesystem creation, use:<br />
<br />
# mkfs.ext4 -m 0 /dev/''device''<br />
<br />
To reduce it to 1% afterwards, use:<br />
<br />
# tune2fs -m 1 /dev/''device''<br />
<br />
You can use {{ic|findmnt(8)}} to find the device name:<br />
<br />
$ findmnt ''/the/mount/point''<br />
<br />
==Migrating from ext2/ext3 to ext4==<br />
<br />
===Mounting ext2/ext3 partitions as ext4 without converting===<br />
<br />
====Rationale====<br />
<br />
A compromise between fully converting to ext4 and simply remaining with ext2/ext3 is to mount the partitions as ext4.<br />
<br />
'''Pros:'''<br />
* Compatibility (the filesystem can continue to be mounted as ext3) &ndash; This allows users to still read the filesystem from other operating systems without ext4 support (e.g. Windows with ext2/ext3 drivers)<br />
* Improved performance (though not as much as a fully-converted ext4 partition).[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Fewer features of ext4 are used (only those that do not change the disk format such as multiblock allocation and delayed allocation)<br />
<br />
{{Note|Except for the relative novelty of ext4 (which can be seen as a risk), '''there is no major drawback to this technique'''.}}<br />
<br />
====Procedure====<br />
<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext2/ext3 to ext4 for any partitions you would like to mount as ext4.<br />
# Re-mount the affected partitions.<br />
<br />
===Converting ext2/ext3 partitions to ext4===<br />
<br />
====Rationale====<br />
<br />
To experience the benefits of ext4, an irreversible conversion process must be completed.<br />
<br />
'''Pros:'''<br />
* Improved performance and new features.[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Partitions that contain mostly static files, such as a {{ic|/boot}} partition, may not benefit from the new features. Also, adding a journal (which is implied by moving a ext2 partition to ext3/4) always incurs performance overhead. <br />
* Irreversible (ext4 partitions cannot be 'downgraded' to ext2/ext3. It is, however, backwards compatible until extent and other unique options are enabled)<br />
<br />
====Procedure====<br />
<br />
These instructions were adapted from [http://ext4.wiki.kernel.org/index.php/Ext4_Howto Kernel documentation] and an [https://bbs.archlinux.org/viewtopic.php?id=61602 BBS thread]. <br />
<br />
{{Warning|<br />
* If you convert the system's root filesystem, ensure that the 'fallback' initramfs is available at reboot. Alternatively, add {{ic|ext4}} according to [[Mkinitcpio#MODULES]] and re-create the 'default' initial ramdisk with {{Ic|mkinitcpio -p linux}} before starting.<br />
* If you decide to convert a separate {{ic|/boot}} partition, ensure the [[bootloader]] supports booting from ext4.}}<br />
<br />
In the following steps {{Ic|/dev/sdxX}} denotes the path to the partition to be converted, such as {{Ic|/dev/sda1}}. <br />
<br />
# '''[[Backup programs|BACK-UP!]]''' Back-up all data on any ext3 partitions that are to be converted to ext4. A useful package, especially for root partitions, is [http://clonezilla.org Clonezilla].<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext3 to ext4 for any partitions that are to be converted to ext4.<br />
# Boot the live medium (if necessary). The conversion process with {{Pkg|e2fsprogs}} must be done when the drive is not mounted. If converting a root partition, the simplest way to achieve this is to boot from some other live medium.<br />
# Ensure the partition is '''NOT''' mounted<br />
# If you want to convert a ext2 partition, the first conversion step is to add a [[File systems#Journaling|journal]] by running {{ic|tune2fs -j /dev/sdxX}} as root; making it a ext3 partition. <br />
# Run {{Ic|tune2fs -O extent,uninit_bg,dir_index /dev/sdxX}} as root. This command converts the ext3 filesystem to ext4 (irreversibly). <br />
# Run {{Ic|fsck -f /dev/sdxX}} as root. <br />
#* The user '''must ''fsck''''' the filesystem, or it '''will be unreadable'''! This ''fsck'' run is needed to return the filesystem to a consistent state. It '''will''' find checksum errors in the group descriptors - this '''is''' expected. The {{ic|-f}} option asks ''fsck'' to force checking even if the file system seems clean. The {{ic|-p}} option may be used on top to 'automatically repair' (otherwise, the user will be asked for input for each error). <br />
# Recommended: mount the partition and run {{Ic|e4defrag -c -v /dev/sdxX}} as root.<br />
#* Even though the filesystem is now converted to ext4, all files that have been written before the conversion do not yet take advantage of the extent option of ext4, which will improve large file performance and reduce fragmentation and filesystem check time. In order to fully take advantage of ext4, all files would have to be rewritten on disk. Use ''e4defrag'' to take care of this problem.<br />
# Reboot Arch Linux!<br />
<br />
== Using ext4 per directory encryption == <br />
<br />
Linux comes with an Ext4 feature to encrypt directories of a filesystem. See also [http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html Quarkslab's blog] entry with a write-up of the features, an overview of the implementation state and practical test results with kernel 4.1. <br />
<br />
Encryption keys are stored in the keyring. To get started, make sure you have enabled {{ic|CONFIG_KEYS}} and {{ic|CONFIG_EXT4_ENCRYPTION}} kernel options and you have kernel 4.1 or higher. Note the Arch default {{Pkg|linux}} does not have {{ic|CONFIG_EXT4_ENCRYPTION}} set yet. <br />
<br />
First of all, you need to update {{Pkg|e2fsprogs}} to at least version 1.43.<br />
<br />
Let us make a directory that we will encrypt. Encryption policy can be set only on new empty directories. For example, if we are to encrypt {{ic|/encrypted/dir}}, create the upper level directory:<br />
<br />
# mkdir /encrypted<br />
<br />
First generate a random salt value and store it in a safe place:<br />
<br />
# head -c 16 /dev/random | xxd -p<br />
877282f53bd0adbbef92142fc4cac459<br />
<br />
Now generate and add a new key into your keyring:<br />
this step should be repeated every time you flush your keychain (reboot)<br />
<br />
# e4crypt add_key -S 0x877282f53bd0adbbef92142fc4cac459<br />
Enter passphrase (echo disabled): <br />
Added key with descriptor [f88747555a6115f5]<br />
<br />
Now you know a descriptor for your key.<br />
Make sure you have added a key into your keychain:<br />
<br />
# keyctl show<br />
Session Keyring<br />
1021618178 --alswrv 1000 1000 keyring: _ses<br />
176349519 --alsw-v 1000 1000 \_ logon: ext4:f88747555a6115f5<br />
<br />
Almost done. Now set an encryption policy for a directory:<br />
<br />
# e4crypt set_policy f88747555a6115f5 /encrypted/dir<br />
<br />
That is all. If you try accessing the disk without adding a key into keychain,<br />
filenames and their contents will be seen as encrypted gibberish. Be careful<br />
running old versions of e2fsck on your filesystem - it will treat encrypted<br />
filenames as invalid.<br />
<br />
== Tips and tricks ==<br />
<br />
=== E4rat ===<br />
<br />
[[E4rat]] is a preload application designed for the ext4 filesystem. It monitors files opened during boot, optimizes their placement on the partition to improve access time, and preloads them at the very beginning of the boot process. [[E4rat]] does not offer improvements with [[SSD]]s, whose access time is negligible compared to hard disks.<br />
<br />
=== Barriers and performance ===<br />
<br />
Since kernel 2.6.30, ext4 performance has decreased due to changes that serve to improve data integrity.[http://www.phoronix.com/scan.php?page=article&item=ext4_then_now&num=1]<br />
<br />
:Most file systems (XFS, ext3, ext4, reiserfs) send write barriers to disk after fsync or during transaction commits. Write barriers enforce proper ordering of writes, making volatile disk write caches safe to use (at some performance penalty). If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.<br />
<br />
:Sending write barriers can be disabled using the {{Ic|1=barrier=0}} mount option (for ext3, ext4, and reiserfs), or using the {{Ic|1=nobarrier}} mount option (for XFS).[http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning.io.html]{{dead link|2016|7|5}}<br />
<br />
{{Warning|Disabling barriers when disks cannot guarantee caches are properly written in case of power failure can lead to severe file system corruption and data loss.}}<br />
<br />
To turn barriers off add the option {{Ic|1=barrier=0}} to the desired filesystem. For example:<br />
<br />
{{hc|/etc/fstab|2=<br />
/dev/sda5 / ext4 noatime,barrier=0 0 1<br />
}}<br />
<br />
==Enabling metadata checksums==<br />
<br />
Starting with [http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.43 e2fsprogs 1.43] we can safely enable support for ext4 checksums and 64bit.<br />
More about metadata checksums can be [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums read here].<br />
<br />
If your CPU supports SSE 4.2, make sure the {{Ic|crc32c_intel}} kernel module is loaded in order to enable the hardware accelerated CRC32C algorithm. If not you'll need to load the {{Ic|crc32c_generic}} module.<br />
<br />
This needs to be done with the partition unmounted, so if you want to convert the root, you'll need to run off an USB live distro.<br />
<br />
First the partition needs to be checked and optimized using {{Ic |e2fsck -D /dev/sdX}}. <br />
<br />
Then the file-system needs to be converted to 64bit: {{Ic |resize2fs -b /dev/sdX}}. <br />
<br />
Finally checksums can be added: {{Ic |tune2fs -O metadata_csum /dev/sdX}}.<br />
<br />
<br />
The file-system can then be mounted as usual.<br />
If this is the root file-system your {{Ic|crc32c_}} module might need to be added to {{Ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES="... crc32c_intel crc32c_generic"<br />
<br />
And then regenerate the kernel image using {{Ic|mkinitcpio -p linux}}.<br />
<br />
== See also ==<br />
<br />
* [https://ext4.wiki.kernel.org/ Official Ext4 wiki]<br />
* [https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout Ext4 Disk Layout] described in its wiki<br />
* [http://lwn.net/Articles/639427/ Ext4 Encryption] LWM article<br />
* Kernel commits for ext4 encryption [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6162e4b0bedeb3dac2ba0a5e1b1f56db107d97ec] [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8663da2c0919896788321cd8a0016af08588c656]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Ext4&diff=442868Ext42016-07-24T21:31:43Z<p>Wooptoo: Enabling metadata checksums</p>
<hr />
<div>[[Category:File systems]]<br />
[[cs:Ext4]]<br />
[[de:Ext4]]<br />
[[es:Ext4]]<br />
[[fr:Ext4]]<br />
[[it:Ext4]]<br />
[[ja:Ext4]]<br />
[[ru:Ext4]]<br />
[[tr:Ext4]]<br />
[[zh-CN:Ext4]]<br />
{{Related articles start}}<br />
{{Related|File systems}}<br />
{{Related|Ext3}}<br />
{{Related articles end}}<br />
From [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies]:<br />
:Ext4 is the evolution of the most used Linux filesystem, Ext3. In many ways, Ext4 is a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding journaling to Ext2, but Ext4 modifies important data structures of the filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability, and features.<br />
<br />
== Create a new ext4 filesystem ==<br />
<br />
To format a partition do:<br />
<br />
# mkfs.ext4 /dev/''partition''<br />
<br />
{{Tip|See the mkfs.ext4 [[man page]] for more options; edit {{ic|/etc/mke2fs.conf}} to view/configure default options.}}<br />
<br />
=== Bytes-per-inode ratio ===<br />
<br />
From {{ic|man mkfs.ext4}}:<br />
<br />
:'''''mke2fs''' creates an inode for every ''bytes-per-inode'' bytes of space on the disk. The larger the ''bytes-per-inode'' ratio, the fewer inodes will be created.''<br />
<br />
Creating a new file, directory, symlink etc. requires at least one free [[Wikipedia:Inode|inode]]. If the inode count is too low, no file can be created on the filesystem even though there is still space left on it. <br />
<br />
Because it is not possible to change either the bytes-per-inode ratio or the inode count after the filesystem is created, {{ic|mkfs.ext4}} uses by default a rather low ratio of one inode every 16384 bytes (16 Kb) to avoid this situation.<br />
<br />
However, for partitions with size in the hundreds or thousands of GB and average file size in the megabyte range, this usually results in a much too large inode number because the number of files created never reaches the number of inodes.<br />
<br />
This results in a waste of disk space, because all those unused inodes each take up 256 bytes on the filesystem (this is also set in {{ic|/etc/mke2fs.conf}} but should not be changed). 256 * several millions = quite a few gigabytes wasted in unused inodes.<br />
<br />
This situation can be evaluated by comparing the {{ic|{I}Use%}} figures provided by {{ic|df}} and {{ic|df -i}}:<br />
<br />
{{hc|$ df -h /home|<br />
Filesystem Size Used Avail '''Use%''' Mounted on<br />
/dev/mapper/lvm-home 115G 56G 59G '''49%''' /home}}<br />
{{hc|$ df -hi /home|<br />
Filesystem Inodes IUsed IFree '''IUse%''' Mounted on<br />
/dev/mapper/lvm-home 1.8M 1.1K 1.8M '''1%''' /home}}<br />
<br />
To specify a different bytes-per-inode ratio, you can use the {{ic|-T ''usage-type''}} option which hints at the expected usage of the filesystem using types defined in {{ic|/etc/mke2fs.conf}}. Among those types are the bigger {{ic|largefile}} and {{ic|largefile4}} which offer more relevant ratios of one inode every 1 MiB and 4 MiB respectively. It can be used as such:<br />
<br />
# mkfs.ext4 -T largefile /dev/''device''<br />
<br />
The bytes-per-inode ratio can also be set directly via the {{ic|-i}} option: ''e.g.'' use {{ic|-i 2097152}} for a 2 MiB ratio and {{ic|-i 6291456}} for a 6 MiB ratio.<br />
<br />
{{Tip|Conversely, if you are setting up a partition dedicated to host millions of small files like emails or newsgroup items, you can use smaller ''usage-type'' values such as {{ic|news}} (one inode for every 4096 bytes) or {{ic|small}} (same plus smaller inode and block sizes).}}<br />
<br />
{{Warning|If you make a heavy use of symbolic links, make sure to keep the inode count high enough with a low bytes-per-inode ratio, because while not taking more space every new symbolic link consumes one new inode and therefore the filesystem may run out of them quickly.}}<br />
<br />
=== Reserved blocks ===<br />
<br />
By default, 5% of the filesystem blocks will be reserved for the super-user, to avoid fragmentation and "''allow root-owned daemons to continue to function correctly after non-privileged processes are prevented from writing to the filesystem''" (from {{ic|man mkfs.ext4}}).<br />
<br />
For modern high-capacity disks, this is higher than necessary if the partition is used as a long-term archive or not crucial to system operations (like {{ic|/home}}). See [http://www.redhat.com/archives/ext3-users/2009-January/msg00026.html this email] for the opinion of ext4 developer Ted Ts'o on reserved blocks.<br />
<br />
It is generally safe to reduce the percentage of reserved blocks to free up disk space when the partition is either:<br />
<br />
* Very large (for example > 50G)<br />
* Used as long-term archive, i.e., where files will not be deleted and created very often<br />
<br />
The {{ic|-m}} option of ext4-related utilities allows to specify the percentage of reserved blocks.<br />
<br />
To totally prevent reserving blocks upon filesystem creation, use:<br />
<br />
# mkfs.ext4 -m 0 /dev/''device''<br />
<br />
To reduce it to 1% afterwards, use:<br />
<br />
# tune2fs -m 1 /dev/''device''<br />
<br />
You can use {{ic|findmnt(8)}} to find the device name:<br />
<br />
$ findmnt ''/the/mount/point''<br />
<br />
==Migrating from ext2/ext3 to ext4==<br />
<br />
===Mounting ext2/ext3 partitions as ext4 without converting===<br />
<br />
====Rationale====<br />
<br />
A compromise between fully converting to ext4 and simply remaining with ext2/ext3 is to mount the partitions as ext4.<br />
<br />
'''Pros:'''<br />
* Compatibility (the filesystem can continue to be mounted as ext3) &ndash; This allows users to still read the filesystem from other operating systems without ext4 support (e.g. Windows with ext2/ext3 drivers)<br />
* Improved performance (though not as much as a fully-converted ext4 partition).[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Fewer features of ext4 are used (only those that do not change the disk format such as multiblock allocation and delayed allocation)<br />
<br />
{{Note|Except for the relative novelty of ext4 (which can be seen as a risk), '''there is no major drawback to this technique'''.}}<br />
<br />
====Procedure====<br />
<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext2/ext3 to ext4 for any partitions you would like to mount as ext4.<br />
# Re-mount the affected partitions.<br />
<br />
===Converting ext2/ext3 partitions to ext4===<br />
<br />
====Rationale====<br />
<br />
To experience the benefits of ext4, an irreversible conversion process must be completed.<br />
<br />
'''Pros:'''<br />
* Improved performance and new features.[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Partitions that contain mostly static files, such as a {{ic|/boot}} partition, may not benefit from the new features. Also, adding a journal (which is implied by moving a ext2 partition to ext3/4) always incurs performance overhead. <br />
* Irreversible (ext4 partitions cannot be 'downgraded' to ext2/ext3. It is, however, backwards compatible until extent and other unique options are enabled)<br />
<br />
====Procedure====<br />
<br />
These instructions were adapted from [http://ext4.wiki.kernel.org/index.php/Ext4_Howto Kernel documentation] and an [https://bbs.archlinux.org/viewtopic.php?id=61602 BBS thread]. <br />
<br />
{{Warning|<br />
* If you convert the system's root filesystem, ensure that the 'fallback' initramfs is available at reboot. Alternatively, add {{ic|ext4}} according to [[Mkinitcpio#MODULES]] and re-create the 'default' initial ramdisk with {{Ic|mkinitcpio -p linux}} before starting.<br />
* If you decide to convert a separate {{ic|/boot}} partition, ensure the [[bootloader]] supports booting from ext4.}}<br />
<br />
In the following steps {{Ic|/dev/sdxX}} denotes the path to the partition to be converted, such as {{Ic|/dev/sda1}}. <br />
<br />
# '''[[Backup programs|BACK-UP!]]''' Back-up all data on any ext3 partitions that are to be converted to ext4. A useful package, especially for root partitions, is [http://clonezilla.org Clonezilla].<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext3 to ext4 for any partitions that are to be converted to ext4.<br />
# Boot the live medium (if necessary). The conversion process with {{Pkg|e2fsprogs}} must be done when the drive is not mounted. If converting a root partition, the simplest way to achieve this is to boot from some other live medium.<br />
# Ensure the partition is '''NOT''' mounted<br />
# If you want to convert a ext2 partition, the first conversion step is to add a [[File systems#Journaling|journal]] by running {{ic|tune2fs -j /dev/sdxX}} as root; making it a ext3 partition. <br />
# Run {{Ic|tune2fs -O extent,uninit_bg,dir_index /dev/sdxX}} as root. This command converts the ext3 filesystem to ext4 (irreversibly). <br />
# Run {{Ic|fsck -f /dev/sdxX}} as root. <br />
#* The user '''must ''fsck''''' the filesystem, or it '''will be unreadable'''! This ''fsck'' run is needed to return the filesystem to a consistent state. It '''will''' find checksum errors in the group descriptors - this '''is''' expected. The {{ic|-f}} option asks ''fsck'' to force checking even if the file system seems clean. The {{ic|-p}} option may be used on top to 'automatically repair' (otherwise, the user will be asked for input for each error). <br />
# Recommended: mount the partition and run {{Ic|e4defrag -c -v /dev/sdxX}} as root.<br />
#* Even though the filesystem is now converted to ext4, all files that have been written before the conversion do not yet take advantage of the extent option of ext4, which will improve large file performance and reduce fragmentation and filesystem check time. In order to fully take advantage of ext4, all files would have to be rewritten on disk. Use ''e4defrag'' to take care of this problem.<br />
# Reboot Arch Linux!<br />
<br />
== Using ext4 per directory encryption == <br />
<br />
Linux comes with an Ext4 feature to encrypt directories of a filesystem. See also [http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html Quarkslab's blog] entry with a write-up of the features, an overview of the implementation state and practical test results with kernel 4.1. <br />
<br />
Encryption keys are stored in the keyring. To get started, make sure you have enabled {{ic|CONFIG_KEYS}} and {{ic|CONFIG_EXT4_ENCRYPTION}} kernel options and you have kernel 4.1 or higher. Note the Arch default {{Pkg|linux}} does not have {{ic|CONFIG_EXT4_ENCRYPTION}} set yet. <br />
<br />
First of all, you need to update {{Pkg|e2fsprogs}} to at least version 1.43.<br />
<br />
Let us make a directory that we will encrypt. Encryption policy can be set only on new empty directories. For example, if we are to encrypt {{ic|/encrypted/dir}}, create the upper level directory:<br />
<br />
# mkdir /encrypted<br />
<br />
First generate a random salt value and store it in a safe place:<br />
<br />
# head -c 16 /dev/random | xxd -p<br />
877282f53bd0adbbef92142fc4cac459<br />
<br />
Now generate and add a new key into your keyring:<br />
this step should be repeated every time you flush your keychain (reboot)<br />
<br />
# e4crypt add_key -S 0x877282f53bd0adbbef92142fc4cac459<br />
Enter passphrase (echo disabled): <br />
Added key with descriptor [f88747555a6115f5]<br />
<br />
Now you know a descriptor for your key.<br />
Make sure you have added a key into your keychain:<br />
<br />
# keyctl show<br />
Session Keyring<br />
1021618178 --alswrv 1000 1000 keyring: _ses<br />
176349519 --alsw-v 1000 1000 \_ logon: ext4:f88747555a6115f5<br />
<br />
Almost done. Now set an encryption policy for a directory:<br />
<br />
# e4crypt set_policy f88747555a6115f5 /encrypted/dir<br />
<br />
That is all. If you try accessing the disk without adding a key into keychain,<br />
filenames and their contents will be seen as encrypted gibberish. Be careful<br />
running old versions of e2fsck on your filesystem - it will treat encrypted<br />
filenames as invalid.<br />
<br />
== Tips and tricks ==<br />
<br />
=== E4rat ===<br />
<br />
[[E4rat]] is a preload application designed for the ext4 filesystem. It monitors files opened during boot, optimizes their placement on the partition to improve access time, and preloads them at the very beginning of the boot process. [[E4rat]] does not offer improvements with [[SSD]]s, whose access time is negligible compared to hard disks.<br />
<br />
=== Barriers and performance ===<br />
<br />
Since kernel 2.6.30, ext4 performance has decreased due to changes that serve to improve data integrity.[http://www.phoronix.com/scan.php?page=article&item=ext4_then_now&num=1]<br />
<br />
:Most file systems (XFS, ext3, ext4, reiserfs) send write barriers to disk after fsync or during transaction commits. Write barriers enforce proper ordering of writes, making volatile disk write caches safe to use (at some performance penalty). If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.<br />
<br />
:Sending write barriers can be disabled using the {{Ic|1=barrier=0}} mount option (for ext3, ext4, and reiserfs), or using the {{Ic|1=nobarrier}} mount option (for XFS).[http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning.io.html]{{dead link|2016|7|5}}<br />
<br />
{{Warning|Disabling barriers when disks cannot guarantee caches are properly written in case of power failure can lead to severe file system corruption and data loss.}}<br />
<br />
To turn barriers off add the option {{Ic|1=barrier=0}} to the desired filesystem. For example:<br />
<br />
{{hc|/etc/fstab|2=<br />
/dev/sda5 / ext4 noatime,barrier=0 0 1<br />
}}<br />
<br />
==Enabling metadata checksums==<br />
<br />
Starting with [http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.43 e2fsprogs 1.43] we can safely enable support for ext4 checksums and 64bit.<br />
More about metadata checksums can be [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums read here].<br />
<br />
If your CPU supports SSE 4.2, make sure the {{Ic|crc32c_intel}} kernel module is loaded in order to enable the hardware accelerated CRC32C algorithm. If not you'll need to load the {{Ic|crc32c_generic}} module.<br />
<br />
This needs to be done with the partition unmounted, so if you want to convert the root, you'll need to run off an USB live distro.<br />
<br />
First the partition needs to be checked and optimized using {{Ic |e2fsck -D /dev/sdX}}. <br />
<br />
Then the file-system needs to be converted to 64bit: {{Ic |resize2fs -b /dev/sdX}}. <br />
<br />
Finally checksums can be added: {{Ic |tune2fs -O metadata_csum /dev/sdX}}.<br />
<br />
<br />
The file-system can then be mounted as usual.<br />
If this is the root file-system these modules might need to be added to {{Ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES="... crc32c_intel crc32c_generic"<br />
<br />
And then regenerate the kernel image using {{Ic|mkinitcpio -p linux}}.<br />
<br />
== See also ==<br />
<br />
* [https://ext4.wiki.kernel.org/ Official Ext4 wiki]<br />
* [https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout Ext4 Disk Layout] described in its wiki<br />
* [http://lwn.net/Articles/639427/ Ext4 Encryption] LWM article<br />
* Kernel commits for ext4 encryption [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6162e4b0bedeb3dac2ba0a5e1b1f56db107d97ec] [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8663da2c0919896788321cd8a0016af08588c656]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Ext4&diff=442867Ext42016-07-24T21:31:10Z<p>Wooptoo: kernel modules for csums</p>
<hr />
<div>[[Category:File systems]]<br />
[[cs:Ext4]]<br />
[[de:Ext4]]<br />
[[es:Ext4]]<br />
[[fr:Ext4]]<br />
[[it:Ext4]]<br />
[[ja:Ext4]]<br />
[[ru:Ext4]]<br />
[[tr:Ext4]]<br />
[[zh-CN:Ext4]]<br />
{{Related articles start}}<br />
{{Related|File systems}}<br />
{{Related|Ext3}}<br />
{{Related articles end}}<br />
From [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies]:<br />
:Ext4 is the evolution of the most used Linux filesystem, Ext3. In many ways, Ext4 is a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding journaling to Ext2, but Ext4 modifies important data structures of the filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability, and features.<br />
<br />
== Create a new ext4 filesystem ==<br />
<br />
To format a partition do:<br />
<br />
# mkfs.ext4 /dev/''partition''<br />
<br />
{{Tip|See the mkfs.ext4 [[man page]] for more options; edit {{ic|/etc/mke2fs.conf}} to view/configure default options.}}<br />
<br />
=== Bytes-per-inode ratio ===<br />
<br />
From {{ic|man mkfs.ext4}}:<br />
<br />
:'''''mke2fs''' creates an inode for every ''bytes-per-inode'' bytes of space on the disk. The larger the ''bytes-per-inode'' ratio, the fewer inodes will be created.''<br />
<br />
Creating a new file, directory, symlink etc. requires at least one free [[Wikipedia:Inode|inode]]. If the inode count is too low, no file can be created on the filesystem even though there is still space left on it. <br />
<br />
Because it is not possible to change either the bytes-per-inode ratio or the inode count after the filesystem is created, {{ic|mkfs.ext4}} uses by default a rather low ratio of one inode every 16384 bytes (16 Kb) to avoid this situation.<br />
<br />
However, for partitions with size in the hundreds or thousands of GB and average file size in the megabyte range, this usually results in a much too large inode number because the number of files created never reaches the number of inodes.<br />
<br />
This results in a waste of disk space, because all those unused inodes each take up 256 bytes on the filesystem (this is also set in {{ic|/etc/mke2fs.conf}} but should not be changed). 256 * several millions = quite a few gigabytes wasted in unused inodes.<br />
<br />
This situation can be evaluated by comparing the {{ic|{I}Use%}} figures provided by {{ic|df}} and {{ic|df -i}}:<br />
<br />
{{hc|$ df -h /home|<br />
Filesystem Size Used Avail '''Use%''' Mounted on<br />
/dev/mapper/lvm-home 115G 56G 59G '''49%''' /home}}<br />
{{hc|$ df -hi /home|<br />
Filesystem Inodes IUsed IFree '''IUse%''' Mounted on<br />
/dev/mapper/lvm-home 1.8M 1.1K 1.8M '''1%''' /home}}<br />
<br />
To specify a different bytes-per-inode ratio, you can use the {{ic|-T ''usage-type''}} option which hints at the expected usage of the filesystem using types defined in {{ic|/etc/mke2fs.conf}}. Among those types are the bigger {{ic|largefile}} and {{ic|largefile4}} which offer more relevant ratios of one inode every 1 MiB and 4 MiB respectively. It can be used as such:<br />
<br />
# mkfs.ext4 -T largefile /dev/''device''<br />
<br />
The bytes-per-inode ratio can also be set directly via the {{ic|-i}} option: ''e.g.'' use {{ic|-i 2097152}} for a 2 MiB ratio and {{ic|-i 6291456}} for a 6 MiB ratio.<br />
<br />
{{Tip|Conversely, if you are setting up a partition dedicated to host millions of small files like emails or newsgroup items, you can use smaller ''usage-type'' values such as {{ic|news}} (one inode for every 4096 bytes) or {{ic|small}} (same plus smaller inode and block sizes).}}<br />
<br />
{{Warning|If you make a heavy use of symbolic links, make sure to keep the inode count high enough with a low bytes-per-inode ratio, because while not taking more space every new symbolic link consumes one new inode and therefore the filesystem may run out of them quickly.}}<br />
<br />
=== Reserved blocks ===<br />
<br />
By default, 5% of the filesystem blocks will be reserved for the super-user, to avoid fragmentation and "''allow root-owned daemons to continue to function correctly after non-privileged processes are prevented from writing to the filesystem''" (from {{ic|man mkfs.ext4}}).<br />
<br />
For modern high-capacity disks, this is higher than necessary if the partition is used as a long-term archive or not crucial to system operations (like {{ic|/home}}). See [http://www.redhat.com/archives/ext3-users/2009-January/msg00026.html this email] for the opinion of ext4 developer Ted Ts'o on reserved blocks.<br />
<br />
It is generally safe to reduce the percentage of reserved blocks to free up disk space when the partition is either:<br />
<br />
* Very large (for example > 50G)<br />
* Used as long-term archive, i.e., where files will not be deleted and created very often<br />
<br />
The {{ic|-m}} option of ext4-related utilities allows to specify the percentage of reserved blocks.<br />
<br />
To totally prevent reserving blocks upon filesystem creation, use:<br />
<br />
# mkfs.ext4 -m 0 /dev/''device''<br />
<br />
To reduce it to 1% afterwards, use:<br />
<br />
# tune2fs -m 1 /dev/''device''<br />
<br />
You can use {{ic|findmnt(8)}} to find the device name:<br />
<br />
$ findmnt ''/the/mount/point''<br />
<br />
==Migrating from ext2/ext3 to ext4==<br />
<br />
===Mounting ext2/ext3 partitions as ext4 without converting===<br />
<br />
====Rationale====<br />
<br />
A compromise between fully converting to ext4 and simply remaining with ext2/ext3 is to mount the partitions as ext4.<br />
<br />
'''Pros:'''<br />
* Compatibility (the filesystem can continue to be mounted as ext3) &ndash; This allows users to still read the filesystem from other operating systems without ext4 support (e.g. Windows with ext2/ext3 drivers)<br />
* Improved performance (though not as much as a fully-converted ext4 partition).[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Fewer features of ext4 are used (only those that do not change the disk format such as multiblock allocation and delayed allocation)<br />
<br />
{{Note|Except for the relative novelty of ext4 (which can be seen as a risk), '''there is no major drawback to this technique'''.}}<br />
<br />
====Procedure====<br />
<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext2/ext3 to ext4 for any partitions you would like to mount as ext4.<br />
# Re-mount the affected partitions.<br />
<br />
===Converting ext2/ext3 partitions to ext4===<br />
<br />
====Rationale====<br />
<br />
To experience the benefits of ext4, an irreversible conversion process must be completed.<br />
<br />
'''Pros:'''<br />
* Improved performance and new features.[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Partitions that contain mostly static files, such as a {{ic|/boot}} partition, may not benefit from the new features. Also, adding a journal (which is implied by moving a ext2 partition to ext3/4) always incurs performance overhead. <br />
* Irreversible (ext4 partitions cannot be 'downgraded' to ext2/ext3. It is, however, backwards compatible until extent and other unique options are enabled)<br />
<br />
====Procedure====<br />
<br />
These instructions were adapted from [http://ext4.wiki.kernel.org/index.php/Ext4_Howto Kernel documentation] and an [https://bbs.archlinux.org/viewtopic.php?id=61602 BBS thread]. <br />
<br />
{{Warning|<br />
* If you convert the system's root filesystem, ensure that the 'fallback' initramfs is available at reboot. Alternatively, add {{ic|ext4}} according to [[Mkinitcpio#MODULES]] and re-create the 'default' initial ramdisk with {{Ic|mkinitcpio -p linux}} before starting.<br />
* If you decide to convert a separate {{ic|/boot}} partition, ensure the [[bootloader]] supports booting from ext4.}}<br />
<br />
In the following steps {{Ic|/dev/sdxX}} denotes the path to the partition to be converted, such as {{Ic|/dev/sda1}}. <br />
<br />
# '''[[Backup programs|BACK-UP!]]''' Back-up all data on any ext3 partitions that are to be converted to ext4. A useful package, especially for root partitions, is [http://clonezilla.org Clonezilla].<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext3 to ext4 for any partitions that are to be converted to ext4.<br />
# Boot the live medium (if necessary). The conversion process with {{Pkg|e2fsprogs}} must be done when the drive is not mounted. If converting a root partition, the simplest way to achieve this is to boot from some other live medium.<br />
# Ensure the partition is '''NOT''' mounted<br />
# If you want to convert a ext2 partition, the first conversion step is to add a [[File systems#Journaling|journal]] by running {{ic|tune2fs -j /dev/sdxX}} as root; making it a ext3 partition. <br />
# Run {{Ic|tune2fs -O extent,uninit_bg,dir_index /dev/sdxX}} as root. This command converts the ext3 filesystem to ext4 (irreversibly). <br />
# Run {{Ic|fsck -f /dev/sdxX}} as root. <br />
#* The user '''must ''fsck''''' the filesystem, or it '''will be unreadable'''! This ''fsck'' run is needed to return the filesystem to a consistent state. It '''will''' find checksum errors in the group descriptors - this '''is''' expected. The {{ic|-f}} option asks ''fsck'' to force checking even if the file system seems clean. The {{ic|-p}} option may be used on top to 'automatically repair' (otherwise, the user will be asked for input for each error). <br />
# Recommended: mount the partition and run {{Ic|e4defrag -c -v /dev/sdxX}} as root.<br />
#* Even though the filesystem is now converted to ext4, all files that have been written before the conversion do not yet take advantage of the extent option of ext4, which will improve large file performance and reduce fragmentation and filesystem check time. In order to fully take advantage of ext4, all files would have to be rewritten on disk. Use ''e4defrag'' to take care of this problem.<br />
# Reboot Arch Linux!<br />
<br />
== Using ext4 per directory encryption == <br />
<br />
Linux comes with an Ext4 feature to encrypt directories of a filesystem. See also [http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html Quarkslab's blog] entry with a write-up of the features, an overview of the implementation state and practical test results with kernel 4.1. <br />
<br />
Encryption keys are stored in the keyring. To get started, make sure you have enabled {{ic|CONFIG_KEYS}} and {{ic|CONFIG_EXT4_ENCRYPTION}} kernel options and you have kernel 4.1 or higher. Note the Arch default {{Pkg|linux}} does not have {{ic|CONFIG_EXT4_ENCRYPTION}} set yet. <br />
<br />
First of all, you need to update {{Pkg|e2fsprogs}} to at least version 1.43.<br />
<br />
Let us make a directory that we will encrypt. Encryption policy can be set only on new empty directories. For example, if we are to encrypt {{ic|/encrypted/dir}}, create the upper level directory:<br />
<br />
# mkdir /encrypted<br />
<br />
First generate a random salt value and store it in a safe place:<br />
<br />
# head -c 16 /dev/random | xxd -p<br />
877282f53bd0adbbef92142fc4cac459<br />
<br />
Now generate and add a new key into your keyring:<br />
this step should be repeated every time you flush your keychain (reboot)<br />
<br />
# e4crypt add_key -S 0x877282f53bd0adbbef92142fc4cac459<br />
Enter passphrase (echo disabled): <br />
Added key with descriptor [f88747555a6115f5]<br />
<br />
Now you know a descriptor for your key.<br />
Make sure you have added a key into your keychain:<br />
<br />
# keyctl show<br />
Session Keyring<br />
1021618178 --alswrv 1000 1000 keyring: _ses<br />
176349519 --alsw-v 1000 1000 \_ logon: ext4:f88747555a6115f5<br />
<br />
Almost done. Now set an encryption policy for a directory:<br />
<br />
# e4crypt set_policy f88747555a6115f5 /encrypted/dir<br />
<br />
That is all. If you try accessing the disk without adding a key into keychain,<br />
filenames and their contents will be seen as encrypted gibberish. Be careful<br />
running old versions of e2fsck on your filesystem - it will treat encrypted<br />
filenames as invalid.<br />
<br />
== Tips and tricks ==<br />
<br />
=== E4rat ===<br />
<br />
[[E4rat]] is a preload application designed for the ext4 filesystem. It monitors files opened during boot, optimizes their placement on the partition to improve access time, and preloads them at the very beginning of the boot process. [[E4rat]] does not offer improvements with [[SSD]]s, whose access time is negligible compared to hard disks.<br />
<br />
=== Barriers and performance ===<br />
<br />
Since kernel 2.6.30, ext4 performance has decreased due to changes that serve to improve data integrity.[http://www.phoronix.com/scan.php?page=article&item=ext4_then_now&num=1]<br />
<br />
:Most file systems (XFS, ext3, ext4, reiserfs) send write barriers to disk after fsync or during transaction commits. Write barriers enforce proper ordering of writes, making volatile disk write caches safe to use (at some performance penalty). If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.<br />
<br />
:Sending write barriers can be disabled using the {{Ic|1=barrier=0}} mount option (for ext3, ext4, and reiserfs), or using the {{Ic|1=nobarrier}} mount option (for XFS).[http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning.io.html]{{dead link|2016|7|5}}<br />
<br />
{{Warning|Disabling barriers when disks cannot guarantee caches are properly written in case of power failure can lead to severe file system corruption and data loss.}}<br />
<br />
To turn barriers off add the option {{Ic|1=barrier=0}} to the desired filesystem. For example:<br />
<br />
{{hc|/etc/fstab|2=<br />
/dev/sda5 / ext4 noatime,barrier=0 0 1<br />
}}<br />
<br />
==Enabling metadata checksums==<br />
<br />
Starting with [http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.43 e2fsprogs 1.43] we can safely enable support for ext4 checksums and 64bit.<br />
More about metadata checksums can be [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums read here].<br />
<br />
If your CPU supports SSE 4.2, make sure the {{Ic|crc32c_intel}} kernel module is loaded in order to enable the hardware accelerated CRC32C algorithm. If not you'll need to load the {{Ic|crc32c_generic}} module.<br />
<br />
This needs to be done with the partition unmounted, so if you want to convert the root, you'll need to run off an USB live distro.<br />
<br />
First the partition needs to be checked and optimized using {{Ic |e2fsck -D /dev/sdX}}. <br />
<br />
Then the file-system needs to be converted to 64bit: {{Ic |resize2fs -b /dev/sdX}}. <br />
<br />
Finally checksums can be added: {{Ic |tune2fs -O metadata_csum /dev/sdX}}.<br />
<br />
The file-system can then be mounted as usual.<br />
If this is the root file-system these modules might need to be added to {{Ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES="... crc32c_intel crc32c_generic"<br />
<br />
And then regenerate the kernel image using {{Ic|mkinitcpio -p linux}}.<br />
<br />
== See also ==<br />
<br />
* [https://ext4.wiki.kernel.org/ Official Ext4 wiki]<br />
* [https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout Ext4 Disk Layout] described in its wiki<br />
* [http://lwn.net/Articles/639427/ Ext4 Encryption] LWM article<br />
* Kernel commits for ext4 encryption [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6162e4b0bedeb3dac2ba0a5e1b1f56db107d97ec] [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8663da2c0919896788321cd8a0016af08588c656]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Ext4&diff=442866Ext42016-07-24T21:25:48Z<p>Wooptoo: enable metadata checksums</p>
<hr />
<div>[[Category:File systems]]<br />
[[cs:Ext4]]<br />
[[de:Ext4]]<br />
[[es:Ext4]]<br />
[[fr:Ext4]]<br />
[[it:Ext4]]<br />
[[ja:Ext4]]<br />
[[ru:Ext4]]<br />
[[tr:Ext4]]<br />
[[zh-CN:Ext4]]<br />
{{Related articles start}}<br />
{{Related|File systems}}<br />
{{Related|Ext3}}<br />
{{Related articles end}}<br />
From [http://kernelnewbies.org/Ext4 Ext4 - Linux Kernel Newbies]:<br />
:Ext4 is the evolution of the most used Linux filesystem, Ext3. In many ways, Ext4 is a deeper improvement over Ext3 than Ext3 was over Ext2. Ext3 was mostly about adding journaling to Ext2, but Ext4 modifies important data structures of the filesystem such as the ones destined to store the file data. The result is a filesystem with an improved design, better performance, reliability, and features.<br />
<br />
== Create a new ext4 filesystem ==<br />
<br />
To format a partition do:<br />
<br />
# mkfs.ext4 /dev/''partition''<br />
<br />
{{Tip|See the mkfs.ext4 [[man page]] for more options; edit {{ic|/etc/mke2fs.conf}} to view/configure default options.}}<br />
<br />
=== Bytes-per-inode ratio ===<br />
<br />
From {{ic|man mkfs.ext4}}:<br />
<br />
:'''''mke2fs''' creates an inode for every ''bytes-per-inode'' bytes of space on the disk. The larger the ''bytes-per-inode'' ratio, the fewer inodes will be created.''<br />
<br />
Creating a new file, directory, symlink etc. requires at least one free [[Wikipedia:Inode|inode]]. If the inode count is too low, no file can be created on the filesystem even though there is still space left on it. <br />
<br />
Because it is not possible to change either the bytes-per-inode ratio or the inode count after the filesystem is created, {{ic|mkfs.ext4}} uses by default a rather low ratio of one inode every 16384 bytes (16 Kb) to avoid this situation.<br />
<br />
However, for partitions with size in the hundreds or thousands of GB and average file size in the megabyte range, this usually results in a much too large inode number because the number of files created never reaches the number of inodes.<br />
<br />
This results in a waste of disk space, because all those unused inodes each take up 256 bytes on the filesystem (this is also set in {{ic|/etc/mke2fs.conf}} but should not be changed). 256 * several millions = quite a few gigabytes wasted in unused inodes.<br />
<br />
This situation can be evaluated by comparing the {{ic|{I}Use%}} figures provided by {{ic|df}} and {{ic|df -i}}:<br />
<br />
{{hc|$ df -h /home|<br />
Filesystem Size Used Avail '''Use%''' Mounted on<br />
/dev/mapper/lvm-home 115G 56G 59G '''49%''' /home}}<br />
{{hc|$ df -hi /home|<br />
Filesystem Inodes IUsed IFree '''IUse%''' Mounted on<br />
/dev/mapper/lvm-home 1.8M 1.1K 1.8M '''1%''' /home}}<br />
<br />
To specify a different bytes-per-inode ratio, you can use the {{ic|-T ''usage-type''}} option which hints at the expected usage of the filesystem using types defined in {{ic|/etc/mke2fs.conf}}. Among those types are the bigger {{ic|largefile}} and {{ic|largefile4}} which offer more relevant ratios of one inode every 1 MiB and 4 MiB respectively. It can be used as such:<br />
<br />
# mkfs.ext4 -T largefile /dev/''device''<br />
<br />
The bytes-per-inode ratio can also be set directly via the {{ic|-i}} option: ''e.g.'' use {{ic|-i 2097152}} for a 2 MiB ratio and {{ic|-i 6291456}} for a 6 MiB ratio.<br />
<br />
{{Tip|Conversely, if you are setting up a partition dedicated to host millions of small files like emails or newsgroup items, you can use smaller ''usage-type'' values such as {{ic|news}} (one inode for every 4096 bytes) or {{ic|small}} (same plus smaller inode and block sizes).}}<br />
<br />
{{Warning|If you make a heavy use of symbolic links, make sure to keep the inode count high enough with a low bytes-per-inode ratio, because while not taking more space every new symbolic link consumes one new inode and therefore the filesystem may run out of them quickly.}}<br />
<br />
=== Reserved blocks ===<br />
<br />
By default, 5% of the filesystem blocks will be reserved for the super-user, to avoid fragmentation and "''allow root-owned daemons to continue to function correctly after non-privileged processes are prevented from writing to the filesystem''" (from {{ic|man mkfs.ext4}}).<br />
<br />
For modern high-capacity disks, this is higher than necessary if the partition is used as a long-term archive or not crucial to system operations (like {{ic|/home}}). See [http://www.redhat.com/archives/ext3-users/2009-January/msg00026.html this email] for the opinion of ext4 developer Ted Ts'o on reserved blocks.<br />
<br />
It is generally safe to reduce the percentage of reserved blocks to free up disk space when the partition is either:<br />
<br />
* Very large (for example > 50G)<br />
* Used as long-term archive, i.e., where files will not be deleted and created very often<br />
<br />
The {{ic|-m}} option of ext4-related utilities allows to specify the percentage of reserved blocks.<br />
<br />
To totally prevent reserving blocks upon filesystem creation, use:<br />
<br />
# mkfs.ext4 -m 0 /dev/''device''<br />
<br />
To reduce it to 1% afterwards, use:<br />
<br />
# tune2fs -m 1 /dev/''device''<br />
<br />
You can use {{ic|findmnt(8)}} to find the device name:<br />
<br />
$ findmnt ''/the/mount/point''<br />
<br />
==Migrating from ext2/ext3 to ext4==<br />
<br />
===Mounting ext2/ext3 partitions as ext4 without converting===<br />
<br />
====Rationale====<br />
<br />
A compromise between fully converting to ext4 and simply remaining with ext2/ext3 is to mount the partitions as ext4.<br />
<br />
'''Pros:'''<br />
* Compatibility (the filesystem can continue to be mounted as ext3) &ndash; This allows users to still read the filesystem from other operating systems without ext4 support (e.g. Windows with ext2/ext3 drivers)<br />
* Improved performance (though not as much as a fully-converted ext4 partition).[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Fewer features of ext4 are used (only those that do not change the disk format such as multiblock allocation and delayed allocation)<br />
<br />
{{Note|Except for the relative novelty of ext4 (which can be seen as a risk), '''there is no major drawback to this technique'''.}}<br />
<br />
====Procedure====<br />
<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext2/ext3 to ext4 for any partitions you would like to mount as ext4.<br />
# Re-mount the affected partitions.<br />
<br />
===Converting ext2/ext3 partitions to ext4===<br />
<br />
====Rationale====<br />
<br />
To experience the benefits of ext4, an irreversible conversion process must be completed.<br />
<br />
'''Pros:'''<br />
* Improved performance and new features.[http://kernelnewbies.org/Ext4] [http://events.linuxfoundation.org/slides/2010/linuxcon_japan/linuxcon_jp2010_fujita.pdf] <br />
<br />
'''Cons:'''<br />
* Partitions that contain mostly static files, such as a {{ic|/boot}} partition, may not benefit from the new features. Also, adding a journal (which is implied by moving a ext2 partition to ext3/4) always incurs performance overhead. <br />
* Irreversible (ext4 partitions cannot be 'downgraded' to ext2/ext3. It is, however, backwards compatible until extent and other unique options are enabled)<br />
<br />
====Procedure====<br />
<br />
These instructions were adapted from [http://ext4.wiki.kernel.org/index.php/Ext4_Howto Kernel documentation] and an [https://bbs.archlinux.org/viewtopic.php?id=61602 BBS thread]. <br />
<br />
{{Warning|<br />
* If you convert the system's root filesystem, ensure that the 'fallback' initramfs is available at reboot. Alternatively, add {{ic|ext4}} according to [[Mkinitcpio#MODULES]] and re-create the 'default' initial ramdisk with {{Ic|mkinitcpio -p linux}} before starting.<br />
* If you decide to convert a separate {{ic|/boot}} partition, ensure the [[bootloader]] supports booting from ext4.}}<br />
<br />
In the following steps {{Ic|/dev/sdxX}} denotes the path to the partition to be converted, such as {{Ic|/dev/sda1}}. <br />
<br />
# '''[[Backup programs|BACK-UP!]]''' Back-up all data on any ext3 partitions that are to be converted to ext4. A useful package, especially for root partitions, is [http://clonezilla.org Clonezilla].<br />
# Edit {{ic|/etc/fstab}} and change the 'type' from ext3 to ext4 for any partitions that are to be converted to ext4.<br />
# Boot the live medium (if necessary). The conversion process with {{Pkg|e2fsprogs}} must be done when the drive is not mounted. If converting a root partition, the simplest way to achieve this is to boot from some other live medium.<br />
# Ensure the partition is '''NOT''' mounted<br />
# If you want to convert a ext2 partition, the first conversion step is to add a [[File systems#Journaling|journal]] by running {{ic|tune2fs -j /dev/sdxX}} as root; making it a ext3 partition. <br />
# Run {{Ic|tune2fs -O extent,uninit_bg,dir_index /dev/sdxX}} as root. This command converts the ext3 filesystem to ext4 (irreversibly). <br />
# Run {{Ic|fsck -f /dev/sdxX}} as root. <br />
#* The user '''must ''fsck''''' the filesystem, or it '''will be unreadable'''! This ''fsck'' run is needed to return the filesystem to a consistent state. It '''will''' find checksum errors in the group descriptors - this '''is''' expected. The {{ic|-f}} option asks ''fsck'' to force checking even if the file system seems clean. The {{ic|-p}} option may be used on top to 'automatically repair' (otherwise, the user will be asked for input for each error). <br />
# Recommended: mount the partition and run {{Ic|e4defrag -c -v /dev/sdxX}} as root.<br />
#* Even though the filesystem is now converted to ext4, all files that have been written before the conversion do not yet take advantage of the extent option of ext4, which will improve large file performance and reduce fragmentation and filesystem check time. In order to fully take advantage of ext4, all files would have to be rewritten on disk. Use ''e4defrag'' to take care of this problem.<br />
# Reboot Arch Linux!<br />
<br />
== Using ext4 per directory encryption == <br />
<br />
Linux comes with an Ext4 feature to encrypt directories of a filesystem. See also [http://blog.quarkslab.com/a-glimpse-of-ext4-filesystem-level-encryption.html Quarkslab's blog] entry with a write-up of the features, an overview of the implementation state and practical test results with kernel 4.1. <br />
<br />
Encryption keys are stored in the keyring. To get started, make sure you have enabled {{ic|CONFIG_KEYS}} and {{ic|CONFIG_EXT4_ENCRYPTION}} kernel options and you have kernel 4.1 or higher. Note the Arch default {{Pkg|linux}} does not have {{ic|CONFIG_EXT4_ENCRYPTION}} set yet. <br />
<br />
First of all, you need to update {{Pkg|e2fsprogs}} to at least version 1.43.<br />
<br />
Let us make a directory that we will encrypt. Encryption policy can be set only on new empty directories. For example, if we are to encrypt {{ic|/encrypted/dir}}, create the upper level directory:<br />
<br />
# mkdir /encrypted<br />
<br />
First generate a random salt value and store it in a safe place:<br />
<br />
# head -c 16 /dev/random | xxd -p<br />
877282f53bd0adbbef92142fc4cac459<br />
<br />
Now generate and add a new key into your keyring:<br />
this step should be repeated every time you flush your keychain (reboot)<br />
<br />
# e4crypt add_key -S 0x877282f53bd0adbbef92142fc4cac459<br />
Enter passphrase (echo disabled): <br />
Added key with descriptor [f88747555a6115f5]<br />
<br />
Now you know a descriptor for your key.<br />
Make sure you have added a key into your keychain:<br />
<br />
# keyctl show<br />
Session Keyring<br />
1021618178 --alswrv 1000 1000 keyring: _ses<br />
176349519 --alsw-v 1000 1000 \_ logon: ext4:f88747555a6115f5<br />
<br />
Almost done. Now set an encryption policy for a directory:<br />
<br />
# e4crypt set_policy f88747555a6115f5 /encrypted/dir<br />
<br />
That is all. If you try accessing the disk without adding a key into keychain,<br />
filenames and their contents will be seen as encrypted gibberish. Be careful<br />
running old versions of e2fsck on your filesystem - it will treat encrypted<br />
filenames as invalid.<br />
<br />
== Tips and tricks ==<br />
<br />
=== E4rat ===<br />
<br />
[[E4rat]] is a preload application designed for the ext4 filesystem. It monitors files opened during boot, optimizes their placement on the partition to improve access time, and preloads them at the very beginning of the boot process. [[E4rat]] does not offer improvements with [[SSD]]s, whose access time is negligible compared to hard disks.<br />
<br />
=== Barriers and performance ===<br />
<br />
Since kernel 2.6.30, ext4 performance has decreased due to changes that serve to improve data integrity.[http://www.phoronix.com/scan.php?page=article&item=ext4_then_now&num=1]<br />
<br />
:Most file systems (XFS, ext3, ext4, reiserfs) send write barriers to disk after fsync or during transaction commits. Write barriers enforce proper ordering of writes, making volatile disk write caches safe to use (at some performance penalty). If your disks are battery-backed in one way or another, disabling barriers may safely improve performance.<br />
<br />
:Sending write barriers can be disabled using the {{Ic|1=barrier=0}} mount option (for ext3, ext4, and reiserfs), or using the {{Ic|1=nobarrier}} mount option (for XFS).[http://doc.opensuse.org/products/draft/SLES/SLES-tuning_sd_draft/cha.tuning.io.html]{{dead link|2016|7|5}}<br />
<br />
{{Warning|Disabling barriers when disks cannot guarantee caches are properly written in case of power failure can lead to severe file system corruption and data loss.}}<br />
<br />
To turn barriers off add the option {{Ic|1=barrier=0}} to the desired filesystem. For example:<br />
<br />
{{hc|/etc/fstab|2=<br />
/dev/sda5 / ext4 noatime,barrier=0 0 1<br />
}}<br />
<br />
==Enabling metadata checksums==<br />
<br />
Starting with [http://e2fsprogs.sourceforge.net/e2fsprogs-release.html#1.43 e2fsprogs 1.43] we can safely enable support for ext4 checksums and 64bit.<br />
More about metadata checksums can be [https://ext4.wiki.kernel.org/index.php/Ext4_Metadata_Checksums read here].<br />
<br />
If your CPU supports SSE 4.2, make sure the {{Ic|crc32c_intel}} kernel module is loaded in order to enable the hardware accelerated CRC32C algorithm. If not you'll need to load the {{Ic|crc32c_generic}} module.<br />
<br />
This needs to be done with the partition unmounted, so if you want to convert the root, you'll need to run off an USB live distro.<br />
<br />
First the partition needs to be checked and optimized using {{Ic |e2fsck -D /dev/sdX}}. <br />
<br />
Then the file-system needs to be converted to 64bit: {{Ic |resize2fs -b /dev/sdX}}. <br />
<br />
Finally checksums can be added: {{Ic |tune2fs -O metadata_csum /dev/sdX}}. <br />
<br />
== See also ==<br />
<br />
* [https://ext4.wiki.kernel.org/ Official Ext4 wiki]<br />
* [https://ext4.wiki.kernel.org/index.php/Ext4_Disk_Layout Ext4 Disk Layout] described in its wiki<br />
* [http://lwn.net/Articles/639427/ Ext4 Encryption] LWM article<br />
* Kernel commits for ext4 encryption [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6162e4b0bedeb3dac2ba0a5e1b1f56db107d97ec] [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=8663da2c0919896788321cd8a0016af08588c656]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Laptop/Dell&diff=441441Laptop/Dell2016-07-14T21:14:51Z<p>Wooptoo: /* Inspiron */</p>
<hr />
<div>[[Category:Dell]]<br />
{{Laptops navigation}}<br />
<br><br />
== Inspiron ==<br />
{{HCL/Laptops table header}}<br />
| Inspiron 1300 || Don't Panic (Core Dump version) || 3D with {{Pkg|xf86-video-intel}} || Intel || ''b44'' module works out-of-the-box || BCM4318-based card, works with [[ndiswrapper]] || N/A || Untested || Untested || -- || Everything works out-of-the-box except wireless and sometimes screen resolution<br />
|- <br />
| Inspiron 1420 || 2012.09 || 3D with {{Pkg|xf86-video-nouveau}} || Intel HD Audio with ALSA || Yes || Yes, {{AUR|broadcom-wl}} needed from the AUR || Untested || Untested || Untested || Untested || Everything that I have tested works great without any problems<br />
|-<br />
| Inspiron 1501 || Duke || 3D with proprietary ATI fglrx || Intel HD audio with ALSA || Yes || Yes, BCM4311 PCI-E with bcm43xx || N/A || Untested || Untested || Smart card reader works out-of-the-box || Everything else works without a hitch<br />
|-<br />
| Inspiron 1520 || Core Dump || 3D with NVIDIA || SigmaTel audio with ALSA || ''b44'' module, out of the box || ''b43'', need firmware || Yes || Both hibernate and suspend-to-RAM and works with [[pm-utils]] || Untested || Hot keys work out-of-the-box || Everything else works without a hitch<br />
|-<br />
| [[Dell Inspiron 1525|Inspiron 1525]] || Arch Linux 2008.06 - "Overlord" FTP Install || 3D with {{Pkg|xf86-video-intel}} 2.4.3, native resolution with {{Pkg|xorg-server}} 1.5.3 (1280x800) || Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || PRO/Wireless 3945ABG with ''iwlwifi-3945-ucode'' 15.28.2.8 || Untested (does not have) || Untested || Untested || SD card reader works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS. Everything else work out-of-the-box.<br />
|- <br />
| Inspiron 1525 || Core Dump (2008.03 ISO) || 3D with {{Pkg|xf86-video-intel}} 2.2, native resolution with {{Pkg|xorg-server}} 1.4 (1280x800)|| Intel HD Audio (SigmaTel STAC9228 codec) with ALSA || Marvell Yukon Gb Ethernet: Yes (''sky2'' module) || Broadcom BCM4310: Yes, [[ndiswrapper]] ([[AUR]] {{AUR|broadcom-wl}} works, but must blacklist {{ic|ssb}} module) || Untested (does not have) || Untested || Untested || SD card reader (Ricoh) works out-of-the-box || {{ic|Fn+Up/Down}} (LCD brightness control) works independently of the OS; media keys configured with KeyTouch. DVD-RW drive and everything else work out-of-the-box.<br />
|- <br />
| [[Dell Inspiron 1564|Inspiron 1564]] || Core Dump || 3D with either [[Catalyst]] or [[ATI|xf86-video-ati]]; both work flawlessly. || Intel HD Audio with ALSA || Realtek RTL8101E Ethernet Controller || Intel WiFi Link 5100 with ''iwlagn'' driver || Untested || Both suspend and hibernate work flawlessly with [[pm-utils]] || Untested || Realtek card reader works out-of-the-box. LCD brightness works out-of-the-box; volume keys need configuring through key bindings. || Overall, this laptop is Linux friendly.<br />
|- <br />
| Inspiron 1764 || 2011.08.19 || 3D with {{Pkg|xf86-video-intel}} || Works well with ALSA || Realtek RTL8101E 10/100 Ethernet Controller || [[Broadcom wireless|Broadcom BCM43224]] 802.11a/b/g/n works well with [[Broadcom_wireless#brcmsmac.2Fbrcmfmac|brcmsmac]] || Untested || Untested || Does not have a modem || SD card reader and LCD brightness {{ic|Fn}} keys work out-of-the-box || Fan control/monitoring is completely broken with {{AUR|i8kutils}}<br />
|-<br />
| [[Dell Inspiron 15 3541|Inspiron 15 3000 Series (Model 3541)]] || 2016.01.01<br />
|-<br />
| [[Dell Inspiron 5547|Inspiron 15 5000 Series (Model 5547)]] || 2016.01.25 || Hybrid graphics/AMD Radeon R7 M260/M265, Please read this [[hybrid_graphics#ATI_Dynamic_Switchable_Graphics|ATI Dynamic Switchable Graphics]]. This has not be testing yet.|| Works with Intel HD Audio and [[PulseAudio]], but need to configure [[PulseAudio/Troubleshooting#Microphone_not_detected_by_PulseAudio|microphone]] || Yes || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM untested. Hibernate untested. Disk spindown untested. || No modem || HDMI work, need configuration to swith between monitor. The touchpad work properly, but just test the basics || Webcam works, SD card reader untested<br />
|-<br />
| Inspiron 15 7000 Series (Model 7537) || 2016.06.01 || Intel® HD Graphics 4400. Works out of the box with {{Pkg|xf86-video-intel}}. || Intel HD Audio. Works out of the box. || Yes RJ45 Ethernet || Intel 7260N or 7260AC, Works out of the box with iwlwifi. || Yes, works out of the box. || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown untested. || No modem || HDMI perfect. The touchpad works with minimal configuration. || Volume up / down button needs some modifying to work all other buttons work with drivers that come with the kernel. ACPI battery is not detected on bootup and requires you to plug in and out the AC adapter.<br />
|-<br />
| Inspiron 15 7000 Series (Model 7548) || 2015.05 || AMD Radeon® R7 M270 || Untested || N/A || Yes, works out of the box || Yes, works out of the box || Suspend-to-RAM perfect. Hibernate untested. Disk spindown untested. || No modem || HDMI is currently untested. The touchpad (clickpad) needs some tweaking to work properly. If the kernel [https://bbs.archlinux.org/viewtopic.php?id=200763 panics] during bootup replace the 'keyboard'-hook with the specifc module.|| Webcam works, SD card reader untested<br />
|-<br />
| Inspiron M5030 || Any || [[ATI]] works fine, [[catalyst]] untested || Yes, works out of the box || Yes || Yes, works out of the box || N/A || Untested || N/A || Everything works alright, and out of the box. || {{AUR|i8kutils}} required for fan control<br />
|-<br />
| Inspiron Duo 1090 (hybrid touchscreen netbook/tablet) || 2014.10.01 || Intel Atom Integrated VGA graphics controller. Software 3D, works out-of-the-box (1366x768). || Intel HD Audio with ALSA || No. || Yes, Qualcomm Atheros (ath9k) || Untested || Suspend-to-RAM works flawlessly. Hibernate untested. || No. || eGalax touchscreen and Synaptics touchpad work flawlessly. All function keys (Power manager, Wifi on/off, touchpad on/off, brightness and audio up/down work flawlessly. Webcam and integrated microphone work. || Audio out works, no standard audio-in or video out ports. USB audio-in and USB video-out untested. <br />
|-<br />
| Inspiron E1405 || Any || 3D with {{Pkg|xf86-video-intel}} 2.0, native resolution with {{Pkg|xorg-server}} 1.3 (1440x900) || Intel HD Audio with [[ALSA]] || Yes || Yes, ipw3945 || Yes || Suspend-to-RAM is shaky; hibernate is flawless || Untested || SD card reader works out-of-the-box || Everything else works without a hitch<br />
|-<br />
! rowspan="2" | Model version<br />
! rowspan="2" | Arch Linux Install CD version<br />
! Video <br />
! Sound<br />
! Ethernet<br />
! Wireless<br />
! Bluetooth<br />
! Power management<br />
! Modem<br />
! Other<br />
! rowspan="2" | Remarks<br />
|-<br />
! colspan="8" | Hardware support<br />
|}<br />
<br />
== Latitude ==<br />
{{HCL/Laptops table header}}<br />
| Latitude D420 || Duke || {{Pkg|xf86-video-intel}}, native resolution with {{Pkg|xorg-server}} 1.2 (1280x800) || Intel HD Audio with ALSA || Yes (with tg3) || Yes (with ipw3945) || N/A || || Untested || Have not tested SD card reader || External D-Bay DVD/CD-RW works, docking station mostly works (can un-dock, but locks up on re-docking)<br />
|-<br />
| Latitude D620 || Duke || 3D with NVIDIA, native resolution with {{Pkg|xorg-server}} 1.2 (1440x900)<br> 3D with Intel 945GM, native resolution 1440x900 || Intel HD Audio with ALSA || Yes || Yes, bcm4311 PCI-E with bcm43xx. Yes for some models with iwl3945. || N/A || Suspend-to-RAM perfect, hibernate works fine. || Untested || not tested smart card reader || Everything else works without a hitch<br />
|-<br />
| Latitude D820 || Duke || 3D with NVIDIA drivers || Intel HD Audio with ALSA || Yes || Yes, IPW3945 || Yes || Suspending with [[KDE]] works || Untested || Everything works, even fingerprint reader with ''bioapi'' and ''pam_bioapi'' || Everything else works without a hitch<br />
|-<br />
| Latitude D830 || Don't Panic (2007.08-2) || NVIDIA Quadro NVS 140M with proprietary NVIDIA drivers || ALSA with the {{ic|snd_hda_intel}} module || Yes, with {{ic|tg3}} module || Yes, with {{ic|iwl3965}} module || Yes || Yes, with [[pm-utils]] || Untested || ||<br />
|-<br />
| [[Latitude E5540]] || 2016.02.01 || Haswell-ULT Integrated + GeForce GT 720M using {{Pkg|nvidia}} || Haswell-ULT HD Audio || Yes, e1000e || Yes, Atheros AR9485 || Untested || Untested || No modem || Dock works find (DisplayPort expander, ethernet, USB || Everything seems to work without problems<br />
|-<br />
| Latitude E6420 || 2011.08.19 || Intel HD3000 {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || Yes, e1000e || Yes, bcma-pci-bridge || Untested || Suspend-to-RAM good, hibernate not working || No modem || SD card reader works out-of-the-box, smart card reader works with ccid, opensc, pcsc-tools. Touchpad (alps a10) pointer aspens by default, install {{AUR|psmouse-elantech}}{{Broken package link|{{aur-mirror|psmouse-elantech}}}} from the [[AUR]] to fix it ({{AUR|psmouse-alps}}{{Broken package link|{{aur-mirror|psmouse-alps}}}} does not work anymore) || Ethernet was not working in fresh installation, had to clone repositories to HDD and update<br />
|-<br />
| Latitude E6530 || 2014.10.01 || NVIDIA NVS5200 3D works flawlessly with either {{Pkg|nvidia}} or {{Pkg|xf86-video-nouveau}} (1600x900). || Intel HD Audio with ALSA || Yes || Intel Centrino A-N (with iwlwifi) || Flawless. File transfer and Audio streaming works || Suspend-to-RAM perfect. Hibernate perfect. Disk spindown perfect. || Untested || SD card reader, ALPS touchpad with gestures, and Webcam work flawlessly. Integrated and external microphone ports work flawlessly. Backlit keyboard, monitor backlight, audio up/down/mute controls all work flawlessly. || HDMI video works but must disable Optimus in bios. HDMI audio out works. If Optimus enabled, Intel HD4000 will be used and optirun works. Prevents use of HDMI (VGA only) but otherwise works.<br />
|}<br />
<br />
== Precision ==<br />
{{HCL/Laptops table header}}<br />
| Precision M4800 || 2014.04.01 || System not usable if booted without kernel parameter {{ic|nomodeset}}. Nvidia Quadro K2100M works with {{Pkg|nvidia}}, but [[Nouveau]] does not work because it requires KMS. || Untested || Yes || Yes || Untested || Untested || No modem || N/A || {{ic|nomodeset}} is ''required'' to boot to a usable system, both with the Arch installation media and post-installation.<br />
|}<br />
<br />
== Studio ==<br />
{{HCL/Laptops table header}}<br />
| Studio 1749 || 2013.01.04 || Radeon HD 5650M, {{ic|xf86-video-ati}} is almost flawless (just slower 3D), {{ic|catalyst}} is faster but has various issues. || HDA Intel MID, works with ALSA after adding {{ic|1=options snd-hda-intel index=0 model=dell-m6-dmic}} to {{ic|/etc/modprobe.d/alsa-base.conf}}. HDMI audio has some issues. || Yes || BCM43224, brcmsmac and {{AUR|broadcom-wl}} both work || N/A || Suspend works; hibernate untested. || N/A || SD card reader works, media keys work, web cam, and microphone both work. || Flawless except for poor 3D performance and battery life.<br />
|-<br />
| Studio XPS M1640 || (2009.08) || ATI HD4670 Mobile works with {{Pkg|xf86-video-ati}} (see the forums for 3D support); Catalyst drivers untested || Works with Intel HD Audio and ALSA. || Yes || Works with iwlagn || Bluetooth works || Works but when using {{Pkg|xf86-video-ati}}, there is video corruption upon boot || N/A || Web cam works, media keys work with the {{ic|dell_laptop}} kernel module, IR works, card reader works || Everything basically worked out-of-the-box<br />
|}<br />
<br />
<br />
== XPS ==<br />
{{HCL/Laptops table header}}<br />
| XPS L322 || 2013_03 || Intel HD 4000, with {{Pkg|xf86-video-intel}} || Intel HD Audio with ALSA || No Ethernet port || Yes || Untested || Yes || No modem || No SD card slot || ALPS Touchpad recognized only as PS/2 mouse, two-finger scroll, finger tap-to-click, etc... does not work. Some new mouse drivers suggest a fix but have not worked.<br />
|-<br />
| XPS M1210 || Duke || 3D with NVIDIA open source drivers || SigmaTel audio with ALSA || ''b44'' module, out-of-the-box || IPW 3945, command-line {{Pkg|wireless_tools}} || Untested || Untested || Untested || rico card reader worked out-of-the-box, hot keys using keytouch, web cam works but is unstable. In [[MPlayer]], use {{ic|1=driver=v4l2:device=/dev/video0}} || Everything else works without a hitch<br />
|-<br />
| [[Dell XPS M1330|XPS M1330]] || Don't Panic (2007.08-2) || For dedicated graphics (NVIDIA 8400m) works with NVIDIA package || Works with Intel HD Audio and ALSA, but need to configure microphone || Yes || Works with iwl4965 || Can set Bluetooth but have not tested with any devices || Suspend works fine with [[pm-utils]] (''acpi_cpufreq'' problem: [https://bbs.archlinux.org/viewtopic.php?id=44500 see forums]) || Untested || 2.0 MP web cam works with ''uvcvideo'', media keys work with keytouch or esekeyd, IR remote works, SD card works || Everything basically worked out-of-the-box except the microphone<br />
|-<br />
| [[Dell XPS 13 (2015)|XPS 13 (2015)]] || --- || --- || --- || --- || --- || --- || --- || --- || --- || --- ||<br />
|-<br />
| [[Dell XPS 13 (2016)|XPS 13 (2016)]] || --- || --- || --- || --- || --- || --- || --- || --- || --- || --- ||<br />
|-<br />
}</div>Wooptoohttps://wiki.archlinux.org/index.php?title=System_backup&diff=433025System backup2016-04-28T12:51:42Z<p>Wooptoo: </p>
<hr />
<div>[[Category:System recovery]]<br />
[[cs:Full system backup with rsync]]<br />
[[es:Full system backup with rsync]]<br />
[[ja:Rsync によるフルシステムバックアップ]]<br />
[[zh-tw:Full system backup with rsync]]<br />
{{Related articles start}}<br />
{{Related|Synchronization and backup programs}}<br />
{{Related|rsync}}<br />
{{Related articles end}}<br />
This article is about using [[rsync]] to transfer a copy of your "/" tree, excluding a few select folders. This approach is considered to be better than [[disk cloning]] with {{ic|dd}} since it allows for a different size, partition table and filesystem to be used, and better than copying with {{ic|cp -a}} as well, because it allows greater control over file permissions, attributes, Access Control Lists (ACLs) and extended attributes. [http://www.bestbits.at/acl/about.html]<br />
<br />
This approach will also work well when we want to migrate an existing installation to a new harddrive / [[Solid State Drives]].<br />
<br />
Either method will work even while the system is running. Since it's going to take a while, you may freely browse the web during this time. Worst case scenario you will not get the same opened tabs when you restore the backup (or boot from it) because they were not saved. Not a big deal.<br />
<br />
== With a single command ==<br />
<br />
This command depends on brace expansion available in both the [https://www.gnu.org/software/bash/manual/html_node/Brace-Expansion.html bash] and [http://zsh.sourceforge.net/Doc/Release/Expansion.html#Brace-Expansion zsh] shells. When using a different [[shell]], {{ic|--exclude}} patterns should be repeated manually.<br />
<br />
# rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / ''/path/to/backup/folder''<br />
<br />
Using the {{ic|-aAX}} set of options, the files are transferred in archive mode, ensuring that symbolic links, devices, permissions and ownerships, modification times, [[ACL]]s and extended attributes are preserved.<br />
<br />
The {{ic|--exclude}} option will cause files that match the given patterns to be excluded. The contents of {{ic|/dev}}, {{ic|/proc}}, {{ic|/sys}}, {{ic|/tmp}} and {{ic|/run}} were excluded because they are populated at boot (while the folders themselves are ''not'' created), {{ic|/lost+found}} is filesystem-specific. Quoting the exclude patterns will avoid expansion by [[shell]], which is necessary e.g. when backing up over [[SSH]]. Ending the excluded paths with {{ic|*}} will still ensure that the directories themselves are created if not already existing.<br />
<br />
Be aware that you will need a Linux compatible file system, eg: {{ic|ext4}} to maintain symlinks etc, when using the {{ic|-aAX}} options.<br />
<br />
{{Note|<br />
* If you plan on backing up your system somewhere other than {{ic|/mnt}} or {{ic|/media}}, do not forget to add it to the list of exclude patterns to avoid an infinite loop.<br />
* If there are any bind mounts in the system, they should be excluded as well, so that the bind mounted contents is copied only once.<br />
* If you use a [[swap file]], make sure to exclude it as well.<br />
* Consider also if you want to backup the {{ic|/home/}} folder. If it contains your data, it might be considerably larger than the system. Otherwise consider excluding unimportant subdirectories such as {{ic|/home/*/.thumbnails/*}}, {{ic|/home/*/.cache/mozilla/*}}, {{ic|/home/*/.cache/chromium/*}}, {{ic|/home/*/.local/share/Trash/*}}, depending on software installed on the system. If [[GVFS]] is installed, {{ic|/home/*/.gvfs}} must be excluded to prevent rsync errors.<br />
}}<br />
<br />
You may want to include additional [[rsync]] options, such as the following (see {{ic|man rsync}} for the full list):<br />
<br />
* If you are a heavy user of hardlinks, you might consider adding the {{ic|-H}} option, which is turned off by default as memory expensive, but nowadays it should be no problem on most modern machines. There are a lot of hard links below the {{ic|/usr/}} folder, which save disk space.<br />
* You may want to add rsync's {{ic|--delete}} option if you are running this multiple times to the same backup folder. In this case make sure that the source path does not end with {{ic|/*}}, or this option will only have effect on the files inside the subdirectories of the source directory, but no effect on the files residing directly inside the source directory.<br />
* If you use any sparse files, such as virtual disks, [[Docker]] images and similar, you should add the {{ic|-S}} option.<br />
* The {{ic|--numeric-ids}} option will disable mapping of user and group names, numeric group and user IDs will be transfered instead. This is useful when backing up over [[SSH]] or when using a live system to backup different system disk.<br />
* Choosing {{ic|1=--info=progress2}} option instead of {{ic|-v}} will show overal progress info and transfer speed instead of huge list of files.<br />
<br />
If you wish to restore the backup use the same rsync command that was executed, but with the source and destination reversed.<br />
<br />
== Boot requirements ==<br />
<br />
Having a bootable backup can be useful in case the filesystem becomes corrupt or if an update breaks the system. The backup can also be used as a test bed for updates, with the [testing] repo enabled, etc. If you transferred the system to a different partition or drive and you want to boot it, the process is as simple as updating the backup's {{ic|/etc/fstab}} and your bootloader's configuration file.<br />
<br />
=== Update the fstab ===<br />
<br />
Without rebooting, edit the backup's [[fstab]] to reflect the changes:<br />
{{hc|/path/to/backup/etc/fstab|2=<br />
tmpfs /tmp tmpfs nodev,nosuid 0 0<br />
<br />
<font color=#888888><i>/dev/sda1 /boot ext2 defaults 0 2<br />
/dev/sda5 none swap defaults 0 0<br />
/dev/sda6 / ext4 defaults 0 1<br />
/dev/sda7 /home ext4 defaults 0 2</i></font>}}<br />
<br />
Because rsync has performed a recursive copy of the ''entire'' root filesystem, all of the {{ic|sda}} mountpoints are problematic and booting the backup will fail. In this example, all of the offending entries are replaced with a single one:<br />
<br />
{{hc|/path/to/backup/etc/fstab|<br />
tmpfs /tmp tmpfs nodev,nosuid 0 0<br />
<br />
/dev/'''sdb1''' / ext4 defaults 0 1}}<br />
<br />
Remember to use the proper device name and filesystem type.<br />
<br />
=== Update the bootloader's configuration file ===<br />
<br />
This section assumes that you backed up the system to another drive or partition, that your current bootloader is working fine, and that you want to boot from the backup as well.<br />
<br />
For [[Syslinux]], all you need to do is duplicate the current entry, except pointing to a different drive or partition.<br />
<br />
{{Tip|Instead of editing {{ic|syslinux.cfg}}, you can also temporarily edit the menu during boot. When the menu shows up, press the {{ic|Tab}} key and change the relevant entries. Partitions are counted from one, drives are counted from zero.}}<br />
<br />
For [[GRUB]], it is recommended that you automatically [[GRUB#Generate_the_main_configuration_file|re-generate the main configuration file]].<br />
<br />
Also verify the new menu entry in {{ic|/boot/grub/grub.cfg}}. Make sure the UUID is matching the new partition, otherwise it could still boot the old system. Find the UUID of a partition as follows:<br />
<br />
# lsblk -no NAME,UUID /dev/sdb3<br />
<br />
where you substitute the desired partition for /dev/sdb3. To list the UUIDs of partitions grub thinks it can boot, use grep:<br />
<br />
# grep UUID= /boot/grub/grub.cfg<br />
<br />
{{Accuracy|How is mkinitcpio related to the UUID problem?}}<br />
<br />
If the one you found from lsblk is not found by grep, then grub-mkconfig did not work. Most likely, you will have to [[Change root]] into the duplicate file system and then use [[mkinitcpio]]. For example, if you had used rsync to duplicate root on /dev/sdb3 then change root and use mkinitcpio as follows:<br />
<br />
# mkdir /mnt/arch<br />
# mount /dev/sdb3 /mnt/arch<br />
# cd /mnt/arch<br />
# mount -t proc proc proc/<br />
# mount --rbind /sys sys/<br />
# mount --rbind /dev dev/<br />
# chroot /mnt/arch /bin/bash<br />
# mkinitcpio -p linux<br />
<br />
After exiting, verify the new UUID is included.<br />
<br />
== First boot ==<br />
<br />
Reboot the computer and select the right entry in the bootloader. This will load the system for the first time. All peripherals should be detected and the empty folders in {{ic|/}} will be populated.<br />
<br />
Now you can re-edit {{ic|/etc/fstab}} to add the previously removed partitions and mount points.<br />
<br />
If you transferred the data from HDD to SSD (solid state drive), do not forget to activate TRIM. Also consider using HDD and tmpfs mount points to reduce SSD wearing - see [[Maximizing performance#Relocate files to tmpfs]] and [[Solid State Drives#Tips for minimizing disk reads/writes]].<br />
<br />
{{Note|You may have to reboot again in order to get all services and daemons working correctly. Personally, pulseaudio would not initialise because of a module loading error. I restarted the dbus.service to make it work.}}<br />
<br />
== See also ==<br />
<br />
* [http://blog.pointsoftware.ch/index.php/howto-local-and-remote-snapshot-backup-using-rsync-with-hard-links/ Howto – local and remote snapshot backup using rsync with hard links] Includes file deduplication with hard-links, MD5 integrity signature, 'chattr' protection, filter rules, disk quota, retention policy with exponential distribution (backups rotation while saving more recent backups than older)</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Migrating_to_SSD&diff=433023Migrating to SSD2016-04-28T12:49:00Z<p>Wooptoo: Redirected page to Full system backup with rsync</p>
<hr />
<div>#REDIRECT [[Full_system_backup_with_rsync]] Migrating an existing Arch install to a SSD.</div>Wooptoohttps://wiki.archlinux.org/index.php?title=System_backup&diff=433022System backup2016-04-28T12:46:54Z<p>Wooptoo: </p>
<hr />
<div>[[Category:System recovery]]<br />
[[cs:Full system backup with rsync]]<br />
[[es:Full system backup with rsync]]<br />
[[ja:Rsync によるフルシステムバックアップ]]<br />
[[zh-tw:Full system backup with rsync]]<br />
{{Related articles start}}<br />
{{Related|Synchronization and backup programs}}<br />
{{Related|rsync}}<br />
{{Related articles end}}<br />
This article is about using [[rsync]] to transfer a copy of your "/" tree, excluding a few select folders. This approach is considered to be better than [[disk cloning]] with {{ic|dd}} since it allows for a different size, partition table and filesystem to be used, and better than copying with {{ic|cp -a}} as well, because it allows greater control over file permissions, attributes, Access Control Lists (ACLs) and extended attributes. [http://www.bestbits.at/acl/about.html]<br />
<br />
This approach will also work well when we want to migrate an existing installation to a new harddrive / SSD.<br />
<br />
Either method will work even while the system is running. Since it's going to take a while, you may freely browse the web during this time. Worst case scenario you will not get the same opened tabs when you restore the backup (or boot from it) because they were not saved. Not a big deal.<br />
<br />
== With a single command ==<br />
<br />
This command depends on brace expansion available in both the [https://www.gnu.org/software/bash/manual/html_node/Brace-Expansion.html bash] and [http://zsh.sourceforge.net/Doc/Release/Expansion.html#Brace-Expansion zsh] shells. When using a different [[shell]], {{ic|--exclude}} patterns should be repeated manually.<br />
<br />
# rsync -aAXv --exclude={"/dev/*","/proc/*","/sys/*","/tmp/*","/run/*","/mnt/*","/media/*","/lost+found"} / ''/path/to/backup/folder''<br />
<br />
Using the {{ic|-aAX}} set of options, the files are transferred in archive mode, ensuring that symbolic links, devices, permissions and ownerships, modification times, [[ACL]]s and extended attributes are preserved.<br />
<br />
The {{ic|--exclude}} option will cause files that match the given patterns to be excluded. The contents of {{ic|/dev}}, {{ic|/proc}}, {{ic|/sys}}, {{ic|/tmp}} and {{ic|/run}} were excluded because they are populated at boot (while the folders themselves are ''not'' created), {{ic|/lost+found}} is filesystem-specific. Quoting the exclude patterns will avoid expansion by [[shell]], which is necessary e.g. when backing up over [[SSH]]. Ending the excluded paths with {{ic|*}} will still ensure that the directories themselves are created if not already existing.<br />
<br />
Be aware that you will need a Linux compatible file system, eg: {{ic|ext4}} to maintain symlinks etc, when using the {{ic|-aAX}} options.<br />
<br />
{{Note|<br />
* If you plan on backing up your system somewhere other than {{ic|/mnt}} or {{ic|/media}}, do not forget to add it to the list of exclude patterns to avoid an infinite loop.<br />
* If there are any bind mounts in the system, they should be excluded as well, so that the bind mounted contents is copied only once.<br />
* If you use a [[swap file]], make sure to exclude it as well.<br />
* Consider also if you want to backup the {{ic|/home/}} folder. If it contains your data, it might be considerably larger than the system. Otherwise consider excluding unimportant subdirectories such as {{ic|/home/*/.thumbnails/*}}, {{ic|/home/*/.cache/mozilla/*}}, {{ic|/home/*/.cache/chromium/*}}, {{ic|/home/*/.local/share/Trash/*}}, depending on software installed on the system. If [[GVFS]] is installed, {{ic|/home/*/.gvfs}} must be excluded to prevent rsync errors.<br />
}}<br />
<br />
You may want to include additional [[rsync]] options, such as the following (see {{ic|man rsync}} for the full list):<br />
<br />
* If you are a heavy user of hardlinks, you might consider adding the {{ic|-H}} option, which is turned off by default as memory expensive, but nowadays it should be no problem on most modern machines. There are a lot of hard links below the {{ic|/usr/}} folder, which save disk space.<br />
* You may want to add rsync's {{ic|--delete}} option if you are running this multiple times to the same backup folder. In this case make sure that the source path does not end with {{ic|/*}}, or this option will only have effect on the files inside the subdirectories of the source directory, but no effect on the files residing directly inside the source directory.<br />
* If you use any sparse files, such as virtual disks, [[Docker]] images and similar, you should add the {{ic|-S}} option.<br />
* The {{ic|--numeric-ids}} option will disable mapping of user and group names, numeric group and user IDs will be transfered instead. This is useful when backing up over [[SSH]] or when using a live system to backup different system disk.<br />
* Choosing {{ic|1=--info=progress2}} option instead of {{ic|-v}} will show overal progress info and transfer speed instead of huge list of files.<br />
<br />
If you wish to restore the backup use the same rsync command that was executed, but with the source and destination reversed.<br />
<br />
== Boot requirements ==<br />
<br />
Having a bootable backup can be useful in case the filesystem becomes corrupt or if an update breaks the system. The backup can also be used as a test bed for updates, with the [testing] repo enabled, etc. If you transferred the system to a different partition or drive and you want to boot it, the process is as simple as updating the backup's {{ic|/etc/fstab}} and your bootloader's configuration file.<br />
<br />
=== Update the fstab ===<br />
<br />
Without rebooting, edit the backup's [[fstab]] to reflect the changes:<br />
{{hc|/path/to/backup/etc/fstab|2=<br />
tmpfs /tmp tmpfs nodev,nosuid 0 0<br />
<br />
<font color=#888888><i>/dev/sda1 /boot ext2 defaults 0 2<br />
/dev/sda5 none swap defaults 0 0<br />
/dev/sda6 / ext4 defaults 0 1<br />
/dev/sda7 /home ext4 defaults 0 2</i></font>}}<br />
<br />
Because rsync has performed a recursive copy of the ''entire'' root filesystem, all of the {{ic|sda}} mountpoints are problematic and booting the backup will fail. In this example, all of the offending entries are replaced with a single one:<br />
<br />
{{hc|/path/to/backup/etc/fstab|<br />
tmpfs /tmp tmpfs nodev,nosuid 0 0<br />
<br />
/dev/'''sdb1''' / ext4 defaults 0 1}}<br />
<br />
Remember to use the proper device name and filesystem type.<br />
<br />
=== Update the bootloader's configuration file ===<br />
<br />
This section assumes that you backed up the system to another drive or partition, that your current bootloader is working fine, and that you want to boot from the backup as well.<br />
<br />
For [[Syslinux]], all you need to do is duplicate the current entry, except pointing to a different drive or partition.<br />
<br />
{{Tip|Instead of editing {{ic|syslinux.cfg}}, you can also temporarily edit the menu during boot. When the menu shows up, press the {{ic|Tab}} key and change the relevant entries. Partitions are counted from one, drives are counted from zero.}}<br />
<br />
For [[GRUB]], it is recommended that you automatically [[GRUB#Generate_the_main_configuration_file|re-generate the main configuration file]].<br />
<br />
Also verify the new menu entry in {{ic|/boot/grub/grub.cfg}}. Make sure the UUID is matching the new partition, otherwise it could still boot the old system. Find the UUID of a partition as follows:<br />
<br />
# lsblk -no NAME,UUID /dev/sdb3<br />
<br />
where you substitute the desired partition for /dev/sdb3. To list the UUIDs of partitions grub thinks it can boot, use grep:<br />
<br />
# grep UUID= /boot/grub/grub.cfg<br />
<br />
{{Accuracy|How is mkinitcpio related to the UUID problem?}}<br />
<br />
If the one you found from lsblk is not found by grep, then grub-mkconfig did not work. Most likely, you will have to [[Change root]] into the duplicate file system and then use [[mkinitcpio]]. For example, if you had used rsync to duplicate root on /dev/sdb3 then change root and use mkinitcpio as follows:<br />
<br />
# mkdir /mnt/arch<br />
# mount /dev/sdb3 /mnt/arch<br />
# cd /mnt/arch<br />
# mount -t proc proc proc/<br />
# mount --rbind /sys sys/<br />
# mount --rbind /dev dev/<br />
# chroot /mnt/arch /bin/bash<br />
# mkinitcpio -p linux<br />
<br />
After exiting, verify the new UUID is included.<br />
<br />
== First boot ==<br />
<br />
Reboot the computer and select the right entry in the bootloader. This will load the system for the first time. All peripherals should be detected and the empty folders in {{ic|/}} will be populated.<br />
<br />
Now you can re-edit {{ic|/etc/fstab}} to add the previously removed partitions and mount points.<br />
<br />
If you transferred the data from HDD to SSD (solid state drive), do not forget to activate TRIM. Also consider using HDD and tmpfs mount points to reduce SSD wearing - see [[Maximizing performance#Relocate files to tmpfs]] and [[Solid State Drives#Tips for minimizing disk reads/writes]].<br />
<br />
{{Note|You may have to reboot again in order to get all services and daemons working correctly. Personally, pulseaudio would not initialise because of a module loading error. I restarted the dbus.service to make it work.}}<br />
<br />
== See also ==<br />
<br />
* [http://blog.pointsoftware.ch/index.php/howto-local-and-remote-snapshot-backup-using-rsync-with-hard-links/ Howto – local and remote snapshot backup using rsync with hard links] Includes file deduplication with hard-links, MD5 integrity signature, 'chattr' protection, filter rules, disk quota, retention policy with exponential distribution (backups rotation while saving more recent backups than older)</div>Wooptoohttps://wiki.archlinux.org/index.php?title=YubiKey&diff=407494YubiKey2015-10-30T10:30:47Z<p>Wooptoo: /* Enabling U2F with Chromium/Chrome */</p>
<hr />
<div>[[Category:Security]]<br />
[[ja:Yubikey]]<br />
The Yubikey is a small [http://en.wikipedia.org/wiki/Security_token USB token] that generates [http://en.wikipedia.org/wiki/One-time_password One-Time Passwords] (OTP).<br />
It is manufactured by [http://www.yubico.com/ Yubico].<br />
<br />
One of its strengths is that it emulates a USB keyboard to send the OTP as text, and thus requires only USB HID drivers found on practically all desktop computers.<br />
<br />
== Introduction ==<br />
<br />
=== How does it work ===<br />
<br />
Yubikey's authentication protocol is based on [http://en.wikipedia.org/wiki/Symmetric_cryptography symmetric cryptography].<br />
More specifically, each Yubikey contains a 128-bit [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES] key, unique to that key.<br />
It is used to encrypt a token made of different fields such as the ID of the key, a counter, a random number, etc.<br />
The OTP is made from concatenating the ID of the key with this encrypted token.<br />
<br />
This OTP is sent to the target system, to which we want to authenticate.<br />
This target system asks a validation server if the OTP is good.<br />
The validation server has a mapping of Yubikey IDs -> AES key.<br />
Using the key ID in the OTP, it can thus retrieve the AES key and decrypt the other part of the OTP.<br />
If it looks OK (plain-text ID and encrypted ID are the same, the counter is bigger than the last seen one to prevent [http://en.wikipedia.org/wiki/Replay_attack replay attacks]...), then authentication is successful.<br />
<br />
The validation server sends that authentication status back to the target system, which grants access or not based on that response.<br />
<br />
=== Security risks ===<br />
<br />
==== AES key compromission ====<br />
<br />
As you can imagine, the AES key should be kept very secret.<br />
It can not be retrieved from the Yubikey itself (or it should not, at least not with software).<br />
It is present in the validation server though, so the security of this server is very important.<br />
<br />
==== Validation requests/responses tampering ====<br />
<br />
Since the target system relies on the ruling of the validation server, a trivial attack would be to impersonate the validation server.<br />
The target system thus needs to authenticate the validation server.<br />
2 methods are available :<br />
* '''HMAC''': This is also symmetric crypto, the target server and validation server share a key that is used to sign requests and responses.<br />
* '''TLS''': Requests and responses travel via HTTP, so TLS (HTTPS) can be used to authenticate and encrypt the connection.<br />
<br />
=== YubiCloud and validation servers ===<br />
<br />
When you buy a Yubikey, it is preloaded with an AES key that is known only to Yubico.<br />
They will not even communicate it to you.<br />
Yubico provides a validation server with free unlimited access (YubiCloud).<br />
It also offers open-source implementations of the server.<br />
<br />
So you can either:<br />
* choose to use your Yubikey with its preloaded AES key and validate against Yubico's validation server ;<br />
* or load a new AES key in your Yubikey and run your own validation server.<br />
<br />
{{Note|To authenticate the Yubico validation server, you can:<br />
* '''with HMAC''': use https://upgrade.yubico.com/getapikey/ to get an HMAC key and ID<br />
* '''with HTTPS''': the validation server's certificate is signed by GoDaddy, that is cool because it is thus trusted by default in Arch installs (at least if you have package ca-certificates)}}<br />
<br />
== Two-factor authentication with SSH ==<br />
<br />
{{Note|See also: https://developers.yubico.com/yubico-pam/Yubikey_and_SSH_via_PAM.html}}<br />
<br />
This details how to use a Yubikey to have [http://en.wikipedia.org/wiki/Two-factor_authentication two-factor authentication] with SSH, that is, to use both a password and a Yubikey-generated OTP.<br />
<br />
=== Prerequisites ===<br />
<br />
Install {{Pkg|yubico-pam}}.<br />
<br />
{{Note|If you are configuring a distant server to use Yubikey, you should open at least one additional, rescue SSH session, so that you are not locked out of your server if the configuration does not work and you exit your main session inadvertently}}<br />
<br />
=== PAM configuration ===<br />
<br />
You have to edit {{ic|/etc/pam.d/sshd}}, and modify the line that reads :<br />
auth required pam_unix.so<br />
into<br />
auth required pam_unix.so use_first_pass<br />
<br />
Then do one of the following. I personally would highly recommend the HTTPS method, but the choice is yours. --[[User:Gohu|Gohu]] 17:49, 24 April 2011 (EDT)<br />
<br />
==== If using HTTPS to authenticate the validation server ====<br />
Insert the following line '''before''' the previously modified {{ic|pam_unix.so}} line.<br />
auth required pam_yubico.so id=1 url=https://api.yubico.com/wsapi/2.0/verify?id=%d&otp=%s<br />
The id=1 is of no real use but it is required.<br />
{{Note|If you run your own validation server, modify the {{ic|url}} parameter to point to your server. If you are not running your own validation server, you may omit the {{ic|url}} parameter entirely as it is the default.}}<br />
{{Note|These instructions are outdated and are unlikely to work. It may be useful to go to https://developers.yubico.com/yubico-pam/Yubikey_and_SSH_via_PAM.html for up to date instructions while someone finds the time to update the Arch Wiki.}}<br />
<br />
==== If using HMAC to authenticate the validation server ====<br />
Insert the following line '''before''' the previously modified {{ic|pam_unix.so}} line.<br />
auth required pam_yubico.so id=1234 key=YnVubmllcyBhcmUgY29vbAo=<br />
where {{ic|id}} and {{ic|key}} are your own HMAC ID and key, requested from Yubico as explained above.<br />
<br />
{{Note|HMAC credentials should be unique to a single target server. That way, if an attacker finds them, he will not be able to craft responses to authenticate to other target servers you own}}<br />
<br />
{{Note|We did not specify the {{ic|url}} parameter: it defaults to Yubico's HTTP (non-TLS) server}}<br />
<br />
You should also disallow unprivileged users to read the file to prevent them from seeing the HMAC credentials:<br />
# chmod o-r /etc/pam.d/sshd<br />
<br />
{{Note|If you run your own validation server, add the {{ic|url}} parameter to point to your server. If you are not running your own validation server, you may omit the {{ic|url}} parameter entirely as it is the default.}}<br />
<br />
=== SSHD configuration ===<br />
<br />
You should check that {{ic|/etc/ssh/sshd_config}} contains these lines and that they are not commented, but I believe this is the default.<br />
ChallengeResponseAuthentication no<br />
UsePAM yes<br />
<br />
=== That is it! ===<br />
<br />
You should not need to restart anything if you just touched the PAM config file.<br />
<br />
To log in, at the {{ic|Password:}} prompt of SSH, you have to type your password '''without pressing enter''' and touch the Yubikey's button.<br />
The Yubikey should send a return at the end of the OTP so you do not need to touch the enter key at all.<br />
<br />
{{Note|If you remove use_first_pass from the pam_unix.so line, you can just use your YubiKey first, then it will prompt for your password after the YubiKey line.}}<br />
<br />
=== Explanation ===<br />
This works because the prompt is {{ic|pam_yubico.so}}'s one, since this module is before {{ic|pam_unix.so}}, which does basic password authentication.<br />
So, you are giving a string that is the concatenation of your password and the OTP to {{ic|pam_yubico.so}}.<br />
Since the OTPs have a fixed length (let us call this size N), it just has to get the last N characters to retrieve the OTP, and it assumes that the other characters at the start are the password.<br />
It tries to validate the OTP, and in case of success, sends the password to the next PAM module, {{ic|pam_unix.so}}, which was instructed not to prompt for the password, but to receive it from the previous module, with {{ic|use_first_pass}}.<br />
<br />
== Installing the OATH Applet for a Yubikey NEO ==<br />
These steps will allow you to install the OATH applet onto your Yubikey NEO. This allows the use of Yubico Authenticator in the Google Play Store.<br />
{{Note|1=These steps are only for NEOs with a firmware version <= 3.1.2. The current generation NEOs (with U2F) come with the OpenPGP applet already installed)}}<br />
<br />
=== Configure the NEO as a CCID Device ===<br />
# Get {{AUR| yubikey-personalization-gui-git}} from the AUR.<br />
# Add the udev rules and reboot so you can manage the YubiKey without needing to be root<br />
# Run {{ic | ykpersonalize -m82}}, enter {{ic | y}}, and hit enter.<br />
<br />
=== Install the Applet ===<br />
# Install {{AUR| gpshell}}, {{AUR| gppcscconnectionplugin}}, {{AUR| globalplatform}}, and {{Pkg | pcsclite}}.<br />
# Start {{ic | pcscd}} with {{ic | sudo systemctl start pcscd}}.<br />
# Download the most recent CAP file from the [http://opensource.yubico.com/ykneo-oath/releases.html ykneo-oath] site.<br />
# Download {{ic | gpinstall.txt}} from [https://github.com/Yubico/ykneo-oath/blob/master/gpinstall.txt GitHub].<br />
# Edit the line in gpinstall.txt beginning with {{ic | install -file}} to reflect the path where the CAP file is located.<br />
# Open a terminal and run {{ic| gpshell <location of gpinstall.txt>}}<br />
# Ideally, a bunch of text will scroll by and it ends saying something like<br />
{{ bc | Command --> 80E88013D7C000C400BE00C700CA00CA00B400BE00CE00D200D500D700B000DB00C700DF00BEFFFF00BE00E400AC00AE00AE00DB00E700A<br />
A00EA00ED00ED00ED00BE00EF00F100F400F100F700FA00FF00BE00F700AA01010103010700CA00C400B400AA00F700B400AA00B600C7010C<br />
010C00AA0140012001B0056810B0013005600000056810E0011006B4B44304B44404B44106B44B4405B443400343B002410636810E06B4B44<br />
407326810B004B43103441003334002B102B404B3B403BB4003B440076820A4100221024405B4341008B44600000231066820A100<br />
Wrapped command --> 84E88013DFC000C400BE00C700CA00CA00B400BE00CE00D200D500D700B000DB00C700DF00BEFFFF00BE00E400AC00AE00AE00DB00E700A<br />
A00EA00ED00ED00ED00BE00EF00F100F400F100F700FA00FF00BE00F700AA01010103010700CA00C400B400AA00F700B400AA00B600C7010C<br />
010C00AA0140012001B0056810B0013005600000056810E0011006B4B44304B44404B44106B44B4405B443400343B002410636810E06B4B44<br />
407326810B004B43103441003334002B102B404B3B403BB4003B440076820A4100221024405B4341008B44600000231066820A15D848CB77<br />
27D0EDA00<br />
Response <-- 009000<br />
Command --> 80E60C002107A000000527210108A00000052721010108A000000527210101010003C901000000<br />
Wrapped command --> 84E60C002907A000000527210108A00000052721010108A000000527210101010003C9010000B4648127914A4C7C00<br />
Response <-- 009000<br />
card_disconnect<br />
release_context}}<br />
# Unplug the NEO and try it with the Yubico Authenticator app<br />
<br />
===(Optional) Install the Yubico Authenticator Desktop client===<br />
<br />
You can get the desktop version of the Yubico Authenticator by installing {{AUR|yubico-yubioath-desktop-git}}.<br />
<br />
== Enabling U2F in the browser ==<br />
<br />
=== Chromium/Chrome ===<br />
<br />
In order for the U2F functionality to work with Chromium you need to install the {{Pkg | libu2f-host}} library.<br />
This provides the [https://github.com/Yubico/libu2f-host/blob/master/70-u2f.rules udev rules] required to enable access to the Yubikey as a user.<br />
Yubikey is by default only accessible by root, and without these rules Chromium will give an error.<br />
<br />
=== Firefox ===<br />
<br />
To enable U2F support in Firefox, you need to install [https://github.com/prefiks/u2f4moz this addon].<br />
Native support is currently work in progress.</div>Wooptoohttps://wiki.archlinux.org/index.php?title=YubiKey&diff=406133YubiKey2015-10-22T08:41:59Z<p>Wooptoo: </p>
<hr />
<div>[[Category:Security]]<br />
[[ja:Yubikey]]<br />
The Yubikey is a small [http://en.wikipedia.org/wiki/Security_token USB token] that generates [http://en.wikipedia.org/wiki/One-time_password One-Time Passwords] (OTP).<br />
It is manufactured by [http://www.yubico.com/ Yubico].<br />
<br />
One of its strengths is that it emulates a USB keyboard to send the OTP as text, and thus requires only USB HID drivers found on practically all desktop computers.<br />
<br />
== Introduction ==<br />
<br />
=== How does it work ===<br />
<br />
Yubikey's authentication protocol is based on [http://en.wikipedia.org/wiki/Symmetric_cryptography symmetric cryptography].<br />
More specifically, each Yubikey contains a 128-bit [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES] key, unique to that key.<br />
It is used to encrypt a token made of different fields such as the ID of the key, a counter, a random number, etc.<br />
The OTP is made from concatenating the ID of the key with this encrypted token.<br />
<br />
This OTP is sent to the target system, to which we want to authenticate.<br />
This target system asks a validation server if the OTP is good.<br />
The validation server has a mapping of Yubikey IDs -> AES key.<br />
Using the key ID in the OTP, it can thus retrieve the AES key and decrypt the other part of the OTP.<br />
If it looks OK (plain-text ID and encrypted ID are the same, the counter is bigger than the last seen one to prevent [http://en.wikipedia.org/wiki/Replay_attack replay attacks]...), then authentication is successful.<br />
<br />
The validation server sends that authentication status back to the target system, which grants access or not based on that response.<br />
<br />
=== Security risks ===<br />
<br />
==== AES key compromission ====<br />
<br />
As you can imagine, the AES key should be kept very secret.<br />
It can not be retrieved from the Yubikey itself (or it should not, at least not with software).<br />
It is present in the validation server though, so the security of this server is very important.<br />
<br />
==== Validation requests/responses tampering ====<br />
<br />
Since the target system relies on the ruling of the validation server, a trivial attack would be to impersonate the validation server.<br />
The target system thus needs to authenticate the validation server.<br />
2 methods are available :<br />
* '''HMAC''': This is also symmetric crypto, the target server and validation server share a key that is used to sign requests and responses.<br />
* '''TLS''': Requests and responses travel via HTTP, so TLS (HTTPS) can be used to authenticate and encrypt the connection.<br />
<br />
=== YubiCloud and validation servers ===<br />
<br />
When you buy a Yubikey, it is preloaded with an AES key that is known only to Yubico.<br />
They will not even communicate it to you.<br />
Yubico provides a validation server with free unlimited access (YubiCloud).<br />
It also offers open-source implementations of the server.<br />
<br />
So you can either:<br />
* choose to use your Yubikey with its preloaded AES key and validate against Yubico's validation server ;<br />
* or load a new AES key in your Yubikey and run your own validation server.<br />
<br />
{{Note|To authenticate the Yubico validation server, you can:<br />
* '''with HMAC''': use https://upgrade.yubico.com/getapikey/ to get an HMAC key and ID<br />
* '''with HTTPS''': the validation server's certificate is signed by GoDaddy, that is cool because it is thus trusted by default in Arch installs (at least if you have package ca-certificates)}}<br />
<br />
== Two-factor authentication with SSH ==<br />
<br />
{{Note|See also: https://developers.yubico.com/yubico-pam/Yubikey_and_SSH_via_PAM.html}}<br />
<br />
This details how to use a Yubikey to have [http://en.wikipedia.org/wiki/Two-factor_authentication two-factor authentication] with SSH, that is, to use both a password and a Yubikey-generated OTP.<br />
<br />
=== Prerequisites ===<br />
<br />
The necessary packages are on the AUR.<br />
The one you need for TFA with SSH is the {{AUR|yubico-pam-git}}.<br />
It depends on:<br />
* {{Pkg|yubico-c}}<br />
* {{AUR|yubico-c-client-git}}<br />
* {{AUR|yubikey-personalization-git}}<br />
<br />
Install them.<br />
<br />
{{Note|If you are configuring a distant server to use Yubikey, you should open at least one additional, rescue SSH session, so that you are not locked out of your server if the configuration does not work and you exit your main session inadvertently}}<br />
<br />
=== PAM configuration ===<br />
<br />
You have to edit {{ic|/etc/pam.d/sshd}}, and modify the line that reads :<br />
auth required pam_unix.so<br />
into<br />
auth required pam_unix.so use_first_pass<br />
<br />
Then do one of the following. I personally would highly recommend the HTTPS method, but the choice is yours. --[[User:Gohu|Gohu]] 17:49, 24 April 2011 (EDT)<br />
<br />
==== If using HTTPS to authenticate the validation server ====<br />
Insert the following line '''before''' the previously modified {{ic|pam_unix.so}} line.<br />
auth required pam_yubico.so id=1 url=https://api.yubico.com/wsapi/2.0/verify?id=%d&otp=%s<br />
The id=1 is of no real use but it is required.<br />
{{Note|If you run your own validation server, modify the {{ic|url}} parameter to point to your server. If you are not running your own validation server, you may omit the {{ic|url}} parameter entirely as it is the default.}}<br />
{{Note|These instructions are outdated and are unlikely to work. It may be useful to go to https://developers.yubico.com/yubico-pam/Yubikey_and_SSH_via_PAM.html for up to date instructions while someone finds the time to update the Arch Wiki.}}<br />
<br />
==== If using HMAC to authenticate the validation server ====<br />
Insert the following line '''before''' the previously modified {{ic|pam_unix.so}} line.<br />
auth required pam_yubico.so id=1234 key=YnVubmllcyBhcmUgY29vbAo=<br />
where {{ic|id}} and {{ic|key}} are your own HMAC ID and key, requested from Yubico as explained above.<br />
{{Note|HMAC credentials should be unique to a single target server. That way, if an attacker finds them, he will not be able to craft responses to authenticate to other target servers you own}}<br />
{{Note|We did not specify the {{ic|url}} parameter: it defaults to Yubico's HTTP (non-TLS) server}}<br />
You should also disallow unprivileged users to read the file to prevent them from seeing the HMAC credentials:<br />
# chmod o-r /etc/pam.d/sshd<br />
<br />
{{Note|If you run your own validation server, add the {{ic|url}} parameter to point to your server. If you are not running your own validation server, you may omit the {{ic|url}} parameter entirely as it is the default.}}<br />
<br />
=== SSHD configuration ===<br />
<br />
You should check that {{ic|/etc/ssh/sshd_config}} contains these lines and that they are not commented, but I believe this is the default.<br />
ChallengeResponseAuthentication no<br />
UsePAM yes<br />
<br />
=== That is it! ===<br />
<br />
You should not need to restart anything if you just touched the PAM config file.<br />
<br />
To log in, at the {{ic|Password:}} prompt of SSH, you have to type your password '''without pressing enter''' and touch the Yubikey's button.<br />
The Yubikey should send a return at the end of the OTP so you do not need to touch the enter key at all.<br />
<br />
{{Note|If you remove use_first_pass from the pam_unix.so line, you can just use your YubiKey first, then it will prompt for your password after the YubiKey line.}}<br />
<br />
=== Explanation ===<br />
This works because the prompt is {{ic|pam_yubico.so}}'s one, since this module is before {{ic|pam_unix.so}}, which does basic password authentication.<br />
So, you are giving a string that is the concatenation of your password and the OTP to {{ic|pam_yubico.so}}.<br />
Since the OTPs have a fixed length (let us call this size N), it just has to get the last N characters to retrieve the OTP, and it assumes that the other characters at the start are the password.<br />
It tries to validate the OTP, and in case of success, sends the password to the next PAM module, {{ic|pam_unix.so}}, which was instructed not to prompt for the password, but to receive it from the previous module, with {{ic|use_first_pass}}.<br />
<br />
== Installing the OATH Applet for a Yubikey NEO ==<br />
These steps will allow you to install the OATH applet onto your Yubikey NEO. This allows the use of Yubico Authenticator in the Google Play Store.<br />
{{Note|1=These steps are only for NEOs with a firmware version <= 3.1.2. The current generation NEOs (with U2F) come with the OpenPGP applet already installed)}}<br />
<br />
=== Configure the NEO as a CCID Device ===<br />
# Get {{AUR| yubikey-personalization-gui-git}} from the AUR.<br />
# Add the udev rules and reboot so you can manage the YubiKey without needing to be root<br />
# Run {{ic | ykpersonalize -m82}}, enter {{ic | y}}, and hit enter.<br />
<br />
=== Install the Applet ===<br />
# Install {{AUR| gpshell}}, {{AUR| gppcscconnectionplugin}}, {{AUR| globalplatform}}, and {{Pkg | pcsclite}}.<br />
# Start {{ic | pcscd}} with {{ic | sudo systemctl start pcscd}}.<br />
# Download the most recent CAP file from the [http://opensource.yubico.com/ykneo-oath/releases.html ykneo-oath] site.<br />
# Download {{ic | gpinstall.txt}} from [https://github.com/Yubico/ykneo-oath/blob/master/gpinstall.txt GitHub].<br />
# Edit the line in gpinstall.txt beginning with {{ic | install -file}} to reflect the path where the CAP file is located.<br />
# Open a terminal and run {{ic| gpshell <location of gpinstall.txt>}}<br />
# Ideally, a bunch of text will scroll by and it ends saying something like<br />
{{ bc | Command --> 80E88013D7C000C400BE00C700CA00CA00B400BE00CE00D200D500D700B000DB00C700DF00BEFFFF00BE00E400AC00AE00AE00DB00E700A<br />
A00EA00ED00ED00ED00BE00EF00F100F400F100F700FA00FF00BE00F700AA01010103010700CA00C400B400AA00F700B400AA00B600C7010C<br />
010C00AA0140012001B0056810B0013005600000056810E0011006B4B44304B44404B44106B44B4405B443400343B002410636810E06B4B44<br />
407326810B004B43103441003334002B102B404B3B403BB4003B440076820A4100221024405B4341008B44600000231066820A100<br />
Wrapped command --> 84E88013DFC000C400BE00C700CA00CA00B400BE00CE00D200D500D700B000DB00C700DF00BEFFFF00BE00E400AC00AE00AE00DB00E700A<br />
A00EA00ED00ED00ED00BE00EF00F100F400F100F700FA00FF00BE00F700AA01010103010700CA00C400B400AA00F700B400AA00B600C7010C<br />
010C00AA0140012001B0056810B0013005600000056810E0011006B4B44304B44404B44106B44B4405B443400343B002410636810E06B4B44<br />
407326810B004B43103441003334002B102B404B3B403BB4003B440076820A4100221024405B4341008B44600000231066820A15D848CB77<br />
27D0EDA00<br />
Response <-- 009000<br />
Command --> 80E60C002107A000000527210108A00000052721010108A000000527210101010003C901000000<br />
Wrapped command --> 84E60C002907A000000527210108A00000052721010108A000000527210101010003C9010000B4648127914A4C7C00<br />
Response <-- 009000<br />
card_disconnect<br />
release_context}}<br />
# Unplug the NEO and try it with the Yubico Authenticator app<br />
<br />
===(Optional) Install the Yubico Authenticator Desktop client===<br />
<br />
You can get the desktop version of the Yubico Authenticator by installing {{AUR|yubico-yubioath-desktop-git}}.<br />
<br />
== Enabling U2F with Chromium/Chrome ==<br />
<br />
In order for the U2F functionality to work with Chromium you need to install the {{Pkg | libu2f-host}} library.<br />
This provides the [https://github.com/Yubico/libu2f-host/blob/master/70-u2f.rules udev rules] required to enable access to the Yubikey as a user.<br />
Yubikey is by default only accessible by root, and without these rules Chromium will give an error.</div>Wooptoohttps://wiki.archlinux.org/index.php?title=YubiKey&diff=406131YubiKey2015-10-22T08:38:24Z<p>Wooptoo: </p>
<hr />
<div>[[Category:Security]]<br />
[[ja:Yubikey]]<br />
The Yubikey is a small [http://en.wikipedia.org/wiki/Security_token USB token] that generates [http://en.wikipedia.org/wiki/One-time_password One-Time Passwords] (OTP).<br />
It is manufactured by [http://www.yubico.com/ Yubico].<br />
<br />
One of its strengths is that it emulates a USB keyboard to send the OTP as text, and thus requires only USB HID drivers found on practically all desktop computers.<br />
<br />
== Introduction ==<br />
<br />
=== How does it work ===<br />
<br />
Yubikey's authentication protocol is based on [http://en.wikipedia.org/wiki/Symmetric_cryptography symmetric cryptography].<br />
More specifically, each Yubikey contains a 128-bit [http://en.wikipedia.org/wiki/Advanced_Encryption_Standard AES] key, unique to that key.<br />
It is used to encrypt a token made of different fields such as the ID of the key, a counter, a random number, etc.<br />
The OTP is made from concatenating the ID of the key with this encrypted token.<br />
<br />
This OTP is sent to the target system, to which we want to authenticate.<br />
This target system asks a validation server if the OTP is good.<br />
The validation server has a mapping of Yubikey IDs -> AES key.<br />
Using the key ID in the OTP, it can thus retrieve the AES key and decrypt the other part of the OTP.<br />
If it looks OK (plain-text ID and encrypted ID are the same, the counter is bigger than the last seen one to prevent [http://en.wikipedia.org/wiki/Replay_attack replay attacks]...), then authentication is successful.<br />
<br />
The validation server sends that authentication status back to the target system, which grants access or not based on that response.<br />
<br />
=== Security risks ===<br />
<br />
==== AES key compromission ====<br />
<br />
As you can imagine, the AES key should be kept very secret.<br />
It can not be retrieved from the Yubikey itself (or it should not, at least not with software).<br />
It is present in the validation server though, so the security of this server is very important.<br />
<br />
==== Validation requests/responses tampering ====<br />
<br />
Since the target system relies on the ruling of the validation server, a trivial attack would be to impersonate the validation server.<br />
The target system thus needs to authenticate the validation server.<br />
2 methods are available :<br />
* '''HMAC''': This is also symmetric crypto, the target server and validation server share a key that is used to sign requests and responses.<br />
* '''TLS''': Requests and responses travel via HTTP, so TLS (HTTPS) can be used to authenticate and encrypt the connection.<br />
<br />
=== YubiCloud and validation servers ===<br />
<br />
When you buy a Yubikey, it is preloaded with an AES key that is known only to Yubico.<br />
They will not even communicate it to you.<br />
Yubico provides a validation server with free unlimited access (YubiCloud).<br />
It also offers open-source implementations of the server.<br />
<br />
So you can either:<br />
* choose to use your Yubikey with its preloaded AES key and validate against Yubico's validation server ;<br />
* or load a new AES key in your Yubikey and run your own validation server.<br />
<br />
{{Note|To authenticate the Yubico validation server, you can:<br />
* '''with HMAC''': use https://upgrade.yubico.com/getapikey/ to get an HMAC key and ID<br />
* '''with HTTPS''': the validation server's certificate is signed by GoDaddy, that is cool because it is thus trusted by default in Arch installs (at least if you have package ca-certificates)}}<br />
<br />
== Two-factor authentication with SSH ==<br />
<br />
{{Note|See also: https://developers.yubico.com/yubico-pam/Yubikey_and_SSH_via_PAM.html}}<br />
<br />
This details how to use a Yubikey to have [http://en.wikipedia.org/wiki/Two-factor_authentication two-factor authentication] with SSH, that is, to use both a password and a Yubikey-generated OTP.<br />
<br />
=== Prerequisites ===<br />
<br />
The necessary packages are on the AUR.<br />
The one you need for TFA with SSH is the {{AUR|yubico-pam-git}}.<br />
It depends on:<br />
* {{Pkg|yubico-c}}<br />
* {{AUR|yubico-c-client-git}}<br />
* {{AUR|yubikey-personalization-git}}<br />
<br />
Install them.<br />
<br />
{{Note|If you are configuring a distant server to use Yubikey, you should open at least one additional, rescue SSH session, so that you are not locked out of your server if the configuration does not work and you exit your main session inadvertently}}<br />
<br />
=== PAM configuration ===<br />
<br />
You have to edit {{ic|/etc/pam.d/sshd}}, and modify the line that reads :<br />
auth required pam_unix.so<br />
into<br />
auth required pam_unix.so use_first_pass<br />
<br />
Then do one of the following. I personally would highly recommend the HTTPS method, but the choice is yours. --[[User:Gohu|Gohu]] 17:49, 24 April 2011 (EDT)<br />
<br />
==== If using HTTPS to authenticate the validation server ====<br />
Insert the following line '''before''' the previously modified {{ic|pam_unix.so}} line.<br />
auth required pam_yubico.so id=1 url=https://api.yubico.com/wsapi/2.0/verify?id=%d&otp=%s<br />
The id=1 is of no real use but it is required.<br />
{{Note|If you run your own validation server, modify the {{ic|url}} parameter to point to your server. If you are not running your own validation server, you may omit the {{ic|url}} parameter entirely as it is the default.}}<br />
{{Note|These instructions are outdated and are unlikely to work. It may be useful to go to https://developers.yubico.com/yubico-pam/Yubikey_and_SSH_via_PAM.html for up to date instructions while someone finds the time to update the Arch Wiki.}}<br />
<br />
==== If using HMAC to authenticate the validation server ====<br />
Insert the following line '''before''' the previously modified {{ic|pam_unix.so}} line.<br />
auth required pam_yubico.so id=1234 key=YnVubmllcyBhcmUgY29vbAo=<br />
where {{ic|id}} and {{ic|key}} are your own HMAC ID and key, requested from Yubico as explained above.<br />
{{Note|HMAC credentials should be unique to a single target server. That way, if an attacker finds them, he will not be able to craft responses to authenticate to other target servers you own}}<br />
{{Note|We did not specify the {{ic|url}} parameter: it defaults to Yubico's HTTP (non-TLS) server}}<br />
You should also disallow unprivileged users to read the file to prevent them from seeing the HMAC credentials:<br />
# chmod o-r /etc/pam.d/sshd<br />
<br />
{{Note|If you run your own validation server, add the {{ic|url}} parameter to point to your server. If you are not running your own validation server, you may omit the {{ic|url}} parameter entirely as it is the default.}}<br />
<br />
=== SSHD configuration ===<br />
<br />
You should check that {{ic|/etc/ssh/sshd_config}} contains these lines and that they are not commented, but I believe this is the default.<br />
ChallengeResponseAuthentication no<br />
UsePAM yes<br />
<br />
=== That is it! ===<br />
<br />
You should not need to restart anything if you just touched the PAM config file.<br />
<br />
To log in, at the {{ic|Password:}} prompt of SSH, you have to type your password '''without pressing enter''' and touch the Yubikey's button.<br />
The Yubikey should send a return at the end of the OTP so you do not need to touch the enter key at all.<br />
<br />
{{Note|If you remove use_first_pass from the pam_unix.so line, you can just use your YubiKey first, then it will prompt for your password after the YubiKey line.}}<br />
<br />
=== Explanation ===<br />
This works because the prompt is {{ic|pam_yubico.so}}'s one, since this module is before {{ic|pam_unix.so}}, which does basic password authentication.<br />
So, you are giving a string that is the concatenation of your password and the OTP to {{ic|pam_yubico.so}}.<br />
Since the OTPs have a fixed length (let us call this size N), it just has to get the last N characters to retrieve the OTP, and it assumes that the other characters at the start are the password.<br />
It tries to validate the OTP, and in case of success, sends the password to the next PAM module, {{ic|pam_unix.so}}, which was instructed not to prompt for the password, but to receive it from the previous module, with {{ic|use_first_pass}}.<br />
<br />
== Installing the OATH Applet for a Yubikey NEO ==<br />
These steps will allow you to install the OATH applet onto your Yubikey NEO. This allows the use of Yubico Authenticator in the Google Play Store.<br />
{{Note|1=These steps are only for NEOs with a firmware version <= 3.1.2. The current generation NEOs (with U2F) come with the OpenPGP applet already installed)}}<br />
<br />
=== Configure the NEO as a CCID Device ===<br />
# Get {{AUR| yubikey-personalization-gui-git}} from the AUR.<br />
# Add the udev rules and reboot so you can manage the YubiKey without needing to be root<br />
# Run {{ic | ykpersonalize -m82}}, enter {{ic | y}}, and hit enter.<br />
<br />
=== Install the Applet ===<br />
# Install {{AUR| gpshell}}, {{AUR| gppcscconnectionplugin}}, {{AUR| globalplatform}}, and {{Pkg | pcsclite}}.<br />
# Start {{ic | pcscd}} with {{ic | sudo systemctl start pcscd}}.<br />
# Download the most recent CAP file from the [http://opensource.yubico.com/ykneo-oath/releases.html ykneo-oath] site.<br />
# Download {{ic | gpinstall.txt}} from [https://github.com/Yubico/ykneo-oath/blob/master/gpinstall.txt GitHub].<br />
# Edit the line in gpinstall.txt beginning with {{ic | install -file}} to reflect the path where the CAP file is located.<br />
# Open a terminal and run {{ic| gpshell <location of gpinstall.txt>}}<br />
# Ideally, a bunch of text will scroll by and it ends saying something like<br />
{{ bc | Command --> 80E88013D7C000C400BE00C700CA00CA00B400BE00CE00D200D500D700B000DB00C700DF00BEFFFF00BE00E400AC00AE00AE00DB00E700A<br />
A00EA00ED00ED00ED00BE00EF00F100F400F100F700FA00FF00BE00F700AA01010103010700CA00C400B400AA00F700B400AA00B600C7010C<br />
010C00AA0140012001B0056810B0013005600000056810E0011006B4B44304B44404B44106B44B4405B443400343B002410636810E06B4B44<br />
407326810B004B43103441003334002B102B404B3B403BB4003B440076820A4100221024405B4341008B44600000231066820A100<br />
Wrapped command --> 84E88013DFC000C400BE00C700CA00CA00B400BE00CE00D200D500D700B000DB00C700DF00BEFFFF00BE00E400AC00AE00AE00DB00E700A<br />
A00EA00ED00ED00ED00BE00EF00F100F400F100F700FA00FF00BE00F700AA01010103010700CA00C400B400AA00F700B400AA00B600C7010C<br />
010C00AA0140012001B0056810B0013005600000056810E0011006B4B44304B44404B44106B44B4405B443400343B002410636810E06B4B44<br />
407326810B004B43103441003334002B102B404B3B403BB4003B440076820A4100221024405B4341008B44600000231066820A15D848CB77<br />
27D0EDA00<br />
Response <-- 009000<br />
Command --> 80E60C002107A000000527210108A00000052721010108A000000527210101010003C901000000<br />
Wrapped command --> 84E60C002907A000000527210108A00000052721010108A000000527210101010003C9010000B4648127914A4C7C00<br />
Response <-- 009000<br />
card_disconnect<br />
release_context}}<br />
# Unplug the NEO and try it with the Yubico Authenticator app<br />
<br />
===(Optional) Install the Yubico Authenticator Desktop client===<br />
<br />
You can get the desktop version of the Yubico Authenticator by installing {{AUR|yubico-yubioath-desktop-git}}.<br />
<br />
== Enabling U2F with Chromium/Chrome ==<br />
<br />
In order for the U2F functionality to work with Chromium you need to install the {{Pkg | libu2f-host}} library.<br />
This provides the udev rules required to enable access to the Yubikey as a user.<br />
Yubikey is by default only accessible by root, and without these rules Chromium will give an error.</div>Wooptoohttps://wiki.archlinux.org/index.php?title=OpenNTPD&diff=389027OpenNTPD2015-07-29T17:44:50Z<p>Wooptoo: /* See also */</p>
<hr />
<div>[[Category:Networking]]<br />
[[it:OpenNTPD]]<br />
{{Out of date|rc.d references, bad style/format.}}<br />
<br />
{{Related articles start}}<br />
{{Related|Time}}<br />
{{Related|Network Time Protocol daemon}}<br />
{{Related|systemd-timesyncd}}<br />
{{Related|Chrony}}<br />
{{Related articles end}}<br />
<br />
OpenNTPD (part of the OpenBSD project) is a daemon that can be used to synchronize the system clock to internet time servers using the Network Time Protocol, and can also act as a time server itself if needed.<br />
<br />
== Installation ==<br />
[[Install]] the {{Pkg|openntpd}} package.<br />
The default configuration is actually usable if all you want is to sync the time of the local computer. For more detailed settings, the {{ic|/etc/ntpd.conf}} file must be edited:<br />
<br />
To sync to a particular server, uncomment and edit the "server" directive. You can find the server's URL in your area at [http://www.pool.ntp.org/zone/@ www.pool.ntp.org/zone/@].<br />
<br />
server ntp.example.org<br />
<br />
The "servers" directive works the same as the "server" directive, however, if the DNS name resolves to multiple IP address, ALL of them will be synced to. The default, "pool.ntp.org" is working and should be acceptable in most cases.<br />
<br />
pool.ntp.org<br />
<br />
Any number of "server" or "servers" directives may be used.<br />
<br />
If you want the computer you run OpenNTPD on to also be a time server, simply uncomment and edit the "listen" directive.<br />
<br />
For example:<br />
<br />
listen on *<br />
<br />
will listen on all interfaces, and<br />
<br />
listen on 127.0.0.1<br />
<br />
will only listen on the loopback interface.<br />
<br />
Your time server will only begin to serve time after it has synchronized itself to a high resolution. This may take hours, or days, depending on the accuracy of your system.<br />
<br />
=== Enable OpenNTPD through systemd ===<br />
[[Start/enable]] the {{ic|openntpd}} service.<br />
<br />
== Making openntpd dependent upon network access ==<br />
If you have intermittent network access (you roam around on a laptop, you use dial-up, etc), it does not make sense to have {{Ic|openntpd}} running as a system daemon on start up. Here are a few ways you can control {{Ic|openntpd}} based on the presence of a network connection. These instructions should also work for {{Ic|ntpd}} found further below. <br />
<br />
=== Using netcfg ===<br />
If you are using netcfg, you can also start/stop openntpd as a POST_UP/PRE_DOWN command in your network profile:<br />
<br />
POST_UP="/etc/rc.d/openntpd start || true"<br />
PRE_DOWN="/etc/rc.d/openntpd stop || true"<br />
<br />
Of course, you will have to specify this manually for each network profile.<br />
<br />
=== Using NetworkManager dispatcher ===<br />
OpenNTPD can be brought up/down along with a network connection through the use of [[NetworkManager#Network Services with NetworkManager Dispatcher|NetworkManager's dispatcher scripts]]. You can [[install]] the needed script, {{ic|networkmanager-dispatcher-openntpd}}.<br />
<br />
=== Using wicd ===<br />
These instructions require wicd 1.7.0 or later, which is available in the standard Arch repository.<br />
You will also need write access to {{ic|/etc/wicd/scripts}}.<br />
<br />
{{Note|Remember to make these two scripts executable using {{Ic|chmod}} }}<br />
<br />
Make one shell script inside {{ic|/etc/wicd/scripts/postconnect/openntpd-start.sh}} with the following:<br />
<pre><br />
#!/bin/sh<br />
/etc/rc.d/openntpd start<br />
</pre><br />
<br />
Similarly, make another shell script inside {{ic|/etc/wicd/scripts/predisconnect/openntpd-stop.sh}} with the following:<br />
<pre><br />
#!/bin/sh<br />
/etc/rc.d/openntpd stop<br />
</pre><br />
<br />
=== Using dhclient hooks ===<br />
Another possibility is to use dhclient hooks to start and stop openntpd.<br />
When dhclient detects a change in state it will run the following scripts:<br />
*{{ic|/etc/dhclient-enter-hooks}}<br />
*{{ic|/etc/dhclient-exit-hooks}}<br />
<br />
The following example uses {{ic|/etc/dhclient-exit-hooks}} to start and stop openntpd depending on dhcp status:<br />
<pre><br />
[ "$interface" != "eth0" ] && exit 0<br />
<br />
if $if_up; then<br />
pgrep ntpd &> /dev/null || /etc/rc.d/openntpd start<br />
elif $if_down; then<br />
pgrep ntpd &> /dev/null && /etc/rc.d/openntpd stop<br />
fi<br />
</pre><br />
<br />
See dhclient-script(8)<br />
<br />
=== Using dhcpcd hooks ===<br />
{{ic|/usr/lib/dhcpcd/dhcpcd-hooks/*}}<br />
<br />
See dhcpcd-run-hooks(8)<br />
<br />
==Troubleshooting==<br />
===Error adjusting time===<br />
If you find your time set incorrectly and in log you see:<br />
<br />
openntpd adjtime failed: Invalid argument<br />
<br />
Try:<br />
<br />
ntpd -s -d<br />
<br />
This is also how you would manually sync your system.<br />
<br />
===Increasing time shift===<br />
Starting ''openntpd'' in the background could lead to synchronization errors between the actual time and the time stored on your computer. If you recognize an increasing time difference between your desktop clock and the actual time, try to start the ''openntpd'' daemon normal and not in the background.<br />
<br />
{{Out of date|rc.d references. Needs update to [[Systemd]].}}<br />
===Initialization Failure===<br />
<br />
Openntpd may fail to initialize properly if it is started before the network is fully configured. In some cases you may want to remove {{Ic|openntpd}} from the DAEMONS array in {{ic|/etc/rc.conf}} and add the following line to {{ic|/etc/rc.local}}:<br />
<br />
(sleep 300 && /etc/rc.d/openntpd start) &<br />
{{Note|This method is an alternative to the four methods listed [[#Making openntpd dependent upon network access|above]]. The other three methods are preferred and work better. Use this as a last resort.}}<br />
<br />
This will wait 5 minutes before starting openntpd, which should give the system sufficient time to set up the network properly. If your network settings change often, you may also consider restarting the daemon regularly with cron.<br />
<br />
==See also==<br />
* [[Network Time Protocol daemon]]<br />
* If you do not require strict timekeeping then [[Systemd-timesyncd]] is easier to setup.<br />
<br />
==External links==<br />
* http://www.openntpd.org</div>Wooptoohttps://wiki.archlinux.org/index.php?title=User:Wooptoo&diff=296851User:Wooptoo2014-02-11T17:51:42Z<p>Wooptoo: </p>
<hr />
<div>* [https://aur.archlinux.org/packages.php?SeB=m&K=wooptoo My Packages]<br />
* [http://en.wikipedia.org/wiki/User:Wooptoo My Wikipedia Profile]<br />
* [http://wooptoo.com My Blog]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Unofficial_user_repositories&diff=287424Unofficial user repositories2013-12-09T15:13:28Z<p>Wooptoo: /* arch-desktop */</p>
<hr />
<div>[[Category:Package management]]<br />
Since the AUR only allows users to upload PKGBUILD and other package build related files, but does not provide a means for distributing a binary package, a user may want to create a binary repository of their packages elsewhere. See [[Pacman Tips#Custom local repository]] for more information.<br />
<br />
If you have your own repository, please add it to this page, so that all the other users will know where to find your packages. Please keep the following rules when adding new repositories:<br />
<br />
* Keep the lists in alphabetical order.<br />
* Include some information about the maintainer - at least a (nick)name + contact (website, email, userpage on ArchWiki or the forums...).<br />
* Include some short description (e.g. the category of packages provided in the repository).<br />
* If there is a page (either on ArchWiki or external) containing more information about the repository, include a link to it.<br />
<br />
{{Expansion|Please fill in the missing information about maintainers.}} <br />
<br />
== Any ==<br />
<br />
"Any" repos are architecture-independent, i.e. they can be used on both i686 and x86_64 systems.<br />
<br />
=== Signed ===<br />
<br />
==== infinality-bundle-fonts ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' infinality-bundle-fonts repository.<br />
* '''Upstream page:''' [[Infinality-bundle+fonts]]<br />
<br />
{{bc|<nowiki><br />
[infinality-bundle-fonts]<br />
Server = http://ibn.net63.net/infinality-bundle-fonts<br />
</nowiki>}}<br />
<br />
==== xyne-any ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#xyne Xyne]<br />
* '''Description:''' A repository for Xyne's own projects containing packages for "any" architecture.<br />
* '''Upstream page:''' http://xyne.archlinux.ca/projects/<br />
<br />
{{Note|Use this repo only if there is no matching {{ic|[xyne-*]}} repo for your architecture.}}<br />
<br />
{{bc|<nowiki><br />
[xyne-any]<br />
SigLevel = Required<br />
Server = http://xyne.archlinux.ca/repos/xyne<br />
</nowiki>}}<br />
<br />
=== Unsigned ===<br />
<br />
==== arch-fonts ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Prebuilt packages for font packages found in AUR. This should be faster than building from source as many have download speed of 10KB/s. If you find missing font, email to <gmail.com: jesse.jaara>. Now with pkgfile support.<br />
<br />
{{bc|<nowiki><br />
[arch-fonts]<br />
Server = http://huulivoide.pp.fi/Arch/arch-fonts<br />
</nowiki>}}<br />
<br />
==== archlinuxgr-any ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' The Hellenic (Greek) archlinux unofficial repository with many interesting packages.<br />
<br />
{{bc|<nowiki><br />
[archlinuxgr-any]<br />
Server = http://archlinuxgr.tiven.org/archlinux/any<br />
</nowiki>}}<br />
<br />
== Both i686 and x86_64 ==<br />
<br />
Repositories with both i686 and x86_64 versions. The $arch variable will be set automatically by pacman.<br />
<br />
=== Signed ===<br />
<br />
==== apathism ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' AUR packages that would take long to build, such as {{AUR|firefox-kde-opensuse}} and {{AUR|mysql-workbench}}.<br />
<br />
{{bc|<nowiki><br />
[apathism]<br />
SigLevel = Required<br />
Server = http://apathism.net/archlinux/<br />
</nowiki>}}<br />
<br />
==== ayatana ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#bgyorgy Balló György]<br />
* '''Description:''' Unity and related packages.<br />
* '''Upstream page:''' http://pkgbuild.com/~bgyorgy/ayatana.html<br />
<br />
{{bc|<nowiki><br />
[ayatana]<br />
SigLevel = PackageRequired<br />
Server = http://pkgbuild.com/~bgyorgy/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
==== blackarch ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Tools for pentesting and security research.<br />
* '''Upstream page:''' http://blackarch.org/<br />
<br />
{{bc|<nowiki><br />
[blackarch]<br />
SigLevel = PackageRequired<br />
Server = http://www.blackarch.org/pub/blackarch/$arch<br />
</nowiki>}}<br />
<br />
==== carstene1ns ====<br />
<br />
* '''Maintainer:''' [[User:Carstene1ns|Carsten Teibes]]<br />
* '''Description:''' AUR packages maintained and/or used by me (games/wii/lib32/python)<br />
* '''Upstream page:''' http://arch.carsten-teibes.de (still under construction)<br />
<br />
{{bc|<nowiki><br />
[carstene1ns]<br />
Server = http://repo.carsten-teibes.de/$arch<br />
</nowiki>}}<br />
<br />
==== catalyst ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' ATI Catalyst proprietary drivers.<br />
<br />
{{bc|<nowiki><br />
[catalyst]<br />
Server = http://catalyst.wirephire.com/repo/catalyst/$arch<br />
</nowiki>}}<br />
<br />
==== city ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#bgyorgy Balló György]<br />
* '''Description:''' Experimental/unpopular packages.<br />
* '''Upstream page:''' http://pkgbuild.com/~bgyorgy/city.html<br />
<br />
{{bc|<nowiki><br />
[city]<br />
SigLevel = PackageRequired<br />
Server = http://pkgbuild.com/~bgyorgy/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
==== crypto ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Includes tomb, tomb-git and other related software.<br />
<br />
{{bc|<nowiki><br />
[crypto]<br />
SigLevel = Required<br />
Server = http://tomb.dyne.org/arch_repo/$arch<br />
</nowiki>}}<br />
<br />
==== demz-repo-core ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Packages for ZFS on Arch Linux.<br />
* '''Upstream page:''' http://demizerone.com/archzfs<br />
<br />
{{bc|<nowiki><br />
[demz-repo-core]<br />
SigLevel = Required<br />
Server = http://demizerone.com/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== gtmanfred ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#dwallace Daniel Wallace]<br />
* '''Description:''' This repo contains git/svn/hg versions of a lot of my packages.<br />
<br />
{{bc|<nowiki><br />
[gtmanfred]<br />
SigLevel=Required<br />
Server = http://code.gtmanfred.com/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== infinality-bundle ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' infinality-bundle main repository.<br />
* '''Upstream page:''' [[Infinality-bundle+fonts]]<br />
<br />
{{bc|<nowiki><br />
[infinality-bundle]<br />
Server = http://ibn.net63.net/infinality-bundle/$arch<br />
</nowiki>}}<br />
<br />
==== repo-ck ====<br />
<br />
* '''Maintainer:''' [[User:Graysky|graysky]]<br />
* '''Description:''' ARCH kernel and modules with Brain Fuck Scheduler and all the goodies in the ck1 patch set.<br />
* '''Upstream page:''' [[repo-ck]]<br />
<br />
{{bc|<nowiki><br />
[repo-ck]<br />
Server = http://repo-ck.com/$arch<br />
</nowiki>}}<br />
<br />
==== sergej-repo ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' psi-plus, owncloud-git, ziproxy, android, mysql and other stuff. Some packages also available for armv7h.<br />
<br />
{{bc|<nowiki><br />
[sergej-repo]<br />
Server = http://repo.p5n.pp.ru/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
=== Unsigned ===<br />
<br />
{{Note|Users will need to add the following to these entries: {{ic|1=SigLevel = PackageOptional}}}}<br />
<br />
==== alucryd ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#alucryd Maxime Gauduin]<br />
* '''Description:''' Repository containing various packages I'm maintaining (or not) in the AUR.<br />
<br />
{{bc|<nowiki><br />
[alucryd]<br />
SigLevel = Optional<br />
Server = http://pkgbuild.com/~alucryd/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== archaudio-production ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' verified PKGBUILDs AND tested packages<br />
<br />
{{bc|<nowiki><br />
[archaudio-production]<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== archaudio-preview ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' unverified PKGBUILDs AND/OR untested packages<br />
<br />
{{bc|<nowiki><br />
[archaudio-preview]<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== archaudio-nightly ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' verified devel PKGBUILDs<br />
<br />
{{bc|<nowiki><br />
[archaudio-nightly]<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== archaudio-experimental ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' unverified devel PKGBUILDs<br />
<br />
{{bc|<nowiki><br />
[archaudio-experimental]<br />
Server = http://repos.archaudio.org/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== archlinuxcn ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' The Chinese Arch Linux communities packages.<br />
<br />
{{bc|<nowiki><br />
[archlinuxcn]<br />
Server = http://repo.archlinuxcn.org/$arch<br />
</nowiki>}}<br />
<br />
==== archlinuxfr ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:'''<br />
* '''Upstream page:''' http://afur.archlinux.fr<br />
<br />
{{bc|<nowiki><br />
[archlinuxfr]<br />
SigLevel = Never<br />
Server = http://repo.archlinux.fr/$arch<br />
</nowiki>}}<br />
<br />
==== archlinuxgis ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Maintainers needed - low bandwidth<br />
<br />
{{bc|<nowiki><br />
[archlinuxgis]<br />
SigLevel = PackageOptional<br />
Server = http://archlinuxgis.no-ip.org/$arch<br />
</nowiki>}}<br />
<br />
==== archlinuxgr ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:'''<br />
<br />
{{bc|<nowiki><br />
[archlinuxgr]<br />
Server = http://archlinuxgr.tiven.org/archlinux/$arch<br />
</nowiki>}}<br />
<br />
==== archlinuxgr-kde4 ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' KDE4 packages (plasmoids, themes etc) provided by the Hellenic (Greek) archlinux community<br />
<br />
{{bc|<nowiki><br />
[archlinuxgr-kde4]<br />
Server = http://archlinuxgr.tiven.org/archlinux-kde4/$arch<br />
</nowiki>}}<br />
<br />
==== archstuff ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' AUR's most voted and many bin32-* and lib32-* packages.<br />
<br />
{{bc|<nowiki><br />
[archstuff]<br />
Server = http://archstuff.vs169092.vserver.de/$arch<br />
</nowiki>}}<br />
<br />
==== arsch ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' From users of orgizm.net<br />
<br />
{{bc|<nowiki><br />
[arsch]<br />
Server = http://arsch.orgizm.net/$arch<br />
</nowiki>}}<br />
<br />
==== aurbin ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Automated build of AUR packages<br />
<br />
{{bc|<nowiki><br />
[aurbin]<br />
SigLevel = Never<br />
Server = http://aurbin.net/$arch<br />
</nowiki>}}<br />
<br />
==== cinnamon ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Stable and actively developed Cinnamon packages (Applets, Themes, Extensions), plus others (Hotot, qBitTorrent, GTK Themes, Perl Mods and more).<br />
<br />
{{bc|<nowiki><br />
[cinnamon]<br />
Server = http://archlinux.zoelife4u.org/cinnamon/$arch<br />
</nowiki>}}<br />
<br />
==== ede ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Equinox Desktop Environment repository<br />
<br />
{{bc|<nowiki><br />
[ede]<br />
Server = http://www.equinox-project.org/repos/arch/$arch<br />
</nowiki>}}<br />
<br />
==== haskell-core ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Arch-Haskell repository<br />
* '''Upstream page:''' [[Haskell Package Guidelines]]<br />
<br />
{{bc|<nowiki><br />
[haskell-core]<br />
Server = http://xsounds.org/~haskell/core/$arch<br />
</nowiki>}}<br />
<br />
==== heftig ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#heftig Jan Steffens]<br />
* '''Description:''' Includes linux-zen and aurora (firefox development build - works alongside firefox in extra).<br />
* '''Upstream page:''' https://bbs.archlinux.org/viewtopic.php?id=117157<br />
<br />
{{bc|<nowiki><br />
[heftig]<br />
SigLevel = PackageOptional<br />
Server = http://pkgbuild.com/~heftig/repo/$arch<br />
</nowiki>}}<br />
<br />
==== herecura-stable ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' additional apps not found in community<br />
<br />
{{bc|<nowiki><br />
[herecura-stable]<br />
Server = http://repo.herecura.be/herecura-stable/$arch<br />
</nowiki>}}<br />
<br />
==== herecura-testing ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' additional apps for testing build against stable arch<br />
<br />
{{bc|<nowiki><br />
[herecura-testing]<br />
Server = http://repo.herecura.be/herecura-testing/$arch<br />
</nowiki>}}<br />
<br />
==== jelle ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:'''<br />
<br />
{{bc|<nowiki><br />
[jelle]<br />
SigLevel = Optional<br />
Server = http://pkgbuild.com/~jelle/repo/$arch<br />
</nowiki>}}<br />
<br />
==== mate ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Contains official mate desktop packages (gnome2 fork).<br />
<br />
{{bc|<nowiki><br />
[mate]<br />
Server = http://repo.mate-desktop.org/archlinux/$arch<br />
</nowiki>}}<br />
<br />
==== mesa-git ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' mesa git builds for testing and multilib-testing<br />
<br />
{{bc|<nowiki><br />
[mesa-git]<br />
Server = http://pkgbuild.com/~lcarlier/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== oracle ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Oracle database client<br />
<br />
{{Warning|By adding this you are agreeing to the Oracle license at http://www.oracle.com/technetwork/licenses/instant-client-lic-152016.html}}<br />
<br />
{{bc|<nowiki><br />
[oracle]<br />
SigLevel = Optional TrustAll<br />
Server = http://linux.shikadi.net/arch/$repo/$arch/<br />
</nowiki>}}<br />
<br />
==== pantheon ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#alucryd Maxime Gauduin]<br />
* '''Description:''' Repository containing Pantheon related packages<br />
<br />
{{bc|<nowiki><br />
[pantheon]<br />
SigLevel = Optional<br />
Server = http://pkgbuild.com/~alucryd/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== paulburton-fitbitd ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Contains fitbitd for synchronizing FitBit trackers<br />
<br />
{{bc|<nowiki><br />
[paulburton-fitbitd]<br />
SigLevel = Optional<br />
Server = http://www.paulburton.eu/arch/fitbitd/$arch<br />
</nowiki>}}<br />
<br />
==== pfkernel ====<br />
<br />
{{Out of date|The repo url http://dl.dropbox.com/u/11734958/ is inaccessible (2013-12-01).}}<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Generic and optimized binaries of the ARCH kernel patched with BFS, TuxOnIce, BFQ, Aufs3, linux-pf, kernel26-pf, gdm-old, nvidia-pf, nvidia-96xx, xchat-greek, arora-git<br />
<br />
{{bc|<nowiki><br />
[pfkernel]<br />
Server = http://dl.dropbox.com/u/11734958/$arch<br />
</nowiki>}}<br />
<br />
==== suckless ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' suckless.org packages<br />
<br />
{{bc|<nowiki><br />
[suckless]<br />
Server = http://dl.suckless.org/arch/$arch<br />
</nowiki>}}<br />
<br />
==== unity ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' unity packages for arch<br />
<br />
{{bc|<nowiki><br />
[unity]<br />
Server = http://unity.xe-xe.org/$arch<br />
</nowiki>}}<br />
<br />
==== unity-extra ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' unity extra packages for arch<br />
<br />
{{bc|<nowiki><br />
[unity-extra]<br />
Server = http://unity.xe-xe.org/extra/$arch<br />
</nowiki>}}<br />
<br />
==== unity ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' unity packages for arch<br />
<br />
{{bc|<nowiki><br />
[unity]<br />
Server = http://unity.humbug.in/$arch<br />
</nowiki>}}<br />
<br />
==== unity-extra ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' unity extra packages for arch<br />
<br />
{{bc|<nowiki><br />
[unity-extra]<br />
Server = http://unity.humbug.in/extra/$arch<br />
</nowiki>}}<br />
<br />
==== home_tarakbumba_archlinux_Arch_Extra_standard ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' few prebuild aur packages (zemberek, firefox-kde-opensuse, etc.)<br />
<br />
{{bc|<nowiki><br />
[home_tarakbumba_archlinux_Arch_Extra_standard]<br />
SigLevel = Optional TrustAll<br />
Server = http://download.opensuse.org/repositories/home:/tarakbumba:/archlinux/Arch_Extra_standard/$arch<br />
</nowiki>}}<br />
<br />
== i686 only ==<br />
<br />
=== Signed ===<br />
<br />
==== eee-ck ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Kernel and modules optimized for Asus Eee PC 701, with -ck patchset.<br />
<br />
{{bc|<nowiki><br />
[eee-ck]<br />
SigLevel = PackageRequired<br />
Server = http://zembla.shatteredsymmetry.com/repo<br />
</nowiki>}}<br />
<br />
==== xyne-i686 ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#xyne Xyne]<br />
* '''Description:''' A repository for Xyne's own projects containing packages for the "i686" architecture.<br />
* '''Upstream page:''' http://xyne.archlinux.ca/projects/<br />
<br />
{{Note|This includes all packages in [[#xyne-any|<nowiki>[xyne-any]</nowiki>]].}}<br />
<br />
{{bc|<nowiki><br />
[xyne-i686]<br />
SigLevel = Required<br />
Server = http://xyne.archlinux.ca/repos/xyne<br />
</nowiki>}}<br />
<br />
=== Unsigned ===<br />
<br />
==== andrwe ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:'''<br />
* '''Upstream page:''' http://andrwe.org/linux/repository<br />
<br />
{{bc|<nowiki><br />
[andrwe]<br />
Server = http://repo.andrwe.org/i686<br />
</nowiki>}}<br />
<br />
==== batchbin ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' My personal projects and utilities which I feel can benifit others.<br />
<br />
{{bc|<nowiki><br />
[batchbin]<br />
Server = http://batchbin.ueuo.com/archlinux<br />
</nowiki>}}<br />
<br />
==== esclinux ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Mostly games, interactive fiction and abc notation stuffs already on AUR.<br />
<br />
{{bc|<nowiki><br />
[esclinux]<br />
Server = http://download.tuxfamily.org/esclinuxcd/ressources/repo/i686/<br />
</nowiki>}}<br />
<br />
==== kpiche ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Stable OpenSync packages.<br />
<br />
{{bc|<nowiki><br />
[kpiche]<br />
Server = http://kpiche.archlinux.ca/repo<br />
</nowiki>}}<br />
<br />
==== kernel26-pae ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' PAE-enabled 32-bit kernel 2.6.39<br />
<br />
{{bc|<nowiki><br />
[kernel26-pae]<br />
Server = http://kernel26-pae.archlinux.ca/<br />
</nowiki>}}<br />
<br />
==== linux-pae ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' PAE-enabled 32-bit kernel 3.0<br />
<br />
{{bc|<nowiki><br />
[linux-pae]<br />
Server = http://pae.archlinux.ca/<br />
</nowiki>}}<br />
<br />
==== mingw32 ====<br />
<br />
* '''Maintainer:''' Alexander 'hatred' Drozdov <adrozdoff [at] gmail (dot) com> (Russian-speaked guys can write on Russian :-)<br />
* '''Description:''' Libs & tools for crosscompiling for Win32, mainly taken from AUR.<br />
<br />
{{bc|<nowiki><br />
[mingw32]<br />
Server = http://hatred.homelinux.net/archlinux/mingw32/os/i686<br />
</nowiki>}}<br />
<br />
==== rfad ====<br />
<br />
* '''Maintainer:''' requiem [at] archlinux.us <br />
* '''Description:''' Repository made by haxit<br />
<br />
{{bc|<nowiki><br />
[rfad]<br />
Server = http://web.ncf.ca/ey723/archlinux/repo/<br />
</nowiki>}}<br />
<br />
==== studioidefix ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Precompiled boxee packages.<br />
<br />
{{bc|<nowiki><br />
[studioidefix]<br />
Server = http://studioidefix.googlecode.com/hg/repo/i686<br />
</nowiki>}}<br />
<br />
== x86_64 only ==<br />
<br />
=== Signed ===<br />
<br />
==== brtln ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#bpiotrowski Bartłomiej Piotrowski]<br />
* '''Description:''' Alpha releases of MariaDB, Wine with win32 support only and some VCS packages.<br />
<br />
{{bc|<nowiki><br />
[brtln]<br />
SigLevel = Optional<br />
Server = http://pkgbuild.com/~barthalion/arch/<br />
</nowiki>}}<br />
<br />
==== heimdal ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Packages are compiled against Heimdal instead of MIT KRB5. Meant to be dropped before {{ic|[core]}} in {{ic|pacman.conf}}. All packages are signed. Be careful, don't use this unless you know what you're doing as many of these packages override {{ic|[core]}} and {{ic|[extra]}}.<br />
* '''Upstream page:''' https://github.com/Kiwilight/Heimdal-Pkgbuilds<br />
<br />
{{bc|<nowiki><br />
[heimdal]<br />
SigLevel = Required<br />
Server = http://www.kiwilight.com/heimdal/$arch/<br />
</nowiki>}}<br />
<br />
==== infinality-bundle-multilib ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' infinality-bundle multilib repository.<br />
* '''Upstream page:''' [[Infinality-bundle+fonts]]<br />
<br />
{{bc|<nowiki><br />
[infinality-bundle-multilib]<br />
Server = http://ibn.net63.net/infinality-bundle-multilib/$arch<br />
</nowiki>}}<br />
<br />
==== subtitlecomposer ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Subtitle Composer stable and nightly builds.<br />
<br />
{{bc|<nowiki><br />
[subtitlecomposer]<br />
SigLevel = PackageRequired<br />
Server = http://smoothware.net/$repo/$arch<br />
</nowiki>}}<br />
<br />
==== xyne-x86_64 ====<br />
<br />
* '''Maintainer:''' [https://www.archlinux.org/trustedusers/#xyne Xyne]<br />
* '''Description:''' A repository for Xyne's own projects containing packages for the "x86_64" architecture.<br />
* '''Upstream page:''' http://xyne.archlinux.ca/projects/<br />
<br />
{{Note|This includes all packages in [[#xyne-any|<nowiki>[xyne-any]</nowiki>]].}}<br />
<br />
{{bc|<nowiki><br />
[xyne-x86_64]<br />
SigLevel = Required<br />
Server = http://xyne.archlinux.ca/repos/xyne<br />
</nowiki>}}<br />
<br />
=== Unsigned ===<br />
<br />
==== andrwe ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:'''<br />
* '''Upstream page:''' http://andrwe.dyndns.org/doku.php/blog/repository {{Linkrot|2013|11|30}}<br />
<br />
{{bc|<nowiki><br />
[andrwe]<br />
Server = http://repo.andrwe.org/x86_64<br />
</nowiki>}}<br />
<br />
==== archstudio ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Audio and Music Packages optimized for Intel Core i3, i5 and i7.<br />
* '''Upstream page:''' http://www.xsounds.org/~archstudio<br />
<br />
{{bc|<nowiki><br />
[archstudio]<br />
Server = http://www.xsounds.org/~archstudio/x86_64<br />
</nowiki>}}<br />
<br />
==== hawaii ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' hawaii Qt5/Wayland-based desktop environment<br />
* '''Upstream page:''' http://www.maui-project.org/<br />
<br />
{{bc|<nowiki><br />
[hawaii]<br />
SigLevel = Optional TrustAll<br />
Server = http://archive.maui-project.org/archlinux/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
==== pnsft-pur ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Japanese input method packages Mozc (vanilla) and libkkc<br />
<br />
{{bc|<nowiki><br />
[pnsft-pur]<br />
SigLevel = Optional TrustAll<br />
Server = http://downloads.sourceforge.net/project/pnsft-aur/pur/x86_64<br />
</nowiki>}}<br />
<br />
==== mingw-w64 ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Almost all mingw-w64 packages in the AUR updated every 8 hours.<br />
* '''Upstream page:''' http://arch.linuxx.org<br />
<br />
{{bc|<nowiki><br />
[mingw-w64]<br />
SigLevel = Optional TrustAll<br />
Server = http://downloads.sourceforge.net/project/mingw-w64-archlinux/$arch<br />
Server = http://arch.linuxx.org/archlinux/$repo/os/$arch<br />
</nowiki>}}<br />
<br />
==== seiichiro ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' VDR and some plugins, mms, foo2zjs-drivers<br />
<br />
{{bc|<nowiki><br />
[seiichiro]<br />
Server = http://repo.seiichiro0185.org/x86_64<br />
</nowiki>}}<br />
<br />
==== studioidefix ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Precompiled boxee packages.<br />
<br />
{{bc|<nowiki><br />
[studioidefix]<br />
Server = http://studioidefix.googlecode.com/hg/repo/x86_64<br />
</nowiki>}}<br />
<br />
==== zen ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Various and zengeist' AUR packages.<br />
<br />
{{bc|<nowiki><br />
[zen]<br />
Server = http://zloduch.cz/archlinux/x86_64<br />
</nowiki>}}<br />
<br />
== armv6h only ==<br />
<br />
=== Unsigned ===<br />
<br />
==== arch-fook-armv6h ====<br />
<br />
* '''Maintainer:'''<br />
* '''Description:''' Enligthenment and home automation stuff for the Raspberry PI<br />
<br />
{{bc|<nowiki><br />
[arch-fook-armv6h]<br />
Server = http://kivela.net/jaska/arch-fook-armv6h<br />
</nowiki>}}</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=277307Intel graphics2013-10-02T06:44:42Z<p>Wooptoo: /* Troubleshooting */</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X Server]]<br />
[[cs:Intel]]<br />
[[es:Intel]]<br />
[[fr:Intel]]<br />
[[hu:Intel]]<br />
[[it:Intel]]<br />
[[ja:Intel Graphics]]<br />
[[pl:Intel]]<br />
[[ru:Intel]]<br />
[[zh-CN:Intel Graphics]]<br />
[[zh-TW:Intel]]<br />
{{Article summary start}}<br />
{{Article summary text|Information on Intel graphics cards/chipsets and the ''intel'' video driver.}}<br />
{{Article summary heading|Related}}<br />
{{Article summary wiki|Intel GMA3600}}<br />
{{Article summary wiki|Poulsbo}}<br />
{{Article summary wiki|Xorg}}<br />
{{Article summary end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are now essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:Comparison of Intel graphics processing units|this comparison on Wikipedia]].<br />
<br />
{{Note|PowerVR-based graphics ([[Poulsbo|GMA 500]] and [[Intel GMA3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
<br />
Prerequisite: [[Xorg]].<br />
<br />
[[pacman|Install]] the {{Pkg|xf86-video-intel}} package which is available in the [[Official Repositories|official repositories]]. It provides the DDX driver for 2D acceleration and an [[XvMC]] driver for video decoding on older GPUs. It pulls in {{Pkg|intel-dri}} as a dependency, providing the DRI driver for 3D acceleration.<br />
<br />
Hardware accelerated video decoding/encoding on newer GPUs is possible through the [[VA-API]] driver provided by {{Pkg|libva-intel-driver}} package also, available in the official repositories.<br />
<br />
{{Note|User ''may'' need to install {{Pkg|lib32-intel-dri}} in 64-bit systems to use 3D acceleration in 32-bit programs.}}<br />
<br />
== Configuration ==<br />
<br />
There is no need for any kind of configuration to get the X.Org running (an {{ic|xorg.conf}} is unneeded, but needs to be configured correctly if present).<br />
<br />
For the list of options, type {{ic|man intel}}.<br />
<br />
== KMS (Kernel Mode Setting) ==<br />
<br />
{{Tip|If you have problems with the resolution, check [[Kernel_Mode_Setting#Forcing_modes_and_EDID|this page]].}}<br />
<br />
[[KMS]] is required in order to run X and a desktop environment such as [[GNOME]], [[KDE]], [[Xfce]], [[LXDE]], etc. KMS is supported by Intel chipsets that use the i915 DRM driver and is enabled by default as of kernel v2.6.32. Versions 2.10 and newer of the {{Pkg|xf86-video-intel}} driver no longer support UMS (except for the very old 810 chipset family), making the use of KMS mandatory<sup>[https://www.archlinux.org/news/484/]</sup>. KMS is typically initialized after the kernel is bootstrapped. It is possible, however, to enable KMS during bootstrap itself, allowing the entire boot process to run at the native resolution.<br />
<br />
{{Note|Users '''must''' remove any deprecated references to {{ic|vga}} or {{ic|nomodeset}} from boot configuration.}}<br />
<br />
To proceed, add the {{ic|i915}} module to the {{ic|MODULES}} line in {{ic|/etc/mkinitcpio.conf}}:<br />
<br />
MODULES="'''i915'''"<br />
<br />
If you are using a custom EDID file, you should embed it into initramfs as well:<br />
<br />
{{hc|/etc/mkinitcpio.conf|<br />
2=FILES="/lib/firmware/edid/your_edid.bin"}}<br />
<br />
Now, regenerate the initramfs:<br />
<br />
# mkinitcpio -p linux<br />
<br />
and reboot the system. Everything should work now.<br />
<br />
== Module-based Powersaving Options ==<br />
<br />
The '''i915''' kernel module allows for configuration via {{ic|/etc/modprobe.d/i915.conf}} wherein users can define powersavings options. A listing of options is available via the following command:<br />
<br />
$ modinfo i915 | grep power<br />
<br />
An example {{ic|/etc/modprobe.d/i915.conf}}:<br />
options i915 i915_enable_rc6=7 i915_enable_fbc=1 lvds_downclock=1<br />
<br />
== Tips and tricks ==<br />
<br />
=== Choose acceleration method ===<br />
*UXA - (Unified Acceleration Architecture) is the mature backend that was introduced to support the GEM driver model.<br />
*SNA - (Sandybridge's New Acceleration) is the faster successor for hardware supporting it.<br />
<br />
The default method is SNA(as of 2013-08-05[https://projects.archlinux.org/svntogit/packages.git/commit/trunk?h=packages/xf86-video-intel&id=d03f5fb77df413017821f492aa81e5d68def7e48]), which is less stable but faster than UXA. Check benchmarks done by Phoronix [http://www.phoronix.com/scan.php?page=news_item&px=MTEzOTE]. These can be found [http://www.phoronix.com/scan.php?page=article&item=intel_glamor_first&num=1 here for Sandy Bridge] and [http://www.phoronix.com/scan.php?page=article&item=intel_ivy_glamor&num=1 here for Ivy Bridge]. UXA is still a solid option, if experiencing trouble with SNA.<br />
<br />
To use the old UXA method, create {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} with the following content:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "AccelMethod" "uxa"<br />
EndSection}}<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
<br />
$ xrandr --output LVDS1 --set PANEL_FITTING param<br />
<br />
where {{ic|param}} can be:<br />
<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
<br />
If it does not work, try:<br />
<br />
$ xrandr --output LVDS1 --set "scaling mode" param<br />
<br />
where {{ic|param}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} in the kernel command line parameter in the bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, try disabling TV1 or VGA1 instead of SVIDEO-1.<br />
<br />
=== H.264 decoding on GMA 4500 ===<br />
<br />
The {{Pkg|libva-intel-driver}} package provides MPEG-2 decoding only for GMA 4500 series GPUs. The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-driver-intel-g45-h264}} package, available in the [[Arch User Repository]]. Note however that this support is experimental and not currently in active development. Using the VA-API with this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load (compared to the XV overlay) but resulted in very choppy playback, while 720p worked reasonably well [https://bbs.archlinux.org/viewtopic.php?id=150550]. This is echoed by other experiences [http://www.emmolution.org/?p=192&cpage=1#comment-12292].<br />
<br />
=== Setting gamma and brightness ===<br />
<br />
Intel offers no way to adjust these at the driver level. Luckily these can be set with {{ic|xgamma}} and {{ic|xrandr}}.<br />
<br />
Gamma can be set with:<br />
<br />
$ xgamma -gamma 1.0<br />
<br />
or:<br />
<br />
$ xrandr --output VGA1 --gamma 1.0:1.0:1.0<br />
<br />
Brightness can be set with:<br />
<br />
$ xrandr --output VGA1 --brightness 1.0<br />
<br />
== Troubleshooting ==<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Intel#KMS (Kernel Mode Setting)|the above]] KMS section.<br />
<br />
Alternatively, appending the following [[Kernel parameters|kernel parameter]] seems to work as well:<br />
<br />
video=SVIDEO-1:d<br />
<br />
If you need to output to VGA then try this:<br />
<br />
video=VGA-1:1280x800<br />
<br />
=== Tear-free video ===<br />
<br />
If using the SNA acceleration method, ablate video tearing by adding the following to the {{ic|Device}} section of {{ic|/etc/X11/xorg.conf.d/20-intel.conf}}:<br />
<br />
Option "TearFree" "true"<br />
<br />
{{Note|<br />
* This option may not work when {{ic|SwapbuffersWait}} is {{ic|false}}.<br />
* This option is problematic for applications that are very picky about vsync timing, like [[Wikipedia:Super Meat Boy|Super Meat Boy]].<br />
}}<br />
<br />
=== X freeze/crash with intel driver ===<br />
<br />
Some issues with X crashing, GPU hanging, or problems with X freezing, can be fixed by disabling the GPU usage with the {{ic|NoAccel}} option:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "NoAccel" "True"<br />
EndSection}}<br />
<br />
Alternatively, try to disable the 3D acceleration only with the {{ic|DRI}} option:<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "DRI" "False"<br />
EndSection}}<br />
<br />
If you experience crashes and have<br />
<br />
Option "TearFree" "true"<br />
Option "AccelMethod" "sna"<br />
<br />
in your config file, in most cases these can be fixed by adding<br />
<br />
i915.semaphores=1<br />
<br />
to your boot parameters.<br />
<br />
=== Adding undetected resolutions ===<br />
<br />
This issue is covered on the [[Xrandr#Adding_undetected_resolutions|Xrandr page]].<br />
<br />
=== Slowness after an upgrade to libGL 9 and Intel-DRI 9 ===<br />
<br />
[https://wiki.archlinux.org/index.php/Downgrading_Packages#ARM Downgrade] to Intel-DRI 8 and libGL 8.<br />
<br />
=== Black textures in video games ===<br />
<br />
Users experiencing black textures in video games may find a solution by enabling S3TC texture compression support. <br />
It can be enabled through {{Pkg|driconf}} or by installing {{Pkg|libtxc_dxtn}}.<br />
<br />
This "issue" will be fixed very soon in the [http://www.phoronix.com/scan.php?page=news_item&px=MTIwOTg newer drivers].<br />
<br />
Read more about S3TC at: <br />
* http://dri.freedesktop.org/wiki/S3TC<br />
* http://en.wikipedia.org/wiki/S3_Texture_Compression<br />
<br />
One of the games that is affected by this issue is [http://www.phoronix.com/scan.php?page=article&item=unigine_oilrush_gold&num=2 Oil Rush] and World of Warcraft using Wine.<br />
<br />
=== Weathered colors (colorspace problem) ===<br />
<br />
{{Note|This problem is related to the changes in the kernel 3.9. This problem still remains in kernel 3.10}}<br />
Kernel 3.9 contains the Intel driver changes allowing easy RGB Limited range settings which can cause weathered colors in some cases. It is related to the new "Automatic" mode for the "Broadcast RGB" property.<br />
One can force mode e.g. {{ic|xrandr --output <HDMI> --set "Broadcast RGB" "Full"}} (replace {{ic|<HDMI>}} with the appropriate output device, verify by running {{ic|xrandr}}). You can add it into your {{ic |.xprofile}}, make it executable to run the command before it will start the graphical mode.<br />
{{Note|Some TVs can only display colors from 16-255 so setting to Full will cause color clipping in the 0-15 range so it's best to leave it at Automatic which will automatically detect whether it needs to compress the colorspace for your TV.}}<br />
<br />
Also there are other related problems which can be fixed editing GPU registers. More information can be found [http://lists.freedesktop.org/archives/intel-gfx/2012-April/016217.html] and [http://github.com/OpenELEC/OpenELEC.tv/commit/09109e9259eb051f34f771929b6a02635806404c].<br />
<br />
=== Backlight not fully adjusting, or adjusting at all, after resume. ===<br />
<br />
If you are using Intel graphics and have no control over your manufacturer suplied hotkeys for changing screen brightness, try booting the kernel parameter:<br />
<br />
acpi_backlight=vendor<br />
<br />
If that doesnt solve the problem, many folks have gotten mileage from either:<br />
<br />
acpi_osi=Linux<br />
<br />
or<br />
<br />
acpi_osi="!Windows 2012"<br />
<br />
in addition to the earlier mentioned parameter.<br />
<br />
If neither of those solve your problem, you should edit/create {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} with the following content:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "card0"<br />
Driver "intel"<br />
Option "Backlight" "intel_backlight"<br />
BusID "PCI:0:2:0"<br />
<br />
EndSection}}<br />
<br />
If you are using the SNA acceleration as mentioned above, create the file as follows:<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "card0"<br />
Driver "intel"<br />
Option "AccelMethod" "sna"<br />
Option "Backlight" "intel_backlight"<br />
BusID "PCI:0:2:0"<br />
<br />
EndSection}}<br />
<br />
=== Disabling frame buffer compression ===<br />
<br />
On some cards such as Intel Corporation Mobile 4 Series Chipsets, enabled and forced frame buffer compression results in endless error messages:<br />
<br />
$ dmesg |tail <br />
[ 2360.475430] [drm] not enough stolen space for compressed buffer (need 4325376 bytes), disabling<br />
[ 2360.475437] [drm] hint: you may be able to increase stolen memory size in the BIOS to avoid this<br />
<br />
The solution is to disable frame buffer compression which will slightly increase power consumption. In order to disable it add {{ic|i915.i915_enable_fbc&#61;0}} to the kernel line parameters. More information on the results of disabled compression can be found [http://zinc.canonical.com/~cking/power-benchmarking/background-colour-and-framebuffer-compression/results.txt here].<br />
<br />
=== Corruption in Chrome/Chromium ===<br />
<br />
If you experience corruption in Chromium set the AccelMethod to "uxa" [https://wiki.archlinux.org/index.php/Intel_Graphics#Choose_acceleration_method]<br />
<br />
== See also ==<br />
<br />
* https://01.org/linuxgraphics/documentation (includes a list of supported hardware)<br />
* [[KMS]] - Arch wiki article on kernel mode setting<br />
* [[Xrandr]] - Problems setting the resolution<br />
* Arch Linux forums: [https://bbs.archlinux.org/viewtopic.php?pid=522665#p522665 Intel 945GM, Xorg, Kernel - performance]</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Talk:System_backup&diff=249673Talk:System backup2013-03-06T19:47:20Z<p>Wooptoo: /* What happened to this page? */</p>
<hr />
<div>===<s> Restore title</s> ===<br />
I cannot move it back to the same title without admin intervention. They have to delete the redirect first. Sorry for changing the name in the first place; I didn't realize subsections worked only for user pages. [[User:Pwd|pwd]] 13:27, 23 December 2009 (EST)<br />
:Oops! Sorry; didn't realize that was the cause of the hold-up. I've removed the redirect. -- [[User:Pointone|pointone]] 13:34, 23 December 2009 (EST)<br />
<br />
::Moved the page even though I don't like the title. I really don't think the naming scheme suits it; should be ''Full system backup with rsync'', in my opinion. <small>[[User:Pwd|pwd]]</small> 14:10, 23 December 2009 (EST)<br />
<br />
== Comments ==<br />
<br />
Thanks! Neat method for a sync-type backup! The only question I have is what happens if you {{Ic|dd}} the boot sector (first 512 bytes) instead of running GRUB? --[[User:VitaminJ|VitaminJ]] 22:18, 11 November 2009 (EST)<br />
<br />
---- <br />
<br />
I don't know if it works with <code>dd</code>, since the partitioning scheme can be different on the two harddrives.<br />
<br />
* I vote for merging this with [[rsync]].<br />
* I second the vote.<br />
<br />
[[User:Wooptoo|Wooptoo]] 07:14, 2 December 2009 (EST)<br />
--[[User:Keiichi|Keiichi]] 20:59, 2 December 2009 (EST)<br />
----<br />
Yep, I think you are right, I think that GRUB hardcodes the path to menu.lst in the GRUB boot program, so if you change around disks it won't work.<br />
<br />
As an alternative, an article on using tar instead might be useful because rsync may improperly preserves permissions across filesystems. For example if you backup from ext3 to XFS, and try to restore back to ext3.<br />
<br />
:The only issue would be doing it with FAT or NTFS were permissions just aren't possible. Coincidentially, I've done this exact setup using XFS and ext4 wihout anything breaking down. I only had problems between reiserfs and *, but that was due to SELinux context. [[User:Dres|Dres]] 21:22, 18 January 2010 (EST)<br />
<br />
----<br />
I think its a good idea to mention dirvish here. --[[User:Moere|Moere]] 03:37, 1 March 2010 (EST)<br />
<br />
----<br />
on the same topic, you can also look at a free script that i wrote to backup the whole disk with rsync here: http://blog.pointsoftware.ch/index.php/howto-local-and-remote-snapshot-backup-using-rsync-with-hard-links/<br />
<br />
It uses file deduplication thanks to hard-links, uses also MD5 integrity signature, 'chattr' protection, filter rules, disk quota, retention policy with exponential distribution (backups rotation while saving more recent backups than older).<br />
It was already used in Disaster Recovery Plans for banking companies, in order to replicate datacenters, using only little network bandwidth and transport encryption tunnel.<br />
<br />
Can be used locally on each servers or via network on a central remote backup server.<br />
windows server could also be backuped by using a linux box that mount smb shares from them.<br />
<br />
i hope it will be useful to you guys <br />
--[[User:Scheuref|Scheuref]] ([[User talk:Scheuref|talk]]) 14:03, 19 September 2012 (UTC)<br />
<br />
== <s> Errors </s> ==<br />
<br />
I'm getting the following error with this script, unless I use --delete-excluded, although that was declared unnecessary:<br />
cannot delete non-empty directory: lib<br />
could not make way for new symlink: lib<br />
cannot delete non-empty directory: lib64<br />
could not make way for new symlink: lib64<br />
--[[User:Malstrond|Malstrond]] ([[User talk:Malstrond|talk]]) 00:31, 8 September 2012 (UTC)<br />
<br />
:Rsync doesn't delete... You must have modified the script? --[[User:DSpider|DSpider]] ([[User talk:DSpider|talk]]) 06:10, 8 September 2012 (UTC)<br />
<br />
::I had the same problem, turned out that I had forgotten that the script needs to be called with a destination argument. It doesn't check for this situation and will use an empty $1, which causes it to be ignored and it'll try make a backup to your root directory.. very scary! I've now added a check to the script to prevent accidental misuse. [[User:Timusan|Timusan]] ([[User talk:Timusan|talk]])<br />
<br />
== What about hard links and delete options ==<br />
<br />
Why the -H option is not added?<br />
I've done a quick search in my arch system and there are a lot of hard link in the /usr/share folders.<br />
Moreover should the -delet option be added to in order to be sure that the cloned system contains all and only the files which are present in the original one?<br />
Thank you,<br />
Xwang<br />
<br />
== What happened to this page? ==<br />
<br />
Ok, I started this page, so I'm biased. It used to be clearly written, with an easy to understand example on how to use rsync and its exclude format. Now it's a one liner with the excludes mashed together and most of the page is dedicated to setting up your fstab. Why?<br />
[[User:Wooptoo|Wooptoo]] ([[User talk:Wooptoo|talk]]) 19:47, 6 March 2013 (UTC)</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Talk:System_backup&diff=249672Talk:System backup2013-03-06T19:47:05Z<p>Wooptoo: /* What happened to this page? */ new section</p>
<hr />
<div>===<s> Restore title</s> ===<br />
I cannot move it back to the same title without admin intervention. They have to delete the redirect first. Sorry for changing the name in the first place; I didn't realize subsections worked only for user pages. [[User:Pwd|pwd]] 13:27, 23 December 2009 (EST)<br />
:Oops! Sorry; didn't realize that was the cause of the hold-up. I've removed the redirect. -- [[User:Pointone|pointone]] 13:34, 23 December 2009 (EST)<br />
<br />
::Moved the page even though I don't like the title. I really don't think the naming scheme suits it; should be ''Full system backup with rsync'', in my opinion. <small>[[User:Pwd|pwd]]</small> 14:10, 23 December 2009 (EST)<br />
<br />
== Comments ==<br />
<br />
Thanks! Neat method for a sync-type backup! The only question I have is what happens if you {{Ic|dd}} the boot sector (first 512 bytes) instead of running GRUB? --[[User:VitaminJ|VitaminJ]] 22:18, 11 November 2009 (EST)<br />
<br />
---- <br />
<br />
I don't know if it works with <code>dd</code>, since the partitioning scheme can be different on the two harddrives.<br />
<br />
* I vote for merging this with [[rsync]].<br />
* I second the vote.<br />
<br />
[[User:Wooptoo|Wooptoo]] 07:14, 2 December 2009 (EST)<br />
--[[User:Keiichi|Keiichi]] 20:59, 2 December 2009 (EST)<br />
----<br />
Yep, I think you are right, I think that GRUB hardcodes the path to menu.lst in the GRUB boot program, so if you change around disks it won't work.<br />
<br />
As an alternative, an article on using tar instead might be useful because rsync may improperly preserves permissions across filesystems. For example if you backup from ext3 to XFS, and try to restore back to ext3.<br />
<br />
:The only issue would be doing it with FAT or NTFS were permissions just aren't possible. Coincidentially, I've done this exact setup using XFS and ext4 wihout anything breaking down. I only had problems between reiserfs and *, but that was due to SELinux context. [[User:Dres|Dres]] 21:22, 18 January 2010 (EST)<br />
<br />
----<br />
I think its a good idea to mention dirvish here. --[[User:Moere|Moere]] 03:37, 1 March 2010 (EST)<br />
<br />
----<br />
on the same topic, you can also look at a free script that i wrote to backup the whole disk with rsync here: http://blog.pointsoftware.ch/index.php/howto-local-and-remote-snapshot-backup-using-rsync-with-hard-links/<br />
<br />
It uses file deduplication thanks to hard-links, uses also MD5 integrity signature, 'chattr' protection, filter rules, disk quota, retention policy with exponential distribution (backups rotation while saving more recent backups than older).<br />
It was already used in Disaster Recovery Plans for banking companies, in order to replicate datacenters, using only little network bandwidth and transport encryption tunnel.<br />
<br />
Can be used locally on each servers or via network on a central remote backup server.<br />
windows server could also be backuped by using a linux box that mount smb shares from them.<br />
<br />
i hope it will be useful to you guys <br />
--[[User:Scheuref|Scheuref]] ([[User talk:Scheuref|talk]]) 14:03, 19 September 2012 (UTC)<br />
<br />
== <s> Errors </s> ==<br />
<br />
I'm getting the following error with this script, unless I use --delete-excluded, although that was declared unnecessary:<br />
cannot delete non-empty directory: lib<br />
could not make way for new symlink: lib<br />
cannot delete non-empty directory: lib64<br />
could not make way for new symlink: lib64<br />
--[[User:Malstrond|Malstrond]] ([[User talk:Malstrond|talk]]) 00:31, 8 September 2012 (UTC)<br />
<br />
:Rsync doesn't delete... You must have modified the script? --[[User:DSpider|DSpider]] ([[User talk:DSpider|talk]]) 06:10, 8 September 2012 (UTC)<br />
<br />
::I had the same problem, turned out that I had forgotten that the script needs to be called with a destination argument. It doesn't check for this situation and will use an empty $1, which causes it to be ignored and it'll try make a backup to your root directory.. very scary! I've now added a check to the script to prevent accidental misuse. [[User:Timusan|Timusan]] ([[User talk:Timusan|talk]])<br />
<br />
== What about hard links and delete options ==<br />
<br />
Why the -H option is not added?<br />
I've done a quick search in my arch system and there are a lot of hard link in the /usr/share folders.<br />
Moreover should the -delet option be added to in order to be sure that the cloned system contains all and only the files which are present in the original one?<br />
Thank you,<br />
Xwang<br />
<br />
== What happened to this page? ==<br />
<br />
Ok, I started this page, so I'm biased. It used to be clearly written, with an easy to understand example on how to use rsync and its exclude format. Now it's a one liner with the excludes mashed together and most of the page is dedicated to setting up your fstab. Why?</div>Wooptoohttps://wiki.archlinux.org/index.php?title=Benchmarking/Data_storage_devices&diff=243545Benchmarking/Data storage devices2013-01-11T23:01:13Z<p>Wooptoo: /* Using gnome-disks */</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 gnome-disks contained in the {{pkg|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 />
* [[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 gnome-disks ===<br />
<br />
# gnome-disks<br />
<br />
Users will need to navigate through the GUI to the benchmark button ("More actions..." => "Benchmark Volume..."). [http://imgur.com/Ayv1B Example]<br />
<br />
=== Using systemd-analyze ===<br />
<br />
systemd-analyze plot > boot.svg<br />
<br />
Will plot a detailed graphic with the boot sequence: kernel time, userspace time, time taken by each service. [http://imgur.com/4ywt1 Example]<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 />
*Controller:<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 />
== Results ==<br />
<br />
=== Table ===<br />
<br />
All values are taken from the [https://wiki.archlinux.org/index.php/SSD_Benchmarking#Using_dd ''dd'' benchmark]. This is just an overview and has no scientific use.<br />
<br />
{| class="wikitable" border="1" cellpadding="5" cellspacing="0"<br />
! User !! Vendor !! Model !! Capacity [GB] !! Write [MB/sec] !! Read [MB/sec] !! Re-Read [MB/sec]<br />
|-<br />
| jac || Crucial || C300 || 128 || 138 || 372 || 6500<br />
|-<br />
| lynix || Crucial || M4 || 128 || 193 || 268 || 6800<br />
|-<br />
| wzyboy || Crucial || M4 || 64 || 113 || 276 || 3400<br />
|-<br />
| dundee || Intel || 310 Soda Creek || 40 || 44.2 || 197 || 4200<br />
|-<br />
| bugflux || Intel || 330 || 120 || 44.2 || 242 || 4500<br />
|-<br />
| Cirk || Intel || X18-M (G2) || 160 || 103 || 263 || 2700<br />
|-<br />
| Graysky || Intel || X25-M (G2) || 80 || 80.6 || 268 || 6300<br />
|-<br />
| fackamato || Intel || X25-M (G2) || 160 || 98 || 262 || 3000<br />
|-<br />
| Cirk || Intel || X25-M (G2) || 80 || 70 || 208 || 4200<br />
|-<br />
| timo.hardebusch || Intel || X25-M (G2) || 120 || 106 || 265 || 2900<br />
|-<br />
| Musikolo || OCZ || Vertex 4 SATA 3 || 128 || 233 || 392 || 3600<br />
|-<br />
| Graysky || OCZ || Vertex 4 SATA 3 || 128 || 228 || 394 || -<br />
|-<br />
| Graysky || OCZ || Vertex 4 SATA 2 || 128 || 251 || 284 || -<br />
|-<br />
| Surfed || OCZ || Vertex || 60 || 142 || 236 || 5200<br />
|-<br />
| Sputnick || OCZ || Vertex 3 || 120 || 245 || 225 || 4600<br />
|-<br />
| ScottKidder || OCZ || Vertex Turbo || 30 || 49 || 115 || 2600<br />
|-<br />
| longint || OCZ || Vertex 2 || 240 || 852? || 241 || 3400<br />
|-<br />
| muflone || OCZ || Vertex 3 || 120 || 377 || 291 || 10300<br />
|-<br />
| bardo || OCZ || Agility 3 || 120 || 445 || 455 || 8200<br />
|-<br />
| Cirk || Samsung || MMCQE28GFMUP-MVA || 128 || 45 || 99 || 2300<br />
|-<br />
| skylinux || Samsung || 470 || 64 || 188 || 204 || 1000<br />
|-<br />
| kevincodux || Samsung || 830 || 128 || 313 || 525 || 9000<br />
|-<br />
| Dani || Sandisk || Extreme || 240 || 481 || 414 || 6000<br />
|- <br />
| Artsibash || Kingston || HyperX || 120 || 451 || 431 || 8600<br />
|- <br />
| WonderWoofy || Kingston || HyperX 3k || 120 || 518 || 316 || 7200<br />
|-<br />
| Tuxe || Kingston || SSDNow V+100 || 128 || 110 || 232 || 3300<br />
|-<br />
| thof || Kingston || SNV425-S2BD || 128 || 164 || 260 || 3000<br />
|-<br />
| WonderWoofy || Mushkin || Atlas (mSATA II) || 128 || 262 || 242 || 7300<br />
|-<br />
| AleksMK || Liteon || M3S || 256 || 336 || 432 || 4200<br />
|-<br />
|}<br />
<br />
=== Corsair ===<br />
==== Corsair Force 3 ====<br />
*SSD: Corsair Force 3 120gb (SATA 3)<br />
*Model Number: Corsair Force 3 SSD<br />
*Firmware Version: 1.3.3 <br />
*Capacity: 120 GB<br />
*User: bserem<br />
*Kernel: 3.4.9<br />
*Filesystem: BTRFS<br />
*Notes: , Systemd, UEFI (with a small FAT uefi partition at the beggining of the disk)<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 28232 MB in 2.00 seconds = 14137.02 MB/sec<br />
Timing buffered disk reads: 1164 MB in 3.01 seconds = 387.33 MB/sec<br />
<br />
Minimum Read Rate: 388.04 MB/s<br />
Maximum Read Rate: 387.13 MB/s<br />
Average Read Rate: 387.252 MS/s<br />
<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 330 ====<br />
*SSD: Intel 330<br />
*Model Number: SSDSC2CT120A3<br />
*Firmware Version: 300i<br />
*Capacity: 120 GB<br />
*User: bugflux<br />
*Filesystem: ext4<br />
*'''Note''': Sata II computer<br />
<br />
# hdparm -tT /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 9222 MB in 2.00 seconds = 4612.61 MB/sec<br />
Timing buffered disk reads: 672 MB in 3.01 seconds = 223.40 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, 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, 4.43827 s, 242 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.240778 s, 4.5 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<br />
*Firmware Version: 1.5<br />
*Capacity: 128 GB<br />
*Controller: Marvell Technology Group Ltd. 88SE9128 PCIe SATA 6 Gb/s RAID controller (rev 11)<br />
*Kernel: 3.6.11-1<br />
*User: Musikolo<br />
*Notes: <br />
** Filesystem: ext4 with options ''defaults,relatime,discard''. <br />
** Partition: aligned (fist sector 2048 / 1MiB free space at the beginning). Additional info [https://bbs.archlinux.org/viewtopic.php?pid=1211245#p1211245 here].<br />
** Scheduler: deadline. Additional info [https://wiki.archlinux.org/index.php/Solid_State_Drives#Using_udev_for_one_device_or_HDD.2FSSD_mixed_environment here].<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 7752 MB in 2.00 seconds = 3877.19 MB/sec<br />
Timing buffered disk reads: 1122 MB in 3.00 seconds = 373.78 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.60766 s, 233 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.74071 s, 392 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.302118 s, 3.6 GB/s<br />
<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: [[User:Graysky]]<br />
===== In SATA3 Controller =====<br />
# hdparm -Tt /dev/sda<br />
<br />
/dev/sda:<br />
Timing cached reads: 33756 MB in 2.00 seconds = 16902.49 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.9279 s, 367 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.49942 s, 430 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 120 ====<br />
*SSD:OCZ-VERTEX3<br />
*Firmware Version:<br />
*Capacity: 6Gb/s SATA III<br />
*User:[[User:pingpong]]<br />
<br />
# hdpram -Tt /dev/sda<br />
<br />
/dev/sda:<br />
Timing cached reads: 11180 MB in 2.00 seconds = 5594.15 MB/sec<br />
Timing buffered disk reads: 736 MB in 3.00 seconds = 245.27 MB/sec<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.20024 s, 256 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.12454 s, 260 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.172948 s, 6.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 />
==== SAMSUNG 830 256GB ====<br />
*SSD: SAMSUNG 830 256GB<br />
*Model Number: MZ-7PC256<br />
*Firmware Version: CXM03B1Q<br />
*Capacity: 256 GB<br />
*User: Revelation<br />
*Kernel: 3.5.4<br />
*Filesystem: ext4<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 15888 MB in 2.00 seconds = 7952.13 MB/sec<br />
Timing buffered disk reads: 1464 MB in 3.00 seconds = 488.00 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,15782 s, 340 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,08421 s, 515 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, 6.2 GB/s<br />
<br />
=== Sandisk ===<br />
==== Sandisk Extreme 240 GB ====<br />
*SSD: Sandisk Extreme (SATA 3: 6Gb/s)<br />
*Model Number: SDSSDX240GG25<br />
*Capacity: 240 GB<br />
*User: Dani<br />
<br />
# sudo hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 11596 MB in 2.00 seconds = 5802.26 MB/sec<br />
Timing buffered disk reads: 1190 MB in 3.00 seconds = 396.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.23003 s, 481 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.5909 s, 414 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.177952 s, 6.0 GB/s<br />
<br />
==== Sandisk Extreme 120 GB ====<br />
* SSD: Sandik Extreme 120 GB (SATA 3: 6 GB/s)<br />
* Model Number: SDSSDX-120G-G25<br />
* Firmware Version: R201<br />
* Capacity: 120 GB<br />
* User: ''hsngrms''<br />
* Kernel: 3.6.3-1-ARCH x86_64<br />
* Filesystem: EXT4<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 6824 MB in 2.00 seconds = 3413.53 MB/sec<br />
Timing buffered disk reads: 1332 MB in 3.00 seconds = 443.99 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,44496 s, 439 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,64944 s, 405 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,163495 s, 6,6 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 HyperX 3K 120GB ====<br />
*SSD: Kingston HyperX 3K 120GB (MLC/Intel synchronous ONFi NAND/LSI SandForce SF-2281 25nm controller/SATA3/2.5")<br />
*Model Number: SH103S3120G<br />
*Firmware: 501ABBF0<br />
*Capacity: 120 GB<br />
*Misc: Intel DQ77MK mobo SATA3 port, linux 3.5.4-1, ext4 (has_journal + discard,noatime)<br />
*[[User: MajorTom]]<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 15382 MB in 2.00 seconds = 7702.01 MB/sec<br />
Timing buffered disk reads: 1442 MB in 3.00 seconds = 480.39 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.06937 s, 519 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.58996 s, 415 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.207434 s, 5.2 GB/s<br />
<br />
==== Kingston HyperX 3K 120GB ====<br />
*SSD: Kingston HyperX 3K 120GB<br />
*Model Number: SH103S3120G<br />
*Firmware: 503ABBF0<br />
*Capacity: 120 GB<br />
*Misc: SATA3 port, linux 3.6.4-1-ck, ext4 <br />
*User: WonderWoofy<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 16562 MB in 2.00 seconds = 8289.47 MB/sec<br />
Timing buffered disk reads: 1078 MB in 3.01 seconds = 358.53 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.07445 s, 518 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.40264 s, 316 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.149056 s, 7.2 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 />
===Mushkin===<br />
==== Mushkin mSATA Atlas 128GB ====<br />
*SSD: Mushkin Atlas 128GB SATA III<br />
*Model Number: MKNSSDAT120GB-DX <br />
*Firmware: 504ABBF0<br />
*Capacity: 120 GB<br />
*Misc: SATA II Port (mSATA), linux 3.6.4-1-ck, ext4, Sandforce, <br />
*User: WonderWoofy<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sdb:<br />
Timing cached reads: 16116 MB in 2.00 seconds = 8065.82 MB/sec<br />
Timing buffered disk reads: 458 MB in 3.00 seconds = 152.53 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.09965 s, 262 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.4438 s, 242 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.143544 s, 7.5 GB/s<br />
<br />
===Liteon===<br />
====Liteon M3S====<br />
*SSD: Liteon M3S 256GB SATA III<br />
*Model Number: LCT-256M3S <br />
*Firmware: VRDC<br />
*Capacity: 256 GB<br />
*User: AleksMK<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 8406 MB in 2.00 seconds = 4206.12 MB/sec<br />
Timing buffered disk reads: 1212 MB in 3.00 seconds = 403.81 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.2338 s, 332 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.48531 s, 432 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.24457 s, 4.4 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 />
'''i5-3210M'''<br />
*~500 MB/s :With AES-NI<br />
*~200 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 />
==== SAMSUNG 830 256GB ====<br />
<br />
*SSD: Samsung 830 256GB<br />
*Model Number: MZ-7PC256B/WW<br />
*Firmware Version: CXM03BQ1<br />
*Capacity: 256 GB<br />
*User: stefseel<br />
*Kernel: 3.4.6-1-ARCH (with aesni_intel module)<br />
*Filesystem: ext4 (relatime,discard) over LVM2 over dm-crypt/LUKS (allow-discards)<br />
*System: Lenovo ThinkPad T430 (i5-3210M)<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 15000 MB in 2.00 seconds = 7500 MB/sec<br />
Timing buffered disk reads: 1470 MB in 3.00 seconds = 490 MB/sec<br />
<br />
With default Arch settings with installed pm-utils: JOURNAL_COMMIT_TIME_AC=0, DRIVE_READAHEAD_AC=256<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.62668 s, 300 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.07337 s, 170 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.154298 s, 7.0 GB/s<br />
<br />
What annoyed me was the poor read performance. I observed that in battery mode with unplugged AC the read rate was 500 MB/s. I did some research and found out that pm-utils is to blame. In AC mode it sets journal commit time to zero and readahead to 256 whereas in battery mode it sets journal commit time to 600 and readahead to 3072. See scripts /usr/lib/pm-utils/power.d/journal-commit and /usr/lib/pm-utils/power.d/readahead. So I added a custom config to set journal commit time always to 600 and readahead always to 4096, the result made me happy :)<br />
<br />
# cat /etc/pm/config.d/config<br />
DRIVE_READAHEAD_AC=4096<br />
DRIVE_READAHEAD_BAT=4096<br />
JOURNAL_COMMIT_TIME_AC=600<br />
JOURNAL_COMMIT_TIME_BAT=600<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.15534 s, 500 MB/s<br />
<br />
However there is still an issue: after resuming from suspend read rate goes down to 270 MB/s.<br />
<br />
<br />
==== SAMSUNG 830 256GB ====<br />
*[[User: hunterthompson]]<br />
*SSD: SAMSUNG 830 256GB<br />
*Firmware: CXM03B1Q<br />
*Capacity: 256 GB<br />
*System: Thinkpad X230, 16GB PC-1600 CL9 Kingston HyperX<br />
*CPU: i7-3520M, AES-NI, Hyper-Threaded, 2.9GHz-3.6GHz, Steady 3.4GHz with all 4 threads 100%<br />
*Kernel: x86_64 linux-grsec 3.5.4-1-grsec (Desktop, Virt, Host, KVM, Security)<br />
*Encryption: Full Disk, LVM2 on LUKS dm-crypt, Allow-Discards<br />
*Cryptsetup: -h sha512 -c aes-xts-plain64 -y -s 512 luksFormat --align-payload=8192<br />
*Filesystem: mkfs.ext4 -b 4096 -E stride=128,stripe-width=128 /dev/mapper/VolGroup00-lvolhome<br />
*fstab: ext4,rw,noatime,nodiratime,discard,stripe=128,data=ordered,errors=remount-ro<br />
*Notes: SATAIII, partitions aligned and no swap<br />
<br />
% dd bs=1M count=1024 if=7600_Retail_Ultimate_DVD.iso of=/dev/null conv=fdatasync<br />
dd: fsync failed for ‘/dev/null’: Invalid argument<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.42075 s, 314 MB/s<br />
<br />
% dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.48574 s, 308 MB/s<br />
<br />
% dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.45361 s, 311 MB/s<br />
<br />
% dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.44276 s, 312 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>Wooptoohttps://wiki.archlinux.org/index.php?title=Benchmarking/Data_storage_devices&diff=243477Benchmarking/Data storage devices2013-01-11T07:24:47Z<p>Wooptoo: </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 gnome-disks contained in the {{pkg|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 />
* [[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 gnome-disks ===<br />
<br />
# gnome-disks<br />
<br />
Users will need to navigate through the GUI to the benchmark button ("More actions..." => "Benchmark Volume...").<br />
<br />
=== Using systemd-analyze ===<br />
<br />
systemd-analyze plot > boot.svg<br />
<br />
Will plot a detailed graphic with the boot sequence: kernel time, userspace time, time taken by each service. [http://imgur.com/4ywt1 Example]<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 />
*Controller:<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 />
== Results ==<br />
<br />
=== Table ===<br />
<br />
All values are taken from the [https://wiki.archlinux.org/index.php/SSD_Benchmarking#Using_dd ''dd'' benchmark]. This is just an overview and has no scientific use.<br />
<br />
{| class="wikitable" border="1" cellpadding="5" cellspacing="0"<br />
! User !! Vendor !! Model !! Capacity [GB] !! Write [MB/sec] !! Read [MB/sec] !! Re-Read [MB/sec]<br />
|-<br />
| jac || Crucial || C300 || 128 || 138 || 372 || 6500<br />
|-<br />
| lynix || Crucial || M4 || 128 || 193 || 268 || 6800<br />
|-<br />
| wzyboy || Crucial || M4 || 64 || 113 || 276 || 3400<br />
|-<br />
| dundee || Intel || 310 Soda Creek || 40 || 44.2 || 197 || 4200<br />
|-<br />
| bugflux || Intel || 330 || 120 || 44.2 || 242 || 4500<br />
|-<br />
| Cirk || Intel || X18-M (G2) || 160 || 103 || 263 || 2700<br />
|-<br />
| Graysky || Intel || X25-M (G2) || 80 || 80.6 || 268 || 6300<br />
|-<br />
| fackamato || Intel || X25-M (G2) || 160 || 98 || 262 || 3000<br />
|-<br />
| Cirk || Intel || X25-M (G2) || 80 || 70 || 208 || 4200<br />
|-<br />
| timo.hardebusch || Intel || X25-M (G2) || 120 || 106 || 265 || 2900<br />
|-<br />
| Musikolo || OCZ || Vertex 4 SATA 3 || 128 || 233 || 392 || 3600<br />
|-<br />
| Graysky || OCZ || Vertex 4 SATA 3 || 128 || 228 || 394 || -<br />
|-<br />
| Graysky || OCZ || Vertex 4 SATA 2 || 128 || 251 || 284 || -<br />
|-<br />
| Surfed || OCZ || Vertex || 60 || 142 || 236 || 5200<br />
|-<br />
| Sputnick || OCZ || Vertex 3 || 120 || 245 || 225 || 4600<br />
|-<br />
| ScottKidder || OCZ || Vertex Turbo || 30 || 49 || 115 || 2600<br />
|-<br />
| longint || OCZ || Vertex 2 || 240 || 852? || 241 || 3400<br />
|-<br />
| muflone || OCZ || Vertex 3 || 120 || 377 || 291 || 10300<br />
|-<br />
| bardo || OCZ || Agility 3 || 120 || 445 || 455 || 8200<br />
|-<br />
| Cirk || Samsung || MMCQE28GFMUP-MVA || 128 || 45 || 99 || 2300<br />
|-<br />
| skylinux || Samsung || 470 || 64 || 188 || 204 || 1000<br />
|-<br />
| kevincodux || Samsung || 830 || 128 || 313 || 525 || 9000<br />
|-<br />
| Dani || Sandisk || Extreme || 240 || 481 || 414 || 6000<br />
|- <br />
| Artsibash || Kingston || HyperX || 120 || 451 || 431 || 8600<br />
|- <br />
| WonderWoofy || Kingston || HyperX 3k || 120 || 518 || 316 || 7200<br />
|-<br />
| Tuxe || Kingston || SSDNow V+100 || 128 || 110 || 232 || 3300<br />
|-<br />
| thof || Kingston || SNV425-S2BD || 128 || 164 || 260 || 3000<br />
|-<br />
| WonderWoofy || Mushkin || Atlas (mSATA II) || 128 || 262 || 242 || 7300<br />
|-<br />
| AleksMK || Liteon || M3S || 256 || 336 || 432 || 4200<br />
|-<br />
|}<br />
<br />
=== Corsair ===<br />
==== Corsair Force 3 ====<br />
*SSD: Corsair Force 3 120gb (SATA 3)<br />
*Model Number: Corsair Force 3 SSD<br />
*Firmware Version: 1.3.3 <br />
*Capacity: 120 GB<br />
*User: bserem<br />
*Kernel: 3.4.9<br />
*Filesystem: BTRFS<br />
*Notes: , Systemd, UEFI (with a small FAT uefi partition at the beggining of the disk)<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 28232 MB in 2.00 seconds = 14137.02 MB/sec<br />
Timing buffered disk reads: 1164 MB in 3.01 seconds = 387.33 MB/sec<br />
<br />
Minimum Read Rate: 388.04 MB/s<br />
Maximum Read Rate: 387.13 MB/s<br />
Average Read Rate: 387.252 MS/s<br />
<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 330 ====<br />
*SSD: Intel 330<br />
*Model Number: SSDSC2CT120A3<br />
*Firmware Version: 300i<br />
*Capacity: 120 GB<br />
*User: bugflux<br />
*Filesystem: ext4<br />
*'''Note''': Sata II computer<br />
<br />
# hdparm -tT /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 9222 MB in 2.00 seconds = 4612.61 MB/sec<br />
Timing buffered disk reads: 672 MB in 3.01 seconds = 223.40 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, 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, 4.43827 s, 242 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.240778 s, 4.5 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<br />
*Firmware Version: 1.5<br />
*Capacity: 128 GB<br />
*Controller: Marvell Technology Group Ltd. 88SE9128 PCIe SATA 6 Gb/s RAID controller (rev 11)<br />
*Kernel: 3.6.11-1<br />
*User: Musikolo<br />
*Notes: <br />
** Filesystem: ext4 with options ''defaults,relatime,discard''. <br />
** Partition: aligned (fist sector 2048 / 1MiB free space at the beginning). Additional info [https://bbs.archlinux.org/viewtopic.php?pid=1211245#p1211245 here].<br />
** Scheduler: deadline. Additional info [https://wiki.archlinux.org/index.php/Solid_State_Drives#Using_udev_for_one_device_or_HDD.2FSSD_mixed_environment here].<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 7752 MB in 2.00 seconds = 3877.19 MB/sec<br />
Timing buffered disk reads: 1122 MB in 3.00 seconds = 373.78 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.60766 s, 233 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.74071 s, 392 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.302118 s, 3.6 GB/s<br />
<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: [[User:Graysky]]<br />
===== In SATA3 Controller =====<br />
# hdparm -Tt /dev/sda<br />
<br />
/dev/sda:<br />
Timing cached reads: 33756 MB in 2.00 seconds = 16902.49 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.9279 s, 367 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.49942 s, 430 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 120 ====<br />
*SSD:OCZ-VERTEX3<br />
*Firmware Version:<br />
*Capacity: 6Gb/s SATA III<br />
*User:[[User:pingpong]]<br />
<br />
# hdpram -Tt /dev/sda<br />
<br />
/dev/sda:<br />
Timing cached reads: 11180 MB in 2.00 seconds = 5594.15 MB/sec<br />
Timing buffered disk reads: 736 MB in 3.00 seconds = 245.27 MB/sec<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.20024 s, 256 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.12454 s, 260 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.172948 s, 6.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 />
==== SAMSUNG 830 256GB ====<br />
*SSD: SAMSUNG 830 256GB<br />
*Model Number: MZ-7PC256<br />
*Firmware Version: CXM03B1Q<br />
*Capacity: 256 GB<br />
*User: Revelation<br />
*Kernel: 3.5.4<br />
*Filesystem: ext4<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 15888 MB in 2.00 seconds = 7952.13 MB/sec<br />
Timing buffered disk reads: 1464 MB in 3.00 seconds = 488.00 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,15782 s, 340 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,08421 s, 515 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, 6.2 GB/s<br />
<br />
=== Sandisk ===<br />
==== Sandisk Extreme 240 GB ====<br />
*SSD: Sandisk Extreme (SATA 3: 6Gb/s)<br />
*Model Number: SDSSDX240GG25<br />
*Capacity: 240 GB<br />
*User: Dani<br />
<br />
# sudo hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 11596 MB in 2.00 seconds = 5802.26 MB/sec<br />
Timing buffered disk reads: 1190 MB in 3.00 seconds = 396.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.23003 s, 481 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.5909 s, 414 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.177952 s, 6.0 GB/s<br />
<br />
==== Sandisk Extreme 120 GB ====<br />
* SSD: Sandik Extreme 120 GB (SATA 3: 6 GB/s)<br />
* Model Number: SDSSDX-120G-G25<br />
* Firmware Version: R201<br />
* Capacity: 120 GB<br />
* User: ''hsngrms''<br />
* Kernel: 3.6.3-1-ARCH x86_64<br />
* Filesystem: EXT4<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 6824 MB in 2.00 seconds = 3413.53 MB/sec<br />
Timing buffered disk reads: 1332 MB in 3.00 seconds = 443.99 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,44496 s, 439 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,64944 s, 405 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,163495 s, 6,6 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 HyperX 3K 120GB ====<br />
*SSD: Kingston HyperX 3K 120GB (MLC/Intel synchronous ONFi NAND/LSI SandForce SF-2281 25nm controller/SATA3/2.5")<br />
*Model Number: SH103S3120G<br />
*Firmware: 501ABBF0<br />
*Capacity: 120 GB<br />
*Misc: Intel DQ77MK mobo SATA3 port, linux 3.5.4-1, ext4 (has_journal + discard,noatime)<br />
*[[User: MajorTom]]<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 15382 MB in 2.00 seconds = 7702.01 MB/sec<br />
Timing buffered disk reads: 1442 MB in 3.00 seconds = 480.39 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.06937 s, 519 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.58996 s, 415 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.207434 s, 5.2 GB/s<br />
<br />
==== Kingston HyperX 3K 120GB ====<br />
*SSD: Kingston HyperX 3K 120GB<br />
*Model Number: SH103S3120G<br />
*Firmware: 503ABBF0<br />
*Capacity: 120 GB<br />
*Misc: SATA3 port, linux 3.6.4-1-ck, ext4 <br />
*User: WonderWoofy<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 16562 MB in 2.00 seconds = 8289.47 MB/sec<br />
Timing buffered disk reads: 1078 MB in 3.01 seconds = 358.53 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.07445 s, 518 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.40264 s, 316 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.149056 s, 7.2 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 />
===Mushkin===<br />
==== Mushkin mSATA Atlas 128GB ====<br />
*SSD: Mushkin Atlas 128GB SATA III<br />
*Model Number: MKNSSDAT120GB-DX <br />
*Firmware: 504ABBF0<br />
*Capacity: 120 GB<br />
*Misc: SATA II Port (mSATA), linux 3.6.4-1-ck, ext4, Sandforce, <br />
*User: WonderWoofy<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sdb:<br />
Timing cached reads: 16116 MB in 2.00 seconds = 8065.82 MB/sec<br />
Timing buffered disk reads: 458 MB in 3.00 seconds = 152.53 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.09965 s, 262 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.4438 s, 242 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.143544 s, 7.5 GB/s<br />
<br />
===Liteon===<br />
====Liteon M3S====<br />
*SSD: Liteon M3S 256GB SATA III<br />
*Model Number: LCT-256M3S <br />
*Firmware: VRDC<br />
*Capacity: 256 GB<br />
*User: AleksMK<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 8406 MB in 2.00 seconds = 4206.12 MB/sec<br />
Timing buffered disk reads: 1212 MB in 3.00 seconds = 403.81 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.2338 s, 332 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.48531 s, 432 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.24457 s, 4.4 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 />
'''i5-3210M'''<br />
*~500 MB/s :With AES-NI<br />
*~200 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 />
==== SAMSUNG 830 256GB ====<br />
<br />
*SSD: Samsung 830 256GB<br />
*Model Number: MZ-7PC256B/WW<br />
*Firmware Version: CXM03BQ1<br />
*Capacity: 256 GB<br />
*User: stefseel<br />
*Kernel: 3.4.6-1-ARCH (with aesni_intel module)<br />
*Filesystem: ext4 (relatime,discard) over LVM2 over dm-crypt/LUKS (allow-discards)<br />
*System: Lenovo ThinkPad T430 (i5-3210M)<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 15000 MB in 2.00 seconds = 7500 MB/sec<br />
Timing buffered disk reads: 1470 MB in 3.00 seconds = 490 MB/sec<br />
<br />
With default Arch settings with installed pm-utils: JOURNAL_COMMIT_TIME_AC=0, DRIVE_READAHEAD_AC=256<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.62668 s, 300 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.07337 s, 170 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.154298 s, 7.0 GB/s<br />
<br />
What annoyed me was the poor read performance. I observed that in battery mode with unplugged AC the read rate was 500 MB/s. I did some research and found out that pm-utils is to blame. In AC mode it sets journal commit time to zero and readahead to 256 whereas in battery mode it sets journal commit time to 600 and readahead to 3072. See scripts /usr/lib/pm-utils/power.d/journal-commit and /usr/lib/pm-utils/power.d/readahead. So I added a custom config to set journal commit time always to 600 and readahead always to 4096, the result made me happy :)<br />
<br />
# cat /etc/pm/config.d/config<br />
DRIVE_READAHEAD_AC=4096<br />
DRIVE_READAHEAD_BAT=4096<br />
JOURNAL_COMMIT_TIME_AC=600<br />
JOURNAL_COMMIT_TIME_BAT=600<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.15534 s, 500 MB/s<br />
<br />
However there is still an issue: after resuming from suspend read rate goes down to 270 MB/s.<br />
<br />
<br />
==== SAMSUNG 830 256GB ====<br />
*[[User: hunterthompson]]<br />
*SSD: SAMSUNG 830 256GB<br />
*Firmware: CXM03B1Q<br />
*Capacity: 256 GB<br />
*System: Thinkpad X230, 16GB PC-1600 CL9 Kingston HyperX<br />
*CPU: i7-3520M, AES-NI, Hyper-Threaded, 2.9GHz-3.6GHz, Steady 3.4GHz with all 4 threads 100%<br />
*Kernel: x86_64 linux-grsec 3.5.4-1-grsec (Desktop, Virt, Host, KVM, Security)<br />
*Encryption: Full Disk, LVM2 on LUKS dm-crypt, Allow-Discards<br />
*Cryptsetup: -h sha512 -c aes-xts-plain64 -y -s 512 luksFormat --align-payload=8192<br />
*Filesystem: mkfs.ext4 -b 4096 -E stride=128,stripe-width=128 /dev/mapper/VolGroup00-lvolhome<br />
*fstab: ext4,rw,noatime,nodiratime,discard,stripe=128,data=ordered,errors=remount-ro<br />
*Notes: SATAIII, partitions aligned and no swap<br />
<br />
% dd bs=1M count=1024 if=7600_Retail_Ultimate_DVD.iso of=/dev/null conv=fdatasync<br />
dd: fsync failed for ‘/dev/null’: Invalid argument<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.42075 s, 314 MB/s<br />
<br />
% dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.48574 s, 308 MB/s<br />
<br />
% dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.45361 s, 311 MB/s<br />
<br />
% dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.44276 s, 312 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>Wooptoohttps://wiki.archlinux.org/index.php?title=Benchmarking/Data_storage_devices&diff=243476Benchmarking/Data storage devices2013-01-11T07:24:24Z<p>Wooptoo: /* Using gnome-disks */</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 gnome-disks contained in the {{pkg|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 />
* [[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 gnome-disks ===<br />
<br />
# gnome-disks<br />
<br />
Users will need to navigate through the GUI to the benchmark button ("More actions..." => "Benchmark Volume...").<br />
<br />
<br />
=== Using systemd-analyze ===<br />
<br />
systemd-analyze plot > boot.svg<br />
<br />
Will plot a detailed graphic with the boot sequence: kernel time, userspace time, time taken by each service. [http://imgur.com/4ywt1 Example]<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 />
*Controller:<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 />
== Results ==<br />
<br />
=== Table ===<br />
<br />
All values are taken from the [https://wiki.archlinux.org/index.php/SSD_Benchmarking#Using_dd ''dd'' benchmark]. This is just an overview and has no scientific use.<br />
<br />
{| class="wikitable" border="1" cellpadding="5" cellspacing="0"<br />
! User !! Vendor !! Model !! Capacity [GB] !! Write [MB/sec] !! Read [MB/sec] !! Re-Read [MB/sec]<br />
|-<br />
| jac || Crucial || C300 || 128 || 138 || 372 || 6500<br />
|-<br />
| lynix || Crucial || M4 || 128 || 193 || 268 || 6800<br />
|-<br />
| wzyboy || Crucial || M4 || 64 || 113 || 276 || 3400<br />
|-<br />
| dundee || Intel || 310 Soda Creek || 40 || 44.2 || 197 || 4200<br />
|-<br />
| bugflux || Intel || 330 || 120 || 44.2 || 242 || 4500<br />
|-<br />
| Cirk || Intel || X18-M (G2) || 160 || 103 || 263 || 2700<br />
|-<br />
| Graysky || Intel || X25-M (G2) || 80 || 80.6 || 268 || 6300<br />
|-<br />
| fackamato || Intel || X25-M (G2) || 160 || 98 || 262 || 3000<br />
|-<br />
| Cirk || Intel || X25-M (G2) || 80 || 70 || 208 || 4200<br />
|-<br />
| timo.hardebusch || Intel || X25-M (G2) || 120 || 106 || 265 || 2900<br />
|-<br />
| Musikolo || OCZ || Vertex 4 SATA 3 || 128 || 233 || 392 || 3600<br />
|-<br />
| Graysky || OCZ || Vertex 4 SATA 3 || 128 || 228 || 394 || -<br />
|-<br />
| Graysky || OCZ || Vertex 4 SATA 2 || 128 || 251 || 284 || -<br />
|-<br />
| Surfed || OCZ || Vertex || 60 || 142 || 236 || 5200<br />
|-<br />
| Sputnick || OCZ || Vertex 3 || 120 || 245 || 225 || 4600<br />
|-<br />
| ScottKidder || OCZ || Vertex Turbo || 30 || 49 || 115 || 2600<br />
|-<br />
| longint || OCZ || Vertex 2 || 240 || 852? || 241 || 3400<br />
|-<br />
| muflone || OCZ || Vertex 3 || 120 || 377 || 291 || 10300<br />
|-<br />
| bardo || OCZ || Agility 3 || 120 || 445 || 455 || 8200<br />
|-<br />
| Cirk || Samsung || MMCQE28GFMUP-MVA || 128 || 45 || 99 || 2300<br />
|-<br />
| skylinux || Samsung || 470 || 64 || 188 || 204 || 1000<br />
|-<br />
| kevincodux || Samsung || 830 || 128 || 313 || 525 || 9000<br />
|-<br />
| Dani || Sandisk || Extreme || 240 || 481 || 414 || 6000<br />
|- <br />
| Artsibash || Kingston || HyperX || 120 || 451 || 431 || 8600<br />
|- <br />
| WonderWoofy || Kingston || HyperX 3k || 120 || 518 || 316 || 7200<br />
|-<br />
| Tuxe || Kingston || SSDNow V+100 || 128 || 110 || 232 || 3300<br />
|-<br />
| thof || Kingston || SNV425-S2BD || 128 || 164 || 260 || 3000<br />
|-<br />
| WonderWoofy || Mushkin || Atlas (mSATA II) || 128 || 262 || 242 || 7300<br />
|-<br />
| AleksMK || Liteon || M3S || 256 || 336 || 432 || 4200<br />
|-<br />
|}<br />
<br />
=== Corsair ===<br />
==== Corsair Force 3 ====<br />
*SSD: Corsair Force 3 120gb (SATA 3)<br />
*Model Number: Corsair Force 3 SSD<br />
*Firmware Version: 1.3.3 <br />
*Capacity: 120 GB<br />
*User: bserem<br />
*Kernel: 3.4.9<br />
*Filesystem: BTRFS<br />
*Notes: , Systemd, UEFI (with a small FAT uefi partition at the beggining of the disk)<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 28232 MB in 2.00 seconds = 14137.02 MB/sec<br />
Timing buffered disk reads: 1164 MB in 3.01 seconds = 387.33 MB/sec<br />
<br />
Minimum Read Rate: 388.04 MB/s<br />
Maximum Read Rate: 387.13 MB/s<br />
Average Read Rate: 387.252 MS/s<br />
<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 330 ====<br />
*SSD: Intel 330<br />
*Model Number: SSDSC2CT120A3<br />
*Firmware Version: 300i<br />
*Capacity: 120 GB<br />
*User: bugflux<br />
*Filesystem: ext4<br />
*'''Note''': Sata II computer<br />
<br />
# hdparm -tT /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 9222 MB in 2.00 seconds = 4612.61 MB/sec<br />
Timing buffered disk reads: 672 MB in 3.01 seconds = 223.40 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, 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, 4.43827 s, 242 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.240778 s, 4.5 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<br />
*Firmware Version: 1.5<br />
*Capacity: 128 GB<br />
*Controller: Marvell Technology Group Ltd. 88SE9128 PCIe SATA 6 Gb/s RAID controller (rev 11)<br />
*Kernel: 3.6.11-1<br />
*User: Musikolo<br />
*Notes: <br />
** Filesystem: ext4 with options ''defaults,relatime,discard''. <br />
** Partition: aligned (fist sector 2048 / 1MiB free space at the beginning). Additional info [https://bbs.archlinux.org/viewtopic.php?pid=1211245#p1211245 here].<br />
** Scheduler: deadline. Additional info [https://wiki.archlinux.org/index.php/Solid_State_Drives#Using_udev_for_one_device_or_HDD.2FSSD_mixed_environment here].<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 7752 MB in 2.00 seconds = 3877.19 MB/sec<br />
Timing buffered disk reads: 1122 MB in 3.00 seconds = 373.78 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.60766 s, 233 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.74071 s, 392 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.302118 s, 3.6 GB/s<br />
<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: [[User:Graysky]]<br />
===== In SATA3 Controller =====<br />
# hdparm -Tt /dev/sda<br />
<br />
/dev/sda:<br />
Timing cached reads: 33756 MB in 2.00 seconds = 16902.49 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.9279 s, 367 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.49942 s, 430 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 120 ====<br />
*SSD:OCZ-VERTEX3<br />
*Firmware Version:<br />
*Capacity: 6Gb/s SATA III<br />
*User:[[User:pingpong]]<br />
<br />
# hdpram -Tt /dev/sda<br />
<br />
/dev/sda:<br />
Timing cached reads: 11180 MB in 2.00 seconds = 5594.15 MB/sec<br />
Timing buffered disk reads: 736 MB in 3.00 seconds = 245.27 MB/sec<br />
<br />
$ dd if=/dev/zero of=tempfile bs=1M count=1024 conv=fdatasync,notrunc<br />
<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 4.20024 s, 256 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.12454 s, 260 MB/s<br />
<br />
$ dd if=tempfile of=/dev/null bs=1M count=1024<br />
<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 0.172948 s, 6.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 />
==== SAMSUNG 830 256GB ====<br />
*SSD: SAMSUNG 830 256GB<br />
*Model Number: MZ-7PC256<br />
*Firmware Version: CXM03B1Q<br />
*Capacity: 256 GB<br />
*User: Revelation<br />
*Kernel: 3.5.4<br />
*Filesystem: ext4<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 15888 MB in 2.00 seconds = 7952.13 MB/sec<br />
Timing buffered disk reads: 1464 MB in 3.00 seconds = 488.00 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,15782 s, 340 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,08421 s, 515 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, 6.2 GB/s<br />
<br />
=== Sandisk ===<br />
==== Sandisk Extreme 240 GB ====<br />
*SSD: Sandisk Extreme (SATA 3: 6Gb/s)<br />
*Model Number: SDSSDX240GG25<br />
*Capacity: 240 GB<br />
*User: Dani<br />
<br />
# sudo hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 11596 MB in 2.00 seconds = 5802.26 MB/sec<br />
Timing buffered disk reads: 1190 MB in 3.00 seconds = 396.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.23003 s, 481 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.5909 s, 414 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.177952 s, 6.0 GB/s<br />
<br />
==== Sandisk Extreme 120 GB ====<br />
* SSD: Sandik Extreme 120 GB (SATA 3: 6 GB/s)<br />
* Model Number: SDSSDX-120G-G25<br />
* Firmware Version: R201<br />
* Capacity: 120 GB<br />
* User: ''hsngrms''<br />
* Kernel: 3.6.3-1-ARCH x86_64<br />
* Filesystem: EXT4<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 6824 MB in 2.00 seconds = 3413.53 MB/sec<br />
Timing buffered disk reads: 1332 MB in 3.00 seconds = 443.99 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,44496 s, 439 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,64944 s, 405 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,163495 s, 6,6 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 HyperX 3K 120GB ====<br />
*SSD: Kingston HyperX 3K 120GB (MLC/Intel synchronous ONFi NAND/LSI SandForce SF-2281 25nm controller/SATA3/2.5")<br />
*Model Number: SH103S3120G<br />
*Firmware: 501ABBF0<br />
*Capacity: 120 GB<br />
*Misc: Intel DQ77MK mobo SATA3 port, linux 3.5.4-1, ext4 (has_journal + discard,noatime)<br />
*[[User: MajorTom]]<br />
<br />
# hdparm -Tt /dev/sda<br />
Timing cached reads: 15382 MB in 2.00 seconds = 7702.01 MB/sec<br />
Timing buffered disk reads: 1442 MB in 3.00 seconds = 480.39 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.06937 s, 519 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.58996 s, 415 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.207434 s, 5.2 GB/s<br />
<br />
==== Kingston HyperX 3K 120GB ====<br />
*SSD: Kingston HyperX 3K 120GB<br />
*Model Number: SH103S3120G<br />
*Firmware: 503ABBF0<br />
*Capacity: 120 GB<br />
*Misc: SATA3 port, linux 3.6.4-1-ck, ext4 <br />
*User: WonderWoofy<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 16562 MB in 2.00 seconds = 8289.47 MB/sec<br />
Timing buffered disk reads: 1078 MB in 3.01 seconds = 358.53 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.07445 s, 518 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.40264 s, 316 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.149056 s, 7.2 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 />
===Mushkin===<br />
==== Mushkin mSATA Atlas 128GB ====<br />
*SSD: Mushkin Atlas 128GB SATA III<br />
*Model Number: MKNSSDAT120GB-DX <br />
*Firmware: 504ABBF0<br />
*Capacity: 120 GB<br />
*Misc: SATA II Port (mSATA), linux 3.6.4-1-ck, ext4, Sandforce, <br />
*User: WonderWoofy<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sdb:<br />
Timing cached reads: 16116 MB in 2.00 seconds = 8065.82 MB/sec<br />
Timing buffered disk reads: 458 MB in 3.00 seconds = 152.53 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.09965 s, 262 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.4438 s, 242 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.143544 s, 7.5 GB/s<br />
<br />
===Liteon===<br />
====Liteon M3S====<br />
*SSD: Liteon M3S 256GB SATA III<br />
*Model Number: LCT-256M3S <br />
*Firmware: VRDC<br />
*Capacity: 256 GB<br />
*User: AleksMK<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 8406 MB in 2.00 seconds = 4206.12 MB/sec<br />
Timing buffered disk reads: 1212 MB in 3.00 seconds = 403.81 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.2338 s, 332 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.48531 s, 432 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.24457 s, 4.4 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 />
'''i5-3210M'''<br />
*~500 MB/s :With AES-NI<br />
*~200 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 />
==== SAMSUNG 830 256GB ====<br />
<br />
*SSD: Samsung 830 256GB<br />
*Model Number: MZ-7PC256B/WW<br />
*Firmware Version: CXM03BQ1<br />
*Capacity: 256 GB<br />
*User: stefseel<br />
*Kernel: 3.4.6-1-ARCH (with aesni_intel module)<br />
*Filesystem: ext4 (relatime,discard) over LVM2 over dm-crypt/LUKS (allow-discards)<br />
*System: Lenovo ThinkPad T430 (i5-3210M)<br />
<br />
# hdparm -Tt /dev/sda<br />
/dev/sda:<br />
Timing cached reads: 15000 MB in 2.00 seconds = 7500 MB/sec<br />
Timing buffered disk reads: 1470 MB in 3.00 seconds = 490 MB/sec<br />
<br />
With default Arch settings with installed pm-utils: JOURNAL_COMMIT_TIME_AC=0, DRIVE_READAHEAD_AC=256<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.62668 s, 300 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.07337 s, 170 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.154298 s, 7.0 GB/s<br />
<br />
What annoyed me was the poor read performance. I observed that in battery mode with unplugged AC the read rate was 500 MB/s. I did some research and found out that pm-utils is to blame. In AC mode it sets journal commit time to zero and readahead to 256 whereas in battery mode it sets journal commit time to 600 and readahead to 3072. See scripts /usr/lib/pm-utils/power.d/journal-commit and /usr/lib/pm-utils/power.d/readahead. So I added a custom config to set journal commit time always to 600 and readahead always to 4096, the result made me happy :)<br />
<br />
# cat /etc/pm/config.d/config<br />
DRIVE_READAHEAD_AC=4096<br />
DRIVE_READAHEAD_BAT=4096<br />
JOURNAL_COMMIT_TIME_AC=600<br />
JOURNAL_COMMIT_TIME_BAT=600<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.15534 s, 500 MB/s<br />
<br />
However there is still an issue: after resuming from suspend read rate goes down to 270 MB/s.<br />
<br />
<br />
==== SAMSUNG 830 256GB ====<br />
*[[User: hunterthompson]]<br />
*SSD: SAMSUNG 830 256GB<br />
*Firmware: CXM03B1Q<br />
*Capacity: 256 GB<br />
*System: Thinkpad X230, 16GB PC-1600 CL9 Kingston HyperX<br />
*CPU: i7-3520M, AES-NI, Hyper-Threaded, 2.9GHz-3.6GHz, Steady 3.4GHz with all 4 threads 100%<br />
*Kernel: x86_64 linux-grsec 3.5.4-1-grsec (Desktop, Virt, Host, KVM, Security)<br />
*Encryption: Full Disk, LVM2 on LUKS dm-crypt, Allow-Discards<br />
*Cryptsetup: -h sha512 -c aes-xts-plain64 -y -s 512 luksFormat --align-payload=8192<br />
*Filesystem: mkfs.ext4 -b 4096 -E stride=128,stripe-width=128 /dev/mapper/VolGroup00-lvolhome<br />
*fstab: ext4,rw,noatime,nodiratime,discard,stripe=128,data=ordered,errors=remount-ro<br />
*Notes: SATAIII, partitions aligned and no swap<br />
<br />
% dd bs=1M count=1024 if=7600_Retail_Ultimate_DVD.iso of=/dev/null conv=fdatasync<br />
dd: fsync failed for ‘/dev/null’: Invalid argument<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.42075 s, 314 MB/s<br />
<br />
% dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.48574 s, 308 MB/s<br />
<br />
% dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.45361 s, 311 MB/s<br />
<br />
% dd bs=1M count=1024 if=/dev/zero of=test conv=fdatasync<br />
1024+0 records in<br />
1024+0 records out<br />
1073741824 bytes (1.1 GB) copied, 3.44276 s, 312 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>Wooptoo