https://wiki.archlinux.org/api.php?action=feedcontributions&user=Saren&feedformat=atomArchWiki - User contributions [en]2024-03-29T00:37:59ZUser contributionsMediaWiki 1.41.0https://wiki.archlinux.org/index.php?title=Waydroid&diff=749705Waydroid2022-09-30T03:21:36Z<p>Saren: could have just removed the link instead of undoing</p>
<hr />
<div>[[Category:Sandboxing]]<br />
[[Category:Virtualization]]<br />
[[Category:Android]]<br />
{{Related articles start}}<br />
{{Related|Anbox}}<br />
{{Related|Linux Containers}}<br />
{{Related articles end}}<br />
<br />
{{Style|Need to improve style.}}<br />
<br />
Waydroid is a container-based approach to boot a full Android system on a regular GNU/Linux system.<br />
<br />
== Prerequisites ==<br />
<br />
=== CPU Requirements ===<br />
<br />
The requirements depend on the CPU architecture. You can check [https://developer.android.com/ndk/guides/abis#sa table] for more information.<br />
<br />
You can check if you have the required CPU instructions with {{ic|cat /proc/cpuinfo}}.<br />
<br />
=== GPU Requirements ===<br />
<br />
Waydroid currently works best with Intel GPUs. They should work out of the box.<br />
<br />
AMD GPUs appear to have mixed results (in particular, the ''RX 6800'' does not work using official images as of 2022-09-29); if Waydroid does ''not'' work you might also want to try to build a new Waydroid image (which works for Radeon 680M), or try the NVIDIA instructions below.<br />
<br />
NVIDIA GPUs do ''not'' work currently, but there are 2 workarounds:<br />
<br />
* Switch to integrated graphic card if possible;<br />
* Use software rendering:<br />
** Make sure that you have already run {{ic|waydroid init}} (see [[#Installation]] section)<br />
** Edit {{ic|/var/lib/waydroid/waydroid_base.prop}} and set:{{bc|<nowiki>ro.hardware.gralloc=default<br />
ro.hardware.egl=swiftshader</nowiki>}}<br />
** [[Restart]] the {{ic|waydroid-container.service}}.<br />
<br />
=== Wayland session manager ===<br />
<br />
Waydroid only works in a [[Wayland]] session manager, so make sure you are in a Wayland session.<br />
<br />
Note that even if you are in X11, many Wayland session managers support nested session (so you can run it inside your X11 session), the simplest example is {{pkg|weston}}.<br />
<br />
=== Kernel Modules ===<br />
<br />
You need to run a kernel which comes with the binder modules and optionally the ashmem one. They are not part of Arch Linux's default kernel ({{Pkg|linux}}), thus you need to install a kernel which ships these modules.<br />
<br />
You might also need to configure your bootloader to use a different kernel. Please refer to the wiki page of your bootloader how to boot with the new kernel. Booting into another kernel (version) is one of the few occasions when you have to reboot a Linux system. You should boot into the kernel with these modules before starting Waydroid.<br />
<br />
{{Note|1=Since {{aur|waydroid}} 1.2.1 ''ashmem'' is not needed anymore, ''memfd'' can be used instead, see [https://github.com/waydroid/waydroid/issues/406 issue]. This because ''ashmem'' has been completely replaced by ''memfd'' in ''mainline Linux'' since version 5.18, see [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=721412ed3d819e767cac2b06646bf03aa158aaec commit].}}<br />
<br />
To get a compatible kernel, you have multiple options:<br />
<br />
==== Using Linux-Zen ====<br />
<br />
The {{Pkg|linux-zen}} kernel includes the necessary modules. This might be the most comfortable way, as you do not have to compile the kernel (which takes a long time) and will receive updated versions regularly.<br />
<br />
==== DKMS modules ====<br />
<br />
You can install {{aur|anbox-modules-dkms-git}} and load kernel modules with: {{bc|# modprobe ashmem_linux<br />
# modprobe binder_linux<br />
}}<br />
<br />
==== Building a kernel ====<br />
<br />
Alternatively, you can recompile the {{Pkg|linux}} kernel — or other kernel packages (>=5.7) — with the necessary options. Also see [[Kernel#Compilation]].<br />
<br />
When setting compilation options, you have 2 options available; ''binder'' and ''binderfs''. Instructions for both are provided below.<br />
<br />
===== Using binder =====<br />
<br />
The modules can either be compiled into the kernel ({{ic|y}}), into modules ({{ic|m}}), or not at all ({{ic|n}}). Also, not all combinations in the configuration are possible, and some options will require other options.<br />
<br />
The configuration options below will compile binder as a module, while the last option specifies that there will be three devices created in the {{ic|/dev/}} directory, when the binder module is loaded.<br />
<br />
{{bc|1=<br />
CONFIG_ANDROID=y<br />
CONFIG_ANDROID_BINDER_IPC=m<br />
CONFIG_ANDROID_BINDERFS=n<br />
CONFIG_ANDROID_BINDER_DEVICES="binder,hwbinder,vndbinder"<br />
}}<br />
<br />
When building a kernel from the AUR, one can update the configuration with the following steps:<br />
<br />
# run {{ic|makepkg --nobuild}}, which will download the sources, verify and extract them and run the {{ic|prepare()}} function.<br />
# edit the {{ic|.config}} file (with the dot in the filename), which is located at the base of the kernel directory.<br />
# at the end of the {{ic|prepare()}} function was probably a command which regenerates the makefiles with information from the configuration, possibly {{ic|make olddefconfig}}. Move that to the {{ic|build()}} function, or execute it yourself.<br />
# run {{ic|makepkg --noextract}}, which will continue from the place where {{ic|makepkg --nobuild}} stopped.<br />
<br />
===== Using binderfs =====<br />
<br />
The binder kernel module is known to cause some issues to several users. To address these issues, binderfs was created. One has to choose between the old and the new way when compiling the kernel. With the options below, one will use binderfs instead.<br />
<br />
With the kernel sources comes also a simple script to set configuration options. It will not do dependency checks, just like when editing the configuration by hand. When being in the same directory where the {{ic|.config}} file lies, one can execute the following commands:<br />
<br />
{{bc|<br />
$ scripts/config --enable CONFIG_ANDROID<br />
$ scripts/config --enable CONFIG_ANDROID_BINDER_IPC<br />
$ scripts/config --enable CONFIG_ANDROID_BINDERFS<br />
$ scripts/config --set-str CONFIG_ANDROID_BINDER_DEVICES ""<br />
}}<br />
<br />
When building a kernel from the AUR, it is enough to insert these lines at the right place in the [[PKGBUILD]], usually in {{ic|prepare()}}.<br />
<br />
==== Setup binder devices ====<br />
<br />
Make sure you have the latest version of Waydroid package, and Waydroid will take automatically care of this.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|waydroid}} package.<br />
<br />
Optionally, install {{AUR|waydroid-image}} or {{AUR|waydroid-image-gapps}} to provide the needed Android image through AUR.<br />
<br />
Afterwards init Waydroid, this will automatically download the latest Android image if it is not yet available.<br />
# waydroid init<br />
<br />
To init with GApps support:<br />
# waydroid init -s GAPPS -f<br />
Next [[start/enable]] the {{ic|waydroid-container.service}}.<br />
<br />
Waydroid should now work.<br />
<br />
== Usage ==<br />
<br />
Make sure that {{ic|waydroid-container.service}} is running then run:<br />
$ waydroid session start<br />
<br />
The Waydroid session is now active, here are a couple of useful commands to interact with it:<br />
<br />
''Launch GUI'':<br />
$ waydroid show-full-ui<br />
''Launch shell'':<br />
# waydroid shell<br />
''Install an application'':<br />
$ waydroid app install $path_to_apk<br />
''Run an application'':<br />
$ waydroid app launch $package-name #Can be retrieved with `waydroid app list`<br />
<br />
== Network ==<br />
<br />
The network should work out of the box, if its not you might need to allow the following rules through your firewall ''before'' running ''Waydroid session start''.<br />
<br />
Taking {{pkg|ufw}} as an example:<br />
<br />
* Dns traffic needs to be allowed:<br />
** {{bc|# ufw allow 67}}<br />
** {{bc|# ufw allow 53}}<br />
* Packet forwarding needs to be allowed:<br />
** {{bc|# ufw default allow FORWARD}}<br />
<br />
For {{pkg|firewalld}}, you can use those commands:<br />
<br />
* DNS:<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-port=67/udp}}<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-port=53/udp}}<br />
* Packet forwarding:<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-forward}}<br />
<br />
{{Note|We assume that interface {{ic|waydroid0}} created by waydroid should be in the firewalld zone {{ic|trusted}} automatically. If not so, please adjust those commands above or move interface {{ic|waydroid0}} to {{ic|trusted}}. You may also need {{bc|# firewall-cmd --runtime-to-permanent}} to make your changes exist after a restart.}}<br />
<br />
== Troubleshooting ==<br />
<br />
If you run into issues, take a look at the official Issue Tracker: [https://github.com/waydroid/waydroid/issues Waydroid issue tracker]<br />
<br />
=== General tips ===<br />
<br />
Waydroid is in rapid developement so if you face issues, here is a good list of steps to do first:<br />
<br />
# Make sure your Waydroid package is up to date;<br />
# Make sure you have the latest Waydroid image by running {{bc|# waydroid upgrade}}<br />
# Reset Waydroid: [[stop]] the {{ic|waydroid-container.service}}, run {{bc|# waydroid init -f}} and [[start]] the service again. <br />
# You may also want to do little cleanup, run {{bc|# rm -rf /var/lib/waydroid /home/.waydroid}} {{bc|$ rm -rf ~/waydroid ~/.share/waydroid ~/.local/share/applications/*aydroid* ~/.local/share/waydroid}}<br />
<br />
=== Rotated apps are unusable ===<br />
<br />
See https://github.com/waydroid/waydroid/issues/70<br />
<br />
Click ''F11'' to switch the current app to windowed mode.<br />
<br />
=== Failed to start Clipboard manager service ===<br />
<br />
Install {{aur|python-pyclip}}<br />
<br />
=== Sometimes the physical keyboard does not work ===<br />
<br />
Press ''Left Alt'' key.<br />
<br />
=== Commands inside Waydroid shell outputs inaccessible or not found ===<br />
<br />
On Arch based distributions there's a [[Linux Containers#Basic usage|"bug" that may appear while working with lxc-attach]] that may cause this issue with commands inside {{ic|waydroid shell}} like {{ic|adbd}} or {{ic|settings}}.<br />
A possible workaround for this would be replace the {{bc|# waydroid shell}} command with {{bc|# lxc-attach -P /var/lib/waydroid/lxc/ -n waydroid --clear-env}}<br />
<br />
=== WARNING: Service manager /dev/binder has died ===<br />
<br />
See https://github.com/waydroid/waydroid/issues/136<br />
<br />
You should enable [https://docs.kernel.org/accounting/psi.html PSI].<br />
Add {{ic|1=psi=1}} to the [[kernel command line]].<br />
<br />
== See also ==<br />
<br />
* [https://github.com/waydroid/waydroid Waydroid GitHub repo]<br />
* [https://docs.waydro.id/ Waydroid documentation]<br />
* [https://matrix.to/#/#waydroid:connolly.tech Waydroid Matrix group]<br />
* [https://t.me/WayDroid Waydroid Telegram group]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Waydroid&diff=749704Waydroid2022-09-30T03:20:21Z<p>Saren: OK, let's not link to a random google doc then, but we have to let others know it could work.</p>
<hr />
<div>[[Category:Sandboxing]]<br />
[[Category:Virtualization]]<br />
[[Category:Android]]<br />
{{Related articles start}}<br />
{{Related|Anbox}}<br />
{{Related|Linux Containers}}<br />
{{Related articles end}}<br />
<br />
{{Style|Need to improve style.}}<br />
<br />
Waydroid is a container-based approach to boot a full Android system on a regular GNU/Linux system.<br />
<br />
== Prerequisites ==<br />
<br />
=== CPU Requirements ===<br />
<br />
The requirements depend on the CPU architecture. You can check [https://developer.android.com/ndk/guides/abis#sa table] for more information.<br />
<br />
You can check if you have the required CPU instructions with {{ic|cat /proc/cpuinfo}}.<br />
<br />
=== GPU Requirements ===<br />
<br />
Waydroid currently works best with Intel GPUs. They should work out of the box.<br />
<br />
AMD GPUs appear to have mixed results (in particular, the ''RX 6800'' does not work using official images as of 2022-09-29); if Waydroid does ''not'' work you might also want to try to build a new Waydroid image, or try the NVIDIA instructions below.<br />
<br />
NVIDIA GPUs do ''not'' work currently, but there are 2 workarounds:<br />
<br />
* Switch to integrated graphic card if possible;<br />
* Use software rendering:<br />
** Make sure that you have already run {{ic|waydroid init}} (see [[#Installation]] section)<br />
** Edit {{ic|/var/lib/waydroid/waydroid_base.prop}} and set:{{bc|<nowiki>ro.hardware.gralloc=default<br />
ro.hardware.egl=swiftshader</nowiki>}}<br />
** [[Restart]] the {{ic|waydroid-container.service}}.<br />
<br />
=== Wayland session manager ===<br />
<br />
Waydroid only works in a [[Wayland]] session manager, so make sure you are in a Wayland session.<br />
<br />
Note that even if you are in X11, many Wayland session managers support nested session (so you can run it inside your X11 session), the simplest example is {{pkg|weston}}.<br />
<br />
=== Kernel Modules ===<br />
<br />
You need to run a kernel which comes with the binder modules and optionally the ashmem one. They are not part of Arch Linux's default kernel ({{Pkg|linux}}), thus you need to install a kernel which ships these modules.<br />
<br />
You might also need to configure your bootloader to use a different kernel. Please refer to the wiki page of your bootloader how to boot with the new kernel. Booting into another kernel (version) is one of the few occasions when you have to reboot a Linux system. You should boot into the kernel with these modules before starting Waydroid.<br />
<br />
{{Note|1=Since {{aur|waydroid}} 1.2.1 ''ashmem'' is not needed anymore, ''memfd'' can be used instead, see [https://github.com/waydroid/waydroid/issues/406 issue]. This because ''ashmem'' has been completely replaced by ''memfd'' in ''mainline Linux'' since version 5.18, see [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=721412ed3d819e767cac2b06646bf03aa158aaec commit].}}<br />
<br />
To get a compatible kernel, you have multiple options:<br />
<br />
==== Using Linux-Zen ====<br />
<br />
The {{Pkg|linux-zen}} kernel includes the necessary modules. This might be the most comfortable way, as you do not have to compile the kernel (which takes a long time) and will receive updated versions regularly.<br />
<br />
==== DKMS modules ====<br />
<br />
You can install {{aur|anbox-modules-dkms-git}} and load kernel modules with: {{bc|# modprobe ashmem_linux<br />
# modprobe binder_linux<br />
}}<br />
<br />
==== Building a kernel ====<br />
<br />
Alternatively, you can recompile the {{Pkg|linux}} kernel — or other kernel packages (>=5.7) — with the necessary options. Also see [[Kernel#Compilation]].<br />
<br />
When setting compilation options, you have 2 options available; ''binder'' and ''binderfs''. Instructions for both are provided below.<br />
<br />
===== Using binder =====<br />
<br />
The modules can either be compiled into the kernel ({{ic|y}}), into modules ({{ic|m}}), or not at all ({{ic|n}}). Also, not all combinations in the configuration are possible, and some options will require other options.<br />
<br />
The configuration options below will compile binder as a module, while the last option specifies that there will be three devices created in the {{ic|/dev/}} directory, when the binder module is loaded.<br />
<br />
{{bc|1=<br />
CONFIG_ANDROID=y<br />
CONFIG_ANDROID_BINDER_IPC=m<br />
CONFIG_ANDROID_BINDERFS=n<br />
CONFIG_ANDROID_BINDER_DEVICES="binder,hwbinder,vndbinder"<br />
}}<br />
<br />
When building a kernel from the AUR, one can update the configuration with the following steps:<br />
<br />
# run {{ic|makepkg --nobuild}}, which will download the sources, verify and extract them and run the {{ic|prepare()}} function.<br />
# edit the {{ic|.config}} file (with the dot in the filename), which is located at the base of the kernel directory.<br />
# at the end of the {{ic|prepare()}} function was probably a command which regenerates the makefiles with information from the configuration, possibly {{ic|make olddefconfig}}. Move that to the {{ic|build()}} function, or execute it yourself.<br />
# run {{ic|makepkg --noextract}}, which will continue from the place where {{ic|makepkg --nobuild}} stopped.<br />
<br />
===== Using binderfs =====<br />
<br />
The binder kernel module is known to cause some issues to several users. To address these issues, binderfs was created. One has to choose between the old and the new way when compiling the kernel. With the options below, one will use binderfs instead.<br />
<br />
With the kernel sources comes also a simple script to set configuration options. It will not do dependency checks, just like when editing the configuration by hand. When being in the same directory where the {{ic|.config}} file lies, one can execute the following commands:<br />
<br />
{{bc|<br />
$ scripts/config --enable CONFIG_ANDROID<br />
$ scripts/config --enable CONFIG_ANDROID_BINDER_IPC<br />
$ scripts/config --enable CONFIG_ANDROID_BINDERFS<br />
$ scripts/config --set-str CONFIG_ANDROID_BINDER_DEVICES ""<br />
}}<br />
<br />
When building a kernel from the AUR, it is enough to insert these lines at the right place in the [[PKGBUILD]], usually in {{ic|prepare()}}.<br />
<br />
==== Setup binder devices ====<br />
<br />
Make sure you have the latest version of Waydroid package, and Waydroid will take automatically care of this.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|waydroid}} package.<br />
<br />
Optionally, install {{AUR|waydroid-image}} or {{AUR|waydroid-image-gapps}} to provide the needed Android image through AUR.<br />
<br />
Afterwards init Waydroid, this will automatically download the latest Android image if it is not yet available.<br />
# waydroid init<br />
<br />
To init with GApps support:<br />
# waydroid init -s GAPPS -f<br />
Next [[start/enable]] the {{ic|waydroid-container.service}}.<br />
<br />
Waydroid should now work.<br />
<br />
== Usage ==<br />
<br />
Make sure that {{ic|waydroid-container.service}} is running then run:<br />
$ waydroid session start<br />
<br />
The Waydroid session is now active, here are a couple of useful commands to interact with it:<br />
<br />
''Launch GUI'':<br />
$ waydroid show-full-ui<br />
''Launch shell'':<br />
# waydroid shell<br />
''Install an application'':<br />
$ waydroid app install $path_to_apk<br />
''Run an application'':<br />
$ waydroid app launch $package-name #Can be retrieved with `waydroid app list`<br />
<br />
== Network ==<br />
<br />
The network should work out of the box, if its not you might need to allow the following rules through your firewall ''before'' running ''Waydroid session start''.<br />
<br />
Taking {{pkg|ufw}} as an example:<br />
<br />
* Dns traffic needs to be allowed:<br />
** {{bc|# ufw allow 67}}<br />
** {{bc|# ufw allow 53}}<br />
* Packet forwarding needs to be allowed:<br />
** {{bc|# ufw default allow FORWARD}}<br />
<br />
For {{pkg|firewalld}}, you can use those commands:<br />
<br />
* DNS:<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-port=67/udp}}<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-port=53/udp}}<br />
* Packet forwarding:<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-forward}}<br />
<br />
{{Note|We assume that interface {{ic|waydroid0}} created by waydroid should be in the firewalld zone {{ic|trusted}} automatically. If not so, please adjust those commands above or move interface {{ic|waydroid0}} to {{ic|trusted}}. You may also need {{bc|# firewall-cmd --runtime-to-permanent}} to make your changes exist after a restart.}}<br />
<br />
== Troubleshooting ==<br />
<br />
If you run into issues, take a look at the official Issue Tracker: [https://github.com/waydroid/waydroid/issues Waydroid issue tracker]<br />
<br />
=== General tips ===<br />
<br />
Waydroid is in rapid developement so if you face issues, here is a good list of steps to do first:<br />
<br />
# Make sure your Waydroid package is up to date;<br />
# Make sure you have the latest Waydroid image by running {{bc|# waydroid upgrade}}<br />
# Reset Waydroid: [[stop]] the {{ic|waydroid-container.service}}, run {{bc|# waydroid init -f}} and [[start]] the service again. <br />
# You may also want to do little cleanup, run {{bc|# rm -rf /var/lib/waydroid /home/.waydroid}} {{bc|$ rm -rf ~/waydroid ~/.share/waydroid ~/.local/share/applications/*aydroid* ~/.local/share/waydroid}}<br />
<br />
=== Rotated apps are unusable ===<br />
<br />
See https://github.com/waydroid/waydroid/issues/70<br />
<br />
Click ''F11'' to switch the current app to windowed mode.<br />
<br />
=== Failed to start Clipboard manager service ===<br />
<br />
Install {{aur|python-pyclip}}<br />
<br />
=== Sometimes the physical keyboard does not work ===<br />
<br />
Press ''Left Alt'' key.<br />
<br />
=== Commands inside Waydroid shell outputs inaccessible or not found ===<br />
<br />
On Arch based distributions there's a [[Linux Containers#Basic usage|"bug" that may appear while working with lxc-attach]] that may cause this issue with commands inside {{ic|waydroid shell}} like {{ic|adbd}} or {{ic|settings}}.<br />
A possible workaround for this would be replace the {{bc|# waydroid shell}} command with {{bc|# lxc-attach -P /var/lib/waydroid/lxc/ -n waydroid --clear-env}}<br />
<br />
=== WARNING: Service manager /dev/binder has died ===<br />
<br />
See https://github.com/waydroid/waydroid/issues/136<br />
<br />
You should enable [https://docs.kernel.org/accounting/psi.html PSI].<br />
Add {{ic|1=psi=1}} to the [[kernel command line]].<br />
<br />
== See also ==<br />
<br />
* [https://github.com/waydroid/waydroid Waydroid GitHub repo]<br />
* [https://docs.waydro.id/ Waydroid documentation]<br />
* [https://matrix.to/#/#waydroid:connolly.tech Waydroid Matrix group]<br />
* [https://t.me/WayDroid Waydroid Telegram group]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Waydroid&diff=749570Waydroid2022-09-29T13:57:47Z<p>Saren: /* GPU Requirements */ a</p>
<hr />
<div>[[Category:Sandboxing]]<br />
[[Category:Virtualization]]<br />
[[Category:Android]]<br />
{{Related articles start}}<br />
{{Related|Anbox}}<br />
{{Related|Linux Containers}}<br />
{{Related articles end}}<br />
<br />
{{Style|Need to improve style.}}<br />
<br />
Waydroid is a container-based approach to boot a full Android system on a regular GNU/Linux system.<br />
<br />
== Prerequisites ==<br />
<br />
=== CPU Requirements ===<br />
<br />
The requirements depend on the CPU architecture. You can check [https://developer.android.com/ndk/guides/abis#sa table] for more information.<br />
<br />
You can check if you have the required CPU instructions with {{ic|cat /proc/cpuinfo}}.<br />
<br />
=== GPU Requirements ===<br />
<br />
Waydroid currently works best with Intel GPUs. They should work out of the box.<br />
<br />
AMD GPUs appear to have mixed results (in particular, the ''RX 6800'' does not work using official images as of 2022-09-29); if Waydroid does ''not'' work you might also want to try the NVIDIA instructions below, or try to build a new Waydroid image by following: https://docs.google.com/document/d/1Sly_VH3w6wFIdE72WXijQegoHZh8IxEnJ9m0hH7GodU/edit# (Works for Radeon 680M)<br />
<br />
NVIDIA GPUs do ''not'' work currently, but there are 2 workarounds:<br />
<br />
* Switch to integrated graphic card if possible;<br />
* Use software rendering:<br />
** Make sure that you have already run {{ic|waydroid init}} (see [[#Installation]] section)<br />
** Edit {{ic|/var/lib/waydroid/waydroid_base.prop}} and set:{{bc|<nowiki>ro.hardware.gralloc=default<br />
ro.hardware.egl=swiftshader</nowiki>}}<br />
** [[Restart]] the {{ic|waydroid-container.service}}.<br />
<br />
=== Wayland session manager ===<br />
<br />
Waydroid only works in a [[Wayland]] session manager, so make sure you are in a Wayland session.<br />
<br />
Note that even if you are in X11, many Wayland session managers support nested session (so you can run it inside your X11 session), the simplest example is {{pkg|weston}}.<br />
<br />
=== Kernel Modules ===<br />
<br />
You need to run a kernel which comes with the binder modules and optionally the ashmem one. They are not part of Arch Linux's default kernel ({{Pkg|linux}}), thus you need to install a kernel which ships these modules.<br />
<br />
You might also need to configure your bootloader to use a different kernel. Please refer to the wiki page of your bootloader how to boot with the new kernel. Booting into another kernel (version) is one of the few occasions when you have to reboot a Linux system. You should boot into the kernel with these modules before starting Waydroid.<br />
<br />
{{Note|1=Since {{aur|waydroid}} 1.2.1 ''ashmem'' is not needed anymore, ''memfd'' can be used instead, see [https://github.com/waydroid/waydroid/issues/406 issue]. This because ''ashmem'' has been completely replaced by ''memfd'' in ''mainline Linux'' since version 5.18, see [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=721412ed3d819e767cac2b06646bf03aa158aaec commit].}}<br />
<br />
To get a compatible kernel, you have multiple options:<br />
<br />
==== Using Linux-Zen ====<br />
<br />
The {{Pkg|linux-zen}} kernel includes the necessary modules. This might be the most comfortable way, as you do not have to compile the kernel (which takes a long time) and will receive updated versions regularly.<br />
<br />
==== DKMS modules ====<br />
<br />
You can install {{aur|anbox-modules-dkms-git}} and load kernel modules with: {{bc|# modprobe ashmem_linux<br />
# modprobe binder_linux<br />
}}<br />
<br />
==== Building a kernel ====<br />
<br />
Alternatively, you can recompile the {{Pkg|linux}} kernel — or other kernel packages (>=5.7) — with the necessary options. Also see [[Kernel#Compilation]].<br />
<br />
When setting compilation options, you have 2 options available; ''binder'' and ''binderfs''. Instructions for both are provided below.<br />
<br />
===== Using binder =====<br />
<br />
The modules can either be compiled into the kernel ({{ic|y}}), into modules ({{ic|m}}), or not at all ({{ic|n}}). Also, not all combinations in the configuration are possible, and some options will require other options.<br />
<br />
The configuration options below will compile binder as a module, while the last option specifies that there will be three devices created in the {{ic|/dev/}} directory, when the binder module is loaded.<br />
<br />
{{bc|1=<br />
CONFIG_ANDROID=y<br />
CONFIG_ANDROID_BINDER_IPC=m<br />
CONFIG_ANDROID_BINDERFS=n<br />
CONFIG_ANDROID_BINDER_DEVICES="binder,hwbinder,vndbinder"<br />
}}<br />
<br />
When building a kernel from the AUR, one can update the configuration with the following steps:<br />
<br />
# run {{ic|makepkg --nobuild}}, which will download the sources, verify and extract them and run the {{ic|prepare()}} function.<br />
# edit the {{ic|.config}} file (with the dot in the filename), which is located at the base of the kernel directory.<br />
# at the end of the {{ic|prepare()}} function was probably a command which regenerates the makefiles with information from the configuration, possibly {{ic|make olddefconfig}}. Move that to the {{ic|build()}} function, or execute it yourself.<br />
# run {{ic|makepkg --noextract}}, which will continue from the place where {{ic|makepkg --nobuild}} stopped.<br />
<br />
===== Using binderfs =====<br />
<br />
The binder kernel module is known to cause some issues to several users. To address these issues, binderfs was created. One has to choose between the old and the new way when compiling the kernel. With the options below, one will use binderfs instead.<br />
<br />
With the kernel sources comes also a simple script to set configuration options. It will not do dependency checks, just like when editing the configuration by hand. When being in the same directory where the {{ic|.config}} file lies, one can execute the following commands:<br />
<br />
{{bc|<br />
$ scripts/config --enable CONFIG_ANDROID<br />
$ scripts/config --enable CONFIG_ANDROID_BINDER_IPC<br />
$ scripts/config --enable CONFIG_ANDROID_BINDERFS<br />
$ scripts/config --set-str CONFIG_ANDROID_BINDER_DEVICES ""<br />
}}<br />
<br />
When building a kernel from the AUR, it is enough to insert these lines at the right place in the [[PKGBUILD]], usually in {{ic|prepare()}}.<br />
<br />
==== Setup binder devices ====<br />
<br />
Make sure you have the latest version of Waydroid package, and Waydroid will take automatically care of this.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|waydroid}} package.<br />
<br />
Optionally, install {{AUR|waydroid-image}} or {{AUR|waydroid-image-gapps}} to provide the needed Android image through AUR.<br />
<br />
Afterwards init Waydroid, this will automatically download the latest Android image if it is not yet available.<br />
# waydroid init<br />
<br />
To init with GApps support:<br />
# waydroid init -s GAPPS -f<br />
Next [[start/enable]] the {{ic|waydroid-container.service}}.<br />
<br />
Waydroid should now work.<br />
<br />
== Usage ==<br />
<br />
Make sure that {{ic|waydroid-container.service}} is running then run:<br />
$ waydroid session start<br />
<br />
The Waydroid session is now active, here are a couple of useful commands to interact with it:<br />
<br />
''Launch GUI'':<br />
$ waydroid show-full-ui<br />
''Launch shell'':<br />
# waydroid shell<br />
''Install an application'':<br />
$ waydroid app install $path_to_apk<br />
''Run an application'':<br />
$ waydroid app launch $package-name #Can be retrieved with `waydroid app list`<br />
<br />
== Network ==<br />
<br />
The network should work out of the box, if its not you might need to allow the following rules through your firewall ''before'' running ''Waydroid session start''.<br />
<br />
Taking {{pkg|ufw}} as an example:<br />
<br />
* Dns traffic needs to be allowed:<br />
** {{bc|# ufw allow 67}}<br />
** {{bc|# ufw allow 53}}<br />
* Packet forwarding needs to be allowed:<br />
** {{bc|# ufw default allow FORWARD}}<br />
<br />
For {{pkg|firewalld}}, you can use those commands:<br />
<br />
* DNS:<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-port=67/udp}}<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-port=53/udp}}<br />
* Packet forwarding:<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-forward}}<br />
<br />
{{Note|We assume that interface {{ic|waydroid0}} created by waydroid should be in the firewalld zone {{ic|trusted}} automatically. If not so, please adjust those commands above or move interface {{ic|waydroid0}} to {{ic|trusted}}. You may also need {{bc|# firewall-cmd --runtime-to-permanent}} to make your changes exist after a restart.}}<br />
<br />
== Troubleshooting ==<br />
<br />
If you run into issues, take a look at the official Issue Tracker: [https://github.com/waydroid/waydroid/issues Waydroid issue tracker]<br />
<br />
=== General tips ===<br />
<br />
Waydroid is in rapid developement so if you face issues, here is a good list of steps to do first:<br />
<br />
# Make sure your Waydroid package is up to date;<br />
# Make sure you have the latest Waydroid image by running {{bc|# waydroid upgrade}}<br />
# Reset Waydroid: [[stop]] the {{ic|waydroid-container.service}}, run {{bc|# waydroid init -f}} and [[start]] the service again. <br />
# You may also want to do little cleanup, run {{bc|# rm -rf /var/lib/waydroid /home/.waydroid}} {{bc|$ rm -rf ~/waydroid ~/.share/waydroid ~/.local/share/applications/*aydroid* ~/.local/share/waydroid}}<br />
<br />
=== Rotated apps are unusable ===<br />
<br />
See https://github.com/waydroid/waydroid/issues/70<br />
<br />
Click ''F11'' to switch the current app to windowed mode.<br />
<br />
=== Failed to start Clipboard manager service ===<br />
<br />
Install {{aur|python-pyclip}}<br />
<br />
=== Sometimes the physical keyboard does not work ===<br />
<br />
Press ''Left Alt'' key.<br />
<br />
=== Commands inside Waydroid shell outputs inaccessible or not found ===<br />
<br />
On Arch based distributions there's a [[Linux Containers#Basic usage|"bug" that may appear while working with lxc-attach]] that may cause this issue with commands inside {{ic|waydroid shell}} like {{ic|adbd}} or {{ic|settings}}.<br />
A possible workaround for this would be replace the {{bc|# waydroid shell}} command with {{bc|# lxc-attach -P /var/lib/waydroid/lxc/ -n waydroid --clear-env}}<br />
<br />
=== WARNING: Service manager /dev/binder has died ===<br />
<br />
See https://github.com/waydroid/waydroid/issues/136<br />
<br />
You should enable [https://docs.kernel.org/accounting/psi.html PSI].<br />
Add {{ic|1=psi=1}} to the [[kernel command line]].<br />
<br />
== See also ==<br />
<br />
* [https://github.com/waydroid/waydroid Waydroid GitHub repo]<br />
* [https://docs.waydro.id/ Waydroid documentation]<br />
* [https://matrix.to/#/#waydroid:connolly.tech Waydroid Matrix group]<br />
* [https://t.me/WayDroid Waydroid Telegram group]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Waydroid&diff=749569Waydroid2022-09-29T13:57:29Z<p>Saren: /* GPU Requirements */ A newer image works for me</p>
<hr />
<div>[[Category:Sandboxing]]<br />
[[Category:Virtualization]]<br />
[[Category:Android]]<br />
{{Related articles start}}<br />
{{Related|Anbox}}<br />
{{Related|Linux Containers}}<br />
{{Related articles end}}<br />
<br />
{{Style|Need to improve style.}}<br />
<br />
Waydroid is a container-based approach to boot a full Android system on a regular GNU/Linux system.<br />
<br />
== Prerequisites ==<br />
<br />
=== CPU Requirements ===<br />
<br />
The requirements depend on the CPU architecture. You can check [https://developer.android.com/ndk/guides/abis#sa table] for more information.<br />
<br />
You can check if you have the required CPU instructions with {{ic|cat /proc/cpuinfo}}.<br />
<br />
=== GPU Requirements ===<br />
<br />
Waydroid currently works best with Intel GPUs. They should work out of the box.<br />
<br />
AMD GPUs appear to have mixed results (in particular, the ''RX 6800'' does not work using official images as of 2022-09-29); if Waydroid does ''not'' work you might also want to try the NVIDIA instructions below, or try to build a new waydroid by following: https://docs.google.com/document/d/1Sly_VH3w6wFIdE72WXijQegoHZh8IxEnJ9m0hH7GodU/edit# (Works for Radeon 680M)<br />
<br />
NVIDIA GPUs do ''not'' work currently, but there are 2 workarounds:<br />
<br />
* Switch to integrated graphic card if possible;<br />
* Use software rendering:<br />
** Make sure that you have already run {{ic|waydroid init}} (see [[#Installation]] section)<br />
** Edit {{ic|/var/lib/waydroid/waydroid_base.prop}} and set:{{bc|<nowiki>ro.hardware.gralloc=default<br />
ro.hardware.egl=swiftshader</nowiki>}}<br />
** [[Restart]] the {{ic|waydroid-container.service}}.<br />
<br />
=== Wayland session manager ===<br />
<br />
Waydroid only works in a [[Wayland]] session manager, so make sure you are in a Wayland session.<br />
<br />
Note that even if you are in X11, many Wayland session managers support nested session (so you can run it inside your X11 session), the simplest example is {{pkg|weston}}.<br />
<br />
=== Kernel Modules ===<br />
<br />
You need to run a kernel which comes with the binder modules and optionally the ashmem one. They are not part of Arch Linux's default kernel ({{Pkg|linux}}), thus you need to install a kernel which ships these modules.<br />
<br />
You might also need to configure your bootloader to use a different kernel. Please refer to the wiki page of your bootloader how to boot with the new kernel. Booting into another kernel (version) is one of the few occasions when you have to reboot a Linux system. You should boot into the kernel with these modules before starting Waydroid.<br />
<br />
{{Note|1=Since {{aur|waydroid}} 1.2.1 ''ashmem'' is not needed anymore, ''memfd'' can be used instead, see [https://github.com/waydroid/waydroid/issues/406 issue]. This because ''ashmem'' has been completely replaced by ''memfd'' in ''mainline Linux'' since version 5.18, see [https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=721412ed3d819e767cac2b06646bf03aa158aaec commit].}}<br />
<br />
To get a compatible kernel, you have multiple options:<br />
<br />
==== Using Linux-Zen ====<br />
<br />
The {{Pkg|linux-zen}} kernel includes the necessary modules. This might be the most comfortable way, as you do not have to compile the kernel (which takes a long time) and will receive updated versions regularly.<br />
<br />
==== DKMS modules ====<br />
<br />
You can install {{aur|anbox-modules-dkms-git}} and load kernel modules with: {{bc|# modprobe ashmem_linux<br />
# modprobe binder_linux<br />
}}<br />
<br />
==== Building a kernel ====<br />
<br />
Alternatively, you can recompile the {{Pkg|linux}} kernel — or other kernel packages (>=5.7) — with the necessary options. Also see [[Kernel#Compilation]].<br />
<br />
When setting compilation options, you have 2 options available; ''binder'' and ''binderfs''. Instructions for both are provided below.<br />
<br />
===== Using binder =====<br />
<br />
The modules can either be compiled into the kernel ({{ic|y}}), into modules ({{ic|m}}), or not at all ({{ic|n}}). Also, not all combinations in the configuration are possible, and some options will require other options.<br />
<br />
The configuration options below will compile binder as a module, while the last option specifies that there will be three devices created in the {{ic|/dev/}} directory, when the binder module is loaded.<br />
<br />
{{bc|1=<br />
CONFIG_ANDROID=y<br />
CONFIG_ANDROID_BINDER_IPC=m<br />
CONFIG_ANDROID_BINDERFS=n<br />
CONFIG_ANDROID_BINDER_DEVICES="binder,hwbinder,vndbinder"<br />
}}<br />
<br />
When building a kernel from the AUR, one can update the configuration with the following steps:<br />
<br />
# run {{ic|makepkg --nobuild}}, which will download the sources, verify and extract them and run the {{ic|prepare()}} function.<br />
# edit the {{ic|.config}} file (with the dot in the filename), which is located at the base of the kernel directory.<br />
# at the end of the {{ic|prepare()}} function was probably a command which regenerates the makefiles with information from the configuration, possibly {{ic|make olddefconfig}}. Move that to the {{ic|build()}} function, or execute it yourself.<br />
# run {{ic|makepkg --noextract}}, which will continue from the place where {{ic|makepkg --nobuild}} stopped.<br />
<br />
===== Using binderfs =====<br />
<br />
The binder kernel module is known to cause some issues to several users. To address these issues, binderfs was created. One has to choose between the old and the new way when compiling the kernel. With the options below, one will use binderfs instead.<br />
<br />
With the kernel sources comes also a simple script to set configuration options. It will not do dependency checks, just like when editing the configuration by hand. When being in the same directory where the {{ic|.config}} file lies, one can execute the following commands:<br />
<br />
{{bc|<br />
$ scripts/config --enable CONFIG_ANDROID<br />
$ scripts/config --enable CONFIG_ANDROID_BINDER_IPC<br />
$ scripts/config --enable CONFIG_ANDROID_BINDERFS<br />
$ scripts/config --set-str CONFIG_ANDROID_BINDER_DEVICES ""<br />
}}<br />
<br />
When building a kernel from the AUR, it is enough to insert these lines at the right place in the [[PKGBUILD]], usually in {{ic|prepare()}}.<br />
<br />
==== Setup binder devices ====<br />
<br />
Make sure you have the latest version of Waydroid package, and Waydroid will take automatically care of this.<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|waydroid}} package.<br />
<br />
Optionally, install {{AUR|waydroid-image}} or {{AUR|waydroid-image-gapps}} to provide the needed Android image through AUR.<br />
<br />
Afterwards init Waydroid, this will automatically download the latest Android image if it is not yet available.<br />
# waydroid init<br />
<br />
To init with GApps support:<br />
# waydroid init -s GAPPS -f<br />
Next [[start/enable]] the {{ic|waydroid-container.service}}.<br />
<br />
Waydroid should now work.<br />
<br />
== Usage ==<br />
<br />
Make sure that {{ic|waydroid-container.service}} is running then run:<br />
$ waydroid session start<br />
<br />
The Waydroid session is now active, here are a couple of useful commands to interact with it:<br />
<br />
''Launch GUI'':<br />
$ waydroid show-full-ui<br />
''Launch shell'':<br />
# waydroid shell<br />
''Install an application'':<br />
$ waydroid app install $path_to_apk<br />
''Run an application'':<br />
$ waydroid app launch $package-name #Can be retrieved with `waydroid app list`<br />
<br />
== Network ==<br />
<br />
The network should work out of the box, if its not you might need to allow the following rules through your firewall ''before'' running ''Waydroid session start''.<br />
<br />
Taking {{pkg|ufw}} as an example:<br />
<br />
* Dns traffic needs to be allowed:<br />
** {{bc|# ufw allow 67}}<br />
** {{bc|# ufw allow 53}}<br />
* Packet forwarding needs to be allowed:<br />
** {{bc|# ufw default allow FORWARD}}<br />
<br />
For {{pkg|firewalld}}, you can use those commands:<br />
<br />
* DNS:<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-port=67/udp}}<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-port=53/udp}}<br />
* Packet forwarding:<br />
** {{bc|1=# firewall-cmd --zone=trusted --add-forward}}<br />
<br />
{{Note|We assume that interface {{ic|waydroid0}} created by waydroid should be in the firewalld zone {{ic|trusted}} automatically. If not so, please adjust those commands above or move interface {{ic|waydroid0}} to {{ic|trusted}}. You may also need {{bc|# firewall-cmd --runtime-to-permanent}} to make your changes exist after a restart.}}<br />
<br />
== Troubleshooting ==<br />
<br />
If you run into issues, take a look at the official Issue Tracker: [https://github.com/waydroid/waydroid/issues Waydroid issue tracker]<br />
<br />
=== General tips ===<br />
<br />
Waydroid is in rapid developement so if you face issues, here is a good list of steps to do first:<br />
<br />
# Make sure your Waydroid package is up to date;<br />
# Make sure you have the latest Waydroid image by running {{bc|# waydroid upgrade}}<br />
# Reset Waydroid: [[stop]] the {{ic|waydroid-container.service}}, run {{bc|# waydroid init -f}} and [[start]] the service again. <br />
# You may also want to do little cleanup, run {{bc|# rm -rf /var/lib/waydroid /home/.waydroid}} {{bc|$ rm -rf ~/waydroid ~/.share/waydroid ~/.local/share/applications/*aydroid* ~/.local/share/waydroid}}<br />
<br />
=== Rotated apps are unusable ===<br />
<br />
See https://github.com/waydroid/waydroid/issues/70<br />
<br />
Click ''F11'' to switch the current app to windowed mode.<br />
<br />
=== Failed to start Clipboard manager service ===<br />
<br />
Install {{aur|python-pyclip}}<br />
<br />
=== Sometimes the physical keyboard does not work ===<br />
<br />
Press ''Left Alt'' key.<br />
<br />
=== Commands inside Waydroid shell outputs inaccessible or not found ===<br />
<br />
On Arch based distributions there's a [[Linux Containers#Basic usage|"bug" that may appear while working with lxc-attach]] that may cause this issue with commands inside {{ic|waydroid shell}} like {{ic|adbd}} or {{ic|settings}}.<br />
A possible workaround for this would be replace the {{bc|# waydroid shell}} command with {{bc|# lxc-attach -P /var/lib/waydroid/lxc/ -n waydroid --clear-env}}<br />
<br />
=== WARNING: Service manager /dev/binder has died ===<br />
<br />
See https://github.com/waydroid/waydroid/issues/136<br />
<br />
You should enable [https://docs.kernel.org/accounting/psi.html PSI].<br />
Add {{ic|1=psi=1}} to the [[kernel command line]].<br />
<br />
== See also ==<br />
<br />
* [https://github.com/waydroid/waydroid Waydroid GitHub repo]<br />
* [https://docs.waydro.id/ Waydroid documentation]<br />
* [https://matrix.to/#/#waydroid:connolly.tech Waydroid Matrix group]<br />
* [https://t.me/WayDroid Waydroid Telegram group]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Diskless_system&diff=727139Diskless system2022-04-21T10:49:34Z<p>Saren: Clearer</p>
<hr />
<div>[[Category:Installation process]]<br />
[[de:Diskless_Workstation]]<br />
[[ja:ディスクレスシステム]]<br />
[[ru:Diskless system]]<br />
[[zh-hans:Diskless system]]<br />
{{Related articles start}}<br />
{{Related|NFS}}<br />
{{Related|NFS Troubleshooting}}<br />
{{Related|PXE}}<br />
{{Related|Mkinitcpio#Using net}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
From [[Wikipedia:Diskless node]]<br />
:''A diskless node (or diskless workstation) is a workstation or personal computer without disk drives, which employs network booting to load its operating system from a server.''<br />
<br />
== Server configuration ==<br />
<br />
First of all, we must install the following components:<br />
* A [[Dhcpd|DHCP]] server to assign IP addresses to our diskless nodes.<br />
* A [[TFTP]] server to transfer the boot image (a requirement of all PXE option roms).<br />
* A form of network storage ([[NFS]] or NBD) to export the Arch installation to the diskless node.<br />
<br />
{{Note|{{pkg|dnsmasq}} is capable of simultaneously acting as both DHCP and TFTP server. For more information, see the [[dnsmasq]] article.}}<br />
<br />
=== DHCP ===<br />
<br />
Install ISC {{Pkg|dhcp}} and configure it:<br />
<br />
{{hc|/etc/dhcpd.conf|2=<br />
allow booting;<br />
allow bootp;<br />
<br />
authoritative;<br />
<br />
option domain-name-servers 10.0.0.1;<br />
<br />
option architecture code 93 = unsigned integer 16;<br />
<br />
group {<br />
next-server 10.0.0.1;<br />
<br />
if option architecture = 00:07 {<br />
filename "/grub/x86_64-efi/core.efi";<br />
} else {<br />
filename "/grub/i386-pc/core.0";<br />
}<br />
<br />
subnet 10.0.0.0 netmask 255.255.255.0 {<br />
option routers 10.0.0.1;<br />
range 10.0.0.128 10.0.0.254;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|{{ic|next-server}} should be the address of the TFTP server; everything else should be changed to match your network}}<br />
<br />
RFC 4578 defines the "Client System Architecture Type" dhcp option. In the above configuration, if the PXE client requests an x86_64-efi binary (type 0x7), we appropriately give them one, otherwise falling back to the legacy binary. This allows both UEFI and legacy BIOS clients to boot simultaneously on the same network segment.<br />
<br />
Start ISC DHCP [[systemd]] service.<br />
<br />
=== TFTP ===<br />
<br />
The TFTP server will be used to transfer the bootloader, kernel, and initramfs to the client.<br />
<br />
Set the TFTP root to {{ic|/srv/arch/boot}}. See [[TFTP]] for installation and configuration.<br />
<br />
=== Network storage ===<br />
<br />
The primary difference between using NFS and NBD is while with both you can in fact have multiple clients using the same installation, with NBD (by the nature of manipulating a filesystem directly) you will need to use the {{ic|copyonwrite}} mode to do so, which ends up discarding all writes on client disconnect. In some situations however, this might be highly desirable.<br />
<br />
==== NFS ====<br />
<br />
Install {{Pkg|nfs-utils}} on the server.<br />
<br />
You will need to add the root of your Arch installation to your [[NFS]] exports:<br />
<br />
{{hc|/etc/exports|2=<br />
/srv *(rw,fsid=0,no_root_squash,no_subtree_check)<br />
/srv/arch *(rw,no_root_squash,no_subtree_check)<br />
}}<br />
<br />
Next, start NFS services: {{ic|nfs-idmapd}} {{ic|nfs-mountd}}.<br />
<br />
==== NBD ====<br />
<br />
Install {{Pkg|nbd}} and configure it.<br />
<br />
{{hc|/etc/nbd-server/config|2=<br />
[generic]<br />
user = nbd<br />
group = nbd<br />
[arch]<br />
exportname = /srv/arch.img<br />
copyonwrite = false<br />
}}<br />
<br />
{{Note|Set {{ic|copyonwrite}} to true if you want to have multiple clients using the same NBD share simultaneously; refer to {{man|5|nbd-server}} for more details. Also use [[chown]] to change the ownership of the exportname directory to the user {{ic|nbd}}.}}<br />
<br />
Start {{ic|nbd}} systemd service.<br />
<br />
== Client installation ==<br />
<br />
Next we will create a full Arch Linux installation in a subdirectory on the server. During boot, the diskless client will get an IP address from the DHCP server, then boot from the host using PXE and mount this installation as its root.<br />
<br />
=== Directory setup ===<br />
<br />
{{Note|Creating a separate filesystem is required for NBD but optional for NFS and can be skipped/ignored.}}<br />
<br />
Create a [[Wikipedia: Sparse file|sparse file]] of at least 1 gigabyte, and create a btrfs filesystem on it (you can of course also use a real block device or [[LVM]] if you want).<br />
<br />
# truncate -s 1G /srv/arch.img<br />
# mkfs.btrfs /srv/arch.img<br />
# export root=/srv/arch<br />
# mkdir -p "$root"<br />
# mount -o loop,compress=lzo /srv/arch.img "$root"<br />
<br />
=== Bootstrapping installation ===<br />
<br />
Install {{Pkg|devtools}} and {{Pkg|arch-install-scripts}}, and run ''pacstrap'' to install the [[Installation guide#Install essential packages|essential packages]] for the client:<br />
<br />
# pacstrap -d "$root" base linux linux-firmware mkinitcpio-nfs-utils nfs-utils<br />
<br />
{{Note|In all cases {{Pkg|mkinitcpio-nfs-utils}} is still required. {{ic|ipconfig}} used in early-boot is provided only by the latter.}}<br />
<br />
Now the initramfs needs to be constructed.<br />
<br />
==== NFS ====<br />
<br />
Trivial modifications to the {{ic|net}} hook are required in order for NFSv4 mounting to work (not supported by {{ic|nfsmount}} – the default for the {{ic|net}} hook).<br />
<br />
# sed s/nfsmount/mount.nfs4/ "$root/usr/lib/initcpio/hooks/net" > "$root/usr/lib/initcpio/hooks/netnfs4"<br />
# cp $root/usr/lib/initcpio/install/net{,nfs4}<br />
<br />
The copy of {{ic|net}} is unfortunately needed so it does not get overwritten when {{pkg|mkinitcpio-nfs-utils}} is updated on the client installation.<br />
<br />
Edit {{ic|$root/etc/mkinitcpio.conf}} and add {{ic|nfsv4}} to {{ic|MODULES}}, {{ic|netnfs4}} to {{ic|HOOKS}}, and {{ic|/usr/bin/mount.nfs4}} to {{ic|BINARIES}}.<br />
<br />
Next, we [[chroot]] our installation and run ''mkinitcpio'':<br />
<br />
# arch-chroot "$root" mkinitcpio -p linux<br />
<br />
==== NBD ====<br />
<br />
The {{AUR|mkinitcpio-nbd}} package needs to be installed on the client. Build it with [[makepkg]] and install it:<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -U mkinitcpio-nbd-0.4-1-any.pkg.tar.xz<br />
<br />
You will then need to append {{ic|nbd}} to your {{ic|HOOKS}} array after {{ic|net}}; {{ic|net}} will configure your networking for you, but not attempt a NFS mount if {{ic|nfsroot}} is not specified in the kernel line.<br />
<br />
== Client configuration ==<br />
<br />
In addition to the setup mentioned here, you should also set up your [[hostname]], [[timezone]], [[Locale#Setting the system locale|locale]], and [[keymap]], and follow any other relevant parts of the [[Installation guide]].<br />
<br />
=== Bootloader ===<br />
<br />
==== GRUB ====<br />
<br />
{{Merge|GRUB|}}<br />
<br />
Though poorly documented, GRUB supports being loaded via PXE.<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -S grub<br />
<br />
Create a grub prefix on the target installation for both architectures using {{ic|grub-mknetdir}}.<br />
<br />
# arch-chroot "$root" grub-mknetdir --net-directory=/boot --subdir=grub<br />
<br />
Luckily for us, grub-mknetdir creates prefixes for all currently compiled/installed targets, and the {{Pkg|grub}} maintainers were nice enough to give us both in the same package, thus grub-mknetdir only needs to be run once.<br />
<br />
{{Note|This example config assumes the NFS/NBD server's IP being {{ic|10.0.0.1}} }}<br />
<br />
Now we create a trivial GRUB configuration:<br />
<br />
{{hc|# vim "$root/boot/grub/grub.cfg"|2=<br />
# ... video settings<br />
menuentry "Arch Linux" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nfsroot=10.0.0.1:/arch<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
menuentry "Arch Linux (NBD)" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nbd_host=10.0.0.1 nbd_name=arch root=/dev/nbd0<br />
initrd /initramfs-linux.img<br />
}<br />
}}<br />
<br />
[[GRUB]] dark-magic will {{ic|1=set root=(tftp,10.0.0.1)}} automatically, so that the kernel and initramfs are transferred via TFTP without any additional configuration, though you might want to set it explicitly if you have any other non-tftp menuentries.<br />
<br />
{{Note|All GRUB files and initcpio files must be available through TFTP. For example, for a NBD install with TFTP root set to {{ic|/srv/tftp}}, {{ic|/srv/tftp/grub/x86_64-efi/core.efi}}, {{ic|/srv/tftp/vmlinuz-linux}} must be present to boot successfully. You may copy all the /boot files inside the image to TFTP server's root. }}<br />
<br />
{{Note|You may generate grub config by {{ic|grub-mkconfig}} to ensure video settings are set correctly. However, it's needed to edit {{ic|boot.cfg}} afterwards, to remove {{ic|search --no-floppy ...}} and ensure {{ic|linux}} {{ic|initrd}} options (paths, NBD settings, NFS settings) are set correctly. }}<br />
<br />
{{Note|Modify your kernel line as-necessary, refer to [[PXELINUX]] for NBD-related options}}<br />
<br />
==== PXELINUX ====<br />
<br />
PXELINUX is provided by {{Pkg|syslinux}}, see [[PXELINUX]] for details.<br />
<br />
=== Additional mountpoints ===<br />
<br />
==== NBD root ====<br />
<br />
In late boot, you will want to switch your root filesystem mount to both {{ic|rw}}, and enable {{ic|1=compress=lzo}}, for much improved disk performance in comparison to [[NFS]].<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
/dev/nbd0 / btrfs rw,noatime,compress=lzo 0 0<br />
}}<br />
<br />
==== Program state directories ====<br />
<br />
{{Accuracy|systemd does not use persistent logging by default when /var/log/journal is in tmpfs and/or does not exist}}<br />
<br />
You could mount {{ic|/var/log}}, for example, as tmpfs so that logs from multiple hosts do not mix unpredictably, and do the same with {{ic|/var/spool/cups}}, so the 20 instances of cups using the same spool do not fight with each other and make 1,498 print jobs and eat an entire ream of paper (or worse: toner cartridge) overnight.<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
tmpfs /var/log tmpfs nodev,nosuid 0 0<br />
tmpfs /var/spool/cups tmpfs nodev,nosuid 0 0}}<br />
<br />
It would be best to configure software that has some sort of state/database to use unique state/database storage directories for each host. If you wanted to run [http://puppetlabs.com/ puppet], for example, you could simply use the {{ic|%H}} specifier in the puppet unit file:<br />
<br />
{{hc|# vim "$root/etc/systemd/system/puppetagent.service"|2=<br />
[Unit]<br />
Description=Puppet agent<br />
Wants=basic.target<br />
After=basic.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/run/puppet/agent.pid<br />
ExecStartPre=/usr/bin/install -d -o puppet -m 755 /run/puppet<br />
ExecStart=/usr/bin/puppet agent --vardir=/var/lib/puppet-%H --ssldir=/etc/puppet/ssl-%H<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Puppet-agent creates {{ic|vardir}} and {{ic|ssldir}} if they do not exist.<br />
<br />
If neither of these approaches are appropriate, the last sane option would be to create a {{man|7|systemd.generator}} that creates a mount unit specific to the current host (specifiers are not allowed in mount units, unfortunately).<br />
<br />
== Client boot ==<br />
<br />
=== NBD ===<br />
<br />
{{Accuracy|When using COW on the server, the clients all effectively have read-only mounts of the original filesystem; it should theoretically be safe to do a read-write mount on the NBD server}}<br />
<br />
If you are using NBD, you will need to umount the {{ic|arch.img}} before/while you boot your client.<br />
<br />
This makes things particularly interesting when it comes to kernel updates. You cannot have your client filesystem mounted while you are booting a client, but that also means you need to use a kernel separate from your client filesystem in order to build it.<br />
<br />
You will need to first copy {{ic|$root/boot}} from the client installation to your tftp root (i.e. {{ic|/srv/boot}}).<br />
<br />
# cp -r "$root/boot" /srv/boot<br />
<br />
You will then need to umount {{ic|$root}} before you start the client.<br />
<br />
# umount "$root"<br />
<br />
{{Note|To update the kernel in this setup, you either need to mount {{ic|/srv/boot}} using [[NFS]] in [[fstab]] on the client (prior to doing the kernel update) or mount your client filesystem after the client has disconnected from NBD}}<br />
<br />
== See also ==<br />
<br />
* [https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsroot.html kernel.org: Mounting the root filesystem via NFS (nfsroot)]<br />
* [https://wiki.syslinux.org/wiki/index.php/PXELINUX syslinux.org: pxelinux FAQ]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Diskless_system&diff=727138Diskless system2022-04-21T10:48:14Z<p>Saren: additional notes for grub</p>
<hr />
<div>[[Category:Installation process]]<br />
[[de:Diskless_Workstation]]<br />
[[ja:ディスクレスシステム]]<br />
[[ru:Diskless system]]<br />
[[zh-hans:Diskless system]]<br />
{{Related articles start}}<br />
{{Related|NFS}}<br />
{{Related|NFS Troubleshooting}}<br />
{{Related|PXE}}<br />
{{Related|Mkinitcpio#Using net}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
From [[Wikipedia:Diskless node]]<br />
:''A diskless node (or diskless workstation) is a workstation or personal computer without disk drives, which employs network booting to load its operating system from a server.''<br />
<br />
== Server configuration ==<br />
<br />
First of all, we must install the following components:<br />
* A [[Dhcpd|DHCP]] server to assign IP addresses to our diskless nodes.<br />
* A [[TFTP]] server to transfer the boot image (a requirement of all PXE option roms).<br />
* A form of network storage ([[NFS]] or NBD) to export the Arch installation to the diskless node.<br />
<br />
{{Note|{{pkg|dnsmasq}} is capable of simultaneously acting as both DHCP and TFTP server. For more information, see the [[dnsmasq]] article.}}<br />
<br />
=== DHCP ===<br />
<br />
Install ISC {{Pkg|dhcp}} and configure it:<br />
<br />
{{hc|/etc/dhcpd.conf|2=<br />
allow booting;<br />
allow bootp;<br />
<br />
authoritative;<br />
<br />
option domain-name-servers 10.0.0.1;<br />
<br />
option architecture code 93 = unsigned integer 16;<br />
<br />
group {<br />
next-server 10.0.0.1;<br />
<br />
if option architecture = 00:07 {<br />
filename "/grub/x86_64-efi/core.efi";<br />
} else {<br />
filename "/grub/i386-pc/core.0";<br />
}<br />
<br />
subnet 10.0.0.0 netmask 255.255.255.0 {<br />
option routers 10.0.0.1;<br />
range 10.0.0.128 10.0.0.254;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|{{ic|next-server}} should be the address of the TFTP server; everything else should be changed to match your network}}<br />
<br />
RFC 4578 defines the "Client System Architecture Type" dhcp option. In the above configuration, if the PXE client requests an x86_64-efi binary (type 0x7), we appropriately give them one, otherwise falling back to the legacy binary. This allows both UEFI and legacy BIOS clients to boot simultaneously on the same network segment.<br />
<br />
Start ISC DHCP [[systemd]] service.<br />
<br />
=== TFTP ===<br />
<br />
The TFTP server will be used to transfer the bootloader, kernel, and initramfs to the client.<br />
<br />
Set the TFTP root to {{ic|/srv/arch/boot}}. See [[TFTP]] for installation and configuration.<br />
<br />
=== Network storage ===<br />
<br />
The primary difference between using NFS and NBD is while with both you can in fact have multiple clients using the same installation, with NBD (by the nature of manipulating a filesystem directly) you will need to use the {{ic|copyonwrite}} mode to do so, which ends up discarding all writes on client disconnect. In some situations however, this might be highly desirable.<br />
<br />
==== NFS ====<br />
<br />
Install {{Pkg|nfs-utils}} on the server.<br />
<br />
You will need to add the root of your Arch installation to your [[NFS]] exports:<br />
<br />
{{hc|/etc/exports|2=<br />
/srv *(rw,fsid=0,no_root_squash,no_subtree_check)<br />
/srv/arch *(rw,no_root_squash,no_subtree_check)<br />
}}<br />
<br />
Next, start NFS services: {{ic|nfs-idmapd}} {{ic|nfs-mountd}}.<br />
<br />
==== NBD ====<br />
<br />
Install {{Pkg|nbd}} and configure it.<br />
<br />
{{hc|/etc/nbd-server/config|2=<br />
[generic]<br />
user = nbd<br />
group = nbd<br />
[arch]<br />
exportname = /srv/arch.img<br />
copyonwrite = false<br />
}}<br />
<br />
{{Note|Set {{ic|copyonwrite}} to true if you want to have multiple clients using the same NBD share simultaneously; refer to {{man|5|nbd-server}} for more details. Also use [[chown]] to change the ownership of the exportname directory to the user {{ic|nbd}}.}}<br />
<br />
Start {{ic|nbd}} systemd service.<br />
<br />
== Client installation ==<br />
<br />
Next we will create a full Arch Linux installation in a subdirectory on the server. During boot, the diskless client will get an IP address from the DHCP server, then boot from the host using PXE and mount this installation as its root.<br />
<br />
=== Directory setup ===<br />
<br />
{{Note|Creating a separate filesystem is required for NBD but optional for NFS and can be skipped/ignored.}}<br />
<br />
Create a [[Wikipedia: Sparse file|sparse file]] of at least 1 gigabyte, and create a btrfs filesystem on it (you can of course also use a real block device or [[LVM]] if you want).<br />
<br />
# truncate -s 1G /srv/arch.img<br />
# mkfs.btrfs /srv/arch.img<br />
# export root=/srv/arch<br />
# mkdir -p "$root"<br />
# mount -o loop,compress=lzo /srv/arch.img "$root"<br />
<br />
=== Bootstrapping installation ===<br />
<br />
Install {{Pkg|devtools}} and {{Pkg|arch-install-scripts}}, and run ''pacstrap'' to install the [[Installation guide#Install essential packages|essential packages]] for the client:<br />
<br />
# pacstrap -d "$root" base linux linux-firmware mkinitcpio-nfs-utils nfs-utils<br />
<br />
{{Note|In all cases {{Pkg|mkinitcpio-nfs-utils}} is still required. {{ic|ipconfig}} used in early-boot is provided only by the latter.}}<br />
<br />
Now the initramfs needs to be constructed.<br />
<br />
==== NFS ====<br />
<br />
Trivial modifications to the {{ic|net}} hook are required in order for NFSv4 mounting to work (not supported by {{ic|nfsmount}} – the default for the {{ic|net}} hook).<br />
<br />
# sed s/nfsmount/mount.nfs4/ "$root/usr/lib/initcpio/hooks/net" > "$root/usr/lib/initcpio/hooks/netnfs4"<br />
# cp $root/usr/lib/initcpio/install/net{,nfs4}<br />
<br />
The copy of {{ic|net}} is unfortunately needed so it does not get overwritten when {{pkg|mkinitcpio-nfs-utils}} is updated on the client installation.<br />
<br />
Edit {{ic|$root/etc/mkinitcpio.conf}} and add {{ic|nfsv4}} to {{ic|MODULES}}, {{ic|netnfs4}} to {{ic|HOOKS}}, and {{ic|/usr/bin/mount.nfs4}} to {{ic|BINARIES}}.<br />
<br />
Next, we [[chroot]] our installation and run ''mkinitcpio'':<br />
<br />
# arch-chroot "$root" mkinitcpio -p linux<br />
<br />
==== NBD ====<br />
<br />
The {{AUR|mkinitcpio-nbd}} package needs to be installed on the client. Build it with [[makepkg]] and install it:<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -U mkinitcpio-nbd-0.4-1-any.pkg.tar.xz<br />
<br />
You will then need to append {{ic|nbd}} to your {{ic|HOOKS}} array after {{ic|net}}; {{ic|net}} will configure your networking for you, but not attempt a NFS mount if {{ic|nfsroot}} is not specified in the kernel line.<br />
<br />
== Client configuration ==<br />
<br />
In addition to the setup mentioned here, you should also set up your [[hostname]], [[timezone]], [[Locale#Setting the system locale|locale]], and [[keymap]], and follow any other relevant parts of the [[Installation guide]].<br />
<br />
=== Bootloader ===<br />
<br />
==== GRUB ====<br />
<br />
{{Merge|GRUB|}}<br />
<br />
Though poorly documented, GRUB supports being loaded via PXE.<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -S grub<br />
<br />
Create a grub prefix on the target installation for both architectures using {{ic|grub-mknetdir}}.<br />
<br />
# arch-chroot "$root" grub-mknetdir --net-directory=/boot --subdir=grub<br />
<br />
Luckily for us, grub-mknetdir creates prefixes for all currently compiled/installed targets, and the {{Pkg|grub}} maintainers were nice enough to give us both in the same package, thus grub-mknetdir only needs to be run once.<br />
<br />
{{Note|This example config assumes the NFS/NBD server's IP being {{ic|10.0.0.1}} }}<br />
<br />
Now we create a trivial GRUB configuration:<br />
<br />
{{hc|# vim "$root/boot/grub/grub.cfg"|2=<br />
# ... video settings<br />
menuentry "Arch Linux" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nfsroot=10.0.0.1:/arch<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
menuentry "Arch Linux (NBD)" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nbd_host=10.0.0.1 nbd_name=arch root=/dev/nbd0<br />
initrd /initramfs-linux.img<br />
}<br />
}}<br />
<br />
[[GRUB]] dark-magic will {{ic|1=set root=(tftp,10.0.0.1)}} automatically, so that the kernel and initramfs are transferred via TFTP without any additional configuration, though you might want to set it explicitly if you have any other non-tftp menuentries.<br />
<br />
{{Note|GRUB files must be available through TFTP. For example, for a NBD install with TFTP root set to {{ic|/srv/tftp}}, {{ic|/srv/tftp/grub/x86_64-efi/core.efi}}, {{ic|/srv/tftp/vmlinuz-linux}} must be present to boot successfully. You may copy all the /boot files inside the image to TFTP server's root. }}<br />
<br />
{{Note|You may generate grub config by {{ic|grub-mkconfig}} to ensure video settings are set correctly. However, it's needed to edit {{ic|boot.cfg}} afterwards, to remove {{ic|search --no-floppy ...}} and ensure {{ic|linux}} {{ic|initrd}} options (paths, NBD settings, NFS settings) are set correctly. }}<br />
<br />
{{Note|Modify your kernel line as-necessary, refer to [[PXELINUX]] for NBD-related options}}<br />
<br />
==== PXELINUX ====<br />
<br />
PXELINUX is provided by {{Pkg|syslinux}}, see [[PXELINUX]] for details.<br />
<br />
=== Additional mountpoints ===<br />
<br />
==== NBD root ====<br />
<br />
In late boot, you will want to switch your root filesystem mount to both {{ic|rw}}, and enable {{ic|1=compress=lzo}}, for much improved disk performance in comparison to [[NFS]].<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
/dev/nbd0 / btrfs rw,noatime,compress=lzo 0 0<br />
}}<br />
<br />
==== Program state directories ====<br />
<br />
{{Accuracy|systemd does not use persistent logging by default when /var/log/journal is in tmpfs and/or does not exist}}<br />
<br />
You could mount {{ic|/var/log}}, for example, as tmpfs so that logs from multiple hosts do not mix unpredictably, and do the same with {{ic|/var/spool/cups}}, so the 20 instances of cups using the same spool do not fight with each other and make 1,498 print jobs and eat an entire ream of paper (or worse: toner cartridge) overnight.<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
tmpfs /var/log tmpfs nodev,nosuid 0 0<br />
tmpfs /var/spool/cups tmpfs nodev,nosuid 0 0}}<br />
<br />
It would be best to configure software that has some sort of state/database to use unique state/database storage directories for each host. If you wanted to run [http://puppetlabs.com/ puppet], for example, you could simply use the {{ic|%H}} specifier in the puppet unit file:<br />
<br />
{{hc|# vim "$root/etc/systemd/system/puppetagent.service"|2=<br />
[Unit]<br />
Description=Puppet agent<br />
Wants=basic.target<br />
After=basic.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/run/puppet/agent.pid<br />
ExecStartPre=/usr/bin/install -d -o puppet -m 755 /run/puppet<br />
ExecStart=/usr/bin/puppet agent --vardir=/var/lib/puppet-%H --ssldir=/etc/puppet/ssl-%H<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Puppet-agent creates {{ic|vardir}} and {{ic|ssldir}} if they do not exist.<br />
<br />
If neither of these approaches are appropriate, the last sane option would be to create a {{man|7|systemd.generator}} that creates a mount unit specific to the current host (specifiers are not allowed in mount units, unfortunately).<br />
<br />
== Client boot ==<br />
<br />
=== NBD ===<br />
<br />
{{Accuracy|When using COW on the server, the clients all effectively have read-only mounts of the original filesystem; it should theoretically be safe to do a read-write mount on the NBD server}}<br />
<br />
If you are using NBD, you will need to umount the {{ic|arch.img}} before/while you boot your client.<br />
<br />
This makes things particularly interesting when it comes to kernel updates. You cannot have your client filesystem mounted while you are booting a client, but that also means you need to use a kernel separate from your client filesystem in order to build it.<br />
<br />
You will need to first copy {{ic|$root/boot}} from the client installation to your tftp root (i.e. {{ic|/srv/boot}}).<br />
<br />
# cp -r "$root/boot" /srv/boot<br />
<br />
You will then need to umount {{ic|$root}} before you start the client.<br />
<br />
# umount "$root"<br />
<br />
{{Note|To update the kernel in this setup, you either need to mount {{ic|/srv/boot}} using [[NFS]] in [[fstab]] on the client (prior to doing the kernel update) or mount your client filesystem after the client has disconnected from NBD}}<br />
<br />
== See also ==<br />
<br />
* [https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsroot.html kernel.org: Mounting the root filesystem via NFS (nfsroot)]<br />
* [https://wiki.syslinux.org/wiki/index.php/PXELINUX syslinux.org: pxelinux FAQ]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Diskless_system&diff=727137Diskless system2022-04-21T10:44:59Z<p>Saren: IP</p>
<hr />
<div>[[Category:Installation process]]<br />
[[de:Diskless_Workstation]]<br />
[[ja:ディスクレスシステム]]<br />
[[ru:Diskless system]]<br />
[[zh-hans:Diskless system]]<br />
{{Related articles start}}<br />
{{Related|NFS}}<br />
{{Related|NFS Troubleshooting}}<br />
{{Related|PXE}}<br />
{{Related|Mkinitcpio#Using net}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
From [[Wikipedia:Diskless node]]<br />
:''A diskless node (or diskless workstation) is a workstation or personal computer without disk drives, which employs network booting to load its operating system from a server.''<br />
<br />
== Server configuration ==<br />
<br />
First of all, we must install the following components:<br />
* A [[Dhcpd|DHCP]] server to assign IP addresses to our diskless nodes.<br />
* A [[TFTP]] server to transfer the boot image (a requirement of all PXE option roms).<br />
* A form of network storage ([[NFS]] or NBD) to export the Arch installation to the diskless node.<br />
<br />
{{Note|{{pkg|dnsmasq}} is capable of simultaneously acting as both DHCP and TFTP server. For more information, see the [[dnsmasq]] article.}}<br />
<br />
=== DHCP ===<br />
<br />
Install ISC {{Pkg|dhcp}} and configure it:<br />
<br />
{{hc|/etc/dhcpd.conf|2=<br />
allow booting;<br />
allow bootp;<br />
<br />
authoritative;<br />
<br />
option domain-name-servers 10.0.0.1;<br />
<br />
option architecture code 93 = unsigned integer 16;<br />
<br />
group {<br />
next-server 10.0.0.1;<br />
<br />
if option architecture = 00:07 {<br />
filename "/grub/x86_64-efi/core.efi";<br />
} else {<br />
filename "/grub/i386-pc/core.0";<br />
}<br />
<br />
subnet 10.0.0.0 netmask 255.255.255.0 {<br />
option routers 10.0.0.1;<br />
range 10.0.0.128 10.0.0.254;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|{{ic|next-server}} should be the address of the TFTP server; everything else should be changed to match your network}}<br />
<br />
RFC 4578 defines the "Client System Architecture Type" dhcp option. In the above configuration, if the PXE client requests an x86_64-efi binary (type 0x7), we appropriately give them one, otherwise falling back to the legacy binary. This allows both UEFI and legacy BIOS clients to boot simultaneously on the same network segment.<br />
<br />
Start ISC DHCP [[systemd]] service.<br />
<br />
=== TFTP ===<br />
<br />
The TFTP server will be used to transfer the bootloader, kernel, and initramfs to the client.<br />
<br />
Set the TFTP root to {{ic|/srv/arch/boot}}. See [[TFTP]] for installation and configuration.<br />
<br />
=== Network storage ===<br />
<br />
The primary difference between using NFS and NBD is while with both you can in fact have multiple clients using the same installation, with NBD (by the nature of manipulating a filesystem directly) you will need to use the {{ic|copyonwrite}} mode to do so, which ends up discarding all writes on client disconnect. In some situations however, this might be highly desirable.<br />
<br />
==== NFS ====<br />
<br />
Install {{Pkg|nfs-utils}} on the server.<br />
<br />
You will need to add the root of your Arch installation to your [[NFS]] exports:<br />
<br />
{{hc|/etc/exports|2=<br />
/srv *(rw,fsid=0,no_root_squash,no_subtree_check)<br />
/srv/arch *(rw,no_root_squash,no_subtree_check)<br />
}}<br />
<br />
Next, start NFS services: {{ic|nfs-idmapd}} {{ic|nfs-mountd}}.<br />
<br />
==== NBD ====<br />
<br />
Install {{Pkg|nbd}} and configure it.<br />
<br />
{{hc|/etc/nbd-server/config|2=<br />
[generic]<br />
user = nbd<br />
group = nbd<br />
[arch]<br />
exportname = /srv/arch.img<br />
copyonwrite = false<br />
}}<br />
<br />
{{Note|Set {{ic|copyonwrite}} to true if you want to have multiple clients using the same NBD share simultaneously; refer to {{man|5|nbd-server}} for more details. Also use [[chown]] to change the ownership of the exportname directory to the user {{ic|nbd}}.}}<br />
<br />
Start {{ic|nbd}} systemd service.<br />
<br />
== Client installation ==<br />
<br />
Next we will create a full Arch Linux installation in a subdirectory on the server. During boot, the diskless client will get an IP address from the DHCP server, then boot from the host using PXE and mount this installation as its root.<br />
<br />
=== Directory setup ===<br />
<br />
{{Note|Creating a separate filesystem is required for NBD but optional for NFS and can be skipped/ignored.}}<br />
<br />
Create a [[Wikipedia: Sparse file|sparse file]] of at least 1 gigabyte, and create a btrfs filesystem on it (you can of course also use a real block device or [[LVM]] if you want).<br />
<br />
# truncate -s 1G /srv/arch.img<br />
# mkfs.btrfs /srv/arch.img<br />
# export root=/srv/arch<br />
# mkdir -p "$root"<br />
# mount -o loop,compress=lzo /srv/arch.img "$root"<br />
<br />
=== Bootstrapping installation ===<br />
<br />
Install {{Pkg|devtools}} and {{Pkg|arch-install-scripts}}, and run ''pacstrap'' to install the [[Installation guide#Install essential packages|essential packages]] for the client:<br />
<br />
# pacstrap -d "$root" base linux linux-firmware mkinitcpio-nfs-utils nfs-utils<br />
<br />
{{Note|In all cases {{Pkg|mkinitcpio-nfs-utils}} is still required. {{ic|ipconfig}} used in early-boot is provided only by the latter.}}<br />
<br />
Now the initramfs needs to be constructed.<br />
<br />
==== NFS ====<br />
<br />
Trivial modifications to the {{ic|net}} hook are required in order for NFSv4 mounting to work (not supported by {{ic|nfsmount}} – the default for the {{ic|net}} hook).<br />
<br />
# sed s/nfsmount/mount.nfs4/ "$root/usr/lib/initcpio/hooks/net" > "$root/usr/lib/initcpio/hooks/netnfs4"<br />
# cp $root/usr/lib/initcpio/install/net{,nfs4}<br />
<br />
The copy of {{ic|net}} is unfortunately needed so it does not get overwritten when {{pkg|mkinitcpio-nfs-utils}} is updated on the client installation.<br />
<br />
Edit {{ic|$root/etc/mkinitcpio.conf}} and add {{ic|nfsv4}} to {{ic|MODULES}}, {{ic|netnfs4}} to {{ic|HOOKS}}, and {{ic|/usr/bin/mount.nfs4}} to {{ic|BINARIES}}.<br />
<br />
Next, we [[chroot]] our installation and run ''mkinitcpio'':<br />
<br />
# arch-chroot "$root" mkinitcpio -p linux<br />
<br />
==== NBD ====<br />
<br />
The {{AUR|mkinitcpio-nbd}} package needs to be installed on the client. Build it with [[makepkg]] and install it:<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -U mkinitcpio-nbd-0.4-1-any.pkg.tar.xz<br />
<br />
You will then need to append {{ic|nbd}} to your {{ic|HOOKS}} array after {{ic|net}}; {{ic|net}} will configure your networking for you, but not attempt a NFS mount if {{ic|nfsroot}} is not specified in the kernel line.<br />
<br />
== Client configuration ==<br />
<br />
In addition to the setup mentioned here, you should also set up your [[hostname]], [[timezone]], [[Locale#Setting the system locale|locale]], and [[keymap]], and follow any other relevant parts of the [[Installation guide]].<br />
<br />
=== Bootloader ===<br />
<br />
==== GRUB ====<br />
<br />
{{Merge|GRUB|}}<br />
<br />
Though poorly documented, GRUB supports being loaded via PXE.<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -S grub<br />
<br />
Create a grub prefix on the target installation for both architectures using {{ic|grub-mknetdir}}.<br />
<br />
# arch-chroot "$root" grub-mknetdir --net-directory=/boot --subdir=grub<br />
<br />
Luckily for us, grub-mknetdir creates prefixes for all currently compiled/installed targets, and the {{Pkg|grub}} maintainers were nice enough to give us both in the same package, thus grub-mknetdir only needs to be run once.<br />
<br />
{{Note|This example config assumes the NFS/NBD server's IP being {{ic|10.0.0.1}} }}<br />
<br />
Now we create a trivial GRUB configuration:<br />
<br />
{{hc|# vim "$root/boot/grub/grub.cfg"|2=<br />
# ... video settings<br />
menuentry "Arch Linux" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nfsroot=10.0.0.1:/arch<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
menuentry "Arch Linux (NBD)" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nbd_host=10.0.0.1 nbd_name=arch root=/dev/nbd0<br />
initrd /initramfs-linux.img<br />
}<br />
}}<br />
<br />
[[GRUB]] dark-magic will {{ic|1=set root=(tftp,10.0.0.1)}} automatically, so that the kernel and initramfs are transferred via TFTP without any additional configuration, though you might want to set it explicitly if you have any other non-tftp menuentries.<br />
<br />
{{Note|GRUB files must be available through TFTP. For example, for a NBD install with TFTP root set to {{ic|/srv/tftp}}, {{ic|/srv/tftp/grub/x86_64-efi/core.efi}}, {{ic|/srv/tftp/vmlinuz-linux}} must be present to boot successfully. You may copy all the /boot files inside the chroot to host TFTP server's root. }}<br />
<br />
{{Note|Modify your kernel line as-necessary, refer to [[PXELINUX]] for NBD-related options}}<br />
<br />
==== PXELINUX ====<br />
<br />
PXELINUX is provided by {{Pkg|syslinux}}, see [[PXELINUX]] for details.<br />
<br />
=== Additional mountpoints ===<br />
<br />
==== NBD root ====<br />
<br />
In late boot, you will want to switch your root filesystem mount to both {{ic|rw}}, and enable {{ic|1=compress=lzo}}, for much improved disk performance in comparison to [[NFS]].<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
/dev/nbd0 / btrfs rw,noatime,compress=lzo 0 0<br />
}}<br />
<br />
==== Program state directories ====<br />
<br />
{{Accuracy|systemd does not use persistent logging by default when /var/log/journal is in tmpfs and/or does not exist}}<br />
<br />
You could mount {{ic|/var/log}}, for example, as tmpfs so that logs from multiple hosts do not mix unpredictably, and do the same with {{ic|/var/spool/cups}}, so the 20 instances of cups using the same spool do not fight with each other and make 1,498 print jobs and eat an entire ream of paper (or worse: toner cartridge) overnight.<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
tmpfs /var/log tmpfs nodev,nosuid 0 0<br />
tmpfs /var/spool/cups tmpfs nodev,nosuid 0 0}}<br />
<br />
It would be best to configure software that has some sort of state/database to use unique state/database storage directories for each host. If you wanted to run [http://puppetlabs.com/ puppet], for example, you could simply use the {{ic|%H}} specifier in the puppet unit file:<br />
<br />
{{hc|# vim "$root/etc/systemd/system/puppetagent.service"|2=<br />
[Unit]<br />
Description=Puppet agent<br />
Wants=basic.target<br />
After=basic.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/run/puppet/agent.pid<br />
ExecStartPre=/usr/bin/install -d -o puppet -m 755 /run/puppet<br />
ExecStart=/usr/bin/puppet agent --vardir=/var/lib/puppet-%H --ssldir=/etc/puppet/ssl-%H<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Puppet-agent creates {{ic|vardir}} and {{ic|ssldir}} if they do not exist.<br />
<br />
If neither of these approaches are appropriate, the last sane option would be to create a {{man|7|systemd.generator}} that creates a mount unit specific to the current host (specifiers are not allowed in mount units, unfortunately).<br />
<br />
== Client boot ==<br />
<br />
=== NBD ===<br />
<br />
{{Accuracy|When using COW on the server, the clients all effectively have read-only mounts of the original filesystem; it should theoretically be safe to do a read-write mount on the NBD server}}<br />
<br />
If you are using NBD, you will need to umount the {{ic|arch.img}} before/while you boot your client.<br />
<br />
This makes things particularly interesting when it comes to kernel updates. You cannot have your client filesystem mounted while you are booting a client, but that also means you need to use a kernel separate from your client filesystem in order to build it.<br />
<br />
You will need to first copy {{ic|$root/boot}} from the client installation to your tftp root (i.e. {{ic|/srv/boot}}).<br />
<br />
# cp -r "$root/boot" /srv/boot<br />
<br />
You will then need to umount {{ic|$root}} before you start the client.<br />
<br />
# umount "$root"<br />
<br />
{{Note|To update the kernel in this setup, you either need to mount {{ic|/srv/boot}} using [[NFS]] in [[fstab]] on the client (prior to doing the kernel update) or mount your client filesystem after the client has disconnected from NBD}}<br />
<br />
== See also ==<br />
<br />
* [https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsroot.html kernel.org: Mounting the root filesystem via NFS (nfsroot)]<br />
* [https://wiki.syslinux.org/wiki/index.php/PXELINUX syslinux.org: pxelinux FAQ]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Diskless_system&diff=727136Diskless system2022-04-21T10:43:51Z<p>Saren: formatting</p>
<hr />
<div>[[Category:Installation process]]<br />
[[de:Diskless_Workstation]]<br />
[[ja:ディスクレスシステム]]<br />
[[ru:Diskless system]]<br />
[[zh-hans:Diskless system]]<br />
{{Related articles start}}<br />
{{Related|NFS}}<br />
{{Related|NFS Troubleshooting}}<br />
{{Related|PXE}}<br />
{{Related|Mkinitcpio#Using net}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
From [[Wikipedia:Diskless node]]<br />
:''A diskless node (or diskless workstation) is a workstation or personal computer without disk drives, which employs network booting to load its operating system from a server.''<br />
<br />
== Server configuration ==<br />
<br />
First of all, we must install the following components:<br />
* A [[Dhcpd|DHCP]] server to assign IP addresses to our diskless nodes.<br />
* A [[TFTP]] server to transfer the boot image (a requirement of all PXE option roms).<br />
* A form of network storage ([[NFS]] or NBD) to export the Arch installation to the diskless node.<br />
<br />
{{Note|{{pkg|dnsmasq}} is capable of simultaneously acting as both DHCP and TFTP server. For more information, see the [[dnsmasq]] article.}}<br />
<br />
=== DHCP ===<br />
<br />
Install ISC {{Pkg|dhcp}} and configure it:<br />
<br />
{{hc|/etc/dhcpd.conf|2=<br />
allow booting;<br />
allow bootp;<br />
<br />
authoritative;<br />
<br />
option domain-name-servers 10.0.0.1;<br />
<br />
option architecture code 93 = unsigned integer 16;<br />
<br />
group {<br />
next-server 10.0.0.1;<br />
<br />
if option architecture = 00:07 {<br />
filename "/grub/x86_64-efi/core.efi";<br />
} else {<br />
filename "/grub/i386-pc/core.0";<br />
}<br />
<br />
subnet 10.0.0.0 netmask 255.255.255.0 {<br />
option routers 10.0.0.1;<br />
range 10.0.0.128 10.0.0.254;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|{{ic|next-server}} should be the address of the TFTP server; everything else should be changed to match your network}}<br />
<br />
RFC 4578 defines the "Client System Architecture Type" dhcp option. In the above configuration, if the PXE client requests an x86_64-efi binary (type 0x7), we appropriately give them one, otherwise falling back to the legacy binary. This allows both UEFI and legacy BIOS clients to boot simultaneously on the same network segment.<br />
<br />
Start ISC DHCP [[systemd]] service.<br />
<br />
=== TFTP ===<br />
<br />
The TFTP server will be used to transfer the bootloader, kernel, and initramfs to the client.<br />
<br />
Set the TFTP root to {{ic|/srv/arch/boot}}. See [[TFTP]] for installation and configuration.<br />
<br />
=== Network storage ===<br />
<br />
The primary difference between using NFS and NBD is while with both you can in fact have multiple clients using the same installation, with NBD (by the nature of manipulating a filesystem directly) you will need to use the {{ic|copyonwrite}} mode to do so, which ends up discarding all writes on client disconnect. In some situations however, this might be highly desirable.<br />
<br />
==== NFS ====<br />
<br />
Install {{Pkg|nfs-utils}} on the server.<br />
<br />
You will need to add the root of your Arch installation to your [[NFS]] exports:<br />
<br />
{{hc|/etc/exports|2=<br />
/srv *(rw,fsid=0,no_root_squash,no_subtree_check)<br />
/srv/arch *(rw,no_root_squash,no_subtree_check)<br />
}}<br />
<br />
Next, start NFS services: {{ic|nfs-idmapd}} {{ic|nfs-mountd}}.<br />
<br />
==== NBD ====<br />
<br />
Install {{Pkg|nbd}} and configure it.<br />
<br />
{{hc|/etc/nbd-server/config|2=<br />
[generic]<br />
user = nbd<br />
group = nbd<br />
[arch]<br />
exportname = /srv/arch.img<br />
copyonwrite = false<br />
}}<br />
<br />
{{Note|Set {{ic|copyonwrite}} to true if you want to have multiple clients using the same NBD share simultaneously; refer to {{man|5|nbd-server}} for more details. Also use [[chown]] to change the ownership of the exportname directory to the user {{ic|nbd}}.}}<br />
<br />
Start {{ic|nbd}} systemd service.<br />
<br />
== Client installation ==<br />
<br />
Next we will create a full Arch Linux installation in a subdirectory on the server. During boot, the diskless client will get an IP address from the DHCP server, then boot from the host using PXE and mount this installation as its root.<br />
<br />
=== Directory setup ===<br />
<br />
{{Note|Creating a separate filesystem is required for NBD but optional for NFS and can be skipped/ignored.}}<br />
<br />
Create a [[Wikipedia: Sparse file|sparse file]] of at least 1 gigabyte, and create a btrfs filesystem on it (you can of course also use a real block device or [[LVM]] if you want).<br />
<br />
# truncate -s 1G /srv/arch.img<br />
# mkfs.btrfs /srv/arch.img<br />
# export root=/srv/arch<br />
# mkdir -p "$root"<br />
# mount -o loop,compress=lzo /srv/arch.img "$root"<br />
<br />
=== Bootstrapping installation ===<br />
<br />
Install {{Pkg|devtools}} and {{Pkg|arch-install-scripts}}, and run ''pacstrap'' to install the [[Installation guide#Install essential packages|essential packages]] for the client:<br />
<br />
# pacstrap -d "$root" base linux linux-firmware mkinitcpio-nfs-utils nfs-utils<br />
<br />
{{Note|In all cases {{Pkg|mkinitcpio-nfs-utils}} is still required. {{ic|ipconfig}} used in early-boot is provided only by the latter.}}<br />
<br />
Now the initramfs needs to be constructed.<br />
<br />
==== NFS ====<br />
<br />
Trivial modifications to the {{ic|net}} hook are required in order for NFSv4 mounting to work (not supported by {{ic|nfsmount}} – the default for the {{ic|net}} hook).<br />
<br />
# sed s/nfsmount/mount.nfs4/ "$root/usr/lib/initcpio/hooks/net" > "$root/usr/lib/initcpio/hooks/netnfs4"<br />
# cp $root/usr/lib/initcpio/install/net{,nfs4}<br />
<br />
The copy of {{ic|net}} is unfortunately needed so it does not get overwritten when {{pkg|mkinitcpio-nfs-utils}} is updated on the client installation.<br />
<br />
Edit {{ic|$root/etc/mkinitcpio.conf}} and add {{ic|nfsv4}} to {{ic|MODULES}}, {{ic|netnfs4}} to {{ic|HOOKS}}, and {{ic|/usr/bin/mount.nfs4}} to {{ic|BINARIES}}.<br />
<br />
Next, we [[chroot]] our installation and run ''mkinitcpio'':<br />
<br />
# arch-chroot "$root" mkinitcpio -p linux<br />
<br />
==== NBD ====<br />
<br />
The {{AUR|mkinitcpio-nbd}} package needs to be installed on the client. Build it with [[makepkg]] and install it:<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -U mkinitcpio-nbd-0.4-1-any.pkg.tar.xz<br />
<br />
You will then need to append {{ic|nbd}} to your {{ic|HOOKS}} array after {{ic|net}}; {{ic|net}} will configure your networking for you, but not attempt a NFS mount if {{ic|nfsroot}} is not specified in the kernel line.<br />
<br />
== Client configuration ==<br />
<br />
In addition to the setup mentioned here, you should also set up your [[hostname]], [[timezone]], [[Locale#Setting the system locale|locale]], and [[keymap]], and follow any other relevant parts of the [[Installation guide]].<br />
<br />
=== Bootloader ===<br />
<br />
==== GRUB ====<br />
<br />
{{Merge|GRUB|}}<br />
<br />
Though poorly documented, GRUB supports being loaded via PXE.<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -S grub<br />
<br />
Create a grub prefix on the target installation for both architectures using {{ic|grub-mknetdir}}.<br />
<br />
# arch-chroot "$root" grub-mknetdir --net-directory=/boot --subdir=grub<br />
<br />
Luckily for us, grub-mknetdir creates prefixes for all currently compiled/installed targets, and the {{Pkg|grub}} maintainers were nice enough to give us both in the same package, thus grub-mknetdir only needs to be run once.<br />
<br />
Now we create a trivial GRUB configuration:<br />
<br />
{{hc|# vim "$root/boot/grub/grub.cfg"|2=<br />
# ... video settings<br />
menuentry "Arch Linux" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nfsroot=10.0.0.1:/arch<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
menuentry "Arch Linux (NBD)" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nbd_host=192.168.0.1 nbd_name=arch root=/dev/nbd0<br />
initrd /initramfs-linux.img<br />
}<br />
}}<br />
<br />
[[GRUB]] dark-magic will {{ic|1=set root=(tftp,10.0.0.1)}} automatically, so that the kernel and initramfs are transferred via TFTP without any additional configuration, though you might want to set it explicitly if you have any other non-tftp menuentries.<br />
<br />
{{Note|GRUB files must be available through TFTP. For example, for a NBD install with TFTP root set to {{ic|/srv/tftp}}, {{ic|/srv/tftp/grub/x86_64-efi/core.efi}}, {{ic|/srv/tftp/vmlinuz-linux}} must be present to boot successfully. You may copy all the /boot files inside the chroot to host TFTP server's root. }}<br />
<br />
{{Note|Modify your kernel line as-necessary, refer to [[PXELINUX]] for NBD-related options}}<br />
<br />
==== PXELINUX ====<br />
<br />
PXELINUX is provided by {{Pkg|syslinux}}, see [[PXELINUX]] for details.<br />
<br />
=== Additional mountpoints ===<br />
<br />
==== NBD root ====<br />
<br />
In late boot, you will want to switch your root filesystem mount to both {{ic|rw}}, and enable {{ic|1=compress=lzo}}, for much improved disk performance in comparison to [[NFS]].<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
/dev/nbd0 / btrfs rw,noatime,compress=lzo 0 0<br />
}}<br />
<br />
==== Program state directories ====<br />
<br />
{{Accuracy|systemd does not use persistent logging by default when /var/log/journal is in tmpfs and/or does not exist}}<br />
<br />
You could mount {{ic|/var/log}}, for example, as tmpfs so that logs from multiple hosts do not mix unpredictably, and do the same with {{ic|/var/spool/cups}}, so the 20 instances of cups using the same spool do not fight with each other and make 1,498 print jobs and eat an entire ream of paper (or worse: toner cartridge) overnight.<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
tmpfs /var/log tmpfs nodev,nosuid 0 0<br />
tmpfs /var/spool/cups tmpfs nodev,nosuid 0 0}}<br />
<br />
It would be best to configure software that has some sort of state/database to use unique state/database storage directories for each host. If you wanted to run [http://puppetlabs.com/ puppet], for example, you could simply use the {{ic|%H}} specifier in the puppet unit file:<br />
<br />
{{hc|# vim "$root/etc/systemd/system/puppetagent.service"|2=<br />
[Unit]<br />
Description=Puppet agent<br />
Wants=basic.target<br />
After=basic.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/run/puppet/agent.pid<br />
ExecStartPre=/usr/bin/install -d -o puppet -m 755 /run/puppet<br />
ExecStart=/usr/bin/puppet agent --vardir=/var/lib/puppet-%H --ssldir=/etc/puppet/ssl-%H<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Puppet-agent creates {{ic|vardir}} and {{ic|ssldir}} if they do not exist.<br />
<br />
If neither of these approaches are appropriate, the last sane option would be to create a {{man|7|systemd.generator}} that creates a mount unit specific to the current host (specifiers are not allowed in mount units, unfortunately).<br />
<br />
== Client boot ==<br />
<br />
=== NBD ===<br />
<br />
{{Accuracy|When using COW on the server, the clients all effectively have read-only mounts of the original filesystem; it should theoretically be safe to do a read-write mount on the NBD server}}<br />
<br />
If you are using NBD, you will need to umount the {{ic|arch.img}} before/while you boot your client.<br />
<br />
This makes things particularly interesting when it comes to kernel updates. You cannot have your client filesystem mounted while you are booting a client, but that also means you need to use a kernel separate from your client filesystem in order to build it.<br />
<br />
You will need to first copy {{ic|$root/boot}} from the client installation to your tftp root (i.e. {{ic|/srv/boot}}).<br />
<br />
# cp -r "$root/boot" /srv/boot<br />
<br />
You will then need to umount {{ic|$root}} before you start the client.<br />
<br />
# umount "$root"<br />
<br />
{{Note|To update the kernel in this setup, you either need to mount {{ic|/srv/boot}} using [[NFS]] in [[fstab]] on the client (prior to doing the kernel update) or mount your client filesystem after the client has disconnected from NBD}}<br />
<br />
== See also ==<br />
<br />
* [https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsroot.html kernel.org: Mounting the root filesystem via NFS (nfsroot)]<br />
* [https://wiki.syslinux.org/wiki/index.php/PXELINUX syslinux.org: pxelinux FAQ]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Diskless_system&diff=727135Diskless system2022-04-21T10:43:02Z<p>Saren: Clearer grub+tftp+nbd notes.</p>
<hr />
<div>[[Category:Installation process]]<br />
[[de:Diskless_Workstation]]<br />
[[ja:ディスクレスシステム]]<br />
[[ru:Diskless system]]<br />
[[zh-hans:Diskless system]]<br />
{{Related articles start}}<br />
{{Related|NFS}}<br />
{{Related|NFS Troubleshooting}}<br />
{{Related|PXE}}<br />
{{Related|Mkinitcpio#Using net}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
From [[Wikipedia:Diskless node]]<br />
:''A diskless node (or diskless workstation) is a workstation or personal computer without disk drives, which employs network booting to load its operating system from a server.''<br />
<br />
== Server configuration ==<br />
<br />
First of all, we must install the following components:<br />
* A [[Dhcpd|DHCP]] server to assign IP addresses to our diskless nodes.<br />
* A [[TFTP]] server to transfer the boot image (a requirement of all PXE option roms).<br />
* A form of network storage ([[NFS]] or NBD) to export the Arch installation to the diskless node.<br />
<br />
{{Note|{{pkg|dnsmasq}} is capable of simultaneously acting as both DHCP and TFTP server. For more information, see the [[dnsmasq]] article.}}<br />
<br />
=== DHCP ===<br />
<br />
Install ISC {{Pkg|dhcp}} and configure it:<br />
<br />
{{hc|/etc/dhcpd.conf|2=<br />
allow booting;<br />
allow bootp;<br />
<br />
authoritative;<br />
<br />
option domain-name-servers 10.0.0.1;<br />
<br />
option architecture code 93 = unsigned integer 16;<br />
<br />
group {<br />
next-server 10.0.0.1;<br />
<br />
if option architecture = 00:07 {<br />
filename "/grub/x86_64-efi/core.efi";<br />
} else {<br />
filename "/grub/i386-pc/core.0";<br />
}<br />
<br />
subnet 10.0.0.0 netmask 255.255.255.0 {<br />
option routers 10.0.0.1;<br />
range 10.0.0.128 10.0.0.254;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|{{ic|next-server}} should be the address of the TFTP server; everything else should be changed to match your network}}<br />
<br />
RFC 4578 defines the "Client System Architecture Type" dhcp option. In the above configuration, if the PXE client requests an x86_64-efi binary (type 0x7), we appropriately give them one, otherwise falling back to the legacy binary. This allows both UEFI and legacy BIOS clients to boot simultaneously on the same network segment.<br />
<br />
Start ISC DHCP [[systemd]] service.<br />
<br />
=== TFTP ===<br />
<br />
The TFTP server will be used to transfer the bootloader, kernel, and initramfs to the client.<br />
<br />
Set the TFTP root to {{ic|/srv/arch/boot}}. See [[TFTP]] for installation and configuration.<br />
<br />
=== Network storage ===<br />
<br />
The primary difference between using NFS and NBD is while with both you can in fact have multiple clients using the same installation, with NBD (by the nature of manipulating a filesystem directly) you will need to use the {{ic|copyonwrite}} mode to do so, which ends up discarding all writes on client disconnect. In some situations however, this might be highly desirable.<br />
<br />
==== NFS ====<br />
<br />
Install {{Pkg|nfs-utils}} on the server.<br />
<br />
You will need to add the root of your Arch installation to your [[NFS]] exports:<br />
<br />
{{hc|/etc/exports|2=<br />
/srv *(rw,fsid=0,no_root_squash,no_subtree_check)<br />
/srv/arch *(rw,no_root_squash,no_subtree_check)<br />
}}<br />
<br />
Next, start NFS services: {{ic|nfs-idmapd}} {{ic|nfs-mountd}}.<br />
<br />
==== NBD ====<br />
<br />
Install {{Pkg|nbd}} and configure it.<br />
<br />
{{hc|/etc/nbd-server/config|2=<br />
[generic]<br />
user = nbd<br />
group = nbd<br />
[arch]<br />
exportname = /srv/arch.img<br />
copyonwrite = false<br />
}}<br />
<br />
{{Note|Set {{ic|copyonwrite}} to true if you want to have multiple clients using the same NBD share simultaneously; refer to {{man|5|nbd-server}} for more details. Also use [[chown]] to change the ownership of the exportname directory to the user {{ic|nbd}}.}}<br />
<br />
Start {{ic|nbd}} systemd service.<br />
<br />
== Client installation ==<br />
<br />
Next we will create a full Arch Linux installation in a subdirectory on the server. During boot, the diskless client will get an IP address from the DHCP server, then boot from the host using PXE and mount this installation as its root.<br />
<br />
=== Directory setup ===<br />
<br />
{{Note|Creating a separate filesystem is required for NBD but optional for NFS and can be skipped/ignored.}}<br />
<br />
Create a [[Wikipedia: Sparse file|sparse file]] of at least 1 gigabyte, and create a btrfs filesystem on it (you can of course also use a real block device or [[LVM]] if you want).<br />
<br />
# truncate -s 1G /srv/arch.img<br />
# mkfs.btrfs /srv/arch.img<br />
# export root=/srv/arch<br />
# mkdir -p "$root"<br />
# mount -o loop,compress=lzo /srv/arch.img "$root"<br />
<br />
=== Bootstrapping installation ===<br />
<br />
Install {{Pkg|devtools}} and {{Pkg|arch-install-scripts}}, and run ''pacstrap'' to install the [[Installation guide#Install essential packages|essential packages]] for the client:<br />
<br />
# pacstrap -d "$root" base linux linux-firmware mkinitcpio-nfs-utils nfs-utils<br />
<br />
{{Note|In all cases {{Pkg|mkinitcpio-nfs-utils}} is still required. {{ic|ipconfig}} used in early-boot is provided only by the latter.}}<br />
<br />
Now the initramfs needs to be constructed.<br />
<br />
==== NFS ====<br />
<br />
Trivial modifications to the {{ic|net}} hook are required in order for NFSv4 mounting to work (not supported by {{ic|nfsmount}} – the default for the {{ic|net}} hook).<br />
<br />
# sed s/nfsmount/mount.nfs4/ "$root/usr/lib/initcpio/hooks/net" > "$root/usr/lib/initcpio/hooks/netnfs4"<br />
# cp $root/usr/lib/initcpio/install/net{,nfs4}<br />
<br />
The copy of {{ic|net}} is unfortunately needed so it does not get overwritten when {{pkg|mkinitcpio-nfs-utils}} is updated on the client installation.<br />
<br />
Edit {{ic|$root/etc/mkinitcpio.conf}} and add {{ic|nfsv4}} to {{ic|MODULES}}, {{ic|netnfs4}} to {{ic|HOOKS}}, and {{ic|/usr/bin/mount.nfs4}} to {{ic|BINARIES}}.<br />
<br />
Next, we [[chroot]] our installation and run ''mkinitcpio'':<br />
<br />
# arch-chroot "$root" mkinitcpio -p linux<br />
<br />
==== NBD ====<br />
<br />
The {{AUR|mkinitcpio-nbd}} package needs to be installed on the client. Build it with [[makepkg]] and install it:<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -U mkinitcpio-nbd-0.4-1-any.pkg.tar.xz<br />
<br />
You will then need to append {{ic|nbd}} to your {{ic|HOOKS}} array after {{ic|net}}; {{ic|net}} will configure your networking for you, but not attempt a NFS mount if {{ic|nfsroot}} is not specified in the kernel line.<br />
<br />
== Client configuration ==<br />
<br />
In addition to the setup mentioned here, you should also set up your [[hostname]], [[timezone]], [[Locale#Setting the system locale|locale]], and [[keymap]], and follow any other relevant parts of the [[Installation guide]].<br />
<br />
=== Bootloader ===<br />
<br />
==== GRUB ====<br />
<br />
{{Merge|GRUB|}}<br />
<br />
Though poorly documented, GRUB supports being loaded via PXE.<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -S grub<br />
<br />
Create a grub prefix on the target installation for both architectures using {{ic|grub-mknetdir}}.<br />
<br />
# arch-chroot "$root" grub-mknetdir --net-directory=/boot --subdir=grub<br />
<br />
Luckily for us, grub-mknetdir creates prefixes for all currently compiled/installed targets, and the {{Pkg|grub}} maintainers were nice enough to give us both in the same package, thus grub-mknetdir only needs to be run once.<br />
<br />
Now we create a trivial GRUB configuration:<br />
<br />
{{hc|# vim "$root/boot/grub/grub.cfg"|2=<br />
# ... video settings<br />
menuentry "Arch Linux" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nfsroot=10.0.0.1:/arch<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
menuentry "Arch Linux (NBD)" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nbd_host=192.168.0.1 nbd_name=arch root=/dev/nbd0<br />
initrd /initramfs-linux.img<br />
}<br />
}}<br />
<br />
[[GRUB]] dark-magic will {{ic|1=set root=(tftp,10.0.0.1)}} automatically, so that the kernel and initramfs are transferred via TFTP without any additional configuration, though you might want to set it explicitly if you have any other non-tftp menuentries.<br />
<br />
{{Note|GRUB files must be available through TFTP. For example, for a NBD install with TFTP root set to `/srv/tftp`, `/srv/tftp/grub/x86_64-efi/core.efi`, `/srv/tftp/vmlinuz-linux` must be present. You may copy all the /boot files inside the chroot to host TFTP server's root. }}<br />
<br />
{{Note|Modify your kernel line as-necessary, refer to [[PXELINUX]] for NBD-related options}}<br />
<br />
==== PXELINUX ====<br />
<br />
PXELINUX is provided by {{Pkg|syslinux}}, see [[PXELINUX]] for details.<br />
<br />
=== Additional mountpoints ===<br />
<br />
==== NBD root ====<br />
<br />
In late boot, you will want to switch your root filesystem mount to both {{ic|rw}}, and enable {{ic|1=compress=lzo}}, for much improved disk performance in comparison to [[NFS]].<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
/dev/nbd0 / btrfs rw,noatime,compress=lzo 0 0<br />
}}<br />
<br />
==== Program state directories ====<br />
<br />
{{Accuracy|systemd does not use persistent logging by default when /var/log/journal is in tmpfs and/or does not exist}}<br />
<br />
You could mount {{ic|/var/log}}, for example, as tmpfs so that logs from multiple hosts do not mix unpredictably, and do the same with {{ic|/var/spool/cups}}, so the 20 instances of cups using the same spool do not fight with each other and make 1,498 print jobs and eat an entire ream of paper (or worse: toner cartridge) overnight.<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
tmpfs /var/log tmpfs nodev,nosuid 0 0<br />
tmpfs /var/spool/cups tmpfs nodev,nosuid 0 0}}<br />
<br />
It would be best to configure software that has some sort of state/database to use unique state/database storage directories for each host. If you wanted to run [http://puppetlabs.com/ puppet], for example, you could simply use the {{ic|%H}} specifier in the puppet unit file:<br />
<br />
{{hc|# vim "$root/etc/systemd/system/puppetagent.service"|2=<br />
[Unit]<br />
Description=Puppet agent<br />
Wants=basic.target<br />
After=basic.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/run/puppet/agent.pid<br />
ExecStartPre=/usr/bin/install -d -o puppet -m 755 /run/puppet<br />
ExecStart=/usr/bin/puppet agent --vardir=/var/lib/puppet-%H --ssldir=/etc/puppet/ssl-%H<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Puppet-agent creates {{ic|vardir}} and {{ic|ssldir}} if they do not exist.<br />
<br />
If neither of these approaches are appropriate, the last sane option would be to create a {{man|7|systemd.generator}} that creates a mount unit specific to the current host (specifiers are not allowed in mount units, unfortunately).<br />
<br />
== Client boot ==<br />
<br />
=== NBD ===<br />
<br />
{{Accuracy|When using COW on the server, the clients all effectively have read-only mounts of the original filesystem; it should theoretically be safe to do a read-write mount on the NBD server}}<br />
<br />
If you are using NBD, you will need to umount the {{ic|arch.img}} before/while you boot your client.<br />
<br />
This makes things particularly interesting when it comes to kernel updates. You cannot have your client filesystem mounted while you are booting a client, but that also means you need to use a kernel separate from your client filesystem in order to build it.<br />
<br />
You will need to first copy {{ic|$root/boot}} from the client installation to your tftp root (i.e. {{ic|/srv/boot}}).<br />
<br />
# cp -r "$root/boot" /srv/boot<br />
<br />
You will then need to umount {{ic|$root}} before you start the client.<br />
<br />
# umount "$root"<br />
<br />
{{Note|To update the kernel in this setup, you either need to mount {{ic|/srv/boot}} using [[NFS]] in [[fstab]] on the client (prior to doing the kernel update) or mount your client filesystem after the client has disconnected from NBD}}<br />
<br />
== See also ==<br />
<br />
* [https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsroot.html kernel.org: Mounting the root filesystem via NFS (nfsroot)]<br />
* [https://wiki.syslinux.org/wiki/index.php/PXELINUX syslinux.org: pxelinux FAQ]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Diskless_system&diff=727134Diskless system2022-04-21T10:38:37Z<p>Saren: Add NBD settings for grub, TFTP caveat</p>
<hr />
<div>[[Category:Installation process]]<br />
[[de:Diskless_Workstation]]<br />
[[ja:ディスクレスシステム]]<br />
[[ru:Diskless system]]<br />
[[zh-hans:Diskless system]]<br />
{{Related articles start}}<br />
{{Related|NFS}}<br />
{{Related|NFS Troubleshooting}}<br />
{{Related|PXE}}<br />
{{Related|Mkinitcpio#Using net}}<br />
{{Related|iSCSI Boot}}<br />
{{Related articles end}}<br />
<br />
From [[Wikipedia:Diskless node]]<br />
:''A diskless node (or diskless workstation) is a workstation or personal computer without disk drives, which employs network booting to load its operating system from a server.''<br />
<br />
== Server configuration ==<br />
<br />
First of all, we must install the following components:<br />
* A [[Dhcpd|DHCP]] server to assign IP addresses to our diskless nodes.<br />
* A [[TFTP]] server to transfer the boot image (a requirement of all PXE option roms).<br />
* A form of network storage ([[NFS]] or NBD) to export the Arch installation to the diskless node.<br />
<br />
{{Note|{{pkg|dnsmasq}} is capable of simultaneously acting as both DHCP and TFTP server. For more information, see the [[dnsmasq]] article.}}<br />
<br />
=== DHCP ===<br />
<br />
Install ISC {{Pkg|dhcp}} and configure it:<br />
<br />
{{hc|/etc/dhcpd.conf|2=<br />
allow booting;<br />
allow bootp;<br />
<br />
authoritative;<br />
<br />
option domain-name-servers 10.0.0.1;<br />
<br />
option architecture code 93 = unsigned integer 16;<br />
<br />
group {<br />
next-server 10.0.0.1;<br />
<br />
if option architecture = 00:07 {<br />
filename "/grub/x86_64-efi/core.efi";<br />
} else {<br />
filename "/grub/i386-pc/core.0";<br />
}<br />
<br />
subnet 10.0.0.0 netmask 255.255.255.0 {<br />
option routers 10.0.0.1;<br />
range 10.0.0.128 10.0.0.254;<br />
}<br />
}<br />
}}<br />
<br />
{{Note|{{ic|next-server}} should be the address of the TFTP server; everything else should be changed to match your network}}<br />
<br />
RFC 4578 defines the "Client System Architecture Type" dhcp option. In the above configuration, if the PXE client requests an x86_64-efi binary (type 0x7), we appropriately give them one, otherwise falling back to the legacy binary. This allows both UEFI and legacy BIOS clients to boot simultaneously on the same network segment.<br />
<br />
Start ISC DHCP [[systemd]] service.<br />
<br />
=== TFTP ===<br />
<br />
The TFTP server will be used to transfer the bootloader, kernel, and initramfs to the client.<br />
<br />
Set the TFTP root to {{ic|/srv/arch/boot}}. See [[TFTP]] for installation and configuration.<br />
<br />
=== Network storage ===<br />
<br />
The primary difference between using NFS and NBD is while with both you can in fact have multiple clients using the same installation, with NBD (by the nature of manipulating a filesystem directly) you will need to use the {{ic|copyonwrite}} mode to do so, which ends up discarding all writes on client disconnect. In some situations however, this might be highly desirable.<br />
<br />
==== NFS ====<br />
<br />
Install {{Pkg|nfs-utils}} on the server.<br />
<br />
You will need to add the root of your Arch installation to your [[NFS]] exports:<br />
<br />
{{hc|/etc/exports|2=<br />
/srv *(rw,fsid=0,no_root_squash,no_subtree_check)<br />
/srv/arch *(rw,no_root_squash,no_subtree_check)<br />
}}<br />
<br />
Next, start NFS services: {{ic|nfs-idmapd}} {{ic|nfs-mountd}}.<br />
<br />
==== NBD ====<br />
<br />
Install {{Pkg|nbd}} and configure it.<br />
<br />
{{hc|/etc/nbd-server/config|2=<br />
[generic]<br />
user = nbd<br />
group = nbd<br />
[arch]<br />
exportname = /srv/arch.img<br />
copyonwrite = false<br />
}}<br />
<br />
{{Note|Set {{ic|copyonwrite}} to true if you want to have multiple clients using the same NBD share simultaneously; refer to {{man|5|nbd-server}} for more details. Also use [[chown]] to change the ownership of the exportname directory to the user {{ic|nbd}}.}}<br />
<br />
Start {{ic|nbd}} systemd service.<br />
<br />
== Client installation ==<br />
<br />
Next we will create a full Arch Linux installation in a subdirectory on the server. During boot, the diskless client will get an IP address from the DHCP server, then boot from the host using PXE and mount this installation as its root.<br />
<br />
=== Directory setup ===<br />
<br />
{{Note|Creating a separate filesystem is required for NBD but optional for NFS and can be skipped/ignored.}}<br />
<br />
Create a [[Wikipedia: Sparse file|sparse file]] of at least 1 gigabyte, and create a btrfs filesystem on it (you can of course also use a real block device or [[LVM]] if you want).<br />
<br />
# truncate -s 1G /srv/arch.img<br />
# mkfs.btrfs /srv/arch.img<br />
# export root=/srv/arch<br />
# mkdir -p "$root"<br />
# mount -o loop,compress=lzo /srv/arch.img "$root"<br />
<br />
=== Bootstrapping installation ===<br />
<br />
Install {{Pkg|devtools}} and {{Pkg|arch-install-scripts}}, and run ''pacstrap'' to install the [[Installation guide#Install essential packages|essential packages]] for the client:<br />
<br />
# pacstrap -d "$root" base linux linux-firmware mkinitcpio-nfs-utils nfs-utils<br />
<br />
{{Note|In all cases {{Pkg|mkinitcpio-nfs-utils}} is still required. {{ic|ipconfig}} used in early-boot is provided only by the latter.}}<br />
<br />
Now the initramfs needs to be constructed.<br />
<br />
==== NFS ====<br />
<br />
Trivial modifications to the {{ic|net}} hook are required in order for NFSv4 mounting to work (not supported by {{ic|nfsmount}} – the default for the {{ic|net}} hook).<br />
<br />
# sed s/nfsmount/mount.nfs4/ "$root/usr/lib/initcpio/hooks/net" > "$root/usr/lib/initcpio/hooks/netnfs4"<br />
# cp $root/usr/lib/initcpio/install/net{,nfs4}<br />
<br />
The copy of {{ic|net}} is unfortunately needed so it does not get overwritten when {{pkg|mkinitcpio-nfs-utils}} is updated on the client installation.<br />
<br />
Edit {{ic|$root/etc/mkinitcpio.conf}} and add {{ic|nfsv4}} to {{ic|MODULES}}, {{ic|netnfs4}} to {{ic|HOOKS}}, and {{ic|/usr/bin/mount.nfs4}} to {{ic|BINARIES}}.<br />
<br />
Next, we [[chroot]] our installation and run ''mkinitcpio'':<br />
<br />
# arch-chroot "$root" mkinitcpio -p linux<br />
<br />
==== NBD ====<br />
<br />
The {{AUR|mkinitcpio-nbd}} package needs to be installed on the client. Build it with [[makepkg]] and install it:<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -U mkinitcpio-nbd-0.4-1-any.pkg.tar.xz<br />
<br />
You will then need to append {{ic|nbd}} to your {{ic|HOOKS}} array after {{ic|net}}; {{ic|net}} will configure your networking for you, but not attempt a NFS mount if {{ic|nfsroot}} is not specified in the kernel line.<br />
<br />
== Client configuration ==<br />
<br />
In addition to the setup mentioned here, you should also set up your [[hostname]], [[timezone]], [[Locale#Setting the system locale|locale]], and [[keymap]], and follow any other relevant parts of the [[Installation guide]].<br />
<br />
=== Bootloader ===<br />
<br />
==== GRUB ====<br />
<br />
{{Merge|GRUB|}}<br />
<br />
Though poorly documented, GRUB supports being loaded via PXE.<br />
<br />
# pacman --root "$root" --dbpath "$root/var/lib/pacman" -S grub<br />
<br />
Create a grub prefix on the target installation for both architectures using {{ic|grub-mknetdir}}.<br />
<br />
# arch-chroot "$root" grub-mknetdir --net-directory=/boot --subdir=grub<br />
<br />
Luckily for us, grub-mknetdir creates prefixes for all currently compiled/installed targets, and the {{Pkg|grub}} maintainers were nice enough to give us both in the same package, thus grub-mknetdir only needs to be run once.<br />
<br />
Now we create a trivial GRUB configuration:<br />
<br />
{{hc|# vim "$root/boot/grub/grub.cfg"|2=<br />
# ... video settings<br />
menuentry "Arch Linux" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nfsroot=10.0.0.1:/arch<br />
initrd /initramfs-linux.img<br />
}<br />
<br />
menuentry "Arch Linux (NBD)" {<br />
# load_video, insmod etc<br />
linux /vmlinuz-linux quiet add_efi_memmap ip=:::::eth0:dhcp nbd_host=192.168.0.1 nbd_name=arch root=/dev/nbd0<br />
initrd /initramfs-linux.img<br />
}<br />
}}<br />
<br />
[[GRUB]] dark-magic will {{ic|1=set root=(tftp,10.0.0.1)}} automatically, so that the kernel and initramfs are transferred via TFTP without any additional configuration, though you might want to set it explicitly if you have any other non-tftp menuentries.<br />
<br />
{{Note|GRUB files must be available through TFTP, such as `grub/x86_64-efi/core.efi`}}<br />
<br />
{{Note|Modify your kernel line as-necessary, refer to [[PXELINUX]] for NBD-related options}}<br />
<br />
==== PXELINUX ====<br />
<br />
PXELINUX is provided by {{Pkg|syslinux}}, see [[PXELINUX]] for details.<br />
<br />
=== Additional mountpoints ===<br />
<br />
==== NBD root ====<br />
<br />
In late boot, you will want to switch your root filesystem mount to both {{ic|rw}}, and enable {{ic|1=compress=lzo}}, for much improved disk performance in comparison to [[NFS]].<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
/dev/nbd0 / btrfs rw,noatime,compress=lzo 0 0<br />
}}<br />
<br />
==== Program state directories ====<br />
<br />
{{Accuracy|systemd does not use persistent logging by default when /var/log/journal is in tmpfs and/or does not exist}}<br />
<br />
You could mount {{ic|/var/log}}, for example, as tmpfs so that logs from multiple hosts do not mix unpredictably, and do the same with {{ic|/var/spool/cups}}, so the 20 instances of cups using the same spool do not fight with each other and make 1,498 print jobs and eat an entire ream of paper (or worse: toner cartridge) overnight.<br />
<br />
{{hc|# vim "$root/etc/fstab"|2=<br />
tmpfs /var/log tmpfs nodev,nosuid 0 0<br />
tmpfs /var/spool/cups tmpfs nodev,nosuid 0 0}}<br />
<br />
It would be best to configure software that has some sort of state/database to use unique state/database storage directories for each host. If you wanted to run [http://puppetlabs.com/ puppet], for example, you could simply use the {{ic|%H}} specifier in the puppet unit file:<br />
<br />
{{hc|# vim "$root/etc/systemd/system/puppetagent.service"|2=<br />
[Unit]<br />
Description=Puppet agent<br />
Wants=basic.target<br />
After=basic.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/run/puppet/agent.pid<br />
ExecStartPre=/usr/bin/install -d -o puppet -m 755 /run/puppet<br />
ExecStart=/usr/bin/puppet agent --vardir=/var/lib/puppet-%H --ssldir=/etc/puppet/ssl-%H<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Puppet-agent creates {{ic|vardir}} and {{ic|ssldir}} if they do not exist.<br />
<br />
If neither of these approaches are appropriate, the last sane option would be to create a {{man|7|systemd.generator}} that creates a mount unit specific to the current host (specifiers are not allowed in mount units, unfortunately).<br />
<br />
== Client boot ==<br />
<br />
=== NBD ===<br />
<br />
{{Accuracy|When using COW on the server, the clients all effectively have read-only mounts of the original filesystem; it should theoretically be safe to do a read-write mount on the NBD server}}<br />
<br />
If you are using NBD, you will need to umount the {{ic|arch.img}} before/while you boot your client.<br />
<br />
This makes things particularly interesting when it comes to kernel updates. You cannot have your client filesystem mounted while you are booting a client, but that also means you need to use a kernel separate from your client filesystem in order to build it.<br />
<br />
You will need to first copy {{ic|$root/boot}} from the client installation to your tftp root (i.e. {{ic|/srv/boot}}).<br />
<br />
# cp -r "$root/boot" /srv/boot<br />
<br />
You will then need to umount {{ic|$root}} before you start the client.<br />
<br />
# umount "$root"<br />
<br />
{{Note|To update the kernel in this setup, you either need to mount {{ic|/srv/boot}} using [[NFS]] in [[fstab]] on the client (prior to doing the kernel update) or mount your client filesystem after the client has disconnected from NBD}}<br />
<br />
== See also ==<br />
<br />
* [https://www.kernel.org/doc/html/latest/admin-guide/nfs/nfsroot.html kernel.org: Mounting the root filesystem via NFS (nfsroot)]<br />
* [https://wiki.syslinux.org/wiki/index.php/PXELINUX syslinux.org: pxelinux FAQ]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Hadoop&diff=566848Hadoop2019-02-18T09:20:49Z<p>Saren: /* Execution */ Add basic namenode startup info</p>
<hr />
<div>[[Category:Distributed computing]]<br />
[[Category:Apache]]<br />
{{Related articles start}}<br />
{{Related|Apache spark}}<br />
{{Related articles end}}<br />
[[ja:Hadoop]]<br />
[[zh-hans:Hadoop]]<br />
[https://hadoop.apache.org Apache Hadoop] is a framework for running applications on large cluster built of commodity hardware. The Hadoop framework transparently provides applications both reliability and data motion. Hadoop implements a computational paradigm named Map/Reduce, where the application is divided into many small fragments of work, each of which may be executed or re-executed on any node in the cluster. In addition, it provides a distributed file system (HDFS) that stores data on the compute nodes, providing very high aggregate bandwidth across the cluster. Both MapReduce and the Hadoop Distributed File System are designed so that node failures are automatically handled by the framework. <br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|hadoop}} package.<br />
<br />
== Configuration ==<br />
<br />
By default, hadoop is already configured for pseudo-distributed operation. Some environment variables are set in {{ic|/etc/profile.d/hadoop.sh}} with different values than traditional hadoop.<br />
<br />
{| class="wikitable"<br />
|-<br />
! ENV<br />
! Value<br />
! Description <br />
! Permission <br />
|-<br />
| HADOOP_CONF_DIR<br />
| {{ic|/etc/hadoop}}<br />
| Where configuration files are stored.<br />
| Read<br />
|-<br />
| HADOOP_LOG_DIR<br />
| {{ic|/tmp/hadoop/log}}<br />
| Where log files are stored.<br />
| Read and Write<br />
|-<br />
| HADOOP_SLAVES<br />
| {{ic|/etc/hadoop/slaves}}<br />
| File naming remote slave hosts.<br />
| Read <br />
|-<br />
| HADOOP_PID_DIR<br />
| {{ic|/tmp/hadoop/run}}<br />
| Where pid files are stored.<br />
| Read and Write<br />
|}<br />
<br />
You also should set up the following files correctly. <br />
<br />
/etc/hosts<br />
/etc/hostname <br />
/etc/locale.conf<br />
<br />
You need to tell hadoop your JAVA_HOME in {{ic|/etc/hadoop/hadoop-env.sh}} because it doesn't assume the location where it's installed to in Arch Linux by itself:<br />
<br />
{{hc|1=/etc/hadoop/hadoop-env.sh|2=<br />
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk/<br />
}}<br />
<br />
Check installation with:<br />
<br />
hadoop version<br />
<br />
If you get warning message "WARNING: HADOOP_SLAVES has been replaced by HADOOP_WORKERS. Using value of HADOOP_SLAVES." Then replace {{ic|1=export HADOOP_SLAVES=/etc/hadoop/slaves}} in {{ic|/etc/profile.d/hadoop.sh}} with:<br />
<br />
export HADOOP_WORKERS=/etc/hadoop/workers<br />
<br />
== Single Node Setup ==<br />
{{Note|This section is based on the [http://hadoop.apache.org/docs/stable/ Hadoop Official Documentation] }}<br />
<br />
=== Standalone Operation ===<br />
<br />
By default, Hadoop is configured to run in a non-distributed mode, as a single Java process. This is useful for debugging.<br />
<br />
The following example copies the unpacked conf directory to use as input and then finds and displays every match of the given regular expression. Output is written to the given output directory.<br />
<br />
$ HADOOP_CONF_DIR=/usr/lib/hadoop/orig_etc/hadoop/<br />
$ mkdir input<br />
$ cp /etc/hadoop/*.xml input<br />
$ hadoop jar /usr/lib/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.0.0.jar grep input output 'dfs[a-z.]+'<br />
$ cat output/*<br />
<br />
=== Pseudo-Distributed Operation ===<br />
<br />
Hadoop can also be run on a single-node in a pseudo-distributed mode where each Hadoop daemon runs in a separate Java process.<br />
<br />
By default, Hadoop will run as the user root. You can change the user in {{ic|/etc/conf.d/hadoop}}:<br />
<br />
HADOOP_USERNAME="<your user name>"<br />
<br />
==== Set up passphraseless ssh ====<br />
<br />
Make sure you have [[sshd]] [[enabled]]. Now check that you can connect to localhost without a passphrase:<br />
<br />
$ ssh localhost<br />
<br />
If you cannot ssh to localhost without a passphrase, execute the following commands:<br />
<br />
$ ssh-keygen -t rsa -P "" -f ~/.ssh/id_rsa<br />
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys<br />
$ chmod 0600 ~/.ssh/authorized_keys<br />
<br />
Also make sure this line is commented in {{ic|/etc/ssh/sshd_config}}<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
#AuthorizedKeysFile .ssh/authorized_keys}}<br />
<br />
==== Execution ====<br />
Format a new distributed-filesystem:<br />
$ hadoop namenode -format<br />
<br />
Edit {{ic|/etc/hadoop/core-site.xml}} and add below configuration:<br />
<configuration><br />
<property><br />
<name>fs.defaultFS</name><br />
<value>hdfs://localhost:9000</value><br />
</property><br />
</configuration><br />
<br />
Start the hadoop namenode:<br />
$ hadoop namenode<br />
<br />
You may access the web GUI via http://localhost:9870/<br />
<br />
{{Accuracy|Instructions for older versions of Hadoop}}<br />
[[Start]] the following hadoop systemd units: {{ic|hadoop-datanode}}, {{ic|hadoop-jobtracker}}, {{ic|hadoop-namenode}}, {{ic|hadoop-secondarynamenode}}, {{ic|hadoop-tasktracker}}.<br />
<br />
The hadoop daemon log output is written to the {{ic|<nowiki>${HADOOP_LOG_DIR}</nowiki>}} directory (defaults to {{ic|/var/log/hadoop}}).<br />
<br />
Browse the web interface for the NameNode and the JobTracker; by default they are available at:<br />
<br />
* NameNode - http://localhost:50070/<br />
* JobTracker - http://localhost:50030/<br />
<br />
Copy the input files into the distributed filesystem:<br />
$ hadoop fs -put /etc/hadoop input<br />
<br />
Run some of the examples provided:<br />
$ hadoop jar /usr/lib/hadoop-2.7.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.3.jar grep input output 'dfs[a-z.]+'<br />
<br />
Examine the output files:<br />
<br />
Copy the output files from the distributed filesystem to the local filesystem and examine them:<br />
$ hadoop fs -get output output<br />
$ cat output/*<br />
<br />
or<br />
<br />
View the output files on the distributed filesystem:<br />
$ hadoop fs -cat output/*<br />
<br />
When you're done, [[stop]] the daemons {{ic|hadoop-datanode}}, {{ic|hadoop-jobtracker}}, {{ic|hadoop-namenode}}, {{ic|hadoop-secondarynamenode}}, {{ic|hadoop-tasktracker}}.</div>Sarenhttps://wiki.archlinux.org/index.php?title=Hadoop&diff=566847Hadoop2019-02-18T09:14:30Z<p>Saren: /* Execution */ Added accuracy notice</p>
<hr />
<div>[[Category:Distributed computing]]<br />
[[Category:Apache]]<br />
{{Related articles start}}<br />
{{Related|Apache spark}}<br />
{{Related articles end}}<br />
[[ja:Hadoop]]<br />
[[zh-hans:Hadoop]]<br />
[https://hadoop.apache.org Apache Hadoop] is a framework for running applications on large cluster built of commodity hardware. The Hadoop framework transparently provides applications both reliability and data motion. Hadoop implements a computational paradigm named Map/Reduce, where the application is divided into many small fragments of work, each of which may be executed or re-executed on any node in the cluster. In addition, it provides a distributed file system (HDFS) that stores data on the compute nodes, providing very high aggregate bandwidth across the cluster. Both MapReduce and the Hadoop Distributed File System are designed so that node failures are automatically handled by the framework. <br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{AUR|hadoop}} package.<br />
<br />
== Configuration ==<br />
<br />
By default, hadoop is already configured for pseudo-distributed operation. Some environment variables are set in {{ic|/etc/profile.d/hadoop.sh}} with different values than traditional hadoop.<br />
<br />
{| class="wikitable"<br />
|-<br />
! ENV<br />
! Value<br />
! Description <br />
! Permission <br />
|-<br />
| HADOOP_CONF_DIR<br />
| {{ic|/etc/hadoop}}<br />
| Where configuration files are stored.<br />
| Read<br />
|-<br />
| HADOOP_LOG_DIR<br />
| {{ic|/tmp/hadoop/log}}<br />
| Where log files are stored.<br />
| Read and Write<br />
|-<br />
| HADOOP_SLAVES<br />
| {{ic|/etc/hadoop/slaves}}<br />
| File naming remote slave hosts.<br />
| Read <br />
|-<br />
| HADOOP_PID_DIR<br />
| {{ic|/tmp/hadoop/run}}<br />
| Where pid files are stored.<br />
| Read and Write<br />
|}<br />
<br />
You also should set up the following files correctly. <br />
<br />
/etc/hosts<br />
/etc/hostname <br />
/etc/locale.conf<br />
<br />
You need to tell hadoop your JAVA_HOME in {{ic|/etc/hadoop/hadoop-env.sh}} because it doesn't assume the location where it's installed to in Arch Linux by itself:<br />
<br />
{{hc|1=/etc/hadoop/hadoop-env.sh|2=<br />
export JAVA_HOME=/usr/lib/jvm/java-8-openjdk/<br />
}}<br />
<br />
Check installation with:<br />
<br />
hadoop version<br />
<br />
If you get warning message "WARNING: HADOOP_SLAVES has been replaced by HADOOP_WORKERS. Using value of HADOOP_SLAVES." Then replace {{ic|1=export HADOOP_SLAVES=/etc/hadoop/slaves}} in {{ic|/etc/profile.d/hadoop.sh}} with:<br />
<br />
export HADOOP_WORKERS=/etc/hadoop/workers<br />
<br />
== Single Node Setup ==<br />
{{Note|This section is based on the [http://hadoop.apache.org/docs/stable/ Hadoop Official Documentation] }}<br />
<br />
=== Standalone Operation ===<br />
<br />
By default, Hadoop is configured to run in a non-distributed mode, as a single Java process. This is useful for debugging.<br />
<br />
The following example copies the unpacked conf directory to use as input and then finds and displays every match of the given regular expression. Output is written to the given output directory.<br />
<br />
$ HADOOP_CONF_DIR=/usr/lib/hadoop/orig_etc/hadoop/<br />
$ mkdir input<br />
$ cp /etc/hadoop/*.xml input<br />
$ hadoop jar /usr/lib/hadoop/share/hadoop/mapreduce/hadoop-mapreduce-examples-3.0.0.jar grep input output 'dfs[a-z.]+'<br />
$ cat output/*<br />
<br />
=== Pseudo-Distributed Operation ===<br />
<br />
Hadoop can also be run on a single-node in a pseudo-distributed mode where each Hadoop daemon runs in a separate Java process.<br />
<br />
By default, Hadoop will run as the user root. You can change the user in {{ic|/etc/conf.d/hadoop}}:<br />
<br />
HADOOP_USERNAME="<your user name>"<br />
<br />
==== Set up passphraseless ssh ====<br />
<br />
Make sure you have [[sshd]] [[enabled]]. Now check that you can connect to localhost without a passphrase:<br />
<br />
$ ssh localhost<br />
<br />
If you cannot ssh to localhost without a passphrase, execute the following commands:<br />
<br />
$ ssh-keygen -t rsa -P "" -f ~/.ssh/id_rsa<br />
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys<br />
$ chmod 0600 ~/.ssh/authorized_keys<br />
<br />
Also make sure this line is commented in {{ic|/etc/ssh/sshd_config}}<br />
<br />
{{hc|/etc/ssh/sshd_config|<br />
#AuthorizedKeysFile .ssh/authorized_keys}}<br />
<br />
==== Execution ====<br />
{{Accuracy|Instructions for older versions of Hadoop}}<br />
Format a new distributed-filesystem:<br />
$ hadoop namenode -format<br />
<br />
[[Start]] the following hadoop systemd units: {{ic|hadoop-datanode}}, {{ic|hadoop-jobtracker}}, {{ic|hadoop-namenode}}, {{ic|hadoop-secondarynamenode}}, {{ic|hadoop-tasktracker}}.<br />
<br />
The hadoop daemon log output is written to the {{ic|<nowiki>${HADOOP_LOG_DIR}</nowiki>}} directory (defaults to {{ic|/var/log/hadoop}}).<br />
<br />
Browse the web interface for the NameNode and the JobTracker; by default they are available at:<br />
<br />
* NameNode - http://localhost:50070/<br />
* JobTracker - http://localhost:50030/<br />
<br />
Copy the input files into the distributed filesystem:<br />
$ hadoop fs -put /etc/hadoop input<br />
<br />
Run some of the examples provided:<br />
$ hadoop jar /usr/lib/hadoop-2.7.3/share/hadoop/mapreduce/hadoop-mapreduce-examples-2.7.3.jar grep input output 'dfs[a-z.]+'<br />
<br />
Examine the output files:<br />
<br />
Copy the output files from the distributed filesystem to the local filesystem and examine them:<br />
$ hadoop fs -get output output<br />
$ cat output/*<br />
<br />
or<br />
<br />
View the output files on the distributed filesystem:<br />
$ hadoop fs -cat output/*<br />
<br />
When you're done, [[stop]] the daemons {{ic|hadoop-datanode}}, {{ic|hadoop-jobtracker}}, {{ic|hadoop-namenode}}, {{ic|hadoop-secondarynamenode}}, {{ic|hadoop-tasktracker}}.</div>Sarenhttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=541686Intel graphics2018-09-16T20:48:10Z<p>Saren: /* Enable GuC / HuC firmware loading */ Rephasing</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[cs:Intel graphics]]<br />
[[de:Intel]]<br />
[[es:Intel graphics]]<br />
[[fr:Intel]]<br />
[[hu:Intel graphics]]<br />
[[it:Intel graphics]]<br />
[[ja:Intel Graphics]]<br />
[[pl:Intel graphics]]<br />
[[pt:Intel graphics]]<br />
[[ru:Intel graphics]]<br />
[[zh-hans:Intel graphics]]<br />
[[zh-hant:Intel graphics]]<br />
{{Related articles start}}<br />
{{Related|Intel GMA 3600}}<br />
{{Related|Xorg}}<br />
{{Related|Kernel mode setting}}<br />
{{Related|Xrandr}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Vulkan}}<br />
{{Related articles end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:List of Intel graphics processing units]].<br />
<br />
{{Note|PowerVR-based graphics ([[Intel GMA 3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|mesa}} package, which provides the DRI driver for 3D acceleration.<br />
<br />
* For 32-bit application support, also install the {{Pkg|lib32-mesa}} package from the [[multilib]] repository.<br />
* For the DDX driver (which provides 2D acceleration in [[Xorg]]), [[install]] the {{Pkg|xf86-video-intel}} package. (Often not recommended, see note below.)<br />
* For [[Vulkan]] support (''Ivy Bridge'' and newer), install the {{Pkg|vulkan-intel}} package.<br />
<br />
Also see [[Hardware video acceleration]].<br />
<br />
{{Note|1=Some ([http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX Debian & Ubuntu], [http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-DDX-Switch Fedora], [https://community.kde.org/Plasma/5.9_Errata#Intel_GPUs KDE]) recommend not installing the {{Pkg|xf86-video-intel}} driver, and instead falling back on the modesetting driver for fourth generation and newer GPUs. See [https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/], [http://www.phoronix.com/scan.php?page=article&item=intel-modesetting-2017&num=1], [[Xorg#Installation]], and {{man|4|modesetting}}. However, the modesetting driver can cause problems such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 Chromium Issue 370022]. Also, the modesetting driver will not be benefited by Intel GuC/HuC/DMC firmware.}}<br />
<br />
== Loading ==<br />
<br />
The Intel kernel module should load fine automatically on system boot.<br />
<br />
If it does not happen, then:<br />
<br />
* Make sure you do '''not''' have {{ic|nomodeset}} or {{ic|1=vga=}} as a [[kernel parameter]], since Intel requires kernel mode-setting.<br />
* Also, check that you have not disabled Intel by using any modprobe blacklisting within {{ic|/etc/modprobe.d/}} or {{ic|/usr/lib/modprobe.d/}}.<br />
<br />
=== Enable early KMS ===<br />
<br />
[[Kernel mode setting]] (KMS) is supported by Intel chipsets that use the i915 DRM driver and is mandatory and enabled by default.<br />
<br />
Refer to [[Kernel mode setting#Early KMS start]] for instructions on how to enable KMS as soon as possible at the boot process.<br />
<br />
=== Enable GuC / HuC firmware loading ===<br />
<br />
{{Warning|1=Setting {{ic|1=enable_gvt=1}} when GuC/HuC is enabled is not supported as of linux 4.18.8. The i915 module would fail to initialize as shown in system journal.<br />
<br />
{{hc|$ journalctl|<br />
... kernel: [drm:intel_gvt_init [i915]] *ERROR* i915 GVT-g loading failed due to Graphics virtualization is not yet supported with GuC submission<br />
... kernel: i915 0000:00:02.0: [drm:i915_driver_load [i915]] Device initialization failed (-5)<br />
... kernel: i915: probe of 0000:00:02.0 failed with error -5<br />
... kernel: snd_hda_intel 0000:00:1f.3: failed to add i915 component master (-19)<br />
}}<br />
<br />
}}<br />
<br />
For Skylake and newer processors, some video features (e.g. CBR rate control on SKL low-power encoding mode) may require the use of an updated GPU firmware, which is currently (as of 4.16) not enabled by default. Enabling GuC/HuC firmware loading can cause issues on some systems; disable it if you experience freezing (for example, after resuming from hibernation).<br />
<br />
It is necessary to add {{ic|1=i915.enable_guc=3}} to the [[kernel parameters]] to enable both GuG and HuC firmware loading. Alternatively, if the [[initramfs]] already includes the {{ic|i915}} module (see [[Kernel mode setting#Early KMS start]]), you can set these options through a file in {{ic|/etc/modprobe.d/}}, e.g.:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 enable_guc=3<br />
}}<br />
<br />
You can verify both are enabled by using ''dmesg'':<br />
{{hc|$ dmesg|2=<br />
[drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)<br />
[drm] GuC: Loaded firmware i915/kbl_guc_ver9_39.bin (version 9.39)<br />
i915 0000:00:02.0: GuC firmware version 9.39<br />
i915 0000:00:02.0: GuC submission enabled<br />
i915 0000:00:02.0: HuC enabled<br />
}}<br />
<br />
Alternatively, check using:<br />
<br />
# cat /sys/kernel/debug/dri/0/i915_huc_load_status<br />
# cat /sys/kernel/debug/dri/0/i915_guc_load_status<br />
<br />
== Xorg configuration ==<br />
<br />
There is no need for any configuration to run [[Xorg]].<br />
<br />
However, to take advantage of some driver options, you will need to create a Xorg configuration file similar to the one below:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
EndSection}}<br />
<br />
Additional options are added by the user on new lines below {{ic|Driver}}.<br />
For the full list of options, see the {{man|4|intel}} man page.<br />
<br />
{{Note|<br />
*You may need to indicate {{ic|Option "AccelMethod"}} when creating a configuration file, even just to set it to the default method (currently {{ic|"sna"}}); otherwise, X may crash.<br />
*You might need to add more device sections than the one listed above. This will be indicated where necessary.}}<br />
<br />
== Module-based options ==<br />
<br />
The {{ic|i915}} kernel module allows for configuration via [[Kernel modules#Setting module options|module options]]. Some of the module options impact power saving.<br />
<br />
A list of all options along with short descriptions and default values can be generated with the following command:<br />
<br />
$ modinfo -p i915<br />
<br />
To check which options are currently enabled, run<br />
<br />
# systool -m i915 -av<br />
<br />
You will note that many options default to -1, resulting in per-chip powersaving defaults. It is however possible to configure more aggressive powersaving by using [[Kernel modules#Setting module options|module options]].<br />
<br />
{{Warning|1=Diverting from the defaults will mark the kernel as [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fc9740cebc3ab7c65f3c5f6ce0caf3e4969013ca tainted] from Linux 3.18 onwards. This basically implies using other options than the per-chip defaults is considered experimental and not supported by the developers. }}<br />
<br />
=== Framebuffer compression (enable_fbc) ===<br />
<br />
Making use of Framebuffer compression (FBC) can reduce power consumption while reducing memory bandwidth needed for screen refreshes.<br />
<br />
To enable FBC, use {{ic|1=i915.enable_fbc=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 enable_fbc=1<br />
</nowiki>}}<br />
<br />
{{Note|Framebuffer compression may be unreliable or unavailable on Intel GPU generations before Sandy Bridge (generation 6). This results in messages logged to the system journal similar to this one:<br />
kernel: drm: not enough stolen space for compressed buffer, disabling.<br />
<br />
Enabling frame buffer compression on pre-Sandy Bridge CPUs results in endless error messages:<br />
<br />
{{hc|$ dmesg|<br />
[ 2360.475430] [drm] not enough stolen space for compressed buffer (need 4325376 bytes), disabling<br />
[ 2360.475437] [drm] hint: you may be able to increase stolen memory size in the BIOS to avoid this<br />
}}<br />
<br />
The solution is to disable frame buffer compression which will imperceptibly increase power consumption (around 0.06 W). In order to disable it add {{ic|1=i915.enable_fbc=0}} to the kernel line parameters. More information on the results of disabled compression can be found [http://kernel.ubuntu.com/~cking/power-benchmarking/background-colour-and-framebuffer-compression/ here].}}<br />
<br />
=== Fastboot ===<br />
<br />
The goal of Intel Fastboot is to preserve the frame-buffer as setup by the BIOS or [[bootloader]] to avoid any flickering until [[Xorg]] has started [https://www.phoronix.com/scan.php?page=news_item&px=MTEwNzc].<br />
<br />
To enable fastboot, set {{ic|1=i915.fastboot=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 fastboot=1<br />
</nowiki>}}<br />
<br />
{{Warning|1=This parameter is not enabled by default and may cause issues on some systems [https://www.phoronix.com/scan.php?page=news_item&px=i915-Fastboot-Default-2017].}}<br />
<br />
=== Intel GVT-g Graphics Virtualization Support ===<br />
<br />
To enable GVT support, mainly used for allowing [[Xen]]/[[KVM]] guests to access the Intel GPU of the host, the {{ic|1=enable_gvt=1}} has to be set:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 enable_gvt=1<br />
</nowiki>}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Tear-free video ===<br />
<br />
The SNA acceleration method causes tearing for some people. To fix this, enable the {{ic|"TearFree"}} option in the driver by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "TearFree" "true"<br />
EndSection}}<br />
<br />
See the [https://bugs.freedesktop.org/show_bug.cgi?id=37686 original bug report] for more info.<br />
<br />
{{Note|1=<nowiki></nowiki><br />
* This option may not work when {{ic|SwapbuffersWait}} is {{ic|false}}.<br />
* This option may increases memory allocation considerably and reduce performance. [https://bugs.freedesktop.org/show_bug.cgi?id=37686#c123]<br />
* This option is problematic for applications that are very picky about vsync timing, like [[Wikipedia:Super Meat Boy|Super Meat Boy]].<br />
* This option does not work with UXA acceleration method, only with SNA.<br />
}}<br />
<br />
=== Disable Vertical Synchronization (VSYNC) ===<br />
Useful when:<br />
* Chomium/Chrome has lags and slow performance due to GPU and runs smoothly with --disable-gpu switch<br />
* glxgears test does not show desired performance<br />
<br />
The intel-driver uses [http://www.intel.com/support/graphics/sb/CS-004527.htm Triple Buffering] for vertical synchronization, this allows for full performance and avoids tearing. To turn vertical synchronization off (e.g. for benchmarking) use this {{ic|.drirc}} in your home directory:<br />
<br />
{{hc|~/.drirc|<br />
<device screen&#61;"0" driver&#61;"dri2"><br />
<application name&#61;"Default"><br />
<option name&#61;"vblank_mode" value&#61;"0"/><br />
</application><br />
</device>}}<br />
<br />
{{Warning|Do not use {{Pkg|driconf}} to create this file. It is buggy and will set the wrong driver.}}<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
<br />
$ xrandr --output LVDS1 --set PANEL_FITTING ''param''<br />
<br />
where {{ic|''param''}} can be:<br />
<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
<br />
If it does not work, try:<br />
<br />
$ xrandr --output LVDS1 --set "scaling mode" ''param''<br />
<br />
where {{ic|''param''}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
{{Note|1=This option currently does not work for external displays (e.g. VGA, DVI, HDMI, DP). [https://bugs.freedesktop.org/show_bug.cgi?id=90989]}}<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} in the kernel command line parameter in the bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, try disabling TV1 or VGA1 instead of SVIDEO-1. Video port names can be listed with [[xrandr]].<br />
<br />
=== Hardware accelerated H.264 decoding on GMA 4500 ===<br />
<br />
The {{Pkg|libva-intel-driver}} package only provides hardware accelerated MPEG-2 decoding for GMA 4500 series GPUs. The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-intel-driver-g45-h264}} package. Note however that this support is experimental and its development has been abandoned. Using the VA-API with this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load (compared to the XV overlay) but resulted in very choppy playback, while 720p worked reasonably well [https://bbs.archlinux.org/viewtopic.php?id=150550]. This is echoed by other experiences [http://www.emmolution.org/?p=192&cpage=1#comment-12292].<br />
Setting the preallocated video ram size higher in bios results in much better hardware decoded playback. Even 1080p h264 works well if this is done.<br />
Smooth playback (1080p/720p) works also with {{AUR|mpv-git}} in combination with {{AUR|ffmpeg-git}} and {{AUR|libva-intel-driver-g45-h264}}. With MPV and the Firefox plugin "Watch with MPV"[https://addons.mozilla.org/de/firefox/addon/watch-with-mpv/] it is possible to watch hardware accelerated YouTube videos.<br />
<br />
=== Setting brightness and gamma ===<br />
<br />
See [[Backlight]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== SNA issues ===<br />
<br />
''SNA'' is the default acceleration method in {{Pkg|xf86-video-intel}}. If you experience issues with ''SNA'' (e.g. pixelated graphics, corrupt text, etc.), try using ''UXA'' instead, which can be done by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "AccelMethod" "uxa"<br />
<br />
See {{man|4|intel}} under {{ic|Option "AccelMethod"}}.<br />
<br />
=== DRI3 issues ===<br />
<br />
''DRI3'' is the default DRI version in {{Pkg|xf86-video-intel}}. On some systems this can cause issues such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 this]. To switch back to ''DRI2'' add the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "DRI" "2"<br />
<br />
For the {{ic|modesetting}} driver, this method of disabling DRI3 does not work. Instead, one can set the environment variable {{ic|1=LIBGL_DRI3_DISABLE=1}}.<br />
<br />
=== Font and screen corruption in GTK+ applications (missing glyphs after suspend/resume) ===<br />
<br />
Should you experience missing font glyphs in GTK+ applications, the following workaround might help. [[textedit|Edit]] {{ic|/etc/environment}} to add the following line:<br />
<br />
{{hc|/etc/environment|output=<br />
COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer<br />
}}<br />
<br />
See also [https://bugs.freedesktop.org/show_bug.cgi?id=88584 FreeDesktop bug 88584].<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Kernel mode setting#Early KMS start]] section.<br />
<br />
Alternatively, appending the following [[kernel parameter]] seems to work as well:<br />
<br />
video=SVIDEO-1:d<br />
<br />
If you need to output to VGA then try this:<br />
<br />
video=VGA-1:1280x800<br />
<br />
=== X freeze/crash with intel driver ===<br />
<br />
Some issues with X crashing, GPU hanging, or problems with X freezing, can be fixed by disabling the GPU usage with the {{ic|NoAccel}} option - add the following lines to your [[#Xorg configuration|configuration file]]:<br />
Option "NoAccel" "True"<br />
<br />
Alternatively, try to disable the 3D acceleration only with the {{ic|DRI}} option:<br />
Option "DRI" "False"<br />
<br />
=== Baytrail complete freeze ===<br />
<br />
If you are using kernel > 3.16 on Baytrail architecture and randomly encounter total system freezes, the following kernel option is a workaround until [https://bugzilla.kernel.org/show_bug.cgi?id=109051 this bug] is fixed in the linux kernel.<br />
<br />
intel_idle.max_cstate=1<br />
<br />
This is originally an Intel CPU bug that can be triggered by certain c-state transitions. It can also happen with Linux kernel 3.16 or Windows, though apparently much more rarely.<br />
The kernel option will prevent the freeze by avoiding c-state transitions but will also increase power consumption.<br />
<br />
=== Adding undetected resolutions ===<br />
<br />
This issue is covered on the [[Xrandr#Adding undetected resolutions|Xrandr page]].<br />
<br />
=== Weathered colors (color range problem) ===<br />
<br />
Kernel 3.9 [http://lists.freedesktop.org/archives/dri-devel/2013-January/033576.html contains] a new default "Automatic" mode for the "Broadcast RGB" property in the Intel driver. It is almost equivalent to "Limited 16:235" (instead of the old default "Full") whenever an HDMI/DP output is in a [http://raspberrypi.stackexchange.com/questions/7332/what-is-the-difference-between-cea-and-dmt CEA mode]. If a monitor does not support signal in limited color range, it will cause weathered colors.<br />
<br />
{{Note|Some monitors/TVs support both color range. In that case an option often known as ''Black Level'' may need to be adjusted to make them handle the signal correctly. Some TVs can handle signal in limited range only. Setting Broadcast RGB to "Full" will cause color clipping. You may need to set it to "Limited 16:235" manually to avoid the clipping.}}<br />
<br />
One can force mode e.g. {{ic|xrandr --output <HDMI> --set "Broadcast RGB" "Full"}} (replace {{ic|<HDMI>}} with the appropriate output device, verify by running {{ic|xrandr}}).<br />
<br />
Unfortunately, the Intel driver does not support setting the color range through an {{ic|xorg.conf.d}} configuration file.<br />
<br />
A [https://bugzilla.kernel.org/show_bug.cgi?id=94921 bug report] is filed and a patch can be found in the attachment.<br />
<br />
Also there are other related problems which can be fixed editing GPU registers. More information can be found [http://lists.freedesktop.org/archives/intel-gfx/2012-April/016217.html] and [http://github.com/OpenELEC/OpenELEC.tv/commit/09109e9259eb051f34f771929b6a02635806404c].<br />
<br />
=== Backlight is not adjustable===<br />
<br />
If after resuming from suspend, the hotkeys for changing the screen brightness do not take effect, check your configuration against the [[Backlight]] article.<br />
<br />
If the problem persists, try one of the following [[kernel parameters]]:<br />
<br />
acpi_osi=Linux<br />
acpi_osi="!Windows 2012"<br />
acpi_osi=<br />
<br />
=== Corruption/Unresponsiveness in Chromium and Firefox ===<br />
<br />
If you experience corruption, unresponsiveness, lags or slow performance in Chromium and/or Firefox: <br />
* [[#SNA issues|Set the AccelMethod to "uxa"]]<br />
* [[#Disable Vertical Synchronization (VSYNC)|Disable VSYNC]]<br />
<br />
=== Kernel crashing w/kernels 4.0+ on Broadwell/Core-M chips ===<br />
<br />
A few seconds after X/Wayland loads the machine will freeze and journalctl will log a kernel crash referencing the Intel graphics as below:<br />
<br />
Jun 16 17:54:03 hostname kernel: BUG: unable to handle kernel NULL pointer dereference at (null)<br />
Jun 16 17:54:03 hostname kernel: IP: [< (null)>] (null)<br />
...<br />
Jun 16 17:54:03 hostname kernel: CPU: 0 PID: 733 Comm: gnome-shell Tainted: G U O 4.0.5-1-ARCH #1<br />
...<br />
Jun 16 17:54:03 hostname kernel: Call Trace:<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055cc27>] ? i915_gem_object_sync+0xe7/0x190 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0579634>] intel_execlists_submission+0x294/0x4c0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa05539fc>] i915_gem_do_execbuffer.isra.12+0xabc/0x1230 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055d349>] ? i915_gem_object_set_to_cpu_domain+0xa9/0x1f0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ba2ae>] ? __kmalloc+0x2e/0x2a0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555471>] i915_gem_execbuffer2+0x141/0x2b0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa042fcab>] drm_ioctl+0x1db/0x640 [drm]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555330>] ? i915_gem_execbuffer+0x450/0x450 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8122339b>] ? eventfd_ctx_read+0x16b/0x200<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebc36>] do_vfs_ioctl+0x2c6/0x4d0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811f6452>] ? __fget+0x72/0xb0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebec1>] SyS_ioctl+0x81/0xa0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8157a589>] system_call_fastpath+0x12/0x17<br />
Jun 16 17:54:03 hostname kernel: Code: Bad RIP value.<br />
Jun 16 17:54:03 hostname kernel: RIP [< (null)>] (null)<br />
<br />
This can be fixed by disabling execlist support which was changed to default on with kernel 4.0. Add the following [[kernel parameter]]:<br />
i915.enable_execlists=0<br />
<br />
This is known to be broken to at least kernel 4.0.5.<br />
<br />
=== Lag in Windows guests ===<br />
<br />
The video output of a Windows guest in VirtualBox sometimes hangs until the host forces a screen update (e.g. by moving the mouse cursor). Removing the {{ic|1=enable_fbc=1}} option fixes this issue.<br />
<br />
=== Screen flickering ===<br />
<br />
Panel Self Refresh (PSR), a power saving feature used by Intel iGPUs is known to cause flickering in some instances {{Bug|49628}} {{Bug|49371}} {{Bug|50605}}. A temporary solution is to disable this feature using the [[kernel parameter]] {{ic|1=i915.enable_psr=0}}.<br />
<br />
=== OpenGL 2.1 with i915 driver ===<br />
<br />
The update of {{Pkg|mesa}} from version 13.x to 17 may break support for OpenGL 2.1 on third gen Intel GPUs (GMA3100, see [[wikipedia:List_of_Intel_graphics_processing_units#Third_generation|here]]), as described in this [http://www.phoronix.com/scan.php?page=news_item&px=Mesa-i915-OpenGL-2-Drop article], reverting it back to OpenGL 1.4. However this could be restored manually by setting {{ic|/etc/drirc}} or {{ic|~/.drirc}} options like:<br />
{{hc|/etc/drirc|output=<br />
<driconf><br />
...<br />
<device driver="i915"><br />
<application name="Default"><br />
<option name="'''stub_occlusion_query'''" value="'''true'''" /><br />
<option name="'''fragment_shader'''" value="'''true'''" /><br />
</application><br />
</device><br />
...<br />
</driconf><br />
}}<br />
{{Note|the reason of this step back was Chromium and other apps bad experience. If needed, you might edit the drirc file in a "app-specific" style, see [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ here], to disable gl2.1 on executable chromium for instance.}}<br />
<br />
== See also ==<br />
<br />
* https://01.org/linuxgraphics/documentation (includes a list of supported hardware)</div>Sarenhttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=541685Intel graphics2018-09-16T20:46:54Z<p>Saren: /* Enable GuC / HuC firmware loading */ Clearify</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[cs:Intel graphics]]<br />
[[de:Intel]]<br />
[[es:Intel graphics]]<br />
[[fr:Intel]]<br />
[[hu:Intel graphics]]<br />
[[it:Intel graphics]]<br />
[[ja:Intel Graphics]]<br />
[[pl:Intel graphics]]<br />
[[pt:Intel graphics]]<br />
[[ru:Intel graphics]]<br />
[[zh-hans:Intel graphics]]<br />
[[zh-hant:Intel graphics]]<br />
{{Related articles start}}<br />
{{Related|Intel GMA 3600}}<br />
{{Related|Xorg}}<br />
{{Related|Kernel mode setting}}<br />
{{Related|Xrandr}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Vulkan}}<br />
{{Related articles end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:List of Intel graphics processing units]].<br />
<br />
{{Note|PowerVR-based graphics ([[Intel GMA 3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|mesa}} package, which provides the DRI driver for 3D acceleration.<br />
<br />
* For 32-bit application support, also install the {{Pkg|lib32-mesa}} package from the [[multilib]] repository.<br />
* For the DDX driver (which provides 2D acceleration in [[Xorg]]), [[install]] the {{Pkg|xf86-video-intel}} package. (Often not recommended, see note below.)<br />
* For [[Vulkan]] support (''Ivy Bridge'' and newer), install the {{Pkg|vulkan-intel}} package.<br />
<br />
Also see [[Hardware video acceleration]].<br />
<br />
{{Note|1=Some ([http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX Debian & Ubuntu], [http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-DDX-Switch Fedora], [https://community.kde.org/Plasma/5.9_Errata#Intel_GPUs KDE]) recommend not installing the {{Pkg|xf86-video-intel}} driver, and instead falling back on the modesetting driver for fourth generation and newer GPUs. See [https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/], [http://www.phoronix.com/scan.php?page=article&item=intel-modesetting-2017&num=1], [[Xorg#Installation]], and {{man|4|modesetting}}. However, the modesetting driver can cause problems such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 Chromium Issue 370022]. Also, the modesetting driver will not be benefited by Intel GuC/HuC/DMC firmware.}}<br />
<br />
== Loading ==<br />
<br />
The Intel kernel module should load fine automatically on system boot.<br />
<br />
If it does not happen, then:<br />
<br />
* Make sure you do '''not''' have {{ic|nomodeset}} or {{ic|1=vga=}} as a [[kernel parameter]], since Intel requires kernel mode-setting.<br />
* Also, check that you have not disabled Intel by using any modprobe blacklisting within {{ic|/etc/modprobe.d/}} or {{ic|/usr/lib/modprobe.d/}}.<br />
<br />
=== Enable early KMS ===<br />
<br />
[[Kernel mode setting]] (KMS) is supported by Intel chipsets that use the i915 DRM driver and is mandatory and enabled by default.<br />
<br />
Refer to [[Kernel mode setting#Early KMS start]] for instructions on how to enable KMS as soon as possible at the boot process.<br />
<br />
=== Enable GuC / HuC firmware loading ===<br />
<br />
{{Warning|1=Do not enable GuC/HuC when {{ic|1=enable_gvt=1}} regardless in {{ic|/etc/modprobe.d/}} or kernel parameters as of linux 4.18.8. The i915 module would fail to initialize as shown in system journal.<br />
<br />
{{hc|$ journalctl|<br />
... kernel: [drm:intel_gvt_init [i915]] *ERROR* i915 GVT-g loading failed due to Graphics virtualization is not yet supported with GuC submission<br />
... kernel: i915 0000:00:02.0: [drm:i915_driver_load [i915]] Device initialization failed (-5)<br />
... kernel: i915: probe of 0000:00:02.0 failed with error -5<br />
... kernel: snd_hda_intel 0000:00:1f.3: failed to add i915 component master (-19)<br />
}}<br />
<br />
}}<br />
<br />
For Skylake and newer processors, some video features (e.g. CBR rate control on SKL low-power encoding mode) may require the use of an updated GPU firmware, which is currently (as of 4.16) not enabled by default. Enabling GuC/HuC firmware loading can cause issues on some systems; disable it if you experience freezing (for example, after resuming from hibernation).<br />
<br />
It is necessary to add {{ic|1=i915.enable_guc=3}} to the [[kernel parameters]] to enable both GuG and HuC firmware loading. Alternatively, if the [[initramfs]] already includes the {{ic|i915}} module (see [[Kernel mode setting#Early KMS start]]), you can set these options through a file in {{ic|/etc/modprobe.d/}}, e.g.:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 enable_guc=3<br />
}}<br />
<br />
You can verify both are enabled by using ''dmesg'':<br />
{{hc|$ dmesg|2=<br />
[drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)<br />
[drm] GuC: Loaded firmware i915/kbl_guc_ver9_39.bin (version 9.39)<br />
i915 0000:00:02.0: GuC firmware version 9.39<br />
i915 0000:00:02.0: GuC submission enabled<br />
i915 0000:00:02.0: HuC enabled<br />
}}<br />
<br />
Alternatively, check using:<br />
<br />
# cat /sys/kernel/debug/dri/0/i915_huc_load_status<br />
# cat /sys/kernel/debug/dri/0/i915_guc_load_status<br />
<br />
== Xorg configuration ==<br />
<br />
There is no need for any configuration to run [[Xorg]].<br />
<br />
However, to take advantage of some driver options, you will need to create a Xorg configuration file similar to the one below:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
EndSection}}<br />
<br />
Additional options are added by the user on new lines below {{ic|Driver}}.<br />
For the full list of options, see the {{man|4|intel}} man page.<br />
<br />
{{Note|<br />
*You may need to indicate {{ic|Option "AccelMethod"}} when creating a configuration file, even just to set it to the default method (currently {{ic|"sna"}}); otherwise, X may crash.<br />
*You might need to add more device sections than the one listed above. This will be indicated where necessary.}}<br />
<br />
== Module-based options ==<br />
<br />
The {{ic|i915}} kernel module allows for configuration via [[Kernel modules#Setting module options|module options]]. Some of the module options impact power saving.<br />
<br />
A list of all options along with short descriptions and default values can be generated with the following command:<br />
<br />
$ modinfo -p i915<br />
<br />
To check which options are currently enabled, run<br />
<br />
# systool -m i915 -av<br />
<br />
You will note that many options default to -1, resulting in per-chip powersaving defaults. It is however possible to configure more aggressive powersaving by using [[Kernel modules#Setting module options|module options]].<br />
<br />
{{Warning|1=Diverting from the defaults will mark the kernel as [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fc9740cebc3ab7c65f3c5f6ce0caf3e4969013ca tainted] from Linux 3.18 onwards. This basically implies using other options than the per-chip defaults is considered experimental and not supported by the developers. }}<br />
<br />
=== Framebuffer compression (enable_fbc) ===<br />
<br />
Making use of Framebuffer compression (FBC) can reduce power consumption while reducing memory bandwidth needed for screen refreshes.<br />
<br />
To enable FBC, use {{ic|1=i915.enable_fbc=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 enable_fbc=1<br />
</nowiki>}}<br />
<br />
{{Note|Framebuffer compression may be unreliable or unavailable on Intel GPU generations before Sandy Bridge (generation 6). This results in messages logged to the system journal similar to this one:<br />
kernel: drm: not enough stolen space for compressed buffer, disabling.<br />
<br />
Enabling frame buffer compression on pre-Sandy Bridge CPUs results in endless error messages:<br />
<br />
{{hc|$ dmesg|<br />
[ 2360.475430] [drm] not enough stolen space for compressed buffer (need 4325376 bytes), disabling<br />
[ 2360.475437] [drm] hint: you may be able to increase stolen memory size in the BIOS to avoid this<br />
}}<br />
<br />
The solution is to disable frame buffer compression which will imperceptibly increase power consumption (around 0.06 W). In order to disable it add {{ic|1=i915.enable_fbc=0}} to the kernel line parameters. More information on the results of disabled compression can be found [http://kernel.ubuntu.com/~cking/power-benchmarking/background-colour-and-framebuffer-compression/ here].}}<br />
<br />
=== Fastboot ===<br />
<br />
The goal of Intel Fastboot is to preserve the frame-buffer as setup by the BIOS or [[bootloader]] to avoid any flickering until [[Xorg]] has started [https://www.phoronix.com/scan.php?page=news_item&px=MTEwNzc].<br />
<br />
To enable fastboot, set {{ic|1=i915.fastboot=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 fastboot=1<br />
</nowiki>}}<br />
<br />
{{Warning|1=This parameter is not enabled by default and may cause issues on some systems [https://www.phoronix.com/scan.php?page=news_item&px=i915-Fastboot-Default-2017].}}<br />
<br />
=== Intel GVT-g Graphics Virtualization Support ===<br />
<br />
To enable GVT support, mainly used for allowing [[Xen]]/[[KVM]] guests to access the Intel GPU of the host, the {{ic|1=enable_gvt=1}} has to be set:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 enable_gvt=1<br />
</nowiki>}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Tear-free video ===<br />
<br />
The SNA acceleration method causes tearing for some people. To fix this, enable the {{ic|"TearFree"}} option in the driver by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "TearFree" "true"<br />
EndSection}}<br />
<br />
See the [https://bugs.freedesktop.org/show_bug.cgi?id=37686 original bug report] for more info.<br />
<br />
{{Note|1=<nowiki></nowiki><br />
* This option may not work when {{ic|SwapbuffersWait}} is {{ic|false}}.<br />
* This option may increases memory allocation considerably and reduce performance. [https://bugs.freedesktop.org/show_bug.cgi?id=37686#c123]<br />
* This option is problematic for applications that are very picky about vsync timing, like [[Wikipedia:Super Meat Boy|Super Meat Boy]].<br />
* This option does not work with UXA acceleration method, only with SNA.<br />
}}<br />
<br />
=== Disable Vertical Synchronization (VSYNC) ===<br />
Useful when:<br />
* Chomium/Chrome has lags and slow performance due to GPU and runs smoothly with --disable-gpu switch<br />
* glxgears test does not show desired performance<br />
<br />
The intel-driver uses [http://www.intel.com/support/graphics/sb/CS-004527.htm Triple Buffering] for vertical synchronization, this allows for full performance and avoids tearing. To turn vertical synchronization off (e.g. for benchmarking) use this {{ic|.drirc}} in your home directory:<br />
<br />
{{hc|~/.drirc|<br />
<device screen&#61;"0" driver&#61;"dri2"><br />
<application name&#61;"Default"><br />
<option name&#61;"vblank_mode" value&#61;"0"/><br />
</application><br />
</device>}}<br />
<br />
{{Warning|Do not use {{Pkg|driconf}} to create this file. It is buggy and will set the wrong driver.}}<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
<br />
$ xrandr --output LVDS1 --set PANEL_FITTING ''param''<br />
<br />
where {{ic|''param''}} can be:<br />
<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
<br />
If it does not work, try:<br />
<br />
$ xrandr --output LVDS1 --set "scaling mode" ''param''<br />
<br />
where {{ic|''param''}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
{{Note|1=This option currently does not work for external displays (e.g. VGA, DVI, HDMI, DP). [https://bugs.freedesktop.org/show_bug.cgi?id=90989]}}<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} in the kernel command line parameter in the bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, try disabling TV1 or VGA1 instead of SVIDEO-1. Video port names can be listed with [[xrandr]].<br />
<br />
=== Hardware accelerated H.264 decoding on GMA 4500 ===<br />
<br />
The {{Pkg|libva-intel-driver}} package only provides hardware accelerated MPEG-2 decoding for GMA 4500 series GPUs. The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-intel-driver-g45-h264}} package. Note however that this support is experimental and its development has been abandoned. Using the VA-API with this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load (compared to the XV overlay) but resulted in very choppy playback, while 720p worked reasonably well [https://bbs.archlinux.org/viewtopic.php?id=150550]. This is echoed by other experiences [http://www.emmolution.org/?p=192&cpage=1#comment-12292].<br />
Setting the preallocated video ram size higher in bios results in much better hardware decoded playback. Even 1080p h264 works well if this is done.<br />
Smooth playback (1080p/720p) works also with {{AUR|mpv-git}} in combination with {{AUR|ffmpeg-git}} and {{AUR|libva-intel-driver-g45-h264}}. With MPV and the Firefox plugin "Watch with MPV"[https://addons.mozilla.org/de/firefox/addon/watch-with-mpv/] it is possible to watch hardware accelerated YouTube videos.<br />
<br />
=== Setting brightness and gamma ===<br />
<br />
See [[Backlight]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== SNA issues ===<br />
<br />
''SNA'' is the default acceleration method in {{Pkg|xf86-video-intel}}. If you experience issues with ''SNA'' (e.g. pixelated graphics, corrupt text, etc.), try using ''UXA'' instead, which can be done by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "AccelMethod" "uxa"<br />
<br />
See {{man|4|intel}} under {{ic|Option "AccelMethod"}}.<br />
<br />
=== DRI3 issues ===<br />
<br />
''DRI3'' is the default DRI version in {{Pkg|xf86-video-intel}}. On some systems this can cause issues such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 this]. To switch back to ''DRI2'' add the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "DRI" "2"<br />
<br />
For the {{ic|modesetting}} driver, this method of disabling DRI3 does not work. Instead, one can set the environment variable {{ic|1=LIBGL_DRI3_DISABLE=1}}.<br />
<br />
=== Font and screen corruption in GTK+ applications (missing glyphs after suspend/resume) ===<br />
<br />
Should you experience missing font glyphs in GTK+ applications, the following workaround might help. [[textedit|Edit]] {{ic|/etc/environment}} to add the following line:<br />
<br />
{{hc|/etc/environment|output=<br />
COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer<br />
}}<br />
<br />
See also [https://bugs.freedesktop.org/show_bug.cgi?id=88584 FreeDesktop bug 88584].<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Kernel mode setting#Early KMS start]] section.<br />
<br />
Alternatively, appending the following [[kernel parameter]] seems to work as well:<br />
<br />
video=SVIDEO-1:d<br />
<br />
If you need to output to VGA then try this:<br />
<br />
video=VGA-1:1280x800<br />
<br />
=== X freeze/crash with intel driver ===<br />
<br />
Some issues with X crashing, GPU hanging, or problems with X freezing, can be fixed by disabling the GPU usage with the {{ic|NoAccel}} option - add the following lines to your [[#Xorg configuration|configuration file]]:<br />
Option "NoAccel" "True"<br />
<br />
Alternatively, try to disable the 3D acceleration only with the {{ic|DRI}} option:<br />
Option "DRI" "False"<br />
<br />
=== Baytrail complete freeze ===<br />
<br />
If you are using kernel > 3.16 on Baytrail architecture and randomly encounter total system freezes, the following kernel option is a workaround until [https://bugzilla.kernel.org/show_bug.cgi?id=109051 this bug] is fixed in the linux kernel.<br />
<br />
intel_idle.max_cstate=1<br />
<br />
This is originally an Intel CPU bug that can be triggered by certain c-state transitions. It can also happen with Linux kernel 3.16 or Windows, though apparently much more rarely.<br />
The kernel option will prevent the freeze by avoiding c-state transitions but will also increase power consumption.<br />
<br />
=== Adding undetected resolutions ===<br />
<br />
This issue is covered on the [[Xrandr#Adding undetected resolutions|Xrandr page]].<br />
<br />
=== Weathered colors (color range problem) ===<br />
<br />
Kernel 3.9 [http://lists.freedesktop.org/archives/dri-devel/2013-January/033576.html contains] a new default "Automatic" mode for the "Broadcast RGB" property in the Intel driver. It is almost equivalent to "Limited 16:235" (instead of the old default "Full") whenever an HDMI/DP output is in a [http://raspberrypi.stackexchange.com/questions/7332/what-is-the-difference-between-cea-and-dmt CEA mode]. If a monitor does not support signal in limited color range, it will cause weathered colors.<br />
<br />
{{Note|Some monitors/TVs support both color range. In that case an option often known as ''Black Level'' may need to be adjusted to make them handle the signal correctly. Some TVs can handle signal in limited range only. Setting Broadcast RGB to "Full" will cause color clipping. You may need to set it to "Limited 16:235" manually to avoid the clipping.}}<br />
<br />
One can force mode e.g. {{ic|xrandr --output <HDMI> --set "Broadcast RGB" "Full"}} (replace {{ic|<HDMI>}} with the appropriate output device, verify by running {{ic|xrandr}}).<br />
<br />
Unfortunately, the Intel driver does not support setting the color range through an {{ic|xorg.conf.d}} configuration file.<br />
<br />
A [https://bugzilla.kernel.org/show_bug.cgi?id=94921 bug report] is filed and a patch can be found in the attachment.<br />
<br />
Also there are other related problems which can be fixed editing GPU registers. More information can be found [http://lists.freedesktop.org/archives/intel-gfx/2012-April/016217.html] and [http://github.com/OpenELEC/OpenELEC.tv/commit/09109e9259eb051f34f771929b6a02635806404c].<br />
<br />
=== Backlight is not adjustable===<br />
<br />
If after resuming from suspend, the hotkeys for changing the screen brightness do not take effect, check your configuration against the [[Backlight]] article.<br />
<br />
If the problem persists, try one of the following [[kernel parameters]]:<br />
<br />
acpi_osi=Linux<br />
acpi_osi="!Windows 2012"<br />
acpi_osi=<br />
<br />
=== Corruption/Unresponsiveness in Chromium and Firefox ===<br />
<br />
If you experience corruption, unresponsiveness, lags or slow performance in Chromium and/or Firefox: <br />
* [[#SNA issues|Set the AccelMethod to "uxa"]]<br />
* [[#Disable Vertical Synchronization (VSYNC)|Disable VSYNC]]<br />
<br />
=== Kernel crashing w/kernels 4.0+ on Broadwell/Core-M chips ===<br />
<br />
A few seconds after X/Wayland loads the machine will freeze and journalctl will log a kernel crash referencing the Intel graphics as below:<br />
<br />
Jun 16 17:54:03 hostname kernel: BUG: unable to handle kernel NULL pointer dereference at (null)<br />
Jun 16 17:54:03 hostname kernel: IP: [< (null)>] (null)<br />
...<br />
Jun 16 17:54:03 hostname kernel: CPU: 0 PID: 733 Comm: gnome-shell Tainted: G U O 4.0.5-1-ARCH #1<br />
...<br />
Jun 16 17:54:03 hostname kernel: Call Trace:<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055cc27>] ? i915_gem_object_sync+0xe7/0x190 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0579634>] intel_execlists_submission+0x294/0x4c0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa05539fc>] i915_gem_do_execbuffer.isra.12+0xabc/0x1230 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055d349>] ? i915_gem_object_set_to_cpu_domain+0xa9/0x1f0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ba2ae>] ? __kmalloc+0x2e/0x2a0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555471>] i915_gem_execbuffer2+0x141/0x2b0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa042fcab>] drm_ioctl+0x1db/0x640 [drm]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555330>] ? i915_gem_execbuffer+0x450/0x450 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8122339b>] ? eventfd_ctx_read+0x16b/0x200<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebc36>] do_vfs_ioctl+0x2c6/0x4d0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811f6452>] ? __fget+0x72/0xb0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebec1>] SyS_ioctl+0x81/0xa0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8157a589>] system_call_fastpath+0x12/0x17<br />
Jun 16 17:54:03 hostname kernel: Code: Bad RIP value.<br />
Jun 16 17:54:03 hostname kernel: RIP [< (null)>] (null)<br />
<br />
This can be fixed by disabling execlist support which was changed to default on with kernel 4.0. Add the following [[kernel parameter]]:<br />
i915.enable_execlists=0<br />
<br />
This is known to be broken to at least kernel 4.0.5.<br />
<br />
=== Lag in Windows guests ===<br />
<br />
The video output of a Windows guest in VirtualBox sometimes hangs until the host forces a screen update (e.g. by moving the mouse cursor). Removing the {{ic|1=enable_fbc=1}} option fixes this issue.<br />
<br />
=== Screen flickering ===<br />
<br />
Panel Self Refresh (PSR), a power saving feature used by Intel iGPUs is known to cause flickering in some instances {{Bug|49628}} {{Bug|49371}} {{Bug|50605}}. A temporary solution is to disable this feature using the [[kernel parameter]] {{ic|1=i915.enable_psr=0}}.<br />
<br />
=== OpenGL 2.1 with i915 driver ===<br />
<br />
The update of {{Pkg|mesa}} from version 13.x to 17 may break support for OpenGL 2.1 on third gen Intel GPUs (GMA3100, see [[wikipedia:List_of_Intel_graphics_processing_units#Third_generation|here]]), as described in this [http://www.phoronix.com/scan.php?page=news_item&px=Mesa-i915-OpenGL-2-Drop article], reverting it back to OpenGL 1.4. However this could be restored manually by setting {{ic|/etc/drirc}} or {{ic|~/.drirc}} options like:<br />
{{hc|/etc/drirc|output=<br />
<driconf><br />
...<br />
<device driver="i915"><br />
<application name="Default"><br />
<option name="'''stub_occlusion_query'''" value="'''true'''" /><br />
<option name="'''fragment_shader'''" value="'''true'''" /><br />
</application><br />
</device><br />
...<br />
</driconf><br />
}}<br />
{{Note|the reason of this step back was Chromium and other apps bad experience. If needed, you might edit the drirc file in a "app-specific" style, see [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ here], to disable gl2.1 on executable chromium for instance.}}<br />
<br />
== See also ==<br />
<br />
* https://01.org/linuxgraphics/documentation (includes a list of supported hardware)</div>Sarenhttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=541683Intel graphics2018-09-16T20:45:19Z<p>Saren: /* Enable GuC / HuC firmware loading */ log</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[cs:Intel graphics]]<br />
[[de:Intel]]<br />
[[es:Intel graphics]]<br />
[[fr:Intel]]<br />
[[hu:Intel graphics]]<br />
[[it:Intel graphics]]<br />
[[ja:Intel Graphics]]<br />
[[pl:Intel graphics]]<br />
[[pt:Intel graphics]]<br />
[[ru:Intel graphics]]<br />
[[zh-hans:Intel graphics]]<br />
[[zh-hant:Intel graphics]]<br />
{{Related articles start}}<br />
{{Related|Intel GMA 3600}}<br />
{{Related|Xorg}}<br />
{{Related|Kernel mode setting}}<br />
{{Related|Xrandr}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Vulkan}}<br />
{{Related articles end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:List of Intel graphics processing units]].<br />
<br />
{{Note|PowerVR-based graphics ([[Intel GMA 3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|mesa}} package, which provides the DRI driver for 3D acceleration.<br />
<br />
* For 32-bit application support, also install the {{Pkg|lib32-mesa}} package from the [[multilib]] repository.<br />
* For the DDX driver (which provides 2D acceleration in [[Xorg]]), [[install]] the {{Pkg|xf86-video-intel}} package. (Often not recommended, see note below.)<br />
* For [[Vulkan]] support (''Ivy Bridge'' and newer), install the {{Pkg|vulkan-intel}} package.<br />
<br />
Also see [[Hardware video acceleration]].<br />
<br />
{{Note|1=Some ([http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX Debian & Ubuntu], [http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-DDX-Switch Fedora], [https://community.kde.org/Plasma/5.9_Errata#Intel_GPUs KDE]) recommend not installing the {{Pkg|xf86-video-intel}} driver, and instead falling back on the modesetting driver for fourth generation and newer GPUs. See [https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/], [http://www.phoronix.com/scan.php?page=article&item=intel-modesetting-2017&num=1], [[Xorg#Installation]], and {{man|4|modesetting}}. However, the modesetting driver can cause problems such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 Chromium Issue 370022]. Also, the modesetting driver will not be benefited by Intel GuC/HuC/DMC firmware.}}<br />
<br />
== Loading ==<br />
<br />
The Intel kernel module should load fine automatically on system boot.<br />
<br />
If it does not happen, then:<br />
<br />
* Make sure you do '''not''' have {{ic|nomodeset}} or {{ic|1=vga=}} as a [[kernel parameter]], since Intel requires kernel mode-setting.<br />
* Also, check that you have not disabled Intel by using any modprobe blacklisting within {{ic|/etc/modprobe.d/}} or {{ic|/usr/lib/modprobe.d/}}.<br />
<br />
=== Enable early KMS ===<br />
<br />
[[Kernel mode setting]] (KMS) is supported by Intel chipsets that use the i915 DRM driver and is mandatory and enabled by default.<br />
<br />
Refer to [[Kernel mode setting#Early KMS start]] for instructions on how to enable KMS as soon as possible at the boot process.<br />
<br />
=== Enable GuC / HuC firmware loading ===<br />
<br />
{{Warning|1=Do not enable GuC/HuC when enable_gvt=1 as of linux 4.18.8, the i915 module would fail to initialize.<br />
<br />
{{hc|$ journalctl|<br />
... kernel: [drm:intel_gvt_init [i915]] *ERROR* i915 GVT-g loading failed due to Graphics virtualization is not yet supported with GuC submission<br />
... kernel: i915 0000:00:02.0: [drm:i915_driver_load [i915]] Device initialization failed (-5)<br />
... kernel: i915: probe of 0000:00:02.0 failed with error -5<br />
... kernel: snd_hda_intel 0000:00:1f.3: failed to add i915 component master (-19)<br />
}}<br />
<br />
}}<br />
<br />
For Skylake and newer processors, some video features (e.g. CBR rate control on SKL low-power encoding mode) may require the use of an updated GPU firmware, which is currently (as of 4.16) not enabled by default. Enabling GuC/HuC firmware loading can cause issues on some systems; disable it if you experience freezing (for example, after resuming from hibernation).<br />
<br />
It is necessary to add {{ic|1=i915.enable_guc=3}} to the [[kernel parameters]] to enable both GuG and HuC firmware loading. Alternatively, if the [[initramfs]] already includes the {{ic|i915}} module (see [[Kernel mode setting#Early KMS start]]), you can set these options through a file in {{ic|/etc/modprobe.d/}}, e.g.:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 enable_guc=3<br />
}}<br />
<br />
You can verify both are enabled by using ''dmesg'':<br />
{{hc|$ dmesg|2=<br />
[drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)<br />
[drm] GuC: Loaded firmware i915/kbl_guc_ver9_39.bin (version 9.39)<br />
i915 0000:00:02.0: GuC firmware version 9.39<br />
i915 0000:00:02.0: GuC submission enabled<br />
i915 0000:00:02.0: HuC enabled<br />
}}<br />
<br />
Alternatively, check using:<br />
<br />
# cat /sys/kernel/debug/dri/0/i915_huc_load_status<br />
# cat /sys/kernel/debug/dri/0/i915_guc_load_status<br />
<br />
== Xorg configuration ==<br />
<br />
There is no need for any configuration to run [[Xorg]].<br />
<br />
However, to take advantage of some driver options, you will need to create a Xorg configuration file similar to the one below:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
EndSection}}<br />
<br />
Additional options are added by the user on new lines below {{ic|Driver}}.<br />
For the full list of options, see the {{man|4|intel}} man page.<br />
<br />
{{Note|<br />
*You may need to indicate {{ic|Option "AccelMethod"}} when creating a configuration file, even just to set it to the default method (currently {{ic|"sna"}}); otherwise, X may crash.<br />
*You might need to add more device sections than the one listed above. This will be indicated where necessary.}}<br />
<br />
== Module-based options ==<br />
<br />
The {{ic|i915}} kernel module allows for configuration via [[Kernel modules#Setting module options|module options]]. Some of the module options impact power saving.<br />
<br />
A list of all options along with short descriptions and default values can be generated with the following command:<br />
<br />
$ modinfo -p i915<br />
<br />
To check which options are currently enabled, run<br />
<br />
# systool -m i915 -av<br />
<br />
You will note that many options default to -1, resulting in per-chip powersaving defaults. It is however possible to configure more aggressive powersaving by using [[Kernel modules#Setting module options|module options]].<br />
<br />
{{Warning|1=Diverting from the defaults will mark the kernel as [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fc9740cebc3ab7c65f3c5f6ce0caf3e4969013ca tainted] from Linux 3.18 onwards. This basically implies using other options than the per-chip defaults is considered experimental and not supported by the developers. }}<br />
<br />
=== Framebuffer compression (enable_fbc) ===<br />
<br />
Making use of Framebuffer compression (FBC) can reduce power consumption while reducing memory bandwidth needed for screen refreshes.<br />
<br />
To enable FBC, use {{ic|1=i915.enable_fbc=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 enable_fbc=1<br />
</nowiki>}}<br />
<br />
{{Note|Framebuffer compression may be unreliable or unavailable on Intel GPU generations before Sandy Bridge (generation 6). This results in messages logged to the system journal similar to this one:<br />
kernel: drm: not enough stolen space for compressed buffer, disabling.<br />
<br />
Enabling frame buffer compression on pre-Sandy Bridge CPUs results in endless error messages:<br />
<br />
{{hc|$ dmesg|<br />
[ 2360.475430] [drm] not enough stolen space for compressed buffer (need 4325376 bytes), disabling<br />
[ 2360.475437] [drm] hint: you may be able to increase stolen memory size in the BIOS to avoid this<br />
}}<br />
<br />
The solution is to disable frame buffer compression which will imperceptibly increase power consumption (around 0.06 W). In order to disable it add {{ic|1=i915.enable_fbc=0}} to the kernel line parameters. More information on the results of disabled compression can be found [http://kernel.ubuntu.com/~cking/power-benchmarking/background-colour-and-framebuffer-compression/ here].}}<br />
<br />
=== Fastboot ===<br />
<br />
The goal of Intel Fastboot is to preserve the frame-buffer as setup by the BIOS or [[bootloader]] to avoid any flickering until [[Xorg]] has started [https://www.phoronix.com/scan.php?page=news_item&px=MTEwNzc].<br />
<br />
To enable fastboot, set {{ic|1=i915.fastboot=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 fastboot=1<br />
</nowiki>}}<br />
<br />
{{Warning|1=This parameter is not enabled by default and may cause issues on some systems [https://www.phoronix.com/scan.php?page=news_item&px=i915-Fastboot-Default-2017].}}<br />
<br />
=== Intel GVT-g Graphics Virtualization Support ===<br />
<br />
To enable GVT support, mainly used for allowing [[Xen]]/[[KVM]] guests to access the Intel GPU of the host, the {{ic|1=enable_gvt=1}} has to be set:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 enable_gvt=1<br />
</nowiki>}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Tear-free video ===<br />
<br />
The SNA acceleration method causes tearing for some people. To fix this, enable the {{ic|"TearFree"}} option in the driver by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "TearFree" "true"<br />
EndSection}}<br />
<br />
See the [https://bugs.freedesktop.org/show_bug.cgi?id=37686 original bug report] for more info.<br />
<br />
{{Note|1=<nowiki></nowiki><br />
* This option may not work when {{ic|SwapbuffersWait}} is {{ic|false}}.<br />
* This option may increases memory allocation considerably and reduce performance. [https://bugs.freedesktop.org/show_bug.cgi?id=37686#c123]<br />
* This option is problematic for applications that are very picky about vsync timing, like [[Wikipedia:Super Meat Boy|Super Meat Boy]].<br />
* This option does not work with UXA acceleration method, only with SNA.<br />
}}<br />
<br />
=== Disable Vertical Synchronization (VSYNC) ===<br />
Useful when:<br />
* Chomium/Chrome has lags and slow performance due to GPU and runs smoothly with --disable-gpu switch<br />
* glxgears test does not show desired performance<br />
<br />
The intel-driver uses [http://www.intel.com/support/graphics/sb/CS-004527.htm Triple Buffering] for vertical synchronization, this allows for full performance and avoids tearing. To turn vertical synchronization off (e.g. for benchmarking) use this {{ic|.drirc}} in your home directory:<br />
<br />
{{hc|~/.drirc|<br />
<device screen&#61;"0" driver&#61;"dri2"><br />
<application name&#61;"Default"><br />
<option name&#61;"vblank_mode" value&#61;"0"/><br />
</application><br />
</device>}}<br />
<br />
{{Warning|Do not use {{Pkg|driconf}} to create this file. It is buggy and will set the wrong driver.}}<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
<br />
$ xrandr --output LVDS1 --set PANEL_FITTING ''param''<br />
<br />
where {{ic|''param''}} can be:<br />
<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
<br />
If it does not work, try:<br />
<br />
$ xrandr --output LVDS1 --set "scaling mode" ''param''<br />
<br />
where {{ic|''param''}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
{{Note|1=This option currently does not work for external displays (e.g. VGA, DVI, HDMI, DP). [https://bugs.freedesktop.org/show_bug.cgi?id=90989]}}<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} in the kernel command line parameter in the bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, try disabling TV1 or VGA1 instead of SVIDEO-1. Video port names can be listed with [[xrandr]].<br />
<br />
=== Hardware accelerated H.264 decoding on GMA 4500 ===<br />
<br />
The {{Pkg|libva-intel-driver}} package only provides hardware accelerated MPEG-2 decoding for GMA 4500 series GPUs. The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-intel-driver-g45-h264}} package. Note however that this support is experimental and its development has been abandoned. Using the VA-API with this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load (compared to the XV overlay) but resulted in very choppy playback, while 720p worked reasonably well [https://bbs.archlinux.org/viewtopic.php?id=150550]. This is echoed by other experiences [http://www.emmolution.org/?p=192&cpage=1#comment-12292].<br />
Setting the preallocated video ram size higher in bios results in much better hardware decoded playback. Even 1080p h264 works well if this is done.<br />
Smooth playback (1080p/720p) works also with {{AUR|mpv-git}} in combination with {{AUR|ffmpeg-git}} and {{AUR|libva-intel-driver-g45-h264}}. With MPV and the Firefox plugin "Watch with MPV"[https://addons.mozilla.org/de/firefox/addon/watch-with-mpv/] it is possible to watch hardware accelerated YouTube videos.<br />
<br />
=== Setting brightness and gamma ===<br />
<br />
See [[Backlight]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== SNA issues ===<br />
<br />
''SNA'' is the default acceleration method in {{Pkg|xf86-video-intel}}. If you experience issues with ''SNA'' (e.g. pixelated graphics, corrupt text, etc.), try using ''UXA'' instead, which can be done by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "AccelMethod" "uxa"<br />
<br />
See {{man|4|intel}} under {{ic|Option "AccelMethod"}}.<br />
<br />
=== DRI3 issues ===<br />
<br />
''DRI3'' is the default DRI version in {{Pkg|xf86-video-intel}}. On some systems this can cause issues such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 this]. To switch back to ''DRI2'' add the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "DRI" "2"<br />
<br />
For the {{ic|modesetting}} driver, this method of disabling DRI3 does not work. Instead, one can set the environment variable {{ic|1=LIBGL_DRI3_DISABLE=1}}.<br />
<br />
=== Font and screen corruption in GTK+ applications (missing glyphs after suspend/resume) ===<br />
<br />
Should you experience missing font glyphs in GTK+ applications, the following workaround might help. [[textedit|Edit]] {{ic|/etc/environment}} to add the following line:<br />
<br />
{{hc|/etc/environment|output=<br />
COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer<br />
}}<br />
<br />
See also [https://bugs.freedesktop.org/show_bug.cgi?id=88584 FreeDesktop bug 88584].<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Kernel mode setting#Early KMS start]] section.<br />
<br />
Alternatively, appending the following [[kernel parameter]] seems to work as well:<br />
<br />
video=SVIDEO-1:d<br />
<br />
If you need to output to VGA then try this:<br />
<br />
video=VGA-1:1280x800<br />
<br />
=== X freeze/crash with intel driver ===<br />
<br />
Some issues with X crashing, GPU hanging, or problems with X freezing, can be fixed by disabling the GPU usage with the {{ic|NoAccel}} option - add the following lines to your [[#Xorg configuration|configuration file]]:<br />
Option "NoAccel" "True"<br />
<br />
Alternatively, try to disable the 3D acceleration only with the {{ic|DRI}} option:<br />
Option "DRI" "False"<br />
<br />
=== Baytrail complete freeze ===<br />
<br />
If you are using kernel > 3.16 on Baytrail architecture and randomly encounter total system freezes, the following kernel option is a workaround until [https://bugzilla.kernel.org/show_bug.cgi?id=109051 this bug] is fixed in the linux kernel.<br />
<br />
intel_idle.max_cstate=1<br />
<br />
This is originally an Intel CPU bug that can be triggered by certain c-state transitions. It can also happen with Linux kernel 3.16 or Windows, though apparently much more rarely.<br />
The kernel option will prevent the freeze by avoiding c-state transitions but will also increase power consumption.<br />
<br />
=== Adding undetected resolutions ===<br />
<br />
This issue is covered on the [[Xrandr#Adding undetected resolutions|Xrandr page]].<br />
<br />
=== Weathered colors (color range problem) ===<br />
<br />
Kernel 3.9 [http://lists.freedesktop.org/archives/dri-devel/2013-January/033576.html contains] a new default "Automatic" mode for the "Broadcast RGB" property in the Intel driver. It is almost equivalent to "Limited 16:235" (instead of the old default "Full") whenever an HDMI/DP output is in a [http://raspberrypi.stackexchange.com/questions/7332/what-is-the-difference-between-cea-and-dmt CEA mode]. If a monitor does not support signal in limited color range, it will cause weathered colors.<br />
<br />
{{Note|Some monitors/TVs support both color range. In that case an option often known as ''Black Level'' may need to be adjusted to make them handle the signal correctly. Some TVs can handle signal in limited range only. Setting Broadcast RGB to "Full" will cause color clipping. You may need to set it to "Limited 16:235" manually to avoid the clipping.}}<br />
<br />
One can force mode e.g. {{ic|xrandr --output <HDMI> --set "Broadcast RGB" "Full"}} (replace {{ic|<HDMI>}} with the appropriate output device, verify by running {{ic|xrandr}}).<br />
<br />
Unfortunately, the Intel driver does not support setting the color range through an {{ic|xorg.conf.d}} configuration file.<br />
<br />
A [https://bugzilla.kernel.org/show_bug.cgi?id=94921 bug report] is filed and a patch can be found in the attachment.<br />
<br />
Also there are other related problems which can be fixed editing GPU registers. More information can be found [http://lists.freedesktop.org/archives/intel-gfx/2012-April/016217.html] and [http://github.com/OpenELEC/OpenELEC.tv/commit/09109e9259eb051f34f771929b6a02635806404c].<br />
<br />
=== Backlight is not adjustable===<br />
<br />
If after resuming from suspend, the hotkeys for changing the screen brightness do not take effect, check your configuration against the [[Backlight]] article.<br />
<br />
If the problem persists, try one of the following [[kernel parameters]]:<br />
<br />
acpi_osi=Linux<br />
acpi_osi="!Windows 2012"<br />
acpi_osi=<br />
<br />
=== Corruption/Unresponsiveness in Chromium and Firefox ===<br />
<br />
If you experience corruption, unresponsiveness, lags or slow performance in Chromium and/or Firefox: <br />
* [[#SNA issues|Set the AccelMethod to "uxa"]]<br />
* [[#Disable Vertical Synchronization (VSYNC)|Disable VSYNC]]<br />
<br />
=== Kernel crashing w/kernels 4.0+ on Broadwell/Core-M chips ===<br />
<br />
A few seconds after X/Wayland loads the machine will freeze and journalctl will log a kernel crash referencing the Intel graphics as below:<br />
<br />
Jun 16 17:54:03 hostname kernel: BUG: unable to handle kernel NULL pointer dereference at (null)<br />
Jun 16 17:54:03 hostname kernel: IP: [< (null)>] (null)<br />
...<br />
Jun 16 17:54:03 hostname kernel: CPU: 0 PID: 733 Comm: gnome-shell Tainted: G U O 4.0.5-1-ARCH #1<br />
...<br />
Jun 16 17:54:03 hostname kernel: Call Trace:<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055cc27>] ? i915_gem_object_sync+0xe7/0x190 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0579634>] intel_execlists_submission+0x294/0x4c0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa05539fc>] i915_gem_do_execbuffer.isra.12+0xabc/0x1230 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055d349>] ? i915_gem_object_set_to_cpu_domain+0xa9/0x1f0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ba2ae>] ? __kmalloc+0x2e/0x2a0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555471>] i915_gem_execbuffer2+0x141/0x2b0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa042fcab>] drm_ioctl+0x1db/0x640 [drm]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555330>] ? i915_gem_execbuffer+0x450/0x450 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8122339b>] ? eventfd_ctx_read+0x16b/0x200<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebc36>] do_vfs_ioctl+0x2c6/0x4d0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811f6452>] ? __fget+0x72/0xb0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebec1>] SyS_ioctl+0x81/0xa0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8157a589>] system_call_fastpath+0x12/0x17<br />
Jun 16 17:54:03 hostname kernel: Code: Bad RIP value.<br />
Jun 16 17:54:03 hostname kernel: RIP [< (null)>] (null)<br />
<br />
This can be fixed by disabling execlist support which was changed to default on with kernel 4.0. Add the following [[kernel parameter]]:<br />
i915.enable_execlists=0<br />
<br />
This is known to be broken to at least kernel 4.0.5.<br />
<br />
=== Lag in Windows guests ===<br />
<br />
The video output of a Windows guest in VirtualBox sometimes hangs until the host forces a screen update (e.g. by moving the mouse cursor). Removing the {{ic|1=enable_fbc=1}} option fixes this issue.<br />
<br />
=== Screen flickering ===<br />
<br />
Panel Self Refresh (PSR), a power saving feature used by Intel iGPUs is known to cause flickering in some instances {{Bug|49628}} {{Bug|49371}} {{Bug|50605}}. A temporary solution is to disable this feature using the [[kernel parameter]] {{ic|1=i915.enable_psr=0}}.<br />
<br />
=== OpenGL 2.1 with i915 driver ===<br />
<br />
The update of {{Pkg|mesa}} from version 13.x to 17 may break support for OpenGL 2.1 on third gen Intel GPUs (GMA3100, see [[wikipedia:List_of_Intel_graphics_processing_units#Third_generation|here]]), as described in this [http://www.phoronix.com/scan.php?page=news_item&px=Mesa-i915-OpenGL-2-Drop article], reverting it back to OpenGL 1.4. However this could be restored manually by setting {{ic|/etc/drirc}} or {{ic|~/.drirc}} options like:<br />
{{hc|/etc/drirc|output=<br />
<driconf><br />
...<br />
<device driver="i915"><br />
<application name="Default"><br />
<option name="'''stub_occlusion_query'''" value="'''true'''" /><br />
<option name="'''fragment_shader'''" value="'''true'''" /><br />
</application><br />
</device><br />
...<br />
</driconf><br />
}}<br />
{{Note|the reason of this step back was Chromium and other apps bad experience. If needed, you might edit the drirc file in a "app-specific" style, see [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ here], to disable gl2.1 on executable chromium for instance.}}<br />
<br />
== See also ==<br />
<br />
* https://01.org/linuxgraphics/documentation (includes a list of supported hardware)</div>Sarenhttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=541682Intel graphics2018-09-16T20:44:47Z<p>Saren: /* Enable GuC / HuC firmware loading */ Typo</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[cs:Intel graphics]]<br />
[[de:Intel]]<br />
[[es:Intel graphics]]<br />
[[fr:Intel]]<br />
[[hu:Intel graphics]]<br />
[[it:Intel graphics]]<br />
[[ja:Intel Graphics]]<br />
[[pl:Intel graphics]]<br />
[[pt:Intel graphics]]<br />
[[ru:Intel graphics]]<br />
[[zh-hans:Intel graphics]]<br />
[[zh-hant:Intel graphics]]<br />
{{Related articles start}}<br />
{{Related|Intel GMA 3600}}<br />
{{Related|Xorg}}<br />
{{Related|Kernel mode setting}}<br />
{{Related|Xrandr}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Vulkan}}<br />
{{Related articles end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:List of Intel graphics processing units]].<br />
<br />
{{Note|PowerVR-based graphics ([[Intel GMA 3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|mesa}} package, which provides the DRI driver for 3D acceleration.<br />
<br />
* For 32-bit application support, also install the {{Pkg|lib32-mesa}} package from the [[multilib]] repository.<br />
* For the DDX driver (which provides 2D acceleration in [[Xorg]]), [[install]] the {{Pkg|xf86-video-intel}} package. (Often not recommended, see note below.)<br />
* For [[Vulkan]] support (''Ivy Bridge'' and newer), install the {{Pkg|vulkan-intel}} package.<br />
<br />
Also see [[Hardware video acceleration]].<br />
<br />
{{Note|1=Some ([http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX Debian & Ubuntu], [http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-DDX-Switch Fedora], [https://community.kde.org/Plasma/5.9_Errata#Intel_GPUs KDE]) recommend not installing the {{Pkg|xf86-video-intel}} driver, and instead falling back on the modesetting driver for fourth generation and newer GPUs. See [https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/], [http://www.phoronix.com/scan.php?page=article&item=intel-modesetting-2017&num=1], [[Xorg#Installation]], and {{man|4|modesetting}}. However, the modesetting driver can cause problems such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 Chromium Issue 370022]. Also, the modesetting driver will not be benefited by Intel GuC/HuC/DMC firmware.}}<br />
<br />
== Loading ==<br />
<br />
The Intel kernel module should load fine automatically on system boot.<br />
<br />
If it does not happen, then:<br />
<br />
* Make sure you do '''not''' have {{ic|nomodeset}} or {{ic|1=vga=}} as a [[kernel parameter]], since Intel requires kernel mode-setting.<br />
* Also, check that you have not disabled Intel by using any modprobe blacklisting within {{ic|/etc/modprobe.d/}} or {{ic|/usr/lib/modprobe.d/}}.<br />
<br />
=== Enable early KMS ===<br />
<br />
[[Kernel mode setting]] (KMS) is supported by Intel chipsets that use the i915 DRM driver and is mandatory and enabled by default.<br />
<br />
Refer to [[Kernel mode setting#Early KMS start]] for instructions on how to enable KMS as soon as possible at the boot process.<br />
<br />
=== Enable GuC / HuC firmware loading ===<br />
<br />
{{Warning|1=Do not enable GuC/HuC when enable_gvt=1 as of linux 4.18.8, the i915 module would fail to initialize.<br />
<br />
{{hc|$ journalctl|<br />
... kernel: [drm:intel_gvt_init [i915]] *ERROR* i915 GVT-g loading failed due to Graphics virtualization is not yet supported with GuC submission<br />
... kernel: i915 0000:00:02.0: [drm:i915_driver_load [i915]] Device initialization failed (-5)<br />
... kernel: i915: probe of 0000:00:02.0 failed with error -5<br />
i915: probe of 0000:00:02.0 failed with error -5<br />
}}<br />
<br />
}}<br />
<br />
For Skylake and newer processors, some video features (e.g. CBR rate control on SKL low-power encoding mode) may require the use of an updated GPU firmware, which is currently (as of 4.16) not enabled by default. Enabling GuC/HuC firmware loading can cause issues on some systems; disable it if you experience freezing (for example, after resuming from hibernation).<br />
<br />
It is necessary to add {{ic|1=i915.enable_guc=3}} to the [[kernel parameters]] to enable both GuG and HuC firmware loading. Alternatively, if the [[initramfs]] already includes the {{ic|i915}} module (see [[Kernel mode setting#Early KMS start]]), you can set these options through a file in {{ic|/etc/modprobe.d/}}, e.g.:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 enable_guc=3<br />
}}<br />
<br />
You can verify both are enabled by using ''dmesg'':<br />
{{hc|$ dmesg|2=<br />
[drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)<br />
[drm] GuC: Loaded firmware i915/kbl_guc_ver9_39.bin (version 9.39)<br />
i915 0000:00:02.0: GuC firmware version 9.39<br />
i915 0000:00:02.0: GuC submission enabled<br />
i915 0000:00:02.0: HuC enabled<br />
}}<br />
<br />
Alternatively, check using:<br />
<br />
# cat /sys/kernel/debug/dri/0/i915_huc_load_status<br />
# cat /sys/kernel/debug/dri/0/i915_guc_load_status<br />
<br />
== Xorg configuration ==<br />
<br />
There is no need for any configuration to run [[Xorg]].<br />
<br />
However, to take advantage of some driver options, you will need to create a Xorg configuration file similar to the one below:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
EndSection}}<br />
<br />
Additional options are added by the user on new lines below {{ic|Driver}}.<br />
For the full list of options, see the {{man|4|intel}} man page.<br />
<br />
{{Note|<br />
*You may need to indicate {{ic|Option "AccelMethod"}} when creating a configuration file, even just to set it to the default method (currently {{ic|"sna"}}); otherwise, X may crash.<br />
*You might need to add more device sections than the one listed above. This will be indicated where necessary.}}<br />
<br />
== Module-based options ==<br />
<br />
The {{ic|i915}} kernel module allows for configuration via [[Kernel modules#Setting module options|module options]]. Some of the module options impact power saving.<br />
<br />
A list of all options along with short descriptions and default values can be generated with the following command:<br />
<br />
$ modinfo -p i915<br />
<br />
To check which options are currently enabled, run<br />
<br />
# systool -m i915 -av<br />
<br />
You will note that many options default to -1, resulting in per-chip powersaving defaults. It is however possible to configure more aggressive powersaving by using [[Kernel modules#Setting module options|module options]].<br />
<br />
{{Warning|1=Diverting from the defaults will mark the kernel as [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fc9740cebc3ab7c65f3c5f6ce0caf3e4969013ca tainted] from Linux 3.18 onwards. This basically implies using other options than the per-chip defaults is considered experimental and not supported by the developers. }}<br />
<br />
=== Framebuffer compression (enable_fbc) ===<br />
<br />
Making use of Framebuffer compression (FBC) can reduce power consumption while reducing memory bandwidth needed for screen refreshes.<br />
<br />
To enable FBC, use {{ic|1=i915.enable_fbc=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 enable_fbc=1<br />
</nowiki>}}<br />
<br />
{{Note|Framebuffer compression may be unreliable or unavailable on Intel GPU generations before Sandy Bridge (generation 6). This results in messages logged to the system journal similar to this one:<br />
kernel: drm: not enough stolen space for compressed buffer, disabling.<br />
<br />
Enabling frame buffer compression on pre-Sandy Bridge CPUs results in endless error messages:<br />
<br />
{{hc|$ dmesg|<br />
[ 2360.475430] [drm] not enough stolen space for compressed buffer (need 4325376 bytes), disabling<br />
[ 2360.475437] [drm] hint: you may be able to increase stolen memory size in the BIOS to avoid this<br />
}}<br />
<br />
The solution is to disable frame buffer compression which will imperceptibly increase power consumption (around 0.06 W). In order to disable it add {{ic|1=i915.enable_fbc=0}} to the kernel line parameters. More information on the results of disabled compression can be found [http://kernel.ubuntu.com/~cking/power-benchmarking/background-colour-and-framebuffer-compression/ here].}}<br />
<br />
=== Fastboot ===<br />
<br />
The goal of Intel Fastboot is to preserve the frame-buffer as setup by the BIOS or [[bootloader]] to avoid any flickering until [[Xorg]] has started [https://www.phoronix.com/scan.php?page=news_item&px=MTEwNzc].<br />
<br />
To enable fastboot, set {{ic|1=i915.fastboot=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 fastboot=1<br />
</nowiki>}}<br />
<br />
{{Warning|1=This parameter is not enabled by default and may cause issues on some systems [https://www.phoronix.com/scan.php?page=news_item&px=i915-Fastboot-Default-2017].}}<br />
<br />
=== Intel GVT-g Graphics Virtualization Support ===<br />
<br />
To enable GVT support, mainly used for allowing [[Xen]]/[[KVM]] guests to access the Intel GPU of the host, the {{ic|1=enable_gvt=1}} has to be set:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 enable_gvt=1<br />
</nowiki>}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Tear-free video ===<br />
<br />
The SNA acceleration method causes tearing for some people. To fix this, enable the {{ic|"TearFree"}} option in the driver by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "TearFree" "true"<br />
EndSection}}<br />
<br />
See the [https://bugs.freedesktop.org/show_bug.cgi?id=37686 original bug report] for more info.<br />
<br />
{{Note|1=<nowiki></nowiki><br />
* This option may not work when {{ic|SwapbuffersWait}} is {{ic|false}}.<br />
* This option may increases memory allocation considerably and reduce performance. [https://bugs.freedesktop.org/show_bug.cgi?id=37686#c123]<br />
* This option is problematic for applications that are very picky about vsync timing, like [[Wikipedia:Super Meat Boy|Super Meat Boy]].<br />
* This option does not work with UXA acceleration method, only with SNA.<br />
}}<br />
<br />
=== Disable Vertical Synchronization (VSYNC) ===<br />
Useful when:<br />
* Chomium/Chrome has lags and slow performance due to GPU and runs smoothly with --disable-gpu switch<br />
* glxgears test does not show desired performance<br />
<br />
The intel-driver uses [http://www.intel.com/support/graphics/sb/CS-004527.htm Triple Buffering] for vertical synchronization, this allows for full performance and avoids tearing. To turn vertical synchronization off (e.g. for benchmarking) use this {{ic|.drirc}} in your home directory:<br />
<br />
{{hc|~/.drirc|<br />
<device screen&#61;"0" driver&#61;"dri2"><br />
<application name&#61;"Default"><br />
<option name&#61;"vblank_mode" value&#61;"0"/><br />
</application><br />
</device>}}<br />
<br />
{{Warning|Do not use {{Pkg|driconf}} to create this file. It is buggy and will set the wrong driver.}}<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
<br />
$ xrandr --output LVDS1 --set PANEL_FITTING ''param''<br />
<br />
where {{ic|''param''}} can be:<br />
<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
<br />
If it does not work, try:<br />
<br />
$ xrandr --output LVDS1 --set "scaling mode" ''param''<br />
<br />
where {{ic|''param''}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
{{Note|1=This option currently does not work for external displays (e.g. VGA, DVI, HDMI, DP). [https://bugs.freedesktop.org/show_bug.cgi?id=90989]}}<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} in the kernel command line parameter in the bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, try disabling TV1 or VGA1 instead of SVIDEO-1. Video port names can be listed with [[xrandr]].<br />
<br />
=== Hardware accelerated H.264 decoding on GMA 4500 ===<br />
<br />
The {{Pkg|libva-intel-driver}} package only provides hardware accelerated MPEG-2 decoding for GMA 4500 series GPUs. The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-intel-driver-g45-h264}} package. Note however that this support is experimental and its development has been abandoned. Using the VA-API with this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load (compared to the XV overlay) but resulted in very choppy playback, while 720p worked reasonably well [https://bbs.archlinux.org/viewtopic.php?id=150550]. This is echoed by other experiences [http://www.emmolution.org/?p=192&cpage=1#comment-12292].<br />
Setting the preallocated video ram size higher in bios results in much better hardware decoded playback. Even 1080p h264 works well if this is done.<br />
Smooth playback (1080p/720p) works also with {{AUR|mpv-git}} in combination with {{AUR|ffmpeg-git}} and {{AUR|libva-intel-driver-g45-h264}}. With MPV and the Firefox plugin "Watch with MPV"[https://addons.mozilla.org/de/firefox/addon/watch-with-mpv/] it is possible to watch hardware accelerated YouTube videos.<br />
<br />
=== Setting brightness and gamma ===<br />
<br />
See [[Backlight]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== SNA issues ===<br />
<br />
''SNA'' is the default acceleration method in {{Pkg|xf86-video-intel}}. If you experience issues with ''SNA'' (e.g. pixelated graphics, corrupt text, etc.), try using ''UXA'' instead, which can be done by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "AccelMethod" "uxa"<br />
<br />
See {{man|4|intel}} under {{ic|Option "AccelMethod"}}.<br />
<br />
=== DRI3 issues ===<br />
<br />
''DRI3'' is the default DRI version in {{Pkg|xf86-video-intel}}. On some systems this can cause issues such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 this]. To switch back to ''DRI2'' add the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "DRI" "2"<br />
<br />
For the {{ic|modesetting}} driver, this method of disabling DRI3 does not work. Instead, one can set the environment variable {{ic|1=LIBGL_DRI3_DISABLE=1}}.<br />
<br />
=== Font and screen corruption in GTK+ applications (missing glyphs after suspend/resume) ===<br />
<br />
Should you experience missing font glyphs in GTK+ applications, the following workaround might help. [[textedit|Edit]] {{ic|/etc/environment}} to add the following line:<br />
<br />
{{hc|/etc/environment|output=<br />
COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer<br />
}}<br />
<br />
See also [https://bugs.freedesktop.org/show_bug.cgi?id=88584 FreeDesktop bug 88584].<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Kernel mode setting#Early KMS start]] section.<br />
<br />
Alternatively, appending the following [[kernel parameter]] seems to work as well:<br />
<br />
video=SVIDEO-1:d<br />
<br />
If you need to output to VGA then try this:<br />
<br />
video=VGA-1:1280x800<br />
<br />
=== X freeze/crash with intel driver ===<br />
<br />
Some issues with X crashing, GPU hanging, or problems with X freezing, can be fixed by disabling the GPU usage with the {{ic|NoAccel}} option - add the following lines to your [[#Xorg configuration|configuration file]]:<br />
Option "NoAccel" "True"<br />
<br />
Alternatively, try to disable the 3D acceleration only with the {{ic|DRI}} option:<br />
Option "DRI" "False"<br />
<br />
=== Baytrail complete freeze ===<br />
<br />
If you are using kernel > 3.16 on Baytrail architecture and randomly encounter total system freezes, the following kernel option is a workaround until [https://bugzilla.kernel.org/show_bug.cgi?id=109051 this bug] is fixed in the linux kernel.<br />
<br />
intel_idle.max_cstate=1<br />
<br />
This is originally an Intel CPU bug that can be triggered by certain c-state transitions. It can also happen with Linux kernel 3.16 or Windows, though apparently much more rarely.<br />
The kernel option will prevent the freeze by avoiding c-state transitions but will also increase power consumption.<br />
<br />
=== Adding undetected resolutions ===<br />
<br />
This issue is covered on the [[Xrandr#Adding undetected resolutions|Xrandr page]].<br />
<br />
=== Weathered colors (color range problem) ===<br />
<br />
Kernel 3.9 [http://lists.freedesktop.org/archives/dri-devel/2013-January/033576.html contains] a new default "Automatic" mode for the "Broadcast RGB" property in the Intel driver. It is almost equivalent to "Limited 16:235" (instead of the old default "Full") whenever an HDMI/DP output is in a [http://raspberrypi.stackexchange.com/questions/7332/what-is-the-difference-between-cea-and-dmt CEA mode]. If a monitor does not support signal in limited color range, it will cause weathered colors.<br />
<br />
{{Note|Some monitors/TVs support both color range. In that case an option often known as ''Black Level'' may need to be adjusted to make them handle the signal correctly. Some TVs can handle signal in limited range only. Setting Broadcast RGB to "Full" will cause color clipping. You may need to set it to "Limited 16:235" manually to avoid the clipping.}}<br />
<br />
One can force mode e.g. {{ic|xrandr --output <HDMI> --set "Broadcast RGB" "Full"}} (replace {{ic|<HDMI>}} with the appropriate output device, verify by running {{ic|xrandr}}).<br />
<br />
Unfortunately, the Intel driver does not support setting the color range through an {{ic|xorg.conf.d}} configuration file.<br />
<br />
A [https://bugzilla.kernel.org/show_bug.cgi?id=94921 bug report] is filed and a patch can be found in the attachment.<br />
<br />
Also there are other related problems which can be fixed editing GPU registers. More information can be found [http://lists.freedesktop.org/archives/intel-gfx/2012-April/016217.html] and [http://github.com/OpenELEC/OpenELEC.tv/commit/09109e9259eb051f34f771929b6a02635806404c].<br />
<br />
=== Backlight is not adjustable===<br />
<br />
If after resuming from suspend, the hotkeys for changing the screen brightness do not take effect, check your configuration against the [[Backlight]] article.<br />
<br />
If the problem persists, try one of the following [[kernel parameters]]:<br />
<br />
acpi_osi=Linux<br />
acpi_osi="!Windows 2012"<br />
acpi_osi=<br />
<br />
=== Corruption/Unresponsiveness in Chromium and Firefox ===<br />
<br />
If you experience corruption, unresponsiveness, lags or slow performance in Chromium and/or Firefox: <br />
* [[#SNA issues|Set the AccelMethod to "uxa"]]<br />
* [[#Disable Vertical Synchronization (VSYNC)|Disable VSYNC]]<br />
<br />
=== Kernel crashing w/kernels 4.0+ on Broadwell/Core-M chips ===<br />
<br />
A few seconds after X/Wayland loads the machine will freeze and journalctl will log a kernel crash referencing the Intel graphics as below:<br />
<br />
Jun 16 17:54:03 hostname kernel: BUG: unable to handle kernel NULL pointer dereference at (null)<br />
Jun 16 17:54:03 hostname kernel: IP: [< (null)>] (null)<br />
...<br />
Jun 16 17:54:03 hostname kernel: CPU: 0 PID: 733 Comm: gnome-shell Tainted: G U O 4.0.5-1-ARCH #1<br />
...<br />
Jun 16 17:54:03 hostname kernel: Call Trace:<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055cc27>] ? i915_gem_object_sync+0xe7/0x190 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0579634>] intel_execlists_submission+0x294/0x4c0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa05539fc>] i915_gem_do_execbuffer.isra.12+0xabc/0x1230 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055d349>] ? i915_gem_object_set_to_cpu_domain+0xa9/0x1f0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ba2ae>] ? __kmalloc+0x2e/0x2a0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555471>] i915_gem_execbuffer2+0x141/0x2b0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa042fcab>] drm_ioctl+0x1db/0x640 [drm]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555330>] ? i915_gem_execbuffer+0x450/0x450 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8122339b>] ? eventfd_ctx_read+0x16b/0x200<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebc36>] do_vfs_ioctl+0x2c6/0x4d0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811f6452>] ? __fget+0x72/0xb0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebec1>] SyS_ioctl+0x81/0xa0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8157a589>] system_call_fastpath+0x12/0x17<br />
Jun 16 17:54:03 hostname kernel: Code: Bad RIP value.<br />
Jun 16 17:54:03 hostname kernel: RIP [< (null)>] (null)<br />
<br />
This can be fixed by disabling execlist support which was changed to default on with kernel 4.0. Add the following [[kernel parameter]]:<br />
i915.enable_execlists=0<br />
<br />
This is known to be broken to at least kernel 4.0.5.<br />
<br />
=== Lag in Windows guests ===<br />
<br />
The video output of a Windows guest in VirtualBox sometimes hangs until the host forces a screen update (e.g. by moving the mouse cursor). Removing the {{ic|1=enable_fbc=1}} option fixes this issue.<br />
<br />
=== Screen flickering ===<br />
<br />
Panel Self Refresh (PSR), a power saving feature used by Intel iGPUs is known to cause flickering in some instances {{Bug|49628}} {{Bug|49371}} {{Bug|50605}}. A temporary solution is to disable this feature using the [[kernel parameter]] {{ic|1=i915.enable_psr=0}}.<br />
<br />
=== OpenGL 2.1 with i915 driver ===<br />
<br />
The update of {{Pkg|mesa}} from version 13.x to 17 may break support for OpenGL 2.1 on third gen Intel GPUs (GMA3100, see [[wikipedia:List_of_Intel_graphics_processing_units#Third_generation|here]]), as described in this [http://www.phoronix.com/scan.php?page=news_item&px=Mesa-i915-OpenGL-2-Drop article], reverting it back to OpenGL 1.4. However this could be restored manually by setting {{ic|/etc/drirc}} or {{ic|~/.drirc}} options like:<br />
{{hc|/etc/drirc|output=<br />
<driconf><br />
...<br />
<device driver="i915"><br />
<application name="Default"><br />
<option name="'''stub_occlusion_query'''" value="'''true'''" /><br />
<option name="'''fragment_shader'''" value="'''true'''" /><br />
</application><br />
</device><br />
...<br />
</driconf><br />
}}<br />
{{Note|the reason of this step back was Chromium and other apps bad experience. If needed, you might edit the drirc file in a "app-specific" style, see [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ here], to disable gl2.1 on executable chromium for instance.}}<br />
<br />
== See also ==<br />
<br />
* https://01.org/linuxgraphics/documentation (includes a list of supported hardware)</div>Sarenhttps://wiki.archlinux.org/index.php?title=Intel_graphics&diff=541681Intel graphics2018-09-16T20:44:15Z<p>Saren: /* Enable GuC / HuC firmware loading */ I experience this issue and found this out.</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[cs:Intel graphics]]<br />
[[de:Intel]]<br />
[[es:Intel graphics]]<br />
[[fr:Intel]]<br />
[[hu:Intel graphics]]<br />
[[it:Intel graphics]]<br />
[[ja:Intel Graphics]]<br />
[[pl:Intel graphics]]<br />
[[pt:Intel graphics]]<br />
[[ru:Intel graphics]]<br />
[[zh-hans:Intel graphics]]<br />
[[zh-hant:Intel graphics]]<br />
{{Related articles start}}<br />
{{Related|Intel GMA 3600}}<br />
{{Related|Xorg}}<br />
{{Related|Kernel mode setting}}<br />
{{Related|Xrandr}}<br />
{{Related|Hybrid graphics}}<br />
{{Related|Vulkan}}<br />
{{Related articles end}}<br />
<br />
Since Intel provides and supports open source drivers, Intel graphics are essentially plug-and-play.<br />
<br />
For a comprehensive list of Intel GPU models and corresponding chipsets and CPUs, see [[Wikipedia:List of Intel graphics processing units]].<br />
<br />
{{Note|PowerVR-based graphics ([[Intel GMA 3600|GMA 3600]] series) are not supported by open source drivers.}}<br />
<br />
== Installation ==<br />
<br />
[[Install]] the {{Pkg|mesa}} package, which provides the DRI driver for 3D acceleration.<br />
<br />
* For 32-bit application support, also install the {{Pkg|lib32-mesa}} package from the [[multilib]] repository.<br />
* For the DDX driver (which provides 2D acceleration in [[Xorg]]), [[install]] the {{Pkg|xf86-video-intel}} package. (Often not recommended, see note below.)<br />
* For [[Vulkan]] support (''Ivy Bridge'' and newer), install the {{Pkg|vulkan-intel}} package.<br />
<br />
Also see [[Hardware video acceleration]].<br />
<br />
{{Note|1=Some ([http://www.phoronix.com/scan.php?page=news_item&px=Ubuntu-Debian-Abandon-Intel-DDX Debian & Ubuntu], [http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Xorg-Intel-DDX-Switch Fedora], [https://community.kde.org/Plasma/5.9_Errata#Intel_GPUs KDE]) recommend not installing the {{Pkg|xf86-video-intel}} driver, and instead falling back on the modesetting driver for fourth generation and newer GPUs. See [https://www.reddit.com/r/archlinux/comments/4cojj9/it_is_probably_time_to_ditch_xf86videointel/], [http://www.phoronix.com/scan.php?page=article&item=intel-modesetting-2017&num=1], [[Xorg#Installation]], and {{man|4|modesetting}}. However, the modesetting driver can cause problems such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 Chromium Issue 370022]. Also, the modesetting driver will not be benefited by Intel GuC/HuC/DMC firmware.}}<br />
<br />
== Loading ==<br />
<br />
The Intel kernel module should load fine automatically on system boot.<br />
<br />
If it does not happen, then:<br />
<br />
* Make sure you do '''not''' have {{ic|nomodeset}} or {{ic|1=vga=}} as a [[kernel parameter]], since Intel requires kernel mode-setting.<br />
* Also, check that you have not disabled Intel by using any modprobe blacklisting within {{ic|/etc/modprobe.d/}} or {{ic|/usr/lib/modprobe.d/}}.<br />
<br />
=== Enable early KMS ===<br />
<br />
[[Kernel mode setting]] (KMS) is supported by Intel chipsets that use the i915 DRM driver and is mandatory and enabled by default.<br />
<br />
Refer to [[Kernel mode setting#Early KMS start]] for instructions on how to enable KMS as soon as possible at the boot process.<br />
<br />
=== Enable GuC / HuC firmware loading ===<br />
<br />
{{Warning|1=Do not enable GuC/HuC when enable_gvt=1 as of linux 4.18.8, the i915 module would fail to initialize.<br />
<br />
{{hc|$ dmesg|<br />
kernel: [drm:intel_gvt_init [i915]] *ERROR* i915 GVT-g loading failed due to Graphics virtualization is not yet supported with GuC submission<br />
kernel: i915 0000:00:02.0: [drm:i915_driver_load [i915]] Device initialization failed (-5)<br />
kernel: i915: probe of 0000:00:02.0 failed with error -5<br />
i915: probe of 0000:00:02.0 failed with error -5<br />
}}<br />
<br />
}}<br />
<br />
For Skylake and newer processors, some video features (e.g. CBR rate control on SKL low-power encoding mode) may require the use of an updated GPU firmware, which is currently (as of 4.16) not enabled by default. Enabling GuC/HuC firmware loading can cause issues on some systems; disable it if you experience freezing (for example, after resuming from hibernation).<br />
<br />
It is necessary to add {{ic|1=i915.enable_guc=3}} to the [[kernel parameters]] to enable both GuG and HuC firmware loading. Alternatively, if the [[initramfs]] already includes the {{ic|i915}} module (see [[Kernel mode setting#Early KMS start]]), you can set these options through a file in {{ic|/etc/modprobe.d/}}, e.g.:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|2=<br />
options i915 enable_guc=3<br />
}}<br />
<br />
You can verify both are enabled by using ''dmesg'':<br />
{{hc|$ dmesg|2=<br />
[drm] HuC: Loaded firmware i915/kbl_huc_ver02_00_1810.bin (version 2.0)<br />
[drm] GuC: Loaded firmware i915/kbl_guc_ver9_39.bin (version 9.39)<br />
i915 0000:00:02.0: GuC firmware version 9.39<br />
i915 0000:00:02.0: GuC submission enabled<br />
i915 0000:00:02.0: HuC enabled<br />
}}<br />
<br />
Alternatively, check using:<br />
<br />
# cat /sys/kernel/debug/dri/0/i915_huc_load_status<br />
# cat /sys/kernel/debug/dri/0/i915_guc_load_status<br />
<br />
== Xorg configuration ==<br />
<br />
There is no need for any configuration to run [[Xorg]].<br />
<br />
However, to take advantage of some driver options, you will need to create a Xorg configuration file similar to the one below:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
EndSection}}<br />
<br />
Additional options are added by the user on new lines below {{ic|Driver}}.<br />
For the full list of options, see the {{man|4|intel}} man page.<br />
<br />
{{Note|<br />
*You may need to indicate {{ic|Option "AccelMethod"}} when creating a configuration file, even just to set it to the default method (currently {{ic|"sna"}}); otherwise, X may crash.<br />
*You might need to add more device sections than the one listed above. This will be indicated where necessary.}}<br />
<br />
== Module-based options ==<br />
<br />
The {{ic|i915}} kernel module allows for configuration via [[Kernel modules#Setting module options|module options]]. Some of the module options impact power saving.<br />
<br />
A list of all options along with short descriptions and default values can be generated with the following command:<br />
<br />
$ modinfo -p i915<br />
<br />
To check which options are currently enabled, run<br />
<br />
# systool -m i915 -av<br />
<br />
You will note that many options default to -1, resulting in per-chip powersaving defaults. It is however possible to configure more aggressive powersaving by using [[Kernel modules#Setting module options|module options]].<br />
<br />
{{Warning|1=Diverting from the defaults will mark the kernel as [https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fc9740cebc3ab7c65f3c5f6ce0caf3e4969013ca tainted] from Linux 3.18 onwards. This basically implies using other options than the per-chip defaults is considered experimental and not supported by the developers. }}<br />
<br />
=== Framebuffer compression (enable_fbc) ===<br />
<br />
Making use of Framebuffer compression (FBC) can reduce power consumption while reducing memory bandwidth needed for screen refreshes.<br />
<br />
To enable FBC, use {{ic|1=i915.enable_fbc=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 enable_fbc=1<br />
</nowiki>}}<br />
<br />
{{Note|Framebuffer compression may be unreliable or unavailable on Intel GPU generations before Sandy Bridge (generation 6). This results in messages logged to the system journal similar to this one:<br />
kernel: drm: not enough stolen space for compressed buffer, disabling.<br />
<br />
Enabling frame buffer compression on pre-Sandy Bridge CPUs results in endless error messages:<br />
<br />
{{hc|$ dmesg|<br />
[ 2360.475430] [drm] not enough stolen space for compressed buffer (need 4325376 bytes), disabling<br />
[ 2360.475437] [drm] hint: you may be able to increase stolen memory size in the BIOS to avoid this<br />
}}<br />
<br />
The solution is to disable frame buffer compression which will imperceptibly increase power consumption (around 0.06 W). In order to disable it add {{ic|1=i915.enable_fbc=0}} to the kernel line parameters. More information on the results of disabled compression can be found [http://kernel.ubuntu.com/~cking/power-benchmarking/background-colour-and-framebuffer-compression/ here].}}<br />
<br />
=== Fastboot ===<br />
<br />
The goal of Intel Fastboot is to preserve the frame-buffer as setup by the BIOS or [[bootloader]] to avoid any flickering until [[Xorg]] has started [https://www.phoronix.com/scan.php?page=news_item&px=MTEwNzc].<br />
<br />
To enable fastboot, set {{ic|1=i915.fastboot=1}} as [[kernel parameter]] or set in {{ic|/etc/modprobe/i915.conf}}:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 fastboot=1<br />
</nowiki>}}<br />
<br />
{{Warning|1=This parameter is not enabled by default and may cause issues on some systems [https://www.phoronix.com/scan.php?page=news_item&px=i915-Fastboot-Default-2017].}}<br />
<br />
=== Intel GVT-g Graphics Virtualization Support ===<br />
<br />
To enable GVT support, mainly used for allowing [[Xen]]/[[KVM]] guests to access the Intel GPU of the host, the {{ic|1=enable_gvt=1}} has to be set:<br />
<br />
{{hc|/etc/modprobe.d/i915.conf|<nowiki><br />
options i915 enable_gvt=1<br />
</nowiki>}}<br />
<br />
== Tips and tricks ==<br />
<br />
=== Tear-free video ===<br />
<br />
The SNA acceleration method causes tearing for some people. To fix this, enable the {{ic|"TearFree"}} option in the driver by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
<br />
{{hc|/etc/X11/xorg.conf.d/20-intel.conf|<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
Option "TearFree" "true"<br />
EndSection}}<br />
<br />
See the [https://bugs.freedesktop.org/show_bug.cgi?id=37686 original bug report] for more info.<br />
<br />
{{Note|1=<nowiki></nowiki><br />
* This option may not work when {{ic|SwapbuffersWait}} is {{ic|false}}.<br />
* This option may increases memory allocation considerably and reduce performance. [https://bugs.freedesktop.org/show_bug.cgi?id=37686#c123]<br />
* This option is problematic for applications that are very picky about vsync timing, like [[Wikipedia:Super Meat Boy|Super Meat Boy]].<br />
* This option does not work with UXA acceleration method, only with SNA.<br />
}}<br />
<br />
=== Disable Vertical Synchronization (VSYNC) ===<br />
Useful when:<br />
* Chomium/Chrome has lags and slow performance due to GPU and runs smoothly with --disable-gpu switch<br />
* glxgears test does not show desired performance<br />
<br />
The intel-driver uses [http://www.intel.com/support/graphics/sb/CS-004527.htm Triple Buffering] for vertical synchronization, this allows for full performance and avoids tearing. To turn vertical synchronization off (e.g. for benchmarking) use this {{ic|.drirc}} in your home directory:<br />
<br />
{{hc|~/.drirc|<br />
<device screen&#61;"0" driver&#61;"dri2"><br />
<application name&#61;"Default"><br />
<option name&#61;"vblank_mode" value&#61;"0"/><br />
</application><br />
</device>}}<br />
<br />
{{Warning|Do not use {{Pkg|driconf}} to create this file. It is buggy and will set the wrong driver.}}<br />
<br />
=== Setting scaling mode ===<br />
<br />
This can be useful for some full screen applications:<br />
<br />
$ xrandr --output LVDS1 --set PANEL_FITTING ''param''<br />
<br />
where {{ic|''param''}} can be:<br />
<br />
* {{ic|center}}: resolution will be kept exactly as defined, no scaling will be made,<br />
* {{ic|full}}: scale the resolution so it uses the entire screen or<br />
* {{ic|full_aspect}}: scale the resolution to the maximum possible but keep the aspect ratio.<br />
<br />
If it does not work, try:<br />
<br />
$ xrandr --output LVDS1 --set "scaling mode" ''param''<br />
<br />
where {{ic|''param''}} is one of {{ic|"Full"}}, {{ic|"Center"}} or {{ic|"Full aspect"}}.<br />
<br />
{{Note|1=This option currently does not work for external displays (e.g. VGA, DVI, HDMI, DP). [https://bugs.freedesktop.org/show_bug.cgi?id=90989]}}<br />
<br />
=== KMS Issue: console is limited to small area ===<br />
<br />
One of the low-resolution video ports may be enabled on boot which is causing the terminal to utilize a small area of the screen. To fix, explicitly disable the port with an i915 module setting with {{ic|1=video=SVIDEO-1:d}} in the kernel command line parameter in the bootloader. See [[Kernel parameters]] for more info.<br />
<br />
If that does not work, try disabling TV1 or VGA1 instead of SVIDEO-1. Video port names can be listed with [[xrandr]].<br />
<br />
=== Hardware accelerated H.264 decoding on GMA 4500 ===<br />
<br />
The {{Pkg|libva-intel-driver}} package only provides hardware accelerated MPEG-2 decoding for GMA 4500 series GPUs. The H.264 decoding support is maintained in a separated g45-h264 branch, which can be used by installing {{AUR|libva-intel-driver-g45-h264}} package. Note however that this support is experimental and its development has been abandoned. Using the VA-API with this driver on a GMA 4500 series GPU will offload the CPU but may not result in as smooth a playback as non-accelerated playback. Tests using mplayer showed that using vaapi to play back an H.264 encoded 1080p video halved the CPU load (compared to the XV overlay) but resulted in very choppy playback, while 720p worked reasonably well [https://bbs.archlinux.org/viewtopic.php?id=150550]. This is echoed by other experiences [http://www.emmolution.org/?p=192&cpage=1#comment-12292].<br />
Setting the preallocated video ram size higher in bios results in much better hardware decoded playback. Even 1080p h264 works well if this is done.<br />
Smooth playback (1080p/720p) works also with {{AUR|mpv-git}} in combination with {{AUR|ffmpeg-git}} and {{AUR|libva-intel-driver-g45-h264}}. With MPV and the Firefox plugin "Watch with MPV"[https://addons.mozilla.org/de/firefox/addon/watch-with-mpv/] it is possible to watch hardware accelerated YouTube videos.<br />
<br />
=== Setting brightness and gamma ===<br />
<br />
See [[Backlight]].<br />
<br />
== Troubleshooting ==<br />
<br />
=== SNA issues ===<br />
<br />
''SNA'' is the default acceleration method in {{Pkg|xf86-video-intel}}. If you experience issues with ''SNA'' (e.g. pixelated graphics, corrupt text, etc.), try using ''UXA'' instead, which can be done by adding the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "AccelMethod" "uxa"<br />
<br />
See {{man|4|intel}} under {{ic|Option "AccelMethod"}}.<br />
<br />
=== DRI3 issues ===<br />
<br />
''DRI3'' is the default DRI version in {{Pkg|xf86-video-intel}}. On some systems this can cause issues such as [https://bugs.chromium.org/p/chromium/issues/detail?id=370022 this]. To switch back to ''DRI2'' add the following line to your [[#Xorg configuration|configuration file]]:<br />
Option "DRI" "2"<br />
<br />
For the {{ic|modesetting}} driver, this method of disabling DRI3 does not work. Instead, one can set the environment variable {{ic|1=LIBGL_DRI3_DISABLE=1}}.<br />
<br />
=== Font and screen corruption in GTK+ applications (missing glyphs after suspend/resume) ===<br />
<br />
Should you experience missing font glyphs in GTK+ applications, the following workaround might help. [[textedit|Edit]] {{ic|/etc/environment}} to add the following line:<br />
<br />
{{hc|/etc/environment|output=<br />
COGL_ATLAS_DEFAULT_BLIT_MODE=framebuffer<br />
}}<br />
<br />
See also [https://bugs.freedesktop.org/show_bug.cgi?id=88584 FreeDesktop bug 88584].<br />
<br />
=== Blank screen during boot, when "Loading modules" ===<br />
<br />
If using "late start" KMS and the screen goes blank when "Loading modules", it may help to add {{ic|i915}} and {{ic|intel_agp}} to the initramfs. See [[Kernel mode setting#Early KMS start]] section.<br />
<br />
Alternatively, appending the following [[kernel parameter]] seems to work as well:<br />
<br />
video=SVIDEO-1:d<br />
<br />
If you need to output to VGA then try this:<br />
<br />
video=VGA-1:1280x800<br />
<br />
=== X freeze/crash with intel driver ===<br />
<br />
Some issues with X crashing, GPU hanging, or problems with X freezing, can be fixed by disabling the GPU usage with the {{ic|NoAccel}} option - add the following lines to your [[#Xorg configuration|configuration file]]:<br />
Option "NoAccel" "True"<br />
<br />
Alternatively, try to disable the 3D acceleration only with the {{ic|DRI}} option:<br />
Option "DRI" "False"<br />
<br />
=== Baytrail complete freeze ===<br />
<br />
If you are using kernel > 3.16 on Baytrail architecture and randomly encounter total system freezes, the following kernel option is a workaround until [https://bugzilla.kernel.org/show_bug.cgi?id=109051 this bug] is fixed in the linux kernel.<br />
<br />
intel_idle.max_cstate=1<br />
<br />
This is originally an Intel CPU bug that can be triggered by certain c-state transitions. It can also happen with Linux kernel 3.16 or Windows, though apparently much more rarely.<br />
The kernel option will prevent the freeze by avoiding c-state transitions but will also increase power consumption.<br />
<br />
=== Adding undetected resolutions ===<br />
<br />
This issue is covered on the [[Xrandr#Adding undetected resolutions|Xrandr page]].<br />
<br />
=== Weathered colors (color range problem) ===<br />
<br />
Kernel 3.9 [http://lists.freedesktop.org/archives/dri-devel/2013-January/033576.html contains] a new default "Automatic" mode for the "Broadcast RGB" property in the Intel driver. It is almost equivalent to "Limited 16:235" (instead of the old default "Full") whenever an HDMI/DP output is in a [http://raspberrypi.stackexchange.com/questions/7332/what-is-the-difference-between-cea-and-dmt CEA mode]. If a monitor does not support signal in limited color range, it will cause weathered colors.<br />
<br />
{{Note|Some monitors/TVs support both color range. In that case an option often known as ''Black Level'' may need to be adjusted to make them handle the signal correctly. Some TVs can handle signal in limited range only. Setting Broadcast RGB to "Full" will cause color clipping. You may need to set it to "Limited 16:235" manually to avoid the clipping.}}<br />
<br />
One can force mode e.g. {{ic|xrandr --output <HDMI> --set "Broadcast RGB" "Full"}} (replace {{ic|<HDMI>}} with the appropriate output device, verify by running {{ic|xrandr}}).<br />
<br />
Unfortunately, the Intel driver does not support setting the color range through an {{ic|xorg.conf.d}} configuration file.<br />
<br />
A [https://bugzilla.kernel.org/show_bug.cgi?id=94921 bug report] is filed and a patch can be found in the attachment.<br />
<br />
Also there are other related problems which can be fixed editing GPU registers. More information can be found [http://lists.freedesktop.org/archives/intel-gfx/2012-April/016217.html] and [http://github.com/OpenELEC/OpenELEC.tv/commit/09109e9259eb051f34f771929b6a02635806404c].<br />
<br />
=== Backlight is not adjustable===<br />
<br />
If after resuming from suspend, the hotkeys for changing the screen brightness do not take effect, check your configuration against the [[Backlight]] article.<br />
<br />
If the problem persists, try one of the following [[kernel parameters]]:<br />
<br />
acpi_osi=Linux<br />
acpi_osi="!Windows 2012"<br />
acpi_osi=<br />
<br />
=== Corruption/Unresponsiveness in Chromium and Firefox ===<br />
<br />
If you experience corruption, unresponsiveness, lags or slow performance in Chromium and/or Firefox: <br />
* [[#SNA issues|Set the AccelMethod to "uxa"]]<br />
* [[#Disable Vertical Synchronization (VSYNC)|Disable VSYNC]]<br />
<br />
=== Kernel crashing w/kernels 4.0+ on Broadwell/Core-M chips ===<br />
<br />
A few seconds after X/Wayland loads the machine will freeze and journalctl will log a kernel crash referencing the Intel graphics as below:<br />
<br />
Jun 16 17:54:03 hostname kernel: BUG: unable to handle kernel NULL pointer dereference at (null)<br />
Jun 16 17:54:03 hostname kernel: IP: [< (null)>] (null)<br />
...<br />
Jun 16 17:54:03 hostname kernel: CPU: 0 PID: 733 Comm: gnome-shell Tainted: G U O 4.0.5-1-ARCH #1<br />
...<br />
Jun 16 17:54:03 hostname kernel: Call Trace:<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055cc27>] ? i915_gem_object_sync+0xe7/0x190 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0579634>] intel_execlists_submission+0x294/0x4c0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa05539fc>] i915_gem_do_execbuffer.isra.12+0xabc/0x1230 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa055d349>] ? i915_gem_object_set_to_cpu_domain+0xa9/0x1f0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ba2ae>] ? __kmalloc+0x2e/0x2a0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555471>] i915_gem_execbuffer2+0x141/0x2b0 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa042fcab>] drm_ioctl+0x1db/0x640 [drm]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffffa0555330>] ? i915_gem_execbuffer+0x450/0x450 [i915]<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8122339b>] ? eventfd_ctx_read+0x16b/0x200<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebc36>] do_vfs_ioctl+0x2c6/0x4d0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811f6452>] ? __fget+0x72/0xb0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff811ebec1>] SyS_ioctl+0x81/0xa0<br />
Jun 16 17:54:03 hostname kernel: [<ffffffff8157a589>] system_call_fastpath+0x12/0x17<br />
Jun 16 17:54:03 hostname kernel: Code: Bad RIP value.<br />
Jun 16 17:54:03 hostname kernel: RIP [< (null)>] (null)<br />
<br />
This can be fixed by disabling execlist support which was changed to default on with kernel 4.0. Add the following [[kernel parameter]]:<br />
i915.enable_execlists=0<br />
<br />
This is known to be broken to at least kernel 4.0.5.<br />
<br />
=== Lag in Windows guests ===<br />
<br />
The video output of a Windows guest in VirtualBox sometimes hangs until the host forces a screen update (e.g. by moving the mouse cursor). Removing the {{ic|1=enable_fbc=1}} option fixes this issue.<br />
<br />
=== Screen flickering ===<br />
<br />
Panel Self Refresh (PSR), a power saving feature used by Intel iGPUs is known to cause flickering in some instances {{Bug|49628}} {{Bug|49371}} {{Bug|50605}}. A temporary solution is to disable this feature using the [[kernel parameter]] {{ic|1=i915.enable_psr=0}}.<br />
<br />
=== OpenGL 2.1 with i915 driver ===<br />
<br />
The update of {{Pkg|mesa}} from version 13.x to 17 may break support for OpenGL 2.1 on third gen Intel GPUs (GMA3100, see [[wikipedia:List_of_Intel_graphics_processing_units#Third_generation|here]]), as described in this [http://www.phoronix.com/scan.php?page=news_item&px=Mesa-i915-OpenGL-2-Drop article], reverting it back to OpenGL 1.4. However this could be restored manually by setting {{ic|/etc/drirc}} or {{ic|~/.drirc}} options like:<br />
{{hc|/etc/drirc|output=<br />
<driconf><br />
...<br />
<device driver="i915"><br />
<application name="Default"><br />
<option name="'''stub_occlusion_query'''" value="'''true'''" /><br />
<option name="'''fragment_shader'''" value="'''true'''" /><br />
</application><br />
</device><br />
...<br />
</driconf><br />
}}<br />
{{Note|the reason of this step back was Chromium and other apps bad experience. If needed, you might edit the drirc file in a "app-specific" style, see [https://dri.freedesktop.org/wiki/ConfigurationInfrastructure/ here], to disable gl2.1 on executable chromium for instance.}}<br />
<br />
== See also ==<br />
<br />
* https://01.org/linuxgraphics/documentation (includes a list of supported hardware)</div>Sarenhttps://wiki.archlinux.org/index.php?title=AMD_Catalyst&diff=434777AMD Catalyst2016-05-12T19:41:25Z<p>Saren: Added link to Vi0L0's repository</p>
<hr />
<div>[[Category:Graphics]]<br />
[[Category:X server]]<br />
[[es:AMD Catalyst]]<br />
[[fr:ATI#Catalyst]]<br />
[[it:AMD Catalyst]]<br />
[[ja:AMD Catalyst]]<br />
[[ru:AMD Catalyst]]<br />
[[zh-CN:AMD Catalyst]]<br />
{{Related articles start}}<br />
{{Related|ATI}}<br />
{{Related|Xorg}}<br />
{{Related articles end}}<br />
<br />
Owners of ATI/AMD video cards have a choice between AMD's proprietary driver ({{AUR|catalyst}}) and the open source driver ([[ATI]] for older or [[AMDGPU]] for newer cards). This article covers the proprietary driver.<br />
<br />
AMD's Linux driver package ''catalyst'' was previously named ''fglrx'' ('''F'''ire'''GL''' and '''R'''adeon '''X'''). Only the package name has changed, while the kernel module retains its original ''fglrx.ko'' filename. Therefore, any mention of fglrx below is specifically in reference to the ''kernel module'', '''not the package'''.<br />
<br />
'''Catalyst packages are no longer offered in the official repositories.''' In the past, Catalyst [https://www.archlinux.org/news/ati-catalyst-support-dropped/ has been dropped] from official Arch support because of dissatisfaction with the quality and speed of development. After a brief return they were dropped again in April 2013 and they have not returned since.<br />
<br />
Compared with the open source driver, Catalyst performs better in both 2D and 3D rendering, also having better power management, but it lacks efficient multi-head support. Supported devices are [[wikipedia:Radeon|ATI/AMD Radeon]] video cards with chipset R600 and newer (Radeon HD 2xxx and newer). See the Xorg [http://www.x.org/wiki/RadeonFeature/#index5h2 decoder ring] or [[wikipedia:Comparison of AMD graphics processing units|this table]], to translate ''model'' names (X1900, HD4850) to/from ''chip'' names (R580, RV770 respectively).<br />
<br />
== Installation ==<br />
<br />
There are three ways of installing Catalyst on your system. One way is to use [https://aur.archlinux.org/account/Vi0l0/ Vi0L0's] (Arch's unofficial Catalyst maintainer) [https://wiki.archlinux.org/index.php/unofficial_user_repositories#catalyst repository]. This repository contains all the necessary packages. The second method you can use is the AUR; PKGBUILDs offered here are also made by Vi0L0 and are the same he uses to built packages for his repository. Lastly, you can install the driver directly from AMD.<br />
<br />
Before choosing the method you prefer, you will have to see which driver you need. Since Catalyst 12.4, AMD has separated its development for Radeon HD 2xxx, 3xxx and 4xxx cards into the '''legacy''' Catalyst driver. For Radeon HD 5xxx and newer, there is the regular Catalyst driver. Regardless of the driver you need, you will also need the Catalyst utilities.<br />
<br />
{{Note|After the instructions for every method of installing, you will find general instructions '''everyone''' has to perform, regardless of the method you used.}}<br />
<br />
=== Installing the driver ===<br />
<br />
==== Installing from the unofficial repository ====<br />
<br />
If you do not fancy building the packages from the [[AUR]], this is the way to go. The repository is maintained by our unofficial Catalyst maintainer, [[User:Vi0L0|Vi0l0]]. All packages are signed and are considered safe to use. As you will see later on in this article, Vi0L0 is also responsible for many other packages that will help you get your system working with your ATI graphic cards. <br />
<br />
Vi0L0 has three different Catalyst repositories, each having different drivers:<br />
* [[Unofficial user repositories#catalyst|catalyst]] for the regular Catalyst driver needed by Radeon HD 5xxx and up, it contains the latest (stable or beta) Catalyst release.<br />
* ''catalyst-stable'' for the regular Catalyst driver needed by Radeon HD 5xxx and up, with the latest stable driver.<br />
* [[Unofficial user repositories#catalyst-hd234k|catalyst-hd234k]] for the legacy Catalyst driver needed by Radeon HD 2xxx, 3xxx and 4xxx cards.<br />
<br />
To enable one of these, follow the instructions in [[Unofficial user repositories]]. Remember to add the chosen repository '''above all other repositories''' in {{ic|pacman.conf}}.<br />
<br />
{{Note|The ''catalyst'' and ''catalyst-stable'' repositories share the same URL. To enable ''catalyst-stable'', follow the instructions for enabling ''catalyst'' and replace {{ic|[catalyst]}} with {{ic|[catalyst-stable]}} in {{ic|pacman.conf}}. If you need to stick with an old version, there are also some versioned repositories using the same URL (for example ''catalyst-stable-13.4'').}}<br />
<br />
{{Tip|Because catalyst.wirephire.com will go down if a certain bandwidth limit is exceeded (this happened in the past) or may be too slow at your location, repository mirror is provided by goll at [http://mirror.hactar.bz/Vi0L0/] (DE). This mirror however come with no warranty and is not guaranteed to always be operational.<br />
}}<br />
<br />
Once you have added some Catalyst repository, update pacman's database and [[install]] these packages (see [[#Tools]] for more information):<br />
<br />
* ''catalyst-hook''<br />
* ''catalyst-utils''<br />
* ''catalyst-libgl''<br />
* ''opencl-catalyst'' - optional, needed for OpenCL support<br />
* ''lib32-catalyst-utils'' - optional, needed for 32-bit OpenGL support on 64-bit systems<br />
* ''lib32-catalyst-libgl'' - optional, needed for 32-bit OpenGL support on 64-bit systems<br />
* ''lib32-opencl-catalyst'' - optional, needed for 32-bit OpenCL support on 64-bit systems<br />
<br />
{{Note|If pacman asks you about removing '''libgl''' you can safely do so.}}<br />
<br />
{{Warning|catalyst package was removed from Vi0L0's repository, its place was taken by catalyst-hook.}}<br />
<br />
==== Installing from the AUR ====<br />
The second way to install Catalyst is from the [[AUR]]. If you want to build the packages specifically for your computer, this is the way to go. Note that this is also the most tedious way to install Catalyst; it requires the most work and also requires manual updates upon every kernel update.<br />
<br />
{{Warning|If you install the Catalyst package from the AUR, you will have to rebuild Catalyst every time the kernel is updated. Otherwise X '''will''' fail to start.}}<br />
<br />
All packages mentioned above in Vi0L0's unofficial repository are also available on the [[AUR]]:<br />
* {{AUR|catalyst}}<br />
* {{AUR|catalyst-generator}}<br />
* {{AUR|catalyst-hook}}<br />
* {{AUR|catalyst-utils}}<br />
* {{AUR|lib32-catalyst-utils}}<br />
<br />
The AUR also holds some packages that are '''not''' found in any of the repositories. These packages contain the so-called ''Catalyst-total'' packages and the beta versions:<br />
* {{AUR|catalyst-total}}<br />
* {{AUR|catalyst-total-hd234k}}<br />
* {{AUR|catalyst-test}}<br />
<br />
The {{AUR|catalyst-total}} packages are made to make the lives of AUR users easier. It builds the driver, the kernel utilities and the 32 bit kernel utilities. It also builds the {{AUR|catalyst-hook}} package, which is described in [[#Tools]].<br />
<br />
=== Configuring the driver ===<br />
After you have installed the driver via your chosen method, you will have to configure X to work with Catalyst. Also, you will have to make sure the module gets loaded at boot. Also, one should disable [[kernel mode setting]].<br />
<br />
==== Configuring X ====<br />
To configure X, you will have to create an {{ic|xorg.conf}} file. Catalyst provides its own {{ic|aticonfig}} tool to create and/or modify this file.<br />
It also can configure virtually every aspect of the card for it also accesses the {{ic|/etc/ati/amdpcsdb}} file. For a complete list of {{ic|aticonfig}} options, run:<br />
<br />
# aticonfig --help | less<br />
<br />
{{Warning|Use the {{ic|--output}} option before committing to {{ic|/etc/X11/}} as an {{ic|xorg.conf}} file will override anything in {{ic|/etc/X11/xorg.conf.d/}}}}<br />
<br />
{{Note|To adhere to the new config location use {{ic|# aticonfig [...] --output}} to adapt the {{ic|Device}} section to {{ic|/etc/X11/xorg.conf.d/20-radeon.conf}}. The drawback is that many {{ic|aticonfig}} options rely on an {{ic|xorg.conf}}, and will be unavailable.}}<br />
<br />
Now, to configure Catalyst. If you have only one monitor, run this:<br />
<br />
# aticonfig --initial<br />
<br />
However, if you have two monitors and want to use both of them, you can run the command stated below. Note that this will generate a dual head configuration with the second screen located above the first screen.<br />
<br />
# aticonfig --initial=dual-head --screen-layout=above<br />
<br />
{{Note|See [[#Double Screen (Dual Head / Dual Screen / Xinerama)]] for more information on setting up dual monitors.}}<br />
<br />
You can compare the generated file to one of the [[Xorg#Sample configurations|Sample Xorg.conf]] examples listed on the Xorg page.<br />
<br />
Although the current Xorg versions auto-detect most options when started, you may want to specify some in case the defaults change between versions.<br />
<br />
Here is an example (with notes) '''for reference'''. Entries with {{ic|#}} should be required, add entries with {{ic|##}} as needed:<br />
<br />
{{hc|/etc/X11/xorg.conf|2=<br />
Section "ServerLayout"<br />
Identifier "Arch"<br />
Screen 0 "Screen0" 0 0 # 0's are necessary.<br />
EndSection<br />
Section "Module"<br />
Load [...]<br />
[...]<br />
EndSection<br />
Section "Monitor"<br />
Identifier "Monitor0"<br />
[...]<br />
EndSection<br />
Section "Device"<br />
Identifier "Card0"<br />
Driver "fglrx" # Essential.<br />
BusID "PCI:1:0:0" # Recommended if autodetect fails.<br />
Option "OpenGLOverlay" "0" ##<br />
Option "XAANoOffscreenPixmaps" "false" ##<br />
EndSection<br />
Section "Screen"<br />
Identifier "Screen0"<br />
Device "Card0"<br />
Monitor "Monitor0"<br />
DefaultDepth 24<br />
SubSection "Display"<br />
Viewport 0 0<br />
Depth 24 # Should not change from '24'<br />
Modes "1280x1024" "2048x1536" ## 1st value=default resolution, 2nd=maximum.<br />
Virtual 1664 1200 ## (x+64, y) to workaround potential OGL rect. artifacts/<br />
EndSubSection ## fixed in Catalyst 9.8<br />
EndSection<br />
Section "DRI"<br />
Mode 0666 # May help enable direct rendering.<br />
EndSection<br />
}}<br />
<br />
{{Note|With '''every''' Catalyst update you should remove {{ic|amdpcsdb}} file in this way: kill X, remove {{ic|/etc/ati/amdpcsdb}}, start X and then run {{ic|amdcccle}} - otherwise the version of Catalyst may display wrongly in {{ic|amdcccle}}.}}<br />
<br />
''If you need more information on Catalyst, visit [https://bbs.archlinux.org/viewtopic.php?id=57084 this thread].''<br />
<br />
==== Loading the module at boot ====<br />
We have to blacklist the {{ic|radeon}} module to prevent it from auto-loading. To do so, blacklist ''radeon'' in {{ic|/etc/modprobe.d/modprobe.conf}}. Also, make sure that it is not loaded by any file under {{ic|/etc/modules-load.d/}}. For more information, see [[kernel modules#Blacklisting]]. <br />
<br />
Then we will have to make sure that the {{ic|fglrx}} module gets auto-loaded. Either add {{ic|fglrx}} on a new line of an existing module file located under {{ic|/etc/modules-load.d/}}, or create a new file and add {{ic|fglrx}}.<br />
<br />
==== Disable kernel mode setting ====<br />
<br />
{{Note|Do not do this if you are using powerXpress technology (or hybrid AMD-Intel graphics) because Intel driver needs it.}}<br />
<br />
Disabling kernel mode setting is important, as the Catalyst driver does not take advantage of [[KMS]]. If you do not deactivate KMS, your system might freeze when trying to switch to a TTY or even when shutting down via your DE.<br />
<br />
To disable kernel mode setting, add {{ic|nomodeset}} to your [[kernel parameters]].<br />
<br />
==== Checking operation ====<br />
<br />
Assuming that a reboot to your login was successful, you can check if {{ic|fglrx}} is running properly with the following commands:<br />
<br />
$ lsmod | grep fglrx<br />
<br />
If you get output, it works. Finally, run X manually with {{ic|$ startx}} or by using a display manager (see [[Xorg#Running]]).<br />
<br />
The following command should output your graphic card model name:<br />
<br />
$ fglrxinfo<br />
<br />
You can then verify that direct rendering is enabled by running the following command in a terminal:<br />
<br />
$ glxinfo | grep "direct rendering"<br />
<br />
If it says {{ic|"direct rendering: yes"}} then you are good to go! If the {{ic|$ glxinfo}} command is not found install the {{Pkg|mesa-demos}} package.<br />
<br />
{{Note|You can also use:<br />
$ fgl_glxgears<br />
as the fglrx alternative test to {{ic|glxgears}}.<br />
}}<br />
<br />
{{Warning|In recent versions of Xorg, the paths of libs are changed. So, sometimes {{ic|libGL.so}} cannot be correctly loaded even if it is installed. Check this if your GL is not working. Please read [[#Troubleshooting]] section for details.}}<br />
<br />
=== Custom kernels ===<br />
<br />
{{Note|If you are at all uncomfortable or inexperienced with making packages, read up the [[ABS]] wiki page first so things go smoothly.}}<br />
<br />
To install catalyst for a custom kernel, you will need to build your own {{ic|catalyst-$kernel}} package:<br />
<br />
# Obtain the {{ic|PKGBUILD}} and {{ic|catalyst.install}} files from [[AUR|Catalyst]].<br />
# Editing the PKGBUILD. Two changes need to be made here:<br />
## Change {{ic|1=pkgname=catalyst}} to {{ic|1=pkgname=catalyst-$kernel_name}}, where {{ic|$kernel_name}} is whatever you want (e.g. custom, mm, themostawesomekernelever).<br />
## Change the dependency of {{ic|linux}} to {{ic|$kernel_name}}.<br />
# Build your package and install; run {{ic|makepkg -i}} or {{ic|makepkg}} followed by {{ic|# pacman -U pkgname.pkg.tar.gz}}<br />
<br />
{{Note|<br />
*If you run multiple kernels, you have to install the {{AUR|catalyst-utils}} packages for all kernels. They will not conflict with one another.<br />
*{{AUR|catalyst-generator}} is able to build {{ic|<nowiki>catalyst-{kernver}</nowiki>}} packages for you so you do not actually need to perform all those steps manually. For more information, see [[#Tools|Tools section]].}}<br />
<br />
=== PowerXpress support ===<br />
<br />
PowerXpress technology allows switching notebooks with dual-graphic capability from integrated graphics (IGP) to discrete graphics either to increase battery life or to achieve better 3D rendering capabilities.<br />
<br />
To use such functionality on Arch you will have to:<br />
* Get and build {{AUR|catalyst-total}} / {{AUR|catalyst-test}} package from the [[AUR]], or<br />
* Install '''catalyst-libgl''' alongside with '''catalyst-utils''' packages from the [catalyst] repository.<br />
<br />
To perform a switch into Intel's IGP you will also have to install the {{pkg|mesa}} package and Intel's drivers: {{pkg|xf86-video-intel}}.<br />
<br />
{{Note|Catalyst sometimes has problems with newest intel drivers. If this is happening please downgrade {{pkg|xf86-video-intel}} to the previous version found on [[Arch Linux Archive]] or maybe even from archive [[#Xorg repositories]] alongside with xorg-server package(s).}}<br />
<br />
Now you can switch between the integrated and the discrete GPU, using these commands:<br />
<br />
{{bc|1=<br />
# aticonfig --px-igpu #for integrated GPU<br />
# aticonfig --px-dgpu #for discrete GPU<br />
}}<br />
<br />
Just remember that fglrx needs {{ic|/etc/X11/xorg.conf}} configured for AMD's card with {{ic|fglrx}} inside.<br />
<br />
You can also use the {{ic|pxp_switch_catalyst}} switching script that will perform some additional usefull operations:<br />
* Switching {{ic|xorg.conf}} - it will rename {{ic|xorg.conf}} into {{ic|xorg.conf.cat}} (if there is fglrx inside) or {{ic|xorg.conf.oth}} (if there is intel inside) and then it will create a symlink to {{ic|xorg.conf}}, depending on what you chose.<br />
* Running {{ic|aticonfig --px-Xgpu}}.<br />
* Running {{ic|switchlibGL}}.<br />
* Adding/removing {{ic|fglrx}} into/from {{ic|/etc/modules-load.d/catalyst.conf}}.<br />
<br />
Usage:<br />
{{bc|1=<br />
# pxp_switch_catalyst amd<br />
# pxp_switch_catalyst intel<br />
}}<br />
<br />
If you have got problems when you try to run X on Intel's driver you may try to force "UXA" acceleration. Just make sure you got {{ic|Option "AccelMethod" "uxa"}} in {{ic|xorg.conf}}:<br />
{{hc|/etc/X11/xorg.conf|2=<br />
Section "Device"<br />
Identifier "Intel Graphics"<br />
Driver "intel"<br />
#Option "AccelMethod" "sna"<br />
'''Option "AccelMethod" "uxa"'''<br />
#Option "AccelMethod" "xaa"<br />
EndSection<br />
}}<br />
<br />
==== Running two X servers (one using the Intel driver, another one using fglrx) simultaneously ====<br />
Because fglrx is crash-prone (regarding PowerXpress), it could be a good idea to use the Intel driver in the main X server and have a secondary X server using fglrx when 3D acceleration is needed. However, simply switching to the discrete GPU from the integrated GPU using {{ic|aticonfig}} or {{ic|amdcccle}} will cause all sorts of weird bugs when starting the second X.<br />
<br />
To run two X servers at the same time (each using different drivers), you should firstly set up a fully working X with Catalyst and then move its {{ic|xorg.conf}} to a temporary place (for example, {{ic|/etc/X11/xorg.conf.fglrx}}. The next time X is started, it will use the Intel driver by default instead of fglrx.<br />
<br />
To start a second X server using fglrx, simply move {{ic|xorg.conf}} back to the proper place ({{ic|/etc/X11/xorg.conf}}) before starting X. This method even allows you to switch between running X sessions. When you are done using fglrx, move {{ic|xorg.conf}} somewhere else again.<br />
<br />
The only disadvantage of this method is not having 3D acceleration using the Intel driver. 2D acceleration, however, is fully functional. Other than that, this will provide us with a completely stable desktop.<br />
<br />
==== Issues with PowerXpress laptops running in AMD mode (pxp_switch_catalyst amd) with external / secondary monitor ====<br />
When using a PowerXpress laptop in AMD-only mode (ie, setting the discrete card to render everything) you sometimes run into issues with artifacting/duplicating between displays. This is a known issue, and seems to effect 7xxxM series cards.<br />
<br />
The artifacting disappears when you transform one of the monitors by either rotating or scaling. So you can use xrandr to fix this:<br />
<br />
{{bc|1=<br />
xrandr --output HDMI1 --left-of LVDS1 --primary --scale 1x1 --output LVDS1 --scale 1.0001x1.0001<br />
}}<br />
<br />
== Xorg repositories ==<br />
Catalyst is notorious for its slow update process. As such, it is common that a new Xorg version is pushed down from upstream that will break compatibility for Catalyst. This means that Catalyst users either have to build Xorg packages on their own, or use a backported repository that only contains the Xorg packages that should be hold back. Vi0L0 has stepped in to fulfil this task and provides several backported repositories. <br />
<br />
To enable one of these, follow the instructions in [[Unofficial user repositories]] (use the same PGP key as for the [[Unofficial user repositories#catalyst|catalyst]] repository). Remember to add the chosen repository '''above all other repositories''' in {{ic|pacman.conf}}, even above your ''catalyst'' repository, should you use one.<br />
<br />
=== xorg117 ===<br />
Catalyst does not support xorg-server 1.18<br />
{{bc|<nowiki><br />
[xorg117]<br />
Server = http://catalyst.wirephire.com/repo/xorg117/$arch<br />
## Mirrors, if the primary server does not work or is too slow:<br />
#Server = http://mirror.hactar.bz/Vi0L0/xorg117/$arch<br />
</nowiki>}}<br />
<br />
=== xorg116 ===<br />
Catalyst < 15.7 does not support xorg-server 1.17<br />
{{bc|<nowiki><br />
[xorg116]<br />
Server = http://catalyst.wirephire.com/repo/xorg116/$arch<br />
## Mirrors, if the primary server does not work or is too slow:<br />
#Server = http://mirror.hactar.bz/Vi0L0/xorg116/$arch<br />
</nowiki>}}<br />
<br />
=== xorg115 ===<br />
Catalyst < 14.9 does not support xorg-server 1.16<br />
<br />
{{bc|<nowiki><br />
[xorg115]<br />
Server = http://catalyst.wirephire.com/repo/xorg115/$arch<br />
## Mirrors, if the primary server does not work or is too slow:<br />
#Server = http://mirror.hactar.bz/Vi0L0/xorg115/$arch<br />
</nowiki>}}<br />
<br />
=== xorg114 ===<br />
Catalyst < 14.1 does not support xorg-server 1.15.<br />
<br />
{{bc|<nowiki><br />
[xorg114]<br />
Server = http://catalyst.wirephire.com/repo/xorg114/$arch<br />
## Mirrors, if the primary server does not work or is too slow:<br />
#Server = http://mirror.hactar.bz/Vi0L0/xorg114/$arch<br />
</nowiki>}}<br />
<br />
=== xorg113 ===<br />
Catalyst < 13.6 does not support xorg-server 1.14.<br />
<br />
{{bc|<nowiki><br />
[xorg113]<br />
Server = http://catalyst.wirephire.com/repo/xorg113/$arch<br />
## Mirrors, if the primary server does not work or is too slow:<br />
#Server = http://mirror.hactar.bz/Vi0L0/xorg113/$arch<br />
</nowiki>}}<br />
<br />
=== xorg112 ===<br />
Catalyst < 12.10 and Catalyst Legacy do not support xorg-server 1.13.<br />
<br />
{{bc|<nowiki><br />
[xorg112]<br />
Server = http://catalyst.wirephire.com/repo/xorg112/$arch<br />
## Mirrors, if the primary server does not work or is too slow:<br />
#Server = http://mirror.hactar.bz/Vi0L0/xorg112/$arch<br />
</nowiki>}}<br />
<br />
== Tools ==<br />
<br />
=== Catalyst-hook ===<br />
{{AUR|Catalyst-hook}} is a [[systemd]] service that will automatically rebuild the {{ic|fglrx}} modules while the system shuts down or reboots, but only if it is necessary (e.g. after an update).<br />
<br />
Before using this package make sure that both the {{Grp|base-devel}} group and the {{Pkg|linux-headers}} package (the one specific to the kernel you use) are installed.<br />
<br />
To enable the automatic update, enable the {{ic|catalyst-hook.service}}:<br />
<br />
# systemctl enable catalyst-hook<br />
# systemctl start catalyst-hook<br />
<br />
You can also use this package to build the {{ic|fglrx}} module manually. Simply run the {{ic|catalyst_build_module}} script after the kernel has been updated:<br />
<br />
# catalyst_build_module all<br />
<br />
'''A few more technical details:'''<br />
<br />
The {{ic|catalyst-hook.service}} is stopping the systemd "river" and is forcing systemd to wait until catalyst-hook finishes its job.<br />
<br />
The {{ic|catalyst-hook.service}} is calling the {{ic|catalyst_build_module check}} function which checks if fglrx rebuilds are really necessary.<br />
<br />
The {{ic|check}} function is checking if the {{ic|fglrx}} module exists, if it:<br />
<br />
*does not exist, it will build it;<br />
<br />
*does exist, it will compare the two values to be sure that a rebuild is necessary.<br />
<br />
These values are md5sums of the {{ic|/usr/lib/modules/<kernel_version>/build/Module.symvers}} file (because I, Vi0L0, noticed that this file is unique and different for every kernel's release). The first value is the md5sum of the existing {{ic|Module.symvers}} file. The second value is the md5sum of the {{ic|Module.symvers}} file which existed in a moment of the {{ic|fglrx}} module creation. This value was compiled into the {{ic|fglrx}} module by a {{ic|catalyst_build_module}} script.<br />
<br />
If the values are different, it will compile the new {{ic|fglrx}} module.<br />
<br />
The check is checking the whole {{ic|/usr/lib/modules/}} directory and building modules for all of the installed kernels if it is necessary. If the build or rebuild is not necessary, the whole process takes only some milliseconds to complete before it gets killed by systemd.<br />
<br />
=== Catalyst-generator ===<br />
<br />
{{AUR|catalyst-generator}} is a package that is able to build and install the {{ic|fglrx}} module packed into pacman compliant {{ic|<nowiki>catalyst-${kernver}</nowiki>}} packages. The basic difference from [[#Catalyst-hook]] is that you will have to trigger this command manually, whereas Catalyst-hook will do this automatically at boot when a new kernel got installed.<br />
<br />
It creates {{ic|<nowiki>catalyst-${kernver}</nowiki>}} packages using [[makepkg]] and installs them with [[pacman]]. {{ic|<nowiki>${kernver}</nowiki>}} is the kernel version for which each package was built (e.g. catalyst-2.6.35-ARCH package was built for 2.6.35-ARCH kernel).<br />
<br />
To build and install {{ic|<nowiki>catalyst-${kernver}</nowiki>}} package for a currently booted kernel as an unprivileged user (non-root; safer way), use {{ic|catalyst_build_module}}. You will be asked for your root password to proceed to package installation.<br />
<br />
A short summary on how to use this package:<br />
<br />
# As root: {{ic|catalyst_build_module remove}}. This will remove all unused {{ic|<nowiki>catalyst-{kernver}</nowiki>}} packages.<br />
# As unprivileged user: {{ic|<nowiki>catalyst_build_module ${kernver}</nowiki>}}, where {{ic|<nowiki>${kernver}</nowiki>}} is the version of the kernel to which you just updated. For example: {{ic|catalyst_build_module 2.6.36-ARCH}}. You can also build {{ic|<nowiki>catalyst-{kernver}</nowiki>}} for all installed kernels by using {{ic|catalyst_build_module all}}.<br />
# If you want to remove {{ic|catalyst-generator}}, it is best to run this as root before removing catalyst-generator: {{ic|catalyst_build_module remove_all}}. '''This will remove all {{ic|<nowiki>catalyst-{kernver}</nowiki>}} packages from the system.'''<br />
<br />
{{ic|Catalyst-generator}} is not able to remove all those {{ic|<nowiki>catalyst-{kernver}</nowiki>}} packages automatically while being removed because there can not be more than one instance of pacman running. If you forget to run {{ic|# catalyst_build_module remove_all}} before using {{ic|# pacman -R catalyst-generator}} catalyst-generator will tell you which {{ic|<nowiki>catalyst-{kernver}</nowiki>}} packages you will have to remove manually after removing catalyst-generator itself.<br />
<br />
Catalyst-generator is most safe and KISS-friendly solution because:<br />
<br />
# you can use unprivileged user to build the package;<br />
# it is building modules in a fakeroot environment;<br />
# it is not throwing files here and there, [[pacman]] always knows where they are;<br />
# all you have to do is to remember to use it<br />
<br />
{{Note|If you see those warnings:<br />
<br />
'''WARNING:''' Package contains reference to $srcdir<br />
<br />
'''WARNING:''' '.pkg' is not a valid archive extension.<br />
<br />
while building {{ic|<nowiki>catalyst-{kernver}</nowiki>}} package, do not be concerned, it is normal.}}<br />
<br />
=== OpenCL and OpenGL development ===<br />
<br />
Since years AMD is working on tools for OpenCL and OpenGL developement.<br />
<br />
Now under the banner of '''"Heterogeneous Computing"''' AMD is providing even more of them, fortunately most of their computing tools are available also for Linux.<br />
<br />
In the AUR and the [catalyst] repositories you will find packages that represent the most important work from AMD, namely:<br />
<br />
* {{AUR|amdapp-aparapi}}<br />
* {{AUR|amdapp-sdk}}<br />
* {{AUR|amdapp-codexl}}<br />
<br />
APP shortcut stands for Accelerated Parallel Processing.<br />
<br />
==== amdapp-aparapi ====<br />
AMD's Aparapi is an API for expressing data parallel workloads in Java and a runtime component capable of converting the Java bytecode of compatible workloads into OpenCL so that it can be executed on a variety of GPU devices. If Aparapi can’t execute on the GPU, it will execute in a Java thread pool.<br />
<br />
You can find more information about Aparapi [http://developer.amd.com/tools/heterogeneous-computing/aparapi/ here].<br />
<br />
==== amdapp-sdk (formerly known as amdstream) ====<br />
The AMD APP Software Development Kit (SDK) is a complete development platform created by AMD to allow you to quickly and easily develop applications accelerated by AMD APP technology. The SDK provides samples, documentation and other materials to quickly get you started leveraging accelerated compute using OpenCL, Bolt, or C++ AMP in your C/C++ application.<br />
<br />
Since version 2.8 amdapp-sdk is providing aparapiUtil as well as aparapi's samples. A package is available on the [catalyst] repository; it depends on the {{AUR|amdapp-aparapi}} package. The AUR's package will let you decide whether you want aparapi's additions or not.<br />
<br />
Version 2.8 does not provide Profiler functionality, it has been moved to CodeXL.<br />
<br />
You can find more information about AMD APP SDK [http://developer.amd.com/tools/heterogeneous-computing/amd-accelerated-parallel-processing-app-sdk/ here].<br />
<br />
==== amdapp-codexl ====<br />
CodeXL is an OpenCL and OpenGL Debugger and Profiler, with a static OpenCL kernel analyzer. It is a GUI application written atop of the well known {{AUR|gdebugger}}{{Broken package link|{{aur-mirror|gdebugger}}}} and is available only for x86_64 systems.<br />
<br />
You can find more informations about CodeXL [http://developer.amd.com/tools/heterogeneous-computing/codexl/ here].<br />
<br />
== Features ==<br />
<br />
=== Tear Free Rendering ===<br />
<br />
Presented in '''Catalyst 11.1''', the ''Tear Free Desktop'' feature reduces tearing in 2D, 3D and video applications. This likely adds triple-buffering and v-sync. Do note that it requires additional GPU processing.<br />
<br />
To enable 'Tear Free Desktop' run {{ic|amdcccle}} and go to: {{ic|Display Options}} → {{ic|Tear Free}}.<br />
<br />
Or run:<br />
<br />
# aticonfig --set-pcs-u32=DDX,EnableTearFreeDesktop,1<br />
<br />
To disable, again use {{ic|amdcccle}} or run:<br />
<br />
# aticonfig --del-pcs-key=DDX,EnableTearFreeDesktop<br />
<br />
=== Video acceleration ===<br />
<br />
'''[[wikipedia:Video_Acceleration_API|Video Acceleration API]] (VA API)''' is an open source software library (libVA) and API specification which provides GPU acceleration for video processing on Linux/UNIX based operating systems. The process works by enabling hardware accelerated video decode at various entry-points (VLD, IDCT, Motion Compensation, deblocking) for common encoding standards (MPEG-2, MPEG-4 ASP/H.263, MPEG-4 AVC/H.264, and VC-1/WMV3).<br />
<br />
VA-API gained a proprietary backend (in November 2009) called {{AUR|xvba-video}}{{Broken package link|{{aur-mirror|xvba-video}}}}, that allows VA-API programmed applications to take advantage of AMD Radeons UVD2 chipsets via the [[wikipedia:XvBA|XvBA (X-Video Bitstream Acceleration API designed by AMD)]] library.<br />
<br />
{{Note|No need to install the {{AUR|xvba-video}}{{Broken package link|{{aur-mirror|xvba-video}}}} package when using {{ic|catalyst-test}} or {{ic|catalyst-total}}, because a symlink is being used instead.}}<br />
XvBA support and xvba-video is still under development, however it is '''working very well in most cases'''. Build (or install from Vi0L0's repo) the proprietary {{AUR|xvba-video}}{{Broken package link|{{aur-mirror|xvba-video}}}} package, or if you have problems with that version, install {{AUR|libva-xvba-driver}}; and also install {{AUR|mplayer-vaapi}} and {{Pkg|libva}}. Then just set your video player to use vaapi:gl as video output:<br />
<br />
$ mplayer -vo vaapi:gl movie.avi<br />
<br />
These options can be added to your mplayer configuration file, see [[MPlayer]].<br />
<br />
For '''smplayer''':<br />
<br />
Options → Preferences → General → Video (tab) → Output driver: User Defined : vaapi:gl<br />
Options → Preferences → General → Video (tab) → Double buffering '''on'''<br />
Options → Preferences → General → General → Screenshots → Turn screenshots '''off'''<br />
Options → Preferences → Performance → Threads for decoding: '''1''' (to turn off -lavdopts parameter)<br />
<br />
{{Note|If Tear Free Desktop is enabled it is better to use:<br />
Options → Preferences → General → Video (tab) → Output driver: vaapi<br />
If Video Output '''vaapi:gl''' is not working - please check:<br />
'''vaapi''', '''vaapi:gl2''' or simply '''xv(0 - AMD Radeon [[wikipedia:Avivo|AVIVO Video]])'''.<br />
}}<br />
<br />
For '''VLC''':<br />
<br />
Tools → Preferences → Input & Codecs → Use GPU accelerated decoding<br />
<br />
It might help to enable v-sync in '''amdcccle''':<br />
<br />
3D → More Settings → Wait for vertical refresh = Always On<br />
<br />
{{Note|If you are using '''Compiz/KWin''', the only way to '''avoid video flickering''' is to watch videos in '''full-screen''' and only when '''Unredirect Fullscreen is off'''.<br />
<br />
In '''compiz''' you need to set '''Redirected Direct Rendering''' in General Options of ccsm. If it is still flickering, try to disable this option in CCSM. It is off by default in '''KWin''', but if you see flickering try to turn "Suspend desktop effects for fullscreen windows" on or off in {{ic|System Settings}} → {{ic|Desktop Effects}} → {{ic|Advanced}}.}}<br />
<br />
=== GPU/Mem frequency, Temperature, Fan speed, Overclocking utilities ===<br />
<br />
You can get the GPU/Mem clocks with: {{ic|$ aticonfig --od-getclocks}}.<br />
<br />
You can get the fan speed with: {{ic|$ aticonfig --pplib-cmd "get fanspeed 0"}}<br />
<br />
You can get the temperature with: {{ic|$ aticonfig --odgt}}<br />
<br />
To set the fanspeed with: {{ic|$ aticonfig --pplib-cmd "set fanspeed 0 50"}} Query Index: 50, Speed in percent<br />
<br />
To overclock and/or underclock it is easier to use a GUI, like '''ATi Overclocking Utility''', which is very simple and requires qt to work. It might be out of date/old, but you can get it [http://kde-apps.org/content/show.php/ATI+Overclock?content=47796 here].<br />
<br />
Another, more complex utility to perform such operations is '''AMDOverdriveCtrl'''. Its homepage is [http://sourceforge.net/projects/amdovdrvctrl here] and you can build {{AUR|amdoverdrivectrl}} from the AUR or from Vi0L0's unofficial repositories.<br />
<br />
=== Double Screen (Dual Head / Dual Screen / Xinerama) ===<br />
<br />
==== Introduction ====<br />
<br />
{{Warning| you should know that there is not one specific solution because each setup differs and needs its own configuration. That is why you will have to adapt the steps below to your own needs. It is possible that you have to try more than once. Therefore, you should save your working {{ic|/etc/X11/xorg.conf}} '''before''' you start modifying and be able to recover from a command-line environment.}}<br />
<br />
* In this chapter, we will describe the installation of two different-sized screens on only one graphics card with two different output ports (DVI + HDMI) using a "BIG Desktop" configuration.<br />
<br />
* The Xinerama solution has some inconveniences, especially because it is not compatible with XrandR. For that very reason, you should not use this solution, because XrandR is a must for our later configuration.<br />
<br />
* The Dual Head solution would allow you to have 2 different sessions (one for each screen). It could be what you want, but you will not be able to move windows from one screen to another. If you have only one screen, you will have to define the mouse inside your Xorg session for each of the two sessions inside the Server Layout section.<br />
<br />
[http://support.amd.com/us/kbarticles/Pages/1105-HowCanIConfigureMultip.aspx ATI Documentation]<br />
<br />
==== ATI Catalyst Control Center ====<br />
<br />
The GUI tool shipped by ATI is very useful and we will try to use it as much as we can. To launch it, open a terminal and use the following command:<br />
<br />
$ {kdesu/gksu} amdcccle<br />
<br />
{{Warning|Do '''not''' use sudo directly with a GUI. Sudo gives you admin rights with user account information. Instead, use ''gksu'' (GNOME) or ''kdesu'' (KDE).}}<br />
<br />
==== Installation ====<br />
<br />
Before we start, make sure that your hardware is plugged in correctly, that power is on and that you know your hardware characteristics (screen dimensions, sizes, refreshment rates, etc.) Normally, both screens are recognized during boot time but not necessarily identified properly, especially if you are not using any Xorg base configuration file ({{ic|/etc/X11/xorg.conf}}) but relying on the hot-plugging feature.<br />
<br />
The first step is to make sure that you screens will be recognized by your DE and by X. For this, you need to generate a basic Xorg configuration file for your two screens:<br />
<br />
# aticonfig --initial --desktop-setup=horizontal --overlay-on=1<br />
<br />
or<br />
<br />
# aticonfig --initial=dual-head --screen-layout=left<br />
<br />
{{Note|{{ic|overlay}} is important because it allows you to have 1 pixel (or more) shared between the 2 screens.}}<br />
{{Tip|For the other possible and available options, do not hesitate to type {{ic|aticonfig --help}} inside a terminal to display all available command lines.}}<br />
<br />
Now you should have a basic Xorg configuration file that you can edit to add your screen resolutions. It is important to use the precise resolution, especially if you have screens of different sizes. These resolutions have to be added in the "Screen" section:<br />
<br />
SubSection "Display"<br />
Depth 24<br />
Modes "X-resolution screen 1xY-resolution screen 1" "Xresolution screen 2xY-resolution screen 2"<br />
EndSubSection<br />
<br />
From now on, instead of editing the {{ic|xorg.conf}} file manually, let us use the ATI GUI tool. Restart X to be sure that your two screens are properly supported and that the resolutions are properly recognized (Screens must be independent, not mirrored).<br />
<br />
==== Configuration ====<br />
<br />
Now you will only have to launch the ATI control center with root privileges, go to the display menu and choose how you would like to set your configuration (small arrow of the drop down menu). A last restart of X and you should be done!<br />
<br />
Before you restart X, do not hesitate to verify your new {{ic|xorg.conf}} file. At this stage, inside the "Display" sub-section of the "Screen" section, you should see a "Virtual" command line, of which the resolution should be the sum of both screens. The "Server Layout" section says all the rest.<br />
<br />
== Uninstallation ==<br />
<br />
If for any reason this driver is not working for you or if you simply want to try out the open source driver, remove the {{ic|catalyst}} and {{ic|catalyst-utils}} packages. Also you should remove {{AUR|catalyst-generator}}, {{AUR|catalyst-hook}} and {{AUR|lib32-catalyst-utils}} packages if they have been installed on your system.<br />
<br />
{{Warning|<br />
*You may need to use {{ic|# pacman -Rdd}} to remove {{AUR|catalyst-utils}} (and/or {{AUR|lib32-catalyst-utils}}) because that package contains ''gl'' related files and many of your installed packages depend on them. These dependencies will be satisfied again when you install {{Pkg|xf86-video-ati}}.<br />
*You may need to remove {{ic|/etc/profile.d/ati-flgrx.sh}} and {{ic|/etc/profile.d/lib32-catalyst}} (if it exists on your system), otherwise {{ic|r600_dri.so}} will fail to load and you would not have 3D support.}}<br />
<br />
{{Note|You should remove unofficial repositories from your {{ic|/etc/pacman.conf}} and run {{ic|# pacman -Syu}}, because those repositories include out-dated Xorg packages to allow use of {{ic|catalyst}} and the {{Pkg|xf86-video-ati}} package needs up-to-date Xorg packages from the [[Official repositories]].}}<br />
<br />
Also follow these steps:<br />
<br />
* If you have the {{ic|/etc/modprobe.d/blacklist-radeon.conf}} file remove it or comment the line {{ic|blacklist radeon}} in that file.<br />
* If you have a file in {{ic|/etc/modules-load.d}} to load the {{ic|fglrx}} module on boot, remove it or comment the line containing {{ic|fglrx}}.<br />
* Make sure to remove or backup {{ic|/etc/X11/xorg.conf}}.<br />
* If you have installed the {{AUR|catalyst-hook}} package, make sure to disable the systemd service.<br />
* If you used the {{ic|nomodeset}} option in your [[kernel parameters]] and plan to use KMS, remove it.<br />
* '''Reboot''' before installing another driver.<br />
<br />
== Troubleshooting ==<br />
<br />
If you can still boot to command-line, then the problem probably lies in {{ic|/etc/X11/xorg.conf}}<br />
<br />
You can parse the whole {{ic|/var/log/Xorg.0.log}} or, for clues:<br />
<br />
$ grep '(EE)' /var/log/Xorg.0.log<br />
$ grep '(WW)' /var/log/Xorg.0.log<br />
<br />
If you are still confused about what is going on, search the forums first. Then post a message in the [https://bbs.archlinux.org/viewtopic.php?pid=1166052#p1166052/ thread specific to ATI/AMD]. Provide the information from {{ic|xorg.conf}} and both commands mentioned above.<br />
<br />
=== Failed to start atieventsd.service ===<br />
Install {{Pkg|acpid}} from the [[official repositories]]. Start and enable the acpid [[Daemon|service]].<br />
<br />
If the service still fails to start, edit {{ic|/usr/lib/systemd/system/atieventsd.service}} and change {{ic|acpid.socket}} to {{ic|acpid.service}}.<br />
<br />
=== Failed to open fglrx_dri.so ===<br />
Create a symlink from {{ic|/usr/lib/xorg/modules/dri/fglrx_dri.so}} to {{ic|/usr/X11R6/lib64/modules/dri/fglrx_dri.so}} (or other requested path)<br />
<br />
# mkdir -p /usr/X11R6/lib64/modules/dri<br />
# ln -s /usr/lib/xorg/modules/dri/fglrx_dri.so /usr/X11R6/lib64/modules/dri/fglrx_dri.so<br />
<br />
=== GDM fails to start ===<br />
Downgrade the {{pkg|xorg-server}} package or try to use another [[display manager]] like [[LightDM]].<br />
<br />
=== 3D Wine applications freeze ===<br />
If you use a 3D Wine application and it hangs, you have to disable TLS. To do this, either use {{ic|aticonfig}} or edit {{ic|/etc/X11/xorg.conf}}. To use {{ic|aticonfig}}:<br />
<br />
# aticonfig --tls=off<br />
<br />
Or, to edit {{ic|/etc/X11/xorg.conf}}; first open the file in an editor as root and then add {{ic|Option "UseFastTLS" "off"}} to the ''Device'' section of this file. <br />
<br />
After applying either of the solutions, restart X for it to take effect.<br />
<br />
=== Problems with video colours ===<br />
<br />
You may still use {{ic|vaapi:gl}} to avoid video flickering, but without video acceleration:<br />
<br />
* Run '''mplayer''' without {{ic|-vo vaapi}} switch.<br />
<br />
* Run '''smplayer''' remove {{ic|-vo vaapi}} from Options → Preferences → Advanced → Options for MPlayer → Options: -vo vaapi<br />
<br />
Plus for '''smplayer''' you may now safely turn screenshots on.<br />
<br />
=== KWin and composite ===<br />
<br />
You may use XRender if the rendering with OpenGL is slow. However, XRender might also be slower than OpenGL depending on your card.<br />
XRender also solves artefact issues in some cases, for instance when resizing Konsole.<br />
<br />
=== Black screen with complete lockups and/or hangs after reboot or startx ===<br />
<br />
Ensure you have added the {{ic|nomodeset}} option to the kernel options line in your bootloader (see [[#Disable kernel mode setting]]). Make sure that Catalyst is compatible with your installed Xorg version and used Linux kernel version.<br />
<br />
If you are using the legacy driver ({{ic|catalyst-hd234k}}) and get a black screen, try downgrading xorg-server to 1.12 by using the [[#xorg112]] repository.<br />
<br />
==== Faulty ACPI hardware calls ====<br />
<br />
It is possible that fglrx does not cooperate well with the system's ACPI hardware calls, so it auto-disables itself and there is no screen output.<br />
<br />
If so, try to run this:<br />
<br />
$ aticonfig --acpi-services=off<br />
<br />
=== KDM disappears after logout ===<br />
<br />
If you are running Catalyst proprietary driver and you get a console (tty1) instead of the expected KDM greeting when you log out, you must instruct KDM to restart the X server after each logout. Uncomment the following line under the section titled {{ic|[X-:*-Core]}}<br />
<br />
{{hc|/usr/share/config/kdm/kdmrc|2=<br />
TerminateServer=True<br />
}}<br />
<br />
KDM should now appear when you log out of KDE.<br />
<br />
=== Direct Rendering does not work ===<br />
<br />
This problem may occur when using the proprietary '''Catalyst''' driver.<br />
<br />
{{Warning|This error would also appear if you have not '''rebooted''' your system after the installation or upgrade of catalyst. The system needs to load the fglrx.ko module in order to make the driver work.}}<br />
<br />
If you have problem with direct rendering, run:<br />
<br />
$ LIBGL_DEBUG=verbose glxinfo > /dev/null<br />
<br />
at the command prompt. At the very start of the output, it will usually give you a nice error message saying why you do not have direct rendering.<br />
<br />
Common errors and their solutions, are:<br />
<br />
libGL error: XF86DRIQueryDirectRenderingCapable returned false<br />
<br />
* Ensure that you are loading the correct agp modules for your AGP chipset before you load the {{ic|fglrx}} kernel module. To determine which agp modules you will need, run {{ic|# hwdetect --show-agp}}. Then open your {{ic|/etc/modules-load.d/fglrx.conf}} and add the agp module on a line '''before''' the {{ic|fglrx}} line.<br />
<br />
libGL error: failed to open DRM: Operation not permitted<br />
libGL error: reverting to (slow) indirect rendering<br />
<br />
libGL: OpenDriver: trying /usr/lib/xorg/modules/dri//fglrx_dri.so<br />
libGL error: dlopen /usr/lib/xorg/modules/dri//fglrx_dri.so failed<br />
(/usr/lib/xorg/modules/dri//fglrx_dri.so: cannot open shared object file: No such file or directory)<br />
libGL error: unable to find driver: fglrx_dri.so<br />
<br />
* Something has not been installed correctly. If the paths in the error message are {{ic|/usr/X11R6/lib/modules/dri/fglrx_dri.so}}, then ensure you have logged completely out of your system, then back in. If you are using a graphical login manager (gdm, kdm, xdm), ensure that {{ic|/etc/profile}} is sourced every time you log in. This is usually accomplished by adding {{ic|source /etc/profile}} into {{ic|~/.xsession}} or {{ic|~/.xinitrc}}, but this may vary between login managers.<br />
<br />
* If the paths above in your error message ''are'' {{ic|/usr/lib/xorg/modules/dri/fglrx_dri.so}}, then something has not been correctly installed. Try reinstalling the {{AUR|catalyst}} package.<br />
<br />
Errors such as:<br />
<br />
fglrx: libGL version undetermined - OpenGL module is using glapi fallback<br />
<br />
could be caused by having multiple versions of {{ic|libGL.so}} on your system. The command below should return the following output:<br />
<br />
{{hc|$ locate libGL.s|<br />
/usr/lib/libGL.so<br />
/usr/lib/libGL.so.1<br />
/usr/lib/libGL.so.1.2}}<br />
<br />
These are the only three libGL.so files you should have on your system. If you have any more (e.g. {{ic|/usr/X11R6/lib/libGL.so.1.2}}), then remove them. This should fix your problem.<br />
<br />
You might not get any error to indicate that this is a problem. If you are using X11R7, make sure you do '''not''' have these files on your system:<br />
<br />
/usr/X11R6/lib/libGL.so.1.2<br />
/usr/X11R6/lib/libGL.so.1<br />
<br />
=== Hibernate/Sleep issues ===<br />
<br />
==== Video fails to resume from suspend2ram ====<br />
<br />
ATI's proprietary Catalyst driver cannot resume from suspend if the framebuffer is enabled. To disable the framebuffer, add {{ic|1=vga=0}} to your kernel [[kernel parameters]].<br />
<br />
To see where you need to add this with other bootloaders, see [[#Disable kernel mode setting]].<br />
<br />
=== System freezes/Hard locks ===<br />
<br />
* The {{ic|radeonfb}} framebuffer drivers have been known in the past to cause problems of this nature. If your kernel has radeonfb support compiled in, you may want to try a different kernel and see if this helps.<br />
<br />
* If you experience system freezes when exiting your DE (shut down, suspend, switching to tty etc.) you probably forgot to deactivate KMS. (See [[#Disable kernel mode setting]])<br />
<br />
=== Hardware conflicts ===<br />
<br />
Radeon cards used in conjunction with some versions of the nForce3 chipset (e.g. nForce 3 250Gb) will not have 3D acceleration. Currently the cause of this issue is unknown, but some sources indicate that it may be possible to get acceleration with this combination of hardware by booting Windows with the drivers from nVIDIA and then rebooting the system. This can be verified by getting output something similar to this (using an nForce3-based system):<br />
<br />
{{hc|<nowiki>$ dmesg | grep agp</nowiki>|<br />
agpgart: Detected AGP bridge 0<br />
agpgart: Setting up Nforce3 AGP.<br />
agpgart: aperture base > 4G<br />
}}<br />
<br />
and also if issuing the following command gets you the following output:<br />
<br />
{{hc|<nowiki>$ tail -n 100 /var/log/Xorg.0.log | grep agp</nowiki>|<br />
(EE) fglrx(0): [agp] unable to acquire AGP, error "xf86_ENODEV"}}<br />
<br />
you have this bug.<br />
<br />
Some sources indicate that in some situations, downgrading the motherboard BIOS may help, but this cannot be verified in all cases. Also, '''a bad BIOS downgrade can render your hardware useless, so beware.'''<br />
<br />
See [http://bugzilla.kernel.org/show_bug.cgi?id=6350 this bugreport] for more information and a potential fix.<br />
<br />
=== Temporary hangs when playing video ===<br />
<br />
This problem may occur when using the proprietary Catalyst.<br />
<br />
If you experience temporary hangs lasting from a few seconds to several minutes occuring randomly during playback with mplayer, check the system logs for output like:<br />
<br />
{{hc|/var/log/messages.log|2=<br />
Nov 28 18:31:56 pandemonium [<c01c64a6>] ? proc_get_sb+0xc6/0x160<br />
Nov 28 18:31:56 pandemonium [<c01c64a6>] ? proc_get_sb+0xc6/0x160<br />
Nov 28 18:31:56 pandemonium [<f8bc628c>] ? ip_firegl_ioctl+0x1c/0x30 [fglrx]<br />
Nov 28 18:31:56 pandemonium [<c01c64a6>] ? proc_get_sb+0xc6/0x160<br />
Nov 28 18:31:56 pandemonium [<c0197038>] ? vfs_ioctl+0x78/0x90<br />
Nov 28 18:31:56 pandemonium [<c01970b7>] ? do_vfs_ioctl+0x67/0x2f0<br />
Nov 28 18:31:56 pandemonium [<c01973a6>] ? sys_ioctl+0x66/0x70<br />
Nov 28 18:31:56 pandemonium [<c0103ef3>] ? sysenter_do_call+0x12/0x33<br />
Nov 28 18:31:56 pandemonium [<c01c64a6>] ? proc_get_sb+0xc6/0x160<br />
Nov 28 18:31:56 pandemonium =======================<br />
}}<br />
<br />
Adding the {{ic|nopat}} and/or {{ic|nomodeset}} [[kernel parameters]] should work.<br />
<br />
=== "aticonfig: No supported adapters detected" ===<br />
<br />
If you get the following:<br />
<br />
{{hc|# aticonfig --initial|<br />
aticonfig: No supported adapters detected<br />
}}<br />
<br />
It may still be possible to get Catalyst working by manually setting the device in your your {{ic|etc/X11/xorg.conf}} file or by copying an older working {{ic|/etc/ati/control}} file (preferred - this also fixes the watermark issue).<br />
<br />
To get an older control file, download a previous version of fglrx from AMD and run it with {{ic|--extract driver}} parameter. You will find the control file in {{ic|driver/common/etc/ati/control}}. Copy the extracted file over the system file and restart Xorg. You can try different versions of the file.<br />
<br />
To set your model in {{ic|xorg.conf}}, edit the device section of {{ic|/etc/X11/xorg.conf}} to:<br />
<br />
{{hc|/etc/X11/xorg.conf|<br />
Section "Device"<br />
Identifier "ATI radeon '''****'''"<br />
Driver "fglrx"<br />
EndSection<br />
}}<br />
<br />
Where {{ic|****}} should be replaced with your device's marketing number (e.g. 6870 for the HD 6870 and 6310 for the E-350 APU).<br />
<br />
Xorg will start and it is possible to use {{ic|amdcccle}} instead of {{ic|aticonfig}}. There will be an "AMD Unsupported hardware" watermark.<br />
<br />
You can remove this watermark using the following script:<br />
<br />
#!/bin/sh<br />
DRIVER=/usr/lib/xorg/modules/drivers/fglrx_drv.so<br />
for x in $(objdump -d $DRIVER|awk '/call/&&/EnableLogo/{print "\\x"$2"\\x"$3"\\x"$4"\\x"$5"\\x"$6}'); do<br />
sed -i "s/$x/\x90\x90\x90\x90\x90/g" $DRIVER<br />
done<br />
<br />
and then reboot your machine.<br />
<br />
=== WebGL support in Chromium ===<br />
<br />
Google has blacklisted Linux's Catalyst driver from supporting webGL in their Chromium/Chrome browsers. See [[Chromium#WebGL]] for details.<br />
<br />
=== Lag/freezes when watching flash videos via Adobe's flashplugin ===<br />
<br />
Edit:<br />
<br />
{{hc|/etc/adobe/mms.cfg|2=<br />
#EnableLinuxHWVideoDecode=1<br />
OverrideGPUValidation=true<br />
}}<br />
<br />
If you are using KDE make sure that "Suspend desktop effects for fullscreen windows" is unchecked under {{ic|System Settings}} → {{ic|Desktop Effects}} → {{ic|Advanced}}.<br />
<br />
=== Lag/slow windows movement in GNOME3 ===<br />
<br />
You can try this solution, it has been reported to work for many people.<br />
<br />
Add this line into {{ic|~/.profile}} or into {{ic|/etc/profile}}:<br />
<br />
export CLUTTER_VBLANK=none<br />
<br />
Restart X server or reboot your system.<br />
<br />
=== Not using full screen resolution at 1920x1080 (underscanning, black borders around the screen) ===<br />
<br />
This usually happens when you use a HDMI connection to connect your monitor/TV to your computer.<br />
<br />
Seemed to be a feature by AMD/ATI to work with all HDTVs that could be adjusted via the amdccle.<br />
<br />
Using the amdcccle GUI you can select the affected display, go to adjustments, and set underscan to 0% (aticonfig defaults to 15% underscan). It is possible as well that the underscan slider will not show under the display's adjustments, as sometimes in (at least) version 14.10.<br />
<br />
The problem is that the settings will not persist after restarting X server or rebooting or wake up or might even revert after changing TTYs.<br />
<br />
For the changes to become permanent, you will need to adjust the underscan settings manually using "aticonfig" via console (as root) or manually edit the file {{ic|/etc/ati/amdpcsdb}} (as root)<br />
<br />
'''using aticonfig method:'''<br />
<br />
# aticonfig --set-pcs-u32=MCIL,DigitalHDTVDefaultUnderscan,0<br />
<br />
After changing the settings, reboot.<br />
<br />
For newer version (for example, 12.11), if Catalyst control center repeatedly fails to save the overscan setting you can also try:<br />
<br />
# aticonfig --set-pcs-u32=MCIL,TVEnableOverscan,0<br />
<br />
'''Manually editing /etc/ati/amdpcsdb method:'''<br />
<br />
Add the following line anywhere under the following header {{ic|[AMDPCSROOT/SYSTEM/MCIL]}}<br />
<br />
# DigitalHDTVDefaultUnderscan=V0<br />
<br />
For newer version (for example, 12.11), if Catalyst control center repeatedly fails to save the overscan setting you can also try:<br />
locate under {{ic|[AMDPCSROOT/SYSTEM/MCIL]}} the following line <br />
<br />
# TVEnableOverscan=V1<br />
<br />
and change it to<br />
<br />
# TVEnableOverscan=V0<br />
<br />
After changing the settings, reboot.<br />
<br />
{{note|You might find that the file {{ic|/etc/ati/amdpcsdb}} will be overwritten and revert no matter what you do as user or as root even with log in/log out/reboot, ergo the modification will not stick.<br />
For the amd database file not to be overwritten you have to modify it without the fglrx driver running.<br />
This can be made by rebooting in any "safe mode" that will not use the driver or directly booting into console mode}}<br />
<br />
'''Workaround:'''<br />
For whatever reason you can find yourself not wanting to touch ATI's config files you can circumvent the problem by forcing the panel's position and resolution:<br />
as user:<br />
<br />
# aticonfig --set-dispattrib=DISPLAYTYPE,positionX:0<br />
# aticonfig --set-dispattrib=DISPLAYTYPE,positionY:0<br />
# aticonfig --set-dispattrib=DISPLAYTYPE,sizeX:1920<br />
# aticonfig --set-dispattrib=DISPLAYTYPE,sizeY:1080<br />
<br />
{{ic|DISPLAYTYPE}} will be the name of the monitor you want to change its attributes, for example "dfp9".<br />
To get the name of your {{ic|DISPLAYTYPE}} run the following command:<br />
<br />
# xrandr --current<br />
<br />
Should RandR be not enabled use:<br />
<br />
# aticonfig --query-monitor<br />
<br />
Using the display switch or DISPLAY variable set to the appropriate display/screen (:0.1 for example) might be necessary.<br />
<br />
That will show you which displays are connected and disconnected and its properties<br />
<br />
This workaround will not persist but it is a quick fix that will show that the panel works just fine and that the above solutions are to be put into place.<br />
<br />
{{note|{{ic|<nowiki>aticonfig --set-pcs-val=MCIL,DigitalHDTVDefaultUnderscan,0</nowiki>}} should not be used on newer versions of the driver as it is deprecated and will be soon removed as stated by ATI.}}<br />
<br />
Try {{ic|<nowiki>aticonfig --help | grep set-pcs-val</nowiki>}} to read ATI's notice<br />
<br />
=== Dual Screen Setup: general problems with acceleration, OpenGL, compositing, performance ===<br />
Try to disable xinerama and xrandr12. Check out ie. this way:<br />
<br />
Type those commands:<br />
# aticonfig --initial<br />
# aticonfig --set-pcs-str="DDX,EnableRandR12,FALSE"<br />
Then reboot your system. In {{ic|/etc/X11/xorg.conf}} check that xinerama is disabled, if it is not, disable it and reboot your system.<br />
<br />
Next run {{ic|amdcccle}} and pick up amdcccle → display manager → multi-display → multidisplay desktop with display(s) 2.<br />
<br />
Reboot again and set up your display layout whatever you desire.<br />
<br />
=== Disabling VariBright feature ===<br />
[http://support.hp.com/vn-en/document/c02848104 Vari-Bright] is a feature designed to save power by dynamically adjusting how much power the display panel uses.<br />
Enter the following command to disable VariBright:<br />
# aticonfig --set-pcs-u32=MCIL,PP_UserVariBrightEnable,0<br />
<br />
=== Hybrid/PowerXpress: turning off discrete GPU ===<br />
When you are using packages with powerXpress support and you are switching to integrated GPU you may notice that discrete GPU is still working, consuming power and making your system's temperature higher. <br />
<br />
Sometimes ie. when your integrated GPU is intel's one you can use {{ic|vgaswitcheroo}} to turn the discrete GPU off.<br />
Sometimes unfortunately, it is not working.<br />
<br />
Then you may check out [https://aur.archlinux.org/packages/?O=0&K=acpi_call acpi_call]. MrDeepPurple has prepared the script which he is using to perform 'turn off' task. He is calling script via systemd service while booting and resuming his system.<br />
Here is his script:<br />
#!/bin/sh<br />
libglx=$(/usr/lib/fglrx/switchlibglx query)<br />
modprobe acpi_call<br />
if [ "$libglx" = "intel" ]; then<br />
echo '\_SB.PCI0.PEG0.PEGP._OFF' > /proc/acpi/call<br />
fi<br />
<br />
=== Switching from X session to TTYs gives a blank screen/low resolution TTY ===<br />
Workaround for this "feature", which appeared in catalyst 13.2 betas, is to use {{ic|1=vga=}} kernel option, like {{ic|1=vga=792}}.<br />
You can get the list of supported resolutions with the<br />
$ hwinfo --framebuffer<br />
command. Get the one that corresponds to your wanted resolution, and copy-paste it into kernel line of your bootloader, so it could look like ie. {{ic|1=vga=0x03d4}}<br />
<br />
=== Switching from X session to TTYs gives a black screen with the monitor backlight on ===<br />
Use [[uvesafb]] as your framebuffer driver. Moreover with {{ic|uvesafb}} it is also possible to set whatever resolution for the TTY.<br />
<br />
=== Switching to TTYs then back to X session gives a black screen with a mouse cursor ===<br />
If you experience this bug, try adding<br />
Option "XAANoOffscreenPixmaps" "true"<br />
to the 'Device' section of your xorg.conf file.<br />
<br />
Also, make sure you have a [[Polkit#Authentication agents|polkit authentication agent]] installed and running, as this behavior can happen when a program is asking for a password, but does not have an authentication agent installed to display the password dialog box.<br />
<br />
=== 30 FPS / Tear-Free / V-Sync bug ===<br />
Bug introduced in Catalyst 13.6 beta, not fixed till now (13.9).<br />
<br />
After enabling "Tear-Free" functionality every freshly started OpenGL application is lagging, often generates only 30 FPS, it also touches composited desktop.<br />
<br />
Workaround is pretty simple and was found by M132. Here are the steps, do everything in "AMD Catalyst Control Center" (amdcccle) application:<br />
<br />
1. Enable Tear-Free, it will set 3D V-Sync option to "Always on".<br />
2. Set 3D V-Sync to "Always Off".<br />
3. Make sure Tear-Free is still on.<br />
4. Restart X / Re-login.<br />
<br />
It is working well on KDE 4.11.x, but in case of problems M132 suggests: "Try disabling "Detect refresh rate" and specify monitor's refresh rate in the Composite plugin."<br />
<br />
=== Backlight adjustment does not work ===<br />
If you have a problem with backlight adjustment, you can try the following command: <br />
# aticonfig --set-pcs-u32=MCIL,PP_PhmUseDummyBackEnd,1<br />
Some users reported that this can decrease FPS. To restore defaults, run:<br />
# aticonfig --set-pcs-u32=MCIL,PP_PhmUseDummyBackEnd,0<br />
[http://ati.cchtml.com/show_bug.cgi?id=711 Read more about this bug]<br />
<br />
=== Chromium glitching when using plasma ===<br />
Add --disable-gpu execute option to the chromium, ie. to /usr/share/applications/chromium.desktop file, like here:<br />
# cat /usr/share/applications/chromium.desktop | grep -i exec<br />
Exec=chromium %U --disable-gpu<br />
<br />
=== Xorg crashes ===<br />
<br />
==== Unsupported Xorg Version ====<br />
<br />
When having a supported Linux kernel version but an unsupported Xorg version, you might get this error message and Xorg will crash<br />
<br />
(WW) fglrx: No matching Device section for instance (BusID PCI:0@0:17:0) found<br />
(...)<br />
/usr/bin/Xorg.bin: symbol lookup error: /usr/lib/xorg/modules/drivers/fglrx_drv.so: undefined symbol: GlxInitVisuals2D<br />
xinit: giving up<br />
xinit: unable to connect to X server: Connection refused<br />
xinit: server error<br />
<br />
For example: fglrx 15.20.3 does not support Xorg 1.17.<br />
<br />
To solve this, you should downgrade Xorg. A helpful list of steps can be found on [https://gist.github.com/anonymous/9ea8d3774f7afce3a605]<br />
<br />
== See also ==<br />
<br />
* [http://wiki.cchtml.com/index.php/Main_Page Unofficial Wiki for the ATI Linux Driver]<br />
* [http://ati.cchtml.com/query.cgi Unofficial ATI Linux Driver Bugzilla]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Mirrors&diff=412693Mirrors2015-12-18T09:12:14Z<p>Saren: Improve visibility</p>
<hr />
<div>[[Category:About Arch]]<br />
[[Category:Package management]]<br />
[[ar:Mirrors]]<br />
[[es:Mirrors]]<br />
[[fr:Miroirs]]<br />
[[it:Mirrors]]<br />
[[ja:ミラー]]<br />
[[ru:Mirrors]]<br />
[[zh-CN:Mirrors]]<br />
{{Related articles start}}<br />
{{Related|pacman}}<br />
{{Related articles end}}<br />
<br />
This page is a guide to selecting and configuring your mirrors, and a listing of current available mirrors.<br />
<br />
== Official mirrors ==<br />
<br />
The official Arch Linux mirror list is available from the {{pkg|pacman-mirrorlist}} package. To get an even more up-to-date list of mirrors, use the [https://www.archlinux.org/mirrorlist/ Pacman Mirrorlist Generator] page on the main site.<br />
<br />
Check the status of the Arch mirrors by visiting the [https://www.archlinux.org/mirrors/status/ Mirror Status] page. It is recommended to only use mirrors that are up to date, i.e. not out of sync.<br />
<br />
=== IPv6-ready mirrors ===<br />
<br />
The [https://www.archlinux.org/mirrorlist/?ip_version=6 Pacman Mirrorlist Generator] can also be used to find a list of current IPv6 mirrors.<br />
<br />
== Enabling a specific mirror ==<br />
<br />
To enable mirrors, edit {{ic|/etc/pacman.d/mirrorlist}} and locate your geographic region. Uncomment mirrors you would like to use.<br />
<br />
Example:<br />
<br />
# Any<br />
# Server = <nowiki>ftp://mirrors.kernel.org/archlinux/$repo/os/$arch</nowiki><br />
'''Server = <nowiki>http://mirrors.kernel.org/archlinux/$repo/os/$arch</nowiki>'''<br />
<br />
See [[#Sorting mirrors]] for tools that help choosing mirrors.<br />
<br />
{{Tip|<br />
* Uncomment 5 favorite mirrors and place them at the top of the mirrorlist file. That way it's easy to find them and move them around if the first mirror on the list has problems. It also makes merging mirrorlist updates easier.<br />
* HTTP mirrors are faster than FTP due to [[Wikipedia:HTTP persistent connection|persistent HTTP connection]]: with FTP, a new connection to server has to be established each time ''pacman'' requests a package to be downloaded, which results in a brief pause.<br />
}}<br />
<br />
It is also possible to specify mirrors in {{ic|/etc/pacman.conf}}. For the ''[core]'' repository, the default setup is:<br />
[core]<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
To use the ''HostEurope'' mirror as a default mirror, add it before the {{ic|Include}} line:<br />
[core]<br />
'''Server = <nowiki>ftp://ftp.hosteurope.de/mirror/ftp.archlinux.org/core/os/$arch</nowiki>'''<br />
Include = /etc/pacman.d/mirrorlist<br />
<br />
pacman will now try to connect to this mirror first. Proceed to do the same for ''[testing]'', ''[extra]'', and ''[community]'', if applicable.<br />
<br />
{{Note|If mirrors have been stated directly in {{ic|pacman.conf}}, remember to use the same mirror for all repositories. Otherwise packages that are incompatible to each other may be installed, like linux from ''[core]'' and an older kernel module from ''[extra]''.}}<br />
<br />
=== Force pacman to refresh the package lists ===<br />
<br />
Mirrors can be out of sync and the package list from the old mirror may not correspond to the package list of the new mirror, even though the dates of the lists may suggest that they do.<br />
<br />
After creating/editing {{ic|/etc/pacman.d/mirrorlist}}, (manually or by using {{ic|rankmirrors}}) issue the following command:<br />
# pacman -Syyu<br />
<br />
Passing two {{ic|--refresh}} or {{ic|-y}} flags forces pacman to refresh all package lists even if they are considered to be up to date. Issuing {{ic|pacman -Syyu}} ''whenever changing to a new mirror'' is good practice and will avoid possible issues. See also [https://bbs.archlinux.org/viewtopic.php?id=163124 Is -Syy safe?].<br />
<br />
== Sorting mirrors ==<br />
<br />
When downloading packages pacman uses the mirrors in the order they are in {{ic|/etc/pacman.d/mirrorlist}}. To set a priority to mirrors, the mirrorlist file has to be sorted manually or using a script.<br />
<br />
It is not a good idea to just use the fastest mirrors, since the fastest mirrors might be out of sync. Instead, make a list of mirrors sorted by their [[#List by speed|speed]], then remove those from the list that are out of sync according to their [https://www.archlinux.org/mirrors/status/ status].<br />
<br />
It is recommended to repeat this process before every system upgrade to keep {{ic|/etc/pacman.d/mirrorlist}} up to date.<br />
<br />
=== List by speed ===<br />
<br />
The {{Pkg|pacman}} package provides a Bash script, {{ic|/usr/bin/rankmirrors}}, which can be used to rank the mirrors according to their connection and opening speeds to take advantage of using the fastest local mirror.<br />
<br />
Back up the existing {{ic|/etc/pacman.d/mirrorlist}}:<br />
<br />
# cp /etc/pacman.d/mirrorlist /etc/pacman.d/mirrorlist.backup<br />
<br />
Edit {{ic|/etc/pacman.d/mirrorlist.backup}} and uncomment mirrors for testing with {{ic|rankmirrors}}.<br />
<br />
Optionally run the following {{ic|sed}} line to uncomment every mirror:<br />
<br />
# sed -i 's/^#Server/Server/' /etc/pacman.d/mirrorlist.backup<br />
<br />
Finally, rank the mirrors. Operand {{ic|-n 6}} means only output the 6 fastest mirrors:<br />
<br />
# rankmirrors -n 6 /etc/pacman.d/mirrorlist.backup > /etc/pacman.d/mirrorlist<br />
<br />
Run {{ic|rankmirrors -h}} for a list of all the available options.<br />
<br />
=== Server-side ranking ===<br />
<br />
The official [https://www.archlinux.org/mirrorlist/ Pacman Mirrorlist Generator] provides an easy way to obtain a ranked list of mirrors. Because all ranking is done on a single server that takes multiple factors into account, the amount of load on the mirrors and the clients is significantly lower compared to ranking on each individual client.<br />
<br />
There are multiple scripts automating the update of the mirrorlist from the ranking server:<br />
<br />
* [[Reflector]] retrieves the latest mirrorlist from the [https://www.archlinux.org/mirrors/status/ MirrorStatus] page, filters the most up-to-date mirrors, sorts them by speed and overwrites the {{ic|/etc/pacman.d/mirrorlist}} file.<br />
* {{AUR|update-pacman-mirrorlist}} is a minimalistic script that downloads a mirrorlist from a specified ranking server defaulting to the official [https://www.archlinux.org/mirrorlist/ Pacman Mirrorlist Generator]. It also provides a [[Systemd/Timers|systemd timer]] to manage the mirrorlist automatically without intervention. Configuration is possible by changing the URL query string in the {{ic|/etc/update-pacman-mirrorlist}} configuration file.<br />
* [https://github.com/Gen2ly/armrr armrr] downloads ranked mirrorlist for a specific country from [https://www.archlinux.org/mirrorlist/ Pacman Mirrorlist Generator] and creates a backup of the previous mirrorlist.<br />
<br />
=== List mirrors only for a specific country ===<br />
<br />
Can be useful to automate update of the mirror list only for a specific countries instead of making a speed test each time. Assumed that {{ic|mirrorlist.pacnew}} exist, the file creates after installation of the {{Pkg|pacman-mirrorlist}} update.<br />
<br />
{{bc|<nowiki>Cnt="China";<br />
awk -v GG=$Cnt '{if(match($0,GG) != "0")AA="1";if(AA == "1"){if( length($2) != "0" )print substr($0,2) ;else AA="0"} }' \<br />
/etc/pacman.d/mirrorlist.pacnew</nowiki>}}<br />
<br />
== Troubleshooting ==<br />
<br />
In the unlikely scenario that you are without any configured mirrors and {{ic|pacman-mirrorlist}} is not installed, run the following command:<br />
# curl -o /etc/pacman.d/mirrorlist <nowiki>https://www.archlinux.org/mirrorlist/all/</nowiki><br />
<br />
Be sure to uncomment a preferred mirror as described above, then:<br />
# pacman -Syu pacman-mirrorlist<br />
<br />
If you get an error stating that the {{ic|$arch}} variable is used but not defined, add the following to your {{ic|/etc/pacman.conf}}:<br />
Architecture = x86_64<br />
<br />
{{Note|You can also use the values {{ic|auto}} and {{ic|i686}} for the {{ic|Architecture}} variable.}}<br />
<br />
== Add your own mirror == <br />
<br />
If you want your mirror to be added to the official list, see [[DeveloperWiki:NewMirrors]]. In the meantime, add it to the [[#Unofficial mirrors]] list at the end of this page.<br />
<br />
== Unofficial mirrors ==<br />
<br />
These mirrors are ''not'' listed in {{ic|/etc/pacman.d/mirrorlist}}.<br />
<br />
=== Austria ===<br />
<br />
*http://gd.tuwien.ac.at/opsys/linux/archlinux/ - ''Vienna University of Technology''<br />
*ftp://gd.tuwien.ac.at/opsys/linux/archlinux/<br />
<br />
=== China ===<br />
<br />
'''Telecom'''<br />
*http://mirror.bit.edu.cn/archlinux/ - ''Beijing Institute of Technology''<br />
*http://mirrors.aliyun.com/archlinux/ - ''Alibaba''<br />
<br />
'''Unicom'''<br />
*http://mirrors.sohu.com/archlinux/<br />
*http://mirrors.yun-idc.com/archlinux/<br />
<br />
'''Cernet'''<br />
*http://ftp.sjtu.edu.cn/archlinux/ - ''Shanghai Jiaotong University''<br />
*http://mirrors.4.tuna.tsinghua.edu.cn/archlinux/ ''(ipv4 only)''<br />
*http://mirrors.6.tuna.tsinghua.edu.cn/archlinux/ ''(ipv6 only)''<br />
*http://mirror.lzu.edu.cn/archlinux/ - ''Lanzhou University''<br />
<br />
=== France ===<br />
<br />
*http://delta.archlinux.fr/ - ''With Delta package support. Needs xdelta3 package from extra to run.''<br />
*http://mirror.soa1.org/archlinux<br />
*ftp://mirror:mirror@mirror.soa1.org/archlinux<br />
<br />
=== Germany ===<br />
<br />
*http://ftp.u-tx.net/archlinux/<br />
*ftp://ftp.u-tx.net/archlinux/<br />
<br />
=== Hong Kong ===<br />
<br />
*http://hk.mirrors.linaxe.net/archlinux/<br />
<br />
=== Indonesia ===<br />
<br />
*http://kambing.ui.ac.id/archlinux/<br />
<br />
=== Iran ===<br />
<br />
*http://mirror.yazd.ac.ir/arch/<br />
<br />
=== Italy ===<br />
<br />
*http://mi.mirror.garr.it/mirrors/archlinux/<br />
<br />
=== Japan ===<br />
<br />
*http://ftp.nara.wide.ad.jp/pub/Linux/archlinux/ - ''NAra Institute of Science and Technology''<br />
*http://ftp.kddilabs.jp/Linux/packages/archlinux/<br />
*http://srv2.ftp.ne.jp/Linux/packages/archlinux/<br />
<br />
=== Malaysia ===<br />
<br />
*http://mirror.oscc.org.my/archlinux/<br />
<br />
=== New Zealand ===<br />
<br />
*http://mirror.ece.auckland.ac.nz/archlinux/ ''NZ only''<br />
<br />
=== Poland ===<br />
<br />
*ftp://ftp.icm.edu.pl/pub/Linux/dist/archlinux/ - ICM UW<br />
*http://ftp.icm.edu.pl/pub/Linux/dist/archlinux/ - ICM UW<br />
*rsync://ftp.icm.edu.pl/pub/Linux/dist/archlinux/ - ICM UW<br />
<br />
=== Russia ===<br />
<br />
*http://mirrors.krasinfo.ru/archlinux/ - ''Krasnoyarsk, Classica-Service Ltd''<br />
<br />
=== South Africa ===<br />
<br />
*http://ftp.leg.uct.ac.za/pub/linux/arch/ - ''University of Cape Town''<br />
*ftp://ftp.leg.uct.ac.za/pub/linux/arch/<br />
*http://mirror.ufs.ac.za/archlinux/ - ''University of the Free State''<br />
*ftp://mirror.ufs.ac.za/os/linux/distros/archlinux/<br />
*http://archlinux.mirror.ac.za - ''TENET - Tertiary Education and Research Network of South Africa''<br />
*ftp://archlinux.mirror.ac.za<br />
<br />
=== United States ===<br />
<br />
* http://mirror.clarkson.edu/archlinux/<br />
* http://mirror.pointysoftware.net/archlinux/<br />
* http://il.mirrors.linaxe.net/archlinux/ - ''Server location - Chicago, IL''<br />
<br />
=== Sourceforge (old ISOs) ===<br />
<br />
* http://sourceforge.net/projects/archlinux/files/ - ''ISO files only; Does not have any releases since 2006. Use it only for getting older ISOs.''</div>Sarenhttps://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&diff=373373Talk:Beginners' guide2015-05-11T15:19:28Z<p>Saren: /* Should we indicate what more could be installed in Post-installation section? */</p>
<hr />
<div>== Unification ==<br />
=== A single, unified official install guide ===<br />
<br />
{{Note|This is based on talk/consensus in #archlinux. The official [[Installation Guide]] page is going to be expanded (or this guide could be protected, cleaned up and replace it - either works, that could be decided here).}}<br />
<br />
Previously, there has been talk here about merging with the old official install guide, and just having a single official [[Installation Guide]]. However, that didn't happen when the old guide was removed because the [[Beginners' Guide]] was (and is) too long, with too much duplication of other pages after the point where it's necessary (getting the initial network access). In order to be an "official" document, it would also have to be protected - edits by regular users would be proposed on the talk page.<br />
<br />
The installation process now always requires network access, and the ISO ships with both a browser and an IRC client, so it's not necessary to keep so much information on this page, since we have very good coverage elsewhere that surpasses the duplication here. For example, there's no need for the [[Beginners' Guide]] to explain how to do an upgrade as [[Pacman#Upgrading packages]] has much better coverage of the gritty details, and the initial install is already fully upgraded.<br />
<br />
-- [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 21:52, 28 October 2012 (UTC)<br />
<br />
:Yes, the ISO comes with a browser ({{Pkg|elinks}}), but it's not very good with formatting. Some people may prefer to actually print the guide ''(which is a waste of paper, if you ask me, but old timers may feel differently)'', or save it as a PDF/HTML and read it on whatever device they own (smartphone, tablet, etc).<br />
<br />
No need to create a section for this, just reminding that the unification would affect {{Bug|36111}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:57, 18 August 2013 (UTC)<br />
<br />
=== Define scope of the guide ===<br />
I'd like to define the scope of the guide(s) better and whether it's OK to remove certain things from the wiki instead of marking them as 'the old way' and maybe moving them to a separate article, if needed. Currently the beginners' guide still has info related to initscripts, like [https://wiki.archlinux.org/index.php/Beginners%27_Guide#Time_zone setting the timezone], but the article on time [https://wiki.archlinux.org/index.php/Time#Time_standard has not]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 09:56, 30 October 2012 (UTC)<br />
: Right now the Beginner's Guide is "A page where user can get their system installed '''without reading other pages'''". This is where the duplications come from. Maybe we can redefine it. So we can:<br />
: # Improve [[Help:Reading]]. Add some guide about Navigation, Searching, Category and Table of Contents. So users can reach the information they want more easily.<br />
: # Reduce long duplication texts. The two network configuration part is a candicate. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:46, 31 October 2012 (UTC)<br />
:The reason for using the manual way of configuring is actually because timedatectl and friends won't work from inside a chroot. We could avoid that by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all) but that would require some minor restructuring, so it's something worth discussing. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 17:28, 3 November 2012 (UTC)<br />
<br />
::''[This comment was pasted here from a different, now deleted discussion]''<br />
:: I think that the goal of the Beginners' Guide is not only to let an Arch novice install the system successfully, but also to introduce him to how an Arch Linux system is structured and the technologies it's based on: we shouldn't think of the Beginners' Guide (or any other article) as a simple howto or step-by-step guide, but as something more formative. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:40, 19 September 2012 (UTC)<br />
<br />
=== Plan ===<br />
If someone was interested and had the time to lay out here a '''detailed''' plan with indications on where to merge every section of the guide and a report of all the problems that could be encountered in the process, it would definitely be the final step before announcing the unification on the forums with full support from the admins, which would mean that at that point only strong and reasonable objections could prevent the unification. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:44, 18 August 2013 (UTC)<br />
<br />
Here is a list of sections that should be merged. Feel free to expand, comment in [[#Comments]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:26, 31 August 2013 (UTC)<br />
<br />
* [[Beginners'_guide#Without_wifi-menu]] -- merge into [[Wireless_network_configuration#Getting_some_useful_information]], leave link to target<br />
* [[Beginners%27_guide#Hardware_clock]] - merge to [[Time]], leave link to target, see [[#Hardware_clock_section]]<br />
* Merge common parts between [[Beginners' guide#Establish an internet connection]] and [[Beginners' guide#Configure_the_network]] into [[Network configuration]] and just link there.<br />
* [[Beginners' guide#Prepare the storage devices]] - Contains more information on parted than the actual [[parted]], merge back details <br />
<br />
==== General problems ====<br />
<br />
* ''timedatectl'', ''hostnamectl'', ''localectl'' etc. won't work from inside a chroot, so manual method of configuration is required. This could be avoided by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all). (mentioned in [[#Define scope of the guide]] by [[User:Thestinger]])<br />
<br />
::You might say these are important enough to have users execute by hand (and thus get a better understanding of, hopefully). But as the underlying processes are explained well enough in their respective articles, I'm fine either way. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:34, 20 February 2015 (UTC)<br />
<br />
* Instructions should be clear and concise, taking the [[Installation guide]] as example.<br />
<br />
* [[Beginners'_guide#Troubleshooting_boot_problems]] lacks coherence, and may need expansion. See [[#Blacklisting radeon module]].<br />
<br />
* Add short introduction on differences between BG and other wiki pages. See [[#Installation template]].<br />
<br />
==== Comments ====<br />
<br />
=== Installation template ===<br />
<br />
Another alternative way to unify the two main guides would be to follow the same philosophy we used to write the scenarios in [[Dm-crypt_with_LUKS/Encrypting_an_entire_system]], originally discussed in [[Talk:Dm-crypt#New_idea]]: the new installation guide could be a bare, though ''complete'', list of commands and simple instructions needed to install the system in one example scenario, with links to the various relevant articles for detailed information and adaptations to specific cases. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:18, 27 March 2014 (UTC)<br />
<br />
:Well, the Beginners' guide suffers from issues related to both content and style, and I really think they need to be addressed at the same time. Every suggestion so far deals only with one problem.<br />
:'''Content:''' I agree that the purpose of the guide (be it Beginners' or Installation) should be to describe only one scenario and provide links to other articles describing the alternatives. I really like ''this part'' of your suggestion, but it solves only half of the problem.<br />
:'''Style:''' The biggest problem is that Beginners' guide is unique mixture of ''introduction to reading ArchWiki'' and ''introduction to installing and '''using''' Arch Linux'', which are simply inseparable in the context of BG - you just can't expect newcomers to first read [[Help:Reading]] and only then start installing their system. So, there is a little bit of anarchy, as the BG is mostly excused from the [[Help:Style|style guidelines]] and there are no guidelines specifically for the BG. Unifying the two guides would necessarily mean a compromise regarding style, which would not be the best for either beginners or gurus.<br />
:Also, I think that it is a good thing that BG is readable ''without reading other pages'' (as defined in [[#Define scope of the guide]]), because it implies that the most important things have been collected and the readers don't have to click-and-search ''too much''. This is really important for the newcomers, because the orientation in the graph of internal links (I wanted to visualize the graph, but it's just too big) is really difficult - they would need to read dozens of pages (with some [[Help:Style|alien style]] applied) before they had the basic system running. On the other hand, one of the main points of BG should be to prepare the readers for other ArchWiki articles, but sometimes the readers are [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=291207&oldid=285657 too] [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=304473&oldid=295238 spoiled].<br />
:Well, that is my defence of keeping both IG and BG. In my opinion it is enough to just properly define the scope of BG and trim it down to ease the maintenance, addressing the ''content'' part. But of course if there is a suggestion on merging the two guides addressing the ''style'' issues, let's hear it!<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:16, 30 March 2014 (UTC)<br />
<br />
::About the style issue, I don't think experienced users would be so bothered by some pacman, systemctl or nano examples, and the unified guide should probably explicitly warn users that they won't find similar examples in the other articles, which would be a perfect way to invite them to become familiar with [[pacman]], [[systemd]], [[Help:Reading]]... Besides, if the guide will be properly structured, experienced users who don't have their own custom installation notes will be able to just follow the automatic ToC as a memory refresher.<br />
::I disagree that the fact that the "BG is readable ''without reading other pages''" is a good thing, as that's exactly the reason that makes it hard to maintain and encourages duplication of information; if users were used to follow links instead, most of the efforts now spent in improving the BG would be instead spent in properly improving the linked articles, which would then become as easy to follow as the BG is now.<br />
::Anyway, I've proposed a change in [[#Comments]] (under [[#Plan]]) that I think should be more likely to reach general consensus, and that would already be a good step forward.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:35, 31 March 2014 (UTC)<br />
<br />
:::I'm beginning to understand the need for merging. After the BG is slimmed down to cover only one example scenario, the title will be just wrong and the scope will be ''exactly'' the same as for IG. It all depends on whether different target audience and related style differences are enough to justify two guides.<br />
:::I hate being the blocker, so let's slim down BG and when it comes to the point of merging with IG, at least it will not be so shocking. I can't help but to think about it as simple redirecting of BG to IG, which will be (more or less) the eventual outcome, so I will need some time to absorb.<br />
:::Finally, we should also look at [[ArchWiki:Requests#Cleanup: installation category]], so that [[:Category:Getting and installing Arch]] is actually useful for providing alternative scenarios, and to ensure there is a place where to move excessive information from the BG.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 7 April 2014 (UTC)<br />
<br />
::::You are not "the blocker", every opinion is as valuable as the others if well argumented, be it for or against the proposal. Especially in this case where we seem to be the only 2 people interested in discussing...<br />
::::If the unification will eventually be completed, of course the BG will become a redirect to the IG, and the latter will be unprotected (and well watched so it's not turned again into a BG).<br />
::::Let's go on with the change very gradually, that's definitely the best way to let everyone successfully and happily adapt to the new way of following the document, which, if done properly, will be even easier and clearer (no need to compare two guides anymore, just to mention an advantage).<br />
::::Of course [[ArchWiki:Requests#Cleanup: installation category]] is strictly linked to all this, I'll try to get there too.<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:26, 9 April 2014 (UTC)<br />
<br />
:::::I personally would suggest leaving the Installation guide locked after the merger (even if that would lock me out also :). Thing is, if someone went through the effort of researching an addition to the guide, it would be easy for them to bring it up here, in the talk page, and easier for the community to discuss (and implement, if applicable). <br />
:::::Leaving the Installation guide unprotected however would make it open to hasty edits. Even if the IG were well watched as said, a made edit's context may not be sufficiently clear to "judge" it on the spot (confirmed by [[ArchWiki:Reports]]). Having contested content remain (however short) on the main, "official" installation reference is less than ideal.<br />
:::::A compromise may be similar to the [[IRC]] page, which is not protected in the technical sense, but has a warning urging users not to edit the page without prior consensus. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:30, 19 February 2015 (UTC)<br />
<br />
::::::Once upon a time, I absolutely don't even remember where, we even discussed the option of keeping the guide in a protected page, but do all the modifications in a separate open page (as if they were two "master" and "devel" branches), with the admins periodically approving and merging the unstable page into the official one. Thanks to the recently introduced [[Special:MergeHistory]] tool, this job could be easier nowadays. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:06, 20 February 2015 (UTC)<br />
<br />
:::::::That sounds like a good option. Working hypothesis: to make users accustomed to the idea, we could now add a note at the top of the BG, suggesting to first discuss changes on the talk page. After the merger this note would then point to the "development" page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:39, 16 March 2015 (UTC)<br />
<br />
::::::::I think that [[Special:MergeHistory]] is too primitive tool for this, AFAIK its only way of operation is "merge all revisions ''up to'' specified one", i.e. there is no ''cherry-picking'' of feasible revisions. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:50, 16 March 2015 (UTC)<br />
<br />
:::::::::@Alad I'm still thinking about it, I'm not sure whether having 2 protected installation guides would be too confusing. The branch method would certainly be well suited if we really ended up merging the guides into one.<br />
:::::::::@Lahwaacz The way it would work would be (''master'' is protected, contains the whole revisions history and ''will not receive direct edits'' by anyone, including admins):<br />
:::::::::# ''develop'' is initialized with a simple copy of the latest revision of ''master''<br />
:::::::::# Some users make some edits to ''develop''<br />
:::::::::# The wiki staff amends/undos ''develop'' as necessary with additional edits (like it happens now in the only branch)<br />
:::::::::# Once ''develop'' is considered in a good state, [[Special:MergeHistory]] can be used safely, no need for cherry-picking<br />
:::::::::# Go back to 1 (at this step ''develop'' is a redirect to ''master'')<br />
:::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:09, 17 March 2015 (UTC)<br />
<br />
:::::::::A simpler alternative with the same effect would be maintaining a link that points to the latest officially approved revision in the history of the article, for example in a Note in the intro. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:13, 17 March 2015 (UTC)<br />
<br />
::::::::::Take your time, it will take a lot more work to get the BG anywhere near ready for merging. A link with note sounds viable as well; we could add a table with different options below. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:08, 17 March 2015 (UTC)<br />
<br />
== Blacklisting radeon module ==<br />
<br />
Installed Arch on my laptop, during pacstrap the screen went blank, pressing SPACE, CTL+C ... didn't helped only modprobe.blacklist=radeon enabled me to go through the whole installation process.<br />
My graphic card is ATI M96 aka Mobility Radeon HD 4650.<br />
I believe this info and similar problems should be added to the beginner's guide on a Installation's Issues Troubleshooting section. I believe this is important enough to dual post and separate it from the Removing "Kernel modules" talk. p.s. I may add that this is my first desktop Linux experience--[[User:Dhead|Dhead]] ([[User talk:Dhead|talk]]) 06:20, 4 March 2013 (UTC)<br />
<br />
:The beginners' guide should not contain hardware-specific info, if the issue is common enough links can be added to [[Beginners%27_guide#Troubleshooting_boot_problems]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:40, 27 December 2014 (UTC)<br />
<br />
== Newbie here offering thoughts on what could be changed in guide ==<br />
<br />
=== General troubleshooting ===<br />
<br />
Apart from that there should be a section at the very beginning explaining how to troubleshoot your own problems. Learning dmesg -HLkd and journalctl -b etc were helpful tools for me. I also appreciated learning lsblk, lsmod, ls etc from the various articles, but a quick over view of these helpful commands on this page would help newbies like myself. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
: Sorry! Just reading over again, and realizing that I could've saved a tonne of time if I knew the problem of "a bunch of white letters clustered on my screen" was an error I could check. It usually happened when the firmware didn't support something (in my case) but telling the user what he can do when this happens helps ease the wiki hopping. I finally, finally figured out how to debug most of my own problems and I think that is the number one thing this guide should do. No offense, but it would also lessen the load on the "newbie corner" on the forums (not that I know it's loaded or not, but less is better, right?). That way no matter what's written in the guide, if it's incorrect or leads to a bad result, the user can figure out why and what to do.. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:05, 7 June 2013 (UTC)<br />
<br />
:: Another [[Keyboard_Shortcuts|useful article]] that could be mentioned (rebooting from black screens, yay!) [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 00:27, 8 June 2013 (UTC)<br />
<br />
:::Regarding your second point, [[General troubleshooting]] is in Related articles - it could be expanded there. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:25, 2 July 2014 (UTC)<br />
<br />
=== Mounting partitions and dual-boot ===<br />
<br />
And lastly, the surprisingly tricky bit about "mounting" partitions that do not belong to you on a dual boot system. Ultimately for me what ended up working was knowing which file systems the others could read (esp in a UEFI system). These things can't just be "linked" to because even the pages linked to don't have the information. I got quite a bit of help from friends and google. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
== Gummiboot instructions are out of order. ==<br />
<br />
I'm not certain if this is the same issue as the heading "gummiboot instructions are confusing?", but I encountered this using the Beginner's guide. In "2.4 Mount the partitions", it mentions that you should mount the ESP at /boot. But then in "2.8 Chroot and configure the base system", the root is changed to the new system's mountpoint, and /boot no longer refers to the mounted ESP partition (because this was mounted in the live installation CD, in zsh). When in "2.12.2 For UEFI motherboards" I run the gummiboot install command, it errors saying that it is not a fat32 partition. Furthermore, I'm not sure if I need to actually have the initramfs files that were made during pacstrap in the actual ESP since they were installed to /boot. (My thought is they should be, because the assumption was that the ESP has actually been mounted on /boot since before pacstrap was run.) <br />
<br />
I'm not certain what to do. (I'm new, this is my first time going through this guide.) Could someone please review this? Or perhaps I made a mistake somewhere...?<br />
<br />
[[User:Tmarks|Tmarks]] ([[User talk:Tmarks|talk]]) 14:23, 11 October 2014 (UTC)<br />
<br />
: Hmmm... After that there's a command telling about mounting to {{ic|/mnt/boot}}, so people must mount it correctly to {{ic|/mnt/boot}}. But I think you are right, I's a bit confusing and we should replace preceding {{ic|/boot}} with {{ic|/mnt/boot}} -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 11:00, 15 October 2014 (UTC)<br />
<br />
::I am not sure I follow this completely; the quoted section numbers anyhow. [[Beginners' guide#For UEFI motherboards]] states "It is strongly recommended to have the EFI System Partition mounted at /boot as this is required to automatically update Gummiboot." and then "(replace) $esp with the location of your EFI System Partiton, usually /boot" right before the gummiboot install. Maybe it was updated meanwhile, do we need to adjust something? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:54, 2 January 2015 (UTC)<br />
<br />
== Hardware clock section ==<br />
<br />
The '''Hardware clock''' section instructs users to set their hardware clock to UTC time:<br />
<br />
# hwclock --systohc --utc<br />
<br />
without explaining that this will actually reset the BIOS clock setting. Users are then warned that ''Using localtime on Arch systems may lead to several known and unfixable bugs''.<br />
<br />
Question: what might those unfixable bugs be? I've been following these instructions fairly rigorously on every Arch system I've installed, but just got burned by the clock setting, as I think I spaced out and reset the BIOS clock to localtime, so outgoing mail on the system was thrown off by several hours for a couple of days until one of the users alerted me to the problem. Setting the system clock to UTC is kind of confusing, particularly for beginners. What are the unfixable bugs from doing this? If these don't actually exist I would suggest just setting the hardware clock to localtime. This allows you to check the accuracy of the RTC when snooping around in the BIOS.<br />
<br />
# hwclock --systohc --localtime<br />
<br />
And if there really are unfixable bugs, users should be told that the hardware clock is going to be set to an unfamiliar value, so they don't freak out when they go in the system setup and find that the clock is off by several hours from the time they thought it should be. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 22:33, 5 February 2015 (UTC)<br />
<br />
:[https://lists.archlinux.org//listinfo/arch-general/ arch-general] is a probably a better place to discuss this. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:47, 6 February 2015 (UTC)<br />
<br />
::OK, I added a note explaining that this command would reset the RTC clock, which is probably good enough for the Beginner's Guide. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 08:44, 6 February 2015 (UTC)<br />
<br />
:::I've just finished [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=359876&oldid=359646 expanding] that section, I hope it clarifies some of the doubts. Regarding the unspecified "several known and unfixable bugs" I second the suggestion to ask in the mailing list. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:22, 7 February 2015 (UTC)<br />
<br />
::::Thanks for making those edits -- it's much clearer now. I also like your simplification of my comment. Based on my own experience, it's important to point this out explicitly (that the BIOS clock setting will look funny) even if it is implicitly obvious, if you think about it. "Don't make me think" is not just a rule that applies to websites. <:) -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 09:52, 7 February 2015 (UTC)<br />
<br />
:::::I think the description is good, but a bit verbose for the BG (particularly as this is about booting multiple operations systems, namely Windows). [http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html ut-rc] (linked from [[Time#Time_standard]]) provides some more background, also on the "unfixable bugs".<br />
:::::I'd suggest to merge the more elaborate description to [[Time]], provide a short paragraph on Windows and localtime (and unexpected BIOS clock), and link to the above website. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:34, 22 February 2015 (UTC)<br />
<br />
::::::If you manage to merge the section into [[Time]] I think it's a good thing; I also think the external link can be kept only there: if we want to make the section brief, I'd say that what the readers need to know from the BG is only that they have to make sure the hw clock is set to UTC time and that all the other installed OSs must be set accordingly (Arch will consider the hw clock to be set to UTC by default). Then, if they want to know why, or if they want to use localtime for some reason, they can be sent to read [[Time]] to understand all the pros and the cons. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:15, 23 February 2015 (UTC)<br />
<br />
== Static IP ==<br />
<br />
I'd like to discuss whether to keep [[#Beginners' guide#Static IP]] or not. [[dhcpcd#Fallback static profile]] could easily be expanded to cover this, and most (home) routers provide DHCP by default. Having the information in [[dhcpcd]] also benefits [[Beginners' guide#Wired]] which directly links to that article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:20, 28 March 2015 (UTC)<br />
<br />
:I assume you'd replace it with a link to [[dhcpcd#Fallback static profile]], +1 from me. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:19, 29 March 2015 (UTC)<br />
<br />
:I'm -1 on this idea. Fallback is useful for headless installs, yes, but that's not a BG topic.? If a user starts configuring [[Beginners' guide#Static IP]], this means default ISO booting DHCP has failed. Making a static connection fallback only delays startup further in this case.. because DHCP will fail again first. <br />
:Sidenote: What one might consider, is open a flyspray suggesting the ISO default dhcpcd config could gain a fallback static IP config (with both 192.168.* and 10.10.* IPs/routes it would probably be reachable for the majority of routers). <s>Doing such might be considered network intrusive by some users though.</s> edit: since it would be a passive config, not really intrusive. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:57, 29 March 2015 (UTC)<br />
<br />
::Well, the idea is to change/expand the dhcpcd section first to include fallback as a sub-section. The main content would be a regular static profile, with info merged from the BG, and named [[dhcpcd#Static profile]]. I like suggesting a default config though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:16, 29 March 2015 (UTC)<br />
<br />
:::Please drop a quick note, if you open a bug for it (I do the same). Sub-section or not, this part makes no sense for BG readers of that section imo. Moving the current dhcpcd content of the section, ok - but that's a neat seven lines including code and not really worth it. Moving the whole section comes at the expense of having it verbose incl. interface identification in [[dhcpcd]]. I'm neutral on that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:45, 29 March 2015 (UTC)<br />
<br />
::::I also doubted if it was worth the effort, hence my asking. Still, I'd like some relation to the chroot section, if only a Tip for users to save/copy their config for later use. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:21, 1 April 2015 (UTC)<br />
<br />
:::::Good idea, added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=368819&oldid=368817]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:41, 6 April 2015 (UTC)<br />
<br />
== Linked to 'parted' Manual doesn't list ext3 or ext4 for fs-type ==<br />
<br />
Hi guys. Recent Arch convert here. Loving it. No bloat! Noticed this during Beginners Guid install though:<br />
<br />
In the section on using parted ( [[Beginners%27_guide#Partition_schemes]] ), it links to the Gnu parted manual at [http://www.gnu.org/software/parted/manual/parted.html#mkpart http://www.gnu.org/software/parted/manual/parted.html#mkpart] for fs-types, but the (rather dated?) manual doesn't list ext3 or ext4. At this point I 'guessed' ext2 was the right choice... Only to find that LATER in the 'Beginners Guide' page it recommended ext4. Damn! Wasn't sure if I had to go back and re-do. Seemed not. But anyway, confusing for 'Beginners'. Anyway, dare not edit the wiki being an Arch noob at this point. Keep up the good work! Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 00:53, 7 April 2015 (UTC)<br />
<br />
:Yes, this is a rather confusing concept: the file system type associated to a partition is a different thing from the file system that you later use to format that partition... It's explained in a bit clearer way in [[Wikipedia:Disk_partitioning#PC_partition_types]], but we should probably explain it better here too.<br />
:In theory, using "ext2", "ext3" or "ext4" when you use {{ic|(parted) mkpart}} shouldn't make any difference at all, as they all set the same partition type code. What does make a difference is the file system you choose when you actually format the partition in [[Beginners'_guide#Create_filesystems]].<br />
:Of course it's wise to make sure the ''fs-type'' corresponds to the file system that is going to be used, but even though I've never tested it, I guess you could use e.g. "NTFS" for ''fs-type'' and still be able to format the partition with ext4 or whatever file system you want.<br />
:— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:49, 7 April 2015 (UTC)<br />
<br />
:: Oh, so for ext3/4 one should just set fs-type to ext2 in parted (etc). Lesson learnt. A one liner would be good saying something like "If you don't know any better, set fs-type to ext2 (Which is the correct option for ext2/3/4), and then format with ext4 below." -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 23:32, 7 April 2015 (UTC)<br />
<br />
:::We needed something more generic and educational, I've added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&action=historysubmit&diff=368977&oldid=368819], I hope it's clear enough, please re-open the discussion if it's not :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:17, 8 April 2015 (UTC)<br />
<br />
::::Looks great. Loving the Arch way, community, Wiki etc. Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 08:49, 8 April 2015 (UTC)<br />
<br />
::::Actually, parted 3.2 has an explicit label for ext4: {{bc|<nowiki><br />
(parted) help mkpart <br />
mkpart PART-TYPE [FS-TYPE] START END make a partition<br />
...<br />
FS-TYPE is one of: btrfs, nilfs2, </nowiki>'''ext4, ext3'''<nowiki>, ext2, fat32, fat16, hfsx, hfs+, hfs, jfs, swsusp, linux-swap(v1), linux-swap(v0),<br />
ntfs, reiserfs, hp-ufs, sun-ufs, xfs, apfs2, apfs1, asfs, amufs5, amufs4, amufs3, amufs2, amufs1, amufs0, amufs, affs7, affs6,<br />
affs5, affs4, affs3, affs2, affs1, affs0, linux-swap, linux-swap(new), linux-swap(old)<br />
...<br />
</nowiki>}}<br />
::::If they are all mapped to the same partition code is another matter, so I'm fine with the current wording. Alternatively we could leave out FS-TYPE completely, after all it is optional (but this is not reflected in the BG).<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:41, 8 April 2015 (UTC)<br />
<br />
:::::Do we want to reopen and investigate this further? Thanks for reminding of the help command, however I can find many sources that seem to confirm that many Linux native file systems (but not all of the above!) map to 0x83: [http://www.win.tue.nl/~aeb/partitions/partition_types-1.html] [http://askubuntu.com/questions/230930/whats-the-difference-of-partition-type-and-filesystem-type] [http://www.tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x190.html] [http://thestarman.pcministry.com/asm/mbr/PartTypes.htm] [http://datarecovery.com/rd/hexadecimal-flags-for-partition-type/]. Unfortunately, as [[Wikipedia:Partition_type#Overview]] says, these codes are not standardized, so we won't be able to find an official reference. Last thing, quoting the [http://www.gnu.org/software/parted/manual/parted.html#mkpart manual], " fs-type is required for data partitions (i.e., non-extended partitions)", so I wouldn't leave it out as optional. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:46, 9 April 2015 (UTC)<br />
<br />
::::::The clearest would either be {{ic|mkpart primary linux}} or {{ic|mkpartfs ext4}} but I doubt either is supported... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:47, 9 April 2015 (UTC)<br />
<br />
:::::::I doubt too, I've [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=369201&oldid=368977 replaced] the link to the manual with "help mkpart". — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:21, 10 April 2015 (UTC)<br />
<br />
== "Internet" a proper name? ==<br />
<br />
Re [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&curid=14839&diff=370951&oldid=370932], there's an article on this: [[Wikipedia:Capitalization of "Internet"]]. It makes no clear case for either generic or proper name, so I'd also stick to the existing lower-case spelling. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 24 April 2015 (UTC)<br />
<br />
:I too tend to prefer the lower-case version for the same reasons as why we spell "telephone" and not "Telephone" etc., but I'm just noting that Wikipedia itself seems to use the upper-case version quite consistently throughout the articles. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:03, 25 April 2015 (UTC)<br />
<br />
== Should we indicate what more could be installed in Post-installation section? ==<br />
<br />
The Post-installation section is short thus kind of hard to be seen. In personal experience, my friend just installed Arch few days ago, and complained that he could not find a way to install GUI on his system by reading beginners' guide.<br />
<br />
Should we add some simple examples to the section to show that what kind of useful applications can be installed by reading the [[General recommendations]] article to make things clearer? If the simple examples were added into the section, the section will become longer and because of that, the section will be easier to be seen too.<br />
<br />
[[User:Saren|Saren]] ([[User talk:Saren|talk]]) 15:01, 11 May 2015 (UTC)<br />
<br />
:This is a general problem: people tend to ignore general information and are interested only in the specific info they need ''right now''. You can't make things clearer by showing all these specifics at once, in one sentence. The [[General recommendations]] page is there ''exactly'' to make things clearer, it is linked from the [[Main page]], the [[Beginners' guide]] at the top under the "Related articles" box and on the bottom from the [[Beginners'_guide#Post-installation|Post-installation]] section. There will always be somebody to miss the information they are looking for and there will always be somebody to point them to the right direction and everybody will be happy in the end :) [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:11, 11 May 2015 (UTC)<br />
<br />
::Exactly. However, the point is the Post-installation section is too short and only contains few lines. The section also exists on the bottom of the article. This makes section so hard to be seen. Should we add few more lines by pointing out what [[General recommendations]] can bring to them? The purpose is not providing the specific info they need for now, but redirect them into the right place by ''making the section easier to be seen''. [[User:Saren|Saren]] ([[User talk:Saren|talk]]) 15:18, 11 May 2015 (UTC)</div>Sarenhttps://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&diff=373372Talk:Beginners' guide2015-05-11T15:18:49Z<p>Saren: /* Should we indicate what more could be installed in Post-installation section? */</p>
<hr />
<div>== Unification ==<br />
=== A single, unified official install guide ===<br />
<br />
{{Note|This is based on talk/consensus in #archlinux. The official [[Installation Guide]] page is going to be expanded (or this guide could be protected, cleaned up and replace it - either works, that could be decided here).}}<br />
<br />
Previously, there has been talk here about merging with the old official install guide, and just having a single official [[Installation Guide]]. However, that didn't happen when the old guide was removed because the [[Beginners' Guide]] was (and is) too long, with too much duplication of other pages after the point where it's necessary (getting the initial network access). In order to be an "official" document, it would also have to be protected - edits by regular users would be proposed on the talk page.<br />
<br />
The installation process now always requires network access, and the ISO ships with both a browser and an IRC client, so it's not necessary to keep so much information on this page, since we have very good coverage elsewhere that surpasses the duplication here. For example, there's no need for the [[Beginners' Guide]] to explain how to do an upgrade as [[Pacman#Upgrading packages]] has much better coverage of the gritty details, and the initial install is already fully upgraded.<br />
<br />
-- [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 21:52, 28 October 2012 (UTC)<br />
<br />
:Yes, the ISO comes with a browser ({{Pkg|elinks}}), but it's not very good with formatting. Some people may prefer to actually print the guide ''(which is a waste of paper, if you ask me, but old timers may feel differently)'', or save it as a PDF/HTML and read it on whatever device they own (smartphone, tablet, etc).<br />
<br />
No need to create a section for this, just reminding that the unification would affect {{Bug|36111}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:57, 18 August 2013 (UTC)<br />
<br />
=== Define scope of the guide ===<br />
I'd like to define the scope of the guide(s) better and whether it's OK to remove certain things from the wiki instead of marking them as 'the old way' and maybe moving them to a separate article, if needed. Currently the beginners' guide still has info related to initscripts, like [https://wiki.archlinux.org/index.php/Beginners%27_Guide#Time_zone setting the timezone], but the article on time [https://wiki.archlinux.org/index.php/Time#Time_standard has not]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 09:56, 30 October 2012 (UTC)<br />
: Right now the Beginner's Guide is "A page where user can get their system installed '''without reading other pages'''". This is where the duplications come from. Maybe we can redefine it. So we can:<br />
: # Improve [[Help:Reading]]. Add some guide about Navigation, Searching, Category and Table of Contents. So users can reach the information they want more easily.<br />
: # Reduce long duplication texts. The two network configuration part is a candicate. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:46, 31 October 2012 (UTC)<br />
:The reason for using the manual way of configuring is actually because timedatectl and friends won't work from inside a chroot. We could avoid that by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all) but that would require some minor restructuring, so it's something worth discussing. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 17:28, 3 November 2012 (UTC)<br />
<br />
::''[This comment was pasted here from a different, now deleted discussion]''<br />
:: I think that the goal of the Beginners' Guide is not only to let an Arch novice install the system successfully, but also to introduce him to how an Arch Linux system is structured and the technologies it's based on: we shouldn't think of the Beginners' Guide (or any other article) as a simple howto or step-by-step guide, but as something more formative. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:40, 19 September 2012 (UTC)<br />
<br />
=== Plan ===<br />
If someone was interested and had the time to lay out here a '''detailed''' plan with indications on where to merge every section of the guide and a report of all the problems that could be encountered in the process, it would definitely be the final step before announcing the unification on the forums with full support from the admins, which would mean that at that point only strong and reasonable objections could prevent the unification. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:44, 18 August 2013 (UTC)<br />
<br />
Here is a list of sections that should be merged. Feel free to expand, comment in [[#Comments]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:26, 31 August 2013 (UTC)<br />
<br />
* [[Beginners'_guide#Without_wifi-menu]] -- merge into [[Wireless_network_configuration#Getting_some_useful_information]], leave link to target<br />
* [[Beginners%27_guide#Hardware_clock]] - merge to [[Time]], leave link to target, see [[#Hardware_clock_section]]<br />
* Merge common parts between [[Beginners' guide#Establish an internet connection]] and [[Beginners' guide#Configure_the_network]] into [[Network configuration]] and just link there.<br />
* [[Beginners' guide#Prepare the storage devices]] - Contains more information on parted than the actual [[parted]], merge back details <br />
<br />
==== General problems ====<br />
<br />
* ''timedatectl'', ''hostnamectl'', ''localectl'' etc. won't work from inside a chroot, so manual method of configuration is required. This could be avoided by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all). (mentioned in [[#Define scope of the guide]] by [[User:Thestinger]])<br />
<br />
::You might say these are important enough to have users execute by hand (and thus get a better understanding of, hopefully). But as the underlying processes are explained well enough in their respective articles, I'm fine either way. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:34, 20 February 2015 (UTC)<br />
<br />
* Instructions should be clear and concise, taking the [[Installation guide]] as example.<br />
<br />
* [[Beginners'_guide#Troubleshooting_boot_problems]] lacks coherence, and may need expansion. See [[#Blacklisting radeon module]].<br />
<br />
* Add short introduction on differences between BG and other wiki pages. See [[#Installation template]].<br />
<br />
==== Comments ====<br />
<br />
=== Installation template ===<br />
<br />
Another alternative way to unify the two main guides would be to follow the same philosophy we used to write the scenarios in [[Dm-crypt_with_LUKS/Encrypting_an_entire_system]], originally discussed in [[Talk:Dm-crypt#New_idea]]: the new installation guide could be a bare, though ''complete'', list of commands and simple instructions needed to install the system in one example scenario, with links to the various relevant articles for detailed information and adaptations to specific cases. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:18, 27 March 2014 (UTC)<br />
<br />
:Well, the Beginners' guide suffers from issues related to both content and style, and I really think they need to be addressed at the same time. Every suggestion so far deals only with one problem.<br />
:'''Content:''' I agree that the purpose of the guide (be it Beginners' or Installation) should be to describe only one scenario and provide links to other articles describing the alternatives. I really like ''this part'' of your suggestion, but it solves only half of the problem.<br />
:'''Style:''' The biggest problem is that Beginners' guide is unique mixture of ''introduction to reading ArchWiki'' and ''introduction to installing and '''using''' Arch Linux'', which are simply inseparable in the context of BG - you just can't expect newcomers to first read [[Help:Reading]] and only then start installing their system. So, there is a little bit of anarchy, as the BG is mostly excused from the [[Help:Style|style guidelines]] and there are no guidelines specifically for the BG. Unifying the two guides would necessarily mean a compromise regarding style, which would not be the best for either beginners or gurus.<br />
:Also, I think that it is a good thing that BG is readable ''without reading other pages'' (as defined in [[#Define scope of the guide]]), because it implies that the most important things have been collected and the readers don't have to click-and-search ''too much''. This is really important for the newcomers, because the orientation in the graph of internal links (I wanted to visualize the graph, but it's just too big) is really difficult - they would need to read dozens of pages (with some [[Help:Style|alien style]] applied) before they had the basic system running. On the other hand, one of the main points of BG should be to prepare the readers for other ArchWiki articles, but sometimes the readers are [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=291207&oldid=285657 too] [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=304473&oldid=295238 spoiled].<br />
:Well, that is my defence of keeping both IG and BG. In my opinion it is enough to just properly define the scope of BG and trim it down to ease the maintenance, addressing the ''content'' part. But of course if there is a suggestion on merging the two guides addressing the ''style'' issues, let's hear it!<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:16, 30 March 2014 (UTC)<br />
<br />
::About the style issue, I don't think experienced users would be so bothered by some pacman, systemctl or nano examples, and the unified guide should probably explicitly warn users that they won't find similar examples in the other articles, which would be a perfect way to invite them to become familiar with [[pacman]], [[systemd]], [[Help:Reading]]... Besides, if the guide will be properly structured, experienced users who don't have their own custom installation notes will be able to just follow the automatic ToC as a memory refresher.<br />
::I disagree that the fact that the "BG is readable ''without reading other pages''" is a good thing, as that's exactly the reason that makes it hard to maintain and encourages duplication of information; if users were used to follow links instead, most of the efforts now spent in improving the BG would be instead spent in properly improving the linked articles, which would then become as easy to follow as the BG is now.<br />
::Anyway, I've proposed a change in [[#Comments]] (under [[#Plan]]) that I think should be more likely to reach general consensus, and that would already be a good step forward.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:35, 31 March 2014 (UTC)<br />
<br />
:::I'm beginning to understand the need for merging. After the BG is slimmed down to cover only one example scenario, the title will be just wrong and the scope will be ''exactly'' the same as for IG. It all depends on whether different target audience and related style differences are enough to justify two guides.<br />
:::I hate being the blocker, so let's slim down BG and when it comes to the point of merging with IG, at least it will not be so shocking. I can't help but to think about it as simple redirecting of BG to IG, which will be (more or less) the eventual outcome, so I will need some time to absorb.<br />
:::Finally, we should also look at [[ArchWiki:Requests#Cleanup: installation category]], so that [[:Category:Getting and installing Arch]] is actually useful for providing alternative scenarios, and to ensure there is a place where to move excessive information from the BG.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 7 April 2014 (UTC)<br />
<br />
::::You are not "the blocker", every opinion is as valuable as the others if well argumented, be it for or against the proposal. Especially in this case where we seem to be the only 2 people interested in discussing...<br />
::::If the unification will eventually be completed, of course the BG will become a redirect to the IG, and the latter will be unprotected (and well watched so it's not turned again into a BG).<br />
::::Let's go on with the change very gradually, that's definitely the best way to let everyone successfully and happily adapt to the new way of following the document, which, if done properly, will be even easier and clearer (no need to compare two guides anymore, just to mention an advantage).<br />
::::Of course [[ArchWiki:Requests#Cleanup: installation category]] is strictly linked to all this, I'll try to get there too.<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:26, 9 April 2014 (UTC)<br />
<br />
:::::I personally would suggest leaving the Installation guide locked after the merger (even if that would lock me out also :). Thing is, if someone went through the effort of researching an addition to the guide, it would be easy for them to bring it up here, in the talk page, and easier for the community to discuss (and implement, if applicable). <br />
:::::Leaving the Installation guide unprotected however would make it open to hasty edits. Even if the IG were well watched as said, a made edit's context may not be sufficiently clear to "judge" it on the spot (confirmed by [[ArchWiki:Reports]]). Having contested content remain (however short) on the main, "official" installation reference is less than ideal.<br />
:::::A compromise may be similar to the [[IRC]] page, which is not protected in the technical sense, but has a warning urging users not to edit the page without prior consensus. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:30, 19 February 2015 (UTC)<br />
<br />
::::::Once upon a time, I absolutely don't even remember where, we even discussed the option of keeping the guide in a protected page, but do all the modifications in a separate open page (as if they were two "master" and "devel" branches), with the admins periodically approving and merging the unstable page into the official one. Thanks to the recently introduced [[Special:MergeHistory]] tool, this job could be easier nowadays. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:06, 20 February 2015 (UTC)<br />
<br />
:::::::That sounds like a good option. Working hypothesis: to make users accustomed to the idea, we could now add a note at the top of the BG, suggesting to first discuss changes on the talk page. After the merger this note would then point to the "development" page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:39, 16 March 2015 (UTC)<br />
<br />
::::::::I think that [[Special:MergeHistory]] is too primitive tool for this, AFAIK its only way of operation is "merge all revisions ''up to'' specified one", i.e. there is no ''cherry-picking'' of feasible revisions. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:50, 16 March 2015 (UTC)<br />
<br />
:::::::::@Alad I'm still thinking about it, I'm not sure whether having 2 protected installation guides would be too confusing. The branch method would certainly be well suited if we really ended up merging the guides into one.<br />
:::::::::@Lahwaacz The way it would work would be (''master'' is protected, contains the whole revisions history and ''will not receive direct edits'' by anyone, including admins):<br />
:::::::::# ''develop'' is initialized with a simple copy of the latest revision of ''master''<br />
:::::::::# Some users make some edits to ''develop''<br />
:::::::::# The wiki staff amends/undos ''develop'' as necessary with additional edits (like it happens now in the only branch)<br />
:::::::::# Once ''develop'' is considered in a good state, [[Special:MergeHistory]] can be used safely, no need for cherry-picking<br />
:::::::::# Go back to 1 (at this step ''develop'' is a redirect to ''master'')<br />
:::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:09, 17 March 2015 (UTC)<br />
<br />
:::::::::A simpler alternative with the same effect would be maintaining a link that points to the latest officially approved revision in the history of the article, for example in a Note in the intro. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:13, 17 March 2015 (UTC)<br />
<br />
::::::::::Take your time, it will take a lot more work to get the BG anywhere near ready for merging. A link with note sounds viable as well; we could add a table with different options below. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:08, 17 March 2015 (UTC)<br />
<br />
== Blacklisting radeon module ==<br />
<br />
Installed Arch on my laptop, during pacstrap the screen went blank, pressing SPACE, CTL+C ... didn't helped only modprobe.blacklist=radeon enabled me to go through the whole installation process.<br />
My graphic card is ATI M96 aka Mobility Radeon HD 4650.<br />
I believe this info and similar problems should be added to the beginner's guide on a Installation's Issues Troubleshooting section. I believe this is important enough to dual post and separate it from the Removing "Kernel modules" talk. p.s. I may add that this is my first desktop Linux experience--[[User:Dhead|Dhead]] ([[User talk:Dhead|talk]]) 06:20, 4 March 2013 (UTC)<br />
<br />
:The beginners' guide should not contain hardware-specific info, if the issue is common enough links can be added to [[Beginners%27_guide#Troubleshooting_boot_problems]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:40, 27 December 2014 (UTC)<br />
<br />
== Newbie here offering thoughts on what could be changed in guide ==<br />
<br />
=== General troubleshooting ===<br />
<br />
Apart from that there should be a section at the very beginning explaining how to troubleshoot your own problems. Learning dmesg -HLkd and journalctl -b etc were helpful tools for me. I also appreciated learning lsblk, lsmod, ls etc from the various articles, but a quick over view of these helpful commands on this page would help newbies like myself. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
: Sorry! Just reading over again, and realizing that I could've saved a tonne of time if I knew the problem of "a bunch of white letters clustered on my screen" was an error I could check. It usually happened when the firmware didn't support something (in my case) but telling the user what he can do when this happens helps ease the wiki hopping. I finally, finally figured out how to debug most of my own problems and I think that is the number one thing this guide should do. No offense, but it would also lessen the load on the "newbie corner" on the forums (not that I know it's loaded or not, but less is better, right?). That way no matter what's written in the guide, if it's incorrect or leads to a bad result, the user can figure out why and what to do.. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:05, 7 June 2013 (UTC)<br />
<br />
:: Another [[Keyboard_Shortcuts|useful article]] that could be mentioned (rebooting from black screens, yay!) [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 00:27, 8 June 2013 (UTC)<br />
<br />
:::Regarding your second point, [[General troubleshooting]] is in Related articles - it could be expanded there. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:25, 2 July 2014 (UTC)<br />
<br />
=== Mounting partitions and dual-boot ===<br />
<br />
And lastly, the surprisingly tricky bit about "mounting" partitions that do not belong to you on a dual boot system. Ultimately for me what ended up working was knowing which file systems the others could read (esp in a UEFI system). These things can't just be "linked" to because even the pages linked to don't have the information. I got quite a bit of help from friends and google. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
== Gummiboot instructions are out of order. ==<br />
<br />
I'm not certain if this is the same issue as the heading "gummiboot instructions are confusing?", but I encountered this using the Beginner's guide. In "2.4 Mount the partitions", it mentions that you should mount the ESP at /boot. But then in "2.8 Chroot and configure the base system", the root is changed to the new system's mountpoint, and /boot no longer refers to the mounted ESP partition (because this was mounted in the live installation CD, in zsh). When in "2.12.2 For UEFI motherboards" I run the gummiboot install command, it errors saying that it is not a fat32 partition. Furthermore, I'm not sure if I need to actually have the initramfs files that were made during pacstrap in the actual ESP since they were installed to /boot. (My thought is they should be, because the assumption was that the ESP has actually been mounted on /boot since before pacstrap was run.) <br />
<br />
I'm not certain what to do. (I'm new, this is my first time going through this guide.) Could someone please review this? Or perhaps I made a mistake somewhere...?<br />
<br />
[[User:Tmarks|Tmarks]] ([[User talk:Tmarks|talk]]) 14:23, 11 October 2014 (UTC)<br />
<br />
: Hmmm... After that there's a command telling about mounting to {{ic|/mnt/boot}}, so people must mount it correctly to {{ic|/mnt/boot}}. But I think you are right, I's a bit confusing and we should replace preceding {{ic|/boot}} with {{ic|/mnt/boot}} -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 11:00, 15 October 2014 (UTC)<br />
<br />
::I am not sure I follow this completely; the quoted section numbers anyhow. [[Beginners' guide#For UEFI motherboards]] states "It is strongly recommended to have the EFI System Partition mounted at /boot as this is required to automatically update Gummiboot." and then "(replace) $esp with the location of your EFI System Partiton, usually /boot" right before the gummiboot install. Maybe it was updated meanwhile, do we need to adjust something? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:54, 2 January 2015 (UTC)<br />
<br />
== Hardware clock section ==<br />
<br />
The '''Hardware clock''' section instructs users to set their hardware clock to UTC time:<br />
<br />
# hwclock --systohc --utc<br />
<br />
without explaining that this will actually reset the BIOS clock setting. Users are then warned that ''Using localtime on Arch systems may lead to several known and unfixable bugs''.<br />
<br />
Question: what might those unfixable bugs be? I've been following these instructions fairly rigorously on every Arch system I've installed, but just got burned by the clock setting, as I think I spaced out and reset the BIOS clock to localtime, so outgoing mail on the system was thrown off by several hours for a couple of days until one of the users alerted me to the problem. Setting the system clock to UTC is kind of confusing, particularly for beginners. What are the unfixable bugs from doing this? If these don't actually exist I would suggest just setting the hardware clock to localtime. This allows you to check the accuracy of the RTC when snooping around in the BIOS.<br />
<br />
# hwclock --systohc --localtime<br />
<br />
And if there really are unfixable bugs, users should be told that the hardware clock is going to be set to an unfamiliar value, so they don't freak out when they go in the system setup and find that the clock is off by several hours from the time they thought it should be. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 22:33, 5 February 2015 (UTC)<br />
<br />
:[https://lists.archlinux.org//listinfo/arch-general/ arch-general] is a probably a better place to discuss this. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:47, 6 February 2015 (UTC)<br />
<br />
::OK, I added a note explaining that this command would reset the RTC clock, which is probably good enough for the Beginner's Guide. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 08:44, 6 February 2015 (UTC)<br />
<br />
:::I've just finished [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=359876&oldid=359646 expanding] that section, I hope it clarifies some of the doubts. Regarding the unspecified "several known and unfixable bugs" I second the suggestion to ask in the mailing list. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:22, 7 February 2015 (UTC)<br />
<br />
::::Thanks for making those edits -- it's much clearer now. I also like your simplification of my comment. Based on my own experience, it's important to point this out explicitly (that the BIOS clock setting will look funny) even if it is implicitly obvious, if you think about it. "Don't make me think" is not just a rule that applies to websites. <:) -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 09:52, 7 February 2015 (UTC)<br />
<br />
:::::I think the description is good, but a bit verbose for the BG (particularly as this is about booting multiple operations systems, namely Windows). [http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html ut-rc] (linked from [[Time#Time_standard]]) provides some more background, also on the "unfixable bugs".<br />
:::::I'd suggest to merge the more elaborate description to [[Time]], provide a short paragraph on Windows and localtime (and unexpected BIOS clock), and link to the above website. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:34, 22 February 2015 (UTC)<br />
<br />
::::::If you manage to merge the section into [[Time]] I think it's a good thing; I also think the external link can be kept only there: if we want to make the section brief, I'd say that what the readers need to know from the BG is only that they have to make sure the hw clock is set to UTC time and that all the other installed OSs must be set accordingly (Arch will consider the hw clock to be set to UTC by default). Then, if they want to know why, or if they want to use localtime for some reason, they can be sent to read [[Time]] to understand all the pros and the cons. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:15, 23 February 2015 (UTC)<br />
<br />
== Static IP ==<br />
<br />
I'd like to discuss whether to keep [[#Beginners' guide#Static IP]] or not. [[dhcpcd#Fallback static profile]] could easily be expanded to cover this, and most (home) routers provide DHCP by default. Having the information in [[dhcpcd]] also benefits [[Beginners' guide#Wired]] which directly links to that article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:20, 28 March 2015 (UTC)<br />
<br />
:I assume you'd replace it with a link to [[dhcpcd#Fallback static profile]], +1 from me. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:19, 29 March 2015 (UTC)<br />
<br />
:I'm -1 on this idea. Fallback is useful for headless installs, yes, but that's not a BG topic.? If a user starts configuring [[Beginners' guide#Static IP]], this means default ISO booting DHCP has failed. Making a static connection fallback only delays startup further in this case.. because DHCP will fail again first. <br />
:Sidenote: What one might consider, is open a flyspray suggesting the ISO default dhcpcd config could gain a fallback static IP config (with both 192.168.* and 10.10.* IPs/routes it would probably be reachable for the majority of routers). <s>Doing such might be considered network intrusive by some users though.</s> edit: since it would be a passive config, not really intrusive. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:57, 29 March 2015 (UTC)<br />
<br />
::Well, the idea is to change/expand the dhcpcd section first to include fallback as a sub-section. The main content would be a regular static profile, with info merged from the BG, and named [[dhcpcd#Static profile]]. I like suggesting a default config though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:16, 29 March 2015 (UTC)<br />
<br />
:::Please drop a quick note, if you open a bug for it (I do the same). Sub-section or not, this part makes no sense for BG readers of that section imo. Moving the current dhcpcd content of the section, ok - but that's a neat seven lines including code and not really worth it. Moving the whole section comes at the expense of having it verbose incl. interface identification in [[dhcpcd]]. I'm neutral on that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:45, 29 March 2015 (UTC)<br />
<br />
::::I also doubted if it was worth the effort, hence my asking. Still, I'd like some relation to the chroot section, if only a Tip for users to save/copy their config for later use. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:21, 1 April 2015 (UTC)<br />
<br />
:::::Good idea, added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=368819&oldid=368817]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:41, 6 April 2015 (UTC)<br />
<br />
== Linked to 'parted' Manual doesn't list ext3 or ext4 for fs-type ==<br />
<br />
Hi guys. Recent Arch convert here. Loving it. No bloat! Noticed this during Beginners Guid install though:<br />
<br />
In the section on using parted ( [[Beginners%27_guide#Partition_schemes]] ), it links to the Gnu parted manual at [http://www.gnu.org/software/parted/manual/parted.html#mkpart http://www.gnu.org/software/parted/manual/parted.html#mkpart] for fs-types, but the (rather dated?) manual doesn't list ext3 or ext4. At this point I 'guessed' ext2 was the right choice... Only to find that LATER in the 'Beginners Guide' page it recommended ext4. Damn! Wasn't sure if I had to go back and re-do. Seemed not. But anyway, confusing for 'Beginners'. Anyway, dare not edit the wiki being an Arch noob at this point. Keep up the good work! Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 00:53, 7 April 2015 (UTC)<br />
<br />
:Yes, this is a rather confusing concept: the file system type associated to a partition is a different thing from the file system that you later use to format that partition... It's explained in a bit clearer way in [[Wikipedia:Disk_partitioning#PC_partition_types]], but we should probably explain it better here too.<br />
:In theory, using "ext2", "ext3" or "ext4" when you use {{ic|(parted) mkpart}} shouldn't make any difference at all, as they all set the same partition type code. What does make a difference is the file system you choose when you actually format the partition in [[Beginners'_guide#Create_filesystems]].<br />
:Of course it's wise to make sure the ''fs-type'' corresponds to the file system that is going to be used, but even though I've never tested it, I guess you could use e.g. "NTFS" for ''fs-type'' and still be able to format the partition with ext4 or whatever file system you want.<br />
:— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:49, 7 April 2015 (UTC)<br />
<br />
:: Oh, so for ext3/4 one should just set fs-type to ext2 in parted (etc). Lesson learnt. A one liner would be good saying something like "If you don't know any better, set fs-type to ext2 (Which is the correct option for ext2/3/4), and then format with ext4 below." -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 23:32, 7 April 2015 (UTC)<br />
<br />
:::We needed something more generic and educational, I've added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&action=historysubmit&diff=368977&oldid=368819], I hope it's clear enough, please re-open the discussion if it's not :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:17, 8 April 2015 (UTC)<br />
<br />
::::Looks great. Loving the Arch way, community, Wiki etc. Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 08:49, 8 April 2015 (UTC)<br />
<br />
::::Actually, parted 3.2 has an explicit label for ext4: {{bc|<nowiki><br />
(parted) help mkpart <br />
mkpart PART-TYPE [FS-TYPE] START END make a partition<br />
...<br />
FS-TYPE is one of: btrfs, nilfs2, </nowiki>'''ext4, ext3'''<nowiki>, ext2, fat32, fat16, hfsx, hfs+, hfs, jfs, swsusp, linux-swap(v1), linux-swap(v0),<br />
ntfs, reiserfs, hp-ufs, sun-ufs, xfs, apfs2, apfs1, asfs, amufs5, amufs4, amufs3, amufs2, amufs1, amufs0, amufs, affs7, affs6,<br />
affs5, affs4, affs3, affs2, affs1, affs0, linux-swap, linux-swap(new), linux-swap(old)<br />
...<br />
</nowiki>}}<br />
::::If they are all mapped to the same partition code is another matter, so I'm fine with the current wording. Alternatively we could leave out FS-TYPE completely, after all it is optional (but this is not reflected in the BG).<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:41, 8 April 2015 (UTC)<br />
<br />
:::::Do we want to reopen and investigate this further? Thanks for reminding of the help command, however I can find many sources that seem to confirm that many Linux native file systems (but not all of the above!) map to 0x83: [http://www.win.tue.nl/~aeb/partitions/partition_types-1.html] [http://askubuntu.com/questions/230930/whats-the-difference-of-partition-type-and-filesystem-type] [http://www.tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x190.html] [http://thestarman.pcministry.com/asm/mbr/PartTypes.htm] [http://datarecovery.com/rd/hexadecimal-flags-for-partition-type/]. Unfortunately, as [[Wikipedia:Partition_type#Overview]] says, these codes are not standardized, so we won't be able to find an official reference. Last thing, quoting the [http://www.gnu.org/software/parted/manual/parted.html#mkpart manual], " fs-type is required for data partitions (i.e., non-extended partitions)", so I wouldn't leave it out as optional. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:46, 9 April 2015 (UTC)<br />
<br />
::::::The clearest would either be {{ic|mkpart primary linux}} or {{ic|mkpartfs ext4}} but I doubt either is supported... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:47, 9 April 2015 (UTC)<br />
<br />
:::::::I doubt too, I've [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=369201&oldid=368977 replaced] the link to the manual with "help mkpart". — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:21, 10 April 2015 (UTC)<br />
<br />
== "Internet" a proper name? ==<br />
<br />
Re [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&curid=14839&diff=370951&oldid=370932], there's an article on this: [[Wikipedia:Capitalization of "Internet"]]. It makes no clear case for either generic or proper name, so I'd also stick to the existing lower-case spelling. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 24 April 2015 (UTC)<br />
<br />
:I too tend to prefer the lower-case version for the same reasons as why we spell "telephone" and not "Telephone" etc., but I'm just noting that Wikipedia itself seems to use the upper-case version quite consistently throughout the articles. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:03, 25 April 2015 (UTC)<br />
<br />
== Should we indicate what more could be installed in Post-installation section? ==<br />
<br />
The Post-installation section is short thus kind of hard to be seen. In personal experience, my friend just installed Arch few days ago, and complained that he could not find a way to install GUI on his system by reading beginners' guide.<br />
<br />
Should we add some simple examples to the section to show that what kind of useful applications can be installed by reading the [[General recommendations]] article to make things clearer? If the simple examples were added into the section, the section will become longer and because of that, the section will be easier to be seen too.<br />
<br />
[[User:Saren|Saren]] ([[User talk:Saren|talk]]) 15:01, 11 May 2015 (UTC)<br />
<br />
:This is a general problem: people tend to ignore general information and are interested only in the specific info they need ''right now''. You can't make things clearer by showing all these specifics at once, in one sentence. The [[General recommendations]] page is there ''exactly'' to make things clearer, it is linked from the [[Main page]], the [[Beginners' guide]] at the top under the "Related articles" box and on the bottom from the [[Beginners'_guide#Post-installation|Post-installation]] section. There will always be somebody to miss the information they are looking for and there will always be somebody to point them to the right direction and everybody will be happy in the end :) [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 15:11, 11 May 2015 (UTC)<br />
<br />
::Exactly. However, the point is the Post-installation section is too short and only contains few lines. The section also exists on the bottom of the article. This makes section so hard to be seen. Should we add few more lines by pointing out what [[General recommendations]] can bring to them? The purpose is not providing the specific info they need for now, but redirect them into the right place. [[User:Saren|Saren]] ([[User talk:Saren|talk]]) 15:18, 11 May 2015 (UTC)</div>Sarenhttps://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&diff=373369Talk:Beginners' guide2015-05-11T15:01:10Z<p>Saren: /* Should we indicate what more could be installed in Post-installation section? */</p>
<hr />
<div>== Unification ==<br />
=== A single, unified official install guide ===<br />
<br />
{{Note|This is based on talk/consensus in #archlinux. The official [[Installation Guide]] page is going to be expanded (or this guide could be protected, cleaned up and replace it - either works, that could be decided here).}}<br />
<br />
Previously, there has been talk here about merging with the old official install guide, and just having a single official [[Installation Guide]]. However, that didn't happen when the old guide was removed because the [[Beginners' Guide]] was (and is) too long, with too much duplication of other pages after the point where it's necessary (getting the initial network access). In order to be an "official" document, it would also have to be protected - edits by regular users would be proposed on the talk page.<br />
<br />
The installation process now always requires network access, and the ISO ships with both a browser and an IRC client, so it's not necessary to keep so much information on this page, since we have very good coverage elsewhere that surpasses the duplication here. For example, there's no need for the [[Beginners' Guide]] to explain how to do an upgrade as [[Pacman#Upgrading packages]] has much better coverage of the gritty details, and the initial install is already fully upgraded.<br />
<br />
-- [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 21:52, 28 October 2012 (UTC)<br />
<br />
:Yes, the ISO comes with a browser ({{Pkg|elinks}}), but it's not very good with formatting. Some people may prefer to actually print the guide ''(which is a waste of paper, if you ask me, but old timers may feel differently)'', or save it as a PDF/HTML and read it on whatever device they own (smartphone, tablet, etc).<br />
<br />
No need to create a section for this, just reminding that the unification would affect {{Bug|36111}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:57, 18 August 2013 (UTC)<br />
<br />
=== Define scope of the guide ===<br />
I'd like to define the scope of the guide(s) better and whether it's OK to remove certain things from the wiki instead of marking them as 'the old way' and maybe moving them to a separate article, if needed. Currently the beginners' guide still has info related to initscripts, like [https://wiki.archlinux.org/index.php/Beginners%27_Guide#Time_zone setting the timezone], but the article on time [https://wiki.archlinux.org/index.php/Time#Time_standard has not]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 09:56, 30 October 2012 (UTC)<br />
: Right now the Beginner's Guide is "A page where user can get their system installed '''without reading other pages'''". This is where the duplications come from. Maybe we can redefine it. So we can:<br />
: # Improve [[Help:Reading]]. Add some guide about Navigation, Searching, Category and Table of Contents. So users can reach the information they want more easily.<br />
: # Reduce long duplication texts. The two network configuration part is a candicate. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:46, 31 October 2012 (UTC)<br />
:The reason for using the manual way of configuring is actually because timedatectl and friends won't work from inside a chroot. We could avoid that by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all) but that would require some minor restructuring, so it's something worth discussing. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 17:28, 3 November 2012 (UTC)<br />
<br />
::''[This comment was pasted here from a different, now deleted discussion]''<br />
:: I think that the goal of the Beginners' Guide is not only to let an Arch novice install the system successfully, but also to introduce him to how an Arch Linux system is structured and the technologies it's based on: we shouldn't think of the Beginners' Guide (or any other article) as a simple howto or step-by-step guide, but as something more formative. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:40, 19 September 2012 (UTC)<br />
<br />
=== Plan ===<br />
If someone was interested and had the time to lay out here a '''detailed''' plan with indications on where to merge every section of the guide and a report of all the problems that could be encountered in the process, it would definitely be the final step before announcing the unification on the forums with full support from the admins, which would mean that at that point only strong and reasonable objections could prevent the unification. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:44, 18 August 2013 (UTC)<br />
<br />
Here is a list of sections that should be merged. Feel free to expand, comment in [[#Comments]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:26, 31 August 2013 (UTC)<br />
<br />
* [[Beginners'_guide#Without_wifi-menu]] -- merge into [[Wireless_network_configuration#Getting_some_useful_information]], leave link to target<br />
* [[Beginners%27_guide#Hardware_clock]] - merge to [[Time]], leave link to target, see [[#Hardware_clock_section]]<br />
* Merge common parts between [[Beginners' guide#Establish an internet connection]] and [[Beginners' guide#Configure_the_network]] into [[Network configuration]] and just link there.<br />
* [[Beginners' guide#Prepare the storage devices]] - Contains more information on parted than the actual [[parted]], merge back details <br />
<br />
==== General problems ====<br />
<br />
* ''timedatectl'', ''hostnamectl'', ''localectl'' etc. won't work from inside a chroot, so manual method of configuration is required. This could be avoided by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all). (mentioned in [[#Define scope of the guide]] by [[User:Thestinger]])<br />
<br />
::You might say these are important enough to have users execute by hand (and thus get a better understanding of, hopefully). But as the underlying processes are explained well enough in their respective articles, I'm fine either way. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:34, 20 February 2015 (UTC)<br />
<br />
* Instructions should be clear and concise, taking the [[Installation guide]] as example.<br />
<br />
* [[Beginners'_guide#Troubleshooting_boot_problems]] lacks coherence, and may need expansion. See [[#Blacklisting radeon module]].<br />
<br />
* Add short introduction on differences between BG and other wiki pages. See [[#Installation template]].<br />
<br />
==== Comments ====<br />
<br />
=== Installation template ===<br />
<br />
Another alternative way to unify the two main guides would be to follow the same philosophy we used to write the scenarios in [[Dm-crypt_with_LUKS/Encrypting_an_entire_system]], originally discussed in [[Talk:Dm-crypt#New_idea]]: the new installation guide could be a bare, though ''complete'', list of commands and simple instructions needed to install the system in one example scenario, with links to the various relevant articles for detailed information and adaptations to specific cases. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:18, 27 March 2014 (UTC)<br />
<br />
:Well, the Beginners' guide suffers from issues related to both content and style, and I really think they need to be addressed at the same time. Every suggestion so far deals only with one problem.<br />
:'''Content:''' I agree that the purpose of the guide (be it Beginners' or Installation) should be to describe only one scenario and provide links to other articles describing the alternatives. I really like ''this part'' of your suggestion, but it solves only half of the problem.<br />
:'''Style:''' The biggest problem is that Beginners' guide is unique mixture of ''introduction to reading ArchWiki'' and ''introduction to installing and '''using''' Arch Linux'', which are simply inseparable in the context of BG - you just can't expect newcomers to first read [[Help:Reading]] and only then start installing their system. So, there is a little bit of anarchy, as the BG is mostly excused from the [[Help:Style|style guidelines]] and there are no guidelines specifically for the BG. Unifying the two guides would necessarily mean a compromise regarding style, which would not be the best for either beginners or gurus.<br />
:Also, I think that it is a good thing that BG is readable ''without reading other pages'' (as defined in [[#Define scope of the guide]]), because it implies that the most important things have been collected and the readers don't have to click-and-search ''too much''. This is really important for the newcomers, because the orientation in the graph of internal links (I wanted to visualize the graph, but it's just too big) is really difficult - they would need to read dozens of pages (with some [[Help:Style|alien style]] applied) before they had the basic system running. On the other hand, one of the main points of BG should be to prepare the readers for other ArchWiki articles, but sometimes the readers are [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=291207&oldid=285657 too] [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=304473&oldid=295238 spoiled].<br />
:Well, that is my defence of keeping both IG and BG. In my opinion it is enough to just properly define the scope of BG and trim it down to ease the maintenance, addressing the ''content'' part. But of course if there is a suggestion on merging the two guides addressing the ''style'' issues, let's hear it!<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:16, 30 March 2014 (UTC)<br />
<br />
::About the style issue, I don't think experienced users would be so bothered by some pacman, systemctl or nano examples, and the unified guide should probably explicitly warn users that they won't find similar examples in the other articles, which would be a perfect way to invite them to become familiar with [[pacman]], [[systemd]], [[Help:Reading]]... Besides, if the guide will be properly structured, experienced users who don't have their own custom installation notes will be able to just follow the automatic ToC as a memory refresher.<br />
::I disagree that the fact that the "BG is readable ''without reading other pages''" is a good thing, as that's exactly the reason that makes it hard to maintain and encourages duplication of information; if users were used to follow links instead, most of the efforts now spent in improving the BG would be instead spent in properly improving the linked articles, which would then become as easy to follow as the BG is now.<br />
::Anyway, I've proposed a change in [[#Comments]] (under [[#Plan]]) that I think should be more likely to reach general consensus, and that would already be a good step forward.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:35, 31 March 2014 (UTC)<br />
<br />
:::I'm beginning to understand the need for merging. After the BG is slimmed down to cover only one example scenario, the title will be just wrong and the scope will be ''exactly'' the same as for IG. It all depends on whether different target audience and related style differences are enough to justify two guides.<br />
:::I hate being the blocker, so let's slim down BG and when it comes to the point of merging with IG, at least it will not be so shocking. I can't help but to think about it as simple redirecting of BG to IG, which will be (more or less) the eventual outcome, so I will need some time to absorb.<br />
:::Finally, we should also look at [[ArchWiki:Requests#Cleanup: installation category]], so that [[:Category:Getting and installing Arch]] is actually useful for providing alternative scenarios, and to ensure there is a place where to move excessive information from the BG.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 7 April 2014 (UTC)<br />
<br />
::::You are not "the blocker", every opinion is as valuable as the others if well argumented, be it for or against the proposal. Especially in this case where we seem to be the only 2 people interested in discussing...<br />
::::If the unification will eventually be completed, of course the BG will become a redirect to the IG, and the latter will be unprotected (and well watched so it's not turned again into a BG).<br />
::::Let's go on with the change very gradually, that's definitely the best way to let everyone successfully and happily adapt to the new way of following the document, which, if done properly, will be even easier and clearer (no need to compare two guides anymore, just to mention an advantage).<br />
::::Of course [[ArchWiki:Requests#Cleanup: installation category]] is strictly linked to all this, I'll try to get there too.<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:26, 9 April 2014 (UTC)<br />
<br />
:::::I personally would suggest leaving the Installation guide locked after the merger (even if that would lock me out also :). Thing is, if someone went through the effort of researching an addition to the guide, it would be easy for them to bring it up here, in the talk page, and easier for the community to discuss (and implement, if applicable). <br />
:::::Leaving the Installation guide unprotected however would make it open to hasty edits. Even if the IG were well watched as said, a made edit's context may not be sufficiently clear to "judge" it on the spot (confirmed by [[ArchWiki:Reports]]). Having contested content remain (however short) on the main, "official" installation reference is less than ideal.<br />
:::::A compromise may be similar to the [[IRC]] page, which is not protected in the technical sense, but has a warning urging users not to edit the page without prior consensus. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:30, 19 February 2015 (UTC)<br />
<br />
::::::Once upon a time, I absolutely don't even remember where, we even discussed the option of keeping the guide in a protected page, but do all the modifications in a separate open page (as if they were two "master" and "devel" branches), with the admins periodically approving and merging the unstable page into the official one. Thanks to the recently introduced [[Special:MergeHistory]] tool, this job could be easier nowadays. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:06, 20 February 2015 (UTC)<br />
<br />
:::::::That sounds like a good option. Working hypothesis: to make users accustomed to the idea, we could now add a note at the top of the BG, suggesting to first discuss changes on the talk page. After the merger this note would then point to the "development" page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:39, 16 March 2015 (UTC)<br />
<br />
::::::::I think that [[Special:MergeHistory]] is too primitive tool for this, AFAIK its only way of operation is "merge all revisions ''up to'' specified one", i.e. there is no ''cherry-picking'' of feasible revisions. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:50, 16 March 2015 (UTC)<br />
<br />
:::::::::@Alad I'm still thinking about it, I'm not sure whether having 2 protected installation guides would be too confusing. The branch method would certainly be well suited if we really ended up merging the guides into one.<br />
:::::::::@Lahwaacz The way it would work would be (''master'' is protected, contains the whole revisions history and ''will not receive direct edits'' by anyone, including admins):<br />
:::::::::# ''develop'' is initialized with a simple copy of the latest revision of ''master''<br />
:::::::::# Some users make some edits to ''develop''<br />
:::::::::# The wiki staff amends/undos ''develop'' as necessary with additional edits (like it happens now in the only branch)<br />
:::::::::# Once ''develop'' is considered in a good state, [[Special:MergeHistory]] can be used safely, no need for cherry-picking<br />
:::::::::# Go back to 1 (at this step ''develop'' is a redirect to ''master'')<br />
:::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:09, 17 March 2015 (UTC)<br />
<br />
:::::::::A simpler alternative with the same effect would be maintaining a link that points to the latest officially approved revision in the history of the article, for example in a Note in the intro. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:13, 17 March 2015 (UTC)<br />
<br />
::::::::::Take your time, it will take a lot more work to get the BG anywhere near ready for merging. A link with note sounds viable as well; we could add a table with different options below. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:08, 17 March 2015 (UTC)<br />
<br />
== Blacklisting radeon module ==<br />
<br />
Installed Arch on my laptop, during pacstrap the screen went blank, pressing SPACE, CTL+C ... didn't helped only modprobe.blacklist=radeon enabled me to go through the whole installation process.<br />
My graphic card is ATI M96 aka Mobility Radeon HD 4650.<br />
I believe this info and similar problems should be added to the beginner's guide on a Installation's Issues Troubleshooting section. I believe this is important enough to dual post and separate it from the Removing "Kernel modules" talk. p.s. I may add that this is my first desktop Linux experience--[[User:Dhead|Dhead]] ([[User talk:Dhead|talk]]) 06:20, 4 March 2013 (UTC)<br />
<br />
:The beginners' guide should not contain hardware-specific info, if the issue is common enough links can be added to [[Beginners%27_guide#Troubleshooting_boot_problems]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:40, 27 December 2014 (UTC)<br />
<br />
== Newbie here offering thoughts on what could be changed in guide ==<br />
<br />
=== General troubleshooting ===<br />
<br />
Apart from that there should be a section at the very beginning explaining how to troubleshoot your own problems. Learning dmesg -HLkd and journalctl -b etc were helpful tools for me. I also appreciated learning lsblk, lsmod, ls etc from the various articles, but a quick over view of these helpful commands on this page would help newbies like myself. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
: Sorry! Just reading over again, and realizing that I could've saved a tonne of time if I knew the problem of "a bunch of white letters clustered on my screen" was an error I could check. It usually happened when the firmware didn't support something (in my case) but telling the user what he can do when this happens helps ease the wiki hopping. I finally, finally figured out how to debug most of my own problems and I think that is the number one thing this guide should do. No offense, but it would also lessen the load on the "newbie corner" on the forums (not that I know it's loaded or not, but less is better, right?). That way no matter what's written in the guide, if it's incorrect or leads to a bad result, the user can figure out why and what to do.. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:05, 7 June 2013 (UTC)<br />
<br />
:: Another [[Keyboard_Shortcuts|useful article]] that could be mentioned (rebooting from black screens, yay!) [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 00:27, 8 June 2013 (UTC)<br />
<br />
:::Regarding your second point, [[General troubleshooting]] is in Related articles - it could be expanded there. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:25, 2 July 2014 (UTC)<br />
<br />
=== Mounting partitions and dual-boot ===<br />
<br />
And lastly, the surprisingly tricky bit about "mounting" partitions that do not belong to you on a dual boot system. Ultimately for me what ended up working was knowing which file systems the others could read (esp in a UEFI system). These things can't just be "linked" to because even the pages linked to don't have the information. I got quite a bit of help from friends and google. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
== Gummiboot instructions are out of order. ==<br />
<br />
I'm not certain if this is the same issue as the heading "gummiboot instructions are confusing?", but I encountered this using the Beginner's guide. In "2.4 Mount the partitions", it mentions that you should mount the ESP at /boot. But then in "2.8 Chroot and configure the base system", the root is changed to the new system's mountpoint, and /boot no longer refers to the mounted ESP partition (because this was mounted in the live installation CD, in zsh). When in "2.12.2 For UEFI motherboards" I run the gummiboot install command, it errors saying that it is not a fat32 partition. Furthermore, I'm not sure if I need to actually have the initramfs files that were made during pacstrap in the actual ESP since they were installed to /boot. (My thought is they should be, because the assumption was that the ESP has actually been mounted on /boot since before pacstrap was run.) <br />
<br />
I'm not certain what to do. (I'm new, this is my first time going through this guide.) Could someone please review this? Or perhaps I made a mistake somewhere...?<br />
<br />
[[User:Tmarks|Tmarks]] ([[User talk:Tmarks|talk]]) 14:23, 11 October 2014 (UTC)<br />
<br />
: Hmmm... After that there's a command telling about mounting to {{ic|/mnt/boot}}, so people must mount it correctly to {{ic|/mnt/boot}}. But I think you are right, I's a bit confusing and we should replace preceding {{ic|/boot}} with {{ic|/mnt/boot}} -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 11:00, 15 October 2014 (UTC)<br />
<br />
::I am not sure I follow this completely; the quoted section numbers anyhow. [[Beginners' guide#For UEFI motherboards]] states "It is strongly recommended to have the EFI System Partition mounted at /boot as this is required to automatically update Gummiboot." and then "(replace) $esp with the location of your EFI System Partiton, usually /boot" right before the gummiboot install. Maybe it was updated meanwhile, do we need to adjust something? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:54, 2 January 2015 (UTC)<br />
<br />
== Hardware clock section ==<br />
<br />
The '''Hardware clock''' section instructs users to set their hardware clock to UTC time:<br />
<br />
# hwclock --systohc --utc<br />
<br />
without explaining that this will actually reset the BIOS clock setting. Users are then warned that ''Using localtime on Arch systems may lead to several known and unfixable bugs''.<br />
<br />
Question: what might those unfixable bugs be? I've been following these instructions fairly rigorously on every Arch system I've installed, but just got burned by the clock setting, as I think I spaced out and reset the BIOS clock to localtime, so outgoing mail on the system was thrown off by several hours for a couple of days until one of the users alerted me to the problem. Setting the system clock to UTC is kind of confusing, particularly for beginners. What are the unfixable bugs from doing this? If these don't actually exist I would suggest just setting the hardware clock to localtime. This allows you to check the accuracy of the RTC when snooping around in the BIOS.<br />
<br />
# hwclock --systohc --localtime<br />
<br />
And if there really are unfixable bugs, users should be told that the hardware clock is going to be set to an unfamiliar value, so they don't freak out when they go in the system setup and find that the clock is off by several hours from the time they thought it should be. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 22:33, 5 February 2015 (UTC)<br />
<br />
:[https://lists.archlinux.org//listinfo/arch-general/ arch-general] is a probably a better place to discuss this. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:47, 6 February 2015 (UTC)<br />
<br />
::OK, I added a note explaining that this command would reset the RTC clock, which is probably good enough for the Beginner's Guide. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 08:44, 6 February 2015 (UTC)<br />
<br />
:::I've just finished [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=359876&oldid=359646 expanding] that section, I hope it clarifies some of the doubts. Regarding the unspecified "several known and unfixable bugs" I second the suggestion to ask in the mailing list. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:22, 7 February 2015 (UTC)<br />
<br />
::::Thanks for making those edits -- it's much clearer now. I also like your simplification of my comment. Based on my own experience, it's important to point this out explicitly (that the BIOS clock setting will look funny) even if it is implicitly obvious, if you think about it. "Don't make me think" is not just a rule that applies to websites. <:) -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 09:52, 7 February 2015 (UTC)<br />
<br />
:::::I think the description is good, but a bit verbose for the BG (particularly as this is about booting multiple operations systems, namely Windows). [http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html ut-rc] (linked from [[Time#Time_standard]]) provides some more background, also on the "unfixable bugs".<br />
:::::I'd suggest to merge the more elaborate description to [[Time]], provide a short paragraph on Windows and localtime (and unexpected BIOS clock), and link to the above website. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:34, 22 February 2015 (UTC)<br />
<br />
::::::If you manage to merge the section into [[Time]] I think it's a good thing; I also think the external link can be kept only there: if we want to make the section brief, I'd say that what the readers need to know from the BG is only that they have to make sure the hw clock is set to UTC time and that all the other installed OSs must be set accordingly (Arch will consider the hw clock to be set to UTC by default). Then, if they want to know why, or if they want to use localtime for some reason, they can be sent to read [[Time]] to understand all the pros and the cons. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:15, 23 February 2015 (UTC)<br />
<br />
== Static IP ==<br />
<br />
I'd like to discuss whether to keep [[#Beginners' guide#Static IP]] or not. [[dhcpcd#Fallback static profile]] could easily be expanded to cover this, and most (home) routers provide DHCP by default. Having the information in [[dhcpcd]] also benefits [[Beginners' guide#Wired]] which directly links to that article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:20, 28 March 2015 (UTC)<br />
<br />
:I assume you'd replace it with a link to [[dhcpcd#Fallback static profile]], +1 from me. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:19, 29 March 2015 (UTC)<br />
<br />
:I'm -1 on this idea. Fallback is useful for headless installs, yes, but that's not a BG topic.? If a user starts configuring [[Beginners' guide#Static IP]], this means default ISO booting DHCP has failed. Making a static connection fallback only delays startup further in this case.. because DHCP will fail again first. <br />
:Sidenote: What one might consider, is open a flyspray suggesting the ISO default dhcpcd config could gain a fallback static IP config (with both 192.168.* and 10.10.* IPs/routes it would probably be reachable for the majority of routers). <s>Doing such might be considered network intrusive by some users though.</s> edit: since it would be a passive config, not really intrusive. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:57, 29 March 2015 (UTC)<br />
<br />
::Well, the idea is to change/expand the dhcpcd section first to include fallback as a sub-section. The main content would be a regular static profile, with info merged from the BG, and named [[dhcpcd#Static profile]]. I like suggesting a default config though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:16, 29 March 2015 (UTC)<br />
<br />
:::Please drop a quick note, if you open a bug for it (I do the same). Sub-section or not, this part makes no sense for BG readers of that section imo. Moving the current dhcpcd content of the section, ok - but that's a neat seven lines including code and not really worth it. Moving the whole section comes at the expense of having it verbose incl. interface identification in [[dhcpcd]]. I'm neutral on that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:45, 29 March 2015 (UTC)<br />
<br />
::::I also doubted if it was worth the effort, hence my asking. Still, I'd like some relation to the chroot section, if only a Tip for users to save/copy their config for later use. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:21, 1 April 2015 (UTC)<br />
<br />
:::::Good idea, added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=368819&oldid=368817]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:41, 6 April 2015 (UTC)<br />
<br />
== Linked to 'parted' Manual doesn't list ext3 or ext4 for fs-type ==<br />
<br />
Hi guys. Recent Arch convert here. Loving it. No bloat! Noticed this during Beginners Guid install though:<br />
<br />
In the section on using parted ( [[Beginners%27_guide#Partition_schemes]] ), it links to the Gnu parted manual at [http://www.gnu.org/software/parted/manual/parted.html#mkpart http://www.gnu.org/software/parted/manual/parted.html#mkpart] for fs-types, but the (rather dated?) manual doesn't list ext3 or ext4. At this point I 'guessed' ext2 was the right choice... Only to find that LATER in the 'Beginners Guide' page it recommended ext4. Damn! Wasn't sure if I had to go back and re-do. Seemed not. But anyway, confusing for 'Beginners'. Anyway, dare not edit the wiki being an Arch noob at this point. Keep up the good work! Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 00:53, 7 April 2015 (UTC)<br />
<br />
:Yes, this is a rather confusing concept: the file system type associated to a partition is a different thing from the file system that you later use to format that partition... It's explained in a bit clearer way in [[Wikipedia:Disk_partitioning#PC_partition_types]], but we should probably explain it better here too.<br />
:In theory, using "ext2", "ext3" or "ext4" when you use {{ic|(parted) mkpart}} shouldn't make any difference at all, as they all set the same partition type code. What does make a difference is the file system you choose when you actually format the partition in [[Beginners'_guide#Create_filesystems]].<br />
:Of course it's wise to make sure the ''fs-type'' corresponds to the file system that is going to be used, but even though I've never tested it, I guess you could use e.g. "NTFS" for ''fs-type'' and still be able to format the partition with ext4 or whatever file system you want.<br />
:— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:49, 7 April 2015 (UTC)<br />
<br />
:: Oh, so for ext3/4 one should just set fs-type to ext2 in parted (etc). Lesson learnt. A one liner would be good saying something like "If you don't know any better, set fs-type to ext2 (Which is the correct option for ext2/3/4), and then format with ext4 below." -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 23:32, 7 April 2015 (UTC)<br />
<br />
:::We needed something more generic and educational, I've added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&action=historysubmit&diff=368977&oldid=368819], I hope it's clear enough, please re-open the discussion if it's not :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:17, 8 April 2015 (UTC)<br />
<br />
::::Looks great. Loving the Arch way, community, Wiki etc. Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 08:49, 8 April 2015 (UTC)<br />
<br />
::::Actually, parted 3.2 has an explicit label for ext4: {{bc|<nowiki><br />
(parted) help mkpart <br />
mkpart PART-TYPE [FS-TYPE] START END make a partition<br />
...<br />
FS-TYPE is one of: btrfs, nilfs2, </nowiki>'''ext4, ext3'''<nowiki>, ext2, fat32, fat16, hfsx, hfs+, hfs, jfs, swsusp, linux-swap(v1), linux-swap(v0),<br />
ntfs, reiserfs, hp-ufs, sun-ufs, xfs, apfs2, apfs1, asfs, amufs5, amufs4, amufs3, amufs2, amufs1, amufs0, amufs, affs7, affs6,<br />
affs5, affs4, affs3, affs2, affs1, affs0, linux-swap, linux-swap(new), linux-swap(old)<br />
...<br />
</nowiki>}}<br />
::::If they are all mapped to the same partition code is another matter, so I'm fine with the current wording. Alternatively we could leave out FS-TYPE completely, after all it is optional (but this is not reflected in the BG).<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:41, 8 April 2015 (UTC)<br />
<br />
:::::Do we want to reopen and investigate this further? Thanks for reminding of the help command, however I can find many sources that seem to confirm that many Linux native file systems (but not all of the above!) map to 0x83: [http://www.win.tue.nl/~aeb/partitions/partition_types-1.html] [http://askubuntu.com/questions/230930/whats-the-difference-of-partition-type-and-filesystem-type] [http://www.tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x190.html] [http://thestarman.pcministry.com/asm/mbr/PartTypes.htm] [http://datarecovery.com/rd/hexadecimal-flags-for-partition-type/]. Unfortunately, as [[Wikipedia:Partition_type#Overview]] says, these codes are not standardized, so we won't be able to find an official reference. Last thing, quoting the [http://www.gnu.org/software/parted/manual/parted.html#mkpart manual], " fs-type is required for data partitions (i.e., non-extended partitions)", so I wouldn't leave it out as optional. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:46, 9 April 2015 (UTC)<br />
<br />
::::::The clearest would either be {{ic|mkpart primary linux}} or {{ic|mkpartfs ext4}} but I doubt either is supported... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:47, 9 April 2015 (UTC)<br />
<br />
:::::::I doubt too, I've [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=369201&oldid=368977 replaced] the link to the manual with "help mkpart". — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:21, 10 April 2015 (UTC)<br />
<br />
== "Internet" a proper name? ==<br />
<br />
Re [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&curid=14839&diff=370951&oldid=370932], there's an article on this: [[Wikipedia:Capitalization of "Internet"]]. It makes no clear case for either generic or proper name, so I'd also stick to the existing lower-case spelling. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 24 April 2015 (UTC)<br />
<br />
:I too tend to prefer the lower-case version for the same reasons as why we spell "telephone" and not "Telephone" etc., but I'm just noting that Wikipedia itself seems to use the upper-case version quite consistently throughout the articles. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:03, 25 April 2015 (UTC)<br />
<br />
== Should we indicate what more could be installed in Post-installation section? ==<br />
<br />
The Post-installation section is short thus kind of hard to be seen. In personal experience, my friend just installed Arch few days ago, and complained that he could not find a way to install GUI on his system by reading beginners' guide.<br />
<br />
Should we add some simple examples to the section to show that what kind of useful applications can be installed by reading the [[General recommendations]] article to make things clearer? If the simple examples were added into the section, the section will become longer and because of that, the section will be easier to be seen too.<br />
<br />
[[User:Saren|Saren]] ([[User talk:Saren|talk]]) 15:01, 11 May 2015 (UTC)</div>Sarenhttps://wiki.archlinux.org/index.php?title=Talk:Beginners%27_guide&diff=373368Talk:Beginners' guide2015-05-11T15:00:59Z<p>Saren: /* Should we indicate what more could be installed in Post-installation section? */ new section</p>
<hr />
<div>== Unification ==<br />
=== A single, unified official install guide ===<br />
<br />
{{Note|This is based on talk/consensus in #archlinux. The official [[Installation Guide]] page is going to be expanded (or this guide could be protected, cleaned up and replace it - either works, that could be decided here).}}<br />
<br />
Previously, there has been talk here about merging with the old official install guide, and just having a single official [[Installation Guide]]. However, that didn't happen when the old guide was removed because the [[Beginners' Guide]] was (and is) too long, with too much duplication of other pages after the point where it's necessary (getting the initial network access). In order to be an "official" document, it would also have to be protected - edits by regular users would be proposed on the talk page.<br />
<br />
The installation process now always requires network access, and the ISO ships with both a browser and an IRC client, so it's not necessary to keep so much information on this page, since we have very good coverage elsewhere that surpasses the duplication here. For example, there's no need for the [[Beginners' Guide]] to explain how to do an upgrade as [[Pacman#Upgrading packages]] has much better coverage of the gritty details, and the initial install is already fully upgraded.<br />
<br />
-- [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 21:52, 28 October 2012 (UTC)<br />
<br />
:Yes, the ISO comes with a browser ({{Pkg|elinks}}), but it's not very good with formatting. Some people may prefer to actually print the guide ''(which is a waste of paper, if you ask me, but old timers may feel differently)'', or save it as a PDF/HTML and read it on whatever device they own (smartphone, tablet, etc).<br />
<br />
No need to create a section for this, just reminding that the unification would affect {{Bug|36111}}. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:57, 18 August 2013 (UTC)<br />
<br />
=== Define scope of the guide ===<br />
I'd like to define the scope of the guide(s) better and whether it's OK to remove certain things from the wiki instead of marking them as 'the old way' and maybe moving them to a separate article, if needed. Currently the beginners' guide still has info related to initscripts, like [https://wiki.archlinux.org/index.php/Beginners%27_Guide#Time_zone setting the timezone], but the article on time [https://wiki.archlinux.org/index.php/Time#Time_standard has not]. -- [[User:Karol|Karol]] ([[User talk:Karol|talk]]) 09:56, 30 October 2012 (UTC)<br />
: Right now the Beginner's Guide is "A page where user can get their system installed '''without reading other pages'''". This is where the duplications come from. Maybe we can redefine it. So we can:<br />
: # Improve [[Help:Reading]]. Add some guide about Navigation, Searching, Category and Table of Contents. So users can reach the information they want more easily.<br />
: # Reduce long duplication texts. The two network configuration part is a candicate. -- [[User:Fengchao|Fengchao]] ([[User talk:Fengchao|talk]]) 07:46, 31 October 2012 (UTC)<br />
:The reason for using the manual way of configuring is actually because timedatectl and friends won't work from inside a chroot. We could avoid that by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all) but that would require some minor restructuring, so it's something worth discussing. [[User:Thestinger|thestinger]] ([[User talk:Thestinger|talk]]) 17:28, 3 November 2012 (UTC)<br />
<br />
::''[This comment was pasted here from a different, now deleted discussion]''<br />
:: I think that the goal of the Beginners' Guide is not only to let an Arch novice install the system successfully, but also to introduce him to how an Arch Linux system is structured and the technologies it's based on: we shouldn't think of the Beginners' Guide (or any other article) as a simple howto or step-by-step guide, but as something more formative. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 15:40, 19 September 2012 (UTC)<br />
<br />
=== Plan ===<br />
If someone was interested and had the time to lay out here a '''detailed''' plan with indications on where to merge every section of the guide and a report of all the problems that could be encountered in the process, it would definitely be the final step before announcing the unification on the forums with full support from the admins, which would mean that at that point only strong and reasonable objections could prevent the unification. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 06:44, 18 August 2013 (UTC)<br />
<br />
Here is a list of sections that should be merged. Feel free to expand, comment in [[#Comments]]. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 18:26, 31 August 2013 (UTC)<br />
<br />
* [[Beginners'_guide#Without_wifi-menu]] -- merge into [[Wireless_network_configuration#Getting_some_useful_information]], leave link to target<br />
* [[Beginners%27_guide#Hardware_clock]] - merge to [[Time]], leave link to target, see [[#Hardware_clock_section]]<br />
* Merge common parts between [[Beginners' guide#Establish an internet connection]] and [[Beginners' guide#Configure_the_network]] into [[Network configuration]] and just link there.<br />
* [[Beginners' guide#Prepare the storage devices]] - Contains more information on parted than the actual [[parted]], merge back details <br />
<br />
==== General problems ====<br />
<br />
* ''timedatectl'', ''hostnamectl'', ''localectl'' etc. won't work from inside a chroot, so manual method of configuration is required. This could be avoided by having users reboot before configuring this stuff (time, hostname, etc. aren't critical at all). (mentioned in [[#Define scope of the guide]] by [[User:Thestinger]])<br />
<br />
::You might say these are important enough to have users execute by hand (and thus get a better understanding of, hopefully). But as the underlying processes are explained well enough in their respective articles, I'm fine either way. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:34, 20 February 2015 (UTC)<br />
<br />
* Instructions should be clear and concise, taking the [[Installation guide]] as example.<br />
<br />
* [[Beginners'_guide#Troubleshooting_boot_problems]] lacks coherence, and may need expansion. See [[#Blacklisting radeon module]].<br />
<br />
* Add short introduction on differences between BG and other wiki pages. See [[#Installation template]].<br />
<br />
==== Comments ====<br />
<br />
=== Installation template ===<br />
<br />
Another alternative way to unify the two main guides would be to follow the same philosophy we used to write the scenarios in [[Dm-crypt_with_LUKS/Encrypting_an_entire_system]], originally discussed in [[Talk:Dm-crypt#New_idea]]: the new installation guide could be a bare, though ''complete'', list of commands and simple instructions needed to install the system in one example scenario, with links to the various relevant articles for detailed information and adaptations to specific cases. -- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 21:18, 27 March 2014 (UTC)<br />
<br />
:Well, the Beginners' guide suffers from issues related to both content and style, and I really think they need to be addressed at the same time. Every suggestion so far deals only with one problem.<br />
:'''Content:''' I agree that the purpose of the guide (be it Beginners' or Installation) should be to describe only one scenario and provide links to other articles describing the alternatives. I really like ''this part'' of your suggestion, but it solves only half of the problem.<br />
:'''Style:''' The biggest problem is that Beginners' guide is unique mixture of ''introduction to reading ArchWiki'' and ''introduction to installing and '''using''' Arch Linux'', which are simply inseparable in the context of BG - you just can't expect newcomers to first read [[Help:Reading]] and only then start installing their system. So, there is a little bit of anarchy, as the BG is mostly excused from the [[Help:Style|style guidelines]] and there are no guidelines specifically for the BG. Unifying the two guides would necessarily mean a compromise regarding style, which would not be the best for either beginners or gurus.<br />
:Also, I think that it is a good thing that BG is readable ''without reading other pages'' (as defined in [[#Define scope of the guide]]), because it implies that the most important things have been collected and the readers don't have to click-and-search ''too much''. This is really important for the newcomers, because the orientation in the graph of internal links (I wanted to visualize the graph, but it's just too big) is really difficult - they would need to read dozens of pages (with some [[Help:Style|alien style]] applied) before they had the basic system running. On the other hand, one of the main points of BG should be to prepare the readers for other ArchWiki articles, but sometimes the readers are [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=291207&oldid=285657 too] [https://wiki.archlinux.org/index.php?title=Talk:NetworkManager&diff=304473&oldid=295238 spoiled].<br />
:Well, that is my defence of keeping both IG and BG. In my opinion it is enough to just properly define the scope of BG and trim it down to ease the maintenance, addressing the ''content'' part. But of course if there is a suggestion on merging the two guides addressing the ''style'' issues, let's hear it!<br />
:-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 11:16, 30 March 2014 (UTC)<br />
<br />
::About the style issue, I don't think experienced users would be so bothered by some pacman, systemctl or nano examples, and the unified guide should probably explicitly warn users that they won't find similar examples in the other articles, which would be a perfect way to invite them to become familiar with [[pacman]], [[systemd]], [[Help:Reading]]... Besides, if the guide will be properly structured, experienced users who don't have their own custom installation notes will be able to just follow the automatic ToC as a memory refresher.<br />
::I disagree that the fact that the "BG is readable ''without reading other pages''" is a good thing, as that's exactly the reason that makes it hard to maintain and encourages duplication of information; if users were used to follow links instead, most of the efforts now spent in improving the BG would be instead spent in properly improving the linked articles, which would then become as easy to follow as the BG is now.<br />
::Anyway, I've proposed a change in [[#Comments]] (under [[#Plan]]) that I think should be more likely to reach general consensus, and that would already be a good step forward.<br />
::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:35, 31 March 2014 (UTC)<br />
<br />
:::I'm beginning to understand the need for merging. After the BG is slimmed down to cover only one example scenario, the title will be just wrong and the scope will be ''exactly'' the same as for IG. It all depends on whether different target audience and related style differences are enough to justify two guides.<br />
:::I hate being the blocker, so let's slim down BG and when it comes to the point of merging with IG, at least it will not be so shocking. I can't help but to think about it as simple redirecting of BG to IG, which will be (more or less) the eventual outcome, so I will need some time to absorb.<br />
:::Finally, we should also look at [[ArchWiki:Requests#Cleanup: installation category]], so that [[:Category:Getting and installing Arch]] is actually useful for providing alternative scenarios, and to ensure there is a place where to move excessive information from the BG.<br />
:::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 07:35, 7 April 2014 (UTC)<br />
<br />
::::You are not "the blocker", every opinion is as valuable as the others if well argumented, be it for or against the proposal. Especially in this case where we seem to be the only 2 people interested in discussing...<br />
::::If the unification will eventually be completed, of course the BG will become a redirect to the IG, and the latter will be unprotected (and well watched so it's not turned again into a BG).<br />
::::Let's go on with the change very gradually, that's definitely the best way to let everyone successfully and happily adapt to the new way of following the document, which, if done properly, will be even easier and clearer (no need to compare two guides anymore, just to mention an advantage).<br />
::::Of course [[ArchWiki:Requests#Cleanup: installation category]] is strictly linked to all this, I'll try to get there too.<br />
::::-- [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 05:26, 9 April 2014 (UTC)<br />
<br />
:::::I personally would suggest leaving the Installation guide locked after the merger (even if that would lock me out also :). Thing is, if someone went through the effort of researching an addition to the guide, it would be easy for them to bring it up here, in the talk page, and easier for the community to discuss (and implement, if applicable). <br />
:::::Leaving the Installation guide unprotected however would make it open to hasty edits. Even if the IG were well watched as said, a made edit's context may not be sufficiently clear to "judge" it on the spot (confirmed by [[ArchWiki:Reports]]). Having contested content remain (however short) on the main, "official" installation reference is less than ideal.<br />
:::::A compromise may be similar to the [[IRC]] page, which is not protected in the technical sense, but has a warning urging users not to edit the page without prior consensus. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 23:30, 19 February 2015 (UTC)<br />
<br />
::::::Once upon a time, I absolutely don't even remember where, we even discussed the option of keeping the guide in a protected page, but do all the modifications in a separate open page (as if they were two "master" and "devel" branches), with the admins periodically approving and merging the unstable page into the official one. Thanks to the recently introduced [[Special:MergeHistory]] tool, this job could be easier nowadays. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 14:06, 20 February 2015 (UTC)<br />
<br />
:::::::That sounds like a good option. Working hypothesis: to make users accustomed to the idea, we could now add a note at the top of the BG, suggesting to first discuss changes on the talk page. After the merger this note would then point to the "development" page. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:39, 16 March 2015 (UTC)<br />
<br />
::::::::I think that [[Special:MergeHistory]] is too primitive tool for this, AFAIK its only way of operation is "merge all revisions ''up to'' specified one", i.e. there is no ''cherry-picking'' of feasible revisions. -- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 20:50, 16 March 2015 (UTC)<br />
<br />
:::::::::@Alad I'm still thinking about it, I'm not sure whether having 2 protected installation guides would be too confusing. The branch method would certainly be well suited if we really ended up merging the guides into one.<br />
:::::::::@Lahwaacz The way it would work would be (''master'' is protected, contains the whole revisions history and ''will not receive direct edits'' by anyone, including admins):<br />
:::::::::# ''develop'' is initialized with a simple copy of the latest revision of ''master''<br />
:::::::::# Some users make some edits to ''develop''<br />
:::::::::# The wiki staff amends/undos ''develop'' as necessary with additional edits (like it happens now in the only branch)<br />
:::::::::# Once ''develop'' is considered in a good state, [[Special:MergeHistory]] can be used safely, no need for cherry-picking<br />
:::::::::# Go back to 1 (at this step ''develop'' is a redirect to ''master'')<br />
:::::::::— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:09, 17 March 2015 (UTC)<br />
<br />
:::::::::A simpler alternative with the same effect would be maintaining a link that points to the latest officially approved revision in the history of the article, for example in a Note in the intro. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:13, 17 March 2015 (UTC)<br />
<br />
::::::::::Take your time, it will take a lot more work to get the BG anywhere near ready for merging. A link with note sounds viable as well; we could add a table with different options below. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:08, 17 March 2015 (UTC)<br />
<br />
== Blacklisting radeon module ==<br />
<br />
Installed Arch on my laptop, during pacstrap the screen went blank, pressing SPACE, CTL+C ... didn't helped only modprobe.blacklist=radeon enabled me to go through the whole installation process.<br />
My graphic card is ATI M96 aka Mobility Radeon HD 4650.<br />
I believe this info and similar problems should be added to the beginner's guide on a Installation's Issues Troubleshooting section. I believe this is important enough to dual post and separate it from the Removing "Kernel modules" talk. p.s. I may add that this is my first desktop Linux experience--[[User:Dhead|Dhead]] ([[User talk:Dhead|talk]]) 06:20, 4 March 2013 (UTC)<br />
<br />
:The beginners' guide should not contain hardware-specific info, if the issue is common enough links can be added to [[Beginners%27_guide#Troubleshooting_boot_problems]]. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:40, 27 December 2014 (UTC)<br />
<br />
== Newbie here offering thoughts on what could be changed in guide ==<br />
<br />
=== General troubleshooting ===<br />
<br />
Apart from that there should be a section at the very beginning explaining how to troubleshoot your own problems. Learning dmesg -HLkd and journalctl -b etc were helpful tools for me. I also appreciated learning lsblk, lsmod, ls etc from the various articles, but a quick over view of these helpful commands on this page would help newbies like myself. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
: Sorry! Just reading over again, and realizing that I could've saved a tonne of time if I knew the problem of "a bunch of white letters clustered on my screen" was an error I could check. It usually happened when the firmware didn't support something (in my case) but telling the user what he can do when this happens helps ease the wiki hopping. I finally, finally figured out how to debug most of my own problems and I think that is the number one thing this guide should do. No offense, but it would also lessen the load on the "newbie corner" on the forums (not that I know it's loaded or not, but less is better, right?). That way no matter what's written in the guide, if it's incorrect or leads to a bad result, the user can figure out why and what to do.. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:05, 7 June 2013 (UTC)<br />
<br />
:: Another [[Keyboard_Shortcuts|useful article]] that could be mentioned (rebooting from black screens, yay!) [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 00:27, 8 June 2013 (UTC)<br />
<br />
:::Regarding your second point, [[General troubleshooting]] is in Related articles - it could be expanded there. --[[User:Alad|Alad]] ([[User talk:Alad|talk]]) 14:25, 2 July 2014 (UTC)<br />
<br />
=== Mounting partitions and dual-boot ===<br />
<br />
And lastly, the surprisingly tricky bit about "mounting" partitions that do not belong to you on a dual boot system. Ultimately for me what ended up working was knowing which file systems the others could read (esp in a UEFI system). These things can't just be "linked" to because even the pages linked to don't have the information. I got quite a bit of help from friends and google. [[User:Victoroux|Victoroux]] ([[User talk:Victoroux|talk]]) 14:01, 7 June 2013 (UTC)<br />
<br />
== Gummiboot instructions are out of order. ==<br />
<br />
I'm not certain if this is the same issue as the heading "gummiboot instructions are confusing?", but I encountered this using the Beginner's guide. In "2.4 Mount the partitions", it mentions that you should mount the ESP at /boot. But then in "2.8 Chroot and configure the base system", the root is changed to the new system's mountpoint, and /boot no longer refers to the mounted ESP partition (because this was mounted in the live installation CD, in zsh). When in "2.12.2 For UEFI motherboards" I run the gummiboot install command, it errors saying that it is not a fat32 partition. Furthermore, I'm not sure if I need to actually have the initramfs files that were made during pacstrap in the actual ESP since they were installed to /boot. (My thought is they should be, because the assumption was that the ESP has actually been mounted on /boot since before pacstrap was run.) <br />
<br />
I'm not certain what to do. (I'm new, this is my first time going through this guide.) Could someone please review this? Or perhaps I made a mistake somewhere...?<br />
<br />
[[User:Tmarks|Tmarks]] ([[User talk:Tmarks|talk]]) 14:23, 11 October 2014 (UTC)<br />
<br />
: Hmmm... After that there's a command telling about mounting to {{ic|/mnt/boot}}, so people must mount it correctly to {{ic|/mnt/boot}}. But I think you are right, I's a bit confusing and we should replace preceding {{ic|/boot}} with {{ic|/mnt/boot}} -- [[User:Kycok|Kycok]] ([[User talk:Kycok|talk]]) 11:00, 15 October 2014 (UTC)<br />
<br />
::I am not sure I follow this completely; the quoted section numbers anyhow. [[Beginners' guide#For UEFI motherboards]] states "It is strongly recommended to have the EFI System Partition mounted at /boot as this is required to automatically update Gummiboot." and then "(replace) $esp with the location of your EFI System Partiton, usually /boot" right before the gummiboot install. Maybe it was updated meanwhile, do we need to adjust something? --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 20:54, 2 January 2015 (UTC)<br />
<br />
== Hardware clock section ==<br />
<br />
The '''Hardware clock''' section instructs users to set their hardware clock to UTC time:<br />
<br />
# hwclock --systohc --utc<br />
<br />
without explaining that this will actually reset the BIOS clock setting. Users are then warned that ''Using localtime on Arch systems may lead to several known and unfixable bugs''.<br />
<br />
Question: what might those unfixable bugs be? I've been following these instructions fairly rigorously on every Arch system I've installed, but just got burned by the clock setting, as I think I spaced out and reset the BIOS clock to localtime, so outgoing mail on the system was thrown off by several hours for a couple of days until one of the users alerted me to the problem. Setting the system clock to UTC is kind of confusing, particularly for beginners. What are the unfixable bugs from doing this? If these don't actually exist I would suggest just setting the hardware clock to localtime. This allows you to check the accuracy of the RTC when snooping around in the BIOS.<br />
<br />
# hwclock --systohc --localtime<br />
<br />
And if there really are unfixable bugs, users should be told that the hardware clock is going to be set to an unfamiliar value, so they don't freak out when they go in the system setup and find that the clock is off by several hours from the time they thought it should be. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 22:33, 5 February 2015 (UTC)<br />
<br />
:[https://lists.archlinux.org//listinfo/arch-general/ arch-general] is a probably a better place to discuss this. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 06:47, 6 February 2015 (UTC)<br />
<br />
::OK, I added a note explaining that this command would reset the RTC clock, which is probably good enough for the Beginner's Guide. -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 08:44, 6 February 2015 (UTC)<br />
<br />
:::I've just finished [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=359876&oldid=359646 expanding] that section, I hope it clarifies some of the doubts. Regarding the unspecified "several known and unfixable bugs" I second the suggestion to ask in the mailing list. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 03:22, 7 February 2015 (UTC)<br />
<br />
::::Thanks for making those edits -- it's much clearer now. I also like your simplification of my comment. Based on my own experience, it's important to point this out explicitly (that the BIOS clock setting will look funny) even if it is implicitly obvious, if you think about it. "Don't make me think" is not just a rule that applies to websites. <:) -- [[User:Pgoetz|Pgoetz]] ([[User talk:Pgoetz|talk]]) 09:52, 7 February 2015 (UTC)<br />
<br />
:::::I think the description is good, but a bit verbose for the BG (particularly as this is about booting multiple operations systems, namely Windows). [http://www.cl.cam.ac.uk/~mgk25/mswish/ut-rtc.html ut-rc] (linked from [[Time#Time_standard]]) provides some more background, also on the "unfixable bugs".<br />
:::::I'd suggest to merge the more elaborate description to [[Time]], provide a short paragraph on Windows and localtime (and unexpected BIOS clock), and link to the above website. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 20:34, 22 February 2015 (UTC)<br />
<br />
::::::If you manage to merge the section into [[Time]] I think it's a good thing; I also think the external link can be kept only there: if we want to make the section brief, I'd say that what the readers need to know from the BG is only that they have to make sure the hw clock is set to UTC time and that all the other installed OSs must be set accordingly (Arch will consider the hw clock to be set to UTC by default). Then, if they want to know why, or if they want to use localtime for some reason, they can be sent to read [[Time]] to understand all the pros and the cons. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 10:15, 23 February 2015 (UTC)<br />
<br />
== Static IP ==<br />
<br />
I'd like to discuss whether to keep [[#Beginners' guide#Static IP]] or not. [[dhcpcd#Fallback static profile]] could easily be expanded to cover this, and most (home) routers provide DHCP by default. Having the information in [[dhcpcd]] also benefits [[Beginners' guide#Wired]] which directly links to that article. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 22:20, 28 March 2015 (UTC)<br />
<br />
:I assume you'd replace it with a link to [[dhcpcd#Fallback static profile]], +1 from me. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:19, 29 March 2015 (UTC)<br />
<br />
:I'm -1 on this idea. Fallback is useful for headless installs, yes, but that's not a BG topic.? If a user starts configuring [[Beginners' guide#Static IP]], this means default ISO booting DHCP has failed. Making a static connection fallback only delays startup further in this case.. because DHCP will fail again first. <br />
:Sidenote: What one might consider, is open a flyspray suggesting the ISO default dhcpcd config could gain a fallback static IP config (with both 192.168.* and 10.10.* IPs/routes it would probably be reachable for the majority of routers). <s>Doing such might be considered network intrusive by some users though.</s> edit: since it would be a passive config, not really intrusive. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 09:57, 29 March 2015 (UTC)<br />
<br />
::Well, the idea is to change/expand the dhcpcd section first to include fallback as a sub-section. The main content would be a regular static profile, with info merged from the BG, and named [[dhcpcd#Static profile]]. I like suggesting a default config though. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 11:16, 29 March 2015 (UTC)<br />
<br />
:::Please drop a quick note, if you open a bug for it (I do the same). Sub-section or not, this part makes no sense for BG readers of that section imo. Moving the current dhcpcd content of the section, ok - but that's a neat seven lines including code and not really worth it. Moving the whole section comes at the expense of having it verbose incl. interface identification in [[dhcpcd]]. I'm neutral on that. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 12:45, 29 March 2015 (UTC)<br />
<br />
::::I also doubted if it was worth the effort, hence my asking. Still, I'd like some relation to the chroot section, if only a Tip for users to save/copy their config for later use. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 08:21, 1 April 2015 (UTC)<br />
<br />
:::::Good idea, added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=368819&oldid=368817]. --[[User:Indigo|Indigo]] ([[User talk:Indigo|talk]]) 19:41, 6 April 2015 (UTC)<br />
<br />
== Linked to 'parted' Manual doesn't list ext3 or ext4 for fs-type ==<br />
<br />
Hi guys. Recent Arch convert here. Loving it. No bloat! Noticed this during Beginners Guid install though:<br />
<br />
In the section on using parted ( [[Beginners%27_guide#Partition_schemes]] ), it links to the Gnu parted manual at [http://www.gnu.org/software/parted/manual/parted.html#mkpart http://www.gnu.org/software/parted/manual/parted.html#mkpart] for fs-types, but the (rather dated?) manual doesn't list ext3 or ext4. At this point I 'guessed' ext2 was the right choice... Only to find that LATER in the 'Beginners Guide' page it recommended ext4. Damn! Wasn't sure if I had to go back and re-do. Seemed not. But anyway, confusing for 'Beginners'. Anyway, dare not edit the wiki being an Arch noob at this point. Keep up the good work! Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 00:53, 7 April 2015 (UTC)<br />
<br />
:Yes, this is a rather confusing concept: the file system type associated to a partition is a different thing from the file system that you later use to format that partition... It's explained in a bit clearer way in [[Wikipedia:Disk_partitioning#PC_partition_types]], but we should probably explain it better here too.<br />
:In theory, using "ext2", "ext3" or "ext4" when you use {{ic|(parted) mkpart}} shouldn't make any difference at all, as they all set the same partition type code. What does make a difference is the file system you choose when you actually format the partition in [[Beginners'_guide#Create_filesystems]].<br />
:Of course it's wise to make sure the ''fs-type'' corresponds to the file system that is going to be used, but even though I've never tested it, I guess you could use e.g. "NTFS" for ''fs-type'' and still be able to format the partition with ext4 or whatever file system you want.<br />
:— [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:49, 7 April 2015 (UTC)<br />
<br />
:: Oh, so for ext3/4 one should just set fs-type to ext2 in parted (etc). Lesson learnt. A one liner would be good saying something like "If you don't know any better, set fs-type to ext2 (Which is the correct option for ext2/3/4), and then format with ext4 below." -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 23:32, 7 April 2015 (UTC)<br />
<br />
:::We needed something more generic and educational, I've added [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&action=historysubmit&diff=368977&oldid=368819], I hope it's clear enough, please re-open the discussion if it's not :) — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 07:17, 8 April 2015 (UTC)<br />
<br />
::::Looks great. Loving the Arch way, community, Wiki etc. Cheers. -- [[User:Peterg4000|Peterg4000]] ([[User talk:Peterg4000|talk]]) 08:49, 8 April 2015 (UTC)<br />
<br />
::::Actually, parted 3.2 has an explicit label for ext4: {{bc|<nowiki><br />
(parted) help mkpart <br />
mkpart PART-TYPE [FS-TYPE] START END make a partition<br />
...<br />
FS-TYPE is one of: btrfs, nilfs2, </nowiki>'''ext4, ext3'''<nowiki>, ext2, fat32, fat16, hfsx, hfs+, hfs, jfs, swsusp, linux-swap(v1), linux-swap(v0),<br />
ntfs, reiserfs, hp-ufs, sun-ufs, xfs, apfs2, apfs1, asfs, amufs5, amufs4, amufs3, amufs2, amufs1, amufs0, amufs, affs7, affs6,<br />
affs5, affs4, affs3, affs2, affs1, affs0, linux-swap, linux-swap(new), linux-swap(old)<br />
...<br />
</nowiki>}}<br />
::::If they are all mapped to the same partition code is another matter, so I'm fine with the current wording. Alternatively we could leave out FS-TYPE completely, after all it is optional (but this is not reflected in the BG).<br />
::::-- [[User:Lahwaacz|Lahwaacz]] ([[User talk:Lahwaacz|talk]]) 14:41, 8 April 2015 (UTC)<br />
<br />
:::::Do we want to reopen and investigate this further? Thanks for reminding of the help command, however I can find many sources that seem to confirm that many Linux native file systems (but not all of the above!) map to 0x83: [http://www.win.tue.nl/~aeb/partitions/partition_types-1.html] [http://askubuntu.com/questions/230930/whats-the-difference-of-partition-type-and-filesystem-type] [http://www.tldp.org/HOWTO/Partition-Mass-Storage-Definitions-Naming-HOWTO/x190.html] [http://thestarman.pcministry.com/asm/mbr/PartTypes.htm] [http://datarecovery.com/rd/hexadecimal-flags-for-partition-type/]. Unfortunately, as [[Wikipedia:Partition_type#Overview]] says, these codes are not standardized, so we won't be able to find an official reference. Last thing, quoting the [http://www.gnu.org/software/parted/manual/parted.html#mkpart manual], " fs-type is required for data partitions (i.e., non-extended partitions)", so I wouldn't leave it out as optional. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 09:46, 9 April 2015 (UTC)<br />
<br />
::::::The clearest would either be {{ic|mkpart primary linux}} or {{ic|mkpartfs ext4}} but I doubt either is supported... -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 12:47, 9 April 2015 (UTC)<br />
<br />
:::::::I doubt too, I've [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=369201&oldid=368977 replaced] the link to the manual with "help mkpart". — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 13:21, 10 April 2015 (UTC)<br />
<br />
== "Internet" a proper name? ==<br />
<br />
Re [https://wiki.archlinux.org/index.php?title=Beginners%27_guide&curid=14839&diff=370951&oldid=370932], there's an article on this: [[Wikipedia:Capitalization of "Internet"]]. It makes no clear case for either generic or proper name, so I'd also stick to the existing lower-case spelling. -- [[User:Alad|Alad]] ([[User talk:Alad|talk]]) 09:42, 24 April 2015 (UTC)<br />
<br />
:I too tend to prefer the lower-case version for the same reasons as why we spell "telephone" and not "Telephone" etc., but I'm just noting that Wikipedia itself seems to use the upper-case version quite consistently throughout the articles. — [[User:Kynikos|Kynikos]] ([[User talk:Kynikos|talk]]) 02:03, 25 April 2015 (UTC)<br />
<br />
== Should we indicate what more could be installed in Post-installation section? ==<br />
<br />
The Post-installation section is short thus kind of hard to be seen. In personal experience, my friend just installed Arch few days ago, and complained that he could not find a way to install GUI on his system by reading beginners' guide.<br />
Should we add some simple examples to the section to show that what kind of useful applications can be installed by reading the [[General recommendations]] article to make things clearer? If the simple examples were added into the section, the section will become longer and because of that, the section will be easier to be seen too.</div>Sarenhttps://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=373365Beginners' guide2015-05-11T14:48:47Z<p>Saren: /* Post-installation */ To indicate that what GUI can be installed in an Arch system since the Post-installation section is somehow hard to be seen.</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:Beginners' Guide]]<br />
[[bg:Beginners' Guide]]<br />
[[cs:Beginners' Guide]]<br />
[[da:Beginners' Guide]]<br />
[[de:Anleitung für Einsteiger]]<br />
[[el:Beginners' Guide]]<br />
[[es:Beginners' Guide]]<br />
[[fa:راهنمای تازهکارها]]<br />
[[fr:Installation]]<br />
[[he:Beginners' Guide]]<br />
[[hr:Beginners' Guide]]<br />
[[hu:Beginners' Guide]]<br />
[[id:Beginners' Guide]]<br />
[[it:Beginners' Guide]]<br />
[[ja:ビギナーズガイド]]<br />
[[ko:Beginners' Guide]]<br />
[[lt:Beginners' Guide]]<br />
[[nl:Beginners' Guide]]<br />
[[pl:Beginners' Guide]]<br />
[[pt:Beginners' Guide]]<br />
[[ro:Ghidul începătorilor]]<br />
[[ru:Beginners' guide]]<br />
[[sk:Beginners' Guide]]<br />
[[sr:Beginners' Guide]]<br />
[[sv:Nybörjarguiden]]<br />
[[tr:Yeni başlayanlar rehberi]]<br />
[[uk:Beginners' Guide]]<br />
[[zh-CN:Beginners' guide]]<br />
[[zh-TW:Beginners' Guide]]<br />
{{Related articles start}}<br />
{{Related|:Category:Accessibility}}<br />
{{Related|Installation guide}}<br />
{{Related|Diskless system}}<br />
{{Related|Install from SSH}}<br />
{{Related|General recommendations}}<br />
{{Related|General troubleshooting}}<br />
{{Related articles end}}<br />
This document will guide you through the process of installing [[Arch Linux]] using the [https://projects.archlinux.org/arch-install-scripts.git/ Arch Install Scripts]. Before installing, you are advised to skim over the [[FAQ]].<br />
<br />
The community-maintained [[Main page|ArchWiki]] is the primary resource that should be consulted if issues arise. The [[IRC channel]] (irc://irc.freenode.net/#archlinux) and the [https://bbs.archlinux.org/ forums] are also excellent resources if an answer cannot be found elsewhere. In accordance with [[the Arch Way]], you are encouraged to type {{ic|man ''command''}} to read the [[man page]] of any command you are unfamiliar with.<br />
<br />
== Minimum system requirements ==<br />
<br />
Arch Linux should run on any [[Wikipedia:P6 (microarchitecture)|i686]] compatible machine with a minimum of 256 MB RAM. A basic installation with all packages from the {{Grp|base}} group should take less than 800 MB of disk space. If you are working with limited space, this can be trimmed down considerably, but you will have to know what you are doing.<br />
<br />
== Prepare the latest installation medium ==<br />
<br />
{{Tip|Compared to the regular ISO images, the [https://downloads.archlinux.de/iso/archboot/latest archboot] images can take several steps explained in this guide [[Archboot#Interactive_setup_features|interactively]]. See [[Archboot]] for details.}}<br />
<br />
The installation media and their [[GnuPG]] signatures can be acquired from the [https://archlinux.org/download/ Download] page. The single ISO image supports both 32bit and 64bit systems; this guide assumes you use the latest available version.<br />
<br />
It is highly recommended to verify the image signature before use, ''especially when downloading from an HTTP mirror'', as these are run by volunteers who could [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#explanation theoretically serve malicious images]. On a system with GnuPG installed, do this by downloading the ''PGP signature'' (under ''Checksums'') to the ISO directory, and run:<br />
<br />
$ gpg --verify archlinux-''version''-dual.iso.sig<br />
<br />
If the public key is not found, [[GnuPG#Import key|import]] it with {{ic|gpg --recv-keys ''key-id''}}. <br />
<br />
Alternatively, run from an existing Arch Linux installation:<br />
<br />
$ pacman-key -v archlinux-''version''-dual.iso.sig<br />
<br />
Now choose one of the methods from the table below to [[#Boot the installation medium]] on the target machine(s). As the installation process retrieves packages from a remote repository, these methods require an internet connection; see [[Offline installation of packages]] when none is available.<br />
<br />
{| class="wikitable"<br />
! Method<br />
! Articles<br />
! Conditions<br />
|-<br />
| Write the image on flash media or optical disc, then boot from it.<br />
|<br />
* [[USB flash installation media]]<br />
* [[Optical disc drive#Burning]]<br />
|<br />
* Installation on one, or a few machines at most<br />
* Obtain a directly bootable system<br />
|-<br />
| Mount the image on a server machine and have clients boot it over the network.<br />
|<br />
* [[PXE]]<br />
* [[Diskless system]]<br />
|<br />
* Client-server model<br />
* Wired (1Gbit+) network connection<br />
|-<br />
| Mount the image in a running Linux system and install Arch from a chroot environment.<br />
|<br />
* [[Install from existing Linux]]<br />
* [[Install from SSH]]<br />
|<br />
* Replace an existing system with reduced downtime<br />
* Install on the local machine, or a remote one via [[VNC]] or [[SSH]]<br />
|-<br />
| Set up a virtual machine and install Arch as a guest system.<br />
|<br />
* [[:Category:Hypervisors]]<br />
* [[Moving an existing install into (or out of) a virtual machine]]<br />
|<br />
* Operating system compatible with virtualization software<br />
* Obtain an isolated system for learning, testing or debugging<br />
|}<br />
<br />
== Boot the installation medium ==<br />
<br />
Point the current boot device to the media containing the Arch installation media. This is typically achieved by pressing a key during the [[Wikipedia:Power-on self test|POST]] phase, as indicated on the splash screen. Refer to your motherboard's manual for details.<br />
<br />
When the Arch menu appears, select "Boot Arch Linux" and press {{ic|Enter}} to enter the live environment where you will perform the actual installation. Various boot parameters (for example, {{ic|copytoram}}) can be used by editing the boot entry ({{ic|tab}} for syslinux and {{ic|e}} for gummiboot), see [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams README.bootparams] for reference.<br />
<br />
You will be presented with a [[Zsh]] shell prompt, logged in as the root user. ''Zsh'' provides advanced tab completion and other features as part of the [http://grml.org/zsh/ grml config]. For editing text files, the console editor [[nano#Usage|nano]] is suggested.<br />
<br />
=== Booting into UEFI mode ===<br />
<br />
{{Warning|While the choice to install in EFI mode is forward looking, early vendor UEFI implementations carried more bugs than their BIOS counterparts. It is advised to do a search relating your particular mainboard model before proceeding.}}<br />
<br />
In case you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard with UEFI mode enabled, the CD/USB will automatically launch Arch Linux via [[Gummiboot]] and present the following menu:<br />
<br />
{{bc|<br />
Arch Linux archiso x86_64 UEFI USB<br />
UEFI Shell x86_64 v1<br />
UEFI Shell x86_64 v2<br />
EFI Default Loader}}<br />
<br />
To verify you are booted in UEFI mode, run:<br />
<br />
# efivar -l<br />
<br />
Should ''efivar'' not list the UEFI variables properly, check if all [[UEFI#Requirements_for_UEFI_variable_support|requirements]] are met.<br />
<br />
=== Troubleshooting boot problems ===<br />
<br />
* If you are using an Intel video chipset and the screen goes blank during the boot process, the problem is likely an issue with [[Kernel mode setting]]. A possible workaround may be achieved by rebooting and pressing {{ic|Tab}} over the entry that you are trying to boot (i686 or x86_64). At the end of the string type {{ic|nomodeset}} and press {{ic|Enter}}. Alternatively, try {{ic|1=video=SVIDEO-1:d}} which, if it works, will not disable kernel mode setting. You can also try {{ic|1=i915.modeset=0}}. See the [[Intel]] article for more information.<br />
* If the screen does ''not'' go blank and the boot process gets stuck while trying to load the kernel, press {{ic|Tab}} while hovering over the menu entry, type {{ic|1=acpi=off}} at the end of the string and press {{ic|Enter}}.<br />
<br />
== Keyboard layout ==<br />
<br />
{{Note|Changes here ''only'' affect the installation process.}}<br />
<br />
The default keyboard layout is set to [[Wikipedia:File:KB United States-NoAltGr.svg|US]], the [[locale]] to {{ic|en_US.UTF-8}}. To change the keyboard layout, run:<br />
<br />
# loadkeys ''layout''<br />
<br />
where ''layout'' is a two-letter [[Wikipedia:ISO 3166-1 alpha-2#Officially assigned code elements|country code]]. Use {{ic|localectl list-keymaps}} to list all available keymaps.<br />
<br />
If certain special characters appear as white squares or other symbols, you may wish to change the console font. See [[Fonts#Previewing_and_testing]] for details.<br />
<br />
== Establish an internet connection ==<br />
<br />
{{Warning|As of [http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id&#61;dee4c244254bb49d1ffa8bd7171ae9cce596d2d0 v197], udev no longer assigns network interface names according to the ''wlanX'' and ''ethX'' naming scheme. If you are coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named ''wlan0'', or that your wired interface is named ''eth0''. You can use the command {{ic|ip link}} to discover the names of your interfaces.}}<br />
<br />
The ''dhcpcd'' network daemon starts automatically during boot of the live system and will attempt to start a wired connection. Try to ping a server to see if a connection was established. For example, Google's webservers:<br />
<br />
{{hc|# ping -c 3 www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=2 ttl=50 time=18.2 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=3 ttl=50 time=16.6 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br />
rtt min/avg/max/mdev = 16.660/17.320/18.254/0.678 ms<br />
}}<br />
<br />
If you get a {{ic|ping: unknown host}} error, first check if there is an issue with your cable. If not, you will need to set up the network manually, as explained below. Once a connection is established move on to [[#Prepare the storage devices]].<br />
<br />
{{Tip|<br />
* The ''elinks'' browser is available in the live system: it can be useful for example to authenticate in RADIUS-protected networks. <br />
* The system you are going to install in this guide makes no pre-assumptions regarding network access. For an easy start after the first boot, it may be helpful to stick to the method that got you connected with the live medium and copy relevant configuration to the new system before you [[#Chroot and configure the base system]] later.}}<br />
<br />
=== Static IP ===<br />
<br />
Follow this procedure if you need to set up a wired connection via a static IP address.<br />
<br />
Identify the name of your ethernet interface:<br />
<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000<br />
link/ether 00:11:25:31:69:20 brd ff:ff:ff:ff:ff:ff<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000<br />
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
In this example, the ethernet interface is {{ic|enp2s0f0}}. If you are unsure, your ethernet interface is likely to start with the letter "e", and unlikely to be "lo" or start with the letter "w".<br />
<br />
See [[Network_configuration#Static_IP_address]] for required settings. Configure a static profile for ''dhcpcd'' in {{ic|/etc/dhcpcd.conf}} with your settings, for example: <br />
<br />
interface enp2s0f0<br />
static ip_address=192.168.0.10/24<br />
static routers=192.168.0.1<br />
static domain_name_servers=192.168.0.1 8.8.8.8<br />
<br />
Restart {{ic|dhcpcd.service}}:<br />
<br />
# systemctl restart dhcpcd.service<br />
<br />
You should now have a working network connection. If you do not, see [[Network configuration]] page.<br />
<br />
=== Wireless ===<br />
<br />
{{Warning|Wireless chipset firmware packages (for cards which require them) are pre-installed under {{ic|/usr/lib/firmware}} in the live environment (on CD/USB stick) '''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!''' Package installation is covered later in this guide. Ensure installation of both your wireless module and firmware before rebooting! See [[Wireless network configuration]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset.}}<br />
<br />
Use [[netctl]]'s ''wifi-menu'' to connect to a wireless network:<br />
<br />
# wifi-menu<br />
<br />
This should bring you a menu of wifi networks if your computer has only one Wi-Fi device (mostly the case in laptops).<br />
<br />
If your computer has more than one Wi-Fi device, you need to choose one and pass its interface name to ''wifi-menu''. First, identify the name of the needed interface:<br />
<br />
{{hc|# iw dev|2=<br />
phy#0<br />
Interface wlp3s0<br />
ifindex 3<br />
wdev 0x1<br />
addr 00:11:22:33:44:55<br />
type managed<br />
}}<br />
<br />
This example shows {{ic|wlp3s0}} as the only available wireless interface, for simplicity. If you are unsure, wireless interfaces are likely to start with the letter "w", and unlikely to be "lo" or start with the letter "e".<br />
<br />
Now try ''wifi-menu'' again by passing it the interface name:<br />
<br />
# wifi-menu wlp3s0<br />
<br />
See the sample configuration in [[WPA2 Enterprise#netctl]] for networks that require both a username and password.<br />
<br />
You should now have a working wireless network connection. If you do not or even failed to identify the wireless interface, see [[#Without wifi-menu]] below or the detailed [[Wireless network configuration]] page.<br />
<br />
==== Without wifi-menu ====<br />
<br />
Bring the interface up with:<br />
<br />
# ip link set wlp3s0 up<br />
<br />
To verify that the interface is up, inspect the output of the following command:<br />
<br />
{{hc|# ip link show wlp3s0|<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000<br />
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
The {{ic|UP}} in {{ic|<BROADCAST,MULTICAST,UP,LOWER_UP>}} is what indicates the interface is up, not the later {{ic|state DOWN}}.<br />
<br />
Most wireless chipsets require firmware in addition to a corresponding driver. The kernel tries to identify and load both automatically. If you get output like {{ic|SIOCSIFFLAGS: No such file or directory}}, this means you will need to manually load the firmware. If unsure, invoke ''dmesg'' to query the kernel log for a firmware request from the wireless chipset. For example, if you have an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
<br />
{{hc|<nowiki># dmesg | grep firmware</nowiki>|<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
}}<br />
<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
Next, scan for available networks using {{ic|iw dev wlp3s0 scan <nowiki>|</nowiki> grep SSID}}, then connect to a network with:<br />
<br />
# wpa_supplicant -B -i wlp3s0 -c <(wpa_passphrase "''ssid''" "''psk''")<br />
<br />
You need to replace {{ic|''ssid''}} with the name of your network and {{ic|''psk''}} with your wireless password, '''leaving the quotes around the network name and password'''.<br />
<br />
Finally, you have to give your interface an IP address. This can be set manually or using dhcp:<br />
<br />
# dhcpcd wlp3s0<br />
<br />
If that does not work, issue the following commands:<br />
<br />
# echo 'ctrl_interface=DIR=/run/wpa_supplicant' > /etc/wpa_supplicant.conf<br />
# wpa_passphrase "''ssid''" "''psk''" >> /etc/wpa_supplicant.conf<br />
# ip link set ''interface'' up<br />
# wpa_supplicant -B -D nl80211,wext -c /etc/wpa_supplicant.conf -i ''interface''<br />
# dhcpcd -A ''interface''<br />
<br />
Setting the interface up at step 3 may not be needed, but does no harm in any case.<br />
<br />
=== Analog modem, ISDN, or PPPoE DSL ===<br />
<br />
For xDSL, dial-up, and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Behind a proxy server ===<br />
<br />
If you are behind a proxy server, you will need to export the {{ic|http_proxy}} and {{ic|ftp_proxy}} environment variables. See [[Proxy settings]] for more information.<br />
<br />
== Prepare the storage devices ==<br />
<br />
In this step, the storage devices that will be used by the new system will be prepared. Read [[Partitioning]] for a more general overview.<br />
<br />
{{Warning|Partitioning will destroy existing data. Before proceeding, you '''must''' backup all data that needs to be preserved.}}<br />
<br />
{{Tip|<br />
* Users intending to create stacked block devices for [[LVM]], [[disk encryption]] or [[RAID]], should keep those instructions into consideration when preparing the partitions.<br />
* If intending to install to a USB flash key, see [[Installing Arch Linux on a USB key]].}}<br />
<br />
=== Identify the devices ===<br />
<br />
The first step is to identify the devices where the new system will be installed. The following command will show all the available devices:<br />
<br />
# lsblk<br />
<br />
This will list all devices connected to your system along with their partition schemes, including that used to host and boot live Arch installation media (e.g. a USB drive). Not all devices listed will therefore be viable or appropriate mediums for installation. To filter out inappropriate results, the command can optionally be amended as follows:<br />
<br />
# lsblk | grep -v "rom\|loop\|airoot"<br />
<br />
Devices (e.g. hard disks) will be listed as {{ic|sd''x''}}, where {{ic|''x''}} is a lower-case letter starting from {{ic|a}} for the first device ({{ic|sda}}), {{ic|b}} for the second device ({{ic|sdb}}), and so on. Existing partitions on those devices will be listed as {{ic|sd''xY''}}, where {{ic|''Y''}} is a number starting from {{ic|1}} for the first partition, {{ic|2}} for the second, and so on. In the example below, only one device is available ({{ic|sda}}), and that device uses only one partition ({{ic|sda1}}):<br />
<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 80G 0 disk<br />
└─sda1 8:1 0 80G 0 part<br />
<br />
The {{ic|sd''xY''}} convention will be used in the examples provided below for partition tables, partitions, and file systems. As they are just examples, it is important to ensure that any necessary changes to device names, partition numbers, and/or partition sizes (etc.) are made. Do not just blindly copy and paste the commands.<br />
<br />
If the existing partition scheme needs not be changed, skip to [[#Create filesystems]], otherwise continue reading the following section.<br />
<br />
=== Partition table types ===<br />
<br />
If you are installing alongside an existing installation (i.e. dual-booting), a partition table will already be in use. If the devices are not partitioned, or the current partitions table or scheme needs to be changed, you will first have to determine the partition tables (one for each device) in use or to be used.<br />
<br />
{{Warning|If Arch and Windows are dual-booting from same device, then Arch '''must''' follow the same firmware boot mode and partitioning combination already used, or Windows will fail to boot. See [[Windows and Arch Dual Boot#Important information]] for more details.}}<br />
<br />
There are two types of partition table:<br />
<br />
* [[Master Boot Record| MBR]]: Intended for BIOS systems (also referred to as "msdos")<br />
* [[GUID Partition Table| GPT]]: Intended for UEFI systems<br />
<br />
Any existing partition table can be identified with the following command for each device:<br />
<br />
# parted /dev/sd''x'' print<br />
<br />
=== Partitioning tools ===<br />
<br />
For each device to be partitioned, a proper tool must be chosen according to the partition table to be used. Several partitioning tools are provided by the Arch installation medium, including:<br />
<br />
* [[parted]]: MBR and GPT<br />
* [[Partitioning#Fdisk usage summary|fdisk]], '''cfdisk''', '''sfdisk''': MBR and GPT<br />
* [[Partitioning#Gdisk usage summary|gdisk]], '''cgdisk''', '''sgdisk''': GPT<br />
<br />
{{Warning|Using a partitioning tool that is incompatible with your partition table type will likely result in the destruction of that table, along with any existing partitions/data.}}<br />
<br />
{{Tip|The devices may also be partitioned before booting the Arch installation media, possibly using alternative live systems with other partitioning tools. For example beginners might find it easier to use a graphical partitioning tool such as [[GParted]], which is also provided as a [http://gparted.sourceforge.net/livecd.php live CD] and works with both MBR and GPT partition tables.}}<br />
<br />
==== Using parted in interactive mode ====<br />
<br />
All the examples provided below make use of ''parted'', as it can be used for both BIOS/MBR and UEFI/GPT. It will be launched in ''interactive mode'', which simplifies the partitioning process and reduces unnecessary repetition by automatically applying all partitioning commands to the specified device.<br />
<br />
In order to start operating on a device, execute:<br />
<br />
# parted /dev/sd''x''<br />
<br />
You will notice that the command-line prompt changes from a hash ({{ic|#}}) to {{ic|(parted)}}: this also means that the new prompt is not a command to be manually entered when running the commands in the examples.<br />
<br />
To see a list of the available commands, enter:<br />
<br />
(parted) help<br />
<br />
When finished, or if wishing to implement a partition table or scheme for another device, exit from parted with:<br />
<br />
(parted) quit<br />
<br />
After exiting, the command-line prompt will change back to {{ic|#}}.<br />
<br />
=== Create new partition table ===<br />
<br />
You need to (re)create the partition table of a device when it has never been partitioned before, or when you want to change the type of its partition table. Recreating the partition table of a device is also useful when the partition scheme needs to be restructured from scratch.<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not erase the partition table. Doing so will destroy all existing data on the device, including the UEFI partition with the Windows ''.efi'' file required to boot it.<br />
* MBR is designed specifically for use with BIOS systems, and GPT is designed for UEFI. It is not recommended for less experienced users to break this convention as both have features and/or limitations that may be incompatible with your hardware (e.g. MBR cannot cope with devices larger than 2 TiB). [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/] If for any reason you do not wish to follow this convention, see [http://mjg59.dreamwidth.org/8035.html] and [http://rodsbooks.com/gdisk/bios.html] for more information and possible workarounds.}}<br />
<br />
Open each device whose partition table must be (re)created with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
To then create a new MBR/msdos partition table for BIOS systems, use the following command:<br />
<br />
(parted) mklabel msdos<br />
<br />
To create a new GPT partition table for UEFI systems instead, use:<br />
<br />
(parted) mklabel gpt<br />
<br />
=== Partition schemes ===<br />
<br />
You can decide the number and size of the partitions the devices should be split into, and which directories will be used to mount the partitions in the installed system (also known as ''mount points''). The mapping from partitions to directories is the [[Partitioning#Partition scheme|partition scheme]], which must comply with the following requirements:<br />
<br />
* At least a partition for the {{ic|/}} (''root'') directory '''must''' be created.<br />
* Depending on the motherboard's firmware interface, the chosen [[#Partition table types]], and in some cases also the chosen [[boot loader]], the following additional partitions '''must''' be created:<br />
** '''BIOS/MBR''': no additional partition required.<br />
** '''UEFI/GPT''': one [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]].<br />
<br />
In the examples below it is assumed that a new and contiguous partitioning scheme is applied to a single device. Some optional partitions will also be created for the {{ic|/boot}} and {{ic|/home}} directories: see also [[Arch filesystem hierarchy]] for an explanation of the purpose of the various directories; if separate partitions for directories like {{ic|/boot}} or {{ic|/home}} are not created, these will simply be contained in the {{ic|/}} partition. Also the creation of an optional partiton for [[swap space]] will be illustrated.<br />
<br />
If not already open in a ''parted'' interactive session, open each device to be partitioned with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
The following command will be used to create partitions:<br />
<br />
(parted) mkpart ''part-type'' ''fs-type'' ''start'' ''end''<br />
<br />
* {{ic|''part-type''}} is one of {{ic|primary}}, {{ic|extended}} or {{ic|logical}}, and is meaningful only for MBR partition tables.<br />
* {{ic|''fs-type''}} is an identifier chosen among those listed by entering {{ic|help mkpart}} as the closest match to the file system that you will use in [[#Create filesystems]]. The ''mkpart'' command does not actually create the file system: the {{ic|''fs-type''}} parameter will simply be used by ''parted'' to set a 1-byte code that is used by boot loaders to "preview" what kind of data is found in the partition, and act accordingly if necessary. See also [[Wikipedia:Disk partitioning#PC partition types]].<br />
: {{Tip|Most [[Wikipedia:File_system#Linux|Linux native file systems]] map to the same partition code ([[Wikipedia:Partition type#PID_83h|0x83]]), so it is perfectly safe to e.g. use {{ic|ext2}} for an ''ext4''-formatted partition.}}<br />
* {{ic|''start''}} is the beginning of the partition from the start of the device. It consists of a number followed by a [http://www.gnu.org/software/parted/manual/parted.html#unit unit], for example {{ic|1M}} means start at 1MiB.<br />
* {{ic|''end''}} is the end of the partition from the start of the device (''not'' from the {{ic|''start''}} value). It has the same syntax as {{ic|''start''}}, for example {{ic|100%}} means end at the end of the device (use all the remaining space).<br />
<br />
{{Warning|It is important that the partitions do not overlap each other: if you do not want to leave unused space in the device, make sure that each partition starts where the previous one ends.}}<br />
<br />
{{Note|''parted'' may issue a warning like:<br />
<br />
Warning: The resulting partition is not properly aligned for best performance.<br />
Ignore/Cancel?<br />
<br />
In this case, read [[Partitioning#Partition alignment]] and follow [[GNU Parted#Alignment]] to fix it.}}<br />
<br />
The following command will be used to flag the partition that contains the {{ic|/boot}} directory as bootable:<br />
<br />
(parted) set ''partition'' boot on<br />
<br />
* {{ic|''partition''}} is the number of the partition to be flagged (see the output of the {{ic|print}} command).<br />
<br />
==== UEFI/GPT examples ====<br />
<br />
In every instance, a special bootable [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] is required.<br />
<br />
{{Warning|If dual-booting with an existing installation of Windows on a UEFI/GPT system, the existing UEFI partition must not be deleted. Doing so will destroy the ''.efi'' file required to boot Windows.}}<br />
<br />
If creating a new EFI System Partition, use the following commands (the recommended size is 512MiB):<br />
<br />
(parted) mkpart ESP fat32 1MiB 513MiB<br />
(parted) set 1 boot on<br />
<br />
The remaining partition scheme is entirely up to you. For one other partition using 100% of remaining space:<br />
<br />
(parted) mkpart primary ext3 513MiB 100%<br />
<br />
For separate {{ic|/}} (20GiB) and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary ext3 20.5GiB 100%<br />
<br />
And for separate {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary linux-swap 20.5GiB 24.5GiB<br />
(parted) mkpart primary ext3 24.5GiB 100%<br />
<br />
==== BIOS/MBR examples ====<br />
<br />
For a minimum single primary partition using all available disk space, the following command would be used:<br />
<br />
(parted) mkpart primary ext3 1MiB 100%<br />
(parted) set 1 boot on<br />
<br />
In the following instance, a 20GiB {{ic|/}} partition will be created, followed by a {{ic|/home}} partition using all the remaining space:<br />
<br />
(parted) mkpart primary ext3 1MiB 20GiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 20GiB 100%<br />
<br />
In the final example below, separate {{ic|/boot}} (100MiB), {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions will be created:<br />
<br />
(parted) mkpart primary ext3 1MiB 100MiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 100MiB 20GiB<br />
(parted) mkpart primary linux-swap 20GiB 24GiB<br />
(parted) mkpart primary ext3 24GiB 100%<br />
<br />
=== Create filesystems ===<br />
<br />
Once the partitions have been created, each must be formatted with an appropriate [[file system]], ''except'' for swap partitions. All available partitions on the intended installation device can be listed with the following command:<br />
<br />
# lsblk /dev/sd''x''<br />
<br />
With the exceptions noted below, it is recommended to use the {{ic|ext4}} file system:<br />
<br />
# mkfs.ext4 /dev/sd''xY''<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not re-format the UEFI partition. Doing so will destroy all existing data on that partition, including the Windows ''.efi'' file required to boot it.<br />
* If a new UEFI system partition has been created on a UEFI/GPT system, it must be formatted with a {{ic|fat32}} or {{ic|vfat32}} file system. Failure to do so will result in an unbootable installation:<br />
:{{bc|# mkfs.vfat -F32 /dev/sd''xY''}}}}<br />
<br />
=== Activate swap ===<br />
<br />
If a swap partition has been created, it must be set up and activated with:<br />
<br />
# mkswap /dev/sd''xY''<br />
# swapon /dev/sd''xY''<br />
<br />
=== Mount the partitions ===<br />
<br />
{{Note|Swap partitions must '''not''' be mounted here.}}<br />
<br />
The {{ic|/}} (root) partition must be mounted '''first''': this is because any directories such as {{ic|/boot}} or {{ic|/home}} that have separate partitions will have to be created in the root file system. The {{ic|/mnt}} directory of the live system will be used to mount the root partition, and consequently all the other partitions will stem from there. If the root partition's name is {{ic|sd''xR''}}, do:<br />
<br />
# mount /dev/sd''xR'' /mnt<br />
<br />
Once the {{ic|/}} partition has been mounted, any remaining partitions may be mounted in any order. The general procedure is to first create the mount point, and then mount the partition to it. If using a separate {{ic|/boot}} partition:<br />
<br />
# mkdir -p /mnt/boot<br />
# mount /dev/sd''xB'' /mnt/boot<br />
<br />
{{Note|Using {{ic|/boot}} is recommended also for mounting the EFI System Partition on UEFI/GPT system. See [[EFISTUB]] and related articles for alternatives.}}<br />
<br />
If using a separate {{ic|/home}} partition:<br />
<br />
# mkdir -p /mnt/home<br />
# mount /dev/sd''xH'' /mnt/home<br />
<br />
Once all the remaining partitions, if any, have been mounted, the devices are ready to install Arch.<br />
<br />
== Select a mirror ==<br />
<br />
You may want to edit the {{ic|mirrorlist}} file and place your preferred mirror first. A copy of this file will be installed on your new system by ''pacstrap'' as well, so it is worth getting it right.<br />
<br />
{{hc|# nano /etc/pacman.d/mirrorlist|<br />
##<br />
## Arch Linux repository mirrorlist<br />
## Sorted by mirror score from mirror status page<br />
## Generated on YYYY-MM-DD<br />
##<br />
<br />
<nowiki>Server = http://mirror.example.xyz/archlinux/$repo/os/$arch</nowiki><br />
...}}<br />
<br />
If you want, you can make it the ''only'' mirror available by deleting all other lines, but it is usually a good idea to have a few more, in case the first one goes offline. Should you change your mirror list at a later stage, refresh all package lists with {{ic|pacman -Syyu}}. See [[Mirrors]] for more information.<br />
<br />
== Install the base system ==<br />
<br />
The base system is installed using the ''pacstrap'' script. Without the {{ic|-i}} switch, every package from the {{Grp|base}} [[Pacman#Installing_package_groups|group]] is installed without prompting. To build packages from the [[AUR]] or with [[ABS]], you will also need the {{Grp|base-devel}} group.<br />
<br />
# pacstrap -i /mnt base base-devel<br />
<br />
Other packages can be installed later using [[pacman]].<br />
<br />
See [[Pacman#Troubleshooting]] and [[Pacman-key#Troubleshooting]] in case of errors.<br />
<br />
== Generate an fstab ==<br />
<br />
[[Wikipedia:Universally_unique_identifier|UUID]]s are used because they have certain advantages (see [[fstab#Identifying filesystems]]). If you prefer labels instead, replace the {{ic|-U}} option with {{ic|-L}}:<br />
<br />
# genfstab -U -p /mnt >> /mnt/etc/fstab<br />
# nano /mnt/etc/fstab<br />
<br />
{{Warning|The {{ic|fstab}} file should always be checked after generating it. If you encounter errors running ''genfstab'' or later in the install process, do '''not''' run ''genfstab'' again; just edit the {{ic|fstab}} file. See [[fstab#Field definitions]] for syntax information.}}<br />
<br />
== Chroot and configure the base system ==<br />
<br />
Next, [[Change root|chroot]] into your newly installed system:<br />
<br />
# arch-chroot /mnt /bin/bash<br />
<br />
At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system. These can either be created if they do not exist, or edited if you wish to change the defaults.<br />
<br />
Closely following and understanding these steps is of key importance to ensure a properly configured system.<br />
<br />
{{Warning|Do not assume that the tools you used from the ISO are automatically installed. For example, if you used ''wifi-menu'' to gain network access during the installation and want to continue so after the first boot, you will have to install ''dialog'' to use it. The following section specifies such cases, do follow it closely to avoid a hiccup in your fresh install.}}<br />
<br />
=== Locale ===<br />
<br />
Locales define which language the system uses and other regional considerations, such as currency denomination, numerology and character sets. Possible values are listed in {{ic|/etc/locale.gen}}, with the active locale defined in {{ic|locale.conf}} files.<br />
<br />
All entries in {{ic|locale.gen}} are commented out (preceded by {{ic|#}}) by default. Uncomment {{ic|en_US.UTF-8 UTF-8}}, as well as other needed localisations. {{ic|UTF-8}} is highly recommended over other options.<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
...<br />
#en_SG ISO-8859-1<br />
en_US.UTF-8 UTF-8<br />
#en_US ISO-8859-1<br />
...<br />
}}<br />
<br />
Before locales can be enabled, they must be ''generated'':<br />
<br />
# locale-gen<br />
<br />
Create {{ic|/etc/locale.conf}}, where {{ic|LANG}} refers to the first column of an uncommented entry in {{ic|/etc/locale.gen}}.<br />
<br />
# echo LANG=''en_US.UTF-8'' > /etc/locale.conf<br />
<br />
Export the chosen locale:<br />
<br />
# export LANG=''en_US.UTF-8''<br />
<br />
{{Note|<br />
* Choosing {{ic|en_US.UTF-8}} as the system locale allows to keep system logs in English for easier troubleshooting. Users may override this setting for their session as described in [[Locale#Setting the locale]].<br />
* {{ic|LANG}} acts as the default value for the locale-related {{ic|LC_*}} variables. To use other locales for these variables, run ''locale'' to see the available options and add them to {{ic|locale.conf}}. It is not recommended to set the {{ic|LC_ALL}} variable. See [[Locale]] for details.}}<br />
<br />
=== Console font and keymap ===<br />
<br />
If you changed the default console keymap and font in [[#Keyboard layout]], create {{ic|/etc/vconsole.conf}} to make those changes persist in the installed system. It is important {{ic|KEYMAP}} matches the value initially set with {{ic|loadkeys}}, to ensure correct entry of [[#Set the root password|the root password]] on reboot.<br />
<br />
{{hc|# nano /etc/vconsole.conf|2=<br />
KEYMAP=''de-latin1''<br />
FONT=''lat9w-16''<br />
}}<br />
<br />
These settings only apply to virtual consoles, not [[Xorg]]. See [[Fonts#Console fonts]] for more information.<br />
<br />
=== Time zone ===<br />
<br />
Available time zones and subzones can be found in the {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} directories, and listed with the ''ls'' command. Create a symbolic link {{ic|/etc/localtime}} to your subzone file {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}}:<br />
<br />
# ln -s /usr/share/zoneinfo/''Zone''/''SubZone'' /etc/localtime<br />
<br />
You may use [http://tldp.org/LDP/abs/html/tabexpansion.html tab completion] to show available zones and subzones. Example:<br />
<br />
# ln -s /usr/share/zoneinfo/Europe/Minsk /etc/localtime<br />
<br />
If you get {{ic|ln: failed to create symbolic link '/etc/localtime': File exists}}, check the existing file with {{ic|ls -l /etc/localtime}} and add the {{ic|-f}} option to the ''ln'' command to overwrite it.<br />
<br />
=== Hardware clock ===<br />
<br />
If you have multiple operating systems installed in the same machine, they will all derive the current time from the same hardware clock, which must be set to either UTC or ''localtime''. For this reason you must make sure that all the operating systems see the hardware clock as providing time in the same chosen [[Time#Time standard|standard]], otherwise some of them will perform the time zone adjustement for the system clock, while others will not.<br />
<br />
In particular, it is strongly recommended to set the hardware clock to UTC, in order to avoid conflicts between the installed operating systems. For example, if the hardware clock was set to ''localtime'', more than one operating system may adjust it after a [[Wikipedia:Daylight_saving_time|DST]] change, thus resulting in an overcorrection; more problems may arise when travelling between different time zones and using one of the operating systems to reset the system/hardware clock.<br />
<br />
To set the hardware clock to UTC in Linux, run:<br />
<br />
# hwclock --systohc --utc<br />
<br />
The ''hwclock'' command also generates the {{ic|/etc/adjtime}} file.<br />
<br />
{{Note|Using UTC for the hardware clock does not mean that software will display time in UTC. However, the system setup/BIOS interface will instead: this should be neither surprising nor treated as a bug.}}<br />
<br />
{{Warning|Windows systems use ''localtime'' by default. Using ''localtime'' on Arch systems may lead to several known and unfixable bugs, but there are no plans to drop support for ''localtime''. It is, though, recommended to set Windows to use UTC instead, and prevent it from synchronising time. See [[Time#UTC in Windows]].}}<br />
<br />
=== Kernel modules ===<br />
<br />
Needed kernel modules are automatically loaded by [[udev]], so you will rarely need to load modules manually. See [[Kernel modules]] for details.<br />
<br />
=== Hostname ===<br />
<br />
Set the [[Network_configuration#Set_the_hostname|hostname]] to your liking:<br />
<br />
# echo ''myhostname'' > /etc/hostname<br />
<br />
Add the same hostname to {{ic|/etc/hosts}}:<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost ''myhostname''<br />
::1 localhost.localdomain localhost ''myhostname''<br />
<br />
=== Configure the network ===<br />
<br />
You need to configure the network again, but this time for your newly installed environment. The procedure and prerequisites are similar to the one described [[#Establish an internet connection|above]], except we are going to make it persistent and automatically run at boot.<br />
<br />
As a first step, identify the network interface name you want to configure the connection for with {{ic|ip link}}.<br />
<br />
{{Note|<br />
* For more in-depth information on network configuration, visit [[Network configuration]] and [[Wireless network configuration]].<br />
* If you would like to use the old interface naming scheme (i.e. {{ic|eth''X''}} and {{ic|wlan''X''}}) you can accomplish this by creating an empty file at {{ic|/etc/udev/rules.d/80-net-setup-link.rules}} which will mask the file of the same name located under {{ic|/usr/lib/udev/rules.d}}.<br />
}}<br />
<br />
Now select a daemon to handle the configuration and operation. Several are listed below; only select '''one''' of them for the new system.<br />
<br />
==== Wired ====<br />
<br />
; Using dhcpcd<br />
A simple option for adapter configuration is to use the DHCP Client Daemon, the method used by default with the install medium. See [[Dhcpcd#Running]].<br />
<br />
Users requiring only '''single wired network connection''' can simply enable the ''dhcpcd'' service for the interface:<br />
<br />
# systemctl enable dhcpcd@''interface_name''.service<br />
<br />
If static IP settings are required, adjust the profile configuration as described in [[#Static IP]]. <br />
<br />
; Using systemd-networkd<br />
<br />
The Arch default init system, [[systemd]] includes built-in support for managing adapters using both DHCP and static IP setups. Configuration is simple. See [[Systemd-networkd#Required_services_and_setup]].<br />
<br />
; Using netctl<br />
<br />
Another option is [[netctl]] which is a CLI-based tool used to configure and manage network connections via user-created profiles. Create a profile as shown in [[netctl#Example profiles]], then enable it as described in [[netctl#Basic method]].<br />
<br />
==== Wireless ====<br />
<br />
All of the tools listed in [[#Wired]] above can activate wireless connections. For wireless, however, ''dhcpcd'' and ''systemd-networkd'' require a separate configuration of the connection in the wireless backend, [[wpa_supplicant]], first. If you anticipate to connect the machine to different wireless networks over time, a tool which provides its own connection management may be easier to handle. Aside from [[netctl]] introduced below, [[Wireless network configuration#Automatic setup]] lists other choices. <br />
<br />
{{Note|If your wireless adapter requires a firmware (as described in the above [[#Wireless|Establish an internet connection]] section and also in the article [[Wireless network configuration#Device driver]]), install the package containing your firmware. Most of the time, the {{Pkg|linux-firmware}} package will contain the needed firmware. Though for some devices, the required firmware might be in its own package. For example:<br />
{{bc|# pacman -S zd1211-firmware}}<br />
See [[Wireless network configuration#Installing driver/firmware]] for more info.}}<br />
<br />
Install {{Pkg|iw}} and {{Pkg|wpa_supplicant}} which you will need to connect to a network:<br />
<br />
# pacman -S iw wpa_supplicant<br />
<br />
===== Adding wireless networks =====<br />
<br />
; Using wifi-menu<br />
<br />
Install {{Pkg|dialog}}, which is required for ''wifi-menu'':<br />
<br />
# pacman -S dialog<br />
<br />
After finishing the rest of this installation and rebooting, you can connect to the network with:<br />
<br />
# wifi-menu ''interface_name''<br />
<br />
Where {{ic|''interface_name''}} is the interface of your wireless chipset.<br />
<br />
{{Warning|Do not use ''wifi-menu'' now, instead wait until you have finished this guide and have rebooted. It will not work now because a process spawned by this command will conflict with the one you have running outside of the chroot. Alternatively, you could just configure a network profile manually using the following templates so that you do not have to worry about using ''wifi-menu'' at all.}}<br />
<br />
; Using manual netctl profiles<br />
<br />
Copy a network profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/wireless-wpa my-network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|ESSID}} and {{ic|Key}}):<br />
<br />
# nano my-network<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my-network<br />
<br />
===== Connect automatically to known networks =====<br />
<br />
{{Warning|This method cannot be used with explicitely enabled [[Netctl#Configuration|profiles]], i.e. through {{ic|netctl enable ''profile''}}.}}<br />
<br />
Install {{Pkg|wpa_actiond}}, which is required for {{ic|netctl-auto}}:<br />
<br />
# pacman -S wpa_actiond<br />
<br />
Enable the {{ic|netctl-auto}} service, which will connect to known networks and gracefully handle roaming and disconnects:<br />
<br />
# systemctl enable netctl-auto@''interface_name''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-ifplugd}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-auto}}.}}<br />
<br />
==== Analog modem, ISDN or PPPoE DSL ====<br />
<br />
For xDSL, dial-up and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Create an initial ramdisk environment ===<br />
<br />
As [[mkinitcpio]] was run on installation of {{Pkg|linux}} with ''pacstrap'', most users can use the defaults provided in {{ic|mkinitcpio.conf}}. For special configurations, set the correct [[Mkinitcpio#HOOKS|hooks]] in {{ic|/etc/mkinitcpio.conf}} and [[Mkinitcpio#Image_creation_and_activation|re-generate the initramfs image]].<br />
<br />
=== Set the root password ===<br />
<br />
Set the root password with:<br />
<br />
# passwd<br />
<br />
=== Install and configure a bootloader ===<br />
<br />
See [[Boot loaders]] for available choices and configurations. [[Microcode]] updates for Intel CPUs must also be configured after installing the boot loader.<br />
<br />
==== For BIOS motherboards ====<br />
<br />
Here, installation with '''GRUB''' and '''MBR''' is demonstrated. <br />
<br />
Install the {{Pkg|grub}} package; to have GRUB search for other installed operating systems, install {{Pkg|os-prober}} in addition:<br />
<br />
# pacman -S grub os-prober<br />
<br />
Install the bootloader to the drive Arch was installed to (do '''not''' append a partition number, or {{ic|/dev/sda''X''}}):<br />
<br />
# grub-install --target=i386-pc --recheck ''/dev/sda''<br />
<br />
Automatically generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|A sample {{ic|/boot/grub/grub.cfg}} is included with the {{Pkg|grub}} package, and subsequent {{ic|grub-*}} commands may not over-write it. Ensure your intended changes are in {{ic|grub.cfg}}, rather than in {{ic|grub.cfg.new}} or similar file.}}<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
==== For UEFI motherboards ====<br />
<br />
Here, installation with ''gummiboot'' is demonstrated. First install {{Pkg|dosfstools}} to manipulate the EFI System Partition post-installation, and {{Pkg|efibootmgr}} to create a UEFI boot entry (used by bootmanager installation scripts):<br />
<br />
# pacman -S dosfstools efibootmgr<br />
<br />
{{Note|<br />
* For UEFI boot, the drive needs to be GPT-partitioned and an [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] (512 MiB or larger, gdisk type {{ic|EF00}}, formatted with FAT32) must be present. In the following examples, this partition is assumed to be mounted at {{ic|/boot}}. If you have followed this guide from the beginning, you have already done all of these.<br />
* It is strongly recommended to have the EFI System Partition mounted at {{ic|/boot}} as this is required to automatically update Gummiboot.<br />
}}<br />
<br />
Install the {{Pkg|gummiboot}} package and run the automated installation script, replacing {{ic|'''$esp'''}} with the location of your EFI System Partiton, usually {{ic|/boot}}:<br />
<br />
# pacman -S gummiboot<br />
# gummiboot --path='''$esp''' install<br />
<br />
Gummiboot will automatically be detected by firmware that requires that the bootable {{ic|bootx64.efi}} stub be placed in {{ic|'''$esp'''/EFI/boot}}, and will in turn automatically detect the presence of any other installed operating systems using ''.efi'' stubs. However, it will still be necessary to manually create a configuration file for Gummiboot.<br />
<br />
First, create {{ic|'''$esp'''/loader/entries/arch.conf}} and add the following, replacing {{ic|/dev/sdaX}} with your '''root''' partition (most likely {{ic|/dev/sda2}} if {{ic|/dev/sda1}} is the ESP):<br />
<br />
{{hc|# nano '''$esp'''/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
<br />
Second, create {{ic|'''$esp'''/loader/loader.conf}} and add the following, replacing the timeout value (in seconds) with your own choice:<br />
{{hc|# nano '''$esp'''/loader/loader.conf|2=<br />
default arch<br />
timeout 5<br />
}}<br />
<br />
See [[gummiboot]] for more information.<br />
<br />
== Unmount the partitions and reboot ==<br />
<br />
Exit from the chroot environment:<br />
<br />
# exit<br />
<br />
{{Note|While partitions are unmounted automatically by ''systemd'' on shutdown, you may do so manually with {{ic|umount -R /mnt}} as a safety measure. If the partition is "busy", you can find the cause with [[fuser]].}}<br />
<br />
Reboot the computer:<br />
<br />
# reboot<br />
<br />
Remove the installation media, or you may boot back into it. You can log into your new installation as ''root'', using the password you specified with ''passwd''.<br />
<br />
== Post-installation ==<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready to be built into whatever you wish or require for your purposes. You are now ''strongly'' advised to read the [[General recommendations]] article, especially the first two sections. Its other sections provide links to post-installation tutorials like setting up a graphical user interface ([[desktop environment]] such as [[GNOME]] and [[window manager]] such as [[Openbox]]), sound or a touchpad.<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Sarenhttps://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=373363Beginners' guide2015-05-11T14:39:39Z<p>Saren: </p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:Beginners' Guide]]<br />
[[bg:Beginners' Guide]]<br />
[[cs:Beginners' Guide]]<br />
[[da:Beginners' Guide]]<br />
[[de:Anleitung für Einsteiger]]<br />
[[el:Beginners' Guide]]<br />
[[es:Beginners' Guide]]<br />
[[fa:راهنمای تازهکارها]]<br />
[[fr:Installation]]<br />
[[he:Beginners' Guide]]<br />
[[hr:Beginners' Guide]]<br />
[[hu:Beginners' Guide]]<br />
[[id:Beginners' Guide]]<br />
[[it:Beginners' Guide]]<br />
[[ja:ビギナーズガイド]]<br />
[[ko:Beginners' Guide]]<br />
[[lt:Beginners' Guide]]<br />
[[nl:Beginners' Guide]]<br />
[[pl:Beginners' Guide]]<br />
[[pt:Beginners' Guide]]<br />
[[ro:Ghidul începătorilor]]<br />
[[ru:Beginners' guide]]<br />
[[sk:Beginners' Guide]]<br />
[[sr:Beginners' Guide]]<br />
[[sv:Nybörjarguiden]]<br />
[[tr:Yeni başlayanlar rehberi]]<br />
[[uk:Beginners' Guide]]<br />
[[zh-CN:Beginners' guide]]<br />
[[zh-TW:Beginners' Guide]]<br />
{{Related articles start}}<br />
{{Related|:Category:Accessibility}}<br />
{{Related|Installation guide}}<br />
{{Related|Diskless system}}<br />
{{Related|Install from SSH}}<br />
{{Related|General recommendations}}<br />
{{Related|General troubleshooting}}<br />
{{Related articles end}}<br />
This document will guide you through the process of installing [[Arch Linux]] using the [https://projects.archlinux.org/arch-install-scripts.git/ Arch Install Scripts]. Before installing, you are advised to skim over the [[FAQ]].<br />
<br />
The community-maintained [[Main page|ArchWiki]] is the primary resource that should be consulted if issues arise. The [[IRC channel]] (irc://irc.freenode.net/#archlinux) and the [https://bbs.archlinux.org/ forums] are also excellent resources if an answer cannot be found elsewhere. In accordance with [[the Arch Way]], you are encouraged to type {{ic|man ''command''}} to read the [[man page]] of any command you are unfamiliar with.<br />
<br />
== Minimum system requirements ==<br />
<br />
Arch Linux should run on any [[Wikipedia:P6 (microarchitecture)|i686]] compatible machine with a minimum of 256 MB RAM. A basic installation with all packages from the {{Grp|base}} group should take less than 800 MB of disk space. If you are working with limited space, this can be trimmed down considerably, but you will have to know what you are doing.<br />
<br />
== Prepare the latest installation medium ==<br />
<br />
{{Tip|Compared to the regular ISO images, the [https://downloads.archlinux.de/iso/archboot/latest archboot] images can take several steps explained in this guide [[Archboot#Interactive_setup_features|interactively]]. See [[Archboot]] for details.}}<br />
<br />
The installation media and their [[GnuPG]] signatures can be acquired from the [https://archlinux.org/download/ Download] page. The single ISO image supports both 32bit and 64bit systems; this guide assumes you use the latest available version.<br />
<br />
It is highly recommended to verify the image signature before use, ''especially when downloading from an HTTP mirror'', as these are run by volunteers who could [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#explanation theoretically serve malicious images]. On a system with GnuPG installed, do this by downloading the ''PGP signature'' (under ''Checksums'') to the ISO directory, and run:<br />
<br />
$ gpg --verify archlinux-''version''-dual.iso.sig<br />
<br />
If the public key is not found, [[GnuPG#Import key|import]] it with {{ic|gpg --recv-keys ''key-id''}}. <br />
<br />
Alternatively, run from an existing Arch Linux installation:<br />
<br />
$ pacman-key -v archlinux-''version''-dual.iso.sig<br />
<br />
Now choose one of the methods from the table below to [[#Boot the installation medium]] on the target machine(s). As the installation process retrieves packages from a remote repository, these methods require an internet connection; see [[Offline installation of packages]] when none is available.<br />
<br />
{| class="wikitable"<br />
! Method<br />
! Articles<br />
! Conditions<br />
|-<br />
| Write the image on flash media or optical disc, then boot from it.<br />
|<br />
* [[USB flash installation media]]<br />
* [[Optical disc drive#Burning]]<br />
|<br />
* Installation on one, or a few machines at most<br />
* Obtain a directly bootable system<br />
|-<br />
| Mount the image on a server machine and have clients boot it over the network.<br />
|<br />
* [[PXE]]<br />
* [[Diskless system]]<br />
|<br />
* Client-server model<br />
* Wired (1Gbit+) network connection<br />
|-<br />
| Mount the image in a running Linux system and install Arch from a chroot environment.<br />
|<br />
* [[Install from existing Linux]]<br />
* [[Install from SSH]]<br />
|<br />
* Replace an existing system with reduced downtime<br />
* Install on the local machine, or a remote one via [[VNC]] or [[SSH]]<br />
|-<br />
| Set up a virtual machine and install Arch as a guest system.<br />
|<br />
* [[:Category:Hypervisors]]<br />
* [[Moving an existing install into (or out of) a virtual machine]]<br />
|<br />
* Operating system compatible with virtualization software<br />
* Obtain an isolated system for learning, testing or debugging<br />
|}<br />
<br />
== Boot the installation medium ==<br />
<br />
Point the current boot device to the media containing the Arch installation media. This is typically achieved by pressing a key during the [[Wikipedia:Power-on self test|POST]] phase, as indicated on the splash screen. Refer to your motherboard's manual for details.<br />
<br />
When the Arch menu appears, select "Boot Arch Linux" and press {{ic|Enter}} to enter the live environment where you will perform the actual installation. Various boot parameters (for example, {{ic|copytoram}}) can be used by editing the boot entry ({{ic|tab}} for syslinux and {{ic|e}} for gummiboot), see [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams README.bootparams] for reference.<br />
<br />
You will be presented with a [[Zsh]] shell prompt, logged in as the root user. ''Zsh'' provides advanced tab completion and other features as part of the [http://grml.org/zsh/ grml config]. For editing text files, the console editor [[nano#Usage|nano]] is suggested.<br />
<br />
=== Booting into UEFI mode ===<br />
<br />
{{Warning|While the choice to install in EFI mode is forward looking, early vendor UEFI implementations carried more bugs than their BIOS counterparts. It is advised to do a search relating your particular mainboard model before proceeding.}}<br />
<br />
In case you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard with UEFI mode enabled, the CD/USB will automatically launch Arch Linux via [[Gummiboot]] and present the following menu:<br />
<br />
{{bc|<br />
Arch Linux archiso x86_64 UEFI USB<br />
UEFI Shell x86_64 v1<br />
UEFI Shell x86_64 v2<br />
EFI Default Loader}}<br />
<br />
To verify you are booted in UEFI mode, run:<br />
<br />
# efivar -l<br />
<br />
Should ''efivar'' not list the UEFI variables properly, check if all [[UEFI#Requirements_for_UEFI_variable_support|requirements]] are met.<br />
<br />
=== Troubleshooting boot problems ===<br />
<br />
* If you are using an Intel video chipset and the screen goes blank during the boot process, the problem is likely an issue with [[Kernel mode setting]]. A possible workaround may be achieved by rebooting and pressing {{ic|Tab}} over the entry that you are trying to boot (i686 or x86_64). At the end of the string type {{ic|nomodeset}} and press {{ic|Enter}}. Alternatively, try {{ic|1=video=SVIDEO-1:d}} which, if it works, will not disable kernel mode setting. You can also try {{ic|1=i915.modeset=0}}. See the [[Intel]] article for more information.<br />
* If the screen does ''not'' go blank and the boot process gets stuck while trying to load the kernel, press {{ic|Tab}} while hovering over the menu entry, type {{ic|1=acpi=off}} at the end of the string and press {{ic|Enter}}.<br />
<br />
== Keyboard layout ==<br />
<br />
{{Note|Changes here ''only'' affect the installation process.}}<br />
<br />
The default keyboard layout is set to [[Wikipedia:File:KB United States-NoAltGr.svg|US]], the [[locale]] to {{ic|en_US.UTF-8}}. To change the keyboard layout, run:<br />
<br />
# loadkeys ''layout''<br />
<br />
where ''layout'' is a two-letter [[Wikipedia:ISO 3166-1 alpha-2#Officially assigned code elements|country code]]. Use {{ic|localectl list-keymaps}} to list all available keymaps.<br />
<br />
If certain special characters appear as white squares or other symbols, you may wish to change the console font. See [[Fonts#Previewing_and_testing]] for details.<br />
<br />
== Establish an internet connection ==<br />
<br />
{{Warning|As of [http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id&#61;dee4c244254bb49d1ffa8bd7171ae9cce596d2d0 v197], udev no longer assigns network interface names according to the ''wlanX'' and ''ethX'' naming scheme. If you are coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named ''wlan0'', or that your wired interface is named ''eth0''. You can use the command {{ic|ip link}} to discover the names of your interfaces.}}<br />
<br />
The ''dhcpcd'' network daemon starts automatically during boot of the live system and will attempt to start a wired connection. Try to ping a server to see if a connection was established. For example, Google's webservers:<br />
<br />
{{hc|# ping -c 3 www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=2 ttl=50 time=18.2 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=3 ttl=50 time=16.6 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br />
rtt min/avg/max/mdev = 16.660/17.320/18.254/0.678 ms<br />
}}<br />
<br />
If you get a {{ic|ping: unknown host}} error, first check if there is an issue with your cable. If not, you will need to set up the network manually, as explained below. Once a connection is established move on to [[#Prepare the storage devices]].<br />
<br />
{{Tip|<br />
* The ''elinks'' browser is available in the live system: it can be useful for example to authenticate in RADIUS-protected networks. <br />
* The system you are going to install in this guide makes no pre-assumptions regarding network access. For an easy start after the first boot, it may be helpful to stick to the method that got you connected with the live medium and copy relevant configuration to the new system before you [[#Chroot and configure the base system]] later.}}<br />
<br />
=== Static IP ===<br />
<br />
Follow this procedure if you need to set up a wired connection via a static IP address.<br />
<br />
Identify the name of your ethernet interface:<br />
<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000<br />
link/ether 00:11:25:31:69:20 brd ff:ff:ff:ff:ff:ff<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000<br />
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
In this example, the ethernet interface is {{ic|enp2s0f0}}. If you are unsure, your ethernet interface is likely to start with the letter "e", and unlikely to be "lo" or start with the letter "w".<br />
<br />
See [[Network_configuration#Static_IP_address]] for required settings. Configure a static profile for ''dhcpcd'' in {{ic|/etc/dhcpcd.conf}} with your settings, for example: <br />
<br />
interface enp2s0f0<br />
static ip_address=192.168.0.10/24<br />
static routers=192.168.0.1<br />
static domain_name_servers=192.168.0.1 8.8.8.8<br />
<br />
Restart {{ic|dhcpcd.service}}:<br />
<br />
# systemctl restart dhcpcd.service<br />
<br />
You should now have a working network connection. If you do not, see [[Network configuration]] page.<br />
<br />
=== Wireless ===<br />
<br />
{{Warning|Wireless chipset firmware packages (for cards which require them) are pre-installed under {{ic|/usr/lib/firmware}} in the live environment (on CD/USB stick) '''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!''' Package installation is covered later in this guide. Ensure installation of both your wireless module and firmware before rebooting! See [[Wireless network configuration]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset.}}<br />
<br />
Use [[netctl]]'s ''wifi-menu'' to connect to a wireless network:<br />
<br />
# wifi-menu<br />
<br />
This should bring you a menu of wifi networks if your computer has only one Wi-Fi device (mostly the case in laptops).<br />
<br />
If your computer has more than one Wi-Fi device, you need to choose one and pass its interface name to ''wifi-menu''. First, identify the name of the needed interface:<br />
<br />
{{hc|# iw dev|2=<br />
phy#0<br />
Interface wlp3s0<br />
ifindex 3<br />
wdev 0x1<br />
addr 00:11:22:33:44:55<br />
type managed<br />
}}<br />
<br />
This example shows {{ic|wlp3s0}} as the only available wireless interface, for simplicity. If you are unsure, wireless interfaces are likely to start with the letter "w", and unlikely to be "lo" or start with the letter "e".<br />
<br />
Now try ''wifi-menu'' again by passing it the interface name:<br />
<br />
# wifi-menu wlp3s0<br />
<br />
See the sample configuration in [[WPA2 Enterprise#netctl]] for networks that require both a username and password.<br />
<br />
You should now have a working wireless network connection. If you do not or even failed to identify the wireless interface, see [[#Without wifi-menu]] below or the detailed [[Wireless network configuration]] page.<br />
<br />
==== Without wifi-menu ====<br />
<br />
Bring the interface up with:<br />
<br />
# ip link set wlp3s0 up<br />
<br />
To verify that the interface is up, inspect the output of the following command:<br />
<br />
{{hc|# ip link show wlp3s0|<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000<br />
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
The {{ic|UP}} in {{ic|<BROADCAST,MULTICAST,UP,LOWER_UP>}} is what indicates the interface is up, not the later {{ic|state DOWN}}.<br />
<br />
Most wireless chipsets require firmware in addition to a corresponding driver. The kernel tries to identify and load both automatically. If you get output like {{ic|SIOCSIFFLAGS: No such file or directory}}, this means you will need to manually load the firmware. If unsure, invoke ''dmesg'' to query the kernel log for a firmware request from the wireless chipset. For example, if you have an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
<br />
{{hc|<nowiki># dmesg | grep firmware</nowiki>|<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
}}<br />
<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
Next, scan for available networks using {{ic|iw dev wlp3s0 scan <nowiki>|</nowiki> grep SSID}}, then connect to a network with:<br />
<br />
# wpa_supplicant -B -i wlp3s0 -c <(wpa_passphrase "''ssid''" "''psk''")<br />
<br />
You need to replace {{ic|''ssid''}} with the name of your network and {{ic|''psk''}} with your wireless password, '''leaving the quotes around the network name and password'''.<br />
<br />
Finally, you have to give your interface an IP address. This can be set manually or using dhcp:<br />
<br />
# dhcpcd wlp3s0<br />
<br />
If that does not work, issue the following commands:<br />
<br />
# echo 'ctrl_interface=DIR=/run/wpa_supplicant' > /etc/wpa_supplicant.conf<br />
# wpa_passphrase "''ssid''" "''psk''" >> /etc/wpa_supplicant.conf<br />
# ip link set ''interface'' up<br />
# wpa_supplicant -B -D nl80211,wext -c /etc/wpa_supplicant.conf -i ''interface''<br />
# dhcpcd -A ''interface''<br />
<br />
Setting the interface up at step 3 may not be needed, but does no harm in any case.<br />
<br />
=== Analog modem, ISDN, or PPPoE DSL ===<br />
<br />
For xDSL, dial-up, and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Behind a proxy server ===<br />
<br />
If you are behind a proxy server, you will need to export the {{ic|http_proxy}} and {{ic|ftp_proxy}} environment variables. See [[Proxy settings]] for more information.<br />
<br />
== Prepare the storage devices ==<br />
<br />
In this step, the storage devices that will be used by the new system will be prepared. Read [[Partitioning]] for a more general overview.<br />
<br />
{{Warning|Partitioning will destroy existing data. Before proceeding, you '''must''' backup all data that needs to be preserved.}}<br />
<br />
{{Tip|<br />
* Users intending to create stacked block devices for [[LVM]], [[disk encryption]] or [[RAID]], should keep those instructions into consideration when preparing the partitions.<br />
* If intending to install to a USB flash key, see [[Installing Arch Linux on a USB key]].}}<br />
<br />
=== Identify the devices ===<br />
<br />
The first step is to identify the devices where the new system will be installed. The following command will show all the available devices:<br />
<br />
# lsblk<br />
<br />
This will list all devices connected to your system along with their partition schemes, including that used to host and boot live Arch installation media (e.g. a USB drive). Not all devices listed will therefore be viable or appropriate mediums for installation. To filter out inappropriate results, the command can optionally be amended as follows:<br />
<br />
# lsblk | grep -v "rom\|loop\|airoot"<br />
<br />
Devices (e.g. hard disks) will be listed as {{ic|sd''x''}}, where {{ic|''x''}} is a lower-case letter starting from {{ic|a}} for the first device ({{ic|sda}}), {{ic|b}} for the second device ({{ic|sdb}}), and so on. Existing partitions on those devices will be listed as {{ic|sd''xY''}}, where {{ic|''Y''}} is a number starting from {{ic|1}} for the first partition, {{ic|2}} for the second, and so on. In the example below, only one device is available ({{ic|sda}}), and that device uses only one partition ({{ic|sda1}}):<br />
<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 80G 0 disk<br />
└─sda1 8:1 0 80G 0 part<br />
<br />
The {{ic|sd''xY''}} convention will be used in the examples provided below for partition tables, partitions, and file systems. As they are just examples, it is important to ensure that any necessary changes to device names, partition numbers, and/or partition sizes (etc.) are made. Do not just blindly copy and paste the commands.<br />
<br />
If the existing partition scheme needs not be changed, skip to [[#Create filesystems]], otherwise continue reading the following section.<br />
<br />
=== Partition table types ===<br />
<br />
If you are installing alongside an existing installation (i.e. dual-booting), a partition table will already be in use. If the devices are not partitioned, or the current partitions table or scheme needs to be changed, you will first have to determine the partition tables (one for each device) in use or to be used.<br />
<br />
{{Warning|If Arch and Windows are dual-booting from same device, then Arch '''must''' follow the same firmware boot mode and partitioning combination already used, or Windows will fail to boot. See [[Windows and Arch Dual Boot#Important information]] for more details.}}<br />
<br />
There are two types of partition table:<br />
<br />
* [[Master Boot Record| MBR]]: Intended for BIOS systems (also referred to as "msdos")<br />
* [[GUID Partition Table| GPT]]: Intended for UEFI systems<br />
<br />
Any existing partition table can be identified with the following command for each device:<br />
<br />
# parted /dev/sd''x'' print<br />
<br />
=== Partitioning tools ===<br />
<br />
For each device to be partitioned, a proper tool must be chosen according to the partition table to be used. Several partitioning tools are provided by the Arch installation medium, including:<br />
<br />
* [[parted]]: MBR and GPT<br />
* [[Partitioning#Fdisk usage summary|fdisk]], '''cfdisk''', '''sfdisk''': MBR and GPT<br />
* [[Partitioning#Gdisk usage summary|gdisk]], '''cgdisk''', '''sgdisk''': GPT<br />
<br />
{{Warning|Using a partitioning tool that is incompatible with your partition table type will likely result in the destruction of that table, along with any existing partitions/data.}}<br />
<br />
{{Tip|The devices may also be partitioned before booting the Arch installation media, possibly using alternative live systems with other partitioning tools. For example beginners might find it easier to use a graphical partitioning tool such as [[GParted]], which is also provided as a [http://gparted.sourceforge.net/livecd.php live CD] and works with both MBR and GPT partition tables.}}<br />
<br />
==== Using parted in interactive mode ====<br />
<br />
All the examples provided below make use of ''parted'', as it can be used for both BIOS/MBR and UEFI/GPT. It will be launched in ''interactive mode'', which simplifies the partitioning process and reduces unnecessary repetition by automatically applying all partitioning commands to the specified device.<br />
<br />
In order to start operating on a device, execute:<br />
<br />
# parted /dev/sd''x''<br />
<br />
You will notice that the command-line prompt changes from a hash ({{ic|#}}) to {{ic|(parted)}}: this also means that the new prompt is not a command to be manually entered when running the commands in the examples.<br />
<br />
To see a list of the available commands, enter:<br />
<br />
(parted) help<br />
<br />
When finished, or if wishing to implement a partition table or scheme for another device, exit from parted with:<br />
<br />
(parted) quit<br />
<br />
After exiting, the command-line prompt will change back to {{ic|#}}.<br />
<br />
=== Create new partition table ===<br />
<br />
You need to (re)create the partition table of a device when it has never been partitioned before, or when you want to change the type of its partition table. Recreating the partition table of a device is also useful when the partition scheme needs to be restructured from scratch.<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not erase the partition table. Doing so will destroy all existing data on the device, including the UEFI partition with the Windows ''.efi'' file required to boot it.<br />
* MBR is designed specifically for use with BIOS systems, and GPT is designed for UEFI. It is not recommended for less experienced users to break this convention as both have features and/or limitations that may be incompatible with your hardware (e.g. MBR cannot cope with devices larger than 2 TiB). [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/] If for any reason you do not wish to follow this convention, see [http://mjg59.dreamwidth.org/8035.html] and [http://rodsbooks.com/gdisk/bios.html] for more information and possible workarounds.}}<br />
<br />
Open each device whose partition table must be (re)created with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
To then create a new MBR/msdos partition table for BIOS systems, use the following command:<br />
<br />
(parted) mklabel msdos<br />
<br />
To create a new GPT partition table for UEFI systems instead, use:<br />
<br />
(parted) mklabel gpt<br />
<br />
=== Partition schemes ===<br />
<br />
You can decide the number and size of the partitions the devices should be split into, and which directories will be used to mount the partitions in the installed system (also known as ''mount points''). The mapping from partitions to directories is the [[Partitioning#Partition scheme|partition scheme]], which must comply with the following requirements:<br />
<br />
* At least a partition for the {{ic|/}} (''root'') directory '''must''' be created.<br />
* Depending on the motherboard's firmware interface, the chosen [[#Partition table types]], and in some cases also the chosen [[boot loader]], the following additional partitions '''must''' be created:<br />
** '''BIOS/MBR''': no additional partition required.<br />
** '''UEFI/GPT''': one [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]].<br />
<br />
In the examples below it is assumed that a new and contiguous partitioning scheme is applied to a single device. Some optional partitions will also be created for the {{ic|/boot}} and {{ic|/home}} directories: see also [[Arch filesystem hierarchy]] for an explanation of the purpose of the various directories; if separate partitions for directories like {{ic|/boot}} or {{ic|/home}} are not created, these will simply be contained in the {{ic|/}} partition. Also the creation of an optional partiton for [[swap space]] will be illustrated.<br />
<br />
If not already open in a ''parted'' interactive session, open each device to be partitioned with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
The following command will be used to create partitions:<br />
<br />
(parted) mkpart ''part-type'' ''fs-type'' ''start'' ''end''<br />
<br />
* {{ic|''part-type''}} is one of {{ic|primary}}, {{ic|extended}} or {{ic|logical}}, and is meaningful only for MBR partition tables.<br />
* {{ic|''fs-type''}} is an identifier chosen among those listed by entering {{ic|help mkpart}} as the closest match to the file system that you will use in [[#Create filesystems]]. The ''mkpart'' command does not actually create the file system: the {{ic|''fs-type''}} parameter will simply be used by ''parted'' to set a 1-byte code that is used by boot loaders to "preview" what kind of data is found in the partition, and act accordingly if necessary. See also [[Wikipedia:Disk partitioning#PC partition types]].<br />
: {{Tip|Most [[Wikipedia:File_system#Linux|Linux native file systems]] map to the same partition code ([[Wikipedia:Partition type#PID_83h|0x83]]), so it is perfectly safe to e.g. use {{ic|ext2}} for an ''ext4''-formatted partition.}}<br />
* {{ic|''start''}} is the beginning of the partition from the start of the device. It consists of a number followed by a [http://www.gnu.org/software/parted/manual/parted.html#unit unit], for example {{ic|1M}} means start at 1MiB.<br />
* {{ic|''end''}} is the end of the partition from the start of the device (''not'' from the {{ic|''start''}} value). It has the same syntax as {{ic|''start''}}, for example {{ic|100%}} means end at the end of the device (use all the remaining space).<br />
<br />
{{Warning|It is important that the partitions do not overlap each other: if you do not want to leave unused space in the device, make sure that each partition starts where the previous one ends.}}<br />
<br />
{{Note|''parted'' may issue a warning like:<br />
<br />
Warning: The resulting partition is not properly aligned for best performance.<br />
Ignore/Cancel?<br />
<br />
In this case, read [[Partitioning#Partition alignment]] and follow [[GNU Parted#Alignment]] to fix it.}}<br />
<br />
The following command will be used to flag the partition that contains the {{ic|/boot}} directory as bootable:<br />
<br />
(parted) set ''partition'' boot on<br />
<br />
* {{ic|''partition''}} is the number of the partition to be flagged (see the output of the {{ic|print}} command).<br />
<br />
==== UEFI/GPT examples ====<br />
<br />
In every instance, a special bootable [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] is required.<br />
<br />
{{Warning|If dual-booting with an existing installation of Windows on a UEFI/GPT system, the existing UEFI partition must not be deleted. Doing so will destroy the ''.efi'' file required to boot Windows.}}<br />
<br />
If creating a new EFI System Partition, use the following commands (the recommended size is 512MiB):<br />
<br />
(parted) mkpart ESP fat32 1MiB 513MiB<br />
(parted) set 1 boot on<br />
<br />
The remaining partition scheme is entirely up to you. For one other partition using 100% of remaining space:<br />
<br />
(parted) mkpart primary ext3 513MiB 100%<br />
<br />
For separate {{ic|/}} (20GiB) and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary ext3 20.5GiB 100%<br />
<br />
And for separate {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary linux-swap 20.5GiB 24.5GiB<br />
(parted) mkpart primary ext3 24.5GiB 100%<br />
<br />
==== BIOS/MBR examples ====<br />
<br />
For a minimum single primary partition using all available disk space, the following command would be used:<br />
<br />
(parted) mkpart primary ext3 1MiB 100%<br />
(parted) set 1 boot on<br />
<br />
In the following instance, a 20GiB {{ic|/}} partition will be created, followed by a {{ic|/home}} partition using all the remaining space:<br />
<br />
(parted) mkpart primary ext3 1MiB 20GiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 20GiB 100%<br />
<br />
In the final example below, separate {{ic|/boot}} (100MiB), {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions will be created:<br />
<br />
(parted) mkpart primary ext3 1MiB 100MiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 100MiB 20GiB<br />
(parted) mkpart primary linux-swap 20GiB 24GiB<br />
(parted) mkpart primary ext3 24GiB 100%<br />
<br />
=== Create filesystems ===<br />
<br />
Once the partitions have been created, each must be formatted with an appropriate [[file system]], ''except'' for swap partitions. All available partitions on the intended installation device can be listed with the following command:<br />
<br />
# lsblk /dev/sd''x''<br />
<br />
With the exceptions noted below, it is recommended to use the {{ic|ext4}} file system:<br />
<br />
# mkfs.ext4 /dev/sd''xY''<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not re-format the UEFI partition. Doing so will destroy all existing data on that partition, including the Windows ''.efi'' file required to boot it.<br />
* If a new UEFI system partition has been created on a UEFI/GPT system, it must be formatted with a {{ic|fat32}} or {{ic|vfat32}} file system. Failure to do so will result in an unbootable installation:<br />
:{{bc|# mkfs.vfat -F32 /dev/sd''xY''}}}}<br />
<br />
=== Activate swap ===<br />
<br />
If a swap partition has been created, it must be set up and activated with:<br />
<br />
# mkswap /dev/sd''xY''<br />
# swapon /dev/sd''xY''<br />
<br />
=== Mount the partitions ===<br />
<br />
{{Note|Swap partitions must '''not''' be mounted here.}}<br />
<br />
The {{ic|/}} (root) partition must be mounted '''first''': this is because any directories such as {{ic|/boot}} or {{ic|/home}} that have separate partitions will have to be created in the root file system. The {{ic|/mnt}} directory of the live system will be used to mount the root partition, and consequently all the other partitions will stem from there. If the root partition's name is {{ic|sd''xR''}}, do:<br />
<br />
# mount /dev/sd''xR'' /mnt<br />
<br />
Once the {{ic|/}} partition has been mounted, any remaining partitions may be mounted in any order. The general procedure is to first create the mount point, and then mount the partition to it. If using a separate {{ic|/boot}} partition:<br />
<br />
# mkdir -p /mnt/boot<br />
# mount /dev/sd''xB'' /mnt/boot<br />
<br />
{{Note|Using {{ic|/boot}} is recommended also for mounting the EFI System Partition on UEFI/GPT system. See [[EFISTUB]] and related articles for alternatives.}}<br />
<br />
If using a separate {{ic|/home}} partition:<br />
<br />
# mkdir -p /mnt/home<br />
# mount /dev/sd''xH'' /mnt/home<br />
<br />
Once all the remaining partitions, if any, have been mounted, the devices are ready to install Arch.<br />
<br />
== Select a mirror ==<br />
<br />
You may want to edit the {{ic|mirrorlist}} file and place your preferred mirror first. A copy of this file will be installed on your new system by ''pacstrap'' as well, so it is worth getting it right.<br />
<br />
{{hc|# nano /etc/pacman.d/mirrorlist|<br />
##<br />
## Arch Linux repository mirrorlist<br />
## Sorted by mirror score from mirror status page<br />
## Generated on YYYY-MM-DD<br />
##<br />
<br />
<nowiki>Server = http://mirror.example.xyz/archlinux/$repo/os/$arch</nowiki><br />
...}}<br />
<br />
If you want, you can make it the ''only'' mirror available by deleting all other lines, but it is usually a good idea to have a few more, in case the first one goes offline. Should you change your mirror list at a later stage, refresh all package lists with {{ic|pacman -Syyu}}. See [[Mirrors]] for more information.<br />
<br />
== Install the base system ==<br />
<br />
The base system is installed using the ''pacstrap'' script. Without the {{ic|-i}} switch, every package from the {{Grp|base}} [[Pacman#Installing_package_groups|group]] is installed without prompting. To build packages from the [[AUR]] or with [[ABS]], you will also need the {{Grp|base-devel}} group.<br />
<br />
# pacstrap -i /mnt base base-devel<br />
<br />
Other packages can be installed later using [[pacman]].<br />
<br />
See [[Pacman#Troubleshooting]] and [[Pacman-key#Troubleshooting]] in case of errors.<br />
<br />
== Generate an fstab ==<br />
<br />
[[Wikipedia:Universally_unique_identifier|UUID]]s are used because they have certain advantages (see [[fstab#Identifying filesystems]]). If you prefer labels instead, replace the {{ic|-U}} option with {{ic|-L}}:<br />
<br />
# genfstab -U -p /mnt >> /mnt/etc/fstab<br />
# nano /mnt/etc/fstab<br />
<br />
{{Warning|The {{ic|fstab}} file should always be checked after generating it. If you encounter errors running ''genfstab'' or later in the install process, do '''not''' run ''genfstab'' again; just edit the {{ic|fstab}} file. See [[fstab#Field definitions]] for syntax information.}}<br />
<br />
== Chroot and configure the base system ==<br />
<br />
Next, [[Change root|chroot]] into your newly installed system:<br />
<br />
# arch-chroot /mnt /bin/bash<br />
<br />
At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system. These can either be created if they do not exist, or edited if you wish to change the defaults.<br />
<br />
Closely following and understanding these steps is of key importance to ensure a properly configured system.<br />
<br />
{{Warning|Do not assume that the tools you used from the ISO are automatically installed. For example, if you used ''wifi-menu'' to gain network access during the installation and want to continue so after the first boot, you will have to install ''dialog'' to use it. The following section specifies such cases, do follow it closely to avoid a hiccup in your fresh install.}}<br />
<br />
=== Locale ===<br />
<br />
Locales define which language the system uses and other regional considerations, such as currency denomination, numerology and character sets. Possible values are listed in {{ic|/etc/locale.gen}}, with the active locale defined in {{ic|locale.conf}} files.<br />
<br />
All entries in {{ic|locale.gen}} are commented out (preceded by {{ic|#}}) by default. Uncomment {{ic|en_US.UTF-8 UTF-8}}, as well as other needed localisations. {{ic|UTF-8}} is highly recommended over other options.<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
...<br />
#en_SG ISO-8859-1<br />
en_US.UTF-8 UTF-8<br />
#en_US ISO-8859-1<br />
...<br />
}}<br />
<br />
Before locales can be enabled, they must be ''generated'':<br />
<br />
# locale-gen<br />
<br />
Create {{ic|/etc/locale.conf}}, where {{ic|LANG}} refers to the first column of an uncommented entry in {{ic|/etc/locale.gen}}.<br />
<br />
# echo LANG=''en_US.UTF-8'' > /etc/locale.conf<br />
<br />
Export the chosen locale:<br />
<br />
# export LANG=''en_US.UTF-8''<br />
<br />
{{Note|<br />
* Choosing {{ic|en_US.UTF-8}} as the system locale allows to keep system logs in English for easier troubleshooting. Users may override this setting for their session as described in [[Locale#Setting the locale]].<br />
* {{ic|LANG}} acts as the default value for the locale-related {{ic|LC_*}} variables. To use other locales for these variables, run ''locale'' to see the available options and add them to {{ic|locale.conf}}. It is not recommended to set the {{ic|LC_ALL}} variable. See [[Locale]] for details.}}<br />
<br />
=== Console font and keymap ===<br />
<br />
If you changed the default console keymap and font in [[#Keyboard layout]], create {{ic|/etc/vconsole.conf}} to make those changes persist in the installed system. It is important {{ic|KEYMAP}} matches the value initially set with {{ic|loadkeys}}, to ensure correct entry of [[#Set the root password|the root password]] on reboot.<br />
<br />
{{hc|# nano /etc/vconsole.conf|2=<br />
KEYMAP=''de-latin1''<br />
FONT=''lat9w-16''<br />
}}<br />
<br />
These settings only apply to virtual consoles, not [[Xorg]]. See [[Fonts#Console fonts]] for more information.<br />
<br />
=== Time zone ===<br />
<br />
Available time zones and subzones can be found in the {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} directories, and listed with the ''ls'' command. Create a symbolic link {{ic|/etc/localtime}} to your subzone file {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}}:<br />
<br />
# ln -s /usr/share/zoneinfo/''Zone''/''SubZone'' /etc/localtime<br />
<br />
You may use [http://tldp.org/LDP/abs/html/tabexpansion.html tab completion] to show available zones and subzones. Example:<br />
<br />
# ln -s /usr/share/zoneinfo/Europe/Minsk /etc/localtime<br />
<br />
If you get {{ic|ln: failed to create symbolic link '/etc/localtime': File exists}}, check the existing file with {{ic|ls -l /etc/localtime}} and add the {{ic|-f}} option to the ''ln'' command to overwrite it.<br />
<br />
=== Hardware clock ===<br />
<br />
If you have multiple operating systems installed in the same machine, they will all derive the current time from the same hardware clock, which must be set to either UTC or ''localtime''. For this reason you must make sure that all the operating systems see the hardware clock as providing time in the same chosen [[Time#Time standard|standard]], otherwise some of them will perform the time zone adjustement for the system clock, while others will not.<br />
<br />
In particular, it is strongly recommended to set the hardware clock to UTC, in order to avoid conflicts between the installed operating systems. For example, if the hardware clock was set to ''localtime'', more than one operating system may adjust it after a [[Wikipedia:Daylight_saving_time|DST]] change, thus resulting in an overcorrection; more problems may arise when travelling between different time zones and using one of the operating systems to reset the system/hardware clock.<br />
<br />
To set the hardware clock to UTC in Linux, run:<br />
<br />
# hwclock --systohc --utc<br />
<br />
The ''hwclock'' command also generates the {{ic|/etc/adjtime}} file.<br />
<br />
{{Note|Using UTC for the hardware clock does not mean that software will display time in UTC. However, the system setup/BIOS interface will instead: this should be neither surprising nor treated as a bug.}}<br />
<br />
{{Warning|Windows systems use ''localtime'' by default. Using ''localtime'' on Arch systems may lead to several known and unfixable bugs, but there are no plans to drop support for ''localtime''. It is, though, recommended to set Windows to use UTC instead, and prevent it from synchronising time. See [[Time#UTC in Windows]].}}<br />
<br />
=== Kernel modules ===<br />
<br />
Needed kernel modules are automatically loaded by [[udev]], so you will rarely need to load modules manually. See [[Kernel modules]] for details.<br />
<br />
=== Hostname ===<br />
<br />
Set the [[Network_configuration#Set_the_hostname|hostname]] to your liking:<br />
<br />
# echo ''myhostname'' > /etc/hostname<br />
<br />
Add the same hostname to {{ic|/etc/hosts}}:<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost ''myhostname''<br />
::1 localhost.localdomain localhost ''myhostname''<br />
<br />
=== Configure the network ===<br />
<br />
You need to configure the network again, but this time for your newly installed environment. The procedure and prerequisites are similar to the one described [[#Establish an internet connection|above]], except we are going to make it persistent and automatically run at boot.<br />
<br />
As a first step, identify the network interface name you want to configure the connection for with {{ic|ip link}}.<br />
<br />
{{Note|<br />
* For more in-depth information on network configuration, visit [[Network configuration]] and [[Wireless network configuration]].<br />
* If you would like to use the old interface naming scheme (i.e. {{ic|eth''X''}} and {{ic|wlan''X''}}) you can accomplish this by creating an empty file at {{ic|/etc/udev/rules.d/80-net-setup-link.rules}} which will mask the file of the same name located under {{ic|/usr/lib/udev/rules.d}}.<br />
}}<br />
<br />
Now select a daemon to handle the configuration and operation. Several are listed below; only select '''one''' of them for the new system.<br />
<br />
==== Wired ====<br />
<br />
; Using dhcpcd<br />
A simple option for adapter configuration is to use the DHCP Client Daemon, the method used by default with the install medium. See [[Dhcpcd#Running]].<br />
<br />
Users requiring only '''single wired network connection''' can simply enable the ''dhcpcd'' service for the interface:<br />
<br />
# systemctl enable dhcpcd@''interface_name''.service<br />
<br />
If static IP settings are required, adjust the profile configuration as described in [[#Static IP]]. <br />
<br />
; Using systemd-networkd<br />
<br />
The Arch default init system, [[systemd]] includes built-in support for managing adapters using both DHCP and static IP setups. Configuration is simple. See [[Systemd-networkd#Required_services_and_setup]].<br />
<br />
; Using netctl<br />
<br />
Another option is [[netctl]] which is a CLI-based tool used to configure and manage network connections via user-created profiles. Create a profile as shown in [[netctl#Example profiles]], then enable it as described in [[netctl#Basic method]].<br />
<br />
==== Wireless ====<br />
<br />
All of the tools listed in [[#Wired]] above can activate wireless connections. For wireless, however, ''dhcpcd'' and ''systemd-networkd'' require a separate configuration of the connection in the wireless backend, [[wpa_supplicant]], first. If you anticipate to connect the machine to different wireless networks over time, a tool which provides its own connection management may be easier to handle. Aside from [[netctl]] introduced below, [[Wireless network configuration#Automatic setup]] lists other choices. <br />
<br />
{{Note|If your wireless adapter requires a firmware (as described in the above [[#Wireless|Establish an internet connection]] section and also in the article [[Wireless network configuration#Device driver]]), install the package containing your firmware. Most of the time, the {{Pkg|linux-firmware}} package will contain the needed firmware. Though for some devices, the required firmware might be in its own package. For example:<br />
{{bc|# pacman -S zd1211-firmware}}<br />
See [[Wireless network configuration#Installing driver/firmware]] for more info.}}<br />
<br />
Install {{Pkg|iw}} and {{Pkg|wpa_supplicant}} which you will need to connect to a network:<br />
<br />
# pacman -S iw wpa_supplicant<br />
<br />
===== Adding wireless networks =====<br />
<br />
; Using wifi-menu<br />
<br />
Install {{Pkg|dialog}}, which is required for ''wifi-menu'':<br />
<br />
# pacman -S dialog<br />
<br />
After finishing the rest of this installation and rebooting, you can connect to the network with:<br />
<br />
# wifi-menu ''interface_name''<br />
<br />
Where {{ic|''interface_name''}} is the interface of your wireless chipset.<br />
<br />
{{Warning|Do not use ''wifi-menu'' now, instead wait until you have finished this guide and have rebooted. It will not work now because a process spawned by this command will conflict with the one you have running outside of the chroot. Alternatively, you could just configure a network profile manually using the following templates so that you do not have to worry about using ''wifi-menu'' at all.}}<br />
<br />
; Using manual netctl profiles<br />
<br />
Copy a network profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/wireless-wpa my-network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|ESSID}} and {{ic|Key}}):<br />
<br />
# nano my-network<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my-network<br />
<br />
===== Connect automatically to known networks =====<br />
<br />
{{Warning|This method cannot be used with explicitely enabled [[Netctl#Configuration|profiles]], i.e. through {{ic|netctl enable ''profile''}}.}}<br />
<br />
Install {{Pkg|wpa_actiond}}, which is required for {{ic|netctl-auto}}:<br />
<br />
# pacman -S wpa_actiond<br />
<br />
Enable the {{ic|netctl-auto}} service, which will connect to known networks and gracefully handle roaming and disconnects:<br />
<br />
# systemctl enable netctl-auto@''interface_name''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-ifplugd}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-auto}}.}}<br />
<br />
==== Analog modem, ISDN or PPPoE DSL ====<br />
<br />
For xDSL, dial-up and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Create an initial ramdisk environment ===<br />
<br />
As [[mkinitcpio]] was run on installation of {{Pkg|linux}} with ''pacstrap'', most users can use the defaults provided in {{ic|mkinitcpio.conf}}. For special configurations, set the correct [[Mkinitcpio#HOOKS|hooks]] in {{ic|/etc/mkinitcpio.conf}} and [[Mkinitcpio#Image_creation_and_activation|re-generate the initramfs image]].<br />
<br />
=== Set the root password ===<br />
<br />
Set the root password with:<br />
<br />
# passwd<br />
<br />
=== Install and configure a bootloader ===<br />
<br />
See [[Boot loaders]] for available choices and configurations. [[Microcode]] updates for Intel CPUs must also be configured after installing the boot loader.<br />
<br />
==== For BIOS motherboards ====<br />
<br />
Here, installation with '''GRUB''' and '''MBR''' is demonstrated. <br />
<br />
Install the {{Pkg|grub}} package; to have GRUB search for other installed operating systems, install {{Pkg|os-prober}} in addition:<br />
<br />
# pacman -S grub os-prober<br />
<br />
Install the bootloader to the drive Arch was installed to (do '''not''' append a partition number, or {{ic|/dev/sda''X''}}):<br />
<br />
# grub-install --target=i386-pc --recheck ''/dev/sda''<br />
<br />
Automatically generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|A sample {{ic|/boot/grub/grub.cfg}} is included with the {{Pkg|grub}} package, and subsequent {{ic|grub-*}} commands may not over-write it. Ensure your intended changes are in {{ic|grub.cfg}}, rather than in {{ic|grub.cfg.new}} or similar file.}}<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
==== For UEFI motherboards ====<br />
<br />
Here, installation with ''gummiboot'' is demonstrated. First install {{Pkg|dosfstools}} to manipulate the EFI System Partition post-installation, and {{Pkg|efibootmgr}} to create a UEFI boot entry (used by bootmanager installation scripts):<br />
<br />
# pacman -S dosfstools efibootmgr<br />
<br />
{{Note|<br />
* For UEFI boot, the drive needs to be GPT-partitioned and an [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] (512 MiB or larger, gdisk type {{ic|EF00}}, formatted with FAT32) must be present. In the following examples, this partition is assumed to be mounted at {{ic|/boot}}. If you have followed this guide from the beginning, you have already done all of these.<br />
* It is strongly recommended to have the EFI System Partition mounted at {{ic|/boot}} as this is required to automatically update Gummiboot.<br />
}}<br />
<br />
Install the {{Pkg|gummiboot}} package and run the automated installation script, replacing {{ic|'''$esp'''}} with the location of your EFI System Partiton, usually {{ic|/boot}}:<br />
<br />
# pacman -S gummiboot<br />
# gummiboot --path='''$esp''' install<br />
<br />
Gummiboot will automatically be detected by firmware that requires that the bootable {{ic|bootx64.efi}} stub be placed in {{ic|'''$esp'''/EFI/boot}}, and will in turn automatically detect the presence of any other installed operating systems using ''.efi'' stubs. However, it will still be necessary to manually create a configuration file for Gummiboot.<br />
<br />
First, create {{ic|'''$esp'''/loader/entries/arch.conf}} and add the following, replacing {{ic|/dev/sdaX}} with your '''root''' partition (most likely {{ic|/dev/sda2}} if {{ic|/dev/sda1}} is the ESP):<br />
<br />
{{hc|# nano '''$esp'''/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
<br />
Second, create {{ic|'''$esp'''/loader/loader.conf}} and add the following, replacing the timeout value (in seconds) with your own choice:<br />
{{hc|# nano '''$esp'''/loader/loader.conf|2=<br />
default arch<br />
timeout 5<br />
}}<br />
<br />
See [[gummiboot]] for more information.<br />
<br />
== Unmount the partitions and reboot ==<br />
<br />
Exit from the chroot environment:<br />
<br />
# exit<br />
<br />
{{Note|While partitions are unmounted automatically by ''systemd'' on shutdown, you may do so manually with {{ic|umount -R /mnt}} as a safety measure. If the partition is "busy", you can find the cause with [[fuser]].}}<br />
<br />
Reboot the computer:<br />
<br />
# reboot<br />
<br />
Remove the installation media, or you may boot back into it. You can log into your new installation as ''root'', using the password you specified with ''passwd''.<br />
<br />
== Post-installation ==<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready to be built into whatever you wish or require for your purposes. You are now ''strongly'' advised to read the [[General recommendations]] article, especially the first two sections. Its other sections provide links to post-installation tutorials like setting up a graphical user interface, sound or a touchpad.<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].<br />
<br />
If you need a working [[desktop environment]] in quick, you can install [[GNOME]], [[Xorg]], [[GDM]]:<br />
<br />
# pacman -S gnome gnome-extra xorg gdm<br />
<br />
Then you start [[GDM]] by:<br />
<br />
# systemctl start gdm<br />
<br />
This might install extra unwanted packages. You should always install packages that fit your own needs. You are still ''strongly'' advised to read the [[General recommendations]] article.</div>Sarenhttps://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=373362Beginners' guide2015-05-11T14:37:54Z<p>Saren: LOL</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:Beginners' Guide]]<br />
[[bg:Beginners' Guide]]<br />
[[cs:Beginners' Guide]]<br />
[[da:Beginners' Guide]]<br />
[[de:Anleitung für Einsteiger]]<br />
[[el:Beginners' Guide]]<br />
[[es:Beginners' Guide]]<br />
[[fa:راهنمای تازهکارها]]<br />
[[fr:Installation]]<br />
[[he:Beginners' Guide]]<br />
[[hr:Beginners' Guide]]<br />
[[hu:Beginners' Guide]]<br />
[[id:Beginners' Guide]]<br />
[[it:Beginners' Guide]]<br />
[[ja:ビギナーズガイド]]<br />
[[ko:Beginners' Guide]]<br />
[[lt:Beginners' Guide]]<br />
[[nl:Beginners' Guide]]<br />
[[pl:Beginners' Guide]]<br />
[[pt:Beginners' Guide]]<br />
[[ro:Ghidul începătorilor]]<br />
[[ru:Beginners' guide]]<br />
[[sk:Beginners' Guide]]<br />
[[sr:Beginners' Guide]]<br />
[[sv:Nybörjarguiden]]<br />
[[tr:Yeni başlayanlar rehberi]]<br />
[[uk:Beginners' Guide]]<br />
[[zh-CN:Beginners' guide]]<br />
[[zh-TW:Beginners' Guide]]<br />
{{Related articles start}}<br />
{{Related|:Category:Accessibility}}<br />
{{Related|Installation guide}}<br />
{{Related|Diskless system}}<br />
{{Related|Install from SSH}}<br />
{{Related|General recommendations}}<br />
{{Related|General troubleshooting}}<br />
{{Related articles end}}<br />
This document will guide you through the process of installing [[Arch Linux]] using the [https://projects.archlinux.org/arch-install-scripts.git/ Arch Install Scripts]. Before installing, you are advised to skim over the [[FAQ]].<br />
<br />
The community-maintained [[Main page|ArchWiki]] is the primary resource that should be consulted if issues arise. The [[IRC channel]] (irc://irc.freenode.net/#archlinux) and the [https://bbs.archlinux.org/ forums] are also excellent resources if an answer cannot be found elsewhere. In accordance with [[the Arch Way]], you are encouraged to type {{ic|man ''command''}} to read the [[man page]] of any command you are unfamiliar with.<br />
<br />
== Minimum system requirements ==<br />
<br />
Arch Linux should run on any [[Wikipedia:P6 (microarchitecture)|i686]] compatible machine with a minimum of 256 MB RAM. A basic installation with all packages from the {{Grp|base}} group should take less than 800 MB of disk space. If you are working with limited space, this can be trimmed down considerably, but you will have to know what you are doing.<br />
<br />
== Prepare the latest installation medium ==<br />
<br />
{{Tip|Compared to the regular ISO images, the [https://downloads.archlinux.de/iso/archboot/latest archboot] images can take several steps explained in this guide [[Archboot#Interactive_setup_features|interactively]]. See [[Archboot]] for details.}}<br />
<br />
The installation media and their [[GnuPG]] signatures can be acquired from the [https://archlinux.org/download/ Download] page. The single ISO image supports both 32bit and 64bit systems; this guide assumes you use the latest available version.<br />
<br />
It is highly recommended to verify the image signature before use, ''especially when downloading from an HTTP mirror'', as these are run by volunteers who could [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#explanation theoretically serve malicious images]. On a system with GnuPG installed, do this by downloading the ''PGP signature'' (under ''Checksums'') to the ISO directory, and run:<br />
<br />
$ gpg --verify archlinux-''version''-dual.iso.sig<br />
<br />
If the public key is not found, [[GnuPG#Import key|import]] it with {{ic|gpg --recv-keys ''key-id''}}. <br />
<br />
Alternatively, run from an existing Arch Linux installation:<br />
<br />
$ pacman-key -v archlinux-''version''-dual.iso.sig<br />
<br />
Now choose one of the methods from the table below to [[#Boot the installation medium]] on the target machine(s). As the installation process retrieves packages from a remote repository, these methods require an internet connection; see [[Offline installation of packages]] when none is available.<br />
<br />
{| class="wikitable"<br />
! Method<br />
! Articles<br />
! Conditions<br />
|-<br />
| Write the image on flash media or optical disc, then boot from it.<br />
|<br />
* [[USB flash installation media]]<br />
* [[Optical disc drive#Burning]]<br />
|<br />
* Installation on one, or a few machines at most<br />
* Obtain a directly bootable system<br />
|-<br />
| Mount the image on a server machine and have clients boot it over the network.<br />
|<br />
* [[PXE]]<br />
* [[Diskless system]]<br />
|<br />
* Client-server model<br />
* Wired (1Gbit+) network connection<br />
|-<br />
| Mount the image in a running Linux system and install Arch from a chroot environment.<br />
|<br />
* [[Install from existing Linux]]<br />
* [[Install from SSH]]<br />
|<br />
* Replace an existing system with reduced downtime<br />
* Install on the local machine, or a remote one via [[VNC]] or [[SSH]]<br />
|-<br />
| Set up a virtual machine and install Arch as a guest system.<br />
|<br />
* [[:Category:Hypervisors]]<br />
* [[Moving an existing install into (or out of) a virtual machine]]<br />
|<br />
* Operating system compatible with virtualization software<br />
* Obtain an isolated system for learning, testing or debugging<br />
|}<br />
<br />
== Boot the installation medium ==<br />
<br />
Point the current boot device to the media containing the Arch installation media. This is typically achieved by pressing a key during the [[Wikipedia:Power-on self test|POST]] phase, as indicated on the splash screen. Refer to your motherboard's manual for details.<br />
<br />
When the Arch menu appears, select "Boot Arch Linux" and press {{ic|Enter}} to enter the live environment where you will perform the actual installation. Various boot parameters (for example, {{ic|copytoram}}) can be used by editing the boot entry ({{ic|tab}} for syslinux and {{ic|e}} for gummiboot), see [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams README.bootparams] for reference.<br />
<br />
You will be presented with a [[Zsh]] shell prompt, logged in as the root user. ''Zsh'' provides advanced tab completion and other features as part of the [http://grml.org/zsh/ grml config]. For editing text files, the console editor [[nano#Usage|nano]] is suggested.<br />
<br />
=== Booting into UEFI mode ===<br />
<br />
{{Warning|While the choice to install in EFI mode is forward looking, early vendor UEFI implementations carried more bugs than their BIOS counterparts. It is advised to do a search relating your particular mainboard model before proceeding.}}<br />
<br />
In case you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard with UEFI mode enabled, the CD/USB will automatically launch Arch Linux via [[Gummiboot]] and present the following menu:<br />
<br />
{{bc|<br />
Arch Linux archiso x86_64 UEFI USB<br />
UEFI Shell x86_64 v1<br />
UEFI Shell x86_64 v2<br />
EFI Default Loader}}<br />
<br />
To verify you are booted in UEFI mode, run:<br />
<br />
# efivar -l<br />
<br />
Should ''efivar'' not list the UEFI variables properly, check if all [[UEFI#Requirements_for_UEFI_variable_support|requirements]] are met.<br />
<br />
=== Troubleshooting boot problems ===<br />
<br />
* If you are using an Intel video chipset and the screen goes blank during the boot process, the problem is likely an issue with [[Kernel mode setting]]. A possible workaround may be achieved by rebooting and pressing {{ic|Tab}} over the entry that you are trying to boot (i686 or x86_64). At the end of the string type {{ic|nomodeset}} and press {{ic|Enter}}. Alternatively, try {{ic|1=video=SVIDEO-1:d}} which, if it works, will not disable kernel mode setting. You can also try {{ic|1=i915.modeset=0}}. See the [[Intel]] article for more information.<br />
* If the screen does ''not'' go blank and the boot process gets stuck while trying to load the kernel, press {{ic|Tab}} while hovering over the menu entry, type {{ic|1=acpi=off}} at the end of the string and press {{ic|Enter}}.<br />
<br />
== Keyboard layout ==<br />
<br />
{{Note|Changes here ''only'' affect the installation process.}}<br />
<br />
The default keyboard layout is set to [[Wikipedia:File:KB United States-NoAltGr.svg|US]], the [[locale]] to {{ic|en_US.UTF-8}}. To change the keyboard layout, run:<br />
<br />
# loadkeys ''layout''<br />
<br />
where ''layout'' is a two-letter [[Wikipedia:ISO 3166-1 alpha-2#Officially assigned code elements|country code]]. Use {{ic|localectl list-keymaps}} to list all available keymaps.<br />
<br />
If certain special characters appear as white squares or other symbols, you may wish to change the console font. See [[Fonts#Previewing_and_testing]] for details.<br />
<br />
== Establish an internet connection ==<br />
<br />
{{Warning|As of [http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id&#61;dee4c244254bb49d1ffa8bd7171ae9cce596d2d0 v197], udev no longer assigns network interface names according to the ''wlanX'' and ''ethX'' naming scheme. If you are coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named ''wlan0'', or that your wired interface is named ''eth0''. You can use the command {{ic|ip link}} to discover the names of your interfaces.}}<br />
<br />
The ''dhcpcd'' network daemon starts automatically during boot of the live system and will attempt to start a wired connection. Try to ping a server to see if a connection was established. For example, Google's webservers:<br />
<br />
{{hc|# ping -c 3 www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=2 ttl=50 time=18.2 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=3 ttl=50 time=16.6 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br />
rtt min/avg/max/mdev = 16.660/17.320/18.254/0.678 ms<br />
}}<br />
<br />
If you get a {{ic|ping: unknown host}} error, first check if there is an issue with your cable. If not, you will need to set up the network manually, as explained below. Once a connection is established move on to [[#Prepare the storage devices]].<br />
<br />
{{Tip|<br />
* The ''elinks'' browser is available in the live system: it can be useful for example to authenticate in RADIUS-protected networks. <br />
* The system you are going to install in this guide makes no pre-assumptions regarding network access. For an easy start after the first boot, it may be helpful to stick to the method that got you connected with the live medium and copy relevant configuration to the new system before you [[#Chroot and configure the base system]] later.}}<br />
<br />
=== Static IP ===<br />
<br />
Follow this procedure if you need to set up a wired connection via a static IP address.<br />
<br />
Identify the name of your ethernet interface:<br />
<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000<br />
link/ether 00:11:25:31:69:20 brd ff:ff:ff:ff:ff:ff<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000<br />
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
In this example, the ethernet interface is {{ic|enp2s0f0}}. If you are unsure, your ethernet interface is likely to start with the letter "e", and unlikely to be "lo" or start with the letter "w".<br />
<br />
See [[Network_configuration#Static_IP_address]] for required settings. Configure a static profile for ''dhcpcd'' in {{ic|/etc/dhcpcd.conf}} with your settings, for example: <br />
<br />
interface enp2s0f0<br />
static ip_address=192.168.0.10/24<br />
static routers=192.168.0.1<br />
static domain_name_servers=192.168.0.1 8.8.8.8<br />
<br />
Restart {{ic|dhcpcd.service}}:<br />
<br />
# systemctl restart dhcpcd.service<br />
<br />
You should now have a working network connection. If you do not, see [[Network configuration]] page.<br />
<br />
=== Wireless ===<br />
<br />
{{Warning|Wireless chipset firmware packages (for cards which require them) are pre-installed under {{ic|/usr/lib/firmware}} in the live environment (on CD/USB stick) '''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!''' Package installation is covered later in this guide. Ensure installation of both your wireless module and firmware before rebooting! See [[Wireless network configuration]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset.}}<br />
<br />
Use [[netctl]]'s ''wifi-menu'' to connect to a wireless network:<br />
<br />
# wifi-menu<br />
<br />
This should bring you a menu of wifi networks if your computer has only one Wi-Fi device (mostly the case in laptops).<br />
<br />
If your computer has more than one Wi-Fi device, you need to choose one and pass its interface name to ''wifi-menu''. First, identify the name of the needed interface:<br />
<br />
{{hc|# iw dev|2=<br />
phy#0<br />
Interface wlp3s0<br />
ifindex 3<br />
wdev 0x1<br />
addr 00:11:22:33:44:55<br />
type managed<br />
}}<br />
<br />
This example shows {{ic|wlp3s0}} as the only available wireless interface, for simplicity. If you are unsure, wireless interfaces are likely to start with the letter "w", and unlikely to be "lo" or start with the letter "e".<br />
<br />
Now try ''wifi-menu'' again by passing it the interface name:<br />
<br />
# wifi-menu wlp3s0<br />
<br />
See the sample configuration in [[WPA2 Enterprise#netctl]] for networks that require both a username and password.<br />
<br />
You should now have a working wireless network connection. If you do not or even failed to identify the wireless interface, see [[#Without wifi-menu]] below or the detailed [[Wireless network configuration]] page.<br />
<br />
==== Without wifi-menu ====<br />
<br />
Bring the interface up with:<br />
<br />
# ip link set wlp3s0 up<br />
<br />
To verify that the interface is up, inspect the output of the following command:<br />
<br />
{{hc|# ip link show wlp3s0|<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000<br />
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
The {{ic|UP}} in {{ic|<BROADCAST,MULTICAST,UP,LOWER_UP>}} is what indicates the interface is up, not the later {{ic|state DOWN}}.<br />
<br />
Most wireless chipsets require firmware in addition to a corresponding driver. The kernel tries to identify and load both automatically. If you get output like {{ic|SIOCSIFFLAGS: No such file or directory}}, this means you will need to manually load the firmware. If unsure, invoke ''dmesg'' to query the kernel log for a firmware request from the wireless chipset. For example, if you have an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
<br />
{{hc|<nowiki># dmesg | grep firmware</nowiki>|<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
}}<br />
<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
Next, scan for available networks using {{ic|iw dev wlp3s0 scan <nowiki>|</nowiki> grep SSID}}, then connect to a network with:<br />
<br />
# wpa_supplicant -B -i wlp3s0 -c <(wpa_passphrase "''ssid''" "''psk''")<br />
<br />
You need to replace {{ic|''ssid''}} with the name of your network and {{ic|''psk''}} with your wireless password, '''leaving the quotes around the network name and password'''.<br />
<br />
Finally, you have to give your interface an IP address. This can be set manually or using dhcp:<br />
<br />
# dhcpcd wlp3s0<br />
<br />
If that does not work, issue the following commands:<br />
<br />
# echo 'ctrl_interface=DIR=/run/wpa_supplicant' > /etc/wpa_supplicant.conf<br />
# wpa_passphrase "''ssid''" "''psk''" >> /etc/wpa_supplicant.conf<br />
# ip link set ''interface'' up<br />
# wpa_supplicant -B -D nl80211,wext -c /etc/wpa_supplicant.conf -i ''interface''<br />
# dhcpcd -A ''interface''<br />
<br />
Setting the interface up at step 3 may not be needed, but does no harm in any case.<br />
<br />
=== Analog modem, ISDN, or PPPoE DSL ===<br />
<br />
For xDSL, dial-up, and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Behind a proxy server ===<br />
<br />
If you are behind a proxy server, you will need to export the {{ic|http_proxy}} and {{ic|ftp_proxy}} environment variables. See [[Proxy settings]] for more information.<br />
<br />
== Prepare the storage devices ==<br />
<br />
In this step, the storage devices that will be used by the new system will be prepared. Read [[Partitioning]] for a more general overview.<br />
<br />
{{Warning|Partitioning will destroy existing data. Before proceeding, you '''must''' backup all data that needs to be preserved.}}<br />
<br />
{{Tip|<br />
* Users intending to create stacked block devices for [[LVM]], [[disk encryption]] or [[RAID]], should keep those instructions into consideration when preparing the partitions.<br />
* If intending to install to a USB flash key, see [[Installing Arch Linux on a USB key]].}}<br />
<br />
=== Identify the devices ===<br />
<br />
The first step is to identify the devices where the new system will be installed. The following command will show all the available devices:<br />
<br />
# lsblk<br />
<br />
This will list all devices connected to your system along with their partition schemes, including that used to host and boot live Arch installation media (e.g. a USB drive). Not all devices listed will therefore be viable or appropriate mediums for installation. To filter out inappropriate results, the command can optionally be amended as follows:<br />
<br />
# lsblk | grep -v "rom\|loop\|airoot"<br />
<br />
Devices (e.g. hard disks) will be listed as {{ic|sd''x''}}, where {{ic|''x''}} is a lower-case letter starting from {{ic|a}} for the first device ({{ic|sda}}), {{ic|b}} for the second device ({{ic|sdb}}), and so on. Existing partitions on those devices will be listed as {{ic|sd''xY''}}, where {{ic|''Y''}} is a number starting from {{ic|1}} for the first partition, {{ic|2}} for the second, and so on. In the example below, only one device is available ({{ic|sda}}), and that device uses only one partition ({{ic|sda1}}):<br />
<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 80G 0 disk<br />
└─sda1 8:1 0 80G 0 part<br />
<br />
The {{ic|sd''xY''}} convention will be used in the examples provided below for partition tables, partitions, and file systems. As they are just examples, it is important to ensure that any necessary changes to device names, partition numbers, and/or partition sizes (etc.) are made. Do not just blindly copy and paste the commands.<br />
<br />
If the existing partition scheme needs not be changed, skip to [[#Create filesystems]], otherwise continue reading the following section.<br />
<br />
=== Partition table types ===<br />
<br />
If you are installing alongside an existing installation (i.e. dual-booting), a partition table will already be in use. If the devices are not partitioned, or the current partitions table or scheme needs to be changed, you will first have to determine the partition tables (one for each device) in use or to be used.<br />
<br />
{{Warning|If Arch and Windows are dual-booting from same device, then Arch '''must''' follow the same firmware boot mode and partitioning combination already used, or Windows will fail to boot. See [[Windows and Arch Dual Boot#Important information]] for more details.}}<br />
<br />
There are two types of partition table:<br />
<br />
* [[Master Boot Record| MBR]]: Intended for BIOS systems (also referred to as "msdos")<br />
* [[GUID Partition Table| GPT]]: Intended for UEFI systems<br />
<br />
Any existing partition table can be identified with the following command for each device:<br />
<br />
# parted /dev/sd''x'' print<br />
<br />
=== Partitioning tools ===<br />
<br />
For each device to be partitioned, a proper tool must be chosen according to the partition table to be used. Several partitioning tools are provided by the Arch installation medium, including:<br />
<br />
* [[parted]]: MBR and GPT<br />
* [[Partitioning#Fdisk usage summary|fdisk]], '''cfdisk''', '''sfdisk''': MBR and GPT<br />
* [[Partitioning#Gdisk usage summary|gdisk]], '''cgdisk''', '''sgdisk''': GPT<br />
<br />
{{Warning|Using a partitioning tool that is incompatible with your partition table type will likely result in the destruction of that table, along with any existing partitions/data.}}<br />
<br />
{{Tip|The devices may also be partitioned before booting the Arch installation media, possibly using alternative live systems with other partitioning tools. For example beginners might find it easier to use a graphical partitioning tool such as [[GParted]], which is also provided as a [http://gparted.sourceforge.net/livecd.php live CD] and works with both MBR and GPT partition tables.}}<br />
<br />
==== Using parted in interactive mode ====<br />
<br />
All the examples provided below make use of ''parted'', as it can be used for both BIOS/MBR and UEFI/GPT. It will be launched in ''interactive mode'', which simplifies the partitioning process and reduces unnecessary repetition by automatically applying all partitioning commands to the specified device.<br />
<br />
In order to start operating on a device, execute:<br />
<br />
# parted /dev/sd''x''<br />
<br />
You will notice that the command-line prompt changes from a hash ({{ic|#}}) to {{ic|(parted)}}: this also means that the new prompt is not a command to be manually entered when running the commands in the examples.<br />
<br />
To see a list of the available commands, enter:<br />
<br />
(parted) help<br />
<br />
When finished, or if wishing to implement a partition table or scheme for another device, exit from parted with:<br />
<br />
(parted) quit<br />
<br />
After exiting, the command-line prompt will change back to {{ic|#}}.<br />
<br />
=== Create new partition table ===<br />
<br />
You need to (re)create the partition table of a device when it has never been partitioned before, or when you want to change the type of its partition table. Recreating the partition table of a device is also useful when the partition scheme needs to be restructured from scratch.<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not erase the partition table. Doing so will destroy all existing data on the device, including the UEFI partition with the Windows ''.efi'' file required to boot it.<br />
* MBR is designed specifically for use with BIOS systems, and GPT is designed for UEFI. It is not recommended for less experienced users to break this convention as both have features and/or limitations that may be incompatible with your hardware (e.g. MBR cannot cope with devices larger than 2 TiB). [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/] If for any reason you do not wish to follow this convention, see [http://mjg59.dreamwidth.org/8035.html] and [http://rodsbooks.com/gdisk/bios.html] for more information and possible workarounds.}}<br />
<br />
Open each device whose partition table must be (re)created with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
To then create a new MBR/msdos partition table for BIOS systems, use the following command:<br />
<br />
(parted) mklabel msdos<br />
<br />
To create a new GPT partition table for UEFI systems instead, use:<br />
<br />
(parted) mklabel gpt<br />
<br />
=== Partition schemes ===<br />
<br />
You can decide the number and size of the partitions the devices should be split into, and which directories will be used to mount the partitions in the installed system (also known as ''mount points''). The mapping from partitions to directories is the [[Partitioning#Partition scheme|partition scheme]], which must comply with the following requirements:<br />
<br />
* At least a partition for the {{ic|/}} (''root'') directory '''must''' be created.<br />
* Depending on the motherboard's firmware interface, the chosen [[#Partition table types]], and in some cases also the chosen [[boot loader]], the following additional partitions '''must''' be created:<br />
** '''BIOS/MBR''': no additional partition required.<br />
** '''UEFI/GPT''': one [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]].<br />
<br />
In the examples below it is assumed that a new and contiguous partitioning scheme is applied to a single device. Some optional partitions will also be created for the {{ic|/boot}} and {{ic|/home}} directories: see also [[Arch filesystem hierarchy]] for an explanation of the purpose of the various directories; if separate partitions for directories like {{ic|/boot}} or {{ic|/home}} are not created, these will simply be contained in the {{ic|/}} partition. Also the creation of an optional partiton for [[swap space]] will be illustrated.<br />
<br />
If not already open in a ''parted'' interactive session, open each device to be partitioned with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
The following command will be used to create partitions:<br />
<br />
(parted) mkpart ''part-type'' ''fs-type'' ''start'' ''end''<br />
<br />
* {{ic|''part-type''}} is one of {{ic|primary}}, {{ic|extended}} or {{ic|logical}}, and is meaningful only for MBR partition tables.<br />
* {{ic|''fs-type''}} is an identifier chosen among those listed by entering {{ic|help mkpart}} as the closest match to the file system that you will use in [[#Create filesystems]]. The ''mkpart'' command does not actually create the file system: the {{ic|''fs-type''}} parameter will simply be used by ''parted'' to set a 1-byte code that is used by boot loaders to "preview" what kind of data is found in the partition, and act accordingly if necessary. See also [[Wikipedia:Disk partitioning#PC partition types]].<br />
: {{Tip|Most [[Wikipedia:File_system#Linux|Linux native file systems]] map to the same partition code ([[Wikipedia:Partition type#PID_83h|0x83]]), so it is perfectly safe to e.g. use {{ic|ext2}} for an ''ext4''-formatted partition.}}<br />
* {{ic|''start''}} is the beginning of the partition from the start of the device. It consists of a number followed by a [http://www.gnu.org/software/parted/manual/parted.html#unit unit], for example {{ic|1M}} means start at 1MiB.<br />
* {{ic|''end''}} is the end of the partition from the start of the device (''not'' from the {{ic|''start''}} value). It has the same syntax as {{ic|''start''}}, for example {{ic|100%}} means end at the end of the device (use all the remaining space).<br />
<br />
{{Warning|It is important that the partitions do not overlap each other: if you do not want to leave unused space in the device, make sure that each partition starts where the previous one ends.}}<br />
<br />
{{Note|''parted'' may issue a warning like:<br />
<br />
Warning: The resulting partition is not properly aligned for best performance.<br />
Ignore/Cancel?<br />
<br />
In this case, read [[Partitioning#Partition alignment]] and follow [[GNU Parted#Alignment]] to fix it.}}<br />
<br />
The following command will be used to flag the partition that contains the {{ic|/boot}} directory as bootable:<br />
<br />
(parted) set ''partition'' boot on<br />
<br />
* {{ic|''partition''}} is the number of the partition to be flagged (see the output of the {{ic|print}} command).<br />
<br />
==== UEFI/GPT examples ====<br />
<br />
In every instance, a special bootable [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] is required.<br />
<br />
{{Warning|If dual-booting with an existing installation of Windows on a UEFI/GPT system, the existing UEFI partition must not be deleted. Doing so will destroy the ''.efi'' file required to boot Windows.}}<br />
<br />
If creating a new EFI System Partition, use the following commands (the recommended size is 512MiB):<br />
<br />
(parted) mkpart ESP fat32 1MiB 513MiB<br />
(parted) set 1 boot on<br />
<br />
The remaining partition scheme is entirely up to you. For one other partition using 100% of remaining space:<br />
<br />
(parted) mkpart primary ext3 513MiB 100%<br />
<br />
For separate {{ic|/}} (20GiB) and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary ext3 20.5GiB 100%<br />
<br />
And for separate {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary linux-swap 20.5GiB 24.5GiB<br />
(parted) mkpart primary ext3 24.5GiB 100%<br />
<br />
==== BIOS/MBR examples ====<br />
<br />
For a minimum single primary partition using all available disk space, the following command would be used:<br />
<br />
(parted) mkpart primary ext3 1MiB 100%<br />
(parted) set 1 boot on<br />
<br />
In the following instance, a 20GiB {{ic|/}} partition will be created, followed by a {{ic|/home}} partition using all the remaining space:<br />
<br />
(parted) mkpart primary ext3 1MiB 20GiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 20GiB 100%<br />
<br />
In the final example below, separate {{ic|/boot}} (100MiB), {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions will be created:<br />
<br />
(parted) mkpart primary ext3 1MiB 100MiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 100MiB 20GiB<br />
(parted) mkpart primary linux-swap 20GiB 24GiB<br />
(parted) mkpart primary ext3 24GiB 100%<br />
<br />
=== Create filesystems ===<br />
<br />
Once the partitions have been created, each must be formatted with an appropriate [[file system]], ''except'' for swap partitions. All available partitions on the intended installation device can be listed with the following command:<br />
<br />
# lsblk /dev/sd''x''<br />
<br />
With the exceptions noted below, it is recommended to use the {{ic|ext4}} file system:<br />
<br />
# mkfs.ext4 /dev/sd''xY''<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not re-format the UEFI partition. Doing so will destroy all existing data on that partition, including the Windows ''.efi'' file required to boot it.<br />
* If a new UEFI system partition has been created on a UEFI/GPT system, it must be formatted with a {{ic|fat32}} or {{ic|vfat32}} file system. Failure to do so will result in an unbootable installation:<br />
:{{bc|# mkfs.vfat -F32 /dev/sd''xY''}}}}<br />
<br />
=== Activate swap ===<br />
<br />
If a swap partition has been created, it must be set up and activated with:<br />
<br />
# mkswap /dev/sd''xY''<br />
# swapon /dev/sd''xY''<br />
<br />
=== Mount the partitions ===<br />
<br />
{{Note|Swap partitions must '''not''' be mounted here.}}<br />
<br />
The {{ic|/}} (root) partition must be mounted '''first''': this is because any directories such as {{ic|/boot}} or {{ic|/home}} that have separate partitions will have to be created in the root file system. The {{ic|/mnt}} directory of the live system will be used to mount the root partition, and consequently all the other partitions will stem from there. If the root partition's name is {{ic|sd''xR''}}, do:<br />
<br />
# mount /dev/sd''xR'' /mnt<br />
<br />
Once the {{ic|/}} partition has been mounted, any remaining partitions may be mounted in any order. The general procedure is to first create the mount point, and then mount the partition to it. If using a separate {{ic|/boot}} partition:<br />
<br />
# mkdir -p /mnt/boot<br />
# mount /dev/sd''xB'' /mnt/boot<br />
<br />
{{Note|Using {{ic|/boot}} is recommended also for mounting the EFI System Partition on UEFI/GPT system. See [[EFISTUB]] and related articles for alternatives.}}<br />
<br />
If using a separate {{ic|/home}} partition:<br />
<br />
# mkdir -p /mnt/home<br />
# mount /dev/sd''xH'' /mnt/home<br />
<br />
Once all the remaining partitions, if any, have been mounted, the devices are ready to install Arch.<br />
<br />
== Select a mirror ==<br />
<br />
You may want to edit the {{ic|mirrorlist}} file and place your preferred mirror first. A copy of this file will be installed on your new system by ''pacstrap'' as well, so it is worth getting it right.<br />
<br />
{{hc|# nano /etc/pacman.d/mirrorlist|<br />
##<br />
## Arch Linux repository mirrorlist<br />
## Sorted by mirror score from mirror status page<br />
## Generated on YYYY-MM-DD<br />
##<br />
<br />
<nowiki>Server = http://mirror.example.xyz/archlinux/$repo/os/$arch</nowiki><br />
...}}<br />
<br />
If you want, you can make it the ''only'' mirror available by deleting all other lines, but it is usually a good idea to have a few more, in case the first one goes offline. Should you change your mirror list at a later stage, refresh all package lists with {{ic|pacman -Syyu}}. See [[Mirrors]] for more information.<br />
<br />
== Install the base system ==<br />
<br />
The base system is installed using the ''pacstrap'' script. Without the {{ic|-i}} switch, every package from the {{Grp|base}} [[Pacman#Installing_package_groups|group]] is installed without prompting. To build packages from the [[AUR]] or with [[ABS]], you will also need the {{Grp|base-devel}} group.<br />
<br />
# pacstrap -i /mnt base base-devel<br />
<br />
Other packages can be installed later using [[pacman]].<br />
<br />
See [[Pacman#Troubleshooting]] and [[Pacman-key#Troubleshooting]] in case of errors.<br />
<br />
== Generate an fstab ==<br />
<br />
[[Wikipedia:Universally_unique_identifier|UUID]]s are used because they have certain advantages (see [[fstab#Identifying filesystems]]). If you prefer labels instead, replace the {{ic|-U}} option with {{ic|-L}}:<br />
<br />
# genfstab -U -p /mnt >> /mnt/etc/fstab<br />
# nano /mnt/etc/fstab<br />
<br />
{{Warning|The {{ic|fstab}} file should always be checked after generating it. If you encounter errors running ''genfstab'' or later in the install process, do '''not''' run ''genfstab'' again; just edit the {{ic|fstab}} file. See [[fstab#Field definitions]] for syntax information.}}<br />
<br />
== Chroot and configure the base system ==<br />
<br />
Next, [[Change root|chroot]] into your newly installed system:<br />
<br />
# arch-chroot /mnt /bin/bash<br />
<br />
At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system. These can either be created if they do not exist, or edited if you wish to change the defaults.<br />
<br />
Closely following and understanding these steps is of key importance to ensure a properly configured system.<br />
<br />
{{Warning|Do not assume that the tools you used from the ISO are automatically installed. For example, if you used ''wifi-menu'' to gain network access during the installation and want to continue so after the first boot, you will have to install ''dialog'' to use it. The following section specifies such cases, do follow it closely to avoid a hiccup in your fresh install.}}<br />
<br />
=== Locale ===<br />
<br />
Locales define which language the system uses and other regional considerations, such as currency denomination, numerology and character sets. Possible values are listed in {{ic|/etc/locale.gen}}, with the active locale defined in {{ic|locale.conf}} files.<br />
<br />
All entries in {{ic|locale.gen}} are commented out (preceded by {{ic|#}}) by default. Uncomment {{ic|en_US.UTF-8 UTF-8}}, as well as other needed localisations. {{ic|UTF-8}} is highly recommended over other options.<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
...<br />
#en_SG ISO-8859-1<br />
en_US.UTF-8 UTF-8<br />
#en_US ISO-8859-1<br />
...<br />
}}<br />
<br />
Before locales can be enabled, they must be ''generated'':<br />
<br />
# locale-gen<br />
<br />
Create {{ic|/etc/locale.conf}}, where {{ic|LANG}} refers to the first column of an uncommented entry in {{ic|/etc/locale.gen}}.<br />
<br />
# echo LANG=''en_US.UTF-8'' > /etc/locale.conf<br />
<br />
Export the chosen locale:<br />
<br />
# export LANG=''en_US.UTF-8''<br />
<br />
{{Note|<br />
* Choosing {{ic|en_US.UTF-8}} as the system locale allows to keep system logs in English for easier troubleshooting. Users may override this setting for their session as described in [[Locale#Setting the locale]].<br />
* {{ic|LANG}} acts as the default value for the locale-related {{ic|LC_*}} variables. To use other locales for these variables, run ''locale'' to see the available options and add them to {{ic|locale.conf}}. It is not recommended to set the {{ic|LC_ALL}} variable. See [[Locale]] for details.}}<br />
<br />
=== Console font and keymap ===<br />
<br />
If you changed the default console keymap and font in [[#Keyboard layout]], create {{ic|/etc/vconsole.conf}} to make those changes persist in the installed system. It is important {{ic|KEYMAP}} matches the value initially set with {{ic|loadkeys}}, to ensure correct entry of [[#Set the root password|the root password]] on reboot.<br />
<br />
{{hc|# nano /etc/vconsole.conf|2=<br />
KEYMAP=''de-latin1''<br />
FONT=''lat9w-16''<br />
}}<br />
<br />
These settings only apply to virtual consoles, not [[Xorg]]. See [[Fonts#Console fonts]] for more information.<br />
<br />
=== Time zone ===<br />
<br />
Available time zones and subzones can be found in the {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} directories, and listed with the ''ls'' command. Create a symbolic link {{ic|/etc/localtime}} to your subzone file {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}}:<br />
<br />
# ln -s /usr/share/zoneinfo/''Zone''/''SubZone'' /etc/localtime<br />
<br />
You may use [http://tldp.org/LDP/abs/html/tabexpansion.html tab completion] to show available zones and subzones. Example:<br />
<br />
# ln -s /usr/share/zoneinfo/Europe/Minsk /etc/localtime<br />
<br />
If you get {{ic|ln: failed to create symbolic link '/etc/localtime': File exists}}, check the existing file with {{ic|ls -l /etc/localtime}} and add the {{ic|-f}} option to the ''ln'' command to overwrite it.<br />
<br />
=== Hardware clock ===<br />
<br />
If you have multiple operating systems installed in the same machine, they will all derive the current time from the same hardware clock, which must be set to either UTC or ''localtime''. For this reason you must make sure that all the operating systems see the hardware clock as providing time in the same chosen [[Time#Time standard|standard]], otherwise some of them will perform the time zone adjustement for the system clock, while others will not.<br />
<br />
In particular, it is strongly recommended to set the hardware clock to UTC, in order to avoid conflicts between the installed operating systems. For example, if the hardware clock was set to ''localtime'', more than one operating system may adjust it after a [[Wikipedia:Daylight_saving_time|DST]] change, thus resulting in an overcorrection; more problems may arise when travelling between different time zones and using one of the operating systems to reset the system/hardware clock.<br />
<br />
To set the hardware clock to UTC in Linux, run:<br />
<br />
# hwclock --systohc --utc<br />
<br />
The ''hwclock'' command also generates the {{ic|/etc/adjtime}} file.<br />
<br />
{{Note|Using UTC for the hardware clock does not mean that software will display time in UTC. However, the system setup/BIOS interface will instead: this should be neither surprising nor treated as a bug.}}<br />
<br />
{{Warning|Windows systems use ''localtime'' by default. Using ''localtime'' on Arch systems may lead to several known and unfixable bugs, but there are no plans to drop support for ''localtime''. It is, though, recommended to set Windows to use UTC instead, and prevent it from synchronising time. See [[Time#UTC in Windows]].}}<br />
<br />
=== Kernel modules ===<br />
<br />
Needed kernel modules are automatically loaded by [[udev]], so you will rarely need to load modules manually. See [[Kernel modules]] for details.<br />
<br />
=== Hostname ===<br />
<br />
Set the [[Network_configuration#Set_the_hostname|hostname]] to your liking:<br />
<br />
# echo ''myhostname'' > /etc/hostname<br />
<br />
Add the same hostname to {{ic|/etc/hosts}}:<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost ''myhostname''<br />
::1 localhost.localdomain localhost ''myhostname''<br />
<br />
=== Configure the network ===<br />
<br />
You need to configure the network again, but this time for your newly installed environment. The procedure and prerequisites are similar to the one described [[#Establish an internet connection|above]], except we are going to make it persistent and automatically run at boot.<br />
<br />
As a first step, identify the network interface name you want to configure the connection for with {{ic|ip link}}.<br />
<br />
{{Note|<br />
* For more in-depth information on network configuration, visit [[Network configuration]] and [[Wireless network configuration]].<br />
* If you would like to use the old interface naming scheme (i.e. {{ic|eth''X''}} and {{ic|wlan''X''}}) you can accomplish this by creating an empty file at {{ic|/etc/udev/rules.d/80-net-setup-link.rules}} which will mask the file of the same name located under {{ic|/usr/lib/udev/rules.d}}.<br />
}}<br />
<br />
Now select a daemon to handle the configuration and operation. Several are listed below; only select '''one''' of them for the new system.<br />
<br />
==== Wired ====<br />
<br />
; Using dhcpcd<br />
A simple option for adapter configuration is to use the DHCP Client Daemon, the method used by default with the install medium. See [[Dhcpcd#Running]].<br />
<br />
Users requiring only '''single wired network connection''' can simply enable the ''dhcpcd'' service for the interface:<br />
<br />
# systemctl enable dhcpcd@''interface_name''.service<br />
<br />
If static IP settings are required, adjust the profile configuration as described in [[#Static IP]]. <br />
<br />
; Using systemd-networkd<br />
<br />
The Arch default init system, [[systemd]] includes built-in support for managing adapters using both DHCP and static IP setups. Configuration is simple. See [[Systemd-networkd#Required_services_and_setup]].<br />
<br />
; Using netctl<br />
<br />
Another option is [[netctl]] which is a CLI-based tool used to configure and manage network connections via user-created profiles. Create a profile as shown in [[netctl#Example profiles]], then enable it as described in [[netctl#Basic method]].<br />
<br />
==== Wireless ====<br />
<br />
All of the tools listed in [[#Wired]] above can activate wireless connections. For wireless, however, ''dhcpcd'' and ''systemd-networkd'' require a separate configuration of the connection in the wireless backend, [[wpa_supplicant]], first. If you anticipate to connect the machine to different wireless networks over time, a tool which provides its own connection management may be easier to handle. Aside from [[netctl]] introduced below, [[Wireless network configuration#Automatic setup]] lists other choices. <br />
<br />
{{Note|If your wireless adapter requires a firmware (as described in the above [[#Wireless|Establish an internet connection]] section and also in the article [[Wireless network configuration#Device driver]]), install the package containing your firmware. Most of the time, the {{Pkg|linux-firmware}} package will contain the needed firmware. Though for some devices, the required firmware might be in its own package. For example:<br />
{{bc|# pacman -S zd1211-firmware}}<br />
See [[Wireless network configuration#Installing driver/firmware]] for more info.}}<br />
<br />
Install {{Pkg|iw}} and {{Pkg|wpa_supplicant}} which you will need to connect to a network:<br />
<br />
# pacman -S iw wpa_supplicant<br />
<br />
===== Adding wireless networks =====<br />
<br />
; Using wifi-menu<br />
<br />
Install {{Pkg|dialog}}, which is required for ''wifi-menu'':<br />
<br />
# pacman -S dialog<br />
<br />
After finishing the rest of this installation and rebooting, you can connect to the network with:<br />
<br />
# wifi-menu ''interface_name''<br />
<br />
Where {{ic|''interface_name''}} is the interface of your wireless chipset.<br />
<br />
{{Warning|Do not use ''wifi-menu'' now, instead wait until you have finished this guide and have rebooted. It will not work now because a process spawned by this command will conflict with the one you have running outside of the chroot. Alternatively, you could just configure a network profile manually using the following templates so that you do not have to worry about using ''wifi-menu'' at all.}}<br />
<br />
; Using manual netctl profiles<br />
<br />
Copy a network profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/wireless-wpa my-network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|ESSID}} and {{ic|Key}}):<br />
<br />
# nano my-network<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my-network<br />
<br />
===== Connect automatically to known networks =====<br />
<br />
{{Warning|This method cannot be used with explicitely enabled [[Netctl#Configuration|profiles]], i.e. through {{ic|netctl enable ''profile''}}.}}<br />
<br />
Install {{Pkg|wpa_actiond}}, which is required for {{ic|netctl-auto}}:<br />
<br />
# pacman -S wpa_actiond<br />
<br />
Enable the {{ic|netctl-auto}} service, which will connect to known networks and gracefully handle roaming and disconnects:<br />
<br />
# systemctl enable netctl-auto@''interface_name''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-ifplugd}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-auto}}.}}<br />
<br />
==== Analog modem, ISDN or PPPoE DSL ====<br />
<br />
For xDSL, dial-up and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Create an initial ramdisk environment ===<br />
<br />
As [[mkinitcpio]] was run on installation of {{Pkg|linux}} with ''pacstrap'', most users can use the defaults provided in {{ic|mkinitcpio.conf}}. For special configurations, set the correct [[Mkinitcpio#HOOKS|hooks]] in {{ic|/etc/mkinitcpio.conf}} and [[Mkinitcpio#Image_creation_and_activation|re-generate the initramfs image]].<br />
<br />
=== Set the root password ===<br />
<br />
Set the root password with:<br />
<br />
# passwd<br />
<br />
=== Install and configure a bootloader ===<br />
<br />
See [[Boot loaders]] for available choices and configurations. [[Microcode]] updates for Intel CPUs must also be configured after installing the boot loader.<br />
<br />
==== For BIOS motherboards ====<br />
<br />
Here, installation with '''GRUB''' and '''MBR''' is demonstrated. <br />
<br />
Install the {{Pkg|grub}} package; to have GRUB search for other installed operating systems, install {{Pkg|os-prober}} in addition:<br />
<br />
# pacman -S grub os-prober<br />
<br />
Install the bootloader to the drive Arch was installed to (do '''not''' append a partition number, or {{ic|/dev/sda''X''}}):<br />
<br />
# grub-install --target=i386-pc --recheck ''/dev/sda''<br />
<br />
Automatically generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|A sample {{ic|/boot/grub/grub.cfg}} is included with the {{Pkg|grub}} package, and subsequent {{ic|grub-*}} commands may not over-write it. Ensure your intended changes are in {{ic|grub.cfg}}, rather than in {{ic|grub.cfg.new}} or similar file.}}<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
==== For UEFI motherboards ====<br />
<br />
Here, installation with ''gummiboot'' is demonstrated. First install {{Pkg|dosfstools}} to manipulate the EFI System Partition post-installation, and {{Pkg|efibootmgr}} to create a UEFI boot entry (used by bootmanager installation scripts):<br />
<br />
# pacman -S dosfstools efibootmgr<br />
<br />
{{Note|<br />
* For UEFI boot, the drive needs to be GPT-partitioned and an [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] (512 MiB or larger, gdisk type {{ic|EF00}}, formatted with FAT32) must be present. In the following examples, this partition is assumed to be mounted at {{ic|/boot}}. If you have followed this guide from the beginning, you have already done all of these.<br />
* It is strongly recommended to have the EFI System Partition mounted at {{ic|/boot}} as this is required to automatically update Gummiboot.<br />
}}<br />
<br />
Install the {{Pkg|gummiboot}} package and run the automated installation script, replacing {{ic|'''$esp'''}} with the location of your EFI System Partiton, usually {{ic|/boot}}:<br />
<br />
# pacman -S gummiboot<br />
# gummiboot --path='''$esp''' install<br />
<br />
Gummiboot will automatically be detected by firmware that requires that the bootable {{ic|bootx64.efi}} stub be placed in {{ic|'''$esp'''/EFI/boot}}, and will in turn automatically detect the presence of any other installed operating systems using ''.efi'' stubs. However, it will still be necessary to manually create a configuration file for Gummiboot.<br />
<br />
First, create {{ic|'''$esp'''/loader/entries/arch.conf}} and add the following, replacing {{ic|/dev/sdaX}} with your '''root''' partition (most likely {{ic|/dev/sda2}} if {{ic|/dev/sda1}} is the ESP):<br />
<br />
{{hc|# nano '''$esp'''/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
<br />
Second, create {{ic|'''$esp'''/loader/loader.conf}} and add the following, replacing the timeout value (in seconds) with your own choice:<br />
{{hc|# nano '''$esp'''/loader/loader.conf|2=<br />
default arch<br />
timeout 5<br />
}}<br />
<br />
See [[gummiboot]] for more information.<br />
<br />
== Unmount the partitions and reboot ==<br />
<br />
Exit from the chroot environment:<br />
<br />
# exit<br />
<br />
{{Note|While partitions are unmounted automatically by ''systemd'' on shutdown, you may do so manually with {{ic|umount -R /mnt}} as a safety measure. If the partition is "busy", you can find the cause with [[fuser]].}}<br />
<br />
Reboot the computer:<br />
<br />
# reboot<br />
<br />
Remove the installation media, or you may boot back into it. You can log into your new installation as ''root'', using the password you specified with ''passwd''.<br />
<br />
== Post-installation ==<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready to be built into whatever you wish or require for your purposes. You are now ''strongly'' advised to read the [[General recommendations]] article, especially the first two sections. Its other sections provide links to post-installation tutorials like setting up a graphical user interface, sound or a touchpad.<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].<br />
<br />
If you need a working [[desktop environment]] in quick, you can install [[GNOME]], [[Xorg]], [[GDM]]:<br />
<br />
# pacman -S gnome gnome-extra xorg gdm<br />
<br />
Then you start [[GDM]] by:<br />
<br />
# systemctl start gdm<br />
<br />
This might install extra unwanted packages. You should always install packages that fit your own needs.</div>Sarenhttps://wiki.archlinux.org/index.php?title=Beginners%27_guide&diff=373360Beginners' guide2015-05-11T14:30:06Z<p>Saren: My friend said he could not find a way to install GUI in his Arch by reading beginners' guide. I am here to make things clearer.</p>
<hr />
<div>[[Category:Getting and installing Arch]]<br />
[[ar:Beginners' Guide]]<br />
[[bg:Beginners' Guide]]<br />
[[cs:Beginners' Guide]]<br />
[[da:Beginners' Guide]]<br />
[[de:Anleitung für Einsteiger]]<br />
[[el:Beginners' Guide]]<br />
[[es:Beginners' Guide]]<br />
[[fa:راهنمای تازهکارها]]<br />
[[fr:Installation]]<br />
[[he:Beginners' Guide]]<br />
[[hr:Beginners' Guide]]<br />
[[hu:Beginners' Guide]]<br />
[[id:Beginners' Guide]]<br />
[[it:Beginners' Guide]]<br />
[[ja:ビギナーズガイド]]<br />
[[ko:Beginners' Guide]]<br />
[[lt:Beginners' Guide]]<br />
[[nl:Beginners' Guide]]<br />
[[pl:Beginners' Guide]]<br />
[[pt:Beginners' Guide]]<br />
[[ro:Ghidul începătorilor]]<br />
[[ru:Beginners' guide]]<br />
[[sk:Beginners' Guide]]<br />
[[sr:Beginners' Guide]]<br />
[[sv:Nybörjarguiden]]<br />
[[tr:Yeni başlayanlar rehberi]]<br />
[[uk:Beginners' Guide]]<br />
[[zh-CN:Beginners' guide]]<br />
[[zh-TW:Beginners' Guide]]<br />
{{Related articles start}}<br />
{{Related|:Category:Accessibility}}<br />
{{Related|Installation guide}}<br />
{{Related|Diskless system}}<br />
{{Related|Install from SSH}}<br />
{{Related|General recommendations}}<br />
{{Related|General troubleshooting}}<br />
{{Related articles end}}<br />
This document will guide you through the process of installing [[Arch Linux]] using the [https://projects.archlinux.org/arch-install-scripts.git/ Arch Install Scripts]. Before installing, you are advised to skim over the [[FAQ]].<br />
<br />
The community-maintained [[Main page|ArchWiki]] is the primary resource that should be consulted if issues arise. The [[IRC channel]] (irc://irc.freenode.net/#archlinux) and the [https://bbs.archlinux.org/ forums] are also excellent resources if an answer cannot be found elsewhere. In accordance with [[the Arch Way]], you are encouraged to type {{ic|man ''command''}} to read the [[man page]] of any command you are unfamiliar with.<br />
<br />
== Minimum system requirements ==<br />
<br />
Arch Linux should run on any [[Wikipedia:P6 (microarchitecture)|i686]] compatible machine with a minimum of 256 MB RAM. A basic installation with all packages from the {{Grp|base}} group should take less than 800 MB of disk space. If you are working with limited space, this can be trimmed down considerably, but you will have to know what you are doing.<br />
<br />
== Prepare the latest installation medium ==<br />
<br />
{{Tip|Compared to the regular ISO images, the [https://downloads.archlinux.de/iso/archboot/latest archboot] images can take several steps explained in this guide [[Archboot#Interactive_setup_features|interactively]]. See [[Archboot]] for details.}}<br />
<br />
The installation media and their [[GnuPG]] signatures can be acquired from the [https://archlinux.org/download/ Download] page. The single ISO image supports both 32bit and 64bit systems; this guide assumes you use the latest available version.<br />
<br />
It is highly recommended to verify the image signature before use, ''especially when downloading from an HTTP mirror'', as these are run by volunteers who could [http://www.cs.arizona.edu/stork/packagemanagersecurity/attacks-on-package-managers.html#explanation theoretically serve malicious images]. On a system with GnuPG installed, do this by downloading the ''PGP signature'' (under ''Checksums'') to the ISO directory, and run:<br />
<br />
$ gpg --verify archlinux-''version''-dual.iso.sig<br />
<br />
If the public key is not found, [[GnuPG#Import key|import]] it with {{ic|gpg --recv-keys ''key-id''}}. <br />
<br />
Alternatively, run from an existing Arch Linux installation:<br />
<br />
$ pacman-key -v archlinux-''version''-dual.iso.sig<br />
<br />
Now choose one of the methods from the table below to [[#Boot the installation medium]] on the target machine(s). As the installation process retrieves packages from a remote repository, these methods require an internet connection; see [[Offline installation of packages]] when none is available.<br />
<br />
{| class="wikitable"<br />
! Method<br />
! Articles<br />
! Conditions<br />
|-<br />
| Write the image on flash media or optical disc, then boot from it.<br />
|<br />
* [[USB flash installation media]]<br />
* [[Optical disc drive#Burning]]<br />
|<br />
* Installation on one, or a few machines at most<br />
* Obtain a directly bootable system<br />
|-<br />
| Mount the image on a server machine and have clients boot it over the network.<br />
|<br />
* [[PXE]]<br />
* [[Diskless system]]<br />
|<br />
* Client-server model<br />
* Wired (1Gbit+) network connection<br />
|-<br />
| Mount the image in a running Linux system and install Arch from a chroot environment.<br />
|<br />
* [[Install from existing Linux]]<br />
* [[Install from SSH]]<br />
|<br />
* Replace an existing system with reduced downtime<br />
* Install on the local machine, or a remote one via [[VNC]] or [[SSH]]<br />
|-<br />
| Set up a virtual machine and install Arch as a guest system.<br />
|<br />
* [[:Category:Hypervisors]]<br />
* [[Moving an existing install into (or out of) a virtual machine]]<br />
|<br />
* Operating system compatible with virtualization software<br />
* Obtain an isolated system for learning, testing or debugging<br />
|}<br />
<br />
== Boot the installation medium ==<br />
<br />
Point the current boot device to the media containing the Arch installation media. This is typically achieved by pressing a key during the [[Wikipedia:Power-on self test|POST]] phase, as indicated on the splash screen. Refer to your motherboard's manual for details.<br />
<br />
When the Arch menu appears, select "Boot Arch Linux" and press {{ic|Enter}} to enter the live environment where you will perform the actual installation. Various boot parameters (for example, {{ic|copytoram}}) can be used by editing the boot entry ({{ic|tab}} for syslinux and {{ic|e}} for gummiboot), see [https://projects.archlinux.org/archiso.git/tree/docs/README.bootparams README.bootparams] for reference.<br />
<br />
You will be presented with a [[Zsh]] shell prompt, logged in as the root user. ''Zsh'' provides advanced tab completion and other features as part of the [http://grml.org/zsh/ grml config]. For editing text files, the console editor [[nano#Usage|nano]] is suggested.<br />
<br />
=== Booting into UEFI mode ===<br />
<br />
{{Warning|While the choice to install in EFI mode is forward looking, early vendor UEFI implementations carried more bugs than their BIOS counterparts. It is advised to do a search relating your particular mainboard model before proceeding.}}<br />
<br />
In case you have a [[Unified Extensible Firmware Interface|UEFI]] motherboard with UEFI mode enabled, the CD/USB will automatically launch Arch Linux via [[Gummiboot]] and present the following menu:<br />
<br />
{{bc|<br />
Arch Linux archiso x86_64 UEFI USB<br />
UEFI Shell x86_64 v1<br />
UEFI Shell x86_64 v2<br />
EFI Default Loader}}<br />
<br />
To verify you are booted in UEFI mode, run:<br />
<br />
# efivar -l<br />
<br />
Should ''efivar'' not list the UEFI variables properly, check if all [[UEFI#Requirements_for_UEFI_variable_support|requirements]] are met.<br />
<br />
=== Troubleshooting boot problems ===<br />
<br />
* If you are using an Intel video chipset and the screen goes blank during the boot process, the problem is likely an issue with [[Kernel mode setting]]. A possible workaround may be achieved by rebooting and pressing {{ic|Tab}} over the entry that you are trying to boot (i686 or x86_64). At the end of the string type {{ic|nomodeset}} and press {{ic|Enter}}. Alternatively, try {{ic|1=video=SVIDEO-1:d}} which, if it works, will not disable kernel mode setting. You can also try {{ic|1=i915.modeset=0}}. See the [[Intel]] article for more information.<br />
* If the screen does ''not'' go blank and the boot process gets stuck while trying to load the kernel, press {{ic|Tab}} while hovering over the menu entry, type {{ic|1=acpi=off}} at the end of the string and press {{ic|Enter}}.<br />
<br />
== Keyboard layout ==<br />
<br />
{{Note|Changes here ''only'' affect the installation process.}}<br />
<br />
The default keyboard layout is set to [[Wikipedia:File:KB United States-NoAltGr.svg|US]], the [[locale]] to {{ic|en_US.UTF-8}}. To change the keyboard layout, run:<br />
<br />
# loadkeys ''layout''<br />
<br />
where ''layout'' is a two-letter [[Wikipedia:ISO 3166-1 alpha-2#Officially assigned code elements|country code]]. Use {{ic|localectl list-keymaps}} to list all available keymaps.<br />
<br />
If certain special characters appear as white squares or other symbols, you may wish to change the console font. See [[Fonts#Previewing_and_testing]] for details.<br />
<br />
== Establish an internet connection ==<br />
<br />
{{Warning|As of [http://cgit.freedesktop.org/systemd/systemd/tree/NEWS?id&#61;dee4c244254bb49d1ffa8bd7171ae9cce596d2d0 v197], udev no longer assigns network interface names according to the ''wlanX'' and ''ethX'' naming scheme. If you are coming from a different distribution or are reinstalling Arch and not aware of the new interface naming style, please do not assume that your wireless interface is named ''wlan0'', or that your wired interface is named ''eth0''. You can use the command {{ic|ip link}} to discover the names of your interfaces.}}<br />
<br />
The ''dhcpcd'' network daemon starts automatically during boot of the live system and will attempt to start a wired connection. Try to ping a server to see if a connection was established. For example, Google's webservers:<br />
<br />
{{hc|# ping -c 3 www.google.com|2=<br />
PING www.l.google.com (74.125.132.105) 56(84) bytes of data.<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=1 ttl=50 time=17.0 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=2 ttl=50 time=18.2 ms<br />
64 bytes from wb-in-f105.1e100.net (74.125.132.105): icmp_req=3 ttl=50 time=16.6 ms<br />
<br />
--- www.l.google.com ping statistics ---<br />
3 packets transmitted, 3 received, 0% packet loss, time 2003ms<br />
rtt min/avg/max/mdev = 16.660/17.320/18.254/0.678 ms<br />
}}<br />
<br />
If you get a {{ic|ping: unknown host}} error, first check if there is an issue with your cable. If not, you will need to set up the network manually, as explained below. Once a connection is established move on to [[#Prepare the storage devices]].<br />
<br />
{{Tip|<br />
* The ''elinks'' browser is available in the live system: it can be useful for example to authenticate in RADIUS-protected networks. <br />
* The system you are going to install in this guide makes no pre-assumptions regarding network access. For an easy start after the first boot, it may be helpful to stick to the method that got you connected with the live medium and copy relevant configuration to the new system before you [[#Chroot and configure the base system]] later.}}<br />
<br />
=== Static IP ===<br />
<br />
Follow this procedure if you need to set up a wired connection via a static IP address.<br />
<br />
Identify the name of your ethernet interface:<br />
<br />
{{hc|# ip link|<br />
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT<br />
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00<br />
2: enp2s0f0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN mode DEFAULT qlen 1000<br />
link/ether 00:11:25:31:69:20 brd ff:ff:ff:ff:ff:ff<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT qlen 1000<br />
link/ether 01:02:03:04:05:06 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
In this example, the ethernet interface is {{ic|enp2s0f0}}. If you are unsure, your ethernet interface is likely to start with the letter "e", and unlikely to be "lo" or start with the letter "w".<br />
<br />
See [[Network_configuration#Static_IP_address]] for required settings. Configure a static profile for ''dhcpcd'' in {{ic|/etc/dhcpcd.conf}} with your settings, for example: <br />
<br />
interface enp2s0f0<br />
static ip_address=192.168.0.10/24<br />
static routers=192.168.0.1<br />
static domain_name_servers=192.168.0.1 8.8.8.8<br />
<br />
Restart {{ic|dhcpcd.service}}:<br />
<br />
# systemctl restart dhcpcd.service<br />
<br />
You should now have a working network connection. If you do not, see [[Network configuration]] page.<br />
<br />
=== Wireless ===<br />
<br />
{{Warning|Wireless chipset firmware packages (for cards which require them) are pre-installed under {{ic|/usr/lib/firmware}} in the live environment (on CD/USB stick) '''but must be explicitly installed to your actual system to provide wireless functionality after you reboot into it!''' Package installation is covered later in this guide. Ensure installation of both your wireless module and firmware before rebooting! See [[Wireless network configuration]] if you are unsure about the requirement of corresponding firmware installation for your particular chipset.}}<br />
<br />
Use [[netctl]]'s ''wifi-menu'' to connect to a wireless network:<br />
<br />
# wifi-menu<br />
<br />
This should bring you a menu of wifi networks if your computer has only one Wi-Fi device (mostly the case in laptops).<br />
<br />
If your computer has more than one Wi-Fi device, you need to choose one and pass its interface name to ''wifi-menu''. First, identify the name of the needed interface:<br />
<br />
{{hc|# iw dev|2=<br />
phy#0<br />
Interface wlp3s0<br />
ifindex 3<br />
wdev 0x1<br />
addr 00:11:22:33:44:55<br />
type managed<br />
}}<br />
<br />
This example shows {{ic|wlp3s0}} as the only available wireless interface, for simplicity. If you are unsure, wireless interfaces are likely to start with the letter "w", and unlikely to be "lo" or start with the letter "e".<br />
<br />
Now try ''wifi-menu'' again by passing it the interface name:<br />
<br />
# wifi-menu wlp3s0<br />
<br />
See the sample configuration in [[WPA2 Enterprise#netctl]] for networks that require both a username and password.<br />
<br />
You should now have a working wireless network connection. If you do not or even failed to identify the wireless interface, see [[#Without wifi-menu]] below or the detailed [[Wireless network configuration]] page.<br />
<br />
==== Without wifi-menu ====<br />
<br />
Bring the interface up with:<br />
<br />
# ip link set wlp3s0 up<br />
<br />
To verify that the interface is up, inspect the output of the following command:<br />
<br />
{{hc|# ip link show wlp3s0|<br />
3: wlp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state DOWN mode DORMANT group default qlen 1000<br />
link/ether 00:11:22:33:44:55 brd ff:ff:ff:ff:ff:ff<br />
}}<br />
<br />
The {{ic|UP}} in {{ic|<BROADCAST,MULTICAST,UP,LOWER_UP>}} is what indicates the interface is up, not the later {{ic|state DOWN}}.<br />
<br />
Most wireless chipsets require firmware in addition to a corresponding driver. The kernel tries to identify and load both automatically. If you get output like {{ic|SIOCSIFFLAGS: No such file or directory}}, this means you will need to manually load the firmware. If unsure, invoke ''dmesg'' to query the kernel log for a firmware request from the wireless chipset. For example, if you have an Intel chipset which requires and has requested firmware from the kernel at boot:<br />
<br />
{{hc|<nowiki># dmesg | grep firmware</nowiki>|<br />
firmware: requesting iwlwifi-5000-1.ucode<br />
}}<br />
<br />
If there is no output, it may be concluded that the system's wireless chipset does not require firmware.<br />
<br />
Next, scan for available networks using {{ic|iw dev wlp3s0 scan <nowiki>|</nowiki> grep SSID}}, then connect to a network with:<br />
<br />
# wpa_supplicant -B -i wlp3s0 -c <(wpa_passphrase "''ssid''" "''psk''")<br />
<br />
You need to replace {{ic|''ssid''}} with the name of your network and {{ic|''psk''}} with your wireless password, '''leaving the quotes around the network name and password'''.<br />
<br />
Finally, you have to give your interface an IP address. This can be set manually or using dhcp:<br />
<br />
# dhcpcd wlp3s0<br />
<br />
If that does not work, issue the following commands:<br />
<br />
# echo 'ctrl_interface=DIR=/run/wpa_supplicant' > /etc/wpa_supplicant.conf<br />
# wpa_passphrase "''ssid''" "''psk''" >> /etc/wpa_supplicant.conf<br />
# ip link set ''interface'' up<br />
# wpa_supplicant -B -D nl80211,wext -c /etc/wpa_supplicant.conf -i ''interface''<br />
# dhcpcd -A ''interface''<br />
<br />
Setting the interface up at step 3 may not be needed, but does no harm in any case.<br />
<br />
=== Analog modem, ISDN, or PPPoE DSL ===<br />
<br />
For xDSL, dial-up, and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Behind a proxy server ===<br />
<br />
If you are behind a proxy server, you will need to export the {{ic|http_proxy}} and {{ic|ftp_proxy}} environment variables. See [[Proxy settings]] for more information.<br />
<br />
== Prepare the storage devices ==<br />
<br />
In this step, the storage devices that will be used by the new system will be prepared. Read [[Partitioning]] for a more general overview.<br />
<br />
{{Warning|Partitioning will destroy existing data. Before proceeding, you '''must''' backup all data that needs to be preserved.}}<br />
<br />
{{Tip|<br />
* Users intending to create stacked block devices for [[LVM]], [[disk encryption]] or [[RAID]], should keep those instructions into consideration when preparing the partitions.<br />
* If intending to install to a USB flash key, see [[Installing Arch Linux on a USB key]].}}<br />
<br />
=== Identify the devices ===<br />
<br />
The first step is to identify the devices where the new system will be installed. The following command will show all the available devices:<br />
<br />
# lsblk<br />
<br />
This will list all devices connected to your system along with their partition schemes, including that used to host and boot live Arch installation media (e.g. a USB drive). Not all devices listed will therefore be viable or appropriate mediums for installation. To filter out inappropriate results, the command can optionally be amended as follows:<br />
<br />
# lsblk | grep -v "rom\|loop\|airoot"<br />
<br />
Devices (e.g. hard disks) will be listed as {{ic|sd''x''}}, where {{ic|''x''}} is a lower-case letter starting from {{ic|a}} for the first device ({{ic|sda}}), {{ic|b}} for the second device ({{ic|sdb}}), and so on. Existing partitions on those devices will be listed as {{ic|sd''xY''}}, where {{ic|''Y''}} is a number starting from {{ic|1}} for the first partition, {{ic|2}} for the second, and so on. In the example below, only one device is available ({{ic|sda}}), and that device uses only one partition ({{ic|sda1}}):<br />
<br />
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT<br />
sda 8:0 0 80G 0 disk<br />
└─sda1 8:1 0 80G 0 part<br />
<br />
The {{ic|sd''xY''}} convention will be used in the examples provided below for partition tables, partitions, and file systems. As they are just examples, it is important to ensure that any necessary changes to device names, partition numbers, and/or partition sizes (etc.) are made. Do not just blindly copy and paste the commands.<br />
<br />
If the existing partition scheme needs not be changed, skip to [[#Create filesystems]], otherwise continue reading the following section.<br />
<br />
=== Partition table types ===<br />
<br />
If you are installing alongside an existing installation (i.e. dual-booting), a partition table will already be in use. If the devices are not partitioned, or the current partitions table or scheme needs to be changed, you will first have to determine the partition tables (one for each device) in use or to be used.<br />
<br />
{{Warning|If Arch and Windows are dual-booting from same device, then Arch '''must''' follow the same firmware boot mode and partitioning combination already used, or Windows will fail to boot. See [[Windows and Arch Dual Boot#Important information]] for more details.}}<br />
<br />
There are two types of partition table:<br />
<br />
* [[Master Boot Record| MBR]]: Intended for BIOS systems (also referred to as "msdos")<br />
* [[GUID Partition Table| GPT]]: Intended for UEFI systems<br />
<br />
Any existing partition table can be identified with the following command for each device:<br />
<br />
# parted /dev/sd''x'' print<br />
<br />
=== Partitioning tools ===<br />
<br />
For each device to be partitioned, a proper tool must be chosen according to the partition table to be used. Several partitioning tools are provided by the Arch installation medium, including:<br />
<br />
* [[parted]]: MBR and GPT<br />
* [[Partitioning#Fdisk usage summary|fdisk]], '''cfdisk''', '''sfdisk''': MBR and GPT<br />
* [[Partitioning#Gdisk usage summary|gdisk]], '''cgdisk''', '''sgdisk''': GPT<br />
<br />
{{Warning|Using a partitioning tool that is incompatible with your partition table type will likely result in the destruction of that table, along with any existing partitions/data.}}<br />
<br />
{{Tip|The devices may also be partitioned before booting the Arch installation media, possibly using alternative live systems with other partitioning tools. For example beginners might find it easier to use a graphical partitioning tool such as [[GParted]], which is also provided as a [http://gparted.sourceforge.net/livecd.php live CD] and works with both MBR and GPT partition tables.}}<br />
<br />
==== Using parted in interactive mode ====<br />
<br />
All the examples provided below make use of ''parted'', as it can be used for both BIOS/MBR and UEFI/GPT. It will be launched in ''interactive mode'', which simplifies the partitioning process and reduces unnecessary repetition by automatically applying all partitioning commands to the specified device.<br />
<br />
In order to start operating on a device, execute:<br />
<br />
# parted /dev/sd''x''<br />
<br />
You will notice that the command-line prompt changes from a hash ({{ic|#}}) to {{ic|(parted)}}: this also means that the new prompt is not a command to be manually entered when running the commands in the examples.<br />
<br />
To see a list of the available commands, enter:<br />
<br />
(parted) help<br />
<br />
When finished, or if wishing to implement a partition table or scheme for another device, exit from parted with:<br />
<br />
(parted) quit<br />
<br />
After exiting, the command-line prompt will change back to {{ic|#}}.<br />
<br />
=== Create new partition table ===<br />
<br />
You need to (re)create the partition table of a device when it has never been partitioned before, or when you want to change the type of its partition table. Recreating the partition table of a device is also useful when the partition scheme needs to be restructured from scratch.<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not erase the partition table. Doing so will destroy all existing data on the device, including the UEFI partition with the Windows ''.efi'' file required to boot it.<br />
* MBR is designed specifically for use with BIOS systems, and GPT is designed for UEFI. It is not recommended for less experienced users to break this convention as both have features and/or limitations that may be incompatible with your hardware (e.g. MBR cannot cope with devices larger than 2 TiB). [https://www.happyassassin.net/2014/01/25/uefi-boot-how-does-that-actually-work-then/] If for any reason you do not wish to follow this convention, see [http://mjg59.dreamwidth.org/8035.html] and [http://rodsbooks.com/gdisk/bios.html] for more information and possible workarounds.}}<br />
<br />
Open each device whose partition table must be (re)created with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
To then create a new MBR/msdos partition table for BIOS systems, use the following command:<br />
<br />
(parted) mklabel msdos<br />
<br />
To create a new GPT partition table for UEFI systems instead, use:<br />
<br />
(parted) mklabel gpt<br />
<br />
=== Partition schemes ===<br />
<br />
You can decide the number and size of the partitions the devices should be split into, and which directories will be used to mount the partitions in the installed system (also known as ''mount points''). The mapping from partitions to directories is the [[Partitioning#Partition scheme|partition scheme]], which must comply with the following requirements:<br />
<br />
* At least a partition for the {{ic|/}} (''root'') directory '''must''' be created.<br />
* Depending on the motherboard's firmware interface, the chosen [[#Partition table types]], and in some cases also the chosen [[boot loader]], the following additional partitions '''must''' be created:<br />
** '''BIOS/MBR''': no additional partition required.<br />
** '''UEFI/GPT''': one [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]].<br />
<br />
In the examples below it is assumed that a new and contiguous partitioning scheme is applied to a single device. Some optional partitions will also be created for the {{ic|/boot}} and {{ic|/home}} directories: see also [[Arch filesystem hierarchy]] for an explanation of the purpose of the various directories; if separate partitions for directories like {{ic|/boot}} or {{ic|/home}} are not created, these will simply be contained in the {{ic|/}} partition. Also the creation of an optional partiton for [[swap space]] will be illustrated.<br />
<br />
If not already open in a ''parted'' interactive session, open each device to be partitioned with:<br />
<br />
# parted /dev/sd''x''<br />
<br />
The following command will be used to create partitions:<br />
<br />
(parted) mkpart ''part-type'' ''fs-type'' ''start'' ''end''<br />
<br />
* {{ic|''part-type''}} is one of {{ic|primary}}, {{ic|extended}} or {{ic|logical}}, and is meaningful only for MBR partition tables.<br />
* {{ic|''fs-type''}} is an identifier chosen among those listed by entering {{ic|help mkpart}} as the closest match to the file system that you will use in [[#Create filesystems]]. The ''mkpart'' command does not actually create the file system: the {{ic|''fs-type''}} parameter will simply be used by ''parted'' to set a 1-byte code that is used by boot loaders to "preview" what kind of data is found in the partition, and act accordingly if necessary. See also [[Wikipedia:Disk partitioning#PC partition types]].<br />
: {{Tip|Most [[Wikipedia:File_system#Linux|Linux native file systems]] map to the same partition code ([[Wikipedia:Partition type#PID_83h|0x83]]), so it is perfectly safe to e.g. use {{ic|ext2}} for an ''ext4''-formatted partition.}}<br />
* {{ic|''start''}} is the beginning of the partition from the start of the device. It consists of a number followed by a [http://www.gnu.org/software/parted/manual/parted.html#unit unit], for example {{ic|1M}} means start at 1MiB.<br />
* {{ic|''end''}} is the end of the partition from the start of the device (''not'' from the {{ic|''start''}} value). It has the same syntax as {{ic|''start''}}, for example {{ic|100%}} means end at the end of the device (use all the remaining space).<br />
<br />
{{Warning|It is important that the partitions do not overlap each other: if you do not want to leave unused space in the device, make sure that each partition starts where the previous one ends.}}<br />
<br />
{{Note|''parted'' may issue a warning like:<br />
<br />
Warning: The resulting partition is not properly aligned for best performance.<br />
Ignore/Cancel?<br />
<br />
In this case, read [[Partitioning#Partition alignment]] and follow [[GNU Parted#Alignment]] to fix it.}}<br />
<br />
The following command will be used to flag the partition that contains the {{ic|/boot}} directory as bootable:<br />
<br />
(parted) set ''partition'' boot on<br />
<br />
* {{ic|''partition''}} is the number of the partition to be flagged (see the output of the {{ic|print}} command).<br />
<br />
==== UEFI/GPT examples ====<br />
<br />
In every instance, a special bootable [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] is required.<br />
<br />
{{Warning|If dual-booting with an existing installation of Windows on a UEFI/GPT system, the existing UEFI partition must not be deleted. Doing so will destroy the ''.efi'' file required to boot Windows.}}<br />
<br />
If creating a new EFI System Partition, use the following commands (the recommended size is 512MiB):<br />
<br />
(parted) mkpart ESP fat32 1MiB 513MiB<br />
(parted) set 1 boot on<br />
<br />
The remaining partition scheme is entirely up to you. For one other partition using 100% of remaining space:<br />
<br />
(parted) mkpart primary ext3 513MiB 100%<br />
<br />
For separate {{ic|/}} (20GiB) and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary ext3 20.5GiB 100%<br />
<br />
And for separate {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions:<br />
<br />
(parted) mkpart primary ext3 513MiB 20.5GiB<br />
(parted) mkpart primary linux-swap 20.5GiB 24.5GiB<br />
(parted) mkpart primary ext3 24.5GiB 100%<br />
<br />
==== BIOS/MBR examples ====<br />
<br />
For a minimum single primary partition using all available disk space, the following command would be used:<br />
<br />
(parted) mkpart primary ext3 1MiB 100%<br />
(parted) set 1 boot on<br />
<br />
In the following instance, a 20GiB {{ic|/}} partition will be created, followed by a {{ic|/home}} partition using all the remaining space:<br />
<br />
(parted) mkpart primary ext3 1MiB 20GiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 20GiB 100%<br />
<br />
In the final example below, separate {{ic|/boot}} (100MiB), {{ic|/}} (20GiB), swap (4GiB), and {{ic|/home}} (all remaining space) partitions will be created:<br />
<br />
(parted) mkpart primary ext3 1MiB 100MiB<br />
(parted) set 1 boot on<br />
(parted) mkpart primary ext3 100MiB 20GiB<br />
(parted) mkpart primary linux-swap 20GiB 24GiB<br />
(parted) mkpart primary ext3 24GiB 100%<br />
<br />
=== Create filesystems ===<br />
<br />
Once the partitions have been created, each must be formatted with an appropriate [[file system]], ''except'' for swap partitions. All available partitions on the intended installation device can be listed with the following command:<br />
<br />
# lsblk /dev/sd''x''<br />
<br />
With the exceptions noted below, it is recommended to use the {{ic|ext4}} file system:<br />
<br />
# mkfs.ext4 /dev/sd''xY''<br />
<br />
{{Warning|<br />
* If dual-booting with an existing installation of Windows on a UEFI/GPT system, do not re-format the UEFI partition. Doing so will destroy all existing data on that partition, including the Windows ''.efi'' file required to boot it.<br />
* If a new UEFI system partition has been created on a UEFI/GPT system, it must be formatted with a {{ic|fat32}} or {{ic|vfat32}} file system. Failure to do so will result in an unbootable installation:<br />
:{{bc|# mkfs.vfat -F32 /dev/sd''xY''}}}}<br />
<br />
=== Activate swap ===<br />
<br />
If a swap partition has been created, it must be set up and activated with:<br />
<br />
# mkswap /dev/sd''xY''<br />
# swapon /dev/sd''xY''<br />
<br />
=== Mount the partitions ===<br />
<br />
{{Note|Swap partitions must '''not''' be mounted here.}}<br />
<br />
The {{ic|/}} (root) partition must be mounted '''first''': this is because any directories such as {{ic|/boot}} or {{ic|/home}} that have separate partitions will have to be created in the root file system. The {{ic|/mnt}} directory of the live system will be used to mount the root partition, and consequently all the other partitions will stem from there. If the root partition's name is {{ic|sd''xR''}}, do:<br />
<br />
# mount /dev/sd''xR'' /mnt<br />
<br />
Once the {{ic|/}} partition has been mounted, any remaining partitions may be mounted in any order. The general procedure is to first create the mount point, and then mount the partition to it. If using a separate {{ic|/boot}} partition:<br />
<br />
# mkdir -p /mnt/boot<br />
# mount /dev/sd''xB'' /mnt/boot<br />
<br />
{{Note|Using {{ic|/boot}} is recommended also for mounting the EFI System Partition on UEFI/GPT system. See [[EFISTUB]] and related articles for alternatives.}}<br />
<br />
If using a separate {{ic|/home}} partition:<br />
<br />
# mkdir -p /mnt/home<br />
# mount /dev/sd''xH'' /mnt/home<br />
<br />
Once all the remaining partitions, if any, have been mounted, the devices are ready to install Arch.<br />
<br />
== Select a mirror ==<br />
<br />
You may want to edit the {{ic|mirrorlist}} file and place your preferred mirror first. A copy of this file will be installed on your new system by ''pacstrap'' as well, so it is worth getting it right.<br />
<br />
{{hc|# nano /etc/pacman.d/mirrorlist|<br />
##<br />
## Arch Linux repository mirrorlist<br />
## Sorted by mirror score from mirror status page<br />
## Generated on YYYY-MM-DD<br />
##<br />
<br />
<nowiki>Server = http://mirror.example.xyz/archlinux/$repo/os/$arch</nowiki><br />
...}}<br />
<br />
If you want, you can make it the ''only'' mirror available by deleting all other lines, but it is usually a good idea to have a few more, in case the first one goes offline. Should you change your mirror list at a later stage, refresh all package lists with {{ic|pacman -Syyu}}. See [[Mirrors]] for more information.<br />
<br />
== Install the base system ==<br />
<br />
The base system is installed using the ''pacstrap'' script. Without the {{ic|-i}} switch, every package from the {{Grp|base}} [[Pacman#Installing_package_groups|group]] is installed without prompting. To build packages from the [[AUR]] or with [[ABS]], you will also need the {{Grp|base-devel}} group.<br />
<br />
# pacstrap -i /mnt base base-devel<br />
<br />
Other packages can be installed later using [[pacman]].<br />
<br />
See [[Pacman#Troubleshooting]] and [[Pacman-key#Troubleshooting]] in case of errors.<br />
<br />
== Generate an fstab ==<br />
<br />
[[Wikipedia:Universally_unique_identifier|UUID]]s are used because they have certain advantages (see [[fstab#Identifying filesystems]]). If you prefer labels instead, replace the {{ic|-U}} option with {{ic|-L}}:<br />
<br />
# genfstab -U -p /mnt >> /mnt/etc/fstab<br />
# nano /mnt/etc/fstab<br />
<br />
{{Warning|The {{ic|fstab}} file should always be checked after generating it. If you encounter errors running ''genfstab'' or later in the install process, do '''not''' run ''genfstab'' again; just edit the {{ic|fstab}} file. See [[fstab#Field definitions]] for syntax information.}}<br />
<br />
== Chroot and configure the base system ==<br />
<br />
Next, [[Change root|chroot]] into your newly installed system:<br />
<br />
# arch-chroot /mnt /bin/bash<br />
<br />
At this stage of the installation, you will configure the primary configuration files of your Arch Linux base system. These can either be created if they do not exist, or edited if you wish to change the defaults.<br />
<br />
Closely following and understanding these steps is of key importance to ensure a properly configured system.<br />
<br />
{{Warning|Do not assume that the tools you used from the ISO are automatically installed. For example, if you used ''wifi-menu'' to gain network access during the installation and want to continue so after the first boot, you will have to install ''dialog'' to use it. The following section specifies such cases, do follow it closely to avoid a hiccup in your fresh install.}}<br />
<br />
=== Locale ===<br />
<br />
Locales define which language the system uses and other regional considerations, such as currency denomination, numerology and character sets. Possible values are listed in {{ic|/etc/locale.gen}}, with the active locale defined in {{ic|locale.conf}} files.<br />
<br />
All entries in {{ic|locale.gen}} are commented out (preceded by {{ic|#}}) by default. Uncomment {{ic|en_US.UTF-8 UTF-8}}, as well as other needed localisations. {{ic|UTF-8}} is highly recommended over other options.<br />
<br />
{{hc|# nano /etc/locale.gen|<br />
...<br />
#en_SG ISO-8859-1<br />
en_US.UTF-8 UTF-8<br />
#en_US ISO-8859-1<br />
...<br />
}}<br />
<br />
Before locales can be enabled, they must be ''generated'':<br />
<br />
# locale-gen<br />
<br />
Create {{ic|/etc/locale.conf}}, where {{ic|LANG}} refers to the first column of an uncommented entry in {{ic|/etc/locale.gen}}.<br />
<br />
# echo LANG=''en_US.UTF-8'' > /etc/locale.conf<br />
<br />
Export the chosen locale:<br />
<br />
# export LANG=''en_US.UTF-8''<br />
<br />
{{Note|<br />
* Choosing {{ic|en_US.UTF-8}} as the system locale allows to keep system logs in English for easier troubleshooting. Users may override this setting for their session as described in [[Locale#Setting the locale]].<br />
* {{ic|LANG}} acts as the default value for the locale-related {{ic|LC_*}} variables. To use other locales for these variables, run ''locale'' to see the available options and add them to {{ic|locale.conf}}. It is not recommended to set the {{ic|LC_ALL}} variable. See [[Locale]] for details.}}<br />
<br />
=== Console font and keymap ===<br />
<br />
If you changed the default console keymap and font in [[#Keyboard layout]], create {{ic|/etc/vconsole.conf}} to make those changes persist in the installed system. It is important {{ic|KEYMAP}} matches the value initially set with {{ic|loadkeys}}, to ensure correct entry of [[#Set the root password|the root password]] on reboot.<br />
<br />
{{hc|# nano /etc/vconsole.conf|2=<br />
KEYMAP=''de-latin1''<br />
FONT=''lat9w-16''<br />
}}<br />
<br />
These settings only apply to virtual consoles, not [[Xorg]]. See [[Fonts#Console fonts]] for more information.<br />
<br />
=== Time zone ===<br />
<br />
Available time zones and subzones can be found in the {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}} directories, and listed with the ''ls'' command. Create a symbolic link {{ic|/etc/localtime}} to your subzone file {{ic|/usr/share/zoneinfo/''Zone''/''SubZone''}}:<br />
<br />
# ln -s /usr/share/zoneinfo/''Zone''/''SubZone'' /etc/localtime<br />
<br />
You may use [http://tldp.org/LDP/abs/html/tabexpansion.html tab completion] to show available zones and subzones. Example:<br />
<br />
# ln -s /usr/share/zoneinfo/Europe/Minsk /etc/localtime<br />
<br />
If you get {{ic|ln: failed to create symbolic link '/etc/localtime': File exists}}, check the existing file with {{ic|ls -l /etc/localtime}} and add the {{ic|-f}} option to the ''ln'' command to overwrite it.<br />
<br />
=== Hardware clock ===<br />
<br />
If you have multiple operating systems installed in the same machine, they will all derive the current time from the same hardware clock, which must be set to either UTC or ''localtime''. For this reason you must make sure that all the operating systems see the hardware clock as providing time in the same chosen [[Time#Time standard|standard]], otherwise some of them will perform the time zone adjustement for the system clock, while others will not.<br />
<br />
In particular, it is strongly recommended to set the hardware clock to UTC, in order to avoid conflicts between the installed operating systems. For example, if the hardware clock was set to ''localtime'', more than one operating system may adjust it after a [[Wikipedia:Daylight_saving_time|DST]] change, thus resulting in an overcorrection; more problems may arise when travelling between different time zones and using one of the operating systems to reset the system/hardware clock.<br />
<br />
To set the hardware clock to UTC in Linux, run:<br />
<br />
# hwclock --systohc --utc<br />
<br />
The ''hwclock'' command also generates the {{ic|/etc/adjtime}} file.<br />
<br />
{{Note|Using UTC for the hardware clock does not mean that software will display time in UTC. However, the system setup/BIOS interface will instead: this should be neither surprising nor treated as a bug.}}<br />
<br />
{{Warning|Windows systems use ''localtime'' by default. Using ''localtime'' on Arch systems may lead to several known and unfixable bugs, but there are no plans to drop support for ''localtime''. It is, though, recommended to set Windows to use UTC instead, and prevent it from synchronising time. See [[Time#UTC in Windows]].}}<br />
<br />
=== Kernel modules ===<br />
<br />
Needed kernel modules are automatically loaded by [[udev]], so you will rarely need to load modules manually. See [[Kernel modules]] for details.<br />
<br />
=== Hostname ===<br />
<br />
Set the [[Network_configuration#Set_the_hostname|hostname]] to your liking:<br />
<br />
# echo ''myhostname'' > /etc/hostname<br />
<br />
Add the same hostname to {{ic|/etc/hosts}}:<br />
<br />
#<ip-address> <hostname.domain.org> <hostname><br />
127.0.0.1 localhost.localdomain localhost ''myhostname''<br />
::1 localhost.localdomain localhost ''myhostname''<br />
<br />
=== Configure the network ===<br />
<br />
You need to configure the network again, but this time for your newly installed environment. The procedure and prerequisites are similar to the one described [[#Establish an internet connection|above]], except we are going to make it persistent and automatically run at boot.<br />
<br />
As a first step, identify the network interface name you want to configure the connection for with {{ic|ip link}}.<br />
<br />
{{Note|<br />
* For more in-depth information on network configuration, visit [[Network configuration]] and [[Wireless network configuration]].<br />
* If you would like to use the old interface naming scheme (i.e. {{ic|eth''X''}} and {{ic|wlan''X''}}) you can accomplish this by creating an empty file at {{ic|/etc/udev/rules.d/80-net-setup-link.rules}} which will mask the file of the same name located under {{ic|/usr/lib/udev/rules.d}}.<br />
}}<br />
<br />
Now select a daemon to handle the configuration and operation. Several are listed below; only select '''one''' of them for the new system.<br />
<br />
==== Wired ====<br />
<br />
; Using dhcpcd<br />
A simple option for adapter configuration is to use the DHCP Client Daemon, the method used by default with the install medium. See [[Dhcpcd#Running]].<br />
<br />
Users requiring only '''single wired network connection''' can simply enable the ''dhcpcd'' service for the interface:<br />
<br />
# systemctl enable dhcpcd@''interface_name''.service<br />
<br />
If static IP settings are required, adjust the profile configuration as described in [[#Static IP]]. <br />
<br />
; Using systemd-networkd<br />
<br />
The Arch default init system, [[systemd]] includes built-in support for managing adapters using both DHCP and static IP setups. Configuration is simple. See [[Systemd-networkd#Required_services_and_setup]].<br />
<br />
; Using netctl<br />
<br />
Another option is [[netctl]] which is a CLI-based tool used to configure and manage network connections via user-created profiles. Create a profile as shown in [[netctl#Example profiles]], then enable it as described in [[netctl#Basic method]].<br />
<br />
==== Wireless ====<br />
<br />
All of the tools listed in [[#Wired]] above can activate wireless connections. For wireless, however, ''dhcpcd'' and ''systemd-networkd'' require a separate configuration of the connection in the wireless backend, [[wpa_supplicant]], first. If you anticipate to connect the machine to different wireless networks over time, a tool which provides its own connection management may be easier to handle. Aside from [[netctl]] introduced below, [[Wireless network configuration#Automatic setup]] lists other choices. <br />
<br />
{{Note|If your wireless adapter requires a firmware (as described in the above [[#Wireless|Establish an internet connection]] section and also in the article [[Wireless network configuration#Device driver]]), install the package containing your firmware. Most of the time, the {{Pkg|linux-firmware}} package will contain the needed firmware. Though for some devices, the required firmware might be in its own package. For example:<br />
{{bc|# pacman -S zd1211-firmware}}<br />
See [[Wireless network configuration#Installing driver/firmware]] for more info.}}<br />
<br />
Install {{Pkg|iw}} and {{Pkg|wpa_supplicant}} which you will need to connect to a network:<br />
<br />
# pacman -S iw wpa_supplicant<br />
<br />
===== Adding wireless networks =====<br />
<br />
; Using wifi-menu<br />
<br />
Install {{Pkg|dialog}}, which is required for ''wifi-menu'':<br />
<br />
# pacman -S dialog<br />
<br />
After finishing the rest of this installation and rebooting, you can connect to the network with:<br />
<br />
# wifi-menu ''interface_name''<br />
<br />
Where {{ic|''interface_name''}} is the interface of your wireless chipset.<br />
<br />
{{Warning|Do not use ''wifi-menu'' now, instead wait until you have finished this guide and have rebooted. It will not work now because a process spawned by this command will conflict with the one you have running outside of the chroot. Alternatively, you could just configure a network profile manually using the following templates so that you do not have to worry about using ''wifi-menu'' at all.}}<br />
<br />
; Using manual netctl profiles<br />
<br />
Copy a network profile from {{ic|/etc/netctl/examples}} to {{ic|/etc/netctl}}:<br />
<br />
# cd /etc/netctl<br />
# cp examples/wireless-wpa my-network<br />
<br />
Edit the profile as needed (modify {{ic|Interface}}, {{ic|ESSID}} and {{ic|Key}}):<br />
<br />
# nano my-network<br />
<br />
Enable above created profile to start it at every boot:<br />
<br />
# netctl enable my-network<br />
<br />
===== Connect automatically to known networks =====<br />
<br />
{{Warning|This method cannot be used with explicitely enabled [[Netctl#Configuration|profiles]], i.e. through {{ic|netctl enable ''profile''}}.}}<br />
<br />
Install {{Pkg|wpa_actiond}}, which is required for {{ic|netctl-auto}}:<br />
<br />
# pacman -S wpa_actiond<br />
<br />
Enable the {{ic|netctl-auto}} service, which will connect to known networks and gracefully handle roaming and disconnects:<br />
<br />
# systemctl enable netctl-auto@''interface_name''.service<br />
<br />
{{Tip|[[netctl]] also provides {{ic|netctl-ifplugd}}, which can be used to handle wired profiles in conjunction with {{ic|netctl-auto}}.}}<br />
<br />
==== Analog modem, ISDN or PPPoE DSL ====<br />
<br />
For xDSL, dial-up and ISDN connections, see [[Direct Modem Connection]].<br />
<br />
=== Create an initial ramdisk environment ===<br />
<br />
As [[mkinitcpio]] was run on installation of {{Pkg|linux}} with ''pacstrap'', most users can use the defaults provided in {{ic|mkinitcpio.conf}}. For special configurations, set the correct [[Mkinitcpio#HOOKS|hooks]] in {{ic|/etc/mkinitcpio.conf}} and [[Mkinitcpio#Image_creation_and_activation|re-generate the initramfs image]].<br />
<br />
=== Set the root password ===<br />
<br />
Set the root password with:<br />
<br />
# passwd<br />
<br />
=== Install and configure a bootloader ===<br />
<br />
See [[Boot loaders]] for available choices and configurations. [[Microcode]] updates for Intel CPUs must also be configured after installing the boot loader.<br />
<br />
==== For BIOS motherboards ====<br />
<br />
Here, installation with '''GRUB''' and '''MBR''' is demonstrated. <br />
<br />
Install the {{Pkg|grub}} package; to have GRUB search for other installed operating systems, install {{Pkg|os-prober}} in addition:<br />
<br />
# pacman -S grub os-prober<br />
<br />
Install the bootloader to the drive Arch was installed to (do '''not''' append a partition number, or {{ic|/dev/sda''X''}}):<br />
<br />
# grub-install --target=i386-pc --recheck ''/dev/sda''<br />
<br />
Automatically generate {{ic|grub.cfg}}:<br />
<br />
# grub-mkconfig -o /boot/grub/grub.cfg<br />
<br />
{{Note|A sample {{ic|/boot/grub/grub.cfg}} is included with the {{Pkg|grub}} package, and subsequent {{ic|grub-*}} commands may not over-write it. Ensure your intended changes are in {{ic|grub.cfg}}, rather than in {{ic|grub.cfg.new}} or similar file.}}<br />
<br />
For more information on configuring and using GRUB, see [[GRUB]].<br />
<br />
==== For UEFI motherboards ====<br />
<br />
Here, installation with ''gummiboot'' is demonstrated. First install {{Pkg|dosfstools}} to manipulate the EFI System Partition post-installation, and {{Pkg|efibootmgr}} to create a UEFI boot entry (used by bootmanager installation scripts):<br />
<br />
# pacman -S dosfstools efibootmgr<br />
<br />
{{Note|<br />
* For UEFI boot, the drive needs to be GPT-partitioned and an [[Unified Extensible Firmware Interface#EFI System Partition|EFI System Partition]] (512 MiB or larger, gdisk type {{ic|EF00}}, formatted with FAT32) must be present. In the following examples, this partition is assumed to be mounted at {{ic|/boot}}. If you have followed this guide from the beginning, you have already done all of these.<br />
* It is strongly recommended to have the EFI System Partition mounted at {{ic|/boot}} as this is required to automatically update Gummiboot.<br />
}}<br />
<br />
Install the {{Pkg|gummiboot}} package and run the automated installation script, replacing {{ic|'''$esp'''}} with the location of your EFI System Partiton, usually {{ic|/boot}}:<br />
<br />
# pacman -S gummiboot<br />
# gummiboot --path='''$esp''' install<br />
<br />
Gummiboot will automatically be detected by firmware that requires that the bootable {{ic|bootx64.efi}} stub be placed in {{ic|'''$esp'''/EFI/boot}}, and will in turn automatically detect the presence of any other installed operating systems using ''.efi'' stubs. However, it will still be necessary to manually create a configuration file for Gummiboot.<br />
<br />
First, create {{ic|'''$esp'''/loader/entries/arch.conf}} and add the following, replacing {{ic|/dev/sdaX}} with your '''root''' partition (most likely {{ic|/dev/sda2}} if {{ic|/dev/sda1}} is the ESP):<br />
<br />
{{hc|# nano '''$esp'''/loader/entries/arch.conf|2=<br />
title Arch Linux<br />
linux /vmlinuz-linux<br />
initrd /initramfs-linux.img<br />
options root='''/dev/sdaX''' rw<br />
}}<br />
<br />
Second, create {{ic|'''$esp'''/loader/loader.conf}} and add the following, replacing the timeout value (in seconds) with your own choice:<br />
{{hc|# nano '''$esp'''/loader/loader.conf|2=<br />
default arch<br />
timeout 5<br />
}}<br />
<br />
See [[gummiboot]] for more information.<br />
<br />
== Unmount the partitions and reboot ==<br />
<br />
Exit from the chroot environment:<br />
<br />
# exit<br />
<br />
{{Note|While partitions are unmounted automatically by ''systemd'' on shutdown, you may do so manually with {{ic|umount -R /mnt}} as a safety measure. If the partition is "busy", you can find the cause with [[fuser]].}}<br />
<br />
Reboot the computer:<br />
<br />
# reboot<br />
<br />
Remove the installation media, or you may boot back into it. You can log into your new installation as ''root'', using the password you specified with ''passwd''.<br />
<br />
== Post-installation (Applications & GUI environments) ==<br />
<br />
Your new Arch Linux base system is now a functional GNU/Linux environment ready to be built into whatever you wish or require for your purposes. You are now ''strongly'' advised to read the [[General recommendations]] article, especially the first two sections. Its other sections provide links to post-installation tutorials like setting up a graphical user interface, sound or a touchpad.<br />
<br />
For a list of applications that may be of interest, see [[List of applications]].</div>Sarenhttps://wiki.archlinux.org/index.php?title=User:Saren&diff=313265User:Saren2014-05-03T20:19:35Z<p>Saren: </p>
<hr />
<div>I am the owner of wtako.net .<br />
<br />
wtako.net is a general purpose private server, router, and minecraft server.<br />
<br />
<br />
[https://www.wtako.net/ https://www.wtako.net/]</div>Sarenhttps://wiki.archlinux.org/index.php?title=User:Saren&diff=313264User:Saren2014-05-03T20:19:10Z<p>Saren: </p>
<hr />
<div>I am the owner of wtako.net<br />
wtako.net is a general purpose private server, router, and minecraft server.<br />
[https://www.wtako.net/ https://www.wtako.net/]</div>Sarenhttps://wiki.archlinux.org/index.php?title=User:Saren&diff=313263User:Saren2014-05-03T20:18:25Z<p>Saren: Created page with "I own this site: [https://www.wtako.net/]"</p>
<hr />
<div>I own this site: [https://www.wtako.net/]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Nginx&diff=313262Nginx2014-05-03T20:16:45Z<p>Saren: Prevent service start fail caused by rm file not found</p>
<hr />
<div>[[Category:Web Server]]<br />
[[de:Nginx]]<br />
[[ja:Nginx]]<br />
[[ru:Nginx]]<br />
[[zh-CN:Nginx]]<br />
'''Nginx''' (pronounced "engine X"), is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server, written by Igor Sysoev in 2005. According to Netcraft's [http://news.netcraft.com/archives/2014/01/03/january-2014-web-server-survey.html January 2014 Web Server Survey], Nginx now hosts 14.4% of all domains worldwide, while [[Apache]] hosts about 41.64%. Nginx is now well known for its stability, rich feature set, simple configuration, and low resource consumption.<br />
<br />
== Installation ==<br />
<br />
[[Pacman|Install]] package {{Pkg|nginx}} in the [[official repositories]].<br />
<br />
For a ''Ruby on Rails'' oriented installation, see [[Ruby on Rails#The Perfect Rails Setup]].<br />
<br />
For a chroot-based installation for additional security, see [[#Installation_in_a_chroot]]<br />
<br />
== Running ==<br />
<br />
To enable the Nginx service by default at start-up, run:<br />
# systemctl enable nginx<br />
<br />
To start the Nginx service, run:<br />
# systemctl start nginx<br />
<br />
The default served page at http://127.0.0.1 is: <br />
/usr/share/nginx/html/index.html<br />
<br />
== Configuring ==<br />
<br />
You can modify the configuration by editing the files in {{ic|/etc/nginx/}}. The main configuration file is located at {{ic|/etc/nginx/nginx.conf}}. <br />
<br />
More details can be found here: [http://wiki.nginx.org/Configuration Nginx Configuration Examples].<br />
<br />
The examples below cover the most common use cases. It is assumed that you use the default location for documents ({{ic|/usr/share/nginx/html}}). If that is not the case, substitute your path instead.<br />
<br />
=== General Configuration ===<br />
<br />
You should choose a fitting value for {{ic|worker_processes}}. This settings ultimately defines how many connection nginx will accept and how many processors it will be able to make use of. Generally, making it the number of hardware threads in your system is a good start. As such, with modern servers, set something like<br />
<br />
worker_processes 8;<br />
<br />
The maximum connections nginx will accept is given by {{ic|1=max_clients = worker_processes * worker_connections}}.<br />
<br />
=== FastCGI ===<br />
<br />
FastCGI, also FCGI, is a protocol for interfacing interactive programs with a web server. FastCGI is a variation on the earlier Common Gateway Interface (CGI); FastCGI's main aim is to reduce the overhead associated with interfacing the web server and CGI programs, allowing a server to handle more web page requests at once.<br />
<br />
FastCGI technology is introduced into Nginx to work with many external tools, i.e.: Perl, [[PHP]] and [[Python]].<br />
<br />
==== PHP implementation ====<br />
<br />
There are different ways to run a FastCGI server for PHP. We cover '''php-fpm''', a recommended solution.<br />
<br />
===== Step 1: PHP configuration =====<br />
<br />
The {{Ic|open_basedir}} in {{ic|/etc/php/php.ini}} has to list base directories which contain PHP files, like {{ic|/usr/share/nginx/html/}} and {{ic|/usr/share/webapps/}}:<br />
open_basedir = /usr/share/webapps/:/srv/http/:/usr/share/nginx/html/:/home/:/tmp/:/usr/share/pear/<br />
<br />
After that let's configure modules you need. For example to use sqlite3 you should install {{ic|php-sqlite}}. Then enable it in {{ic|/etc/php/php.ini}} by uncommenting following line:<br />
extension=sqlite3.so<br />
<br />
If you run nginx in chrooted environment (chroot is {{ic|/srv/nginx-jail}}, web pages are served at {{ic|/srv/nginx-jail/www}}), the directive refers to the chroot only (i.e. {{ic|1=open_basedir = /www}}) only.<br />
<br />
===== Step 2: php-fpm =====<br />
<br />
* http://php-fpm.org<br />
<br />
Install {{Pkg|php-fpm}}.<br />
The configuration file is {{ic|/etc/php/php-fpm.conf}}.<br />
Enable and start the [[systemd]] ''php-fpm.service''.<br />
<br />
If you run nginx in chrooted environment (chroot is {{ic|/srv/nginx-jail}}, web pages are served at {{ic|/srv/nginx-jail/www}}), you must modify the file {{ic|/etc/php/php-fpm.conf}} to include the {{ic|chroot /srv/nginx-jail}} and {{ic|1=listen = /srv/nginx-jail/run/php-fpm/php-fpm.sock}} directives within the pool name section (a default one is {{ic|[www]}}). (Create the directory for the socket file, if missing.)<br />
<br />
===== Step 3: Nginx configuration =====<br />
<br />
Inside each {{Ic|server}} block serving a PHP web application should appear a {{Ic|location}} block similar to:<br />
location ~ \.php$ {<br />
try_files $uri = 404; <br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
fastcgi_index index.php;<br />
include fastcgi.conf;<br />
}<br />
<br />
If the {{Ic|root}} path in specified only inside a {{Ic|location}} (as it is in the default config), then either add<br />
root /srv/http<br />
to the {{Ic|location ~ \.php$}}, or move it directly somewhere under {{Ic|server}}.<br />
<br />
A complete working configuration could look like this:<br />
<br />
server {<br />
listen 80;<br />
server_name localhost;<br />
root /usr/share/nginx/html;<br />
location / {<br />
index index.html index.htm index.php;<br />
}<br />
<br />
location ~ \.php$ {<br />
#fastcgi_pass 127.0.0.1:9000; (depending on your php-fpm socket configuration)<br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
fastcgi_index index.php;<br />
include fastcgi.conf;<br />
}<br />
}<br />
<br />
You could create {{Ic|/etc/nginx/php.conf}} and save the php bit of the configuration there, then when needed just include this file into the {{Ic|server}} block.<br />
server = {<br />
...<br />
include php.conf;<br />
...<br />
}<br />
<br />
If you are going to process .html and .htm files with PHP, you should have something like this:<br />
location ~ \.(php|html|htm)$ {<br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
fastcgi_index index.php;<br />
include fastcgi_params;<br />
}<br />
<br />
Non .php files processing in php-fpm should be explicitly enabled in<br />
{{Ic|/etc/php/php-fpm.conf}}:<br />
security.limit_extensions = .php .html .htm<br />
<br />
You need to restart the php-fpm daemon if you changed the configuration.<br />
# systemctl restart php-fpm<br />
<br />
'''Pay attention''' to the {{Ic|fastcgi_pass}} argument, as it must be the TCP or Unix socket defined by the chosen FastCGI server in its config file. The '''default''' (Unix) socket for {{Ic|php-fpm}} is<br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
You might use the common TCP socket, '''not default''',<br />
fastcgi_pass 127.0.0.1:9000;<br />
Unix domain sockets are however faster.<br />
<br />
{{Ic|fastcgi.conf}} or {{Ic|fastcgi_params}} are usually included because they hold FastCGI settings for Nginx; the use of the latter is deprecated, though. They come within the Nginx installation.<br />
<br />
Finally, if Nginx has been working, run:<br />
# systemctl restart nginx<br />
<br />
If you would like to test the FastCGI implementation, create {{ic|/usr/share/nginx/html/index.php}} with content<br />
<?php<br />
phpinfo();<br />
?> <br />
and visit the URL http://127.0.0.1/index.php with your browser after checking that {{ic|/usr/share/nginx/html}} is included in {{ic|open_basedir}}.<br />
<br />
==== CGI implementation ====<br />
<br />
This implementation is needed for CGI applications.<br />
<br />
===== Step 1: fcgiwrap =====<br />
<br />
Install {{Pkg|fcgiwrap}}.<br />
The configuration file is {{ic|/usr/lib/systemd/system/fcgiwrap.socket}}.<br />
Enable and start the [[systemd]] ''fcgiwrap.socket''.<br />
<br />
The systemd unit file is currently being discussed on [https://bugs.archlinux.org/task/31696 this ArchLinux task page]. You may want to examine the unit file yourself to ensure it will work the way you want.<br />
<br />
====== Multiple worker threads ======<br />
<br />
If you want to spawn multiple worker threads, it's recommended that you use {{AUR|multiwatch}}, which will take care of restarting crashed children. You will need to use {{ic|spawn-fcgi}} to create the unix socket, as multiwatch seems unable to handle the systemd-created socket, even though fcgiwrap itself does not have any trouble if invoked directly in the unit file.<br />
<br />
Copy the unit file from {{ic|/usr/lib/systemd/system/fcgiwrap.service}} to {{ic|/etc/systemd/system/fcgiwrap.service}} (and the {{ic|fcgiwrap.socket}} unit, if present), and modify the {{ic|ExecStart}} line to suit your needs. Here is a unit file that uses {{AUR|multiwatch}}. Make sure {{ic|fcgiwrap.socket}} is not started or enabled, because it will conflict with this unit:<br />
<br />
{{hc|/etc/systemd/system/fcgiwrap.service|2=<br />
[Unit]<br />
Description=Simple CGI Server<br />
After=nss-user-lookup.target<br />
<br />
[Service]<br />
ExecStartPre=/bin/rm -f /run/fcgiwrap.socket<br />
ExecStart=/usr/bin/spawn-fcgi -u http -g http -s /run/fcgiwrap.sock -n -- /usr/bin/multiwatch -f 10 -- /usr/sbin/fcgiwrap<br />
ExecStartPost=/usr/bin/chmod 660 /run/fcgiwrap.sock<br />
PrivateTmp=true<br />
Restart=on-failure<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Tweak {{ic|-f 10}} to change the number of children that are spawned.<br />
<br />
{{Warning|The ExecStartPost line is required because of strange behaviour I'm seeing when I use the {{ic|-M 660}} option for {{ic|spawn-fcgi}}. The wrong mode is set. This may be a bug?}}<br />
<br />
===== Step 2: Nginx configuration =====<br />
<br />
Inside each {{Ic|server}} block serving a CGI web application should appear a {{Ic|location}} block similar to:<br />
<br />
location ~ \.cgi$ {<br />
root /path/to/server/cgi-bin;<br />
fastcgi_pass unix:/run/fcgiwrap.sock;<br />
include fastcgi.conf;<br />
}<br />
<br />
The '''default''' (Unix) socket for {{Ic|fcgiwrap}} is ''/run/fcgiwrap.sock''.<br />
<br />
== Installation in a chroot ==<br />
<br />
Installing Nginx in a chroot adds an additional layer of security. For<br />
maximum security the chroot should include only the files needed to run<br />
the Nginx server and all files should have the most restrictive<br />
permissions possible, e.g., as much as possible should be owned by root,<br />
directories such as {{ic|/usr/bin}} should be unreadable and unwriteable,<br />
etc. <br />
<br />
Arch comes with an {{ic|http}} user and group by default which will run the<br />
server. The chroot will be in {{ic|/srv/http}}.<br />
<br />
A perl script to create this jail is available at<br />
[https://gist.github.com/4365696 jail.pl gist]. You can either use that or follow the instructions in this article. It expects to be run<br />
as root. You will need to uncomment a line before it makes any changes.<br />
<br />
=== Create Necessary Devices ===<br />
<br />
Nginx needs {{ic|/dev/null}}, {{ic|/dev/random}}, and<br />
{{ic|/dev/urandom}}. To install these in the chroot we create the<br />
{{ic|/dev/}} folder and add the devices with mknod. We avoid mounting<br />
all of {{ic|/dev/}} to ensure that, even if the chroot is compromised, an<br />
attacker must break out of the chroot to access important devices like<br />
{{ic|/dev/sda1}}.<br />
<br />
{{Tip|See {{ic|man mknod}} and {{ic|<nowiki>ls -l<br />
/dev/{null,random,urandom}</nowiki>}} to better<br />
understand the argument to mknod.}}<br />
<br />
# export JAIL=/srv/http<br />
# mkdir $JAIL/dev<br />
# mknod -m 0666 $JAIL/dev/null c 1 3<br />
# mknod -m 0666 $JAIL/dev/random c 1 8<br />
# mknod -m 0444 $JAIL/dev/urandom c 1 9<br />
<br />
=== Create Necessary Folders ===<br />
<br />
Nginx requires a bunch of files to run properly. Before copying them<br />
over, create the folders to store them. This assumes your Nginx document<br />
root will be {{ic|/srv/http/www}}.<br />
<br />
# mkdir -p $JAIL/etc/nginx/logs<br />
# mkdir -p $JAIL/usr/{lib,bin}<br />
# mkdir -p $JAIL/usr/share/nginx<br />
# mkdir -p $JAIL/var/{log,lib}/nginx<br />
# mkdir -p $JAIL/www/cgi-bin<br />
# mkdir -p $JAIL/{run,tmp}<br />
# cd $JAIL; ln -s usr/lib lib <br />
<br />
{{Note| If using a 64 bit kernel you will need to create symbolic links {{ic|lib64}} and {{ic|usr/lib64}} to {{ic|usr/lib}}: {{ic|cd $JAIL; ln -s usr/lib lib64}} and {{ic|cd $JAIL/usr; ln -s lib lib64}}<br />
}}<br />
Then mount {{ic|$JAIL/tmp}} and {{ic|$JAIL/run}} as tmpfs's. The size<br />
should be limited to ensure an attacker cannot eat all the RAM.<br />
<br />
# mount -t tmpfs none $JAIL/run -o 'noexec,size=1M'<br />
# mount -t tmpfs none $JAIL/tmp -o 'noexec,size=100M'<br />
<br />
In order to preserve the mounts across reboots, the following entries should be added to /etc/fstab:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
tmpfs /srv/http/run tmpfs rw,noexec,relatime,size=1024k 0 0<br />
tmpfs /srv/http/tmp tmpfs rw,noexec,relatime,size=102400k 0 0<br />
</nowiki>}}<br />
<br />
=== Populate the chroot ===<br />
<br />
First copy over the easy files.<br />
<br />
# cp -r /usr/share/nginx/* $JAIL/usr/share/nginx<br />
# cp -r /usr/share/nginx/html/* $JAIL/www<br />
# cp /usr/bin/nginx $JAIL/usr/bin/<br />
# cp -r /var/lib/nginx $JAIL/var/lib/nginx<br />
<br />
Now copy over required libraries. Use ldd to list them and then copy<br />
them all to the correct location. Copying is preferred over hardlinks to<br />
ensure that even if an attacker gains write access to the files they<br />
cannot destroy or alter the true system files.<br />
<br />
{{hc|$ ldd /usr/bin/nginx|<nowiki><br />
linux-vdso.so.1 (0x00007fffc41fe000)<br />
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f57ec3e8000)<br />
libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f57ec1b1000)<br />
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f57ebead000)<br />
libm.so.6 => /usr/lib/libm.so.6 (0x00007f57ebbaf000)<br />
libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f57eb94c000)<br />
libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f57eb6e0000)<br />
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f57eb2d6000)<br />
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f57eb0d2000)<br />
libz.so.1 => /usr/lib/libz.so.1 (0x00007f57eaebc000)<br />
libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0x00007f57eac8d000)<br />
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f57eaa77000)<br />
libc.so.6 => /usr/lib/libc.so.6 (0x00007f57ea6ca000)<br />
/lib64/ld-linux-x86-64.so.2 (0x00007f57ec604000)</nowiki>}}<br />
<br />
# cp /lib64/ld-linux-x86-64.so.2 $JAIL/lib<br />
<br />
For files residing in {{ic|/usr/lib}} you may try the following one-liner:<br />
{{bc|<nowiki># cp $(ldd /usr/bin/nginx | grep /usr/lib | sed -sre 's/(.+)(\/usr\/lib\/\S+).+/\2/g') $JAIL/usr/lib</nowiki>}}<br />
<br />
{{Note|Do not try to copy linux-vdso.so – it is not a real library and does not exist in /usr/lib. Also ld-linux-x86-64.so will likely be listed in /lib64 for a 64 bit system.}}<br />
<br />
Copy over some misc. but necessary libraries and system files.<br />
<br />
{{bc|# cp /usr/lib/libnss_* $JAIL/usr/lib<br />
# cp -rfvL /etc/{services,localtime,nsswitch.conf,nscd.conf,protocols,hosts,ld.so.cache,ld.so.conf,resolv.conf,host.conf,nginx} $JAIL/etc}}<br />
<br />
Create restricted user/group files for the chroot. This way only the<br />
users needed for the chroot to function exist as far as the chroot<br />
knows, and none of the system users/groups are leaked to attackers<br />
should they gain access to the chroot.<br />
<br />
{{hc|$JAIL/etc/group|<br />
http:x:33:<br />
nobody:x:99:<br />
}}<br />
<br />
{{hc|$JAIL/etc/passwd|<br />
http:x:33:33:http:/:/bin/false<br />
nobody:x:99:99:nobody:/:/bin/false<br />
}}<br />
<br />
{{hc|$JAIL/etc/shadow|<br />
http:x:14871::::::<br />
nobody:x:14871::::::<br />
}}<br />
<br />
{{hc|$JAIL/etc/gshadow|<br />
http:::<br />
nobody:::<br />
}}<br />
<br />
# touch $JAIL/etc/shells<br />
# touch $JAIL/run/nginx.pid<br />
<br />
Finally make set very restrictive permissions. As much as possible<br />
should be owned by root and set unwritable.<br />
<br />
# chown -R root:root $JAIL/<br />
<br />
# chown -R http:http $JAIL/www<br />
# chown -R http:http $JAIL/etc/nginx<br />
# chown -R http:http $JAIL/var/{log,lib}/nginx<br />
# chown http:http $JAIL/run/nginx.pid<br />
<br />
# find $JAIL/ -gid 0 -uid 0 -type d -print | xargs sudo chmod -rw<br />
# find $JAIL/ -gid 0 -uid 0 -type d -print | xargs sudo chmod +x<br />
# find $JAIL/etc -gid 0 -uid 0 -type f -print | xargs sudo chmod -x<br />
# find $JAIL/usr/bin -type f -print | xargs sudo chmod ug+rx<br />
# find $JAIL/ -group http -user http -print | xargs sudo chmod o-rwx<br />
# chmod +rw $JAIL/tmp<br />
# chmod +rw $JAIL/run<br />
<br />
If your server will bind port 80 (or any port 0-1024), give the<br />
chrooted executable permission to bind these ports without root.<br />
<br />
# setcap 'cap_net_bind_service=+ep' $JAIL/usr/bin/nginx<br />
<br />
=== Modify nginx.service to start chroot ===<br />
<br />
Before modifying the nginx.service unit file, it may be a good idea to copy it to<br />
{{ic|/etc/systemd/system/}} since the unit files there take priority over those in {{ic|/usr/lib/systemd/system/}}. <br />
This means upgrading nginx would not modify your custom .service file. <br />
# cp /usr/lib/systemd/system/nginx.service /etc/systemd/system/nginx.service<br />
<br />
The systemd unit must be changed to start up Nginx in the chroot, as<br />
the http user, and store the pid file in the chroot <br />
{{Note|I'm not sure if the pid file needs to be stored in the chroot jail.}}<br />
<br />
{{hc|/etc/systemd/system/nginx.service|<nowiki><br />
[Unit]<br />
Description=A high performance web server and a reverse proxy server<br />
After=syslog.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/srv/http/run/nginx.pid<br />
ExecStartPre=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -t -q -g 'pid /run/nginx.pid; daemon on; master_process on;'<br />
ExecStart=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;'<br />
ExecReload=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;' -s reload<br />
ExecStop=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid;' -s quit<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki>}}<br />
<br />
{{Note|Upgrading nginx with pacman will not upgrade the chrooted nginx installation. You have to take care of the updates manually by repeating some of the steps above. Do not forget to also update the libraries it links against. }}<br />
<br />
You can now safely get rid of the non-chrooted nginx installation. <br />
# pacman -Rsc nginx<br />
<br />
If you do not remove the non-chrooted nginx installation, you may want to make sure that the running nginx process is in fact the chrooted one. You can do so by checking where {{ic|/proc/{PID}/root}} symmlinks to. If should link to {{ic|/srv/http}} instead of {{ic|/}}. <br />
# ps -C nginx | awk '{print $1}' | sed 1d | while read -r PID; do ls -l /proc/$PID/root; done<br />
<br />
== Troubleshooting ==<br />
<br />
=== Accessing local IP redirects to localhost ===<br />
<br />
Solution from the Arch Linux [https://bbs.archlinux.org/viewtopic.php?pid=780561#p780561 forum].<br />
<br />
Edit {{ic|/etc/nginx/nginx.conf}} and locate the "server_name localhost" line without a # infront of it, and add below:<br />
server_name_in_redirect off;<br />
<br />
Default behavior is that nginx redirects any requests to the value given as server_name in the config.<br />
<br />
=== Error: 403 (Permission error) ===<br />
<br />
This is most likely a permission error. Are you sure whatever user configured in the Nginx configuration is able to read the correct files?<br />
<br />
If the files are located within a home directory, (e.g. {{ic|/home/arch/public/webapp}}) and you are sure the user running Nginx has the right permissions (you can temporarily chmod all the files to 777 in order to determine this), {{ic|/home/arch}} might be '''chmod 750''', simply {{Ic|chmod}} it to ''751'', and it should work.<br />
<br />
'''If you have changed your document root'''<br />
<br />
If you are sure that permissions are as they should be, make sure that your document root directory is not empty. Try creating index.html in there.<br />
<br />
=== Error: 404 (Pathinfo error) ===<br />
<br />
In some framework (like thinkphp, cakephp) or CMS, they need the pathinfo function. <br />
<br />
1. Edit the file {{ic|/etc/php/php.ini}}, make sure<br />
cgi.fix_pathinfo=1<br />
2. Edit {{ic|/etc/nginx/conf/nginx.conf}}, comment<br />
<br />
location ~ \.php$ {<br />
...<br />
}<br />
<br />
to <br />
<br />
#location ~ \.php$ {<br />
#...<br />
#}<br />
<br />
Then add the follows,<br />
location ~ ^(.+\.php)(.*)$ {<br />
root /srv/http/nginx;<br />
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; <br />
#fastcgi_pass 127.0.0.1:9000; #Un-comment this and comment "fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;" if you are not using php-fpm.<br />
fastcgi_index index.php;<br />
set $document_root2 $document_root;<br />
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }<br />
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }<br />
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }<br />
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }<br />
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }<br />
fastcgi_split_path_info ^(.+\.php)(.*)$;<br />
fastcgi_param SCRIPT_FILENAME $document_root2$fastcgi_script_name;<br />
fastcgi_param PATH_INFO $fastcgi_path_info;<br />
fastcgi_param PATH_TRANSLATED $document_root2$fastcgi_path_info;<br />
include fastcgi_params;<br />
fastcgi_param DOCUMENT_ROOT $document_root2;<br />
}<br />
<br />
=== Error: The page you are looking for is temporarily unavailable. Please try again later. ===<br />
<br />
This is because the FastCGI server has not been started, or the socket used has wrong permissions.<br />
<br />
=== Error: No input file specified ===<br />
<br />
1. Most Likely you do not have the SCRIPT_FILENAME containing the full path to your scripts.<br />
If the configuration of nginx (fastcgi_param SCRIPT_FILENAME) is correct, this kind of error means php failed to load the requested script. Usually it is simply a permissions issue, you can just run php-cgi as root<br />
# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi<br />
or you should create a group and user to start the php-cgi. For example:<br />
# groupadd www<br />
# useradd -g www www<br />
# chmod +w /srv/www/nginx/html<br />
# chown -R www:www /srv/www/nginx/html<br />
# spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi<br />
<br />
2. Another occasion is that, wrong "root" argument in the "location ~ \.php$" section in {{ic|nginx.conf}}, make sure the "root" points to the same directory as it in "location /" in the same server. Or you may just set root as global, do not define it in any location section.<br />
<br />
3. Verify that variable "open_basedir" in {{ic|/etc/php/php.ini}} also contains path you specified in "root" argument in {{ic|nginx.conf}}<br />
<br />
4. Also notice that not only php script should have read permission, but also the entire directory structure should have execute permission so that PHP user can traverse the path.<br />
<br />
=== Error: "File not found" in browser or "Primary script unknown" in log file ===<br />
<br />
Ensure you've specified a '''root''' and '''index''' in your '''server''' or '''location''' directive:<br />
location ~ \.php$ {<br />
root /srv/http/root_dir;<br />
index index.php;<br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
include fastcgi.conf;<br />
}<br />
<br />
=== Error: chroot: '/usr/sbin/nginx' No such file or directory ===<br />
<br />
If you encounter this error when running the daemon of nginx using chroot, this is likely due to missing 64 bit libraries in the jailed environment.<br />
<br />
If you are running chroot in {{ic|/srv/http}} you need to add the required 64 bit libraries. <br />
<br />
First, set up the directories (these commands will need to be run as root)<br />
<br />
# mkdir /srv/http/usr/lib64 <br />
# cd /srv/http; ln -s usr/lib64 lib64<br />
<br />
Then copy the required 64 bit libraries found using {{ic|ldd /usr/sbin/nginx}} to {{ic|/srv/http/usr/lib64}}<br />
<br />
if run as root, permissions for the libraries should be read and executable for all users, so no modification is required.<br />
<br />
=== Error: Blank page through FastCGI ===<br />
<br />
No error trace, code 200 in access.log but blank page:<br />
<br />
<html><br />
<head></head><br />
<body></body><br />
</html><br />
<br />
Solution from [http://beutelevision.com/blog2/2013/08/26/nginx-with-php-fpm-generating-blank-page/ Thomas Beutel's blog]:<br />
<br />
Edit {{ic|/etc/nginx/nginx.conf}} and add a {{ic|fastcgi_param}} line in php {{ic|location}} section:<br />
<br />
location ~ \.php$ {<br />
...<br />
include fastcgi_params;<br />
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;<br />
...<br />
}<br />
<br />
php_fpm needs this so that it knows the path to the PHP file.<br />
<br />
=== Alternative Script for Systemd ===<br />
<br />
On pure Systemd you can get advantages of chroot + Systemd -> [http://0pointer.de/blog/projects/changing-roots.html Systemd for Administrators, Part VI ]<br />
Based on set [http://wiki.nginx.org/CoreModule#user user group] an pid on:<br />
{{hc|/etc/nginx/nginx.conf|2=<br />
user http;<br />
pid /run/nginx.pid;<br />
}}<br />
the absolute path of file is {{ic|/srv/http/etc/nginx/nginx.conf}}<br />
{{hc|/etc/systemd/system/nginx.service|2=<br />
[Unit]<br />
Description=Nginx (Chroot)<br />
After=syslog.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/srv/http/run/nginx.pid<br />
RootDirectory=/srv/http<br />
ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf<br />
ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf<br />
ExecReload=/usr/sbin/nginx -c /etc/nginx/nginx.conf -s reload<br />
ExecStop=/usr/sbin/nginx -c /etc/nginx/nginx.conf -s stop<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
Is not necesary set the default location, nginx loads at default {{ic| -c /etc/nginx/nginx.conf}}, but is a good idea set it. <br />
<br />
Alternatively can run '''only''' ExecStart as chroot whit parameter {{ic|RootDirectoryStartOnly}} set as yes [[http://www.freedesktop.org/software/systemd/man/systemd.service.html man systemd service]] or start it before mount point as efective or a [http://www.freedesktop.org/software/systemd/man/systemd.path.html systemd path] is available.<br />
<br />
{{hc|/etc/systemd/system/nginx.path|2=<br />
[Unit]<br />
Description=Nginx (Chroot) path<br />
[Path]<br />
PathExists=/srv/http/site/Public_html<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
to activate it<br />
{{ic|systemctl enable nginx.path }} <br />
and change on {{ic|/etc/systemd/system/nginx.service}} '''WantedBy=default.target''' to '''WantedBy=nginx.path'''<br />
Practicality may be that the mount point delay unless the folder to be accessible, each time the point is accessible, systemd start the server. In my case, I prefer to mount, and before Bind to existing Dir. <br />
<br />
The {{ic| PIDFile}} on .service file allows Systemd to monitor process(absolute Path), If not the desired behavior, you can change to default one-shoot Type, and delete the reference on .service file.<br />
<br />
<br />
== See Also ==<br />
* [https://calomel.org/nginx.html Very good in-depth 2014 look at Nginx security and Reverse Proxying]<br />
* [[Nginx/Init_script|Init script for Nginx]]<br />
* [http://nginx.org/ Nginx Official Site]<br />
* [http://calomel.org/nginx.html Nginx HowTo]<br />
* [http://blog.gotux.net/tutorial/custom-nginx-indexer/ Custom Nginx Indexer]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Nginx&diff=311275Nginx2014-04-21T07:19:13Z<p>Saren: Prevent "spawn-fcgi: removing old socket failed: Permission denied"</p>
<hr />
<div>[[Category:Web Server]]<br />
[[de:Nginx]]<br />
[[ja:Nginx]]<br />
[[ru:Nginx]]<br />
[[zh-CN:Nginx]]<br />
'''Nginx''' (pronounced "engine X"), is a free, open-source, high-performance HTTP server and reverse proxy, as well as an IMAP/POP3 proxy server, written by Igor Sysoev in 2005. According to Netcraft's [http://news.netcraft.com/archives/2014/01/03/january-2014-web-server-survey.html January 2014 Web Server Survey], Nginx now hosts 14.4% of all domains worldwide, while [[Apache]] hosts about 41.64%. Nginx is now well known for its stability, rich feature set, simple configuration, and low resource consumption.<br />
<br />
== Installation ==<br />
<br />
[[Pacman|Install]] package {{Pkg|nginx}} in the [[official repositories]].<br />
<br />
For a ''Ruby on Rails'' oriented installation, see [[Ruby on Rails#The Perfect Rails Setup]].<br />
<br />
For a chroot-based installation for additional security, see [[#Installation_in_a_chroot]]<br />
<br />
== Running ==<br />
<br />
To enable the Nginx service by default at start-up, run:<br />
# systemctl enable nginx<br />
<br />
To start the Nginx service, run:<br />
# systemctl start nginx<br />
<br />
The default served page at http://127.0.0.1 is: <br />
/usr/share/nginx/html/index.html<br />
<br />
== Configuring ==<br />
<br />
You can modify the configuration by editing the files in {{ic|/etc/nginx/}}. The main configuration file is located at {{ic|/etc/nginx/nginx.conf}}. <br />
<br />
More details can be found here: [http://wiki.nginx.org/Configuration Nginx Configuration Examples].<br />
<br />
The examples below cover the most common use cases. It is assumed that you use the default location for documents ({{ic|/usr/share/nginx/html}}). If that is not the case, substitute your path instead.<br />
<br />
=== General Configuration ===<br />
<br />
You should choose a fitting value for {{ic|worker_processes}}. This settings ultimately defines how many connection nginx will accept and how many processors it will be able to make use of. Generally, making it the number of hardware threads in your system is a good start. As such, with modern servers, set something like<br />
<br />
worker_processes 8;<br />
<br />
The maximum connections nginx will accept is given by {{ic|1=max_clients = worker_processes * worker_connections}}.<br />
<br />
=== FastCGI ===<br />
<br />
FastCGI, also FCGI, is a protocol for interfacing interactive programs with a web server. FastCGI is a variation on the earlier Common Gateway Interface (CGI); FastCGI's main aim is to reduce the overhead associated with interfacing the web server and CGI programs, allowing a server to handle more web page requests at once.<br />
<br />
FastCGI technology is introduced into Nginx to work with many external tools, i.e.: Perl, [[PHP]] and [[Python]].<br />
<br />
==== PHP implementation ====<br />
<br />
There are different ways to run a FastCGI server for PHP. We cover '''php-fpm''', a recommended solution.<br />
<br />
===== Step 1: PHP configuration =====<br />
<br />
The {{Ic|open_basedir}} in {{ic|/etc/php/php.ini}} has to list base directories which contain PHP files, like {{ic|/usr/share/nginx/html/}} and {{ic|/usr/share/webapps/}}:<br />
open_basedir = /usr/share/webapps/:/srv/http/:/usr/share/nginx/html/:/home/:/tmp/:/usr/share/pear/<br />
<br />
After that let's configure modules you need. For example to use sqlite3 you should install {{ic|php-sqlite}}. Then enable it in {{ic|/etc/php/php.ini}} by uncommenting following line:<br />
extension=sqlite3.so<br />
<br />
If you run nginx in chrooted environment (chroot is {{ic|/srv/nginx-jail}}, web pages are served at {{ic|/srv/nginx-jail/www}}), the directive refers to the chroot only (i.e. {{ic|1=open_basedir = /www}}) only.<br />
<br />
===== Step 2: php-fpm =====<br />
<br />
* http://php-fpm.org<br />
<br />
Install {{Pkg|php-fpm}}.<br />
The configuration file is {{ic|/etc/php/php-fpm.conf}}.<br />
Enable and start the [[systemd]] ''php-fpm.service''.<br />
<br />
If you run nginx in chrooted environment (chroot is {{ic|/srv/nginx-jail}}, web pages are served at {{ic|/srv/nginx-jail/www}}), you must modify the file {{ic|/etc/php/php-fpm.conf}} to include the {{ic|chroot /srv/nginx-jail}} and {{ic|1=listen = /srv/nginx-jail/run/php-fpm/php-fpm.sock}} directives within the pool name section (a default one is {{ic|[www]}}). (Create the directory for the socket file, if missing.)<br />
<br />
===== Step 3: Nginx configuration =====<br />
<br />
Inside each {{Ic|server}} block serving a PHP web application should appear a {{Ic|location}} block similar to:<br />
location ~ \.php$ {<br />
try_files $uri = 404; <br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
fastcgi_index index.php;<br />
include fastcgi.conf;<br />
}<br />
<br />
If the {{Ic|root}} path in specified only inside a {{Ic|location}} (as it is in the default config), then either add<br />
root /srv/http<br />
to the {{Ic|location ~ \.php$}}, or move it directly somewhere under {{Ic|server}}.<br />
<br />
A complete working configuration could look like this:<br />
<br />
server {<br />
listen 80;<br />
server_name localhost;<br />
root /usr/share/nginx/html;<br />
location / {<br />
index index.html index.htm index.php;<br />
}<br />
<br />
location ~ \.php$ {<br />
#fastcgi_pass 127.0.0.1:9000; (depending on your php-fpm socket configuration)<br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
fastcgi_index index.php;<br />
include fastcgi.conf;<br />
}<br />
}<br />
<br />
You could create {{Ic|/etc/nginx/php.conf}} and save the php bit of the configuration there, then when needed just include this file into the {{Ic|server}} block.<br />
server = {<br />
...<br />
include php.conf;<br />
...<br />
}<br />
<br />
If you are going to process .html and .htm files with PHP, you should have something like this:<br />
location ~ \.(php|html|htm)$ {<br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
fastcgi_index index.php;<br />
include fastcgi_params;<br />
}<br />
<br />
Non .php files processing in php-fpm should be explicitly enabled in<br />
{{Ic|/etc/php/php-fpm.conf}}:<br />
security.limit_extensions = .php .html .htm<br />
<br />
You need to restart the php-fpm daemon if you changed the configuration.<br />
# systemctl restart php-fpm<br />
<br />
'''Pay attention''' to the {{Ic|fastcgi_pass}} argument, as it must be the TCP or Unix socket defined by the chosen FastCGI server in its config file. The '''default''' (Unix) socket for {{Ic|php-fpm}} is<br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
You might use the common TCP socket, '''not default''',<br />
fastcgi_pass 127.0.0.1:9000;<br />
Unix domain sockets are however faster.<br />
<br />
{{Ic|fastcgi.conf}} or {{Ic|fastcgi_params}} are usually included because they hold FastCGI settings for Nginx; the use of the latter is deprecated, though. They come within the Nginx installation.<br />
<br />
Finally, if Nginx has been working, run:<br />
# systemctl restart nginx<br />
<br />
If you would like to test the FastCGI implementation, create {{ic|/usr/share/nginx/html/index.php}} with content<br />
<?php<br />
phpinfo();<br />
?> <br />
and visit the URL http://127.0.0.1/index.php with your browser after checking that {{ic|/usr/share/nginx/html}} is included in {{ic|open_basedir}}.<br />
<br />
==== CGI implementation ====<br />
<br />
This implementation is needed for CGI applications.<br />
<br />
===== Step 1: fcgiwrap =====<br />
<br />
Install {{Pkg|fcgiwrap}}.<br />
The configuration file is {{ic|/usr/lib/systemd/system/fcgiwrap.socket}}.<br />
Enable and start the [[systemd]] ''fcgiwrap.socket''.<br />
<br />
The systemd unit file is currently being discussed on [https://bugs.archlinux.org/task/31696 this ArchLinux task page]. You may want to examine the unit file yourself to ensure it will work the way you want.<br />
<br />
====== Multiple worker threads ======<br />
<br />
If you want to spawn multiple worker threads, it's recommended that you use {{AUR|multiwatch}}, which will take care of restarting crashed children. You will need to use {{ic|spawn-fcgi}} to create the unix socket, as multiwatch seems unable to handle the systemd-created socket, even though fcgiwrap itself does not have any trouble if invoked directly in the unit file.<br />
<br />
Copy the unit file from {{ic|/usr/lib/systemd/system/fcgiwrap.service}} to {{ic|/etc/systemd/system/fcgiwrap.service}} (and the {{ic|fcgiwrap.socket}} unit, if present), and modify the {{ic|ExecStart}} line to suit your needs. Here is a unit file that uses {{AUR|multiwatch}}. Make sure {{ic|fcgiwrap.socket}} is not started or enabled, because it will conflict with this unit:<br />
<br />
{{hc|/etc/systemd/system/fcgiwrap.service|2=<br />
[Unit]<br />
Description=Simple CGI Server<br />
After=nss-user-lookup.target<br />
<br />
[Service]<br />
ExecStartPre=/bin/rm /run/fcgiwrap.socket<br />
ExecStart=/usr/bin/spawn-fcgi -u http -g http -s /run/fcgiwrap.sock -n -- /usr/bin/multiwatch -f 10 -- /usr/sbin/fcgiwrap<br />
ExecStartPost=/usr/bin/chmod 660 /run/fcgiwrap.sock<br />
PrivateTmp=true<br />
Restart=on-failure<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
<br />
Tweak {{ic|-f 10}} to change the number of children that are spawned.<br />
<br />
{{Warning|The ExecStartPost line is required because of strange behaviour I'm seeing when I use the {{ic|-M 660}} option for {{ic|spawn-fcgi}}. The wrong mode is set. This may be a bug?}}<br />
<br />
===== Step 2: Nginx configuration =====<br />
<br />
Inside each {{Ic|server}} block serving a CGI web application should appear a {{Ic|location}} block similar to:<br />
<br />
location ~ \.cgi$ {<br />
root /path/to/server/cgi-bin/<br />
fastcgi_pass unix:/run/fcgiwrap.sock;<br />
include fastcgi.conf;<br />
}<br />
<br />
The '''default''' (Unix) socket for {{Ic|fcgiwrap}} is ''/run/fcgiwrap.sock''.<br />
<br />
== Installation in a chroot ==<br />
<br />
Installing Nginx in a chroot adds an additional layer of security. For<br />
maximum security the chroot should include only the files needed to run<br />
the Nginx server and all files should have the most restrictive<br />
permissions possible, e.g., as much as possible should be owned by root,<br />
directories such as {{ic|/usr/bin}} should be unreadable and unwriteable,<br />
etc. <br />
<br />
Arch comes with an {{ic|http}} user and group by default which will run the<br />
server. The chroot will be in {{ic|/srv/http}}.<br />
<br />
A perl script to create this jail is available at<br />
[https://gist.github.com/4365696 jail.pl gist]. You can either use that or follow the instructions in this article. It expects to be run<br />
as root. You will need to uncomment a line before it makes any changes.<br />
<br />
=== Create Necessary Devices ===<br />
<br />
Nginx needs {{ic|/dev/null}}, {{ic|/dev/random}}, and<br />
{{ic|/dev/urandom}}. To install these in the chroot we create the<br />
{{ic|/dev/}} folder and add the devices with mknod. We avoid mounting<br />
all of {{ic|/dev/}} to ensure that, even if the chroot is compromised, an<br />
attacker must break out of the chroot to access important devices like<br />
{{ic|/dev/sda1}}.<br />
<br />
{{Tip|See {{ic|man mknod}} and {{ic|<nowiki>ls -l<br />
/dev/{null,random,urandom}</nowiki>}} to better<br />
understand the argument to mknod.}}<br />
<br />
# export JAIL=/srv/http<br />
# mkdir $JAIL/dev<br />
# mknod -m 0666 $JAIL/dev/null c 1 3<br />
# mknod -m 0666 $JAIL/dev/random c 1 8<br />
# mknod -m 0444 $JAIL/dev/urandom c 1 9<br />
<br />
=== Create Necessary Folders ===<br />
<br />
Nginx requires a bunch of files to run properly. Before copying them<br />
over, create the folders to store them. This assumes your Nginx document<br />
root will be {{ic|/srv/http/www}}.<br />
<br />
# mkdir -p $JAIL/etc/nginx/logs<br />
# mkdir -p $JAIL/usr/{lib,bin}<br />
# mkdir -p $JAIL/usr/share/nginx<br />
# mkdir -p $JAIL/var/{log,lib}/nginx<br />
# mkdir -p $JAIL/www/cgi-bin<br />
# mkdir -p $JAIL/{run,tmp}<br />
# cd $JAIL; ln -s usr/lib lib <br />
<br />
{{Note| If using a 64 bit kernel you will need to create symbolic links {{ic|lib64}} and {{ic|usr/lib64}} to {{ic|usr/lib}}: {{ic|cd $JAIL; ln -s usr/lib lib64}} and {{ic|cd $JAIL/usr; ln -s lib lib64}}<br />
}}<br />
Then mount {{ic|$JAIL/tmp}} and {{ic|$JAIL/run}} as tmpfs's. The size<br />
should be limited to ensure an attacker cannot eat all the RAM.<br />
<br />
# mount -t tmpfs none $JAIL/run -o 'noexec,size=1M'<br />
# mount -t tmpfs none $JAIL/tmp -o 'noexec,size=100M'<br />
<br />
In order to preserve the mounts across reboots, the following entries should be added to /etc/fstab:<br />
<br />
{{hc|/etc/fstab|<nowiki><br />
tmpfs /srv/http/run tmpfs rw,noexec,relatime,size=1024k 0 0<br />
tmpfs /srv/http/tmp tmpfs rw,noexec,relatime,size=102400k 0 0<br />
</nowiki>}}<br />
<br />
=== Populate the chroot ===<br />
<br />
First copy over the easy files.<br />
<br />
# cp -r /usr/share/nginx/* $JAIL/usr/share/nginx<br />
# cp -r /usr/share/nginx/html/* $JAIL/www<br />
# cp /usr/bin/nginx $JAIL/usr/bin/<br />
# cp -r /var/lib/nginx $JAIL/var/lib/nginx<br />
<br />
Now copy over required libraries. Use ldd to list them and then copy<br />
them all to the correct location. Copying is preferred over hardlinks to<br />
ensure that even if an attacker gains write access to the files they<br />
cannot destroy or alter the true system files.<br />
<br />
{{hc|$ ldd /usr/bin/nginx|<nowiki><br />
linux-vdso.so.1 (0x00007fffc41fe000)<br />
libpthread.so.0 => /usr/lib/libpthread.so.0 (0x00007f57ec3e8000)<br />
libcrypt.so.1 => /usr/lib/libcrypt.so.1 (0x00007f57ec1b1000)<br />
libstdc++.so.6 => /usr/lib/libstdc++.so.6 (0x00007f57ebead000)<br />
libm.so.6 => /usr/lib/libm.so.6 (0x00007f57ebbaf000)<br />
libpcre.so.1 => /usr/lib/libpcre.so.1 (0x00007f57eb94c000)<br />
libssl.so.1.0.0 => /usr/lib/libssl.so.1.0.0 (0x00007f57eb6e0000)<br />
libcrypto.so.1.0.0 => /usr/lib/libcrypto.so.1.0.0 (0x00007f57eb2d6000)<br />
libdl.so.2 => /usr/lib/libdl.so.2 (0x00007f57eb0d2000)<br />
libz.so.1 => /usr/lib/libz.so.1 (0x00007f57eaebc000)<br />
libGeoIP.so.1 => /usr/lib/libGeoIP.so.1 (0x00007f57eac8d000)<br />
libgcc_s.so.1 => /usr/lib/libgcc_s.so.1 (0x00007f57eaa77000)<br />
libc.so.6 => /usr/lib/libc.so.6 (0x00007f57ea6ca000)<br />
/lib64/ld-linux-x86-64.so.2 (0x00007f57ec604000)</nowiki>}}<br />
<br />
# cp /lib64/ld-linux-x86-64.so.2 $JAIL/lib<br />
<br />
For files residing in {{ic|/usr/lib}} you may try the following one-liner:<br />
{{bc|<nowiki># cp $(ldd /usr/bin/nginx | grep /usr/lib | sed -sre 's/(.+)(\/usr\/lib\/\S+).+/\2/g') $JAIL/usr/lib</nowiki>}}<br />
<br />
{{Note|Do not try to copy linux-vdso.so – it is not a real library and does not exist in /usr/lib. Also ld-linux-x86-64.so will likely be listed in /lib64 for a 64 bit system.}}<br />
<br />
Copy over some misc. but necessary libraries and system files.<br />
<br />
{{bc|# cp /usr/lib/libnss_* $JAIL/usr/lib<br />
# cp -rfvL /etc/{services,localtime,nsswitch.conf,nscd.conf,protocols,hosts,ld.so.cache,ld.so.conf,resolv.conf,host.conf,nginx} $JAIL/etc}}<br />
<br />
Create restricted user/group files for the chroot. This way only the<br />
users needed for the chroot to function exist as far as the chroot<br />
knows, and none of the system users/groups are leaked to attackers<br />
should they gain access to the chroot.<br />
<br />
{{hc|$JAIL/etc/group|<br />
http:x:33:<br />
nobody:x:99:<br />
}}<br />
<br />
{{hc|$JAIL/etc/passwd|<br />
http:x:33:33:http:/:/bin/false<br />
nobody:x:99:99:nobody:/:/bin/false<br />
}}<br />
<br />
{{hc|$JAIL/etc/shadow|<br />
http:x:14871::::::<br />
nobody:x:14871::::::<br />
}}<br />
<br />
{{hc|$JAIL/etc/gshadow|<br />
http:::<br />
nobody:::<br />
}}<br />
<br />
# touch $JAIL/etc/shells<br />
# touch $JAIL/run/nginx.pid<br />
<br />
Finally make set very restrictive permissions. As much as possible<br />
should be owned by root and set unwritable.<br />
<br />
# chown -R root:root $JAIL/<br />
<br />
# chown -R http:http $JAIL/www<br />
# chown -R http:http $JAIL/etc/nginx<br />
# chown -R http:http $JAIL/var/{log,lib}/nginx<br />
# chown http:http $JAIL/run/nginx.pid<br />
<br />
# find $JAIL/ -gid 0 -uid 0 -type d -print | xargs sudo chmod -rw<br />
# find $JAIL/ -gid 0 -uid 0 -type d -print | xargs sudo chmod +x<br />
# find $JAIL/etc -gid 0 -uid 0 -type f -print | xargs sudo chmod -x<br />
# find $JAIL/usr/bin -type f -print | xargs sudo chmod ug+rx<br />
# find $JAIL/ -group http -user http -print | xargs sudo chmod o-rwx<br />
# chmod +rw $JAIL/tmp<br />
# chmod +rw $JAIL/run<br />
<br />
If your server will bind port 80 (or any port 0-1024), give the<br />
chrooted executable permission to bind these ports without root.<br />
<br />
# setcap 'cap_net_bind_service=+ep' $JAIL/usr/bin/nginx<br />
<br />
=== Modify nginx.service to start chroot ===<br />
<br />
Before modifying the nginx.service unit file, it may be a good idea to copy it to<br />
{{ic|/etc/systemd/system/}} since the unit files there take priority over those in {{ic|/usr/lib/systemd/system/}}. <br />
This means upgrading nginx would not modify your custom .service file. <br />
# cp /usr/lib/systemd/system/nginx.service /etc/systemd/system/nginx.service<br />
<br />
The systemd unit must be changed to start up Nginx in the chroot, as<br />
the http user, and store the pid file in the chroot <br />
{{Note|I'm not sure if the pid file needs to be stored in the chroot jail.}}<br />
<br />
{{hc|/etc/systemd/system/nginx.service|<nowiki><br />
[Unit]<br />
Description=A high performance web server and a reverse proxy server<br />
After=syslog.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/srv/http/run/nginx.pid<br />
ExecStartPre=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -t -q -g 'pid /run/nginx.pid; daemon on; master_process on;'<br />
ExecStart=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;'<br />
ExecReload=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid; daemon on; master_process on;' -s reload<br />
ExecStop=/usr/bin/chroot --userspec=http:http /srv/http /usr/bin/nginx -g 'pid /run/nginx.pid;' -s quit<br />
<br />
[Install]<br />
WantedBy=multi-user.target</nowiki>}}<br />
<br />
{{Note|Upgrading nginx with pacman will not upgrade the chrooted nginx installation. You have to take care of the updates manually by repeating some of the steps above. Do not forget to also update the libraries it links against. }}<br />
<br />
You can now safely get rid of the non-chrooted nginx installation. <br />
# pacman -Rsc nginx<br />
<br />
If you do not remove the non-chrooted nginx installation, you may want to make sure that the running nginx process is in fact the chrooted one. You can do so by checking where {{ic|/proc/{PID}/root}} symmlinks to. If should link to {{ic|/srv/http}} instead of {{ic|/}}. <br />
# ps -C nginx | awk '{print $1}' | sed 1d | while read -r PID; do ls -l /proc/$PID/root; done<br />
<br />
== Troubleshooting ==<br />
<br />
=== Accessing local IP redirects to localhost ===<br />
<br />
Solution from the Arch Linux [https://bbs.archlinux.org/viewtopic.php?pid=780561#p780561 forum].<br />
<br />
Edit {{ic|/etc/nginx/nginx.conf}} and locate the "server_name localhost" line without a # infront of it, and add below:<br />
server_name_in_redirect off;<br />
<br />
Default behavior is that nginx redirects any requests to the value given as server_name in the config.<br />
<br />
=== Error: 403 (Permission error) ===<br />
<br />
This is most likely a permission error. Are you sure whatever user configured in the Nginx configuration is able to read the correct files?<br />
<br />
If the files are located within a home directory, (e.g. {{ic|/home/arch/public/webapp}}) and you are sure the user running Nginx has the right permissions (you can temporarily chmod all the files to 777 in order to determine this), {{ic|/home/arch}} might be '''chmod 750''', simply {{Ic|chmod}} it to ''751'', and it should work.<br />
<br />
'''If you have changed your document root'''<br />
<br />
If you are sure that permissions are as they should be, make sure that your document root directory is not empty. Try creating index.html in there.<br />
<br />
=== Error: 404 (Pathinfo error) ===<br />
<br />
In some framework (like thinkphp, cakephp) or CMS, they need the pathinfo function. <br />
<br />
1. Edit the file {{ic|/etc/php/php.ini}}, make sure<br />
cgi.fix_pathinfo=1<br />
2. Edit {{ic|/etc/nginx/conf/nginx.conf}}, comment<br />
<br />
location ~ \.php$ {<br />
...<br />
}<br />
<br />
to <br />
<br />
#location ~ \.php$ {<br />
#...<br />
#}<br />
<br />
Then add the follows,<br />
location ~ ^(.+\.php)(.*)$ {<br />
root /srv/http/nginx;<br />
fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock; <br />
#fastcgi_pass 127.0.0.1:9000; #Un-comment this and comment "fastcgi_pass unix:/var/run/php-fpm/php-fpm.sock;" if you are not using php-fpm.<br />
fastcgi_index index.php;<br />
set $document_root2 $document_root;<br />
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }<br />
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }<br />
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }<br />
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }<br />
if ($document_root2 ~ "^(.*\\\\).*?[\\\\|\/]\.\.\/(.*)$") { set $document_root2 $1$2; }<br />
fastcgi_split_path_info ^(.+\.php)(.*)$;<br />
fastcgi_param SCRIPT_FILENAME $document_root2$fastcgi_script_name;<br />
fastcgi_param PATH_INFO $fastcgi_path_info;<br />
fastcgi_param PATH_TRANSLATED $document_root2$fastcgi_path_info;<br />
include fastcgi_params;<br />
fastcgi_param DOCUMENT_ROOT $document_root2;<br />
}<br />
<br />
=== Error: The page you are looking for is temporarily unavailable. Please try again later. ===<br />
<br />
This is because the FastCGI server has not been started, or the socket used has wrong permissions.<br />
<br />
=== Error: No input file specified ===<br />
<br />
1. Most Likely you do not have the SCRIPT_FILENAME containing the full path to your scripts.<br />
If the configuration of nginx (fastcgi_param SCRIPT_FILENAME) is correct, this kind of error means php failed to load the requested script. Usually it is simply a permissions issue, you can just run php-cgi as root<br />
# spawn-fcgi -a 127.0.0.1 -p 9000 -f /usr/bin/php-cgi<br />
or you should create a group and user to start the php-cgi. For example:<br />
# groupadd www<br />
# useradd -g www www<br />
# chmod +w /srv/www/nginx/html<br />
# chown -R www:www /srv/www/nginx/html<br />
# spawn-fcgi -a 127.0.0.1 -p 9000 -u www -g www -f /usr/bin/php-cgi<br />
<br />
2. Another occasion is that, wrong "root" argument in the "location ~ \.php$" section in {{ic|nginx.conf}}, make sure the "root" points to the same directory as it in "location /" in the same server. Or you may just set root as global, do not define it in any location section.<br />
<br />
3. Verify that variable "open_basedir" in {{ic|/etc/php/php.ini}} also contains path you specified in "root" argument in {{ic|nginx.conf}}<br />
<br />
4. Also notice that not only php script should have read permission, but also the entire directory structure should have execute permission so that PHP user can traverse the path.<br />
<br />
=== Error: "File not found" in browser or "Primary script unknown" in log file ===<br />
<br />
Ensure you've specified a '''root''' and '''index''' in your '''server''' or '''location''' directive:<br />
location ~ \.php$ {<br />
root /srv/http/root_dir;<br />
index index.php;<br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
include fastcgi.conf;<br />
}<br />
<br />
=== Error: chroot: '/usr/sbin/nginx' No such file or directory ===<br />
<br />
If you encounter this error when running the daemon of nginx using chroot, this is likely due to missing 64 bit libraries in the jailed environment.<br />
<br />
If you are running chroot in {{ic|/srv/http}} you need to add the required 64 bit libraries. <br />
<br />
First, set up the directories (these commands will need to be run as root)<br />
<br />
# mkdir /srv/http/usr/lib64 <br />
# cd /srv/http; ln -s usr/lib64 lib64<br />
<br />
Then copy the required 64 bit libraries found using {{ic|ldd /usr/sbin/nginx}} to {{ic|/srv/http/usr/lib64}}<br />
<br />
if run as root, permissions for the libraries should be read and executable for all users, so no modification is required.<br />
<br />
=== Error: Blank page through FastCGI ===<br />
<br />
No error trace, code 200 in access.log but blank page:<br />
<br />
<html><br />
<head></head><br />
<body></body><br />
</html><br />
<br />
Solution from [http://beutelevision.com/blog2/2013/08/26/nginx-with-php-fpm-generating-blank-page/ Thomas Beutel's blog]:<br />
<br />
Edit {{ic|/etc/nginx/nginx.conf}} and add a {{ic|fastcgi_param}} line in php {{ic|location}} section:<br />
<br />
location ~ \.php$ {<br />
...<br />
include fastcgi_params;<br />
fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;<br />
...<br />
}<br />
<br />
php_fpm needs this so that it knows the path to the PHP file.<br />
<br />
=== Alternative Script for Systemd ===<br />
<br />
On pure Systemd you can get advantages of chroot + Systemd -> [http://0pointer.de/blog/projects/changing-roots.html Systemd for Administrators, Part VI ]<br />
Based on set [http://wiki.nginx.org/CoreModule#user user group] an pid on:<br />
{{hc|/etc/nginx/nginx.conf|2=<br />
user http;<br />
pid /run/nginx.pid;<br />
}}<br />
the absolute path of file is {{ic|/srv/http/etc/nginx/nginx.conf}}<br />
{{hc|/etc/systemd/system/nginx.service|2=<br />
[Unit]<br />
Description=Nginx (Chroot)<br />
After=syslog.target network.target<br />
<br />
[Service]<br />
Type=forking<br />
PIDFile=/srv/http/run/nginx.pid<br />
RootDirectory=/srv/http<br />
ExecStartPre=/usr/sbin/nginx -t -c /etc/nginx/nginx.conf<br />
ExecStart=/usr/sbin/nginx -c /etc/nginx/nginx.conf<br />
ExecReload=/usr/sbin/nginx -c /etc/nginx/nginx.conf -s reload<br />
ExecStop=/usr/sbin/nginx -c /etc/nginx/nginx.conf -s stop<br />
<br />
[Install]<br />
WantedBy=multi-user.target<br />
}}<br />
Is not necesary set the default location, nginx loads at default {{ic| -c /etc/nginx/nginx.conf}}, but is a good idea set it. <br />
<br />
Alternatively can run '''only''' ExecStart as chroot whit parameter {{ic|RootDirectoryStartOnly}} set as yes [[http://www.freedesktop.org/software/systemd/man/systemd.service.html man systemd service]] or start it before mount point as efective or a [http://www.freedesktop.org/software/systemd/man/systemd.path.html systemd path] is available.<br />
<br />
{{hc|/etc/systemd/system/nginx.path|2=<br />
[Unit]<br />
Description=Nginx (Chroot) path<br />
[Path]<br />
PathExists=/srv/http/site/Public_html<br />
[Install]<br />
WantedBy=default.target<br />
}}<br />
to activate it<br />
{{ic|systemctl enable nginx.path }} <br />
and change on {{ic|/etc/systemd/system/nginx.service}} '''WantedBy=default.target''' to '''WantedBy=nginx.path'''<br />
Practicality may be that the mount point delay unless the folder to be accessible, each time the point is accessible, systemd start the server. In my case, I prefer to mount, and before Bind to existing Dir. <br />
<br />
The {{ic| PIDFile}} on .service file allows Systemd to monitor process(absolute Path), If not the desired behavior, you can change to default one-shoot Type, and delete the reference on .service file.<br />
<br />
<br />
== See Also ==<br />
* [https://calomel.org/nginx.html Very good in-depth 2014 look at Nginx security and Reverse Proxying]<br />
* [[Nginx/Init_script|Init script for Nginx]]<br />
* [http://nginx.org/ Nginx Official Site]<br />
* [http://calomel.org/nginx.html Nginx HowTo]<br />
* [http://blog.gotux.net/tutorial/custom-nginx-indexer/ Custom Nginx Indexer]</div>Sarenhttps://wiki.archlinux.org/index.php?title=Nagios&diff=309924Nagios2014-04-10T16:05:18Z<p>Saren: /* Nginx Configuration */</p>
<hr />
<div>[[Category:Networking]]<br />
[http://www.nagios.org/ Nagios] is an open source host, service and network monitoring program. It monitors specified hosts and services, alerting you to any developing issues, errors or improvements. This article describes the installation and configuration of Nagios.<br />
<br />
==Features==<br />
Some of Nagios' features [http://nagios.sourceforge.net/docs/3_0/about.html#whatis include]:<br />
*Monitoring of network services (SMTP, POP3, HTTP, NNTP, PING, etc.)<br />
*Monitoring of host resources (processor load, disk usage, etc.)<br />
*Simple plugin design that allows users to easily develop their own service checks<br />
*Parallelized service checks<br />
*Ability to define network host hierarchy using "parent" hosts, allowing detection of and distinction between hosts that are down and those that are unreachable<br />
*Contact notifications when service or host problems occur and get resolved (via email, pager, or user-defined method)<br />
*Ability to define event handlers to be run during service or host events for proactive problem resolution<br />
*Automatic log file rotation<br />
*Support for implementing redundant monitoring hosts<br />
*Optional web interface for viewing current network status, notification and problem history, log file, etc.<br />
<br />
The following installation and configuration were tested using nagios 3.2.0-1, [[Apache]] web server 2.2.14-2, and [[PHP]]5 5.3.1-3 by [https://bbs.archlinux.org/viewtopic.php?id=88461 awayand].<br />
<br />
==Webserver==<br />
According to the [http://nagios.sourceforge.net/docs/3_0/about.html official documentation] a webserver is not required, but if you wish to use any of the CGI features then a webserver (apache preferred), PHP ([[Apache#PHP|php-apache]]) for it and the gd library are required. This is assumed for this installation<br />
<br />
==Installation==<br />
Install {{AUR|nagios}} from the [[AUR]].<br />
<br />
Users may also want to install {{AUR|nagios-plugins}}.<br />
<br />
==Nagios Configuration==<br />
Copy the sample config files as root:<br />
{{bc|<br />
cp /etc/nagios/cgi.cfg.sample /etc/nagios/cgi.cfg<br />
cp /etc/nagios/resource.cfg.sample /etc/nagios/resource.cfg<br />
cp /etc/nagios/nagios.cfg.sample /etc/nagios/nagios.cfg<br />
cp /etc/nagios/objects/commands.cfg.sample /etc/nagios/objects/commands.cfg<br />
cp /etc/nagios/objects/contacts.cfg.sample /etc/nagios/objects/contacts.cfg<br />
cp /etc/nagios/objects/localhost.cfg.sample /etc/nagios/objects/localhost.cfg<br />
cp /etc/nagios/objects/templates.cfg.sample /etc/nagios/objects/templates.cfg<br />
cp /etc/nagios/objects/timeperiods.cfg.sample /etc/nagios/objects/timeperiods.cfg<br />
}}<br />
<br />
Make owner/group for all the files you just copied and belong to root equal to nagios/nagios:<br />
<br />
{{bc|<br />
# chown -R nagios:nagios /etc/nagios<br />
}}<br />
<br />
Create htpasswd.users file with a username and password, eg. nagiosadmin and secretpass<br />
<br />
{{bc|<br />
# htpasswd -c /etc/nagios/htpasswd.users nagiosadmin<br />
}}<br />
<br />
If the owner/group of the nagios-plugins you installed are root:root, the following needs to be done:<br />
<br />
{{bc|<br />
# chown -R nagios:nagios /usr/share/nagios<br />
}}<br />
<br />
Once Nagios is configured, it is time to configure the webserver.<br />
<br />
==Apache Configuration==<br />
Edit /etc/httpd/conf/httpd.conf, add the following to the end of the file:<br />
<br />
{{bc|<br />
LoadModule php5_module modules/libphp5.so<br />
<br />
# Nagios<br />
Include "conf/extra/nagios.conf"<br />
<br />
# PHP<br />
Include "conf/extra/php5_module.conf"<br />
<br />
}}<br />
<br />
Copy configure file:<br />
# cp /etc/webapps/nagios/apache.example.conf /etc/httpd/conf/extra/nagios.conf<br />
<br />
Add the apache user http to the group nagios, otherwise you will get the following error when using nagios: <br />
Could not open command file '/var/nagios/rw/nagios.cmd' for update!: <br />
<br />
# usermod -G nagios -a http<br />
<br />
==Nginx Configuration==<br />
Apart from php and php-fpm, You should have [https://wiki.archlinux.org/index.php/Nginx#CGI_implementation fcgiwrap] installed or else CGI scripts won't run.<br />
<br />
Example configuration:<br />
{{bc|<br />
1=server {<br />
server_name nagios.yourdomain.tld;<br />
root /usr/share/nagios/share;<br />
listen 80;<br />
index index.php index.html index.htm;<br />
access_log nagios.access.log;<br />
error_log nagios.error.log;<br />
<br />
location ~ \.php$ {<br />
try_files $uri = 404;<br />
fastcgi_index index.php;<br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
include fastcgi.conf;<br />
}<br />
<br />
location ~ \.cgi$ {<br />
root /usr/share/nagios/sbin;<br />
rewrite ^/nagios/cgi-bin/(.*)\.cgi /$1.cgi break;<br />
fastcgi_param AUTH_USER $remote_user;<br />
fastcgi_param REMOTE_USER $remote_user;<br />
include fastcgi.conf;<br />
fastcgi_pass unix:/run/fcgiwrap.socket;<br />
}<br />
<br />
}<br />
}}<br />
<br />
==PHP Configuration==<br />
Edit /etc/php/php.ini to include /usr/share/nagios in the open_basedir directive.<br />
<br />
Example configuration:<br />
<br />
{{bc|1=open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps:/etc/webapps:/usr/share/nagios}}<br />
<br />
==Final Steps==<br />
Start/Restart nagios:<br />
<br />
# systemctl restart nagios<br />
<br />
Start/Restart apache:<br />
<br />
# systemctl restart httpd<br />
<br />
Now you should be able to access nagios through your webbrowser using the username and password you have created above using htpasswd:<br />
<br />
http://localhost/nagios<br />
<br />
==Plugin check_rdiff==<br />
A small guide on monitoring rdiff-backups using a plugin called check_rdiff.<br />
<br />
===Download and Install===<br />
<br />
You will need perl installed.<br />
<br />
{{bc|<br />
cd<br />
wget http://www.monitoringexchange.org/attachment/download/Check-Plugins/Software/Backup/check_rdiff/check_rdiff<br />
cp check_rdiff /usr/share/nagios/libexec<br />
chown nagios:nagios /usr/share/nagios/libexec/check_rdiff<br />
chmod 755 /usr/share/nagios/libexec/check_rdiff<br />
}}<br />
<br />
===Enable sudo for user nagios===<br />
Since the perl script check_rdiff needs to run as root, you will have to enable sudo for the nagios user:<br />
<br />
{{bc|<br />
sudoedit /etc/sudoers<br />
}}<br />
<br />
This will open the /etc/sudoers file, then paste the following at the end of the file (you should know how to use the vi editor, if that is the one being used by sudoedit):<br />
<br />
{{bc|1=<br />
nagios ALL=(root)NOPASSWD:/usr/share/nagios/libexec/check_rdiff<br />
}}<br />
<br />
===Integrate check_rdiff plugin into nagios===<br />
<br />
Edit /etc/nagios/objects/commands.cfg to include the following command definition:<br />
<br />
{{bc|<br />
# check rdiff-backup<br />
define command{<br />
command_name check_rdiff<br />
command_line sudo $USER1$/check_rdiff -r $ARG1$ -w $ARG2$ -c $ARG3$ -l $ARG4$ -p $ARG5$ <br />
}<br />
}}<br />
<br />
Edit /etc/nagios/objects/localhost.cfg to include checking of rdiff-backup on localhost, for example:<br />
<br />
{{bc|<br />
define service{<br />
use local-service ; Name of service template to use<br />
host_name localhost<br />
service_description rdiff-backup<br />
check_command check_rdiff!/home/x/rdiffbackup!8!10!500!24<br />
}<br />
}}<br />
<br />
Quote from the check_rdiff script content:<br />
<br />
''The above command checks the repository (-r) which is defined as the destination of the backup, or more specifically, the directory above the rdiff-backup-data directory. It will return warning if the backup hasn't finished by 8am and critical by 10am. It will also return warning if the TotalDestinationSizeChange is greater than 500Mb. It also get the period set to 24hrs (-p). This is important as the plugin will throw a critical if the backup doesn't start in time.''<br />
<br />
Finally, restart nagios:<br />
<br />
# systemctl restart nagios<br />
<br />
You can now see the rdiff-backup status by clicking on Services on the left side of the nagios web interface control panel.<br />
<br />
==Forks==<br />
*[[Icinga]] is a Nagios fork. More details about the fork can be found at [https://www.icinga.org/faq/why-a-fork/ Icinga FAQ: Why a fork?]<br />
<br />
==See also==<br />
*[http://www.nagios.org/ nagios.org] Official website<br />
*[http://www.nagiosplugins.org/ Nagios Plugins] the home of the official plugins <br />
*[[Wikipedia:Nagios|wikipedia.org]] Wikipedia article<br />
*[http://www.nagiosexchange.org NagiosExchange] overview of plugins, addons, mailing lists for Nagios<br />
*[http://www.nagiosforge.org/ NagiosForge] a repository for ad</div>Sarenhttps://wiki.archlinux.org/index.php?title=Nagios&diff=309923Nagios2014-04-10T16:01:28Z<p>Saren: </p>
<hr />
<div>[[Category:Networking]]<br />
[http://www.nagios.org/ Nagios] is an open source host, service and network monitoring program. It monitors specified hosts and services, alerting you to any developing issues, errors or improvements. This article describes the installation and configuration of Nagios.<br />
<br />
==Features==<br />
Some of Nagios' features [http://nagios.sourceforge.net/docs/3_0/about.html#whatis include]:<br />
*Monitoring of network services (SMTP, POP3, HTTP, NNTP, PING, etc.)<br />
*Monitoring of host resources (processor load, disk usage, etc.)<br />
*Simple plugin design that allows users to easily develop their own service checks<br />
*Parallelized service checks<br />
*Ability to define network host hierarchy using "parent" hosts, allowing detection of and distinction between hosts that are down and those that are unreachable<br />
*Contact notifications when service or host problems occur and get resolved (via email, pager, or user-defined method)<br />
*Ability to define event handlers to be run during service or host events for proactive problem resolution<br />
*Automatic log file rotation<br />
*Support for implementing redundant monitoring hosts<br />
*Optional web interface for viewing current network status, notification and problem history, log file, etc.<br />
<br />
The following installation and configuration were tested using nagios 3.2.0-1, [[Apache]] web server 2.2.14-2, and [[PHP]]5 5.3.1-3 by [https://bbs.archlinux.org/viewtopic.php?id=88461 awayand].<br />
<br />
==Webserver==<br />
According to the [http://nagios.sourceforge.net/docs/3_0/about.html official documentation] a webserver is not required, but if you wish to use any of the CGI features then a webserver (apache preferred), PHP ([[Apache#PHP|php-apache]]) for it and the gd library are required. This is assumed for this installation<br />
<br />
==Installation==<br />
Install {{AUR|nagios}} from the [[AUR]].<br />
<br />
Users may also want to install {{AUR|nagios-plugins}}.<br />
<br />
==Nagios Configuration==<br />
Copy the sample config files as root:<br />
{{bc|<br />
cp /etc/nagios/cgi.cfg.sample /etc/nagios/cgi.cfg<br />
cp /etc/nagios/resource.cfg.sample /etc/nagios/resource.cfg<br />
cp /etc/nagios/nagios.cfg.sample /etc/nagios/nagios.cfg<br />
cp /etc/nagios/objects/commands.cfg.sample /etc/nagios/objects/commands.cfg<br />
cp /etc/nagios/objects/contacts.cfg.sample /etc/nagios/objects/contacts.cfg<br />
cp /etc/nagios/objects/localhost.cfg.sample /etc/nagios/objects/localhost.cfg<br />
cp /etc/nagios/objects/templates.cfg.sample /etc/nagios/objects/templates.cfg<br />
cp /etc/nagios/objects/timeperiods.cfg.sample /etc/nagios/objects/timeperiods.cfg<br />
}}<br />
<br />
Make owner/group for all the files you just copied and belong to root equal to nagios/nagios:<br />
<br />
{{bc|<br />
# chown -R nagios:nagios /etc/nagios<br />
}}<br />
<br />
Create htpasswd.users file with a username and password, eg. nagiosadmin and secretpass<br />
<br />
{{bc|<br />
# htpasswd -c /etc/nagios/htpasswd.users nagiosadmin<br />
}}<br />
<br />
If the owner/group of the nagios-plugins you installed are root:root, the following needs to be done:<br />
<br />
{{bc|<br />
# chown -R nagios:nagios /usr/share/nagios<br />
}}<br />
<br />
Once Nagios is configured, it is time to configure the webserver.<br />
<br />
==Apache Configuration==<br />
Edit /etc/httpd/conf/httpd.conf, add the following to the end of the file:<br />
<br />
{{bc|<br />
LoadModule php5_module modules/libphp5.so<br />
<br />
# Nagios<br />
Include "conf/extra/nagios.conf"<br />
<br />
# PHP<br />
Include "conf/extra/php5_module.conf"<br />
<br />
}}<br />
<br />
Copy configure file:<br />
# cp /etc/webapps/nagios/apache.example.conf /etc/httpd/conf/extra/nagios.conf<br />
<br />
Add the apache user http to the group nagios, otherwise you will get the following error when using nagios: <br />
Could not open command file '/var/nagios/rw/nagios.cmd' for update!: <br />
<br />
# usermod -G nagios -a http<br />
<br />
==Nginx Configuration==<br />
Apart from php and php-fpm, You should have [https://wiki.archlinux.org/index.php/Nginx#CGI_implementation fcgiwrap] installed or else CGI scripts won't run.<br />
<br />
Example configuration:<br />
{{bc|<br />
server {<br />
server_name nagios.yourdomain.tld;<br />
root /usr/share/nagios/share;<br />
listen 80;<br />
index index.php index.html index.htm;<br />
access_log nagios.access.log;<br />
error_log nagios.error.log;<br />
<br />
location ~ \.php$ {<br />
try_files $uri = 404;<br />
fastcgi_index index.php;<br />
fastcgi_pass unix:/run/php-fpm/php-fpm.sock;<br />
include fastcgi.conf;<br />
}<br />
<br />
location ~ \.cgi$ {<br />
root /usr/share/nagios/sbin;<br />
rewrite ^/nagios/cgi-bin/(.*)\.cgi /$1.cgi break;<br />
fastcgi_param AUTH_USER $remote_user;<br />
fastcgi_param REMOTE_USER $remote_user;<br />
include fastcgi.conf;<br />
fastcgi_pass unix:/run/fcgiwrap.socket;<br />
}<br />
<br />
}<br />
}}<br />
<br />
==PHP Configuration==<br />
Edit /etc/php/php.ini to include /usr/share/nagios in the open_basedir directive.<br />
<br />
Example configuration:<br />
<br />
{{bc|1=open_basedir = /srv/http/:/home/:/tmp/:/usr/share/pear/:/usr/share/webapps:/etc/webapps:/usr/share/nagios}}<br />
<br />
==Final Steps==<br />
Start/Restart nagios:<br />
<br />
# systemctl restart nagios<br />
<br />
Start/Restart apache:<br />
<br />
# systemctl restart httpd<br />
<br />
Now you should be able to access nagios through your webbrowser using the username and password you have created above using htpasswd:<br />
<br />
http://localhost/nagios<br />
<br />
==Plugin check_rdiff==<br />
A small guide on monitoring rdiff-backups using a plugin called check_rdiff.<br />
<br />
===Download and Install===<br />
<br />
You will need perl installed.<br />
<br />
{{bc|<br />
cd<br />
wget http://www.monitoringexchange.org/attachment/download/Check-Plugins/Software/Backup/check_rdiff/check_rdiff<br />
cp check_rdiff /usr/share/nagios/libexec<br />
chown nagios:nagios /usr/share/nagios/libexec/check_rdiff<br />
chmod 755 /usr/share/nagios/libexec/check_rdiff<br />
}}<br />
<br />
===Enable sudo for user nagios===<br />
Since the perl script check_rdiff needs to run as root, you will have to enable sudo for the nagios user:<br />
<br />
{{bc|<br />
sudoedit /etc/sudoers<br />
}}<br />
<br />
This will open the /etc/sudoers file, then paste the following at the end of the file (you should know how to use the vi editor, if that is the one being used by sudoedit):<br />
<br />
{{bc|1=<br />
nagios ALL=(root)NOPASSWD:/usr/share/nagios/libexec/check_rdiff<br />
}}<br />
<br />
===Integrate check_rdiff plugin into nagios===<br />
<br />
Edit /etc/nagios/objects/commands.cfg to include the following command definition:<br />
<br />
{{bc|<br />
# check rdiff-backup<br />
define command{<br />
command_name check_rdiff<br />
command_line sudo $USER1$/check_rdiff -r $ARG1$ -w $ARG2$ -c $ARG3$ -l $ARG4$ -p $ARG5$ <br />
}<br />
}}<br />
<br />
Edit /etc/nagios/objects/localhost.cfg to include checking of rdiff-backup on localhost, for example:<br />
<br />
{{bc|<br />
define service{<br />
use local-service ; Name of service template to use<br />
host_name localhost<br />
service_description rdiff-backup<br />
check_command check_rdiff!/home/x/rdiffbackup!8!10!500!24<br />
}<br />
}}<br />
<br />
Quote from the check_rdiff script content:<br />
<br />
''The above command checks the repository (-r) which is defined as the destination of the backup, or more specifically, the directory above the rdiff-backup-data directory. It will return warning if the backup hasn't finished by 8am and critical by 10am. It will also return warning if the TotalDestinationSizeChange is greater than 500Mb. It also get the period set to 24hrs (-p). This is important as the plugin will throw a critical if the backup doesn't start in time.''<br />
<br />
Finally, restart nagios:<br />
<br />
# systemctl restart nagios<br />
<br />
You can now see the rdiff-backup status by clicking on Services on the left side of the nagios web interface control panel.<br />
<br />
==Forks==<br />
*[[Icinga]] is a Nagios fork. More details about the fork can be found at [https://www.icinga.org/faq/why-a-fork/ Icinga FAQ: Why a fork?]<br />
<br />
==See also==<br />
*[http://www.nagios.org/ nagios.org] Official website<br />
*[http://www.nagiosplugins.org/ Nagios Plugins] the home of the official plugins <br />
*[[Wikipedia:Nagios|wikipedia.org]] Wikipedia article<br />
*[http://www.nagiosexchange.org NagiosExchange] overview of plugins, addons, mailing lists for Nagios<br />
*[http://www.nagiosforge.org/ NagiosForge] a repository for ad</div>Saren