https://wiki.archlinux.org/api.php?action=feedcontributions&user=Ndt&feedformat=atomArchWiki - User contributions [en]2024-03-28T17:26:27ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Swap&diff=710563Swap2022-01-16T19:25:50Z<p>Ndt: /* Loopback swap files */ minor edit s/file/device</p>
<hr />
<div>[[Category:File systems]]<br />
[[de:Swap]]<br />
[[es:Swap]]<br />
[[fr:Swap]]<br />
[[hu:Swap]]<br />
[[it:Swap]]<br />
[[ja:スワップ]]<br />
[[pt:Swap]]<br />
[[ru:Swap]]<br />
[[zh-hans:Swap]]<br />
{{Related articles start}}<br />
{{Related|fstab}}<br />
{{Related|Power management/Suspend and hibernate#Hibernation}}<br />
{{Related|Zswap}}<br />
{{Related|Swap on video ram}}<br />
{{Related|ZFS#Swap volume}}<br />
{{Related|dm-crypt/Swap encryption}}<br />
{{Related articles end}}<br />
This page provides an introduction to [[Wikipedia:Paging|swap space and paging]] on GNU/Linux. It covers creation and activation of swap partitions and swap files.<br />
<br />
From [https://www.linux.com/news/all-about-linux-swap-space/ All about Linux swap space]:<br />
<br />
:Linux divides its physical RAM (random access memory) into chunks of memory called pages. Swapping is the process whereby a page of memory is copied to the preconfigured space on the hard disk, called swap space, to free up that page of memory. The combined sizes of the physical memory and the swap space is the amount of virtual memory available.<br />
<br />
Support for swap is provided by the Linux kernel and user-space utilities from the {{Pkg|util-linux}} package.<br />
<br />
== Swap space ==<br />
<br />
Swap space can take the form of a disk partition or a file. Users may create a swap space during installation or at any later time as desired. Swap space can be used for two purposes, to extend the virtual memory beyond the installed physical memory (RAM), and also for [[Power management/Suspend and hibernate|suspend-to-disk]] support.<br />
<br />
If it is beneficial to extend the virtual memory with swap depends on the amount of installed physical memory. If the amount of physical memory is less than the amount of memory required to run all the desired programs, then it ''may be'' beneficial to enable swap. This avoids [[Wikipedia:Out of memory|out of memory conditions]], where the Linux kernel OOM killer mechanism will automatically attempt to free up memory by killing processes. To increase the amount of virtual memory to the required amount, add the necessary difference (or more) as swap space.<br />
<br />
The biggest drawback of enabling swap is its lower performance, see section [[#Performance]]. Hence, enabling swap is a matter of personal preference: some prefer programs to be killed over enabling swap and others prefer enabling swap and slower system when the physical memory is exhausted.<br />
<br />
{{Note|There is no performance difference between using a swap partition and a contiguous swap file.}}<br />
<br />
To check swap status, use:<br />
<br />
$ swapon --show<br />
<br />
Or to show physical memory as well as swap usage:<br />
<br />
$ free -h<br />
<br />
== Swap partition ==<br />
<br />
{{Accuracy|{{ic|82}} is the swap [[Wikipedia:Partition type|partition type]] on MBR, there is no swap partition autodetection on MBR. / TRIM commands on swap partitions seem to be issued automatically by the Kernel if supported see [https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/newmds-ssdtuning.html Fedora Deployment Guides].|section=Clarify swap discovery}}<br />
<br />
A swap partition can be created with most GNU/Linux [[partitioning tools]]. Swap partitions are typically designated as type {{ic|82}}. Even though it is possible to use any partition type as swap, it is recommended to use type {{ic|82}} in most cases since [[systemd]] will automatically detect it and mount it (see below).<br />
<br />
To set up a partition as Linux swap area, the {{man|8|mkswap}} command is used. For example:<br />
<br />
# mkswap /dev/sd''xy''<br />
<br />
{{Warning|All data on the specified partition will be lost.}}<br />
<br />
To enable the device for paging:<br />
<br />
# swapon /dev/sd''xy''<br />
<br />
To enable this swap partition on boot, add an entry to {{ic|/etc/fstab}}:<br />
<br />
UUID=''device_UUID'' none swap defaults 0 0<br />
<br />
where the {{ic|''device_UUID''}} is the [[UUID]] of the swap space.<br />
<br />
See [[fstab]] for the file syntax.<br />
<br />
{{Note|<br />
* The fstab-entry is optional if the swap partition is located on a device using GPT. See the next subsection.<br />
* If using an SSD with [[TRIM]] support, consider using {{ic|discard}} in the swap line in [[fstab]]. If activating swap manually with ''swapon'', using the {{ic|-d}}/{{ic|--discard}} parameter achieves the same. See {{man|8|swapon}} for details.<br />
}}<br />
<br />
{{Warning|Enabling discard on RAID setups using mdadm will cause system lockup on boot and during runtime, if using swapon.}}<br />
<br />
=== Activation by systemd ===<br />
<br />
[[systemd]] activates swap partitions based on two different mechanisms. Both are executables in {{ic|/usr/lib/systemd/system-generators}}. The generators are run on start-up and create native systemd units for mounts. The first, {{ic|systemd-fstab-generator}}, reads the fstab to generate units, including a unit for swap. The second, {{ic|systemd-gpt-auto-generator}} inspects the root disk to generate units. It operates on GPT disks only, and can identify swap partitions by their type GUID, see [[systemd#GPT partition automounting]] for more information.<br />
<br />
=== Disabling swap ===<br />
<br />
To deactivate specific swap space:<br />
<br />
# swapoff /dev/sd''xy''<br />
<br />
Alternatively use the {{ic|-a}} switch to deactivate all swap space.<br />
<br />
Since swap is managed by systemd, it will be activated again on the next system startup. To disable the automatic activation of detected swap space permanently, run {{ic|systemctl --type swap}} to find the responsible ''.swap'' unit and [[mask]] it.<br />
<br />
== Swap file ==<br />
<br />
As an alternative to creating an entire partition, a swap file offers the ability to vary its size on-the-fly, and is more easily removed altogether. This may be especially desirable if disk space is at a premium (e.g. a modestly-sized SSD).<br />
{{Warning|[[Btrfs]] supports swap file with limitations since Linux kernel version 5.0. See [[Btrfs#Swap file]] for more information.}}<br />
<br />
=== Manually ===<br />
<br />
==== Swap file creation ====<br />
<br />
{{Note|If you use Btrfs, first follow the procedure described in [[Btrfs#Swap file]] to initialize the swap file.}}<br />
<br />
Use [[dd]] to create a swap file the size of your choosing. For example, creating a 512 MiB swap file:<br />
<br />
# dd if=/dev/zero of=/swapfile bs=1M count=512 status=progress<br />
<br />
{{Note|Using ''dd'' to allocate a swap file is the most portable solution, see {{man|8|swapon|Files with holes}} for details.}}<br />
<br />
Set the right permissions (a world-readable swap file is a huge local vulnerability):<br />
<br />
# chmod 600 /swapfile<br />
<br />
After creating the correctly sized file, format it to swap:<br />
<br />
# mkswap /swapfile<br />
<br />
Activate the swap file:<br />
<br />
# swapon /swapfile<br />
<br />
Finally, edit the fstab configuration to add an entry for the swap file:<br />
<br />
{{hc|/etc/fstab|<br />
/swapfile none swap defaults 0 0<br />
}}<br />
<br />
For additional information, see [[fstab#Usage]].<br />
<br />
{{Note|<br />
* The swap file must be specified by its location on the file system, not by its UUID or LABEL.<br />
* When using [[Btrfs]], do not forget to add the created subvolume to the list as well, and remove the {{ic|discard,autodefrag}} and compression options.<br />
}}<br />
<br />
===== Loopback swap files =====<br />
<br />
It is possible to create a swap file on an otherwise unsupported filesystem (e.g., [[Btrfs]]) by mounting the file as a [[Wikipedia:loop device|loopback device]]. After creating a swap file and setting it up for swap usage with {{ic|mkswap}}:<br />
<br />
# swapdev="$(losetup --find "$(readlink -f ./swap)" --show)"<br />
# swapon "${swapdev}"<br />
<br />
Removal of a loopback swap device can be performed with<br />
<br />
# losetup -d "${swapdev}"<br />
<br />
This has the additional advantage that the backing swap file may contain file holes. While swap file fragmentation can degrade performance, file holes may be desirable in certain use cases (SSDs).<br />
<br />
==== Remove swap file ====<br />
<br />
To remove a swap file, it must be turned off first and then can be removed:<br />
<br />
# swapoff /swapfile<br />
# rm -f /swapfile<br />
<br />
Finally remove the relevant entry from {{ic|/etc/fstab}}.<br />
<br />
=== Automated ===<br />
<br />
{{Remove|systemd-swap is deprecated and zram-generator does not create swap files. Both zram and zswap are covered in [[Improving performance#zram or zswap]].}}<br />
<br />
==== zram-generator ====<br />
<br />
The aim of this tool is the creation of zram devices. It is written in Rust and resides in [https://github.com/systemd/zram-generator systemd's GitHub]. It can be installed with the {{Pkg|zram-generator}} package. Configuration is straightforward and explained in the [https://github.com/systemd/zram-generator/blob/main/README.md README].<br />
<br />
==== systemd-swap ====<br />
<br />
{{Note|The author now [https://github.com/Nefelim4ag/systemd-swap#%EF%B8%8F-current-code-quality-and-commit-frequency-is-low-%EF%B8%8F recommends using zram-generator instead], due to low commit frequency and zram covering the needs of most users.}}<br />
<br />
systemd-swap is a script for creating hybrid swap space from zram swaps, swap files and swap partitions. It is not affiliated with the systemd project.<br />
<br />
[[Install]] the {{pkg|systemd-swap}} package. Uncomment and set {{ic|1=swapfc_enabled=1}} in the ''Swap File Chunked'' section of {{ic|/etc/systemd/swap.conf}}. [[Start/enable]] the {{ic|systemd-swap}} service.<br />
<br />
Visit the [https://github.com/Nefelim4ag/systemd-swap authors GitHub] page for more information and setting up the [https://github.com/Nefelim4ag/systemd-swap/blob/master/README.md#about-configuration recommended configuration].<br />
<br />
{{Note|<br />
* If the journal keeps showing the following warning {{ic|systemd-swap[..]: WARN: swapFC: ENOSPC}} and no swap file is being created, you need to uncomment and set {{ic|1=swapfc_force_preallocated=1}} in {{ic|/etc/systemd/swap.conf}}.<br />
* The swap file created by systemd-swap cannot be easily used for [[hibernation]]. See [https://github.com/Nefelim4ag/systemd-swap/issues/85 systemd-swap issue 85].<br />
}}<br />
<br />
== Swap encryption ==<br />
<br />
See [[dm-crypt/Swap encryption]].<br />
<br />
== Performance ==<br />
<br />
Swap operations are usually significantly slower than directly accessing data in RAM. Disabling swap entirely to improve performance can sometimes lead to a degradation, since it decreases the memory available for VFS caches, causing more frequent and costly disk I/O.<br />
<br />
Swap values can be adjusted to help performance:<br />
<br />
=== Swappiness ===<br />
<br />
The ''swappiness'' [[sysctl]] parameter represents the kernel's preference (or avoidance) of swap space. Swappiness can have a value between 0 and 200 (max 100 if Linux < 5.8), the default value is 60. A low value causes the kernel to avoid swapping, a high value causes the kernel to try to use swap space, and a value of 100 means IO cost is assumed to be equal. Using a low value on sufficient memory is known to improve responsiveness on many systems.<br />
<br />
To check the current swappiness value:<br />
<br />
$ sysctl vm.swappiness<br />
<br />
Alternatively, the files {{ic|/sys/fs/cgroup/memory/memory.swappiness}} or {{ic|/proc/sys/vm/swappiness}} can be read in order to obtain the raw integer value.<br />
<br />
{{Note|As {{ic|/proc}} is a lot less organized and is kept only for compatibility purposes, you are encouraged to use {{ic|/sys}} instead.}}<br />
<br />
To temporarily set the swappiness value:<br />
<br />
# sysctl -w vm.swappiness=10<br />
<br />
To set the swappiness value permanently, create a {{man|5|sysctl.d}} configuration file. For example:<br />
<br />
{{hc|/etc/sysctl.d/99-swappiness.conf|2=<br />
vm.swappiness=10<br />
}}<br />
<br />
To test and more on why this may work, take a look at [https://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that this article].<br />
<br />
=== VFS cache pressure ===<br />
<br />
Another ''sysctl'' parameter that affects swap performance is {{ic|vm.vfs_cache_pressure}}, which controls the tendency of the kernel to reclaim the memory which is used for caching of VFS caches, versus pagecache and swap. Increasing this value increases the rate at which VFS caches are reclaimed[https://web.archive.org/web/20171004100853/http://doc.opensuse.org/documentation/leap/tuning/html/book.sle.tuning/cha.tuning.memory.html#cha.tuning.memory.vm.reclaim]. For more information, see the [https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html Linux kernel documentation].<br />
<br />
=== Priority ===<br />
<br />
If you have more than one swap file or swap partition you should consider assigning a priority value (0 to 32767) for each swap area. The system will use swap areas of higher priority before using swap areas of lower priority. For example, if you have a faster disk ({{ic|/dev/sda}}) and a slower disk ({{ic|/dev/sdb}}), assign a higher priority to the swap area located on the fastest device. Priorities can be assigned in [[fstab]] via the {{ic|pri}} parameter:<br />
<br />
/dev/sda1 none swap defaults,pri=100 0 0<br />
/dev/sdb2 none swap defaults,pri=10 0 0<br />
<br />
Or via the {{ic|--priority}} parameter of ''swapon'':<br />
<br />
# swapon --priority 100 /dev/sda1<br />
<br />
If two or more areas have the same priority, and it is the highest priority available, pages are allocated on a round-robin basis between them.<br />
<br />
=== Using zswap or zram ===<br />
<br />
[[Zswap]] is a Linux kernel feature providing a compressed write-back cache for swapped pages. This increases the performance and decreases the IO-Operations. [[ZRAM]] creates a virtual compressed Swap-file in memory as alternative to a swapfile on disk.<br />
<br />
=== Striping ===<br />
<br />
There is no necessity to use [[RAID]] for swap performance reasons. The kernel itself can stripe swapping on several devices, if you just give them the same priority in the {{ic|/etc/fstab}} file. Refer to [https://unthought.net/Software-RAID.HOWTO/Software-RAID.HOWTO-2.html#ss2.3 The Software-RAID HOWTO] for details.</div>Ndthttps://wiki.archlinux.org/index.php?title=Swap&diff=710562Swap2022-01-16T19:25:10Z<p>Ndt: /* Swap file */ add description of loopback mounted swap files</p>
<hr />
<div>[[Category:File systems]]<br />
[[de:Swap]]<br />
[[es:Swap]]<br />
[[fr:Swap]]<br />
[[hu:Swap]]<br />
[[it:Swap]]<br />
[[ja:スワップ]]<br />
[[pt:Swap]]<br />
[[ru:Swap]]<br />
[[zh-hans:Swap]]<br />
{{Related articles start}}<br />
{{Related|fstab}}<br />
{{Related|Power management/Suspend and hibernate#Hibernation}}<br />
{{Related|Zswap}}<br />
{{Related|Swap on video ram}}<br />
{{Related|ZFS#Swap volume}}<br />
{{Related|dm-crypt/Swap encryption}}<br />
{{Related articles end}}<br />
This page provides an introduction to [[Wikipedia:Paging|swap space and paging]] on GNU/Linux. It covers creation and activation of swap partitions and swap files.<br />
<br />
From [https://www.linux.com/news/all-about-linux-swap-space/ All about Linux swap space]:<br />
<br />
:Linux divides its physical RAM (random access memory) into chunks of memory called pages. Swapping is the process whereby a page of memory is copied to the preconfigured space on the hard disk, called swap space, to free up that page of memory. The combined sizes of the physical memory and the swap space is the amount of virtual memory available.<br />
<br />
Support for swap is provided by the Linux kernel and user-space utilities from the {{Pkg|util-linux}} package.<br />
<br />
== Swap space ==<br />
<br />
Swap space can take the form of a disk partition or a file. Users may create a swap space during installation or at any later time as desired. Swap space can be used for two purposes, to extend the virtual memory beyond the installed physical memory (RAM), and also for [[Power management/Suspend and hibernate|suspend-to-disk]] support.<br />
<br />
If it is beneficial to extend the virtual memory with swap depends on the amount of installed physical memory. If the amount of physical memory is less than the amount of memory required to run all the desired programs, then it ''may be'' beneficial to enable swap. This avoids [[Wikipedia:Out of memory|out of memory conditions]], where the Linux kernel OOM killer mechanism will automatically attempt to free up memory by killing processes. To increase the amount of virtual memory to the required amount, add the necessary difference (or more) as swap space.<br />
<br />
The biggest drawback of enabling swap is its lower performance, see section [[#Performance]]. Hence, enabling swap is a matter of personal preference: some prefer programs to be killed over enabling swap and others prefer enabling swap and slower system when the physical memory is exhausted.<br />
<br />
{{Note|There is no performance difference between using a swap partition and a contiguous swap file.}}<br />
<br />
To check swap status, use:<br />
<br />
$ swapon --show<br />
<br />
Or to show physical memory as well as swap usage:<br />
<br />
$ free -h<br />
<br />
== Swap partition ==<br />
<br />
{{Accuracy|{{ic|82}} is the swap [[Wikipedia:Partition type|partition type]] on MBR, there is no swap partition autodetection on MBR. / TRIM commands on swap partitions seem to be issued automatically by the Kernel if supported see [https://docs.fedoraproject.org/en-US/Fedora/14/html/Storage_Administration_Guide/newmds-ssdtuning.html Fedora Deployment Guides].|section=Clarify swap discovery}}<br />
<br />
A swap partition can be created with most GNU/Linux [[partitioning tools]]. Swap partitions are typically designated as type {{ic|82}}. Even though it is possible to use any partition type as swap, it is recommended to use type {{ic|82}} in most cases since [[systemd]] will automatically detect it and mount it (see below).<br />
<br />
To set up a partition as Linux swap area, the {{man|8|mkswap}} command is used. For example:<br />
<br />
# mkswap /dev/sd''xy''<br />
<br />
{{Warning|All data on the specified partition will be lost.}}<br />
<br />
To enable the device for paging:<br />
<br />
# swapon /dev/sd''xy''<br />
<br />
To enable this swap partition on boot, add an entry to {{ic|/etc/fstab}}:<br />
<br />
UUID=''device_UUID'' none swap defaults 0 0<br />
<br />
where the {{ic|''device_UUID''}} is the [[UUID]] of the swap space.<br />
<br />
See [[fstab]] for the file syntax.<br />
<br />
{{Note|<br />
* The fstab-entry is optional if the swap partition is located on a device using GPT. See the next subsection.<br />
* If using an SSD with [[TRIM]] support, consider using {{ic|discard}} in the swap line in [[fstab]]. If activating swap manually with ''swapon'', using the {{ic|-d}}/{{ic|--discard}} parameter achieves the same. See {{man|8|swapon}} for details.<br />
}}<br />
<br />
{{Warning|Enabling discard on RAID setups using mdadm will cause system lockup on boot and during runtime, if using swapon.}}<br />
<br />
=== Activation by systemd ===<br />
<br />
[[systemd]] activates swap partitions based on two different mechanisms. Both are executables in {{ic|/usr/lib/systemd/system-generators}}. The generators are run on start-up and create native systemd units for mounts. The first, {{ic|systemd-fstab-generator}}, reads the fstab to generate units, including a unit for swap. The second, {{ic|systemd-gpt-auto-generator}} inspects the root disk to generate units. It operates on GPT disks only, and can identify swap partitions by their type GUID, see [[systemd#GPT partition automounting]] for more information.<br />
<br />
=== Disabling swap ===<br />
<br />
To deactivate specific swap space:<br />
<br />
# swapoff /dev/sd''xy''<br />
<br />
Alternatively use the {{ic|-a}} switch to deactivate all swap space.<br />
<br />
Since swap is managed by systemd, it will be activated again on the next system startup. To disable the automatic activation of detected swap space permanently, run {{ic|systemctl --type swap}} to find the responsible ''.swap'' unit and [[mask]] it.<br />
<br />
== Swap file ==<br />
<br />
As an alternative to creating an entire partition, a swap file offers the ability to vary its size on-the-fly, and is more easily removed altogether. This may be especially desirable if disk space is at a premium (e.g. a modestly-sized SSD).<br />
{{Warning|[[Btrfs]] supports swap file with limitations since Linux kernel version 5.0. See [[Btrfs#Swap file]] for more information.}}<br />
<br />
=== Manually ===<br />
<br />
==== Swap file creation ====<br />
<br />
{{Note|If you use Btrfs, first follow the procedure described in [[Btrfs#Swap file]] to initialize the swap file.}}<br />
<br />
Use [[dd]] to create a swap file the size of your choosing. For example, creating a 512 MiB swap file:<br />
<br />
# dd if=/dev/zero of=/swapfile bs=1M count=512 status=progress<br />
<br />
{{Note|Using ''dd'' to allocate a swap file is the most portable solution, see {{man|8|swapon|Files with holes}} for details.}}<br />
<br />
Set the right permissions (a world-readable swap file is a huge local vulnerability):<br />
<br />
# chmod 600 /swapfile<br />
<br />
After creating the correctly sized file, format it to swap:<br />
<br />
# mkswap /swapfile<br />
<br />
Activate the swap file:<br />
<br />
# swapon /swapfile<br />
<br />
Finally, edit the fstab configuration to add an entry for the swap file:<br />
<br />
{{hc|/etc/fstab|<br />
/swapfile none swap defaults 0 0<br />
}}<br />
<br />
For additional information, see [[fstab#Usage]].<br />
<br />
{{Note|<br />
* The swap file must be specified by its location on the file system, not by its UUID or LABEL.<br />
* When using [[Btrfs]], do not forget to add the created subvolume to the list as well, and remove the {{ic|discard,autodefrag}} and compression options.<br />
}}<br />
<br />
===== Loopback swap files =====<br />
<br />
It is possible to create a swap file on an otherwise unsupported filesystem (e.g., [[Btrfs]]) by mounting the file as a [[Wikipedia:loop device|loopback device]]. After creating a swap file and setting it up for swap usage with {{ic|mkswap}}:<br />
<br />
# swapdev="$(losetup --find "$(readlink -f ./swap)" --show)"<br />
# swapon "${swapdev}"<br />
<br />
Removal of a loopback swap file can be performed with<br />
<br />
# losetup -d "${swapdev}"<br />
<br />
This has the additional advantage that the backing swap file may contain file holes. While swap file fragmentation can degrade performance, file holes may be desirable in certain use cases (SSDs).<br />
<br />
==== Remove swap file ====<br />
<br />
To remove a swap file, it must be turned off first and then can be removed:<br />
<br />
# swapoff /swapfile<br />
# rm -f /swapfile<br />
<br />
Finally remove the relevant entry from {{ic|/etc/fstab}}.<br />
<br />
=== Automated ===<br />
<br />
{{Remove|systemd-swap is deprecated and zram-generator does not create swap files. Both zram and zswap are covered in [[Improving performance#zram or zswap]].}}<br />
<br />
==== zram-generator ====<br />
<br />
The aim of this tool is the creation of zram devices. It is written in Rust and resides in [https://github.com/systemd/zram-generator systemd's GitHub]. It can be installed with the {{Pkg|zram-generator}} package. Configuration is straightforward and explained in the [https://github.com/systemd/zram-generator/blob/main/README.md README].<br />
<br />
==== systemd-swap ====<br />
<br />
{{Note|The author now [https://github.com/Nefelim4ag/systemd-swap#%EF%B8%8F-current-code-quality-and-commit-frequency-is-low-%EF%B8%8F recommends using zram-generator instead], due to low commit frequency and zram covering the needs of most users.}}<br />
<br />
systemd-swap is a script for creating hybrid swap space from zram swaps, swap files and swap partitions. It is not affiliated with the systemd project.<br />
<br />
[[Install]] the {{pkg|systemd-swap}} package. Uncomment and set {{ic|1=swapfc_enabled=1}} in the ''Swap File Chunked'' section of {{ic|/etc/systemd/swap.conf}}. [[Start/enable]] the {{ic|systemd-swap}} service.<br />
<br />
Visit the [https://github.com/Nefelim4ag/systemd-swap authors GitHub] page for more information and setting up the [https://github.com/Nefelim4ag/systemd-swap/blob/master/README.md#about-configuration recommended configuration].<br />
<br />
{{Note|<br />
* If the journal keeps showing the following warning {{ic|systemd-swap[..]: WARN: swapFC: ENOSPC}} and no swap file is being created, you need to uncomment and set {{ic|1=swapfc_force_preallocated=1}} in {{ic|/etc/systemd/swap.conf}}.<br />
* The swap file created by systemd-swap cannot be easily used for [[hibernation]]. See [https://github.com/Nefelim4ag/systemd-swap/issues/85 systemd-swap issue 85].<br />
}}<br />
<br />
== Swap encryption ==<br />
<br />
See [[dm-crypt/Swap encryption]].<br />
<br />
== Performance ==<br />
<br />
Swap operations are usually significantly slower than directly accessing data in RAM. Disabling swap entirely to improve performance can sometimes lead to a degradation, since it decreases the memory available for VFS caches, causing more frequent and costly disk I/O.<br />
<br />
Swap values can be adjusted to help performance:<br />
<br />
=== Swappiness ===<br />
<br />
The ''swappiness'' [[sysctl]] parameter represents the kernel's preference (or avoidance) of swap space. Swappiness can have a value between 0 and 200 (max 100 if Linux < 5.8), the default value is 60. A low value causes the kernel to avoid swapping, a high value causes the kernel to try to use swap space, and a value of 100 means IO cost is assumed to be equal. Using a low value on sufficient memory is known to improve responsiveness on many systems.<br />
<br />
To check the current swappiness value:<br />
<br />
$ sysctl vm.swappiness<br />
<br />
Alternatively, the files {{ic|/sys/fs/cgroup/memory/memory.swappiness}} or {{ic|/proc/sys/vm/swappiness}} can be read in order to obtain the raw integer value.<br />
<br />
{{Note|As {{ic|/proc}} is a lot less organized and is kept only for compatibility purposes, you are encouraged to use {{ic|/sys}} instead.}}<br />
<br />
To temporarily set the swappiness value:<br />
<br />
# sysctl -w vm.swappiness=10<br />
<br />
To set the swappiness value permanently, create a {{man|5|sysctl.d}} configuration file. For example:<br />
<br />
{{hc|/etc/sysctl.d/99-swappiness.conf|2=<br />
vm.swappiness=10<br />
}}<br />
<br />
To test and more on why this may work, take a look at [https://rudd-o.com/en/linux-and-free-software/tales-from-responsivenessland-why-linux-feels-slow-and-how-to-fix-that this article].<br />
<br />
=== VFS cache pressure ===<br />
<br />
Another ''sysctl'' parameter that affects swap performance is {{ic|vm.vfs_cache_pressure}}, which controls the tendency of the kernel to reclaim the memory which is used for caching of VFS caches, versus pagecache and swap. Increasing this value increases the rate at which VFS caches are reclaimed[https://web.archive.org/web/20171004100853/http://doc.opensuse.org/documentation/leap/tuning/html/book.sle.tuning/cha.tuning.memory.html#cha.tuning.memory.vm.reclaim]. For more information, see the [https://www.kernel.org/doc/html/latest/admin-guide/sysctl/vm.html Linux kernel documentation].<br />
<br />
=== Priority ===<br />
<br />
If you have more than one swap file or swap partition you should consider assigning a priority value (0 to 32767) for each swap area. The system will use swap areas of higher priority before using swap areas of lower priority. For example, if you have a faster disk ({{ic|/dev/sda}}) and a slower disk ({{ic|/dev/sdb}}), assign a higher priority to the swap area located on the fastest device. Priorities can be assigned in [[fstab]] via the {{ic|pri}} parameter:<br />
<br />
/dev/sda1 none swap defaults,pri=100 0 0<br />
/dev/sdb2 none swap defaults,pri=10 0 0<br />
<br />
Or via the {{ic|--priority}} parameter of ''swapon'':<br />
<br />
# swapon --priority 100 /dev/sda1<br />
<br />
If two or more areas have the same priority, and it is the highest priority available, pages are allocated on a round-robin basis between them.<br />
<br />
=== Using zswap or zram ===<br />
<br />
[[Zswap]] is a Linux kernel feature providing a compressed write-back cache for swapped pages. This increases the performance and decreases the IO-Operations. [[ZRAM]] creates a virtual compressed Swap-file in memory as alternative to a swapfile on disk.<br />
<br />
=== Striping ===<br />
<br />
There is no necessity to use [[RAID]] for swap performance reasons. The kernel itself can stripe swapping on several devices, if you just give them the same priority in the {{ic|/etc/fstab}} file. Refer to [https://unthought.net/Software-RAID.HOWTO/Software-RAID.HOWTO-2.html#ss2.3 The Software-RAID HOWTO] for details.</div>Ndthttps://wiki.archlinux.org/index.php?title=Security&diff=709337Security2022-01-10T15:04:55Z<p>Ndt: /* Run Xorg rootless */ Wayland is probably stable enough to recommend as a first choice now</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[de:Sicherheit]]<br />
[[es:Security]]<br />
[[fa:امنیت]]<br />
[[hu:Security]]<br />
[[ja:セキュリティ]]<br />
[[pt:Security]]<br />
[[ru:Security]]<br />
[[zh-hans:Security]]<br />
{{Related articles start}}<br />
{{Related|Arch Security Team}}<br />
{{Related|General recommendations}}<br />
{{Related|PAM}}<br />
{{Related|Capabilities}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|Arch package guidelines/Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for [[Wikipedia:Hardening (computing)|hardening]] an Arch Linux system.<br />
<br />
== Concepts ==<br />
<br />
* It ''is'' possible to tighten security to the point where the system is unusable. Security and convenience must be balanced. The trick is to create a secure ''and'' useful system.<br />
* The biggest threat is, and will always be, the user.<br />
* The [[Wikipedia:Principle of least privilege|principle of least privilege]]: Each part of a system should only be able to access what is strictly required, and nothing more.<br />
* Defense in depth: Security works better in independent layers. When one layer is breached, another should stop the attack.<br />
* Be a little paranoid. And be suspicious. If anything sounds too good to be true, it probably is!<br />
* You can never make a system 100% secure unless you unplug the machine from all networks, turn it off, lock it in a safe, smother it in concrete and never use it.<br />
* Prepare for failure. Create a plan ahead of time to follow when your security is broken.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure Linux system. They secure your [[Users and groups|user accounts]], [[Data-at-rest encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
Passwords must be complex enough to not be easily guessed from e.g. personal information, or [[Wikipedia:Password cracking|cracked]] using methods like social engineering or brute-force attacks. The tenets of strong passwords are based on ''length'' and ''randomness''. In cryptography the quality of a password is referred to as its [[Wikipedia:Entropic security|entropic security]]. <br />
<br />
Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}}), as modern dictionary attacks can easily work with these<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Common phrases or strings of dictionary words (e.g. {{ic|photocopyhauntbranchexpose}}) including with character substitution (e.g. {{ic|Ph0toc0pyh4uN7br@nch3xp*se}}) <br />
* Any of the [[wikipedia:List_of_the_most_common_passwords|most common passwords]]<br />
<br />
The best choice for a password is something long (the longer, the better) and generated from a random source. It is important to use a long password. [https://www.theregister.com/2019/02/14/password_length Weak hash algorithms allow an 8-character password hash to be compromised in just a few hours.]<br />
<br />
Tools like {{Pkg|pwgen}} or {{AUR|apg}} can generate random passwords. However, these passwords can be difficult to memorize. One memorization technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
One technique for memorizing a password is to use a mnemonic phrase, where each word in the phrase reminds you of the next character in the password.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]). <br />
<br />
Another effective technique can be to write randomly generated passwords down and store them in a ''safe'' place, such as in a wallet, purse or document safe. Most people do a generally good job of protecting their physical valuables from attack, and it is easier for most people to understand physical security best practices compared to digital security practices. [https://www.schneier.com/news/archives/2010/11/bruce_schneier_write.html Bruce Schneier has endorsed this technique].<br />
<br />
It is also very effective to combine the mnemonic and random technique by saving long randomly generated passwords with a [[password manager]], which will be in turn accessed with a memorable "master password" that must be used only for that purpose. The master password must be memorized and never saved. This requires the password manager to be installed on a system to easily access the password (which could be seen as an inconvenience or a security feature, depending on the situation). Some password managers also have smartphone apps which can be used to display passwords for manual entry on systems without that password manager installed. Note that a password manager introduces a single point of failure if you ever forget the master password.<br />
<br />
It can be effective to use a memorable long series of unrelated words as a password. The theory is that if a sufficiently long phrase is used, the gained entropy from the password's length can counter the lost entropy from the use of dictionary words. This [https://xkcd.com/936/ xkcd comic] demonstrates the entropy tradeoff of this method, taking into account the limited set of possible words for each word in the passphrase. However, password crackers have caught on to this trick and will generate wordlists containing billions of permutations and variants of dictionary words, reducing the effective entropy of the password from the huge character count times the possible characters to (set of words to choose from)^(number of words chosen), because the attacker knows the passphrase generation method. If the set of words you choose from is large (multiple thousand words) and you choose 5-7 or even more random words from it, this method still provides great entropy, even assuming the attacker knows the set of possible words chosen from and the number of words chosen. See e.g. [https://www.rempe.us/diceware/ Diceware] for more.<br />
<br />
See Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords], [https://www.iusmentis.com/security/passphrasefaq/ The passphrase FAQ] or [[Wikipedia:Password strength]] for some additional background.<br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Keylogger|keyloggers]] (software and hardware), screen loggers, [[Wikipedia:Social engineering (security)|social engineering]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}). Note that password managers that are implemented as browser extensions may be vulnerable to [https://www.spookjs.com side channel attacks]. These can be mitigated by using password managers that run as separate applications.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective [https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
Another aspect of the strength of the passphrase is that it must not be easily recoverable from other places.<br />
<br />
If you use the same passphrase for disk encryption as you use for your login password (useful e.g. to auto-mount the encrypted partition or folder on login), make sure that {{ic|/etc/shadow}} ends up on an encrypted partition or/and uses a strong key derivation function (i.e. yescrypt/bcrypt/argon2 or sha512 with PBKDF2, but not md5 or low iterations in PBKDF2) for the stored password hash (see [[SHA password hashes]] for more information).<br />
<br />
If you are backing up your password database, make sure that each copy is not stored behind any other passphrase which in turn is stored in it, e.g. an encrypted drive or an authenticated remote storage service, or you will not be able to access it in case of need; a useful trick is to protect the drives or accounts where the database is backed up using a simple cryptographic hash of the master password. Maintain a list of all the backup locations: if one day you fear that the master passphrase has been compromised you will have to change it immediately on all the database backups and the locations protected with keys derived from the master password.<br />
<br />
Version-controlling the database in a secure way can be very complicated: if you choose to do it, you must have a way to update the master password of all the database versions. It may not always be immediately clear when the master password is leaked: to reduce the risk of somebody else discovering your password before you realize that it leaked, you may choose to change it on a periodical basis. If you fear that you have lost control over a copy of the database, you will need to change all the passwords contained in it within the time that it may take to brute-force the master password, according to its entropy.<br />
<br />
=== Password hashes ===<br />
<br />
{{Expansion|Mention [[Wikipedia:Key derivation function|key derivation functions]], in particular argon2, bcrypt, scrypt and PBKDF2, how to use them, advantages and disadvantages, especially regarding custom-hardware-based brute-force attacks.|section=Removal of incorrect warning}}<br />
<br />
By default, Arch stores the hashed user passwords in the root-only-readable {{ic|/etc/shadow}} file, separated from the other user parameters stored in the world-readable {{ic|/etc/passwd}} file, see [[Users and groups#User database]]. See also [[#Restricting root]].<br />
<br />
Passwords are set with the '''passwd''' command, which [[Wikipedia:Key stretching|stretches]] them with the [[Wikipedia:Crypt (C)|crypt]] function and then saves them in {{ic|/etc/shadow}}. See also [[SHA password hashes]]. The passwords are also [[Wikipedia:Salt (cryptography)|salted]] in order to defend them against [[Wikipedia:Rainbow table|rainbow table]] attacks.<br />
<br />
See also [https://www.slashroot.in/how-are-passwords-stored-linux-understanding-hashing-shadow-utils How are passwords stored in Linux (Understanding hashing with shadow utils)]{{Dead link|2021|11|19|status=SSL error}}.<br />
<br />
=== Enforcing strong passwords with pam_pwquality ===<br />
<br />
''pam_pwquality'' provides protection against [[Wikipedia:Dictionary attack|Dictionary attacks]] and helps configure a password policy that can be enforced throughout the system. It is based on ''pam_cracklib'', so it is backwards compatible with its options.<br />
<br />
[[Install]] the {{Pkg|libpwquality}} package.<br />
<br />
{{Warning|The ''root'' account is not affected by this policy by default.}}<br />
<br />
{{Note|<br />
* You can use the ''root'' account to set a password for a user that bypasses the desired/configured policy. This is useful when setting temporary passwords.<br />
* Current security guidelines around passwords, e.g. from NIST, but also from others, do not recommend enforcing special characters, since they often only lead to predictable alterations.<br />
}}<br />
<br />
If for example you want to enforce this policy:<br />
<br />
* prompt 2 times for password in case of an error (retry option)<br />
* 10 characters minimum length (minlen option)<br />
* at least 6 characters should be different from old password when entering a new one (difok option)<br />
* at least 1 digit (dcredit option)<br />
* at least 1 uppercase (ucredit option)<br />
* at least 1 lowercase (lcredit option)<br />
* at least 1 other character (ocredit option)<br />
* cannot contain the words "myservice" and "mydomain"<br />
* enforce the policy for root<br />
<br />
Edit the {{ic|/etc/pam.d/passwd}} file to read as:<br />
<br />
{{bc|1=<br />
#%PAM-1.0<br />
password required pam_pwquality.so retry=2 minlen=10 difok=6 dcredit=-1 ucredit=-1 ocredit=-1 lcredit=-1 [badwords=myservice mydomain] enforce_for_root<br />
password required pam_unix.so use_authtok sha512 shadow<br />
}}<br />
<br />
The {{ic|password required pam_unix.so use_authtok}} instructs the ''pam_unix'' module to not prompt for a password but rather to use the one provided by ''pam_pwquality''.<br />
<br />
You can refer to the {{man|8|pam_pwquality}} and {{man|8|pam_unix}} man pages for more information.<br />
<br />
== CPU ==<br />
<br />
=== Microcode ===<br />
<br />
See [[microcode]] for information on how to install important security updates for your CPU's microcode.<br />
<br />
=== Hardware vulnerabilities ===<br />
<br />
Some CPUs contain hardware vulnerabilities. See the [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/ kernel documentation on hardware vulnerabilities] for a list of these vulnerabilities, as well as mitigation selection guides to help customize the kernel to mitigate these vulnerabilities for specific usage scenarios.<br />
<br />
To check if you are affected by a known vulnerability, run the following:<br />
<br />
$ grep -r . /sys/devices/system/cpu/vulnerabilities/<br />
<br />
In most cases, updating the kernel and microcode will mitigate vulnerabilities.<br />
<br />
==== Simultaneous multithreading (hyper-threading) ====<br />
<br />
[[Wikipedia:Simultaneous multithreading|Simultaneous multithreading]] (SMT), also called hyper-threading on Intel CPUs, is a hardware feature that may be a source of [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html L1 Terminal Fault] and [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html Microarchitectural Data Sampling] vulnerabilities. The Linux kernel and microcode updates contain mitigations for known vulnerabilities, but [https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/l1tf.html#virtualization-with-untrusted-guests disabling SMT may still be required on certain CPUs if untrusted virtualization guests are present].<br />
<br />
SMT can often be disabled in your system's firmware. Consult your motherboard or system documentation for more information. You can also disable SMT in the kernel by adding the following [[kernel parameters]]:<br />
<br />
l1tf=full,force mds=full,nosmt mitigations=auto,nosmt nosmt=force<br />
<br />
== Memory ==<br />
<br />
=== Hardened malloc ===<br />
<br />
[https://github.com/GrapheneOS/hardened_malloc hardened_malloc] ({{AUR|hardened_malloc}}, {{AUR|hardened-malloc-git}}) is a hardened replacement for [[Wikipedia:GNU C Library|glibc]]'s malloc(). The project was originally developed for integration into Android's [[Wikipedia:Bionic (software)|Bionic]] and [[Wikipedia:musl|musl]] by Daniel Micay, of [[Wikipedia:GrapheneOS|GrapheneOS]], but he has also built in support for standard Linux distributions on the x86_64 architecture.<br />
<br />
While hardened_malloc is not yet integrated into glibc (assistance and pull requests welcome) it can be used easily with LD_PRELOAD. In testing so far, it only causes issues with a handful of applications if enabled globally in {{ic|/etc/ld.so.preload}}. For example, {{ic|man}} fails to work properly unless its {{ic|seccomp}} environment flag is disabled due to not having {{ic|getrandom}} in the standard whitelist, although this can be easily fixed by rebuilding it with the system call added. Since hardened_malloc has a performance cost, you may want to decide which implementation to use on a case-by-case basis based on attack surface and performance needs.<br />
<br />
To try it out in a standalone manner, use the hardened-malloc-preload wrapper script, or manually start an application with the proper preload value:<br />
<br />
LD_PRELOAD="/usr/lib/libhardened_malloc.so" /usr/bin/firefox<br />
<br />
Proper usage with [[Firejail]] can be found on its wiki page, and some configurable build options for hardened_malloc can be found on the github repo.<br />
<br />
== Storage ==<br />
<br />
=== Data-at-rest encryption ===<br />
<br />
[[Data-at-rest encryption]], preferably full-disk encryption with a [[#Passwords|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full-disk encryption when only certain parts of the system need be secure.<br />
<br />
You may also [[Trusted Platform Module#Data-at-rest encryption with LUKS|encrypt a drive with the key stored in a TPM]], although it has had [https://tpm.fail vulnerabilites in the past] and the key can be extracted by a [https://pulsesecurity.co.nz/articles/TPM-sniffing bus sniffing attack].<br />
<br />
==== File encryption ====<br />
<br />
{{Merge|Data-at-rest encryption|File encryption is still a type of encryption at rest (as opposed to in use or transit).}}<br />
<br />
While data-at-rest encryption is useful at protecting data on physical media, it can not be used to protect data on a remote system that you can not control (such as on cloud storages). In that case, file encryption will be useful.<br />
<br />
These are some methods to encrypt files:<br />
* Some [[Archiving_and_compression|archiving and compressing]] tools also provide encryption. Some examples are {{Pkg|p7zip}} ({{ic|-p}} flag), {{Pkg|zip}} ({{ic|-e}} flag).<br />
* [[GnuPG]] can be used to [[GnuPG#Encrypt_and_decrypt|encrypt files]].<br />
* {{Pkg|age}} is a simple and easy to use file encryption tool. It also supports multiple recipients and encryption using SSH keys, which is useful for secure file sharing.<br />
<br />
=== File systems ===<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
File systems containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like [[Disk quota|quotas]]), and some [[file systems]] include related features themselves (Btrfs has quotas on subvolumes).<br />
<br />
==== Mount options ====<br />
<br />
Following the principle of least privilege, file systems should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
Relevant mount options are:<br />
<br />
* {{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
* {{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
* {{ic|noexec}}: Do not allow direct execution of any binaries on the mounted file system.<br />
** Setting {{ic|noexec}} on {{ic|/home}} disallows executable scripts and breaks [[Wine]]*, [[Steam]], PyCharm, etc.<br />
** Some packages (building {{Pkg|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
{{Note|Wine does not need the {{ic|exec}} flag for opening Windows executables. It is only needed when Wine itself is installed in {{ic|/home}}.}}<br />
<br />
File systems used for data should always be mounted with {{ic|nodev}}, {{ic|nosuid}} and {{ic|noexec}}.<br />
<br />
Potential file system mounts to consider:<br />
<br />
* {{ic|/var}}<br />
* {{ic|/home}}<br />
* {{ic|/dev/shm}}<br />
* {{ic|/tmp}}<br />
* {{ic|/boot}}<br />
<br />
=== File access permissions ===<br />
<br />
The default [[file permissions]] allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the {{ic|http}} or {{ic|nobody}} users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] {{ic|0022}} can be changed to improve security for newly created files. The [https://apps.nsa.gov/iaarchive/library/ia-guidance/security-configuration/operating-systems/guide-to-the-secure-configuration-of-red-hat-enterprise.cfm NSA RHEL5 Security Guide] suggests a umask of {{ic|0077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Set the mask value]].<br />
<br />
=== Backups ===<br />
<br />
{{Merge|System backup|There is a dedicated page for system backups.}}<br />
<br />
Regularly create backups of important data. Regularly test the integrity of the backups. Regularly test that the backups can be restored.<br />
<br />
Make sure that at least one copy of the data is stored offline, i.e. not connected to the system under threat in any way. [[Wikipedia:Ransomware|Ransomware]] and other destructive attacks may also attack any connected backup systems.<br />
<br />
== User setup ==<br />
<br />
=== Do not use the root account for daily use ===<br />
<br />
Following the principle of least privilege, do not use the root user for daily use. Create a non-privileged user account for each person using the system. Use [[sudo]] as necessary for temporary privileged access.<br />
<br />
=== Enforce a delay after a failed login attempt ===<br />
<br />
Add the following line to {{ic|/etc/pam.d/system-login}} to add a delay of at least 4 seconds between failed login attempts:<br />
<br />
{{hc|/etc/pam.d/system-login|2=<br />
auth optional pam_faildelay.so delay=4000000<br />
}}<br />
<br />
{{ic|4000000}} is the time in microseconds to delay.<br />
<br />
=== Lock out user after three failed login attempts ===<br />
<br />
As of {{Pkg|pambase}} 20200721.1-2, {{ic|pam_faillock.so}} is enabled by default to lock out users for 10 minutes after 3 failed login attempts in a 15 minute period (see {{Bug|67644}}). The lockout only applies to password authentication (e.g. login and ''sudo''), public key authentication over SSH is still accepted. To prevent complete denial-of-service, this lockout is disabled on root.<br />
<br />
To unlock a user, do:<br />
<br />
$ faillock --reset --user ''username''<br />
<br />
By default, the lock mechanism is a file per-user located at {{ic|/run/faillock/}}. Deleting or emptying the file unlocks that user—the directory is owned by root, but the file is owned by the user, so the {{ic|faillock}} command only empties the file, therefore does not require root.<br />
<br />
The module {{ic|pam_faillock.so}} can be configured with the file {{ic|1=/etc/security/faillock.conf}}. The lockout parameters:<br />
<br />
* {{ic|unlock_time}} — the lockout time (in seconds, default 10 minutes).<br />
* {{ic|fail_interval}} — the time in which failed logins can cause a lockout (in seconds, default 15 minutes).<br />
* {{ic|deny}} — the number of failed logins before lockout (default 3).<br />
<br />
{{Note|{{ic|1=deny = 0}} will disable the lockout.}}<br />
<br />
No restart is required for changes to take effect. See {{man|5|faillock.conf}} for further configuration options, such as enabling lockout for the root account, disabling for centralized login (e.g. LDAP), etc.<br />
<br />
=== Limit amount of processes ===<br />
<br />
On systems with many, or untrusted users, it is important to limit the number of processes each can run at once, therefore preventing [[Wikipedia:Fork bomb|fork bombs]] and other denial of service attacks. {{ic|/etc/security/limits.conf}} determines how many processes each user, or group can have open, and is empty (except for useful comments) by default. Adding the following lines to this file will limit all users to 100 active processes, unless they use the {{ic|prlimit}} command to explicitly raise their maximum to 200 for that session. These values can be changed according to the appropriate number of processes a user should have running, or the hardware of the box you are administrating. <br />
<br />
* soft nproc 100<br />
* hard nproc 200<br />
<br />
The current number of threads for each user can be found with {{ic|ps --no-headers -Leo user {{!}} sort {{!}} uniq --count}}. This may help with determining appropriate values for the limits.<br />
<br />
=== Use Wayland ===<br />
<br />
Prefer using [[Wayland]] over [[Xorg]]. Xorg's design predates modern security practices and is [https://security.stackexchange.com/questions/4641/why-are-people-saying-that-the-x-window-system-is-not-secure/4646#4646 considered insecure] by many. For example, Xorg applications may record keystrokes while inactive.<br />
<br />
If you must run Xorg, it is recommended to [[Xorg#Rootless_Xorg|avoid running it as root]]. Within Wayland, the XWayland compatibility layer will automatically use rootless Xorg.<br />
<br />
== Restricting root ==<br />
<br />
The root user is, by definition, the most powerful user on a system. It is also difficult to audit the root user account. It is therefore important to restrict usage of the root user account as much as possible. There are a number of ways to keep the power of the root user while limiting its ability to cause harm.<br />
<br />
=== Use sudo instead of su ===<br />
<br />
{{Merge|sudo|There is a dedicated article.}}<br />
<br />
Using [[sudo]] for privileged access is preferable to [[su]] for a number of reasons.<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
# visudo<br />
<br />
{{hc|/etc/sudoers|2=<br />
alice ALL = NOPASSWD: /path/to/program<br />
}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use restricted version of {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|2=<br />
Defaults editor=/usr/bin/rnano<br />
}}<br />
<br />
Exporting {{ic|1=EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
==== Editing files using sudo ====<br />
<br />
See [[Sudo#Editing files]]. Alternatively, you can use an editor like {{ic|rvim}} or {{ic|rnano}} which has restricted capabilities in order to be safe to run as root.<br />
<br />
=== Restricting root login ===<br />
<br />
Once [[sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability. To disable root, but still allowing to use [[sudo]], you can use {{ic|passwd --lock root}}.<br />
<br />
==== Allow only certain users ====<br />
<br />
The [[PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using [[su]]. See [[su#su and wheel]].<br />
<br />
==== Denying SSH login ====<br />
<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[OpenSSH#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==== Specify acceptable login combinations with access.conf ====<br />
<br />
When someone attempts to log in with [[PAM]], {{ic|/etc/security/access.conf}} is checked for the first combination that matches their login properties. Their attempt then fails or succeeds based on the rule for that combination. <br />
<br />
+:root:LOCAL<br />
-:root:ALL<br />
<br />
Rules can be set for specific groups and users. In this example, the user archie is allowed to login locally, as are all users in the wheel and adm groups. All other logins are rejected:<br />
<br />
+:archie:LOCAL<br />
+:(wheel):LOCAL<br />
+:(adm):LOCAL<br />
-:ALL:ALL<br />
<br />
Read more at {{man|5|access.conf}}<br />
<br />
== Mandatory access control ==<br />
<br />
[[Wikipedia:Mandatory Access Control|Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control|discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
=== Pathname MAC ===<br />
<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
* [[AppArmor]] is a [[Wikipedia:Canonical (company)|Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
* [[TOMOYO]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
=== Labels MAC ===<br />
<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
* [[SELinux]], based on a [[Wikipedia:NSA|NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
<br />
[[Access Control Lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
== Kernel hardening ==<br />
<br />
=== Kernel self-protection / exploit mitigation ===<br />
<br />
The {{pkg|linux-hardened}} package uses a [https://github.com/anthraxx/linux-hardened basic kernel hardening patch set] and more security-focused compile-time configuration options than the {{pkg|linux}} package. A custom build can be made to choose a different compromise between security and performance than the security-leaning defaults.<br />
<br />
However, it should be noted that several packages will not work when using this kernel. For example:<br />
<br />
* {{AUR|skypeforlinux-preview-bin}}<br />
* {{AUR|skypeforlinux-stable-bin}}<br />
* {{pkg|throttled}}<br />
<br />
If you use an out-of-tree driver such as [[NVIDIA]], you may need to switch to its [[DKMS]] package.<br />
<br />
==== Userspace ASLR comparison ====<br />
<br />
The {{pkg|linux-hardened}} package provides an improved implementation of Address Space Layout Randomization for userspace processes. The {{pkg|paxtest}} command can be used to obtain an estimate of the provided entropy:<br />
<br />
===== 64-bit processes =====<br />
<br />
{{hc|linux-hardened 5.4.21.a-1-hardened|<br />
Anonymous mapping randomization test : 32 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 40 quality bits (guessed)<br />
Heap randomization test (PIE) : 40 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : 32 quality bits (guessed)<br />
Main executable randomization (PIE) : 32 quality bits (guessed)<br />
Shared library randomization test : 32 quality bits (guessed)<br />
VDSO randomization test : 32 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 40 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 40 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 44 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 44 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 34 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 34 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 32 bits (guessed)<br />
Randomization under memory exhaustion @0 : 32 bits (guessed)<br />
}}<br />
<br />
{{hc|linux 5.5.5-arch1-1|<br />
Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 20 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 29 bits (guessed)<br />
Randomization under memory exhaustion @0 : 29 bits (guessed)<br />
}}<br />
<br />
{{hc|linux-lts 4.19.101-1-lts|<br />
Anonymous mapping randomization test : 28 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 28 quality bits (guessed)<br />
Heap randomization test (PIE) : 28 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : 28 quality bits (guessed)<br />
Main executable randomization (PIE) : 28 quality bits (guessed)<br />
Shared library randomization test : 28 quality bits (guessed)<br />
VDSO randomization test : 19 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 30 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 30 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 22 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 22 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 28 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 28 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 28 bits (guessed)<br />
Randomization under memory exhaustion @0 : 28 bits (guessed)<br />
}}<br />
<br />
===== 32-bit processes (on an x86_64 kernel) =====<br />
<br />
{{hc|linux-hardened|<br />
Anonymous mapping randomization test : 16 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 22 quality bits (guessed)<br />
Heap randomization test (PIE) : 27 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 18 quality bits (guessed)<br />
Shared library randomization test : 16 quality bits (guessed)<br />
VDSO randomization test : 16 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 24 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 24 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 28 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 28 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 18 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 16 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: 18 bits (guessed)<br />
Randomization under memory exhaustion @0 : 18 bits (guessed)<br />
}}<br />
<br />
{{hc|linux|<br />
Anonymous mapping randomization test : 8 quality bits (guessed)<br />
Heap randomization test (ET_EXEC) : 13 quality bits (guessed)<br />
Heap randomization test (PIE) : 13 quality bits (guessed)<br />
Main executable randomization (ET_EXEC) : No randomization<br />
Main executable randomization (PIE) : 8 quality bits (guessed)<br />
Shared library randomization test : 8 quality bits (guessed)<br />
VDSO randomization test : 8 quality bits (guessed)<br />
Stack randomization test (SEGMEXEC) : 19 quality bits (guessed)<br />
Stack randomization test (PAGEEXEC) : 19 quality bits (guessed)<br />
Arg/env randomization test (SEGMEXEC) : 11 quality bits (guessed)<br />
Arg/env randomization test (PAGEEXEC) : 11 quality bits (guessed)<br />
Offset to library randomisation (ET_EXEC): 8 quality bits (guessed)<br />
Offset to library randomisation (ET_DYN) : 13 quality bits (guessed)<br />
Randomization under memory exhaustion @~0: No randomization<br />
Randomization under memory exhaustion @0 : No randomization<br />
}}<br />
<br />
=== Restricting access to kernel logs ===<br />
<br />
{{Remove|All [[Kernel#Officially supported kernels|officially supported kernels]] have {{ic|1=CONFIG_SECURITY_DMESG_RESTRICT=y}}.}}<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/51-dmesg-restrict.conf|2=<br />
kernel.dmesg_restrict = 1<br />
}}<br />
<br />
{{Note|This is enabled by default in {{pkg|linux}}[https://github.com/archlinux/svntogit-packages/commit/b78bc292e2218661a3b70163ec30711c87100941], {{Pkg|linux-lts}}[https://github.com/archlinux/svntogit-packages/commit/283332609549a479357d2d58adf80d12e89e345f], {{Pkg|linux-zen}}[https://github.com/archlinux/svntogit-packages/commit/5962e24fe3062a3a96dbc1876ba8ea4ef1d500c9] and {{pkg|linux-hardened}}.}}<br />
<br />
=== Restricting access to kernel pointers in the proc filesystem ===<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 1 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you are compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
Setting {{ic|kernel.kptr_restrict}} to 2 will hide kernel symbol addresses in {{ic|/proc/kallsyms}} regardless of privileges.<br />
<br />
{{hc|/etc/sysctl.d/51-kptr-restrict.conf|2=<br />
kernel.kptr_restrict = 1<br />
}}<br />
<br />
{{Note|{{pkg|linux-hardened}} sets {{ic|1=kptr_restrict=2}} by default rather than {{ic|0}}.}}<br />
<br />
=== BPF hardening ===<br />
<br />
BPF is a system used to load and execute bytecode within the kernel dynamically during runtime. It is used in a number of Linux kernel subsystems such as networking (e.g. XDP, tc), tracing (e.g. kprobes, uprobes, tracepoints) and security (e.g. seccomp). It is also useful for advanced network security, performance profiling and dynamic tracing.<br />
<br />
BPF was originally an acronym of [[Wikipedia:Berkeley Packet Filter|Berkeley Packet Filter]] since the original classic BPF was used for packet capture tools for BSD. This eventually evolved into Extended BPF (eBPF), which was shortly afterwards renamed to just BPF (not an acronym). BPF should not be confused with packet filtering tools like iptables or netfilter, although BPF can be used to implement packet filtering tools.<br />
<br />
BPF code may be either interpreted or compiled using a [[Wikipedia:Just-in-time compilation|Just-In-Time (JIT) compiler]]. The Arch kernel is built with {{ic|CONFIG_BPF_JIT_ALWAYS_ON}} which disables the BPF interpreter and forces all BPF to use JIT compilation. This makes it harder for an attacker to use BPF to escalate attacks that exploit SPECTRE-style vulnerabilities. See [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=290af86629b25ffd1ed6232c4e9107da031705cb the kernel patch which introduced CONFIG_BPF_JIT_ALWAYS_ON] for more details.<br />
<br />
The kernel includes a hardening feature for JIT-compiled BPF which can mitigate some types of JIT spraying attacks at the cost of performance and the ability to trace and debug many BPF programs. It may be enabled by setting {{ic|net.core.bpf_jit_harden}} to {{ic|1}} (to enable hardening of unprivileged code) or {{ic|2}} (to enable hardening of all code).<br />
<br />
See the {{ic|net.core.bpf_*}} settings in the [https://www.kernel.org/doc/html/latest/admin-guide/sysctl/net.html kernel documentation] for more details.<br />
<br />
{{Tip|<br />
* {{Pkg|linux-hardened}} sets {{ic|1=net.core.bpf_jit_harden=2}} by default rather than {{ic|0}}.<br />
* By default, BPF programs can be run even by unprivileged users. To change that behaviour set {{ic|1=kernel.unprivileged_bpf_disabled=1}}[https://access.redhat.com/security/cve/cve-2021-33624].<br />
}}<br />
<br />
=== ptrace scope ===<br />
<br />
The {{man|2|ptrace}} syscall provides a means by which one process (the "tracer") may observe and control the execution of another process (the "tracee"), and examine and change the tracee's memory and registers. {{ic|ptrace}} is commonly used by debugging tools including ''gdb'', ''strace'', ''perf'', ''reptyr'' and other debuggers. However, it also provides a means by which a malicious process can read data from and take control of other processes.<br />
<br />
Arch enables the [https://www.kernel.org/doc/html/latest/admin-guide/LSM/Yama.html Yama LSM] by default, which provides a {{ic|kernel.yama.ptrace_scope}} [[kernel parameter]]. This parameter is set to {{ic|1}} (restricted) by default which prevents tracers from performing a {{ic|ptrace}} call on traces outside of a restricted scope unless the tracer is privileged or has the {{ic|CAP_SYS_PTRACE}} [[Capabilities|capability]]. This is a significant improvement in security compared to the classic permissions. Without this module, there is no separation between processes running as the same user (in the absence of additional security layers such as {{man|7|pid_namespaces}}).<br />
<br />
{{Note|By default, you can still use tools which require {{ic|ptrace}} by running them as privileged processes, e.g. using [[sudo]].}}<br />
<br />
If you do not need to use debugging tools, consider setting {{ic|kernel.yama.ptrace_scope}} to {{ic|2}} (admin-only) or {{ic|3}} (no {{ic|ptrace}} possible) to harden the system.<br />
<br />
=== hidepid ===<br />
<br />
{{Expansion|1=[https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=0fb5ce62c5920b6e0a8a061f2fe80e0403281e10 Linux 5.8 implemented private instances] and new values for {{ic|1=hidepid=}}.}}<br />
<br />
{{Warning|<br />
* This may cause issues for certain applications like an application running in a sandbox and [[Xorg]] (see workaround).<br />
* This causes issues with [[D-Bus]], [[Polkit]], [[PulseAudio]] and [[bluetooth]] when using {{Pkg|systemd}} > 237.64-1.<br />
}}<br />
<br />
The kernel has the ability to hide other users' processes, normally accessible via {{ic|/proc}}, from unprivileged users by mounting the {{ic|proc}} filesystem with the {{ic|1=hidepid=}} and {{ic|1=gid=}} options documented in https://www.kernel.org/doc/html/latest/filesystems/proc.html. <br />
<br />
This greatly complicates an intruder's task of gathering information about running processes, whether some daemon runs with elevated privileges, whether other user runs some sensitive program, whether other users run any program at all, makes it impossible to learn whether any user runs a specific program (given the program does not reveal itself by its behaviour), and, as an additional bonus, poorly written programs passing sensitive information via program arguments are now protected against local eavesdroppers.<br />
<br />
The {{ic|proc}} [[Users_and_groups#System_groups|group]], provided by the {{Pkg|filesystem}} package, acts as a whitelist of users authorized to learn other users' process information. If users or services need access to {{ic|/proc/<pid>}} directories beyond their own, [[Users_and_groups#Group_management|add them to the group]].<br />
<br />
For example, to hide process information from other users except those in the {{ic|proc}} group:<br />
<br />
{{hc|/etc/fstab|2=<br />
proc /proc proc nosuid,nodev,noexec,hidepid=2,gid=proc 0 0<br />
}}<br />
<br />
For user sessions to work correctly, an exception needs to be added for ''systemd-logind'':<br />
<br />
{{hc|/etc/systemd/system/systemd-logind.service.d/hidepid.conf|2=<br />
[Service]<br />
SupplementaryGroups=proc<br />
}}<br />
<br />
=== Restricting module loading ===<br />
<br />
The default Arch kernel has {{ic|CONFIG_MODULE_SIG_ALL}} enabled which signs all kernel modules build as part of the {{Pkg|linux}} package. This allows the kernel to restrict modules to be only loaded when they are signed with a valid key, in practical terms this means that all out of tree modules compiled locally or provides by packages such as {{Pkg|virtualbox-host-modules-arch}} cannot be loaded. Kernel module loading can be restricted by setting the [[kernel parameter]] {{ic|1=module.sig_enforce=1}}. More information can be found at the [https://www.kernel.org/doc/html/latest/admin-guide/module-signing.html kernel documentation].<br />
<br />
=== Disable kexec ===<br />
<br />
Kexec allows replacing the current running kernel.<br />
<br />
{{hc|/etc/sysctl.d/51-kexec-restrict.conf|2=<br />
kernel.kexec_load_disabled = 1<br />
}}<br />
<br />
{{Tip|kexec is disabled by default in {{pkg|linux-hardened}}.}}<br />
<br />
=== Kernel lockdown mode ===<br />
<br />
Since Linux 5.4 the kernel [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=aefcf2f4b58155d27340ba5f9ddbe9513da8286d has gained] an optional [https://mjg59.dreamwidth.org/55105.html lockdown feature], intended to strengthen the boundary between UID 0 (root) and the kernel. When enabled some applications may cease to work who rely on low-level access to either hardware or the kernel.<br />
<br />
To use lockdown, its LSM must be initialized and a lockdown mode must be set.<br />
<br />
All [[Kernel#Officially supported kernels|officially supported kernels]] initialize the LSM, but none of them enforce any lockdown mode. <br />
<br />
{{Tip|Enabled LSMs can be verified by running {{ic|cat /sys/kernel/security/lsm}}.}}<br />
<br />
Lockdown has two modes of operation:<br />
<br />
* {{ic|integrity}}: kernel features that allow userland to modify the running kernel are disabled (kexec, bpf).<br />
* {{ic|confidentiality}}: kernel features that allow userland to extract confidential information from the kernel are also disabled.<br />
<br />
To enable kernel lockdown at runtime, run:<br />
<br />
# echo ''mode'' > /sys/kernel/security/lockdown<br />
<br />
To enable kernel lockdown on boot, use the [[kernel parameter]] {{ic|1=lockdown=''mode''}}.<br />
<br />
{{Note|<br />
* Kernel lockdown cannot be disabled at runtime.<br />
* Kernel lockdown disables [[hibernation]].<br />
}}<br />
<br />
See also {{man|7|kernel_lockdown}}.<br />
<br />
=== Linux Kernel Runtime Guard (LKRG) ===<br />
<br />
[https://www.openwall.com/lkrg/ LKRG] ({{AUR|lkrg-dkms}}) is a kernel module which performs integrity checking of the kernel and detection of exploit attempts.<br />
<br />
== Sandboxing applications ==<br />
<br />
See also [[Wikipedia:Sandbox (computer security)]].<br />
<br />
{{Note|The user namespace configuration item {{ic|CONFIG_USER_NS}} is currently enabled in {{Pkg|linux}} (4.14.5 or later), {{Pkg|linux-lts}} (4.14.15 or later), {{Pkg|linux-zen}} (4.14.4-2 or later) and {{Pkg|linux-hardened}}. Lack of it may prevent certain sandboxing features from being made available to applications.}}<br />
<br />
{{Warning|Unprivileged user namespace usage ({{ic|CONFIG_USER_NS_UNPRIVILEGED}}) is enabled by default in {{Pkg|linux}} (5.1.8 or later), {{Pkg|linux-lts}} (4.19.55-2 or later) and {{Pkg|linux-zen}} (5.1.14.zen1-2 or later) unless the {{ic|kernel.unprivileged_userns_clone}} [[sysctl]] is set to {{ic|0}}. Since this greatly increases the attack surface for local privilege escalation, it is advised to disable this manually, or use the {{Pkg|linux-hardened}} kernel. For more information see {{Bug|36969}}.}}<br />
<br />
=== Firejail ===<br />
<br />
[[Firejail]] is an easy to use and simple tool for sandboxing applications and servers alike. Firejail is suggested for browsers and internet facing applications, as well as any servers you may be running.<br />
<br />
=== bubblewrap ===<br />
<br />
[[bubblewrap]] is a sandbox application developed from [[Wikipedia:Flatpak|Flatpak]] with an even smaller resource footprint than Firejail. While it lacks certain features such as file path whitelisting, bubblewrap does offer bind mounts as well as the creation of user/IPC/PID/network/cgroup namespaces and can support both simple and complex sandboxes.<br />
<br />
=== chroots ===<br />
<br />
Manual [[chroot]] jails can also be constructed.<br />
<br />
=== Linux containers ===<br />
<br />
[[Linux Containers]] are another good option when you need more separation than the other options (short of KVM and VirtualBox) provide. LXC is run on top of the existing kernel in a pseudo-chroot with their own virtual hardware.<br />
<br />
=== Other virtualization options ===<br />
<br />
Using full virtualization options such as [[VirtualBox]], [[KVM]], [[Xen]] or [https://www.qubes-os.org/ Qubes OS] (based on Xen) can also improve isolation and security in the event you plan on running risky applications or browsing dangerous websites.<br />
<br />
== Network and firewalls ==<br />
<br />
=== Firewalls ===<br />
<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]] and [[nftables]], they are not enabled by default. It is highly recommended to set up some form of firewall to protect the services running on the system. Many resources (including ArchWiki) do not state explicitly which services are worth protecting, so enabling a firewall is a good precaution.<br />
<br />
* See [[iptables]] and [[nftables]] for general information.<br />
* See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
* See [[:Category:Firewalls]] for other ways of setting up netfilter.<br />
* See [[Ipset]] for blocking lists of ip addresses, such as those from Bluetack.<br />
<br />
==== Open ports ====<br />
<br />
{{Style|"Open ports" is not a good title since it disregards interfaces and addresses that the application may be bound to. From the firewalls' point of view, ports may be "open" even if no application listens on them at the moment.}}<br />
<br />
Some services listen for inbound traffic on open network ports. It is important to only bind these services to the addresses and interfaces that are strictly necessary. It may be possible for a remote attacker to [https://samy.pl/slipstream/ exploit flawed network protocols to access exposed services]. This can even happen with [https://nvd.nist.gov/vuln/detail/CVE-2019-13450 processes bound to localhost].<br />
<br />
In general, if a service only needs to be accessible to the local system, bind to a Unix domain socket ({{man|7|unix}}) or a loopback address such as {{ic|localhost}} instead of a non-loopback address like {{ic|0.0.0.0/0}}.<br />
<br />
If a service needs to be accessible to other systems via the network, control the access with strict [[firewall]] rules and configure authentication, authorization and encryption whenever possible.<br />
<br />
You can list all current open ports with {{ic|ss -l}}. To show all '''l'''istening '''p'''rocesses and their '''n'''umeric '''t'''cp and '''u'''dp port numbers:<br />
<br />
# ss -lpntu<br />
<br />
See {{man|8|ss}} for more options.<br />
<br />
=== Kernel parameters ===<br />
<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
=== SSH ===<br />
<br />
To mitigate [[Wikipedia:Brute-force attack|brute-force attacks]] it is recommended to enforce key-based authentication. For OpenSSH, see [[OpenSSH#Force public key authentication]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[firewall]] rules but open up the potential for a denial of service, since an attacker can [[wikipedia:Spoofing_attack#Spoofing_and_TCP/IP|spoof]] packets as if they came from the administrator after identifying their address. Spoofing IP has lines of defense, such as by [[sysctl#Reverse path filtering|reverse path filtering]] and [[sysctl#Disable ICMP redirects|disabling ICMP redirects]].<br />
<br />
You may want to harden authentication even more by using two-factor authentication. [[Google Authenticator]] provides a two-step authentication procedure using one-time passcodes (OTP).<br />
<br />
Denying root login is also a good practice, both for tracing intrusions and adding an additional layer of security before root access. For OpenSSH, see [[OpenSSH#Deny]].<br />
<br />
Mozilla publishes an [https://infosec.mozilla.org/guidelines/openssh.html OpenSSH configuration guide] which configures more verbose audit logging and restricts ciphers.<br />
<br />
=== DNS ===<br />
<br />
The default domain name resolution (DNS) configuration is highly compatible but has security weaknesses. See [[Domain name resolution#Privacy_and_security|DNS privacy and security]] for more information.<br />
<br />
=== Proxies ===<br />
<br />
Proxies are commonly used as an extra layer between applications and the network, sanitizing data from untrusted sources. The attack surface of a small proxy running with lower privileges is significantly smaller than a complex application running with the end user privileges.<br />
<br />
For example the DNS resolver is implemented in {{Pkg|glibc}}, that is linked with the application (that may be running as root), so a bug in the DNS resolver might lead to a remote code execution. This can be prevented by installing a DNS caching server, such as [[dnsmasq]], which acts as a proxy. [https://googleonlinesecurity.blogspot.it/2016/02/cve-2015-7547-glibc-getaddrinfo-stack.html]<br />
<br />
=== Managing TLS certificates ===<br />
<br />
See [[TLS#Trust management]].<br />
<br />
== Physical security ==<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access by default.[https://web.archive.org/web/20210312083421/http://breaknenter.org/2014/09/inception-metasploit-integration/] For Thunderbolt, you can restrict the direct memory access completely or to known devices, see [[Thunderbolt#User device authorization]]. For Firewire and PCI Express, here is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Data-at-rest encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
=== Locking down BIOS ===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
=== Boot loaders ===<br />
<br />
It is highly important to protect your [[boot loader]]. An unprotected boot loader can bypass any login restrictions, e.g. by setting the {{ic|1=init=/bin/sh}} [[kernel parameter]] to boot directly to a shell.<br />
<br />
==== Syslinux ====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]]. It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
==== GRUB ====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB/Tips and tricks#Password protection of GRUB menu]] for details. It also has support for [[GRUB#Encrypted /boot|encrypted /boot]], which only leaves some parts of the bootloader code unencrypted. GRUB's configuration, [[kernel]] and [[initramfs]] are encrypted.<br />
<br />
=== Secure Boot ===<br />
<br />
[[Secure Boot]] is a feature of [[UEFI]] that allows authentication of the files your computer boots. This helps preventing some [[Wikipedia:Evil maid attack|evil maid attacks]] such as replacing files inside the boot partition. Normally computers come with keys that are enrolled by vendors (OEM). However these can be removed and allow the computer to enter ''Setup Mode'' which allows the user to enroll and manage their own keys.<br />
<br />
The secure boot page guides you through how to set secure boot up by [[Unified Extensible Firmware Interface/Secure Boot#Using your own keys|using your own keys]].<br />
<br />
=== Trusted Platform Module (TPM) ===<br />
<br />
[[Trusted Platform Module|TPMs]] are hardware microprocessors which have cryptographic keys embedded. This forms the fundamental root of trust of most modern computers and allows end-to-end verification of the boot chain. They can be used as internal smartcards, attest the firmware running on the computer and allow users to insert secrets into a tamper-proof and brute-force resistant store.<br />
<br />
=== Boot partition on removable flash drive ===<br />
<br />
One popular idea is to place the boot partition on a flash drive in order to render the system unbootable without it. Proponents of this idea often use [[#Data-at-rest encryption|full-disk encryption]] alongside, and some also use [[Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header|detached encryption headers]] placed on the boot partition.<br />
<br />
This method can also be merged with [[Dm-crypt/Specialties#Encrypted_/boot_and_a_detached_LUKS_header_on_USB|encrypting /boot]].<br />
<br />
=== Automatic logout ===<br />
<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very useful.<br />
<br />
=== Protect against rogue USB devices ===<br />
<br />
Install [[USBGuard]], which is a software framework that helps to protect your computer against rogue USB devices (a.k.a. [https://srlabs.de/badusb BadUSB]{{Dead link|2021|11|19|status=404}}, [https://github.com/samyk/poisontap PoisonTap] or [https://lanturtle.com/ LanTurtle]) by implementing basic whitelisting and blacklisting capabilities based on device attributes.<br />
<br />
=== Volatile data collection ===<br />
<br />
A computer that is powered on may be vulnerable to [https://fedvte.usalearning.gov/courses/CSI/course/videos/pdf/CSI_D01_S05_T01_STEP.pdf volatile data collection]. It is a best practice to turn a computer completely off at times it is not necessary for it to be on, or if the computer's physical security is temporarily compromised (e.g. when passing through a security checkpoint).<br />
<br />
== Packages ==<br />
<br />
=== Authentication ===<br />
<br />
[https://www2.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [https://www2.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
=== Upgrades ===<br />
<br />
It is important to regularly [[System_maintenance#Upgrading_the_system|upgrade the system]].<br />
<br />
=== Follow vulnerability alerts ===<br />
<br />
Subscribe to the Common Vulnerabilities and Exposure (CVE) Security Alert updates, made available by National Vulnerability Database, and found on the [https://nvd.nist.gov/download.cfm NVD Download webpage]. The [https://security.archlinux.org/ Arch Linux Security Tracker] serves as a particularly useful resource in that it combines Arch Linux Security Advisory (ASA), Arch Linux Vulnerability Group (AVG) and CVE data sets in tabular format. The tool {{Pkg|arch-audit}} can be used to check for vulnerabilities affecting the running system. A graphical system tray, {{Pkg|arch-audit-gtk}}, can also be used. See also [[Arch Security Team]].<br />
<br />
You should also consider subscribing to the release notifications for software you use, especially if you install software through means other than the main repositories or AUR. Some software have mailing lists you can subscribe to for security notifications. Source code hosting sites often offer RSS feeds for new releases.<br />
<br />
=== Rebuilding packages ===<br />
<br />
Packages can be rebuilt and stripped of undesired functions and features as a means to reduce attack surface. For example, {{Pkg|bzip2}} can be rebuilt without {{ic|bzip2recover}} in an attempt to circumvent [https://security.archlinux.org/CVE-2016-3189 CVE-2016-3189]. Custom hardening flags can also be applied either manually or via a wrapper.<br />
<br />
{{Merge|Arch package guidelines/Security|Security related build flags have their own article.}}<br />
<br />
{{Accuracy|Copy-pasted from a 3 years old blog post. The compiler flags are specific to [[GCC]], some are hardly security related (e.g. {{ic|-O2}}, {{ic|-g}}, {{ic|-Wall}}).}}<br />
<br />
{| class="wikitable"<br />
! Flag !! Purpose<br />
|-<br />
| -D_FORTIFY_SOURCE=2 || Run-time buffer overflow detection <br />
|-<br />
| -D_GLIBCXX_ASSERTIONS || Run-time bounds checking for C++ strings and containers <br />
|-<br />
| -fasynchronous-unwind-tables || Increased reliability of backtraces <br />
|-<br />
| -fexceptions || Enable table-based thread cancellation <br />
|-<br />
| -fpie -Wl,-pie || Full ASLR for executables <br />
|-<br />
| -fpic -shared || No text relocations for shared libraries <br />
|-<br />
| -fplugin=annobin || Generate data for hardening quality control <br />
|-<br />
| -fstack-clash-protection || Increased reliability of stack overflow detection <br />
|-<br />
| -fstack-protector or -fstack-protector-all || Stack smashing protector <br />
|-<br />
| -fstack-protector-strong || Likewise <br />
|-<br />
| -g || Generate debugging information <br />
|-<br />
| -grecord-gcc-switches || Store compiler flags in debugging information <br />
|-<br />
| -mcet -fcf-protection || Control flow integrity protection <br />
|-<br />
| -O2 || Recommended optimizations <br />
|-<br />
| -pipe || Avoid temporary files, speeding up builds <br />
|-<br />
| -Wall || Recommended compiler warnings <br />
|-<br />
| -Werror=format-security || Reject potentially unsafe format string arguments <br />
|-<br />
| -Werror=implicit-function-declaration || Reject missing function prototypes <br />
|-<br />
| -Wl,-z,defs || Detect and reject underlinking <br />
|-<br />
| -Wl,-z,now || Disable lazy binding <br />
|-<br />
| -Wl,-z,relro || Read-only segments after relocation <br />
|}<br />
<br />
* [https://developers.redhat.com/blog/2018/03/21/compiler-and-linker-flags-gcc/ Flags and info source]<br />
<br />
== See also ==<br />
<br />
* [https://security.archlinux.org/ Arch Linux Security Tracker]<br />
* [https://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [https://developer.ibm.com/technologies/linux/articles/l-harden-desktop/ Hardening the Linux desktop]<br />
* [https://web.archive.org/web/20190701140035/https://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the Linux server]<br />
* [https://github.com/lfit/itpol/blob/master/linux-workstation-security.md Linux Foundation: Linux workstation security checklist]<br />
* [https://www.privacyguides.org/ privacyguides.org Privacy Resources]<br />
* [https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/Security_Guide/ Red Hat Enterprise Linux 7 Security Guide]<br />
* [https://www.debian.org/doc/manuals/securing-debian-manual/index.en.html Securing Debian Manual]<br />
* [https://web.archive.org/web/20140220055801/http://crunchbang.org:80/forums/viewtopic.php?id=24722 The paranoid #! Security Guide]</div>Ndthttps://wiki.archlinux.org/index.php?title=Install_Arch_Linux_from_existing_Linux&diff=645795Install Arch Linux from existing Linux2020-12-17T01:52:11Z<p>Ndt: /* From a host running another Linux distribution */ DigitalOCean -> DigitalOcean</p>
<hr />
<div>[[Category:Installation process]]<br />
[[de:Arch Linux auf einem Root-Server]]<br />
[[es:Install Arch Linux from existing Linux]]<br />
[[fr:Install chroot]]<br />
[[it:Install Arch Linux from existing Linux]]<br />
[[ja:既存の Linux からインストール]]<br />
[[pt:Install Arch Linux from existing Linux]]<br />
[[ru:Install Arch Linux from existing Linux]]<br />
[[zh-hans:Install Arch Linux from existing Linux]]<br />
[[zh-hant:Install Arch Linux from existing Linux]]<br />
{{Related articles start}}<br />
{{Related|Install from SSH}}<br />
{{Related articles end}}<br />
<br />
This document describes the bootstrapping process required to install Arch Linux from a running Linux host system.<br />
After bootstrapping, the installation proceeds as described in the [[Installation guide]].<br />
<br />
Installing Arch Linux from a running Linux is useful for:<br />
<br />
* remotely installing Arch Linux, e.g. a (virtual) root server<br />
* replacing an existing Linux without a LiveCD (see [[#Replacing the existing system without a LiveCD]])<br />
* creating a new Linux distribution or [[Arch-based distributions|LiveMedia based on Arch Linux]]<br />
* creating an Arch Linux chroot environment, e.g. for a Docker base container<br />
* [[Diskless network boot NFS root|rootfs-over-NFS for diskless machines]]<br />
<br />
The goal of the bootstrapping procedure is to setup an environment from which the scripts from {{Pkg|arch-install-scripts}} (such as {{ic|pacstrap}} and {{ic|arch-chroot}}) can be run.<br />
<br />
If the host system runs Arch Linux, this can be achieved by simply installing {{Pkg|arch-install-scripts}}. If the host system runs another Linux distribution, you will first need to set up an Arch Linux-based chroot.<br />
<br />
{{Note|This guide requires that the existing host system be able to execute the new target Arch Linux architecture programs. This means it has to be an x86_64 host.}}<br />
<br />
{{Warning|Please make sure you understand each step before proceeding. It is easy to destroy your system or to lose critical data, and your service provider will likely charge a lot to help you recover. }}<br />
<br />
== Backup and preparation ==<br />
<br />
Backup all your data including mails, webservers, etc. Have all information at your fingertips. Preserve all your server configurations, hostnames, etc.<br />
<br />
Here is a list of data you will likely need:<br />
<br />
* IP address<br />
* hostname(s), (note: rootserver are mostly also part of the providers domain, check or save your {{ic|/etc/hosts}} before you delete)<br />
* DNS server (check {{ic|/etc/resolv.conf}})<br />
* SSH keys (if other people work on your server, they will have to accept new keys otherwise. This includes keys from your Apache, your mail servers, your SSH server and others.)<br />
* Hardware info (network card, etc. Refer to your pre-installed {{ic|/etc/modules.conf}} )<br />
* Grub configuration files.<br />
<br />
In general, it is a good idea to have a local copy of your original {{ic|/etc}} directory on your local hard drive.<br />
<br />
== From a host running Arch Linux ==<br />
<br />
Install the {{Pkg|arch-install-scripts}} package.<br />
<br />
Follow [[Installation guide#Mount the file systems]] to mount the filesystem that will be used for the root directory as well as all the other needed mount points. If you already use the {{ic|/mnt}} directory for something else, just create another directory such as {{ic|/mnt/install}} and use it as the mount point base for the rest of the installation.<br />
<br />
At this stage, Arch Linux can either be installed from scratch or it can mirror the host installation. The two options are described thereafter.<br />
<br />
=== Create a new Arch installation ===<br />
<br />
Follow [[Installation guide#Installation]].<br />
<br />
In the procedure, the first step, [[Installation guide#Select the mirrors]], can be skipped since the host should already have a correct mirrorlist.<br />
<br />
{{Tip|<br />
* In order to avoid redownloading all the packages, consider following [[Pacman/Tips and tricks#Network shared pacman cache]], or use ''pacstrap''<nowiki>'</nowiki>s {{ic|-c}} option to use your host machine's package cache.<br />
* When the grub boot-loader is used, the {{ic|grub-mkconfig}} may detect devices incorrectly. This will result in {{ic|Error:no such device}} when trying to boot from the stick. To solve this problem, from the host running Arch Linux, mount the newly installed partitions, ''arch-chroot'' to the new partition, then install and configure grub. The last step may require disabling ''lvmetad'' from {{ic|/etc/lvm/lvm.conf}} by setting {{ic|1=use_lvmetad=0}}.<br />
}}<br />
<br />
=== Create a copy of an existing Arch installation ===<br />
<br />
It is possible to replicate an existing Arch Linux installation by copying the host filesystem to the new partition and make some adjustments to it to make it bootable and unique.<br />
<br />
The first step is to copy the host files into the mounted new partition, for this, consider using the approach exhibited in [[rsync#Full system backup]].<br />
<br />
Then, follow the procedure described in [[Installation guide#Configure the system]] with some caveats and additional steps:<br />
<br />
* [[Installation guide#Time zone]], [[Installation guide#Localization]] and [[Installation guide#Root password]] can be skipped<br />
* [[Installation guide#Initramfs]] may be required in particular if changing filesystem, for example from [[ext4]] to [[Btrfs]]<br />
* Regarding [[Installation guide#Boot loader]], it is necessary to reinstall the bootloader<br />
* Delete {{ic|/etc/machine-id}} so that a new, unique one, is generated at the next boot<br />
<br />
If the mirrored Arch installation may be used within a different configuration or with another hardware, consider the following additional operations:<br />
<br />
* Use the CPU [[microcode]] update adapted to the target system during the step [[Installation guide#Boot loader]]<br />
* If any specific [[Xorg#Configuration]] was present on the host and may be incompatible with the target system, follow [[Moving an existing install into (or out of) a virtual machine#Disable any Xorg-related files]]<br />
* Make any other adjustment appropriate to the target system, like reconfiguring the network or the audio.<br />
<br />
== From a host running another Linux distribution ==<br />
<br />
There are multiple tools which automate a large part of the steps described in the following subsections. See their respective homepages for detailed instructions.<br />
<br />
* [https://github.com/tokland/arch-bootstrap arch-bootstrap] (Bash)<br />
* [https://github.com/gh2o/digitalocean-debian-to-arch digitalocean-debian-to-arch] (repartition disk, DigitalOcean specific)<br />
* [https://github.com/hartwork/image-bootstrap image-bootstrap] (Python)<br />
* [https://gitlab.com/drizzt/vps2arch vps2arch] (Bash)<br />
* [https://github.com/BiteDasher/archbashstrap archbashstrap] (Bash)<br />
<br />
The manual way is presented in the following subsections. The idea is to either get [[pacman]] working directly on the host system, or to run an Arch system inside the host system, with the actual installation being executed from the Arch system. The nested system is contained inside a chroot.<br />
<br />
=== Using pacman from the host system ===<br />
<br />
[https://git.archlinux.org/pacman.git/ Pacman] can be compiled on most Linux distributions, and used directly on the host system to bootstrap Arch Linux. The [https://git.archlinux.org/arch-install-scripts.git/about/ arch-install-scripts] should run without issues directly from the downloaded sources on any recent distribution.<br />
<br />
Some distributions provide a package for ''pacman'' and/or ''arch-install-scripts'' in their official repositories which can be used for this purpose. As of July 2020, Void Linux is known to provide the ''pacman'' package, and Alpine Linux and Fedora are known to provide both ''pacman'' and ''arch-install-scripts''.<br />
<br />
=== Creating a chroot ===<br />
<br />
Two methods to setup and enter the chroot are presented below, from the easiest to the most complicated. Select only one of the two methods. Then, continue at [[#Using a chroot environment]].<br />
<br />
==== Method A: Using the bootstrap image (recommended) ====<br />
<br />
Download the bootstrap image from a [https://www.archlinux.org/download mirror] into {{ic|/tmp}}.<br />
<br />
You can also download the signature (same URL with {{ic|.sig}} added) and [[GnuPG#Verify_a_signature|verify it with GnuPG]].<br />
<br />
Extract the tarball:<br />
<br />
# tar xzf <path-to-bootstrap-image>/archlinux-bootstrap-*-x86_64.tar.gz<br />
<br />
Select a repository server by editing {{ic|/tmp/root.x86_64/etc/pacman.d/mirrorlist}}.<br />
<br />
Enter the chroot<br />
<br />
* If bash 4 or later is installed, and unshare supports the --fork and --pid options:<br />
# /tmp/root.x86_64/bin/arch-chroot /tmp/root.x86_64/<br />
* Otherwise, run the following commands:<br />
# mount --bind /tmp/root.x86_64 /tmp/root.x86_64<br />
# cd /tmp/root.x86_64<br />
# cp /etc/resolv.conf etc<br />
# mount -t proc /proc proc<br />
# mount --make-rslave --rbind /sys sys<br />
# mount --make-rslave --rbind /dev dev<br />
# mount --make-rslave --rbind /run run # (assuming /run exists on the system)<br />
# chroot /tmp/root.x86_64 /bin/bash<br />
<br />
==== Method B: Using the LiveCD image ====<br />
<br />
It is possible to mount the root image of the latest Arch Linux installation media and then chroot into it. This method has the advantage of providing a working Arch Linux installation right within the host system without the need to prepare it by installing specific packages.<br />
<br />
{{Note|Before proceeding, make sure the latest version of [http://squashfs.sourceforge.net/ squashfs] is installed on the host system. Otherwise, errors like the following are to be expected: {{ic|FATAL ERROR aborting: uncompress_inode_table: failed to read block}}.}}<br />
<br />
* The root image can be found on one of the [https://www.archlinux.org/download mirrors] under {{ic|arch/x86_64/}}. The squashfs format is not editable, so we unsquash the root image and mount it.<br />
<br />
*To unsquash the root image, run<br />
<br />
# unsquashfs airootfs.sfs<br />
<br />
* Before [[Change root|chrooting]] to it, we need to set up some mount points and copy the resolv.conf for networking.<br />
<br />
# mount --bind squashfs-root squashfs-root<br />
# mount -t proc none squashfs-root/proc<br />
# mount -t sysfs none squashfs-root/sys<br />
# mount -o bind /dev squashfs-root/dev<br />
# mount -o bind /dev/pts squashfs-root/dev/pts ## important for pacman (for signature check)<br />
# cp -L /etc/resolv.conf squashfs-root/etc ## this is needed to use networking within the chroot<br />
<br />
* Now, everything is prepared to chroot into the newly installed Arch environment<br />
# chroot squashfs-root bash<br />
<br />
=== Using a chroot environment ===<br />
<br />
The bootstrap environment is really barebones (no {{Pkg|nano}} or {{Pkg|lvm2}}). Therefore, we need to set up pacman in order to download other necessary packages.<br />
<br />
==== Initializing pacman keyring ====<br />
<br />
Before starting the installation, pacman keys need to be setup. Before running the following two commands, read [[pacman-key#Initializing the keyring]] to understand the entropy requirements:<br />
<br />
# pacman-key --init<br />
# pacman-key --populate archlinux<br />
<br />
{{Tip|Installing and running {{Pkg|haveged}} must be done on the host system, since it is not possible to install packages before initializing pacman keyring and because ''systemd'' will detect it is running in a chroot and [https://superuser.com/questions/688733/start-a-systemd-service-inside-chroot ignore activation request].<br />
<br />
If you go with doing {{ic|ls -Ra /}} in another console (TTY, terminal, SSH session...), do not be afraid of running it in a loop a few times: five or six runs from the host proved sufficient to generate enough entropy on a remote headless server.}}<br />
<br />
==== Selecting a mirror and downloading basic tools ====<br />
<br />
After [[Mirrors#Enabling_a_specific_mirror|selecting a mirror]], [[Mirrors#Force_pacman_to_refresh_the_package_lists|refresh the package lists]] and [[install]] what you need: {{Grp|base-devel}}, {{Pkg|parted}} etc.<br />
<br />
{{Note|<br />
* As there is no any text editor yet, you need to exit arch-chroot and edit mirrorlist using host's text editor.<br />
* When you try to install packages with pacman, you could get {{ic|''error: could not determine cachedir mount point /var/cache/pacman/pkg''}}. To workaround it, you could run {{bc|mount --bind ''directory-to-livecd-or-bootstrap'' ''directory-to-livecd-or-bootstrap''}} before chrooting. See {{Bug|46169}}.<br />
}}<br />
<br />
=== Installation tips ===<br />
<br />
You can now proceed to [[Installation guide#Partition the disks]] and follow the rest of the [[Installation guide]].<br />
<br />
Some host systems or configurations may require certain extra steps. See the sections below for tips.<br />
<br />
===== Debian-based host =====<br />
<br />
====== /dev/shm ======<br />
<br />
On some Debian-based host systems, ''pacstrap'' may produce the following error:<br />
<br />
{{hc|# pacstrap /mnt base|<br />
==> Creating install root at /mnt<br />
mount: mount point /mnt/dev/shm is a symbolic link to nowhere<br />
==> ERROR: failed to setup API filesystems in new root<br />
}}<br />
<br />
This is because in some versions of Debian, {{ic|/dev/shm}} points to {{ic|/run/shm}} while in the Arch-based chroot, {{ic|/run/shm}} does not exist and the link is broken. To correct this error, create a directory {{ic|/run/shm}}:<br />
<br />
# mkdir /run/shm<br />
<br />
====== /dev/pts ======<br />
<br />
While installing {{ic|archlinux-2015.07.01-x86_64}} from a Debian 7 host, the following error prevented both [https://projects.archlinux.org/arch-install-scripts.git/tree/pacstrap.in pacstrap] and [[Change root#Using arch-chroot|arch-chroot]] from working:<br />
<br />
{{hc|# pacstrap -i /mnt|<br />
mount: mount point /mnt/dev/pts does not exist<br />
==> ERROR: failed to setup chroot /mnt<br />
}}<br />
<br />
Apparently, this is because these two scripts use a common function. {{ic|chroot_setup()}}[https://projects.archlinux.org/arch-install-scripts.git/tree/common#n76] relies on newer features of {{Pkg|util-linux}}, which are incompatible with Debian 7 userland (see {{Bug|45737}}).<br />
<br />
The solution for ''pacstrap'' is to manually execute its [https://projects.archlinux.org/arch-install-scripts.git/tree/pacstrap.in#n77 various tasks], but use the [[Change root#Using_chroot|regular procedure]] to mount the kernel filesystems on the target directory ({{ic|"$newroot"}}):<br />
<br />
# newroot=/mnt<br />
# mkdir -m 0755 -p "$newroot"/var/{cache/pacman/pkg,lib/pacman,log} "$newroot"/{dev,run,etc}<br />
# mkdir -m 1777 -p "$newroot"/tmp<br />
# mkdir -m 0555 -p "$newroot"/{sys,proc}<br />
# mount --bind "$newroot" "$newroot"<br />
# mount -t proc /proc "$newroot/proc"<br />
# mount --rbind /sys "$newroot/sys"<br />
# mount --rbind /run "$newroot/run"<br />
# mount --rbind /dev "$newroot/dev"<br />
# pacman -r "$newroot" --cachedir="$newroot/var/cache/pacman/pkg" -Sy base base-devel ... ## add the packages you want<br />
# cp -a /etc/pacman.d/gnupg "$newroot/etc/pacman.d/" ## copy keyring<br />
# cp -a /etc/pacman.d/mirrorlist "$newroot/etc/pacman.d/" ## copy mirrorlist<br />
<br />
Instead of using ''arch-chroot'' for [[Installation guide#Chroot]], simply use:<br />
<br />
# chroot "$newroot"<br />
<br />
====== lvmetad ======<br />
<br />
Trying to create [[LVM]] [[LVM#Logical volumes|logical volumes]] from an {{ic|archlinux-bootstrap-2015.07.01-x86_64}} environment on a Debian 7 host resulted in the following error:<br />
<br />
{{hc|# lvcreate -L 20G lvm -n root|<br />
/run/lvm/lvmetad.socket: connect failed: No such file or directory<br />
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.<br />
/dev/lvm/root: not found: device not cleared<br />
Aborting. Failed to wipe start of new LV.}}<br />
<br />
(Physical volume and volume group creation worked despite {{ic|/run/lvm/lvmetad.socket: connect failed: No such file or directory}} being displayed.)<br />
<br />
This could be easily worked around by creating the logical volumes outside the chroot (from the Debian host). They are then available once chrooted again.<br />
<br />
{{Accuracy|This problem did not arise when installing from a Debian 7 host without ''lvmetad'' enabled. The recommended messaround with {{ic|/etc/lvm/lvm.conf}} looks rather error prone (2015-07-26).}}<br />
<br />
Also, if the system you are using has lvm, you might have the following output:<br />
<br />
{{hc|1=# grub-install --target=i386-pc --recheck /dev/main/archroot|2=<br />
Installing for i386-pc platform.<br />
/run/lvm/lvmetad.socket: connect failed: No such file or directory<br />
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.<br />
/run/lvm/lvmetad.socket: connect failed: No such file or directory<br />
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.<br />
/run/lvm/lvmetad.socket: connect failed: No such file or directory<br />
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.<br />
/run/lvm/lvmetad.socket: connect failed: No such file or directory<br />
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.<br />
/run/lvm/lvmetad.socket: connect failed: No such file or directory<br />
WARNING: Failed to connect to lvmetad. Falling back to internal scanning.<br />
}}<br />
<br />
This is because debian does not use lvmetad by default. You need to edit {{ic|/etc/lvm/lvm.conf}} and set {{ic|use_lvmetad}} to {{ic|0}}:<br />
<br />
use_lvmetad = 0<br />
{{Accuracy|Is it the problem with LVM on Debian or with trying to install Arch on LVM?}}<br />
{{Style|poor style}}<br />
This will trigger later an error on boot in the initrd stage. Therefore, you have to change it back after the grub generation. In a software RAID + LVM, steps would be the following:<br />
<br />
* After installing the system, double check your [[Mkinitcpio]] and your bootloader settings. See [[Arch boot process#Boot loader]] for a list of bootloaders.<br />
* You may need to change your {{ic|/etc/mdadm.conf}} to reflect your [[RAID]] settings (if applicable).<br />
* You may need to change your {{ic|HOOKS}} and {{ic|MODULES}} according to your [[LVM]] and [[RAID]] requirements: {{ic|1=MODULES="dm_mod" HOOKS="base udev '''mdadm_udev''' ... block '''lvm2''' filesystems ..."}}<br />
* You will most likely need to generate new initrd images with mkinitcpio. See [[Mkinitcpio#Image creation and activation]].<br />
* Set {{ic|1=use_lvmetad = 0}} in {{ic|/etc/lvm/lvm.conf}}.<br />
* Update your bootloader settings. See your bootloader's wiki page for details.<br />
* Set {{ic|1=use_lvmetad = 1}} in {{ic|/etc/lvm/lvm.conf}}.<br />
<br />
===== Fedora-based host =====<br />
<br />
On Fedora based hosts and live USBs you may encounter problems when using ''genfstab'' to generate your [[fstab]]. Remove duplicate entries and the "seclabel" option where it appears, as this is Fedora-specific and will keep your system from booting normally.<br />
<br />
== Things to check before you reboot ==<br />
<br />
Before rebooting, doublecheck a few details in your installation to achieve a successful installation. To do so, first chroot into the newly-installed system, and then:<br />
<br />
* [[Users and groups#User management|create a user with password]], so you can login via ''ssh''. This is critical since root login is disabled by default since OpenSSH-7.1p2.<br />
* [[Users and groups#User management|set a root password]] so that you can switch to root via ''su'' later<br />
* [[install]] a [[ssh]] solution and [[enable]] its server instance to start automatically at boot.<br />
* set up your [[network configuration]] in order to have a connection started automatically at boot.<br />
* set up a [[boot loader]] and configure it to use the swap partition you appropriated earlier as the root partition. You might want to configure your bootloader to be able to boot into your old system; it is helpful to re-use the server's existing {{ic|/boot}} partition in the new system for this purpose.<br />
<br />
== Replacing the existing system without a LiveCD ==<br />
<br />
Find ~700 MB of free space somewhere on the disk, e.g. by partitioning a swap partition. You can disable the swap partition and set up your system there. <br />
<br />
===Set old swap partition as new root partition===<br />
<br />
Check {{ic|cfdisk}}, {{ic|/proc/swaps}} or {{ic|/etc/fstab}} to find your swap partition. Assuming your hard drive is located on {{ic|sda''X''}} ({{ic|''X''}} will be a number). <br />
<br />
Do the following:<br />
<br />
Disable the swap space:<br />
<br />
# swapoff /dev/sda''X''<br />
<br />
Create a filesystem on it<br />
<br />
# fdisk /dev/sda<br />
(set /dev/sda''X'' ID field to "Linux" - Hex 83)<br />
# mke2fs -j /dev/sda''X''<br />
<br />
Create a directory to mount it in<br />
<br />
# mkdir /mnt/newsys<br />
<br />
Finally, mount the new directory for installing the intermediate system.<br />
<br />
# mount -t ext4 /dev/sda''X'' /mnt/newsys<br />
<br />
=== Installation ===<br />
<br />
[[Installation guide#Install essential packages|Install essentials packages]] and any other package required to get a system with internet connection up and running in the temporary partition, being careful with the limit of ~700 MB space. When specifying packages to be installed with ''pacstrap'', consider adding the {{ic|-c}} flag to avoid filling up valuable space by downloading packages to the host system.<br />
<br />
Once the new Arch Linux system is installed, fix the bootloader configuration, then reboot into the newly created system, and [[rsync#Full system backup|rsync the entire system]] to the primary partition.</div>Ndthttps://wiki.archlinux.org/index.php?title=Mac&diff=483432Mac2017-07-31T17:06:59Z<p>Ndt: /* Suspend & Power Off (11,4+) */ fix formatting</p>
<hr />
<div>[[Category:Apple]]<br />
[[de:ArchLinux auf einem MacBook]]<br />
[[fr:MacBook]]<br />
[[it:MacBook]]<br />
[[ja:MacBook]]<br />
[[zh-hans:MacBook]]<br />
{{Related articles start}}<br />
{{Related|Installation guide}}<br />
{{Related|General recommendations}}<br />
{{Related|MacBook4,2 (late 2008)}}<br />
{{Related|MacBook5,2 (early-mid 2009)}}<br />
{{Related|MacBookPro7,1}}<br />
{{Related|MacBookPro8,1/8,2/8,3 (2011)}}<br />
{{Related|MacBookPro9,2 (Mid-2012)}}<br />
{{Related|MacBookPro10,x}}<br />
{{Related|MacBookPro11,x}}<br />
{{Related|iMac Aluminum}}<br />
{{Related|Apple Fusion Drive}}<br />
{{Related articles end}}<br />
<br />
Installing Arch Linux on a MacBook (12"/Air/Pro) or an iMac is quite similar to installing it on any other computer. However, due to the specific hardware configuration of a Mac, there are a few deviations and special considerations which warrant a separate guide. For more background information, please see the [[Installation guide]] and [[UEFI]]. This guide contains installation-instructions that can be used on any Apple computer whose hardware is supported by the Linux kernel. Please see 'related' pages (on the top right of this page) for model-specific tips and troubleshooting.<br />
<br />
== Overview ==<br />
<br />
Specifically, the procedure for installing Arch Linux on a MacBook is:<br />
<br />
# '''[[#Firmware updates|Firmware updates]]''': It always helps to start from a clean, backed up, and up-to-date install of OS X.<br />
# '''[[#Partitions|Partition]]''': Resizing or deleting the OS X partition to create partitions for Arch Linux.<br />
# '''[[#Setup bootloader|Setup bootloader]]''': Making sure that the new partition is bootable.<br />
# '''[[#Installation|Install Arch Linux]]''': Actually installing Arch Linux.<br />
# '''[[#Post-installation|Post-installation]]''': MacBook-specific configuration.<br />
<br />
== Firmware updates ==<br />
<br />
Before proceeding with the installation of Arch Linux, it is important to ensure that the latest firmware updates for you MacBook are installed. This procedure requires OS X.<br />
In OS X, open the App Store and check for updates. If your mac finds and installs any updates, make sure to '''reboot''' your computer, and then check again for updates to make sure that you installed everything.<br />
<br />
{{Note|If you uninstalled OS X or want to reinstall it, [https://support.apple.com/en-us/HT204904 Apple] has great instructions.}}<br />
<br />
It is advisable to keep OS X installed, because MacBook firmware updates can only be installed using OS X. However, if you plan to remove OS X completely, make backups of these files, which you will need in Linux for adjusting the [[#Color Profile|color profile]]:<br />
/Library/ColorSync/Profiles/Displays/*<br />
<br />
Continue to [[#Partitions]]<br />
<br />
== Partitions ==<br />
<br />
Partitioning of the storage drive is no different from any other PC or laptop. However, if you plan on keeping OS X for dual booting, you should consider that, by default, a MacBook's drive is formatted using GPT and contains at least 3 partitions:<br />
<br />
* '''EFI''': the ~200 MB [[EFI System Partition]].<br />
* '''OS X''': the main partition containing your OS X installation. It is formatted using [[File_systems|HFS+]].<br />
* '''Recovery''': A recovery partition present in almost all MacBooks running OS X 10.7 or newer. It is usually hidden from OS X but can be viewed with partitioning tools.<br />
<br />
{{Note|In Macs that use the [[Apple Fusion Drive]], the partition scheme could be different.}}<br />
<br />
How to partition depends on how many operating systems you want install. The following options will be explained:<br />
<br />
* Single boot: [[#Arch Linux only]]<br />
* Dual boot: [[#Arch Linux with OS X or other operating systems]] ''(recommended so you can still return to OS X when needed)''<br />
* Triple boot: [[#OS X, Windows XP, and Arch Linux triple boot]]<br />
<br />
<br />
=== Arch Linux only ===<br />
<br />
This situation is the easiest to deal with. Partitioning is the same as any other hardware that Arch Linux can be installed on. Please refer to the standard [[Installation guide]] for details.<br />
<br />
{{Note|It is advisable to '''disable''' the MacBook startup sound before proceeding with partitioning. Just boot in OS X, mute your system sound and reboot again to the Arch Linux Installation media. Please keep in mind that the volume of the startup sound can only be modified reliably in OS X.}}<br />
<br />
If you want to configure you system in order to have full-disk encryption, please look at the [[Dm-crypt/Encrypting an entire system]] page for details.<br />
<br />
An example for a very basic partitioning, that does not consider a separate {{ic|/home}} partition nor encryption or LVM, is the following:<br />
partition mountpoint size type label<br />
/dev/sda1 /boot 200MiB vfat EFI<br />
/dev/sda2 /swap adjust swap swap<br />
/dev/sda3 / remain ext4 root<br />
<br />
* Done, you can continue to [[#Installation]]<br />
<br />
<br />
=== Arch Linux with OS X or other operating systems ===<br />
<br />
You need to partition your hard drive while keeping the partitions used for OS X/Windows. If you wish to keep OS X, the easiest way is to use partitioning tools in OS X and then finish with Arch Linux tools.<br />
<br />
{{Warning| If you OS X partition is encrypted with FileVault 2, you '''must''' disable the disk encryption before proceeding. After the OS X partition has been resized, FileVault 2 can be re-enabled.}}<br />
<br />
'''Procedure''':<br />
* In OS X, run ''Disk Utility.app'' (located in {{ic|/Applications/Utilities}})<br />
* Select the drive to be partitioned in the left-hand column (not the partitions!). Click on the '''Partition''' button.<br />
* Add a new partition by pressing the '''+''' button and choose how much space you want to leave for OS X, and how much for the new partition. Keep in mind the new partition will be formatted in Arch Linux, so you can choose any partition type you want. <br />
* If the above completed successfully, then you can continue. If not, then you may need to fix your partitions from within OS X first.<br />
* Boot the Arch installation media or [[USB flash installation media|LiveUSB]] by holding down the {{ic|Alt}} '''during boot'''. Proceed with [[#Installation]].<br />
<br />
It is possible to resize the newly created partition from within the Arch installation media, or delete it in order to proceed with the creation of other partitions (eg. swap).<br />
<br />
{{Tip|Instead of cluttering your drive with different partition, it is possible to use a [[swapfile]] instead of a dedicated partition. Another solution can be setting up [[LVM]] in order to use the newly-created partition as a container. Please refer to the linked articles.}}<br />
<br />
<br />
==== Option 1: EFI ====<br />
<br />
* Run ''cgdisk''<br />
<br />
* Delete the partition you made in ''Disk Utility.app'' and create the necessary partitions for Arch Linux. OS X likes to see a 128 MiB gap after partitions, so when you create the first partition after the last OS X-partition, type in '''+128M''' when cgdisk asks for the first sector for the partition. More information about Apple's partitioning policy can be read [https://developer.apple.com/library/mac/technotes/tn2166/_index.html#//apple_ref/doc/uid/DTS10003927-CH1-SUBSECTION5 here]. A simple example (no LVM, crypto):<br />
<br />
{{Note|<br />
* The swap partition is optional on machines with 4GB of RAM or more. A '''[[swap file]]''' can be created later.<br />
* The easiest dual-boot option is to install rEFInd from inside OS X, to its root directory (default for {{ic|install.sh}}). Following that, copy the driver folder from the installation tarball into the new rEFInd location, and uncomment the lines ''"scan_all_linux_kernels"'' and ''"also_scan_dirs"'' options in {{ic|refind.conf}}. Configuration of boot options can then be done from a {{ic|refind_linux.conf}} in Arch's {{ic|/boot}} directory.<br />
* If you want to be able to boot GRUB from the Apple boot loader, you can create a small hfs+ partition (for convenience, use OS X to format it in ''Disk Utility.app'' afterwards). Follow the GRUB EFI install procedure, and mount your {{ic|/boot/efi}} directory to the hfs+ partition you created. Finally, finish up again in OS X by blessing the partition. This will set GRUB as the default boot option (holding alt at startup goes to the mac boot options screen still. See http://mjg59.dreamwidth.org/7468.html).,<br />
* OS X's EFI partition can be shared with Arch Linux, making the creation of an additional EFI partition dedicated to Arch completely optional.<br />
}}<br />
<br />
{{Note|For more information on partitioning, see [[Partitioning]]}}<br />
partition mountpoint size type label<br />
/dev/sda1 /boot/efi 200MiB vfat EFI<br />
/dev/sda2 - ? hfs+ OS X<br />
/dev/sda3 - ? hfs+ Recovery<br />
/dev/sda4 - 100MiB hfs+ Boot Arch Linux from the Apple boot loader (optional)<br />
/dev/sda5 /boot 100MiB boot boot<br />
/dev/sda6 - ? swap swap (optional)<br />
/dev/sda7 / 10GiB ext4 root<br />
/dev/sda8 /home remaining ext4 home<br />
<br />
* Done, you can continue to [[#Installation]]<br />
<br />
==== Option 2: BIOS-compatibility ====<br />
<br />
* Run ''parted'' as root.<br />
<br />
* Delete the empty space partition and partition the space as you would for any other installation. Note that MBR is limited to 4 primary partitions (including the efi partition). That leaves 2 primary partitions for Arch. One strategy is to have a system and home partition, and use a swap file (I have not tried to use logical partitions). Another is to dedicate one partition to a shared partition (see below).<br />
<br />
* Next, create new filesystems on those partitions which need them, especially the partition which will contain {{ic|/boot}}. If you are not sure how to do this using {{ic|mkfs.ext2}} (or whatever), run {{ic|/arch/setup}} and work through until you get to Prepare Hard Drive and use the ''"Manually configure block devices..."'' option, then exit the installer. This is necessary so that rEFIt will set the right partition type in the MBR in the next step (without an existing filesystem, it seems to ignore the partition type set by parted), without which GRUB will refuse to install to the right partition.<br />
<br />
* At this point you should reboot your computer and have rEFIt fix the partition tables on your hard drive. (If you do not do this, you may have to reinstall GRUB later on in order to have your Mac recognize the Linux partition.) When you are into the rEFIt menu, select '''update partition table''', then press {{ic|y}}. Reboot.<br />
<br />
* Done, you can continue with [[#Installation]].<br />
<br />
=== OS X, Windows XP, and Arch Linux triple boot ===<br />
<br />
This may not work for everyone but it has been successfully tested on a MacBook from late 2009.<br />
<br />
The easiest way to partition your hard drive, so that all these operating systems can co-exist, is to use disk utility in OS X, use the formatter on windows XP, install XP and then finish with Arch Linux tools.<br />
<br />
{{Warning|It is highly recommended that this only be attempted after a clean install of OS X. Using these methods on a pre-existing system may have undesired results. At least back your stuff up with timemachine or clonezilla before you begin.}}<br />
<br />
'''Procedure''':<br />
* In OS X, run '''Disk Utility''' (located in {{ic|/Applications/Utilities}}).<br />
<br />
* Select the drive to be partitioned in the left-hand column (not the partitions!). Click on the '''partition''' tab on the right.<br />
<br />
* Select the volume to be resized in the '''volume scheme.'''<br />
<br />
* Decide how much space you wish to have for your OS X partition, how much for XP, and how much for Arch Linux. Remember that a typical installation of OS X requires around 15-20 GiB, and XP about the same, depending on the number of software applications and files. Something like OS X 200Gb, XP 25Gb, Arch 25Gb should be fine.<br />
<br />
* Put your decisions into action by pressing the + button and adding the new partitions, Label them as you like and make sure that your XP partition is the last one on the disk and is formatted for FAT32. It is probably best to have Arch formatted in HFS format as to not confuse you later, it will be reformatted anyway.<br />
<br />
So in linux terms your partitions will be something like:<br />
<br />
:*sda (disk)<br />
:*sda1 (Mac boot partition - you cannot see this one in OS X)<br />
:*sda2 (OS X install in HFS+)<br />
:*sda3 (Arch install temporarly in HFS)<br />
:*sda4 (XP install in FAT32)<br />
<br />
* Finally, click '''apply'''. This will create a new partition out of the empty space.<br />
<br />
{{Note|Using this method you may not be able to have a shared partition between OS X and Arch Linux, this is because the mac will only allow for 4 active partitions. You will however be able to mount a HFS partition in Arch for one workaround. There are other workarounds possible also.}}<br />
<br />
* If the above completed successfully, you can continue. If not, then you may need to fix your partitions from within OS X first.<br />
<br />
* You will not be needing boot camp this way, the program rEFIt is much more flexible (though not as flexible as GRUB). Download and install rEFIt [http://refit.sourceforge.net/]<br />
<br />
* Go into a terminal in OS X and perform the following, this will enable the rEFIt boot manager. <br />
<br />
cd /efi/refit<br />
./enable.sh<br />
<br />
* Reboot to check the rEFIt is working, it should appear on boot. When it comes up go to the rEFIt partition manager and agree to the changes.<br />
<br />
* Put your XP install CD and boot it with rEFIt - You may have to reboot a few times until it is recognized by the boot loader. Install XP and once it is installed use the OS X installation CD to get your drivers running nicely in XP.<br />
** Note: when installing XP make sure you select your XP partition and format it again inside the XP installer. If you do not reformat it will not work.<br />
<br />
* Boot the Arch install CD, log in as root and run {{ic|# /arch/setup}}.<br />
<br />
* Follow the install as normal but note that you will have to tell that arch installer to mount sda3 as the root partition and format it as ext3, there will not be a /boot or swap partition so ignore those warnings.<br />
<br />
* At this point, if you are dual booting, you should reboot your computer and have rEFIt fix the partition tables on your hard drive. (If you do not do this, you may have to reinstall GRUB later on in order to have your Mac recognize the Linux partition.) When you are into the rEFIt menu, select '''update partition table''', then press Y.<br />
# reboot<br />
<br />
* Done! You can continue to [[#Installation]].<br />
<br />
== Setup bootloader ==<br />
<br />
=== Using the native Apple bootloader with systemd-boot (Recommended) ===<br />
<br />
Apple's native EFI bootloader reads {{ic|.efi}} files located inside the [[EFI System Partition]] at {{ic|/EFI/BOOT/BOOTX64.EFI}}. Luckily, this is also the default install location for the [[systemd-boot]] binary. This means that booting linux using ''systemd-boot'' is very simple.<br />
* First, make sure you mounted the EFI System Partition at {{ic|/boot}}<br />
* Proceed with [[#Installation]] normally<br />
* Once inside the chrooted enviroment, type the following command to install ''systemd-boot'':<br />
{{bc|1=# bootctl --path=/boot install}}<br />
The above command will copy the ''systemd-boot'' binary to {{ic|/boot/EFI/BOOT/BOOTX64.EFI}} and add ''systemd-boot'' itself as the default EFI application (default boot entry) loaded by the EFI Boot Manager. <br />
* Proceed to [[systemd-boot#Configuration]] in order to correctly set up the bootloader<br />
At the next reboot, the Apple Boot Manager, shown when holding down the option key when booting the MacBook, should display Arch Linux (it will be displayed as {{ic|EFI Boot}} as a possible boot option.<br />
{{Tip|If you installed Arch Linux alongside OS X, you will be able to change the default boot location from system Settings inside OS X. If Arch Linux does not show up as a possible boot option, you will have to mount the EFI System Partition inside OS X before selecting your boot option:<br />
{{bc|$ diskutil mount disk0s1}}<br />
}}<br />
<br />
=== Using the native Apple bootloader with GRUB ===<br />
<br />
{{Style|Uses [[partial upgrade]] procedure and explicitly lists many basic commands.}}<br />
<br />
Despite using UEFI, the MacBook's native EFI bootloader [http://refit.sourceforge.net/myths/ does not use the EFI partition for booting]. Instead, it looks for .efi files inside all the partitions in internal and external drives and shows them as possible boot options if certain conditions are satisfied. For example, MacBooks can detect an existing OSX installation after checking that:<br />
* there is a partition formatted as HFS+<br />
* the partition contains the partition id {{ic|af00}} <br />
* in the root of that partition, there is a file called {{ic|mach_kernel}}<br />
* inside that partition, there a {{ic|boot.efi}} file inside {{ic|/System/Library/CoreServices}}<br />
<br />
This means that configuring an Arch installation to be automatically recognized by the MacBook bootloader is possible. Moreover, it simply requires a properly-formatted HFS+ {{ic|/boot}} partition and does not require meddling with the EFI system partition. The advantage of this method is that it can coexist with OS X nicely and allows to avoid other bootloaders such as rEFInd. However, this requires manual configuration. The following steps will illustrate how to perform this configuration using GRUB.<br />
* First, while configuring a new Arch installation, create a separate {{ic|/boot}} partition. Many tools are available in the Arch ISO, for example '''cgdisk'''.<br />
* Make sure the partition is at least ~250 MB in size, since it will be used to store the kernel as well as any custom kernel you will install in the future. Moreover, make sure the partition type is set as Apple HFS/HFS+ (it will appear as {{ic|Apple HFS/HFS+}} in fdisk/cgdisk or {{ic|af00}} in gdisk)<br />
* Since the Arch installation ISO does not include the {{Pkg|hfsprogs}} package, we need to install it in the installation environment before proceeding with formatting the new partition as HFS+<br />
# pacman -Sy hfsprogs<br />
# modprobe hfsplus<br />
# mkfs.hfsplus /dev/sd'''X''' -v "Arch Linux"<br />
<br />
Note: replace /dev/sd'''X''' with the correct device as appropriate<br />
<br />
* Done, proceed with [[#Installation]]<br />
<br />
{{Warning|<br />
Once inside the chrooted enviroment, don’t forget to install the {{Pkg|hfsprogs}} package on the newly installed system as well. After the installation of the package, regenerate the initramfs while chrooted<br />
# mkinitcpio -p linux<br />
}}<br />
<br />
* Once inside the chrooted enviroment, install the {{Pkg|grub}} and {{Pkg|efibootmgr}} packages. The following steps install the GRUB UEFI application to {{ic|/boot/EFI/arch/System/Library/CoreServices/boot.efi}} and install its modules to {{ic|/boot/grub/x86_64-efi}}.<br />
# grub-install --target=x86_64-efi --efi-directory=/boot<br />
<br />
After that, remember to create a standard configuration file:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
As you can see, the directory structure of the {{ic|boot.efi}} is not correct, as the {{ic|/System/Library/CoreServices}} directory is not supposed to be a subdirectory of the {{ic|/boot/EFI/}} folder. For this reason, we need to relocate the {{ic|boot.efi}} stub in a location the MacBook bootloader is able to recognize:<br />
# mv /boot/EFI/arch/System/ /boot/<br />
# rm -r /boot/EFI/<br />
<br />
Also, create a dummy {{ic|mach_kernel}} file<br />
# touch /boot/mach_kernel<br />
<br />
After that, you need to create the following file <br />
<br />
{{hc|1=# nano /boot/System/Library/CoreServices/SystemVersion.plist|2=<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<plist version="1.0"><br />
<dict><br />
<key>ProductBuildVersion</key><br />
<string></string><br />
<key>ProductName</key><br />
<string>Linux</string><br />
<key>ProductVersion</key><br />
<string>Arch Linux</string><br />
</dict><br />
</plist><br />
}}<br />
<br />
At the next reboot, the Apple Boot Manager, shown when holding down the option key when booting the MacBook, should display Arch Linux as a possible boot option. Selecting that option will boot GRUB.<br />
<br />
Done! GRUB can now be selected on the standard MacBook bootloader and you can boot into your newly installed Arch Linux.<br />
<br />
{{Tip| After the installation, it is optionally possible to set a custom icon that will be displayed in the MacBook boot loader. In order to do that, you need to install the {{Pkg|wget}}, {{Pkg|librsvg}} and {{AUR|libicns}} packages. After that, just follow the following commands:<br />
$ wget -O /tmp/archlinux.svg https://www.archlinux.org/logos/archlinux-icon-crystal-64.svg<br />
$ rsvg-convert -w 128 -h 128 -o /tmp/archlogo.png /tmp/archlinux.svg<br />
$ sudo png2icns /boot/.VolumeIcon.icns /tmp/archlogo.png<br />
$ rm /tmp/archlogo.png<br />
$ rm /tmp/archlinux.svg<br />
Obviously, you can replace the Arch logo with any other icon you like.<br />
}}<br />
<br />
=== Other methods ===<br />
<br />
{{Out of date | Section that describes bootloader setup for other setups should be revised and re-structured into more readable way}}<br />
{{Tip|rEFIt is a popular bootloader for EFI-firmware computers (including Macs). It can be installed at any time during the installation. For instructions, please see [[#rEFIt]]. }}<br />
<br />
If you are going for an Arch Linux-only setup, installing the bootloader is no different than on any other machine: Install [[systemd-boot]], [[rEFInd]] or other bootloader of your choice.<br />
<br />
If, on the other hand, you are dual/triple booting, then read on.<br />
<br />
<br />
=== Installing GRUB to EFI partition directly ===<br />
<br />
* If you would like to use GRUB as your main bootloader and use the "boot while holding the Alt/Option key" method to go back to OS X rather than using alternatives such as rEFIt (http://refit.sourceforge.net/, mentioned previously in [[#Option 2: BIOS-compatibility]] and [[#OS X, Windows XP, and Arch Linux triple boot]]) then you must install {{Pkg|grub}} to your Mac's '''already-existing''' EFI partition (see below). <br />
<br />
{{Note| These instructions are known to work on a MacBook Pro (Early 2011). Please read the procedure carefully '''as well as the details following it'''.}}<br />
<br />
{{Note| With a new MacBook Pro (Mid 2014), this procedure worked only after installing the<br />
{{Pkg|efibootmgr}} package.}}<br />
<br />
'''Procedure''':<br />
<br />
* Install {{Pkg|grub}}<br />
<br />
* Make a directory named {{ic|efi}} in {{ic|/boot}} <br />
<br />
* Mount the '''already-existing''' EFI partition on your Mac to this {{ic|/boot/efi}} directory<br />
<br />
* Install GRUB to this directory<br />
<br />
* Make a directory named {{ic| locale}} in {{ic| /boot/grub}}<br />
<br />
* Copy {{ic| grub.mo}} from {{ic| /usr/share/locale/en\@quot/LC_MESSAGES/}} to {{ic| /boot/grub/locale}} <br />
<br />
* Generate a configuration for GRUB<br />
<br />
* Done! GRUB will now start on reboot and you can boot into your newly installed Arch Linux.<br />
<br />
* Remember to hold ALT/Option key '''while''' starting your computer if you want to boot back into OS X.<br />
<br />
'''Details (quoted from [[GRUB EFI Examples#M5A97]]):'''<br />
<br />
Finish the standard Arch install procedures, making sure that you install {{Pkg|grub}} and partition your boot hard disk as GPT.<br />
<br />
From [[GRUB#UEFI systems]]:<br />
<br />
The UEFI system partition will need to be mounted at {{ic|/boot/efi/}} for the GRUB install script to detect it:<br />
<br />
# mkdir -p /boot/efi<br />
# mount -t vfat /dev/sdXY /boot/efi<br />
<br />
Where X is your boot hard disk and Y is the efi partition you created earlier.<br />
<br />
Install GRUB UEFI application to and its modules to {{ic|/boot/grub/x86_64-efi}} using:<br />
<br />
# modprobe dm-mod<br />
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --recheck --debug<br />
# mkdir -p /boot/grub/locale<br />
# cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo<br />
<br />
Generate a configuration for GRUB<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Using blessing ===<br />
<br />
It is possible to boot directly from GRUB in EFI mode without using rEFIt through what is known as "blessing" after placing GRUB on a '''separate partition'''. These instructions are known to work on a MacBook7,1. It is advisable to host GRUB on either a FAT32 or HFS+ partition, but ext2 or ext3 may also work. GRUB's appleloader command does not currently work with the 7,1, but support can be added with the patch available [https://savannah.gnu.org/bugs/index.php?33185 here].<br />
<br />
After the GRUB install is in the desired location, the firmware needs to be instructed to boot from that location. This can be done from either an existing OS X install or an OS X install disk. The following command assumes that the GRUB install is in {{ic|/efi/grub}} on an existing OS X partition:<br />
# bless --folder /efi/grub --file /efi/grub/grub.efi<br />
<br />
=== Compilation ===<br />
<br />
Some models may need EFI_ARCH set to i386.<br />
bzr branch --revision -2 bzr://bzr.savannah.gnu.org/grub/trunk/grub grub<br />
cd grub<br />
./autogen.sh<br />
patch -p1 < appleloader_macbook_7_1.patch<br />
export EFI_ARCH=x86_64<br />
./configure --with-platform=efi --target=${EFI_ARCH} --program-prefix=""<br />
make<br />
cd grub-core<br />
../grub-mkimage -O ${EFI_ARCH}-efi -d . -o grub.efi -p "" part_gpt part_msdos ntfs ntfscomp hfsplus fat ext2 normal chain boot configfile linux multiboot<br />
cp grub.efi *.mod *.lst yourinstalllocation<br />
<br />
== Installation ==<br />
<br />
{{Note|This section is only required if you want to have OS X installed along with Arch Linux. If not, follow the steps in the official install guide, then skip to [[#Post-installation]].}}<br />
<br />
* Boot from the Arch Linux install CD, from the latest [[Archboot]] iso (unofficial), or from a [[USB flash installation media#Using manual formatting|manually created]] bootable USB drive.<br />
{{Note|<br />
* On a MacBookPro7,1, I had an error booting the installation media Version 2012.12.01: "unable to handle kernel NULL pointer dereference at 0000000000000010" during pacpi_set_dmamode. To fix this problem, boot with the option: acpi&#61;off. After chrooting, add MODULES&#61;"ata_generic" into /etc/mkinitcpio.conf and execute mkinitcpio -p linux, see: [[Installation guide#Configure_the_system|Installation Guide, 9 Configure the system]].<br />
* Some MacBook users report strange keyboard output such as long delays and character doubling. To fix this problem, boot with the following options: arch noapic irqpoll acpi&#61;force}}<br />
<br />
* Proceed through the installation as described in the [[Installation guide]] '''except''' in the following areas:<br />
** Skip the [[Installation guide#Partition the disks|partition the disks]] stage, do only the [[Installation guide#Format the partitions|partition formatting]] and [[Installation guide#Mount the partitions|mounting]] steps, taking care to assign the correct partitions. Partitions have already been created if you followed [[#Partitions]]<br />
** '''(for booting with EFI''') After the [[Installation guide#Boot loader|install boot loader]] stage, exit the installer and install [[GRUB]].<br />
** '''(for booting with BIOS-compatibility)''' In the [[Installation guide#Boot loader|install boot loader]] stage, edit the menu.lst file and add '''reboot=pci''' to the end of the '''kernel''' lines, for example: {{bc|1=kernel /vmlinuz-linux root=/dev/sda5 ro reboot=pci}} This will allow your MacBook to reboot correctly from Arch.<br />
** '''(for booting with BIOS-compatibility)''' Also in the [[Installation guide#Boot loader|install boot loader]] stage, install GRUB on whatever partition that {{ic|/boot}} is on. {{Warning|Do not install GRUB onto ''/dev/sda'' !!! Doing so is likely to lead to an unstable post-environment.}}<br />
** In the [[Installation guide#Configure the system|configure system]] stage, edit /etc/mkinitcpio.conf and ensure the '''keyboard''' hook is in the '''HOOKS''' line somewhere after the '''autodetect''' hook. This will load the drivers for your keyboard in case you need to use it before Arch boots (e.g. entering a [[LUKS]] password or using the troubleshooting shell).<br />
<br />
* When the install process is complete, reboot your computer.<br />
<br />
* If using optical media, hold down the eject key as your MacBook starts, this should eject the Arch Linux install disk.<br />
<br />
* If dual-booting OS X and Arch Linux, hold down the alt (option) key while the system boots to use the Mac bootloader to select which OS to boot.<br />
<br />
== Post-installation ==<br />
<br />
{{Style|Duplicated information, does not comply with [[Help:Style]].}}<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials like setting up a graphical user interface, sound or a touchpad.<br />
<br />
==== Video ====<br />
<br />
Different MacBook models have different graphic cards.<br />
To see which graphics card you have type:<br />
<br />
$ lspci | grep VGA<br />
<br />
* If it returns a string containing '''Intel''', read [[Intel graphics]].<br />
<br />
* If it returns '''NVIDIA''', read [[NVIDIA]].<br />
<br />
* Otherwise if it returns '''ATI''' or '''AMD''', read [[ATI]].<br />
<br />
===== NVIDIA note =====<br />
<br />
{{Tip|If you have installed OS in EFI mode and NVIDIA binary drivers are working only in BIOS mode (e.g. you get black screen on EFI boot), try this approach: http://askubuntu.com/a/613573/492886 }}<br />
<br />
For MacBooks with NVIDIA graphics, for the backlight to work properly you may need the {{AUR|nvidia-bl}} package.<br />
<br />
{{Tip|<br />
* If backlight control does not work after installing nvidia-bl, you should [[blacklist]] apple_bl kernel module.<br />
* If backlight control does not work even this way, try setting module parameters. Uncommenting {{ic|1=options nvidia_bl max_level=0x1ffff shift=11}} in {{ic|/etc/modprobe.d/nvidia_bl.conf}} should do the trick.<br />
* Alternatively, you can choose to use the {{AUR|pommed-light}} package. If you do so, you may wish to change the step settings in {{ic|/etc/pommed.conf.mactel}} to something around 5000-10000 depending on how many levels of brightness you desire. The max brightness is around 80000, so take that into account.}}<br />
<br />
==== Touchpad ====<br />
<br />
The touchpad should have basic functionality by default. A true multitouch driver which behaves very similarly to native OS X is included in the {{AUR|xf86-input-mtrack-git}} package. Configuration options are documented in the [https://github.com/BlueDragonX/xf86-input-mtrack readme].<br />
<br />
The following mtrack options work well on a MacBook7,1:<br />
<br />
Option "Thumbsize" "50"<br />
Option "ScrollDistance" "100"<br />
<br />
Probably you need also to add:<br />
<br />
MatchDevicePath "/dev/input/event10"<br />
<br />
To disable tap-to-click (that is, to press down to click) by default, add the following to your mtrack configuration section<br />
<br />
Option "TapButton1" "0" <br />
Option "TapButton2" "0"<br />
Option "TapButton3" "0"<br />
<br />
'''Natural scrolling:''' To configure natural two finger scrolling similar to [http://www.apple.com/au/osx/what-is/gestures.html#gallery-gestures-scroll OS X], refer to [[Touchpad Synaptics#Natural scrolling]].<br />
<br />
If you are using {{AUR|xf86-input-mtrack-git}}, you can simply swap the scroll up and scroll down buttons (along with the scroll left and scroll right):<br />
{{hc|/etc/X11/xorg.conf.d/10-mtrack.conf|<br />
...<br />
Option "ScrollUpButton" "5"<br />
Option "ScrollDownButton" "4"<br />
Option "ScrollLeftButton" "7"<br />
Option "ScrollRightButton" "6"<br />
...}}<br />
<br />
<br />
'''Special Note About Older Macbook Models (confirmed on MacBook2,1):''' On older Macbook models (pre-multitouch), the touchpad will not function properly until you install the xf86-input-synaptics package. Please see [[Touchpad Synaptics]] for more information on installing and configuring this package.<br />
<br />
'''Note on MacBookPro5,5:''' I found it is much simpler to use the {{Pkg|xf86-input-synaptics}} in Extra. Although it does not have much function as 3 finger swipe, this driver provides faster response. {{Pkg|gpointing-device-settings}} also provides a simple GUI config. Below is a Xorg config file /etc/X11/xorg.conf.d/60-synaptics.conf for reference only.<br />
Section "InputClass"<br />
Identifier "touchpad catchall"<br />
Driver "synaptics"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "SHMConfig" "on"<br />
Option "TapButton1" "1"<br />
Option "TapButton2" "3"<br />
Option "TapButton3" "2"<br />
Option "PalmDetect" "on"<br />
Option "VertEdgeScroll" "off"<br />
Option "HorizEdgeScroll" "off"<br />
Option "CornerCoasting" "off"<br />
Option "EdgeMotionUseAlways" "off"<br />
Option "AreaLeftEdge" "10"<br />
Option "AreaRightEdge" "1270"<br />
EndSection<br />
'''For some users, the two-finger right-click may not work correctly and trackpad may also become less responsive after these settings. For me, removing the 'AreaLeftEdge' and 'AreaRightEdge', solved that problem.'''<br />
'''OS X like MultiTouch Gestures''' ''currently broken due to newer synaptic drivers!'' For users looking to add more of OS X's multitouch gestures to Arch, [https://github.com/iberianpig/xSwipe xSwipe] is a highly customisable, light weight perl script, which does just that. Once installed and configured (see xSwipe wiki on Github) I would recommend adding xSwipe as a [[Autostarting|start up item]].<br />
<br />
==== Keyboard ====<br />
<br />
MacBook keyboards work by default. For swaping fn keys with Fx keys see [[Apple Keyboard]].<br />
<br />
To enable it you can map with right application like '''xbindkeys''' or through DE preferences; but another very good way, that we recommend, is to install the {{AUR|pommed-light}} package.<br />
<br />
Edit the {{ic|/etc/pommed.conf}} according to your hardware on MacBook, building it from {{ic|/etc/pommed.conf.mac}} or {{ic|/etc/pommed.conf.ppc}} example files.<br />
<br />
Note that you can also run it without a configuration file, the defaults may work for you. Then [[enable]] and start {{ic|pommed.service}}.<br />
<br />
{{Tip|if you are using Gnome or KDE you can easily configure ''3rd level functionality'', ''multimedia key'', etc. in Keyboard Preferences.}}<br />
<br />
{{Note|See the [[Xorg input hotplugging]] page for other configuration information.}}<br />
<br />
===== Keyboard Backlight =====<br />
<br />
The keyboard backlight is controlled by {{ic|/sys/class/leds/smc::kbd_backlight}}. Write the desired value to {{ic|brightness}} in that directory.<br />
<br />
Both {{AUR|acpilight}} or {{AUR|kbdlight}} allow to control keyboard backlight though scripts. With the appropriate udev rules or [[sxhkd]] they allow light-level changes without being root.<br />
<br />
====== NVIDIA note ======<br />
<br />
If the brightness does not function correctly through pommed, make sure you have installed the {{AUR|nvidia-bl}} package and insert<br />
<br />
find . -name "*" -exec sed -i 's/mbp_backlight/nvidia_backlight/' '{}' \;<br />
<br />
into the second line of the pommed PKGBUILD build() function and remake the package. From [https://bbs.archlinux.org/viewtopic.php?id=105091 this forum post].<br />
<br />
Another possible solution is to modify the pommed PKGBUILD build():<br />
<br />
find . -name "*" -exec sed -i 's/nvidia_backlight/apple_backlight/' '{}' \;<br />
<br />
If the previous does not work try the following,<br />
<br />
run nvidia-settings, edit the file '/etc/X11/xorg.conf' and add this line into the Device section:<br />
<br />
Option "RegistryDwords" "EnableBrightnessControl=1"<br />
Save and reboot and check backlight buttons work.<br />
More information available at [https://help.ubuntu.com/community/MacBookPro5-5/Precise#LCD Ubuntu MacBookPro5,5]<br />
<br />
=== Wi-Fi ===<br />
<br />
Different MacBook models have different wireless cards.<br />
<br />
You can easily check what card do your MacBook have by:<br />
<br />
# lspci | grep Network<br />
<br />
* If you have an Atheros card, all should work out-of-the-box.<br />
<br />
* If you have a Broadcom card, follow the [[Broadcom wireless]] page.<br />
<br />
* 5.0 and 6.0 generation MacBooks may have a BCM43xx, follow the instructions for the broadcom-wl driver on the [[Broadcom wireless]] page. The interfaces can swap during reboot so its best to define them in a udev rule (instructions on the [[Broadcom wireless]] page).<br />
<br />
* 8.1 generation MacBooks have BCM4331, for which support is not present in either Linux (3.0 and 3.1) or the proprietary drivers by Broadcom. There is however preliminary support for it in Linux 3.2. To run the drivers on earlier kernels, you will need to use [https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers compat-drivers]<br />
<br />
* If you have the correct broadcom DKMS driver (i.e. broadcom-wl-dkms) installed and your wifi card is still not being recognised, try rebuilding the driver (See [[Dynamic Kernel Module Support]]).<br />
<br />
{{Note|<br />
* If your connection frequently drops, you may have to turn off Wi-Fi power management. If you are running [[pm-utils]], you may override wireless power management by creating an executable file {{ic|/etc/pm/wireless}} with the lines:<br />
#!/bin/sh<br />
iwconfig wlp2s0 power off<br />
* Eduroam or similar may crash your network manager. Simply delaying the connection after login should do the trick<br />
}}<br />
<br />
=== Power management ===<br />
<br />
[[Powerdown]] is a very simple to set up set of scripts what will maximize your battery duration. A MacBook Air 2013 with powerdown provides about 11 hours of light usage with just powerdown installed.<br />
All the usual [[power management]] recomendations apply as well.<br />
<br />
Adding 'acpi_osi=' to kernel parameters reportedly brings the battery life of a MacBook Air 2013 from 5 hours to 11-12 hours. See [https://bbs.archlinux.org/viewtopic.php?pid=1530283#p1530283 this forum post] for more information.<br />
<br />
==== Suspend and Hibernate ====<br />
<br />
Suspending (suspend to ram) and hibernating (suspend to disk) work fine out of the box:<br />
<br />
systemctl suspend<br />
<br />
Issues were reported where the machine would "suspend immediately after resume" in certain conditions when suspending by closing the lid. This was solved by setting the option "sleep-inactive-ac-type" to "nothing" using dconf-editor, option path: org &rarr; gnome &rarr; settings-daemon &rarr; plugins &rarr; power).<br />
<br />
See [[Suspend and hibernate]] for details on how to configure hibernation. Noticably, you'll need a swap partition or file (see the mentioned article for further instructions).<br />
<br />
If after suspend laptop is woken up after few seconds, may help to disable all stuff in /proc/acpi/wakeup, exclude LID0:<br />
# echo XHC1 > /proc/acpi/wakeup<br />
$ cat /proc/acpi/wakeup<br />
Device S-state Status Sysfs node<br />
P0P2 S3 *disabled<br />
EC S3 *disabled<br />
HDEF S3 *disabled pci:0000:00:1b.0<br />
RP01 S3 *disabled pci:0000:00:1c.0<br />
RP02 S3 *disabled pci:0000:00:1c.1<br />
RP03 S3 *disabled pci:0000:00:1c.2<br />
ARPT S4 *disabled pci:0000:03:00.0<br />
RP05 S3 *disabled pci:0000:00:1c.4<br />
RP06 S3 *disabled pci:0000:00:1c.5<br />
SPIT S3 *disabled<br />
XHC1 S3 *disabled pci:0000:00:14.0<br />
ADP1 S3 *disabled<br />
LID0 S3 *enabled<br />
And for permanent disabling:<br />
$ cat /etc/udev/rules.d/90-xhc_sleep.rules <br />
<br />
# disable wake from S3 on XHC1<br />
SUBSYSTEM=="pci", KERNEL=="0000:00:14.0", ATTR{power/wakeup}="disabled"<br />
<br />
If this does not work, check that ARPT is disabled, and add a corresponding rule to udev, like this:<br />
<br />
SUBSYSTEM=="pci", KERNEL=="0000:03:00.0", ATTR{power/wakeup}="disabled"<br />
<br />
If this still does not work, try disabling LID0.<br />
This way suspending via lid-closing should be made impossible, so you might want to follow the instructions in [https://bbs.archlinux.org/viewtopic.php?pid=1556046#p1556046 this forum post] to make suspending via both lid-closing and systemd possible, by using systemd services.<br />
<br />
=== Light sensor ===<br />
<br />
The values can be read from:<br />
<br />
/sys/devices/platform/applesmc.768/light<br />
<br />
A "cat" on this path returns two-tuples like (4,0). The below referenced lighter script ignores the second value - which always seems to be 0 - and uses the first number as measured environment lighting brightness value.<br />
<br />
If you want to use the built in light sensor to automatically adjust screen and keyboard backlight brightness check out<br />
'''Lighter''' [https://github.com/Janhouse/lighter] (simple perl script, easy to fine-tune) and '''Lightum''' [https://github.com/poliva/lightum] (Requires Gnome or KDE but is older and more complete than Lighter).<br />
<br />
=== Sound ===<br />
<br />
{{Tip| If using [[ALSA]], the internal speaker might not be disabled when using the headphone jack. To solve this, enable "Auto-mute" using {{ic|alsamixer}}}}<br />
<br />
First of all follow [[ALSA]] wiki page, then if something does not work correctly, continue reading this part.<br />
<br />
Edit your {{ic|/etc/modprobe.d/50-sound.conf}} or {{ic|/etc/modprobe.d/modprobe.conf}} appending this line:<br />
<br />
options snd_hda_intel model=intel-mac-auto<br />
<br />
This should automatically specify the codec in your MacBook. If you have a MacBookPro12,1, you might need<br />
<br />
options snd-hda-intel index=1,0<br />
<br />
instead. Alternatively, for MacBookPro5,X, you can use:<br />
<br />
options snd_hda_intel model=mb5<br />
<br />
(note that the jack output is controlled with "HP").<br />
<br />
If you have an iMac8,1, you should instead use<br />
<br />
options snd-hda-intel model=mbp3 position_fix=2<br />
<br />
You can try to specify other options, that depend on your hardware. All other possible settings are listed in Kernel Documentation, avaible online:<br />
<br />
* [http://www.kernel.org/doc/Documentation/sound/alsa/ALSA-Configuration.txt ALSA-Configuration.txt]<br />
* [http://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio.txt HD-Audio.txt]<br />
* [http://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio-Models.txt HD-Audio-Models.txt].}}<br />
<br />
Then, reboot.<br />
<br />
=== Bluetooth ===<br />
<br />
Bluetooth should work out-of-the box. See the article on [[Bluetooth]] to install and configure all software needed.<br />
<br />
=== Magic Mouse ===<br />
<br />
If you use a magic mouse you will find it works nicely out of the box. You might want to tweak some settings such as ''scroll-speed'' or ''acceleration''. There is no GUI for this at this time. The only way to set these settings is to instruct the kernel driver ({{ic|hid_magicmouse}}) with parameters. Create a modprobe config file for your mouse.<br />
<br />
{{hc|1=/etc/modprobe.d/magicmouse.conf|2=<br />
options hid_magicmouse scroll-speed=55 scroll-acceleration=1 emulate_3button=0<br />
}}<br />
<br />
<br />
This will instruct the driver to have a fast scroll-speed, do exponential acceleration and do not emulate a 3 button mouse. You can find an overview of all parameters and their current settings in {{ic|/sys/module/hid_magicmouse/parameters}}.<br />
<br />
To play with the settings without rebooting you can also set them through the command line, like so: <br />
<br />
# echo 55 | sudo tee /sys/module/hid_magicmouse/parameters/scroll_speed<br />
<br />
{{Note|Using kernel ''4.10.10-1-macbook'' the Magic Mouse (''hid_magicmouse'') will cause a lot of system lock ups. If you experience random lock ups, try a different, wired, mouse to see if this is the case for you as well.}}<br />
<br />
=== Webcam ===<br />
<br />
==== iSight ====<br />
<br />
{{Note|Linux kernel from 2.6.26 includes the Linux UVC driver natively. '''MBP 6,2+ (Kernel ~2.6.37+) iSight works out of the box''' without the need to use firmware from OS X. Only use {{ic|isight-firmware-tools}} if it doesn't work normally.}}<br />
<br />
iSight webcams on MacBooks or pre 6,2 MacBook Pros (6,2 came out around 2010) require the Apple's proprietary firmware that cannot be redistributed. It must be extracted from OS X and loaded onto Arch.<br />
<br />
You will need to install {{AUR|isight-firmware-tools}} to extract the firmware. This package also includes a udev rule and ELF binary that are necessary, even once you have extracted the firmware file into {{ic|/lib/firmware/isight.fw}}, for the file to be loaded every time you boot your computer (namely {{ic|/etc/udev/rules.d/isight.rules}} which uses {{ic|/usr/lib/udev/ift-load}}).<br />
<br />
Instructions:<br />
<br />
First you need to get the firmware out of a particular file located on your OS X install. It is located in {{ic|/System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBVideoSupport.kext/Contents/MacOS/AppleUSBVideoSupport}}.<br />
<br />
{{ Tip | The {{ic|AppleUSBVideoSupport}} file from a OS X 10.6 (Snow Leopard) installation may not work properly. If possible, use the file from OS X 10.5 or earlier.}}<br />
<br />
To mount the OS X drive if multi-booting:<br />
<br />
# sudo mkdir /media/OSX<br />
# sudo mount -t hfsplus /dev/sda2 /media/OSX<br />
<br />
Then, install the {{AUR|isight-firmware-tools}} package.<br />
<br />
Locate the {{ic|AppleUSBVideoSupport}} file in the OS X directory listed above. Either copy it over to your Arch system (Any OS X installation should do, such as an iMac, not just one specific to your system) or, if multi-booting, mount the OS X drive and navigate to the directory. (On 10.7 (Lion) the directory is {{ic|/System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBVideoSupport.kext/Contents/MacOS}}.) In that directory you can go ahead and extract the driver:<br />
<br />
# ift-extract --apple-driver AppleUSBVideoSupport<br />
<br />
When it's done, check that the firmware has been found:<br />
<br />
# ls /lib/firmware/isight.fw<br />
<br />
Once successful, completely '''SHUTDOWN''' your Mac and start it back up again (to clear the hardware state of the webcam). Do ''not'' reboot.<br />
<br />
It should be automatically loaded at boot; if it isn't you can load the '''uvcvideo''' module [[Kernel modules|manually or load it at boot]].<br />
<br />
You can use many applications to test the webcam:<br />
<br />
* MPlayer<br />
<br />
# mplayer tv:// -tv driver=v4l2:width=320:height=240:device=/dev/video0 -fps 30<br />
<br />
* Cheese<br />
* Skype<br />
* Ekiga<br />
<br />
A simple solution to take snapshots is:<br />
<br />
# mplayer tv:// -vf screenshot<br />
<br />
and the pressing the s key to take a snapshot. Files are of the format {{ic|shot\d\d\d\d.png}} and are reported in the standard output.<br />
<br />
==== Facetime HD ====<br />
According to Apple, all recent MacBook models contain a Facetime HD camera instead of the iSight. The following list is an example:<br />
* iMac (21,5" mid 2011)<br />
* iMac (27" mid 2011)<br />
* MacBook Air (mid 2011)<br />
* MacBook Pro (15" early 2011)<br />
* MacBook Pro (17" early 2011)<br />
* MacBook Pro (13" early 2011)<br />
If your MacBook is more recent than the models listed above, it is likely equipped with the Facetime HD camera as well.<br />
<br />
In order to make the camera work, you need to install the {{AUR|bcwc-pcie-dkms}} and {{AUR|bcwc-pcie-firmware}}{{Broken package link|package not found}} packages. This will enable camera video support through the {{ic|facetimehd}} kernel module.<br />
<br />
In order to verify if the Facetime camera is working after the installation of both packages, you'll need to reboot your system.<br />
<br />
{{Note|Keep in mind that, although working, this is a reverse-engineered driver. PC suspension is not supported if a program that is keeping the camera active is running.}}<br />
<br />
=== Temperature Sensors ===<br />
<br />
For reading temperature just install {{Pkg|lm_sensors}}. See the [[lm_sensors]] page for more information.<br />
<br />
=== Color Profile ===<br />
<br />
We can use color profiles from OS X.<br />
<br />
First, install the {{AUR|xcalib}} package.<br />
<br />
Second copy pre-saved color profiles placed in {{ic|/Library/ColorSync/Profiles/Displays/}} on OS X partition to {{ic|~/colorprofiles/}} for example.<br />
<br />
There are color profile files agree with in MacBook models; select the right one:<br />
<br />
* '''Color LCD-4271800.icc''' for MacBook Pro with CoreDuo CPU<br />
* '''Color LCD-4271880.icc''' for MacBook with Core2Duo<br />
* '''Color LCD-4271780.icc''' for MacBook (non-Pro) based on CoreDuo or Core2Duo.<br />
<br />
{{Tip|Also OS X allows to save current color profile from ''Displays > Color'' section of the ''Mac OS System Preferences'', in this case file is saved to {{ic|/Users/<username>/Library/ColorSync/Profiles}}.}}<br />
<br />
Finally you can activate it by running<br />
<br />
# xcalib ~/colorprofile.icc<br />
<br />
{{Note|Previous command set the color profile only for the current session; this mean that you must run it every time you login in your system. For automating it you can execute the command by '''Autostart Application''', concording with your DE (or add the command to your login manager's initialization script, e.g. /etc/gdm/Init/Default).}}<br />
<br />
{{Warning|GNOME will revert the profile set by xcalib. It's preferable to set the profile using '''Color''' in settings.}}<br />
<br />
=== Apple Remote ===<br />
<br />
First, to correctly install and configure the '''lirc''' software that control IR see [[LIRC]] wiki.<br />
<br />
Then make LIRC use {{ic|/dev/usb/hiddev0}} (or {{ic|/dev/hiddev0}}) by editing {{ic|/etc/conf.d/lircd}}. Here is how mine look:<br />
<br />
#<br />
# Parameters for lirc daemon<br />
#<br />
LIRC_DEVICE="/dev/usb/hiddev0"<br />
LIRC_DRIVER="macmini"<br />
LIRC_EXTRAOPTS=""<br />
LIRC_CONFIGFILE="/etc/lirc/lircd.conf"<br />
<br />
Use '''irrecord''' (available when installing '''lirc''') to create a configuration file matching your remote control signals (alternatively, you can try to use the {{ic|lircd.conf}} below):<br />
<br />
# irrecord -d /dev/usb/hiddev0 -H macmini output_conf_file<br />
<br />
Start '''lircd''' and use '''irw''' to check if it works.<br />
<br />
Example of an {{ic|/etc/lirc/lircd.conf}}:<br />
<br />
begin remote<br />
<br />
name lircd.conf.macbook<br />
bits 8<br />
eps 30<br />
aeps 100<br />
<br />
one 0 0<br />
zero 0 0<br />
pre_data_bits 24<br />
pre_data 0x87EEFD<br />
gap 211994<br />
toggle_bit_mask 0x87EEFD01<br />
<br />
begin codes<br />
Repeat 0x01<br />
Menu 0x03<br />
Play 0x05<br />
Prev 0x09<br />
Next 0x06<br />
Up 0x0A<br />
Down 0x0C<br />
end codes<br />
<br />
end remote<br />
<br />
=== HFS partition sharing ===<br />
<br />
First, install the {{Pkg|hfsprogs}} package. <br />
<br />
we have to list our partitions. Use<br />
<br />
fdisk -l /dev/sda<br />
<br />
example output:<br />
<br />
# fdisk -l /dev/sda<br />
Device Boot Start End Blocks Id Type<br />
/dev/sda1 1 26 204819 ee GPT<br />
/dev/sda2 26 13602 109051903+ af Unknown<br />
/dev/sda3 * 13602 14478 7031250 83 Linux<br />
/dev/sda4 14478 14594 932832+ 82 Linux swap / Solaris<br />
<br />
As we see, the "Unknown" partition is our OS X partition, which is located in {{ic|/dev/sda2}}.<br />
<br />
Create a "mac" folder in /media:<br />
<br />
# mkdir /media/mac<br />
<br />
Add at the end of ''/etc/fstab'' this line:<br />
<br />
/dev/sda2 /media/mac hfsplus auto,user,rw,exec 0 0<br />
<br />
Mount it :<br />
<br />
mount /media/mac<br />
<br />
and check it:<br />
<br />
ls /media/mac<br />
<br />
=== HFS+ Partitions ===<br />
<br />
==== Journaling ====<br />
<br />
HFS+ partitions, now the default in OS X, are not fully supported by Linux and are mounted as read-only by default. In order to write to an HFS+ partition, the safe way is to disable journaling. This can be accomplished using the OS X Disk Utility. Refer to this [http://support.apple.com/kb/ht2355 Apple support page] for more information or try to do it from the command line:<br />
<br />
Find your partition:<br />
<br />
$ diskutil list<br />
/dev/disk0<br />
#: TYPE NAME SIZE IDENTIFIER<br />
0: GUID_partition_scheme *750.2 GB disk0<br />
1: EFI EFI 209.7 MB disk0s1<br />
2: Apple_HFS OSX 149.5 GB disk0s2<br />
3: Apple_HFS Macintosh HD 599.2 GB disk0s3<br />
4: Apple_Boot Recovery HD 650.0 MB disk0s4<br />
<br />
In this example we will use ''disk0s3'' partition named as ''Macintosh HD''. To know if journaling is activate or not you could execute:<br />
<br />
$ diskutil info /dev/disk0s3 | grep -i journal<br />
File System Personality: Journaled HFS+<br />
Name (User Visible): Mac OS Extended (Journaled)<br />
Journal: Journal size 49152 KB at offset 0x1176000<br />
<br />
As you can read the journaling is active. To turn off the journaling you could execute:<br />
<br />
$ sudo diskutil disableJournal disk0s3<br />
Password:<br />
Journaling has been disabled for volume Macintosh HD on disk0s3<br />
<br />
To verify it is done execute the info command again:<br />
<br />
$ diskutil info /dev/disk0s3 | grep -i journal<br />
<br />
If you get noting as output, then journaling is disabled.<br />
<br />
However, if you fail to disable journaling. You can change "auto,user,rw,exec" in {{ic|/etc/fstab}} to "auto,user,force,rw,exec" and mount it.<br />
<br />
====Yosemite and later====<br />
<br />
Since Yosemite, HFS+ partitions are now wrapped a CoreStorage volume. Verify that you have an CoreStorage volume.<br />
<br />
# fdisk -l /dev/sdX<br />
Disk /dev/sdX: 298.1 GiB, 320072933376 bytes, 625142448 sectors<br />
Units: sectors of 1* 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 4096 bytes<br />
I/O size (minimum/optimal): 4096 bytes / 4096 bytes<br />
Disklabel type: gpt<br />
Device Start End Sectors Size Type<br />
/dev/sdX1 40 409639 409600 200M EFI System<br />
/dev/sdX2 409640 623872871 623463232 297.3G Apple Core storage<br />
/dev/sdX3 623872872 625142407 1269536 916.0M Apple boot<br />
<br />
HFS+ uses two volume headers, one 1024 bytes into the device and one 1024 from the end of the device. With the HFS+ partition wrapped in the CoreStorage volume the end of the partition is not actually 1024 bytes from the end of the {{ic|/dev/sdX2}} partition.<br />
To fix this you need to specify {{ic|1=sizelimit=X}} when mounting.<br />
<br />
To determine {{ic|sizelimit}} do the following:<br />
<br />
# Run {{ic|testdisk /dev/sdX}} and select your drive<br />
# Select {{ic|EFI GPT}}<br />
# Select {{ic|Analyse}} and then {{ic|Quick Search}}<br />
<br />
Sample output:<br />
TestDisk 7.0, Data Recovery Utility, April 2015<br />
Christophe GRENIER <grenier@cgsecurity.org><br />
http://www.cgsecurity.org<br />
<br />
Disk /dev/sdX - 320 GB / 298 GiB - CHS 38913 255 63<br />
Partition Start End Size in sectors<br />
P EFI System 40 409639 409600 [EFI]<br />
P Mac HFS 409640 623147815 622738176<br />
P Mac HFS 623872872 625142407 1269536<br />
<br />
What you see now is the output of the HFS partition itself without the CoreStorage volume. Take the size in sectors (622738176 in this example) and multiply by the number of bytes in your logical sector size (512 in this example).<br />
<br />
622738176 * 512 = 318841946112<br />
<br />
Finally, mount your disk with the {{ic|1=sizelimit=X}} option.<br />
<br />
mount /dev/sdX -t hfsplus -o ro,sizelimit=318841946112<br />
<br />
===Home Sharing===<br />
<br />
'''''UID Synchronization'''''<br />
<br />
==== In OS X ====<br />
<br />
{{Note|It is strongly recommended that UID/GID manipulation be done immediately after a new user account is created, in OS X as well as in Arch Linux. If you installed OS X from scratch, then this operation is guaranteed to work after logging into your account for the first time.}}<br />
<br />
===== Step 1: change UID and GID(s) =====<br />
<br />
'''''Pre-Leopard'''''<br />
<br />
# Open '''NetInfo Manager''' located in the ''/Applications/Utilities'' folder.<br />
# If not done for you already, enable access to user account transactions by clicking on the closed lock at the bottom of the window, and entering your account password, or root password if you have created a root account.<br />
# Navigate to ''/users/<new user name>'' where <new user name> is the name of the account that will have read/write access to the folder that will be shared with the primary user in Arch.<br />
# Change the '''UID''' value to 1000 (the value used by default for first user created in Arch).<br />
# Also change the '''GID''' value to 1000 (the value used by default for user account creation in Arch).<br />
# Navigate to {{ic|/groups/<new user name>}}, automatically saving the changes you have made so far.<br />
<br />
{{Note|If you get an error message that the transaction is not allowed, log out and log back in.}}<br />
<br />
'''''Leopard'''''<br />
<br />
In Leopard, the '''NetInfo Manager''' application is not present. A different set of steps is required for UID synchronization:<br />
<br />
# Open '''System Preferences'''.<br />
# Click on '''Users & Groups'''.<br />
# Unlock the pane if not already done so.<br />
# Right-click on the desired user and select '''Advanced Options'''.<br />
# Write down the value of the '''User ID''' field, you will need it later on. Change both the UID and GID to match the UID and GID of the account wished to be shared with in Arch (1000 by default for the first user created in Arch).<br />
<br />
===== Step 2: change "Home" permissions =====<br />
<br />
# Open up '''Terminal''' in the {{ic|/Applications/Utilities}} folder.<br />
<br />
# Enter the following command to reclaim the permission settings of your home folder, replacing <your user name>, <your user group> and <your old UID> with the user name whose UID and GID values you just changed, the group name whose GID value you just changed and the old UID number, respectively.<br />
<br />
# find /User/<your user name> -user <your old UID> -exec chown <your user name>:<your user group> {} \;<br />
<br />
==== In Arch ====<br />
<br />
To synchronize your UID in Arch Linux, you are advised to perform this operation ''while creating a new user account''.<br />
It is therefore recommended that you do this as soon as you install Arch Linux.<br />
<br />
Now you must substitute Arch's home with OS X's home, by modify entries of {{ic|/etc/fstab}}.<br />
<br />
=== Avoid long EFI wait before booting ===<br />
<br />
If your MacBook spends 30 seconds with "white screen" before booting you need to tell the firmware where is the booting partition.<br />
<br />
Boot OS X, if do not have it installed, you can use the install DVD (select language, then click Utilities->Terminal), or another MacBook with OS X (connect the two computers via firewire or thunderbolt, start the other MacBook keeping pressed T, boot your MacBook keeping pressed Options).<br />
<br />
Either way, once you got a OS X terminal running on your MacBook you need to execute, as root, a different command if the boot partition is EFI or it is not:<br />
<br />
# bless --device /dev/disk0s1 --setBoot # if the booting partition is EFI<br />
or<br />
# bless --device /dev/disk0s1 --setBoot --legacy # if the booting partition is not EFI<br />
<br />
(given that if your GRUB or EFI is on sda1, /dev/disk1s2 if it is on sdb2, etc). See also https://bbs.archlinux.org/viewtopic.php?pid=833215 and https://support.apple.com/kb/HT1533 .<br />
<br />
=== Mute startup chime ===<br />
<br />
The startup chime volume is controlled by the EFI variable ''SystemAudioVolume-7c436110-ab2a-4bbb-a880-fe41995c9f82''. So it can be muted with<br />
<br />
# printf "\x07\x00\x00\x00\x00" > /sys/firmware/efi/efivars/SystemAudioVolume-7c436110-ab2a-4bbb-a880-fe41995c9f82<br />
<br />
Alternatively, you can use a OS X install disk to mute the chime. Boot from it, select language, then click ''Utilities > Terminal'', and enter<br />
<br />
# /usr/sbin/nvram SystemAudioVolume=%01<br />
<br />
(or whatever volume you want).<br />
<br />
{{Note|Required formatting of the value provided for key SystemAudioVolume may differ depending on MacBook model and perhaps the version of OS X install media. If the above command fails to work, try enclosing the value in double quotes.}}<br />
<br />
=== kworker using high CPU ===<br />
Sometime with the addition of Yosemite, some users found that kworker CPU usage will spike, as disccused [https://bbs.archlinux.org/viewtopic.php?id=171883&p=11 here]. This is sometimes the result of runaway ACPI interrupts.<br />
<br />
To check and see, you can count the number of recent ACPI interrupts and see if any of them are out of control.<br />
<br />
grep . -r /sys/firmware/acpi/interrupts/<br />
<br />
<br />
If you see that one particular interrupt is out of control (possibly GPE66), i.e., registering hundreds of thousands of lines, you can try disabling it (replace XX with the runaway interrupt):<br />
<br />
<br />
echo "disable" > /sys/firmware/acpi/interrupts/gpeXX<br />
<br />
<br />
Disabling random ACPI interrupts could cause all kinds of problems, so do this at your own risk. If this fixes the problem, there is discussion about how to make a systemd service that automatically disables an interrupt at every boot [https://bbs.archlinux.org/viewtopic.php?pid=1488371 here].<br />
<br />
== rEFIt ==<br />
<br />
{{Note|<br />
* You probably want to have a look at [http://www.rodsbooks.com/refind/ rEFInd], which is some type of successor of rEFIt.<br />
* This is not a requirement. It only gives you a menu to choose between OS X and Arch Linux upon every boot.<br />
}}<br />
<br />
For more see, [http://refit.sourceforge.net/myths/ rEFIt myths].<br />
<br />
In OS X, download the ".dmg" from [http://refit.sourceforge.net/ rEFIt Homepage] and install it.<br />
<br />
{{Note|If you have already partitioned your hard disk in preparation for the Arch installation, rEFIt may not be enabled by default. You will have to run the "enable.sh" script installed in /efi/refit/.}}<br />
<br />
Open up '''Terminal''' and enter:<br />
<br />
cd /efi/refit;<br />
./enable.sh<br />
<br />
=== Problems with rEFIt ===<br />
<br />
If you experience problems after the install of Arch or rEFIt, especially is the right OS is not showing up to boot to or if it dumps you at a GRUB prompt stuck like the following:<br />
<br />
GRUB>_<br />
<br />
Then have a look at this link:<br />
<br />
http://mac.linux.be/content/problems-refit-and-grub-after-installation<br />
<br />
It can give you a basic idea on how to boot off the Arch live cd, mount the problem Arch install, chroot, use gptsync, and reinstall GRUB. This is probably for more advanced users who can translate the commands from a debian system to an Arch system and also apply it to the partitions on their machine. Be careful not to install GRUB in the wrong spot.<br />
<br />
If you need a copy of gptsync you can wget it from here:<br />
http://packages.debian.org/sid/gptsync<br />
or try these, for 64 bit:<br />
<br />
wget http://ftp.us.debian.org/debian/pool/main/r/refit/gptsync_0.14-2_amd64.deb<br />
<br />
and for i386:<br />
<br />
wget http://ftp.us.debian.org/debian/pool/main/r/refit/gptsync_0.14-2_i386.deb<br />
<br />
since they are .deb packages you will need the program {{AUR|deb2targz}}.<br />
<br />
==== Mavericks upgrade breaks Arch boot option ====<br />
For some multi-boot users who utilize a separate Linux boot partition, the OS X Mavericks upgrade may overwrite the boot partition with Apple's own recovery boot filesystem. This breaks the Arch Linux boot option in rEFIt/rEFInd. The best way to proceed in this situation is to abandon a separate boot partition and use the EFI system partition (ESP) to install the bootloader of your choice. It is also recommended that you use rEFInd instead of rEFIt as development on the latter has halted.<br />
<br />
Assuming grub2 as the bootloader:<br />
<br />
Use the Arch LiveCD to boot to a shell and [[Change root|chroot]] to your broken Arch Linux environment.<br />
<br />
Mount the ESP on /boot.<br />
<br />
Edit the fstab and remove the old boot partition and make ESP the new boot partition. Now mount the ESP as the new /boot parition.<br />
# mount -a<br />
<br />
[[install|Reinstall]] the {{pkg|linux}} package.<br />
<br />
Create a new initramfs and vmlinuz in /boot.<br />
# mkinitcpio -p linux<br />
<br />
Install grub.<br />
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub --recheck --debug<br />
<br />
Create a new grub.cfg file.<br />
# grub-mkconfig -o /boot/EFI/grub/grub.cfg<br />
<br />
Make sure that grub.cfg is in the same directory as grubx64.efi.<br />
<br />
Generate a new refind_linux.conf file in /boot simply by running mkrlconf.sh which comes with rEFInd.<br />
<br />
Exit the chroot environment.<br />
<br />
Reboot. You should see a new entry for Arch Linux in rEFInd and it should boot to your Arch Linux installation.<br />
<br />
== Model-specific information ==<br />
<br />
=== MacBook ===<br />
<br />
==== April 2016 12" - Version 9,1 ====<br />
<br />
* Booting from USB via EFI works fine, when giving the {{ic|noapic}} kernel option. (On Ubuntu, also {{ic|noacpi nomodeset}} seem to be necessary.) Remember to hold the Alt key on booting.<br />
<br />
* The wireless card works out of the box with {{ic|brcmfmac}}.<br />
<br />
* Suspend / hibernate does not work.<br />
<br />
* The built-in flash drive does ''not'' work with kernel 4.5.4-1-ARCH, but it ''does'' work with kernel 4.6.0-mainline (install {{AUR|linux-mainline}}). As long as a [http://lists.infradead.org/pipermail/linux-nvme/2016-May/004618.html rather trivial patch] is not merged into the kernel, either this patch must be applied locally or one puts {{ic|modprobe nvme; echo 106b 2003 > /sys/bus/pci/drivers/nvme/new_id}} into a mkinitcpio hook (to be started after the udev hook). The reason is that the NVMe controller of the flash drive doesn't advertise itself with the correct PCI device class. Note that with the patch, a short sleep still seems to be necessary.<br />
<br />
* Audio recording works out of the box. Audio playback doesn't work (still looking for a solution).<br />
<br />
* The keyboard and the touchpad do ''not'' work (still looking for a solution).<br />
** There's a WIP driver [https://github.com/cb22/macbook12-spi-driver here] that sort of works with a DSDT hack (the previous problem with this driver related to battery drain has been fixed now).<br />
** The keyboard backlight cannot be enabled [https://bbs.archlinux.org/viewtopic.php?id=219631]<br />
<br />
==== Mid 2007 13" - Version 2,1 ====<br />
<br />
{{Note|I used the 201212 ISO image.}}<br />
<br />
Since older Macbooks have a 32bit EFI running, the usual installation image is not recognized. You need to either remove the UEFI support from the disc ([[Unified_Extensible_Firmware_Interface#Remove_UEFI_boot_support_from_ISO]]) or build a 32bit EFI version of the disc. The paragraphs below will take the first path to success, booting into BIOS mode and its pitfalls. For a try the other way round, read [[Unified_Extensible_Firmware_Interface#Create_UEFI_bootable_USB_from_ISO]] first.<br />
<br />
First prepare your harddisc according to your wishes. In this scenario it was a "Linux only" approach with<br />
<br />
/dev/sda1 HFS+ AF00 200M -> EFI boot system on Apple HFS+ partition<br />
/dev/sda2 ext4 8300 147G -> arch system<br />
/dev/sda3 swap 8200 1G -> swap<br />
<br />
The {{Pkg|hfsprogs}} package contains the tools to handle HFS/HFS+ filesystems. The rEFInd bootloader recognizes it on its own. Usually the partition for the EFI bootloader is a FAT32 (vfat) partition. In this case I tried rEFIt first, which apparently needs the HFS+ filesystem to work, and kept it at that.<br />
<br />
The mount points are:<br />
<br />
/dev/sda2 -> /<br />
/dev/sda1 -> /boot<br />
<br />
The bootloader in use was [http://www.rodsbooks.com/refind/index.html rEFInd] instead of rEFIt. To install it, the rEFInd homepage provides a good guide. Usually it is simply done by copying rEFInd:<br />
<br />
mkdir /boot/EFI<br />
cp -vr /usr/share/refind/drivers_ia32 /boot/EFI/refind/<br />
cp -vr /usr/share/refind/tools_ia32 /boot/EFI/refind/<br />
cp -vr /usr/share/refind/fonts /boot/EFI/refind/<br />
cp -vr /usr/share/refind/icons /boot/EFI/refind/<br />
cp -v /usr/share/refind/refind_ia32.efi /boot/EFI/refind/<br />
cp -v /usr/share/refind/refind.conf-sample /boot/EFI/refind/refind.conf<br />
cp -v /usr/share/refind/refind_linux.conf-sample /boot/refind_linux.conf<br />
<br />
{{Note|I'm using the 32bit version of Arch and refind, since the EFI of the old MacBooks is 32bit. I'm not sure about 32bit rEFInd booting a 64bit Arch...}}<br />
<br />
The pitfall here is, that the system bootet in BIOS compatibility mode and not in EFI mode. You cannot therefore use {{ic|efibootmgr}}, because the EFI variables (even with 'modprobe efivars') are not available. While installing the system get {{AUR|mactel-boot}}. The {{ic|hfs-bless}} utility comes in handy, when blessing the EFI bootloader. This is done by calling:<br />
<br />
hfs-bless /boot/EFI/refind/refind_ia32.efi<br />
<br />
Since the Linux kernel does come with EFI stub enabled, it seems a good idea to run it through a bootloader first. Especially if it runs not out of the box. But using rEFInd makes GRUB (or any other bootloader) obsolete, because of that.<br />
<br />
{{Note|In the refind_linux.conf you add any kernel option you may want as long as you use the EFI stub of your kernel. In refind.conf you adjust your needs for the bootloader itself, like menu entries. If you use them (menu entries), rEFInd should not look for these EFI stub kernels itself, so blacklist the directories used in here, like {{ic|/boot/}}.}}<br />
<br />
Not running out of the box is unfortunately the initial stage for the kernel. Since we installed it in BIOS mode, two modules are missing to grant access to the root partition while booting. Hence the 'initfsram-linux.img' can not be found/loaded. Adding the following modules to your 'MODULES' line in {{ic|/etc/mkinitcpio.conf}} solved this ([https://bbs.archlinux.org/viewtopic.php?pid=1139226#p1139226 original post]).<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES="ahci sd_mod"}}<br />
<br />
Rebuild your kernel image:<br />
<br />
mkinitcpio -p linux<br />
<br />
The bootloader rEFInd can scan kernels even out of the '/boot/...' directory and assumes an efi kernel even without the extension '.efi'. If you do not want to try out special kernels, this should work without the hassle to copy each kernel after building to some spot special.<br />
<br />
If you happen to get multiple entries for one boot image, it often results of a previous installation of a bootloader within the MBR. To remove that, try the following - taken from the [http://ubuntuforums.org/showpost.php?p=7828260&postcount=4 original post]. This is valid for GPT partitioned discs, so please check your environment and save your MBR first.<br />
<br />
# dd if=/dev/zero of=/dev/sda bs=440 count=1<br />
<br />
=== MacBook Pro ===<br />
<br />
==== Early 2015 13"/15" - Version 12,x/11,4+ ====<br />
<br />
===== Wireless =====<br />
The {{ic|brcmfmac}} driver is working as of 2015-11-20, with newer firmware necessary for working 5GHz support ([https://bugzilla.kernel.org/show_bug.cgi?id=100201#c65 see here.])<br />
<br />
{{<br />
Note| On the Macbook Pro 12,1 if the {{ic|brcmfmac}} driver can not be started and the following errors occur in the journal:<br />
<br />
{{bc|<nowiki><br />
brcmfmac: brcmf_chip_recognition: chip backplane type 15 is not supported<br />
brcmfmac: brcmf_pcie_probe: failed 14e4:43ba<br />
</nowiki>}}<br />
<br />
then check whether [[Power_management#PCI_Runtime_Power_Management|PCI runtime power management]] is enabled on the device, and disable it if so.<br />
<br />
}}<br />
<br />
===== Bluetooth =====<br />
Bluetooth is fully supported starting from kernel-4.4.0.<br />
<br />
===== Suspend & Power Off (11,4+) =====<br />
The 11,4 and 11,5 MacBook Pros do not shutdown or suspend correctly with the default kernel. This issue is being addressed in [https://bugzilla.kernel.org/show_bug.cgi?id=103211 Bug 103211] and a temporary patch is currently available in {{AUR|linux-macbook}}. Note that [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/pci/fixup.c?h=v4.13-rc1&id=13cfc732160f7bc7e596128ce34cda361c556966 Linux 4.13.0] has this patch included, and will be released shortly.<br />
<br />
===== Keyboard & Trackpad =====<br />
Haptic feedback works out of the box due to the trackpad's built-in firmware.<br />
<br />
There are several drivers available that provide multitouch support. The following have been confirmed working with the MacBookPro12,1.<br />
<br />
For {{Pkg|xf86-input-libinput}} the following configuration emulates some features from the OS X functionality. For more options see {{man|4|libinput|url=https://www.mankier.com/4/libinput}}.<br />
{{hc|1=/etc/X11/xorg.conf.d/90-libinput.conf|2=<br />
Section "InputClass"<br />
Identifier "libinput touchpad catchall"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Driver "libinput"<br />
Option "NaturalScrolling" "true"<br />
EndSection<br />
}}<br />
<br />
For {{Pkg|xf86-input-synaptics}} the following configuration is necessary to make the touchpad work fully.<br />
{{hc|1=/etc/X11/xorg.conf.d/60-magictrackpad.conf|2=<br />
Section "InputClass"<br />
Identifier "Trackpad"<br />
Driver "synaptics"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"<br />
EndSection<br />
}}<br />
<br />
Further, some US/ANSI keyboards suffer from an issue where the tilde key (~, the key vertically between Esc and Tab) registers as < and >. The following config file fixes this issue.<br />
<br />
{{hc|1=/etc/modprobe.d/hid_apple.conf|2=<br />
options hid_apple iso_layout=0<br />
}}<br />
<br />
See [https://bugzilla.kernel.org/show_bug.cgi?id=96771 this kernel bugzilla] for more details and the relevant patches for earlier kernels.<br />
<br />
===== Graphics =====<br />
For Intel-only graphics, install the {{Pkg|xf86-video-intel}} package. For more information or OpenGL/3D support, follow instructions at [[Intel graphics]].<br />
<br />
For Dual Graphics see [[MacBookPro11,x#Graphics]].<br />
<br />
{{Note|The kernel parameters ''acpi_backlight'', ''i915.lvds_downclock'', ''i915.enable_ips'', and ''intel_iommu'' are no longer necessary as of kernel 4.2.}}<br />
{{Note|(Kernel 4.10.8, MacBook Pro 11,4) If you experience system lock ups and/or tearing in Xorg, remove the .{{Pkg|xf86-video-intel}} completely, including any config file you made for it. Xorg will default to its modesetting DDX driver. The performance of this driver is good and the locks go away. See also: [[Intel graphics]]}}<br />
<br />
==== 2012 - 2014 models ====<br />
<br />
* [[MacBookPro11,x]] (Late 2013—Mid 2014)<br />
* [[MacBookPro10,x]] (Mid 2012—Early 2013)<br />
<br />
=== MacBook Air===<br />
<br />
==== Early 2014 11" - Version 6,1 ====<br />
This is almost the same as the 2013 version, where the only known difference is a slightly faster processor. The version numbers have not been changed since the 2013 version.<br />
<br />
It works excellently after following the instructions for the MBA 2013 13" here and in the forum thread.<br />
Bluetooth, which has been reported not working for some people with the 2013 version, works without trouble for the 2014 version, although it should be excactly the same.<br />
<br />
{{Note| Unless you have a local repository on a USB disk, you need a USB to ethernet adaptor or a USB wireless adaptor supported natively by the kernel to easily install Arch Linux, since you have to install the {{Pkg|broadcom-wl-dkms}} package to make the internal wireless adaptor work.}}<br />
<br />
Unresolved issues:<br />
* There is no driver for the webcam yet.<br />
* rEFInd uses 30 seconds to start booting. Using the bless trick stops rEFInd from loading, and it has to be re-installed.<br />
<br />
==== Mid 2013 13" - Version 6,2 ====<br />
[https://bbs.archlinux.org/viewtopic.php?id=165899 Dedicated forum thread]<br />
===== Installing and booting =====<br />
Booting from a normal 2013.6 USB key works fine, but I could not seem to get either GRUB or Syslinux working.<br />
<br />
I was able to boot by first installing Arch Linux following the MacBook guide at the wiki (having a separate FAT32 /boot partition). Skip the bootloader installation. <br />
<br />
Installing [http://www.rodsbooks.com/refind/getting.html rEFInd] from OS X (important!) and installing the EFI stub loader made me able to boot fine.<br />
<br />
[https://bbs.archlinux.org/viewtopic.php?id=165710 Dedicated thread].<br />
<br />
{{Note| Installing [http://www.rodsbooks.com/refind/getting.html rEFInd] from Linux (or from OS X, but to the esp) also works fine}}<br />
<br />
===== Arch Only Installation =====<br />
This method works without rEFInd and uses grub to boot EFI. Partition as follows:<br />
<br />
/dev/sda1 200M Microsoft basic data<br />
/dev/sda2 256M Linux filesystem<br />
/dev/sda3 4G Linux swap<br />
/dev/sda4 108.6G Linux filesystem<br />
<br />
sda1 can also be a HFS+ partition for EFI. This example chooses to use FAT32 (vfat). Although swap is optional, it is required for hibernation. Instead of sda4 for root and home, an alternative partition scheme would be to make sda4 as root and sda5 as home.<br />
<br />
Format and mount:<br />
<br />
mkfs.vfat -F 32 /dev/sda1<br />
mkfs.ext2 /dev/sda2<br />
mkswap /dev/sda3<br />
swapon /dev/sda3<br />
mkfs.ext4 /dev/sda4<br />
<br />
mount /dev/sda4 /mnt<br />
mkdir /mnt/boot<br />
mount/dev/sda2 /mnt/boot<br />
mkdir /mnt/boot/efi<br />
mount /dev/sda1 /mnt/boot/efi<br />
<br />
Finish the installation according to the [[Installation guide]] and skip anything after the bootloader. After you have generated your initramfs and set root passwd follow below to setup grub:<br />
<br />
pacman -S grub efibootmgr<br />
mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --recheck --debug<br />
grub-mkconfig -o /boot/efi/EFI/grub/grub.cfg<br />
cp /boot/efi/EFI/grub/grub.cfg /boot/grub/grub.cfg<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi}}<br />
<br />
Now you can exit/unmount/reboot:<br />
exit<br />
umount -R /mnt<br />
reboot<br />
<br />
===== Stability problems =====<br />
{{Note| Passing {{ic|<nowiki>libata.force=1:noncq</nowiki>}} to the kernel parameters solves the problem.}}<br />
This is the big worry for me. Every now and then my system hangs for a brief moment and everything involving net or disk access just hangs there for a while and then it seems to work. <br />
So far it only seems to happen when I run something disk- or CPU-intensive. Also had an occassion when I could not start X and just got this repeating all over my screen:<br />
<br />
ata1.00: failed command: WRITE FPDMA QUEUED<br />
ata1.00: cmd 61/08:f0:10:8c:c2/00:00:0b:00:00/40 tag 30 ncq 4096 out<br />
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)<br />
ata1.00: status: { DRDY }<br />
<br />
On the next attempt it worked fine.<br />
I did SMART short and long tests on my disk and they returned fine:<br />
<br />
[http://pastebin.com/vRE4T2Ld smartctl -a]<br />
<br />
There are some messages in my boot that indicate this could be disk and/or ACPI related.<br />
<br />
These are with 2013-06 ISO, 3.9.7-1 2013 x86_64 kernel.<br />
<br />
[http://pastebin.com/mjTJaPFa journalctl -b]<br />
Seems to only work with the headphone jack, not with the speakers.<br />
<br />
[http://pastebin.com/SdAcHuKh dmesg]<br />
<br />
{{Note | Same problem in 2017 with a Macbook Air early 2014. Updating the firmware (via migration to macOS Sierra) solved the issue.}}<br />
<br />
===== Marvell ATA suspend bugs =====<br />
If you have 2013 MacBook Air with a Marvell 128 or 256 GB drive, you might get the following ata errors instead after pm-suspend/resumes:<br />
<br />
ata1: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen<br />
ata1: irq_stat 0x00400000, PHY RDY changed<br />
ata1: SError: { PHYRdyChg }<br />
ata1: hard resetting link<br />
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)<br />
ata1.00: unexpected _GTF length (8)<br />
ata1.00: unexpected _GTF length (8)<br />
ata1.00: configured for UDMA/33<br />
ata1: EH complete<br />
<br />
Try what Patrick and Tejun figured out on the [https://bugzilla.kernel.org/show_bug.cgi?id=62351 linux bug]. I followed what Patrick describes with sata_alpm, and I haven't seen the issue since.<br />
<br />
There are more steps on how to resolve this issue in [https://bbs.archlinux.org/viewtopic.php?pid=1562168#p1562168 this thread on the Arch forum]<br />
<br />
===== Suspend/Resume =====<br />
Brightness is either 0% or 100% after resuming from suspend. Until the kernel is fixed, use patjak's fix by installing {{AUR|mba6x_bl-dkms}}. Patjak's github is at [https://github.com/patjak/mba6x_bl].<br />
===== WiFi =====<br />
WiFi does not work out of the box. Install {{Pkg|broadcom-wl-dkms}} to connect to a network. <br />
<br />
===== Touchpad =====<br />
Since 3.10.3 kernel touchpad works perfectly with {{Pkg|xf86-input-synaptics}}.<br />
<br />
===== Audio =====<br />
As of Linux 3.12, sound works out of the box. If you do not get sound with only {{pkg|alsa-utils}}, you may need to create a /etc/asound.conf with below entries:<br />
<br />
defaults.pcm.card 1<br />
defaults.pcm.device 0<br />
defaults.ctl.card 1<br />
<br />
==== Mid 2012 13" — version 5,2 ====<br />
<br />
Kernel panics using default boot media under arch kernel 3.5. Adding <code>intremap=off</code> fixes this. Additionally, there are problems loading the <code>applesmc</code> module (meaning the temperature sensors, fan, and keyboard backlight do not work). These problems are fixed in the linux 3.6-rc4 mainline kernel (I have tested).<br />
<br />
==== Mid 2012 11.5" — Version 5,1 ====<br />
<br />
If you have issues with waking from sleep while in X11 such as a black screen or showing the console with a frozen mouse cursor then remove {{Pkg|xf86-input-synaptics}} and install {{AUR|xf86-input-mtrack-git}}. This fixed errors such as <br />
(EE) [dix] bcm5974: unable to find touch point 0<br />
and backtraces that causes X11 to crash. This might apply to Version 5,2 assuming they use the same trackpad.<br />
<br />
==== Mid 2011 — version 4,x ====<br />
<br />
Works out-of-the-box since kernel 3.2. It is recommended to use [[Archboot]], install [[GRUB]] and use EFI.<br />
<br />
==== Early 2008 — version 1,1 ====<br />
<br />
Everything works out of the box though you will need the {{Pkg|b43-fwcutter}} package (or simply {{AUR|b43-firmware}}) for the wireless adapter to work.<br />
<br />
Since this model has only one USB port, you may find it easiest to install Arch with a powered USB hub. Plug a USB network adapter (wireless or ethernet adapter to plug into a USB port) and your Arch installation media into the USB hub.<br />
<br />
If you can't get any result by scanning wireless network after boot, unload modules <code>b43</code> and <code>ssb</code> and load them again:<br />
<br />
rmmod ssb<br />
rmmod b43<br />
modprobe b43<br />
<br />
There is a good chance you will find what's wrong with DMA from the dmesg log.<br />
<br />
Even if you can scan wireless networks after reloading the modules, it's still possible that you will only be able to connect to some networks, but not all of them. According to a more detailed discussion here: http://crunchbang.org/forums/viewtopic.php?id=17368, adding <code>pio=1,qos=0</code> options to the b43 module can solve this problem.<br />
<br />
I tested this for a 13' MacBookAir1,1 with a BCM4321 chipset, and it works.<br />
<br />
== See also ==<br />
* '''MacBook Air'''<br />
** [http://dabase.com/blog/Macbook_Air_Early_2014_Archlinux/ Macbook Air Early 2014 — dabase.com]<br />
** [http://www.frankshin.com/installing-archlinux-on-macbook-air-2013/ Installing Archlinux on Macbook Air 2013 — Frank Shin]<br />
** [http://blog.panks.me/posts/2013/06/arch-linux-installation-with-os-x-on-macbook-air-dual-boot/ Arch Linux Installation with OS X on Macbook Air (Dual Boot) — Pankaj Kumar]{{Dead link|2017|06|01}}<br />
** [http://ryangehrig.com/index.php/arch-linux-on-macbook-air-2013/ Arch Linux – MacBook Air 2013 — Ryan Gehrig]<br />
** [http://www.nico.schottelius.org/blog/macbook-air-42-archlinux/ Installing Linux on a Macbook Air (4,2) — Nico Schottelius]<br />
** [http://www.dm9.se/?p=398 Arch linux single, pure efi boot on the macbook air3,1/3,2 — DIMENSION9]<br />
* '''MacBook Pro'''<br />
** http://www.netsoc.tcd.ie/~theorie/interblag/2010/01/30/installing-arch-linux-on-a-mac-pro/{{Dead link|2017|06|01}}<br />
** http://allanmcrae.com/2010/04/installing-arch-on-a-macbook-pro-5-5/<br />
** http://allanmcrae.com/2012/04/installing-arch-on-a-macbook-pro-8-1/<br />
** http://linux-junky.blogspot.com/2011/08/triple-boot-archlinux-windows-7-and-mac.html</div>Ndthttps://wiki.archlinux.org/index.php?title=Mac&diff=483431Mac2017-07-31T17:06:37Z<p>Ndt: /* Suspend & Power Off (11,4+) */ add note about suspend fix for Linux 4.13.0</p>
<hr />
<div>[[Category:Apple]]<br />
[[de:ArchLinux auf einem MacBook]]<br />
[[fr:MacBook]]<br />
[[it:MacBook]]<br />
[[ja:MacBook]]<br />
[[zh-hans:MacBook]]<br />
{{Related articles start}}<br />
{{Related|Installation guide}}<br />
{{Related|General recommendations}}<br />
{{Related|MacBook4,2 (late 2008)}}<br />
{{Related|MacBook5,2 (early-mid 2009)}}<br />
{{Related|MacBookPro7,1}}<br />
{{Related|MacBookPro8,1/8,2/8,3 (2011)}}<br />
{{Related|MacBookPro9,2 (Mid-2012)}}<br />
{{Related|MacBookPro10,x}}<br />
{{Related|MacBookPro11,x}}<br />
{{Related|iMac Aluminum}}<br />
{{Related|Apple Fusion Drive}}<br />
{{Related articles end}}<br />
<br />
Installing Arch Linux on a MacBook (12"/Air/Pro) or an iMac is quite similar to installing it on any other computer. However, due to the specific hardware configuration of a Mac, there are a few deviations and special considerations which warrant a separate guide. For more background information, please see the [[Installation guide]] and [[UEFI]]. This guide contains installation-instructions that can be used on any Apple computer whose hardware is supported by the Linux kernel. Please see 'related' pages (on the top right of this page) for model-specific tips and troubleshooting.<br />
<br />
== Overview ==<br />
<br />
Specifically, the procedure for installing Arch Linux on a MacBook is:<br />
<br />
# '''[[#Firmware updates|Firmware updates]]''': It always helps to start from a clean, backed up, and up-to-date install of OS X.<br />
# '''[[#Partitions|Partition]]''': Resizing or deleting the OS X partition to create partitions for Arch Linux.<br />
# '''[[#Setup bootloader|Setup bootloader]]''': Making sure that the new partition is bootable.<br />
# '''[[#Installation|Install Arch Linux]]''': Actually installing Arch Linux.<br />
# '''[[#Post-installation|Post-installation]]''': MacBook-specific configuration.<br />
<br />
== Firmware updates ==<br />
<br />
Before proceeding with the installation of Arch Linux, it is important to ensure that the latest firmware updates for you MacBook are installed. This procedure requires OS X.<br />
In OS X, open the App Store and check for updates. If your mac finds and installs any updates, make sure to '''reboot''' your computer, and then check again for updates to make sure that you installed everything.<br />
<br />
{{Note|If you uninstalled OS X or want to reinstall it, [https://support.apple.com/en-us/HT204904 Apple] has great instructions.}}<br />
<br />
It is advisable to keep OS X installed, because MacBook firmware updates can only be installed using OS X. However, if you plan to remove OS X completely, make backups of these files, which you will need in Linux for adjusting the [[#Color Profile|color profile]]:<br />
/Library/ColorSync/Profiles/Displays/*<br />
<br />
Continue to [[#Partitions]]<br />
<br />
== Partitions ==<br />
<br />
Partitioning of the storage drive is no different from any other PC or laptop. However, if you plan on keeping OS X for dual booting, you should consider that, by default, a MacBook's drive is formatted using GPT and contains at least 3 partitions:<br />
<br />
* '''EFI''': the ~200 MB [[EFI System Partition]].<br />
* '''OS X''': the main partition containing your OS X installation. It is formatted using [[File_systems|HFS+]].<br />
* '''Recovery''': A recovery partition present in almost all MacBooks running OS X 10.7 or newer. It is usually hidden from OS X but can be viewed with partitioning tools.<br />
<br />
{{Note|In Macs that use the [[Apple Fusion Drive]], the partition scheme could be different.}}<br />
<br />
How to partition depends on how many operating systems you want install. The following options will be explained:<br />
<br />
* Single boot: [[#Arch Linux only]]<br />
* Dual boot: [[#Arch Linux with OS X or other operating systems]] ''(recommended so you can still return to OS X when needed)''<br />
* Triple boot: [[#OS X, Windows XP, and Arch Linux triple boot]]<br />
<br />
<br />
=== Arch Linux only ===<br />
<br />
This situation is the easiest to deal with. Partitioning is the same as any other hardware that Arch Linux can be installed on. Please refer to the standard [[Installation guide]] for details.<br />
<br />
{{Note|It is advisable to '''disable''' the MacBook startup sound before proceeding with partitioning. Just boot in OS X, mute your system sound and reboot again to the Arch Linux Installation media. Please keep in mind that the volume of the startup sound can only be modified reliably in OS X.}}<br />
<br />
If you want to configure you system in order to have full-disk encryption, please look at the [[Dm-crypt/Encrypting an entire system]] page for details.<br />
<br />
An example for a very basic partitioning, that does not consider a separate {{ic|/home}} partition nor encryption or LVM, is the following:<br />
partition mountpoint size type label<br />
/dev/sda1 /boot 200MiB vfat EFI<br />
/dev/sda2 /swap adjust swap swap<br />
/dev/sda3 / remain ext4 root<br />
<br />
* Done, you can continue to [[#Installation]]<br />
<br />
<br />
=== Arch Linux with OS X or other operating systems ===<br />
<br />
You need to partition your hard drive while keeping the partitions used for OS X/Windows. If you wish to keep OS X, the easiest way is to use partitioning tools in OS X and then finish with Arch Linux tools.<br />
<br />
{{Warning| If you OS X partition is encrypted with FileVault 2, you '''must''' disable the disk encryption before proceeding. After the OS X partition has been resized, FileVault 2 can be re-enabled.}}<br />
<br />
'''Procedure''':<br />
* In OS X, run ''Disk Utility.app'' (located in {{ic|/Applications/Utilities}})<br />
* Select the drive to be partitioned in the left-hand column (not the partitions!). Click on the '''Partition''' button.<br />
* Add a new partition by pressing the '''+''' button and choose how much space you want to leave for OS X, and how much for the new partition. Keep in mind the new partition will be formatted in Arch Linux, so you can choose any partition type you want. <br />
* If the above completed successfully, then you can continue. If not, then you may need to fix your partitions from within OS X first.<br />
* Boot the Arch installation media or [[USB flash installation media|LiveUSB]] by holding down the {{ic|Alt}} '''during boot'''. Proceed with [[#Installation]].<br />
<br />
It is possible to resize the newly created partition from within the Arch installation media, or delete it in order to proceed with the creation of other partitions (eg. swap).<br />
<br />
{{Tip|Instead of cluttering your drive with different partition, it is possible to use a [[swapfile]] instead of a dedicated partition. Another solution can be setting up [[LVM]] in order to use the newly-created partition as a container. Please refer to the linked articles.}}<br />
<br />
<br />
==== Option 1: EFI ====<br />
<br />
* Run ''cgdisk''<br />
<br />
* Delete the partition you made in ''Disk Utility.app'' and create the necessary partitions for Arch Linux. OS X likes to see a 128 MiB gap after partitions, so when you create the first partition after the last OS X-partition, type in '''+128M''' when cgdisk asks for the first sector for the partition. More information about Apple's partitioning policy can be read [https://developer.apple.com/library/mac/technotes/tn2166/_index.html#//apple_ref/doc/uid/DTS10003927-CH1-SUBSECTION5 here]. A simple example (no LVM, crypto):<br />
<br />
{{Note|<br />
* The swap partition is optional on machines with 4GB of RAM or more. A '''[[swap file]]''' can be created later.<br />
* The easiest dual-boot option is to install rEFInd from inside OS X, to its root directory (default for {{ic|install.sh}}). Following that, copy the driver folder from the installation tarball into the new rEFInd location, and uncomment the lines ''"scan_all_linux_kernels"'' and ''"also_scan_dirs"'' options in {{ic|refind.conf}}. Configuration of boot options can then be done from a {{ic|refind_linux.conf}} in Arch's {{ic|/boot}} directory.<br />
* If you want to be able to boot GRUB from the Apple boot loader, you can create a small hfs+ partition (for convenience, use OS X to format it in ''Disk Utility.app'' afterwards). Follow the GRUB EFI install procedure, and mount your {{ic|/boot/efi}} directory to the hfs+ partition you created. Finally, finish up again in OS X by blessing the partition. This will set GRUB as the default boot option (holding alt at startup goes to the mac boot options screen still. See http://mjg59.dreamwidth.org/7468.html).,<br />
* OS X's EFI partition can be shared with Arch Linux, making the creation of an additional EFI partition dedicated to Arch completely optional.<br />
}}<br />
<br />
{{Note|For more information on partitioning, see [[Partitioning]]}}<br />
partition mountpoint size type label<br />
/dev/sda1 /boot/efi 200MiB vfat EFI<br />
/dev/sda2 - ? hfs+ OS X<br />
/dev/sda3 - ? hfs+ Recovery<br />
/dev/sda4 - 100MiB hfs+ Boot Arch Linux from the Apple boot loader (optional)<br />
/dev/sda5 /boot 100MiB boot boot<br />
/dev/sda6 - ? swap swap (optional)<br />
/dev/sda7 / 10GiB ext4 root<br />
/dev/sda8 /home remaining ext4 home<br />
<br />
* Done, you can continue to [[#Installation]]<br />
<br />
==== Option 2: BIOS-compatibility ====<br />
<br />
* Run ''parted'' as root.<br />
<br />
* Delete the empty space partition and partition the space as you would for any other installation. Note that MBR is limited to 4 primary partitions (including the efi partition). That leaves 2 primary partitions for Arch. One strategy is to have a system and home partition, and use a swap file (I have not tried to use logical partitions). Another is to dedicate one partition to a shared partition (see below).<br />
<br />
* Next, create new filesystems on those partitions which need them, especially the partition which will contain {{ic|/boot}}. If you are not sure how to do this using {{ic|mkfs.ext2}} (or whatever), run {{ic|/arch/setup}} and work through until you get to Prepare Hard Drive and use the ''"Manually configure block devices..."'' option, then exit the installer. This is necessary so that rEFIt will set the right partition type in the MBR in the next step (without an existing filesystem, it seems to ignore the partition type set by parted), without which GRUB will refuse to install to the right partition.<br />
<br />
* At this point you should reboot your computer and have rEFIt fix the partition tables on your hard drive. (If you do not do this, you may have to reinstall GRUB later on in order to have your Mac recognize the Linux partition.) When you are into the rEFIt menu, select '''update partition table''', then press {{ic|y}}. Reboot.<br />
<br />
* Done, you can continue with [[#Installation]].<br />
<br />
=== OS X, Windows XP, and Arch Linux triple boot ===<br />
<br />
This may not work for everyone but it has been successfully tested on a MacBook from late 2009.<br />
<br />
The easiest way to partition your hard drive, so that all these operating systems can co-exist, is to use disk utility in OS X, use the formatter on windows XP, install XP and then finish with Arch Linux tools.<br />
<br />
{{Warning|It is highly recommended that this only be attempted after a clean install of OS X. Using these methods on a pre-existing system may have undesired results. At least back your stuff up with timemachine or clonezilla before you begin.}}<br />
<br />
'''Procedure''':<br />
* In OS X, run '''Disk Utility''' (located in {{ic|/Applications/Utilities}}).<br />
<br />
* Select the drive to be partitioned in the left-hand column (not the partitions!). Click on the '''partition''' tab on the right.<br />
<br />
* Select the volume to be resized in the '''volume scheme.'''<br />
<br />
* Decide how much space you wish to have for your OS X partition, how much for XP, and how much for Arch Linux. Remember that a typical installation of OS X requires around 15-20 GiB, and XP about the same, depending on the number of software applications and files. Something like OS X 200Gb, XP 25Gb, Arch 25Gb should be fine.<br />
<br />
* Put your decisions into action by pressing the + button and adding the new partitions, Label them as you like and make sure that your XP partition is the last one on the disk and is formatted for FAT32. It is probably best to have Arch formatted in HFS format as to not confuse you later, it will be reformatted anyway.<br />
<br />
So in linux terms your partitions will be something like:<br />
<br />
:*sda (disk)<br />
:*sda1 (Mac boot partition - you cannot see this one in OS X)<br />
:*sda2 (OS X install in HFS+)<br />
:*sda3 (Arch install temporarly in HFS)<br />
:*sda4 (XP install in FAT32)<br />
<br />
* Finally, click '''apply'''. This will create a new partition out of the empty space.<br />
<br />
{{Note|Using this method you may not be able to have a shared partition between OS X and Arch Linux, this is because the mac will only allow for 4 active partitions. You will however be able to mount a HFS partition in Arch for one workaround. There are other workarounds possible also.}}<br />
<br />
* If the above completed successfully, you can continue. If not, then you may need to fix your partitions from within OS X first.<br />
<br />
* You will not be needing boot camp this way, the program rEFIt is much more flexible (though not as flexible as GRUB). Download and install rEFIt [http://refit.sourceforge.net/]<br />
<br />
* Go into a terminal in OS X and perform the following, this will enable the rEFIt boot manager. <br />
<br />
cd /efi/refit<br />
./enable.sh<br />
<br />
* Reboot to check the rEFIt is working, it should appear on boot. When it comes up go to the rEFIt partition manager and agree to the changes.<br />
<br />
* Put your XP install CD and boot it with rEFIt - You may have to reboot a few times until it is recognized by the boot loader. Install XP and once it is installed use the OS X installation CD to get your drivers running nicely in XP.<br />
** Note: when installing XP make sure you select your XP partition and format it again inside the XP installer. If you do not reformat it will not work.<br />
<br />
* Boot the Arch install CD, log in as root and run {{ic|# /arch/setup}}.<br />
<br />
* Follow the install as normal but note that you will have to tell that arch installer to mount sda3 as the root partition and format it as ext3, there will not be a /boot or swap partition so ignore those warnings.<br />
<br />
* At this point, if you are dual booting, you should reboot your computer and have rEFIt fix the partition tables on your hard drive. (If you do not do this, you may have to reinstall GRUB later on in order to have your Mac recognize the Linux partition.) When you are into the rEFIt menu, select '''update partition table''', then press Y.<br />
# reboot<br />
<br />
* Done! You can continue to [[#Installation]].<br />
<br />
== Setup bootloader ==<br />
<br />
=== Using the native Apple bootloader with systemd-boot (Recommended) ===<br />
<br />
Apple's native EFI bootloader reads {{ic|.efi}} files located inside the [[EFI System Partition]] at {{ic|/EFI/BOOT/BOOTX64.EFI}}. Luckily, this is also the default install location for the [[systemd-boot]] binary. This means that booting linux using ''systemd-boot'' is very simple.<br />
* First, make sure you mounted the EFI System Partition at {{ic|/boot}}<br />
* Proceed with [[#Installation]] normally<br />
* Once inside the chrooted enviroment, type the following command to install ''systemd-boot'':<br />
{{bc|1=# bootctl --path=/boot install}}<br />
The above command will copy the ''systemd-boot'' binary to {{ic|/boot/EFI/BOOT/BOOTX64.EFI}} and add ''systemd-boot'' itself as the default EFI application (default boot entry) loaded by the EFI Boot Manager. <br />
* Proceed to [[systemd-boot#Configuration]] in order to correctly set up the bootloader<br />
At the next reboot, the Apple Boot Manager, shown when holding down the option key when booting the MacBook, should display Arch Linux (it will be displayed as {{ic|EFI Boot}} as a possible boot option.<br />
{{Tip|If you installed Arch Linux alongside OS X, you will be able to change the default boot location from system Settings inside OS X. If Arch Linux does not show up as a possible boot option, you will have to mount the EFI System Partition inside OS X before selecting your boot option:<br />
{{bc|$ diskutil mount disk0s1}}<br />
}}<br />
<br />
=== Using the native Apple bootloader with GRUB ===<br />
<br />
{{Style|Uses [[partial upgrade]] procedure and explicitly lists many basic commands.}}<br />
<br />
Despite using UEFI, the MacBook's native EFI bootloader [http://refit.sourceforge.net/myths/ does not use the EFI partition for booting]. Instead, it looks for .efi files inside all the partitions in internal and external drives and shows them as possible boot options if certain conditions are satisfied. For example, MacBooks can detect an existing OSX installation after checking that:<br />
* there is a partition formatted as HFS+<br />
* the partition contains the partition id {{ic|af00}} <br />
* in the root of that partition, there is a file called {{ic|mach_kernel}}<br />
* inside that partition, there a {{ic|boot.efi}} file inside {{ic|/System/Library/CoreServices}}<br />
<br />
This means that configuring an Arch installation to be automatically recognized by the MacBook bootloader is possible. Moreover, it simply requires a properly-formatted HFS+ {{ic|/boot}} partition and does not require meddling with the EFI system partition. The advantage of this method is that it can coexist with OS X nicely and allows to avoid other bootloaders such as rEFInd. However, this requires manual configuration. The following steps will illustrate how to perform this configuration using GRUB.<br />
* First, while configuring a new Arch installation, create a separate {{ic|/boot}} partition. Many tools are available in the Arch ISO, for example '''cgdisk'''.<br />
* Make sure the partition is at least ~250 MB in size, since it will be used to store the kernel as well as any custom kernel you will install in the future. Moreover, make sure the partition type is set as Apple HFS/HFS+ (it will appear as {{ic|Apple HFS/HFS+}} in fdisk/cgdisk or {{ic|af00}} in gdisk)<br />
* Since the Arch installation ISO does not include the {{Pkg|hfsprogs}} package, we need to install it in the installation environment before proceeding with formatting the new partition as HFS+<br />
# pacman -Sy hfsprogs<br />
# modprobe hfsplus<br />
# mkfs.hfsplus /dev/sd'''X''' -v "Arch Linux"<br />
<br />
Note: replace /dev/sd'''X''' with the correct device as appropriate<br />
<br />
* Done, proceed with [[#Installation]]<br />
<br />
{{Warning|<br />
Once inside the chrooted enviroment, don’t forget to install the {{Pkg|hfsprogs}} package on the newly installed system as well. After the installation of the package, regenerate the initramfs while chrooted<br />
# mkinitcpio -p linux<br />
}}<br />
<br />
* Once inside the chrooted enviroment, install the {{Pkg|grub}} and {{Pkg|efibootmgr}} packages. The following steps install the GRUB UEFI application to {{ic|/boot/EFI/arch/System/Library/CoreServices/boot.efi}} and install its modules to {{ic|/boot/grub/x86_64-efi}}.<br />
# grub-install --target=x86_64-efi --efi-directory=/boot<br />
<br />
After that, remember to create a standard configuration file:<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
As you can see, the directory structure of the {{ic|boot.efi}} is not correct, as the {{ic|/System/Library/CoreServices}} directory is not supposed to be a subdirectory of the {{ic|/boot/EFI/}} folder. For this reason, we need to relocate the {{ic|boot.efi}} stub in a location the MacBook bootloader is able to recognize:<br />
# mv /boot/EFI/arch/System/ /boot/<br />
# rm -r /boot/EFI/<br />
<br />
Also, create a dummy {{ic|mach_kernel}} file<br />
# touch /boot/mach_kernel<br />
<br />
After that, you need to create the following file <br />
<br />
{{hc|1=# nano /boot/System/Library/CoreServices/SystemVersion.plist|2=<br />
<?xml version="1.0" encoding="UTF-8"?><br />
<plist version="1.0"><br />
<dict><br />
<key>ProductBuildVersion</key><br />
<string></string><br />
<key>ProductName</key><br />
<string>Linux</string><br />
<key>ProductVersion</key><br />
<string>Arch Linux</string><br />
</dict><br />
</plist><br />
}}<br />
<br />
At the next reboot, the Apple Boot Manager, shown when holding down the option key when booting the MacBook, should display Arch Linux as a possible boot option. Selecting that option will boot GRUB.<br />
<br />
Done! GRUB can now be selected on the standard MacBook bootloader and you can boot into your newly installed Arch Linux.<br />
<br />
{{Tip| After the installation, it is optionally possible to set a custom icon that will be displayed in the MacBook boot loader. In order to do that, you need to install the {{Pkg|wget}}, {{Pkg|librsvg}} and {{AUR|libicns}} packages. After that, just follow the following commands:<br />
$ wget -O /tmp/archlinux.svg https://www.archlinux.org/logos/archlinux-icon-crystal-64.svg<br />
$ rsvg-convert -w 128 -h 128 -o /tmp/archlogo.png /tmp/archlinux.svg<br />
$ sudo png2icns /boot/.VolumeIcon.icns /tmp/archlogo.png<br />
$ rm /tmp/archlogo.png<br />
$ rm /tmp/archlinux.svg<br />
Obviously, you can replace the Arch logo with any other icon you like.<br />
}}<br />
<br />
=== Other methods ===<br />
<br />
{{Out of date | Section that describes bootloader setup for other setups should be revised and re-structured into more readable way}}<br />
{{Tip|rEFIt is a popular bootloader for EFI-firmware computers (including Macs). It can be installed at any time during the installation. For instructions, please see [[#rEFIt]]. }}<br />
<br />
If you are going for an Arch Linux-only setup, installing the bootloader is no different than on any other machine: Install [[systemd-boot]], [[rEFInd]] or other bootloader of your choice.<br />
<br />
If, on the other hand, you are dual/triple booting, then read on.<br />
<br />
<br />
=== Installing GRUB to EFI partition directly ===<br />
<br />
* If you would like to use GRUB as your main bootloader and use the "boot while holding the Alt/Option key" method to go back to OS X rather than using alternatives such as rEFIt (http://refit.sourceforge.net/, mentioned previously in [[#Option 2: BIOS-compatibility]] and [[#OS X, Windows XP, and Arch Linux triple boot]]) then you must install {{Pkg|grub}} to your Mac's '''already-existing''' EFI partition (see below). <br />
<br />
{{Note| These instructions are known to work on a MacBook Pro (Early 2011). Please read the procedure carefully '''as well as the details following it'''.}}<br />
<br />
{{Note| With a new MacBook Pro (Mid 2014), this procedure worked only after installing the<br />
{{Pkg|efibootmgr}} package.}}<br />
<br />
'''Procedure''':<br />
<br />
* Install {{Pkg|grub}}<br />
<br />
* Make a directory named {{ic|efi}} in {{ic|/boot}} <br />
<br />
* Mount the '''already-existing''' EFI partition on your Mac to this {{ic|/boot/efi}} directory<br />
<br />
* Install GRUB to this directory<br />
<br />
* Make a directory named {{ic| locale}} in {{ic| /boot/grub}}<br />
<br />
* Copy {{ic| grub.mo}} from {{ic| /usr/share/locale/en\@quot/LC_MESSAGES/}} to {{ic| /boot/grub/locale}} <br />
<br />
* Generate a configuration for GRUB<br />
<br />
* Done! GRUB will now start on reboot and you can boot into your newly installed Arch Linux.<br />
<br />
* Remember to hold ALT/Option key '''while''' starting your computer if you want to boot back into OS X.<br />
<br />
'''Details (quoted from [[GRUB EFI Examples#M5A97]]):'''<br />
<br />
Finish the standard Arch install procedures, making sure that you install {{Pkg|grub}} and partition your boot hard disk as GPT.<br />
<br />
From [[GRUB#UEFI systems]]:<br />
<br />
The UEFI system partition will need to be mounted at {{ic|/boot/efi/}} for the GRUB install script to detect it:<br />
<br />
# mkdir -p /boot/efi<br />
# mount -t vfat /dev/sdXY /boot/efi<br />
<br />
Where X is your boot hard disk and Y is the efi partition you created earlier.<br />
<br />
Install GRUB UEFI application to and its modules to {{ic|/boot/grub/x86_64-efi}} using:<br />
<br />
# modprobe dm-mod<br />
# grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=arch_grub --recheck --debug<br />
# mkdir -p /boot/grub/locale<br />
# cp /usr/share/locale/en\@quot/LC_MESSAGES/grub.mo /boot/grub/locale/en.mo<br />
<br />
Generate a configuration for GRUB<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
=== Using blessing ===<br />
<br />
It is possible to boot directly from GRUB in EFI mode without using rEFIt through what is known as "blessing" after placing GRUB on a '''separate partition'''. These instructions are known to work on a MacBook7,1. It is advisable to host GRUB on either a FAT32 or HFS+ partition, but ext2 or ext3 may also work. GRUB's appleloader command does not currently work with the 7,1, but support can be added with the patch available [https://savannah.gnu.org/bugs/index.php?33185 here].<br />
<br />
After the GRUB install is in the desired location, the firmware needs to be instructed to boot from that location. This can be done from either an existing OS X install or an OS X install disk. The following command assumes that the GRUB install is in {{ic|/efi/grub}} on an existing OS X partition:<br />
# bless --folder /efi/grub --file /efi/grub/grub.efi<br />
<br />
=== Compilation ===<br />
<br />
Some models may need EFI_ARCH set to i386.<br />
bzr branch --revision -2 bzr://bzr.savannah.gnu.org/grub/trunk/grub grub<br />
cd grub<br />
./autogen.sh<br />
patch -p1 < appleloader_macbook_7_1.patch<br />
export EFI_ARCH=x86_64<br />
./configure --with-platform=efi --target=${EFI_ARCH} --program-prefix=""<br />
make<br />
cd grub-core<br />
../grub-mkimage -O ${EFI_ARCH}-efi -d . -o grub.efi -p "" part_gpt part_msdos ntfs ntfscomp hfsplus fat ext2 normal chain boot configfile linux multiboot<br />
cp grub.efi *.mod *.lst yourinstalllocation<br />
<br />
== Installation ==<br />
<br />
{{Note|This section is only required if you want to have OS X installed along with Arch Linux. If not, follow the steps in the official install guide, then skip to [[#Post-installation]].}}<br />
<br />
* Boot from the Arch Linux install CD, from the latest [[Archboot]] iso (unofficial), or from a [[USB flash installation media#Using manual formatting|manually created]] bootable USB drive.<br />
{{Note|<br />
* On a MacBookPro7,1, I had an error booting the installation media Version 2012.12.01: "unable to handle kernel NULL pointer dereference at 0000000000000010" during pacpi_set_dmamode. To fix this problem, boot with the option: acpi&#61;off. After chrooting, add MODULES&#61;"ata_generic" into /etc/mkinitcpio.conf and execute mkinitcpio -p linux, see: [[Installation guide#Configure_the_system|Installation Guide, 9 Configure the system]].<br />
* Some MacBook users report strange keyboard output such as long delays and character doubling. To fix this problem, boot with the following options: arch noapic irqpoll acpi&#61;force}}<br />
<br />
* Proceed through the installation as described in the [[Installation guide]] '''except''' in the following areas:<br />
** Skip the [[Installation guide#Partition the disks|partition the disks]] stage, do only the [[Installation guide#Format the partitions|partition formatting]] and [[Installation guide#Mount the partitions|mounting]] steps, taking care to assign the correct partitions. Partitions have already been created if you followed [[#Partitions]]<br />
** '''(for booting with EFI''') After the [[Installation guide#Boot loader|install boot loader]] stage, exit the installer and install [[GRUB]].<br />
** '''(for booting with BIOS-compatibility)''' In the [[Installation guide#Boot loader|install boot loader]] stage, edit the menu.lst file and add '''reboot=pci''' to the end of the '''kernel''' lines, for example: {{bc|1=kernel /vmlinuz-linux root=/dev/sda5 ro reboot=pci}} This will allow your MacBook to reboot correctly from Arch.<br />
** '''(for booting with BIOS-compatibility)''' Also in the [[Installation guide#Boot loader|install boot loader]] stage, install GRUB on whatever partition that {{ic|/boot}} is on. {{Warning|Do not install GRUB onto ''/dev/sda'' !!! Doing so is likely to lead to an unstable post-environment.}}<br />
** In the [[Installation guide#Configure the system|configure system]] stage, edit /etc/mkinitcpio.conf and ensure the '''keyboard''' hook is in the '''HOOKS''' line somewhere after the '''autodetect''' hook. This will load the drivers for your keyboard in case you need to use it before Arch boots (e.g. entering a [[LUKS]] password or using the troubleshooting shell).<br />
<br />
* When the install process is complete, reboot your computer.<br />
<br />
* If using optical media, hold down the eject key as your MacBook starts, this should eject the Arch Linux install disk.<br />
<br />
* If dual-booting OS X and Arch Linux, hold down the alt (option) key while the system boots to use the Mac bootloader to select which OS to boot.<br />
<br />
== Post-installation ==<br />
<br />
{{Style|Duplicated information, does not comply with [[Help:Style]].}}<br />
<br />
See [[General recommendations]] for system management directions and post-installation tutorials like setting up a graphical user interface, sound or a touchpad.<br />
<br />
==== Video ====<br />
<br />
Different MacBook models have different graphic cards.<br />
To see which graphics card you have type:<br />
<br />
$ lspci | grep VGA<br />
<br />
* If it returns a string containing '''Intel''', read [[Intel graphics]].<br />
<br />
* If it returns '''NVIDIA''', read [[NVIDIA]].<br />
<br />
* Otherwise if it returns '''ATI''' or '''AMD''', read [[ATI]].<br />
<br />
===== NVIDIA note =====<br />
<br />
{{Tip|If you have installed OS in EFI mode and NVIDIA binary drivers are working only in BIOS mode (e.g. you get black screen on EFI boot), try this approach: http://askubuntu.com/a/613573/492886 }}<br />
<br />
For MacBooks with NVIDIA graphics, for the backlight to work properly you may need the {{AUR|nvidia-bl}} package.<br />
<br />
{{Tip|<br />
* If backlight control does not work after installing nvidia-bl, you should [[blacklist]] apple_bl kernel module.<br />
* If backlight control does not work even this way, try setting module parameters. Uncommenting {{ic|1=options nvidia_bl max_level=0x1ffff shift=11}} in {{ic|/etc/modprobe.d/nvidia_bl.conf}} should do the trick.<br />
* Alternatively, you can choose to use the {{AUR|pommed-light}} package. If you do so, you may wish to change the step settings in {{ic|/etc/pommed.conf.mactel}} to something around 5000-10000 depending on how many levels of brightness you desire. The max brightness is around 80000, so take that into account.}}<br />
<br />
==== Touchpad ====<br />
<br />
The touchpad should have basic functionality by default. A true multitouch driver which behaves very similarly to native OS X is included in the {{AUR|xf86-input-mtrack-git}} package. Configuration options are documented in the [https://github.com/BlueDragonX/xf86-input-mtrack readme].<br />
<br />
The following mtrack options work well on a MacBook7,1:<br />
<br />
Option "Thumbsize" "50"<br />
Option "ScrollDistance" "100"<br />
<br />
Probably you need also to add:<br />
<br />
MatchDevicePath "/dev/input/event10"<br />
<br />
To disable tap-to-click (that is, to press down to click) by default, add the following to your mtrack configuration section<br />
<br />
Option "TapButton1" "0" <br />
Option "TapButton2" "0"<br />
Option "TapButton3" "0"<br />
<br />
'''Natural scrolling:''' To configure natural two finger scrolling similar to [http://www.apple.com/au/osx/what-is/gestures.html#gallery-gestures-scroll OS X], refer to [[Touchpad Synaptics#Natural scrolling]].<br />
<br />
If you are using {{AUR|xf86-input-mtrack-git}}, you can simply swap the scroll up and scroll down buttons (along with the scroll left and scroll right):<br />
{{hc|/etc/X11/xorg.conf.d/10-mtrack.conf|<br />
...<br />
Option "ScrollUpButton" "5"<br />
Option "ScrollDownButton" "4"<br />
Option "ScrollLeftButton" "7"<br />
Option "ScrollRightButton" "6"<br />
...}}<br />
<br />
<br />
'''Special Note About Older Macbook Models (confirmed on MacBook2,1):''' On older Macbook models (pre-multitouch), the touchpad will not function properly until you install the xf86-input-synaptics package. Please see [[Touchpad Synaptics]] for more information on installing and configuring this package.<br />
<br />
'''Note on MacBookPro5,5:''' I found it is much simpler to use the {{Pkg|xf86-input-synaptics}} in Extra. Although it does not have much function as 3 finger swipe, this driver provides faster response. {{Pkg|gpointing-device-settings}} also provides a simple GUI config. Below is a Xorg config file /etc/X11/xorg.conf.d/60-synaptics.conf for reference only.<br />
Section "InputClass"<br />
Identifier "touchpad catchall"<br />
Driver "synaptics"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Option "SHMConfig" "on"<br />
Option "TapButton1" "1"<br />
Option "TapButton2" "3"<br />
Option "TapButton3" "2"<br />
Option "PalmDetect" "on"<br />
Option "VertEdgeScroll" "off"<br />
Option "HorizEdgeScroll" "off"<br />
Option "CornerCoasting" "off"<br />
Option "EdgeMotionUseAlways" "off"<br />
Option "AreaLeftEdge" "10"<br />
Option "AreaRightEdge" "1270"<br />
EndSection<br />
'''For some users, the two-finger right-click may not work correctly and trackpad may also become less responsive after these settings. For me, removing the 'AreaLeftEdge' and 'AreaRightEdge', solved that problem.'''<br />
'''OS X like MultiTouch Gestures''' ''currently broken due to newer synaptic drivers!'' For users looking to add more of OS X's multitouch gestures to Arch, [https://github.com/iberianpig/xSwipe xSwipe] is a highly customisable, light weight perl script, which does just that. Once installed and configured (see xSwipe wiki on Github) I would recommend adding xSwipe as a [[Autostarting|start up item]].<br />
<br />
==== Keyboard ====<br />
<br />
MacBook keyboards work by default. For swaping fn keys with Fx keys see [[Apple Keyboard]].<br />
<br />
To enable it you can map with right application like '''xbindkeys''' or through DE preferences; but another very good way, that we recommend, is to install the {{AUR|pommed-light}} package.<br />
<br />
Edit the {{ic|/etc/pommed.conf}} according to your hardware on MacBook, building it from {{ic|/etc/pommed.conf.mac}} or {{ic|/etc/pommed.conf.ppc}} example files.<br />
<br />
Note that you can also run it without a configuration file, the defaults may work for you. Then [[enable]] and start {{ic|pommed.service}}.<br />
<br />
{{Tip|if you are using Gnome or KDE you can easily configure ''3rd level functionality'', ''multimedia key'', etc. in Keyboard Preferences.}}<br />
<br />
{{Note|See the [[Xorg input hotplugging]] page for other configuration information.}}<br />
<br />
===== Keyboard Backlight =====<br />
<br />
The keyboard backlight is controlled by {{ic|/sys/class/leds/smc::kbd_backlight}}. Write the desired value to {{ic|brightness}} in that directory.<br />
<br />
Both {{AUR|acpilight}} or {{AUR|kbdlight}} allow to control keyboard backlight though scripts. With the appropriate udev rules or [[sxhkd]] they allow light-level changes without being root.<br />
<br />
====== NVIDIA note ======<br />
<br />
If the brightness does not function correctly through pommed, make sure you have installed the {{AUR|nvidia-bl}} package and insert<br />
<br />
find . -name "*" -exec sed -i 's/mbp_backlight/nvidia_backlight/' '{}' \;<br />
<br />
into the second line of the pommed PKGBUILD build() function and remake the package. From [https://bbs.archlinux.org/viewtopic.php?id=105091 this forum post].<br />
<br />
Another possible solution is to modify the pommed PKGBUILD build():<br />
<br />
find . -name "*" -exec sed -i 's/nvidia_backlight/apple_backlight/' '{}' \;<br />
<br />
If the previous does not work try the following,<br />
<br />
run nvidia-settings, edit the file '/etc/X11/xorg.conf' and add this line into the Device section:<br />
<br />
Option "RegistryDwords" "EnableBrightnessControl=1"<br />
Save and reboot and check backlight buttons work.<br />
More information available at [https://help.ubuntu.com/community/MacBookPro5-5/Precise#LCD Ubuntu MacBookPro5,5]<br />
<br />
=== Wi-Fi ===<br />
<br />
Different MacBook models have different wireless cards.<br />
<br />
You can easily check what card do your MacBook have by:<br />
<br />
# lspci | grep Network<br />
<br />
* If you have an Atheros card, all should work out-of-the-box.<br />
<br />
* If you have a Broadcom card, follow the [[Broadcom wireless]] page.<br />
<br />
* 5.0 and 6.0 generation MacBooks may have a BCM43xx, follow the instructions for the broadcom-wl driver on the [[Broadcom wireless]] page. The interfaces can swap during reboot so its best to define them in a udev rule (instructions on the [[Broadcom wireless]] page).<br />
<br />
* 8.1 generation MacBooks have BCM4331, for which support is not present in either Linux (3.0 and 3.1) or the proprietary drivers by Broadcom. There is however preliminary support for it in Linux 3.2. To run the drivers on earlier kernels, you will need to use [https://backports.wiki.kernel.org/index.php/Documentation/compat-drivers compat-drivers]<br />
<br />
* If you have the correct broadcom DKMS driver (i.e. broadcom-wl-dkms) installed and your wifi card is still not being recognised, try rebuilding the driver (See [[Dynamic Kernel Module Support]]).<br />
<br />
{{Note|<br />
* If your connection frequently drops, you may have to turn off Wi-Fi power management. If you are running [[pm-utils]], you may override wireless power management by creating an executable file {{ic|/etc/pm/wireless}} with the lines:<br />
#!/bin/sh<br />
iwconfig wlp2s0 power off<br />
* Eduroam or similar may crash your network manager. Simply delaying the connection after login should do the trick<br />
}}<br />
<br />
=== Power management ===<br />
<br />
[[Powerdown]] is a very simple to set up set of scripts what will maximize your battery duration. A MacBook Air 2013 with powerdown provides about 11 hours of light usage with just powerdown installed.<br />
All the usual [[power management]] recomendations apply as well.<br />
<br />
Adding 'acpi_osi=' to kernel parameters reportedly brings the battery life of a MacBook Air 2013 from 5 hours to 11-12 hours. See [https://bbs.archlinux.org/viewtopic.php?pid=1530283#p1530283 this forum post] for more information.<br />
<br />
==== Suspend and Hibernate ====<br />
<br />
Suspending (suspend to ram) and hibernating (suspend to disk) work fine out of the box:<br />
<br />
systemctl suspend<br />
<br />
Issues were reported where the machine would "suspend immediately after resume" in certain conditions when suspending by closing the lid. This was solved by setting the option "sleep-inactive-ac-type" to "nothing" using dconf-editor, option path: org &rarr; gnome &rarr; settings-daemon &rarr; plugins &rarr; power).<br />
<br />
See [[Suspend and hibernate]] for details on how to configure hibernation. Noticably, you'll need a swap partition or file (see the mentioned article for further instructions).<br />
<br />
If after suspend laptop is woken up after few seconds, may help to disable all stuff in /proc/acpi/wakeup, exclude LID0:<br />
# echo XHC1 > /proc/acpi/wakeup<br />
$ cat /proc/acpi/wakeup<br />
Device S-state Status Sysfs node<br />
P0P2 S3 *disabled<br />
EC S3 *disabled<br />
HDEF S3 *disabled pci:0000:00:1b.0<br />
RP01 S3 *disabled pci:0000:00:1c.0<br />
RP02 S3 *disabled pci:0000:00:1c.1<br />
RP03 S3 *disabled pci:0000:00:1c.2<br />
ARPT S4 *disabled pci:0000:03:00.0<br />
RP05 S3 *disabled pci:0000:00:1c.4<br />
RP06 S3 *disabled pci:0000:00:1c.5<br />
SPIT S3 *disabled<br />
XHC1 S3 *disabled pci:0000:00:14.0<br />
ADP1 S3 *disabled<br />
LID0 S3 *enabled<br />
And for permanent disabling:<br />
$ cat /etc/udev/rules.d/90-xhc_sleep.rules <br />
<br />
# disable wake from S3 on XHC1<br />
SUBSYSTEM=="pci", KERNEL=="0000:00:14.0", ATTR{power/wakeup}="disabled"<br />
<br />
If this does not work, check that ARPT is disabled, and add a corresponding rule to udev, like this:<br />
<br />
SUBSYSTEM=="pci", KERNEL=="0000:03:00.0", ATTR{power/wakeup}="disabled"<br />
<br />
If this still does not work, try disabling LID0.<br />
This way suspending via lid-closing should be made impossible, so you might want to follow the instructions in [https://bbs.archlinux.org/viewtopic.php?pid=1556046#p1556046 this forum post] to make suspending via both lid-closing and systemd possible, by using systemd services.<br />
<br />
=== Light sensor ===<br />
<br />
The values can be read from:<br />
<br />
/sys/devices/platform/applesmc.768/light<br />
<br />
A "cat" on this path returns two-tuples like (4,0). The below referenced lighter script ignores the second value - which always seems to be 0 - and uses the first number as measured environment lighting brightness value.<br />
<br />
If you want to use the built in light sensor to automatically adjust screen and keyboard backlight brightness check out<br />
'''Lighter''' [https://github.com/Janhouse/lighter] (simple perl script, easy to fine-tune) and '''Lightum''' [https://github.com/poliva/lightum] (Requires Gnome or KDE but is older and more complete than Lighter).<br />
<br />
=== Sound ===<br />
<br />
{{Tip| If using [[ALSA]], the internal speaker might not be disabled when using the headphone jack. To solve this, enable "Auto-mute" using {{ic|alsamixer}}}}<br />
<br />
First of all follow [[ALSA]] wiki page, then if something does not work correctly, continue reading this part.<br />
<br />
Edit your {{ic|/etc/modprobe.d/50-sound.conf}} or {{ic|/etc/modprobe.d/modprobe.conf}} appending this line:<br />
<br />
options snd_hda_intel model=intel-mac-auto<br />
<br />
This should automatically specify the codec in your MacBook. If you have a MacBookPro12,1, you might need<br />
<br />
options snd-hda-intel index=1,0<br />
<br />
instead. Alternatively, for MacBookPro5,X, you can use:<br />
<br />
options snd_hda_intel model=mb5<br />
<br />
(note that the jack output is controlled with "HP").<br />
<br />
If you have an iMac8,1, you should instead use<br />
<br />
options snd-hda-intel model=mbp3 position_fix=2<br />
<br />
You can try to specify other options, that depend on your hardware. All other possible settings are listed in Kernel Documentation, avaible online:<br />
<br />
* [http://www.kernel.org/doc/Documentation/sound/alsa/ALSA-Configuration.txt ALSA-Configuration.txt]<br />
* [http://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio.txt HD-Audio.txt]<br />
* [http://www.kernel.org/doc/Documentation/sound/alsa/HD-Audio-Models.txt HD-Audio-Models.txt].}}<br />
<br />
Then, reboot.<br />
<br />
=== Bluetooth ===<br />
<br />
Bluetooth should work out-of-the box. See the article on [[Bluetooth]] to install and configure all software needed.<br />
<br />
=== Magic Mouse ===<br />
<br />
If you use a magic mouse you will find it works nicely out of the box. You might want to tweak some settings such as ''scroll-speed'' or ''acceleration''. There is no GUI for this at this time. The only way to set these settings is to instruct the kernel driver ({{ic|hid_magicmouse}}) with parameters. Create a modprobe config file for your mouse.<br />
<br />
{{hc|1=/etc/modprobe.d/magicmouse.conf|2=<br />
options hid_magicmouse scroll-speed=55 scroll-acceleration=1 emulate_3button=0<br />
}}<br />
<br />
<br />
This will instruct the driver to have a fast scroll-speed, do exponential acceleration and do not emulate a 3 button mouse. You can find an overview of all parameters and their current settings in {{ic|/sys/module/hid_magicmouse/parameters}}.<br />
<br />
To play with the settings without rebooting you can also set them through the command line, like so: <br />
<br />
# echo 55 | sudo tee /sys/module/hid_magicmouse/parameters/scroll_speed<br />
<br />
{{Note|Using kernel ''4.10.10-1-macbook'' the Magic Mouse (''hid_magicmouse'') will cause a lot of system lock ups. If you experience random lock ups, try a different, wired, mouse to see if this is the case for you as well.}}<br />
<br />
=== Webcam ===<br />
<br />
==== iSight ====<br />
<br />
{{Note|Linux kernel from 2.6.26 includes the Linux UVC driver natively. '''MBP 6,2+ (Kernel ~2.6.37+) iSight works out of the box''' without the need to use firmware from OS X. Only use {{ic|isight-firmware-tools}} if it doesn't work normally.}}<br />
<br />
iSight webcams on MacBooks or pre 6,2 MacBook Pros (6,2 came out around 2010) require the Apple's proprietary firmware that cannot be redistributed. It must be extracted from OS X and loaded onto Arch.<br />
<br />
You will need to install {{AUR|isight-firmware-tools}} to extract the firmware. This package also includes a udev rule and ELF binary that are necessary, even once you have extracted the firmware file into {{ic|/lib/firmware/isight.fw}}, for the file to be loaded every time you boot your computer (namely {{ic|/etc/udev/rules.d/isight.rules}} which uses {{ic|/usr/lib/udev/ift-load}}).<br />
<br />
Instructions:<br />
<br />
First you need to get the firmware out of a particular file located on your OS X install. It is located in {{ic|/System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBVideoSupport.kext/Contents/MacOS/AppleUSBVideoSupport}}.<br />
<br />
{{ Tip | The {{ic|AppleUSBVideoSupport}} file from a OS X 10.6 (Snow Leopard) installation may not work properly. If possible, use the file from OS X 10.5 or earlier.}}<br />
<br />
To mount the OS X drive if multi-booting:<br />
<br />
# sudo mkdir /media/OSX<br />
# sudo mount -t hfsplus /dev/sda2 /media/OSX<br />
<br />
Then, install the {{AUR|isight-firmware-tools}} package.<br />
<br />
Locate the {{ic|AppleUSBVideoSupport}} file in the OS X directory listed above. Either copy it over to your Arch system (Any OS X installation should do, such as an iMac, not just one specific to your system) or, if multi-booting, mount the OS X drive and navigate to the directory. (On 10.7 (Lion) the directory is {{ic|/System/Library/Extensions/IOUSBFamily.kext/Contents/PlugIns/AppleUSBVideoSupport.kext/Contents/MacOS}}.) In that directory you can go ahead and extract the driver:<br />
<br />
# ift-extract --apple-driver AppleUSBVideoSupport<br />
<br />
When it's done, check that the firmware has been found:<br />
<br />
# ls /lib/firmware/isight.fw<br />
<br />
Once successful, completely '''SHUTDOWN''' your Mac and start it back up again (to clear the hardware state of the webcam). Do ''not'' reboot.<br />
<br />
It should be automatically loaded at boot; if it isn't you can load the '''uvcvideo''' module [[Kernel modules|manually or load it at boot]].<br />
<br />
You can use many applications to test the webcam:<br />
<br />
* MPlayer<br />
<br />
# mplayer tv:// -tv driver=v4l2:width=320:height=240:device=/dev/video0 -fps 30<br />
<br />
* Cheese<br />
* Skype<br />
* Ekiga<br />
<br />
A simple solution to take snapshots is:<br />
<br />
# mplayer tv:// -vf screenshot<br />
<br />
and the pressing the s key to take a snapshot. Files are of the format {{ic|shot\d\d\d\d.png}} and are reported in the standard output.<br />
<br />
==== Facetime HD ====<br />
According to Apple, all recent MacBook models contain a Facetime HD camera instead of the iSight. The following list is an example:<br />
* iMac (21,5" mid 2011)<br />
* iMac (27" mid 2011)<br />
* MacBook Air (mid 2011)<br />
* MacBook Pro (15" early 2011)<br />
* MacBook Pro (17" early 2011)<br />
* MacBook Pro (13" early 2011)<br />
If your MacBook is more recent than the models listed above, it is likely equipped with the Facetime HD camera as well.<br />
<br />
In order to make the camera work, you need to install the {{AUR|bcwc-pcie-dkms}} and {{AUR|bcwc-pcie-firmware}}{{Broken package link|package not found}} packages. This will enable camera video support through the {{ic|facetimehd}} kernel module.<br />
<br />
In order to verify if the Facetime camera is working after the installation of both packages, you'll need to reboot your system.<br />
<br />
{{Note|Keep in mind that, although working, this is a reverse-engineered driver. PC suspension is not supported if a program that is keeping the camera active is running.}}<br />
<br />
=== Temperature Sensors ===<br />
<br />
For reading temperature just install {{Pkg|lm_sensors}}. See the [[lm_sensors]] page for more information.<br />
<br />
=== Color Profile ===<br />
<br />
We can use color profiles from OS X.<br />
<br />
First, install the {{AUR|xcalib}} package.<br />
<br />
Second copy pre-saved color profiles placed in {{ic|/Library/ColorSync/Profiles/Displays/}} on OS X partition to {{ic|~/colorprofiles/}} for example.<br />
<br />
There are color profile files agree with in MacBook models; select the right one:<br />
<br />
* '''Color LCD-4271800.icc''' for MacBook Pro with CoreDuo CPU<br />
* '''Color LCD-4271880.icc''' for MacBook with Core2Duo<br />
* '''Color LCD-4271780.icc''' for MacBook (non-Pro) based on CoreDuo or Core2Duo.<br />
<br />
{{Tip|Also OS X allows to save current color profile from ''Displays > Color'' section of the ''Mac OS System Preferences'', in this case file is saved to {{ic|/Users/<username>/Library/ColorSync/Profiles}}.}}<br />
<br />
Finally you can activate it by running<br />
<br />
# xcalib ~/colorprofile.icc<br />
<br />
{{Note|Previous command set the color profile only for the current session; this mean that you must run it every time you login in your system. For automating it you can execute the command by '''Autostart Application''', concording with your DE (or add the command to your login manager's initialization script, e.g. /etc/gdm/Init/Default).}}<br />
<br />
{{Warning|GNOME will revert the profile set by xcalib. It's preferable to set the profile using '''Color''' in settings.}}<br />
<br />
=== Apple Remote ===<br />
<br />
First, to correctly install and configure the '''lirc''' software that control IR see [[LIRC]] wiki.<br />
<br />
Then make LIRC use {{ic|/dev/usb/hiddev0}} (or {{ic|/dev/hiddev0}}) by editing {{ic|/etc/conf.d/lircd}}. Here is how mine look:<br />
<br />
#<br />
# Parameters for lirc daemon<br />
#<br />
LIRC_DEVICE="/dev/usb/hiddev0"<br />
LIRC_DRIVER="macmini"<br />
LIRC_EXTRAOPTS=""<br />
LIRC_CONFIGFILE="/etc/lirc/lircd.conf"<br />
<br />
Use '''irrecord''' (available when installing '''lirc''') to create a configuration file matching your remote control signals (alternatively, you can try to use the {{ic|lircd.conf}} below):<br />
<br />
# irrecord -d /dev/usb/hiddev0 -H macmini output_conf_file<br />
<br />
Start '''lircd''' and use '''irw''' to check if it works.<br />
<br />
Example of an {{ic|/etc/lirc/lircd.conf}}:<br />
<br />
begin remote<br />
<br />
name lircd.conf.macbook<br />
bits 8<br />
eps 30<br />
aeps 100<br />
<br />
one 0 0<br />
zero 0 0<br />
pre_data_bits 24<br />
pre_data 0x87EEFD<br />
gap 211994<br />
toggle_bit_mask 0x87EEFD01<br />
<br />
begin codes<br />
Repeat 0x01<br />
Menu 0x03<br />
Play 0x05<br />
Prev 0x09<br />
Next 0x06<br />
Up 0x0A<br />
Down 0x0C<br />
end codes<br />
<br />
end remote<br />
<br />
=== HFS partition sharing ===<br />
<br />
First, install the {{Pkg|hfsprogs}} package. <br />
<br />
we have to list our partitions. Use<br />
<br />
fdisk -l /dev/sda<br />
<br />
example output:<br />
<br />
# fdisk -l /dev/sda<br />
Device Boot Start End Blocks Id Type<br />
/dev/sda1 1 26 204819 ee GPT<br />
/dev/sda2 26 13602 109051903+ af Unknown<br />
/dev/sda3 * 13602 14478 7031250 83 Linux<br />
/dev/sda4 14478 14594 932832+ 82 Linux swap / Solaris<br />
<br />
As we see, the "Unknown" partition is our OS X partition, which is located in {{ic|/dev/sda2}}.<br />
<br />
Create a "mac" folder in /media:<br />
<br />
# mkdir /media/mac<br />
<br />
Add at the end of ''/etc/fstab'' this line:<br />
<br />
/dev/sda2 /media/mac hfsplus auto,user,rw,exec 0 0<br />
<br />
Mount it :<br />
<br />
mount /media/mac<br />
<br />
and check it:<br />
<br />
ls /media/mac<br />
<br />
=== HFS+ Partitions ===<br />
<br />
==== Journaling ====<br />
<br />
HFS+ partitions, now the default in OS X, are not fully supported by Linux and are mounted as read-only by default. In order to write to an HFS+ partition, the safe way is to disable journaling. This can be accomplished using the OS X Disk Utility. Refer to this [http://support.apple.com/kb/ht2355 Apple support page] for more information or try to do it from the command line:<br />
<br />
Find your partition:<br />
<br />
$ diskutil list<br />
/dev/disk0<br />
#: TYPE NAME SIZE IDENTIFIER<br />
0: GUID_partition_scheme *750.2 GB disk0<br />
1: EFI EFI 209.7 MB disk0s1<br />
2: Apple_HFS OSX 149.5 GB disk0s2<br />
3: Apple_HFS Macintosh HD 599.2 GB disk0s3<br />
4: Apple_Boot Recovery HD 650.0 MB disk0s4<br />
<br />
In this example we will use ''disk0s3'' partition named as ''Macintosh HD''. To know if journaling is activate or not you could execute:<br />
<br />
$ diskutil info /dev/disk0s3 | grep -i journal<br />
File System Personality: Journaled HFS+<br />
Name (User Visible): Mac OS Extended (Journaled)<br />
Journal: Journal size 49152 KB at offset 0x1176000<br />
<br />
As you can read the journaling is active. To turn off the journaling you could execute:<br />
<br />
$ sudo diskutil disableJournal disk0s3<br />
Password:<br />
Journaling has been disabled for volume Macintosh HD on disk0s3<br />
<br />
To verify it is done execute the info command again:<br />
<br />
$ diskutil info /dev/disk0s3 | grep -i journal<br />
<br />
If you get noting as output, then journaling is disabled.<br />
<br />
However, if you fail to disable journaling. You can change "auto,user,rw,exec" in {{ic|/etc/fstab}} to "auto,user,force,rw,exec" and mount it.<br />
<br />
====Yosemite and later====<br />
<br />
Since Yosemite, HFS+ partitions are now wrapped a CoreStorage volume. Verify that you have an CoreStorage volume.<br />
<br />
# fdisk -l /dev/sdX<br />
Disk /dev/sdX: 298.1 GiB, 320072933376 bytes, 625142448 sectors<br />
Units: sectors of 1* 512 = 512 bytes<br />
Sector size (logical/physical): 512 bytes / 4096 bytes<br />
I/O size (minimum/optimal): 4096 bytes / 4096 bytes<br />
Disklabel type: gpt<br />
Device Start End Sectors Size Type<br />
/dev/sdX1 40 409639 409600 200M EFI System<br />
/dev/sdX2 409640 623872871 623463232 297.3G Apple Core storage<br />
/dev/sdX3 623872872 625142407 1269536 916.0M Apple boot<br />
<br />
HFS+ uses two volume headers, one 1024 bytes into the device and one 1024 from the end of the device. With the HFS+ partition wrapped in the CoreStorage volume the end of the partition is not actually 1024 bytes from the end of the {{ic|/dev/sdX2}} partition.<br />
To fix this you need to specify {{ic|1=sizelimit=X}} when mounting.<br />
<br />
To determine {{ic|sizelimit}} do the following:<br />
<br />
# Run {{ic|testdisk /dev/sdX}} and select your drive<br />
# Select {{ic|EFI GPT}}<br />
# Select {{ic|Analyse}} and then {{ic|Quick Search}}<br />
<br />
Sample output:<br />
TestDisk 7.0, Data Recovery Utility, April 2015<br />
Christophe GRENIER <grenier@cgsecurity.org><br />
http://www.cgsecurity.org<br />
<br />
Disk /dev/sdX - 320 GB / 298 GiB - CHS 38913 255 63<br />
Partition Start End Size in sectors<br />
P EFI System 40 409639 409600 [EFI]<br />
P Mac HFS 409640 623147815 622738176<br />
P Mac HFS 623872872 625142407 1269536<br />
<br />
What you see now is the output of the HFS partition itself without the CoreStorage volume. Take the size in sectors (622738176 in this example) and multiply by the number of bytes in your logical sector size (512 in this example).<br />
<br />
622738176 * 512 = 318841946112<br />
<br />
Finally, mount your disk with the {{ic|1=sizelimit=X}} option.<br />
<br />
mount /dev/sdX -t hfsplus -o ro,sizelimit=318841946112<br />
<br />
===Home Sharing===<br />
<br />
'''''UID Synchronization'''''<br />
<br />
==== In OS X ====<br />
<br />
{{Note|It is strongly recommended that UID/GID manipulation be done immediately after a new user account is created, in OS X as well as in Arch Linux. If you installed OS X from scratch, then this operation is guaranteed to work after logging into your account for the first time.}}<br />
<br />
===== Step 1: change UID and GID(s) =====<br />
<br />
'''''Pre-Leopard'''''<br />
<br />
# Open '''NetInfo Manager''' located in the ''/Applications/Utilities'' folder.<br />
# If not done for you already, enable access to user account transactions by clicking on the closed lock at the bottom of the window, and entering your account password, or root password if you have created a root account.<br />
# Navigate to ''/users/<new user name>'' where <new user name> is the name of the account that will have read/write access to the folder that will be shared with the primary user in Arch.<br />
# Change the '''UID''' value to 1000 (the value used by default for first user created in Arch).<br />
# Also change the '''GID''' value to 1000 (the value used by default for user account creation in Arch).<br />
# Navigate to {{ic|/groups/<new user name>}}, automatically saving the changes you have made so far.<br />
<br />
{{Note|If you get an error message that the transaction is not allowed, log out and log back in.}}<br />
<br />
'''''Leopard'''''<br />
<br />
In Leopard, the '''NetInfo Manager''' application is not present. A different set of steps is required for UID synchronization:<br />
<br />
# Open '''System Preferences'''.<br />
# Click on '''Users & Groups'''.<br />
# Unlock the pane if not already done so.<br />
# Right-click on the desired user and select '''Advanced Options'''.<br />
# Write down the value of the '''User ID''' field, you will need it later on. Change both the UID and GID to match the UID and GID of the account wished to be shared with in Arch (1000 by default for the first user created in Arch).<br />
<br />
===== Step 2: change "Home" permissions =====<br />
<br />
# Open up '''Terminal''' in the {{ic|/Applications/Utilities}} folder.<br />
<br />
# Enter the following command to reclaim the permission settings of your home folder, replacing <your user name>, <your user group> and <your old UID> with the user name whose UID and GID values you just changed, the group name whose GID value you just changed and the old UID number, respectively.<br />
<br />
# find /User/<your user name> -user <your old UID> -exec chown <your user name>:<your user group> {} \;<br />
<br />
==== In Arch ====<br />
<br />
To synchronize your UID in Arch Linux, you are advised to perform this operation ''while creating a new user account''.<br />
It is therefore recommended that you do this as soon as you install Arch Linux.<br />
<br />
Now you must substitute Arch's home with OS X's home, by modify entries of {{ic|/etc/fstab}}.<br />
<br />
=== Avoid long EFI wait before booting ===<br />
<br />
If your MacBook spends 30 seconds with "white screen" before booting you need to tell the firmware where is the booting partition.<br />
<br />
Boot OS X, if do not have it installed, you can use the install DVD (select language, then click Utilities->Terminal), or another MacBook with OS X (connect the two computers via firewire or thunderbolt, start the other MacBook keeping pressed T, boot your MacBook keeping pressed Options).<br />
<br />
Either way, once you got a OS X terminal running on your MacBook you need to execute, as root, a different command if the boot partition is EFI or it is not:<br />
<br />
# bless --device /dev/disk0s1 --setBoot # if the booting partition is EFI<br />
or<br />
# bless --device /dev/disk0s1 --setBoot --legacy # if the booting partition is not EFI<br />
<br />
(given that if your GRUB or EFI is on sda1, /dev/disk1s2 if it is on sdb2, etc). See also https://bbs.archlinux.org/viewtopic.php?pid=833215 and https://support.apple.com/kb/HT1533 .<br />
<br />
=== Mute startup chime ===<br />
<br />
The startup chime volume is controlled by the EFI variable ''SystemAudioVolume-7c436110-ab2a-4bbb-a880-fe41995c9f82''. So it can be muted with<br />
<br />
# printf "\x07\x00\x00\x00\x00" > /sys/firmware/efi/efivars/SystemAudioVolume-7c436110-ab2a-4bbb-a880-fe41995c9f82<br />
<br />
Alternatively, you can use a OS X install disk to mute the chime. Boot from it, select language, then click ''Utilities > Terminal'', and enter<br />
<br />
# /usr/sbin/nvram SystemAudioVolume=%01<br />
<br />
(or whatever volume you want).<br />
<br />
{{Note|Required formatting of the value provided for key SystemAudioVolume may differ depending on MacBook model and perhaps the version of OS X install media. If the above command fails to work, try enclosing the value in double quotes.}}<br />
<br />
=== kworker using high CPU ===<br />
Sometime with the addition of Yosemite, some users found that kworker CPU usage will spike, as disccused [https://bbs.archlinux.org/viewtopic.php?id=171883&p=11 here]. This is sometimes the result of runaway ACPI interrupts.<br />
<br />
To check and see, you can count the number of recent ACPI interrupts and see if any of them are out of control.<br />
<br />
grep . -r /sys/firmware/acpi/interrupts/<br />
<br />
<br />
If you see that one particular interrupt is out of control (possibly GPE66), i.e., registering hundreds of thousands of lines, you can try disabling it (replace XX with the runaway interrupt):<br />
<br />
<br />
echo "disable" > /sys/firmware/acpi/interrupts/gpeXX<br />
<br />
<br />
Disabling random ACPI interrupts could cause all kinds of problems, so do this at your own risk. If this fixes the problem, there is discussion about how to make a systemd service that automatically disables an interrupt at every boot [https://bbs.archlinux.org/viewtopic.php?pid=1488371 here].<br />
<br />
== rEFIt ==<br />
<br />
{{Note|<br />
* You probably want to have a look at [http://www.rodsbooks.com/refind/ rEFInd], which is some type of successor of rEFIt.<br />
* This is not a requirement. It only gives you a menu to choose between OS X and Arch Linux upon every boot.<br />
}}<br />
<br />
For more see, [http://refit.sourceforge.net/myths/ rEFIt myths].<br />
<br />
In OS X, download the ".dmg" from [http://refit.sourceforge.net/ rEFIt Homepage] and install it.<br />
<br />
{{Note|If you have already partitioned your hard disk in preparation for the Arch installation, rEFIt may not be enabled by default. You will have to run the "enable.sh" script installed in /efi/refit/.}}<br />
<br />
Open up '''Terminal''' and enter:<br />
<br />
cd /efi/refit;<br />
./enable.sh<br />
<br />
=== Problems with rEFIt ===<br />
<br />
If you experience problems after the install of Arch or rEFIt, especially is the right OS is not showing up to boot to or if it dumps you at a GRUB prompt stuck like the following:<br />
<br />
GRUB>_<br />
<br />
Then have a look at this link:<br />
<br />
http://mac.linux.be/content/problems-refit-and-grub-after-installation<br />
<br />
It can give you a basic idea on how to boot off the Arch live cd, mount the problem Arch install, chroot, use gptsync, and reinstall GRUB. This is probably for more advanced users who can translate the commands from a debian system to an Arch system and also apply it to the partitions on their machine. Be careful not to install GRUB in the wrong spot.<br />
<br />
If you need a copy of gptsync you can wget it from here:<br />
http://packages.debian.org/sid/gptsync<br />
or try these, for 64 bit:<br />
<br />
wget http://ftp.us.debian.org/debian/pool/main/r/refit/gptsync_0.14-2_amd64.deb<br />
<br />
and for i386:<br />
<br />
wget http://ftp.us.debian.org/debian/pool/main/r/refit/gptsync_0.14-2_i386.deb<br />
<br />
since they are .deb packages you will need the program {{AUR|deb2targz}}.<br />
<br />
==== Mavericks upgrade breaks Arch boot option ====<br />
For some multi-boot users who utilize a separate Linux boot partition, the OS X Mavericks upgrade may overwrite the boot partition with Apple's own recovery boot filesystem. This breaks the Arch Linux boot option in rEFIt/rEFInd. The best way to proceed in this situation is to abandon a separate boot partition and use the EFI system partition (ESP) to install the bootloader of your choice. It is also recommended that you use rEFInd instead of rEFIt as development on the latter has halted.<br />
<br />
Assuming grub2 as the bootloader:<br />
<br />
Use the Arch LiveCD to boot to a shell and [[Change root|chroot]] to your broken Arch Linux environment.<br />
<br />
Mount the ESP on /boot.<br />
<br />
Edit the fstab and remove the old boot partition and make ESP the new boot partition. Now mount the ESP as the new /boot parition.<br />
# mount -a<br />
<br />
[[install|Reinstall]] the {{pkg|linux}} package.<br />
<br />
Create a new initramfs and vmlinuz in /boot.<br />
# mkinitcpio -p linux<br />
<br />
Install grub.<br />
# grub-install --target=x86_64-efi --efi-directory=/boot --bootloader-id=grub --recheck --debug<br />
<br />
Create a new grub.cfg file.<br />
# grub-mkconfig -o /boot/EFI/grub/grub.cfg<br />
<br />
Make sure that grub.cfg is in the same directory as grubx64.efi.<br />
<br />
Generate a new refind_linux.conf file in /boot simply by running mkrlconf.sh which comes with rEFInd.<br />
<br />
Exit the chroot environment.<br />
<br />
Reboot. You should see a new entry for Arch Linux in rEFInd and it should boot to your Arch Linux installation.<br />
<br />
== Model-specific information ==<br />
<br />
=== MacBook ===<br />
<br />
==== April 2016 12" - Version 9,1 ====<br />
<br />
* Booting from USB via EFI works fine, when giving the {{ic|noapic}} kernel option. (On Ubuntu, also {{ic|noacpi nomodeset}} seem to be necessary.) Remember to hold the Alt key on booting.<br />
<br />
* The wireless card works out of the box with {{ic|brcmfmac}}.<br />
<br />
* Suspend / hibernate does not work.<br />
<br />
* The built-in flash drive does ''not'' work with kernel 4.5.4-1-ARCH, but it ''does'' work with kernel 4.6.0-mainline (install {{AUR|linux-mainline}}). As long as a [http://lists.infradead.org/pipermail/linux-nvme/2016-May/004618.html rather trivial patch] is not merged into the kernel, either this patch must be applied locally or one puts {{ic|modprobe nvme; echo 106b 2003 > /sys/bus/pci/drivers/nvme/new_id}} into a mkinitcpio hook (to be started after the udev hook). The reason is that the NVMe controller of the flash drive doesn't advertise itself with the correct PCI device class. Note that with the patch, a short sleep still seems to be necessary.<br />
<br />
* Audio recording works out of the box. Audio playback doesn't work (still looking for a solution).<br />
<br />
* The keyboard and the touchpad do ''not'' work (still looking for a solution).<br />
** There's a WIP driver [https://github.com/cb22/macbook12-spi-driver here] that sort of works with a DSDT hack (the previous problem with this driver related to battery drain has been fixed now).<br />
** The keyboard backlight cannot be enabled [https://bbs.archlinux.org/viewtopic.php?id=219631]<br />
<br />
==== Mid 2007 13" - Version 2,1 ====<br />
<br />
{{Note|I used the 201212 ISO image.}}<br />
<br />
Since older Macbooks have a 32bit EFI running, the usual installation image is not recognized. You need to either remove the UEFI support from the disc ([[Unified_Extensible_Firmware_Interface#Remove_UEFI_boot_support_from_ISO]]) or build a 32bit EFI version of the disc. The paragraphs below will take the first path to success, booting into BIOS mode and its pitfalls. For a try the other way round, read [[Unified_Extensible_Firmware_Interface#Create_UEFI_bootable_USB_from_ISO]] first.<br />
<br />
First prepare your harddisc according to your wishes. In this scenario it was a "Linux only" approach with<br />
<br />
/dev/sda1 HFS+ AF00 200M -> EFI boot system on Apple HFS+ partition<br />
/dev/sda2 ext4 8300 147G -> arch system<br />
/dev/sda3 swap 8200 1G -> swap<br />
<br />
The {{Pkg|hfsprogs}} package contains the tools to handle HFS/HFS+ filesystems. The rEFInd bootloader recognizes it on its own. Usually the partition for the EFI bootloader is a FAT32 (vfat) partition. In this case I tried rEFIt first, which apparently needs the HFS+ filesystem to work, and kept it at that.<br />
<br />
The mount points are:<br />
<br />
/dev/sda2 -> /<br />
/dev/sda1 -> /boot<br />
<br />
The bootloader in use was [http://www.rodsbooks.com/refind/index.html rEFInd] instead of rEFIt. To install it, the rEFInd homepage provides a good guide. Usually it is simply done by copying rEFInd:<br />
<br />
mkdir /boot/EFI<br />
cp -vr /usr/share/refind/drivers_ia32 /boot/EFI/refind/<br />
cp -vr /usr/share/refind/tools_ia32 /boot/EFI/refind/<br />
cp -vr /usr/share/refind/fonts /boot/EFI/refind/<br />
cp -vr /usr/share/refind/icons /boot/EFI/refind/<br />
cp -v /usr/share/refind/refind_ia32.efi /boot/EFI/refind/<br />
cp -v /usr/share/refind/refind.conf-sample /boot/EFI/refind/refind.conf<br />
cp -v /usr/share/refind/refind_linux.conf-sample /boot/refind_linux.conf<br />
<br />
{{Note|I'm using the 32bit version of Arch and refind, since the EFI of the old MacBooks is 32bit. I'm not sure about 32bit rEFInd booting a 64bit Arch...}}<br />
<br />
The pitfall here is, that the system bootet in BIOS compatibility mode and not in EFI mode. You cannot therefore use {{ic|efibootmgr}}, because the EFI variables (even with 'modprobe efivars') are not available. While installing the system get {{AUR|mactel-boot}}. The {{ic|hfs-bless}} utility comes in handy, when blessing the EFI bootloader. This is done by calling:<br />
<br />
hfs-bless /boot/EFI/refind/refind_ia32.efi<br />
<br />
Since the Linux kernel does come with EFI stub enabled, it seems a good idea to run it through a bootloader first. Especially if it runs not out of the box. But using rEFInd makes GRUB (or any other bootloader) obsolete, because of that.<br />
<br />
{{Note|In the refind_linux.conf you add any kernel option you may want as long as you use the EFI stub of your kernel. In refind.conf you adjust your needs for the bootloader itself, like menu entries. If you use them (menu entries), rEFInd should not look for these EFI stub kernels itself, so blacklist the directories used in here, like {{ic|/boot/}}.}}<br />
<br />
Not running out of the box is unfortunately the initial stage for the kernel. Since we installed it in BIOS mode, two modules are missing to grant access to the root partition while booting. Hence the 'initfsram-linux.img' can not be found/loaded. Adding the following modules to your 'MODULES' line in {{ic|/etc/mkinitcpio.conf}} solved this ([https://bbs.archlinux.org/viewtopic.php?pid=1139226#p1139226 original post]).<br />
<br />
{{hc|/etc/mkinitcpio.conf|2=<br />
MODULES="ahci sd_mod"}}<br />
<br />
Rebuild your kernel image:<br />
<br />
mkinitcpio -p linux<br />
<br />
The bootloader rEFInd can scan kernels even out of the '/boot/...' directory and assumes an efi kernel even without the extension '.efi'. If you do not want to try out special kernels, this should work without the hassle to copy each kernel after building to some spot special.<br />
<br />
If you happen to get multiple entries for one boot image, it often results of a previous installation of a bootloader within the MBR. To remove that, try the following - taken from the [http://ubuntuforums.org/showpost.php?p=7828260&postcount=4 original post]. This is valid for GPT partitioned discs, so please check your environment and save your MBR first.<br />
<br />
# dd if=/dev/zero of=/dev/sda bs=440 count=1<br />
<br />
=== MacBook Pro ===<br />
<br />
==== Early 2015 13"/15" - Version 12,x/11,4+ ====<br />
<br />
===== Wireless =====<br />
The {{ic|brcmfmac}} driver is working as of 2015-11-20, with newer firmware necessary for working 5GHz support ([https://bugzilla.kernel.org/show_bug.cgi?id=100201#c65 see here.])<br />
<br />
{{<br />
Note| On the Macbook Pro 12,1 if the {{ic|brcmfmac}} driver can not be started and the following errors occur in the journal:<br />
<br />
{{bc|<nowiki><br />
brcmfmac: brcmf_chip_recognition: chip backplane type 15 is not supported<br />
brcmfmac: brcmf_pcie_probe: failed 14e4:43ba<br />
</nowiki>}}<br />
<br />
then check whether [[Power_management#PCI_Runtime_Power_Management|PCI runtime power management]] is enabled on the device, and disable it if so.<br />
<br />
}}<br />
<br />
===== Bluetooth =====<br />
Bluetooth is fully supported starting from kernel-4.4.0.<br />
<br />
===== Suspend & Power Off (11,4+) =====<br />
The 11,4 and 11,5 MacBook Pros do not shutdown or suspend correctly with the default kernel. This issue is being addressed in [https://bugzilla.kernel.org/show_bug.cgi?id=103211 Bug 103211] and a temporary patch is currently available in {{AUR|linux-macbook}}.<br />
<br />
Note that [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/arch/x86/pci/fixup.c?h=v4.13-rc1&id=13cfc732160f7bc7e596128ce34cda361c556966 Linux 4.13.0] has this patch included, and will be released shortly.<br />
<br />
===== Keyboard & Trackpad =====<br />
Haptic feedback works out of the box due to the trackpad's built-in firmware.<br />
<br />
There are several drivers available that provide multitouch support. The following have been confirmed working with the MacBookPro12,1.<br />
<br />
For {{Pkg|xf86-input-libinput}} the following configuration emulates some features from the OS X functionality. For more options see {{man|4|libinput|url=https://www.mankier.com/4/libinput}}.<br />
{{hc|1=/etc/X11/xorg.conf.d/90-libinput.conf|2=<br />
Section "InputClass"<br />
Identifier "libinput touchpad catchall"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"<br />
Driver "libinput"<br />
Option "NaturalScrolling" "true"<br />
EndSection<br />
}}<br />
<br />
For {{Pkg|xf86-input-synaptics}} the following configuration is necessary to make the touchpad work fully.<br />
{{hc|1=/etc/X11/xorg.conf.d/60-magictrackpad.conf|2=<br />
Section "InputClass"<br />
Identifier "Trackpad"<br />
Driver "synaptics"<br />
MatchIsTouchpad "on"<br />
MatchDevicePath "/dev/input/event*"<br />
EndSection<br />
}}<br />
<br />
Further, some US/ANSI keyboards suffer from an issue where the tilde key (~, the key vertically between Esc and Tab) registers as < and >. The following config file fixes this issue.<br />
<br />
{{hc|1=/etc/modprobe.d/hid_apple.conf|2=<br />
options hid_apple iso_layout=0<br />
}}<br />
<br />
See [https://bugzilla.kernel.org/show_bug.cgi?id=96771 this kernel bugzilla] for more details and the relevant patches for earlier kernels.<br />
<br />
===== Graphics =====<br />
For Intel-only graphics, install the {{Pkg|xf86-video-intel}} package. For more information or OpenGL/3D support, follow instructions at [[Intel graphics]].<br />
<br />
For Dual Graphics see [[MacBookPro11,x#Graphics]].<br />
<br />
{{Note|The kernel parameters ''acpi_backlight'', ''i915.lvds_downclock'', ''i915.enable_ips'', and ''intel_iommu'' are no longer necessary as of kernel 4.2.}}<br />
{{Note|(Kernel 4.10.8, MacBook Pro 11,4) If you experience system lock ups and/or tearing in Xorg, remove the .{{Pkg|xf86-video-intel}} completely, including any config file you made for it. Xorg will default to its modesetting DDX driver. The performance of this driver is good and the locks go away. See also: [[Intel graphics]]}}<br />
<br />
==== 2012 - 2014 models ====<br />
<br />
* [[MacBookPro11,x]] (Late 2013—Mid 2014)<br />
* [[MacBookPro10,x]] (Mid 2012—Early 2013)<br />
<br />
=== MacBook Air===<br />
<br />
==== Early 2014 11" - Version 6,1 ====<br />
This is almost the same as the 2013 version, where the only known difference is a slightly faster processor. The version numbers have not been changed since the 2013 version.<br />
<br />
It works excellently after following the instructions for the MBA 2013 13" here and in the forum thread.<br />
Bluetooth, which has been reported not working for some people with the 2013 version, works without trouble for the 2014 version, although it should be excactly the same.<br />
<br />
{{Note| Unless you have a local repository on a USB disk, you need a USB to ethernet adaptor or a USB wireless adaptor supported natively by the kernel to easily install Arch Linux, since you have to install the {{Pkg|broadcom-wl-dkms}} package to make the internal wireless adaptor work.}}<br />
<br />
Unresolved issues:<br />
* There is no driver for the webcam yet.<br />
* rEFInd uses 30 seconds to start booting. Using the bless trick stops rEFInd from loading, and it has to be re-installed.<br />
<br />
==== Mid 2013 13" - Version 6,2 ====<br />
[https://bbs.archlinux.org/viewtopic.php?id=165899 Dedicated forum thread]<br />
===== Installing and booting =====<br />
Booting from a normal 2013.6 USB key works fine, but I could not seem to get either GRUB or Syslinux working.<br />
<br />
I was able to boot by first installing Arch Linux following the MacBook guide at the wiki (having a separate FAT32 /boot partition). Skip the bootloader installation. <br />
<br />
Installing [http://www.rodsbooks.com/refind/getting.html rEFInd] from OS X (important!) and installing the EFI stub loader made me able to boot fine.<br />
<br />
[https://bbs.archlinux.org/viewtopic.php?id=165710 Dedicated thread].<br />
<br />
{{Note| Installing [http://www.rodsbooks.com/refind/getting.html rEFInd] from Linux (or from OS X, but to the esp) also works fine}}<br />
<br />
===== Arch Only Installation =====<br />
This method works without rEFInd and uses grub to boot EFI. Partition as follows:<br />
<br />
/dev/sda1 200M Microsoft basic data<br />
/dev/sda2 256M Linux filesystem<br />
/dev/sda3 4G Linux swap<br />
/dev/sda4 108.6G Linux filesystem<br />
<br />
sda1 can also be a HFS+ partition for EFI. This example chooses to use FAT32 (vfat). Although swap is optional, it is required for hibernation. Instead of sda4 for root and home, an alternative partition scheme would be to make sda4 as root and sda5 as home.<br />
<br />
Format and mount:<br />
<br />
mkfs.vfat -F 32 /dev/sda1<br />
mkfs.ext2 /dev/sda2<br />
mkswap /dev/sda3<br />
swapon /dev/sda3<br />
mkfs.ext4 /dev/sda4<br />
<br />
mount /dev/sda4 /mnt<br />
mkdir /mnt/boot<br />
mount/dev/sda2 /mnt/boot<br />
mkdir /mnt/boot/efi<br />
mount /dev/sda1 /mnt/boot/efi<br />
<br />
Finish the installation according to the [[Installation guide]] and skip anything after the bootloader. After you have generated your initramfs and set root passwd follow below to setup grub:<br />
<br />
pacman -S grub efibootmgr<br />
mount -t efivarfs efivarfs /sys/firmware/efi/efivars<br />
grub-install --target=x86_64-efi --efi-directory=/boot/efi --bootloader-id=grub --recheck --debug<br />
grub-mkconfig -o /boot/efi/EFI/grub/grub.cfg<br />
cp /boot/efi/EFI/grub/grub.cfg /boot/grub/grub.cfg<br />
cp /boot/efi/EFI/grub/grubx64.efi /boot/efi/EFI/boot/bootx64.efi}}<br />
<br />
Now you can exit/unmount/reboot:<br />
exit<br />
umount -R /mnt<br />
reboot<br />
<br />
===== Stability problems =====<br />
{{Note| Passing {{ic|<nowiki>libata.force=1:noncq</nowiki>}} to the kernel parameters solves the problem.}}<br />
This is the big worry for me. Every now and then my system hangs for a brief moment and everything involving net or disk access just hangs there for a while and then it seems to work. <br />
So far it only seems to happen when I run something disk- or CPU-intensive. Also had an occassion when I could not start X and just got this repeating all over my screen:<br />
<br />
ata1.00: failed command: WRITE FPDMA QUEUED<br />
ata1.00: cmd 61/08:f0:10:8c:c2/00:00:0b:00:00/40 tag 30 ncq 4096 out<br />
res 40/00:00:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)<br />
ata1.00: status: { DRDY }<br />
<br />
On the next attempt it worked fine.<br />
I did SMART short and long tests on my disk and they returned fine:<br />
<br />
[http://pastebin.com/vRE4T2Ld smartctl -a]<br />
<br />
There are some messages in my boot that indicate this could be disk and/or ACPI related.<br />
<br />
These are with 2013-06 ISO, 3.9.7-1 2013 x86_64 kernel.<br />
<br />
[http://pastebin.com/mjTJaPFa journalctl -b]<br />
Seems to only work with the headphone jack, not with the speakers.<br />
<br />
[http://pastebin.com/SdAcHuKh dmesg]<br />
<br />
{{Note | Same problem in 2017 with a Macbook Air early 2014. Updating the firmware (via migration to macOS Sierra) solved the issue.}}<br />
<br />
===== Marvell ATA suspend bugs =====<br />
If you have 2013 MacBook Air with a Marvell 128 or 256 GB drive, you might get the following ata errors instead after pm-suspend/resumes:<br />
<br />
ata1: exception Emask 0x10 SAct 0x0 SErr 0x10000 action 0xe frozen<br />
ata1: irq_stat 0x00400000, PHY RDY changed<br />
ata1: SError: { PHYRdyChg }<br />
ata1: hard resetting link<br />
ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310)<br />
ata1.00: unexpected _GTF length (8)<br />
ata1.00: unexpected _GTF length (8)<br />
ata1.00: configured for UDMA/33<br />
ata1: EH complete<br />
<br />
Try what Patrick and Tejun figured out on the [https://bugzilla.kernel.org/show_bug.cgi?id=62351 linux bug]. I followed what Patrick describes with sata_alpm, and I haven't seen the issue since.<br />
<br />
There are more steps on how to resolve this issue in [https://bbs.archlinux.org/viewtopic.php?pid=1562168#p1562168 this thread on the Arch forum]<br />
<br />
===== Suspend/Resume =====<br />
Brightness is either 0% or 100% after resuming from suspend. Until the kernel is fixed, use patjak's fix by installing {{AUR|mba6x_bl-dkms}}. Patjak's github is at [https://github.com/patjak/mba6x_bl].<br />
===== WiFi =====<br />
WiFi does not work out of the box. Install {{Pkg|broadcom-wl-dkms}} to connect to a network. <br />
<br />
===== Touchpad =====<br />
Since 3.10.3 kernel touchpad works perfectly with {{Pkg|xf86-input-synaptics}}.<br />
<br />
===== Audio =====<br />
As of Linux 3.12, sound works out of the box. If you do not get sound with only {{pkg|alsa-utils}}, you may need to create a /etc/asound.conf with below entries:<br />
<br />
defaults.pcm.card 1<br />
defaults.pcm.device 0<br />
defaults.ctl.card 1<br />
<br />
==== Mid 2012 13" — version 5,2 ====<br />
<br />
Kernel panics using default boot media under arch kernel 3.5. Adding <code>intremap=off</code> fixes this. Additionally, there are problems loading the <code>applesmc</code> module (meaning the temperature sensors, fan, and keyboard backlight do not work). These problems are fixed in the linux 3.6-rc4 mainline kernel (I have tested).<br />
<br />
==== Mid 2012 11.5" — Version 5,1 ====<br />
<br />
If you have issues with waking from sleep while in X11 such as a black screen or showing the console with a frozen mouse cursor then remove {{Pkg|xf86-input-synaptics}} and install {{AUR|xf86-input-mtrack-git}}. This fixed errors such as <br />
(EE) [dix] bcm5974: unable to find touch point 0<br />
and backtraces that causes X11 to crash. This might apply to Version 5,2 assuming they use the same trackpad.<br />
<br />
==== Mid 2011 — version 4,x ====<br />
<br />
Works out-of-the-box since kernel 3.2. It is recommended to use [[Archboot]], install [[GRUB]] and use EFI.<br />
<br />
==== Early 2008 — version 1,1 ====<br />
<br />
Everything works out of the box though you will need the {{Pkg|b43-fwcutter}} package (or simply {{AUR|b43-firmware}}) for the wireless adapter to work.<br />
<br />
Since this model has only one USB port, you may find it easiest to install Arch with a powered USB hub. Plug a USB network adapter (wireless or ethernet adapter to plug into a USB port) and your Arch installation media into the USB hub.<br />
<br />
If you can't get any result by scanning wireless network after boot, unload modules <code>b43</code> and <code>ssb</code> and load them again:<br />
<br />
rmmod ssb<br />
rmmod b43<br />
modprobe b43<br />
<br />
There is a good chance you will find what's wrong with DMA from the dmesg log.<br />
<br />
Even if you can scan wireless networks after reloading the modules, it's still possible that you will only be able to connect to some networks, but not all of them. According to a more detailed discussion here: http://crunchbang.org/forums/viewtopic.php?id=17368, adding <code>pio=1,qos=0</code> options to the b43 module can solve this problem.<br />
<br />
I tested this for a 13' MacBookAir1,1 with a BCM4321 chipset, and it works.<br />
<br />
== See also ==<br />
* '''MacBook Air'''<br />
** [http://dabase.com/blog/Macbook_Air_Early_2014_Archlinux/ Macbook Air Early 2014 — dabase.com]<br />
** [http://www.frankshin.com/installing-archlinux-on-macbook-air-2013/ Installing Archlinux on Macbook Air 2013 — Frank Shin]<br />
** [http://blog.panks.me/posts/2013/06/arch-linux-installation-with-os-x-on-macbook-air-dual-boot/ Arch Linux Installation with OS X on Macbook Air (Dual Boot) — Pankaj Kumar]{{Dead link|2017|06|01}}<br />
** [http://ryangehrig.com/index.php/arch-linux-on-macbook-air-2013/ Arch Linux – MacBook Air 2013 — Ryan Gehrig]<br />
** [http://www.nico.schottelius.org/blog/macbook-air-42-archlinux/ Installing Linux on a Macbook Air (4,2) — Nico Schottelius]<br />
** [http://www.dm9.se/?p=398 Arch linux single, pure efi boot on the macbook air3,1/3,2 — DIMENSION9]<br />
* '''MacBook Pro'''<br />
** http://www.netsoc.tcd.ie/~theorie/interblag/2010/01/30/installing-arch-linux-on-a-mac-pro/{{Dead link|2017|06|01}}<br />
** http://allanmcrae.com/2010/04/installing-arch-on-a-macbook-pro-5-5/<br />
** http://allanmcrae.com/2012/04/installing-arch-on-a-macbook-pro-8-1/<br />
** http://linux-junky.blogspot.com/2011/08/triple-boot-archlinux-windows-7-and-mac.html</div>Ndthttps://wiki.archlinux.org/index.php?title=DisplayLink&diff=351109DisplayLink2014-12-20T13:56:34Z<p>Ndt: /* Configuring X Server */ better show connection between udl/xrandr</p>
<hr />
<div>[[Category:Other hardware]]<br />
DisplayLink devices on Linux still only have experimental support. While some people have had success in using them, it is generally not an easy process and not guaranteed to work. The steps on this page describe the generally most successful methods of using external monitors with DisplayLink.<br />
<br />
==Installation==<br />
<br />
{{Note|1=Modern USB 3.0 DisplayLink adapters are not supported as of October 2014.[http://displaylink.org/forum/showthread.php?t=1748] Older DisplayLink chips (USB 2.0) are supported.}}<br />
<br />
Install the {{Pkg|xf86-video-fbdev}} package, which provides framebuffer video for X.org.<br />
<br />
Hardware-level support is provided by the [[Kernel modules|kernel module]] {{ic|udlfb}}, which should be loadable by default in Arch.<br />
=== udl === <br />
<br />
The kernel [[Wikipedia: Direct_Rendering_Manager |DRM]] driver for DisplayLink is {{ic|udl}}, a rewrite of the original [https://www.kernel.org/doc/Documentation/fb/udlfb.txt udlfb] driver. It allows configuring DisplayLink monitors using [[Xrandr]].<br />
<br />
First, the setup and installation:<br />
<br />
* [[Kernel modules#Blacklisting|Blacklist]] the old kernel module, {{ic|udlfb}}, which may attempt to load itself first.<br />
* [[Pacman|Install]] {{Pkg|xf86-video-modesetting}}, the required [[Xorg]] driver.<br />
<br />
After that, run:<br />
<br />
{{hc|# xrandr --listproviders|<nowiki><br />
Providers: number : 2<br />
Provider 0: id: 0x49 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 8 associated providers: 0 name:Intel<br />
Provider 1: id: 0x13c cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 0 name:modesetting<br />
</nowiki>}}<br />
<br />
In the above output, we can see that provider 0 is the system's regular graphics provider (Intel), and provider 1 (modesetting) is the DisplayLink provider. To use the DisplayLink device, connect provider 1 to provider 0:<br />
<br />
# xrandr --setprovideroutputsource 1 0<br />
<br />
and xrandr will add a DVI output you can [[Xrandr#Configuration|use as normal with xrandr]]. This is still experimental but supports hotplugging and when works, it's by far the simplest setup. If it works then everything below is unnecessary.<br />
<br />
==Configuration==<br />
<br />
These instructions assume that you already have an up and running X server and are simply adding a monitor to your existing setup.<br />
<br />
===Load the framebuffer device===<br />
<br />
Before your system will recognize your DisplayLink device, the {{ic|udl}} kernel module must be loaded. To do this, run<br />
<br />
# modprobe udl<br />
<br />
If your DisplayLink device is connected, it should show some visual indication of this. Although a green screen is the standard indicator of this, other variations have been spotted and are perfectly normal. Most importantly, the output of {{ic|dmesg}} should show something like the following, indicating a new DisplayLink device was found:<br />
<br />
{{bc|<nowiki>usb 2-1.1: new high-speed USB device number 7 using ehci-pci<br />
usb 2-1.1: New USB device found, idVendor=17e9, idProduct=03e0<br />
usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br />
usb 2-1.1: Product: Lenovo LT1421 wide<br />
usb 2-1.1: Manufacturer: DisplayLink<br />
usb 2-1.1: SerialNumber: 6V9BBRM1<br />
[drm] vendor descriptor length:17 data:17 5f 01 00 15 05 00 01 03 00 04<br />
udl 2-1.1:1.0: fb1: udldrmfb frame buffer device<br />
[drm] Initialized udl 0.0.1 20120220 on minor 1<br />
</nowiki>}}<br />
<br />
Furthermore, {{ic|/dev}} should contain a new {{ic|fb}} device, likely {{ic|/dev/fb1}} if you already had a framebuffer for your primary display.<br />
<br />
To automatically load {{ic|udl}} at boot, create the file {{ic|udl.conf}} in {{ic|/etc/modules-load.d/}} with the following contents:<br />
<br />
{{hc|/etc/modules-load.d/udl.conf|udl}}<br />
<br />
For more information on loading kernel modules, see [[Kernel modules#Loading]].<br />
<br />
===Configuring X Server===<br />
There are three popular ways people use DisplayLink devices with X on desktop Linux computers:<br />
* With {{ic|xrandr}} and {{ic|udl}} (recommended)<br />
* Xinerama with a single X server<br />
* Two separate X servers, linked together in some way<br />
While Xinerama is probably the more desirable setup, it is also less likely to work. Both methods are described below.<br />
<br />
====xrandr====<br />
<br />
The {{ic|udl}} kernel driver is the only one that works wiith [[Xrandr|xrandr]]. Once the driver is loaded, the DisplayLink monitor is listed as an output provider:<br />
<br />
{{hc|$ xrandr --listproviders|<nowiki><br />
Providers: number : 2<br />
Provider 0: id: 0x43 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 2 associated providers: 1 name:Intel<br />
Provider 1: id: 0xcb cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting<br />
</nowiki>}}<br />
In the above example, provider 1 is the DisplayLink device, and provider 0 is the default display. Running {{ic|xrandr --current}} gives a list of available screens:<br />
<br />
{{hc|$ xrandr --current|<nowiki><br />
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192<br />
LVDS1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm<br />
1600x900 60.0*+ 40.0 <br />
1440x900 59.9 <br />
1360x768 59.8 60.0 <br />
1152x864 60.0 <br />
1024x768 60.0 <br />
800x600 60.3 56.2 <br />
640x480 59.9 <br />
VGA1 disconnected (normal left inverted right x axis y axis)<br />
DVI-1-0 connected (normal left inverted right x axis y axis)<br />
1366x768 60.0 +<br />
1368x768_59.90 59.9 <br />
1368x768_59.90 (0xd0) 85.7MHz<br />
h: width 1368 start 1440 end 1584 total 1800 skew 0 clock 47.6KHz<br />
v: height 768 start 769 end 772 total 795 clock 59.9Hz<br />
</nowiki>}}<br />
<br />
If the above does not list the DisplayLink screen, then you will need to offload DisplayLink to the main GPU:<br />
<br />
{{bc|xrandr --setprovideroutputsource 1 0}}<br />
<br />
Once the screen is available, refer to [[Xrandr]] for info on setting it up. For automating the configuration process, see [https://github.com/nathantypanski/displaylink.sh displaylink.sh].<br />
<br />
====Xinerama setup====<br />
You must update or create an [[xorg.conf]] with a properly configured {{ic|ServerLayout}} to use a DisplayLink monitor, as Xorg will prefer internal monitors by default. The DisplayLink device is normally only usable if it is set as {{ic|screen0}} and the internal display as {{ic|screen1}}.<br />
<br />
Add this to the bottom of your {{ic|xorg.conf}}:<br />
{{hc|/etc/X11/xorg.conf|<br />
################ DisplayLink ###################<br />
Section "Device"<br />
Identifier "DisplayLinkDevice"<br />
Driver "fbdev" <br />
BusID "USB" # needed to use multiple DisplayLink devices <br />
Option "fbdev" "/dev/fb0" # change to whatever device you want to use<br />
# Option "rotate" "CCW" # uncomment for rotation<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "DisplayLinkMonitor"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "DisplayLinkScreen"<br />
Device "DisplayLinkDevice"<br />
Monitor "DisplayLinkMonitor"<br />
DefaultDepth 16<br />
EndSection<br />
}}<br />
<br />
Then edit your server layout to look something like this<br />
<br />
Screen 0 "DisplayLinkScreen"<br />
Screen 1 "Internal" RightOf "DisplayLinkScreen"<br />
Option "Xinerama" "on"<br />
<br />
Change ''Internal'' to your main display, then restart X.<br />
====Dual X setup====<br />
Refer to the steps covered in the [http://wiki.gentoo.org/wiki/DisplayLink#Two_X_server Gentoo Wiki] for details on this setup.<br />
<br />
==Troubleshooting==<br />
<br />
===Screen redraw is broken===<br />
If you are using {{ic|udl}} as your kernel driver and the monitor appears to work, but is only updating where you move the mouse or when windows change in certain places, then you probably have the wrong modeline for your screen. Getting a proper modeline for your screen with a command like<br />
<br />
{{bc|<br />
gtf 1366 768 59.9<br />
}}<br />
<br />
where {{ic|1366}} and {{ic|768}} are the horizontal and vertical resolutions for your monitor, and {{ic|59.9}} is the refresh rate from its specs. To use this, create a new mode with {{ic|xrandr}} like follows:<br />
<br />
{{bc|<br />
xrandr --newmode "1368x768_59.90" 85.72 1368 1440 1584 1800 768 769 772 795 -HSync +Vsync<br />
}}<br />
<br />
and add it to [[Xrandr]]:<br />
<br />
{{bc|<br />
xrandr --addmode DVI-0 1368x768_59.90<br />
}}<br />
<br />
Then tell the monitor to use that mode for the DisplayLink monitor, and this should fix the redraw issues. Check the [[Xrandr]] page for information on using a different mode.<br />
<br />
===X crashes or keeps blank===<br />
<br />
If X crashes, or nothing is shown at load, try to start X only using the external display by updating {{ic|xorg.conf}} as follows:<br />
<br />
{{bc|<br />
Screen 0 "DisplayLinkScreen"<br />
#Screen 1 "Internal" RightOf "DisplayLinkScreen"<br />
#Option "Xinerama" "on"<br />
}}<br />
<br />
There are reported instances in which Xinerama requires all its {{ic|Screen}} color depths to be the same. In both {{ic|Screen}} sections, try changing the {{ic|DefaultDepth}} to 16.<br />
<br />
{{bc|<br />
Section "Screen"<br />
...<br />
DefaultDepth 16<br />
...<br />
EndSection<br />
<br />
}}<br />
<br />
{{Note| With fbdev this is not true anymore, because fbdev provides virtual 24 bit support. Everything may be used with {{ic|DefaultDepth 24}}. However, USB 2.0 has less bandwidth than a standard monitor, so a performance update may be seen from setting it to 16 bit mode.}}<br />
<br />
===Cannot start in framebuffer mode. Please specify busIDs for all framebuffer devices===<br />
<br />
With two monitors configured in Xinerama mode, {{ic|/var/log/Xorg.0.log}} will sometimes display the following error:<br />
<br />
{{bc|<br />
Fatal server error:<br />
Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices<br />
}}<br />
<br />
As indicated by [http://forums.gentoo.org/viewtopic-t-809655.html this Gentoo Forums thread], KMS might be incompatible with fbdev. They also suggested the possible fix of running {{ic|startx -- -retro}} which will allow X to run even when, to X itself, it doesn't appear to be working.<br />
<br />
{{Note |1= A [https://bugs.freedesktop.org/show_bug.cgi?id=65384 bug report] has been filed for this issue.}}<br />
<br />
===DisplayLink refresh rate is extremely slow with gnome 3===<br />
If once you set up your DisplayLink your entire desktop becomes slow, and maximizing a window on the displaylink screen reduces the lag, try adding the screen manually via xrandr:<br />
{{bc|<br />
xrandr -q<br />
xrandr --output [screen_here] --right-of [other_screen] --auto<br />
}}<br />
<br />
==See Also==<br />
<br />
* [http://displaylink.org/forum/forumdisplay.php?f=29 DisplayLink Open Source]: Official DisplayLink open source support forum<br />
* [http://plugable.com/platforms/linux Plugable]: Vendor blog chronicling Linux support for DisplayLink.</div>Ndthttps://wiki.archlinux.org/index.php?title=DisplayLink&diff=351094DisplayLink2014-12-20T13:09:53Z<p>Ndt: /* xrandr */ change displaylink.sh link to GitHub repo</p>
<hr />
<div>[[Category:Other hardware]]<br />
DisplayLink devices on Linux still only have experimental support. While some people have had success in using them, it is generally not an easy process and not guaranteed to work. The steps on this page describe the generally most successful methods of using external monitors with DisplayLink.<br />
<br />
==Installation==<br />
<br />
{{Note|1=Modern USB 3.0 DisplayLink adapters are not supported as of October 2014.[http://displaylink.org/forum/showthread.php?t=1748] Older DisplayLink chips (USB 2.0) are supported.}}<br />
<br />
Install the {{Pkg|xf86-video-fbdev}} package, which provides framebuffer video for X.org.<br />
<br />
Hardware-level support is provided by the [[Kernel modules|kernel module]] {{ic|udlfb}}, which should be loadable by default in Arch.<br />
=== udl === <br />
<br />
The kernel [[Wikipedia: Direct_Rendering_Manager |DRM]] driver for DisplayLink is {{ic|udl}}, a rewrite of the original [https://www.kernel.org/doc/Documentation/fb/udlfb.txt udlfb] driver. It allows configuring DisplayLink monitors using [[Xrandr]].<br />
<br />
First, the setup and installation:<br />
<br />
* [[Kernel modules#Blacklisting|Blacklist]] the old kernel module, {{ic|udlfb}}, which may attempt to load itself first.<br />
* [[Pacman|Install]] {{Pkg|xf86-video-modesetting}}, the required [[Xorg]] driver.<br />
<br />
After that, run:<br />
<br />
{{hc|# xrandr --listproviders|<nowiki><br />
Providers: number : 2<br />
Provider 0: id: 0x49 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 8 associated providers: 0 name:Intel<br />
Provider 1: id: 0x13c cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 0 name:modesetting<br />
</nowiki>}}<br />
<br />
In the above output, we can see that provider 0 is the system's regular graphics provider (Intel), and provider 1 (modesetting) is the DisplayLink provider. To use the DisplayLink device, connect provider 1 to provider 0:<br />
<br />
# xrandr --setprovideroutputsource 1 0<br />
<br />
and xrandr will add a DVI output you can [[Xrandr#Configuration|use as normal with xrandr]]. This is still experimental but supports hotplugging and when works, it's by far the simplest setup. If it works then everything below is unnecessary.<br />
<br />
==Configuration==<br />
<br />
These instructions assume that you already have an up and running X server and are simply adding a monitor to your existing setup.<br />
<br />
===Load the framebuffer device===<br />
<br />
Before your system will recognize your DisplayLink device, the {{ic|udl}} kernel module must be loaded. To do this, run<br />
<br />
# modprobe udl<br />
<br />
If your DisplayLink device is connected, it should show some visual indication of this. Although a green screen is the standard indicator of this, other variations have been spotted and are perfectly normal. Most importantly, the output of {{ic|dmesg}} should show something like the following, indicating a new DisplayLink device was found:<br />
<br />
{{bc|<nowiki>usb 2-1.1: new high-speed USB device number 7 using ehci-pci<br />
usb 2-1.1: New USB device found, idVendor=17e9, idProduct=03e0<br />
usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br />
usb 2-1.1: Product: Lenovo LT1421 wide<br />
usb 2-1.1: Manufacturer: DisplayLink<br />
usb 2-1.1: SerialNumber: 6V9BBRM1<br />
[drm] vendor descriptor length:17 data:17 5f 01 00 15 05 00 01 03 00 04<br />
udl 2-1.1:1.0: fb1: udldrmfb frame buffer device<br />
[drm] Initialized udl 0.0.1 20120220 on minor 1<br />
</nowiki>}}<br />
<br />
Furthermore, {{ic|/dev}} should contain a new {{ic|fb}} device, likely {{ic|/dev/fb1}} if you already had a framebuffer for your primary display.<br />
<br />
To automatically load {{ic|udl}} at boot, create the file {{ic|udl.conf}} in {{ic|/etc/modules-load.d/}} with the following contents:<br />
<br />
{{hc|/etc/modules-load.d/udl.conf|udl}}<br />
<br />
For more information on loading kernel modules, see [[Kernel modules#Loading]].<br />
<br />
===Configuring X Server===<br />
There are three popular ways people use DisplayLink devices with X on desktop Linux computers:<br />
* With {{ic|xrandr}} (recommended)<br />
* Xinerama with a single X server<br />
* Two separate X servers, linked together in some way<br />
While Xinerama is probably the more desirable setup, it is also less likely to work. Both methods are described below.<br />
<br />
====xrandr====<br />
<br />
Since {{ic|udl}} has become stable, {{ic|udl}} now works with {{ic|xrandr}}. Once the driver is loaded, the DisplayLink monitor is listed as an output provider:<br />
<br />
{{hc|$ xrandr --listproviders|<nowiki><br />
Providers: number : 2<br />
Provider 0: id: 0x43 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 2 associated providers: 1 name:Intel<br />
Provider 1: id: 0xcb cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting<br />
</nowiki>}}<br />
In the above example, provider 1 is the DisplayLink device, and provider 0 is the default display. Running {{ic|xrandr --current}} gives a list of available screens:<br />
<br />
{{hc|$ xrandr --current|<nowiki><br />
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192<br />
LVDS1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm<br />
1600x900 60.0*+ 40.0 <br />
1440x900 59.9 <br />
1360x768 59.8 60.0 <br />
1152x864 60.0 <br />
1024x768 60.0 <br />
800x600 60.3 56.2 <br />
640x480 59.9 <br />
VGA1 disconnected (normal left inverted right x axis y axis)<br />
DVI-1-0 connected (normal left inverted right x axis y axis)<br />
1366x768 60.0 +<br />
1368x768_59.90 59.9 <br />
1368x768_59.90 (0xd0) 85.7MHz<br />
h: width 1368 start 1440 end 1584 total 1800 skew 0 clock 47.6KHz<br />
v: height 768 start 769 end 772 total 795 clock 59.9Hz<br />
</nowiki>}}<br />
<br />
If the above does not list the DisplayLink screen, then you will need to offload DisplayLink to the main GPU:<br />
<br />
{{bc|xrandr --setprovideroutputsource 1 0}}<br />
<br />
Once the screen is available, refer to [[Xrandr]] for info on setting it up. For automating the configuration process, see [https://github.com/nathantypanski/displaylink.sh displaylink.sh].<br />
<br />
====Xinerama setup====<br />
You must update or create an [[xorg.conf]] with a properly configured {{ic|ServerLayout}} to use a DisplayLink monitor, as Xorg will prefer internal monitors by default. The DisplayLink device is normally only usable if it is set as {{ic|screen0}} and the internal display as {{ic|screen1}}.<br />
<br />
Add this to the bottom of your {{ic|xorg.conf}}:<br />
{{hc|/etc/X11/xorg.conf|<br />
################ DisplayLink ###################<br />
Section "Device"<br />
Identifier "DisplayLinkDevice"<br />
Driver "fbdev" <br />
BusID "USB" # needed to use multiple DisplayLink devices <br />
Option "fbdev" "/dev/fb0" # change to whatever device you want to use<br />
# Option "rotate" "CCW" # uncomment for rotation<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "DisplayLinkMonitor"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "DisplayLinkScreen"<br />
Device "DisplayLinkDevice"<br />
Monitor "DisplayLinkMonitor"<br />
DefaultDepth 16<br />
EndSection<br />
}}<br />
<br />
Then edit your server layout to look something like this<br />
<br />
Screen 0 "DisplayLinkScreen"<br />
Screen 1 "Internal" RightOf "DisplayLinkScreen"<br />
Option "Xinerama" "on"<br />
<br />
Change ''Internal'' to your main display, then restart X.<br />
====Dual X setup====<br />
Refer to the steps covered in the [http://wiki.gentoo.org/wiki/DisplayLink#Two_X_server Gentoo Wiki] for details on this setup.<br />
<br />
==Troubleshooting==<br />
<br />
===Screen redraw is broken===<br />
If you are using {{ic|udl}} as your kernel driver and the monitor appears to work, but is only updating where you move the mouse or when windows change in certain places, then you probably have the wrong modeline for your screen. Getting a proper modeline for your screen with a command like<br />
<br />
{{bc|<br />
gtf 1366 768 59.9<br />
}}<br />
<br />
where {{ic|1366}} and {{ic|768}} are the horizontal and vertical resolutions for your monitor, and {{ic|59.9}} is the refresh rate from its specs. To use this, create a new mode with {{ic|xrandr}} like follows:<br />
<br />
{{bc|<br />
xrandr --newmode "1368x768_59.90" 85.72 1368 1440 1584 1800 768 769 772 795 -HSync +Vsync<br />
}}<br />
<br />
and add it to [[Xrandr]]:<br />
<br />
{{bc|<br />
xrandr --addmode DVI-0 1368x768_59.90<br />
}}<br />
<br />
Then tell the monitor to use that mode for the DisplayLink monitor, and this should fix the redraw issues. Check the [[Xrandr]] page for information on using a different mode.<br />
<br />
===X crashes or keeps blank===<br />
<br />
If X crashes, or nothing is shown at load, try to start X only using the external display by updating {{ic|xorg.conf}} as follows:<br />
<br />
{{bc|<br />
Screen 0 "DisplayLinkScreen"<br />
#Screen 1 "Internal" RightOf "DisplayLinkScreen"<br />
#Option "Xinerama" "on"<br />
}}<br />
<br />
There are reported instances in which Xinerama requires all its {{ic|Screen}} color depths to be the same. In both {{ic|Screen}} sections, try changing the {{ic|DefaultDepth}} to 16.<br />
<br />
{{bc|<br />
Section "Screen"<br />
...<br />
DefaultDepth 16<br />
...<br />
EndSection<br />
<br />
}}<br />
<br />
{{Note| With fbdev this is not true anymore, because fbdev provides virtual 24 bit support. Everything may be used with {{ic|DefaultDepth 24}}. However, USB 2.0 has less bandwidth than a standard monitor, so a performance update may be seen from setting it to 16 bit mode.}}<br />
<br />
===Cannot start in framebuffer mode. Please specify busIDs for all framebuffer devices===<br />
<br />
With two monitors configured in Xinerama mode, {{ic|/var/log/Xorg.0.log}} will sometimes display the following error:<br />
<br />
{{bc|<br />
Fatal server error:<br />
Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices<br />
}}<br />
<br />
As indicated by [http://forums.gentoo.org/viewtopic-t-809655.html this Gentoo Forums thread], KMS might be incompatible with fbdev. They also suggested the possible fix of running {{ic|startx -- -retro}} which will allow X to run even when, to X itself, it doesn't appear to be working.<br />
<br />
{{Note |1= A [https://bugs.freedesktop.org/show_bug.cgi?id=65384 bug report] has been filed for this issue.}}<br />
<br />
===DisplayLink refresh rate is extremely slow with gnome 3===<br />
If once you set up your DisplayLink your entire desktop becomes slow, and maximizing a window on the displaylink screen reduces the lag, try adding the screen manually via xrandr:<br />
{{bc|<br />
xrandr -q<br />
xrandr --output [screen_here] --right-of [other_screen] --auto<br />
}}<br />
<br />
==See Also==<br />
<br />
* [http://displaylink.org/forum/forumdisplay.php?f=29 DisplayLink Open Source]: Official DisplayLink open source support forum<br />
* [http://plugable.com/platforms/linux Plugable]: Vendor blog chronicling Linux support for DisplayLink.</div>Ndthttps://wiki.archlinux.org/index.php?title=DisplayLink&diff=350966DisplayLink2014-12-20T03:23:19Z<p>Ndt: /* Load the framebuffer device */ this section describes udl, so say "udl"</p>
<hr />
<div>[[Category:Other hardware]]<br />
DisplayLink devices on Linux still only have experimental support. While some people have had success in using them, it is generally not an easy process and not guaranteed to work. The steps on this page describe the generally most successful methods of using external monitors with DisplayLink.<br />
<br />
==Installation==<br />
<br />
{{Note|1=Modern USB 3.0 DisplayLink adapters are not supported as of October 2014.[http://displaylink.org/forum/showthread.php?t=1748] Older DisplayLink chips (USB 2.0) are supported.}}<br />
<br />
Install the {{Pkg|xf86-video-fbdev}} package, which provides framebuffer video for X.org.<br />
<br />
Hardware-level support is provided by the [[Kernel modules|kernel module]] {{ic|udlfb}}, which should be loadable by default in Arch.<br />
=== udl === <br />
<br />
The kernel [[Wikipedia: Direct_Rendering_Manager |DRM]] driver for DisplayLink is {{ic|udl}}, a rewrite of the original [https://www.kernel.org/doc/Documentation/fb/udlfb.txt udlfb] driver. It allows configuring DisplayLink monitors using [[Xrandr]].<br />
<br />
First, the setup and installation:<br />
<br />
* [[Kernel modules#Blacklisting|Blacklist]] the old kernel module, {{ic|udlfb}}, which may attempt to load itself first.<br />
* [[Pacman|Install]] {{Pkg|xf86-video-modesetting}}, the required [[Xorg]] driver.<br />
<br />
After that, run:<br />
<br />
{{hc|# xrandr --listproviders|<nowiki><br />
Providers: number : 2<br />
Provider 0: id: 0x49 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 8 associated providers: 0 name:Intel<br />
Provider 1: id: 0x13c cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 0 name:modesetting<br />
</nowiki>}}<br />
<br />
In the above output, we can see that provider 0 is the system's regular graphics provider (Intel), and provider 1 (modesetting) is the DisplayLink provider. To use the DisplayLink device, connect provider 1 to provider 0:<br />
<br />
# xrandr --setprovideroutputsource 1 0<br />
<br />
and xrandr will add a DVI output you can [[Xrandr#Configuration|use as normal with xrandr]]. This is still experimental but supports hotplugging and when works, it's by far the simplest setup. If it works then everything below is unnecessary.<br />
<br />
==Configuration==<br />
<br />
These instructions assume that you already have an up and running X server and are simply adding a monitor to your existing setup.<br />
<br />
===Load the framebuffer device===<br />
<br />
Before your system will recognize your DisplayLink device, the {{ic|udl}} kernel module must be loaded. To do this, run<br />
<br />
# modprobe udl<br />
<br />
If your DisplayLink device is connected, it should show some visual indication of this. Although a green screen is the standard indicator of this, other variations have been spotted and are perfectly normal. Most importantly, the output of {{ic|dmesg}} should show something like the following, indicating a new DisplayLink device was found:<br />
<br />
{{bc|<nowiki>usb 2-1.1: new high-speed USB device number 7 using ehci-pci<br />
usb 2-1.1: New USB device found, idVendor=17e9, idProduct=03e0<br />
usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br />
usb 2-1.1: Product: Lenovo LT1421 wide<br />
usb 2-1.1: Manufacturer: DisplayLink<br />
usb 2-1.1: SerialNumber: 6V9BBRM1<br />
[drm] vendor descriptor length:17 data:17 5f 01 00 15 05 00 01 03 00 04<br />
udl 2-1.1:1.0: fb1: udldrmfb frame buffer device<br />
[drm] Initialized udl 0.0.1 20120220 on minor 1<br />
</nowiki>}}<br />
<br />
Furthermore, {{ic|/dev}} should contain a new {{ic|fb}} device, likely {{ic|/dev/fb1}} if you already had a framebuffer for your primary display.<br />
<br />
To automatically load {{ic|udl}} at boot, create the file {{ic|udl.conf}} in {{ic|/etc/modules-load.d/}} with the following contents:<br />
<br />
{{hc|/etc/modules-load.d/udl.conf|udl}}<br />
<br />
For more information on loading kernel modules, see [[Kernel modules#Loading]].<br />
<br />
===Configuring X Server===<br />
There are three popular ways people use DisplayLink devices with X on desktop Linux computers:<br />
* With {{ic|xrandr}} (recommended)<br />
* Xinerama with a single X server<br />
* Two separate X servers, linked together in some way<br />
While Xinerama is probably the more desirable setup, it is also less likely to work. Both methods are described below.<br />
<br />
====xrandr====<br />
<br />
Since {{ic|udl}} has become stable, {{ic|udl}} now works with {{ic|xrandr}}. Once the driver is loaded, the DisplayLink monitor is listed as an output provider:<br />
<br />
{{hc|$ xrandr --listproviders|<nowiki><br />
Providers: number : 2<br />
Provider 0: id: 0x43 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 2 associated providers: 1 name:Intel<br />
Provider 1: id: 0xcb cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting<br />
</nowiki>}}<br />
In the above example, provider 1 is the DisplayLink device, and provider 0 is the default display. Running {{ic|xrandr --current}} gives a list of available screens:<br />
<br />
{{hc|$ xrandr --current|<nowiki><br />
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192<br />
LVDS1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm<br />
1600x900 60.0*+ 40.0 <br />
1440x900 59.9 <br />
1360x768 59.8 60.0 <br />
1152x864 60.0 <br />
1024x768 60.0 <br />
800x600 60.3 56.2 <br />
640x480 59.9 <br />
VGA1 disconnected (normal left inverted right x axis y axis)<br />
DVI-1-0 connected (normal left inverted right x axis y axis)<br />
1366x768 60.0 +<br />
1368x768_59.90 59.9 <br />
1368x768_59.90 (0xd0) 85.7MHz<br />
h: width 1368 start 1440 end 1584 total 1800 skew 0 clock 47.6KHz<br />
v: height 768 start 769 end 772 total 795 clock 59.9Hz<br />
</nowiki>}}<br />
<br />
If the above does not list the DisplayLink screen, then you will need to offload DisplayLink to the main GPU:<br />
<br />
{{bc|xrandr --setprovideroutputsource 1 0}}<br />
<br />
Once the screen is available, refer to [[Xrandr]] for info on setting it up. For automating the configuration process, [[DisplayLink/displaylink.sh]] gives an example script.<br />
<br />
====Xinerama setup====<br />
You must update or create an [[xorg.conf]] with a properly configured {{ic|ServerLayout}} to use a DisplayLink monitor, as Xorg will prefer internal monitors by default. The DisplayLink device is normally only usable if it is set as {{ic|screen0}} and the internal display as {{ic|screen1}}.<br />
<br />
Add this to the bottom of your {{ic|xorg.conf}}:<br />
{{hc|/etc/X11/xorg.conf|<br />
################ DisplayLink ###################<br />
Section "Device"<br />
Identifier "DisplayLinkDevice"<br />
Driver "fbdev" <br />
BusID "USB" # needed to use multiple DisplayLink devices <br />
Option "fbdev" "/dev/fb0" # change to whatever device you want to use<br />
# Option "rotate" "CCW" # uncomment for rotation<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "DisplayLinkMonitor"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "DisplayLinkScreen"<br />
Device "DisplayLinkDevice"<br />
Monitor "DisplayLinkMonitor"<br />
DefaultDepth 16<br />
EndSection<br />
}}<br />
<br />
Then edit your server layout to look something like this<br />
<br />
Screen 0 "DisplayLinkScreen"<br />
Screen 1 "Internal" RightOf "DisplayLinkScreen"<br />
Option "Xinerama" "on"<br />
<br />
Change ''Internal'' to your main display, then restart X.<br />
====Dual X setup====<br />
Refer to the steps covered in the [http://wiki.gentoo.org/wiki/DisplayLink#Two_X_server Gentoo Wiki] for details on this setup.<br />
<br />
==Troubleshooting==<br />
<br />
===Screen redraw is broken===<br />
If you are using {{ic|udl}} as your kernel driver and the monitor appears to work, but is only updating where you move the mouse or when windows change in certain places, then you probably have the wrong modeline for your screen. Getting a proper modeline for your screen with a command like<br />
<br />
{{bc|<br />
gtf 1366 768 59.9<br />
}}<br />
<br />
where {{ic|1366}} and {{ic|768}} are the horizontal and vertical resolutions for your monitor, and {{ic|59.9}} is the refresh rate from its specs. To use this, create a new mode with {{ic|xrandr}} like follows:<br />
<br />
{{bc|<br />
xrandr --newmode "1368x768_59.90" 85.72 1368 1440 1584 1800 768 769 772 795 -HSync +Vsync<br />
}}<br />
<br />
and add it to [[Xrandr]]:<br />
<br />
{{bc|<br />
xrandr --addmode DVI-0 1368x768_59.90<br />
}}<br />
<br />
Then tell the monitor to use that mode for the DisplayLink monitor, and this should fix the redraw issues. Check the [[Xrandr]] page for information on using a different mode.<br />
<br />
===X crashes or keeps blank===<br />
<br />
If X crashes, or nothing is shown at load, try to start X only using the external display by updating {{ic|xorg.conf}} as follows:<br />
<br />
{{bc|<br />
Screen 0 "DisplayLinkScreen"<br />
#Screen 1 "Internal" RightOf "DisplayLinkScreen"<br />
#Option "Xinerama" "on"<br />
}}<br />
<br />
There are reported instances in which Xinerama requires all its {{ic|Screen}} color depths to be the same. In both {{ic|Screen}} sections, try changing the {{ic|DefaultDepth}} to 16.<br />
<br />
{{bc|<br />
Section "Screen"<br />
...<br />
DefaultDepth 16<br />
...<br />
EndSection<br />
<br />
}}<br />
<br />
{{Note| With fbdev this is not true anymore, because fbdev provides virtual 24 bit support. Everything may be used with {{ic|DefaultDepth 24}}. However, USB 2.0 has less bandwidth than a standard monitor, so a performance update may be seen from setting it to 16 bit mode.}}<br />
<br />
===Cannot start in framebuffer mode. Please specify busIDs for all framebuffer devices===<br />
<br />
With two monitors configured in Xinerama mode, {{ic|/var/log/Xorg.0.log}} will sometimes display the following error:<br />
<br />
{{bc|<br />
Fatal server error:<br />
Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices<br />
}}<br />
<br />
As indicated by [http://forums.gentoo.org/viewtopic-t-809655.html this Gentoo Forums thread], KMS might be incompatible with fbdev. They also suggested the possible fix of running {{ic|startx -- -retro}} which will allow X to run even when, to X itself, it doesn't appear to be working.<br />
<br />
{{Note |1= A [https://bugs.freedesktop.org/show_bug.cgi?id=65384 bug report] has been filed for this issue.}}<br />
<br />
===DisplayLink refresh rate is extremely slow with gnome 3===<br />
If once you set up your DisplayLink your entire desktop becomes slow, and maximizing a window on the displaylink screen reduces the lag, try adding the screen manually via xrandr:<br />
{{bc|<br />
xrandr -q<br />
xrandr --output [screen_here] --right-of [other_screen] --auto<br />
}}<br />
<br />
==See Also==<br />
<br />
* [http://displaylink.org/forum/forumdisplay.php?f=29 DisplayLink Open Source]: Official DisplayLink open source support forum<br />
* [http://plugable.com/platforms/linux Plugable]: Vendor blog chronicling Linux support for DisplayLink.</div>Ndthttps://wiki.archlinux.org/index.php?title=DisplayLink&diff=350965DisplayLink2014-12-20T03:20:33Z<p>Ndt: /* udl */ cleanup section for clarity. No longer an ongoing rewrite: udl is the maintained driver</p>
<hr />
<div>[[Category:Other hardware]]<br />
DisplayLink devices on Linux still only have experimental support. While some people have had success in using them, it is generally not an easy process and not guaranteed to work. The steps on this page describe the generally most successful methods of using external monitors with DisplayLink.<br />
<br />
==Installation==<br />
<br />
{{Note|1=Modern USB 3.0 DisplayLink adapters are not supported as of October 2014.[http://displaylink.org/forum/showthread.php?t=1748] Older DisplayLink chips (USB 2.0) are supported.}}<br />
<br />
Install the {{Pkg|xf86-video-fbdev}} package, which provides framebuffer video for X.org.<br />
<br />
Hardware-level support is provided by the [[Kernel modules|kernel module]] {{ic|udlfb}}, which should be loadable by default in Arch.<br />
=== udl === <br />
<br />
The kernel [[Wikipedia: Direct_Rendering_Manager |DRM]] driver for DisplayLink is {{ic|udl}}, a rewrite of the original [https://www.kernel.org/doc/Documentation/fb/udlfb.txt udlfb] driver. It allows configuring DisplayLink monitors using [[Xrandr]].<br />
<br />
First, the setup and installation:<br />
<br />
* [[Kernel modules#Blacklisting|Blacklist]] the old kernel module, {{ic|udlfb}}, which may attempt to load itself first.<br />
* [[Pacman|Install]] {{Pkg|xf86-video-modesetting}}, the required [[Xorg]] driver.<br />
<br />
After that, run:<br />
<br />
{{hc|# xrandr --listproviders|<nowiki><br />
Providers: number : 2<br />
Provider 0: id: 0x49 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 8 associated providers: 0 name:Intel<br />
Provider 1: id: 0x13c cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 0 name:modesetting<br />
</nowiki>}}<br />
<br />
In the above output, we can see that provider 0 is the system's regular graphics provider (Intel), and provider 1 (modesetting) is the DisplayLink provider. To use the DisplayLink device, connect provider 1 to provider 0:<br />
<br />
# xrandr --setprovideroutputsource 1 0<br />
<br />
and xrandr will add a DVI output you can [[Xrandr#Configuration|use as normal with xrandr]]. This is still experimental but supports hotplugging and when works, it's by far the simplest setup. If it works then everything below is unnecessary.<br />
<br />
==Configuration==<br />
<br />
These instructions assume that you already have an up and running X server and are simply adding a monitor to your existing setup.<br />
<br />
===Load the framebuffer device===<br />
<br />
Before your system will recognize your DisplayLink device, the {{ic|udl}} kernel module must be loaded. To do this, run<br />
<br />
# modprobe udl<br />
<br />
If your DisplayLink device is connected, it should show some visual indication of this. Although a green screen is the standard indicator of this, other variations have been spotted and are perfectly normal. Most importantly, the output of {{ic|dmesg}} should show something like the following, indicating a new DisplayLink device was found:<br />
<br />
{{bc|<nowiki>usb 2-1.1: new high-speed USB device number 7 using ehci-pci<br />
usb 2-1.1: New USB device found, idVendor=17e9, idProduct=03e0<br />
usb 2-1.1: New USB device strings: Mfr=1, Product=2, SerialNumber=3<br />
usb 2-1.1: Product: Lenovo LT1421 wide<br />
usb 2-1.1: Manufacturer: DisplayLink<br />
usb 2-1.1: SerialNumber: 6V9BBRM1<br />
[drm] vendor descriptor length:17 data:17 5f 01 00 15 05 00 01 03 00 04<br />
udl 2-1.1:1.0: fb1: udldrmfb frame buffer device<br />
[drm] Initialized udl 0.0.1 20120220 on minor 1<br />
</nowiki>}}<br />
<br />
Furthermore, {{ic|/dev}} should contain a new {{ic|fb}} device, likely {{ic|/dev/fb1}} if you already had a framebuffer for your primary display.<br />
<br />
To automatically load {{ic|udlfb}} at boot, create the file {{ic|udl.conf}} in {{ic|/etc/modules-load.d/}} with the following contents:<br />
<br />
{{hc|/etc/modules-load.d/udl.conf|udl}}<br />
<br />
For more information on loading kernel modules, see [[Kernel modules#Loading]].<br />
<br />
===Configuring X Server===<br />
There are three popular ways people use DisplayLink devices with X on desktop Linux computers:<br />
* With {{ic|xrandr}} (recommended)<br />
* Xinerama with a single X server<br />
* Two separate X servers, linked together in some way<br />
While Xinerama is probably the more desirable setup, it is also less likely to work. Both methods are described below.<br />
<br />
====xrandr====<br />
<br />
Since {{ic|udl}} has become stable, {{ic|udl}} now works with {{ic|xrandr}}. Once the driver is loaded, the DisplayLink monitor is listed as an output provider:<br />
<br />
{{hc|$ xrandr --listproviders|<nowiki><br />
Providers: number : 2<br />
Provider 0: id: 0x43 cap: 0xb, Source Output, Sink Output, Sink Offload crtcs: 2 outputs: 2 associated providers: 1 name:Intel<br />
Provider 1: id: 0xcb cap: 0x2, Sink Output crtcs: 1 outputs: 1 associated providers: 1 name:modesetting<br />
</nowiki>}}<br />
In the above example, provider 1 is the DisplayLink device, and provider 0 is the default display. Running {{ic|xrandr --current}} gives a list of available screens:<br />
<br />
{{hc|$ xrandr --current|<nowiki><br />
Screen 0: minimum 320 x 200, current 1600 x 900, maximum 8192 x 8192<br />
LVDS1 connected 1600x900+0+0 (normal left inverted right x axis y axis) 309mm x 174mm<br />
1600x900 60.0*+ 40.0 <br />
1440x900 59.9 <br />
1360x768 59.8 60.0 <br />
1152x864 60.0 <br />
1024x768 60.0 <br />
800x600 60.3 56.2 <br />
640x480 59.9 <br />
VGA1 disconnected (normal left inverted right x axis y axis)<br />
DVI-1-0 connected (normal left inverted right x axis y axis)<br />
1366x768 60.0 +<br />
1368x768_59.90 59.9 <br />
1368x768_59.90 (0xd0) 85.7MHz<br />
h: width 1368 start 1440 end 1584 total 1800 skew 0 clock 47.6KHz<br />
v: height 768 start 769 end 772 total 795 clock 59.9Hz<br />
</nowiki>}}<br />
<br />
If the above does not list the DisplayLink screen, then you will need to offload DisplayLink to the main GPU:<br />
<br />
{{bc|xrandr --setprovideroutputsource 1 0}}<br />
<br />
Once the screen is available, refer to [[Xrandr]] for info on setting it up. For automating the configuration process, [[DisplayLink/displaylink.sh]] gives an example script.<br />
<br />
====Xinerama setup====<br />
You must update or create an [[xorg.conf]] with a properly configured {{ic|ServerLayout}} to use a DisplayLink monitor, as Xorg will prefer internal monitors by default. The DisplayLink device is normally only usable if it is set as {{ic|screen0}} and the internal display as {{ic|screen1}}.<br />
<br />
Add this to the bottom of your {{ic|xorg.conf}}:<br />
{{hc|/etc/X11/xorg.conf|<br />
################ DisplayLink ###################<br />
Section "Device"<br />
Identifier "DisplayLinkDevice"<br />
Driver "fbdev" <br />
BusID "USB" # needed to use multiple DisplayLink devices <br />
Option "fbdev" "/dev/fb0" # change to whatever device you want to use<br />
# Option "rotate" "CCW" # uncomment for rotation<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "DisplayLinkMonitor"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "DisplayLinkScreen"<br />
Device "DisplayLinkDevice"<br />
Monitor "DisplayLinkMonitor"<br />
DefaultDepth 16<br />
EndSection<br />
}}<br />
<br />
Then edit your server layout to look something like this<br />
<br />
Screen 0 "DisplayLinkScreen"<br />
Screen 1 "Internal" RightOf "DisplayLinkScreen"<br />
Option "Xinerama" "on"<br />
<br />
Change ''Internal'' to your main display, then restart X.<br />
====Dual X setup====<br />
Refer to the steps covered in the [http://wiki.gentoo.org/wiki/DisplayLink#Two_X_server Gentoo Wiki] for details on this setup.<br />
<br />
==Troubleshooting==<br />
<br />
===Screen redraw is broken===<br />
If you are using {{ic|udl}} as your kernel driver and the monitor appears to work, but is only updating where you move the mouse or when windows change in certain places, then you probably have the wrong modeline for your screen. Getting a proper modeline for your screen with a command like<br />
<br />
{{bc|<br />
gtf 1366 768 59.9<br />
}}<br />
<br />
where {{ic|1366}} and {{ic|768}} are the horizontal and vertical resolutions for your monitor, and {{ic|59.9}} is the refresh rate from its specs. To use this, create a new mode with {{ic|xrandr}} like follows:<br />
<br />
{{bc|<br />
xrandr --newmode "1368x768_59.90" 85.72 1368 1440 1584 1800 768 769 772 795 -HSync +Vsync<br />
}}<br />
<br />
and add it to [[Xrandr]]:<br />
<br />
{{bc|<br />
xrandr --addmode DVI-0 1368x768_59.90<br />
}}<br />
<br />
Then tell the monitor to use that mode for the DisplayLink monitor, and this should fix the redraw issues. Check the [[Xrandr]] page for information on using a different mode.<br />
<br />
===X crashes or keeps blank===<br />
<br />
If X crashes, or nothing is shown at load, try to start X only using the external display by updating {{ic|xorg.conf}} as follows:<br />
<br />
{{bc|<br />
Screen 0 "DisplayLinkScreen"<br />
#Screen 1 "Internal" RightOf "DisplayLinkScreen"<br />
#Option "Xinerama" "on"<br />
}}<br />
<br />
There are reported instances in which Xinerama requires all its {{ic|Screen}} color depths to be the same. In both {{ic|Screen}} sections, try changing the {{ic|DefaultDepth}} to 16.<br />
<br />
{{bc|<br />
Section "Screen"<br />
...<br />
DefaultDepth 16<br />
...<br />
EndSection<br />
<br />
}}<br />
<br />
{{Note| With fbdev this is not true anymore, because fbdev provides virtual 24 bit support. Everything may be used with {{ic|DefaultDepth 24}}. However, USB 2.0 has less bandwidth than a standard monitor, so a performance update may be seen from setting it to 16 bit mode.}}<br />
<br />
===Cannot start in framebuffer mode. Please specify busIDs for all framebuffer devices===<br />
<br />
With two monitors configured in Xinerama mode, {{ic|/var/log/Xorg.0.log}} will sometimes display the following error:<br />
<br />
{{bc|<br />
Fatal server error:<br />
Cannot run in framebuffer mode. Please specify busIDs for all framebuffer devices<br />
}}<br />
<br />
As indicated by [http://forums.gentoo.org/viewtopic-t-809655.html this Gentoo Forums thread], KMS might be incompatible with fbdev. They also suggested the possible fix of running {{ic|startx -- -retro}} which will allow X to run even when, to X itself, it doesn't appear to be working.<br />
<br />
{{Note |1= A [https://bugs.freedesktop.org/show_bug.cgi?id=65384 bug report] has been filed for this issue.}}<br />
<br />
===DisplayLink refresh rate is extremely slow with gnome 3===<br />
If once you set up your DisplayLink your entire desktop becomes slow, and maximizing a window on the displaylink screen reduces the lag, try adding the screen manually via xrandr:<br />
{{bc|<br />
xrandr -q<br />
xrandr --output [screen_here] --right-of [other_screen] --auto<br />
}}<br />
<br />
==See Also==<br />
<br />
* [http://displaylink.org/forum/forumdisplay.php?f=29 DisplayLink Open Source]: Official DisplayLink open source support forum<br />
* [http://plugable.com/platforms/linux Plugable]: Vendor blog chronicling Linux support for DisplayLink.</div>Ndthttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=345007Kernel/Traditional compilation2014-11-16T17:52:37Z<p>Ndt: /* First-timers */ code blocks and style tweaks</p>
<hr />
<div>[[Category:Kernel]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:Kernels/Compilation/Traditional]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
<br />
== Fetching source ==<br />
* Fetch the kernel source from http://www.kernel.org. This can be done with GUI or text-based tools that utilize: HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]].<br />
For instance, using wget via http:<br />
$ wget -c https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.16.tar.xz<br />
* It is always a good idea to verify the signature for any downloaded tarball. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature] for how this works and other details. <br />
<br />
* Copy the kernel source to your build directory, e.g.:<br />
$ cp linux-3.16.tar.xz ~/kernelbuild/<br />
<br />
* Unpack it and enter the source directory:<br />
$ cd ~/kernelbuild<br />
$ tar -xvJf linux-3.16.tar.xz<br />
$ cd linux-3.16<br />
Prepare for compilation by running the following command:<br />
make mrproper<br />
This ensures that the kernel tree is absolutely clean. The kernel team recommends that this command be issued prior to each kernel compilation. Do not rely on the source tree being clean after un-tarring.<br />
<br />
=== What about /usr/src/ ? ===<br />
Using {{ic|/usr/src/}} for compilation as root, along with the creation of the corresponding symlink, has been the target of much debate.<br />
<br />
* It is considered poor practice by some users. They consider the cleanest method to simply use your home directory for configuring and compiling. Then installing as root. <br />
<br />
* Other experienced users consider the practice of the entire compiling process as root to be completely safe, acceptable, and even preferable. <br />
<br />
Use whichever method you feel more comfortable with. The following instructions can be interchangeable for either method.<br />
<br />
== Build configuration ==<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently.<br />
<br />
=== Configure your kernel ===<br />
{{Warning| If compiling the ''radeon'' driver into the kernel(>3.3.3) for early KMS with a newer video card, you '''must''' include the firmware files for your card. Otherwise acceleration will be crippled. See [http://wiki.x.org/wiki/radeonBuildHowTo#Missing_Extra_Firmware here]}}<br />
{{Tip| It is possible, to configure a kernel that does not require initramfs on '''''simple configurations'''''. Ensure that all your modules required for video/input/disks/fs are compiled into the kernel. As well as support for DEVTMPFS_MOUNT, TMPFS, AUTOFS4_FS at the very least. If in doubt, learn about these options and what they mean ''before'' attempting.}}<br />
<br />
==== First-timers ====<br />
Two options for beginners to ease use or save time:<br />
* Copy the {{ic|.config}} file from the running kernel, if you want to start with the default Arch settings.<br />
{{bc|$ zcat /proc/config.gz > .config}}<br />
* Use {{ic|localmodconfig}}. Since kernel 2.6.32, this only selects those options which are currently being used.<br />
*# Boot into stock {{ic|-ARCH}} kernel, and plug in all devices that you expect to use on the system.<br />
*# {{ic|cd}} into your source directory and run: {{ic|$ make localmodconfig}}<br />
*# The resulting configuration file will be written to {{ic|.config}}. You can then compile and install as stated below.<br />
<br />
==== Traditional menuconfig ====<br />
<br />
An [[Wikipedia:Ncurses|ncurses]] interface to configuring the kernel is available with<br />
{{bc|$ make menuconfig}}<br />
Alternatively, you can use the more modern<br />
{{bc|$ make nconfig}}<br />
<br />
This will start with a fresh {{ic|.config}}, unless one already exists (e.g. copied over). Option dependencies are automatically selected. And new options (i.e. with an older kernel {{ic|.config}}) may or may not be automatically selected.<br />
<br />
Make your changes to the kernel and save your config file. It is a good idea to make a backup copy outside the source directory, since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compiles. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
==== Versioning ====<br />
If you are compiling a kernel using your current config file, do not forget to rename your kernel version, or you may replace your existing one by mistake.<br />
<br />
$ make menuconfig<br />
General setup ---><br />
(-ARCH) Local version - append to kernel release '3.n.n-RCn'<br />
<br />
== Compilation and installation ==<br />
<br />
=== Compile ===<br />
Compilation time will vary from 15 minutes to over an hour. This is largely based on how many options/modules are selected, as well as processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details.<br />
<br />
{{Warning | If you use GRUB and still have LILO installed; {{ic|make all}} will configure LILO, and may result in an unbootable system.}}<br />
Run {{ic| $ make }}.<br />
<br />
=== Install modules ===<br />
# make modules_install<br />
<br />
This copies the compiled modules into {{ic|/lib/modules/[kernel version + CONFIG_LOCALVERSION]}}. This way, modules can be kept separate from those used by other kernels on your machine.<br />
<br />
=== Make the kernel and copy the kernel to /boot directory ===<br />
# make bzImage<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-YourKernelName<br />
<br />
=== Make initial RAM disk ===<br />
If you do not know what this is, please see: [[wikipedia:Initrd| Initramfs on Wikipedia]] and [[mkinitcpio]].<br />
# mkinitcpio -k FullKernelName -c /etc/mkinitcpio.conf -g /boot/initramfs-YourKernelName.img<br />
<br />
You are free to name the {{ic|/boot}} files anything you want. However, using the [kernel-major-minor-revision] naming scheme helps to keep order if you: <br />
* Keep multiple kernels<br />
* Use mkinitcpio often<br />
* Build third-party modules.<br />
{{Tip| If rebuilding images often, it might be helpful to create a separate preset file resulting in the command being something like:<code># mkinitcpio -p custom</code>. See [[mkinitcpio#Image_creation_and_activation| here]]}}<br />
<br />
If you are using LILO and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
Copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your amazing new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]] or [[Syslinux]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Ndthttps://wiki.archlinux.org/index.php?title=Kernel/Traditional_compilation&diff=345006Kernel/Traditional compilation2014-11-16T17:50:37Z<p>Ndt: /* Traditional menuconfig */ describe more config interface choices</p>
<hr />
<div>[[Category:Kernel]]<br />
[[it:Kernels/Compilation/Traditional]]<br />
[[ja:Kernels/Compilation/Traditional]]<br />
[[ru:Kernels/Compilation/Traditional]]<br />
[[zh-CN:Kernels/Compilation/Traditional]]<br />
This article is an introduction to building custom kernels from '''kernel.org sources'''. This method of compiling kernels is the traditional method common to all distributions. If this seems too complicated, see some alternatives at: [[Kernels#Compilation]]<br />
<br />
== Fetching source ==<br />
* Fetch the kernel source from http://www.kernel.org. This can be done with GUI or text-based tools that utilize: HTTP, [[Ftp#FTP|FTP]], [[Rsync|RSYNC]], or [[Git]].<br />
For instance, using wget via http:<br />
$ wget -c https://www.kernel.org/pub/linux/kernel/v3.x/linux-3.16.tar.xz<br />
* It is always a good idea to verify the signature for any downloaded tarball. See [http://kernel.org/signature.html#using-gnupg-to-verify-kernel-signatures kernel.org/signature] for how this works and other details. <br />
<br />
* Copy the kernel source to your build directory, e.g.:<br />
$ cp linux-3.16.tar.xz ~/kernelbuild/<br />
<br />
* Unpack it and enter the source directory:<br />
$ cd ~/kernelbuild<br />
$ tar -xvJf linux-3.16.tar.xz<br />
$ cd linux-3.16<br />
Prepare for compilation by running the following command:<br />
make mrproper<br />
This ensures that the kernel tree is absolutely clean. The kernel team recommends that this command be issued prior to each kernel compilation. Do not rely on the source tree being clean after un-tarring.<br />
<br />
=== What about /usr/src/ ? ===<br />
Using {{ic|/usr/src/}} for compilation as root, along with the creation of the corresponding symlink, has been the target of much debate.<br />
<br />
* It is considered poor practice by some users. They consider the cleanest method to simply use your home directory for configuring and compiling. Then installing as root. <br />
<br />
* Other experienced users consider the practice of the entire compiling process as root to be completely safe, acceptable, and even preferable. <br />
<br />
Use whichever method you feel more comfortable with. The following instructions can be interchangeable for either method.<br />
<br />
== Build configuration ==<br />
This is the most crucial step in customizing the kernel to reflect your computer's precise specifications. By setting the options in {{ic|.config}} properly, your kernel and computer will function most efficiently.<br />
<br />
=== Configure your kernel ===<br />
{{Warning| If compiling the ''radeon'' driver into the kernel(>3.3.3) for early KMS with a newer video card, you '''must''' include the firmware files for your card. Otherwise acceleration will be crippled. See [http://wiki.x.org/wiki/radeonBuildHowTo#Missing_Extra_Firmware here]}}<br />
{{Tip| It is possible, to configure a kernel that does not require initramfs on '''''simple configurations'''''. Ensure that all your modules required for video/input/disks/fs are compiled into the kernel. As well as support for DEVTMPFS_MOUNT, TMPFS, AUTOFS4_FS at the very least. If in doubt, learn about these options and what they mean ''before'' attempting.}}<br />
<br />
==== First-timers ====<br />
Two options for beginners to ease use or save time:<br />
* Copy the .config file from the running kernel, if you want to modify default Arch settings.<br />
$ zcat /proc/config.gz > .config<br />
* '''localmodconfig''' Since kernel 2.6.32, this should only select those options which are currently being used.<br />
*# Boot into stock {{ic|-ARCH}} kernel, and plug in all devices that you expect to use on the system.<br />
*# {{ic|cd}} into your source directory and run: {{ic|$ make localmodconfig}}<br />
*# The resulting configuration file will be written to {{ic|.config}}. You can then compile and install as stated below.<br />
<br />
==== Traditional menuconfig ====<br />
<br />
An [[Wikipedia:Ncurses|ncurses]] interface to configuring the kernel is available with<br />
{{bc|$ make menuconfig}}<br />
Alternatively, you can use the more modern<br />
{{bc|$ make nconfig}}<br />
<br />
This will start with a fresh {{ic|.config}}, unless one already exists (e.g. copied over). Option dependencies are automatically selected. And new options (i.e. with an older kernel {{ic|.config}}) may or may not be automatically selected.<br />
<br />
Make your changes to the kernel and save your config file. It is a good idea to make a backup copy outside the source directory, since you could be doing this multiple times until you get all the options right. If unsure, only change a few options between compiles. If you cannot boot your newly built kernel, see the list of necessary config items [https://www.archlinux.org/news/users-of-unofficial-kernels-must-enable-devtmpfs-support/ here]. Running {{ic|$ lspci -k #}} from liveCD lists names of kernel modules in use. Most importantly, you must maintain CGROUPS support. This is necessary for [[systemd]].<br />
<br />
==== Versioning ====<br />
If you are compiling a kernel using your current config file, do not forget to rename your kernel version, or you may replace your existing one by mistake.<br />
<br />
$ make menuconfig<br />
General setup ---><br />
(-ARCH) Local version - append to kernel release '3.n.n-RCn'<br />
<br />
== Compilation and installation ==<br />
<br />
=== Compile ===<br />
Compilation time will vary from 15 minutes to over an hour. This is largely based on how many options/modules are selected, as well as processor capability. See [[Makepkg#MAKEFLAGS|Makeflags]] for details.<br />
<br />
{{Warning | If you use GRUB and still have LILO installed; {{ic|make all}} will configure LILO, and may result in an unbootable system.}}<br />
Run {{ic| $ make }}.<br />
<br />
=== Install modules ===<br />
# make modules_install<br />
<br />
This copies the compiled modules into {{ic|/lib/modules/[kernel version + CONFIG_LOCALVERSION]}}. This way, modules can be kept separate from those used by other kernels on your machine.<br />
<br />
=== Make the kernel and copy the kernel to /boot directory ===<br />
# make bzImage<br />
# cp -v arch/x86/boot/bzImage /boot/vmlinuz-YourKernelName<br />
<br />
=== Make initial RAM disk ===<br />
If you do not know what this is, please see: [[wikipedia:Initrd| Initramfs on Wikipedia]] and [[mkinitcpio]].<br />
# mkinitcpio -k FullKernelName -c /etc/mkinitcpio.conf -g /boot/initramfs-YourKernelName.img<br />
<br />
You are free to name the {{ic|/boot}} files anything you want. However, using the [kernel-major-minor-revision] naming scheme helps to keep order if you: <br />
* Keep multiple kernels<br />
* Use mkinitcpio often<br />
* Build third-party modules.<br />
{{Tip| If rebuilding images often, it might be helpful to create a separate preset file resulting in the command being something like:<code># mkinitcpio -p custom</code>. See [[mkinitcpio#Image_creation_and_activation| here]]}}<br />
<br />
If you are using LILO and it cannot communicate with the kernel device-mapper driver, you have to run {{ic|modprobe dm-mod}} first.<br />
<br />
=== Copy System.map ===<br />
The {{ic|System.map}} file is not required for booting Linux. It is a type of "phone directory" list of functions in a particular build of a kernel. The {{ic|System.map}} contains a list of kernel symbols (i.e function names, variable names etc) and their corresponding addresses. This "symbol-name to address mapping" is used by:<br />
<br />
* Some processes like klogd, ksymoops etc<br />
* By OOPS handler when information has to be dumped to the screen during a kernel crash (i.e info like in which function it has crashed).<br />
<br />
Copy System.map to /boot, appending your kernel's name to the destination file. Then create a symlink /boot/System.map to point to /boot/System.map-YourKernelName.<br />
# cp System.map /boot/System.map-YourKernelName<br />
# ln -sf /boot/System.map-YourKernelName /boot/System.map<br />
<br />
After completing all steps above, you should have the following 3 files and 1 soft symlink in your {{ic|/boot}} directory along with any other previously existing files:<br />
* Kernel: vmlinuz-YourKernelName<br />
* Initramfs-YourKernelName.img<br />
* System Map: System.map-YourKernelName<br />
* System Map symlink: System.map<br />
<br />
== Bootloader configuration ==<br />
<br />
Add an entry for your amazing new kernel in your bootloader's configuration file - see [[GRUB]], [[LILO]], [[GRUB2]] or [[Syslinux]] for examples. <br />
<br />
{{Tip| Kernel sources include a script to automate the process for LILO: {{ic|$ arch/x86/boot/install.sh}}. Remember to type {{ic|lilo}} as root at the prompt to update it.}}<br />
<br />
== Using the NVIDIA video driver with your custom kernel ==<br />
To use the NVIDIA driver with your new custom kernel, see: [[NVIDIA#Alternate install: custom kernel|How to install nVIDIA driver with custom kernel]]. You can also install nvidia drivers from AUR.</div>Ndthttps://wiki.archlinux.org/index.php?title=Cgroups&diff=344233Cgroups2014-11-11T06:08:46Z<p>Ndt: /* Installing */ cgmanager.service: no wait don't remain after exit</p>
<hr />
<div>[[Category:Kernel]]<br />
[[Category:Virtualization]]<br />
[[ja:Cgroups]]<br />
{{Related articles start}}<br />
{{Related|Linux Containers}}<br />
{{Related|Arch systemd container}}<br />
{{Related|Docker}}<br />
{{Related articles end}}<br />
<br />
'''cgroups''' (aka '''control groups''') is a Linux kernel feature to limit, police and account the resource usage of certain processes (actually process groups). Compared to other approaches like the 'nice' command or {{ic|/etc/security/limits.conf}}, cgroups are more flexible.<br />
<br />
Control groups can be used in multiple ways:<br />
* create and manage them on the fly using tools like {{ic|cgcreate}}, {{ic|cgexec}}, {{ic|cgclassify}} etc<br />
* the "rules engine daemon", to automatically move certain users/groups/commands to groups ({{ic|/etc/cgrules.conf}} and {{ic|/usr/lib/systemd/system/cgconfig.service}})<br />
* through other software such as [[Linux Containers]] (LXC) virtualization<br />
<br />
== Installing ==<br />
<br />
First, install the utilities for managing cgroups; you need to install the {{AUR|libcgroup}} package from the [[AUR]].<br />
<br />
If you wish to use the client script {{ic|cgm}}, you will need to start the {{ic|cgmanager}} daemon.<br />
<br />
This can be done with a [[Systemd|systemd unit]] like the following:<br />
<br />
{{hc|/usr/lib/systemd/system/cgmanager.service|<nowiki><br />
[Unit]<br />
Description=Control Group manager<br />
<br />
[Service]<br />
Type=simple<br />
ExecStart=/usr/bin/cgmanager<br />
<br />
[Install]<br />
WantedBy=sysinit.target<br />
</nowiki>}}<br />
<br />
== Managing Resource Groups with Systemd ==<br />
<br />
You can [[Systemd#Using_units|enable]] the {{ic|cgconfig}} service with systemd. This gives you the capability to track more easily any errors in {{ic|cgconfig.conf}}.<br />
<br />
== Simple usage ==<br />
<br />
=== Ad-hoc groups ===<br />
<br />
One of the powers of cgroups is that you can create "ad-hoc" groups on the fly. You can even grant the privileges to create custom groups to regular users. {{ic|groupname}} is the cgroup name:<br />
<br />
# cgcreate -a ''user'' -g memory,cpu:''groupname''<br />
<br />
Now all the tunables in the group {{ic|groupname}} are writable by your user:<br />
<br />
$ ls -l /sys/fs/cgroup/memory/''groupname''<br />
total 0<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.event_control<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.procs<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_period_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_runtime_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.shares<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 notify_on_release<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 tasks<br />
<br />
Cgroups are hierarchical, so you can create as many subgroups as you like. If a normal user wants to run a {{ic|bash}} shell under a new subgroup called {{ic|foo}}:<br />
<br />
$ cgcreate -g memory,cpu:'''groupname/foo'''<br />
'''cgexec''' -g memory,cpu:groupname/foo '''bash'''<br />
<br />
To make sure:<br />
<br />
$ cat /proc/self/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
A new subdirectory was created for this group. To limit the memory usage of all processes in this group to 10 MB, run the following:<br />
<br />
$ echo 10000000 > /sys/fs/cgroup/memory/groupname/foo/memory.limit_in_bytes<br />
<br />
Note that the memory limit applies to RAM use only -- once tasks hit this limit, they will begin to swap. But it won't affect the performance of other processes significantly.<br />
<br />
Similarly you can change the CPU priority ("shares") of this group. By default all groups have 1024 shares. A group with 100 shares will get a ~10% portion of the CPU time:<br />
<br />
$ echo 100 > /sys/fs/cgroup/cpu/groupname/foo/cpu.shares<br />
<br />
You can find more tunables or statistics by listing the cgroup directory.<br />
<br />
You can also change the cgroup of already running processes. To move all 'bash' commands to this group:<br />
<br />
$ pidof bash<br />
13244 13266<br />
$ '''cgclassify''' -g memory,cpu:groupname/foo `pidof bash`<br />
$ cat /proc/13244/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
=== Persistent group configuration ===<br />
<br />
{{Note|when using [[Systemd]] > &#61; 205 to manage cgroups, you can ignore this file entirely.<br />
}}<br />
<br />
If you want your cgroups to be created at boot, you can define them in {{ic|/etc/cgconfig.conf}} instead. For example, the "groupname" has a permission for {{ic|$USER}} and ''users'' of group {{ic|$GROUP}} to manage limits and add tasks. A ''subgroup'' "groupname/foo" group definitions would look like this: <br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
group '''groupname''' {<br />
perm {<br />
# who can manage limits<br />
admin {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
# who can add tasks to this group<br />
task {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
}<br />
# create this group in cpu and memory controllers<br />
cpu { }<br />
memory { }<br />
}<br />
<br />
group '''groupname/foo''' {<br />
cpu {<br />
'''cpu.shares''' = 100;<br />
}<br />
memory {<br />
'''memory.limit_in_bytes''' = 10000000;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|<br />
*Comments should begin at the start of a line! The '''#''' character for comments must appear as the first character of a line. Else, ''cgconfigparser'' will have problem parsing it but will only report {{ic|cgroup change of group failed}} as the error, unless you started ''cgconfig'' with [[Systemd]]<br />
*The permissions section is optional.<br />
*The {{ic|/sys/fs/cgroup/}} hierarchy directory containing all ''controllers'' sub-directories is already created and mounted at boot as a virtual file system. This gives the ability to create a new group entry with the {{ic|''$CONTROLLER-NAME { }''}} command. If for any reason you want to create and mount hierachies in another place, you will then need to write a second entry in {{ic|/etc/cgconfig.conf}} following this way :<br />
<br />
mount { <br />
cpuset &#61; /your/path/''groupname'';<br />
}<br />
<br />
This is equivalent to these shell commands:<br />
{{ic| <br />
# mkdir /your/path/''groupname''<br />
# mount -t /your/path -o cpuset ''groupname'' /your/path/''groupname''}}<br />
<br />
}}<br />
<br />
== Useful examples ==<br />
<br />
=== Matlab ===<br />
<br />
Matlab does not have any protection against taking all your machine's memory or CPU. Launching a large calculation can thus trash your system. You could put the following in {{ic|/etc/cgconfig.conf}} to protect from this (where {{ic|$USER}} is your username):<br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
# Prevent Matlab from taking all memory<br />
group matlab {<br />
perm {<br />
admin {<br />
uid = ''$USER'';<br />
}<br />
task {<br />
uid = ''$USER'';<br />
}<br />
}<br />
<br />
cpuset {<br />
cpuset.mems="0";<br />
cpuset.cpus="0-5";<br />
}<br />
memory {<br />
# 5 GiB limit<br />
memory.limit_in_bytes = 5368709120;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|Do not forget to change $USER to the actual username Matlab will be run by.}}<br />
<br />
This cgroup will bind Matlab to cores 0 to 5 (e.g., if you have have 8, Matlab will only see 6) and cap its memory usage to 5 GiB. The "cpu" resource constraint can also be defined to prevent CPU usage, but you may find the "cpuset" constrain to be sufficient.<br />
<br />
Launch matlab like this:<br />
<br />
$ cgexec -g memory,cpuset:matlab /opt/MATLAB/2012b/bin/matlab -desktop<br />
<br />
Make sure to use the right path to the executable.<br />
<br />
== Documentation ==<br />
<br />
* For information on controllers and what certain switches and tunables mean, refer to [https://www.kernel.org/doc/Documentation/cgroups/ kernel's Documentation/cgroup] (or install linux-docs and see {{ic|/usr/src/linux/Documentation/cgroup}}<br />
* A detailed and complete Resource Management Guide can be found in the [http://docs.fedoraproject.org/en-US/Fedora/17/html-single/Resource_Management_Guide/index.html#sec-How_Control_Groups_Are_Organized fedora project documentation].<br />
For commands and configuration files, see relevant man pages, e.g. {{ic|man cgcreate}} or {{ic|man cgrules.conf}}</div>Ndthttps://wiki.archlinux.org/index.php?title=Cgroups&diff=344232Cgroups2014-11-11T06:08:13Z<p>Ndt: /* Installing */ add instructions for starting cgmanager</p>
<hr />
<div>[[Category:Kernel]]<br />
[[Category:Virtualization]]<br />
[[ja:Cgroups]]<br />
{{Related articles start}}<br />
{{Related|Linux Containers}}<br />
{{Related|Arch systemd container}}<br />
{{Related|Docker}}<br />
{{Related articles end}}<br />
<br />
'''cgroups''' (aka '''control groups''') is a Linux kernel feature to limit, police and account the resource usage of certain processes (actually process groups). Compared to other approaches like the 'nice' command or {{ic|/etc/security/limits.conf}}, cgroups are more flexible.<br />
<br />
Control groups can be used in multiple ways:<br />
* create and manage them on the fly using tools like {{ic|cgcreate}}, {{ic|cgexec}}, {{ic|cgclassify}} etc<br />
* the "rules engine daemon", to automatically move certain users/groups/commands to groups ({{ic|/etc/cgrules.conf}} and {{ic|/usr/lib/systemd/system/cgconfig.service}})<br />
* through other software such as [[Linux Containers]] (LXC) virtualization<br />
<br />
== Installing ==<br />
<br />
First, install the utilities for managing cgroups; you need to install the {{AUR|libcgroup}} package from the [[AUR]].<br />
<br />
If you wish to use the client script {{ic|cgm}}, you will need to start the {{ic|cgmanager}} daemon.<br />
<br />
This can be done with a [[Systemd|systemd unit]] like the following:<br />
<br />
{{hc|/usr/lib/systemd/system/cgmanager.service|<nowiki><br />
[Unit]<br />
Description=Control Group manager<br />
<br />
[Service]<br />
Type=simple<br />
RemainAfterExit=yes<br />
ExecStart=/usr/bin/cgmanager<br />
<br />
[Install]<br />
WantedBy=sysinit.target<br />
</nowiki>}}<br />
<br />
== Managing Resource Groups with Systemd ==<br />
<br />
You can [[Systemd#Using_units|enable]] the {{ic|cgconfig}} service with systemd. This gives you the capability to track more easily any errors in {{ic|cgconfig.conf}}.<br />
<br />
== Simple usage ==<br />
<br />
=== Ad-hoc groups ===<br />
<br />
One of the powers of cgroups is that you can create "ad-hoc" groups on the fly. You can even grant the privileges to create custom groups to regular users. {{ic|groupname}} is the cgroup name:<br />
<br />
# cgcreate -a ''user'' -g memory,cpu:''groupname''<br />
<br />
Now all the tunables in the group {{ic|groupname}} are writable by your user:<br />
<br />
$ ls -l /sys/fs/cgroup/memory/''groupname''<br />
total 0<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.event_control<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.procs<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_period_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_runtime_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.shares<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 notify_on_release<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 tasks<br />
<br />
Cgroups are hierarchical, so you can create as many subgroups as you like. If a normal user wants to run a {{ic|bash}} shell under a new subgroup called {{ic|foo}}:<br />
<br />
$ cgcreate -g memory,cpu:'''groupname/foo'''<br />
'''cgexec''' -g memory,cpu:groupname/foo '''bash'''<br />
<br />
To make sure:<br />
<br />
$ cat /proc/self/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
A new subdirectory was created for this group. To limit the memory usage of all processes in this group to 10 MB, run the following:<br />
<br />
$ echo 10000000 > /sys/fs/cgroup/memory/groupname/foo/memory.limit_in_bytes<br />
<br />
Note that the memory limit applies to RAM use only -- once tasks hit this limit, they will begin to swap. But it won't affect the performance of other processes significantly.<br />
<br />
Similarly you can change the CPU priority ("shares") of this group. By default all groups have 1024 shares. A group with 100 shares will get a ~10% portion of the CPU time:<br />
<br />
$ echo 100 > /sys/fs/cgroup/cpu/groupname/foo/cpu.shares<br />
<br />
You can find more tunables or statistics by listing the cgroup directory.<br />
<br />
You can also change the cgroup of already running processes. To move all 'bash' commands to this group:<br />
<br />
$ pidof bash<br />
13244 13266<br />
$ '''cgclassify''' -g memory,cpu:groupname/foo `pidof bash`<br />
$ cat /proc/13244/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
=== Persistent group configuration ===<br />
<br />
{{Note|when using [[Systemd]] > &#61; 205 to manage cgroups, you can ignore this file entirely.<br />
}}<br />
<br />
If you want your cgroups to be created at boot, you can define them in {{ic|/etc/cgconfig.conf}} instead. For example, the "groupname" has a permission for {{ic|$USER}} and ''users'' of group {{ic|$GROUP}} to manage limits and add tasks. A ''subgroup'' "groupname/foo" group definitions would look like this: <br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
group '''groupname''' {<br />
perm {<br />
# who can manage limits<br />
admin {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
# who can add tasks to this group<br />
task {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
}<br />
# create this group in cpu and memory controllers<br />
cpu { }<br />
memory { }<br />
}<br />
<br />
group '''groupname/foo''' {<br />
cpu {<br />
'''cpu.shares''' = 100;<br />
}<br />
memory {<br />
'''memory.limit_in_bytes''' = 10000000;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|<br />
*Comments should begin at the start of a line! The '''#''' character for comments must appear as the first character of a line. Else, ''cgconfigparser'' will have problem parsing it but will only report {{ic|cgroup change of group failed}} as the error, unless you started ''cgconfig'' with [[Systemd]]<br />
*The permissions section is optional.<br />
*The {{ic|/sys/fs/cgroup/}} hierarchy directory containing all ''controllers'' sub-directories is already created and mounted at boot as a virtual file system. This gives the ability to create a new group entry with the {{ic|''$CONTROLLER-NAME { }''}} command. If for any reason you want to create and mount hierachies in another place, you will then need to write a second entry in {{ic|/etc/cgconfig.conf}} following this way :<br />
<br />
mount { <br />
cpuset &#61; /your/path/''groupname'';<br />
}<br />
<br />
This is equivalent to these shell commands:<br />
{{ic| <br />
# mkdir /your/path/''groupname''<br />
# mount -t /your/path -o cpuset ''groupname'' /your/path/''groupname''}}<br />
<br />
}}<br />
<br />
== Useful examples ==<br />
<br />
=== Matlab ===<br />
<br />
Matlab does not have any protection against taking all your machine's memory or CPU. Launching a large calculation can thus trash your system. You could put the following in {{ic|/etc/cgconfig.conf}} to protect from this (where {{ic|$USER}} is your username):<br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
# Prevent Matlab from taking all memory<br />
group matlab {<br />
perm {<br />
admin {<br />
uid = ''$USER'';<br />
}<br />
task {<br />
uid = ''$USER'';<br />
}<br />
}<br />
<br />
cpuset {<br />
cpuset.mems="0";<br />
cpuset.cpus="0-5";<br />
}<br />
memory {<br />
# 5 GiB limit<br />
memory.limit_in_bytes = 5368709120;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|Do not forget to change $USER to the actual username Matlab will be run by.}}<br />
<br />
This cgroup will bind Matlab to cores 0 to 5 (e.g., if you have have 8, Matlab will only see 6) and cap its memory usage to 5 GiB. The "cpu" resource constraint can also be defined to prevent CPU usage, but you may find the "cpuset" constrain to be sufficient.<br />
<br />
Launch matlab like this:<br />
<br />
$ cgexec -g memory,cpuset:matlab /opt/MATLAB/2012b/bin/matlab -desktop<br />
<br />
Make sure to use the right path to the executable.<br />
<br />
== Documentation ==<br />
<br />
* For information on controllers and what certain switches and tunables mean, refer to [https://www.kernel.org/doc/Documentation/cgroups/ kernel's Documentation/cgroup] (or install linux-docs and see {{ic|/usr/src/linux/Documentation/cgroup}}<br />
* A detailed and complete Resource Management Guide can be found in the [http://docs.fedoraproject.org/en-US/Fedora/17/html-single/Resource_Management_Guide/index.html#sec-How_Control_Groups_Are_Organized fedora project documentation].<br />
For commands and configuration files, see relevant man pages, e.g. {{ic|man cgcreate}} or {{ic|man cgrules.conf}}</div>Ndthttps://wiki.archlinux.org/index.php?title=Cgroups&diff=344231Cgroups2014-11-11T05:37:20Z<p>Ndt: /* Matlab */ style tweaks; see Help:Style</p>
<hr />
<div>[[Category:Kernel]]<br />
[[Category:Virtualization]]<br />
[[ja:Cgroups]]<br />
{{Related articles start}}<br />
{{Related|Linux Containers}}<br />
{{Related|Arch systemd container}}<br />
{{Related|Docker}}<br />
{{Related articles end}}<br />
<br />
'''cgroups''' (aka '''control groups''') is a Linux kernel feature to limit, police and account the resource usage of certain processes (actually process groups). Compared to other approaches like the 'nice' command or {{ic|/etc/security/limits.conf}}, cgroups are more flexible.<br />
<br />
Control groups can be used in multiple ways:<br />
* create and manage them on the fly using tools like {{ic|cgcreate}}, {{ic|cgexec}}, {{ic|cgclassify}} etc<br />
* the "rules engine daemon", to automatically move certain users/groups/commands to groups ({{ic|/etc/cgrules.conf}} and {{ic|/usr/lib/systemd/system/cgconfig.service}})<br />
* through other software such as [[Linux Containers]] (LXC) virtualization<br />
<br />
== Installing ==<br />
<br />
First, install the utilities for managing cgroups; you need to install the {{AUR|libcgroup}} package from the [[AUR]].<br />
<br />
== Managing Resource Groups with Systemd ==<br />
<br />
You can [[Systemd#Using_units|enable]] the {{ic|cgconfig}} service with systemd. This gives you the capability to track more easily any errors in {{ic|cgconfig.conf}}.<br />
<br />
== Simple usage ==<br />
<br />
=== Ad-hoc groups ===<br />
<br />
One of the powers of cgroups is that you can create "ad-hoc" groups on the fly. You can even grant the privileges to create custom groups to regular users. {{ic|groupname}} is the cgroup name:<br />
<br />
# cgcreate -a ''user'' -g memory,cpu:''groupname''<br />
<br />
Now all the tunables in the group {{ic|groupname}} are writable by your user:<br />
<br />
$ ls -l /sys/fs/cgroup/memory/''groupname''<br />
total 0<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.event_control<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.procs<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_period_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_runtime_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.shares<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 notify_on_release<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 tasks<br />
<br />
Cgroups are hierarchical, so you can create as many subgroups as you like. If a normal user wants to run a {{ic|bash}} shell under a new subgroup called {{ic|foo}}:<br />
<br />
$ cgcreate -g memory,cpu:'''groupname/foo'''<br />
'''cgexec''' -g memory,cpu:groupname/foo '''bash'''<br />
<br />
To make sure:<br />
<br />
$ cat /proc/self/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
A new subdirectory was created for this group. To limit the memory usage of all processes in this group to 10 MB, run the following:<br />
<br />
$ echo 10000000 > /sys/fs/cgroup/memory/groupname/foo/memory.limit_in_bytes<br />
<br />
Note that the memory limit applies to RAM use only -- once tasks hit this limit, they will begin to swap. But it won't affect the performance of other processes significantly.<br />
<br />
Similarly you can change the CPU priority ("shares") of this group. By default all groups have 1024 shares. A group with 100 shares will get a ~10% portion of the CPU time:<br />
<br />
$ echo 100 > /sys/fs/cgroup/cpu/groupname/foo/cpu.shares<br />
<br />
You can find more tunables or statistics by listing the cgroup directory.<br />
<br />
You can also change the cgroup of already running processes. To move all 'bash' commands to this group:<br />
<br />
$ pidof bash<br />
13244 13266<br />
$ '''cgclassify''' -g memory,cpu:groupname/foo `pidof bash`<br />
$ cat /proc/13244/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
=== Persistent group configuration ===<br />
<br />
{{Note|when using [[Systemd]] > &#61; 205 to manage cgroups, you can ignore this file entirely.<br />
}}<br />
<br />
If you want your cgroups to be created at boot, you can define them in {{ic|/etc/cgconfig.conf}} instead. For example, the "groupname" has a permission for {{ic|$USER}} and ''users'' of group {{ic|$GROUP}} to manage limits and add tasks. A ''subgroup'' "groupname/foo" group definitions would look like this: <br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
group '''groupname''' {<br />
perm {<br />
# who can manage limits<br />
admin {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
# who can add tasks to this group<br />
task {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
}<br />
# create this group in cpu and memory controllers<br />
cpu { }<br />
memory { }<br />
}<br />
<br />
group '''groupname/foo''' {<br />
cpu {<br />
'''cpu.shares''' = 100;<br />
}<br />
memory {<br />
'''memory.limit_in_bytes''' = 10000000;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|<br />
*Comments should begin at the start of a line! The '''#''' character for comments must appear as the first character of a line. Else, ''cgconfigparser'' will have problem parsing it but will only report {{ic|cgroup change of group failed}} as the error, unless you started ''cgconfig'' with [[Systemd]]<br />
*The permissions section is optional.<br />
*The {{ic|/sys/fs/cgroup/}} hierarchy directory containing all ''controllers'' sub-directories is already created and mounted at boot as a virtual file system. This gives the ability to create a new group entry with the {{ic|''$CONTROLLER-NAME { }''}} command. If for any reason you want to create and mount hierachies in another place, you will then need to write a second entry in {{ic|/etc/cgconfig.conf}} following this way :<br />
<br />
mount { <br />
cpuset &#61; /your/path/''groupname'';<br />
}<br />
<br />
This is equivalent to these shell commands:<br />
{{ic| <br />
# mkdir /your/path/''groupname''<br />
# mount -t /your/path -o cpuset ''groupname'' /your/path/''groupname''}}<br />
<br />
}}<br />
<br />
== Useful examples ==<br />
<br />
=== Matlab ===<br />
<br />
Matlab does not have any protection against taking all your machine's memory or CPU. Launching a large calculation can thus trash your system. You could put the following in {{ic|/etc/cgconfig.conf}} to protect from this (where {{ic|$USER}} is your username):<br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
# Prevent Matlab from taking all memory<br />
group matlab {<br />
perm {<br />
admin {<br />
uid = ''$USER'';<br />
}<br />
task {<br />
uid = ''$USER'';<br />
}<br />
}<br />
<br />
cpuset {<br />
cpuset.mems="0";<br />
cpuset.cpus="0-5";<br />
}<br />
memory {<br />
# 5 GiB limit<br />
memory.limit_in_bytes = 5368709120;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|Do not forget to change $USER to the actual username Matlab will be run by.}}<br />
<br />
This cgroup will bind Matlab to cores 0 to 5 (e.g., if you have have 8, Matlab will only see 6) and cap its memory usage to 5 GiB. The "cpu" resource constraint can also be defined to prevent CPU usage, but you may find the "cpuset" constrain to be sufficient.<br />
<br />
Launch matlab like this:<br />
<br />
$ cgexec -g memory,cpuset:matlab /opt/MATLAB/2012b/bin/matlab -desktop<br />
<br />
Make sure to use the right path to the executable.<br />
<br />
== Documentation ==<br />
<br />
* For information on controllers and what certain switches and tunables mean, refer to [https://www.kernel.org/doc/Documentation/cgroups/ kernel's Documentation/cgroup] (or install linux-docs and see {{ic|/usr/src/linux/Documentation/cgroup}}<br />
* A detailed and complete Resource Management Guide can be found in the [http://docs.fedoraproject.org/en-US/Fedora/17/html-single/Resource_Management_Guide/index.html#sec-How_Control_Groups_Are_Organized fedora project documentation].<br />
For commands and configuration files, see relevant man pages, e.g. {{ic|man cgcreate}} or {{ic|man cgrules.conf}}</div>Ndthttps://wiki.archlinux.org/index.php?title=Cgroups&diff=344230Cgroups2014-11-11T05:35:36Z<p>Ndt: /* Persistent group configuration */ fix ic code block tags</p>
<hr />
<div>[[Category:Kernel]]<br />
[[Category:Virtualization]]<br />
[[ja:Cgroups]]<br />
{{Related articles start}}<br />
{{Related|Linux Containers}}<br />
{{Related|Arch systemd container}}<br />
{{Related|Docker}}<br />
{{Related articles end}}<br />
<br />
'''cgroups''' (aka '''control groups''') is a Linux kernel feature to limit, police and account the resource usage of certain processes (actually process groups). Compared to other approaches like the 'nice' command or {{ic|/etc/security/limits.conf}}, cgroups are more flexible.<br />
<br />
Control groups can be used in multiple ways:<br />
* create and manage them on the fly using tools like {{ic|cgcreate}}, {{ic|cgexec}}, {{ic|cgclassify}} etc<br />
* the "rules engine daemon", to automatically move certain users/groups/commands to groups ({{ic|/etc/cgrules.conf}} and {{ic|/usr/lib/systemd/system/cgconfig.service}})<br />
* through other software such as [[Linux Containers]] (LXC) virtualization<br />
<br />
== Installing ==<br />
<br />
First, install the utilities for managing cgroups; you need to install the {{AUR|libcgroup}} package from the [[AUR]].<br />
<br />
== Managing Resource Groups with Systemd ==<br />
<br />
You can [[Systemd#Using_units|enable]] the {{ic|cgconfig}} service with systemd. This gives you the capability to track more easily any errors in {{ic|cgconfig.conf}}.<br />
<br />
== Simple usage ==<br />
<br />
=== Ad-hoc groups ===<br />
<br />
One of the powers of cgroups is that you can create "ad-hoc" groups on the fly. You can even grant the privileges to create custom groups to regular users. {{ic|groupname}} is the cgroup name:<br />
<br />
# cgcreate -a ''user'' -g memory,cpu:''groupname''<br />
<br />
Now all the tunables in the group {{ic|groupname}} are writable by your user:<br />
<br />
$ ls -l /sys/fs/cgroup/memory/''groupname''<br />
total 0<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.event_control<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.procs<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_period_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_runtime_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.shares<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 notify_on_release<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 tasks<br />
<br />
Cgroups are hierarchical, so you can create as many subgroups as you like. If a normal user wants to run a {{ic|bash}} shell under a new subgroup called {{ic|foo}}:<br />
<br />
$ cgcreate -g memory,cpu:'''groupname/foo'''<br />
'''cgexec''' -g memory,cpu:groupname/foo '''bash'''<br />
<br />
To make sure:<br />
<br />
$ cat /proc/self/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
A new subdirectory was created for this group. To limit the memory usage of all processes in this group to 10 MB, run the following:<br />
<br />
$ echo 10000000 > /sys/fs/cgroup/memory/groupname/foo/memory.limit_in_bytes<br />
<br />
Note that the memory limit applies to RAM use only -- once tasks hit this limit, they will begin to swap. But it won't affect the performance of other processes significantly.<br />
<br />
Similarly you can change the CPU priority ("shares") of this group. By default all groups have 1024 shares. A group with 100 shares will get a ~10% portion of the CPU time:<br />
<br />
$ echo 100 > /sys/fs/cgroup/cpu/groupname/foo/cpu.shares<br />
<br />
You can find more tunables or statistics by listing the cgroup directory.<br />
<br />
You can also change the cgroup of already running processes. To move all 'bash' commands to this group:<br />
<br />
$ pidof bash<br />
13244 13266<br />
$ '''cgclassify''' -g memory,cpu:groupname/foo `pidof bash`<br />
$ cat /proc/13244/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
=== Persistent group configuration ===<br />
<br />
{{Note|when using [[Systemd]] > &#61; 205 to manage cgroups, you can ignore this file entirely.<br />
}}<br />
<br />
If you want your cgroups to be created at boot, you can define them in {{ic|/etc/cgconfig.conf}} instead. For example, the "groupname" has a permission for {{ic|$USER}} and ''users'' of group {{ic|$GROUP}} to manage limits and add tasks. A ''subgroup'' "groupname/foo" group definitions would look like this: <br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
group '''groupname''' {<br />
perm {<br />
# who can manage limits<br />
admin {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
# who can add tasks to this group<br />
task {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
}<br />
# create this group in cpu and memory controllers<br />
cpu { }<br />
memory { }<br />
}<br />
<br />
group '''groupname/foo''' {<br />
cpu {<br />
'''cpu.shares''' = 100;<br />
}<br />
memory {<br />
'''memory.limit_in_bytes''' = 10000000;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|<br />
*Comments should begin at the start of a line! The '''#''' character for comments must appear as the first character of a line. Else, ''cgconfigparser'' will have problem parsing it but will only report {{ic|cgroup change of group failed}} as the error, unless you started ''cgconfig'' with [[Systemd]]<br />
*The permissions section is optional.<br />
*The {{ic|/sys/fs/cgroup/}} hierarchy directory containing all ''controllers'' sub-directories is already created and mounted at boot as a virtual file system. This gives the ability to create a new group entry with the {{ic|''$CONTROLLER-NAME { }''}} command. If for any reason you want to create and mount hierachies in another place, you will then need to write a second entry in {{ic|/etc/cgconfig.conf}} following this way :<br />
<br />
mount { <br />
cpuset &#61; /your/path/''groupname'';<br />
}<br />
<br />
This is equivalent to these shell commands:<br />
{{ic| <br />
# mkdir /your/path/''groupname''<br />
# mount -t /your/path -o cpuset ''groupname'' /your/path/''groupname''}}<br />
<br />
}}<br />
<br />
== Useful examples ==<br />
<br />
=== Matlab ===<br />
<br />
Matlab does not have any protection against taking all your machine's memory or CPU. Launching a large calculation can thus trash your system. You could put the following in {{ic|/etc/cgconfig.conf}} to protect from this (where {{ic|$USER}} is your username):<br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
# Prevent Matlab from taking all memory<br />
group matlab {<br />
perm {<br />
admin {<br />
uid = ''$USER'';<br />
}<br />
task {<br />
uid = ''$USER'';<br />
}<br />
}<br />
<br />
cpuset {<br />
cpuset.mems="0";<br />
cpuset.cpus="0-5";<br />
}<br />
memory {<br />
# 5 GiB limit<br />
memory.limit_in_bytes = 5368709120;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|Don't forget to change $USER to the actual username Matlab will be run by.}}<br />
This cgroup will bind Matlab to cores 0 to 5 (I have 8, so Matlab will only see 6) and cap its memory usage to 5 GiB. The "cpu" resource constrain can also be defined to prevent CPU usage, but I find the "cpuset" constrain to be sufficient.<br />
<br />
Launch matlab like this:<br />
<br />
$ cgexec -g memory,cpuset:matlab /opt/MATLAB/2012b/bin/matlab -desktop<br />
<br />
Make sure to use the right path to the executable.<br />
<br />
== Documentation ==<br />
<br />
* For information on controllers and what certain switches and tunables mean, refer to [https://www.kernel.org/doc/Documentation/cgroups/ kernel's Documentation/cgroup] (or install linux-docs and see {{ic|/usr/src/linux/Documentation/cgroup}}<br />
* A detailed and complete Resource Management Guide can be found in the [http://docs.fedoraproject.org/en-US/Fedora/17/html-single/Resource_Management_Guide/index.html#sec-How_Control_Groups_Are_Organized fedora project documentation].<br />
For commands and configuration files, see relevant man pages, e.g. {{ic|man cgcreate}} or {{ic|man cgrules.conf}}</div>Ndthttps://wiki.archlinux.org/index.php?title=Cgroups&diff=344229Cgroups2014-11-11T05:34:51Z<p>Ndt: style improvements; see Help:Style</p>
<hr />
<div>[[Category:Kernel]]<br />
[[Category:Virtualization]]<br />
[[ja:Cgroups]]<br />
{{Related articles start}}<br />
{{Related|Linux Containers}}<br />
{{Related|Arch systemd container}}<br />
{{Related|Docker}}<br />
{{Related articles end}}<br />
<br />
'''cgroups''' (aka '''control groups''') is a Linux kernel feature to limit, police and account the resource usage of certain processes (actually process groups). Compared to other approaches like the 'nice' command or {{ic|/etc/security/limits.conf}}, cgroups are more flexible.<br />
<br />
Control groups can be used in multiple ways:<br />
* create and manage them on the fly using tools like {{ic|cgcreate}}, {{ic|cgexec}}, {{ic|cgclassify}} etc<br />
* the "rules engine daemon", to automatically move certain users/groups/commands to groups ({{ic|/etc/cgrules.conf}} and {{ic|/usr/lib/systemd/system/cgconfig.service}})<br />
* through other software such as [[Linux Containers]] (LXC) virtualization<br />
<br />
== Installing ==<br />
<br />
First, install the utilities for managing cgroups; you need to install the {{AUR|libcgroup}} package from the [[AUR]].<br />
<br />
== Managing Resource Groups with Systemd ==<br />
<br />
You can [[Systemd#Using_units|enable]] the {{ic|cgconfig}} service with systemd. This gives you the capability to track more easily any errors in {{ic|cgconfig.conf}}.<br />
<br />
== Simple usage ==<br />
<br />
=== Ad-hoc groups ===<br />
<br />
One of the powers of cgroups is that you can create "ad-hoc" groups on the fly. You can even grant the privileges to create custom groups to regular users. {{ic|groupname}} is the cgroup name:<br />
<br />
# cgcreate -a ''user'' -g memory,cpu:''groupname''<br />
<br />
Now all the tunables in the group {{ic|groupname}} are writable by your user:<br />
<br />
$ ls -l /sys/fs/cgroup/memory/''groupname''<br />
total 0<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.event_control<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.procs<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_period_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_runtime_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.shares<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 notify_on_release<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 tasks<br />
<br />
Cgroups are hierarchical, so you can create as many subgroups as you like. If a normal user wants to run a {{ic|bash}} shell under a new subgroup called {{ic|foo}}:<br />
<br />
$ cgcreate -g memory,cpu:'''groupname/foo'''<br />
'''cgexec''' -g memory,cpu:groupname/foo '''bash'''<br />
<br />
To make sure:<br />
<br />
$ cat /proc/self/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
A new subdirectory was created for this group. To limit the memory usage of all processes in this group to 10 MB, run the following:<br />
<br />
$ echo 10000000 > /sys/fs/cgroup/memory/groupname/foo/memory.limit_in_bytes<br />
<br />
Note that the memory limit applies to RAM use only -- once tasks hit this limit, they will begin to swap. But it won't affect the performance of other processes significantly.<br />
<br />
Similarly you can change the CPU priority ("shares") of this group. By default all groups have 1024 shares. A group with 100 shares will get a ~10% portion of the CPU time:<br />
<br />
$ echo 100 > /sys/fs/cgroup/cpu/groupname/foo/cpu.shares<br />
<br />
You can find more tunables or statistics by listing the cgroup directory.<br />
<br />
You can also change the cgroup of already running processes. To move all 'bash' commands to this group:<br />
<br />
$ pidof bash<br />
13244 13266<br />
$ '''cgclassify''' -g memory,cpu:groupname/foo `pidof bash`<br />
$ cat /proc/13244/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
=== Persistent group configuration ===<br />
<br />
{{Note|when using [[Systemd]] > &#61; 205 to manage cgroups, you can ignore this file entirely.<br />
}}<br />
<br />
If you want your cgroups to be created at boot, you can define them in {{ic|/etc/cgconfig.conf}} instead. For example, the "groupname" has a permission for {{IC|$USER}} and ''users'' of group {{IC|$GROUP}} to manage limits and add tasks. A ''subgroup'' "groupname/foo" group definitions would look like this: <br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
group '''groupname''' {<br />
perm {<br />
# who can manage limits<br />
admin {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
# who can add tasks to this group<br />
task {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
}<br />
# create this group in cpu and memory controllers<br />
cpu { }<br />
memory { }<br />
}<br />
<br />
group '''groupname/foo''' {<br />
cpu {<br />
'''cpu.shares''' = 100;<br />
}<br />
memory {<br />
'''memory.limit_in_bytes''' = 10000000;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|<br />
*Comments should begin at the start of a line! The '''#''' character for comments must appear as the first character of a line. Else, ''cgconfigparser'' will have problem parsing it but will only report {{ic|cgroup change of group failed}} as the error, unless you started ''cgconfig'' with [[Systemd]]<br />
*The permissions section is optional.<br />
*The {{ic|/sys/fs/cgroup/}} hierarchy directory containing all ''controllers'' sub-directories is already created and mounted at boot as a virtual file system. This gives the ability to create a new group entry with the {{ic|''$CONTROLLER-NAME { }''}} command. If for any reason you want to create and mount hierachies in another place, you will then need to write a second entry in {{ic|/etc/cgconfig.conf}} following this way :<br />
<br />
mount { <br />
cpuset &#61; /your/path/''groupname'';<br />
}<br />
<br />
This is equivalent to these shell commands:<br />
{{ic| <br />
# mkdir /your/path/''groupname''<br />
# mount -t /your/path -o cpuset ''groupname'' /your/path/''groupname''}}<br />
<br />
}}<br />
<br />
== Useful examples ==<br />
<br />
=== Matlab ===<br />
<br />
Matlab does not have any protection against taking all your machine's memory or CPU. Launching a large calculation can thus trash your system. You could put the following in {{ic|/etc/cgconfig.conf}} to protect from this (where {{ic|$USER}} is your username):<br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
# Prevent Matlab from taking all memory<br />
group matlab {<br />
perm {<br />
admin {<br />
uid = ''$USER'';<br />
}<br />
task {<br />
uid = ''$USER'';<br />
}<br />
}<br />
<br />
cpuset {<br />
cpuset.mems="0";<br />
cpuset.cpus="0-5";<br />
}<br />
memory {<br />
# 5 GiB limit<br />
memory.limit_in_bytes = 5368709120;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|Don't forget to change $USER to the actual username Matlab will be run by.}}<br />
This cgroup will bind Matlab to cores 0 to 5 (I have 8, so Matlab will only see 6) and cap its memory usage to 5 GiB. The "cpu" resource constrain can also be defined to prevent CPU usage, but I find the "cpuset" constrain to be sufficient.<br />
<br />
Launch matlab like this:<br />
<br />
$ cgexec -g memory,cpuset:matlab /opt/MATLAB/2012b/bin/matlab -desktop<br />
<br />
Make sure to use the right path to the executable.<br />
<br />
== Documentation ==<br />
<br />
* For information on controllers and what certain switches and tunables mean, refer to [https://www.kernel.org/doc/Documentation/cgroups/ kernel's Documentation/cgroup] (or install linux-docs and see {{ic|/usr/src/linux/Documentation/cgroup}}<br />
* A detailed and complete Resource Management Guide can be found in the [http://docs.fedoraproject.org/en-US/Fedora/17/html-single/Resource_Management_Guide/index.html#sec-How_Control_Groups_Are_Organized fedora project documentation].<br />
For commands and configuration files, see relevant man pages, e.g. {{ic|man cgcreate}} or {{ic|man cgrules.conf}}</div>Ndthttps://wiki.archlinux.org/index.php?title=Linux_Containers&diff=344228Linux Containers2014-11-11T05:22:09Z<p>Ndt: make 'Cgroups' a related article</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:Virtualization]]<br />
[[pt:Linux Containers]]<br />
{{Stub|Some parts of this are dated and are being rewritten to offer up-to-date information regarding LXC setup on Arch Linux}}<br />
{{Poor writing|Several [[Help:Style]] issues.}}<br />
<br />
{{Related articles start}}<br />
{{Related|Cgroups}}<br />
{{Related|Arch systemd container}}<br />
{{Related|Docker}}<br />
{{Related|Lxc-systemd}}<br />
{{Related articles end}}<br />
<br />
'''LinuX Containers''' ('''LXC''') is an operating system-level virtualization method for running multiple isolated Linux systems (containers) on a single control host (LXC host). <br />
<br />
LXC does not provide a virtual machine, but rather provides a virtual environment that has its own CPU, memory, block I/O, network etc. space. This is provided by [[cgroups]] features in Linux kernel on LXC host. It is similar to a chroot, but offers much more isolation.<br />
<br />
This document is intended as an overview on setting up and deploying containers. A certain amount of prerequisite knowledge and skills is required (networking setup, running commands as root, installing packages from [[AUR]], kernel configuration, mounting filesystems etc.).<br />
<br />
== Setup ==<br />
<br />
Virtualization features for LXC Containers are provided by Linux Kernel and LXC Userspace tools. This section will cover basic information on how to setup LXC capable system.<br />
<br />
=== Packages ===<br />
<br />
The {{Pkg|lxc}} package is available in the [[official repositories]]. It provides LXC Userspace tools which are used to manage LXC containers on LXC Host. Install the {{Pkg|lxc}} package from [[official repositories]].<br />
<br />
It is also highly recommended to install {{Pkg|bridge-utils}} and [[netctl]] which will be useful when configuring different network virtualization types. See also [[Bridge with netctl]].<br />
<br />
You can also optionally install [[OpenVPN]], see also [[OpenVPN Bridge]].<br />
<br />
LXC depends on the control group filesystem being mounted. The standard location for it is {{ic|/sys/fs/cgroup}}. The cgroup filesystem is mounted automatically by systemd.<br />
<br />
Depending on which Linux OS you want to install on your container, you might need to install additional packages which are used in container templates. If you plan to create Arch Linux containers, installing {{Pkg|arch-install-scripts}} from the [[official repositories]] is enough.<br />
<br />
To install other OS containers, you need these OS specific packages:<br />
* Debian: {{AUR|debootstrap}} package from [[AUR]].<br />
* CentOS: {{AUR|yum}} package from [[AUR]].<br />
<br />
=== Testing Setup ===<br />
<br />
Once the {{Pkg|lxc}} package is installed, running {{ic|lxc-checkconfig}} will print out a list of your system's capabilities. For correctly configured system the output should be similar to:<br />
<br />
{{bc|$ lxc-checkconfig<br />
--- Namespaces ---<br />
Namespaces: enabled<br />
Utsname namespace: enabled<br />
Ipc namespace: enabled<br />
Pid namespace: enabled<br />
User namespace: missing<br />
Network namespace: enabled<br />
Multiple /dev/pts instances: enabled<br />
<br />
--- Control groups ---<br />
Cgroup: enabled<br />
Cgroup clone_children flag: enabled<br />
Cgroup device: enabled<br />
Cgroup sched: enabled<br />
Cgroup cpu account: enabled<br />
Cgroup memory controller: enabled<br />
Cgroup cpuset: enabled<br />
<br />
--- Misc ---<br />
Veth pair device: enabled<br />
Macvlan: enabled<br />
Vlan: enabled<br />
File capabilities: enabled}}<br />
<br />
If, however {{ic|lxc-checkconfig}} command is showing missing components, that would usually mean that your kernel is not properly configured for full LXC support. {{Pkg|linux}} kernel package from [[official repositories]] has LXC support. You can check kernel's LXC configuration before actually booting the kernel by setting {{ic|CONFIG}} environment variable to your kernel's config:<br />
<br />
{{bc|1=$ CONFIG=/path/to/kernel/config /usr/bin/lxc-checkconfig}}<br />
<br />
== Container setup ==<br />
<br />
This section will provide information on how to install various containers. You can find all available templates that come with LXC in {{ic|/usr/share/lxc/templates}} directory:<br />
<br />
{{hc|$ ls /usr/share/lxc/templates|<br />
lxc-alpine lxc-altlinux lxc-archlinux lxc-busybox lxc-centos lxc-cirros lxc-debian lxc-download lxc-fedora lxc-gentoo lxc-openmandriva lxc-opensuse lxc-oracle lxc-plamo lxc-sshd lxc-ubuntu lxc-ubuntu-cloud}}<br />
<br />
These template files are bash scripts which build LXC container. Before creating LXC container using specific template, you need to make sure that you have all the packages installed which are required to build the container. You can find required packages for popular containers below:<br />
<br />
* '''Arch Linux''' - {{Pkg|arch-install-scripts}}<br />
* '''Debian''' - {{AUR|debootstrap}}<br />
* '''Centos''' - {{AUR|yum}}<br />
* ...<br />
<br />
=== Create Container ===<br />
<br />
To create containers we will use {{ic|lxc-create}} command and specify the template. Templates can also be provided special arguments which usually allow you to install specific release. Examples:<br />
<br />
{{bc|$ lxc-create -n CONTAINER_NAME -t TEMPLATE<br />
$ lxc-create -n CONTAINER_NAME -t TEMPLATE -- -r RELEASE}}<br />
<br />
Containers are stored in {{ic|/var/lib/lxc/CONTAINER_NAME}} directory. The main configuration file is {{ic|/var/lib/lxc/CONTAINER_NAME/config}} and root filesystem under {{ic|/var/lib/lxc/CONTAINER_NAME/rootfs}}<br />
<br />
See the section [[#Containers|Containers]] below for information on setting up OS-specific LXC containers.<br />
<br />
If you are using [[Btrfs]] you can append {{ic|-B btrfs}} to {{ic|lxc-create}} command if you want LXC to make a Btrfs subvolume for storing LXC Containers rootfs. This comes in handy when you want to clone containers with the help of {{ic|lxc-clone}} command. It will make cloning and cloning from snapshots use '''Btrfs''' features:<br />
<br />
{{bc|$ lxc-create -n CONTAINER_NAME -t TEMPLATE -B btrfs}}<br />
<br />
Also it is worth noting that during creation of some of the containers the setup generates private/GPG keys for OS package managers etc., so it is important that your random devices are properly seeded with random data. Otherwise, this can sometimes hang setup process while it is waiting for random data to be seeded. For this, you can install {{Pkg|haveged}} package and run {{ic|haveged}} command to seed {{ic|/dev/random}} before issuing {{ic|lxc-create}} command.<br />
<br />
=== List Containers ===<br />
<br />
You can list all installed LXC containers with the help of {{ic|lxc-ls}} command:<br />
<br />
{{bc|$ lxc-ls}}<br />
<br />
You can also provide {{ic|-f}} argument to get more detailed output:<br />
<br />
{{bc|$ lxc-ls -f}}<br />
<br />
=== Start Container ===<br />
<br />
After container is created you can start it via {{ic|lxc-start}} command:<br />
<br />
{{bc|$ lxc-start -n CONTAINER_NAME}}<br />
<br />
This will output all the boot messages in current terminal and ask you to login. You can login and use the container. Once you are done, you will have to issue '''halt''' command to shut it down.<br />
<br />
Most of the time, you will want to start LXC container in the background and then use `lxc-attach` command to login to the container. To start LXC container in the background:<br />
<br />
{{bc|$ lxc-start -n CONTAINER_NAME -d}}<br />
<br />
=== Attach to the Container ===<br />
<br />
To attach to the running LXC container in the background:<br />
<br />
{{bc|$ lxc-attach -n CONTAINER_NAME}}<br />
<br />
=== Stop Container ===<br />
<br />
To stop LXC container:<br />
<br />
{{bc|$lxc-stop -n CONTAINER_NAME}}<br />
<br />
=== Starting containers on Boot ===<br />
<br />
You can make LXC containers start on boot by activating container specific systemd service:<br />
<br />
systemctl enable lxc@CONTAINER_NAME.service<br />
<br />
=== Network Configuration ===<br />
<br />
This section provides information on required network configuration on LXC host before you create LXC containers.<br />
<br />
LXC containers support different virtual network types (see [[#Virtual Network Types]] below). For most virtual networking types to work you will need to configure a bridge device on your host. LXC expects '''br0''' interface available during creation of some containers, it will also be used in the examples below with '''veth''' networking. Here are two ways to setup a Bridge in Arch, with [[brctl]] and with [[Netctl]].<br />
<br />
===== brctl =====<br />
Make sure you have the {{Pkg|bridge-utils}} package installed:<br />
<br />
$ pacman -S bridge-utils<br />
<br />
Create the '''br0''' interface:<br />
$ brctl addbr br0<br />
$ ifconfig br0 10.0.0.1/24<br />
$ ifconfig br0<br />
<br />
Then change the networking section of the container's config file to look like this, you can pick an ip different than '''10.0.0.100''' if you wish, make sure you do for running more than one machine simultaneously:<br />
#networking<br />
lxc.network.type=veth<br />
lxc.network.link=br0<br />
lxc.network.ipv4=10.0.0.100<br />
lxc.network.ipv4.gateway=10.0.0.1<br />
lxc.network.flags=up<br />
lxc.network.name=eth0<br />
lxc.network.mtu=1500<br />
<br />
Start the container and make sure you can ping the host computer:<br />
$ ping 10.0.0.1<br />
PING 10.0.0.1 (10.0.0.1) 56(84) bytes of data.<br />
64 bytes from 10.0.0.1: icmp_seq=1 ttl=64 time=0.165 ms<br />
...<br />
<br />
Stop the container. To share internet with the host you need to allow iptables to route your requests outside the bridge.<br />
# make sure you RUN THIS FROM THE HOST NOT INSIDE THE CONTAINER<br />
$ iptables -t nat -A POSTROUTING -s 10.0.0.100 -o eth0 -j MASQUERADE<br />
$ sysctl net.ipv4.ip_forward=1<br />
<br />
Here we assume that your internet adapter is named eth0, it also works with wifi adapters. Run {{ic|$ ip addr}} to see which adapters are available to you.<br />
Start the container and ping some external site:<br />
$ ping www.archlinux.org<br />
PING gudrun.archlinux.org (66.211.214.131) 56(84) bytes of data.<br />
64 bytes from gudrun.archlinux.org (66.211.214.131): icmp_seq=1 ttl=48 time=115 ms<br />
...<br />
<br />
You now have a shared internet connection inside the container.<br />
<br />
===== Netctl =====<br />
Make sure you have {{Pkg|netctl}} package installed:<br />
<br />
$ pacman -Sy netctl<br />
<br />
====== Bridge (Simple) ======<br />
<br />
You can setup an empty bridge if you do NOT need internet access in your LXC containers:<br />
<br />
{{hc|1=/etc/netctl/lxcbridge|2=<br />
Description="LXC Bridge"<br />
Interface=br0<br />
Connection=bridge<br />
BindsToInterfaces=()<br />
IP=static<br />
Address=10.0.2.1/24<br />
SkipForwardingDelay=yes}}<br />
<br />
Enable lxcbridge and start it:<br />
<br />
{{bc|$ netctl enable lxcbridge<br />
$ netctl start lxcbridge}}<br />
<br />
'''Note''': if you ever need to change configuration of netctl profile you need to '''reenable''' it by running {{ic|netctl reenable lxcbridge}} for automatic service to pick up the changes. After re-enabling it run {{ic|netctl restart lxcbridge}}. For more info consult [[Netctl]] page.<br />
<br />
===== Bridge (Internet-shared) =====<br />
<br />
If you need internet connection on your LXC containers or want them to be able to access the network LXC host is on from LXC containers - you can add network interfaces to lxcbridge. In the examples below we add and configure '''enp3s0''' network interface to LXC bridge which has internet access:<br />
<br />
====== Static IP ======<br />
<br />
This example will bridge network interface '''eth0''' and configure a static IP for the bridge:<br />
<br />
{{hc|1=/etc/netctl/lxcbridge|2=<br />
Description="LXC Bridge"<br />
Interface=br0<br />
Connection=bridge<br />
BindsToInterfaces=(eth0)<br />
IP=static<br />
Address=10.0.2.1/24<br />
SkipForwardingDelay=yes}}<br />
<br />
After changes are made, make sure to re-enable and restart the bridge:<br />
<br />
{{bc|$ netctl reenable lxcbridge<br />
$ netctl restart lxcbridge}}<br />
<br />
====== DHCP ======<br />
<br />
This example will bridge network interface '''eth0''' and configure an IP via DHCP:<br />
<br />
{{hc|1=/etc/netctl/lxcbridge|2=<br />
Description="LXC Bridge"<br />
Interface=br0<br />
Connection=bridge<br />
BindsToInterfaces=(eth0)<br />
IP=dhcp<br />
SkipForwardingDelay=yes}}<br />
<br />
After changes are made, make sure to re-enable and restart the bridge:<br />
<br />
{{bc|$ netctl reenable lxcbridge<br />
$ netctl restart lxcbridge}}<br />
<br />
===== IP Forwarding =====<br />
<br />
You will also have to enable IP Forwarding on LXC Host:<br />
<br />
{{bc|1=$ sysctl net.ipv4.ip_forward=1<br />
net.ipv6.conf.default.forwarding=1<br />
net.ipv6.conf.all.forwarding=1}}<br />
<br />
To make changes persist upon reboot:<br />
<br />
{{hc|1=/etc/sysctl.d/40-ip-forward.conf|2=<br />
net.ipv4.ip_forward=1}}<br />
<br />
And also apply this [[iptables]] rule (make sure you have {{Pkg|iptables}} package installed):<br />
<br />
{{bc|$ iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE}}<br />
<br />
To make changes persist upon reboot:<br />
<br />
{{bc|1=$ iptables-save > /etc/iptables/iptables.rules<br />
$ systemctl enable iptables<br />
$ systemctl start iptables}}<br />
<br />
== Containers ==<br />
<br />
This section will provide information on how to setup OS-specific LXC containers on Arch Linux host. This will only include information on how to create and configure the container. For information on starting containers, read the sections above.<br />
<br />
=== Arch Linux Container ===<br />
<br />
To create Arch Linux container execute this command:<br />
<br />
{{bc|$ lxc-create -n arch -t archlinux}}<br />
<br />
If you get an error {{ic|/usr/share/lxc/templates/lxc-archlinux: line 183: pacstrap: command not found}} when trying to install the {{ic|lxc-archlinux}} container, make sure to install the package {{ic|extra/arch-install-scripts}} and try again.<br />
<br />
If you have [[Btrfs]] filesystem and you want LXC to create a separate subvolume for containers rootfs, append {{ic|-B btrfs}} like this:<br />
<br />
{{bc|$lxc-create -n arch -t archlinux -B btrfs}}<br />
<br />
Configuration for container should be similar to this:<br />
<br />
{{hc|1=/var/lib/lxc/arch/config|2=<br />
# Template used to create this container: /usr/share/lxc/templates/lxc-archlinux<br />
# Parameters passed to the template:<br />
# For additional config options, please look at lxc.conf(5)<br />
lxc.utsname=arch<br />
lxc.autodev=1<br />
lxc.tty=1<br />
lxc.pts=1024<br />
lxc.mount=/var/lib/lxc/arch/fstab<br />
lxc.cap.drop=sys_module mac_admin mac_override sys_time<br />
lxc.kmsg=0<br />
lxc.stopsignal=SIGRTMIN+4<br />
#networking<br />
lxc.network.type=veth<br />
lxc.network.link=br0<br />
lxc.network.flags=up<br />
lxc.network.name=eth0<br />
lxc.network.ipv4=10.0.2.2/24<br />
lxc.network.ipv4.gateway=10.0.2.1<br />
lxc.network.mtu=1500<br />
#cgroups<br />
lxc.cgroup.devices.deny = a<br />
lxc.cgroup.devices.allow = c *:* m<br />
lxc.cgroup.devices.allow = b *:* m<br />
lxc.cgroup.devices.allow = c 1:3 rwm<br />
lxc.cgroup.devices.allow = c 1:5 rwm<br />
lxc.cgroup.devices.allow = c 1:7 rwm<br />
lxc.cgroup.devices.allow = c 1:8 rwm<br />
lxc.cgroup.devices.allow = c 1:9 rwm<br />
lxc.cgroup.devices.allow = c 4:1 rwm<br />
lxc.cgroup.devices.allow = c 5:0 rwm<br />
lxc.cgroup.devices.allow = c 5:1 rwm<br />
lxc.cgroup.devices.allow = c 5:2 rwm<br />
lxc.cgroup.devices.allow = c 136:* rwm<br />
lxc.rootfs = /var/lib/lxc/arch/rootfs}}<br />
<br />
Make sure that '''networking''' part is setup correctly to use previously setup bridge. IP and Gateway configuration is also important if you want networking to work properly on LXC container. You should be able to [[#Start Container]] now without needing further configuration.<br />
<br />
{{Stub|Parts of the article below are mostly outdated and are pending rewrite.}}<br />
<br />
== Container configuration ==<br />
<br />
=== Configuration file ===<br />
<br />
The main configuration files are used to describe how to originally create a container. Though these files may be located anywhere, /etc/lxc is probably a good place.<br />
<br />
'''23/Aug/2010: Be aware that the kernel may not handle additional whitespace in the configuration file. This has been experienced on "lxc.cgroup.devices.allow" settings but may also be true on other settings. If in doubt use only one space wherever whitespace is required.'''<br />
<br />
==== Basic settings ====<br />
<br />
lxc.utsname = $CONTAINER_NAME<br><br />
lxc.mount = $CONTAINER_FSTAB<br />
lxc.rootfs = $CONTAINER_ROOTFS<br><br />
lxc.network.type = veth<br />
lxc.network.flags = up<br />
lxc.network.link = br0<br />
lxc.network.hwaddr = $CONTAINER_MACADDR <br />
lxc.network.ipv4 = $CONTAINER_IPADDR<br />
lxc.network.name = $CONTAINER_DEVICENAME<br />
<br />
===== Basic settings explained =====<br />
<br />
'''lxc.utsname''' : This will be the name of the cgroup for the container. Once the container is started, you should be able to see a new folder named ''/cgroup/$CONTAINER_NAME''.<br />
<br />
Furthermore, this will also be the value returned by ''hostname'' from within the container. Assuming you have not removed access, the container may overwrite this with its init script.<br />
<br />
'''lxc.mount''' : This points to an fstab formatted file that is a listing of the mount points used when ''lxc-start'' is called. This file is further explained [[#Configuring fstab|further]]<br />
<br />
==== Virtual Network Types ====<br />
<br />
LXC containers support the following networking types:<br />
* '''empty''' - creates only loopback interface and assigns it to the container.<br />
* '''veth''' - a virtual etherned device is created with one side assigned to the container and other side attached to a bridge on LXC host. If the bridge is not specified, then the veth pair device will be created but not attached to any bridge. Using '''veth''' with '''bridge''' is useful when you want to create virtual networks for LXC containers and LXC host. <br />
* '''macvlan''' - a macvlan interface is created and assigned to the container. macvlan interfaces can only communicate to other macvlan interfaces on the same LXC host. This is useful when you want to create different networks for different LXC containers and you do not need to access LXC containers from LXC host via network.<br />
* '''vlan''' - a vlan interface is linked with the interface specified in container's configuration and is assigned to a the container.<br />
* '''phys''' - an already existing interface is assigned to the container. This is useful when you want to assign a physical network interface to a LXC container.<br />
* '''none''' - will cause container to use host's network namespace.<br />
<br />
It is possible to configure container with several network virtualization types at the same time. This wiki page will configure only one at a time for simplicity.<br />
<br />
In your container config file, you will need to assign an IP address:<br />
<br />
lxc.network.ipv4 = 192.168.100.2/24<br />
<br />
You can also specify default gateway:<br />
<br />
lxc.network.ipv4.gateway= 192.168.100.1<br />
<br />
====Cgroups device configuration====<br />
Cgroups allows you to decide which devices the container is allowed to use, to see which devices are available to the container by default you can run "ls -la":<br />
# ls -la rootfs.dev/<br />
....<br />
crw------- 1 root root 5, 1 Sep 15 16:03 console<br />
crw-rw-rw- 1 root root 1, 3 Sep 15 16:03 null<br />
crw-rw-rw- 1 root root 1, 8 Sep 15 16:03 random<br />
crw-rw-rw- 1 root root 5, 0 Sep 15 16:47 tty<br />
-rw------- 1 root root 0 Sep 15 16:03 tty1<br />
crw-rw-rw- 1 root root 1, 9 Sep 15 16:03 urandom<br />
crw-rw-rw- 1 root root 1, 5 Sep 15 16:03 zero<br />
...<br />
<br />
This shows you the device numbers in the format "majorNumber, minorNumber", you need these numbers to edit the cgroups configuration, for example if you want allow access to /dev/null you can add this to the lxc container's config file:<br />
# the "c" stands for character device<br />
lxc.cgroup.devices.allow = c 1:3 rwm<br />
as you can see the "ls -la" command will show you the numbers you need to allow or deny<br />
The rootfs.dev/ directory corresponds to the /dev directory inside the container, you can also run "ls -la /dev" outside the container to see which devices you have available outside the container.<br />
<br />
===== Add non-default devices =====<br />
See [[Lxc-systemd]] if you want to add a device not available by default.<br />
If you just want to temporarily add a certain device, for instance a loop device.<br />
First find the major and minor device numbers, in our case since we want a loop device we take '''7:*''' since we want all the loop devices from 0 and on.<br />
<br />
Then add this to the config file:<br />
# lxc.cgroup.devices.allow = typeofdevice majornumber:minornumber rwm<br />
lxc.cgroup.devices.allow = b 7:* rwm<br />
Start the container, then run the following inside:<br />
# check which devices are already busy<br />
$ losetup -a<br />
/dev/loop0: [65024]:1689590 (/mnt)<br />
# pick a device not already in use like loop5, the '''b''' stands for byte device, a '''c''' for character device, see man mknod, the cgroup here is 7, 5 for loop device number 5<br />
$ mknod /dev/loop5 -m0660 b 7 5<br />
$ losetup -f<br />
/dev/loop5<br />
Your loop device is located in /dev/loop5 and is ready to be used!<br />
<br />
===== Host device access settings =====<br />
<br />
lxc.cgroup.devices.deny = a # Deny all access to devices<br><br />
lxc.cgroup.devices.allow = c 1:3 rwm # dev/null<br />
lxc.cgroup.devices.allow = c 1:5 rwm # dev/zero<br><br />
lxc.cgroup.devices.allow = c 5:1 rwm # dev/console<br />
lxc.cgroup.devices.allow = c 5:0 rwm # dev/tty<br />
lxc.cgroup.devices.allow = c 4:0 rwm # dev/tty0<br><br />
lxc.cgroup.devices.allow = c 1:9 rwm # dev/urandom<br />
lxc.cgroup.devices.allow = c 1:8 rwm # dev/random<br />
lxc.cgroup.devices.allow = c 136:* rwm # dev/pts/*<br />
lxc.cgroup.devices.allow = c 5:2 rwm # dev/pts/ptmx<br><br />
# No idea what this is .. dev/bsg/0:0:0:0 ???<br />
lxc.cgroup.devices.allow = c 254:0 rwm<br />
<br />
===== Host device access settings explained =====<br />
<br />
'''lxc.cgroup.devices.deny''' : By setting this to ''a'', we are stating that the container has access to no devices unless explicitely defined within the configuration file.<br />
<br />
====Terminal settings====<br />
<br />
'''Sep/15/2014 - systemd will automatically log you into a tty when you run lxc-start, most of what follows is needed only if you want to run several TTYs simultaneously.'''<br />
<br />
The following configuration is optional. You may add them to your main configuration file if you wish to login via lxc-console, or through a terminal ( e.g.: {{ic|Ctrl+Alt+F1}} ).<br />
<br />
The container can be configured with virtual consoles (tty devices). These may be devices from the host that the container is given permission to use (by its configuration file) or they may be devices created locally within the container.<br />
<br />
The host's virtual consoles are accessed using the key sequence {{ic|Alt+Fn}} (or {{ic|Ctrl+Alt+Fn}} from within an X11 session). The left {{ic|Alt}} key reaches consoles 1 through 12 and the right {{ic|Alt}} key reaches consoles 13 through 24. Further virtual consoles may be reached by the {{ic|Alt+→}} key sequence which steps to the next virtual console.<br />
<br />
The container's local virtual consoles may be accessed using the "lxc-console" command.<br />
<br />
===== Host Virtual Consoles =====<br />
<br />
The container may access the host's virtual consoles if the host is not using them and the container's configuration allows it. Typical container configuration would deny access to all devices and then allow access to specific devices like this:<br />
<br />
lxc.cgroup.devices.deny = a # Deny all access to devices<br />
lxc.cgroup.devices.allow = c 4:0 rwm # /dev/tty0<br />
lxc.cgroup.devices.allow = c 4:1 rwm # /dev/tty1<br />
lxc.cgroup.devices.allow = c 4:2 rwm # /dev/tty2<br />
<br />
For a container to be able to use a host's virtual console it must not be in use by the host. This will most likely require the host's {{ic|/etc/inittab}} to be modified to ensure no getty or other process runs on any virtual console that is to be used by the container.<br />
<br />
After editing the host's {{ic|/etc/inittab}} file, issung a {{ic|killall -HUP init}} will terminate any getty processes that are no longer configured and this will free up the virtual conosole for use by the container.<br />
<br />
Note that local virtual consoles take precedence over host virtual consoles. This is described in the next section.<br />
<br />
===== Local Virtual Consoles =====<br />
<br />
The number of local virtual consoles that the container has is defined in the container's configuration file (normally on the host in {{ic|/etc/lxc}}). It is defined thus:<br />
<br />
lxc.tty = n<br />
<br />
where {{ic|n}} is the number of local virtual consoles required.<br />
<br />
The local virtual consoles are numbered starting at tty1 and take precedence over any of the host's virtual consoles that the container might be entitled to use. This means that, for example, if n = 2 then the container will not be able to use the host's tty1 and tty2 devices even entitled to do so by its configuration file. Setting n to 0 will prevent local virtual consoles from being created thus allowing full access to any of host's virtual consoles that the container might be entitled to use.<br />
<br />
===== /dev/tty Device Files =====<br />
<br />
The container must have a tty device file (e.g. {{ic|/dev/tty1}}) for each virtual console (host or local). These can be created thus:<br />
<br />
# mknod -m 666 /dev/tty1 c 4 1<br />
# mknod -m 666 /dev/tty2 c 4 2<br />
<br />
and so on...<br />
<br />
In the above, {{ic|c}} means character device, {{ic|4}} is the major device number (tty devices) and {{ic|1}}, {{ic|2}}, {{ic|3}}, etc., is the minor device number (specific tty device). Note that {{ic|/dev/tty0}} is special and always refers to the current virtual console.<br />
<br />
For further info on tty devices, read this: http://www.kernel.org/pub/linux/docs/device-list/devices.txt<br />
<br />
'''If a virtual console's device file does not exist in the container, then the container cannot use the virtual console.'''<br />
<br />
===== Configuring Log-In Ability =====<br />
<br />
The container's virtual consoles may be used for login sessions if the container runs "getty" services on their tty devices. This is normally done by the container's "init" process and is configured in the container's {{ic|/etc/inittab}} file using lines like this:<br />
<br />
c1:2345:respawn:/sbin/agetty -8 38400 tty1 linux<br />
<br />
There is one line per device. The first part {{ic|c1}} is just a unique label, the second part defines applicable run levels, the third part tells init to start a new getty when the current one terminates and the last part gives the command line for the getty. For further information refer to {{ic|man init}}.<br />
<br />
If there is no getty process on a virtual console it will not be possible to log in via that virtual console. A getty is not required on a virtual console unless it is to be used to log in.<br />
<br />
If a virtual console is to allow root logins it also needs to be listed in the container's {{ic|/etc/securetty}} file.<br />
<br />
===== Troubleshooting virtual consoles =====<br />
<br />
If lxc.tty is set to a number, n, then no host devices numbered n or below will be accessible even if the above configuration is present because they will be replaced with local virtual consoles instead.<br />
<br />
A tty device file's major number will change from 4 to 136 if it is a local virtual console. This change is visible within the container but not when viewing the container's devices from the host's filesystem. This information is useful when troubleshooting.<br />
<br />
This can be checked from within a container thus:<br />
<br />
# ls -Al /dev/tty*<br />
crw------- 1 root root 136, 10 Aug 21 21:28 /dev/tty1<br />
crw------- 1 root root 4, 2 Aug 21 21:28 /dev/tty2<br />
<br />
===== Pseudo Terminals =====<br />
<br />
lxc.pseudo = 1024<br />
<br />
Maximum amount of pseudo terminals that may be created in {{ic|/dev/pts}}. Currently, assuming the kernel was compiled with {{ic|CONFIG_DEVPTS_MULTIPLE_INSTANCES}}, this tells lxc-start to mount the devpts filesystem with the newinstance flag.<br />
<br />
=== Configuration file notes ===<br />
<br />
==== At runtime /dev/ttyX devices are recreated ====<br />
<br />
If you have enabled multiple DevPTS instances in your kernel, lxc-start will recreate ''lxc.tty'' amount of {{ic|/dev/ttyX}} devices when it is executed.<br />
<br />
This means that you will have ''lxc.tty'' amount of pseudo ttys. If you are planning on accessing the container via a "real" terminal ({{ic|Ctrl+Alt+FX}}), make sure that it is a number that is inferior to ''lxc.tty''.<br />
<br />
To tell whether it has been re-created, just log in to the container via either lxc-console or SSH and perform a {{ic|ls -Al}} command on the tty. Devices with a major number of 4 are "real" tty devices whereas a major number of 136 indicates a pts.<br />
<br />
Be aware that this is only visible from within the container itself and not from the host.<br />
<br />
==== Containers have access to host's TTY nodes ====<br />
<br />
If you do not properly restrict the container's access to the /dev/tty nodes, the container may have access to the host's.<br />
<br />
Taking into consideration that, as previously mentioned, lxc-start recreates ''lxc.tty'' amount of /dev/tty devices, any tty nodes present in the container that are of a greater minor number than ''lxc.tty'' will be linked to the host's.<br />
<br />
===== To access the container from a host TTY =====<br />
<br />
# On the host, verify no getty is started for that tty by checking ''/etc/inittab''.<br />
# In the container, start a getty for that tty.<br />
<br />
===== To prevent access to the host TTY =====<br />
<br />
Please have a look at the configuration statements found in [[#Host device access settings|host device access settings]].<br />
<br />
Via the ''lxc.cgroup.devices.deny = a'' we are preventing access to all host level devices. And then, throuh ''lxc.cgroup.devices.allow = c 4:'''1''' rwm'' we are allowing access to the host's /dev/tty'''1'''. In the above example, simply removing all allow statements for major number 4 and minor > 1 should be sufficient.<br />
<br />
===== To test this access =====<br />
<br />
I may be off here, but looking at the output of the ''ls'' command below should show you both the ''major'' and ''minor'' device numbers. These are located after the user and group and represented as : 4, 2<br />
<br />
# Set lxc.tty to 1<br />
# Make there that the container has dev/tty1 and /dev/tty2<br />
# ''lxc-start'' the container<br />
# ''lxc-console'' into the container<br />
# ''ls -Al /dev/tty''<br>crw------- 1 root root 4, 2 Dec 2 00:20 /dev/tty2<br />
# ''echo "test output" > /dev/tty2''<br />
# ''Ctrl+Alt+F2'' to view the host's second terminal<br />
# You should see "test output" printed on the screen<br />
<br />
==== Configuration troubleshooting ====<br />
<br />
===== console access denied: Permission denied =====<br />
<br />
If, when executing lxc-console, you receive the error ''lxc-console: console access denied: Permission denied'' you have most likely either omitted lxc.tty or set it to 0.<br />
<br />
===== lxc-console does not provide a login prompt =====<br />
<br />
Though you are reaching a tty on the container, it most likely is not running a getty. You will want to double check that you have a getty defined in the container's ''/etc/inittab'' for the specific tty.<br />
<br />
If using '''systemd''' chances are that a problem with the ''getty@.service'' script will bite you. The script only starts a getty if ''/dev/tty0'' exists. And since this condition is not met in the container, you get no getty. Use this patch, to let ''lxc-console'' finally work.<br />
<br />
{{bc|<nowiki><br />
--- /usr/lib/systemd/system/getty@.service.orig 2013-05-30 12:55:28.000000000 +0000<br />
+++ /usr/lib/systemd/system/getty@.service 2013-06-16 23:05:49.827146901 +0000<br />
@@ -20,7 +20,8 @@<br />
# On systems without virtual consoles, don't start any getty. (Note<br />
# that serial gettys are covered by serial-getty@.service, not this<br />
# unit<br />
-ConditionPathExists=/dev/tty0<br />
+ConditionVirtualization=|lxc<br />
+ConditionPathExists=|/dev/tty0<br />
<br />
[Service]<br />
# the VT is cleared by TTYVTDisallocate<br />
</nowiki>}}<br />
<br />
For more than one getty you have to explicitly enable the needed service (and decrease ''lxc.tty'' in the container configuration) by doing this:<br />
# ln -sf /usr/lib/systemd/system/getty@.service /etc/systemd/system/getty.target.wants/getty@ttyX.service<br />
The ''ttyX'' should be replaced by the tty you want to use such as ''tty2''. In the ''real'' system a configurable number of getty-services is automatically created from the ''systemd-logind.service''<br />
<br />
=== Configuring fstab ===<br />
<br />
none $CONTAINER_ROOTFS/dev/pts devpts defaults 0 0<br />
none $CONTAINER_ROOTFS/proc proc defaults 0 0<br />
none $CONTAINER_ROOTFS/sys sysfs defaults 0 0<br />
none $CONTAINER_ROOTFS/dev/shm tmpfs defaults 0 0<br />
<br />
This fstab is used by lxc-start when mounting the container. As such, you can define any mount that would be possible on the host such as bind mounting to the host's own filesystem. However, please be aware of any and all security implications that this may have.<br />
<br />
'''Warning''' : You certainly do not want to bind mount the host's /dev to the container as this would allow it to, amongst other things, reboot the host.<br />
<br />
== Troubleshooting ==<br />
<br />
===Container cannot be stopped when using systemd===<br />
<br />
''lxc-stop'' should be used for clean shutdown or reboot of the container, but only the ''reboot'' is working out of the box when using systemd.<br />
<br />
Shutdown will be signalled to the container with ''SIGPWR'' but current systemd does not have any services in place to handle the ''sigpwr.target''. But for the container we can simply reuse the ''poweroff.target'' and get exactly what we want.<br />
<br />
# ln -s /usr/lib/systemd/system/poweroff.target ${CONTAINER_RFS}/etc/systemd/system/sigpwr.target<br />
<br />
=== Cannot use pacman from inside an LXC container instance ===<br />
<br />
Attempting to use {{ic|pacman}} inside an LXC environment entered via {{ic|lxc-attach}} will result in the following error:<br />
<br />
error: GPGME error: Inappropriate ioctl for device<br />
<br />
To not have this error, make sure to use {{ic|pacman}} inside an LXC environment entered via {{ic|lxc-console}} only.<br />
<br />
===Starting container changes keymap of host computer===<br />
One solution is to create a wrapper around the start script that resets the keyboard layout every few seconds until the container has started:<br />
# ./lxc-start-wrapper<br />
sleep 3 && resetkeyboard 2>/dev/null &<br />
sleep 5 && resetkeyboard 2>/dev/null &<br />
sleep 6 && resetkeyboard 2>/dev/null &<br />
sleep 7 && resetkeyboard 2>/dev/null &<br />
sleep 9 && resetkeyboard 2>/dev/null &<br />
#sleep 15 && resetkeyboard 2>/dev/null &<br />
sudo lxc-start -n nameofcontainer<br />
<br />
# ./resetkeyboard<br />
setxkbmap us -print | xkbcomp - $DISPLAY<br />
#setxkbmap dvorak -print | xkbcomp - $DISPLAY<br />
# in case you have a custom keyboard layout located in $HOME/.xkb<br />
# setxkbmap -I ~/.xkb nameofcustomlayout -print | xkbcomp -I$HOME/.xkb - $DISPLAY<br />
<br />
== See also ==<br />
<br />
* [https://www.stgraber.org/2013/12/20/lxc-1-0-blog-post-series/ LXC 1.0 Blog Post Series]<br />
* [http://www.ibm.com/developerworks/linux/library/l-lxc-containers/ LXC@developerWorks]<br />
* [http://docs.docker.io/en/latest/installation/archlinux/ Docker Installation on ArchLinux]</div>Ndthttps://wiki.archlinux.org/index.php?title=Cgroups&diff=344227Cgroups2014-11-11T05:21:45Z<p>Ndt: add related articles</p>
<hr />
<div>[[Category:Kernel]]<br />
[[Category:Virtualization]]<br />
[[ja:Cgroups]]<br />
{{Related articles start}}<br />
{{Related|Linux Containers}}<br />
{{Related|Arch systemd container}}<br />
{{Related|Docker}}<br />
{{Related articles end}}<br />
<br />
'''cgroups''' (aka '''control groups''') is a Linux kernel feature to limit, police and account the resource usage of certain processes (actually process groups). Compared to other approaches like the 'nice' command or {{ic|/etc/security/limits.conf}}, cgroups are more flexible.<br />
<br />
Control groups can be used in multiple ways:<br />
* create and manage them on the fly using tools like '''cgcreate''', '''cgexec''', '''cgclassify''' etc<br />
* the "rules engine daemon", to automatically move certain users/groups/commands to groups ('''/etc/cgrules.conf''' and '''/usr/lib/systemd/system/cgconfig.service''')<br />
* through other software such as [[Linux Containers]] (LXC) virtualization<br />
<br />
== Installing ==<br />
<br />
First, install the utilities for managing cgroups; you need to install the {{AUR|libcgroup}} package from the [[AUR]].<br />
<br />
== Managing Resource Groups with Systemd ==<br />
<br />
You can [[Systemd#Using_units|enable]] the '''cgconfig''' service with systemd. This gives you the capability to track more easily any errors in '''cgconfig.conf'''.<br />
<br />
== Simple usage ==<br />
<br />
=== Ad-hoc groups ===<br />
<br />
One of the powers of cgroups is that you can create "ad-hoc" groups on the fly. You can even grant the privileges to create custom groups to regular users. ''groupname'' is the cgroup name:<br />
<br />
# cgcreate -a ''user'' -g memory,cpu:''groupname''<br />
<br />
Now all the tunables in the group ''groupname'' are writable by your user:<br />
<br />
$ ls -l /sys/fs/cgroup/memory/''groupname''<br />
total 0<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.event_control<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cgroup.procs<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_period_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.rt_runtime_us<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 cpu.shares<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 notify_on_release<br />
-rwxrwxr-x 1 user root 0 Sep 25 00:39 tasks<br />
<br />
Cgroups are hierarchical, so you can create as many subgroups as you like. If a normal user wants to run a ''bash'' shell under a new subgroup called 'foo':<br />
<br />
$ cgcreate -g memory,cpu:'''groupname/foo'''<br />
'''cgexec''' -g memory,cpu:groupname/foo '''bash'''<br />
<br />
To make sure:<br />
<br />
$ cat /proc/self/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
A new subdirectory was created for this group. To limit the memory usage of all processes in this group to '''10 MB''', run the following:<br />
<br />
$ echo 10000000 > /sys/fs/cgroup/memory/groupname/foo/memory.limit_in_bytes<br />
<br />
Note that the memory limit applies to RAM use only -- once tasks hit this limit, they will begin to swap. But it won't affect the performance of other processes significantly.<br />
<br />
Similarly you can change the CPU priority ("shares") of this group. By default all groups have '''1024''' shares. A group with '''100''' shares will get a ~10% portion of the CPU time:<br />
<br />
$ echo 100 > /sys/fs/cgroup/cpu/groupname/foo/cpu.shares<br />
<br />
You can find more tunables or statistics by listing the cgroup directory.<br />
<br />
You can also change the cgroup of already running processes. To move all 'bash' commands to this group:<br />
<br />
$ pidof bash<br />
13244 13266<br />
$ '''cgclassify''' -g memory,cpu:groupname/foo `pidof bash`<br />
$ cat /proc/13244/cgroup<br />
11:memory:/groupname/foo<br />
6:cpu:/groupname/foo<br />
<br />
=== Persistent group configuration ===<br />
<br />
{{Note|when using [[Systemd]] > &#61; 205 to manage cgroups, you can ignore this file entirely.<br />
}}<br />
<br />
If you want your cgroups to be created at boot, you can define them in {{ic|/etc/cgconfig.conf}} instead. For example, the "groupname" has a permission for '''$USER''' and ''users'' of group '''$GROUP''' to manage limits and add tasks. A ''subgroup'' "groupname/foo" group definitions would look like this. <br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
group '''groupname''' {<br />
perm {<br />
# who can manage limits<br />
admin {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
# who can add tasks to this group<br />
task {<br />
uid = '''$USER''';<br />
gid = '''$GROUP''';<br />
}<br />
}<br />
# create this group in cpu and memory controllers<br />
cpu { }<br />
memory { }<br />
}<br />
<br />
group '''groupname/foo''' {<br />
cpu {<br />
'''cpu.shares''' = 100;<br />
}<br />
memory {<br />
'''memory.limit_in_bytes''' = 10000000;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|<br />
*Comments should begin at the start of a line! The '''#''' character for comments must appear as the first character of a line. Else, ''cgconfigparser'' will have problem parsing it but will only report {{ic|cgroup change of group failed}} as the error, unless you started ''cgconfig'' with [[Systemd]]<br />
*The permissions section is optional.<br />
*The {{ic|/sys/fs/cgroup/}} hierarchy directory containing all ''controllers'' sub-directories is already created and mounted at boot as a virtual file system. This gives the ability to create a new group entry with the {{ic|''$CONTROLLER-NAME { }''}} command. If for any reason you want to create and mount hierachies in another place, you will then need to write a second entry in {{ic|/etc/cgconfig.conf}} following this way :<br />
<br />
mount { <br />
cpuset &#61; /your/path/''groupname'';<br />
}<br />
<br />
This is equivalent to these shell commands:<br />
{{ic| <br />
# mkdir /your/path/''groupname''<br />
# mount -t /your/path -o cpuset ''groupname'' /your/path/''groupname''}}<br />
<br />
}}<br />
<br />
== Useful examples ==<br />
<br />
=== Matlab ===<br />
<br />
Matlab does not have any protection against taking all your machine's memory or CPU. Launching a large calculation can thus trash your system. Here's the what I have put in {{ic|/etc/cgconfig.conf}} to protect from this (replace $USER with your username):<br />
<br />
{{hc|/etc/cgconfig.conf |2=<br />
# Prevent Matlab from taking all memory<br />
group matlab {<br />
perm {<br />
admin {<br />
uid = ''$USER'';<br />
}<br />
task {<br />
uid = ''$USER'';<br />
}<br />
}<br />
<br />
cpuset {<br />
cpuset.mems="0";<br />
cpuset.cpus="0-5";<br />
}<br />
memory {<br />
# 5 GiB limit<br />
memory.limit_in_bytes = 5368709120;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|Don't forget to change $USER to the actual username Matlab will be run by.}}<br />
This cgroup will bind Matlab to cores 0 to 5 (I have 8, so Matlab will only see 6) and cap its memory usage to 5 GiB. The "cpu" resource constrain can also be defined to prevent CPU usage, but I find the "cpuset" constrain to be sufficient.<br />
<br />
Launch matlab like this:<br />
<br />
$ cgexec -g memory,cpuset:matlab /opt/MATLAB/2012b/bin/matlab -desktop<br />
<br />
Make sure to use the right path to the executable.<br />
<br />
== Documentation ==<br />
<br />
* For information on controllers and what certain switches and tunables mean, refer to [https://www.kernel.org/doc/Documentation/cgroups/ kernel's Documentation/cgroup] (or install linux-docs and see {{ic|/usr/src/linux/Documentation/cgroup}}<br />
* A detailed and complete Resource Management Guide can be found in the [http://docs.fedoraproject.org/en-US/Fedora/17/html-single/Resource_Management_Guide/index.html#sec-How_Control_Groups_Are_Organized fedora project documentation].<br />
For commands and configuration files, see relevant man pages, e.g. {{ic|man cgcreate}} or {{ic|man cgrules.conf}}</div>Ndthttps://wiki.archlinux.org/index.php?title=Security&diff=333372Security2014-08-31T23:06:01Z<p>Ndt: /* Passwords */ add heading "Choosing secure passwords" to divide content better (hopefully)</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ja:Security]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
== Passwords ==<br />
<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
=== Choosing secure passwords ===<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Phrases of known words (e.g., {{ic|all of the lights}}, {{ic|correct horse battery staple}}), even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password, but note that the the various letters have very different probabilities of being found at the start of words ([[Wikipedia:Letter frequency#Relative frequencies of the first letters of a word in the English language|Wikipedia:Letter frequency]]).<br />
<br />
A better approach is to generate pseudo-random passwords with tools like {{Pkg|pwgen}} or {{Pkg|apg}}: for memorizing them, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
It is also very effective to combine these two techniques by saving long, complex random passwords with a [[List of applications/Security#Password managers|password manager]], which will be in turn accessed with a mnemonic password that will have to be used only for that purpose, especially avoiding to ever transmit it over any kind of network. This method of course limits the use of the stored passwords to the terminals where the database is available for reading (which on the other hand could be seen as an added security feature).<br />
<br />
See [[Disk_encryption#Choosing_a_strong_passphrase|choosing a strong passphrase]] and Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] for some additional background. <br />
<br />
=== Maintaining passwords ===<br />
<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. [[List of applications/Security#Password managers|Password managers]] can help manage large numbers of complex passwords: if you are copy-pasting the stored passwords from the manager to the applications that need them, make sure to clear the copy buffer every time, and ensure they are not saved in any kind of log (e.g. do not paste them in plain terminal commands, which would store them in files like {{ic|.bash_history}}). [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation. <br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
=== Password hashes ===<br />
<br />
{{Warning|SHA512 is designed as a fast hash function, not for password hashing. An attacker can brute force a SHA512 hashed password ''far'' faster than bcrypt or scrypt allow.}}<br />
<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
See also [[Wikipedia:Key stretching]].<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting_the_umask]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[Disk encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Role-based access control===<br />
The MAC implementation grsecurity supports is called role-based access control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you have not thought of.<br />
<br />
*[[Grsecurity#RBAC|Grsecurity RBAC]] has a learning mode like AppArmor for easy configureation<br />
*[[Grsecurity#RBAC|Grsecurity RBAC]] does not rely on extra meta-data like SELinux. RBAC is significantly faster then SELinux.<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Kernel hardening==<br />
<br />
===Restricting access to kernel logs===<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit a kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
===Restricting access to kernel pointers in the proc filesystem===<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
===Keep BPF JIT compiler disabled===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
{{note|[[grsecurity]] includes JIT hardening for the BPF JIT compiler, greatly reducing the risk of exploitation.}}<br />
<br />
===ptrace scope===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
{{note|In [[grsecurity]], this protection is toggled via the {{ic|kernel.grsecurity.harden_ptrace}} flag instead.}}<br />
<br />
====Examples of broken functionality====<br />
<br />
{{Note|You can still execute these commands as root, such as allowing them through {{ic|sudo}} for certain users, with or without a password.}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== Preventing link [[Wikipedia:TOCTOU|TOCTOU]] vulnerabilities ===<br />
<br />
See the [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7 commit message] for when this feature was added for the rationale.<br />
<br />
fs.protected_hardlinks = 1<br />
fs.protected_symlinks = 1<br />
<br />
{{Note|This is now enabled by default via {{ic|/usr/lib/sysctl.d/50-default.conf}}}}<br />
<br />
===hidepid===<br />
<br />
The kernel has the ability to hide other users' processes from unprivileged users by mounting the {{ic|proc}} filesystem with {{ic|1=hidepid=1}} or {{ic|1=hidepid=2}}. However, [http://lists.freedesktop.org/archives/systemd-devel/2012-October/006859.html this is currently broken with systemd] because it requires a workaround for the kernel's lack of support for virtualizing the cgroup filesystem in a container.<br />
<br />
===grsecurity===<br />
<br />
The [[grsecurity]] kernel provides many security-related improvements. It hardens both the kernel and userspace against common memory corruption vulnerabilities, along with providing many miscellaneous features and a role-based access control system. It is the only way to secure the kernel itself against exploitation, which is the most important improvement for a system already making good use of user isolation, containers/chroots and sandboxes.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH keys#Disabling password logins|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Password_protection_of_GRUB_menu]] for details.<br />
<br />
===Denying console login as root===<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
== See also ==<br />
<br />
* [[DeveloperWiki:Security]]<br />
* ArchWiki's Current list of security applications: [[List_of_Applications/Security|Lists of Applications: Security]]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [http://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Hardening Debian (pdf)]</div>Ndthttps://wiki.archlinux.org/index.php?title=Talk:Security&diff=333016Talk:Security2014-08-29T21:51:44Z<p>Ndt: call for help on the password section</p>
<hr />
<div>==Todo==<br />
*Update "Lockout user after three failed login attempts", file mentioned no longer contains those lines ? <br />
*descriptions/rationale for all the links to other articles (MAC)<br />
*base64 /dev/urandom | dd bs=1 count=10 2>/dev/null<br />
*use (enhanced?) ACL on partitions<br />
*[[Disk quota|quotas]]<br />
*limits/cgroups<br />
*sudo timeout<br />
*DNSSEC<br />
*[[Securely Wipe HDD]]<br />
*[[Using File Capabilities Instead Of Setuid]]<br />
*VNC, proxies, ssl, etc<br />
*rvim/rgvim<br />
*browser security (requestpolicy, noscript, sand-boxing browser)<br />
*PAX/<s>grsecurity</s><br />
*stack protector gcc flag: Put some text in the page indicationg Archlinux has it by default (See: [https://bugs.archlinux.org/task/18864 FS#18864])<br />
* document hidepid mount option<br />
* run services as non-root (mention that Arch does this where possible by default - but it needs improvement via feature requests)<br />
* run services in clean namespaces<br />
* run services in chroots<br />
* mention issues with sudo (any X11 application can grab the password, and it is a large setuid binary with potential vulnerabilities)<br />
--[[User:Thestinger|thestinger]] 18:09, 11 January 2011 (EST), --[[User:Det|Det]] ([[User talk:Det|talk]]) 11:35, 3 January 2013 (UTC),<br />
--[[User:Flu|Flu]] ([[User talk:Flu|talk]]) 13:49, 19 April 2013 (UTC)<br />
-- [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 22:45, 12 August 2013 (UTC)<br />
<br />
== CentOS Wiki OS Protection Article ==<br />
<br />
Hello,<br />
<br />
This seems to be a good article to cross-reference or to use as a basis to pull in more content here. CC BY SA rights so I suspect it is compatible with the Arch Wiki. http://wiki.centos.org/HowTos/OS_Protection<br />
<br />
I am hoping to pull some content in myself, but I am by no means a security guy. I figured some wiser heads might be able to make better use of it than I or correct any mistakes I might make while attempting to contribute.<br />
<br />
Cheers,<br />
[[User:AdamT|AdamT]] ([[User talk:AdamT|talk]]) 22:29, 1 August 2013 (UTC)<br />
<br />
:Of course the information itself is not licensed/licenseable, however the way it is presented is, so you either study the original article and present the same information here in an original way, or you actually adapt some content from that article, but in that case the licence clearly states that you have to credit the original authors, and ''I guess'' you can do it by mentioning the original article in the Summary of your edits, and adding a link to [[Security#See also]].<br />
:Just as a clarification, I know that [[Help:Style#Hypertext metaphor]] states "If the upstream documentation for the subject of your article is well-written and maintained, prefer just writing Arch-specific adaptations and linking to the official documentation for general information", however in this case we can't talk about "upstream documentation", that's why the rule doesn't apply and duplication of information is allowed, being CentOS's and Arch's wikis on the "same level" with respect to the information provided.<br />
:-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:33, 3 August 2013 (UTC)<br />
<br />
:: Let's first compare the sections in the two articles and see how they relate:<br />
::* '''Modifying fstab''' -> [[Security#Partitions]].<br />
::* '''Package installs''' -> We have [[Security#Authenticating_packages]] and a note at the bottom of [[Security#Partitions]].<br />
::** We ''definitely'' should talk about [[Pacman#Package_security]] in more depth. That is, we should have a general overview of the function of [[Pacman-key]] and why it is important from a security perspective. [[Pacman-key]] mentions the function of the utility, but not its importance from a security perspective.<br />
::* '''Physical protection''' -> [[Security#Physical_security]]<br />
::* '''Restricting root''' -> We have [[Security#Use_sudo_instead_of_su]] which is a good start, but does not mention [[Ssh#Deny_root_login]]. File system permissions on {{ic|/root}}, which I think by default are not {{ic|700}} (they should be) should be added to [[Security#Filesystem permissions]].<br />
::* '''Umask restrictions''' -> We should talk about {{ic|umask}} in [[Security#Filesystem permissions]].<br />
::* '''Pam modifications''' -> [[Realtime process management]], a wiki page in desperate need of editing.<br />
::* '''Reaping idle users''' -> We should cover this in [[Security#User_setup]].<br />
::* '''Restricting cron and at''' -> We have no equivalent.<br />
::* '''Wireless has to go''' -> Maybe worth talking about, but this is low-priority unless we are willing to write a more detailed section called "Wireless security" that is about more than just "turn off wireless."<br />
::* '''Sysctl Security''' -> Covered in [[Sysctl#TCP/IP stack hardening]], maybe we should just link to this.<br />
::* '''Using TCP Wrappers''' -> I could not find anything on ArchWiki discussing general security practices for {{ic|/etc/hotss}}.<br />
::* '''Beefing up IPTables''' -> Should be adapted into [[Iptables]], but perhaps [[Simple Stateful Firewall]] (an article that has good information, but I am not sure if its name makes sense).<br />
::* '''Tamper Resistance''' -> We should have a section on '''logging''' in general and incorporate tools like this, probably.<br />
::Comments ''highly'' appreciated.<br />
::-- [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 05:09, 3 August 2013 (UTC)<br />
:::If you want to start working in this direction, go for it! :) -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 11:04, 5 August 2013 (UTC)<br />
<br />
== Grsecurity sections ==<br />
<br />
We now have three sections devoted only to Grsecurity. What can we do about this?<br />
<br />
The [https://wiki.archlinux.org/index.php?title=Security&diff=272330&oldid=272327 addition] of [[Security#Grsecurity RBAC]] seems to be redundant. However, I agree that "RBAC" is a better name for Grsecurity's MAC implementaiton than [[Security#Access Control Lists]]. In technical terms ACLs are a subset of RBAC and Grsecurity implmeents both. The Grsecurity patchset [https://www.cs.virginia.edu/~jcg8f/GrsecuritySELinuxCaseStudy.pdf only had ACLs][PDF] back in 2005, and the cited case study mentions (it also refers to SELinux as a RBAC implementation, so perhaps SELinux should also be mentioned there):<br />
<br />
:This implementation of ACLs creates a form of process-based mandatory access control. It is possible to restrict what a process can and cannot do. Additionally, access can be restricted to an object for any user, even root. Further, these restrictions cannot be changed by normal users. The system will soon offer role-based access control as well. <br />
<br />
Probably the right solution for this is:<br />
<br />
* Rename [[Security#Grsecurity RBAC]] to [[Security#Role-Based Access Control]].<br />
* Discuss both SELinux/Grsecurity implementations there. There is no need for the RBAC section to be Grsecurity-specific.<br />
<br />
[[Security#Kernel Hardening]] is only about [[Grsecurity]] but I am not sure if it should be merged into [[Security#Mandatory access control|Mandatory access control]] as suggested.<br />
<br />
* I think it is best to give general recommendations here rather than something like "install Grsecurity to make your kernel secure".<br />
* The right solution is probably to expand [[Security#Kernel Hardening]] and discuss [[Wikipedia:PaX]] and whatnot more generally, mentioning Grsecurity as an implementation. <br />
* I do think [[Security#Kernel Hardening]] should probably be moved lower on the page, closer to [[Security#Mandatory access control]]/[[Security#Network and Firewalls]]/[[Security#Authenticating packages]] since that seems to better suit the logical flow of the article.<br />
<br />
-- [[User:Ndt|Ndt]] ([[User Talk:Ndt|talk]]) 21:36, 4 September 2013 (UTC)<br />
<br />
:I can't comment on the content since I don't know much about it, but allow me to add some notes:<br />
:# The different security models (RBAC, MAC, DAC, ACL, ...) should be compared/described separately from the individual implementations (SELinux, Tomoyo, AppArmor, ...). Meaning there should be separate sections for each group, but mainly ''"RBAC is significantly faster then SELinux."'' does not make much sense.<br />
:# There should always be provided alternatives, not just 1:1 mapping (like in case of RBAC and Grsecurity).<br />
:# Descriptions of both ''groups'' can be provided from multiple perspectives. From my experience, in these situations a comparison table is often the best solution.<br />
:I'm not sure about the [[Security#Kernel Hardening]] section, should it focus only on security options that require patching the Arch kernel, or also those included in Arch kernel but not activated?<br />
:I hope it makes sense...<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 22:09, 4 September 2013 (UTC)<br />
::+1, also on mentioning the other options. I further agree with Ndt, moving [[Security#Kernel Hardening]] down to below (or above?) [[Security#Mandatory_access_control]] and merging the bits for [[Security#Kernel_parameters]] into it is better flow, then any other options that are avail without patching into it, followed by PAX and the existing Grsecurity so those get mentioned just before MAC. If someone wants to work on that: I like the comparison/table [http://www.cyberciti.biz/tips/selinux-vs-apparmor-vs-grsecurity.html here] maybe it gives some inspiration how to expand. If not, maybe good for See also. (further comparisons are at the bottom of the link). --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 18:05, 5 September 2013 (UTC)<br />
<br />
== Nobody as script user ==<br />
<br />
[[Systemd/cron_functionality#The_pkgstats_service]] article says that it is better to use {{ic|noboby}} for some tipe of scripts. Is there any person who can explain further and add a note in this article?<br />
<br />
-- [[User:Flu|Flu]] ([[User talk:Flu|talk]]) 11:29, 13 September 2013 (UTC)<br />
<br />
: Following the [[Wikipedia:Principle of least privilege|principle of least privilege]] it is logical to run as many scripts as possible as an unprivileged user. But this is not possible always, e.g. when the script needs (write) access to some file(s) to function properly, you need to provide those privileges. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 13:32, 13 September 2013 (UTC)<br />
::It's not actually a good idea to do this. Processes running as {{ic|nobody}} can ptrace each other, so there is a loss of security if more than one thing is run as that users. Ideally, individual users would be created for each case. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 10:52, 31 March 2014 (UTC)<br />
<br />
== Improving the password section ==<br />
<br />
This is a call for ideas and community effort to improve the password recommendations here. I think it's generally agreed that the password section needs (and has, for a long time, needed) some work.<br />
<br />
What does the password section need? Is it even necessary - does it make sense for someone to get this information from a wiki? How can we back up our statements, so that we know that the password recommendations made aren't just totally arbitrary (e.g, "at least one number ...")? <br />
<br />
Citing sources, I think, is useful here - even though there's an element of password generation that is a matter of opinion, there are many recommendation that can be made that are ''not'' opinion. Just my two cents. - [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 21:51, 29 August 2014 (UTC)</div>Ndthttps://wiki.archlinux.org/index.php?title=User_talk:Axper&diff=332822User talk:Axper2014-08-28T01:17:42Z<p>Ndt: security page addition</p>
<hr />
<div>== Passwords ==<br />
<br />
I've updated the [[Security#Passwords|Security section on passwords]]. It's not perfect, but let me know what you think. [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 01:17, 28 August 2014 (UTC)</div>Ndthttps://wiki.archlinux.org/index.php?title=Security&diff=332819Security2014-08-28T01:01:44Z<p>Ndt: /* Passwords */ commentary on passwords, what's insecure, and how to memorize good ones</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ja:Security]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
==Passwords==<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. Insecure passwords include those containing:<br />
<br />
* Personally identifiable information (e.g., a your dog's name, date of birth, area code, favorite video game)<br />
* Simple character substitutions on words (e.g., {{ic|k1araj0hns0n}})<br />
* Root "words" or common strings followed or preceded by added numbers, symbols, or characters (e.g., {{ic|DG091101%}})<br />
* Phrases of known words (e.g., {{ic|all of the lights}}, {{ic|correct horse battery staple}}), even with character substitution.<br />
<br />
The right choice for a password is something long (8-20 characters, depending on importance) and seemingly completely random.<br />
A good technique for building secure, seemingly random passwords is to base them on characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to {{ic|t6!WdtR5}} or, less simply, {{ic|t&6!RrlW@dtR,57}}.<br />
This approach could make it easier to remember a password.<br />
<br />
See [[Disk_encryption#Choosing_a_strong_passphrase|choosing a strong passphrase]] and Bruce Schneier's article [https://www.schneier.com/blog/archives/2014/03/choosing_secure_1.html Choosing Secure Passwords] for some additional background. <br />
<br />
Tools like {{Pkg|pwgen}} and {{Pkg|apg}} can help you generate secure passwords.<br />
<br />
For memorizing generated random passwords, one technique (for ones typed often) is to generate a long password and memorize a minimally secure number of characters, temporarily writing down the full generated string. Over time, increase the number of characters typed - until the password is ingrained in muscle memory and need not be remembered. This technique is more difficult, but can provide confidence that a password will not turn up in wordlists or "intelligent" brute force attacks that combine words and substitute characters.<br />
<br />
===Maintaining passwords===<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. Tools like {{Pkg|pass}}, {{Pkg|keepassx}}, and {{Pkg|gnome-keyring}} can help manage large numbers of complex passwords. [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
===Password hashes===<br />
{{Warning|SHA512 is designed as a fast hash function, not for password hashing. An attacker can brute force a SHA512 hashed password ''far'' faster than bcrypt or scrypt allow.}}<br />
<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting_the_umask]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[Disk encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Role-based access control===<br />
The MAC implementation grsecurity supports is called role-based access control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you have not thought of.<br />
<br />
*[[Grsecurity#RBAC|Grsecurity RBAC]] has a learning mode like AppArmor for easy configureation<br />
*[[Grsecurity#RBAC|Grsecurity RBAC]] does not rely on extra meta-data like SELinux. RBAC is significantly faster then SELinux.<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Kernel hardening==<br />
<br />
===Restricting access to kernel logs===<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit a kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
===Restricting access to kernel pointers in the proc filesystem===<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
===Keep BPF JIT compiler disabled===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
{{note|[[grsecurity]] includes JIT hardening for the BPF JIT compiler, greatly reducing the risk of exploitation.}}<br />
<br />
===ptrace scope===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
{{note|In [[grsecurity]], this protection is toggled via the {{ic|kernel.grsecurity.harden_ptrace}} flag instead.}}<br />
<br />
====Examples of broken functionality====<br />
<br />
{{Note|You can still execute these commands as root, such as allowing them through {{ic|sudo}} for certain users, with or without a password.}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== Preventing link [[Wikipedia:TOCTOU|TOCTOU]] vulnerabilities ===<br />
<br />
See the [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7 commit message] for when this feature was added for the rationale.<br />
<br />
fs.protected_hardlinks = 1<br />
fs.protected_symlinks = 1<br />
<br />
{{Note|This is now enabled by default via {{ic|/usr/lib/sysctl.d/50-default.conf}}}}<br />
<br />
===hidepid===<br />
<br />
The kernel has the ability to hide other users' processes from unprivileged users by mounting the {{ic|proc}} filesystem with {{ic|1=hidepid=1}} or {{ic|1=hidepid=2}}. However, [http://lists.freedesktop.org/archives/systemd-devel/2012-October/006859.html this is currently broken with systemd] because it requires a workaround for the kernel's lack of support for virtualizing the cgroup filesystem in a container.<br />
<br />
===grsecurity===<br />
<br />
The [[grsecurity]] kernel provides many security-related improvements. It hardens both the kernel and userspace against common memory corruption vulnerabilities, along with providing many miscellaneous features and a role-based access control system. It is the only way to secure the kernel itself against exploitation, which is the most important improvement for a system already making good use of user isolation, containers/chroots and sandboxes.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH keys#Disabling password logins|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Password_protection_of_GRUB_menu]] for details.<br />
<br />
===Denying console login as root===<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
== See also ==<br />
<br />
* [[DeveloperWiki:Security]]<br />
* ArchWiki's Current list of security applications: [[List_of_Applications/Security|Lists of Applications: Security]]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [http://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Hardening Debian (pdf)]</div>Ndthttps://wiki.archlinux.org/index.php?title=UMID_SE&diff=330996UMID SE2014-08-19T05:21:43Z<p>Ndt: /* Screen brightness */ typo correction</p>
<hr />
<div>[[Category:Laptops]]<br />
{{stub}}<br />
This guide assumes that you are experienced in installing Archlinux. If you are not experienced, please read this guide in parallel with the [[Beginners' guide]] or the [[Installation guide]]. No assumptions are made on your desired environment (DE/WM). Note that the SSD will completely be wiped if you follow this guide without alterations.<br />
<br />
== Installing Archlinux ==<br />
<br />
=== SSD partitining ===<br />
<br />
You'll also need to manually format the SSD before using the installer. Install GPT tools from {{Pkg|gptfdisk}} as described in the [[SSD#Using GPT - RECOMMENDED METHOD|SSD Article]]. This ensures that your partitions are properly aligned. Run it:<br />
gdisk /dev/sda<br />
<br />
Type {{ic|o}} to clear out the partition table and then create at least 3 partitions by typing {{ic|n}} and answering the questions (type {{ic|?}} or {{ic|m}} for help). You need at least a 2MiB Partition at the beginning for the boot loader as well as a bit more than 1GiB of swap space to be able to use hibernation. Your partition table should look something like this in the end (for example using 8GiB for {{ic|/}} and the rest for {{ic|/home}} :<br />
Number Start (sector) End (sector) Size Code Name<br />
1 2048 6143 2.0 MiB EF02 BIOS boot partition<br />
2 6144 2463743 1.2 GiB 8200 Linux swap<br />
3 2463744 19240959 8.0 GiB 8300 Linux filesystem<br />
4 19240960 61865950 20.3 GiB 8300 Linux filesystem<br />
Type {{ic|w}} to write the partition table. Note that the SSD doesn't seem to support TRIM. Make sure to leave plenty of free space on each partition so you don't run into performance issues.<br />
<br />
=== Running the installer ===<br />
<br />
Progress through the installer as usual, but mind these things:<br />
* When configuring the hard drive, select to configure the mountpoints manually and choose the mountpoints accordingly. Regarding filesystems, you can select {{ic|ext2}} for the BIOS boot partition. For the root and any other regular partitions [[ext4]] is a good choice.<br />
* Install {{Pkg|iw}} and {{Pkg|wireless_tools}} from core to be able to connect to a [[Wireless network configuration|wifi network]] in your freshly installed system. You may also want to select [[netctl]].<br />
* When editing the config files, edit {{ic|/etc/fstab}} and add the {{ic|noatime,nodiratime,discard}} options to your ext4 partitions. Also remove disable '''network''' [[daemon]].<br />
* Skip the bootloader installation, exit the installer but do '''not''' reboot!<br />
<br />
=== Installing the bootloader ===<br />
<br />
After exiting the installer, do this while still running from the install medium. Prepare the environment:<br />
# cp /etc/resolv.conf /tmp/install/etc/resolv.conf<br />
# modprobe dm-mod<br />
# mount -o bind /dev /mnt/dev<br />
# mount -t proc /proc /mnt/proc/<br />
# mount -t sysfs /sys /mnt/sys/<br />
Chroot into your fresh installation:<br />
# chroot /mnt bash<br />
Install GRUB:<br />
# pacman-db-upgrade<br />
# pacman -Syy<br />
# rm -rf /boot/grub<br />
# pacman -S grub2-bios<br />
# grub-install --directory=/usr/lib/grub/i386-pc --target=i386-pc --boot-directory=/boot --recheck --debug /dev/sda<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
Now you're ready to reboot!<br />
<br />
== Configuring the system ==<br />
<br />
=== Power saving and thermal monitoring ===<br />
<br />
The UMID SE can get quite hot because of the relatively powerful CPU and lack of air flow. This happens especially when charging the batteries. Keep an eye on the thermals at all times. Refer to [[#dzen|dzen]] for an example on how to do this efficiently. Enable cpu scaling, configure the thermal sensor and enable all power saving options as follows:<br />
<br />
See [[power saving]].<br />
<br />
=== Graphics driver ===<br />
<br />
There are several drivers and they're all terrible. The probably best option at the time of writing is the pbs_gfx driver used with fbdev. The performance (for playing videos for example) will nevertheless be awful but it works well for regular work. Install it as follows:<br />
Add {{ic|psb_gfx}} to {{ic|MODULES}} in {{ic|/etc/mkinitcpio.conf}} and rebuild the kernel initramfs:<br />
# mkinitcpio -p linux<br />
<br />
Install the {{Pkg|xf86-video-fbdev}} driver.<br />
<br />
You should now be able to install and run X.<br />
<br />
=== X ===<br />
<br />
Install Xorg and whatever DE/WM you want to use. You don't need any xorg.conf yet. Launch X.<br />
<br />
=== Screen brightness ===<br />
<br />
The psb_gfx driver allows for easy brightness settings via {{ic|/sys/class/backlight/psb-bl/brightness}}. Just {{ic|echo}} a value between 0 and 100 to that file and the brightness will be set. Here's a suitable script for changing the brightness using keyboard shortcuts.<br />
<br />
{{bc|<nowiki><br />
#!/bin/sh<br />
#increase or decrease the brightness by about 10%<br />
current="$(cat /sys/class/backlight/psb-bl/brightness)"<br />
if [[ "$1" == "up" ]]; then<br />
current=$((current+((current/10+1))))<br />
[[ $current -ge 100 ]] && current=100<br />
elif [[ "$1" == "down" ]]; then<br />
current=$((current-((current/10+1))))<br />
else<br />
echo "1st argument should be 'up' or 'down'"<br />
exit 1<br />
fi<br />
echo "$current" > /sys/class/backlight/psb-bl/brightness<br />
</nowiki>}}<br />
<br />
Place it in {{ic|/usr/local/bin}} or similar, allow it to be run by regular users using {{ic|visudo}} and then you can bind it to the brightness key combo on your keyboard by whatever means, for example through your WM. You may want to write the new value to a file and reload it upon boot-up or you can just set it to a default upon boot-up by adding this to a [[systemd]] tmpfile:<br />
w /sys/class/backlight/psb-bl/brightness - - - - 40<br />
<br />
=== Touchscreen ===<br />
<br />
At the time of writing, the touchscreen works out of the box as a relative "touch-pad-like" pointer device. After some correspondence with EETI, the following can be said:<br />
* The official "eGalax Touch driver" 3.06.5625 from [http://home.eeti.com.tw/web20/eGalaxTouchDriver/linuxDriver.htm EETI] does only work up until xorg 1.8.<br />
* The newer "eGTouch daemon driver" does not support the PS/2 interface used in the UMID SE.<br />
* I have been given an update driver via email but I cannot disclose it at this time. Feel free to contact EETI through the email address mentioned at [http://home.eeti.com.tw/web20/eGalaxTouchDriver/linuxDriver.htm EETI] and ask for the updated egalax_drv.so for Xorg 1.11.<br />
When you have the updated egalax_drv.so, do the following. Add this to a systemd tmpfile, enabling raw access to the device at {{ic|/dev/serio_raw0}}:<br />
<br />
w /sys/bus/serio/devices/serio1/drvctl - - - - serio_raw<br />
<br />
The following kernel options must supposedly be enabled by adding them in {{ic|/etc/default/grub}}:<br />
GRUB_CMDLINE_LINUX_DEFAULT="quiet i8042.nomux=1 i8042.noloop=1"<br />
Install the 3.06.5625 driver via AUR by editing the PKGBUILD for {{ic|xf86-input-egalax-beta}}, updating the Version to 3.06.5625 and the source URL to<br />
http://home.eeti.com.tw/web20/drivers/touch_driver/Linux/20110831/eGalaxTouch-3.06.5625-32b-k26.tar.gz<br />
Run the PKGBUILD and install the package. Then copy over the updated egalax_drv.so overwriting the outdated one:<br />
cp ./egalax_drv.so /usr/lib/xorg/modules/input/<br />
Use the following {{ic|/etc/X11/xorg.conf}}<br />
Section "InputDevice"<br />
Identifier "EETI"<br />
Driver "egalax"<br />
Option "Device" "/dev/serio_raw0"<br />
Option "Parameters" "/var/lib/eeti.param"<br />
Option "ScreenNo" "0"<br />
EndSection<br />
<br />
Section "ServerLayout"<br />
Identifier "Default Layout"<br />
InputDevice "EETI" "SendCoreEvents"<br />
EndSection<br />
Reboot. You can now run {{ic|TKCal}} to calibrate your touchscreen and it should work as a proper absolute pointing device.<br />
<br />
=== Optical mouse ===<br />
<br />
Not working. A bug has been filed at the [https://bugzilla.kernel.org/show_bug.cgi?id=43058 Kernel bug tracker].<br />
<br />
=== Keyboard ===<br />
<br />
==== Special keys ====<br />
<br />
Create a file {{ic|/lib/udev/keymaps/umid-se}} containing:<br />
0xEE battery # Fn+Q<br />
0xDF sleep # Fn+W<br />
0xD5 switchvideomode # Fn+E<br />
0xF0 record # Fn+R<br />
0xF6 camera # Fn+T<br />
0xF9 brightnessdown # Fn+A<br />
0xF8 brightnessup # Fn+S<br />
0xA0 mute # Fn+D<br />
0xAE volumedown # Fn+F<br />
0xB0 volumeup # Fn+G<br />
0xFC wlan # Fn+J<br />
Edit {{ic|/lib/udev/rules.d/95-keymap.rules}} adding this after {{ic|1=LABEL="keyboard_vendorcheck"}}:<br />
ENV{DMI_VENDOR}=="UMiDCorp", ATTR{[dmi/id]product_name}=="M-BOOK", RUN+="keymap $name umid-se"<br />
The above vendor and product IDs can be found under {{ic|/sys/class/dmi/id/*}}. The codes themselves are written to dmesg when hitting the keys. Reboot to apply the changes.<br />
<br />
==== Capacitive stripe ====<br />
<br />
The UMID SE comes with a capacitive touch area above the keyboard (where the grey dots are). Input is given as keycodes. This is relatively useless and also litters dmesg with warnings about unknown scan codes. To remedy this, you can append this to {{ic|/lib/udev/keymaps/umid-se}} as pointed out above:<br />
0x75 prog1<br />
0xF5 prog1<br />
0x6F prog1<br />
0xDA prog1<br />
0x5A prog1<br />
0x62 prog1<br />
0xD9 prog1<br />
0xE0 prog1<br />
0xE2 prog1<br />
0xEF prog1<br />
0x59 prog1<br />
This will associate the whole general area with the {{ic|XF86Launch1}} keycode. You can now use the area as a hotkey like any other key. It's quite sensible though and may fire unintentionally, which is why it best left unused.<br />
<br />
=== Suspend and hibernation ===<br />
<br />
Should work in theory when using the psb_gfx driver for Poulsbo and using pm-suspend. Doesn't seem to work yet.<br />
{{ic|TODO}}<br />
<br />
=== Webcam ===<br />
<br />
Doesn't seem to be even connected. Not visible at all. Probably needs to be enabled by some sort of kill switch instruction.<br />
{{ic|TODO}}<br />
<br />
==Additional Information==<br />
<br />
=== BIOS password recovery ===<br />
<br />
The AMI BIOS of the UMID SE can be read out and decrypted using cmospwd which is in AUR.</div>Ndthttps://wiki.archlinux.org/index.php?title=Xmodmap&diff=330995Xmodmap2014-08-19T05:13:29Z<p>Ndt: add related link for xbindkeys</p>
<hr />
<div>{{Lowercase title}}<br />
[[Category:Keyboards]]<br />
[[Category:X Server]]<br />
[[de:Xmodmap]]<br />
[[fr:Xmodmap]]<br />
[[zh-CN:Xmodmap]]<br />
{{Related articles start}}<br />
{{Related|Xorg}}<br />
{{Related|Extra Keyboard Keys}}<br />
{{Related|Extra Keyboard Keys in Xorg}}<br />
{{Related|Extra Keyboard Keys in Console}}<br />
{{Related|Xbindkeys}}<br />
{{Related articles end}}<br />
<br />
''xmodmap'' is a utility for modifying keymaps and pointer button mappings in [[Xorg]].<br />
<br />
''xmodmap'' is not directly related to [[X KeyBoard extension]] (XKB), as it uses different (pre-XKB) ideas on how ''keycodes'' are processed within X. Generally, it is only recommended for the simplest tasks. See [[X KeyBoard extension]] for advanced layout configuration.<br />
<br />
== Introduction == <br />
<br />
There are two types of keyboard values in [[Xorg]]: ''keycodes'' and ''keysyms''.<br />
<br />
; keycode <br />
: The ''keycode'' is the numeric representation received by the kernel when a key or a mouse button is pressed.<br />
; keysym<br />
: The ''keysym'' is the value assigned to the ''keycode''. For example, pressing {{ic|A}} generates the {{ic|keycode 73}}, which is mapped to the {{ic|keysym 0×61}}, which matches {{ic|A}} in the [[Wikipedia:ASCII|ASCII table]].<br />
: The ''keysyms'' are managed by [[Xorg]] in a table of ''keycodes'' defining the ''keycode''-''keysym'' relations, which is called the [[#Keymap table|keymap table]]. This can be shown by running {{ic|xmodmap}}.<br />
<br />
== Installation ==<br />
<br />
''xmodmap'' can be [[pacman|installed]] through the {{Pkg|xorg-xmodmap}} package from the [[official repositories]].<br />
<br />
Optionally, install {{Pkg|xkeycaps}}, which is a graphical front-end to ''xmodmap''.<br />
<br />
== Keymap table ==<br />
<br />
Print the current keymap table formatted into expressions:<br />
<br />
{{hc|$ xmodmap -pke|2=<br />
[...]<br />
keycode 57 = n N<br />
[...]<br />
}}<br />
<br />
Each ''keycode'' is followed by the ''keysym'' it is mapped to. The above example indicates that the ''keycode'' {{ic|57}} is mapped to the lowercase {{ic|n}}, while the uppercase {{ic|N}} is mapped to ''keycode'' {{ic|57}} plus {{ic|Shift}}.<br />
<br />
Each ''keysym'' column in the table corresponds to a particular combination of modifier keys:<br />
# {{ic|Key}}<br />
# {{ic|Shift+Key}}<br />
# {{ic|mode_switch+Key}}<br />
# {{ic|mode_switch+Shift+Key}}<br />
# {{ic|AltGr+Key}}<br />
# {{ic|AltGr+Shift+Key}}<br />
<br />
Not all ''keysyms'' have to be set, but to assign only a latter ''keysym'', use the {{ic|NoSymbol}} value.<br />
<br />
To see which ''keycode'' corresponds to a key, see [[Extra Keyboard Keys#In Xorg]] for details on the ''xev'' utility.<br />
<br />
{{Tip|There are predefined descriptive ''keysyms'' for multimedia keys, e.g. {{ic|XF86AudioMute}} or {{ic|XF86Mail}}. These ''keysyms'' can be found in {{ic|/usr/include/X11/XF86keysym.h}}. Many multimedia programs are designed to work with these ''keysyms'' out-of-the-box, without the need to configure any third-party application.<br />
}}<br />
<br />
== Custom table ==<br />
<br />
To create a key map (i.e. {{ic|~/.Xmodmap}}):<br />
$ xmodmap -pke > ~/.Xmodmap<br />
<br />
To test the changes:<br />
$ xmodmap ~/.Xmodmap<br />
<br />
=== Activating the custom table ===<br />
<br />
With [[GDM]], [[XDM]] or [[KDM]] there is no need to source {{ic|~/.Xmodmap}}. For [[startx]], use:<br />
<br />
{{hc|~/.xinitrc|<br />
if [ -s ~/.Xmodmap ]; then<br />
xmodmap ~/.Xmodmap<br />
fi}}<br />
<br />
Alternatively, edit the global startup script {{ic|/etc/X11/xinit/xinitrc}}.<br />
<br />
=== Test changes ===<br />
<br />
To make temporary changes:<br />
$ xmodmap -e "keycode 46 = l L l L lstroke Lstroke lstroke"<br />
$ xmodmap -e "keysym a = e E"<br />
<br />
== Modifier keys ==<br />
<br />
''xmodmap'' can also be used to override [[Wikipedia:Modifier key|modifier keys]], e.g. to swap {{ic|Control}} and {{ic|Super}} (the [[Wikipedia:Windows key|Windows keys]]).<br />
<br />
Before assignment the modifier keys need to be empty. {{ic|!}} is a comment, so only the modifiers {{ic|Control}} and {{ic|Mod4}} get cleared in the following example. Then the ''keysyms'' {{ic|Control_L}}, {{ic|Control_R}}, {{ic|Super_L}} and {{ic|Super_R}} are assigned to the opposite modifier. Assigning both left and right to the same modifier means that both keys are treated the same way.<br />
<br />
{{hc|~/.Xmodmap|2=<br />
[...]<br />
!clear Shift<br />
!clear Lock<br />
clear Control<br />
!clear Mod1<br />
!clear Mod2<br />
!clear Mod3<br />
clear Mod4<br />
!clear Mod5<br />
!add Shift = Shift_L Shift_R<br />
!add Lock = Caps_Lock<br />
add Control = Super_L Super_R<br />
!add Mod1 = Alt_L Alt_R<br />
!add Mod2 = Mode_switch<br />
!add Mod3 =<br />
add Mod4 = Control_L Control_R<br />
!add Mod5 =<br />
}}<br />
<br />
{{Note|The example assumes that the {{ic|Control_L}} and {{ic|Control_R}} keysyms were assigned to the {{ic|Control}} modifier, and {{ic|Super_L}} and {{ic|Super_R}} keysyms to the {{ic|Mod4}} modifier. If you get the following error message {{ic|X Error of failed request: BadValue (integer parameter out of range for operation)}}, you will need to adapt accordingly. Running {{ic|xmodmap}} produces a list of modifiers and keys that are assigned to them.}}<br />
<br />
== Reverse Scrolling ==<br />
<br />
The [http://who-t.blogspot.com/2011/09/natural-scrolling-in-synaptics-driver.html natural scrolling] feature available in OS X Lion (mimicking smartphone or tablet scrolling) can be [https://bbs.archlinux.org/viewtopic.php?id=126258 replicated] with xmodmap. Since the synaptics driver uses the buttons 4/5/6/7 for up/down/left/right scrolling, you simply need to swap the order of how the buttons are declared in {{ic|~/.Xmodmap}}:<br />
<br />
{{hc|~/.Xmodmap|2=<br />
pointer = 1 2 3 '''5 4''' 7 6 8 9 10 11 12<br />
}}<br />
<br />
Then update xmodmap:<br />
$ xmodmap ~/.Xmodmap<br />
<br />
== Templates ==<br />
<br />
=== Spanish === <br />
<br />
{{hc|~/.Xmodmap|<br />
keycode 24 &#61; a A aacute Aacute ae AE ae<br />
keycode 26 &#61; e E eacute Eacute EuroSign cent EuroSign<br />
keycode 30 &#61; u U uacute Uacute downarrow uparrow downarrow<br />
keycode 31 &#61; i I iacute Iacute rightarrow idotless rightarrow<br />
keycode 32 &#61; o O oacute Oacute oslash Oslash oslash<br />
keycode 57 &#61; n N ntilde Ntilde n N n<br />
keycode 58 &#61; comma question comma questiondown dead_acute dead_doubleacute dead_acute<br />
keycode 61 &#61; exclam section exclamdown section dead_belowdot dead_abovedot dead_belowdot<br />
!Maps the Mode key to the Alt key<br />
keycode 64 &#61; Mode_switch<br />
}}<br />
<br />
=== Turn CapsLock into Control, and LeftControl into Hyper ===<br />
<br />
Laptop users may prefer having {{ic|CapsLock}} as {{ic|Control}}. The {{ic|Left Hyper}} key can be used as a modifier.<br />
<br />
{{hc|~/.Xmodmap|<nowiki><br />
clear lock <br />
clear control<br />
clear mod1<br />
clear mod2<br />
clear mod3<br />
clear mod4<br />
clear mod5<br />
keycode 37 = Hyper_L<br />
keycode 66 = Control_L<br />
add control = Control_L Control_R<br />
add mod1 = Alt_L Alt_R Meta_L<br />
add mod2 = Num_Lock<br />
add mod3 = Hyper_L<br />
add mod4 = Super_L Super_R<br />
add mod5 = Mode_switch ISO_Level3_Shift<br />
</nowiki>}}<br />
<br />
== See also ==<br />
<br />
*[http://www.x.org/archive/current/doc/man/man1/xmodmap.1.xhtml Current man page] at X.Org Foundation<br />
*[http://cweiske.de/howto/xmodmap/allinone.html Multimediakeys with .Xmodmap HOWTO] by Christian Weiske<br />
*[http://dev-loki.blogspot.com/2006/04/mapping-unsupported-keys-with-xmodmap.html Mapping unsupported keys with xmodmap] by Pascal Bleser<br />
*[http://en.gentoo-wiki.com/wiki/Multimedia_Keys Multimedia Keys article]{{Dead link|2013|10|05}} on the [http://en.gentoo-wiki.com/ Gentoo Wiki]<br />
*[http://wiki.linuxquestions.org/wiki/List_of_Keysyms_Recognised_by_Xmodmap List of Keysyms Recognised by Xmodmap] on [http://linuxquestions.org LinuxQuestions]</div>Ndthttps://wiki.archlinux.org/index.php?title=Xbindkeys&diff=330994Xbindkeys2014-08-19T05:13:08Z<p>Ndt: add related link for xmodmap</p>
<hr />
<div>[[Category:Keyboards]]<br />
[[Category:X Server]]<br />
[[fr:Xbindkeys]]<br />
[[ru:Xbindkeys]]<br />
[[tr:Xbindkeys]]<br />
{{Related articles start}}<br />
{{Related|Xmodmap}}<br />
{{Related articles end}}<br />
<br />
Xbindkeys is a program that enables us to bind commands to certain keys or key combinations on the keyboard. Xbindkeys works with multimedia keys and is window manager / DE independent, so if you switch much, xbindkeys is very handy. <br />
<br />
== Installation ==<br />
<br />
[[pacman|Install]] Xbindkeys with the package {{Pkg|xbindkeys}}, available in the [[official repositories]].<br />
<br />
For those who prefer a GUI, there is the {{AUR|xbindkeys_config}} package in the [[AUR]].<br />
<br />
== Configuration ==<br />
<br />
Create a file named {{ic|.xbindkeysrc}} in your home directory:<br />
$ touch ~/.xbindkeysrc<br />
<br />
Alternatively, you can create a sample file by invoking<br />
$ xbindkeys -d > ~/.xbindkeysrc<br />
<br />
Now you can either edit {{ic|~/.xbindkeysrc}} to set keybindings, or you can do that with the GUI.<br />
<br />
=== Xbindkeysrc ===<br />
<br />
To see the format of a configuration file entry, enter the following command:<br />
$ xbindkeys -k<br />
<br />
A blank window will pop up. Press the key(s) to which you wish to assign a command and ''xbindkeys'' will output a handy snippet that can be entered into {{ic|~/.xbindkeysrc}}. For example, while the blank window is open, press {{ic|Alt+o}} to get the following output (results may vary):<br />
"(Scheme function)"<br />
m:0x8 + c:32<br />
Alt + o<br />
<br />
The first line represents a command. The second contains the state (0x8) and keycode (32) as reported by {{ic|xev}}. The third line contains the keysyms associated with the given keycodes. To use this output, copy either one of the last two lines to {{ic|~/.xbindkeysrc}} and replace "(Scheme function)" with the command you wish to perform. Here is an example configuration file that binds Fn key combos on a laptop to {{AUR|pamixer}} commands that adjust sound volume. Note that pound (#) symbols can be used to create comments.<br />
# Increase volume<br />
"pamixer --increase 5"<br />
XF86AudioRaiseVolume<br />
<br />
# Decrease volume<br />
"pamixer --decrease 5"<br />
m:0x0 + c:122<br />
or<br />
"pamixer --decrease 5"<br />
XF86AudioLowerVolume<br />
<br />
Alternatively, instead of {{AUR|pamixer}} it is also possible to use ''pactl'' to control a running [[PulseAudio]] and to change volume level (replace above ''pamixer'' command with the following):<br />
pactl set-sink-volume 0 -- +2%<br />
pactl set-sink-volume 0 -- -2%<br />
pactl set-sink-mute 0 toggle<br />
<br />
Another possibilty is to use amixer (part of the alsa-utils package)<br />
amixer -c 1 set Master 5+<br />
amixer -c 1 set Master 5-<br />
amixer -c 1 set Master toggle<br />
<br />
<br />
{{Tip|Use {{ic|xbindkeys -mk}} to keep the key prompt open for multiple keypresses. Press {{ic|q}} to quit.}}<br />
<br />
=== GUI method ===<br />
<br />
If you installed the xbindkeys_config package, just run:<br />
$ xbindkeys_config<br />
<br />
== Usage ==<br />
<br />
Once you're done configuring your keys, edit your {{ic|~/.xinitrc}} and place <br />
xbindkeys<br />
<br />
before the line that starts your window manager or DE.<br />
<br />
== Simulating multimedia keys ==<br />
<br />
The XF86Audio* and other multimedia keys [http://wiki.linuxquestions.org/wiki/XF86_keyboard_symbols] are pretty-much well-recognized by the major DEs. For keyboards without such keys, you can simulate their effect with other keys<br />
# Decrease volume on pressing Super-minus<br />
"amixer set Master playback 1-"<br />
m:0x50 + c:20<br />
Mod2+Mod4 + minus<br />
However, to actually call the keys themselves you can use tools like xdotool [http://www.semicomplete.com/projects/xdotool/] (its in official repositories) and xmacro [http://xmacro.sourceforge.net/] (in the AUR). Unfortunately since you'd already be holding down some modifier key (Super or Shift, for example), X will see the result as {{ic|Super-XF86AudioLowerVolume}} which won't do anything useful. Here's a script based on ''xmacro'' and ''xmodmap'' from the {{Pkg|xorg-server-utils}} package for doing this[https://bbs.archlinux.org/viewtopic.php?pid=843395].<br />
{{bc|<br />
#!/bin/sh<br />
echo 'KeyStrRelease Super_L KeyStrRelease minus' | xmacroplay :0<br />
xmodmap -e 'remove Mod4 = Super_L'<br />
echo 'KeyStrPress XF86AudioLowerVolume KeyStrRelease XF86AudioLowerVolume' | xmacroplay :0<br />
xmodmap -e 'add Mod4 = Super_L'<br />
}}<br />
This works for calling XF86AudioLowerVolume once (assuming you are using {{ic|Super+minus}}), but repeatedly calling it without releasing the Super key (like tapping on a volume button) does not work. If you would like it to work that way, add the following line to the bottom of the script.<br />
echo 'KeyStrPress Super_L' | xmacroplay :0<br />
With this modified script, if you press the key combination fast enough your Super_L key will remain 'on' till the next time you hit it, which may result in some interesting side-effects. Just tap it again to remove that state, or use the original script if you want things to 'just work' and do not mind not multi-tapping on volume up/down.<br />
<br />
These instructions are valid for pretty much any one of the XF86 multimedia keys (important ones would be XF86AudioRaiseVolume, XF86AudioLowerVolume, XF86AudioPlay, XF86AudioPrev, XF86AudioNext).<br />
<br />
== Troubleshooting ==<br />
<br />
If, for any reason, a hotkey you ''already'' set in {{ic|~/.xbindkeysrc}} doesn't work, open up a terminal and type the following:<br />
$ xbindkeys -n<br />
<br />
By pressing the non-working key, you will be able to see any error ''xbindkeys'' encounter (e.g: mistyped command/keycode,...).</div>Ndthttps://wiki.archlinux.org/index.php?title=Patching_packages&diff=330991Patching packages2014-08-19T03:43:17Z<p>Ndt: more sensible summary. move extra info link to the bottom.</p>
<hr />
<div>[[Category:Package management]]<br />
This document covers the steps to creating and/or applying patches to packages when using ABS.<br />
<br />
==Creating patches==<br />
If you are attempting to use a patch that you got from elsewhere (ie: you downloaded a patch to the Linux kernel), you can skip to the next section. However, if you need to edit source code, make files, configuration files, etc, you will need to be able to create a patch.<br />
<br />
Note: If you need only to change one or two lines in a file (ie: a Makefile), you may be better off investigating the properties of <code>sed</code> instead.<br />
<br />
Creating a patch for a package involves creating two copies of the package, editing the new copy, and creating a unified diff between the two files. When creating an Arch Linux package, this can be done as follows:<br />
<br />
# Add the download source of the file to the source array of the <code>PKGBUILD</code> you are creating. Of course, if you are altering an existing PKGBUILD, this step is taken care of.<br />
# Create a dummy (empty, or containing a single <code>echo</code> command is good) build() function. If you are altering an existing <code>PKGBUILD</code>, you should comment out most of the lines of the build function, as you're likely going to be running <code>makepkg</code> several times, and you won't want to spend a lot of time waiting for a broken package to build.<br />
# Run <code>makepkg -o</code> This will download the source files you need to edit into the <code>src</code> directory.<br />
# Change to the <code>src</code> directory. In standard cases, there will be a directory containing a bunch of files that were unzipped or untarred from a downloaded archive there (Sometimes it's a single file, but diffs work on multiple files too!) You should make two copies of these directories. One is a pristine copy that makepkg won't be allowed to manipulate, and one will be the new copy that you will create a patch from. You can name the two copies <code>package.pristine</code> and <code>package.new</code> or something similar.<br />
# Change into the <code>package.new</code> directory. Edit whichever files need to be edited. The changes needed depend on what the patch has to do; it might correct a Makefile paths, it may have to correct source errors (for example, to agree with <code>gcc 3.4</code>), and so on. You can also edit files in subfolders of the <code>package.new</code> directory, of course. '''Do not''' issue any commands that will inadvertently create a bunch of files in the <code>package.new</code> directory; ie: do not try to compile the program to make sure your changes work. The problem is that all the new files will show up in the patch, and you do not want that. Instead, apply the patch to another copy of the directory ('''not''' the pristine directory), either manually with the <code>patch</code> command, or in the <code>PKGBUILD</code> (described below) and test the changes from there.<br />
# Change back to the <code>src</code> directory.<br />
# Run <code>diff -aur package.pristine package.new</code> This will output all the changes you made in unified diff format. You can scan these to make sure the patch is good.<br />
# Run <code>diff -aur package.pristine package.new > package.patch</code> to capture all the changes in a file named <code>package.patch</code>. This is the file that will be used by patch. You may now apply the changes to a copy of the original directory and make sure they are working properly. You should also check to ensure that the patch does not contain any extraneous details. For example, you do not want the patch to convert all tabs in the files you edited to spaces because your text editor did that behind your back. You can edit the patch either using a text editor, or to be safer (and not accidentally introduce errors into the diff file), edit the original files and create the patch afresh.<br />
<br />
==Applying patches==<br />
This section outlines how to apply patches you created or downloaded from the Internet from within a <code>PKGBUILD</code>'s <code>build()</code> function. Follow these steps:<br />
<br />
# Add an entry to the <code>source</code> array of the <code>PKGBUILD</code> for the patch file, separated from the original source url by a space. If the file is available online, you can provide the full URL and it will automatically be downloaded and placed in the <code>src</code> directory. If it is a patch you created yourself, or is otherwise not available, you should place the patch file in the same directory as the <code>PKGBUILD</code> file, and just add the name of the file to the source array so that it is copied into the <code>src</code> directory. If you redistribute the <code>PKGBUILD</code>, you should, of course, include the patch with the <code>PKGBUILD</code>.<br />
# Then use <code>updpkgsums</code> to update the <code>md5sums</code> array. Or manually add an entry to the <code>md5sums</code> array; you can generate sum of your patch using <code>md5sum</code> tool.<br />
# Create the <code>build()</code> function in the <code>PKGBUILD</code>. In most cases you will want to apply the patch first thing in the function, but you will know best where the patch lines need to be applied.<br />
# The first step is to change into the directory that needs to be patched (in the <code>build()</code> function, not on your terminal! You want to automate the process of applying the patch). You can do this with something like <code>cd $srcdir/$pkgname-$pkgver</code> or something similar. <code>$pkgname-$pkgver</code> is often the name of a directory created by untarring a downloaded source file, but not in all cases.<br />
# Now you simply need to apply the patch from within this directory. This is very simply done by adding <br />
patch -p1 -i $srcdir/pkgname.patch <br />
to your <code>build()</code> function, changing <code>pkgname.patch</code> to the name of the file containing the diff (the file that was automatically copied into your <code>src</code> directory because it was in the <code>source</code> array of the <code>PKGBUILD</code> file).<br />
<br />
An example build array with patch function:<br />
build() {<br />
cd "${srcdir}"/${pkgname}-${pkgver}<br />
patch -Np1 -i ../eject.patch<br />
./configure --prefix=/usr --sysconfdir=/etc --libexecdir=/usr/lib/xfce4 \<br />
--localstatedir=/var --disable-static \<br />
--enable-mcs-plugin --enable-python<br />
make<br />
}<br />
<br />
Run <code>makepkg</code> (from the terminal now). If all goes well, the patch will be automatically applied, and your new package will contain whatever changes were included in the patch. If not, you may have to experiment with the <code>-p</code> option of patch. read <code>man patch</code> for more information.<br />
Basically it works as follows. If the diff file was created to apply patches to files in <code>myversion/</code>, the diff files will be applied to <code>myversion/file</code>. You are running it from within the <code>yourversion/</code> directory (because you cd'd into that directory in the <code>PKGBUILD</code>), so when patch applies the file, you want it to apply it to the file <code>file</code>, taking off the <code>myversion/</code> part. <code>-p1</code> does this, by removing one directory from the path. However, if the developer patched in <code>myfiles/myversion</code>, you need to remove two directories, so you use <code>-p2</code>.<br />
<br />
If you do not apply a -p option, it will take off all directory structure. This is ok if all the files are in the base directory, but if the patch was created on <code>myversion/</code> and one of the edited files was <code>myversion/src/file</code>, and you run the patch without a <code>-p</code> option from within <code>yourversion</code>, it will try to patch a file named <code>yourversion/file</code>.<br />
<br />
Most developers create patches from the parent directory of the directory that is being patched, so <code>-p1</code> will usually be right.<br />
<br />
== External Links ==<br />
<br />
* [http://www.kegel.com/academy/opensource.html useful information on patching files]</div>Ndthttps://wiki.archlinux.org/index.php?title=Arch_build_system&diff=330990Arch build system2014-08-19T03:41:03Z<p>Ndt: add related link for patching in abs</p>
<hr />
<div>[[Category:About Arch]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[cs:Arch Build System]]<br />
[[da:Arch Build System]]<br />
[[de:Arch Build System]]<br />
[[el:Arch Build System]]<br />
[[es:Arch Build System]]<br />
[[fr:ABS]]<br />
[[it:Arch Build System]]<br />
[[ja:Arch Build System]]<br />
[[ko:Arch Build System]]<br />
[[pl:Arch Build System]]<br />
[[ro:ABS]]<br />
[[ru:Arch Build System]]<br />
[[tr:Arch_derleme_sistemi]]<br />
[[zh-CN:Arch Build System]]<br />
[[zh-TW:Arch Build System]]<br />
{{Related articles start}}<br />
{{Related|Arch packaging standards}}<br />
{{Related|Arch User Repository}}<br />
{{Related|Creating packages}}<br />
{{Related|Kernel Compilation with ABS}}<br />
{{Related|makepkg}}<br />
{{Related|Official repositories}}<br />
{{Related|pacman}}<br />
{{Related|PKGBUILD}}<br />
{{Related|Patching in ABS}}<br />
{{Related articles end}}<br />
<br />
This article provides an overview of the Arch Build System along with a walkthrough for beginners. It is not a complete reference guide. If you need more information, please reference the man pages.<br />
<br />
{{Note|ABS syncs once a day so it may lag behind what is already available in the repositories.}}<br />
<br />
== What is the Arch Build System? ==<br />
<br />
The Arch Build System, '''ABS''' for short, is a ''ports-like'' system for building and packaging software from source code. While [[pacman]] is the specialized Arch tool for binary package management (including packages built with the ABS), ABS is a collection of tools for compiling source into installable {{ic|.pkg.tar.xz}} packages.<br />
<br />
=== What is a ports-like system? ===<br />
<br />
''Ports'' is a system used by *BSD to automate the process of building software from source code. The system uses a ''port'' to download, unpack, patch, compile, and install the given software. A ''port'' is merely a small directory on the user's computer, named after the corresponding software to be installed, that contains a few files with the instructions for building and installing the software from source. This makes installing software as simple as typing {{ic|make}} or {{ic|make install clean}} within the port's directory.<br />
<br />
=== ABS is a similar concept ===<br />
<br />
ABS is made up of a directory tree (the ABS tree) residing under {{ic|/var/abs}}. This tree contains many subdirectories, each within a category and each named by their respective package. This tree represents (but does not contain) all ''official Arch software'', retrievable through the SVN system. You may refer to each package-named subdirectory as an 'ABS', much the way one would refer to a 'port'. These ABS (or subdirectories) do not contain the software package nor the source but rather a [[PKGBUILD]] file (and sometimes other files). A PKGBUILD is a simple Bash build script -- a text file containing the compilation and packaging instructions as well as the URL of the appropriate '''source''' tarball to be downloaded. (The most important component of ABS are PKGBUILDs.) By issuing the ABS [[makepkg]] command, the software is first compiled and then ''packaged'' within the build directory before being installed. Now you may use [[pacman]], the Arch Linux package manager, to install, upgrade, and remove your new package.<br />
<br />
=== ABS overview ===<br />
<br />
'ABS' may be used as an umbrella term since it includes and relies on several other components; therefore, though not technically accurate, 'ABS' can refer to the following tools as a complete toolkit:<br />
<br />
; ABS tree: The ABS directory structure; an SVN hierarchy under {{ic|/var/abs/}} on your (local) machine. It contains many subdirectories, named for all available official Arch Linux software from repositories specified in {{ic|/etc/abs.conf}}, but not the packages themselves. The tree is created after installing the {{Pkg|abs}} package with [[pacman]] and subsequently running the {{ic|abs}} script.<br />
<br />
{{note|The actual packages are available in [https://www.archlinux.org/svn/ svn] and [https://projects.archlinux.org/svntogit/packages.git/ git] repositories, and the {{ic|abs}} script downloads them using [[rsync]].}}<br />
<br />
; [[PKGBUILD]]s: A [[Bash]] script that contains the URL of the source code along with the compilation and packaging instructions.<br />
<br />
; [[makepkg]]: ABS shell command tool which reads the PKGBUILDs, automatically downloads and compiles the sources and creates a {{ic|.pkg.tar*}} according to the {{ic|PKGEXT}} array in {{ic|makepkg.conf}}. You may also use makepkg to make your own custom packages from the [[AUR]] or third-party sources. (See the [[Creating packages]] wiki article.)<br />
<br />
; [[pacman]]: pacman is completely separate, but is necessarily invoked either by makepkg or manually, to install and remove the built packages and for fetching dependencies.<br />
<br />
; [[Arch User Repository|AUR]]: The Arch User Repository is separate from ABS but AUR (unsupported) PKGBUILDs are built using makepkg to compile and package up software. In contrast to the ABS tree on your local machine, the AUR exists as a website interface. It contains many thousands of user-contributed PKGBUILDs for software which is unavailable as an official Arch package. If you need to build a package outside the official Arch tree, chances are it is in the AUR.<br />
<br />
== Why would I want to use ABS? ==<br />
<br />
The Arch Build System is used to:<br />
* Compile or recompile a package, for any reason<br />
* Make and install new packages from source of software for which no packages are yet available (see [[Creating packages]]) <br />
* Customize existing packages to fit your needs (enabling or disabling options, patching)<br />
* Rebuild your entire system using your compiler flags, "à la FreeBSD" (e.g. with [[pacbuilder]])<br />
* Cleanly build and install your own custom kernel (see [[Kernel Compilation]])<br />
* Get kernel modules working with your custom kernel<br />
* Easily compile and install a newer, older, beta, or development version of an Arch package by editing the version number in the PKGBUILD<br />
<br />
ABS is not necessary to use Arch Linux, but it is useful for automating certain tasks of source compilation.<br />
<br />
== How to use ABS ==<br />
<br />
Building packages using abs consists of these steps:<br />
#Install the {{Pkg|abs}} package with [[pacman]].<br />
#Run {{ic|abs}} as root to create the ABS tree by synchronizing it with the Arch Linux server.<br />
#Copy the build files (usually residing under {{ic|/var/abs/<repo>/<pkgname>}}) to a build directory.<br />
#Navigate to that directory, edit the PKGBUILD (if desired/necessary) and do '''makepkg'''. <br />
#According to instructions in the PKGBUILD, makepkg will download the appropriate source tarball, unpack it, patch if desired, compile according to {{ic|CFLAGS}} specified in {{ic|makepkg.conf}}, and finally compress the built files into a package with the extension {{ic|.pkg.tar.gz}} or {{ic|.pkg.tar.xz}}. <br />
#Installing is as easy as doing {{ic|pacman -U <.pkg.tar.xz file>}}. Package removal is also handled by pacman.<br />
<br />
=== Install tools ===<br />
<br />
To use the ABS, you first need to [[pacman|install]] {{Pkg|abs}} from the [[official repositories]].<br />
<br />
This will grab the abs-sync scripts, various build scripts, and [[rsync]] (as a dependency, if you do not already have it).<br />
<br />
Before you can actually build anything, however, you will also need basic compiling tools. These are handily collected in the [[Pacman#Installing_package_groups|package group]] {{grp|base-devel}}. This group can be installed with pacman.<br />
<br />
=== /etc/abs.conf ===<br />
<br />
As root, edit {{ic|/etc/abs.conf}} to include your desired repositories.<br />
<br />
Remove the {{ic|!}} in front of the appropriate repositories. For example:<br />
REPOS=(core extra community !testing)<br />
<br />
=== ABS tree ===<br />
<br />
The ABS tree is an SVN directory hierarchy located under {{ic|/var/abs}} and looks like this:<br />
<br />
{{bc|<nowiki><br />
| -- core/<br />
| || -- acl/<br />
| || || -- PKGBUILD<br />
| || -- attr/<br />
| || || -- PKGBUILD<br />
| || -- abs/<br />
| || || -- PKGBUILD<br />
| || -- autoconf/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- extra/<br />
| || -- acpid/<br />
| || || -- PKGBUILD<br />
| || -- apache/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- community/<br />
| || -- ...<br />
</nowiki>}}<br />
<br />
The ABS tree has exactly the same structure as the package database:<br />
<br />
* First-level: Repository name<br />
* Second-level: Package name directories<br />
* Third level: PKGBUILD (contains information needed to build a package) and other related files (patches, other files needed for building the package)<br />
<br />
The source code for the package is not present in the ABS directory. Instead, the '''PKGBUILD''' file contains a URL that will download the source code when the package is built. So the size of abs tree is quite small.<br />
<br />
==== Download ABS tree ====<br />
<br />
As root, run:<br />
<br />
# abs<br />
<br />
Your ABS tree is now created under {{ic|/var/abs}}. Note the appropriate branches of the ABS tree now exist and correspond to the ones you specified in {{ic|/etc/abs.conf}}. <br />
<br />
The abs command should be run periodically to keep in sync with the official repositories. Individual ABS package files can also be downloaded with:<br />
<br />
# abs <repository>/<package><br />
<br />
This way you do not have to check out the entire abs tree just to build one package.<br />
<br />
=== /etc/makepkg.conf ===<br />
<br />
[[makepkg]]'s {{ic|/etc/makepkg.conf}} specifies global environment variables and compiler flags which you may wish to edit if you are using an SMP system, or to specify other desired optimizations. The default settings are for i686 and x86_64 optimizations which will work fine for those architectures on single-CPU systems. (The defaults will work on SMP machines, but will only use one core/CPU when compiling -- see [[makepkg]] for details.)<br />
<br />
==== Set the PACKAGER variable in /etc/makepkg.conf ====<br />
<br />
Setting the {{ic|PACKAGER}} variable in {{ic|/etc/makepkg.conf}} is an optional but ''highly recommended'' step. It allows a "flag" to quickly identify which packages have been built and/or installed by YOU, not the official maintainer! This is easily accomplished using {{Pkg|expac}} available from the community repo:<br />
<br />
===== Showing all packages (including those from AUR) =====<br />
<br />
$ grep myname /etc/makepkg.conf<br />
PACKAGER="myname <myemail@myserver.com>"<br />
<br />
$ expac "%n %p" | grep "myname" | column -t<br />
archey3 myname<br />
binutils myname<br />
gcc myname<br />
gcc-libs myname<br />
glibc myname<br />
tar myname<br />
<br />
===== Showing only packages contained in repos =====<br />
<br />
This example only shows packages contained in the repos defined in {{ic|/etc/pacman.conf}}:<br />
<br />
$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)<br />
binutils<br />
gcc<br />
gcc-libs<br />
glibc<br />
tar<br />
<br />
=== Create a build directory ===<br />
<br />
It is recommended to create a build directory where the actual compiling will take place; you should never modify the ABS tree by building within it, as data will be lost (overwritten) on each ABS update. It is good practice to use your home directory, though some Arch users prefer to create a 'local' directory under {{ic|/var/abs/}}, owned by a normal user. <br />
<br />
Create your build directory. e.g.:<br />
<br />
$ mkdir -p $HOME/abs<br />
<br />
Copy the ABS from the tree ({{ic|/var/abs/<repository>/<pkgname>}}) to the build directory.<br />
<br />
=== Build package ===<br />
<br />
In our example, we will build the ''slim'' display manager package.<br />
<br />
Copy the slim ABS from the ABS tree to a build directory:<br />
<br />
$ cp -r /var/abs/extra/slim/ ~/abs<br />
<br />
Navigate to the build directory:<br />
<br />
$ cd ~/abs/slim<br />
<br />
Modify the PKGBUILD to your liking, then run ''makepkg'' (with the {{ic|-s}} flag to enable automatic build-time dependency handling):<br />
<br />
$ makepkg -s<br />
<br />
{{Note|Before complaining about missing (make) dependencies, remember that the group {{Grp|base-devel}} is assumed to be installed when building with ''makepkg''. See [[#Install tools]].}}<br />
<br />
Install as root:<br />
<br />
# pacman -U slim-1.3.0-2-i686.pkg.tar.xz<br />
<br />
That's it. You have just built slim from source and cleanly installed it to your system with pacman. Package removal is also handled by pacman with {{ic|pacman -R slim}}.<br />
<br />
The ABS method adds a level of convenience and automation, while still maintaining complete transparency and control of the build and installation functions by including them in the PKGBUILD.<br />
<br />
==== fakeroot ====<br />
<br />
Essentially, the same steps are being executed in the traditional method (generally including the {{ic|./configure, make, make install}} steps) but the software is installed into a ''fake root'' environment. (A ''fake root'' is simply a subdirectory within the build directory that functions and behaves as the system's root directory. In conjunction with the '''fakeroot''' program, ''makepkg'' creates a fake root directory, and installs the compiled binaries and associated files into it, with '''root''' as owner.) The ''fake root'', or subdirectory tree containing the compiled software, is then compressed into an archive with the extension {{ic|.pkg.tar.xz}}, or a ''package''. When invoked, pacman then extracts the package (installs it) into the system's real root directory ({{ic|/}}).<br />
<br />
=== Preserve modified packages ===<br />
<br />
Updating the system with pacman will replace a modified package from ABS with the package of the same name from the official repositories. See the following instructions for how to avoid this.<br />
<br />
Insert a group array into the PKGBUILD, and add the package to a group called {{ic|modified}}.<br />
<br />
{{hc|PKGBUILD|2=<br />
groups=('modified')<br />
}}<br />
<br />
Add this group to the section {{ic|IgnoreGroup}} in {{ic|/etc/pacman.conf}}.<br />
<br />
{{hc|/etc/pacman.conf|2=<br />
IgnoreGroup = modified<br />
}}<br />
<br />
If new versions are available in the official repositories during a system update, pacman prints a note that it is skipping this update because it is in the IgnoreGroup section. At this point the modified package should be rebuilt from ABS to avoid partial upgrades.</div>Ndthttps://wiki.archlinux.org/index.php?title=Bumblebee&diff=330847Bumblebee2014-08-18T02:48:37Z<p>Ndt: /* [ERROR]Cannot access secondary GPU: No devices detected = */ extra = sign :(</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X Server]]<br />
[[es:Bumblebee]]<br />
[[fr:Bumblebee]]<br />
[[it:Bumblebee]]<br />
[[ru:Bumblebee]]<br />
[[tr:Bumblebee]]<br />
[[zh-CN:Bumblebee]]<br />
{{Related articles start}}<br />
{{Related|NVIDIA Optimus}}<br />
{{Related|Nouveau}}<br />
{{Related|NVIDIA}}<br />
{{Related|Intel graphics}}<br />
{{Related articles end}}<br />
From Bumblebee's [https://github.com/Bumblebee-Project/Bumblebee/wiki/FAQ FAQ]:<br />
<br />
"''Bumblebee is an effort to make NVIDIA Optimus enabled laptops work in GNU/Linux systems. Such feature involves two graphics cards with two different power consumption profiles plugged in a layered way sharing a single framebuffer.''"<br />
<br />
== Bumblebee: Optimus for Linux ==<br />
<br />
[http://www.nvidia.com/object/optimus_technology.html Optimus Technology] is an ''[http://hybrid-graphics-linux.tuxfamily.org/index.php?title=Hybrid_graphics hybrid graphics]'' implementation without a hardware multiplexer. The integrated GPU manages the display while the dedicated GPU manages the most demanding rendering and ships the work to the integrated GPU to be displayed. When the laptop is running on battery supply, the dedicated GPU is turned off to save power and prolong the battery life. It has also been tested successfully with desktop machines with Intel integrated graphics and an nVidia dedicated graphics card. <br />
<br />
Bumblebee is a software implementation comprising of two parts:<br />
<br />
* Render programs off-screen on the dedicated video card and display it on the screen using the integrated video card. This bridge is provided by VirtualGL or primus (read further) and connects to a X server started for the discrete video card.<br />
* Disable the dedicated video card when it is not in use (see the [[#Power Management|Power management]] section)<br />
<br />
It tries to mimic the Optimus technology behavior; using the dedicated GPU for rendering when needed and power it down when not in use. The present releases only support rendering on-demand, automatically starting a program with the discrete video card based on workload is not implemented.<br />
<br />
== Installation ==<br />
<br />
Before installing Bumblebee check your BIOS and activate Optimus (older laptops call it "switchable graphics") if possible (BIOS doesn't have to provide this option), and install the [[Intel graphics|Intel driver]] for the secondary on board graphics card.<br />
<br />
Several packages are available for a complete setup:<br />
<br />
* {{Pkg|bumblebee}} - The main package providing the daemon and client programs.<br />
* (optional) {{Pkg|bbswitch}} (or {{AUR|bbswitch-dkms}}) - Recommended for saving power by disable the NVIDIA card.<br />
* (optional) If you want more than just saving power, that is rendering programs on the discrete NVDIA card you also need:<br />
** a driver for the NVIDIA card. The open-source [[nouveau]] driver or the more closed-source [[NVIDIA]] driver. See the subsection.<br />
** a render/display bridge. Two packages are currently available for that, {{Pkg|primus}} (or {{AUR|primus-git}}) and {{Pkg|virtualgl}}. Only one of them is necessary, but installing them side-by-side does not hurt.<br />
<br />
{{Note|If you want to run a 32-bit application on a 64-bit system you must install the proper lib32-* libraries for the program. In addition to this, you also need to install {{Pkg|lib32-virtualgl}} or {{Pkg|lib32-primus}}, depending on your choice for the render bridge. Just make sure you run {{ic|primusrun}} instead of {{ic|optirun}} if you decide to use Primus render bridge.}}<br />
<br />
=== Installing Bumblebee with Intel/NVIDIA ===<br />
<br />
Install {{Pkg|intel-dri}}, {{Pkg|xf86-video-intel}}, {{Pkg|bumblebee}} and {{Pkg|nvidia}}. If you have {{Pkg|intel-dri}} and {{Pkg|xf86-video-intel}} installed, you will have to reinstall them together with the rest to avoid a dependency conflict between {{Pkg|intel-dri}} and {{Pkg|nvidia}}. <br />
<br />
If you want to run 32-bit applications (like games with wine) on a 64-bit system you need the {{Pkg|lib32-nvidia-utils}} (and {{Pkg|lib32-intel-dri}} if you intend to use {{ic|primusrun}}) package too.<br />
<br />
{{Warning|Do not install {{pkg|lib32-nvidia-libgl}}. Bumblebee will find the correct lib32 NVIDIA libraries without it.}}<br />
<br />
=== Installing Bumblebee with Intel/Nouveau ===<br />
<br />
Install:<br />
* {{Pkg|xf86-video-nouveau}} - experimental 3D acceleration driver.<br />
* {{Pkg|nouveau-dri}} - Mesa classic DRI + Gallium3D drivers.<br />
* {{Pkg|mesa}} - Mesa 3D graphics libraries.<br />
<br />
== Start Bumblebee ==<br />
<br />
In order to use Bumblebee it is necessary add yourself (and other users) to the bumblebee group:<br />
<br />
# gpasswd -a $USER bumblebee<br />
<br />
where {{ic|$USER}} is the login name of the user to be added. Then log off and on again to apply the group changes.<br />
<br />
{{Tip|If you wish '''bumblebee''' to start at boot, you have to enable [[systemd]] service '''bumblebeed'''.}}<br />
<br />
Finished. Reboot system and use the shell program {{ic|[[#Usage|optirun]]}} for Optimus NVIDIA rendering!<br />
<br />
If you simply wish to disable your NVIDIA card, this should be all that is needed, apart from having {{ic|bbswitch}} installed. The bumblebeed daemon will, by default, instruct bbswitch to turn off the card when it starts. See also the [[#Power management|power management]] section below.<br />
<br />
== Usage ==<br />
<br />
The command line program {{ic|optirun}} shipped with Bumblebee is your best friend<br />
for running applications on your Optimus NVIDIA card.<br />
<br />
Test Bumblebee if it works with your Optimus system:<br />
$ optirun glxgears -info<br />
<br />
If it succeeds and the terminal you are running from mentions something about your NVIDIA - Optimus with Bumblebee is working!<br />
<br />
General usage:<br />
<br />
$ optirun [options] ''application'' [application-parameters]<br />
<br />
Some Examples:<br />
<br />
Start Windows applications with Optimus:<br />
<br />
$ optirun wine ''windows application''.exe<br />
<br />
Use NVIDIA Settings with Optimus:<br />
<br />
$ optirun -b none nvidia-settings -c :8<br />
<br />
For a list of options for {{ic|optirun}} view its manual page.<br />
<br />
A new program is soon becoming the default choice because of better performance, namely<br />
primus. Currently you need to run this program separately (it does not accept options<br />
unlike {{ic|optirun}}), but in the future it will be started by optirun. Usage:<br />
$ primusrun glxgears<br />
<br />
== Configuration ==<br />
<br />
You can configure the behaviour of Bumblebee to fit your needs. Fine tuning like speed optimization, power management and other stuff can be configured in {{ic|/etc/bumblebee/bumblebee.conf}}<br />
<br />
=== Optimizing speed when using VirtualGL as bridge ===<br />
<br />
Bumblebee renders frames for your Optimus NVIDIA card in an invisible X Server with VirtualGL and transports them back to your visible X Server.<br />
<br />
Frames will be compressed before they are transported - this saves bandwidth and can be used for speed-up optimization of bumblebee:<br />
<br />
To use an other compression method for a single application:<br />
<br />
$ optirun -c ''compress-method'' application<br />
<br />
The method of compres will affect performance in the GPU/GPU usage. Compressed methods (such as {{ic|jpeg}}) will load the CPU the most but will load GPU the minimum necessary; uncompressed methods loads the most on GPU and the CPU will have the minimum load possible.<br />
<br />
Compressed methods are: {{ic|jpeg}}, {{ic|rgb}}, {{ic|yuv}}.<br />
<br />
Uncompressed methods are: {{ic|proxy}}, {{ic|xv}}.<br />
<br />
To use a standard compression for all applications set the {{ic|VGLTransport}} to {{ic|''compress-method''}} in {{ic|/etc/bumblebee/bumblebee.conf}}:<br />
<br />
{{hc|/etc/bumblebee/bumblebee.conf|2=<br />
[...]<br />
[optirun]<br />
VGLTransport=proxy<br />
[...]<br />
}}<br />
<br />
You can also play with the way VirtualGL reads back the pixels from your graphic card. Setting {{ic|VGL_READBACK}} environment variable to {{ic|pbo}} should increase the performance. Compare these two:<br />
<br />
# PBO should be faster.<br />
VGL_READBACK=pbo optirun glxspheres<br />
# The default value is sync.<br />
VGL_READBACK=sync optirun glxspheres<br />
<br />
{{Note|CPU frequency scaling will affect directly on render performance}}<br />
<br />
=== Power management ===<br />
<br />
The goal of power management feature is to turn off the NVIDIA card when it is not used by bumblebee any more.<br />
If bbswitch is installed, it will be detected automatically when the Bumblebee daemon starts. No additional<br />
configuration is necessary.<br />
<br />
==== Default power state of NVIDIA card using bbswitch ====<br />
<br />
The default behavior of bbswitch is to leave the card power state unchanged. {{ic|bumblebeed}} does disable<br />
the card when started, so the following is only necessary if you use bbswitch without bumblebeed.<br />
<br />
Set {{ic|load_state}} and {{ic|unload_state}} module options according to your needs (see [https://github.com/Bumblebee-Project/bbswitch bbswitch documentation]).<br />
{{hc|/etc/modprobe.d/bbswitch.conf|2=<br />
options bbswitch load_state=0 unload_state=1<br />
}}<br />
<br />
==== Enable NVIDIA card during shutdown ====<br />
The NVIDIA card may not correctly initialize during boot if the card was powered off when the system was last shutdown. One option is to set {{ic|TurnCardOffAtExit&#61;false}} in {{ic|/etc/bumblebee/bumblebee.conf}}, however this will enable the card everytime you stop the Bumblebee daemon, even if done manually. To ensure that the NVIDIA card is always powered on during shutdown, add the following [[systemd]] service (if using {{pkg|bbswitch}}):<br />
<br />
{{hc|/etc/systemd/system/nvidia-enable.service|2=<br />
[Unit]<br />
Description=Enable NVIDIA card<br />
DefaultDependencies=no<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/bin/sh -c 'echo ON > /proc/acpi/bbswitch'<br />
<br />
[Install]<br />
WantedBy=shutdown.target<br />
}}<br />
<br />
Then enable the service by running {{ic|systemctl enable nvidia-enable.service}} at the root prompt.<br />
<br />
=== Multiple monitors ===<br />
<br />
==== Outputs wired to the Intel chip ====<br />
<br />
If the port (DisplayPort/HDMI/VGA) is wired to the Intel chip, you can set up multiple monitors with xorg.conf. Set them to use the Intel card, but Bumblebee can still use the NVIDIA card. One example configuration is below for two identical screens with 1080p resolution and using the HDMI out.<br />
<br />
{{hc|/etc/X11/xorg.conf|2=<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "intelgpu0"<br />
Monitor "Monitor0"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1980x1080_60.00"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen1"<br />
Device "intelgpu1"<br />
Monitor "Monitor1"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1980x1080_60.00"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor1"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "intelgpu0"<br />
Driver "intel"<br />
Option "XvMC" "true"<br />
Option "UseEvents" "true"<br />
Option "AccelMethod" "UXA"<br />
BusID "PCI:0:2:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "intelgpu1"<br />
Driver "intel"<br />
Option "XvMC" "true"<br />
Option "UseEvents" "true"<br />
Option "AccelMethod" "UXA"<br />
BusID "PCI:0:2:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidiagpu1"<br />
Driver "nvidia"<br />
BusID "PCI:0:1:0"<br />
EndSection<br />
<br />
}}<br />
<br />
You need to probably change the BusID for both the Intel and the NVIDIA card.<br />
<br />
{{hc|<nowiki>$ lspci | grep VGA</nowiki>|<br />
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)<br />
}}<br />
<br />
The BusID is 0:2:0<br />
<br />
==== Output wired to the NVIDIA chip ====<br />
<br />
On some notebooks, the digital Video Output (HDMI or DisplayPort) is hardwired to the NVIDIA chip. If you want to use all the displays on such a system simultaniously, you have to run 2 X Servers. The first will be using the Intel driver for the notebooks panel and a display connected on VGA. The second will be started through optirun on the NVIDIA card, and drives the digital display.<br />
<br />
There are currently several instructions on the web how such a setup can be made to work. One can be found on the bumblebee [https://github.com/Bumblebee-Project/Bumblebee/wiki/Multi-monitor-setup wiki page]. Another approach is described below.<br />
<br />
===== xf86-video-intel-virtual-crtc and hybrid-screenclone =====<br />
<br />
This method uses a patched Intel driver, which is extended to have a VIRTUAL Display, and the program hybrid-screenclone which is used to copy the display over from the virtual display to a second X Server which is running on the NVIDIA card using Optirun. Credit goes to [http://judsonsnotes.com/notes/index.php?option=com_content&view=article&id=673:triple-head-monitors-on-thinkpad-t520&catid=37:tech-notes&Itemid=59 Triple-head monitors on a Thinkpad T520] which has a detailed explanation on how this is done on a Ubuntu system.<br />
<br />
For simplicity, DP is used below to refer to the Digital Output (DisplayPort). The instructions should be the same if the notebook has a HDMI port instead.<br />
<br />
* Set system to use NVIDIA card exclusively, test DP/Monitor combination and generate xorg.nvidia.conf. This step is not required, but recommended if your system Bios has an option to switch the graphics into NVIDIA-only mode. To do this, first uninstall the bumblebee package and install just the NVIDIA driver. Then reboot, enter the Bios and switch the Graphics to NVIDIA-only. When back in Arch, connect you Monitor on DP and use startx to test if it is working in principle. Use Xorg -configure to generate an xorg.conf file for your NVIDIA card. This will come in handy further down below.<br />
<br />
* Reinstall bumlbebee and bbswitch, reboot and set the system Gfx back to Hybrid in the BIOS. <br />
* Install {{AUR|xf86-video-intel-virtual-crtc}}, and replace your xf86-video-intel package with it.<br />
* Install {{AUR|screenclone-git}}<br />
* Change these bumblebee.conf settings:<br />
{{hc|/etc/bumblebee/bumblebee.conf|2=<br />
KeepUnusedXServer=true<br />
Driver=nvidia<br />
}}<br />
{{Note|Leave the PMMethod set to "bumblebee". This is contrary to the instructions linked in the article above, but on arch this options needs to be left alone so that bbswitch module is automatically loaded}}<br />
* Copy the xorg.conf generated in Step 1 to {{ic|/etc/X11}} (e.g. {{ic|/etc/X11/xorg.nvidia.conf}}). In the [driver-nvidia] section of {{ic|bumblebee.conf}}, change {{ic|XorgConfFile}} to point to it.<br />
* Test if your {{ic|/etc/X11/xorg.nvidia.conf}} is working with {{ic|startx -- -config /etc/X11/xorg.nvidia.conf}}<br />
* In order for your DP Monitor to show up with the correct resolution in your VIRTUAL Display you might have to edit the Monitor section in your {{ic|/etc/xorg.nvidia.conf}}. Since this is extra work, you could try to continue with your auto-generated file. Come back to this step in the instructions if you find that the resolution of the VIRTUAL Display as shown by xrandr is not correct.<br />
** First you have to generate a Modeline. You can use the tool [http://amlc.berlios.de/ amlc], which will genearte a Modeline if you input a few basic parameters. <br />
<br />
::Example: 24" 1920x1080 Monitor<br />
::start the tool with {{ic|amlc -c}}<br />
{{bc|Monitor Identifier: Samsung 2494<br />
Aspect Ratio: 2<br />
physical size[cm]: 60<br />
Ideal refresh rate, in Hz: 60<br />
min HSync, kHz: 40<br />
max HSync, kHz: 90<br />
min VSync, Hz: 50<br />
max VSync, Hz: 70<br />
max pixel Clock, MHz: 400}}<br />
<br />
This is the Monitor section which {{ic|amlc}} generated for this input:<br />
{{bc|Section "Monitor"<br />
Identifier "Samsung 2494"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494}}<br />
<br />
Change your {{ic|xorg.nvidia.conf}} to include this Monitor section. You can also trim down your file so that it only contains ServerLayout, Monitor, Device and Screen sections. For reference, here is mine:<br />
{{hc|/etc/X11/xorg.nvidia.conf|<br />
Section "ServerLayout"<br />
Identifier "X.org Nvidia DP"<br />
Screen 0 "Screen0" 0 0<br />
InputDevice "Mouse0" "CorePointer"<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Samsung 2494"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494<br />
<br />
Section "Device"<br />
Identifier "DiscreteNvidia"<br />
Driver "nvidia"<br />
BusID "PCI:1:0:0"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "DiscreteNvidia"<br />
Monitor "Samsung 2494"<br />
SubSection "Display"<br />
Viewport 0 0<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
}}<br />
* Plug in both external monitors and startx. Look at your {{ic|/var/log/Xorg.0.log}}. Check that your VGA Monitor is detected with the correct Modes there. You should also see a VIRTUAL output with modes show up.<br />
* Run {{ic|xrandr}} and three displays should be listed there, along with the supported modes.<br />
* If the listed Modelines for your VIRTUAL display doesn't have your Monitors native resolution, make note of the exact output name. For me that is {{ic|VIRTUAL1}}. Then have a look again in the Xorg.0.log file. You should see a message: "Output VIRTUAL1 has no monitor section" there. We will change this by putting a file with the needed Monitor section into {{ic|/etc/X11/xorg.conf.d}}. Exit and Restart X afterward.<br />
{{hc|/etc/X11/xorg.conf.d/20-monitor_samsung.conf|<br />
Section "Monitor"<br />
Identifier "VIRTUAL1"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494<br />
}}<br />
* Turn the NVIDIA card on by running: {{ic|sudo tee /proc/acpi/bbswitch <<< ON}}<br />
* Start another X server for the DisplayPort monitor: {{ic|sudo optirun true}}<br />
* Check the log of the second X server in {{ic|/var/log/Xorg.8.log}}<br />
* Run xrandr to set up the VIRTUAL display to be the right size and placement, eg.: {{ic|xrandr --output VGA1 --auto --rotate normal --pos 0x0 --output VIRTUAL1 --mode 1920x1080 --right-of VGA1 --output LVDS1 --auto --rotate normal --right-of VIRTUAL1}}<br />
* Take note of the position of the VIRTUAL display in the list of Outputs as shown by xrandr. The counting starts from zero, i.e. if it is the third display shown, you would specify {{ic|-x 2}} as parameter to {{ic|screenclone}} (Note: This might not always be correct. If you see your internal laptop display cloned on the monitor, try {{ic|-x 2}} anyway.)<br />
* Clone the contents of the VIRTUAL display onto the X server created by bumblebee, which is connected to the DisplayPort monitor via the NVIDIA chip:<br />
: {{ic|screenclone -d :8 -x 2}}<br />
<br />
Thats it, all three displays should be up and running now.<br />
<br />
== Switch between discrete and integrated like Windows==<br />
<br />
In Windows, the way that Optimus works is NVIDIA has a whitelist of applications that require Optimus for, and you can add applications to this whitelist as needed. When you launch the application, it automatically decides which card to use.<br />
<br />
To mimic this behavior in Linux, you can use {{AUR|libgl-switcheroo-git}}. After installing, you can add the below in your .xprofile.<br />
<br />
{{hc|~/.xprofile|2=<br />
mkdir -p /tmp/libgl-switcheroo-$USER/fs<br />
gtkglswitch &<br />
libgl-switcheroo /tmp/libgl-switcheroo-$USER/fs &<br />
}}<br />
<br />
To enable this, you must add the below to the shell that you intend to launch applications from (I simply added it to the .xprofile file)<br />
export LD_LIBRARY_PATH=/tmp/libgl-switcheroo-$USER/fs/\$LIB${LD_LIBRARY_PATH+:}$LD_LIBRARY_PATH<br />
<br />
Once this has all been done, every application you launch from this shell will pop up a GTK+ window asking which card you want to run it with (you can also add an application to the whitelist in the configuration). The configuration is located in {{ic|$XDG_CONFIG_HOME/libgl-switcheroo.conf}}, usually {{ic|~/.config/libgl-switcheroo.conf}}<br />
<br />
== CUDA without Bumblebee==<br />
<br />
This is not well documented, but you do not need Bumblebee to use CUDA and it may work even on machines where optirun fails. For a guide on how to get it working with the Lenovo IdeaPad Y580 (which uses the GeForce 660M), see: https://wiki.archlinux.org/index.php/Lenovo_IdeaPad_Y580#NVIDIA_Card. Those instructions are very likely to work with other machines.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Note|Please report bugs at [https://github.com/Bumblebee-Project/Bumblebee Bumblebee-Project]'s GitHub tracker as described in its [https://github.com/Bumblebee-Project/Bumblebee/wiki/Reporting-Issues wiki].}}<br />
<br />
=== [VGL] ERROR: Could not open display :8 ===<br />
<br />
There is a known problem with some wine applications that fork and kill the parent process without keeping track of it (for example the free to play online game "Runes of Magic")<br />
<br />
This is a known problem with VirtualGL. As of bumblebee 3.1, so long as you have it installed, you can use Primus as your render bridge:<br />
<br />
$ optirun -b primus wine ''windows program''.exe<br />
<br />
If this does not work, an alternative walkaround for this problem is:<br />
<br />
$ optirun bash<br />
$ optirun wine ''windows program''.exe<br />
<br />
If using NVIDIA drivers a fix for this problem is to edit {{ic|/etc/bumblebee/xorg.conf.nvidia}} and change Option {{ic|ConnectedMonitor}} to {{ic|CRT-0}}.<br />
<br />
=== [ERROR]Cannot access secondary GPU: No devices detected ===<br />
<br />
In some instances, running optirun will return:<br />
<br />
[ERROR]Cannot access secondary GPU - error: [XORG] (EE) No devices detected.<br />
[ERROR]Aborting because fallback start is disabled.<br />
<br />
In this case, you will need to move the file {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} to somewhere else. Restart the bumblebeed daemon, and it should work. If you do need to change some features on Intel module, a workaround is to move your {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} to {{ic|/etc/X11/xorg.conf}}.<br />
<br />
It could be also necessary to comment the driver line in {{ic|/etc/X11/xorg.conf.d/10-monitor.conf}}.<br />
<br />
If you're using the nouveau driver you could try switching to the nVidia driver.<br />
<br />
You might need to define the NVIDIA card somewhere (e.g. file {{ic|/etc/X11/xorg.conf.d}}), and remember to change the BusID using lspci.<br />
<br />
{{bc|<br />
Section "Device"<br />
Identifier "nvidiagpu1"<br />
Driver "nvidia"<br />
BusID "PCI:0:1:0"<br />
EndSection<br />
}}<br />
<br />
==== NVIDIA(0): Failed to assign any connected display devices to X screen 0 ====<br />
<br />
If the console output is:<br />
<br />
[ERROR]Cannot access secondary GPU - error: [XORG] (EE) NVIDIA(0): Failed to assign any connected display devices to X screen 0<br />
[ERROR]Aborting because fallback start is disabled.<br />
<br />
<br />
You can change this line in {{ic|/etc/bumblebee/xorg.conf.nvidia}}:<br />
<br />
Option "ConnectedMonitor" "DFP"<br />
<br />
to:<br />
<br />
Option "ConnectedMonitor" "CRT"<br />
<br />
==== Could not load GPU driver ====<br />
<br />
If the console output is:<br />
<br />
[ERROR]Cannot access secondary GPU - error: Could not load GPU driver<br />
<br />
and if you try to load the nvidia module you get:<br />
<br />
modprobe nvidia<br />
modprobe: ERROR: could not insert 'nvidia': Exec format error<br />
<br />
You should try manually compiling the nvidia packages against your current kernel, for example with {{aur|nvidia-dkms}} or by compiling {{pkg|nvidia}} from the [[ABS]].<br />
<br />
==== Failed to initialize the NVIDIA GPU at PCI:1:0:0 (GPU fallen off the bus / RmInitAdapter failed!) ====<br />
<br />
Add {{ic|1=rcutree.rcu_idle_gp_delay=1}} to the kernel parameters. Original topic can be found [https://bbs.archlinux.org/viewtopic.php?id=169742 here].<br />
<br />
==== NOUVEAU(0): [drm] failed to set drm interface version ====<br />
<br />
Consider switching to the official nvidia driver. As commented [https://github.com/Bumblebee-Project/Bumblebee/issues/438#issuecomment-22005923 here], nouveau driver has some issues with some cards and bumblebee.<br />
<br />
=== ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored ===<br />
<br />
You probably want to start a 32-bit application with bumblebee on a 64-bit system. See the "Note" box in [[#Installation|Installation]].<br />
<br />
=== Fatal IO error 11 (Resource temporarily unavailable) on X server ===<br />
<br />
Change {{ic|KeepUnusedXServer}} in {{ic|/etc/bumblebee/bumblebee.conf}} from {{ic|false}} to {{ic|true}}. Your program forks into background and bumblebee don't know anything about it.<br />
<br />
=== Video tearing ===<br />
<br />
Video tearing is a somewhat common problem on Bumblebee. To fix it, you need to enable vsync. It should be enabled by default on the Intel card, but verify that from Xorg logs. To check whether or not it is enabled for NVIDIA, run: <br />
<br />
$ optirun nvidia-settings -c :8<br />
<br />
{{ic|1=X Server XVideo Settings -> Sync to VBlank}} and {{ic|1=OpenGL Settings -> Sync to VBlank}} should both be enabled. The Intel card has in general less tearing, so use it for video playback. Especially use VA-API for video decoding (e.g. {{ic|mplayer-vaapi}} and with {{ic|-vsync}} parameter).<br />
<br />
Refer to the [[Intel#Video_tearing|Intel]] article on how to fix tearing on the Intel card.<br />
<br />
If it is still not fixed, try to disable compositing from your desktop environment. Try also disabling triple buffering.<br />
<br />
=== Bumblebee cannot connect to socket ===<br />
<br />
You might get something like:<br />
<br />
{{hc|$ optirun glxspheres|<br />
[ 1648.179533] [ERROR]You've no permission to communicate with the Bumblebee daemon. Try adding yourself to the 'bumblebee' group<br />
[ 1648.179628] [ERROR]Could not connect to bumblebee daemon - is it running?<br />
}}<br />
<br />
If you are already in the {{ic|bumblebee}} group ({{ic|<nowiki>$ groups | grep bumblebee</nowiki>}}), you may try [https://bbs.archlinux.org/viewtopic.php?pid=1178729#p1178729 removing the socket] {{ic|/var/run/bumblebeed.socket}}.<br />
<br />
=== Running X.org from console after login (rootless X.org) ===<br />
<br />
See [[Xorg#Rootless_Xorg_.28v1.16.29]].<br />
<br />
== See also ==<br />
<br />
* [http://www.bumblebee-project.org Bumblebee project repository]<br />
* [http://wiki.bumblebee-project.org/ Bumblebee project wiki]<br />
* [https://github.com/Bumblebee-Project/bbswitch Bumblebee project bbswitch repository]<br />
<br />
Join us at #bumblebee at freenode.net.</div>Ndthttps://wiki.archlinux.org/index.php?title=Bumblebee&diff=330846Bumblebee2014-08-18T02:48:22Z<p>Ndt: /* [ERROR]Cannot access secondary GPU */ combine empty section about the same error message</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X Server]]<br />
[[es:Bumblebee]]<br />
[[fr:Bumblebee]]<br />
[[it:Bumblebee]]<br />
[[ru:Bumblebee]]<br />
[[tr:Bumblebee]]<br />
[[zh-CN:Bumblebee]]<br />
{{Related articles start}}<br />
{{Related|NVIDIA Optimus}}<br />
{{Related|Nouveau}}<br />
{{Related|NVIDIA}}<br />
{{Related|Intel graphics}}<br />
{{Related articles end}}<br />
From Bumblebee's [https://github.com/Bumblebee-Project/Bumblebee/wiki/FAQ FAQ]:<br />
<br />
"''Bumblebee is an effort to make NVIDIA Optimus enabled laptops work in GNU/Linux systems. Such feature involves two graphics cards with two different power consumption profiles plugged in a layered way sharing a single framebuffer.''"<br />
<br />
== Bumblebee: Optimus for Linux ==<br />
<br />
[http://www.nvidia.com/object/optimus_technology.html Optimus Technology] is an ''[http://hybrid-graphics-linux.tuxfamily.org/index.php?title=Hybrid_graphics hybrid graphics]'' implementation without a hardware multiplexer. The integrated GPU manages the display while the dedicated GPU manages the most demanding rendering and ships the work to the integrated GPU to be displayed. When the laptop is running on battery supply, the dedicated GPU is turned off to save power and prolong the battery life. It has also been tested successfully with desktop machines with Intel integrated graphics and an nVidia dedicated graphics card. <br />
<br />
Bumblebee is a software implementation comprising of two parts:<br />
<br />
* Render programs off-screen on the dedicated video card and display it on the screen using the integrated video card. This bridge is provided by VirtualGL or primus (read further) and connects to a X server started for the discrete video card.<br />
* Disable the dedicated video card when it is not in use (see the [[#Power Management|Power management]] section)<br />
<br />
It tries to mimic the Optimus technology behavior; using the dedicated GPU for rendering when needed and power it down when not in use. The present releases only support rendering on-demand, automatically starting a program with the discrete video card based on workload is not implemented.<br />
<br />
== Installation ==<br />
<br />
Before installing Bumblebee check your BIOS and activate Optimus (older laptops call it "switchable graphics") if possible (BIOS doesn't have to provide this option), and install the [[Intel graphics|Intel driver]] for the secondary on board graphics card.<br />
<br />
Several packages are available for a complete setup:<br />
<br />
* {{Pkg|bumblebee}} - The main package providing the daemon and client programs.<br />
* (optional) {{Pkg|bbswitch}} (or {{AUR|bbswitch-dkms}}) - Recommended for saving power by disable the NVIDIA card.<br />
* (optional) If you want more than just saving power, that is rendering programs on the discrete NVDIA card you also need:<br />
** a driver for the NVIDIA card. The open-source [[nouveau]] driver or the more closed-source [[NVIDIA]] driver. See the subsection.<br />
** a render/display bridge. Two packages are currently available for that, {{Pkg|primus}} (or {{AUR|primus-git}}) and {{Pkg|virtualgl}}. Only one of them is necessary, but installing them side-by-side does not hurt.<br />
<br />
{{Note|If you want to run a 32-bit application on a 64-bit system you must install the proper lib32-* libraries for the program. In addition to this, you also need to install {{Pkg|lib32-virtualgl}} or {{Pkg|lib32-primus}}, depending on your choice for the render bridge. Just make sure you run {{ic|primusrun}} instead of {{ic|optirun}} if you decide to use Primus render bridge.}}<br />
<br />
=== Installing Bumblebee with Intel/NVIDIA ===<br />
<br />
Install {{Pkg|intel-dri}}, {{Pkg|xf86-video-intel}}, {{Pkg|bumblebee}} and {{Pkg|nvidia}}. If you have {{Pkg|intel-dri}} and {{Pkg|xf86-video-intel}} installed, you will have to reinstall them together with the rest to avoid a dependency conflict between {{Pkg|intel-dri}} and {{Pkg|nvidia}}. <br />
<br />
If you want to run 32-bit applications (like games with wine) on a 64-bit system you need the {{Pkg|lib32-nvidia-utils}} (and {{Pkg|lib32-intel-dri}} if you intend to use {{ic|primusrun}}) package too.<br />
<br />
{{Warning|Do not install {{pkg|lib32-nvidia-libgl}}. Bumblebee will find the correct lib32 NVIDIA libraries without it.}}<br />
<br />
=== Installing Bumblebee with Intel/Nouveau ===<br />
<br />
Install:<br />
* {{Pkg|xf86-video-nouveau}} - experimental 3D acceleration driver.<br />
* {{Pkg|nouveau-dri}} - Mesa classic DRI + Gallium3D drivers.<br />
* {{Pkg|mesa}} - Mesa 3D graphics libraries.<br />
<br />
== Start Bumblebee ==<br />
<br />
In order to use Bumblebee it is necessary add yourself (and other users) to the bumblebee group:<br />
<br />
# gpasswd -a $USER bumblebee<br />
<br />
where {{ic|$USER}} is the login name of the user to be added. Then log off and on again to apply the group changes.<br />
<br />
{{Tip|If you wish '''bumblebee''' to start at boot, you have to enable [[systemd]] service '''bumblebeed'''.}}<br />
<br />
Finished. Reboot system and use the shell program {{ic|[[#Usage|optirun]]}} for Optimus NVIDIA rendering!<br />
<br />
If you simply wish to disable your NVIDIA card, this should be all that is needed, apart from having {{ic|bbswitch}} installed. The bumblebeed daemon will, by default, instruct bbswitch to turn off the card when it starts. See also the [[#Power management|power management]] section below.<br />
<br />
== Usage ==<br />
<br />
The command line program {{ic|optirun}} shipped with Bumblebee is your best friend<br />
for running applications on your Optimus NVIDIA card.<br />
<br />
Test Bumblebee if it works with your Optimus system:<br />
$ optirun glxgears -info<br />
<br />
If it succeeds and the terminal you are running from mentions something about your NVIDIA - Optimus with Bumblebee is working!<br />
<br />
General usage:<br />
<br />
$ optirun [options] ''application'' [application-parameters]<br />
<br />
Some Examples:<br />
<br />
Start Windows applications with Optimus:<br />
<br />
$ optirun wine ''windows application''.exe<br />
<br />
Use NVIDIA Settings with Optimus:<br />
<br />
$ optirun -b none nvidia-settings -c :8<br />
<br />
For a list of options for {{ic|optirun}} view its manual page.<br />
<br />
A new program is soon becoming the default choice because of better performance, namely<br />
primus. Currently you need to run this program separately (it does not accept options<br />
unlike {{ic|optirun}}), but in the future it will be started by optirun. Usage:<br />
$ primusrun glxgears<br />
<br />
== Configuration ==<br />
<br />
You can configure the behaviour of Bumblebee to fit your needs. Fine tuning like speed optimization, power management and other stuff can be configured in {{ic|/etc/bumblebee/bumblebee.conf}}<br />
<br />
=== Optimizing speed when using VirtualGL as bridge ===<br />
<br />
Bumblebee renders frames for your Optimus NVIDIA card in an invisible X Server with VirtualGL and transports them back to your visible X Server.<br />
<br />
Frames will be compressed before they are transported - this saves bandwidth and can be used for speed-up optimization of bumblebee:<br />
<br />
To use an other compression method for a single application:<br />
<br />
$ optirun -c ''compress-method'' application<br />
<br />
The method of compres will affect performance in the GPU/GPU usage. Compressed methods (such as {{ic|jpeg}}) will load the CPU the most but will load GPU the minimum necessary; uncompressed methods loads the most on GPU and the CPU will have the minimum load possible.<br />
<br />
Compressed methods are: {{ic|jpeg}}, {{ic|rgb}}, {{ic|yuv}}.<br />
<br />
Uncompressed methods are: {{ic|proxy}}, {{ic|xv}}.<br />
<br />
To use a standard compression for all applications set the {{ic|VGLTransport}} to {{ic|''compress-method''}} in {{ic|/etc/bumblebee/bumblebee.conf}}:<br />
<br />
{{hc|/etc/bumblebee/bumblebee.conf|2=<br />
[...]<br />
[optirun]<br />
VGLTransport=proxy<br />
[...]<br />
}}<br />
<br />
You can also play with the way VirtualGL reads back the pixels from your graphic card. Setting {{ic|VGL_READBACK}} environment variable to {{ic|pbo}} should increase the performance. Compare these two:<br />
<br />
# PBO should be faster.<br />
VGL_READBACK=pbo optirun glxspheres<br />
# The default value is sync.<br />
VGL_READBACK=sync optirun glxspheres<br />
<br />
{{Note|CPU frequency scaling will affect directly on render performance}}<br />
<br />
=== Power management ===<br />
<br />
The goal of power management feature is to turn off the NVIDIA card when it is not used by bumblebee any more.<br />
If bbswitch is installed, it will be detected automatically when the Bumblebee daemon starts. No additional<br />
configuration is necessary.<br />
<br />
==== Default power state of NVIDIA card using bbswitch ====<br />
<br />
The default behavior of bbswitch is to leave the card power state unchanged. {{ic|bumblebeed}} does disable<br />
the card when started, so the following is only necessary if you use bbswitch without bumblebeed.<br />
<br />
Set {{ic|load_state}} and {{ic|unload_state}} module options according to your needs (see [https://github.com/Bumblebee-Project/bbswitch bbswitch documentation]).<br />
{{hc|/etc/modprobe.d/bbswitch.conf|2=<br />
options bbswitch load_state=0 unload_state=1<br />
}}<br />
<br />
==== Enable NVIDIA card during shutdown ====<br />
The NVIDIA card may not correctly initialize during boot if the card was powered off when the system was last shutdown. One option is to set {{ic|TurnCardOffAtExit&#61;false}} in {{ic|/etc/bumblebee/bumblebee.conf}}, however this will enable the card everytime you stop the Bumblebee daemon, even if done manually. To ensure that the NVIDIA card is always powered on during shutdown, add the following [[systemd]] service (if using {{pkg|bbswitch}}):<br />
<br />
{{hc|/etc/systemd/system/nvidia-enable.service|2=<br />
[Unit]<br />
Description=Enable NVIDIA card<br />
DefaultDependencies=no<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/bin/sh -c 'echo ON > /proc/acpi/bbswitch'<br />
<br />
[Install]<br />
WantedBy=shutdown.target<br />
}}<br />
<br />
Then enable the service by running {{ic|systemctl enable nvidia-enable.service}} at the root prompt.<br />
<br />
=== Multiple monitors ===<br />
<br />
==== Outputs wired to the Intel chip ====<br />
<br />
If the port (DisplayPort/HDMI/VGA) is wired to the Intel chip, you can set up multiple monitors with xorg.conf. Set them to use the Intel card, but Bumblebee can still use the NVIDIA card. One example configuration is below for two identical screens with 1080p resolution and using the HDMI out.<br />
<br />
{{hc|/etc/X11/xorg.conf|2=<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "intelgpu0"<br />
Monitor "Monitor0"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1980x1080_60.00"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen1"<br />
Device "intelgpu1"<br />
Monitor "Monitor1"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1980x1080_60.00"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor1"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "intelgpu0"<br />
Driver "intel"<br />
Option "XvMC" "true"<br />
Option "UseEvents" "true"<br />
Option "AccelMethod" "UXA"<br />
BusID "PCI:0:2:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "intelgpu1"<br />
Driver "intel"<br />
Option "XvMC" "true"<br />
Option "UseEvents" "true"<br />
Option "AccelMethod" "UXA"<br />
BusID "PCI:0:2:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidiagpu1"<br />
Driver "nvidia"<br />
BusID "PCI:0:1:0"<br />
EndSection<br />
<br />
}}<br />
<br />
You need to probably change the BusID for both the Intel and the NVIDIA card.<br />
<br />
{{hc|<nowiki>$ lspci | grep VGA</nowiki>|<br />
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)<br />
}}<br />
<br />
The BusID is 0:2:0<br />
<br />
==== Output wired to the NVIDIA chip ====<br />
<br />
On some notebooks, the digital Video Output (HDMI or DisplayPort) is hardwired to the NVIDIA chip. If you want to use all the displays on such a system simultaniously, you have to run 2 X Servers. The first will be using the Intel driver for the notebooks panel and a display connected on VGA. The second will be started through optirun on the NVIDIA card, and drives the digital display.<br />
<br />
There are currently several instructions on the web how such a setup can be made to work. One can be found on the bumblebee [https://github.com/Bumblebee-Project/Bumblebee/wiki/Multi-monitor-setup wiki page]. Another approach is described below.<br />
<br />
===== xf86-video-intel-virtual-crtc and hybrid-screenclone =====<br />
<br />
This method uses a patched Intel driver, which is extended to have a VIRTUAL Display, and the program hybrid-screenclone which is used to copy the display over from the virtual display to a second X Server which is running on the NVIDIA card using Optirun. Credit goes to [http://judsonsnotes.com/notes/index.php?option=com_content&view=article&id=673:triple-head-monitors-on-thinkpad-t520&catid=37:tech-notes&Itemid=59 Triple-head monitors on a Thinkpad T520] which has a detailed explanation on how this is done on a Ubuntu system.<br />
<br />
For simplicity, DP is used below to refer to the Digital Output (DisplayPort). The instructions should be the same if the notebook has a HDMI port instead.<br />
<br />
* Set system to use NVIDIA card exclusively, test DP/Monitor combination and generate xorg.nvidia.conf. This step is not required, but recommended if your system Bios has an option to switch the graphics into NVIDIA-only mode. To do this, first uninstall the bumblebee package and install just the NVIDIA driver. Then reboot, enter the Bios and switch the Graphics to NVIDIA-only. When back in Arch, connect you Monitor on DP and use startx to test if it is working in principle. Use Xorg -configure to generate an xorg.conf file for your NVIDIA card. This will come in handy further down below.<br />
<br />
* Reinstall bumlbebee and bbswitch, reboot and set the system Gfx back to Hybrid in the BIOS. <br />
* Install {{AUR|xf86-video-intel-virtual-crtc}}, and replace your xf86-video-intel package with it.<br />
* Install {{AUR|screenclone-git}}<br />
* Change these bumblebee.conf settings:<br />
{{hc|/etc/bumblebee/bumblebee.conf|2=<br />
KeepUnusedXServer=true<br />
Driver=nvidia<br />
}}<br />
{{Note|Leave the PMMethod set to "bumblebee". This is contrary to the instructions linked in the article above, but on arch this options needs to be left alone so that bbswitch module is automatically loaded}}<br />
* Copy the xorg.conf generated in Step 1 to {{ic|/etc/X11}} (e.g. {{ic|/etc/X11/xorg.nvidia.conf}}). In the [driver-nvidia] section of {{ic|bumblebee.conf}}, change {{ic|XorgConfFile}} to point to it.<br />
* Test if your {{ic|/etc/X11/xorg.nvidia.conf}} is working with {{ic|startx -- -config /etc/X11/xorg.nvidia.conf}}<br />
* In order for your DP Monitor to show up with the correct resolution in your VIRTUAL Display you might have to edit the Monitor section in your {{ic|/etc/xorg.nvidia.conf}}. Since this is extra work, you could try to continue with your auto-generated file. Come back to this step in the instructions if you find that the resolution of the VIRTUAL Display as shown by xrandr is not correct.<br />
** First you have to generate a Modeline. You can use the tool [http://amlc.berlios.de/ amlc], which will genearte a Modeline if you input a few basic parameters. <br />
<br />
::Example: 24" 1920x1080 Monitor<br />
::start the tool with {{ic|amlc -c}}<br />
{{bc|Monitor Identifier: Samsung 2494<br />
Aspect Ratio: 2<br />
physical size[cm]: 60<br />
Ideal refresh rate, in Hz: 60<br />
min HSync, kHz: 40<br />
max HSync, kHz: 90<br />
min VSync, Hz: 50<br />
max VSync, Hz: 70<br />
max pixel Clock, MHz: 400}}<br />
<br />
This is the Monitor section which {{ic|amlc}} generated for this input:<br />
{{bc|Section "Monitor"<br />
Identifier "Samsung 2494"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494}}<br />
<br />
Change your {{ic|xorg.nvidia.conf}} to include this Monitor section. You can also trim down your file so that it only contains ServerLayout, Monitor, Device and Screen sections. For reference, here is mine:<br />
{{hc|/etc/X11/xorg.nvidia.conf|<br />
Section "ServerLayout"<br />
Identifier "X.org Nvidia DP"<br />
Screen 0 "Screen0" 0 0<br />
InputDevice "Mouse0" "CorePointer"<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Samsung 2494"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494<br />
<br />
Section "Device"<br />
Identifier "DiscreteNvidia"<br />
Driver "nvidia"<br />
BusID "PCI:1:0:0"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "DiscreteNvidia"<br />
Monitor "Samsung 2494"<br />
SubSection "Display"<br />
Viewport 0 0<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
}}<br />
* Plug in both external monitors and startx. Look at your {{ic|/var/log/Xorg.0.log}}. Check that your VGA Monitor is detected with the correct Modes there. You should also see a VIRTUAL output with modes show up.<br />
* Run {{ic|xrandr}} and three displays should be listed there, along with the supported modes.<br />
* If the listed Modelines for your VIRTUAL display doesn't have your Monitors native resolution, make note of the exact output name. For me that is {{ic|VIRTUAL1}}. Then have a look again in the Xorg.0.log file. You should see a message: "Output VIRTUAL1 has no monitor section" there. We will change this by putting a file with the needed Monitor section into {{ic|/etc/X11/xorg.conf.d}}. Exit and Restart X afterward.<br />
{{hc|/etc/X11/xorg.conf.d/20-monitor_samsung.conf|<br />
Section "Monitor"<br />
Identifier "VIRTUAL1"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494<br />
}}<br />
* Turn the NVIDIA card on by running: {{ic|sudo tee /proc/acpi/bbswitch <<< ON}}<br />
* Start another X server for the DisplayPort monitor: {{ic|sudo optirun true}}<br />
* Check the log of the second X server in {{ic|/var/log/Xorg.8.log}}<br />
* Run xrandr to set up the VIRTUAL display to be the right size and placement, eg.: {{ic|xrandr --output VGA1 --auto --rotate normal --pos 0x0 --output VIRTUAL1 --mode 1920x1080 --right-of VGA1 --output LVDS1 --auto --rotate normal --right-of VIRTUAL1}}<br />
* Take note of the position of the VIRTUAL display in the list of Outputs as shown by xrandr. The counting starts from zero, i.e. if it is the third display shown, you would specify {{ic|-x 2}} as parameter to {{ic|screenclone}} (Note: This might not always be correct. If you see your internal laptop display cloned on the monitor, try {{ic|-x 2}} anyway.)<br />
* Clone the contents of the VIRTUAL display onto the X server created by bumblebee, which is connected to the DisplayPort monitor via the NVIDIA chip:<br />
: {{ic|screenclone -d :8 -x 2}}<br />
<br />
Thats it, all three displays should be up and running now.<br />
<br />
== Switch between discrete and integrated like Windows==<br />
<br />
In Windows, the way that Optimus works is NVIDIA has a whitelist of applications that require Optimus for, and you can add applications to this whitelist as needed. When you launch the application, it automatically decides which card to use.<br />
<br />
To mimic this behavior in Linux, you can use {{AUR|libgl-switcheroo-git}}. After installing, you can add the below in your .xprofile.<br />
<br />
{{hc|~/.xprofile|2=<br />
mkdir -p /tmp/libgl-switcheroo-$USER/fs<br />
gtkglswitch &<br />
libgl-switcheroo /tmp/libgl-switcheroo-$USER/fs &<br />
}}<br />
<br />
To enable this, you must add the below to the shell that you intend to launch applications from (I simply added it to the .xprofile file)<br />
export LD_LIBRARY_PATH=/tmp/libgl-switcheroo-$USER/fs/\$LIB${LD_LIBRARY_PATH+:}$LD_LIBRARY_PATH<br />
<br />
Once this has all been done, every application you launch from this shell will pop up a GTK+ window asking which card you want to run it with (you can also add an application to the whitelist in the configuration). The configuration is located in {{ic|$XDG_CONFIG_HOME/libgl-switcheroo.conf}}, usually {{ic|~/.config/libgl-switcheroo.conf}}<br />
<br />
== CUDA without Bumblebee==<br />
<br />
This is not well documented, but you do not need Bumblebee to use CUDA and it may work even on machines where optirun fails. For a guide on how to get it working with the Lenovo IdeaPad Y580 (which uses the GeForce 660M), see: https://wiki.archlinux.org/index.php/Lenovo_IdeaPad_Y580#NVIDIA_Card. Those instructions are very likely to work with other machines.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Note|Please report bugs at [https://github.com/Bumblebee-Project/Bumblebee Bumblebee-Project]'s GitHub tracker as described in its [https://github.com/Bumblebee-Project/Bumblebee/wiki/Reporting-Issues wiki].}}<br />
<br />
=== [VGL] ERROR: Could not open display :8 ===<br />
<br />
There is a known problem with some wine applications that fork and kill the parent process without keeping track of it (for example the free to play online game "Runes of Magic")<br />
<br />
This is a known problem with VirtualGL. As of bumblebee 3.1, so long as you have it installed, you can use Primus as your render bridge:<br />
<br />
$ optirun -b primus wine ''windows program''.exe<br />
<br />
If this does not work, an alternative walkaround for this problem is:<br />
<br />
$ optirun bash<br />
$ optirun wine ''windows program''.exe<br />
<br />
If using NVIDIA drivers a fix for this problem is to edit {{ic|/etc/bumblebee/xorg.conf.nvidia}} and change Option {{ic|ConnectedMonitor}} to {{ic|CRT-0}}.<br />
<br />
=== [ERROR]Cannot access secondary GPU: No devices detected ====<br />
<br />
In some instances, running optirun will return:<br />
<br />
[ERROR]Cannot access secondary GPU - error: [XORG] (EE) No devices detected.<br />
[ERROR]Aborting because fallback start is disabled.<br />
<br />
In this case, you will need to move the file {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} to somewhere else. Restart the bumblebeed daemon, and it should work. If you do need to change some features on Intel module, a workaround is to move your {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} to {{ic|/etc/X11/xorg.conf}}.<br />
<br />
It could be also necessary to comment the driver line in {{ic|/etc/X11/xorg.conf.d/10-monitor.conf}}.<br />
<br />
If you're using the nouveau driver you could try switching to the nVidia driver.<br />
<br />
You might need to define the NVIDIA card somewhere (e.g. file {{ic|/etc/X11/xorg.conf.d}}), and remember to change the BusID using lspci.<br />
<br />
{{bc|<br />
Section "Device"<br />
Identifier "nvidiagpu1"<br />
Driver "nvidia"<br />
BusID "PCI:0:1:0"<br />
EndSection<br />
}}<br />
<br />
==== NVIDIA(0): Failed to assign any connected display devices to X screen 0 ====<br />
<br />
If the console output is:<br />
<br />
[ERROR]Cannot access secondary GPU - error: [XORG] (EE) NVIDIA(0): Failed to assign any connected display devices to X screen 0<br />
[ERROR]Aborting because fallback start is disabled.<br />
<br />
<br />
You can change this line in {{ic|/etc/bumblebee/xorg.conf.nvidia}}:<br />
<br />
Option "ConnectedMonitor" "DFP"<br />
<br />
to:<br />
<br />
Option "ConnectedMonitor" "CRT"<br />
<br />
==== Could not load GPU driver ====<br />
<br />
If the console output is:<br />
<br />
[ERROR]Cannot access secondary GPU - error: Could not load GPU driver<br />
<br />
and if you try to load the nvidia module you get:<br />
<br />
modprobe nvidia<br />
modprobe: ERROR: could not insert 'nvidia': Exec format error<br />
<br />
You should try manually compiling the nvidia packages against your current kernel, for example with {{aur|nvidia-dkms}} or by compiling {{pkg|nvidia}} from the [[ABS]].<br />
<br />
==== Failed to initialize the NVIDIA GPU at PCI:1:0:0 (GPU fallen off the bus / RmInitAdapter failed!) ====<br />
<br />
Add {{ic|1=rcutree.rcu_idle_gp_delay=1}} to the kernel parameters. Original topic can be found [https://bbs.archlinux.org/viewtopic.php?id=169742 here].<br />
<br />
==== NOUVEAU(0): [drm] failed to set drm interface version ====<br />
<br />
Consider switching to the official nvidia driver. As commented [https://github.com/Bumblebee-Project/Bumblebee/issues/438#issuecomment-22005923 here], nouveau driver has some issues with some cards and bumblebee.<br />
<br />
=== ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored ===<br />
<br />
You probably want to start a 32-bit application with bumblebee on a 64-bit system. See the "Note" box in [[#Installation|Installation]].<br />
<br />
=== Fatal IO error 11 (Resource temporarily unavailable) on X server ===<br />
<br />
Change {{ic|KeepUnusedXServer}} in {{ic|/etc/bumblebee/bumblebee.conf}} from {{ic|false}} to {{ic|true}}. Your program forks into background and bumblebee don't know anything about it.<br />
<br />
=== Video tearing ===<br />
<br />
Video tearing is a somewhat common problem on Bumblebee. To fix it, you need to enable vsync. It should be enabled by default on the Intel card, but verify that from Xorg logs. To check whether or not it is enabled for NVIDIA, run: <br />
<br />
$ optirun nvidia-settings -c :8<br />
<br />
{{ic|1=X Server XVideo Settings -> Sync to VBlank}} and {{ic|1=OpenGL Settings -> Sync to VBlank}} should both be enabled. The Intel card has in general less tearing, so use it for video playback. Especially use VA-API for video decoding (e.g. {{ic|mplayer-vaapi}} and with {{ic|-vsync}} parameter).<br />
<br />
Refer to the [[Intel#Video_tearing|Intel]] article on how to fix tearing on the Intel card.<br />
<br />
If it is still not fixed, try to disable compositing from your desktop environment. Try also disabling triple buffering.<br />
<br />
=== Bumblebee cannot connect to socket ===<br />
<br />
You might get something like:<br />
<br />
{{hc|$ optirun glxspheres|<br />
[ 1648.179533] [ERROR]You've no permission to communicate with the Bumblebee daemon. Try adding yourself to the 'bumblebee' group<br />
[ 1648.179628] [ERROR]Could not connect to bumblebee daemon - is it running?<br />
}}<br />
<br />
If you are already in the {{ic|bumblebee}} group ({{ic|<nowiki>$ groups | grep bumblebee</nowiki>}}), you may try [https://bbs.archlinux.org/viewtopic.php?pid=1178729#p1178729 removing the socket] {{ic|/var/run/bumblebeed.socket}}.<br />
<br />
=== Running X.org from console after login (rootless X.org) ===<br />
<br />
See [[Xorg#Rootless_Xorg_.28v1.16.29]].<br />
<br />
== See also ==<br />
<br />
* [http://www.bumblebee-project.org Bumblebee project repository]<br />
* [http://wiki.bumblebee-project.org/ Bumblebee project wiki]<br />
* [https://github.com/Bumblebee-Project/bbswitch Bumblebee project bbswitch repository]<br />
<br />
Join us at #bumblebee at freenode.net.</div>Ndthttps://wiki.archlinux.org/index.php?title=Bumblebee&diff=330845Bumblebee2014-08-18T02:47:22Z<p>Ndt: /* Could not load GPU driver */ better recommendations for compiling against current kernel</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X Server]]<br />
[[es:Bumblebee]]<br />
[[fr:Bumblebee]]<br />
[[it:Bumblebee]]<br />
[[ru:Bumblebee]]<br />
[[tr:Bumblebee]]<br />
[[zh-CN:Bumblebee]]<br />
{{Related articles start}}<br />
{{Related|NVIDIA Optimus}}<br />
{{Related|Nouveau}}<br />
{{Related|NVIDIA}}<br />
{{Related|Intel graphics}}<br />
{{Related articles end}}<br />
From Bumblebee's [https://github.com/Bumblebee-Project/Bumblebee/wiki/FAQ FAQ]:<br />
<br />
"''Bumblebee is an effort to make NVIDIA Optimus enabled laptops work in GNU/Linux systems. Such feature involves two graphics cards with two different power consumption profiles plugged in a layered way sharing a single framebuffer.''"<br />
<br />
== Bumblebee: Optimus for Linux ==<br />
<br />
[http://www.nvidia.com/object/optimus_technology.html Optimus Technology] is an ''[http://hybrid-graphics-linux.tuxfamily.org/index.php?title=Hybrid_graphics hybrid graphics]'' implementation without a hardware multiplexer. The integrated GPU manages the display while the dedicated GPU manages the most demanding rendering and ships the work to the integrated GPU to be displayed. When the laptop is running on battery supply, the dedicated GPU is turned off to save power and prolong the battery life. It has also been tested successfully with desktop machines with Intel integrated graphics and an nVidia dedicated graphics card. <br />
<br />
Bumblebee is a software implementation comprising of two parts:<br />
<br />
* Render programs off-screen on the dedicated video card and display it on the screen using the integrated video card. This bridge is provided by VirtualGL or primus (read further) and connects to a X server started for the discrete video card.<br />
* Disable the dedicated video card when it is not in use (see the [[#Power Management|Power management]] section)<br />
<br />
It tries to mimic the Optimus technology behavior; using the dedicated GPU for rendering when needed and power it down when not in use. The present releases only support rendering on-demand, automatically starting a program with the discrete video card based on workload is not implemented.<br />
<br />
== Installation ==<br />
<br />
Before installing Bumblebee check your BIOS and activate Optimus (older laptops call it "switchable graphics") if possible (BIOS doesn't have to provide this option), and install the [[Intel graphics|Intel driver]] for the secondary on board graphics card.<br />
<br />
Several packages are available for a complete setup:<br />
<br />
* {{Pkg|bumblebee}} - The main package providing the daemon and client programs.<br />
* (optional) {{Pkg|bbswitch}} (or {{AUR|bbswitch-dkms}}) - Recommended for saving power by disable the NVIDIA card.<br />
* (optional) If you want more than just saving power, that is rendering programs on the discrete NVDIA card you also need:<br />
** a driver for the NVIDIA card. The open-source [[nouveau]] driver or the more closed-source [[NVIDIA]] driver. See the subsection.<br />
** a render/display bridge. Two packages are currently available for that, {{Pkg|primus}} (or {{AUR|primus-git}}) and {{Pkg|virtualgl}}. Only one of them is necessary, but installing them side-by-side does not hurt.<br />
<br />
{{Note|If you want to run a 32-bit application on a 64-bit system you must install the proper lib32-* libraries for the program. In addition to this, you also need to install {{Pkg|lib32-virtualgl}} or {{Pkg|lib32-primus}}, depending on your choice for the render bridge. Just make sure you run {{ic|primusrun}} instead of {{ic|optirun}} if you decide to use Primus render bridge.}}<br />
<br />
=== Installing Bumblebee with Intel/NVIDIA ===<br />
<br />
Install {{Pkg|intel-dri}}, {{Pkg|xf86-video-intel}}, {{Pkg|bumblebee}} and {{Pkg|nvidia}}. If you have {{Pkg|intel-dri}} and {{Pkg|xf86-video-intel}} installed, you will have to reinstall them together with the rest to avoid a dependency conflict between {{Pkg|intel-dri}} and {{Pkg|nvidia}}. <br />
<br />
If you want to run 32-bit applications (like games with wine) on a 64-bit system you need the {{Pkg|lib32-nvidia-utils}} (and {{Pkg|lib32-intel-dri}} if you intend to use {{ic|primusrun}}) package too.<br />
<br />
{{Warning|Do not install {{pkg|lib32-nvidia-libgl}}. Bumblebee will find the correct lib32 NVIDIA libraries without it.}}<br />
<br />
=== Installing Bumblebee with Intel/Nouveau ===<br />
<br />
Install:<br />
* {{Pkg|xf86-video-nouveau}} - experimental 3D acceleration driver.<br />
* {{Pkg|nouveau-dri}} - Mesa classic DRI + Gallium3D drivers.<br />
* {{Pkg|mesa}} - Mesa 3D graphics libraries.<br />
<br />
== Start Bumblebee ==<br />
<br />
In order to use Bumblebee it is necessary add yourself (and other users) to the bumblebee group:<br />
<br />
# gpasswd -a $USER bumblebee<br />
<br />
where {{ic|$USER}} is the login name of the user to be added. Then log off and on again to apply the group changes.<br />
<br />
{{Tip|If you wish '''bumblebee''' to start at boot, you have to enable [[systemd]] service '''bumblebeed'''.}}<br />
<br />
Finished. Reboot system and use the shell program {{ic|[[#Usage|optirun]]}} for Optimus NVIDIA rendering!<br />
<br />
If you simply wish to disable your NVIDIA card, this should be all that is needed, apart from having {{ic|bbswitch}} installed. The bumblebeed daemon will, by default, instruct bbswitch to turn off the card when it starts. See also the [[#Power management|power management]] section below.<br />
<br />
== Usage ==<br />
<br />
The command line program {{ic|optirun}} shipped with Bumblebee is your best friend<br />
for running applications on your Optimus NVIDIA card.<br />
<br />
Test Bumblebee if it works with your Optimus system:<br />
$ optirun glxgears -info<br />
<br />
If it succeeds and the terminal you are running from mentions something about your NVIDIA - Optimus with Bumblebee is working!<br />
<br />
General usage:<br />
<br />
$ optirun [options] ''application'' [application-parameters]<br />
<br />
Some Examples:<br />
<br />
Start Windows applications with Optimus:<br />
<br />
$ optirun wine ''windows application''.exe<br />
<br />
Use NVIDIA Settings with Optimus:<br />
<br />
$ optirun -b none nvidia-settings -c :8<br />
<br />
For a list of options for {{ic|optirun}} view its manual page.<br />
<br />
A new program is soon becoming the default choice because of better performance, namely<br />
primus. Currently you need to run this program separately (it does not accept options<br />
unlike {{ic|optirun}}), but in the future it will be started by optirun. Usage:<br />
$ primusrun glxgears<br />
<br />
== Configuration ==<br />
<br />
You can configure the behaviour of Bumblebee to fit your needs. Fine tuning like speed optimization, power management and other stuff can be configured in {{ic|/etc/bumblebee/bumblebee.conf}}<br />
<br />
=== Optimizing speed when using VirtualGL as bridge ===<br />
<br />
Bumblebee renders frames for your Optimus NVIDIA card in an invisible X Server with VirtualGL and transports them back to your visible X Server.<br />
<br />
Frames will be compressed before they are transported - this saves bandwidth and can be used for speed-up optimization of bumblebee:<br />
<br />
To use an other compression method for a single application:<br />
<br />
$ optirun -c ''compress-method'' application<br />
<br />
The method of compres will affect performance in the GPU/GPU usage. Compressed methods (such as {{ic|jpeg}}) will load the CPU the most but will load GPU the minimum necessary; uncompressed methods loads the most on GPU and the CPU will have the minimum load possible.<br />
<br />
Compressed methods are: {{ic|jpeg}}, {{ic|rgb}}, {{ic|yuv}}.<br />
<br />
Uncompressed methods are: {{ic|proxy}}, {{ic|xv}}.<br />
<br />
To use a standard compression for all applications set the {{ic|VGLTransport}} to {{ic|''compress-method''}} in {{ic|/etc/bumblebee/bumblebee.conf}}:<br />
<br />
{{hc|/etc/bumblebee/bumblebee.conf|2=<br />
[...]<br />
[optirun]<br />
VGLTransport=proxy<br />
[...]<br />
}}<br />
<br />
You can also play with the way VirtualGL reads back the pixels from your graphic card. Setting {{ic|VGL_READBACK}} environment variable to {{ic|pbo}} should increase the performance. Compare these two:<br />
<br />
# PBO should be faster.<br />
VGL_READBACK=pbo optirun glxspheres<br />
# The default value is sync.<br />
VGL_READBACK=sync optirun glxspheres<br />
<br />
{{Note|CPU frequency scaling will affect directly on render performance}}<br />
<br />
=== Power management ===<br />
<br />
The goal of power management feature is to turn off the NVIDIA card when it is not used by bumblebee any more.<br />
If bbswitch is installed, it will be detected automatically when the Bumblebee daemon starts. No additional<br />
configuration is necessary.<br />
<br />
==== Default power state of NVIDIA card using bbswitch ====<br />
<br />
The default behavior of bbswitch is to leave the card power state unchanged. {{ic|bumblebeed}} does disable<br />
the card when started, so the following is only necessary if you use bbswitch without bumblebeed.<br />
<br />
Set {{ic|load_state}} and {{ic|unload_state}} module options according to your needs (see [https://github.com/Bumblebee-Project/bbswitch bbswitch documentation]).<br />
{{hc|/etc/modprobe.d/bbswitch.conf|2=<br />
options bbswitch load_state=0 unload_state=1<br />
}}<br />
<br />
==== Enable NVIDIA card during shutdown ====<br />
The NVIDIA card may not correctly initialize during boot if the card was powered off when the system was last shutdown. One option is to set {{ic|TurnCardOffAtExit&#61;false}} in {{ic|/etc/bumblebee/bumblebee.conf}}, however this will enable the card everytime you stop the Bumblebee daemon, even if done manually. To ensure that the NVIDIA card is always powered on during shutdown, add the following [[systemd]] service (if using {{pkg|bbswitch}}):<br />
<br />
{{hc|/etc/systemd/system/nvidia-enable.service|2=<br />
[Unit]<br />
Description=Enable NVIDIA card<br />
DefaultDependencies=no<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/bin/sh -c 'echo ON > /proc/acpi/bbswitch'<br />
<br />
[Install]<br />
WantedBy=shutdown.target<br />
}}<br />
<br />
Then enable the service by running {{ic|systemctl enable nvidia-enable.service}} at the root prompt.<br />
<br />
=== Multiple monitors ===<br />
<br />
==== Outputs wired to the Intel chip ====<br />
<br />
If the port (DisplayPort/HDMI/VGA) is wired to the Intel chip, you can set up multiple monitors with xorg.conf. Set them to use the Intel card, but Bumblebee can still use the NVIDIA card. One example configuration is below for two identical screens with 1080p resolution and using the HDMI out.<br />
<br />
{{hc|/etc/X11/xorg.conf|2=<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "intelgpu0"<br />
Monitor "Monitor0"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1980x1080_60.00"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen1"<br />
Device "intelgpu1"<br />
Monitor "Monitor1"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1980x1080_60.00"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor1"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "intelgpu0"<br />
Driver "intel"<br />
Option "XvMC" "true"<br />
Option "UseEvents" "true"<br />
Option "AccelMethod" "UXA"<br />
BusID "PCI:0:2:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "intelgpu1"<br />
Driver "intel"<br />
Option "XvMC" "true"<br />
Option "UseEvents" "true"<br />
Option "AccelMethod" "UXA"<br />
BusID "PCI:0:2:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidiagpu1"<br />
Driver "nvidia"<br />
BusID "PCI:0:1:0"<br />
EndSection<br />
<br />
}}<br />
<br />
You need to probably change the BusID for both the Intel and the NVIDIA card.<br />
<br />
{{hc|<nowiki>$ lspci | grep VGA</nowiki>|<br />
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)<br />
}}<br />
<br />
The BusID is 0:2:0<br />
<br />
==== Output wired to the NVIDIA chip ====<br />
<br />
On some notebooks, the digital Video Output (HDMI or DisplayPort) is hardwired to the NVIDIA chip. If you want to use all the displays on such a system simultaniously, you have to run 2 X Servers. The first will be using the Intel driver for the notebooks panel and a display connected on VGA. The second will be started through optirun on the NVIDIA card, and drives the digital display.<br />
<br />
There are currently several instructions on the web how such a setup can be made to work. One can be found on the bumblebee [https://github.com/Bumblebee-Project/Bumblebee/wiki/Multi-monitor-setup wiki page]. Another approach is described below.<br />
<br />
===== xf86-video-intel-virtual-crtc and hybrid-screenclone =====<br />
<br />
This method uses a patched Intel driver, which is extended to have a VIRTUAL Display, and the program hybrid-screenclone which is used to copy the display over from the virtual display to a second X Server which is running on the NVIDIA card using Optirun. Credit goes to [http://judsonsnotes.com/notes/index.php?option=com_content&view=article&id=673:triple-head-monitors-on-thinkpad-t520&catid=37:tech-notes&Itemid=59 Triple-head monitors on a Thinkpad T520] which has a detailed explanation on how this is done on a Ubuntu system.<br />
<br />
For simplicity, DP is used below to refer to the Digital Output (DisplayPort). The instructions should be the same if the notebook has a HDMI port instead.<br />
<br />
* Set system to use NVIDIA card exclusively, test DP/Monitor combination and generate xorg.nvidia.conf. This step is not required, but recommended if your system Bios has an option to switch the graphics into NVIDIA-only mode. To do this, first uninstall the bumblebee package and install just the NVIDIA driver. Then reboot, enter the Bios and switch the Graphics to NVIDIA-only. When back in Arch, connect you Monitor on DP and use startx to test if it is working in principle. Use Xorg -configure to generate an xorg.conf file for your NVIDIA card. This will come in handy further down below.<br />
<br />
* Reinstall bumlbebee and bbswitch, reboot and set the system Gfx back to Hybrid in the BIOS. <br />
* Install {{AUR|xf86-video-intel-virtual-crtc}}, and replace your xf86-video-intel package with it.<br />
* Install {{AUR|screenclone-git}}<br />
* Change these bumblebee.conf settings:<br />
{{hc|/etc/bumblebee/bumblebee.conf|2=<br />
KeepUnusedXServer=true<br />
Driver=nvidia<br />
}}<br />
{{Note|Leave the PMMethod set to "bumblebee". This is contrary to the instructions linked in the article above, but on arch this options needs to be left alone so that bbswitch module is automatically loaded}}<br />
* Copy the xorg.conf generated in Step 1 to {{ic|/etc/X11}} (e.g. {{ic|/etc/X11/xorg.nvidia.conf}}). In the [driver-nvidia] section of {{ic|bumblebee.conf}}, change {{ic|XorgConfFile}} to point to it.<br />
* Test if your {{ic|/etc/X11/xorg.nvidia.conf}} is working with {{ic|startx -- -config /etc/X11/xorg.nvidia.conf}}<br />
* In order for your DP Monitor to show up with the correct resolution in your VIRTUAL Display you might have to edit the Monitor section in your {{ic|/etc/xorg.nvidia.conf}}. Since this is extra work, you could try to continue with your auto-generated file. Come back to this step in the instructions if you find that the resolution of the VIRTUAL Display as shown by xrandr is not correct.<br />
** First you have to generate a Modeline. You can use the tool [http://amlc.berlios.de/ amlc], which will genearte a Modeline if you input a few basic parameters. <br />
<br />
::Example: 24" 1920x1080 Monitor<br />
::start the tool with {{ic|amlc -c}}<br />
{{bc|Monitor Identifier: Samsung 2494<br />
Aspect Ratio: 2<br />
physical size[cm]: 60<br />
Ideal refresh rate, in Hz: 60<br />
min HSync, kHz: 40<br />
max HSync, kHz: 90<br />
min VSync, Hz: 50<br />
max VSync, Hz: 70<br />
max pixel Clock, MHz: 400}}<br />
<br />
This is the Monitor section which {{ic|amlc}} generated for this input:<br />
{{bc|Section "Monitor"<br />
Identifier "Samsung 2494"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494}}<br />
<br />
Change your {{ic|xorg.nvidia.conf}} to include this Monitor section. You can also trim down your file so that it only contains ServerLayout, Monitor, Device and Screen sections. For reference, here is mine:<br />
{{hc|/etc/X11/xorg.nvidia.conf|<br />
Section "ServerLayout"<br />
Identifier "X.org Nvidia DP"<br />
Screen 0 "Screen0" 0 0<br />
InputDevice "Mouse0" "CorePointer"<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Samsung 2494"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494<br />
<br />
Section "Device"<br />
Identifier "DiscreteNvidia"<br />
Driver "nvidia"<br />
BusID "PCI:1:0:0"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "DiscreteNvidia"<br />
Monitor "Samsung 2494"<br />
SubSection "Display"<br />
Viewport 0 0<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
}}<br />
* Plug in both external monitors and startx. Look at your {{ic|/var/log/Xorg.0.log}}. Check that your VGA Monitor is detected with the correct Modes there. You should also see a VIRTUAL output with modes show up.<br />
* Run {{ic|xrandr}} and three displays should be listed there, along with the supported modes.<br />
* If the listed Modelines for your VIRTUAL display doesn't have your Monitors native resolution, make note of the exact output name. For me that is {{ic|VIRTUAL1}}. Then have a look again in the Xorg.0.log file. You should see a message: "Output VIRTUAL1 has no monitor section" there. We will change this by putting a file with the needed Monitor section into {{ic|/etc/X11/xorg.conf.d}}. Exit and Restart X afterward.<br />
{{hc|/etc/X11/xorg.conf.d/20-monitor_samsung.conf|<br />
Section "Monitor"<br />
Identifier "VIRTUAL1"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494<br />
}}<br />
* Turn the NVIDIA card on by running: {{ic|sudo tee /proc/acpi/bbswitch <<< ON}}<br />
* Start another X server for the DisplayPort monitor: {{ic|sudo optirun true}}<br />
* Check the log of the second X server in {{ic|/var/log/Xorg.8.log}}<br />
* Run xrandr to set up the VIRTUAL display to be the right size and placement, eg.: {{ic|xrandr --output VGA1 --auto --rotate normal --pos 0x0 --output VIRTUAL1 --mode 1920x1080 --right-of VGA1 --output LVDS1 --auto --rotate normal --right-of VIRTUAL1}}<br />
* Take note of the position of the VIRTUAL display in the list of Outputs as shown by xrandr. The counting starts from zero, i.e. if it is the third display shown, you would specify {{ic|-x 2}} as parameter to {{ic|screenclone}} (Note: This might not always be correct. If you see your internal laptop display cloned on the monitor, try {{ic|-x 2}} anyway.)<br />
* Clone the contents of the VIRTUAL display onto the X server created by bumblebee, which is connected to the DisplayPort monitor via the NVIDIA chip:<br />
: {{ic|screenclone -d :8 -x 2}}<br />
<br />
Thats it, all three displays should be up and running now.<br />
<br />
== Switch between discrete and integrated like Windows==<br />
<br />
In Windows, the way that Optimus works is NVIDIA has a whitelist of applications that require Optimus for, and you can add applications to this whitelist as needed. When you launch the application, it automatically decides which card to use.<br />
<br />
To mimic this behavior in Linux, you can use {{AUR|libgl-switcheroo-git}}. After installing, you can add the below in your .xprofile.<br />
<br />
{{hc|~/.xprofile|2=<br />
mkdir -p /tmp/libgl-switcheroo-$USER/fs<br />
gtkglswitch &<br />
libgl-switcheroo /tmp/libgl-switcheroo-$USER/fs &<br />
}}<br />
<br />
To enable this, you must add the below to the shell that you intend to launch applications from (I simply added it to the .xprofile file)<br />
export LD_LIBRARY_PATH=/tmp/libgl-switcheroo-$USER/fs/\$LIB${LD_LIBRARY_PATH+:}$LD_LIBRARY_PATH<br />
<br />
Once this has all been done, every application you launch from this shell will pop up a GTK+ window asking which card you want to run it with (you can also add an application to the whitelist in the configuration). The configuration is located in {{ic|$XDG_CONFIG_HOME/libgl-switcheroo.conf}}, usually {{ic|~/.config/libgl-switcheroo.conf}}<br />
<br />
== CUDA without Bumblebee==<br />
<br />
This is not well documented, but you do not need Bumblebee to use CUDA and it may work even on machines where optirun fails. For a guide on how to get it working with the Lenovo IdeaPad Y580 (which uses the GeForce 660M), see: https://wiki.archlinux.org/index.php/Lenovo_IdeaPad_Y580#NVIDIA_Card. Those instructions are very likely to work with other machines.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Note|Please report bugs at [https://github.com/Bumblebee-Project/Bumblebee Bumblebee-Project]'s GitHub tracker as described in its [https://github.com/Bumblebee-Project/Bumblebee/wiki/Reporting-Issues wiki].}}<br />
<br />
=== [VGL] ERROR: Could not open display :8 ===<br />
<br />
There is a known problem with some wine applications that fork and kill the parent process without keeping track of it (for example the free to play online game "Runes of Magic")<br />
<br />
This is a known problem with VirtualGL. As of bumblebee 3.1, so long as you have it installed, you can use Primus as your render bridge:<br />
<br />
$ optirun -b primus wine ''windows program''.exe<br />
<br />
If this does not work, an alternative walkaround for this problem is:<br />
<br />
$ optirun bash<br />
$ optirun wine ''windows program''.exe<br />
<br />
If using NVIDIA drivers a fix for this problem is to edit {{ic|/etc/bumblebee/xorg.conf.nvidia}} and change Option {{ic|ConnectedMonitor}} to {{ic|CRT-0}}.<br />
<br />
=== [ERROR]Cannot access secondary GPU ===<br />
<br />
==== No devices detected ====<br />
<br />
In some instances, running optirun will return:<br />
<br />
[ERROR]Cannot access secondary GPU - error: [XORG] (EE) No devices detected.<br />
[ERROR]Aborting because fallback start is disabled.<br />
<br />
In this case, you will need to move the file {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} to somewhere else. Restart the bumblebeed daemon, and it should work. If you do need to change some features on Intel module, a workaround is to move your {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} to {{ic|/etc/X11/xorg.conf}}.<br />
<br />
It could be also necessary to comment the driver line in {{ic|/etc/X11/xorg.conf.d/10-monitor.conf}}.<br />
<br />
If you're using the nouveau driver you could try switching to the nVidia driver.<br />
<br />
You might need to define the NVIDIA card somewhere (e.g. file {{ic|/etc/X11/xorg.conf.d}}), and remember to change the BusID using lspci.<br />
<br />
{{bc|<br />
Section "Device"<br />
Identifier "nvidiagpu1"<br />
Driver "nvidia"<br />
BusID "PCI:0:1:0"<br />
EndSection<br />
}}<br />
<br />
==== NVIDIA(0): Failed to assign any connected display devices to X screen 0 ====<br />
<br />
If the console output is:<br />
<br />
[ERROR]Cannot access secondary GPU - error: [XORG] (EE) NVIDIA(0): Failed to assign any connected display devices to X screen 0<br />
[ERROR]Aborting because fallback start is disabled.<br />
<br />
<br />
You can change this line in {{ic|/etc/bumblebee/xorg.conf.nvidia}}:<br />
<br />
Option "ConnectedMonitor" "DFP"<br />
<br />
to:<br />
<br />
Option "ConnectedMonitor" "CRT"<br />
<br />
==== Could not load GPU driver ====<br />
<br />
If the console output is:<br />
<br />
[ERROR]Cannot access secondary GPU - error: Could not load GPU driver<br />
<br />
and if you try to load the nvidia module you get:<br />
<br />
modprobe nvidia<br />
modprobe: ERROR: could not insert 'nvidia': Exec format error<br />
<br />
You should try manually compiling the nvidia packages against your current kernel, for example with {{aur|nvidia-dkms}} or by compiling {{pkg|nvidia}} from the [[ABS]].<br />
<br />
==== Failed to initialize the NVIDIA GPU at PCI:1:0:0 (GPU fallen off the bus / RmInitAdapter failed!) ====<br />
<br />
Add {{ic|1=rcutree.rcu_idle_gp_delay=1}} to the kernel parameters. Original topic can be found [https://bbs.archlinux.org/viewtopic.php?id=169742 here].<br />
<br />
==== NOUVEAU(0): [drm] failed to set drm interface version ====<br />
<br />
Consider switching to the official nvidia driver. As commented [https://github.com/Bumblebee-Project/Bumblebee/issues/438#issuecomment-22005923 here], nouveau driver has some issues with some cards and bumblebee.<br />
<br />
=== ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored ===<br />
<br />
You probably want to start a 32-bit application with bumblebee on a 64-bit system. See the "Note" box in [[#Installation|Installation]].<br />
<br />
=== Fatal IO error 11 (Resource temporarily unavailable) on X server ===<br />
<br />
Change {{ic|KeepUnusedXServer}} in {{ic|/etc/bumblebee/bumblebee.conf}} from {{ic|false}} to {{ic|true}}. Your program forks into background and bumblebee don't know anything about it.<br />
<br />
=== Video tearing ===<br />
<br />
Video tearing is a somewhat common problem on Bumblebee. To fix it, you need to enable vsync. It should be enabled by default on the Intel card, but verify that from Xorg logs. To check whether or not it is enabled for NVIDIA, run: <br />
<br />
$ optirun nvidia-settings -c :8<br />
<br />
{{ic|1=X Server XVideo Settings -> Sync to VBlank}} and {{ic|1=OpenGL Settings -> Sync to VBlank}} should both be enabled. The Intel card has in general less tearing, so use it for video playback. Especially use VA-API for video decoding (e.g. {{ic|mplayer-vaapi}} and with {{ic|-vsync}} parameter).<br />
<br />
Refer to the [[Intel#Video_tearing|Intel]] article on how to fix tearing on the Intel card.<br />
<br />
If it is still not fixed, try to disable compositing from your desktop environment. Try also disabling triple buffering.<br />
<br />
=== Bumblebee cannot connect to socket ===<br />
<br />
You might get something like:<br />
<br />
{{hc|$ optirun glxspheres|<br />
[ 1648.179533] [ERROR]You've no permission to communicate with the Bumblebee daemon. Try adding yourself to the 'bumblebee' group<br />
[ 1648.179628] [ERROR]Could not connect to bumblebee daemon - is it running?<br />
}}<br />
<br />
If you are already in the {{ic|bumblebee}} group ({{ic|<nowiki>$ groups | grep bumblebee</nowiki>}}), you may try [https://bbs.archlinux.org/viewtopic.php?pid=1178729#p1178729 removing the socket] {{ic|/var/run/bumblebeed.socket}}.<br />
<br />
=== Running X.org from console after login (rootless X.org) ===<br />
<br />
See [[Xorg#Rootless_Xorg_.28v1.16.29]].<br />
<br />
== See also ==<br />
<br />
* [http://www.bumblebee-project.org Bumblebee project repository]<br />
* [http://wiki.bumblebee-project.org/ Bumblebee project wiki]<br />
* [https://github.com/Bumblebee-Project/bbswitch Bumblebee project bbswitch repository]<br />
<br />
Join us at #bumblebee at freenode.net.</div>Ndthttps://wiki.archlinux.org/index.php?title=Bumblebee&diff=330844Bumblebee2014-08-18T02:44:43Z<p>Ndt: /* Could not load GPU driver */ stop recommending yaourt</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X Server]]<br />
[[es:Bumblebee]]<br />
[[fr:Bumblebee]]<br />
[[it:Bumblebee]]<br />
[[ru:Bumblebee]]<br />
[[tr:Bumblebee]]<br />
[[zh-CN:Bumblebee]]<br />
{{Related articles start}}<br />
{{Related|NVIDIA Optimus}}<br />
{{Related|Nouveau}}<br />
{{Related|NVIDIA}}<br />
{{Related|Intel graphics}}<br />
{{Related articles end}}<br />
From Bumblebee's [https://github.com/Bumblebee-Project/Bumblebee/wiki/FAQ FAQ]:<br />
<br />
"''Bumblebee is an effort to make NVIDIA Optimus enabled laptops work in GNU/Linux systems. Such feature involves two graphics cards with two different power consumption profiles plugged in a layered way sharing a single framebuffer.''"<br />
<br />
== Bumblebee: Optimus for Linux ==<br />
<br />
[http://www.nvidia.com/object/optimus_technology.html Optimus Technology] is an ''[http://hybrid-graphics-linux.tuxfamily.org/index.php?title=Hybrid_graphics hybrid graphics]'' implementation without a hardware multiplexer. The integrated GPU manages the display while the dedicated GPU manages the most demanding rendering and ships the work to the integrated GPU to be displayed. When the laptop is running on battery supply, the dedicated GPU is turned off to save power and prolong the battery life. It has also been tested successfully with desktop machines with Intel integrated graphics and an nVidia dedicated graphics card. <br />
<br />
Bumblebee is a software implementation comprising of two parts:<br />
<br />
* Render programs off-screen on the dedicated video card and display it on the screen using the integrated video card. This bridge is provided by VirtualGL or primus (read further) and connects to a X server started for the discrete video card.<br />
* Disable the dedicated video card when it is not in use (see the [[#Power Management|Power management]] section)<br />
<br />
It tries to mimic the Optimus technology behavior; using the dedicated GPU for rendering when needed and power it down when not in use. The present releases only support rendering on-demand, automatically starting a program with the discrete video card based on workload is not implemented.<br />
<br />
== Installation ==<br />
<br />
Before installing Bumblebee check your BIOS and activate Optimus (older laptops call it "switchable graphics") if possible (BIOS doesn't have to provide this option), and install the [[Intel graphics|Intel driver]] for the secondary on board graphics card.<br />
<br />
Several packages are available for a complete setup:<br />
<br />
* {{Pkg|bumblebee}} - The main package providing the daemon and client programs.<br />
* (optional) {{Pkg|bbswitch}} (or {{AUR|bbswitch-dkms}}) - Recommended for saving power by disable the NVIDIA card.<br />
* (optional) If you want more than just saving power, that is rendering programs on the discrete NVDIA card you also need:<br />
** a driver for the NVIDIA card. The open-source [[nouveau]] driver or the more closed-source [[NVIDIA]] driver. See the subsection.<br />
** a render/display bridge. Two packages are currently available for that, {{Pkg|primus}} (or {{AUR|primus-git}}) and {{Pkg|virtualgl}}. Only one of them is necessary, but installing them side-by-side does not hurt.<br />
<br />
{{Note|If you want to run a 32-bit application on a 64-bit system you must install the proper lib32-* libraries for the program. In addition to this, you also need to install {{Pkg|lib32-virtualgl}} or {{Pkg|lib32-primus}}, depending on your choice for the render bridge. Just make sure you run {{ic|primusrun}} instead of {{ic|optirun}} if you decide to use Primus render bridge.}}<br />
<br />
=== Installing Bumblebee with Intel/NVIDIA ===<br />
<br />
Install {{Pkg|intel-dri}}, {{Pkg|xf86-video-intel}}, {{Pkg|bumblebee}} and {{Pkg|nvidia}}. If you have {{Pkg|intel-dri}} and {{Pkg|xf86-video-intel}} installed, you will have to reinstall them together with the rest to avoid a dependency conflict between {{Pkg|intel-dri}} and {{Pkg|nvidia}}. <br />
<br />
If you want to run 32-bit applications (like games with wine) on a 64-bit system you need the {{Pkg|lib32-nvidia-utils}} (and {{Pkg|lib32-intel-dri}} if you intend to use {{ic|primusrun}}) package too.<br />
<br />
{{Warning|Do not install {{pkg|lib32-nvidia-libgl}}. Bumblebee will find the correct lib32 NVIDIA libraries without it.}}<br />
<br />
=== Installing Bumblebee with Intel/Nouveau ===<br />
<br />
Install:<br />
* {{Pkg|xf86-video-nouveau}} - experimental 3D acceleration driver.<br />
* {{Pkg|nouveau-dri}} - Mesa classic DRI + Gallium3D drivers.<br />
* {{Pkg|mesa}} - Mesa 3D graphics libraries.<br />
<br />
== Start Bumblebee ==<br />
<br />
In order to use Bumblebee it is necessary add yourself (and other users) to the bumblebee group:<br />
<br />
# gpasswd -a $USER bumblebee<br />
<br />
where {{ic|$USER}} is the login name of the user to be added. Then log off and on again to apply the group changes.<br />
<br />
{{Tip|If you wish '''bumblebee''' to start at boot, you have to enable [[systemd]] service '''bumblebeed'''.}}<br />
<br />
Finished. Reboot system and use the shell program {{ic|[[#Usage|optirun]]}} for Optimus NVIDIA rendering!<br />
<br />
If you simply wish to disable your NVIDIA card, this should be all that is needed, apart from having {{ic|bbswitch}} installed. The bumblebeed daemon will, by default, instruct bbswitch to turn off the card when it starts. See also the [[#Power management|power management]] section below.<br />
<br />
== Usage ==<br />
<br />
The command line program {{ic|optirun}} shipped with Bumblebee is your best friend<br />
for running applications on your Optimus NVIDIA card.<br />
<br />
Test Bumblebee if it works with your Optimus system:<br />
$ optirun glxgears -info<br />
<br />
If it succeeds and the terminal you are running from mentions something about your NVIDIA - Optimus with Bumblebee is working!<br />
<br />
General usage:<br />
<br />
$ optirun [options] ''application'' [application-parameters]<br />
<br />
Some Examples:<br />
<br />
Start Windows applications with Optimus:<br />
<br />
$ optirun wine ''windows application''.exe<br />
<br />
Use NVIDIA Settings with Optimus:<br />
<br />
$ optirun -b none nvidia-settings -c :8<br />
<br />
For a list of options for {{ic|optirun}} view its manual page.<br />
<br />
A new program is soon becoming the default choice because of better performance, namely<br />
primus. Currently you need to run this program separately (it does not accept options<br />
unlike {{ic|optirun}}), but in the future it will be started by optirun. Usage:<br />
$ primusrun glxgears<br />
<br />
== Configuration ==<br />
<br />
You can configure the behaviour of Bumblebee to fit your needs. Fine tuning like speed optimization, power management and other stuff can be configured in {{ic|/etc/bumblebee/bumblebee.conf}}<br />
<br />
=== Optimizing speed when using VirtualGL as bridge ===<br />
<br />
Bumblebee renders frames for your Optimus NVIDIA card in an invisible X Server with VirtualGL and transports them back to your visible X Server.<br />
<br />
Frames will be compressed before they are transported - this saves bandwidth and can be used for speed-up optimization of bumblebee:<br />
<br />
To use an other compression method for a single application:<br />
<br />
$ optirun -c ''compress-method'' application<br />
<br />
The method of compres will affect performance in the GPU/GPU usage. Compressed methods (such as {{ic|jpeg}}) will load the CPU the most but will load GPU the minimum necessary; uncompressed methods loads the most on GPU and the CPU will have the minimum load possible.<br />
<br />
Compressed methods are: {{ic|jpeg}}, {{ic|rgb}}, {{ic|yuv}}.<br />
<br />
Uncompressed methods are: {{ic|proxy}}, {{ic|xv}}.<br />
<br />
To use a standard compression for all applications set the {{ic|VGLTransport}} to {{ic|''compress-method''}} in {{ic|/etc/bumblebee/bumblebee.conf}}:<br />
<br />
{{hc|/etc/bumblebee/bumblebee.conf|2=<br />
[...]<br />
[optirun]<br />
VGLTransport=proxy<br />
[...]<br />
}}<br />
<br />
You can also play with the way VirtualGL reads back the pixels from your graphic card. Setting {{ic|VGL_READBACK}} environment variable to {{ic|pbo}} should increase the performance. Compare these two:<br />
<br />
# PBO should be faster.<br />
VGL_READBACK=pbo optirun glxspheres<br />
# The default value is sync.<br />
VGL_READBACK=sync optirun glxspheres<br />
<br />
{{Note|CPU frequency scaling will affect directly on render performance}}<br />
<br />
=== Power management ===<br />
<br />
The goal of power management feature is to turn off the NVIDIA card when it is not used by bumblebee any more.<br />
If bbswitch is installed, it will be detected automatically when the Bumblebee daemon starts. No additional<br />
configuration is necessary.<br />
<br />
==== Default power state of NVIDIA card using bbswitch ====<br />
<br />
The default behavior of bbswitch is to leave the card power state unchanged. {{ic|bumblebeed}} does disable<br />
the card when started, so the following is only necessary if you use bbswitch without bumblebeed.<br />
<br />
Set {{ic|load_state}} and {{ic|unload_state}} module options according to your needs (see [https://github.com/Bumblebee-Project/bbswitch bbswitch documentation]).<br />
{{hc|/etc/modprobe.d/bbswitch.conf|2=<br />
options bbswitch load_state=0 unload_state=1<br />
}}<br />
<br />
==== Enable NVIDIA card during shutdown ====<br />
The NVIDIA card may not correctly initialize during boot if the card was powered off when the system was last shutdown. One option is to set {{ic|TurnCardOffAtExit&#61;false}} in {{ic|/etc/bumblebee/bumblebee.conf}}, however this will enable the card everytime you stop the Bumblebee daemon, even if done manually. To ensure that the NVIDIA card is always powered on during shutdown, add the following [[systemd]] service (if using {{pkg|bbswitch}}):<br />
<br />
{{hc|/etc/systemd/system/nvidia-enable.service|2=<br />
[Unit]<br />
Description=Enable NVIDIA card<br />
DefaultDependencies=no<br />
<br />
[Service]<br />
Type=oneshot<br />
ExecStart=/bin/sh -c 'echo ON > /proc/acpi/bbswitch'<br />
<br />
[Install]<br />
WantedBy=shutdown.target<br />
}}<br />
<br />
Then enable the service by running {{ic|systemctl enable nvidia-enable.service}} at the root prompt.<br />
<br />
=== Multiple monitors ===<br />
<br />
==== Outputs wired to the Intel chip ====<br />
<br />
If the port (DisplayPort/HDMI/VGA) is wired to the Intel chip, you can set up multiple monitors with xorg.conf. Set them to use the Intel card, but Bumblebee can still use the NVIDIA card. One example configuration is below for two identical screens with 1080p resolution and using the HDMI out.<br />
<br />
{{hc|/etc/X11/xorg.conf|2=<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "intelgpu0"<br />
Monitor "Monitor0"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1980x1080_60.00"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen1"<br />
Device "intelgpu1"<br />
Monitor "Monitor1"<br />
DefaultDepth 24<br />
Option "TwinView" "0"<br />
SubSection "Display"<br />
Depth 24<br />
Modes "1980x1080_60.00"<br />
EndSubSection<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Monitor1"<br />
Option "Enable" "true"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "intelgpu0"<br />
Driver "intel"<br />
Option "XvMC" "true"<br />
Option "UseEvents" "true"<br />
Option "AccelMethod" "UXA"<br />
BusID "PCI:0:2:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "intelgpu1"<br />
Driver "intel"<br />
Option "XvMC" "true"<br />
Option "UseEvents" "true"<br />
Option "AccelMethod" "UXA"<br />
BusID "PCI:0:2:0"<br />
EndSection<br />
<br />
Section "Device"<br />
Identifier "nvidiagpu1"<br />
Driver "nvidia"<br />
BusID "PCI:0:1:0"<br />
EndSection<br />
<br />
}}<br />
<br />
You need to probably change the BusID for both the Intel and the NVIDIA card.<br />
<br />
{{hc|<nowiki>$ lspci | grep VGA</nowiki>|<br />
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)<br />
}}<br />
<br />
The BusID is 0:2:0<br />
<br />
==== Output wired to the NVIDIA chip ====<br />
<br />
On some notebooks, the digital Video Output (HDMI or DisplayPort) is hardwired to the NVIDIA chip. If you want to use all the displays on such a system simultaniously, you have to run 2 X Servers. The first will be using the Intel driver for the notebooks panel and a display connected on VGA. The second will be started through optirun on the NVIDIA card, and drives the digital display.<br />
<br />
There are currently several instructions on the web how such a setup can be made to work. One can be found on the bumblebee [https://github.com/Bumblebee-Project/Bumblebee/wiki/Multi-monitor-setup wiki page]. Another approach is described below.<br />
<br />
===== xf86-video-intel-virtual-crtc and hybrid-screenclone =====<br />
<br />
This method uses a patched Intel driver, which is extended to have a VIRTUAL Display, and the program hybrid-screenclone which is used to copy the display over from the virtual display to a second X Server which is running on the NVIDIA card using Optirun. Credit goes to [http://judsonsnotes.com/notes/index.php?option=com_content&view=article&id=673:triple-head-monitors-on-thinkpad-t520&catid=37:tech-notes&Itemid=59 Triple-head monitors on a Thinkpad T520] which has a detailed explanation on how this is done on a Ubuntu system.<br />
<br />
For simplicity, DP is used below to refer to the Digital Output (DisplayPort). The instructions should be the same if the notebook has a HDMI port instead.<br />
<br />
* Set system to use NVIDIA card exclusively, test DP/Monitor combination and generate xorg.nvidia.conf. This step is not required, but recommended if your system Bios has an option to switch the graphics into NVIDIA-only mode. To do this, first uninstall the bumblebee package and install just the NVIDIA driver. Then reboot, enter the Bios and switch the Graphics to NVIDIA-only. When back in Arch, connect you Monitor on DP and use startx to test if it is working in principle. Use Xorg -configure to generate an xorg.conf file for your NVIDIA card. This will come in handy further down below.<br />
<br />
* Reinstall bumlbebee and bbswitch, reboot and set the system Gfx back to Hybrid in the BIOS. <br />
* Install {{AUR|xf86-video-intel-virtual-crtc}}, and replace your xf86-video-intel package with it.<br />
* Install {{AUR|screenclone-git}}<br />
* Change these bumblebee.conf settings:<br />
{{hc|/etc/bumblebee/bumblebee.conf|2=<br />
KeepUnusedXServer=true<br />
Driver=nvidia<br />
}}<br />
{{Note|Leave the PMMethod set to "bumblebee". This is contrary to the instructions linked in the article above, but on arch this options needs to be left alone so that bbswitch module is automatically loaded}}<br />
* Copy the xorg.conf generated in Step 1 to {{ic|/etc/X11}} (e.g. {{ic|/etc/X11/xorg.nvidia.conf}}). In the [driver-nvidia] section of {{ic|bumblebee.conf}}, change {{ic|XorgConfFile}} to point to it.<br />
* Test if your {{ic|/etc/X11/xorg.nvidia.conf}} is working with {{ic|startx -- -config /etc/X11/xorg.nvidia.conf}}<br />
* In order for your DP Monitor to show up with the correct resolution in your VIRTUAL Display you might have to edit the Monitor section in your {{ic|/etc/xorg.nvidia.conf}}. Since this is extra work, you could try to continue with your auto-generated file. Come back to this step in the instructions if you find that the resolution of the VIRTUAL Display as shown by xrandr is not correct.<br />
** First you have to generate a Modeline. You can use the tool [http://amlc.berlios.de/ amlc], which will genearte a Modeline if you input a few basic parameters. <br />
<br />
::Example: 24" 1920x1080 Monitor<br />
::start the tool with {{ic|amlc -c}}<br />
{{bc|Monitor Identifier: Samsung 2494<br />
Aspect Ratio: 2<br />
physical size[cm]: 60<br />
Ideal refresh rate, in Hz: 60<br />
min HSync, kHz: 40<br />
max HSync, kHz: 90<br />
min VSync, Hz: 50<br />
max VSync, Hz: 70<br />
max pixel Clock, MHz: 400}}<br />
<br />
This is the Monitor section which {{ic|amlc}} generated for this input:<br />
{{bc|Section "Monitor"<br />
Identifier "Samsung 2494"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494}}<br />
<br />
Change your {{ic|xorg.nvidia.conf}} to include this Monitor section. You can also trim down your file so that it only contains ServerLayout, Monitor, Device and Screen sections. For reference, here is mine:<br />
{{hc|/etc/X11/xorg.nvidia.conf|<br />
Section "ServerLayout"<br />
Identifier "X.org Nvidia DP"<br />
Screen 0 "Screen0" 0 0<br />
InputDevice "Mouse0" "CorePointer"<br />
InputDevice "Keyboard0" "CoreKeyboard"<br />
EndSection<br />
<br />
Section "Monitor"<br />
Identifier "Samsung 2494"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494<br />
<br />
Section "Device"<br />
Identifier "DiscreteNvidia"<br />
Driver "nvidia"<br />
BusID "PCI:1:0:0"<br />
EndSection<br />
<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "DiscreteNvidia"<br />
Monitor "Samsung 2494"<br />
SubSection "Display"<br />
Viewport 0 0<br />
Depth 24<br />
EndSubSection<br />
EndSection<br />
}}<br />
* Plug in both external monitors and startx. Look at your {{ic|/var/log/Xorg.0.log}}. Check that your VGA Monitor is detected with the correct Modes there. You should also see a VIRTUAL output with modes show up.<br />
* Run {{ic|xrandr}} and three displays should be listed there, along with the supported modes.<br />
* If the listed Modelines for your VIRTUAL display doesn't have your Monitors native resolution, make note of the exact output name. For me that is {{ic|VIRTUAL1}}. Then have a look again in the Xorg.0.log file. You should see a message: "Output VIRTUAL1 has no monitor section" there. We will change this by putting a file with the needed Monitor section into {{ic|/etc/X11/xorg.conf.d}}. Exit and Restart X afterward.<br />
{{hc|/etc/X11/xorg.conf.d/20-monitor_samsung.conf|<br />
Section "Monitor"<br />
Identifier "VIRTUAL1"<br />
ModelName "Generated by Another Modeline Calculator"<br />
HorizSync 40-90<br />
VertRefresh 50-70<br />
DisplaySize 532 299 # Aspect ratio 1.778:1<br />
# Custom modes<br />
Modeline "1920x1080" 174.83 1920 2056 2248 2536 1080 1081 1084 1149 # 174.83 MHz, 68.94 kHz, 60.00 Hz<br />
EndSection # Samsung 2494<br />
}}<br />
* Turn the NVIDIA card on by running: {{ic|sudo tee /proc/acpi/bbswitch <<< ON}}<br />
* Start another X server for the DisplayPort monitor: {{ic|sudo optirun true}}<br />
* Check the log of the second X server in {{ic|/var/log/Xorg.8.log}}<br />
* Run xrandr to set up the VIRTUAL display to be the right size and placement, eg.: {{ic|xrandr --output VGA1 --auto --rotate normal --pos 0x0 --output VIRTUAL1 --mode 1920x1080 --right-of VGA1 --output LVDS1 --auto --rotate normal --right-of VIRTUAL1}}<br />
* Take note of the position of the VIRTUAL display in the list of Outputs as shown by xrandr. The counting starts from zero, i.e. if it is the third display shown, you would specify {{ic|-x 2}} as parameter to {{ic|screenclone}} (Note: This might not always be correct. If you see your internal laptop display cloned on the monitor, try {{ic|-x 2}} anyway.)<br />
* Clone the contents of the VIRTUAL display onto the X server created by bumblebee, which is connected to the DisplayPort monitor via the NVIDIA chip:<br />
: {{ic|screenclone -d :8 -x 2}}<br />
<br />
Thats it, all three displays should be up and running now.<br />
<br />
== Switch between discrete and integrated like Windows==<br />
<br />
In Windows, the way that Optimus works is NVIDIA has a whitelist of applications that require Optimus for, and you can add applications to this whitelist as needed. When you launch the application, it automatically decides which card to use.<br />
<br />
To mimic this behavior in Linux, you can use {{AUR|libgl-switcheroo-git}}. After installing, you can add the below in your .xprofile.<br />
<br />
{{hc|~/.xprofile|2=<br />
mkdir -p /tmp/libgl-switcheroo-$USER/fs<br />
gtkglswitch &<br />
libgl-switcheroo /tmp/libgl-switcheroo-$USER/fs &<br />
}}<br />
<br />
To enable this, you must add the below to the shell that you intend to launch applications from (I simply added it to the .xprofile file)<br />
export LD_LIBRARY_PATH=/tmp/libgl-switcheroo-$USER/fs/\$LIB${LD_LIBRARY_PATH+:}$LD_LIBRARY_PATH<br />
<br />
Once this has all been done, every application you launch from this shell will pop up a GTK+ window asking which card you want to run it with (you can also add an application to the whitelist in the configuration). The configuration is located in {{ic|$XDG_CONFIG_HOME/libgl-switcheroo.conf}}, usually {{ic|~/.config/libgl-switcheroo.conf}}<br />
<br />
== CUDA without Bumblebee==<br />
<br />
This is not well documented, but you do not need Bumblebee to use CUDA and it may work even on machines where optirun fails. For a guide on how to get it working with the Lenovo IdeaPad Y580 (which uses the GeForce 660M), see: https://wiki.archlinux.org/index.php/Lenovo_IdeaPad_Y580#NVIDIA_Card. Those instructions are very likely to work with other machines.<br />
<br />
== Troubleshooting ==<br />
<br />
{{Note|Please report bugs at [https://github.com/Bumblebee-Project/Bumblebee Bumblebee-Project]'s GitHub tracker as described in its [https://github.com/Bumblebee-Project/Bumblebee/wiki/Reporting-Issues wiki].}}<br />
<br />
=== [VGL] ERROR: Could not open display :8 ===<br />
<br />
There is a known problem with some wine applications that fork and kill the parent process without keeping track of it (for example the free to play online game "Runes of Magic")<br />
<br />
This is a known problem with VirtualGL. As of bumblebee 3.1, so long as you have it installed, you can use Primus as your render bridge:<br />
<br />
$ optirun -b primus wine ''windows program''.exe<br />
<br />
If this does not work, an alternative walkaround for this problem is:<br />
<br />
$ optirun bash<br />
$ optirun wine ''windows program''.exe<br />
<br />
If using NVIDIA drivers a fix for this problem is to edit {{ic|/etc/bumblebee/xorg.conf.nvidia}} and change Option {{ic|ConnectedMonitor}} to {{ic|CRT-0}}.<br />
<br />
=== [ERROR]Cannot access secondary GPU ===<br />
<br />
==== No devices detected ====<br />
<br />
In some instances, running optirun will return:<br />
<br />
[ERROR]Cannot access secondary GPU - error: [XORG] (EE) No devices detected.<br />
[ERROR]Aborting because fallback start is disabled.<br />
<br />
In this case, you will need to move the file {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} to somewhere else. Restart the bumblebeed daemon, and it should work. If you do need to change some features on Intel module, a workaround is to move your {{ic|/etc/X11/xorg.conf.d/20-intel.conf}} to {{ic|/etc/X11/xorg.conf}}.<br />
<br />
It could be also necessary to comment the driver line in {{ic|/etc/X11/xorg.conf.d/10-monitor.conf}}.<br />
<br />
If you're using the nouveau driver you could try switching to the nVidia driver.<br />
<br />
You might need to define the NVIDIA card somewhere (e.g. file {{ic|/etc/X11/xorg.conf.d}}), and remember to change the BusID using lspci.<br />
<br />
{{bc|<br />
Section "Device"<br />
Identifier "nvidiagpu1"<br />
Driver "nvidia"<br />
BusID "PCI:0:1:0"<br />
EndSection<br />
}}<br />
<br />
==== NVIDIA(0): Failed to assign any connected display devices to X screen 0 ====<br />
<br />
If the console output is:<br />
<br />
[ERROR]Cannot access secondary GPU - error: [XORG] (EE) NVIDIA(0): Failed to assign any connected display devices to X screen 0<br />
[ERROR]Aborting because fallback start is disabled.<br />
<br />
<br />
You can change this line in {{ic|/etc/bumblebee/xorg.conf.nvidia}}:<br />
<br />
Option "ConnectedMonitor" "DFP"<br />
<br />
to:<br />
<br />
Option "ConnectedMonitor" "CRT"<br />
<br />
==== Could not load GPU driver ====<br />
<br />
If the console output is:<br />
<br />
[ERROR]Cannot access secondary GPU - error: Could not load GPU driver<br />
<br />
and if you try to load the nvidia module you get:<br />
<br />
modprobe nvidia<br />
modprobe: ERROR: could not insert 'nvidia': Exec format error<br />
<br />
You should try manually compiling the nvidia packages against your current kernel.<br />
<br />
==== Failed to initialize the NVIDIA GPU at PCI:1:0:0 (GPU fallen off the bus / RmInitAdapter failed!) ====<br />
<br />
Add {{ic|1=rcutree.rcu_idle_gp_delay=1}} to the kernel parameters. Original topic can be found [https://bbs.archlinux.org/viewtopic.php?id=169742 here].<br />
<br />
==== NOUVEAU(0): [drm] failed to set drm interface version ====<br />
<br />
Consider switching to the official nvidia driver. As commented [https://github.com/Bumblebee-Project/Bumblebee/issues/438#issuecomment-22005923 here], nouveau driver has some issues with some cards and bumblebee.<br />
<br />
=== ERROR: ld.so: object 'libdlfaker.so' from LD_PRELOAD cannot be preloaded: ignored ===<br />
<br />
You probably want to start a 32-bit application with bumblebee on a 64-bit system. See the "Note" box in [[#Installation|Installation]].<br />
<br />
=== Fatal IO error 11 (Resource temporarily unavailable) on X server ===<br />
<br />
Change {{ic|KeepUnusedXServer}} in {{ic|/etc/bumblebee/bumblebee.conf}} from {{ic|false}} to {{ic|true}}. Your program forks into background and bumblebee don't know anything about it.<br />
<br />
=== Video tearing ===<br />
<br />
Video tearing is a somewhat common problem on Bumblebee. To fix it, you need to enable vsync. It should be enabled by default on the Intel card, but verify that from Xorg logs. To check whether or not it is enabled for NVIDIA, run: <br />
<br />
$ optirun nvidia-settings -c :8<br />
<br />
{{ic|1=X Server XVideo Settings -> Sync to VBlank}} and {{ic|1=OpenGL Settings -> Sync to VBlank}} should both be enabled. The Intel card has in general less tearing, so use it for video playback. Especially use VA-API for video decoding (e.g. {{ic|mplayer-vaapi}} and with {{ic|-vsync}} parameter).<br />
<br />
Refer to the [[Intel#Video_tearing|Intel]] article on how to fix tearing on the Intel card.<br />
<br />
If it is still not fixed, try to disable compositing from your desktop environment. Try also disabling triple buffering.<br />
<br />
=== Bumblebee cannot connect to socket ===<br />
<br />
You might get something like:<br />
<br />
{{hc|$ optirun glxspheres|<br />
[ 1648.179533] [ERROR]You've no permission to communicate with the Bumblebee daemon. Try adding yourself to the 'bumblebee' group<br />
[ 1648.179628] [ERROR]Could not connect to bumblebee daemon - is it running?<br />
}}<br />
<br />
If you are already in the {{ic|bumblebee}} group ({{ic|<nowiki>$ groups | grep bumblebee</nowiki>}}), you may try [https://bbs.archlinux.org/viewtopic.php?pid=1178729#p1178729 removing the socket] {{ic|/var/run/bumblebeed.socket}}.<br />
<br />
=== Running X.org from console after login (rootless X.org) ===<br />
<br />
See [[Xorg#Rootless_Xorg_.28v1.16.29]].<br />
<br />
== See also ==<br />
<br />
* [http://www.bumblebee-project.org Bumblebee project repository]<br />
* [http://wiki.bumblebee-project.org/ Bumblebee project wiki]<br />
* [https://github.com/Bumblebee-Project/bbswitch Bumblebee project bbswitch repository]<br />
<br />
Join us at #bumblebee at freenode.net.</div>Ndthttps://wiki.archlinux.org/index.php?title=Kernel_mode_setting&diff=330843Kernel mode setting2014-08-18T00:24:40Z<p>Ndt: /* Problem upon bootloading and dmesg */ ic block</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:Kernel]]<br />
[[Category:X Server]]<br />
[[es:Kernel Mode Setting]]<br />
[[hu:Kernel Mode Setting]]<br />
[[ja:Kernel Mode Setting]]<br />
[[zh-CN:Kernel Mode Setting]]<br />
[[zh-TW:Kernel Mode Setting]]<br />
{{Related articles start}}<br />
{{Related|ATI}}<br />
{{Related|Intel graphics}}<br />
{{Related|Nouveau}}<br />
{{Related articles end}}<br />
{{Expansion|KMS and rootless X (1.16), see [[Talk:Kernel mode setting]] and [[Xorg#Rootless_Xorg_.28v1.16.29]].}}<br />
Kernel [[Wikipedia:Mode-setting|Mode Setting]] (KMS) is a method for setting display resolution and depth in the kernel space rather than user space.<br />
<br />
The Linux kernel's implementation of KMS enables native resolution in the framebuffer and allows for instant console (tty) switching. KMS also enables newer technologies (such as DRI2) which will help reduce artifacts and increase 3D performance, even kernel space power-saving.<br />
<br />
{{Note|The proprietary [[NVIDIA|nvidia]] and [[AMD Catalyst|catalyst]] drivers also implement kernel mode-setting, but as they do not use the built-in kernel implementation, they lack an fbdev driver for the high-resolution console.}}<br />
<br />
== Background ==<br />
Previously, setting up the video card was the job of the X server. Because of this, it was not easily possible to have fancy graphics in virtual consoles. Also, each time a switch from X to a virtual console was made ({{ic|Ctrl+Alt+F1}}), the server had to give control over the video card to the kernel, which was slow and caused flickering. The same "painful" process happened when the control was given back to the X server ({{ic|Ctrl+Alt+F7}}).<br />
<br />
With Kernel Mode Setting (KMS), the kernel is now able to set the mode of the video card. This makes fancy graphics during bootup, virtual console and X fast switching possible, among other things.<br />
== Installation ==<br />
At first, note that for ''any'' method you use, you should ''always'' disable:<br />
* Any {{ic|<nowiki>vga=</nowiki>}} options in your bootloader as these will conflict with the native resolution enabled by KMS.<br />
* Any {{ic|<nowiki>video=</nowiki>}} lines that enable a framebuffer that conflicts with the driver.<br />
* Any other framebuffer drivers (such as [[uvesafb]]).<br />
<br />
=== Late KMS start===<br />
[[Intel]], [[Nouveau]] and [[ATI]] drivers already enable KMS automatically for all chipsets, so you need not install it manually.<br />
<br />
The proprietary [[NVIDIA]] and [[AMD Catalyst]] drivers do not use the open driver stack. In order to use KMS you should replace them with open source drivers.<br />
<br />
=== Early KMS start ===<br />
<br />
To load KMS as early as possible in boot process, add the module [[radeon]] (for ATI/AMD cards), [[Intel|i915]] (for Intel integrated graphics) or [[nouveau]] (for Nvidia cards) to the {{ic|MODULES}} line in {{ic|/etc/mkinitcpio.conf}}. For example:<br />
{{hc|/etc/mkinitcpio.conf|2=MODULES="... i915 ..."}}<br />
If you are using a custom EDID file (not applicable for the built-in resolutions), 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 />
Rebuild your kernel image (refer to the [[mkinitcpio]] article for more info):<br />
<br />
{{bc|# mkinitcpio -p <name of your kernel preset; e.g. ''linux''>}}<br />
<br />
==Troubleshooting==<br />
<br />
===My fonts are too tiny===<br />
See [[Fonts#Changing_the_default_font | changing the default font]] for how to change your console font to a large font. Terminus font in [community] is available in many sizes, including larger sizes.<br />
<br />
===Problem upon bootloading and dmesg===<br />
Polling for connected display devices on older systems can be quite expensive. Poll will happen periodically and can in worst cases take several hundred milliseconds, depending on the hardware. This will cause visible stalls, for example in video playback. These stalls might happen even when your video is on HDP output but you have other non HDP outputs in your hw configuration. If you experience stalls in display output occurring every 10 seconds, disabling polling might help.<br />
<br />
If you see an error code of {{ic|0x00000010 (2)}} while booting up, (You will get about 10 lines of text, the last part denoting that error code), then add the following line into {{ic|/etc/modprobe.d/modprobe.conf}}:<br />
options drm_kms_helper poll=0<br />
<br />
==Forcing modes and EDID==<br />
<br />
{{Note|This section is a WIP. Improvements and corrections are more than welcome}}<br />
<br />
In case that your monitor/TV is not sending the appropriate [[Wikipedia:EDID|EDID]] data or similar problems, you will notice that the native resolution is not automatically configured or no display at all. The kernel has a provision to load the binary EDID data, and provides as well data to set four of the most typical resolutions.<br />
<br />
If you have the EDID file for your monitor the process is easy. If you do not have, you can either use one of the built-in resolution-EDID binaries (or generate one during kernel compilation, [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/EDID/HOWTO.txt more info here]) or build your own EDID.<br />
<br />
In case you have an EDID file (e.g. extracted from Windows drivers for your monitor), create a dir {{ic|edid}} under {{ic|/usr/lib/firmware}}:<br />
<br />
# mkdir /usr/lib/firmware/edid<br />
<br />
and then copy your binary into the {{ic|/usr/lib/firmware/edid}} directory.<br />
<br />
To load it at boot, specify the following in the kernel command line:<br />
<br />
{{bc|1=drm_kms_helper.edid_firmware=edid/your_edid.bin}}<br />
<br />
You can also specify it only for a specified connection:<br />
<br />
{{bc|1=drm_kms_helper.edid_firmware=VGA-1:edid/your_edid.bin}}<br />
<br />
For the four built-in resolutions, see table below for the name to specify:<br />
<br />
{| class="wikitable"<br />
|-<br />
| '''Resolution''' || '''Name to specify''' <br />
|-<br />
| 1024x768 || edid/1024x768.bin <br />
|-<br />
| 1280x1024 || edid/1280x1024.bin <br />
|-<br />
| 1600x1200 (kernel 3.10 or higher) || edid/1600x1200.bin<br />
|-<br />
| 1680x1050 || edid/1680x1050.bin <br />
|-<br />
| 1920x1080 || edid/1920x1080.bin <br />
|}<br />
<br />
If you are doing early KMS, you must include the custom EDID file in the initramfs or you will run into problems.<br />
<br />
You can also construct your own EDID with the makefile included in the {{ic|Documentation/EDID}} sources of the kernel. The full information can be read [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/EDID/HOWTO.txt here] and [https://www.osadl.org/Single-View.111+M591850c02b5.0.html there].<br />
<br />
{{Warning|The method described below is somehow incomplete because e.g. Xorg does not take into account the resolution specified, so users are encouraged to use the method described above; however, specifying resolution with {{ic|1=video=}} command line may be useful in some scenarios}}<br />
<br />
From [http://nouveau.freedesktop.org/wiki/KernelModeSetting the nouveau wiki]:<br />
<br />
A mode can be forced on the kernel command line. Unfortunately, the command line option video is poorly documented in the DRM case. Bits and pieces on how to use it can be found in<br />
<br />
*http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/fb/modedb.txt<br />
*http://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/drm_fb_helper.c <br />
<br />
The format is: <br />
video=<conn>:<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]<br />
<br />
*<conn>: Connector, e.g. DVI-I-1, see {{ic|/sys/class/drm/}} for available connectors<br />
*<xres> x <yres>: resolution<br />
*M: compute a CVT mode?<br />
*R: reduced blanking?<br />
*-<bpp>: color depth<br />
*@<refresh>: refresh rate<br />
*i: interlaced (non-CVT mode)<br />
*m: margins?<br />
*e: output forced to on<br />
*d: output forced to off<br />
*D: digital output forced to on (e.g. DVI-I connector) <br />
<br />
You can override the modes of several outputs using "video" several times, for instance, to force DVI to 1024x768 at 85 Hz and TV-out off: <br />
video=DVI-I-1:1024x768@85 video=TV-1:d<br />
<br />
To get the name and current status of connectors, you can use the following shell oneliner:<br />
<br />
{{hc|<nowiki>for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done</nowiki>| <br />
DVI-I-1: connected<br />
HDMI-A-1: disconnected<br />
VGA-1: disconnected<br />
}}<br />
<br />
==Disabling modesetting==<br />
<br />
You may want to disable KMS for various reasons, such as getting a blank screen or a "no signal" error from the display, when using the Catalyst driver, etc. To disable KMS add {{ic|nomodeset}} as a kernel parameter. See [[Kernel parameters]] for more info.<br />
<br />
Along with {{ic|nomodeset}} kernel parameter, for Intel graphics card you need to add {{ic|1=i915.modeset=0}} and for Nvidia graphics card you need to add {{ic|1=nouveau.modeset=0}}. For Nvidia Optimus dual-graphics system, you need to add all the three kernel parameters (i.e. {{ic|1="nomodeset i915.modeset=0 nouveau.modeset=0"}}).<br />
<br />
{{Note|Some [[Xorg]] drivers will not work with KMS disabled. See the wiki page on your specific driver for details.}}</div>Ndthttps://wiki.archlinux.org/index.php?title=Kernel_mode_setting&diff=330842Kernel mode setting2014-08-18T00:23:56Z<p>Ndt: /* Installation */ oh god forgot nowiki tags</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:Kernel]]<br />
[[Category:X Server]]<br />
[[es:Kernel Mode Setting]]<br />
[[hu:Kernel Mode Setting]]<br />
[[ja:Kernel Mode Setting]]<br />
[[zh-CN:Kernel Mode Setting]]<br />
[[zh-TW:Kernel Mode Setting]]<br />
{{Related articles start}}<br />
{{Related|ATI}}<br />
{{Related|Intel graphics}}<br />
{{Related|Nouveau}}<br />
{{Related articles end}}<br />
{{Expansion|KMS and rootless X (1.16), see [[Talk:Kernel mode setting]] and [[Xorg#Rootless_Xorg_.28v1.16.29]].}}<br />
Kernel [[Wikipedia:Mode-setting|Mode Setting]] (KMS) is a method for setting display resolution and depth in the kernel space rather than user space.<br />
<br />
The Linux kernel's implementation of KMS enables native resolution in the framebuffer and allows for instant console (tty) switching. KMS also enables newer technologies (such as DRI2) which will help reduce artifacts and increase 3D performance, even kernel space power-saving.<br />
<br />
{{Note|The proprietary [[NVIDIA|nvidia]] and [[AMD Catalyst|catalyst]] drivers also implement kernel mode-setting, but as they do not use the built-in kernel implementation, they lack an fbdev driver for the high-resolution console.}}<br />
<br />
== Background ==<br />
Previously, setting up the video card was the job of the X server. Because of this, it was not easily possible to have fancy graphics in virtual consoles. Also, each time a switch from X to a virtual console was made ({{ic|Ctrl+Alt+F1}}), the server had to give control over the video card to the kernel, which was slow and caused flickering. The same "painful" process happened when the control was given back to the X server ({{ic|Ctrl+Alt+F7}}).<br />
<br />
With Kernel Mode Setting (KMS), the kernel is now able to set the mode of the video card. This makes fancy graphics during bootup, virtual console and X fast switching possible, among other things.<br />
== Installation ==<br />
At first, note that for ''any'' method you use, you should ''always'' disable:<br />
* Any {{ic|<nowiki>vga=</nowiki>}} options in your bootloader as these will conflict with the native resolution enabled by KMS.<br />
* Any {{ic|<nowiki>video=</nowiki>}} lines that enable a framebuffer that conflicts with the driver.<br />
* Any other framebuffer drivers (such as [[uvesafb]]).<br />
<br />
=== Late KMS start===<br />
[[Intel]], [[Nouveau]] and [[ATI]] drivers already enable KMS automatically for all chipsets, so you need not install it manually.<br />
<br />
The proprietary [[NVIDIA]] and [[AMD Catalyst]] drivers do not use the open driver stack. In order to use KMS you should replace them with open source drivers.<br />
<br />
=== Early KMS start ===<br />
<br />
To load KMS as early as possible in boot process, add the module [[radeon]] (for ATI/AMD cards), [[Intel|i915]] (for Intel integrated graphics) or [[nouveau]] (for Nvidia cards) to the {{ic|MODULES}} line in {{ic|/etc/mkinitcpio.conf}}. For example:<br />
{{hc|/etc/mkinitcpio.conf|2=MODULES="... i915 ..."}}<br />
If you are using a custom EDID file (not applicable for the built-in resolutions), 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 />
Rebuild your kernel image (refer to the [[mkinitcpio]] article for more info):<br />
<br />
{{bc|# mkinitcpio -p <name of your kernel preset; e.g. ''linux''>}}<br />
<br />
==Troubleshooting==<br />
<br />
===My fonts are too tiny===<br />
See [[Fonts#Changing_the_default_font | changing the default font]] for how to change your console font to a large font. Terminus font in [community] is available in many sizes, including larger sizes.<br />
<br />
===Problem upon bootloading and dmesg===<br />
Polling for connected display devices on older systems can be quite expensive. Poll will happen periodically and can in worst cases take several hundred milliseconds, depending on the hardware. This will cause visible stalls, for example in video playback. These stalls might happen even when your video is on HDP output but you have other non HDP outputs in your hw configuration. If you experience stalls in display output occurring every 10 seconds, disabling polling might help.<br />
<br />
If you see an error code of 0x00000010 (2) while booting up, (You will get about 10 lines of text, the last part denoting that error code), then add the following line into {{ic|/etc/modprobe.d/modprobe.conf}}:<br />
options drm_kms_helper poll=0<br />
<br />
==Forcing modes and EDID==<br />
<br />
{{Note|This section is a WIP. Improvements and corrections are more than welcome}}<br />
<br />
In case that your monitor/TV is not sending the appropriate [[Wikipedia:EDID|EDID]] data or similar problems, you will notice that the native resolution is not automatically configured or no display at all. The kernel has a provision to load the binary EDID data, and provides as well data to set four of the most typical resolutions.<br />
<br />
If you have the EDID file for your monitor the process is easy. If you do not have, you can either use one of the built-in resolution-EDID binaries (or generate one during kernel compilation, [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/EDID/HOWTO.txt more info here]) or build your own EDID.<br />
<br />
In case you have an EDID file (e.g. extracted from Windows drivers for your monitor), create a dir {{ic|edid}} under {{ic|/usr/lib/firmware}}:<br />
<br />
# mkdir /usr/lib/firmware/edid<br />
<br />
and then copy your binary into the {{ic|/usr/lib/firmware/edid}} directory.<br />
<br />
To load it at boot, specify the following in the kernel command line:<br />
<br />
{{bc|1=drm_kms_helper.edid_firmware=edid/your_edid.bin}}<br />
<br />
You can also specify it only for a specified connection:<br />
<br />
{{bc|1=drm_kms_helper.edid_firmware=VGA-1:edid/your_edid.bin}}<br />
<br />
For the four built-in resolutions, see table below for the name to specify:<br />
<br />
{| class="wikitable"<br />
|-<br />
| '''Resolution''' || '''Name to specify''' <br />
|-<br />
| 1024x768 || edid/1024x768.bin <br />
|-<br />
| 1280x1024 || edid/1280x1024.bin <br />
|-<br />
| 1600x1200 (kernel 3.10 or higher) || edid/1600x1200.bin<br />
|-<br />
| 1680x1050 || edid/1680x1050.bin <br />
|-<br />
| 1920x1080 || edid/1920x1080.bin <br />
|}<br />
<br />
If you are doing early KMS, you must include the custom EDID file in the initramfs or you will run into problems.<br />
<br />
You can also construct your own EDID with the makefile included in the {{ic|Documentation/EDID}} sources of the kernel. The full information can be read [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/EDID/HOWTO.txt here] and [https://www.osadl.org/Single-View.111+M591850c02b5.0.html there].<br />
<br />
{{Warning|The method described below is somehow incomplete because e.g. Xorg does not take into account the resolution specified, so users are encouraged to use the method described above; however, specifying resolution with {{ic|1=video=}} command line may be useful in some scenarios}}<br />
<br />
From [http://nouveau.freedesktop.org/wiki/KernelModeSetting the nouveau wiki]:<br />
<br />
A mode can be forced on the kernel command line. Unfortunately, the command line option video is poorly documented in the DRM case. Bits and pieces on how to use it can be found in<br />
<br />
*http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/fb/modedb.txt<br />
*http://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/drm_fb_helper.c <br />
<br />
The format is: <br />
video=<conn>:<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]<br />
<br />
*<conn>: Connector, e.g. DVI-I-1, see {{ic|/sys/class/drm/}} for available connectors<br />
*<xres> x <yres>: resolution<br />
*M: compute a CVT mode?<br />
*R: reduced blanking?<br />
*-<bpp>: color depth<br />
*@<refresh>: refresh rate<br />
*i: interlaced (non-CVT mode)<br />
*m: margins?<br />
*e: output forced to on<br />
*d: output forced to off<br />
*D: digital output forced to on (e.g. DVI-I connector) <br />
<br />
You can override the modes of several outputs using "video" several times, for instance, to force DVI to 1024x768 at 85 Hz and TV-out off: <br />
video=DVI-I-1:1024x768@85 video=TV-1:d<br />
<br />
To get the name and current status of connectors, you can use the following shell oneliner:<br />
<br />
{{hc|<nowiki>for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done</nowiki>| <br />
DVI-I-1: connected<br />
HDMI-A-1: disconnected<br />
VGA-1: disconnected<br />
}}<br />
<br />
==Disabling modesetting==<br />
<br />
You may want to disable KMS for various reasons, such as getting a blank screen or a "no signal" error from the display, when using the Catalyst driver, etc. To disable KMS add {{ic|nomodeset}} as a kernel parameter. See [[Kernel parameters]] for more info.<br />
<br />
Along with {{ic|nomodeset}} kernel parameter, for Intel graphics card you need to add {{ic|1=i915.modeset=0}} and for Nvidia graphics card you need to add {{ic|1=nouveau.modeset=0}}. For Nvidia Optimus dual-graphics system, you need to add all the three kernel parameters (i.e. {{ic|1="nomodeset i915.modeset=0 nouveau.modeset=0"}}).<br />
<br />
{{Note|Some [[Xorg]] drivers will not work with KMS disabled. See the wiki page on your specific driver for details.}}</div>Ndthttps://wiki.archlinux.org/index.php?title=Kernel_mode_setting&diff=330841Kernel mode setting2014-08-18T00:22:36Z<p>Ndt: /* Installation */ code in ic blocks</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:Kernel]]<br />
[[Category:X Server]]<br />
[[es:Kernel Mode Setting]]<br />
[[hu:Kernel Mode Setting]]<br />
[[ja:Kernel Mode Setting]]<br />
[[zh-CN:Kernel Mode Setting]]<br />
[[zh-TW:Kernel Mode Setting]]<br />
{{Related articles start}}<br />
{{Related|ATI}}<br />
{{Related|Intel graphics}}<br />
{{Related|Nouveau}}<br />
{{Related articles end}}<br />
{{Expansion|KMS and rootless X (1.16), see [[Talk:Kernel mode setting]] and [[Xorg#Rootless_Xorg_.28v1.16.29]].}}<br />
Kernel [[Wikipedia:Mode-setting|Mode Setting]] (KMS) is a method for setting display resolution and depth in the kernel space rather than user space.<br />
<br />
The Linux kernel's implementation of KMS enables native resolution in the framebuffer and allows for instant console (tty) switching. KMS also enables newer technologies (such as DRI2) which will help reduce artifacts and increase 3D performance, even kernel space power-saving.<br />
<br />
{{Note|The proprietary [[NVIDIA|nvidia]] and [[AMD Catalyst|catalyst]] drivers also implement kernel mode-setting, but as they do not use the built-in kernel implementation, they lack an fbdev driver for the high-resolution console.}}<br />
<br />
== Background ==<br />
Previously, setting up the video card was the job of the X server. Because of this, it was not easily possible to have fancy graphics in virtual consoles. Also, each time a switch from X to a virtual console was made ({{ic|Ctrl+Alt+F1}}), the server had to give control over the video card to the kernel, which was slow and caused flickering. The same "painful" process happened when the control was given back to the X server ({{ic|Ctrl+Alt+F7}}).<br />
<br />
With Kernel Mode Setting (KMS), the kernel is now able to set the mode of the video card. This makes fancy graphics during bootup, virtual console and X fast switching possible, among other things.<br />
== Installation ==<br />
At first, note that for ''any'' method you use, you should ''always'' disable:<br />
* Any {{ic|vga=}} options in your bootloader as these will conflict with the native resolution enabled by KMS.<br />
* Any {{ic|video=}} lines that enable a framebuffer that conflicts with the driver.<br />
* Any other framebuffer drivers (such as [[uvesafb]]).<br />
<br />
=== Late KMS start===<br />
[[Intel]], [[Nouveau]] and [[ATI]] drivers already enable KMS automatically for all chipsets, so you need not install it manually.<br />
<br />
The proprietary [[NVIDIA]] and [[AMD Catalyst]] drivers do not use the open driver stack. In order to use KMS you should replace them with open source drivers.<br />
<br />
=== Early KMS start ===<br />
<br />
To load KMS as early as possible in boot process, add the module [[radeon]] (for ATI/AMD cards), [[Intel|i915]] (for Intel integrated graphics) or [[nouveau]] (for Nvidia cards) to the {{ic|MODULES}} line in {{ic|/etc/mkinitcpio.conf}}. For example:<br />
{{hc|/etc/mkinitcpio.conf|2=MODULES="... i915 ..."}}<br />
If you are using a custom EDID file (not applicable for the built-in resolutions), 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 />
Rebuild your kernel image (refer to the [[mkinitcpio]] article for more info):<br />
<br />
{{bc|# mkinitcpio -p <name of your kernel preset; e.g. ''linux''>}}<br />
<br />
==Troubleshooting==<br />
<br />
===My fonts are too tiny===<br />
See [[Fonts#Changing_the_default_font | changing the default font]] for how to change your console font to a large font. Terminus font in [community] is available in many sizes, including larger sizes.<br />
<br />
===Problem upon bootloading and dmesg===<br />
Polling for connected display devices on older systems can be quite expensive. Poll will happen periodically and can in worst cases take several hundred milliseconds, depending on the hardware. This will cause visible stalls, for example in video playback. These stalls might happen even when your video is on HDP output but you have other non HDP outputs in your hw configuration. If you experience stalls in display output occurring every 10 seconds, disabling polling might help.<br />
<br />
If you see an error code of 0x00000010 (2) while booting up, (You will get about 10 lines of text, the last part denoting that error code), then add the following line into {{ic|/etc/modprobe.d/modprobe.conf}}:<br />
options drm_kms_helper poll=0<br />
<br />
==Forcing modes and EDID==<br />
<br />
{{Note|This section is a WIP. Improvements and corrections are more than welcome}}<br />
<br />
In case that your monitor/TV is not sending the appropriate [[Wikipedia:EDID|EDID]] data or similar problems, you will notice that the native resolution is not automatically configured or no display at all. The kernel has a provision to load the binary EDID data, and provides as well data to set four of the most typical resolutions.<br />
<br />
If you have the EDID file for your monitor the process is easy. If you do not have, you can either use one of the built-in resolution-EDID binaries (or generate one during kernel compilation, [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/plain/Documentation/EDID/HOWTO.txt more info here]) or build your own EDID.<br />
<br />
In case you have an EDID file (e.g. extracted from Windows drivers for your monitor), create a dir {{ic|edid}} under {{ic|/usr/lib/firmware}}:<br />
<br />
# mkdir /usr/lib/firmware/edid<br />
<br />
and then copy your binary into the {{ic|/usr/lib/firmware/edid}} directory.<br />
<br />
To load it at boot, specify the following in the kernel command line:<br />
<br />
{{bc|1=drm_kms_helper.edid_firmware=edid/your_edid.bin}}<br />
<br />
You can also specify it only for a specified connection:<br />
<br />
{{bc|1=drm_kms_helper.edid_firmware=VGA-1:edid/your_edid.bin}}<br />
<br />
For the four built-in resolutions, see table below for the name to specify:<br />
<br />
{| class="wikitable"<br />
|-<br />
| '''Resolution''' || '''Name to specify''' <br />
|-<br />
| 1024x768 || edid/1024x768.bin <br />
|-<br />
| 1280x1024 || edid/1280x1024.bin <br />
|-<br />
| 1600x1200 (kernel 3.10 or higher) || edid/1600x1200.bin<br />
|-<br />
| 1680x1050 || edid/1680x1050.bin <br />
|-<br />
| 1920x1080 || edid/1920x1080.bin <br />
|}<br />
<br />
If you are doing early KMS, you must include the custom EDID file in the initramfs or you will run into problems.<br />
<br />
You can also construct your own EDID with the makefile included in the {{ic|Documentation/EDID}} sources of the kernel. The full information can be read [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/EDID/HOWTO.txt here] and [https://www.osadl.org/Single-View.111+M591850c02b5.0.html there].<br />
<br />
{{Warning|The method described below is somehow incomplete because e.g. Xorg does not take into account the resolution specified, so users are encouraged to use the method described above; however, specifying resolution with {{ic|1=video=}} command line may be useful in some scenarios}}<br />
<br />
From [http://nouveau.freedesktop.org/wiki/KernelModeSetting the nouveau wiki]:<br />
<br />
A mode can be forced on the kernel command line. Unfortunately, the command line option video is poorly documented in the DRM case. Bits and pieces on how to use it can be found in<br />
<br />
*http://cgit.freedesktop.org/nouveau/linux-2.6/tree/Documentation/fb/modedb.txt<br />
*http://cgit.freedesktop.org/nouveau/linux-2.6/tree/drivers/gpu/drm/drm_fb_helper.c <br />
<br />
The format is: <br />
video=<conn>:<xres>x<yres>[M][R][-<bpp>][@<refresh>][i][m][eDd]<br />
<br />
*<conn>: Connector, e.g. DVI-I-1, see {{ic|/sys/class/drm/}} for available connectors<br />
*<xres> x <yres>: resolution<br />
*M: compute a CVT mode?<br />
*R: reduced blanking?<br />
*-<bpp>: color depth<br />
*@<refresh>: refresh rate<br />
*i: interlaced (non-CVT mode)<br />
*m: margins?<br />
*e: output forced to on<br />
*d: output forced to off<br />
*D: digital output forced to on (e.g. DVI-I connector) <br />
<br />
You can override the modes of several outputs using "video" several times, for instance, to force DVI to 1024x768 at 85 Hz and TV-out off: <br />
video=DVI-I-1:1024x768@85 video=TV-1:d<br />
<br />
To get the name and current status of connectors, you can use the following shell oneliner:<br />
<br />
{{hc|<nowiki>for p in /sys/class/drm/*/status; do con=${p%/status}; echo -n "${con#*/card?-}: "; cat $p; done</nowiki>| <br />
DVI-I-1: connected<br />
HDMI-A-1: disconnected<br />
VGA-1: disconnected<br />
}}<br />
<br />
==Disabling modesetting==<br />
<br />
You may want to disable KMS for various reasons, such as getting a blank screen or a "no signal" error from the display, when using the Catalyst driver, etc. To disable KMS add {{ic|nomodeset}} as a kernel parameter. See [[Kernel parameters]] for more info.<br />
<br />
Along with {{ic|nomodeset}} kernel parameter, for Intel graphics card you need to add {{ic|1=i915.modeset=0}} and for Nvidia graphics card you need to add {{ic|1=nouveau.modeset=0}}. For Nvidia Optimus dual-graphics system, you need to add all the three kernel parameters (i.e. {{ic|1="nomodeset i915.modeset=0 nouveau.modeset=0"}}).<br />
<br />
{{Note|Some [[Xorg]] drivers will not work with KMS disabled. See the wiki page on your specific driver for details.}}</div>Ndthttps://wiki.archlinux.org/index.php?title=Nftables&diff=330840Nftables2014-08-18T00:03:09Z<p>Ndt: /* Tables */ pretty table</p>
<hr />
<div>{{DISPLAYTITLE:nftables}}<br />
[[Category:Firewalls]]<br />
[[ja:Nftables]]<br />
{{Related articles start}}<br />
{{Related|Firewalls}}<br />
{{Related|iptables}}<br />
{{Related articles end}}<br />
[http://netfilter.org/projects/nftables/ nftables] is a netfilter project that aims to replace the existing ip-, ip6-, arp-, and ebtables framework. It provides a new packet filtering framework, a new user-space utility (nft), and a compatibility layer for ip- and ip6tables. It uses the existing hooks, connection tracking system, user-space queueing component, and logging subsystem of netfilter.<br />
<br />
The first release is available in Linux 3.13, which is in the ''core'' repository ({{Pkg|linux}}), and nftables (the user-space components) is available in the ''extra'' repository ({{Pkg|nftables}}), and on the [[AUR]] in package {{AUR|nftables-git}}.<br />
<br />
{{Expansion|nftables is an entirely new utility, and lacks sufficient documentation on this wiki, as well as elsewhere.}}<br />
<br />
==Overview==<br />
nftables consists of three main components: a kernel implementation, the libnl netlink communication and the nftables user-space front-end. The kernel provides a netlink configuration interface, as well as run-time rule-set evaluation using a small classification language interpreter. libnl contains the low-level functions for communicating with the kernel; the nftables front-end is what the user interacts with.<br />
<br />
==nft==<br />
nftables' user-space utility {{ic|nft}} now performs most of the rule-set evaluation before handing rule-sets to the kernel. Because of this, nftables provides no default tables or chains; although, a user can emulate an iptables-like setup.<br />
<br />
It works in a fashion similar to ifconfig or iproute2. The commands are a long, structured sequence rather than using argument switches like in iptables. For example:<br />
nft add rule ip6 filter input ip6 saddr ::1 accept<br />
{{ic|add}} is the command. {{ic|rule}} is a subcommand of {{ic|add}}. {{ic|ip6}} is an argument of {{ic|rule}}, telling it to use the ip6 family. {{ic|filter}} and {{ic|input}} are arguments of {{ic|rule}} specifying the table and chain to use, respectively. The rest that follows is a rule definition, which includes matches ({{ic|ip}}), their parameters ({{ic|saddr}}), parameter arguments ({{ic|::1}}), and jumps ({{ic|accept}}).<br />
<br />
The following is an incomplete list of the commands available in nft:<br />
<nowiki><br />
list<br />
tables [family]<br />
table [family] <name><br />
chain [family] <table> <name><br />
<br />
add<br />
table [family] <name><br />
chain [family] <table> <name> [chain definitions]<br />
rule [family] <table> <chain> <rule definition><br />
<br />
table [family] <name> (shortcut for `add table`)<br />
<br />
insert<br />
rule [family] <table> <chain> <rule definition><br />
<br />
delete<br />
table [family] <name><br />
chain [family] <table> <name><br />
rule [family] <table> <handle><br />
<br />
flush<br />
table [family] <name><br />
chain [family] <table> <name></nowiki><br />
{{ic|family}} is optional, but it will default to {{ic|ip}}.<br />
<br />
==Tables==<br />
The purpose of tables is to hold chains. Unlike tables in iptables, there are no built-in tables in nftables. Tables can have one of four families specified, which unifies the various iptables utilities into one:<br />
<br />
{| class="wikitable"<br />
! nftables family || iptables utility<br />
|-<br />
| ip || iptables<br />
|-<br />
| ip6 || ip6tables<br />
|-<br />
| arp || arptables<br />
|-<br />
| bridge || ebtables<br />
|}<br />
<br />
{{ic|ip}} is the default family.<br />
A fifth family is scheduled for Linux 3.15 that allows for the unification of the ip and ip6 families to make defining rules for both easier.<br />
<br />
===Listing===<br />
You can list the current tables in a family with the {{ic|nft list}} command.<br />
# nft list tables<br />
# nft list tables ip6<br />
<br />
You can list a full table definition by specifying a table name:<br />
# nft list table foo<br />
# nft list table ip6 foo<br />
<br />
===Creation===<br />
Tables can be added via two commands — one just being a shortcut for the other. Here is an example of how to add an ip table called foo and an ip6 table called foo:<br />
# nft add table foo<br />
# nft table ip6 foo<br />
You can have two tables with the same name as long as they are in different families.<br />
<br />
===Deletion===<br />
Tables can only be deleted if there are no chains in them.<br />
# nft delete table foo<br />
# nft delete table ip6 foo<br />
<br />
==Chains==<br />
The purpose of chains is to hold rules. Unlike chains in iptables, there are no built-in chains in nftables. This means that if no chain uses any types or hooks in the netfilter framework, packets that would flow through those chains will not be touched by nftables, unlike iptables.<br />
<br />
===Listing===<br />
The {{ic|nft list table foo}} command will list all the chains in the foo table. You can also list rules from an individual chain.<br />
# nft list chain foo bar<br />
# nft list chain ip6 foo bar<br />
These commands will list the {{ic|bar}} chains in the ip and ip6 {{ic|foo}} tables.<br />
<br />
===Creation===<br />
Chains can be added when a table is created in a file definition or one at time via the {{ic|nft add chain}} command.<br />
# nft add chain foo bar<br />
# nft add chain ip6 foo bar<br />
These commands will add a chain called {{ic|bar}} to the ip and ip6 {{ic|foo}} tables.<br />
<br />
====Properties====<br />
Because nftables has no built-in chains, it allows chains to access certain features of the netfilter framework.<br />
# nft add chain filter input { type filter hook input priority 0\; }<br />
This command tells nftables to add a chain called {{ic|input}} to the {{ic|filter}} table and defines its type, hook, and priority. These properties essentially replace the built-in tables and chains in iptables.<br />
<br />
=====Types=====<br />
There are three types a chain can have and they correspond to the tables used in iptables:<br />
*filter<br />
*nat<br />
*route (mangle)<br />
<br />
=====Hooks=====<br />
There are five hooks a chain can use and they correspond to the chains used in iptables:<br />
*input<br />
*output<br />
*forward<br />
*prerouting<br />
*postrouting<br />
<br />
=====Priorities=====<br />
{{Note|Priorities do not currently appear to have any effect on which chain sees packets first.}}<br />
{{Note|Since the priority seems to be an unsigned integer, negative priorities will be converted into very high priorities.}}<br />
Priorities tell nftables which chains packets should pass through first. They are integers, and the higher the integer, the higher the priority.<br />
<br />
===Deletion===<br />
Chains can only be deleted if there are no rules in them.<br />
# nft delete chain foo bar<br />
# nft delete chain ip6 foo bar<br />
These commands delete the {{ic|bar}} chains from the ip and ip6 {{ic|foo}} tables.<br />
<br />
==Rules==<br />
The purpose of rules is to identify packets (match) and carry out tasks (jump). Like in iptables, there are various matches and jumps available, though not all of them are feature-complete in nftables.<br />
<br />
===Listing===<br />
You can list the current rules in a table with the {{ic|nft list}} command, using the same method as listing a table. You can also list rules from an individual chain.<br />
# nft list chain foo bar<br />
# nft list chain ip6 foo bar<br />
These commands will list the rules in the {{ic|bar}} chains in the ip and ip6 {{ic|foo}} tables.<br />
<br />
===Creation===<br />
Rules can be added when a table is created in a file definition or one at time via the {{ic|nft add rule}} command.<br />
# nft add rule foo bar ip saddr 127.0.0.1 accept<br />
# nft add rule ip6 foo bar ip saddr ::1 accept<br />
These commands will add a rule to the {{ic|bar}} chains in the ip and ip6 {{ic|foo}} tables that matches an {{ic|ip}} packet when its {{ic|saddr}} (source address) is 127.0.0.1 (IPv4) or ::1 (IPv6) and accepts those packets.<br />
<br />
====Matches====<br />
There are various matches available in nftables and, for the most part, coincide with their iptables counterparts. The most noticeable difference is that there are no generic or implicit matches anymore. A generic match was one that was always available, such as {{ic|--protocol}} or {{ic|--source}}. Implicit matches were protocol-specific, such as {{ic|--sport}} when a packet was determined to be TCP.<br />
<br />
The following is an incomplete list of the matches available:<br />
*meta (meta properties, e.g. interfaces)<br />
*icmp (ICMP protocol)<br />
*icmpv6 (ICMPv6 protocol)<br />
*ip (IP protocol)<br />
*ip6 (IPv6 protocol)<br />
*tcp (TCP protocol)<br />
*udp (UDP protocol)<br />
*sctp (SCTP protocol)<br />
*ct (connection tracking)<br />
<br />
The following is an incomplete list of match arguments:<br />
<nowiki><br />
meta:<br />
oif <output interface INDEX><br />
iif <input interface INDEX><br />
oifname <output interface NAME><br />
iifname <input interface NAME><br />
<br />
(oif and iif accept string arguments and are converted to interface indexes)<br />
(oifname and iifname are more dynamic, but slower because of string matching)<br />
<br />
icmp:<br />
type <icmp type><br />
<br />
icmpv6:<br />
type <icmpv6 type><br />
<br />
ip:<br />
protocol <protocol><br />
daddr <destination address><br />
saddr <source address><br />
<br />
ip6:<br />
daddr <destination address><br />
saddr <source address><br />
<br />
tcp:<br />
dport <destination port><br />
sport <source port><br />
<br />
udp:<br />
dport <destination port><br />
sport <source port><br />
<br />
sctp:<br />
dport <destination port><br />
sport <source port><br />
<br />
ct:<br />
state <new | established | related | invalid></nowiki><br />
<br />
====Jumps====<br />
Jumps work the same as they do in iptables, except multiple jumps can now be used in one rule.<br />
# nft add rule filter input tcp dport 22 log accept<br />
<br />
The following is an incomplete list of jumps:<br />
*accept (accept a packet)<br />
*reject (reject a packet)<br />
*drop (drop a packet)<br />
*snat (perform source NAT on a packet)<br />
*dnat (perform destination NAT on a packet)<br />
*log (log a packet)<br />
*counter (keep a counter on a packet; counters are optional in nftables)<br />
*return (stop traversing the chain)<br />
<br />
===Insertion===<br />
Rules can be prepended to chains with the {{ic|nft insert rule}} command.<br />
# nft insert rule filter input ct state established,related accept<br />
<br />
===Deletion===<br />
Individual rules can only be deleted by their handles. The {{ic|nft --handle list}} command must be used to determine rule handles. Note the {{ic|--handle}} switch, which tells {{ic|nft}} to list handles in its output.<br />
<br />
The following determines the handle for a rule and then deletes it. The {{ic|--number}} argument is useful for viewing some numeric output, like unresolved IP addresses.<br />
{{hc|# nft --handle --numeric list chain filter input|2=<br />
<nowiki><br />
table ip filter {<br />
chain input {<br />
type filter hook input priority 0;<br />
ip saddr 127.0.0.1 accept # handle 10<br />
}<br />
}<br />
</nowiki><br />
}}<br />
# nft delete rule filter input handle 10<br />
<br />
All the chains in a table can be flushed with the {{ic|nft flush table}} command. Individual chains can be flushed using either the {{ic|nft flush chain}} or {{ic|nft delete rule}} commands.<br />
# nft flush table foo<br />
# nft flush chain foo bar<br />
# nft delete rule ip6 foo bar<br />
The first command flushes all of the chains in the ip {{ic|foo}} table. The second flushes the {{ic|bar}} chain in the ip {{ic|foo}} table. The third deletes all of the rules in {{ic|bar}} chain in the ip6 {{ic|foo}} table.<br />
<br />
==File Definitions==<br />
{{Warning|The {{ic|nft -f}} command, despite what the [http://people.netfilter.org/wiki-nftables/index.php/Atomic_rule_replacement netfilter wiki] says, is '''NOT''' atomic. This means you will have a small window between deleting the old tables and when the new ruleset is loaded where all packets will be accepted.}}<br />
{{Note|You must delete all conflicting tables before using the {{ic|nft -f}} command.}}<br />
File definitions can be used by the {{ic|nft -f}} command, which acts like the {{ic|iptables-restore}} command.<br />
{{hc|/etc/nftables/filter.rules|2=<br />
<nowiki><br />
table ip filter {<br />
chain input {<br />
type filter hook input priority 0;<br />
ct state established,related accept<br />
ip saddr 127.0.0.1 accept<br />
tcp dport 22 log accept<br />
reject<br />
}<br />
}<br />
</nowiki><br />
}}<br />
<br />
==Getting Started==<br />
To get an [[iptables]]-like chain set up, you will first need to use the provided IPv4 filter file:<br />
<br />
# nft -f /etc/nftables/ipv4-filter<br />
<br />
To list the resulting chain:<br />
<br />
# nft list table filter<br />
<br />
Drop output to a destination:<br />
<br />
# nft add rule ip filter output ip daddr 1.2.3.4 drop<br />
<br />
Drop packets destined for local port 80:<br />
<br />
# nft add rule ip filter input tcp dport 80 drop<br />
<br />
Delete all rules in a chain:<br />
<br />
# nft delete rule filter output<br />
<br />
==Samples==<br />
===Simple IP/IPv6 Firewall===<br />
{{hc|firewall.rules|2=<br />
<nowiki><br />
# A simple firewall<br />
<br />
table firewall {<br />
chain incoming {<br />
type filter hook input priority 0;<br />
<br />
# established/related connections<br />
ct state {established, related} accept<br />
<br />
# invalid connections<br />
ct state invalid drop<br />
<br />
# loopback interface<br />
iifname lo accept<br />
<br />
# icmp<br />
ip protocol icmp accept<br />
<br />
# open tcp ports: sshd (22), httpd (80)<br />
tcp dport {ssh, http} accept<br />
<br />
# everything else<br />
reject<br />
}<br />
}<br />
<br />
table ip6 firewall {<br />
chain incoming {<br />
type filter hook input priority 0;<br />
<br />
# established/related connections<br />
ct state {established, related} accept<br />
<br />
# invalid connections<br />
ct state invalid drop<br />
<br />
# loopback interface<br />
iifname lo accept<br />
<br />
# icmp<br />
ip6 nexthdr icmpv6 accept<br />
<br />
# open tcp ports: sshd (22), httpd (80)<br />
tcp dport {ssh, http} accept<br />
<br />
# everything else<br />
reject<br />
}<br />
}<br />
</nowiki><br />
}}<br />
<br />
===Limit rate and tcp flags IP/IPv6 Firewall===<br />
{{hc|firewall.2.rules|2=<br />
<nowiki><br />
table firewall {<br />
chain incoming {<br />
type filter hook input priority 0;<br />
<br />
# bad tcp -> avoid network scanning:<br />
tcp flags & (fin|syn) == (fin|syn) drop<br />
tcp flags & (syn|rst) == (syn|rst) drop<br />
tcp flags & (fin|syn|rst|psh|ack|urg) < (fin) drop # == 0 would be better, not supported yet.<br />
tcp flags & (fin|syn|rst|psh|ack|urg) == (fin|psh|urg) drop<br />
<br />
# no ping floods:<br />
ip protocol icmp limit rate 10/second accept<br />
ip protocol icmp drop<br />
<br />
ct state {established, related} accept<br />
ct state invalid drop<br />
<br />
iifname lo accept<br />
<br />
# avoid brute force on ssh:<br />
tcp dport {ssh} limit rate 15/minute accept<br />
<br />
reject<br />
}<br />
}<br />
<br />
table ip6 firewall {<br />
chain incoming {<br />
type filter hook input priority 0;<br />
<br />
# bad tcp:<br />
tcp flags & (fin|syn) == (fin|syn) drop<br />
tcp flags & (syn|rst) == (syn|rst) drop<br />
tcp flags & (fin|syn|rst|psh|ack|urg) < (fin) drop # == 0 would be better, not supported yet.<br />
tcp flags & (fin|syn|rst|psh|ack|urg) == (fin|psh|urg) drop<br />
<br />
# no ping floods:<br />
ip6 nexthdr icmpv6 limit rate 10/second accept<br />
ip6 nexthdr icmpv6 drop<br />
<br />
ct state {established, related} accept<br />
ct state invalid drop<br />
<br />
# loopback interface<br />
iifname lo accept<br />
<br />
# avoid brute force on ssh:<br />
tcp dport {ssh} limit rate 15/minute accept<br />
<br />
reject<br />
}<br />
}<br />
</nowiki><br />
}}<br />
<br />
===Priority-based Atomic Fix===<br />
If priorities ever actually take effect, this may be a workaround for {{ic|nft -f}}'s lack of true atomicness (being able to replace all the current rules with new ones in one go):<br />
{{hc|atomic.rules|2=<br />
table atomic {<br />
chain incoming {<br />
type filter hook input priority 0;<br />
ct state new reject<br />
}<br />
}<br />
<br />
table ip6 atomic {<br />
chain incoming {<br />
type filter hook input priority 0;<br />
ct state new reject<br />
}<br />
}<br />
}}<br />
Set the priority of other chains that hook input to higher than 0. This should block new connections while no other input chains are loaded.<br />
<br />
===Rules Script with Atomic Fix===<br />
Because using {{ic|nft -f}} to reload rulesets is time consuming, it's far easier to script it. This will include an atomic fix not based on priorities. It uses the two rules files from above.<br />
{{hc|firewall.sh|2=<br />
#!/bin/sh<br />
<br />
# Load atomic rules first<br />
nft -f atomic.rules<br />
<br />
# New incoming traffic should now be stopped<br />
<br />
# Get rid of both the ip and ip6 firewall tables<br />
<br />
nft flush table firewall 2>/dev/null<br />
nft delete chain firewall incoming 2>/dev/null<br />
nft delete table firewall 2>/dev/null<br />
<br />
nft flush table ip6 firewall 2>/dev/null<br />
nft delete chain ip6 firewall incoming 2>/dev/null<br />
nft delete table ip6 firewall 2>/dev/null<br />
<br />
# Reload the firewall rules<br />
nft -f firewall.rules<br />
<br />
# Get rid of both the ip and ip6 atomic tables<br />
<br />
nft flush table atomic 2>/dev/null<br />
nft delete chain atomic incoming 2>/dev/null<br />
nft delete table atomic 2>/dev/null<br />
<br />
# New incoming IP traffic should be working<br />
<br />
nft flush table ip6 atomic 2>/dev/null<br />
nft delete chain ip6 atomic incoming 2>/dev/null<br />
nft delete table ip6 atomic 2>/dev/null<br />
<br />
# New incoming IPv6 traffic should be working<br />
}}<br />
This should take anywhere from 100ms to 400ms, which is clearly unacceptable, but the only apparent solution.<br />
<br />
==Loading rules at boot==<br />
<br />
To automatically load rules on system boot, {{AUR|nftables-systemd-git}} can be used.<br />
Further install instructions can be found on the corresponding [https://github.com/devkid/nftables-systemd github page].<br />
<br />
{{Note|While the name suggests that it works only for systemd, it can be adapted for other init systems as well.}}<br />
<br />
{{Note|You may have to create {{ic|/etc/modules-load.d/nftables.conf}} with all of the nftables related modules you require as entries for the systemd service to work correctly. You can get a list of modules using this command: {{bc|<nowiki>lsmod | grep nf</nowiki>}} <br />
<br />
Otheriwse, you could end up with the dreaded {{ic|Error: Could not process rule: No such file or directory}} error.}}<br />
<br />
==Logging to Syslog==<br />
<br />
For logging to Syslog, the {{ic|xt_LOG}} module needs to be loaded.<br />
<br />
==See also==<br />
* [http://people.netfilter.org/wiki-nftables/index.php/ netfilter nftables wiki]<br />
* [https://lwn.net/Articles/324251/ First release of nftables]<br />
* [https://home.regit.org/netfilter-en/nftables-quick-howto/ nftables quick howto]<br />
* [https://lwn.net/Articles/564095/ The return of nftables]</div>Ndthttps://wiki.archlinux.org/index.php?title=User_talk:Ndt&diff=330709User talk:Ndt2014-08-16T22:14:42Z<p>Ndt: /* Password advice */ typo</p>
<hr />
<div>== Nice Addition to Security Page! ==<br />
<br />
Hi Ndt,<br />
<br />
I just wanted to thank you for the edit to the [[Security#Disk_encryption]] page. I definitely think your additions and changes clarified that section.<br />
<br />
Cheers!<br />
<br />
[[User:AdamT|AdamT]] ([[User talk:AdamT|talk]]) 00:53, 30 June 2013 (UTC)<br />
<br />
:AdamT,<br />
<br />
:Thanks for the feedback! I've been working on improving that page in my free time over the past couple of weeks, and I was really glad to see that you appreciated my early edits.<br />
<br />
:Much appreciated,<br />
<br />
:[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 01:36, 10 July 2013 (UTC)<br />
<br />
== Questions on DisplayLink ==<br />
<br />
Thank you for your contribution to the [[DisplayLink]] wiki page! I am planning on buying a ThinkVision LT1421 as well, but I am just wondering...are you able to see the DisplayLink device in the output of xrandr? Is it possible to simply turn on and specify the relative position of DisplayLink display by using xrandr instead of Xinerama? Thanks! If you would kindly reply by writing on my discussion page or email me at [...] that would be great! Thanks in advance! --[[User:Jiehanzheng|Jiehanzheng]] ([[User talk:Jiehanzheng|talk]]) 22:43, 8 June 2013 (UTC)<br />
<br />
:Hey Jiehan,<br />
<br />
:You can see my progress on DisplayLink on Arch detailed here. Unfortunately nobody replied, and a true solution was never achieved. It looks like true two-monitor DisplayLink support is still in its early days on Linux.<br />
<br />
:No, I'm not able to see the output on xrandr: I have only been able to get it working by running two separate X servers and making them talk using the ancient x2x tool (1998 or something). I'm still planning on updating the wiki page more to reflect these changes, but for now I've had little luck.<br />
<br />
:Kernel level support is good, and getting better as udl (the recent rewrite, I think driven by Red Hat) slowly replaces udlfb, but it's a process.<br />
<br />
:Supposedly there was a working driver for X back in the day, called xf86-video-displaylink, but since recent X.org updates (bug 50762) that driver won't even compile. I've been working on improving my C skills to see if I can go in and fix that driver myself, but even if I can (which is no guarantee) it'll still probably take a few months. Presumably, this driver would enable xrandr to work and everything to be nice and pretty.<br />
<br />
:Suggestion: don't buy that Lenovo monitor. I own it. Support is garbage on Linux. Unless you're a kernel hacker who also is deeply familiar with writing Xorg display drivers, I would highly suggest against it.<br />
<br />
:I don't suspect we are going to see ''anything'' in the vein of working USB display hotplugging under Linux until early-mid 2014.<br />
<br />
:The exception to this rule is if you want single-monitor support. I plan on picking up a Raspberry Pi (or similar device with wifi capabilities) and setting it up with my ThinkVision and and one of those ThinkPad USB keyboards and making my own lightweight ThinkPad. That's a cool project and it will make the display worth owning. If you want it for the purpose of running a dual-monitor xorg, though, avoid the ThinkVision at all costs.<br />
<br />
:[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 17:02, 9 June 2013 (UTC)<br />
<br />
==Netcfg/Wireless networking/Wireless Setup==<br />
Hi, I'd like to understand what you've done to [[Netcfg]] (then renamed [[Wireless networking]]): is it possible that you've just copy-pasted there the content of [[Wireless Setup]] also doing [https://wiki.archlinux.org/index.php/Special:ComparePages?page1=Wireless+Setup&rev1=&page2=Wireless+networking&rev2=&action=&diffonly=&unhide= some changes] in the same edit? If that's the case, it's not how you should have handled it, this way you've duplicated an article and lost all of its history in its copy: you should have requested the deletion of [[Netcfg]], then you could have ''moved'' [[Wireless Setup]] to a new title if you felt there was a better one, like [[Wireless networking]], and then you should have performed further adaptations. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:27, 16 July 2013 (UTC)<br />
<br />
(And anyway [[Netcfg]] should better be redirected to [[Netctl]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:30, 16 July 2013 (UTC))<br />
<br />
:Hi,<br />
:I am incredibly sorry about my changes to the Netcfg page. That was stupid, and it was supposed to be an edit to [[Wireless Setup]] that removes netcfg references. Please do not waste your time trying to understand the edit; it was on the wrong page and should be redirected as you stated.<br />
:Good thing it happened on the the [[Netcfg]] page, at least. I would be even more upset with myself had I done it to a page that matters more.<br />
:Thank you for being polite about it, however. I appreciate you giving me the benefit of the doubt. I will be considerably more careful about this in the future.<br />
:[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 14:19, 16 July 2013 (UTC)<br />
:Looking at the change history for that page, now (and the subsequent renaming), I can see why this must be ridiculously unusual for a wiki administrator. ''Thank you for trying to understand this.'' I think what should happen is the new [[Wireless networking]]/[[Netcfg]] page be renamed back to [[Netcfg]], then setup to properly redirect to [[Netctl]]. Subsequently, [[Wireless networking]] should redirect to [[Wireless Setup]].<br />
:This is only my suggestion, of course, but I appreciate your work in getting this resolved. [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 14:27, 16 July 2013 (UTC)<br />
<br />
::No worries, I learnt to appreciate your edits in the recent days, so I was surprised to see you doing that, there surely had to be some reason behind :)<br />
::It should all be fixed now, I've moved here your reply as explained in [[Help:Discussion#User talk pages]].<br />
::One last thing: is it possible that you're using an external editor for editing the articles? That would explain how you've managed to paste the entire page into another one... Also, ''note well'', that would explain why you removed some space-only lines in [[Wireless Setup]], as it's probably been done automatically by your editor: always review your edits because sometimes space-only lines ''are'' meaningful for MediaWiki, see for example:<br />
<br />
code<br />
<br />
code<br />
<br />
code<br />
<br />
::(look at the source text)<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:44, 16 July 2013 (UTC)<br />
<br />
::: Thanks for the reply. Yes, occasionally use vim for my edits, if I find the default editor is not powerful enough. Unfortunately, I am not very experienced with wiki editing in general (I am not sure I had ever edited a wiki page before Arch) so I have obviously made a couple of mistakes with the software. I am going to do some research in properly setting up my editor and will more closely review my edits until I have ironed out these kinks.<br />
<br />
::: I do really strive to make high-quality edits, however, so I appreciate your help in climbing this learning curve. Not that it is exceptionally difficult; I am just new.<br />
::: --[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 17:04, 16 July 2013 (UTC)<br />
<br />
== Password advice ==<br />
<br />
I do agree with both of your edits<br />
[https://wiki.archlinux.org/index.php?title=Security&curid=10081&diff=330507&oldid=330506 #1]<br />
[https://wiki.archlinux.org/index.php?title=Security&curid=10081&diff=330506&oldid=328095 #2]<br />
, and I'd like to hear what advice you give about modern password complextiy, length and character components (since you removed both countering advices). If possible, let's fill the void in the [[Security]] article in regards to password advice.<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 08:05, 16 August 2014 (UTC)<br />
<br />
:Thanks for the feedback. Of course - I'm fairly busy right now, but give me a day or two and I'll put some effort into making it better. [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 22:00, 16 August 2014 (UTC)<br />
<br />
<br />
:In the meantime, I will mention my personal strategy for passwords: I use a password database ({{Pkg|pass}} which uses [[GnuPG]]) and memorize long, randomly generated passwords that encrypt it. I do '''not''' change my passwords without reason, since this is a barrier to memorizing complex ones and I need at least a handful in memory for adequate security. This probably is not for everyone, however, so I won't just go dumping it into the article without further consideration.<br />
:The way I memorize a long random passphrase is this: I set my initial password to the longest number of characters that I can easily remember, and write the full generated password down and put it in my wallet. Over the next week or two, I periodically add characters to the ''in use'' password until I have memorized a 16-20 digit random password. Then, if it's a password I'll use often enough to remember, I destroy the piece of paper.<br />
:Using this technique, I can memorize passwords that are cryptographically secure and not based on dictionary words, sentences, or anything else that humans would come up with. [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 22:13, 16 August 2014 (UTC)</div>Ndthttps://wiki.archlinux.org/index.php?title=User_talk:Ndt&diff=330708User talk:Ndt2014-08-16T22:13:30Z<p>Ndt: /* Password advice */ re @ axper #2</p>
<hr />
<div>== Nice Addition to Security Page! ==<br />
<br />
Hi Ndt,<br />
<br />
I just wanted to thank you for the edit to the [[Security#Disk_encryption]] page. I definitely think your additions and changes clarified that section.<br />
<br />
Cheers!<br />
<br />
[[User:AdamT|AdamT]] ([[User talk:AdamT|talk]]) 00:53, 30 June 2013 (UTC)<br />
<br />
:AdamT,<br />
<br />
:Thanks for the feedback! I've been working on improving that page in my free time over the past couple of weeks, and I was really glad to see that you appreciated my early edits.<br />
<br />
:Much appreciated,<br />
<br />
:[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 01:36, 10 July 2013 (UTC)<br />
<br />
== Questions on DisplayLink ==<br />
<br />
Thank you for your contribution to the [[DisplayLink]] wiki page! I am planning on buying a ThinkVision LT1421 as well, but I am just wondering...are you able to see the DisplayLink device in the output of xrandr? Is it possible to simply turn on and specify the relative position of DisplayLink display by using xrandr instead of Xinerama? Thanks! If you would kindly reply by writing on my discussion page or email me at [...] that would be great! Thanks in advance! --[[User:Jiehanzheng|Jiehanzheng]] ([[User talk:Jiehanzheng|talk]]) 22:43, 8 June 2013 (UTC)<br />
<br />
:Hey Jiehan,<br />
<br />
:You can see my progress on DisplayLink on Arch detailed here. Unfortunately nobody replied, and a true solution was never achieved. It looks like true two-monitor DisplayLink support is still in its early days on Linux.<br />
<br />
:No, I'm not able to see the output on xrandr: I have only been able to get it working by running two separate X servers and making them talk using the ancient x2x tool (1998 or something). I'm still planning on updating the wiki page more to reflect these changes, but for now I've had little luck.<br />
<br />
:Kernel level support is good, and getting better as udl (the recent rewrite, I think driven by Red Hat) slowly replaces udlfb, but it's a process.<br />
<br />
:Supposedly there was a working driver for X back in the day, called xf86-video-displaylink, but since recent X.org updates (bug 50762) that driver won't even compile. I've been working on improving my C skills to see if I can go in and fix that driver myself, but even if I can (which is no guarantee) it'll still probably take a few months. Presumably, this driver would enable xrandr to work and everything to be nice and pretty.<br />
<br />
:Suggestion: don't buy that Lenovo monitor. I own it. Support is garbage on Linux. Unless you're a kernel hacker who also is deeply familiar with writing Xorg display drivers, I would highly suggest against it.<br />
<br />
:I don't suspect we are going to see ''anything'' in the vein of working USB display hotplugging under Linux until early-mid 2014.<br />
<br />
:The exception to this rule is if you want single-monitor support. I plan on picking up a Raspberry Pi (or similar device with wifi capabilities) and setting it up with my ThinkVision and and one of those ThinkPad USB keyboards and making my own lightweight ThinkPad. That's a cool project and it will make the display worth owning. If you want it for the purpose of running a dual-monitor xorg, though, avoid the ThinkVision at all costs.<br />
<br />
:[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 17:02, 9 June 2013 (UTC)<br />
<br />
==Netcfg/Wireless networking/Wireless Setup==<br />
Hi, I'd like to understand what you've done to [[Netcfg]] (then renamed [[Wireless networking]]): is it possible that you've just copy-pasted there the content of [[Wireless Setup]] also doing [https://wiki.archlinux.org/index.php/Special:ComparePages?page1=Wireless+Setup&rev1=&page2=Wireless+networking&rev2=&action=&diffonly=&unhide= some changes] in the same edit? If that's the case, it's not how you should have handled it, this way you've duplicated an article and lost all of its history in its copy: you should have requested the deletion of [[Netcfg]], then you could have ''moved'' [[Wireless Setup]] to a new title if you felt there was a better one, like [[Wireless networking]], and then you should have performed further adaptations. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:27, 16 July 2013 (UTC)<br />
<br />
(And anyway [[Netcfg]] should better be redirected to [[Netctl]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:30, 16 July 2013 (UTC))<br />
<br />
:Hi,<br />
:I am incredibly sorry about my changes to the Netcfg page. That was stupid, and it was supposed to be an edit to [[Wireless Setup]] that removes netcfg references. Please do not waste your time trying to understand the edit; it was on the wrong page and should be redirected as you stated.<br />
:Good thing it happened on the the [[Netcfg]] page, at least. I would be even more upset with myself had I done it to a page that matters more.<br />
:Thank you for being polite about it, however. I appreciate you giving me the benefit of the doubt. I will be considerably more careful about this in the future.<br />
:[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 14:19, 16 July 2013 (UTC)<br />
:Looking at the change history for that page, now (and the subsequent renaming), I can see why this must be ridiculously unusual for a wiki administrator. ''Thank you for trying to understand this.'' I think what should happen is the new [[Wireless networking]]/[[Netcfg]] page be renamed back to [[Netcfg]], then setup to properly redirect to [[Netctl]]. Subsequently, [[Wireless networking]] should redirect to [[Wireless Setup]].<br />
:This is only my suggestion, of course, but I appreciate your work in getting this resolved. [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 14:27, 16 July 2013 (UTC)<br />
<br />
::No worries, I learnt to appreciate your edits in the recent days, so I was surprised to see you doing that, there surely had to be some reason behind :)<br />
::It should all be fixed now, I've moved here your reply as explained in [[Help:Discussion#User talk pages]].<br />
::One last thing: is it possible that you're using an external editor for editing the articles? That would explain how you've managed to paste the entire page into another one... Also, ''note well'', that would explain why you removed some space-only lines in [[Wireless Setup]], as it's probably been done automatically by your editor: always review your edits because sometimes space-only lines ''are'' meaningful for MediaWiki, see for example:<br />
<br />
code<br />
<br />
code<br />
<br />
code<br />
<br />
::(look at the source text)<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:44, 16 July 2013 (UTC)<br />
<br />
::: Thanks for the reply. Yes, occasionally use vim for my edits, if I find the default editor is not powerful enough. Unfortunately, I am not very experienced with wiki editing in general (I am not sure I had ever edited a wiki page before Arch) so I have obviously made a couple of mistakes with the software. I am going to do some research in properly setting up my editor and will more closely review my edits until I have ironed out these kinks.<br />
<br />
::: I do really strive to make high-quality edits, however, so I appreciate your help in climbing this learning curve. Not that it is exceptionally difficult; I am just new.<br />
::: --[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 17:04, 16 July 2013 (UTC)<br />
<br />
== Password advice ==<br />
<br />
I do agree with both of your edits<br />
[https://wiki.archlinux.org/index.php?title=Security&curid=10081&diff=330507&oldid=330506 #1]<br />
[https://wiki.archlinux.org/index.php?title=Security&curid=10081&diff=330506&oldid=328095 #2]<br />
, and I'd like to hear what advice you give about modern password complextiy, length and character components (since you removed both countering advices). If possible, let's fill the void in the [[Security]] article in regards to password advice.<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 08:05, 16 August 2014 (UTC)<br />
<br />
:Thanks for the feedback. Of course - I'm fairly busy right now, but give me a day or two and I'll put some effort into making it better. [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 22:00, 16 August 2014 (UTC)<br />
<br />
<br />
:In the meantime, I will mention my personal strategy for passwords: I use a password database ({{Pkg|pass}} which uses [[GnuPG]]) and memorize long, randomly generated passwords that encrypt it. I do '''not''' change my passwords without reason, since this is a barrier to memorizing complex ones and I need at least a handful in memory for adequate security. This probably is not for everyone, however, so I won't just go dumping it into the article without further consideration.<br />
:The way I memorize a long random passphrase is this: I set my initial password to the longest number of characters that I can easily remember, and write the full generated password down and put it in my wallet. Over the next week or two, I periodically add characters to this generated password until I have memorized a 16-20 digit random password. Then, if it's a password I'll use often enough to remember, I destroy the piece of paper.<br />
:Using this technique, I can memorize passwords that are cryptographically secure and not based on dictionary words, sentences, or anything else that humans would come up with. [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 22:13, 16 August 2014 (UTC)</div>Ndthttps://wiki.archlinux.org/index.php?title=User_talk:Ndt&diff=330704User talk:Ndt2014-08-16T22:00:58Z<p>Ndt: /* Password advice */ re @ axper</p>
<hr />
<div>== Nice Addition to Security Page! ==<br />
<br />
Hi Ndt,<br />
<br />
I just wanted to thank you for the edit to the [[Security#Disk_encryption]] page. I definitely think your additions and changes clarified that section.<br />
<br />
Cheers!<br />
<br />
[[User:AdamT|AdamT]] ([[User talk:AdamT|talk]]) 00:53, 30 June 2013 (UTC)<br />
<br />
:AdamT,<br />
<br />
:Thanks for the feedback! I've been working on improving that page in my free time over the past couple of weeks, and I was really glad to see that you appreciated my early edits.<br />
<br />
:Much appreciated,<br />
<br />
:[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 01:36, 10 July 2013 (UTC)<br />
<br />
== Questions on DisplayLink ==<br />
<br />
Thank you for your contribution to the [[DisplayLink]] wiki page! I am planning on buying a ThinkVision LT1421 as well, but I am just wondering...are you able to see the DisplayLink device in the output of xrandr? Is it possible to simply turn on and specify the relative position of DisplayLink display by using xrandr instead of Xinerama? Thanks! If you would kindly reply by writing on my discussion page or email me at [...] that would be great! Thanks in advance! --[[User:Jiehanzheng|Jiehanzheng]] ([[User talk:Jiehanzheng|talk]]) 22:43, 8 June 2013 (UTC)<br />
<br />
:Hey Jiehan,<br />
<br />
:You can see my progress on DisplayLink on Arch detailed here. Unfortunately nobody replied, and a true solution was never achieved. It looks like true two-monitor DisplayLink support is still in its early days on Linux.<br />
<br />
:No, I'm not able to see the output on xrandr: I have only been able to get it working by running two separate X servers and making them talk using the ancient x2x tool (1998 or something). I'm still planning on updating the wiki page more to reflect these changes, but for now I've had little luck.<br />
<br />
:Kernel level support is good, and getting better as udl (the recent rewrite, I think driven by Red Hat) slowly replaces udlfb, but it's a process.<br />
<br />
:Supposedly there was a working driver for X back in the day, called xf86-video-displaylink, but since recent X.org updates (bug 50762) that driver won't even compile. I've been working on improving my C skills to see if I can go in and fix that driver myself, but even if I can (which is no guarantee) it'll still probably take a few months. Presumably, this driver would enable xrandr to work and everything to be nice and pretty.<br />
<br />
:Suggestion: don't buy that Lenovo monitor. I own it. Support is garbage on Linux. Unless you're a kernel hacker who also is deeply familiar with writing Xorg display drivers, I would highly suggest against it.<br />
<br />
:I don't suspect we are going to see ''anything'' in the vein of working USB display hotplugging under Linux until early-mid 2014.<br />
<br />
:The exception to this rule is if you want single-monitor support. I plan on picking up a Raspberry Pi (or similar device with wifi capabilities) and setting it up with my ThinkVision and and one of those ThinkPad USB keyboards and making my own lightweight ThinkPad. That's a cool project and it will make the display worth owning. If you want it for the purpose of running a dual-monitor xorg, though, avoid the ThinkVision at all costs.<br />
<br />
:[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 17:02, 9 June 2013 (UTC)<br />
<br />
==Netcfg/Wireless networking/Wireless Setup==<br />
Hi, I'd like to understand what you've done to [[Netcfg]] (then renamed [[Wireless networking]]): is it possible that you've just copy-pasted there the content of [[Wireless Setup]] also doing [https://wiki.archlinux.org/index.php/Special:ComparePages?page1=Wireless+Setup&rev1=&page2=Wireless+networking&rev2=&action=&diffonly=&unhide= some changes] in the same edit? If that's the case, it's not how you should have handled it, this way you've duplicated an article and lost all of its history in its copy: you should have requested the deletion of [[Netcfg]], then you could have ''moved'' [[Wireless Setup]] to a new title if you felt there was a better one, like [[Wireless networking]], and then you should have performed further adaptations. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:27, 16 July 2013 (UTC)<br />
<br />
(And anyway [[Netcfg]] should better be redirected to [[Netctl]]. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:30, 16 July 2013 (UTC))<br />
<br />
:Hi,<br />
:I am incredibly sorry about my changes to the Netcfg page. That was stupid, and it was supposed to be an edit to [[Wireless Setup]] that removes netcfg references. Please do not waste your time trying to understand the edit; it was on the wrong page and should be redirected as you stated.<br />
:Good thing it happened on the the [[Netcfg]] page, at least. I would be even more upset with myself had I done it to a page that matters more.<br />
:Thank you for being polite about it, however. I appreciate you giving me the benefit of the doubt. I will be considerably more careful about this in the future.<br />
:[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 14:19, 16 July 2013 (UTC)<br />
:Looking at the change history for that page, now (and the subsequent renaming), I can see why this must be ridiculously unusual for a wiki administrator. ''Thank you for trying to understand this.'' I think what should happen is the new [[Wireless networking]]/[[Netcfg]] page be renamed back to [[Netcfg]], then setup to properly redirect to [[Netctl]]. Subsequently, [[Wireless networking]] should redirect to [[Wireless Setup]].<br />
:This is only my suggestion, of course, but I appreciate your work in getting this resolved. [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 14:27, 16 July 2013 (UTC)<br />
<br />
::No worries, I learnt to appreciate your edits in the recent days, so I was surprised to see you doing that, there surely had to be some reason behind :)<br />
::It should all be fixed now, I've moved here your reply as explained in [[Help:Discussion#User talk pages]].<br />
::One last thing: is it possible that you're using an external editor for editing the articles? That would explain how you've managed to paste the entire page into another one... Also, ''note well'', that would explain why you removed some space-only lines in [[Wireless Setup]], as it's probably been done automatically by your editor: always review your edits because sometimes space-only lines ''are'' meaningful for MediaWiki, see for example:<br />
<br />
code<br />
<br />
code<br />
<br />
code<br />
<br />
::(look at the source text)<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:44, 16 July 2013 (UTC)<br />
<br />
::: Thanks for the reply. Yes, occasionally use vim for my edits, if I find the default editor is not powerful enough. Unfortunately, I am not very experienced with wiki editing in general (I am not sure I had ever edited a wiki page before Arch) so I have obviously made a couple of mistakes with the software. I am going to do some research in properly setting up my editor and will more closely review my edits until I have ironed out these kinks.<br />
<br />
::: I do really strive to make high-quality edits, however, so I appreciate your help in climbing this learning curve. Not that it is exceptionally difficult; I am just new.<br />
::: --[[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 17:04, 16 July 2013 (UTC)<br />
<br />
== Password advice ==<br />
<br />
I do agree with both of your edits<br />
[https://wiki.archlinux.org/index.php?title=Security&curid=10081&diff=330507&oldid=330506 #1]<br />
[https://wiki.archlinux.org/index.php?title=Security&curid=10081&diff=330506&oldid=328095 #2]<br />
, and I'd like to hear what advice you give about modern password complextiy, length and character components (since you removed both countering advices). If possible, let's fill the void in the [[Security]] article in regards to password advice.<br />
[[User:Axper|axper]] ([[User talk:Axper|talk]]) 08:05, 16 August 2014 (UTC)<br />
<br />
:Thanks for the feedback. Of course - I'm fairly busy right now, but give me a day or two and I'll put some effort into making it better. [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 22:00, 16 August 2014 (UTC)</div>Ndthttps://wiki.archlinux.org/index.php?title=Security&diff=330507Security2014-08-16T07:37:35Z<p>Ndt: /* Passwords */ the "xkcd trick" is no longer good advice for passwords</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ja:Security]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
==Passwords==<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. For this reason, do not to use a dictionary word or something like your dog's name. As expected, longer, more complex passwords are generally better.<br />
<br />
Tools like {{Pkg|pwgen}} and {{Pkg|apg}} can help you generate secure passwords.<br />
<br />
Alternatively you can make a password using the first characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password.<br />
<br />
===Maintaining passwords===<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. Tools like {{Pkg|pass}}, {{Pkg|keepassx}}, and {{Pkg|gnome-keyring}} can help manage large numbers of complex passwords. [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
===Password hashes===<br />
{{Warning|SHA512 is designed as a fast hash function, not for password hashing. An attacker can brute force a SHA512 hashed password ''far'' faster than bcrypt or scrypt allow.}}<br />
<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting_the_umask]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[Disk encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Role-based access control===<br />
The MAC implementation grsecurity supports is called role-based access control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you have not thought of.<br />
<br />
*[[Grsecurity#RBAC|Grsecurity RBAC]] has a learning mode like AppArmor for easy configureation<br />
*[[Grsecurity#RBAC|Grsecurity RBAC]] does not rely on extra meta-data like SELinux. RBAC is significantly faster then SELinux.<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Kernel hardening==<br />
<br />
===Restricting access to kernel logs===<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit a kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
===Restricting access to kernel pointers in the proc filesystem===<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
===Keep BPF JIT compiler disabled===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
{{note|[[grsecurity]] includes JIT hardening for the BPF JIT compiler, greatly reducing the risk of exploitation.}}<br />
<br />
===ptrace scope===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
{{note|In [[grsecurity]], this protection is toggled via the {{ic|kernel.grsecurity.harden_ptrace}} flag instead.}}<br />
<br />
====Examples of broken functionality====<br />
<br />
{{Note|You can still execute these commands as root, such as allowing them through {{ic|sudo}} for certain users, with or without a password.}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== Preventing link [[Wikipedia:TOCTOU|TOCTOU]] vulnerabilities ===<br />
<br />
See the [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7 commit message] for when this feature was added for the rationale.<br />
<br />
fs.protected_hardlinks = 1<br />
fs.protected_symlinks = 1<br />
<br />
{{Note|This is now enabled by default via {{ic|/usr/lib/sysctl.d/50-default.conf}}}}<br />
<br />
===hidepid===<br />
<br />
The kernel has the ability to hide other users' processes from unprivileged users by mounting the {{ic|proc}} filesystem with {{ic|1=hidepid=1}} or {{ic|1=hidepid=2}}. However, [http://lists.freedesktop.org/archives/systemd-devel/2012-October/006859.html this is currently broken with systemd] because it requires a workaround for the kernel's lack of support for virtualizing the cgroup filesystem in a container.<br />
<br />
===grsecurity===<br />
<br />
The [[grsecurity]] kernel provides many security-related improvements. It hardens both the kernel and userspace against common memory corruption vulnerabilities, along with providing many miscellaneous features and a role-based access control system. It is the only way to secure the kernel itself against exploitation, which is the most important improvement for a system already making good use of user isolation, containers/chroots and sandboxes.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH keys#Disabling password logins|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Password_protection_of_GRUB_menu]] for details.<br />
<br />
===Denying console login as root===<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
== See also ==<br />
<br />
* [[DeveloperWiki:Security]]<br />
* ArchWiki's Current list of security applications: [[List_of_Applications/Security|Lists of Applications: Security]]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [http://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Hardening Debian (pdf)]</div>Ndthttps://wiki.archlinux.org/index.php?title=Security&diff=330506Security2014-08-16T07:32:44Z<p>Ndt: /* Passwords */ remove outdated and way oversimplified password advice</p>
<hr />
<div>[[Category:Security]]<br />
[[Category:File systems]]<br />
[[Category:Networking]]<br />
[[ja:Security]]<br />
[[ru:Security]]<br />
{{Related articles start}}<br />
{{Related|List of Applications/Security}}<br />
{{Related|:Category:Security}}<br />
{{Related articles end}}<br />
This article contains recommendations and best practices for hardening an Arch Linux system.<br />
<br />
==Concepts==<br />
*It ''is'' possible to tighten the security so much as to make your system unusable. The trick is to secure it without overdoing it.<br />
*There are many other things that can be done to heighten the security, but the biggest threat is, and will always be, the user himself. When you think security, you have to think layers. When one layer is breached, another should stop the attack. But you can never make the system 100% secure unless you unplug the machine from all networks, lock it in a safe and never use it.<br />
*Be a little paranoid. It helps. And be suspicious. If anything sounds too good to be true, it probably is!<br />
*The [[Wikipedia:Principle of least privilege|principle of least privilege]]: each part of a system should only be able to access what is required to use it, and nothing more.<br />
<br />
==Passwords==<br />
Passwords are key to a secure linux system. They secure your [[Users and groups|user accounts]], [[Disk encryption|encrypted filesystems]], and [[SSH keys|SSH]]/[[GPG]] keys. They are the main way a computer chooses to trust the person using it, so a big part of security is just about picking secure passwords and protecting them.<br />
<br />
It is important that your passwords cannot be easily [[Wikipedia:Password cracking|cracked]] or guessed from personal information. For this reason, do not to use a dictionary word or something like your dog's name. As expected, longer, more complex passwords are generally better.<br />
<br />
Tools like {{Pkg|pwgen}} and {{Pkg|apg}} can help you generate secure passwords.<br />
<br />
Alternatively you can make a password using the first characters from every word in a sentence.<br />
Take for instance “the girl is walking down the rainy street” could be translated to “t6!WdtR5”. This approach could make it easier to remember a password. Or, if you do not mind typing you could make it “The girl is walking down the rainy street.”<br />
<br />
===Maintaining passwords===<br />
Once you pick a strong password, be sure to keep it safe. Watch out for [[Wikipedia:Social engineering (security)|manipulation]], [[Wikipedia:Shoulder surfing (computer security)|shoulder surfing]], and avoid reusing passwords so insecure servers cannot leak more information than necessary. Tools like {{Pkg|pass}}, {{Pkg|keepassx}}, and {{Pkg|gnome-keyring}} can help manage large numbers of complex passwords. [[Wikipedia:LastPass Password Manager|Lastpass]] is a service that stores encrypted passwords online for synchronization between devices, but requires that you trust both closed-source code and an external corporation.<br />
<br />
As a rule, do not pick insecure passwords just because secure ones are harder to remember. Passwords are a balancing act. It is better to have an encrypted database of secure passwords, guarded behind a key and one strong master password, than it is to have many similar weak passwords. Writing passwords down is perhaps equally effective[https://www.schneier.com/blog/archives/2005/06/write_down_your.html], avoiding potential vulnerabilities in software solutions while requiring physical security.<br />
<br />
===Password hashes===<br />
{{Warning|SHA512 is designed as a fast hash function, not for password hashing. An attacker can brute force a SHA512 hashed password ''far'' faster than bcrypt or scrypt allow.}}<br />
<br />
The default Arch hash [[SHA_password_hashes|sha512]] is very strong and there is no need to change it. By default, passwords are hashed in {{ic|/etc/shadow}}, readable only by root, and only user identifiers are stored in {{ic|/etc/passwd}}, therefore, as long as the [[Security#Restricting root|root user is secured]], the file cannot be copied and cracked on an external system.<br />
<br />
==Partitions==<br />
<br />
The kernel now prevents security issues related to hardlinks and symlinks if the {{ic|fs.protected_hardlinks}} and {{ic|fs.protected_symlinks}} sysctl switches are enabled, so there is no longer a major security benefit from separating out world-writable directories.<br />
<br />
Partitions containing world-writable directories can still be kept separate as a coarse way of limiting the damage from disk space exhaustion. However, filling a partition like {{ic|/var}} or {{ic|/tmp}} is enough to take down services. More flexible mechanisms for dealing with this concern exist (like quotas), and some filesystems include related features themselves (btrfs has quotas on subvolumes).<br />
<br />
===Mount options===<br />
<br />
Following the principle of least privilege, partitions should be mounted with the most restrictive mount options possible (without losing functionality).<br />
<br />
====Relevant mount options====<br />
<br />
*{{ic|nodev}}: Do not interpret character or block special devices on the file system.<br />
*{{ic|nosuid}}: Do not allow set-user-identifier or set-group-identifier bits to take effect.<br />
*{{ic|noexec}}: Do not allow direct execution of any binaries on the mounted filesystem.<br />
<br />
====Potential usage====<br />
<br />
{{Note|Data partitions should always be mounted with {{ic|nodev}}, {{ic|nosuid}}, {{ic|noexec}}.}}<br />
<br />
{| class="wikitable"<br />
| align="center" |'''Partition'''<br />
| align="center" |{{ic|nodev}}<br />
| align="center" |{{ic|nosuid}}<br />
| align="center" |{{ic|noexec}}<br />
|-<br />
| {{ic|/var}}||yes||yes||yes <sup>[1]</sup><br />
|-<br />
| {{ic|/home}}||yes||yes||yes, if you do not code, use wine or steam<br />
|-<br />
| {{ic|/dev/shm}}||yes||yes||yes<br />
|-<br />
| {{ic|/tmp}}||yes||yes||maybe, breaks compiling packages and various other things<br />
|-<br />
| {{ic|/boot}}||yes||yes||yes<br />
|-<br />
|}<br />
<br />
<sup>[1]</sup> Note that some packages (building {{AUR|nvidia-dkms}} for example) may require {{ic|exec}} on {{ic|/var}}.<br />
<br />
==Filesystem permissions==<br />
The default filesystem permissions allow read access to almost everything and changing the permissions can hide valuable information from an attacker who gains access to a non-root account such as the http or nobody users.<br />
<br />
For example:<br />
<br />
# chmod 700 /boot /etc/{iptables,arptables}<br />
<br />
The default [[Umask]] can be changed to improve security for newly created files. The [http://www.nsa.gov/ia/_files/os/redhat/rhel5-guide-i731.pdf NSA RHEL5 Security Guide] suggests a umask of {{ic|077}} for maximum security, which makes new files not readable by users other than the owner. To change this, see [[Umask#Setting_the_umask]].<br />
<br />
==Disk encryption==<br />
<br />
[[Disk encryption]], preferably full disk encryption with a [[Disk encryption#Choosing a strong passphrase|strong passphrase]], is the only way to guard data against physical recovery. This provides complete security when the computer is turned off or the disks in question are unmounted.<br />
<br />
Once the computer is powered on and the drive is mounted, however, its data becomes just as vulnerable as an unencrypted drive. It is therefore best practice to unmount data partitions as soon as they are no longer needed.<br />
<br />
Certain programs, like [[Dm-crypt]], allow the user to encrypt a loop file as a virtual volume. This is a reasonable alternative to full disk encryption when only certain parts of the system need be secure.<br />
<br />
==User setup==<br />
After installation make a normal user for daily use. Do not use the root user for daily use.<br />
<br />
===Lockout user after three failed login attempts===<br />
To further heighten the security it is possible to lockout a user after a specified number of failed login attempts. The user account can either be locked until the root user unlocks it, or automatically be unlocked after a set time.<br />
To lockout a user for ten minutes after three failed login attempts you have to modify {{ic|/etc/pam.d/system-login}}:<br />
<br />
{{hc|/etc/pam.d/system-login|<br />
2=auth required pam_tally.so deny=2 unlock_time=600 onerr=succeed file=/var/log/faillog<br />
#auth required pam_tally.so onerr=succeed file=/var/log/faillog<br />
}}<br />
<br />
If you do not comment the second line every failed login attempt will be counted twice. That is all there is to it. If you feel adventurous, make three failed login attempts. Then you can see for yourself what happens. To unlock a user manually do:<br />
<br />
# pam_tally --user --reset<br />
<br />
If you want to permanently lockout a user after 3 failed login attempts remove the {{ic|unlock_time}} part of the line. The user can then not login until root unlocks the account.<br />
<br />
== Restricting root ==<br />
The root user is, by definition, the most powerful user on a system. Because of this, there are a number of ways to keep the power of the root user while limiting its ability to cause harm, or at least to make root user actions more traceable.<br />
<br />
===Use sudo instead of su===<br />
Using [[sudo]] for privileged access is preferable to [[Su|su]] for [[Su#Security|a number of reasons]].<br />
<br />
* It keeps a log of which normal privilege user has run each privileged command.<br />
* The root user password need not be given out to each user who requires root access.<br />
* {{ic|sudo}} prevents users from accidentally running commands as ''root'' that do not need root access, because a full root terminal is not created. This aligns with the [[Wikipedia:Principle of least privilege|principle of least privilege]].<br />
* Individual programs may be enabled per user, instead of offering complete root access just to run one command. For example, to give the user ''alice'' access to a particular program:<br />
<br />
{{bc|<br />
# visudo<br />
}}<br />
<br />
{{hc|/etc/sudoers|<br />
alice ALL &#61; NOPASSWD: /path/to/program}}<br />
<br />
Or, individual commands can be allowed for all users. To mount Samba shares from a server as a regular user:<br />
<br />
%users ALL=/sbin/mount.cifs,/sbin/umount.cifs<br />
<br />
This allows all users who are members of the group users to run the commands {{ic|/sbin/mount.cifs}} and {{ic|/sbin/umount.cifs}} from any machine (ALL).<br />
<br />
{{Tip|To use {{ic|nano}} instead of {{ic|vi}} with {{ic|visudo}},<br />
<br />
{{hc|/etc/sudoers|<br />
2=Defaults editor=/usr/bin/nano<br />
}}<br />
Exporting {{ic|1=# EDITOR=nano visudo}} is regarded as a severe security risk since everything can be used as an {{ic|EDITOR}}.<br />
}}<br />
<br />
====Editing files using sudo====<br />
Using a text editor like {{ic|vim}} as root is a security vulnerability as it allows one to execute arbitrary shell commands, and does not log the user who executed the commands. To solve this, add<br />
<br />
{{bc|<br />
EXPORT SUDO_EDITOR&#61;rvim<br />
}}<br />
to your shell's configuration file and use {{ic|sudoedit filename}} or {{ic|sudo -e filename}} to edit files. This will automatically edit {{ic|filename}} with {{ic|rvim}}, disabling shell commands from within your text editor.<br />
<br />
===Restricting root login===<br />
Once [[Sudo|sudo]] is properly configured, full root access can be heavily restricted or denied without losing much usability.<br />
<br />
====Allow only certain users====<br />
The [[Wikipedia:Pluggable authentication module|PAM]] {{ic|pam_wheel.so}} lets you allow only users in the group {{ic|wheel}} to login using {{ic|su}}. Edit {{ic|/etc/pam.d/su}} and uncomment the line:<br />
{{bc|<nowiki><br />
# Uncomment the following line to require a user to be in the "wheel" group.<br />
auth required pam_wheel.so use_uid<br />
</nowiki>}}<br />
This means only users who are already able to run privileged commands may login as root.<br />
<br />
====Denying ssh login====<br />
Even if you do not wish to deny root login for local users, it is always good practice to [[Ssh#Deny|deny root login via SSH]]. The purpose of this is to add an additional layer of security before a user can completely compromise your system remotely.<br />
<br />
==Mandatory access control==<br />
<br />
[[Wikipedia:Mandatory Access Control | Mandatory access control]] (MAC) is a type of security policy that differs significantly from the [[Wikipedia:Discretionary Access Control | discretionary access control]] (DAC) used by default in Arch and most Linux distributions. MAC essentially means that every action a program could perform that affects the system in any way is checked against a security ruleset. This ruleset, in contrast to DAC methods, cannot be modified by users. Using virtually any mandatory access control system will significantly improve the security of your computer, although there are differences in how it can be implemented.<br />
<br />
===Pathname MAC===<br />
Pathname-based access control is a simple form of access control that offers permissions based on the path of a given file. The downside to this style of access control is that permissions are not carried with files if they are moved about the system. On the positive side, pathname-based MAC can be implemented on a much wider range of filesystems, unlike labels-based alternatives.<br />
<br />
*[[AppArmor]] is a [[Wikipedia:Canonical | Canonical]]-maintained MAC implementation seen as an "easier" alternative to SELinux.<br />
*[[Tomoyo]] is another simple, easy-to-use system offering mandatory access control. It is designed to be both simple in usage and in implementation, requiring very few dependencies.<br />
<br />
===Role-based access control===<br />
The MAC implementation grsecurity supports is called role-based access control. RBAC associates roles with each user. Each role defines what operations can be performed on certain objects. Given a well-written collection of roles and operations your users will be restricted to perform only those tasks that you tell them they can do. The default "deny-all" ensures you that a user cannot perform an action you have not thought of.<br />
<br />
*[[Grsecurity#RBAC|Grsecurity RBAC]] has a learning mode like AppArmor for easy configureation<br />
*[[Grsecurity#RBAC|Grsecurity RBAC]] does not rely on extra meta-data like SELinux. RBAC is significantly faster then SELinux.<br />
<br />
===Labels MAC===<br />
Labels-based access control means the extended attributes of a file are used to govern its security permissions. While this system is arguably more flexible in its security offerings than pathname-based MAC, it only works on filesystems that support these extended attributes.<br />
<br />
*[[SELinux]], based on a [[Wikipedia:NSA | NSA]] project to improve Linux security, implements MAC completely separate from system users and roles. It offers an extremely robust multi-level MAC policy implementation that can easily maintain control of a system that grows and changes past its original configuration.<br />
<br />
=== Access Control Lists ===<br />
[[Wikipedia:Access control list | Access control lists]] (ACLs) are an alternative to attaching rules directly to the filesystem in some way. ACLs implement access control by checking program actions against a list of permitted behavior.<br />
<br />
*[[grsecurity]] implements ACL access control, as well as a complete kernel patchset focused on improving security. Its changes extend to control of memory allocation, improved chroot restrictions, and rules involving specific network behavior.<br />
<br />
==Kernel hardening==<br />
<br />
===Restricting access to kernel logs===<br />
<br />
The kernel logs contain useful information for an attacker trying to exploit a kernel vulnerabilities, such as sensitive memory addresses. The {{ic|kernel.dmesg_restrict}} flag was to forbid access to the logs without the {{ic|CAP_SYS_ADMIN}} capability (which only processes running as root have by default).<br />
<br />
{{hc|/etc/sysctl.d/50-dmesg-restrict.conf|2=kernel.dmesg_restrict = 1}}<br />
<br />
===Restricting access to kernel pointers in the proc filesystem===<br />
<br />
Enabling {{ic|kernel.kptr_restrict}} will hide kernel symbol addresses in {{ic|/proc/kallsyms}} from regular users without {{ic|CAP_SYSLOG}}, making it more difficult for kernel exploits to resolve addresses/symbols dynamically. This will not help that much on a pre-compiled Arch Linux kernel, since a determined attacker could just download the kernel package and get the symbols manually from there, but if you're compiling your own kernel, this can help mitigating local root exploits. This will break some {{Pkg|perf}} commands when used by non-root users (but many {{Pkg|perf}} features require root access anyway). See {{Bug|34323}} for more information.<br />
<br />
{{hc|/etc/sysctl.d/50-kptr-restrict.conf|2=kernel.kptr_restrict = 1}}<br />
<br />
===Keep BPF JIT compiler disabled===<br />
<br />
The Linux kernel includes the ability to compile BPF/Seccomp rule sets to native code as a performance optimization. The {{ic|net.core.bpf_jit_enable}} flag should be left at 0 for a maximum level of security.<br />
<br />
This can be helpful in specific domains, but is not usually useful. A JIT compiler opens up the possibility for an attacker to perform a heap spraying attack, where they fill the kernel's heap with malicious code. This code can then potentially be executed via another exploit, like an incorrect function pointer dereference.<br />
<br />
{{note|[[grsecurity]] includes JIT hardening for the BPF JIT compiler, greatly reducing the risk of exploitation.}}<br />
<br />
===ptrace scope===<br />
<br />
Arch enables the Yama LSM by default, providing a {{ic|kernel.yama.ptrace_scope}} flag. This flag is enabled by default and prevents processes from performing a {{ic|ptrace}} call on other processes outside of their scope without {{ic|CAP_SYS_PTRACE}}. While many debugging tools require this for some of their functionality, it is a significant improvement in security. Without this feature, there is essentially no separation between processes running as the same user without applying extra layers like namespaces. The ability to attach a debugger to an existing process is a demonstration of this weakness.<br />
<br />
{{note|In [[grsecurity]], this protection is toggled via the {{ic|kernel.grsecurity.harden_ptrace}} flag instead.}}<br />
<br />
====Examples of broken functionality====<br />
<br />
{{Note|You can still execute these commands as root, such as allowing them through {{ic|sudo}} for certain users, with or without a password.}}<br />
<br />
* {{ic|gdb -p $PID}}<br />
* {{ic|strace -p $PID}}<br />
* {{ic|perf trace -p $PID}}<br />
* {{ic|reptyr $PID}}<br />
<br />
=== Preventing link [[Wikipedia:TOCTOU|TOCTOU]] vulnerabilities ===<br />
<br />
See the [https://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7 commit message] for when this feature was added for the rationale.<br />
<br />
fs.protected_hardlinks = 1<br />
fs.protected_symlinks = 1<br />
<br />
{{Note|This is now enabled by default via {{ic|/usr/lib/sysctl.d/50-default.conf}}}}<br />
<br />
===hidepid===<br />
<br />
The kernel has the ability to hide other users' processes from unprivileged users by mounting the {{ic|proc}} filesystem with {{ic|1=hidepid=1}} or {{ic|1=hidepid=2}}. However, [http://lists.freedesktop.org/archives/systemd-devel/2012-October/006859.html this is currently broken with systemd] because it requires a workaround for the kernel's lack of support for virtualizing the cgroup filesystem in a container.<br />
<br />
===grsecurity===<br />
<br />
The [[grsecurity]] kernel provides many security-related improvements. It hardens both the kernel and userspace against common memory corruption vulnerabilities, along with providing many miscellaneous features and a role-based access control system. It is the only way to secure the kernel itself against exploitation, which is the most important improvement for a system already making good use of user isolation, containers/chroots and sandboxes.<br />
<br />
==Network and Firewalls==<br />
<br />
===Firewalls===<br />
While the stock Arch kernel is capable of using [[Wikipedia:Netfilter|Netfilter]]'s [[iptables]], it is not enabled by default. It is highly recommended to install {{Pkg|iptables}} from the [[official repositories]], enable it, and set up some form of firewall.<br />
<br />
*See [[iptables]] for general info.<br />
*See [[Simple stateful firewall]] for a guide on setting up an iptables firewall.<br />
*See [[Firewalls]] for other ways of setting up netfilter.<br />
<br />
===Kernel parameters===<br />
Kernel parameters which affect networking can be set using [[Sysctl]]. For how to do this, see [[Sysctl#TCP/IP stack hardening]].<br />
<br />
===SSH===<br />
Avoid using [[Secure Shell]] without [[SSH keys#Disabling password logins|requiring SSH keys]]. This prevents [[Wikipedia:Brute-force attack|brute-force attacks]]. Alternatively [[Fail2ban]] or [[Sshguard]] offer lesser forms of protection by monitoring logs and writing [[Iptables|iptables rules]] but open up the potential for a denial of serving, since an attacker can spoof packets as if they came from the administrator after identifying their address.<br />
<br />
[[Secure Shell#Deny root login|Denying root login]] is good practice, both for tracing intrusions and adding an additional layer of security before root access.<br />
<br />
===DNS===<br />
<br />
See [[DNSSEC]] and [[DNSCrypt]].<br />
<br />
==Authenticating packages==<br />
[http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#overview Attacks on package managers] are possible without proper use of package signing, and can affect even package managers with [http://www.cs.arizona.edu/stork/packagemanagersecurity/faq.html proper signature systems]. Arch uses package signing by default and relies on a web of trust from 5 trusted master keys. See [[Pacman-key]] for details.<br />
<br />
==Physical security==<br />
{{Note|You can ignore this section if you just want to secure your computer against remote threats.}}<br />
<br />
Physical access to a computer is root access given enough time and resources. However, a high ''practical'' level of security can be obtained by putting up enough barriers.<br />
<br />
An attacker can gain full control of your computer on the next boot by simply attaching a malicious IEEE 1394 (FireWire), Thunderbolt or PCI Express device as they are given full memory access.[http://www.breaknenter.org/projects/inception/] There is little you can do from preventing this, or modification of the hardware itself - such as flashing malicious firmware onto a drive. However, the vast majority of attackers will not be this knowledgeable and determined.<br />
<br />
[[#Disk encryption]] will prevent access to your data if the computer is stolen, but malicious firmware can be installed to obtain this data upon your next log in by a resourceful attacker.<br />
<br />
===Locking down BIOS===<br />
<br />
Adding a password to the BIOS prevents someone from booting into removable media, which is basically the same as having root access to your computer. You should make sure your drive is first in the boot order and disable the other drives from being bootable if you can.<br />
<br />
===Bootloaders===<br />
<br />
It is highly important to protect your bootloader. There is a magic kernel parameter called {{ic|1=init=/bin/sh}}. This makes any user/login restrictions totally useless.<br />
<br />
====Syslinux====<br />
<br />
Syslinux supports [[Syslinux#Security|password-protecting your bootloader]].<br />
It allows you to set either a per-menu-item password or a global bootloader password.<br />
<br />
====GRUB====<br />
<br />
[[GRUB]] supports bootloader passwords as well. See [[GRUB#Password_protection_of_GRUB_menu]] for details.<br />
<br />
===Denying console login as root===<br />
Changing the configuration to disallow root to login from the console makes it harder for an intruder to gain access to the system. The intruder would have to guess both a user-name that exists on the system and that users password. When root is allowed to log in via the console, an intruder only needs to guess a password.<br />
Blocking root login at the console is done by commenting out the tty lines in {{ic|/etc/securetty}}.<br />
{{hc|/etc/securetty|<br />
#tty1<br />
}}<br />
<br />
Repeat for any tty you wish to block.<br />
To check the effect of this change, start by commenting out only one line and go to that particular console and try to login as root. You will be greeted by the message {{ic|Login incorrect}}. Now that we are sure it works, go back and comment out the rest of the tty lines.<br />
{{Note|If you see {{ic|ttyS0}} this is for a serial console. Similarly, on Xen virtualized systems {{ic|hvc0}} is for the administrator.}}<br />
<br />
=== Automatic logout ===<br />
If you are using [[Bash]] or [[Zsh]], you can set {{ic|TMOUT}} for an automatic logout from shells after a timeout.<br />
<br />
For example, the following will automatically log out from virtual consoles (but not terminal emulators in X11):<br />
<br />
{{hc|/etc/profile.d/shell-timeout.sh|<nowiki><br />
TMOUT="$(( 60*10 ))";<br />
[ -z "$DISPLAY" ] && export TMOUT;<br />
case $( /usr/bin/tty ) in<br />
/dev/tty[0-9]*) export TMOUT;;<br />
esac<br />
</nowiki>}}<br />
<br />
If you really want EVERY Bash/Zsh prompt (even within X) to timeout, use:<br />
<br />
$ export TMOUT="$(( 60*10 ))";<br />
<br />
Note that this will not work if there is some command running in the shell (eg.: an SSH session or other shell without {{ic|TMOUT}} support). But if you are using VC mostly for restarting frozen GDM/Xorg as root, then this is very usefull.<br />
<br />
== See also ==<br />
<br />
* [[DeveloperWiki:Security]]<br />
* ArchWiki's Current list of security applications: [[List_of_Applications/Security|Lists of Applications: Security]]<br />
* [http://www.puschitz.com/SecuringLinux.shtml Securing and Hardening Red Hat Linux Production Systems]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-desktop/index.html Hardening the linux desktop]<br />
* [http://www.ibm.com/developerworks/linux/tutorials/l-harden-server/index.html Hardening the linux server]<br />
* [http://www.faqs.org/docs/securing/index.html Securing and Optimizing Linux]<br />
* [http://www.auscert.org.au/5816 UNIX and Linux Security Checklist v3.0]<br />
* [http://wiki.centos.org/HowTos/OS_Protection CentOS Wiki: OS Protection]<br />
* [http://www.debian.org/doc/manuals/securing-debian-howto/securing-debian-howto.en.pdf Hardening Debian (pdf)]</div>Ndthttps://wiki.archlinux.org/index.php?title=Talk:Arch_build_system&diff=330146Talk:Arch build system2014-08-13T16:57:03Z<p>Ndt: </p>
<hr />
<div>== "The ABS tree is a SVN hirearchy" ==<br />
<br />
This gets mentioned repeatedly throughout this article. I think this might actually be outdated - I recall talk on the mailing lists months back about a Git migration, and the packages are definitely [https://projects.archlinux.org/svntogit/packages.git/ available through Git now]. But apparently there's also [https://www.archlinux.org/svn/ SVN repositories]. So which is it? Regardless, I don't think it's accurate to say "ABS is a SVN hirearchy at {{ic|/var/abs}}" unless it actually ''is'' a SVN hierarchy located at {{ic|/var/abs}}. If it's just a bunch of scripts pulled via {{ic|rsync}}, but they happen to come from a SVN repo, then we shouldn't be calling the client's directory tree a SVN tree. [[User:Ndt|Ndt]] ([[User talk:Ndt|talk]]) 16:57, 13 August 2014 (UTC)</div>Ndthttps://wiki.archlinux.org/index.php?title=Arch_build_system&diff=330145Arch build system2014-08-13T16:53:09Z<p>Ndt: /* ABS overview */ add note about svn/git hosting of abs tree</p>
<hr />
<div>[[Category:About Arch]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[cs:Arch Build System]]<br />
[[da:Arch Build System]]<br />
[[de:Arch Build System]]<br />
[[el:Arch Build System]]<br />
[[es:Arch Build System]]<br />
[[fr:ABS]]<br />
[[it:Arch Build System]]<br />
[[ja:Arch Build System]]<br />
[[ko:Arch Build System]]<br />
[[pl:Arch Build System]]<br />
[[ro:ABS]]<br />
[[ru:Arch Build System]]<br />
[[tr:Arch_derleme_sistemi]]<br />
[[zh-CN:Arch Build System]]<br />
[[zh-TW:Arch Build System]]<br />
{{Related articles start}}<br />
{{Related|Arch packaging standards}}<br />
{{Related|Arch User Repository}}<br />
{{Related|Creating packages}}<br />
{{Related|Kernel Compilation with ABS}}<br />
{{Related|makepkg}}<br />
{{Related|Official repositories}}<br />
{{Related|pacman}}<br />
{{Related|PKGBUILD}}<br />
{{Related articles end}}<br />
<br />
This article provides an overview of the Arch Build System along with a walkthrough for beginners. It is not a complete reference guide. If you need more information, please reference the man pages.<br />
<br />
{{Note|ABS syncs once a day so it may lag behind what is already available in the repositories.}}<br />
<br />
== What is the Arch Build System? ==<br />
<br />
The Arch Build System, '''ABS''' for short, is a ''ports-like'' system for building and packaging software from source code. While [[pacman]] is the specialized Arch tool for binary package management (including packages built with the ABS), ABS is a collection of tools for compiling source into installable {{ic|.pkg.tar.xz}} packages.<br />
<br />
=== What is a ports-like system? ===<br />
<br />
''Ports'' is a system used by *BSD to automate the process of building software from source code. The system uses a ''port'' to download, unpack, patch, compile, and install the given software. A ''port'' is merely a small directory on the user's computer, named after the corresponding software to be installed, that contains a few files with the instructions for building and installing the software from source. This makes installing software as simple as typing {{ic|make}} or {{ic|make install clean}} within the port's directory.<br />
<br />
=== ABS is a similar concept ===<br />
<br />
ABS is made up of a directory tree (the ABS tree) residing under {{ic|/var/abs}}. This tree contains many subdirectories, each within a category and each named by their respective package. This tree represents (but does not contain) all ''official Arch software'', retrievable through the SVN system. You may refer to each package-named subdirectory as an 'ABS', much the way one would refer to a 'port'. These ABS (or subdirectories) do not contain the software package nor the source but rather a [[PKGBUILD]] file (and sometimes other files). A PKGBUILD is a simple Bash build script -- a text file containing the compilation and packaging instructions as well as the URL of the appropriate '''source''' tarball to be downloaded. (The most important component of ABS are PKGBUILDs.) By issuing the ABS [[makepkg]] command, the software is first compiled and then ''packaged'' within the build directory before being installed. Now you may use [[pacman]], the Arch Linux package manager, to install, upgrade, and remove your new package.<br />
<br />
=== ABS overview ===<br />
<br />
'ABS' may be used as an umbrella term since it includes and relies on several other components; therefore, though not technically accurate, 'ABS' can refer to the following tools as a complete toolkit:<br />
<br />
; ABS tree: The ABS directory structure; an SVN hierarchy under {{ic|/var/abs/}} on your (local) machine. It contains many subdirectories, named for all available official Arch Linux software from repositories specified in {{ic|/etc/abs.conf}}, but not the packages themselves. The tree is created after installing the {{Pkg|abs}} package with [[pacman]] and subsequently running the {{ic|abs}} script.<br />
<br />
{{note|The actual packages are available in [https://www.archlinux.org/svn/ svn] and [https://projects.archlinux.org/svntogit/packages.git/ git] repositories, and the {{ic|abs}} script downloads them using [[rsync]].}}<br />
<br />
; [[PKGBUILD]]s: A [[Bash]] script that contains the URL of the source code along with the compilation and packaging instructions.<br />
<br />
; [[makepkg]]: ABS shell command tool which reads the PKGBUILDs, automatically downloads and compiles the sources and creates a {{ic|.pkg.tar*}} according to the {{ic|PKGEXT}} array in {{ic|makepkg.conf}}. You may also use makepkg to make your own custom packages from the [[AUR]] or third-party sources. (See the [[Creating packages]] wiki article.)<br />
<br />
; [[pacman]]: pacman is completely separate, but is necessarily invoked either by makepkg or manually, to install and remove the built packages and for fetching dependencies.<br />
<br />
; [[Arch User Repository|AUR]]: The Arch User Repository is separate from ABS but AUR (unsupported) PKGBUILDs are built using makepkg to compile and package up software. In contrast to the ABS tree on your local machine, the AUR exists as a website interface. It contains many thousands of user-contributed PKGBUILDs for software which is unavailable as an official Arch package. If you need to build a package outside the official Arch tree, chances are it is in the AUR.<br />
<br />
== Why would I want to use ABS? ==<br />
<br />
The Arch Build System is used to:<br />
* Compile or recompile a package, for any reason<br />
* Make and install new packages from source of software for which no packages are yet available (see [[Creating packages]]) <br />
* Customize existing packages to fit your needs (enabling or disabling options, patching)<br />
* Rebuild your entire system using your compiler flags, "à la FreeBSD" (e.g. with [[pacbuilder]])<br />
* Cleanly build and install your own custom kernel (see [[Kernel Compilation]])<br />
* Get kernel modules working with your custom kernel<br />
* Easily compile and install a newer, older, beta, or development version of an Arch package by editing the version number in the PKGBUILD<br />
<br />
ABS is not necessary to use Arch Linux, but it is useful for automating certain tasks of source compilation.<br />
<br />
== How to use ABS ==<br />
<br />
Building packages using abs consists of these steps:<br />
#Install the {{Pkg|abs}} package with [[pacman]].<br />
#Run {{ic|abs}} as root to create the ABS tree by synchronizing it with the Arch Linux server.<br />
#Copy the build files (usually residing under {{ic|/var/abs/<repo>/<pkgname>}}) to a build directory.<br />
#Navigate to that directory, edit the PKGBUILD (if desired/necessary) and do '''makepkg'''. <br />
#According to instructions in the PKGBUILD, makepkg will download the appropriate source tarball, unpack it, patch if desired, compile according to {{ic|CFLAGS}} specified in {{ic|makepkg.conf}}, and finally compress the built files into a package with the extension {{ic|.pkg.tar.gz}} or {{ic|.pkg.tar.xz}}. <br />
#Installing is as easy as doing {{ic|pacman -U <.pkg.tar.xz file>}}. Package removal is also handled by pacman.<br />
<br />
=== Install tools ===<br />
<br />
To use the ABS, you first need to [[pacman|install]] {{Pkg|abs}} from the [[official repositories]].<br />
<br />
This will grab the abs-sync scripts, various build scripts, and [[rsync]] (as a dependency, if you do not already have it).<br />
<br />
Before you can actually build anything, however, you will also need basic compiling tools. These are handily collected in the [[Pacman#Installing_package_groups|package group]] {{grp|base-devel}}. This group can be installed with pacman.<br />
<br />
=== /etc/abs.conf ===<br />
<br />
As root, edit {{ic|/etc/abs.conf}} to include your desired repositories.<br />
<br />
Remove the {{ic|!}} in front of the appropriate repositories. For example:<br />
REPOS=(core extra community !testing)<br />
<br />
=== ABS tree ===<br />
<br />
The ABS tree is an SVN directory hierarchy located under {{ic|/var/abs}} and looks like this:<br />
<br />
{{bc|<nowiki><br />
| -- core/<br />
| || -- acl/<br />
| || || -- PKGBUILD<br />
| || -- attr/<br />
| || || -- PKGBUILD<br />
| || -- abs/<br />
| || || -- PKGBUILD<br />
| || -- autoconf/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- extra/<br />
| || -- acpid/<br />
| || || -- PKGBUILD<br />
| || -- apache/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- community/<br />
| || -- ...<br />
</nowiki>}}<br />
<br />
The ABS tree has exactly the same structure as the package database:<br />
<br />
* First-level: Repository name<br />
* Second-level: Package name directories<br />
* Third level: PKGBUILD (contains information needed to build a package) and other related files (patches, other files needed for building the package)<br />
<br />
The source code for the package is not present in the ABS directory. Instead, the '''PKGBUILD''' file contains a URL that will download the source code when the package is built. So the size of abs tree is quite small.<br />
<br />
==== Download ABS tree ====<br />
<br />
As root, run:<br />
<br />
# abs<br />
<br />
Your ABS tree is now created under {{ic|/var/abs}}. Note the appropriate branches of the ABS tree now exist and correspond to the ones you specified in {{ic|/etc/abs.conf}}. <br />
<br />
The abs command should be run periodically to keep in sync with the official repositories. Individual ABS package files can also be downloaded with:<br />
<br />
# abs <repository>/<package><br />
<br />
This way you do not have to check out the entire abs tree just to build one package.<br />
<br />
=== /etc/makepkg.conf ===<br />
<br />
[[makepkg]]'s {{ic|/etc/makepkg.conf}} specifies global environment variables and compiler flags which you may wish to edit if you are using an SMP system, or to specify other desired optimizations. The default settings are for i686 and x86_64 optimizations which will work fine for those architectures on single-CPU systems. (The defaults will work on SMP machines, but will only use one core/CPU when compiling -- see [[makepkg]] for details.)<br />
<br />
==== Set the PACKAGER variable in /etc/makepkg.conf ====<br />
<br />
Setting the {{ic|PACKAGER}} variable in {{ic|/etc/makepkg.conf}} is an optional but ''highly recommended'' step. It allows a "flag" to quickly identify which packages have been built and/or installed by YOU, not the official maintainer! This is easily accomplished using {{Pkg|expac}} available from the community repo:<br />
<br />
===== Showing all packages (including those from AUR) =====<br />
<br />
$ grep myname /etc/makepkg.conf<br />
PACKAGER="myname <myemail@myserver.com>"<br />
<br />
$ expac "%n %p" | grep "myname" | column -t<br />
archey3 myname<br />
binutils myname<br />
gcc myname<br />
gcc-libs myname<br />
glibc myname<br />
tar myname<br />
<br />
===== Showing only packages contained in repos =====<br />
<br />
This example only shows packages contained in the repos defined in {{ic|/etc/pacman.conf}}:<br />
<br />
$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)<br />
binutils<br />
gcc<br />
gcc-libs<br />
glibc<br />
tar<br />
<br />
=== Create a build directory ===<br />
<br />
It is recommended to create a build directory where the actual compiling will take place; you should never modify the ABS tree by building within it, as data will be lost (overwritten) on each ABS update. It is good practice to use your home directory, though some Arch users prefer to create a 'local' directory under {{ic|/var/abs/}}, owned by a normal user. <br />
<br />
Create your build directory. e.g.:<br />
<br />
$ mkdir -p $HOME/abs<br />
<br />
Copy the ABS from the tree ({{ic|/var/abs/<repository>/<pkgname>}}) to the build directory.<br />
<br />
=== Build package ===<br />
<br />
In our example, we will build the ''slim'' display manager package.<br />
<br />
Copy the slim ABS from the ABS tree to a build directory:<br />
<br />
$ cp -r /var/abs/extra/slim/ ~/abs<br />
<br />
Navigate to the build directory:<br />
<br />
$ cd ~/abs/slim<br />
<br />
Modify the PKGBUILD to your liking, then run ''makepkg'' (with the {{ic|-s}} flag to enable automatic build-time dependency handling):<br />
<br />
$ makepkg -s<br />
<br />
{{Note|Before complaining about missing (make) dependencies, remember that the group {{Grp|base-devel}} is assumed to be installed when building with ''makepkg''. See [[#Install tools]].}}<br />
<br />
Install as root:<br />
<br />
# pacman -U slim-1.3.0-2-i686.pkg.tar.xz<br />
<br />
That's it. You have just built slim from source and cleanly installed it to your system with pacman. Package removal is also handled by pacman with {{ic|pacman -R slim}}.<br />
<br />
The ABS method adds a level of convenience and automation, while still maintaining complete transparency and control of the build and installation functions by including them in the PKGBUILD.<br />
<br />
==== fakeroot ====<br />
<br />
Essentially, the same steps are being executed in the traditional method (generally including the {{ic|./configure, make, make install}} steps) but the software is installed into a ''fake root'' environment. (A ''fake root'' is simply a subdirectory within the build directory that functions and behaves as the system's root directory. In conjunction with the '''fakeroot''' program, ''makepkg'' creates a fake root directory, and installs the compiled binaries and associated files into it, with '''root''' as owner.) The ''fake root'', or subdirectory tree containing the compiled software, is then compressed into an archive with the extension {{ic|.pkg.tar.xz}}, or a ''package''. When invoked, pacman then extracts the package (installs it) into the system's real root directory ({{ic|/}}).<br />
<br />
=== Preserve modified packages ===<br />
<br />
Updating the system with pacman will replace a modified package from ABS with the package of the same name from the official repositories. See the following instructions for how to avoid this.<br />
<br />
Insert a group array into the PKGBUILD, and add the package to a group called {{ic|modified}}.<br />
<br />
{{hc|PKGBUILD|2=<br />
groups=('modified')<br />
}}<br />
<br />
Add this group to the section {{ic|IgnoreGroup}} in {{ic|/etc/pacman.conf}}.<br />
<br />
{{hc|/etc/pacman.conf|2=<br />
IgnoreGroup = modified<br />
}}<br />
<br />
If new versions are available in the official repositories during a system update, pacman prints a note that it is skipping this update because it is in the IgnoreGroup section. At this point the modified package should be rebuilt from ABS to avoid partial upgrades.</div>Ndthttps://wiki.archlinux.org/index.php?title=Arch_build_system&diff=330142Arch build system2014-08-13T16:48:14Z<p>Ndt: /* Set the {{ic|PACKAGER}} variable in {{ic|/etc/makepkg.conf}} */ nevermind - rm inline code from title</p>
<hr />
<div>[[Category:About Arch]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[cs:Arch Build System]]<br />
[[da:Arch Build System]]<br />
[[de:Arch Build System]]<br />
[[el:Arch Build System]]<br />
[[es:Arch Build System]]<br />
[[fr:ABS]]<br />
[[it:Arch Build System]]<br />
[[ja:Arch Build System]]<br />
[[ko:Arch Build System]]<br />
[[pl:Arch Build System]]<br />
[[ro:ABS]]<br />
[[ru:Arch Build System]]<br />
[[tr:Arch_derleme_sistemi]]<br />
[[zh-CN:Arch Build System]]<br />
[[zh-TW:Arch Build System]]<br />
{{Related articles start}}<br />
{{Related|Arch packaging standards}}<br />
{{Related|Arch User Repository}}<br />
{{Related|Creating packages}}<br />
{{Related|Kernel Compilation with ABS}}<br />
{{Related|makepkg}}<br />
{{Related|Official repositories}}<br />
{{Related|pacman}}<br />
{{Related|PKGBUILD}}<br />
{{Related articles end}}<br />
<br />
This article provides an overview of the Arch Build System along with a walkthrough for beginners. It is not a complete reference guide. If you need more information, please reference the man pages.<br />
<br />
{{Note|ABS syncs once a day so it may lag behind what is already available in the repositories.}}<br />
<br />
== What is the Arch Build System? ==<br />
<br />
The Arch Build System, '''ABS''' for short, is a ''ports-like'' system for building and packaging software from source code. While [[pacman]] is the specialized Arch tool for binary package management (including packages built with the ABS), ABS is a collection of tools for compiling source into installable {{ic|.pkg.tar.xz}} packages.<br />
<br />
=== What is a ports-like system? ===<br />
<br />
''Ports'' is a system used by *BSD to automate the process of building software from source code. The system uses a ''port'' to download, unpack, patch, compile, and install the given software. A ''port'' is merely a small directory on the user's computer, named after the corresponding software to be installed, that contains a few files with the instructions for building and installing the software from source. This makes installing software as simple as typing {{ic|make}} or {{ic|make install clean}} within the port's directory.<br />
<br />
=== ABS is a similar concept ===<br />
<br />
ABS is made up of a directory tree (the ABS tree) residing under {{ic|/var/abs}}. This tree contains many subdirectories, each within a category and each named by their respective package. This tree represents (but does not contain) all ''official Arch software'', retrievable through the SVN system. You may refer to each package-named subdirectory as an 'ABS', much the way one would refer to a 'port'. These ABS (or subdirectories) do not contain the software package nor the source but rather a [[PKGBUILD]] file (and sometimes other files). A PKGBUILD is a simple Bash build script -- a text file containing the compilation and packaging instructions as well as the URL of the appropriate '''source''' tarball to be downloaded. (The most important component of ABS are PKGBUILDs.) By issuing the ABS [[makepkg]] command, the software is first compiled and then ''packaged'' within the build directory before being installed. Now you may use [[pacman]], the Arch Linux package manager, to install, upgrade, and remove your new package.<br />
<br />
=== ABS overview ===<br />
<br />
'ABS' may be used as an umbrella term since it includes and relies on several other components; therefore, though not technically accurate, 'ABS' can refer to the following tools as a complete toolkit:<br />
<br />
; ABS tree: The ABS directory structure; an SVN hierarchy under {{ic|/var/abs/}} on your (local) machine. It contains many subdirectories, named for all available official Arch Linux software from repositories specified in {{ic|/etc/abs.conf}}, but not the packages themselves. The tree is created after installing the {{Pkg|abs}} package with [[pacman]] and subsequently running the {{ic|abs}} script.<br />
<br />
; [[PKGBUILD]]s: A [[Bash]] script that contains the URL of the source code along with the compilation and packaging instructions.<br />
<br />
; [[makepkg]]: ABS shell command tool which reads the PKGBUILDs, automatically downloads and compiles the sources and creates a {{ic|.pkg.tar*}} according to the {{ic|PKGEXT}} array in {{ic|makepkg.conf}}. You may also use makepkg to make your own custom packages from the [[AUR]] or third-party sources. (See the [[Creating packages]] wiki article.)<br />
<br />
; [[pacman]]: pacman is completely separate, but is necessarily invoked either by makepkg or manually, to install and remove the built packages and for fetching dependencies.<br />
<br />
; [[Arch User Repository|AUR]]: The Arch User Repository is separate from ABS but AUR (unsupported) PKGBUILDs are built using makepkg to compile and package up software. In contrast to the ABS tree on your local machine, the AUR exists as a website interface. It contains many thousands of user-contributed PKGBUILDs for software which is unavailable as an official Arch package. If you need to build a package outside the official Arch tree, chances are it is in the AUR.<br />
<br />
== Why would I want to use ABS? ==<br />
<br />
The Arch Build System is used to:<br />
* Compile or recompile a package, for any reason<br />
* Make and install new packages from source of software for which no packages are yet available (see [[Creating packages]]) <br />
* Customize existing packages to fit your needs (enabling or disabling options, patching)<br />
* Rebuild your entire system using your compiler flags, "à la FreeBSD" (e.g. with [[pacbuilder]])<br />
* Cleanly build and install your own custom kernel (see [[Kernel Compilation]])<br />
* Get kernel modules working with your custom kernel<br />
* Easily compile and install a newer, older, beta, or development version of an Arch package by editing the version number in the PKGBUILD<br />
<br />
ABS is not necessary to use Arch Linux, but it is useful for automating certain tasks of source compilation.<br />
<br />
== How to use ABS ==<br />
<br />
Building packages using abs consists of these steps:<br />
#Install the {{Pkg|abs}} package with [[pacman]].<br />
#Run {{ic|abs}} as root to create the ABS tree by synchronizing it with the Arch Linux server.<br />
#Copy the build files (usually residing under {{ic|/var/abs/<repo>/<pkgname>}}) to a build directory.<br />
#Navigate to that directory, edit the PKGBUILD (if desired/necessary) and do '''makepkg'''. <br />
#According to instructions in the PKGBUILD, makepkg will download the appropriate source tarball, unpack it, patch if desired, compile according to {{ic|CFLAGS}} specified in {{ic|makepkg.conf}}, and finally compress the built files into a package with the extension {{ic|.pkg.tar.gz}} or {{ic|.pkg.tar.xz}}. <br />
#Installing is as easy as doing {{ic|pacman -U <.pkg.tar.xz file>}}. Package removal is also handled by pacman.<br />
<br />
=== Install tools ===<br />
<br />
To use the ABS, you first need to [[pacman|install]] {{Pkg|abs}} from the [[official repositories]].<br />
<br />
This will grab the abs-sync scripts, various build scripts, and [[rsync]] (as a dependency, if you do not already have it).<br />
<br />
Before you can actually build anything, however, you will also need basic compiling tools. These are handily collected in the [[Pacman#Installing_package_groups|package group]] {{grp|base-devel}}. This group can be installed with pacman.<br />
<br />
=== /etc/abs.conf ===<br />
<br />
As root, edit {{ic|/etc/abs.conf}} to include your desired repositories.<br />
<br />
Remove the {{ic|!}} in front of the appropriate repositories. For example:<br />
REPOS=(core extra community !testing)<br />
<br />
=== ABS tree ===<br />
<br />
The ABS tree is an SVN directory hierarchy located under {{ic|/var/abs}} and looks like this:<br />
<br />
{{bc|<nowiki><br />
| -- core/<br />
| || -- acl/<br />
| || || -- PKGBUILD<br />
| || -- attr/<br />
| || || -- PKGBUILD<br />
| || -- abs/<br />
| || || -- PKGBUILD<br />
| || -- autoconf/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- extra/<br />
| || -- acpid/<br />
| || || -- PKGBUILD<br />
| || -- apache/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- community/<br />
| || -- ...<br />
</nowiki>}}<br />
<br />
The ABS tree has exactly the same structure as the package database:<br />
<br />
* First-level: Repository name<br />
* Second-level: Package name directories<br />
* Third level: PKGBUILD (contains information needed to build a package) and other related files (patches, other files needed for building the package)<br />
<br />
The source code for the package is not present in the ABS directory. Instead, the '''PKGBUILD''' file contains a URL that will download the source code when the package is built. So the size of abs tree is quite small.<br />
<br />
==== Download ABS tree ====<br />
<br />
As root, run:<br />
<br />
# abs<br />
<br />
Your ABS tree is now created under {{ic|/var/abs}}. Note the appropriate branches of the ABS tree now exist and correspond to the ones you specified in {{ic|/etc/abs.conf}}. <br />
<br />
The abs command should be run periodically to keep in sync with the official repositories. Individual ABS package files can also be downloaded with:<br />
<br />
# abs <repository>/<package><br />
<br />
This way you do not have to check out the entire abs tree just to build one package.<br />
<br />
=== /etc/makepkg.conf ===<br />
<br />
[[makepkg]]'s {{ic|/etc/makepkg.conf}} specifies global environment variables and compiler flags which you may wish to edit if you are using an SMP system, or to specify other desired optimizations. The default settings are for i686 and x86_64 optimizations which will work fine for those architectures on single-CPU systems. (The defaults will work on SMP machines, but will only use one core/CPU when compiling -- see [[makepkg]] for details.)<br />
<br />
==== Set the PACKAGER variable in /etc/makepkg.conf ====<br />
<br />
Setting the {{ic|PACKAGER}} variable in {{ic|/etc/makepkg.conf}} is an optional but ''highly recommended'' step. It allows a "flag" to quickly identify which packages have been built and/or installed by YOU, not the official maintainer! This is easily accomplished using {{Pkg|expac}} available from the community repo:<br />
<br />
===== Showing all packages (including those from AUR) =====<br />
<br />
$ grep myname /etc/makepkg.conf<br />
PACKAGER="myname <myemail@myserver.com>"<br />
<br />
$ expac "%n %p" | grep "myname" | column -t<br />
archey3 myname<br />
binutils myname<br />
gcc myname<br />
gcc-libs myname<br />
glibc myname<br />
tar myname<br />
<br />
===== Showing only packages contained in repos =====<br />
<br />
This example only shows packages contained in the repos defined in {{ic|/etc/pacman.conf}}:<br />
<br />
$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)<br />
binutils<br />
gcc<br />
gcc-libs<br />
glibc<br />
tar<br />
<br />
=== Create a build directory ===<br />
<br />
It is recommended to create a build directory where the actual compiling will take place; you should never modify the ABS tree by building within it, as data will be lost (overwritten) on each ABS update. It is good practice to use your home directory, though some Arch users prefer to create a 'local' directory under {{ic|/var/abs/}}, owned by a normal user. <br />
<br />
Create your build directory. e.g.:<br />
<br />
$ mkdir -p $HOME/abs<br />
<br />
Copy the ABS from the tree ({{ic|/var/abs/<repository>/<pkgname>}}) to the build directory.<br />
<br />
=== Build package ===<br />
<br />
In our example, we will build the ''slim'' display manager package.<br />
<br />
Copy the slim ABS from the ABS tree to a build directory:<br />
<br />
$ cp -r /var/abs/extra/slim/ ~/abs<br />
<br />
Navigate to the build directory:<br />
<br />
$ cd ~/abs/slim<br />
<br />
Modify the PKGBUILD to your liking, then run ''makepkg'' (with the {{ic|-s}} flag to enable automatic build-time dependency handling):<br />
<br />
$ makepkg -s<br />
<br />
{{Note|Before complaining about missing (make) dependencies, remember that the group {{Grp|base-devel}} is assumed to be installed when building with ''makepkg''. See [[#Install tools]].}}<br />
<br />
Install as root:<br />
<br />
# pacman -U slim-1.3.0-2-i686.pkg.tar.xz<br />
<br />
That's it. You have just built slim from source and cleanly installed it to your system with pacman. Package removal is also handled by pacman with {{ic|pacman -R slim}}.<br />
<br />
The ABS method adds a level of convenience and automation, while still maintaining complete transparency and control of the build and installation functions by including them in the PKGBUILD.<br />
<br />
==== fakeroot ====<br />
<br />
Essentially, the same steps are being executed in the traditional method (generally including the {{ic|./configure, make, make install}} steps) but the software is installed into a ''fake root'' environment. (A ''fake root'' is simply a subdirectory within the build directory that functions and behaves as the system's root directory. In conjunction with the '''fakeroot''' program, ''makepkg'' creates a fake root directory, and installs the compiled binaries and associated files into it, with '''root''' as owner.) The ''fake root'', or subdirectory tree containing the compiled software, is then compressed into an archive with the extension {{ic|.pkg.tar.xz}}, or a ''package''. When invoked, pacman then extracts the package (installs it) into the system's real root directory ({{ic|/}}).<br />
<br />
=== Preserve modified packages ===<br />
<br />
Updating the system with pacman will replace a modified package from ABS with the package of the same name from the official repositories. See the following instructions for how to avoid this.<br />
<br />
Insert a group array into the PKGBUILD, and add the package to a group called {{ic|modified}}.<br />
<br />
{{hc|PKGBUILD|2=<br />
groups=('modified')<br />
}}<br />
<br />
Add this group to the section {{ic|IgnoreGroup}} in {{ic|/etc/pacman.conf}}.<br />
<br />
{{hc|/etc/pacman.conf|2=<br />
IgnoreGroup = modified<br />
}}<br />
<br />
If new versions are available in the official repositories during a system update, pacman prints a note that it is skipping this update because it is in the IgnoreGroup section. At this point the modified package should be rebuilt from ABS to avoid partial upgrades.</div>Ndthttps://wiki.archlinux.org/index.php?title=Arch_build_system&diff=330141Arch build system2014-08-13T16:47:28Z<p>Ndt: /* Set the PACKAGER variable in /etc/makepkg.conf */ inline code blocks for verbatim/code things</p>
<hr />
<div>[[Category:About Arch]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[cs:Arch Build System]]<br />
[[da:Arch Build System]]<br />
[[de:Arch Build System]]<br />
[[el:Arch Build System]]<br />
[[es:Arch Build System]]<br />
[[fr:ABS]]<br />
[[it:Arch Build System]]<br />
[[ja:Arch Build System]]<br />
[[ko:Arch Build System]]<br />
[[pl:Arch Build System]]<br />
[[ro:ABS]]<br />
[[ru:Arch Build System]]<br />
[[tr:Arch_derleme_sistemi]]<br />
[[zh-CN:Arch Build System]]<br />
[[zh-TW:Arch Build System]]<br />
{{Related articles start}}<br />
{{Related|Arch packaging standards}}<br />
{{Related|Arch User Repository}}<br />
{{Related|Creating packages}}<br />
{{Related|Kernel Compilation with ABS}}<br />
{{Related|makepkg}}<br />
{{Related|Official repositories}}<br />
{{Related|pacman}}<br />
{{Related|PKGBUILD}}<br />
{{Related articles end}}<br />
<br />
This article provides an overview of the Arch Build System along with a walkthrough for beginners. It is not a complete reference guide. If you need more information, please reference the man pages.<br />
<br />
{{Note|ABS syncs once a day so it may lag behind what is already available in the repositories.}}<br />
<br />
== What is the Arch Build System? ==<br />
<br />
The Arch Build System, '''ABS''' for short, is a ''ports-like'' system for building and packaging software from source code. While [[pacman]] is the specialized Arch tool for binary package management (including packages built with the ABS), ABS is a collection of tools for compiling source into installable {{ic|.pkg.tar.xz}} packages.<br />
<br />
=== What is a ports-like system? ===<br />
<br />
''Ports'' is a system used by *BSD to automate the process of building software from source code. The system uses a ''port'' to download, unpack, patch, compile, and install the given software. A ''port'' is merely a small directory on the user's computer, named after the corresponding software to be installed, that contains a few files with the instructions for building and installing the software from source. This makes installing software as simple as typing {{ic|make}} or {{ic|make install clean}} within the port's directory.<br />
<br />
=== ABS is a similar concept ===<br />
<br />
ABS is made up of a directory tree (the ABS tree) residing under {{ic|/var/abs}}. This tree contains many subdirectories, each within a category and each named by their respective package. This tree represents (but does not contain) all ''official Arch software'', retrievable through the SVN system. You may refer to each package-named subdirectory as an 'ABS', much the way one would refer to a 'port'. These ABS (or subdirectories) do not contain the software package nor the source but rather a [[PKGBUILD]] file (and sometimes other files). A PKGBUILD is a simple Bash build script -- a text file containing the compilation and packaging instructions as well as the URL of the appropriate '''source''' tarball to be downloaded. (The most important component of ABS are PKGBUILDs.) By issuing the ABS [[makepkg]] command, the software is first compiled and then ''packaged'' within the build directory before being installed. Now you may use [[pacman]], the Arch Linux package manager, to install, upgrade, and remove your new package.<br />
<br />
=== ABS overview ===<br />
<br />
'ABS' may be used as an umbrella term since it includes and relies on several other components; therefore, though not technically accurate, 'ABS' can refer to the following tools as a complete toolkit:<br />
<br />
; ABS tree: The ABS directory structure; an SVN hierarchy under {{ic|/var/abs/}} on your (local) machine. It contains many subdirectories, named for all available official Arch Linux software from repositories specified in {{ic|/etc/abs.conf}}, but not the packages themselves. The tree is created after installing the {{Pkg|abs}} package with [[pacman]] and subsequently running the {{ic|abs}} script.<br />
<br />
; [[PKGBUILD]]s: A [[Bash]] script that contains the URL of the source code along with the compilation and packaging instructions.<br />
<br />
; [[makepkg]]: ABS shell command tool which reads the PKGBUILDs, automatically downloads and compiles the sources and creates a {{ic|.pkg.tar*}} according to the {{ic|PKGEXT}} array in {{ic|makepkg.conf}}. You may also use makepkg to make your own custom packages from the [[AUR]] or third-party sources. (See the [[Creating packages]] wiki article.)<br />
<br />
; [[pacman]]: pacman is completely separate, but is necessarily invoked either by makepkg or manually, to install and remove the built packages and for fetching dependencies.<br />
<br />
; [[Arch User Repository|AUR]]: The Arch User Repository is separate from ABS but AUR (unsupported) PKGBUILDs are built using makepkg to compile and package up software. In contrast to the ABS tree on your local machine, the AUR exists as a website interface. It contains many thousands of user-contributed PKGBUILDs for software which is unavailable as an official Arch package. If you need to build a package outside the official Arch tree, chances are it is in the AUR.<br />
<br />
== Why would I want to use ABS? ==<br />
<br />
The Arch Build System is used to:<br />
* Compile or recompile a package, for any reason<br />
* Make and install new packages from source of software for which no packages are yet available (see [[Creating packages]]) <br />
* Customize existing packages to fit your needs (enabling or disabling options, patching)<br />
* Rebuild your entire system using your compiler flags, "à la FreeBSD" (e.g. with [[pacbuilder]])<br />
* Cleanly build and install your own custom kernel (see [[Kernel Compilation]])<br />
* Get kernel modules working with your custom kernel<br />
* Easily compile and install a newer, older, beta, or development version of an Arch package by editing the version number in the PKGBUILD<br />
<br />
ABS is not necessary to use Arch Linux, but it is useful for automating certain tasks of source compilation.<br />
<br />
== How to use ABS ==<br />
<br />
Building packages using abs consists of these steps:<br />
#Install the {{Pkg|abs}} package with [[pacman]].<br />
#Run {{ic|abs}} as root to create the ABS tree by synchronizing it with the Arch Linux server.<br />
#Copy the build files (usually residing under {{ic|/var/abs/<repo>/<pkgname>}}) to a build directory.<br />
#Navigate to that directory, edit the PKGBUILD (if desired/necessary) and do '''makepkg'''. <br />
#According to instructions in the PKGBUILD, makepkg will download the appropriate source tarball, unpack it, patch if desired, compile according to {{ic|CFLAGS}} specified in {{ic|makepkg.conf}}, and finally compress the built files into a package with the extension {{ic|.pkg.tar.gz}} or {{ic|.pkg.tar.xz}}. <br />
#Installing is as easy as doing {{ic|pacman -U <.pkg.tar.xz file>}}. Package removal is also handled by pacman.<br />
<br />
=== Install tools ===<br />
<br />
To use the ABS, you first need to [[pacman|install]] {{Pkg|abs}} from the [[official repositories]].<br />
<br />
This will grab the abs-sync scripts, various build scripts, and [[rsync]] (as a dependency, if you do not already have it).<br />
<br />
Before you can actually build anything, however, you will also need basic compiling tools. These are handily collected in the [[Pacman#Installing_package_groups|package group]] {{grp|base-devel}}. This group can be installed with pacman.<br />
<br />
=== /etc/abs.conf ===<br />
<br />
As root, edit {{ic|/etc/abs.conf}} to include your desired repositories.<br />
<br />
Remove the {{ic|!}} in front of the appropriate repositories. For example:<br />
REPOS=(core extra community !testing)<br />
<br />
=== ABS tree ===<br />
<br />
The ABS tree is an SVN directory hierarchy located under {{ic|/var/abs}} and looks like this:<br />
<br />
{{bc|<nowiki><br />
| -- core/<br />
| || -- acl/<br />
| || || -- PKGBUILD<br />
| || -- attr/<br />
| || || -- PKGBUILD<br />
| || -- abs/<br />
| || || -- PKGBUILD<br />
| || -- autoconf/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- extra/<br />
| || -- acpid/<br />
| || || -- PKGBUILD<br />
| || -- apache/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- community/<br />
| || -- ...<br />
</nowiki>}}<br />
<br />
The ABS tree has exactly the same structure as the package database:<br />
<br />
* First-level: Repository name<br />
* Second-level: Package name directories<br />
* Third level: PKGBUILD (contains information needed to build a package) and other related files (patches, other files needed for building the package)<br />
<br />
The source code for the package is not present in the ABS directory. Instead, the '''PKGBUILD''' file contains a URL that will download the source code when the package is built. So the size of abs tree is quite small.<br />
<br />
==== Download ABS tree ====<br />
<br />
As root, run:<br />
<br />
# abs<br />
<br />
Your ABS tree is now created under {{ic|/var/abs}}. Note the appropriate branches of the ABS tree now exist and correspond to the ones you specified in {{ic|/etc/abs.conf}}. <br />
<br />
The abs command should be run periodically to keep in sync with the official repositories. Individual ABS package files can also be downloaded with:<br />
<br />
# abs <repository>/<package><br />
<br />
This way you do not have to check out the entire abs tree just to build one package.<br />
<br />
=== /etc/makepkg.conf ===<br />
<br />
[[makepkg]]'s {{ic|/etc/makepkg.conf}} specifies global environment variables and compiler flags which you may wish to edit if you are using an SMP system, or to specify other desired optimizations. The default settings are for i686 and x86_64 optimizations which will work fine for those architectures on single-CPU systems. (The defaults will work on SMP machines, but will only use one core/CPU when compiling -- see [[makepkg]] for details.)<br />
<br />
==== Set the {{ic|PACKAGER}} variable in {{ic|/etc/makepkg.conf}} ====<br />
<br />
Setting the {{ic|PACKAGER}} variable in {{ic|/etc/makepkg.conf}} is an optional but ''highly recommended'' step. It allows a "flag" to quickly identify which packages have been built and/or installed by YOU, not the official maintainer! This is easily accomplished using {{Pkg|expac}} available from the community repo:<br />
<br />
===== Showing all packages (including those from AUR) =====<br />
<br />
$ grep myname /etc/makepkg.conf<br />
PACKAGER="myname <myemail@myserver.com>"<br />
<br />
$ expac "%n %p" | grep "myname" | column -t<br />
archey3 myname<br />
binutils myname<br />
gcc myname<br />
gcc-libs myname<br />
glibc myname<br />
tar myname<br />
<br />
===== Showing only packages contained in repos =====<br />
<br />
This example only shows packages contained in the repos defined in {{ic|/etc/pacman.conf}}:<br />
<br />
$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)<br />
binutils<br />
gcc<br />
gcc-libs<br />
glibc<br />
tar<br />
<br />
=== Create a build directory ===<br />
<br />
It is recommended to create a build directory where the actual compiling will take place; you should never modify the ABS tree by building within it, as data will be lost (overwritten) on each ABS update. It is good practice to use your home directory, though some Arch users prefer to create a 'local' directory under {{ic|/var/abs/}}, owned by a normal user. <br />
<br />
Create your build directory. e.g.:<br />
<br />
$ mkdir -p $HOME/abs<br />
<br />
Copy the ABS from the tree ({{ic|/var/abs/<repository>/<pkgname>}}) to the build directory.<br />
<br />
=== Build package ===<br />
<br />
In our example, we will build the ''slim'' display manager package.<br />
<br />
Copy the slim ABS from the ABS tree to a build directory:<br />
<br />
$ cp -r /var/abs/extra/slim/ ~/abs<br />
<br />
Navigate to the build directory:<br />
<br />
$ cd ~/abs/slim<br />
<br />
Modify the PKGBUILD to your liking, then run ''makepkg'' (with the {{ic|-s}} flag to enable automatic build-time dependency handling):<br />
<br />
$ makepkg -s<br />
<br />
{{Note|Before complaining about missing (make) dependencies, remember that the group {{Grp|base-devel}} is assumed to be installed when building with ''makepkg''. See [[#Install tools]].}}<br />
<br />
Install as root:<br />
<br />
# pacman -U slim-1.3.0-2-i686.pkg.tar.xz<br />
<br />
That's it. You have just built slim from source and cleanly installed it to your system with pacman. Package removal is also handled by pacman with {{ic|pacman -R slim}}.<br />
<br />
The ABS method adds a level of convenience and automation, while still maintaining complete transparency and control of the build and installation functions by including them in the PKGBUILD.<br />
<br />
==== fakeroot ====<br />
<br />
Essentially, the same steps are being executed in the traditional method (generally including the {{ic|./configure, make, make install}} steps) but the software is installed into a ''fake root'' environment. (A ''fake root'' is simply a subdirectory within the build directory that functions and behaves as the system's root directory. In conjunction with the '''fakeroot''' program, ''makepkg'' creates a fake root directory, and installs the compiled binaries and associated files into it, with '''root''' as owner.) The ''fake root'', or subdirectory tree containing the compiled software, is then compressed into an archive with the extension {{ic|.pkg.tar.xz}}, or a ''package''. When invoked, pacman then extracts the package (installs it) into the system's real root directory ({{ic|/}}).<br />
<br />
=== Preserve modified packages ===<br />
<br />
Updating the system with pacman will replace a modified package from ABS with the package of the same name from the official repositories. See the following instructions for how to avoid this.<br />
<br />
Insert a group array into the PKGBUILD, and add the package to a group called {{ic|modified}}.<br />
<br />
{{hc|PKGBUILD|2=<br />
groups=('modified')<br />
}}<br />
<br />
Add this group to the section {{ic|IgnoreGroup}} in {{ic|/etc/pacman.conf}}.<br />
<br />
{{hc|/etc/pacman.conf|2=<br />
IgnoreGroup = modified<br />
}}<br />
<br />
If new versions are available in the official repositories during a system update, pacman prints a note that it is skipping this update because it is in the IgnoreGroup section. At this point the modified package should be rebuilt from ABS to avoid partial upgrades.</div>Ndthttps://wiki.archlinux.org/index.php?title=Arch_build_system&diff=330140Arch build system2014-08-13T16:46:24Z<p>Ndt: /* /etc/makepkg.conf */ link to makepkg at the beginning of this section</p>
<hr />
<div>[[Category:About Arch]]<br />
[[Category:Package development]]<br />
[[Category:Package management]]<br />
[[cs:Arch Build System]]<br />
[[da:Arch Build System]]<br />
[[de:Arch Build System]]<br />
[[el:Arch Build System]]<br />
[[es:Arch Build System]]<br />
[[fr:ABS]]<br />
[[it:Arch Build System]]<br />
[[ja:Arch Build System]]<br />
[[ko:Arch Build System]]<br />
[[pl:Arch Build System]]<br />
[[ro:ABS]]<br />
[[ru:Arch Build System]]<br />
[[tr:Arch_derleme_sistemi]]<br />
[[zh-CN:Arch Build System]]<br />
[[zh-TW:Arch Build System]]<br />
{{Related articles start}}<br />
{{Related|Arch packaging standards}}<br />
{{Related|Arch User Repository}}<br />
{{Related|Creating packages}}<br />
{{Related|Kernel Compilation with ABS}}<br />
{{Related|makepkg}}<br />
{{Related|Official repositories}}<br />
{{Related|pacman}}<br />
{{Related|PKGBUILD}}<br />
{{Related articles end}}<br />
<br />
This article provides an overview of the Arch Build System along with a walkthrough for beginners. It is not a complete reference guide. If you need more information, please reference the man pages.<br />
<br />
{{Note|ABS syncs once a day so it may lag behind what is already available in the repositories.}}<br />
<br />
== What is the Arch Build System? ==<br />
<br />
The Arch Build System, '''ABS''' for short, is a ''ports-like'' system for building and packaging software from source code. While [[pacman]] is the specialized Arch tool for binary package management (including packages built with the ABS), ABS is a collection of tools for compiling source into installable {{ic|.pkg.tar.xz}} packages.<br />
<br />
=== What is a ports-like system? ===<br />
<br />
''Ports'' is a system used by *BSD to automate the process of building software from source code. The system uses a ''port'' to download, unpack, patch, compile, and install the given software. A ''port'' is merely a small directory on the user's computer, named after the corresponding software to be installed, that contains a few files with the instructions for building and installing the software from source. This makes installing software as simple as typing {{ic|make}} or {{ic|make install clean}} within the port's directory.<br />
<br />
=== ABS is a similar concept ===<br />
<br />
ABS is made up of a directory tree (the ABS tree) residing under {{ic|/var/abs}}. This tree contains many subdirectories, each within a category and each named by their respective package. This tree represents (but does not contain) all ''official Arch software'', retrievable through the SVN system. You may refer to each package-named subdirectory as an 'ABS', much the way one would refer to a 'port'. These ABS (or subdirectories) do not contain the software package nor the source but rather a [[PKGBUILD]] file (and sometimes other files). A PKGBUILD is a simple Bash build script -- a text file containing the compilation and packaging instructions as well as the URL of the appropriate '''source''' tarball to be downloaded. (The most important component of ABS are PKGBUILDs.) By issuing the ABS [[makepkg]] command, the software is first compiled and then ''packaged'' within the build directory before being installed. Now you may use [[pacman]], the Arch Linux package manager, to install, upgrade, and remove your new package.<br />
<br />
=== ABS overview ===<br />
<br />
'ABS' may be used as an umbrella term since it includes and relies on several other components; therefore, though not technically accurate, 'ABS' can refer to the following tools as a complete toolkit:<br />
<br />
; ABS tree: The ABS directory structure; an SVN hierarchy under {{ic|/var/abs/}} on your (local) machine. It contains many subdirectories, named for all available official Arch Linux software from repositories specified in {{ic|/etc/abs.conf}}, but not the packages themselves. The tree is created after installing the {{Pkg|abs}} package with [[pacman]] and subsequently running the {{ic|abs}} script.<br />
<br />
; [[PKGBUILD]]s: A [[Bash]] script that contains the URL of the source code along with the compilation and packaging instructions.<br />
<br />
; [[makepkg]]: ABS shell command tool which reads the PKGBUILDs, automatically downloads and compiles the sources and creates a {{ic|.pkg.tar*}} according to the {{ic|PKGEXT}} array in {{ic|makepkg.conf}}. You may also use makepkg to make your own custom packages from the [[AUR]] or third-party sources. (See the [[Creating packages]] wiki article.)<br />
<br />
; [[pacman]]: pacman is completely separate, but is necessarily invoked either by makepkg or manually, to install and remove the built packages and for fetching dependencies.<br />
<br />
; [[Arch User Repository|AUR]]: The Arch User Repository is separate from ABS but AUR (unsupported) PKGBUILDs are built using makepkg to compile and package up software. In contrast to the ABS tree on your local machine, the AUR exists as a website interface. It contains many thousands of user-contributed PKGBUILDs for software which is unavailable as an official Arch package. If you need to build a package outside the official Arch tree, chances are it is in the AUR.<br />
<br />
== Why would I want to use ABS? ==<br />
<br />
The Arch Build System is used to:<br />
* Compile or recompile a package, for any reason<br />
* Make and install new packages from source of software for which no packages are yet available (see [[Creating packages]]) <br />
* Customize existing packages to fit your needs (enabling or disabling options, patching)<br />
* Rebuild your entire system using your compiler flags, "à la FreeBSD" (e.g. with [[pacbuilder]])<br />
* Cleanly build and install your own custom kernel (see [[Kernel Compilation]])<br />
* Get kernel modules working with your custom kernel<br />
* Easily compile and install a newer, older, beta, or development version of an Arch package by editing the version number in the PKGBUILD<br />
<br />
ABS is not necessary to use Arch Linux, but it is useful for automating certain tasks of source compilation.<br />
<br />
== How to use ABS ==<br />
<br />
Building packages using abs consists of these steps:<br />
#Install the {{Pkg|abs}} package with [[pacman]].<br />
#Run {{ic|abs}} as root to create the ABS tree by synchronizing it with the Arch Linux server.<br />
#Copy the build files (usually residing under {{ic|/var/abs/<repo>/<pkgname>}}) to a build directory.<br />
#Navigate to that directory, edit the PKGBUILD (if desired/necessary) and do '''makepkg'''. <br />
#According to instructions in the PKGBUILD, makepkg will download the appropriate source tarball, unpack it, patch if desired, compile according to {{ic|CFLAGS}} specified in {{ic|makepkg.conf}}, and finally compress the built files into a package with the extension {{ic|.pkg.tar.gz}} or {{ic|.pkg.tar.xz}}. <br />
#Installing is as easy as doing {{ic|pacman -U <.pkg.tar.xz file>}}. Package removal is also handled by pacman.<br />
<br />
=== Install tools ===<br />
<br />
To use the ABS, you first need to [[pacman|install]] {{Pkg|abs}} from the [[official repositories]].<br />
<br />
This will grab the abs-sync scripts, various build scripts, and [[rsync]] (as a dependency, if you do not already have it).<br />
<br />
Before you can actually build anything, however, you will also need basic compiling tools. These are handily collected in the [[Pacman#Installing_package_groups|package group]] {{grp|base-devel}}. This group can be installed with pacman.<br />
<br />
=== /etc/abs.conf ===<br />
<br />
As root, edit {{ic|/etc/abs.conf}} to include your desired repositories.<br />
<br />
Remove the {{ic|!}} in front of the appropriate repositories. For example:<br />
REPOS=(core extra community !testing)<br />
<br />
=== ABS tree ===<br />
<br />
The ABS tree is an SVN directory hierarchy located under {{ic|/var/abs}} and looks like this:<br />
<br />
{{bc|<nowiki><br />
| -- core/<br />
| || -- acl/<br />
| || || -- PKGBUILD<br />
| || -- attr/<br />
| || || -- PKGBUILD<br />
| || -- abs/<br />
| || || -- PKGBUILD<br />
| || -- autoconf/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- extra/<br />
| || -- acpid/<br />
| || || -- PKGBUILD<br />
| || -- apache/<br />
| || || -- PKGBUILD<br />
| || -- ...<br />
| -- community/<br />
| || -- ...<br />
</nowiki>}}<br />
<br />
The ABS tree has exactly the same structure as the package database:<br />
<br />
* First-level: Repository name<br />
* Second-level: Package name directories<br />
* Third level: PKGBUILD (contains information needed to build a package) and other related files (patches, other files needed for building the package)<br />
<br />
The source code for the package is not present in the ABS directory. Instead, the '''PKGBUILD''' file contains a URL that will download the source code when the package is built. So the size of abs tree is quite small.<br />
<br />
==== Download ABS tree ====<br />
<br />
As root, run:<br />
<br />
# abs<br />
<br />
Your ABS tree is now created under {{ic|/var/abs}}. Note the appropriate branches of the ABS tree now exist and correspond to the ones you specified in {{ic|/etc/abs.conf}}. <br />
<br />
The abs command should be run periodically to keep in sync with the official repositories. Individual ABS package files can also be downloaded with:<br />
<br />
# abs <repository>/<package><br />
<br />
This way you do not have to check out the entire abs tree just to build one package.<br />
<br />
=== /etc/makepkg.conf ===<br />
<br />
[[makepkg]]'s {{ic|/etc/makepkg.conf}} specifies global environment variables and compiler flags which you may wish to edit if you are using an SMP system, or to specify other desired optimizations. The default settings are for i686 and x86_64 optimizations which will work fine for those architectures on single-CPU systems. (The defaults will work on SMP machines, but will only use one core/CPU when compiling -- see [[makepkg]] for details.)<br />
<br />
==== Set the PACKAGER variable in /etc/makepkg.conf ====<br />
<br />
Setting the PACKAGER variable in {{ic|/etc/makepkg.conf}} is an optional but ''highly recommended'' step. It allows a "flag" to quickly identify which packages have been built and/or installed by YOU, not the official maintainer! This is easily accomplished using {{Pkg|expac}} available from the community repo:<br />
<br />
===== Showing all packages (including those from AUR) =====<br />
<br />
$ grep myname /etc/makepkg.conf<br />
PACKAGER="myname <myemail@myserver.com>"<br />
<br />
$ expac "%n %p" | grep "myname" | column -t<br />
archey3 myname<br />
binutils myname<br />
gcc myname<br />
gcc-libs myname<br />
glibc myname<br />
tar myname<br />
<br />
===== Showing only packages contained in repos =====<br />
<br />
This example only shows packages contained in the repos defined in {{ic|/etc/pacman.conf}}:<br />
<br />
$ . /etc/makepkg.conf; grep -xvFf <(pacman -Qqm) <(expac "%n\t%p" | grep "$PACKAGER$" | cut -f1)<br />
binutils<br />
gcc<br />
gcc-libs<br />
glibc<br />
tar<br />
<br />
=== Create a build directory ===<br />
<br />
It is recommended to create a build directory where the actual compiling will take place; you should never modify the ABS tree by building within it, as data will be lost (overwritten) on each ABS update. It is good practice to use your home directory, though some Arch users prefer to create a 'local' directory under {{ic|/var/abs/}}, owned by a normal user. <br />
<br />
Create your build directory. e.g.:<br />
<br />
$ mkdir -p $HOME/abs<br />
<br />
Copy the ABS from the tree ({{ic|/var/abs/<repository>/<pkgname>}}) to the build directory.<br />
<br />
=== Build package ===<br />
<br />
In our example, we will build the ''slim'' display manager package.<br />
<br />
Copy the slim ABS from the ABS tree to a build directory:<br />
<br />
$ cp -r /var/abs/extra/slim/ ~/abs<br />
<br />
Navigate to the build directory:<br />
<br />
$ cd ~/abs/slim<br />
<br />
Modify the PKGBUILD to your liking, then run ''makepkg'' (with the {{ic|-s}} flag to enable automatic build-time dependency handling):<br />
<br />
$ makepkg -s<br />
<br />
{{Note|Before complaining about missing (make) dependencies, remember that the group {{Grp|base-devel}} is assumed to be installed when building with ''makepkg''. See [[#Install tools]].}}<br />
<br />
Install as root:<br />
<br />
# pacman -U slim-1.3.0-2-i686.pkg.tar.xz<br />
<br />
That's it. You have just built slim from source and cleanly installed it to your system with pacman. Package removal is also handled by pacman with {{ic|pacman -R slim}}.<br />
<br />
The ABS method adds a level of convenience and automation, while still maintaining complete transparency and control of the build and installation functions by including them in the PKGBUILD.<br />
<br />
==== fakeroot ====<br />
<br />
Essentially, the same steps are being executed in the traditional method (generally including the {{ic|./configure, make, make install}} steps) but the software is installed into a ''fake root'' environment. (A ''fake root'' is simply a subdirectory within the build directory that functions and behaves as the system's root directory. In conjunction with the '''fakeroot''' program, ''makepkg'' creates a fake root directory, and installs the compiled binaries and associated files into it, with '''root''' as owner.) The ''fake root'', or subdirectory tree containing the compiled software, is then compressed into an archive with the extension {{ic|.pkg.tar.xz}}, or a ''package''. When invoked, pacman then extracts the package (installs it) into the system's real root directory ({{ic|/}}).<br />
<br />
=== Preserve modified packages ===<br />
<br />
Updating the system with pacman will replace a modified package from ABS with the package of the same name from the official repositories. See the following instructions for how to avoid this.<br />
<br />
Insert a group array into the PKGBUILD, and add the package to a group called {{ic|modified}}.<br />
<br />
{{hc|PKGBUILD|2=<br />
groups=('modified')<br />
}}<br />
<br />
Add this group to the section {{ic|IgnoreGroup}} in {{ic|/etc/pacman.conf}}.<br />
<br />
{{hc|/etc/pacman.conf|2=<br />
IgnoreGroup = modified<br />
}}<br />
<br />
If new versions are available in the official repositories during a system update, pacman prints a note that it is skipping this update because it is in the IgnoreGroup section. At this point the modified package should be rebuilt from ABS to avoid partial upgrades.</div>Ndthttps://wiki.archlinux.org/index.php?title=Haskell&diff=329767Haskell2014-08-11T01:49:52Z<p>Ndt: /* Pros/Cons of the different methods */ table for pros/cons</p>
<hr />
<div>[[Category:Programming language]]<br />
[http://www.haskell.org Haskell] is a general purpose, purely functional, programming language.<br />
<br />
== Installation ==<br />
<br />
Haskell generates machine code that can be run natively on Linux. There is nothing special required to run a binary (already compiled) software, like the ones provided in the [[official repositories]] or by the [[ArchHaskell]] group. On the other side, [[AUR]] packages or source codes requires a compiler to build the software.<br />
<br />
Installing the compiler alone permits to build Haskell source code. For development there is a ''Haskell-Platform'' bundle which offers the complete set of tools to get started with Haskell.<br />
<br />
=== Compiler ===<br />
<br />
To build a Haskell source–code into native–code, a compiler must be installed. There are several [http://www.haskell.org/haskellwiki/Implementations implementations available], but the most used one (which became ''de facto'' the reference) is the GHC (Glasgow Haskell Compiler). It is available in the official repositories as {{Pkg|ghc}}.<br />
<br />
You can try it with the following file:<br />
<br />
{{hc|Main.hs|main &#61; putStrLn "Hello, World"}}<br />
<br />
and by running:<br />
<br />
{{hc|<br />
$ ghc Main.hs<br />
$ ./Main |<br />
Hello, World<br />
}}<br />
<br />
=== Haskell platform ===<br />
<br />
To start developing in Haskell easily, there is a [http://www.haskell.org/platform/ haskell-platform] bundle which is described as:<br />
<br />
:''The easiest way to get started with programming Haskell. It comes with all you need to get up and running. Think of it as "Haskell: batteries included".''<br />
<br />
An [[Arch User Repository|AUR]] package exists ({{AUR|haskell-platform}}), but can advantageously be replaced by [[pacman|installing]] the [https://bbs.archlinux.org/viewtopic.php?pid=1151382#p1151382 following packages] from the [[official repositories]]:<br />
<br />
* ghc ({{Pkg|ghc}}) — The compiler<br />
* cabal-install ({{Pkg|cabal-install}}) — A command line interface for ''Cabal'' and ''Hackage''<br />
* haddock ({{Pkg|haddock}}) — Tools for generating documentation<br />
* happy ({{Pkg|happy}}) — Parser generator<br />
* alex ({{Pkg|alex}}) — Lexical analyzer generator<br />
<br />
== Managing Haskell packages ==<br />
<br />
There are a lot of Haskell libraries and executables grouped in packages. They are all available on [http://hackage.haskell.org Hackage]. To install and manage these packages, several methods are available and unusual ones are explained in the rest of this section.<br />
<br />
The recommended workflow is the following:<br />
* [[Official repositories]] or [[#ArchHaskell repository|ArchHaskell repository]] as principal source of Haskell packages (the ''or'' is exclusive here)<br />
* [[#cabal-install|cabal-install]] (possibly with sandboxes) for Haskell development<br />
* [[Arch User Repository]] for packages that are not available elsewhere<br />
<br />
[https://github.com/magthe/cblrepo cblrepo] is a tool used for maintaining Haskell packages for Linux distributions. A wrapper around this, {{AUR|cabal2pkgbuild-git}}, can create PKGBUILD files from Hackage packages. See [[Haskell Package Guidelines]] for more information on ''creating new'' Haskell packages.<br />
<br />
=== Pros/Cons of the different methods ===<br />
<br />
The following table documents the advantages and disadvantages of different package management styles.<br />
<br />
{| class="wikitable"<br />
! '''Method'''<br />
! '''Pros'''<br />
! '''Cons'''<br />
|-<br />
| [[Official Repositories]] || Provided by ArchLinux developers, consistent versions of packages, already compiled || Only a few packages available<br />
|-<br />
| [[#ArchHaskell repository|ArchHaskell repository]] || Provided by ArchHaskell group, consistent versions of packages, already compiled || Need manual intervention to get started with<br />
|-<br />
| [[#cabal-install|cabal-install]] || All packages available || Installed in home folder, {{Pkg|cabal-install}} [https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager is not a package manager], incompatible versions of packages possible (aka. [http://www.haskell.org/haskellwiki/Cabal/Survival#What_is_the_difficulty_caused_by_Cabal-install.3F cabal hell])<br />
|-<br />
| [[Arch User Repository]] || Simple to get started || Risk of unmaintained or orphaned packages, incompatible versions of packages possible<br />
|-<br />
|}<br />
<br />
=== ArchHaskell repository ===<br />
<br />
See [[ArchHaskell]] for details.<br />
<br />
=== cabal-install ===<br />
<br />
{{warning|Discouraged method, keep in mind that {{Pkg|cabal-install}} [https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager is not a package manager].}}<br />
<br />
{{Note|The only exception is for Haskell development, where {{Pkg|cabal-install}} is the recommended tool. Since version 1.18, cabal provides a ''sandbox'' system that permits to isolate different versions of libraries for different projects. There is an introduction to cabal sandbox [http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html here].}}<br />
<br />
==== Preparation ====<br />
Install {{Pkg|cabal-install}} from the [[official repositories]].<br />
<br />
To run installed executables without specifying the path, the cabal binary folder {{ic|~/.cabal/bin}} must be added to the {{ic|$PATH}} variable. That can be done by putting the following line in your shell configuration file, for instance {{ic|~/.bashrc}} for {{Pkg|bash}} or {{ic|~/.zshrc}} for {{Pkg|zsh}}:<br />
{{bc|PATH&#61;$PATH:~/.cabal/bin}}<br />
<br />
==== Installing packages ====<br />
{{bc|<br />
$ cabal update<br />
$ cabal install <pkg>}}<br />
<br />
You can add {{ic|-j}} for parallel compilation. It is also possible to install a package system–wide with the {{ic|--global}} flag, but this is '''strongly discouraged'''. With the user–wide install, all files are kept in {{ic|~/.cabal}} and libraries are registered to {{ic|~/.ghc}}, offering the possibility to do a clean-up easily by simply removing these folders. With system–wide install, the files will be dispersed in the file system and difficult to manage.<br />
<br />
==== Removing packages ====<br />
There is no easy way to do it.</div>Ndthttps://wiki.archlinux.org/index.php?title=Haskell&diff=329766Haskell2014-08-11T01:45:34Z<p>Ndt: /* Managing Haskell packages */ better description of cblrepo/cabal2pkgbuild and what they do</p>
<hr />
<div>[[Category:Programming language]]<br />
[http://www.haskell.org Haskell] is a general purpose, purely functional, programming language.<br />
<br />
== Installation ==<br />
<br />
Haskell generates machine code that can be run natively on Linux. There is nothing special required to run a binary (already compiled) software, like the ones provided in the [[official repositories]] or by the [[ArchHaskell]] group. On the other side, [[AUR]] packages or source codes requires a compiler to build the software.<br />
<br />
Installing the compiler alone permits to build Haskell source code. For development there is a ''Haskell-Platform'' bundle which offers the complete set of tools to get started with Haskell.<br />
<br />
=== Compiler ===<br />
<br />
To build a Haskell source–code into native–code, a compiler must be installed. There are several [http://www.haskell.org/haskellwiki/Implementations implementations available], but the most used one (which became ''de facto'' the reference) is the GHC (Glasgow Haskell Compiler). It is available in the official repositories as {{Pkg|ghc}}.<br />
<br />
You can try it with the following file:<br />
<br />
{{hc|Main.hs|main &#61; putStrLn "Hello, World"}}<br />
<br />
and by running:<br />
<br />
{{hc|<br />
$ ghc Main.hs<br />
$ ./Main |<br />
Hello, World<br />
}}<br />
<br />
=== Haskell platform ===<br />
<br />
To start developing in Haskell easily, there is a [http://www.haskell.org/platform/ haskell-platform] bundle which is described as:<br />
<br />
:''The easiest way to get started with programming Haskell. It comes with all you need to get up and running. Think of it as "Haskell: batteries included".''<br />
<br />
An [[Arch User Repository|AUR]] package exists ({{AUR|haskell-platform}}), but can advantageously be replaced by [[pacman|installing]] the [https://bbs.archlinux.org/viewtopic.php?pid=1151382#p1151382 following packages] from the [[official repositories]]:<br />
<br />
* ghc ({{Pkg|ghc}}) — The compiler<br />
* cabal-install ({{Pkg|cabal-install}}) — A command line interface for ''Cabal'' and ''Hackage''<br />
* haddock ({{Pkg|haddock}}) — Tools for generating documentation<br />
* happy ({{Pkg|happy}}) — Parser generator<br />
* alex ({{Pkg|alex}}) — Lexical analyzer generator<br />
<br />
== Managing Haskell packages ==<br />
<br />
There are a lot of Haskell libraries and executables grouped in packages. They are all available on [http://hackage.haskell.org Hackage]. To install and manage these packages, several methods are available and unusual ones are explained in the rest of this section.<br />
<br />
The recommended workflow is the following:<br />
* [[Official repositories]] or [[#ArchHaskell repository|ArchHaskell repository]] as principal source of Haskell packages (the ''or'' is exclusive here)<br />
* [[#cabal-install|cabal-install]] (possibly with sandboxes) for Haskell development<br />
* [[Arch User Repository]] for packages that are not available elsewhere<br />
<br />
[https://github.com/magthe/cblrepo cblrepo] is a tool used for maintaining Haskell packages for Linux distributions. A wrapper around this, {{AUR|cabal2pkgbuild-git}}, can create PKGBUILD files from Hackage packages. See [[Haskell Package Guidelines]] for more information on ''creating new'' Haskell packages.<br />
<br />
=== Pros/Cons of the different methods ===<br />
<br />
* [[Official repositories]]<br />
: '''Pros''': Provided by ArchLinux developers, consistent versions of packages, already compiled<br />
: '''Cons''': Only a few packages available<br />
* [[#ArchHaskell repository|ArchHaskell repository]]<br />
: '''Pros''': Provided by ArchHaskell group, consistent versions of packages, already compiled<br />
: '''Cons''': Need manual intervention to get started with<br />
* [[#cabal-install|cabal-install]]<br />
: '''Pros''': All packages available<br />
: '''Cons''': Installed in home folder, {{Pkg|cabal-install}} [https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager is not a package manager], incompatible versions of packages possible (aka. [http://www.haskell.org/haskellwiki/Cabal/Survival#What_is_the_difficulty_caused_by_Cabal-install.3F cabal hell])<br />
* [[Arch User Repository]]<br />
: '''Pros''': Simple to get started<br />
: '''Cons''': Risk of unmaintained or orphaned packages, incompatible versions of packages possible<br />
<br />
=== ArchHaskell repository ===<br />
<br />
See [[ArchHaskell]] for details.<br />
<br />
=== cabal-install ===<br />
<br />
{{warning|Discouraged method, keep in mind that {{Pkg|cabal-install}} [https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager is not a package manager].}}<br />
<br />
{{Note|The only exception is for Haskell development, where {{Pkg|cabal-install}} is the recommended tool. Since version 1.18, cabal provides a ''sandbox'' system that permits to isolate different versions of libraries for different projects. There is an introduction to cabal sandbox [http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html here].}}<br />
<br />
==== Preparation ====<br />
Install {{Pkg|cabal-install}} from the [[official repositories]].<br />
<br />
To run installed executables without specifying the path, the cabal binary folder {{ic|~/.cabal/bin}} must be added to the {{ic|$PATH}} variable. That can be done by putting the following line in your shell configuration file, for instance {{ic|~/.bashrc}} for {{Pkg|bash}} or {{ic|~/.zshrc}} for {{Pkg|zsh}}:<br />
{{bc|PATH&#61;$PATH:~/.cabal/bin}}<br />
<br />
==== Installing packages ====<br />
{{bc|<br />
$ cabal update<br />
$ cabal install <pkg>}}<br />
<br />
You can add {{ic|-j}} for parallel compilation. It is also possible to install a package system–wide with the {{ic|--global}} flag, but this is '''strongly discouraged'''. With the user–wide install, all files are kept in {{ic|~/.cabal}} and libraries are registered to {{ic|~/.ghc}}, offering the possibility to do a clean-up easily by simply removing these folders. With system–wide install, the files will be dispersed in the file system and difficult to manage.<br />
<br />
==== Removing packages ====<br />
There is no easy way to do it.</div>Ndthttps://wiki.archlinux.org/index.php?title=Haskell&diff=329765Haskell2014-08-11T01:43:29Z<p>Ndt: /* Managing Haskell packages */ linkify cblrepo</p>
<hr />
<div>[[Category:Programming language]]<br />
[http://www.haskell.org Haskell] is a general purpose, purely functional, programming language.<br />
<br />
== Installation ==<br />
<br />
Haskell generates machine code that can be run natively on Linux. There is nothing special required to run a binary (already compiled) software, like the ones provided in the [[official repositories]] or by the [[ArchHaskell]] group. On the other side, [[AUR]] packages or source codes requires a compiler to build the software.<br />
<br />
Installing the compiler alone permits to build Haskell source code. For development there is a ''Haskell-Platform'' bundle which offers the complete set of tools to get started with Haskell.<br />
<br />
=== Compiler ===<br />
<br />
To build a Haskell source–code into native–code, a compiler must be installed. There are several [http://www.haskell.org/haskellwiki/Implementations implementations available], but the most used one (which became ''de facto'' the reference) is the GHC (Glasgow Haskell Compiler). It is available in the official repositories as {{Pkg|ghc}}.<br />
<br />
You can try it with the following file:<br />
<br />
{{hc|Main.hs|main &#61; putStrLn "Hello, World"}}<br />
<br />
and by running:<br />
<br />
{{hc|<br />
$ ghc Main.hs<br />
$ ./Main |<br />
Hello, World<br />
}}<br />
<br />
=== Haskell platform ===<br />
<br />
To start developing in Haskell easily, there is a [http://www.haskell.org/platform/ haskell-platform] bundle which is described as:<br />
<br />
:''The easiest way to get started with programming Haskell. It comes with all you need to get up and running. Think of it as "Haskell: batteries included".''<br />
<br />
An [[Arch User Repository|AUR]] package exists ({{AUR|haskell-platform}}), but can advantageously be replaced by [[pacman|installing]] the [https://bbs.archlinux.org/viewtopic.php?pid=1151382#p1151382 following packages] from the [[official repositories]]:<br />
<br />
* ghc ({{Pkg|ghc}}) — The compiler<br />
* cabal-install ({{Pkg|cabal-install}}) — A command line interface for ''Cabal'' and ''Hackage''<br />
* haddock ({{Pkg|haddock}}) — Tools for generating documentation<br />
* happy ({{Pkg|happy}}) — Parser generator<br />
* alex ({{Pkg|alex}}) — Lexical analyzer generator<br />
<br />
== Managing Haskell packages ==<br />
<br />
There are a lot of Haskell libraries and executables grouped in packages. They are all available on [http://hackage.haskell.org Hackage]. To install and manage these packages, several methods are available and unusual ones are explained in the rest of this section.<br />
<br />
The recommended workflow is the following:<br />
* [[Official repositories]] or [[#ArchHaskell repository|ArchHaskell repository]] as principal source of Haskell packages (the ''or'' is exclusive here)<br />
* [[#cabal-install|cabal-install]] (possibly with sandboxes) for Haskell development<br />
* [[Arch User Repository]] for packages that are not available elsewhere<br />
<br />
A wrapper around [https://github.com/magthe/cblrepo cblrepo] exists, called cabal2pkgbuild ({{AUR|cabal2pkgbuild-git}}), that you can use to create PKGBUILD files for Hackage packages. See [[Haskell Package Guidelines]] for more information on ''creating new'' Haskell packages.<br />
<br />
=== Pros/Cons of the different methods ===<br />
<br />
* [[Official repositories]]<br />
: '''Pros''': Provided by ArchLinux developers, consistent versions of packages, already compiled<br />
: '''Cons''': Only a few packages available<br />
* [[#ArchHaskell repository|ArchHaskell repository]]<br />
: '''Pros''': Provided by ArchHaskell group, consistent versions of packages, already compiled<br />
: '''Cons''': Need manual intervention to get started with<br />
* [[#cabal-install|cabal-install]]<br />
: '''Pros''': All packages available<br />
: '''Cons''': Installed in home folder, {{Pkg|cabal-install}} [https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager is not a package manager], incompatible versions of packages possible (aka. [http://www.haskell.org/haskellwiki/Cabal/Survival#What_is_the_difficulty_caused_by_Cabal-install.3F cabal hell])<br />
* [[Arch User Repository]]<br />
: '''Pros''': Simple to get started<br />
: '''Cons''': Risk of unmaintained or orphaned packages, incompatible versions of packages possible<br />
<br />
=== ArchHaskell repository ===<br />
<br />
See [[ArchHaskell]] for details.<br />
<br />
=== cabal-install ===<br />
<br />
{{warning|Discouraged method, keep in mind that {{Pkg|cabal-install}} [https://ivanmiljenovic.wordpress.com/2010/03/15/repeat-after-me-cabal-is-not-a-package-manager is not a package manager].}}<br />
<br />
{{Note|The only exception is for Haskell development, where {{Pkg|cabal-install}} is the recommended tool. Since version 1.18, cabal provides a ''sandbox'' system that permits to isolate different versions of libraries for different projects. There is an introduction to cabal sandbox [http://coldwa.st/e/blog/2013-08-20-Cabal-sandbox.html here].}}<br />
<br />
==== Preparation ====<br />
Install {{Pkg|cabal-install}} from the [[official repositories]].<br />
<br />
To run installed executables without specifying the path, the cabal binary folder {{ic|~/.cabal/bin}} must be added to the {{ic|$PATH}} variable. That can be done by putting the following line in your shell configuration file, for instance {{ic|~/.bashrc}} for {{Pkg|bash}} or {{ic|~/.zshrc}} for {{Pkg|zsh}}:<br />
{{bc|PATH&#61;$PATH:~/.cabal/bin}}<br />
<br />
==== Installing packages ====<br />
{{bc|<br />
$ cabal update<br />
$ cabal install <pkg>}}<br />
<br />
You can add {{ic|-j}} for parallel compilation. It is also possible to install a package system–wide with the {{ic|--global}} flag, but this is '''strongly discouraged'''. With the user–wide install, all files are kept in {{ic|~/.cabal}} and libraries are registered to {{ic|~/.ghc}}, offering the possibility to do a clean-up easily by simply removing these folders. With system–wide install, the files will be dispersed in the file system and difficult to manage.<br />
<br />
==== Removing packages ====<br />
There is no easy way to do it.</div>Ndthttps://wiki.archlinux.org/index.php?title=Haskell_package_guidelines&diff=329764Haskell package guidelines2014-08-11T01:43:09Z<p>Ndt: /* cabal2pkgbuild */ link to cblrepo</p>
<hr />
<div>[[Category:Package development]]<br />
[[it:Haskell Package Guidelines]]<br />
{{Stub|Please help improve this article by creating reasonable [[Creating packages|package creation guidelines]] for [[Haskell]] packages. The previous content on this page, which was unrelated to packaging guidelines, has been moved to [[ArchHaskell]].}}<br />
<br />
{{Package Guidelines}}<br />
<br />
This document aims to cover standards and guidelines for producing good [[Haskell]] [[Creating packages|packages]] on Arch.<br />
<br />
== cabal2pkgbuild ==<br />
<br />
{{AUR|cabal2pkgbuild-git}}, available in the [[AUR]], may be used to automatically generate Arch packages from [[Haskell#cabal-install | cabal]] build files. It is a wrapper around [https://github.com/magthe/cblrepo cblrepo]. Generally there should be one package (i.e., one [[PKGBUILD]]) per {{ic|.cabal}} file for a package.</div>Ndt